Interoperabilidad en Salud Perspectiva de un Integrador: Mito o Realidad

1. 1ª Reunión del Foro de Interoperabilidad en Salud Interoperabilidad en Salud Perspectiva de un Integrador: Mito o Realidad CÓDIGO: GMVSGI-ANTARI-PRE-003 FECHA: 31/03/2011 VERSIÓN: 1 CÓDIGO INTERNO: GMVSGI 20432/11 V1/11

2. SALUD TELEMEDICINA • ANTARI • Dhanu- Antari es según la mitología hinduista, la encarnación médica de Dios (el primer médico del mundo). Está representado aquí con cuatro manos, que sostienen el disco Súdarshana, una flor de loto, una caracola y el pote de amrita (néctar de la inmortalidad). • Es el supuesto autor del Āiur-vedá. • Además, el término sánscrito dhanu antara representa el espacio o distancia (antara) de un arco (arma), llamado dhanu en sánscrito. INFORMACIÓN SECRETA

3. ÍNDICE DE CONTENIDOS • Introducción • Problemática • Situación actual • Organizaciones y Estándares de referencia • IHE • OpenEHR • CEN ISO 13606 • HL7 • Metodología de diseño e implementación • Antari. Plataforma interoperable de telemedicina

4. INTRODUCCIÓN • Interoperabilidad entre Sistemas de Salud necesaria para: • Clínicos y Pacientes: • Necesidad de compartir información de pacientes entre profesionales multidisciplinarios. • Necesidad de comunicación dentro de una organización, región, país o entre países. • Proveedores: • Comunicación entre sistemas de distintos proveedores (diferentes implementaciones de HIS) • 2 ámbitos diferenciados: • Interoperabilidad Sintáctica: Dossistemas son interoperablessintácticamentesiutilizan la mismaestructurapara la informaciónintercambiada y procesada. • Interoperabilidad Semántica:Garantiza que el contenido es entendido de la misma forma en ambos sistemas. • Causas de la heterogeneidad semántica: • Términos distintos con idéntica semántica (ej. Ataque cardiaco vs Infarto de miocardio) • Términos con semántica distinta en función del contexto. • Empleo de sistemas de referencia o escalas diferentes para el mismo propósito.

5. PROBLEMÁTICA • Diversidad de aplicaciones, tecnologías, actores, etc. en el mundo de la Sanidad  escenario complejo de por sí. • Estándares necesariamente abiertos por la diversidad existente. • Existencia de diversos estándares, versiones, tecnologías, etc. • Sistemas de información propietarios y cerrados. • Falta de autoridad regulatoria. • Diversidad de procedimientos • Diversidad de manera de hacer las cosas • Variabilidad de la práctica médica.

6. SITUACIÓN ACTUAL • Multitud de implementaciones (y adaptaciones) • Selene–Siemens • HP-HP HIS • Cerner-Cerner Millenium • NovaHIS • SAP • Lorenzo-ISOFT • Diversos estándares/metodologías de integración.

7. IHE (IntegratingHealthcare Enterprise) • Organización cuyo objetivo es la definición de pautas y especificaciones técnicas (basadas en estándares conocidos) para la implementación de sistemas TI de Salud interoperables

8. OpenEHR – CEN ISO 13606 • OpenEHR: Estándar abierto para la administración y almacenamiento de información sanitaria en forma de informes de HCE. • Influencia en el resto de organizaciones de desarrollo de estándares de interoperabilidad CEN (European Committee for Standardization), HL7 (Health Level 7), and ISO (International Organization for Standardization). • CEN ISO 13606: Norma europea para la definición de una arquitectura de información robusta para la comunicación de HCE de pacientes. • Presentefundamentalmente en ámbitos de investigación. • Subconjunto de especificaciones de openEHRpara el intercambio de extractos de HCE. • Desarrollado conjuntamente por CEN e ISO. • Desarrollado por las dificultades de adopción clínica de HL7 v2. • Doble modelo: Modelo de referencia: Posibles componentes de cualquier extracto. Modelo de arquetipos: Combinaciones de las estructuras del modelo de referencia restringidas para modelar los extractos.

9. CEN ISO 13606 (Continuación) • El modelo de referencia emula electrónicamente la organización de registros en papel. • Los arquetipos normalizan las transferencias de HCEs (o partes de ellas) de forma semánticamente interoperable. Los arquetipos son definidos por personal clínico

10. HL7 (HEALTH LEVEL SEVEN) - I • Conjunto de estándarespara el intercambioelectrónico de informaciónclínicadesarrolladospor la organización HL7 internacional • HL7 v2: • No estábasado en ningúnmodelo de referencia. • Másapropiadopara la transmisión de informacióndemográfica/administrativaquepara la transmisión de HCE. • Criticadoporfalta de precisión en la definición de mensajes lo quehacíadifícil la comunicación en caso de queemisor y receptor no llegaran a un acuerdo. • Estándar con mayor aceptacióninternacional y en productoscomerciales (aunque no directamente compatibles entre sí). • HL7 v3: • No compatible con versionesanteriores de HL7. • Diferencias con v2: Incluye un modelo de referencia (RIM) y los documentos CDA. • CDA es un concepto similar al de arquetipo (existe compatibilidad entre ambos).

11. HL7 (HEALTH LEVEL SEVEN) - II • CDA: Organizado en tresniveles: • Primer nivel. Emplea un modelo de referencia (RIM) quecontieneciertasclasesgenéricas (i.e. Role, act, Entity, participation) • Segundo nivel: Conceptosclínicosespecíficoscomopresión arterial, pruebaslaboratorio, etc … se modelancomoarquetipos, i.e. se especificanrestriccionesqueespecializanestructurasgenéricas . • Tercernivel: Especifica la semántica de maneraquecadaentidad de informaciónrecibe un códigoparaquepueda ser entendidoporunamáquina. • HL7 CDA no define cómodebentransmitirseextractos de HCE, solo indicaquedocumentos CDA puedenincluirsedentro de mensajes HL7, i.e. no existe un interfazespecífico a priori.

12. METODOLOGÍA DE DISEÑO E IMPLEMENTACIÓN • Seleccionar el estándar apropiado a seguir y la tecnología a utilizar. • Elegir e implementar los perfiles IHE: • Propuestas para solucionar la interoperabilidad en diferentes escenarios dentro de un dominio concreto. • Cada uno de estos perfiles describe una necesidad clínica de integración de sistemas y la solución para llevarla a cabo. • Perfil XDS: Perfil de integración creado para la compartición de documentación clínica. • Empleo de motores de integración, tienen gran parte del trabajo avanzado. • Opciones propietarias y de libre distribución. • Necesario un trabajo importante de configuración, adaptación, etc. • Colaboración fluida con los responsables de los sistemas.

13. ANTARI Plataforma interoperable de telemedicina INFORMACIÓN CONFIDENCIAL

14. ANTARI - INTEGRACIÓN CON SISTEMAS EXTERNOS • Comunicación con diferentes sistemas de información de los hospitales: • RIS • PACS • HCE • Gestión de citas • Aplicaciones departamentales • Gestión económico/financiera • Información a obtener/actualizar: • Historia clínica de los pacientes • Imágenes médicas digitalizadas • Citas

15. ANTARI - DISEÑO ANTARI – Plataforma de telemedicina Interoperable IHE – Casos de uso y consideraciones de diseño Estándares de interoperabilidad HL7 – ISO 13606 - DICOM • Plataforma de desarrollo • JEE • APIs Específicos

16. ANTARI – RED DE TELEMEDICINA • Prestación de los siguientes servicios: • Telemonitorización • Telediagnóstico y segunda opinión médica HOSPITAL DE REFERENCIA CENTRO REMOTO Internet Estación de telemedicina remota Cliente Emisor Estación de telemedicina Cliente Receptor Balanceadores Cortafuegos Servidores Aplicación Puestos Administrador

17. ANTARI - ARQUITECTURA

18. ANTARI – INTEGRACIÓN CON UN HIS • Seguimiento de los perfiles de integración IHE. • Empleo de un motor de integración: • Integración con diferentes HIS a través de conectores • Gestión de enrutamiento para incluir diferentes hospitales en la red • Uso de estándares de intercambio de información médica (HL7/CDA) • Empleo de diferentes protocolos de transporte (TCP/MLLP)

19. ANTARI – INTEGRACIÓN CON UN PACS • Almacenamiento de imágenes médicas procedentes de diferentes fuentes (DICOM, video compuesto, USB) • Consulta de imágenes mediante protocolos WADO (Web Access to DICOM Objects) y RID (IHE Retrieve Information for Display) • Comunicación entre servidores PACS.

20. ANTARI. TELECONSULTA (1/8)

21. ANTARI. TELECONSULTA (2/8) • Validación automática de cita de teleconsulta, utilizando una de estas dos opciones: • QR • SmartImage • Características • El profesional sanitario sitúa el justificante impreso de la cita (que incluye un QR o una SmartImage) • La imagen contiene los datos de la cita • El agente de Antari envía los datos de la cita al servidor • No es necesaria ninguna otra interacción con el sistema para la validación de la cita

22. ANTARI. TELECONSULTA (3/8) • El servidor verifica la cita y devuelve al agente Antari toda la información asociada a la cita • Código de colores para mostrar el “estado” del Especialista que va a atender al paciente remoto • Verde: El Especialista tiene sesión en Antari • Rojo: El Especialista no tiene sesión • El sistema indica la hora aproximada a la que será atendido el paciente

23. ANTARI. TELECONSULTA (4/8) • El Especialista visualizará el “estado” de los pacientes remotos y/o presenciales a través de esta vista • En el momento en el que el Profesional Sanitario verifica una cita (QR o SmartImage), el Especialista visualizará en esta vista que dicho paciente “le está esperando” • El Especialista podrá aceptar a un paciente con una simple acción de usuario

24. ANTARI. TELECONSULTA (5/8) • Mientras el Profesional Sanitario recibe el aviso que indica que el Especialista está preparado para atender a su paciente, puede: • realizar pruebas diagnósticas al paciente (si el Profesional Sanitario está cualificado para ello) • quedarse a la espera de ser atendido por el Especialista

25. ANTARI. TELECONSULTA (6/8) • El Especialista “acepta” al paciente remoto. • El Profesional Sanitario recibe una notificación (pantalla emergente) para que se una a una sesión de videoconferencia • En el momento en el que se una, el sistema unirá a la videoconferencia al Especialista de forma automática • Mientras el Profesional Sanitario recibe el aviso del Especialista puede realizar pruebas diagnósticas al paciente que quedarán registradas en el sistema

26. ANTARI. TELECONSULTA (7/8)

27. ANTARI. TELECONSULTA (8/8) • Tras la sesión de videoconferencia le aparecerá al Profesional Sanitario y al Especialista un formulario de cierre de sesión • Formulario Profesional Sanitario. Introducirá: • comentarios de la sesión de teleconsulta • Formulario Especialista. Introducirá: • Diagnóstico • Tratamiento • Observaciones • Ambas partes podrán reanudar la videoconferencia (cierre por error, etc)

28. Muchas Gracias Carlos Royo Sánchez croyo@gmv.es www.gmv.es INFORMACIÓN NO CLASIFICADA