Interoperabilidad en Salud

http://www.hl7.org.ar

Dr. Humberto F. Mandirola1

Dr. Humberto Fernán Mandirola

Email: hmandirola@biocom.com

Director de la Carrera de post grado de Medicina Interna de la UBA sede Hospital Belgrano (Universidad de Buenos Aires Argentina),

Director de BIOCOM Argentina http://www.biocom.com , Miembro de la comisión directiva de HL7 Argentina http://www.hl7.org.ar ,

Que es la Interoperabilidad

Es la condición mediante la cual sistemas heterogéneos pueden intercambiar procesos o datos.

Sigue el principio de neutralidad tecnológica.

El medicina el estándar mas aceptado mundialmente para hacer intercambio de información entre sistemas es el HL7

Escenario• No hay un sistema único que pueda resolver

todas las necesidades de una organización de salud.

• Necesidad e intercambiar datos entre las distintas instituciones.

• Cada vez hay mas aparotologia en el área hospitalera que utilizan programas de computación – Ejemplos:

• Auto analizadores en el laboratorio de análisis clínicos.

• Aparotologia de Imágenes Medicas Tomógrafos computados, Ecógrafos, Radiología digital, etc.

Ejemplos

• Si instamos un sistema PA C S (Picture Archiving and

Communication Systems), se debe identificar y determinar la interoperabilidad con la historia clínica o un software de administración.

• Esto re q u i e re de una serie de lenguajes que permiten la comunicación entre los diferentes sistemas.

Evolución de los sistemas de información en el Sector Salud

• Sistemas cerrados y propietarios ( era la política de diseño de los sistemas en el sector salud hasta la década de los noventa).

• A partir de los 80 se hace cada vez mas necesario compartir información e interactuar entre los distintos programas de información

• Se comienzan a utilizar y definir distintos estándares para compartir información

Definiciones

• Integración, Interoperabilidad

– Integración: inclusión de aplicaciones aparentemente disjuntas para constituir un sistema homogéneo.

– Interoperabilidad (semántica): capacidad de compartir información entre sistemas heterogéneos (y procesarla / aprovecharla en forma automática)

Definiciones

• Estándares: protocolos utilizados por la industriadel software (de facto o en forma regulada) parafacilitar la interoperabilidad y/o la integración.

• Los hay en las diversas capas de comunicación- comunicaciones

- transporte de datos

- mensajería

- vocabulario

- marcado de documentos

Definiciones

¿Para qué queremos interoperabilidad e integración de los sistemas?– Aumentar la seguridad y calidad de atención de los pacientes

– Asegurar la precisión de los datos clínicos

– Reducir la incidencia de los errores médicos

– Ahorro de costos evitando • Servicios duplicados

• Fraudes

• Dispensa de medicamentos innecesariamente caros

– Acceso universal a la historia clínica electrónica.

– Ahorro de tiempo del prestador de salud (médicos, enfermeras, técnicos, etc.)

Desafíos

• ¿Deben los hospitales, prestadores de salud, etc. almacenar la información en un lugar determinado o de una manera específica?

• ¿Deben inevitablemente REEMPLAZAR TODAS LAS APLICACIONES?

• Lograr esto puede tomar AÑOS… ¿Debo hacer todo de golpe o hay alguna estrategia evolutiva?

Interoperabilidad con HL7

• Estándares de HL7 para interoperabilidad entre sistemas de salud

CDA R2MENSAJERIA V3

MENSAJERIA V2.X OTROS

ESTANDARES

DE HL7

Herramientas de HL7: HL7 v2.x

HL7 V2.x - Estándar para MensajeríaIntrahospitalaria o 'Local'

Ultima versión : v2.6 -2008 (v2.7 en camino) Disponible en ^ | y como XML• Fortaleza: mensajería intrahospitalaria interdepartamental• Debilidad: para implementaciones regionales, ambigüedad

(requiere de negociación sitio por sitio), modelo de datos implícito

• Alto nivel de uso en el mercado : proveedores de software y usuarios (hospitales, prestadores)

Ejemplos: LIS to HIS, LIS to BILLING, HIS to RIS, ADT broadcastDominios: Admisión de pacientes, Laboratorio, Radiología, Ordenes,

Interconsulta, Turnos, etc.

Herramientas de HL7: HL7 v3HL7 V3 - Mensajería a nivel regional

• Ultima versión : Normativa 2006 (v2008 en proceso) Disponible como XML

• Fortaleza: mensajería REGIONAL (usado para implementaciones de este tipo en Canada, Alemania, Mexico, UK).

Modelo formal basado en UML, estricto y explicito de información. Reduce la ambigüedad. Basado en XML. Identificadores únicos globales.

• Debilidad: todavía no cubre algunos requerimientos de aplicaciones departamentales. Mayor complejidad inicial. Todavía algo inestable.Menor nivel de uso en el mercado : proveedores de software y usuarios (hospitales, prestadores)

Herramientas de HL7: HL7 CDA R2

HL7 CDA R2 - Documentos Clínicos

• Estandar para intercambio de DOCUMENTOS clinicos(en lugar de mensajes)Ultima versión : Normativa 2005 (CDA R2) (CDA R3 en discusión,

no ballot) Fortaleza: Ampliamente difundido. Facil de implementar.

Interoperabilidad evolutiva. Basado en XML y en modelos de V3. Identificadores unicos globales.

Debilidad: Se lo quiere utilizar como si fuera toda la navaja suiza.Alto nivel de uso en el mercado : proveedores de software y

usuarios (hospitales, prestadores)Dominios: Cualquiera que permita generar documentos

Desafíos

• Variabilidad de Aplicaciones

• Semántica y vocabulario complejo

• Síndrome de NIH (NOT INVENTED HERE)

• Procesos y tipos de documentos

Algunas respuestas a ¿Por qué es tan dificil?"

Desafíos

• Variabilidad de Aplicaciones

– En Salud hay cientos (o hasta miles) de actores que tienen sus propias aplicaciones:

• médicos individuales • centros de atención primaria• laboratorios de análisis clínicos• Centros de diagnóstico por imágenes• Hospitales u otros centros de internación• Farmacias• Pagadores (financiadores, mutuales) • Salud Pública

– La lista sigue y ahora se agrega el PACIENTE !

Desafíos• Semántica y Vocabulario Complejo

Porque la semántica de nuestro dominio es compleja de representar en forma fidedigna.

Y no hay un único vocabulario controlado que cubra todos los conceptos codificables.

Tomada prestada del Dr.

House - Nota: para los que no

vieron el final del capítulo, la

paciente estaba mal

identificada, tenían los

antecedentes EN PAPEL pero

de otra persona que no era

Megan y actuaban en base a

lo que sabían de la OTRA

paciente. No tiene que ver con

la semántica pero si con que

HC es imprescindible la

fiabilidad de los datos!!!

Desafíos• Procesos y Tipos de Documentos "Únicos"

– Los tipos de documentos que manejamos para los procesos dependen de definiciones de cada institución (no están estandarizados)

• Anamnesis• Exploraciones• Notas de evolución clínica• Ordenes Médicas• Reportes de Resultados• Diagnósticos• Interconsultas• Epicrisis• Informes de Vacunación

Niveles de informacion en el Sector Salud

– El problema empeora a medida que avanzamos.

• Consigo interoperabilidad DENTRO DE MI HOSPITAL, y me falta integrarme con el de enfrente.

• Nos integramos en la RED ASISTENCIAL, pero no con el resto de la ciudad.

• La CIUDAD se entiende, pero no se comunica con el resto de la COMUNIDAD.

• Y una vez que nos entendemos con la COMUNIDAD, si una persona se cae del lado de enfrente del río y es alérgico a la penicilina y al maní, le dan un cóctel mortal (nombre científico: manícilina) de ambos.

INTRAHOSPITAL

INTERHOSPITAL

REGIONAL

SUPRARREGIONAL

Estrategias y Arquitecturas• Clasificación de las estrategias y modelos

– Según el lugar de almacenamiento de los datos• Dispositivo del Paciente• Repositorio Distribuido• Repositorio Centralizado• Broker externo - PHR Provider

– Según el nivel de interoperabilidad• Imagen/Objetos Binarios• Texto (ASCII/PDF/WORD)• Contexto+Texto (ASCII/PDF/WORD) • Contexto+XML+Secciones de Documentos• Contexto+XML+Secciones de Documentos+Codificación parcial• Contexto+XML+Codificación completa+Workflow

Estrategias y Arquitecturas

• Modelos de RHIO (Regional Health Information Organizations ):

– Federación: prestadores de salud y un organismo público o privado que concentra la información - gran volumen

– Cooperación: prestadores de salud y un organismo público que comparten determinados recursos en común

– Híbridos: algunos recursos federados, algunos distribuidos

– PHR provider (Personal Health Records ): proveedor específico para su historia clínica personal, seleccionado por el paciente

Estrategias / Almacenamiento

• Dispositivo del paciente

– Se trata de guardar toda la información en un dispositivo que el paciente debe llevar de un prestador a otro.

• Repositorio Distribuido o Compartido– Cada grupo de prestadores tiene un repositorio con

toda o una parte de la historia clínica de los pacientes a su cargo

– Pero existe un repositorio

'indice' que puede ser

consultado por cualquier

prestador y entrega

un vínculo al repositorio

correspondiente.

Estrategias / Almacenamiento• Broker de PHR

– El paciente contrata a una tercera parte para que mantenga su historia clínica personal (PHR).

– Los diversos prestadores acceden a la información del paciente a través del broker.

– Desventajas:¿la autoridad sanitaria queda afuera? ¿Cómo se maneja la multiplicidad de brokers?

• Repositorio CentralizadoUna autoridad sanitaria recibe de los prestadores

información (documentos, mensajes)

sobre los pacientes.

Si algún prestador requiere

información sobre un paciente,

puede hacer la consulta

directamente sobre el repositorio

centralizado.

Interoperabilidad Semántica Evolutiva

• Definición de Interoperabilidad Semántica

Capacidad de compartir información entre sistemas heterogéneos y procesarla /

aprovecharla en forma automática

Ejemplo

Se registra en la aplicación de atención primaria utilizada por el médico A: "el paciente B tiene alergia a la eritromicina"

Preguntas:

¿cómo hizo la aplicación del médico C para enterarse?

¿cómo hizo la aplicación del médico C para avisarle?

¿qué diferencia hay?

El médico C, en un Hospital, descubre un germen en un

urocultivo, que es sensible a penicilina, y decide recetar en

forma electrónica eritromicina al paciente B.

Se registra en la aplicación de atención primaria utilizada por el médico A: "el paciente B tiene alergia a la eritromicina"

forma electrónica eritromicina al paciente B.

La aplicación del médico C LE AVISA que el paciente es

alérgico a la penicilina, y se evita un error.

Se registra en la aplicación de atención primaria utilizada por elmédico A: "el paciente B tiene alergia a la penicilina"

forma electrónica penicilina al paciente B.

Ejemplo

• Si el médico tiene que FIJARSE para enterarse, hay MENOR INTEROPERABILIDAD.

• Para que el médico que solicita llegue a VER el registro alcanza con el formato visual y el contexto (paciente, médico, etc.)

• Para que la aplicación le avise (suponiendo que pueda) se requiere mayor nivel de interoperabilidad: formato visual y computable, contexto, vocabulario (alergias y medicamentos recetables)

Interoperabilidad Semántica Evolutiva

• Las preguntas serían:

– ¿qué niveles de interoperabilidad existen?

– ¿qué nivel de interoperabilidad necesitamos?

– ¿qué nivel de interoperabilidad podemos soportar (pagar, desarrollar, imaginar) hoy?

– ¿Hay alguna manera de empezar con un nivel de interoperabilidad y mejorarlo en el futuro?

Estrategias / Nivel de Interoperabilidad

1. Básica (GIF/JPG)

2. No Estructurada (WORD/PDF)

3. Contexto + Información No Estructurada

4. Contexto + Información Estructurada (secciones fijas según el tipo de documento)

5. Contexto + Información Estructurada (secciones fijas y entradas codificadas según el tipo de documento)

6. Contexto + Información Estructurada + Workflow (mensajes)

Mayor Nivel de Interoperabilidad Semántica

• 1. Nivel básico– Imagen/Objetos Binarios

• 2. No estructurada– Texto (ASCII/PDF/WORD)

• Si bien se envía algo, no es aprovechable, ni puede contener estructura ni se puede estandarizar.

• 3. Información No Estructurada + Contexto

– Se envía el documento clínico original pero se agrega una cabecera que brinda el contexto indizable que identifica:

– Información sobre el paciente,

– fecha,

– Organización prestadora,

– Participantes (médicos, anestesistas, etc.)

– Tipo de documento (de un subconjunto estandarizado)

– lugar de realización, encargado del documento, acto clínico realizado, etc.

• 4. Información Estructurada + Contexto + Secciones

– Se envía el documento clínico en forma estructurada en secciones además de la cabecera estándar con contenido indizable.

– Se estandariza asi por lo menos la forma del contenido (Secciones + XHTML)

• 5. Información Estructurada + Contexto + Entradas Codificadas

– Se envía el documento clínico en forma estructurada en secciones además de la cabecera estándar con contenido indizable.

– Además se codifican algunas secciones (diagnósticos, medicaciones, vacunación, procedimientos) para permitir su procesamiento automatizado y su aprovechamiento para control de gestión, epidemiología, etc.

• 6. Información Completamente Estructurada y Codificada + Contexto + Workflow

– A través de mensajería se envía además la información sobre los cambios de estado de los diversos objetos (pedidos, resultados, ocupación de camas, agendamiento de citas, etc.)

Estándar de CCOW• CCOW( Clinical Context Object Workgroup)

• El estándar de CCOW lo inició en 1996 un consorcio independiente de vendedores y de abastecedores del health care que compartieron el objetivo de crear los estándares de la integración para el expediente clínico.

• En 1998, el comité técnico de CCOW formó parte de la organización de estándares del nivel siete de salud (HL7) y fue certificado por el American National Standards Institute (ANSI) en 1999. Desde entonces, el comité ha desarrollado y ha ratificado cuatro versiones del estándar de CCOW.

Comparativa de Documentos vs. Mensajes.(I)

CARACTERISTICA DOCUMENTOS MENSAJES

Ciclo de Vida Persistente Temporal

Comunicación Entre Personas Entre Aplicaciones

Relación con los prestadores

Están entrenados para crearlos

No entienden bien qué significan

Aspecto Legal Tienen status legal Ni firma ni validez legal

Origen Usos y costumbres Ad-Hoc según casos de uso

Contexto

A nivel de documento Segmentado

Completitud Completo Fragmentado

Documentos vs. Mensajes(II)

• Otras diferencias– El mensaje se utiliza cuando se quiere granular a

nivel de objeto la información y transmitir los diversos estados por los que pasan los distintos objetos.

– El documento se utiliza cuando se desea enviar solamente el estado/resultado final del acto (o los actos) en cuestión.

– Veamos ahora un ejemplo en laboratorio

Documentos vs Mensajes (III)20-Abr-07 18:30 Petición analitica: “Glucosa en Sangre” realizada por el Dr. Amado Pérez para el

paciente Alberto Soria, internado en Cama 10 del Servicio de Clínica Médica.

Diagnóstico presuntivo : diabetes. Solicitud de realizar la petición dia 21/04/07 como

rutina

20-Abr-07 18:31 Confirmación electrónica de recepción del pedido

20-Abr-07 22:00 Aviso electrónico de agendamiento de la extracción: será realizada por la

extraccionista Carolina Sanchez a las 07:30 hs del día 21/04/07

21-Abr-07 07:35 Muestra tomada por la enfermera Carolina Sanchez de la Hoz: sin novedades.

21-Abr-07 08:00 Muestra recibida en el laboratorio por el técnico Joaquín Perdomo. Colocada en

gradilla temporaria Q45 para su análisis rutinario. Aviso electrónico de petición en

proceso.

21-Abr-07 08:45 Muestra programada en Analizador T45 en posición 43

21-Abr-07 08:55 Resultado generado por Analizador T45: 75 mg/dl

21-Abr-07 09:20 Resultado de glucosa en Sangre : 75 mg/dl, revisado y firmado por el Dr. Mario

Antares. Aviso electrónico de petición cumplida a sistema administrativo. Mensaje

conteniendo resultado enviado electrónicamente a sistema de historia clínica

electrónicaInteroperabilidad a través de mensajería damos cuenta del

workflow: los cambios de estado de cada objeto en un sistema

son enviados a otro sistema para sincronización.

Documentos vs. Mensajes (IV)

• Pero de todo este cúmulo de información, lo más relevante para el médico:

21-Abr-07 09:20 Resultado de Glucosa en Sangre : 75 mg/dl, revisado y firmado por el Dr. Mario Antares, a partir de una muestra tomada el 21-Abr-07 a las 07:35.

Documentos vs. Mensajes (V)

• Entonces, – A. ¿documentos y mensajes son excluyentes?

– B. ¿Es “mejor” utilizar documentos que mensajes?

• Mejor preguntarse– “Cuándo utilizar documentos”

– “Cuándo utilizar mensajes”

Documentos vs Mensajes (VI)

• Los otros ejes para considerar son

– Relación entre los sistemas (interhospitalario intrahospitalario, hospital – gobierno, etc.)

– El eje temporal (el receptor necesita conocer la información on-line o puede esperar para recibir el informe final o una relacion de actuaciones al final del episodio)

– Consideraciones de seguridad (intrínseca o dada por el entorno) / legislación

– ¿ Debo notificar algo o estoy haciendo una consulta? http://www.hl7.org.ar

Estándares Disponibles

• Comunicaciones

• Protocolo de Intercambio Semántico

• Registros

• Perfiles de Implementación

• Vocabularios

• Servicios de Terminología

Estándares Disponibles http://www.hl7.org.ar

Estándares de ComunicacionesTCP/IP -> HTTP+ XML----------------------------SOAP, WDSL, UDDI

=WEB SERVICES¿Es la única manera?No: MLLP, ebXML, etc.

<Pregunta_Incomoda>¿Alguien discute la necesidad de estandarizar los niveles ISO/OSI 1 a 6?¿Sería mejor usar alguna alternativa "local" a TCP/IP, HTTP, XML, SOAP, etc?

</Pregunta_Incomoda>

Estándares de Seguridad

• XMLDSIG: Firma digital, PKI, certificados

• Kerberos: Protocolo de comunicación segura en redes inseguras

• SAML: Security assertion markup language

• SSL: Seguridad de la capa de transporte

• HL7 RBAC (Role Based Access Control): define derechos de acceso según rol del usuario

Protocolos de Intercambio Semántico

• HL7 CDA R2: Intercambio de documentos clínicos en distintos niveles de interoperabilidad (sólo contexto, secciones codificadas, entradas codificadas)

Protocolos de Intercambio Semántico

• HL7 V3: Intercambio a través de mensajería. Diversos Dominios: Ordenes, Resultados, Citaciones, Facturación, E-Claims, Admisión, Dispositivos Clínicos.

• HL7 Arden Syntax/Gello: reglas clínicas y evaluación de expresiones.

• HL7 V2.x: Intercambio a través de mensajería. Lo nombramos porque está aquí y no se va a irpor varios años (¿5,10?) - especialmente en laboratorio, anatomía patológica e imágenes.

• DICOM/WADO: Para intercambio de imágenes

Vocabularios

• Vocabularios disponibles y maduros para casi todas las áreas– Laboratorio: LOINC– Secciones y Documentos: LOINC - Tipos de documento y secciones– Anatomía Patológica: SNOMED CT - morfologías, problemas,

localizaciones– Hallazgos Clínicos: SNOMED CT, UMLS– Diagnósticos, Motivos de consulta: CIE9. CIE10,CIAP– Procedimientos: LOINC, CPT– Enfermería: NANDA (Diagnósticos), NIC (Intervenciones) ,NOC

(Resultados)

• Estándar para Servidor de Terminología– HL7 CTS (Common Terminology Server)

Interoperabilidad Evolutiva

• Usando HL7 CDA R2 se puede alcanzar un mayor nivel de interoperabilidad en forma evolutiva, seleccionando los tipos de documentos a implementar, el nivel de interoperabilidad deseado, y el orden temporal de la implementación, caso por caso, obteniendo resultados de la inversión más velozmente.

Conclusiones

• Están dadas las condiciones para trabajar hacia una historia clínica universal.

• Pero,

¿Cómo empezamos?

Una hoja de ruta

• Quién, Dónde, Qué, Quién lo Hizo– Quién: Cómo identificamos al paciente? Hay un

identificador nacional? Hay legislación para proteger el uso, la privacidad y la confidencialidad?

– Dónde: Hay un registro nacional de prestadores, clínicas, laboratorios, hospitales, etc.

– Qué: Hay un maestro de servicios con identificadores públicos? Hay un sistema de codificación de procedimientos?

– Por quién: Hay un registro de prestadores nacionales público y accesible?

Una hoja de ruta

• HL7 no alcanza si no se cuenta con otros recursos estandarizados

– Seguridad: estándares e infraestructura.

– Red: conectividad en todos los lugares.

– Registros: pacientes, lugares, proveedores, pagadores, beneficiarios.

– Vocabularios: servicios, determinaciones, terminología clínica.

Más Información

• CDA R2,HL7 V2,HL7 V3

– www.hl7.org o www.hl7.org.ar o www.hl7.org.co

• DICOM

– http://medical.nema.org/

• PERFILES IHE

– http://www.ihe.net/

Agradecimientos

A Diego KAMINKER (Presidente de Hl7 Argentina), por enseñarme HL7 y brindarme material para armar esta presentación que permite difundir la ventajas que representan los estándares en el sector salud.

Gracias por su atención

Cualquier consulta pueden enviarla por mail al foro

http://groups.google.com.ar/group/historia-clinica

Dr. Humberto Fernán Mandirola BrieuxEmail hmandirola@biocom.com

Interoperabilidad en Salud

Health & Medicine

Transcript of Interoperabilidad en Salud

Modelo Arquitectónico de Interoperabilidad entre Instituciones Prestadoras de Servicios de Salud en Colombia

Pàgina 1 Carlos Gallego. Responsable Oficina d'estàndards i Interoperabiltat Esquema Nacional de Interoperabilidad: También para Salud?

La Interoperabilidad en la Administración Electrónicaestaticoarchivo.carm.es/adjuntos/DOC24560553333_163_80479.pdf · La Interoperabilidad en la Administración Electrónica Esta

Interoperabilidad de Historias Clínicas Electrónicas en el ...

LA INTEROPERABILIDAD* EN FUERZAS COMBINADAS

Interoperabilidad - Talleres EGob

Interoperabilidad en mHEALTH

PLATAFORMA DE INTEROPERABILIDAD

2012022 Esquema nacional de interoperabilidad (ENI), aplicando las normas técnicas de interoperabilidad.

La interoperabilidad: el nodo central del Sistema Nacional de Salud

Integración e Interoperabilidad en Sanidad

Interoperabilidad en México - IBTTA · Interoperabilidad en México Luis Lezama Elguero Director de Desarrollo Tecnológico. ... Tipos de TAGs utilizados en México.

CURSO: INTEROPERABILIDAD IFC - Editeca€¦ · 3. Interoperabilidad - Condiciones de interoperabilidad. - Métodos de interoperabilidad. Interoperabilidad entre software propio. Software

DICCIONARIO DE TÉRMINOS MÉDICOS Foro de Interoperabilidad en Salud 16 de mayo La Granja de San Ildefonso.

ESTÁNDARES PARA LA INTEROPERABILIDAD EN SALUD · CIBERSALUD (eSalud) INTEROPERABILIDAD Técnica Semántica Organizacional ESTÁNDARES Normas, regulaciones, guías o definiciones

Modelo Arquitectónico para Interoperabilidad entre ... · Castrillón H. et al. Modelo Arquitectónico para Interoperabilidad entre Instituciones Prestadoras de Salud en Colombia

Marco Conceptual - minsalud.gov.co · Ricardo Domínguez Contreras Dir Arquitectura, Dotted Cloud CMISO TC 215 Marco Conceptual: CiberSalud , Interoperabilidad en Salud, Gobierno

Spdece Interoperabilidad

Estándares e interoperabilidad en salud electrónica ...archivo.cepal.org/pdfs/2011/S2011120.pdf · Estándares e interoperabilidad en salud electrónica: Requisitos para una gestión

Interoperabilidad de la receta electrónica del SNS · Interoperabilidad de la receta electrónica del SNS Mercedes Alfaro Latorre SG de Información Sanitaria DG Salud Pública ,