Introduccion a Hl7
Content
Introducción a HL7
Contenido
1. 2.
Introducción a HL7
3. 4. 5.
Introducción a HL7 Diego Kaminker HL7 Argentina – Presidente Marcelo Ceitlin SADIO SIS 2007 - MAR DEL PLATA
SIS 2007 © 2005-7, HL7 Argentina 0
6. 7.
HL7 – Organización y Objetivos Desarrollo de HL7 V2 y otros estándares Relación de HL7 con otros estándares. Necesidad de Interfaces. Interoperabilidad Sistemas monolíticos y distribuidos El porqué de los Estándares de Comunicación Taller de Interoperabilidad
© 2005-7, HL7 Argentina 1
SIS 2007
1. HL7 – Organización y Objetivos
¿Qué significa siete en HL7?
Misión
Misión de HL7: interoperabilidad clínica
“Proveer un marco completo y estándares relacionados para el intercambio, integración y recuperación de información electrónica de salud que soporte la práctica clínica y el gerenciamiento y evaluación de servicios de salud. Específicamente: crear estándares flexibles y costo-efectivos, guías y metodologías para permitir la interoperabilidad entre los sistemas de información y el intercambio de registros electrónicos de salud” (HL7 Mission statement, revisado en el año 2001) Estrategia: innovación – tanto de nuestros usuarios como de la organización
SIS 2007 © 2005-7, HL7 Argentina 2
Un protocolo para el intercambio de información clínica 7 7 6 6 5 5 4 4 3 3 2 2 1 1 Applicación Applicación HL7 Presentación Presentación Sesión Sesión Transporte Transporte Red Red Enlace Enlace Física Física
Función
Communicación
Arquitectura de comunicaciones del modelo de ISO llamado OSI (Open System Interconnection)
04/09/2007 3
1. HL7 – Organización y Objetivos
1. HL7 – Organización y Objetivos
¿Quiénes conforman HL7?
•Fundada en 1987. •Acreditada como SDO por ANSI en 1994 (Los estándares aprobados por HL7 desde 1994 son estándares para USA). •HL7 como organización tiene una estructura y procedimientos formales basados en la búsqueda del consenso y el balance de intereses entre los distintos sectores representados: empresas de software, financiadores de la salud, estados nacionales, universidades, prestadores de salud, consultores, etc.
SIS 2007 © 2005-7, HL7 Argentina 4 SIS 2007
•Más de 500 empresas miembros de la organización, más de 1500 miembros en total. •Alrededor de 500 miembros se reúnen periódicamente en los WGM – alrededor de 100 de ellos de algún afiliado internacional. •26 Afiliados internacionales (además de USA):
Argentina Canadá Rep.Checa Alemania Irlanda Corea N.Zelanda Sud Africa Holanda Australia China Dinamarca Grecia Italia Lituania Polonia Suiza Reino Unido Brasil Croacia Finlandia India Japón Mexico, Chile,Uruguay España Taiwan Prox.: Colombia
© 2005-7, HL7 Argentina
5
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
2. Desarrollo de HL7 V2 y otros estándares
Contenido
• •
Versión 1.0 y 2.0 de mensajería en años 1987 y 1988 Estándares de mensajería aprobados: 1990 1994 1997 1999 2000 2003 2007
Enfoque conceptual Construcción de Mensajes versión 2.X
Mensajes, Segmentos, Campos Delimitadores Reglas de ensamblado y desensamblado Tipos de datos
2.1
2.2
2.3 2.3.1 2.4
2.5
2.6?
Reglas de procesamiento Ejemplos de mensajes HL7 V2.X Recomendación para implementación de version 2.X Versión V2 XML
SIS 2007
© 2005-7, HL7 Argentina
6
04/09/2007
7
Modelo básico de transacciones HL7
Sistema B
Paradigmas de respuestas HL7
ORM msg
RECIBE MENSAJE Evento disparador ENVIA RESPUESTA
Evento disparador Aceptar ACK (opt)
ENVIA MENSAJE RECIBE RESPUESTA
Sistema A
Sistema A
RED ORR (opt)
Sistema B
Evento disparador
Aceptar ACK (opt)
04/09/2007
8
04/09/2007
9
Conceptos
Ejemplo de evento disparador
Eventos disparadores
El evento disparador es el hecho que genera la transmisión del mensaje. La relación entre TIPOS DE MENSAJE y CODIGOS DE EVENTO DISPARADOR es UNO a MUCHOS: El mismo evento disparador no puede asociarse a más de un tipo de mensaje.
Cuándo
Un evento A01 es enviado cuando se realiza el ingreso/admisión del paciente.
Qué
Normalmente, esta información es ingresada por el sistema de admisión de pacientes e informada al resto de los sistemas que conforman la organización
Actualizaciones no solicitadas
Cuando la transferencia de información es iniciada por el sistema que controla el evento, la transacción se denomina ‘ACTUALIZACION NO SOLICITADA’. Ejemplo: se concluye un estudio diagnóstico
Uso
Por ejemplo, un evento A01 puede ser usado para notificar al sistema de Laboratorio que un paciente ha sido admitido y al que se le puede fehacientemente solicitar estudios.
04/09/2007
10
04/09/2007
11
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Ejemplos de eventos ADT
A01 A02 A03 A04 A05 A06 A07 A08 A09 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 ADT/ACK - Admit a patient ADT/ACK - Transfer a patient ADT/ACK - Discharge a patient ADT/ACK - Register a patient ADT/ACK - Preadmit a patient ADT/ACK - Transfer an outpatient to inpatient ADT/ACK - Transfer an inpatient to outpatient ADT/ACK - Update patient information ADT/ACK - Patient departing ADT/ACK - Patient arriving ADT/ACK - Cancel admit ADT/ACK - Cancel transfer ADT/ACK - Cancel discharge ADT/ACK - Pending admit ADT/ACK - Pending transfer ADT/ACK - Pending discharge ADT/ACK - Swap patients ADT/ACK - Merge patient information QRY/ACK - Patient query ADT/ACK - Nursing/Census application updates ADT/ACK - Leave of absence - out (leaving) ADT/ACK - Leave of absence - in (returning) ADT/ACK - Delete a patient record
¿Qué es un mensaje HL7 abstracto?
Mensaje Abstracto
El nivel básico de definición dentro del estándar HL7 es el del mensaje abstracto asociado a cada evento particular. La definición del mensaje incluye:
DATOS : Los campos de datos a enviar dentro del mensaje RESPUESTAS : Las respuestas válidas ERRORES : El tratamiento de errores de aplicación (datos erróneos) o fallas de comunicación
12 04/09/2007 13
04/09/2007
Ejemplo de mensaje HL7 abstracto (ADT^A01)
ADT^A01^ADT_A01 MSH EVN PID [ PD1 ] [{ ROL }] [{ NK1 }] PV1 [ PV2 ] [{ ROL }] [{ DB1 }] [{ OBX }] [{ AL1 }] [{ DG1 }] [ DRG ] [{ PR1 [{ ROL }] }] [{ GT1 }] [{ IN1 [ IN2 ] [{ IN3 }] [{ ROL }] }] [ ACC ] [ UB1 ] [ UB2 ] [ P DA ] ADT Message Message Header Event Type Patient Identification Additional Demographics Role Next of Kin / Associated Parties Patient Visit Patient Visit - Additional Info. Role Disability Information Observation/Result Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Insurance Insurance Additional Info. Insurance Additional Info - Cert. Role Accident Information Universal Bill Information Universal Bill 92 Information Patient Death and Autopsy Chapter 2 3 3 3 12 3 3 3 12 3 7 3 6 6 6 12 6 6 6 6 12 6 6 6 3
Mensajes HL7
MSH|^~\&|NSI||LAB||20010827120759||ADT^A01|NSI1|P|2.3||||AL<cr> EVN|A01|18000101000000<cr> PID|1||60719^^^^HI|26690949^^^^DNI|TORRALBA^AIDA||19780113000000 |F|||POTOSI 4032 108^^CAPITAL FEDERAL^^1899<cr> NK1|1|CAMUS^ALBERTO|PAD|RIVADAVIA 253|42539686<cr> PV1|1|I|301|R|||1436^PEREZ^JORGE^ALBERTO|1026^LOPEZ^NORBERTO|998 ^GARCIA^ALEJANDRO|M|||A|4|A0|N|1026^LOPEZ^NORBERTO|OB|H0100240 |||||||||||||||||ALV||||||||20010823095130|20010823102455<cr> IN1|1|INT^^HI|2^^^^HI~347^^^^NSI|PLAN DE SALUD<cr>
Un Unmensaje mensajees esla launidad unidadtransferida transferidaentre entresistemas sistemasinformáticos. informáticos.Esta Esta compuesto compuestode depor porun ungrupo grupode desegmentos segmentosen enuna unasecuencia secuenciadefinida. definida.El El primer primersegmento segmento(MSH) (MSH)identifica identificael eltipo tipode demensaje mensajey yel elevento eventodisparador disparador que quehizo hizoque queel elmensaje mensajesea seaenviado. enviado.
14 04/09/2007 15
SIS 2007
© 2005-7, HL7 Argentina
Segmentos
SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
16 SIS 2007
Definición de segmento PID
LEN 4 20 250 20 250 250 26 1 250 250 250 4 250 250 250 250 250 250 16 25 250 DT OPT RP/# TBL# ITEM# SI O 00104 CX B 00105 CX R Y 00106 CX B Y 00107 XPN R Y 00108 XPN O Y 00109 TS O 00110 IS O 0001 00111 XPN B Y 00112 CE O Y 0005 00113 XAD O Y 00114 IS B 0289 00115 XTN O Y 00116 XTN O Y 00117 CE O 0296 00118 CE O 0002 00119 CE O 0006 00120 CX O 00121 ST B 00122 DLN O 00123 CX O Y 00124 ELEMENT NAME Set ID - PID Patient ID Patient Identifier List Alternate Patient ID - PID Patient Name Mother's Maiden Name Date/Time of Birth Administrative Sex Patient Alias Race Patient Address County Code Phone Number - Home Phone Number - Business Primary Language Marital Status Religion Patient Account Number SSN Number - Patient Driver's License Number - Patient Mother's Identifier
17
Características de los segmentos
Un segmento HL7 es una agrupación de campos. Los segmentos dentro de un mensaje:
Pueden ser REQUERIDOS u OPCIONALES Pueden ocurrir UNA SOLA VEZ o permitir REPETICIONES Se identifican por un código único de tres caracteres denominado ‘SEGMENT ID’
HL7 permite en cada implementación definir segmentos específicos para intercambiar información no prevista
Segmentos Z..
04/09/2007
© 2005-7, HL7 Argentina
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Campos
Componentes de un campo
Campo
Un campo es una cadena de caracteres definida por un tipo de datos de HL7. El apendice A del estándar, el diccionario de datos, brinda un listado alfabético de los campos, listados de codificación recomendada, y una referencia cruzada de los campos contra los segmentos
3.3.2.5 3.3.2.5Patient Patientname name(XPN) (XPN)00108 00108
Components: Components: <family <family name name (ST)> (ST)> ^ ^ <given <given name name (ST)> (ST)> ^ ^ <middle <middle initial initial or or name name (ST)> (ST)> ^ ^ <suffix <suffix (e.g., (e.g., JR JR or or III) III) (ST)> (ST)> ^ ^ <prefix <prefix (e.g., (e.g., DR) DR) (ST)> (ST)> ^ ^ <degree <degree (e.g., (e.g., MD) MD) (ST)> (ST)> ^ ^ <name <name type type code code (ID) (ID) > >
04/09/2007 18
MSH|^~\&|NSI||LAB||20010827120759||ADT^A01|NSI1|P|2.3||||AL<cr> EVN|A01|18000101000000<cr> PID|1||60719^^^^HI|26690949^^^^DNI|TORRALBA^AIDA^LIDIA||19780113 |F|||POTOSI 4032 108^^CAPITAL FEDERAL^^1899<cr> NK1|1|CAMUS^ALBERTO|PAD|RIVADAVIA 253|42539686<cr> PV1|1|I|301|R|||1436^PEREZ^JORGE^ALBERTO|1026^LOPEZ^NORBERTO|998 ^GARCIA^ALEJANDRO|M|||A|4|A0|N|1026^LOPEZ^NORBERTO|OB|H0100240 |||||||||||||||||ALV||||||||20010823095130|20010823102455<cr> IN1|1|INT^^HI|2^^^^HI~347^^^^NSI|PLAN DE SALUD<cr>
Componentes Componentesde deun uncampo campo((separador separador= =^ ^)) Un Uncampo campotambién tambiénpuede puedetener tenerpartes parteso ocomponentes componentes‘separables’. ‘separables’.Por Por ejemplo, ejemplo,el elnombre nombredel delpaciente pacientese seregistra registracomo comoApellido, Apellido,Nombre, Nombre,Inicial Inicial de Segundo Nombre. de Segundo Nombre.
04/09/2007 19
Caracteres de Codificación
Delimitadores:
| ^ ˜ \ & <CR>
Al construir un mensaje, se utilizan determinados caracteres como DELIMITADORES
Terminador de Segmento Separador de Campo Separador de Componente Separador de Subcomponente Caracter de Repetición Caracter de Escape <CR> | ^ & ~ \ (ASCII 13) (ASCII 124) (ASCII 94) (ASCII 38) (ASCII 126) (ASCII 92)
Alfanuméricos (ST,TX,FT) Numéricos (CQ,MO,NM,SI,SN) Identificadores (ID,IS,HD,EI,RP,PL,PT) Fecha/Hora (DT,TM,TS) Valores Codificados (CE,CF,CK,CN,CX,XCN) Genéricos (CM) Forma de Onda (CD,MA,NA,ED) Precios (CP) Finanzas (FC) Consultas extendidas (QSC,QIP,RCD) Archivos maestros (DLN,JCC,VH) Registros médicos (PPN) Series temporales (DR,RI,TQ) Datos Demográficos (AD,PN,TN,XAD,XPN,XON,XTN)
Tipos de datos
XPN XPNdata datatype: type: <family <familyname name(ST)> (ST)>^ ^<given <givenname name(ST)> (ST)>^ ^<middle <middleinitial initialor or name name(ST)> (ST)>^ ^<suffix <suffix(e.g., (e.g.,JR JRor orIII) III)(ST)> (ST)>^ ^<prefix <prefix(e.g., (e.g.,DR) DR)(ST)> (ST)>^ ^<degree <degree (e.g., (e.g.,MD) MD)(ST)> (ST)>^ ^<name <nametype typecode code(ID) (ID)> >
20 04/09/2007 21
04/09/2007
Reglas de procesamiento de mensajes
Reglas de proceso (Nivel 7 - Aplicación)
Existen dos formas de procesamiento de mensajes:
ORIGINAL PROCESSING RULES ENHANCED PROCESSING RULES
Secuencia de intercambio de mensajes
Paso 1. El sistema emisor construye un mensaje HL7 basado en datos de la aplicación y lo envía al sistema receptor. Paso 2. El sistema receptor recibe el mensaje y …
a) Valida sintácticamente el mensaje de acuerdo a reglas de iniciación basadas en el segmento MSH. Si falla envía un mensaje de rechazo al emisor; si no continua ... b) Pasa el mensaje a la aplicación, la cual:
1) crea un mensaje de respuesta, o … 2) crea un mensaje de error, o … 3) crea un mensaje de rechazo.
04/09/2007
22
c) Envía el mensaje de respuesta, error o rechazo.
04/09/2007
23
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Mensajes de respuesta - ACK
Procesamiento de la aplicación
Mensaje ACK - general acknowledgment
Mensaje de uso general para indicar un acuse de recibo de un mensaje. Indica si hubo o no un error al procesar el mensaje.
ACK MSH MSA [ ERR ] General acknowledgment Message Header Message acknowledgment Error Chapter 2 2 2
Una vez que la validación inicial del protocolo, analizando el encabezado MSH, se ha realizado se ejecuta una de las siguientes acciones:
1) Se procesa satisfactoriamente el mensaje, generando una respuesta con el valor AA en MSA-1-ack code. 2) Se crea una respuesta de error, proveyendo la información del error y el valor AE en el campo MSA-1 3) Falla al procesar el mensaje (Rechazo) por razones ajenas al contenido o formato (Caída del sistema, error interno, etc). Enviandose un mensaje con el valor AR en el campo MSA-1
04/09/2007
24
04/09/2007
25
Especificación del tipo de respuesta
Desafíos al utilizar HL7
En cada envío de un mensaje se puede especificar el campo MSH-15-Accept acknowledgment type
Este campo identifica las condiciones de requerimiento de mensajes de respuesta. Este campo es requerido para el modo extendido. Valor AL NE ER SU Descripción Siempre requiere respuesta Nunca requiere respuesta Únicamente ante un error Únicamente cuando es satisfactorio
Necesidad de especificaciones detalladas
¿Es correcta mi interpretación? ¿Es correcta la interpretación del otro? ¿Estoy de acuerdo?
• Decidir:
– ¿Qué mensajes utilizar? – ¿Qué eventos utilizar? – ¿Qué segmentos dentro de los mensajes? – ¿Qué campos dentro de los segmentos? – ¿Qué valores de las tablas definidas por el usuario?
26 04/09/2007 27
04/09/2007
¿Cómo implementar mensajería HL7?
2. Desarrollo de HL7 V2 y otros estándares
Establecer un ambiente de comunicaciones Especificar el protocolo de bajo nivel más aplicable Identificar los mensajes y eventos Establecer procedimientos
“Generales” para todos “Particulares” para sistemas específicos
HL7 – Otros estándares
• CCOW (Framework para compartir contexto entre aplicaciones) 1.3 (1999) • Arden Syntax (Sintaxis para compartir reglas de conocimiento clínico) 2.0 (1999) • CDA (Arquitectura de documento clínico – XML) 2000 (R2: Estándar 2005)
Identificar datos opcionales Generar una especificación detallada Escribir el plan de pruebas Desarrollar un plan de contingencias y mantenimiento
04/09/2007
28
SIS 2007
© 2005-7, HL7 Argentina
29
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
2. Desarrollo de HL7 V2 y otros estándares
3. Desarrollo de HL7 V2 y otros estándares
HL7 – Otros estándares
Interfaces con broker de objetos – 1998 Mensajería segura por email – 1999 HIPAA Claims Attachments – 1999 Mensajería v 2.x a través de XML – 2000 Healthcare Service Specification – 2005
Año 2000
Historia de HL7 – V3
Comienza el desarrollo de V3 (primeros RIM)
Año 2003
Metodología de Versión 3: RIM + Vocabulario + Herramientas
Año 2004:
Estándares temporarios (DSTU) V3 Early Adopters (Grupo de empresas o afiliados internacionales con implementaciones del estándar en su forma actual) El núcleo de v3 se transforma en estándar ANSI v3
SIS 2007
© 2005-7, HL7 Argentina
30
SIS 2007
© 2005-7, HL7 Argentina
31
2. Desarrollo de HL7 V2 y otros estándares
3. Relación de HL7 con otras SDO
Historia de HL7 – V3
Estado actual de V3 – Estándares normativos a Enero de 2007 (hay un ballot nuevo en setiembre)
Relación de HL7 con otras SDO
X12N (US: Edifact) US FDA y US CDISC/ Pharma DICOM UK: NHS National “spine” and GP-to-GP projects CEN TC 251 ISO TC 215 NIST (US: Nat’l Institute for Standards and Technology) HIMSS IHE
1.Refinamiento y Localización 2.Modelo de Referencia de Información (RIM) 3.Tipos de datos 4.Implementaciones XML y UML 5.Transporte MLLP 6.Servicios comunes de terminología 7.GELLO (lenguaje de expresión común) 8.Dominios de infraestructura:Master File, Query, Transmisión 9. Dominios administrativos:Facturación y cuentas, Liquidación y reembolsos, Turnos 10.Dominios clínicos: Provisión de Cuidado, CDA, Reportes de Salud Pública, Estudios regulados, Dispositivos terapéuticos
SIS 2007 © 2005-7, HL7 Argentina 32
SIS 2007
© 2005-7, HL7 Argentina
33
3. Relación de HL7 con otras SDO
4. Necesidad de Interfaces / Interoperabilidad
HL7 y el EHR
HL7 tiene como tarea encomendada por el Gob. de USA la definición de un modelo funcional estándar para el registro electrónico de salud: qué funciones debe cumplir y de qué manera. EHR-S
El Escenario Actual
Complejidad creciente de servicios de salud
Necesidad de mejor informació información para la toma de decisiones clí clínicas y de gestió gestión Necesidad de controlar los Servicios de Salud Disminuir costos Mejorar servicios
Necesidad de Informatizació Informatización de Servicios de Salud
SIS 2007 © 2005-7, HL7 Argentina 34 SIS 2007 © 2005-7, HL7 Argentina 35
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Evolución del Proceso de Informatización
Proliferación de sistemas departamentales independientes
Cubren mejor los requerimientos específicos de cada servicio Permiten informatización y actualizaciones graduales
Menos traumáticas que procesos masivos
4. Necesidad de Interfaces / Interoperabilidad
4. Necesidad de Interfaces / Interoperabilidad
Proliferación de Interfaces
Los sistemas distribuidos NO SIEMPRE poseen arquitecturas de datos compatibles
Necesidad de Interfaces entre Sistemas Necesidad de desarrollo y mantenimiento específicos para cada interfaz Multiplicación de desarrollos
La descentralización se adapta mejor a las complejas organizaciones de salud
Necesidad de Intercambio de Datos Necesidad de Integración de Información entre Sistemas de Salud
SIS 2007 © 2005-7, HL7 Argentina 36 SIS 2007
© 2005-7, HL7 Argentina
37
4. Necesidad de Interfaces / Interoperabilidad
4. Sistemas monolíticos y distribuidos
Interoperabilidad semántica
“Los sistemas son capaces de intercambiar datos y además pueden usar de manera predecible la información obtenida del intercambio”
Integración vs. Interoperabilidad
“Integración” es un concepto ‘difuso’: depende del contexto. Las aplicaciones pueden ser integradas a través de una base de datos común o usando mensajes e interfaces definidas. En los 80’s dominaban las bases de datos monolíticas. Se trasformó en imposible de mantener y actualizar. De allí el surgimiento de dominios heterogeneos.
¿Por qué es tan difícil en el área de salud?
Complejidad del propósito. Múltiples dominios (área de negocios, área clínica, etc.). Falta histórica de estándares que garantizaran la interoperabilidad semántica. Selección del mejor sistema en cada área departamental o institución (‘best of breed’).
SIS 2007 © 2005-7, HL7 Argentina 38
SIS 2007
© 2005-7, HL7 Argentina
39
5. Sistemas monolíticos y distribuidos
5. Sistemas monolíticos y distribuidos
La arquitectura ES importante
60’s and 70’s IBM otros 70’s and 80’s
Desarrolladores de Aplicaciones
¿Sistemas monolíticos?
Fase 1 – el pasado: Con la digitalizacion de los equipos de diagnóstico (PACs y laboratorio) se crearon ‘islas’ informatizadas. Esas islas debían poder interconectarse con cualquier sistema central –¿monolítico?- (administrativo o clínico)
90’s
Integradores de sistemas
Un proveedor de Hardware y Software
Proyectos de Instalacion Aplicaciones
Proyectos de instalacion Aplicaciones
Servidores, PCs
Hardware
Redes Selección estratégica Arquitecturas Herramientas SW industrial Alianzas
40
Selección Estratégica: Un proveedor!
Selección Estratégica Plataforma HW/SW Proveedor de Aplicaciones
© 2005-7, HL7 Argentina
SIS 2007
SIS 2007
© 2005-7, HL7 Argentina
41
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
3. Sistemas monolíticos y distribuidos
5. Sistemas monolíticos y distribuidos
¿Sistemas monolíticos?
Fase 2 – presente y futuro: Todas las ‘islas’ se pueden interconectar. La nueva ‘red’ se extiende entre prestadores, financiadores, gobiernos, y hasta la casa de los pacientes. Basado en:
una arquitectura obligatoriamente distribuida y heterogenea. una estructura técnica basada en estándares de facto.
Estrategia con sistemas distribuidos
Migrar del entorno monolítico a un marco abierto con integración de sistemas.
Comprar o construir las mejores aplicaciones para cada departamento y combinar las instalaciones con el manejo del cambio (reingeniería de procesos) Basar la arquitectura en estándares y productos estándares ‘de facto’.
Definir una estrategia de sistemas de información que de soporte a los objetivos organizacionales
SIS 2007 © 2005-7, HL7 Argentina 43
SIS 2007
© 2005-7, HL7 Argentina
42
6. ¿Porqué interfaces estándares?
6. ¿Porqué interfaces estándares?
Interfaces Estándares – Por Qué
interoperabilidad: capacidad de dos o más sistemas para intercambiar información y usar la información intercambiada.
Fuente: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]
SEMANTICA FUNCIONAL
Interfaces estándares – Por qué
Algo de historia: el número de Interfaces crece aprox. como ½ del cuadrado de la cantidad de sistemas a unir
Sistema A B 3 sistemas, 3 Interfases A C Sistema B 2 sistemas, 1 interfase
SIS 2007
© 2005-7, HL7 Argentina
44
SIS 2007
© 2005-7, HL7 Argentina
45
6. ¿Porqué interfaces estándares?
6. ¿Porqué interfaces estándares?
Interfaces estándares – Por qué
I = (n x (n-1)) / 2 Si hay entre 30 y 40 sistemas interfaceables: SIST Interfaces 30 435 40 780 50 1225 ¡Imposible de mantener! ¿Cuánto trabajo cuesta agregar un sistema?
SIS 2007 © 2005-7, HL7 Argentina 46
Interfaces estándares – Por qué
Algunos prestadores o financiadores en USA tienen usualmente entre 50 y 100 interfaces. Lo mismo ocurre para sistemas de salud regionales o nacionales en Europa. A un costo de entre 50.000 y 100.000 dolares por interface, es mucho mas barato tener una interface estándar. Esto reduce el costo a I=(n1). También permite que una interfaz se reemplace sin impactar a las demás. Esto último permite encarar un acercamiento más práctico al mantenimiento y reemplazo de los sistemas de información
SIS 2007 © 2005-7, HL7 Argentina 47
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
6. ¿Porqué interfaces estándares?
6. ¿Porqué interfaces estándares?
Interfaces estándares – Por qué
MODELO/MENSAJE ESTANDAR
Interfaces estándares – Por qué
Por otra parte, la tendencia actual es hacia la integración de la información de salud a nivel regional o de país. Imaginen la complejidad de esa tarea. Ahora imaginen la complejidad de esa tarea sin estándares bien definidos y localizados para mensajes, vocabularios, etc.
SIS 2007 © 2005-7, HL7 Argentina 49
?
PATIENT_ID FAMILY NAME GIVEN NAME ADDRESS STREET ADDRESS REGION PHONE
?
SISTEMA A
SISTEMA B
ID_PACIENTE APELLIDO MATERNO APELLIDO PATERNO DOMICILIO CALLE DOMICILIO PROVINCIA DOMICILIO COMUNA DOMICILIO NUMERO DOMICILIO PISO TELEFONO
IDENTIFICACION APELLIDO MADRE DOMICILIO CALLE NOMBRE PROVINCIA LOCALIDAD PISO TELEFONO COMERCIAL TELEFONO HOGAR CELULAR
Esto significa que no importa qué vendedor desarrolle un sistema, sus estructuras serán mapeadas contra una estructura semántica común y compartida. Realizar una interface, se convierte sencillamente en mapear desde/hasta estructuras semánticas estándares.
48
SIS 2007
© 2005-7, HL7 Argentina
6. ¿Porqué interfaces estándares?
7. Taller de interoperabilidad
Tipos de estándares
“De jure” vs. “de facto”
Es mejor ‘no ir contra la corriente’. Es muy dificil forzar el uso de estándares.
1. 2.
Tareas al enfocar una interface
Entender los requerimientos de interoperabilidad Definir para cada caso el estándar aplicable y los artefactos (mensajes, llamadas, documentos) requeridos Trabajar el vocabulario Especificar el entorno de comunicaciones Determinar el movimiento de datos a artefacto y viceversa. Construir la interface Documentar la implementación
© 2005-7, HL7 Argentina 51
Estándares “de jure”
CEN 251, ASTM (IEC, Cenelec TC 62), ICD10
3. 4. 5. 6. 7.
Estándares “de facto”
DICOM, HL7, EDI, DCE, Corbamed,IHE
SIS 2007 © 2005-7, HL7 Argentina 50
SIS 2007
Perfiles de Conformidad
Introducidos en versión 2.5 - NORMATIVO Los mensajes conformantes deben adherir a las reglas definidas por un ‘perfil de mensaje’.
Perfil de Mensaje
El ‘perfil de mensaje’ debe especificar
Qué datos se transferirán El formato en el cual serán transferidos Las responsabilidades del receptor/emisor
Es una especificación sin ambigüedades de uno o más mensajes analizados para un escenario o caso de uso en particular. Prescribe una serie de restricciones sobre el uso de un mensaje.
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Perfil de Mensaje
Debe contener:
el análisis del caso de uso una o más definiciones dinámicas (modelo de interacción, diagrama de actividades UML) una o más definiciones estáticas, expresadas como un documento XML registrado en un archivo centralizado en HL7.org
Perfil de Mensaje
Herramienta para creación de perfiles de mensajes (la parte estática)
MWB (Messaging Workbench)
(Disponible en HL7 Canadá: http://secure.cihi.ca/cihiweb/en/downloads/MWB%20Rel%20 6-2p1.zip
La definición estática debe contener: Reglas de uso para segmentos, grupos de segmentos, campos y componentes Cardinalidad (cantidad de repeticiones posibles para cada segmento) Conjuntos de valores y sistemas de codificación
Definición Estática
Guías de Implementación
No son normativas. Son una idea para documentar una implementación. Sugeridas en ‘Implementation Guide’ (v 2.4) Contiene plantillas (templates) para
Diagrama de interfaces Detalle de delimitadores Plantilla para tipos de datos Plantilla para cada mensaje definido Formulario para segmentos ‘Z’ Plantilla para cada segmento definido Matriz de eventos
Guías de Implementación
Cuáles son las circunstancias que generan intercambio de información. Mensajes a intercambiar. ¿Cuándo?. ¿Cómo? Responsabilidades de las partes. Respuesta en tiempo real o diferida Que segmentos, campos son opcionales u obligatorios Con qué información se completa cada campo
HL7 V2.X XML
Especificación para enviar mensajes HL7 utilizando XML como una alternativa a los ^y| Es estándar ANSI (2003) Ventajas:
¡se pueden utilizar parseadores estándares XML!
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
HL7 V2.X XML
Derivada de la base de datos del estándar HL7 v 2.x (una base access con todos los campos, segmentos, etc. que se puede adquirir en HL7.org) Contiene las definiciones hasta HL7 v2.4 La especificación viene acompañada de un schema XML para validar documentos XML que representan mensajes HL7.
HL7 V2.X XML
Los mensajes son elementos XML Los segmentos son elementos XML Los campos son elementos XML El tipo de datos es un atributo XML de cada campo
7. Taller de interoperabilidad
HL7 V2 XML (ejemplo)
<ACK xmlns="urn:hl7-org:v2xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v2xml ACK.xsd"> <MSH> <MSH.1>|</MSH.1> <MSH.2>^~\&</MSH.2> <MSH.3> <HD.1>LAB</HD.1> </MSH.3> <MSH.4> <HD.1>767543</HD.1> </MSH.4> <MSH.5> <HD.1>ADT</HD.1> </MSH.5>...
En todos los problemas:
1.
Antes de Empezar
2.
3.
4.
5.
Los sistemas son disjuntos, no comparten plataforma ni base de datos, de lo único que se dispone es de una linea confiable en caso de sitios remotos o de una red local conectada por IP. No hay restricción de fondos, tiempos, ni de herramientas: estamos definiendo REQUERIMIENTOS de INTEROPERABILIDAD: soñando despiertos. No tomamos en cuenta (HOY) los riesgos de mal funcionamiento. Diseñamos interacciones entre dos aplicaciones. Tómese luego el tiempo de pensar que pasa con estos casos cuando se suman aplicaciones interesadas o generadoras de datos... ¿para qué hacemos interfaces?: para evitar el doble ingreso de los datos y hacer que la información esté en el momento justo en el lugar preciso.
© 2005-7, HL7 Argentina 63
SIS 2007
7. Taller de interoperabilidad
7. Taller de interoperabilidad
EJERCICIOS DE INTEROPERABILIDAD
EN TODOS LOS CASOS:
a. b.
EJERCICIOS DE INTEROPERABILIDAD
Divididos en cinco casos de uso genéricos y estereotipados.
1. 2. 3. 4. 5.
Definir las partes involucradas en cada caso. Qué están tratando de conseguir – para que servirá la información. Cuándo se intercambia la información. Cuál es el contenido exacto de cada intercambio. Definir para cada caso los artefactos (mensajes,documentos, llamadas remotas a función, etc.) requeridos. Para cada interacción seleccionar los roles de aplicación y los eventos que generan intercambio de datos. Especificar el vocabulario para cada atributo codificado.
c. d. e.
f.
g.
Interoperabilidad intrahospitalaria clásica. Comunicación Prestadores – Pagadores. Otorgamiento de turnos médicos en forma distribuida. Información epidemiológica. Transmisión desde dispositivos electrónicos.
© 2005-7, HL7 Argentina 65
SIS 2007
© 2005-7, HL7 Argentina
64
SIS 2007
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
7. Taller de interoperabilidad
7. Taller de interoperabilidad
Problema 1
Sistema Sistema Administrativo Administrativo de deHospital Hospital ¿¿¿??? ¿¿¿??? Sistema Sistemade de Laboratorio Laboratorio Cobertura Cobertura Médica Médica ‘SU ‘SUSALUD’ SALUD’ ¿¿¿??? ¿¿¿???
Problema 2
Prestadores Prestadoresde de Alta AltaFrecuencia Frecuencia
El Hospital “ABC” (250 camas) tiene un sistema de gestiòn para el laboratorio y un Sistema Administrativo. Se desea que los datos de admision de los pacientes sean transmitidos al Sistema de Laboratorio y que el estado de las ordenes de laboratorio (en proceso, cumplidas, etc) sea transmitido al sistema del Hospital para su facturación.
La cobertura médica ‘Su Salud’ desea conectar su sistema de autorizaciones con los de sus 10 prestadores de mayor frecuencia (más de 250 consultas y prestaciones diarias c/u) para posibilitar la validación y autorización en línea. Por otra parte, ‘Su Salud’ exige a los prestadores de internación una epicrisis electrónica completa al momento del alta.
SIS 2007 © 2005-7, HL7 Argentina 67
SIS 2007
© 2005-7, HL7 Argentina
66
7. Taller de interoperabilidad
7. Taller de interoperabilidad
Problema 3
Cobertura Cobertura Médica Médica ‘WEBSALUD ‘WEBSALUD ’’ ¿¿¿??? ¿¿¿??? Centros CentrosMédicos Médicos Secretaria Secretariade de Salud Salud’’ ¿¿¿??? ¿¿¿??? Centro Centrode de Referencia Referencia
Problema 4
Centros Centrosde de Atención Atención Primaria Primaria
La cobertura médica ‘WEBSALUD’ desea conectar su call-center con cinco centros médicos para ofrecer un único front end para la toma de turnos por parte sus asociados. Los centros médicos tienen sistemas y reglas de negocio diversas para la asignación de turnos.
SIS 2007 © 2005-7, HL7 Argentina 68
La secretaría de salud de la provincia de Oberfonia quiere obtener en forma automatizada información epidemiológica de sus 20 centros de atención primaria. Es exclusivamente cuando en los laboratorios se detectan casos de Hepatitis B o C, HIV, Chagas y Toxoplasmosis, pero tiene que ser apenas detectado el caso. Los laboratorios cuentan con distintos sistemas otorgados en comodato por los seis proveedores de los analizadores de serologia. Además hay un centro de referencia encargado de confirmar los casos de HIV, que debe recibir en linea la solicitud confirmatoria.
SIS 2007 © 2005-7, HL7 Argentina 69
7. Taller de interoperabilidad
7. Taller de interoperabilidad
Problema 5
Emergencias Emergencias Médicas Médicas ¿¿¿??? ¿¿¿??? Hospitales Hospitales Zonales Zonales
EJERCICIOS DE INTEROPERABILIDAD
TIENEN 20 MINUTOS PARA DISCUTIR. ESTAMOS DISPONIBLES PARA CONSULTAS. SON LIBRES DE ASUMIR LO QUE QUIERAN SI LO DOCUMENTAN. ¡¡ADELANTE!!
La municipalidad de Lomas del Alto desea enviar a través de Wi Fi directamente desde la ambulancia la evaluación clínica y los resultados de EKG y gases en sangre que realizan a los pacientes in-situ en caso de emergencias médicas a la historia clínica electronica que reside en cada uno de sus hospitales zonales.
SIS 2007
© 2005-7, HL7 Argentina
70
SIS 2007
© 2005-7, HL7 Argentina
71
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
7. Taller de interoperabilidad
Conclusiones
Las claves de la interoperabilidad:
1. 2. 3. 4. 5. 6. Una interface debe servir para intercambiar INFORMACION con significado entre dos o más aplicaciones. Cada aplicación (y sus usuarios) tiene intereses distintos. Vocabulario compartido y controlado. Es fundamental una buena definición de los requerimientos y de las capacidades de los sistemas involucrados. ¿Por qué usar estándares?: para ayudarnos a entender los requerimientos y reducir costos y tiempos. HL7 cubre todos los requerimientos para armar interfaces estándar en el área de salud.
Implementaciones de HL7 en la Argentina •Proyecto de Conectividad de las Prepagas •Farmacia – Farmalink-SVI-SIBS •Fresenius – Argentina – Brasil •Hospital Italiano de Buenos Aires - Mensajería ADT •Hospital Italiano de Buenos Aires - Ordenes •Hospital Italiano de Buenos Aires - Resultados •Hospital Italiano de Buenos Aires - Farmacia •Hospital Italiano de Buenos Aires - Query •Hospital Italiano de Buenos Aires - CDA R2 •Hospital Italiano de Buenos Aires - RIS/PACS •Hospital Durand - Maternidades - Screening Neonatal •Biomerieux Argentina / Chile / Venezuela - Conexiones LIS MIC
SIS 2007
© 2005-7, HL7 Argentina
72
SIS 2007
© 2005-7, HL7 Argentina
73
Saber más
Como saber más
En el SIS 2007 mañana:
introducción a CDA
Cursos Introductorios a a distancia organizado por HL7 Argentina y el resto de los afiliados a HL7 de España y Latinoamérica:
la tercera edición comienza el 15 de setiembre de 2007 y cubre HL7 V2, V3, CDA (NO SPL)
Curso presencial y certificación en Córdoba:
9 y 10 de noviembre de 2007
Más información en www.hl7.org.ar
(C) 2005 HL7 & HL7 Argentina
Contenido
1. 2.
Introducción a HL7
3. 4. 5.
Introducción a HL7 Diego Kaminker HL7 Argentina – Presidente Marcelo Ceitlin SADIO SIS 2007 - MAR DEL PLATA
SIS 2007 © 2005-7, HL7 Argentina 0
6. 7.
HL7 – Organización y Objetivos Desarrollo de HL7 V2 y otros estándares Relación de HL7 con otros estándares. Necesidad de Interfaces. Interoperabilidad Sistemas monolíticos y distribuidos El porqué de los Estándares de Comunicación Taller de Interoperabilidad
© 2005-7, HL7 Argentina 1
SIS 2007
1. HL7 – Organización y Objetivos
¿Qué significa siete en HL7?
Misión
Misión de HL7: interoperabilidad clínica
“Proveer un marco completo y estándares relacionados para el intercambio, integración y recuperación de información electrónica de salud que soporte la práctica clínica y el gerenciamiento y evaluación de servicios de salud. Específicamente: crear estándares flexibles y costo-efectivos, guías y metodologías para permitir la interoperabilidad entre los sistemas de información y el intercambio de registros electrónicos de salud” (HL7 Mission statement, revisado en el año 2001) Estrategia: innovación – tanto de nuestros usuarios como de la organización
SIS 2007 © 2005-7, HL7 Argentina 2
Un protocolo para el intercambio de información clínica 7 7 6 6 5 5 4 4 3 3 2 2 1 1 Applicación Applicación HL7 Presentación Presentación Sesión Sesión Transporte Transporte Red Red Enlace Enlace Física Física
Función
Communicación
Arquitectura de comunicaciones del modelo de ISO llamado OSI (Open System Interconnection)
04/09/2007 3
1. HL7 – Organización y Objetivos
1. HL7 – Organización y Objetivos
¿Quiénes conforman HL7?
•Fundada en 1987. •Acreditada como SDO por ANSI en 1994 (Los estándares aprobados por HL7 desde 1994 son estándares para USA). •HL7 como organización tiene una estructura y procedimientos formales basados en la búsqueda del consenso y el balance de intereses entre los distintos sectores representados: empresas de software, financiadores de la salud, estados nacionales, universidades, prestadores de salud, consultores, etc.
SIS 2007 © 2005-7, HL7 Argentina 4 SIS 2007
•Más de 500 empresas miembros de la organización, más de 1500 miembros en total. •Alrededor de 500 miembros se reúnen periódicamente en los WGM – alrededor de 100 de ellos de algún afiliado internacional. •26 Afiliados internacionales (además de USA):
Argentina Canadá Rep.Checa Alemania Irlanda Corea N.Zelanda Sud Africa Holanda Australia China Dinamarca Grecia Italia Lituania Polonia Suiza Reino Unido Brasil Croacia Finlandia India Japón Mexico, Chile,Uruguay España Taiwan Prox.: Colombia
© 2005-7, HL7 Argentina
5
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
2. Desarrollo de HL7 V2 y otros estándares
Contenido
• •
Versión 1.0 y 2.0 de mensajería en años 1987 y 1988 Estándares de mensajería aprobados: 1990 1994 1997 1999 2000 2003 2007
Enfoque conceptual Construcción de Mensajes versión 2.X
Mensajes, Segmentos, Campos Delimitadores Reglas de ensamblado y desensamblado Tipos de datos
2.1
2.2
2.3 2.3.1 2.4
2.5
2.6?
Reglas de procesamiento Ejemplos de mensajes HL7 V2.X Recomendación para implementación de version 2.X Versión V2 XML
SIS 2007
© 2005-7, HL7 Argentina
6
04/09/2007
7
Modelo básico de transacciones HL7
Sistema B
Paradigmas de respuestas HL7
ORM msg
RECIBE MENSAJE Evento disparador ENVIA RESPUESTA
Evento disparador Aceptar ACK (opt)
ENVIA MENSAJE RECIBE RESPUESTA
Sistema A
Sistema A
RED ORR (opt)
Sistema B
Evento disparador
Aceptar ACK (opt)
04/09/2007
8
04/09/2007
9
Conceptos
Ejemplo de evento disparador
Eventos disparadores
El evento disparador es el hecho que genera la transmisión del mensaje. La relación entre TIPOS DE MENSAJE y CODIGOS DE EVENTO DISPARADOR es UNO a MUCHOS: El mismo evento disparador no puede asociarse a más de un tipo de mensaje.
Cuándo
Un evento A01 es enviado cuando se realiza el ingreso/admisión del paciente.
Qué
Normalmente, esta información es ingresada por el sistema de admisión de pacientes e informada al resto de los sistemas que conforman la organización
Actualizaciones no solicitadas
Cuando la transferencia de información es iniciada por el sistema que controla el evento, la transacción se denomina ‘ACTUALIZACION NO SOLICITADA’. Ejemplo: se concluye un estudio diagnóstico
Uso
Por ejemplo, un evento A01 puede ser usado para notificar al sistema de Laboratorio que un paciente ha sido admitido y al que se le puede fehacientemente solicitar estudios.
04/09/2007
10
04/09/2007
11
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Ejemplos de eventos ADT
A01 A02 A03 A04 A05 A06 A07 A08 A09 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 ADT/ACK - Admit a patient ADT/ACK - Transfer a patient ADT/ACK - Discharge a patient ADT/ACK - Register a patient ADT/ACK - Preadmit a patient ADT/ACK - Transfer an outpatient to inpatient ADT/ACK - Transfer an inpatient to outpatient ADT/ACK - Update patient information ADT/ACK - Patient departing ADT/ACK - Patient arriving ADT/ACK - Cancel admit ADT/ACK - Cancel transfer ADT/ACK - Cancel discharge ADT/ACK - Pending admit ADT/ACK - Pending transfer ADT/ACK - Pending discharge ADT/ACK - Swap patients ADT/ACK - Merge patient information QRY/ACK - Patient query ADT/ACK - Nursing/Census application updates ADT/ACK - Leave of absence - out (leaving) ADT/ACK - Leave of absence - in (returning) ADT/ACK - Delete a patient record
¿Qué es un mensaje HL7 abstracto?
Mensaje Abstracto
El nivel básico de definición dentro del estándar HL7 es el del mensaje abstracto asociado a cada evento particular. La definición del mensaje incluye:
DATOS : Los campos de datos a enviar dentro del mensaje RESPUESTAS : Las respuestas válidas ERRORES : El tratamiento de errores de aplicación (datos erróneos) o fallas de comunicación
12 04/09/2007 13
04/09/2007
Ejemplo de mensaje HL7 abstracto (ADT^A01)
ADT^A01^ADT_A01 MSH EVN PID [ PD1 ] [{ ROL }] [{ NK1 }] PV1 [ PV2 ] [{ ROL }] [{ DB1 }] [{ OBX }] [{ AL1 }] [{ DG1 }] [ DRG ] [{ PR1 [{ ROL }] }] [{ GT1 }] [{ IN1 [ IN2 ] [{ IN3 }] [{ ROL }] }] [ ACC ] [ UB1 ] [ UB2 ] [ P DA ] ADT Message Message Header Event Type Patient Identification Additional Demographics Role Next of Kin / Associated Parties Patient Visit Patient Visit - Additional Info. Role Disability Information Observation/Result Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Insurance Insurance Additional Info. Insurance Additional Info - Cert. Role Accident Information Universal Bill Information Universal Bill 92 Information Patient Death and Autopsy Chapter 2 3 3 3 12 3 3 3 12 3 7 3 6 6 6 12 6 6 6 6 12 6 6 6 3
Mensajes HL7
MSH|^~\&|NSI||LAB||20010827120759||ADT^A01|NSI1|P|2.3||||AL<cr> EVN|A01|18000101000000<cr> PID|1||60719^^^^HI|26690949^^^^DNI|TORRALBA^AIDA||19780113000000 |F|||POTOSI 4032 108^^CAPITAL FEDERAL^^1899<cr> NK1|1|CAMUS^ALBERTO|PAD|RIVADAVIA 253|42539686<cr> PV1|1|I|301|R|||1436^PEREZ^JORGE^ALBERTO|1026^LOPEZ^NORBERTO|998 ^GARCIA^ALEJANDRO|M|||A|4|A0|N|1026^LOPEZ^NORBERTO|OB|H0100240 |||||||||||||||||ALV||||||||20010823095130|20010823102455<cr> IN1|1|INT^^HI|2^^^^HI~347^^^^NSI|PLAN DE SALUD<cr>
Un Unmensaje mensajees esla launidad unidadtransferida transferidaentre entresistemas sistemasinformáticos. informáticos.Esta Esta compuesto compuestode depor porun ungrupo grupode desegmentos segmentosen enuna unasecuencia secuenciadefinida. definida.El El primer primersegmento segmento(MSH) (MSH)identifica identificael eltipo tipode demensaje mensajey yel elevento eventodisparador disparador que quehizo hizoque queel elmensaje mensajesea seaenviado. enviado.
14 04/09/2007 15
SIS 2007
© 2005-7, HL7 Argentina
Segmentos
SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
16 SIS 2007
Definición de segmento PID
LEN 4 20 250 20 250 250 26 1 250 250 250 4 250 250 250 250 250 250 16 25 250 DT OPT RP/# TBL# ITEM# SI O 00104 CX B 00105 CX R Y 00106 CX B Y 00107 XPN R Y 00108 XPN O Y 00109 TS O 00110 IS O 0001 00111 XPN B Y 00112 CE O Y 0005 00113 XAD O Y 00114 IS B 0289 00115 XTN O Y 00116 XTN O Y 00117 CE O 0296 00118 CE O 0002 00119 CE O 0006 00120 CX O 00121 ST B 00122 DLN O 00123 CX O Y 00124 ELEMENT NAME Set ID - PID Patient ID Patient Identifier List Alternate Patient ID - PID Patient Name Mother's Maiden Name Date/Time of Birth Administrative Sex Patient Alias Race Patient Address County Code Phone Number - Home Phone Number - Business Primary Language Marital Status Religion Patient Account Number SSN Number - Patient Driver's License Number - Patient Mother's Identifier
17
Características de los segmentos
Un segmento HL7 es una agrupación de campos. Los segmentos dentro de un mensaje:
Pueden ser REQUERIDOS u OPCIONALES Pueden ocurrir UNA SOLA VEZ o permitir REPETICIONES Se identifican por un código único de tres caracteres denominado ‘SEGMENT ID’
HL7 permite en cada implementación definir segmentos específicos para intercambiar información no prevista
Segmentos Z..
04/09/2007
© 2005-7, HL7 Argentina
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Campos
Componentes de un campo
Campo
Un campo es una cadena de caracteres definida por un tipo de datos de HL7. El apendice A del estándar, el diccionario de datos, brinda un listado alfabético de los campos, listados de codificación recomendada, y una referencia cruzada de los campos contra los segmentos
3.3.2.5 3.3.2.5Patient Patientname name(XPN) (XPN)00108 00108
Components: Components: <family <family name name (ST)> (ST)> ^ ^ <given <given name name (ST)> (ST)> ^ ^ <middle <middle initial initial or or name name (ST)> (ST)> ^ ^ <suffix <suffix (e.g., (e.g., JR JR or or III) III) (ST)> (ST)> ^ ^ <prefix <prefix (e.g., (e.g., DR) DR) (ST)> (ST)> ^ ^ <degree <degree (e.g., (e.g., MD) MD) (ST)> (ST)> ^ ^ <name <name type type code code (ID) (ID) > >
04/09/2007 18
MSH|^~\&|NSI||LAB||20010827120759||ADT^A01|NSI1|P|2.3||||AL<cr> EVN|A01|18000101000000<cr> PID|1||60719^^^^HI|26690949^^^^DNI|TORRALBA^AIDA^LIDIA||19780113 |F|||POTOSI 4032 108^^CAPITAL FEDERAL^^1899<cr> NK1|1|CAMUS^ALBERTO|PAD|RIVADAVIA 253|42539686<cr> PV1|1|I|301|R|||1436^PEREZ^JORGE^ALBERTO|1026^LOPEZ^NORBERTO|998 ^GARCIA^ALEJANDRO|M|||A|4|A0|N|1026^LOPEZ^NORBERTO|OB|H0100240 |||||||||||||||||ALV||||||||20010823095130|20010823102455<cr> IN1|1|INT^^HI|2^^^^HI~347^^^^NSI|PLAN DE SALUD<cr>
Componentes Componentesde deun uncampo campo((separador separador= =^ ^)) Un Uncampo campotambién tambiénpuede puedetener tenerpartes parteso ocomponentes componentes‘separables’. ‘separables’.Por Por ejemplo, ejemplo,el elnombre nombredel delpaciente pacientese seregistra registracomo comoApellido, Apellido,Nombre, Nombre,Inicial Inicial de Segundo Nombre. de Segundo Nombre.
04/09/2007 19
Caracteres de Codificación
Delimitadores:
| ^ ˜ \ & <CR>
Al construir un mensaje, se utilizan determinados caracteres como DELIMITADORES
Terminador de Segmento Separador de Campo Separador de Componente Separador de Subcomponente Caracter de Repetición Caracter de Escape <CR> | ^ & ~ \ (ASCII 13) (ASCII 124) (ASCII 94) (ASCII 38) (ASCII 126) (ASCII 92)
Alfanuméricos (ST,TX,FT) Numéricos (CQ,MO,NM,SI,SN) Identificadores (ID,IS,HD,EI,RP,PL,PT) Fecha/Hora (DT,TM,TS) Valores Codificados (CE,CF,CK,CN,CX,XCN) Genéricos (CM) Forma de Onda (CD,MA,NA,ED) Precios (CP) Finanzas (FC) Consultas extendidas (QSC,QIP,RCD) Archivos maestros (DLN,JCC,VH) Registros médicos (PPN) Series temporales (DR,RI,TQ) Datos Demográficos (AD,PN,TN,XAD,XPN,XON,XTN)
Tipos de datos
XPN XPNdata datatype: type: <family <familyname name(ST)> (ST)>^ ^<given <givenname name(ST)> (ST)>^ ^<middle <middleinitial initialor or name name(ST)> (ST)>^ ^<suffix <suffix(e.g., (e.g.,JR JRor orIII) III)(ST)> (ST)>^ ^<prefix <prefix(e.g., (e.g.,DR) DR)(ST)> (ST)>^ ^<degree <degree (e.g., (e.g.,MD) MD)(ST)> (ST)>^ ^<name <nametype typecode code(ID) (ID)> >
20 04/09/2007 21
04/09/2007
Reglas de procesamiento de mensajes
Reglas de proceso (Nivel 7 - Aplicación)
Existen dos formas de procesamiento de mensajes:
ORIGINAL PROCESSING RULES ENHANCED PROCESSING RULES
Secuencia de intercambio de mensajes
Paso 1. El sistema emisor construye un mensaje HL7 basado en datos de la aplicación y lo envía al sistema receptor. Paso 2. El sistema receptor recibe el mensaje y …
a) Valida sintácticamente el mensaje de acuerdo a reglas de iniciación basadas en el segmento MSH. Si falla envía un mensaje de rechazo al emisor; si no continua ... b) Pasa el mensaje a la aplicación, la cual:
1) crea un mensaje de respuesta, o … 2) crea un mensaje de error, o … 3) crea un mensaje de rechazo.
04/09/2007
22
c) Envía el mensaje de respuesta, error o rechazo.
04/09/2007
23
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Mensajes de respuesta - ACK
Procesamiento de la aplicación
Mensaje ACK - general acknowledgment
Mensaje de uso general para indicar un acuse de recibo de un mensaje. Indica si hubo o no un error al procesar el mensaje.
ACK MSH MSA [ ERR ] General acknowledgment Message Header Message acknowledgment Error Chapter 2 2 2
Una vez que la validación inicial del protocolo, analizando el encabezado MSH, se ha realizado se ejecuta una de las siguientes acciones:
1) Se procesa satisfactoriamente el mensaje, generando una respuesta con el valor AA en MSA-1-ack code. 2) Se crea una respuesta de error, proveyendo la información del error y el valor AE en el campo MSA-1 3) Falla al procesar el mensaje (Rechazo) por razones ajenas al contenido o formato (Caída del sistema, error interno, etc). Enviandose un mensaje con el valor AR en el campo MSA-1
04/09/2007
24
04/09/2007
25
Especificación del tipo de respuesta
Desafíos al utilizar HL7
En cada envío de un mensaje se puede especificar el campo MSH-15-Accept acknowledgment type
Este campo identifica las condiciones de requerimiento de mensajes de respuesta. Este campo es requerido para el modo extendido. Valor AL NE ER SU Descripción Siempre requiere respuesta Nunca requiere respuesta Únicamente ante un error Únicamente cuando es satisfactorio
Necesidad de especificaciones detalladas
¿Es correcta mi interpretación? ¿Es correcta la interpretación del otro? ¿Estoy de acuerdo?
• Decidir:
– ¿Qué mensajes utilizar? – ¿Qué eventos utilizar? – ¿Qué segmentos dentro de los mensajes? – ¿Qué campos dentro de los segmentos? – ¿Qué valores de las tablas definidas por el usuario?
26 04/09/2007 27
04/09/2007
¿Cómo implementar mensajería HL7?
2. Desarrollo de HL7 V2 y otros estándares
Establecer un ambiente de comunicaciones Especificar el protocolo de bajo nivel más aplicable Identificar los mensajes y eventos Establecer procedimientos
“Generales” para todos “Particulares” para sistemas específicos
HL7 – Otros estándares
• CCOW (Framework para compartir contexto entre aplicaciones) 1.3 (1999) • Arden Syntax (Sintaxis para compartir reglas de conocimiento clínico) 2.0 (1999) • CDA (Arquitectura de documento clínico – XML) 2000 (R2: Estándar 2005)
Identificar datos opcionales Generar una especificación detallada Escribir el plan de pruebas Desarrollar un plan de contingencias y mantenimiento
04/09/2007
28
SIS 2007
© 2005-7, HL7 Argentina
29
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
2. Desarrollo de HL7 V2 y otros estándares
3. Desarrollo de HL7 V2 y otros estándares
HL7 – Otros estándares
Interfaces con broker de objetos – 1998 Mensajería segura por email – 1999 HIPAA Claims Attachments – 1999 Mensajería v 2.x a través de XML – 2000 Healthcare Service Specification – 2005
Año 2000
Historia de HL7 – V3
Comienza el desarrollo de V3 (primeros RIM)
Año 2003
Metodología de Versión 3: RIM + Vocabulario + Herramientas
Año 2004:
Estándares temporarios (DSTU) V3 Early Adopters (Grupo de empresas o afiliados internacionales con implementaciones del estándar en su forma actual) El núcleo de v3 se transforma en estándar ANSI v3
SIS 2007
© 2005-7, HL7 Argentina
30
SIS 2007
© 2005-7, HL7 Argentina
31
2. Desarrollo de HL7 V2 y otros estándares
3. Relación de HL7 con otras SDO
Historia de HL7 – V3
Estado actual de V3 – Estándares normativos a Enero de 2007 (hay un ballot nuevo en setiembre)
Relación de HL7 con otras SDO
X12N (US: Edifact) US FDA y US CDISC/ Pharma DICOM UK: NHS National “spine” and GP-to-GP projects CEN TC 251 ISO TC 215 NIST (US: Nat’l Institute for Standards and Technology) HIMSS IHE
1.Refinamiento y Localización 2.Modelo de Referencia de Información (RIM) 3.Tipos de datos 4.Implementaciones XML y UML 5.Transporte MLLP 6.Servicios comunes de terminología 7.GELLO (lenguaje de expresión común) 8.Dominios de infraestructura:Master File, Query, Transmisión 9. Dominios administrativos:Facturación y cuentas, Liquidación y reembolsos, Turnos 10.Dominios clínicos: Provisión de Cuidado, CDA, Reportes de Salud Pública, Estudios regulados, Dispositivos terapéuticos
SIS 2007 © 2005-7, HL7 Argentina 32
SIS 2007
© 2005-7, HL7 Argentina
33
3. Relación de HL7 con otras SDO
4. Necesidad de Interfaces / Interoperabilidad
HL7 y el EHR
HL7 tiene como tarea encomendada por el Gob. de USA la definición de un modelo funcional estándar para el registro electrónico de salud: qué funciones debe cumplir y de qué manera. EHR-S
El Escenario Actual
Complejidad creciente de servicios de salud
Necesidad de mejor informació información para la toma de decisiones clí clínicas y de gestió gestión Necesidad de controlar los Servicios de Salud Disminuir costos Mejorar servicios
Necesidad de Informatizació Informatización de Servicios de Salud
SIS 2007 © 2005-7, HL7 Argentina 34 SIS 2007 © 2005-7, HL7 Argentina 35
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Evolución del Proceso de Informatización
Proliferación de sistemas departamentales independientes
Cubren mejor los requerimientos específicos de cada servicio Permiten informatización y actualizaciones graduales
Menos traumáticas que procesos masivos
4. Necesidad de Interfaces / Interoperabilidad
4. Necesidad de Interfaces / Interoperabilidad
Proliferación de Interfaces
Los sistemas distribuidos NO SIEMPRE poseen arquitecturas de datos compatibles
Necesidad de Interfaces entre Sistemas Necesidad de desarrollo y mantenimiento específicos para cada interfaz Multiplicación de desarrollos
La descentralización se adapta mejor a las complejas organizaciones de salud
Necesidad de Intercambio de Datos Necesidad de Integración de Información entre Sistemas de Salud
SIS 2007 © 2005-7, HL7 Argentina 36 SIS 2007
© 2005-7, HL7 Argentina
37
4. Necesidad de Interfaces / Interoperabilidad
4. Sistemas monolíticos y distribuidos
Interoperabilidad semántica
“Los sistemas son capaces de intercambiar datos y además pueden usar de manera predecible la información obtenida del intercambio”
Integración vs. Interoperabilidad
“Integración” es un concepto ‘difuso’: depende del contexto. Las aplicaciones pueden ser integradas a través de una base de datos común o usando mensajes e interfaces definidas. En los 80’s dominaban las bases de datos monolíticas. Se trasformó en imposible de mantener y actualizar. De allí el surgimiento de dominios heterogeneos.
¿Por qué es tan difícil en el área de salud?
Complejidad del propósito. Múltiples dominios (área de negocios, área clínica, etc.). Falta histórica de estándares que garantizaran la interoperabilidad semántica. Selección del mejor sistema en cada área departamental o institución (‘best of breed’).
SIS 2007 © 2005-7, HL7 Argentina 38
SIS 2007
© 2005-7, HL7 Argentina
39
5. Sistemas monolíticos y distribuidos
5. Sistemas monolíticos y distribuidos
La arquitectura ES importante
60’s and 70’s IBM otros 70’s and 80’s
Desarrolladores de Aplicaciones
¿Sistemas monolíticos?
Fase 1 – el pasado: Con la digitalizacion de los equipos de diagnóstico (PACs y laboratorio) se crearon ‘islas’ informatizadas. Esas islas debían poder interconectarse con cualquier sistema central –¿monolítico?- (administrativo o clínico)
90’s
Integradores de sistemas
Un proveedor de Hardware y Software
Proyectos de Instalacion Aplicaciones
Proyectos de instalacion Aplicaciones
Servidores, PCs
Hardware
Redes Selección estratégica Arquitecturas Herramientas SW industrial Alianzas
40
Selección Estratégica: Un proveedor!
Selección Estratégica Plataforma HW/SW Proveedor de Aplicaciones
© 2005-7, HL7 Argentina
SIS 2007
SIS 2007
© 2005-7, HL7 Argentina
41
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
3. Sistemas monolíticos y distribuidos
5. Sistemas monolíticos y distribuidos
¿Sistemas monolíticos?
Fase 2 – presente y futuro: Todas las ‘islas’ se pueden interconectar. La nueva ‘red’ se extiende entre prestadores, financiadores, gobiernos, y hasta la casa de los pacientes. Basado en:
una arquitectura obligatoriamente distribuida y heterogenea. una estructura técnica basada en estándares de facto.
Estrategia con sistemas distribuidos
Migrar del entorno monolítico a un marco abierto con integración de sistemas.
Comprar o construir las mejores aplicaciones para cada departamento y combinar las instalaciones con el manejo del cambio (reingeniería de procesos) Basar la arquitectura en estándares y productos estándares ‘de facto’.
Definir una estrategia de sistemas de información que de soporte a los objetivos organizacionales
SIS 2007 © 2005-7, HL7 Argentina 43
SIS 2007
© 2005-7, HL7 Argentina
42
6. ¿Porqué interfaces estándares?
6. ¿Porqué interfaces estándares?
Interfaces Estándares – Por Qué
interoperabilidad: capacidad de dos o más sistemas para intercambiar información y usar la información intercambiada.
Fuente: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]
SEMANTICA FUNCIONAL
Interfaces estándares – Por qué
Algo de historia: el número de Interfaces crece aprox. como ½ del cuadrado de la cantidad de sistemas a unir
Sistema A B 3 sistemas, 3 Interfases A C Sistema B 2 sistemas, 1 interfase
SIS 2007
© 2005-7, HL7 Argentina
44
SIS 2007
© 2005-7, HL7 Argentina
45
6. ¿Porqué interfaces estándares?
6. ¿Porqué interfaces estándares?
Interfaces estándares – Por qué
I = (n x (n-1)) / 2 Si hay entre 30 y 40 sistemas interfaceables: SIST Interfaces 30 435 40 780 50 1225 ¡Imposible de mantener! ¿Cuánto trabajo cuesta agregar un sistema?
SIS 2007 © 2005-7, HL7 Argentina 46
Interfaces estándares – Por qué
Algunos prestadores o financiadores en USA tienen usualmente entre 50 y 100 interfaces. Lo mismo ocurre para sistemas de salud regionales o nacionales en Europa. A un costo de entre 50.000 y 100.000 dolares por interface, es mucho mas barato tener una interface estándar. Esto reduce el costo a I=(n1). También permite que una interfaz se reemplace sin impactar a las demás. Esto último permite encarar un acercamiento más práctico al mantenimiento y reemplazo de los sistemas de información
SIS 2007 © 2005-7, HL7 Argentina 47
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
6. ¿Porqué interfaces estándares?
6. ¿Porqué interfaces estándares?
Interfaces estándares – Por qué
MODELO/MENSAJE ESTANDAR
Interfaces estándares – Por qué
Por otra parte, la tendencia actual es hacia la integración de la información de salud a nivel regional o de país. Imaginen la complejidad de esa tarea. Ahora imaginen la complejidad de esa tarea sin estándares bien definidos y localizados para mensajes, vocabularios, etc.
SIS 2007 © 2005-7, HL7 Argentina 49
?
PATIENT_ID FAMILY NAME GIVEN NAME ADDRESS STREET ADDRESS REGION PHONE
?
SISTEMA A
SISTEMA B
ID_PACIENTE APELLIDO MATERNO APELLIDO PATERNO DOMICILIO CALLE DOMICILIO PROVINCIA DOMICILIO COMUNA DOMICILIO NUMERO DOMICILIO PISO TELEFONO
IDENTIFICACION APELLIDO MADRE DOMICILIO CALLE NOMBRE PROVINCIA LOCALIDAD PISO TELEFONO COMERCIAL TELEFONO HOGAR CELULAR
Esto significa que no importa qué vendedor desarrolle un sistema, sus estructuras serán mapeadas contra una estructura semántica común y compartida. Realizar una interface, se convierte sencillamente en mapear desde/hasta estructuras semánticas estándares.
48
SIS 2007
© 2005-7, HL7 Argentina
6. ¿Porqué interfaces estándares?
7. Taller de interoperabilidad
Tipos de estándares
“De jure” vs. “de facto”
Es mejor ‘no ir contra la corriente’. Es muy dificil forzar el uso de estándares.
1. 2.
Tareas al enfocar una interface
Entender los requerimientos de interoperabilidad Definir para cada caso el estándar aplicable y los artefactos (mensajes, llamadas, documentos) requeridos Trabajar el vocabulario Especificar el entorno de comunicaciones Determinar el movimiento de datos a artefacto y viceversa. Construir la interface Documentar la implementación
© 2005-7, HL7 Argentina 51
Estándares “de jure”
CEN 251, ASTM (IEC, Cenelec TC 62), ICD10
3. 4. 5. 6. 7.
Estándares “de facto”
DICOM, HL7, EDI, DCE, Corbamed,IHE
SIS 2007 © 2005-7, HL7 Argentina 50
SIS 2007
Perfiles de Conformidad
Introducidos en versión 2.5 - NORMATIVO Los mensajes conformantes deben adherir a las reglas definidas por un ‘perfil de mensaje’.
Perfil de Mensaje
El ‘perfil de mensaje’ debe especificar
Qué datos se transferirán El formato en el cual serán transferidos Las responsabilidades del receptor/emisor
Es una especificación sin ambigüedades de uno o más mensajes analizados para un escenario o caso de uso en particular. Prescribe una serie de restricciones sobre el uso de un mensaje.
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
Perfil de Mensaje
Debe contener:
el análisis del caso de uso una o más definiciones dinámicas (modelo de interacción, diagrama de actividades UML) una o más definiciones estáticas, expresadas como un documento XML registrado en un archivo centralizado en HL7.org
Perfil de Mensaje
Herramienta para creación de perfiles de mensajes (la parte estática)
MWB (Messaging Workbench)
(Disponible en HL7 Canadá: http://secure.cihi.ca/cihiweb/en/downloads/MWB%20Rel%20 6-2p1.zip
La definición estática debe contener: Reglas de uso para segmentos, grupos de segmentos, campos y componentes Cardinalidad (cantidad de repeticiones posibles para cada segmento) Conjuntos de valores y sistemas de codificación
Definición Estática
Guías de Implementación
No son normativas. Son una idea para documentar una implementación. Sugeridas en ‘Implementation Guide’ (v 2.4) Contiene plantillas (templates) para
Diagrama de interfaces Detalle de delimitadores Plantilla para tipos de datos Plantilla para cada mensaje definido Formulario para segmentos ‘Z’ Plantilla para cada segmento definido Matriz de eventos
Guías de Implementación
Cuáles son las circunstancias que generan intercambio de información. Mensajes a intercambiar. ¿Cuándo?. ¿Cómo? Responsabilidades de las partes. Respuesta en tiempo real o diferida Que segmentos, campos son opcionales u obligatorios Con qué información se completa cada campo
HL7 V2.X XML
Especificación para enviar mensajes HL7 utilizando XML como una alternativa a los ^y| Es estándar ANSI (2003) Ventajas:
¡se pueden utilizar parseadores estándares XML!
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
HL7 V2.X XML
Derivada de la base de datos del estándar HL7 v 2.x (una base access con todos los campos, segmentos, etc. que se puede adquirir en HL7.org) Contiene las definiciones hasta HL7 v2.4 La especificación viene acompañada de un schema XML para validar documentos XML que representan mensajes HL7.
HL7 V2.X XML
Los mensajes son elementos XML Los segmentos son elementos XML Los campos son elementos XML El tipo de datos es un atributo XML de cada campo
7. Taller de interoperabilidad
HL7 V2 XML (ejemplo)
<ACK xmlns="urn:hl7-org:v2xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v2xml ACK.xsd"> <MSH> <MSH.1>|</MSH.1> <MSH.2>^~\&</MSH.2> <MSH.3> <HD.1>LAB</HD.1> </MSH.3> <MSH.4> <HD.1>767543</HD.1> </MSH.4> <MSH.5> <HD.1>ADT</HD.1> </MSH.5>...
En todos los problemas:
1.
Antes de Empezar
2.
3.
4.
5.
Los sistemas son disjuntos, no comparten plataforma ni base de datos, de lo único que se dispone es de una linea confiable en caso de sitios remotos o de una red local conectada por IP. No hay restricción de fondos, tiempos, ni de herramientas: estamos definiendo REQUERIMIENTOS de INTEROPERABILIDAD: soñando despiertos. No tomamos en cuenta (HOY) los riesgos de mal funcionamiento. Diseñamos interacciones entre dos aplicaciones. Tómese luego el tiempo de pensar que pasa con estos casos cuando se suman aplicaciones interesadas o generadoras de datos... ¿para qué hacemos interfaces?: para evitar el doble ingreso de los datos y hacer que la información esté en el momento justo en el lugar preciso.
© 2005-7, HL7 Argentina 63
SIS 2007
7. Taller de interoperabilidad
7. Taller de interoperabilidad
EJERCICIOS DE INTEROPERABILIDAD
EN TODOS LOS CASOS:
a. b.
EJERCICIOS DE INTEROPERABILIDAD
Divididos en cinco casos de uso genéricos y estereotipados.
1. 2. 3. 4. 5.
Definir las partes involucradas en cada caso. Qué están tratando de conseguir – para que servirá la información. Cuándo se intercambia la información. Cuál es el contenido exacto de cada intercambio. Definir para cada caso los artefactos (mensajes,documentos, llamadas remotas a función, etc.) requeridos. Para cada interacción seleccionar los roles de aplicación y los eventos que generan intercambio de datos. Especificar el vocabulario para cada atributo codificado.
c. d. e.
f.
g.
Interoperabilidad intrahospitalaria clásica. Comunicación Prestadores – Pagadores. Otorgamiento de turnos médicos en forma distribuida. Información epidemiológica. Transmisión desde dispositivos electrónicos.
© 2005-7, HL7 Argentina 65
SIS 2007
© 2005-7, HL7 Argentina
64
SIS 2007
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
7. Taller de interoperabilidad
7. Taller de interoperabilidad
Problema 1
Sistema Sistema Administrativo Administrativo de deHospital Hospital ¿¿¿??? ¿¿¿??? Sistema Sistemade de Laboratorio Laboratorio Cobertura Cobertura Médica Médica ‘SU ‘SUSALUD’ SALUD’ ¿¿¿??? ¿¿¿???
Problema 2
Prestadores Prestadoresde de Alta AltaFrecuencia Frecuencia
El Hospital “ABC” (250 camas) tiene un sistema de gestiòn para el laboratorio y un Sistema Administrativo. Se desea que los datos de admision de los pacientes sean transmitidos al Sistema de Laboratorio y que el estado de las ordenes de laboratorio (en proceso, cumplidas, etc) sea transmitido al sistema del Hospital para su facturación.
La cobertura médica ‘Su Salud’ desea conectar su sistema de autorizaciones con los de sus 10 prestadores de mayor frecuencia (más de 250 consultas y prestaciones diarias c/u) para posibilitar la validación y autorización en línea. Por otra parte, ‘Su Salud’ exige a los prestadores de internación una epicrisis electrónica completa al momento del alta.
SIS 2007 © 2005-7, HL7 Argentina 67
SIS 2007
© 2005-7, HL7 Argentina
66
7. Taller de interoperabilidad
7. Taller de interoperabilidad
Problema 3
Cobertura Cobertura Médica Médica ‘WEBSALUD ‘WEBSALUD ’’ ¿¿¿??? ¿¿¿??? Centros CentrosMédicos Médicos Secretaria Secretariade de Salud Salud’’ ¿¿¿??? ¿¿¿??? Centro Centrode de Referencia Referencia
Problema 4
Centros Centrosde de Atención Atención Primaria Primaria
La cobertura médica ‘WEBSALUD’ desea conectar su call-center con cinco centros médicos para ofrecer un único front end para la toma de turnos por parte sus asociados. Los centros médicos tienen sistemas y reglas de negocio diversas para la asignación de turnos.
SIS 2007 © 2005-7, HL7 Argentina 68
La secretaría de salud de la provincia de Oberfonia quiere obtener en forma automatizada información epidemiológica de sus 20 centros de atención primaria. Es exclusivamente cuando en los laboratorios se detectan casos de Hepatitis B o C, HIV, Chagas y Toxoplasmosis, pero tiene que ser apenas detectado el caso. Los laboratorios cuentan con distintos sistemas otorgados en comodato por los seis proveedores de los analizadores de serologia. Además hay un centro de referencia encargado de confirmar los casos de HIV, que debe recibir en linea la solicitud confirmatoria.
SIS 2007 © 2005-7, HL7 Argentina 69
7. Taller de interoperabilidad
7. Taller de interoperabilidad
Problema 5
Emergencias Emergencias Médicas Médicas ¿¿¿??? ¿¿¿??? Hospitales Hospitales Zonales Zonales
EJERCICIOS DE INTEROPERABILIDAD
TIENEN 20 MINUTOS PARA DISCUTIR. ESTAMOS DISPONIBLES PARA CONSULTAS. SON LIBRES DE ASUMIR LO QUE QUIERAN SI LO DOCUMENTAN. ¡¡ADELANTE!!
La municipalidad de Lomas del Alto desea enviar a través de Wi Fi directamente desde la ambulancia la evaluación clínica y los resultados de EKG y gases en sangre que realizan a los pacientes in-situ en caso de emergencias médicas a la historia clínica electronica que reside en cada uno de sus hospitales zonales.
SIS 2007
© 2005-7, HL7 Argentina
70
SIS 2007
© 2005-7, HL7 Argentina
71
(C) 2005 HL7 & HL7 Argentina
Introducción a HL7
7. Taller de interoperabilidad
Conclusiones
Las claves de la interoperabilidad:
1. 2. 3. 4. 5. 6. Una interface debe servir para intercambiar INFORMACION con significado entre dos o más aplicaciones. Cada aplicación (y sus usuarios) tiene intereses distintos. Vocabulario compartido y controlado. Es fundamental una buena definición de los requerimientos y de las capacidades de los sistemas involucrados. ¿Por qué usar estándares?: para ayudarnos a entender los requerimientos y reducir costos y tiempos. HL7 cubre todos los requerimientos para armar interfaces estándar en el área de salud.
Implementaciones de HL7 en la Argentina •Proyecto de Conectividad de las Prepagas •Farmacia – Farmalink-SVI-SIBS •Fresenius – Argentina – Brasil •Hospital Italiano de Buenos Aires - Mensajería ADT •Hospital Italiano de Buenos Aires - Ordenes •Hospital Italiano de Buenos Aires - Resultados •Hospital Italiano de Buenos Aires - Farmacia •Hospital Italiano de Buenos Aires - Query •Hospital Italiano de Buenos Aires - CDA R2 •Hospital Italiano de Buenos Aires - RIS/PACS •Hospital Durand - Maternidades - Screening Neonatal •Biomerieux Argentina / Chile / Venezuela - Conexiones LIS MIC
SIS 2007
© 2005-7, HL7 Argentina
72
SIS 2007
© 2005-7, HL7 Argentina
73
Saber más
Como saber más
En el SIS 2007 mañana:
introducción a CDA
Cursos Introductorios a a distancia organizado por HL7 Argentina y el resto de los afiliados a HL7 de España y Latinoamérica:
la tercera edición comienza el 15 de setiembre de 2007 y cubre HL7 V2, V3, CDA (NO SPL)
Curso presencial y certificación en Córdoba:
9 y 10 de noviembre de 2007
Más información en www.hl7.org.ar
(C) 2005 HL7 & HL7 Argentina
