Revisión de Arquitecturas para el fomento de la ... · PDF fileLa arquitectura es...

24
Revisión de Arquitecturas para el fomento de la interoperabilidad en e-Salud Vicente Traver Valencia, 21 de Mayo de 2005

Transcript of Revisión de Arquitecturas para el fomento de la ... · PDF fileLa arquitectura es...

Revisión de Arquitecturas para el fomento de la interoperabilidad en e-Salud

Vicente Traver

Valencia, 21 de Mayo de 2005

II Jornadas de Normalización N+ISIS’05

¿Quiénes somos?

• I+D+I en 5 áreas de aplicación de las TIC

• Comunicaciones• Electromagnetismo• Electrónica• Redes de altas prestaciones y GRID• TIC en salud

Ciudad Politécnica de la Innovación (UPV)

• 190 investigadores• 3.500 m2 de laboratorios• Proyectos competitivos de I+D• I+D+I en colaboración con

empresas• Transferencia de tecnología

II Jornadas de Normalización N+ISIS’05

Área TIC en salud: Grupo BET Telemedicina

GRUPO BET-Telemedicina• 44 personas contratadas y estudiantes de último

curso• Ingenieros de telecomunicación• Ingenieros informáticos• Médicos• Nutricionista• Diseñador gráfico• Administrativos

• Actividad centrada en• Proyectos competitivos de I+D: europeos y nacionales• Convenios con empresas• Convenios con la Administración Pública, sector Salud• Desarrollo independiente de soluciones

II Jornadas de Normalización N+ISIS’05

¿Qué es una … arquitectura?

Organización fundamental de un sistema reflejado en sus componentes, las relaciones de cada uno de esos componentes con el resto y con el entorno y los principios que guían su diseño y evolución.

Similitud con arquitectura tradicional

II Jornadas de Normalización N+ISIS’05

¿Qué es … un marco arquitectural?

•Un instrumento que puede ser usado para desarrollar un amplio juego de arquitecturas. Este marco describe un método para diseñar un sistema de información en términos de un juego de componentes básicos y para mostrar cómo dichos componentes básicos se combinan.

•Contiene un conjunto de herramientas y proporciona un vocabulario común.

•Generalmente, también incluye las normas recomendadas y productos adecuados que pueden ser usados para implementar los componentes básicos.

II Jornadas de Normalización N+ISIS’05

¿ Por qué necesitamos una arquitectura?

• Funcionamiento más eficiente de las TIC

• Reducción del riesgo de inversiones futuras

• Consecución mas simple, más rápida y más barata

Los sistemas con una arquitectura explícita parecen resultar más rápidos, mejores y más baratos.

La arquitectura es reconocida como un elemento crítico para el éxito en el desarrollo y evolución de los sistemas.

II Jornadas de Normalización N+ISIS’05

¿Para qué necesitamos una descripción de la arquitectura?

• Expresión del sistema y de su evolución• Recolección de los intereses de los actores• Comunicación entre los actores• Evaluación y comparación de arquitecturas de una manera

consistente• Planificación, gestión y ejecución de las actividades del

desarrollo del sistema• Verificación de la correcta implementación de acuerdo con la

descripción arquitectural

Se utiliza para :

Base de la estandarización y la normalización

II Jornadas de Normalización N+ISIS’05

• Es una práctica recomendada para la descripción arquitectural de los sistemas de software

• No especifica ni medio ni formato para la descripción arquitectural

IEEE 1471-2000

II Jornadas de Normalización N+ISIS’05

Misión

SistemaEntorno Arquitectura

ActorDescripción de la Arquitectura

Base lógica

Punto de vista Vista

ModeloLibrería de puntos de

vista

Competencia

cumple 1..*

influencia

se ubica

posee una

tiene 1..*

identifica 1..*

descrito por

provee

participa en

organizado en 1..*

selecciona 1..*

conforme a

agrega 1..*

Consiste en 1..*

Participa en 1..*

establece métodos para 1..*

tiene como fuente 0..1

usado para cubrir 1..*

identifica 1..*tiene 1..*

está dirigido a 1..*

IEEE 1471-2000

Marco conceptual

II Jornadas de Normalización N+ISIS’05

Misión

SistemaEntorno Arquitectura

ActorDescripción de la Arquitectura

Base lógica

Punto de vista Vista

ModeloLibrería de puntos de

vista

Competencia

cumple 1..*

influencia

se ubica

posee una

tiene 1..*

identifica 1..*

descrito por

provee

participa en

organizado en 1..*

selecciona 1..*

conforme a

agrega 1..*

Consiste en 1..*

Participa en 1..*

establece métodos para 1..*

tiene como fuente 0..1

usado para cubrir 1..*

identifica 1..*tiene 1..*

está dirigido a 1..*

IEEE 1471-2000

Marco conceptual

II Jornadas de Normalización N+ISIS’05

IEEE 1471-2000

• Una vista es una descripción del sistema completo desde la perspectiva de un conjunto de competencias relacionadas

• Un punto de vista es un estándar o plantilla para construir una vista

Vistas y puntos de vista

Vista (view) es lo que se observa

Punto de vista (viewpoint) es desde donde se observa

Vista (view) es lo que se observa

Punto de vista (viewpoint) es desde donde se observa

II Jornadas de Normalización N+ISIS’05

TOGAF

• TOGAF es un marco arquitectural creado por Open Group, que permite el diseño, construcción y evaluación de la arquitectura adecuada para cada caso.

II Jornadas de Normalización N+ISIS’05

TOGAF

• Es compatible IEEE 1471-2000• Architecturas vistas≈

– Arquitectura de Negocio– Arquitectura de Aplicaciones– Arquitectura de Datos– Arquitectura Tecnológica

• No se necesitan todas las arquitecturas para cada caso

II Jornadas de Normalización N+ISIS’05

TOGAF

Business Architecture

View s

Data Architecture

View s

Applicat ions Architecture

View s

Technology Architecture

View s

Business Funct ion View

Business Services View

Business Process View

Business inform at ion View

Networked Com put ing/ Hardware View

Business Locat ions View

Data Ent it y View

Software Engineer ing View

Business Logist ics View

Com m unicat ions Engineer ing View

People View (organizat ion chart )

Workflow View

Usabilit y View

Processing View

Data Flow View (Organizat ion Data Use)

Applicat ions I nteroperabilit y View

Business St rategy and Goals View

Business Object ives View

Cost View

Business Rules View

Business Events View

Business Perform ance View

Logical Data View

Software Dist r ibut ion View

Standards View

System Engineer ing View

Enterprise Security View

Enterpr ise Manageabilit y View

Enterpr ise Qualit y of Service View

Enterprise Mobilit y View

Ejemplo de una taxomonía de vistas

arquitecturales

II Jornadas de Normalización N+ISIS’05

TSIA – Telemedicine System Interoperability Architecture

• Concept paper – Vehículo de debate sobre la telemedicina teniendo en cuenta el desarrollo de las especificaciones de interoperabilidad aceptadas por la industria

• Financiada por U.S. Army Telemedicine and Advanced Technologies Research Center y ejecutada por Sandia National Laboratories

II Jornadas de Normalización N+ISIS’05

TSIA – Telemedicine System Interoperability Architecture

• Dos niveles de interoperabilidad– Cómo los nodos o estaciones dentro de un

sistema de telemedicina pueden estar compuestas y cómo los recursos dentro de una estación consiguen realizar su función

– Cómo una estación diferente en un sistema descubre la existencia de las demás y comienzan a intercambiar datos

II Jornadas de Normalización N+ISIS’05

TSIA – Telemedicine System Interoperability Architecture

• Arquitectura a nivel de estación

Tres juegos de interfaces

Station

Station-to-StationInterfaces

Station-InternalInterfaces

Station-to-DeviceInterfaces

Nota: Los interfaces internos para cada estación son definidos explícitamente para permitir la creación de estaciones de telemedicina desde componentes desarrollados independientemente, incluyendo aquellos que originalmente no fueron diseñados para su uso en aplicaciones tele médicas

II Jornadas de Normalización N+ISIS’05

TSIA – Telemedicine System Interoperability Architecture

• Tecnologías y Estándares candidatos– Distribución de componentes de estación– Bus de comunicación interna– Buses de dispositivos– Interfaces de usuarios– Comunicaciones de historial de pacientes– Videoconferencia– …

• Haciendo la interoperabilidad una realidad– Planificado en nueve fases

II Jornadas de Normalización N+ISIS’05

Otras Arquitecturas

• Healthcare Information System Architecture - HISA ENV 12967

• HL7 – Clinical Document Architecture CDA

• Sun’s Platform Independent Framework for e-health

• SAMTA - Open Scaleable Architecture for Multimedia Telemedicine Applications

II Jornadas de Normalización N+ISIS’05

Estándares necesitados en e-salud y telemedicina

¿Qué estándares necesitamos?

¿Ya existen?

Necesidad de un marco común ≈Arquitectura

II Jornadas de Normalización N+ISIS’05

Estándares necesitados en e-salud y telemedicina

• Distribución de componentes (CORBA,.NET…)

• Bus de comunicación interna (IP,Firewire …)

• Buses de dispositivo (IrDA, USB, Bluetooth …)

• Medios de comunicación interna (ISDN, xDSL …)

• Interfaces de usuario

• Dispositivos médicos (IEEE 1073, POCT, DICOM …)

• Directorio de historial de pacientes (ENV 13606, openEHR …)

II Jornadas de Normalización N+ISIS’05

Estándares necesitados en e-salud y telemedicina

• Comunicaciones de historial de pacientes (HL7, OMG …)

• Imágenes (DICOM, CIAS …)

• Videoconferencia (SIP, H.323 …)

• Seguridad

• Terminología (SNOMED, …)

Necesidad de un marco común ≈Arquitectura

II Jornadas de Normalización N+ISIS’05

Conclusiones

• La normalización ha de ir más allá de la Historia Clínica Electrónica

• Es vital la utilización de una arquitectura software que normalice el uso de estándares y permita la integración de sistemas

• Hay que hacer un análisis detallado de las necesidades antes del desarrollo de nuevos estándares

• Aprender de la experiencia ( la buena y la mala)

• No olvidar el objetivo final de todas estas actividades: EL CIUDADANO

Revisión de Arquitecturas para el fomento de la interoperabilidad en e-Salud

Gracias por su atención

Dr. Vicente TraverBET,ITACA, Universidad Politécnica de Valencia