Taller de Interoperabilidad HL7 v3/cda DIA 2

Transcripción

1 Taller de Interoperabilidad HL7 v3/cda DIA 2 Juan Miguel Venturello HL7Spain jventurello@costaisa.com Agradecimiento especial a Diego Kaminker, HL7 Argentina, dkaminker@fibertel.com.ar 1 Agenda DIA 1 Presentación del Taller Introducción HL7 versión 3 Fundamentos de la versión 3 de HL7 Arquitectura de Mensajes y Documentos DIA 2 Admisión de un paciente con mensajes v3 Resultados de laboratorio con mensajes v3 DIA 3 Introducción CDA Informe de alta con un documento CDA Hoja de ruta para implantar HL7 v3 & CDA 2 1

2 Recursos Documentales En el CD (y en su PC, en el escritorio) encontrarán toda la documentación expuesta: En la carpeta Estándar: Ballot de Septiembre HL7 v3 (no es final). Contiene errores, está incompleta no usar en implementaciones! Versión normativa 2005 disponible para miembros. En la carpeta Ejemplos: Ejemplo de Admisión. Ejemplo de Laboratorio. Documento CDA. En la carpeta de cada día: Los enunciados de los ejercicios (nunca las respuestas!). En la carpeta del segundo día: Información sobre el escenario específico ficticio (texto narrativo, vocabulario, identificadores en hoja excel, etc). En la carpeta Imágenes del segundo día: Ficheros con DMIM s, RMIM s, CMET s y otras imágenes referenciadas. En formato GIF y PNG. En la carpeta de cada día, PDF s con todas las presentaciones. En la carpeta Enlaces, vínculos a páginas webs de referenciadas o de interés para ustedes. 3 Herramientas Para explorar documentos XML: SyncRO Soft s Oxygen XML Aplicación recomendada, se puede descagar versión de prueba de 30 días con funcionalidad completa. Valida correctamente con los esquemas complejos de HL7 v3 (no todas las herramientas lo hacen!). Otra herramienta popular en el circulo de HL7, y que valida correctamente, es Altova s XML Spy. Más costosa, más opciones avanzadas

3 Storyboard Para que los datos comiencen a sonarnos conocidos, trabajaremos durante todo el taller con aplicaciones y actores físicos( pacientes, hospitales, laboratorios) conocidos, tomados de un solo storyboard y un escenario específico de interoperabilidad. Ver: Escenario Descipción.pdf 5 Escenario de Interoperabilidad AUSAN HOCEM SILAB SIMAG CENAP 6 3

4 Actores Nuestro caso específico se desarrolla en un entorno en el cual las aplicaciones que se comunican (actores de interoperabilidad) son: CENAP: Punto de asistencia HOCEN: Hospital de referencia SILAB: Laboratorio clinico SIMAG: Diagnostico por imágenes AUSAN: Autoridad sanitaria 7 Actores (detalle) Punto de asistencia (CENAP) Servicio de Emergencias Médicas de un Centro de Atención Primaria (CAP) que forma parte de una red de puntos de una organización asistencial. Red de hospitales, cada hospital disponiendo de una red de CAP s. En cada CAP disponen de su aplicación informática CENAP que está conectada con la corporativa del hospital. En nuestro caso de uso, este es el primer punto de contacto del paciente con nuestro Health Care Community Network. 8 4

5 Actores (detalle) Hospital de referencia (HOCEN) Es quien gestiona los servicios concertados con laboratorios y diagnóstico por la imagen y en caso de derivación del paciente es el que lo ingresa. También lleva una historia clínica electrónica completa del paciente a través de la aplicación HOCEN, por lo cual requiere conocer las admisiones, los resultados de diagnóstico y evoluciones médicas. 9 Actores (detalle) Laboratorio (SILAB) y Diagnostico por la imagen (SIMAG) Los servicios auxiliares de diagnóstico cuentan con sus propias aplicaciones que están conectadas al resto de la red mediante mensajería HL7 v3. Estas aplicaciones requieren conocer las ordenes (SILAB, en el caso de laboratorio) y los datos de admisión (SIMAG, en el caso de imágenes) para realizar los servicios diagnósticos correspondientes. Luego envían los resultados a HOCEN. Autoridad sanitaria (AUSAN) A la autoridad sanitaria se le informa un detalle completo del caso por razones regulatorias (este caso se trata de una de las enfermedades infecciosas que debe ser notificada). La aplicación de la autoridad es AUSAN. 10 5

6 Escenario (visión simplificada) SISTEMA DE LABORATORIO SILAB MENSAJE DE RESULTADOS v3 MENSAJE ORDEN ANALITICA v3 SISTEMA PUNTO DE ASISTENCIA CENAP MENSAJE DE ADMISION v3 MENSAJE DE RESULTADOS v3 SISTEMA DE RADIOLOGIA SIMAG SISTEMA CONTROL INFECCIONES AUSAN INFORME ATENCION CDA INFORME ATENCION CDA SISTEMA ADMISION HOSPITAL HOCEN En En fondo azul, los los mensajes que que exploraremos a fondo. 11 Vista del Esquema Implantado 12 6

7 Mensajes y Documentos a Implantar Del universo de posibles mensajes y documentos a utilizar para implantar este escenario, seleccionamos: Mensaje v3 de admisión de paciente CENAP SIMAG Mensaje v3 de resultados de laboratorio SILAB CENAP Documento CDA R2 de alta HOCEN AUSAN 13 Caso Caso de de Uso Uso Escenario Escenario Emisor Especifica Es formalizado Rol Rol de de Aplicación Aplicación Interacción Interacción Receptor Evento Evento Activador Activador Activa Contiene Instancia Define Define Define RIM RIM D-MIM D-MIM R-MIM R-MIM HMD HMD Mensaje Mensaje Detalle? Que significa revisar en detalle?: apoyándonos en el ballot de v3/cda de septiembre de 2005, revisaremos cada uno de estos ítems: Escenario / CU, Roles de Aplicación, Evento Activador, Modelos (RIM/DMIM/RMIM/HMD) Vocabulario, Mensaje 14 7

8 Nota Preliminar Primero que nada, desde que rol estamos trabajando: Somos USUARIOS del estándar - queremos utilizar los componentes (mensajes y documentos ya definidos en el ballot) Podríamos ser desarrolladores del estándar, y ver el proceso para desarrollar mensajes, pero no es el caso hoy. Ayer vimos la teoría en la cual hoy nos basaremos para elaborar este caso práctico. 15 Parte 1 Admisión de un paciente con mensajes v3 SISTEMA PUNTO DE ASISTENCIA CENAP MENSAJE DE ADMISION v3 SISTEMA DE RADIOLOGIA SIMAG 16 8

9 Metodología 1. Entender los requerimientos de interoperabilidad del escenario especifico. 2. Definir para cada caso el estándar aplicable y los artefactos (mensajes, llamadas, documentos) requeridos. 3. Trabajar el vocabulario y los identificadores. 4. Especificar el entorno de comunicaciones. 5. Determinar el movimiento de datos a artefacto y viceversa. 6. Construir y documentar la interfase. 17 Entender los Requerimientos Para el escenario simplificado del mensaje de admisión, lo único que se requiere es enviar la información al servicio de radiología en el momento en que comienza un encuentro de emergencia en el Servicio de Urgencias del Centro de Atención Primaria. 18 9

10 Definir el estándar y artefactos aplicables El Estándar? Vamos a usar HL7! Sabrán porqué Esto nos reduce las opciones a mensajes (V2, v3) o CDA Si no usáramos HL7, podríamos haber utilizado un web service con un contenido definido por nosotros, un file transfer igualmente con contenido definido, una llamada a RPC, etc. 19 Definir el estándar y artefactos aplicables V2.x, v3 o CDA? Normalmente, para este dominio, V2.x hubiera sido suficiente (en el curso del martes optamos por v2.x). Optamos por v3/cda por razones de infraestructura e interoperabilidad a gran escala: un requerimiento no escrito pero que se ve en el escenario es que hay MUCHAS partes involucradas, que deben interactuar entre sí. La recomendación de HL7 ahora es si es un proyecto nuevo y grande, use v

11 Definir el estándar y artefactos aplicables Mensajes o Documentos v3? Este caso es uno de los que involucran mensajes. Es una APLICACION que quiere notificar a otra de un EVENTO. Claramente es un mensaje. No hay una persona que quiere entregar un documento firmado a otra a través de las aplicaciones. La aplicación receptora y la emisora descartarán el medio por el cual se transfiere la información luego de procesarla (excepto para log). Ya veremos en la introducción a CDA la definición. Por todo esto, utilizaremos mensajes de HL7 v3. 21 Qué mensaje v3? Lo primero por decidir es que mensaje se envía. Vamos a buscar en el estándar recomiendo que me sigáis en su ordenador para que se familiaricen con el documento. Los Los dominios clínicos y administrativos están en en la la carpeta Domains del del estándar

12 Qué mensaje v3? Seleccionamos el el tópico Emergency Encounter del del dominio Patient Administration de de la la carpeta Administrative Management 23 Qué mensaje v3? Ahora veamos si el escenario coincide con el nuestro... Leemos la descripción

13 Storyboard Buscamos entre los Storyboards disponibles y seleccionamos el escenario para Emergency Encounter. Será este el correcto? Pequeña digresión: Como se forma código en los nombre? De que vá esto? Ej. PRPA_ST Cómo se forma el nombre de un artefacto? Subsección Dominio Descripción Detalle PO POLB Operaciones Laboratorio PO PORX Operaciones Farmacia RC RCMR Registros Registros médicos PR PRPA Práctica Administración de Pacientes PR PRSC Práctica Turnos PR PRPM Práctica Manejo de Personal FI FICR Financiero Pagos y reembolsos FI FIAB Financiero Cuentas y facturación MC MCCI Control de Mensajes Infraestructura de control de mensajes MC MCAI Control de Mensajes Infraestructura de mensajes de actos MF MFMI Archivos maestros Gestión de archivos maestros QU QUQI Consultas Infraestructura de consultas CO COMT Contenido común Elementos comunes (CMETs) Realm (por ahora solo existe UV=Universal) PRPA _ST UV 00 Tipo de Artefacto CODIGO Rol de aplicación AR D-MIM (Modelo de información de dominio) DM HMD (Descriptor jerárquico de mensaje) HD Interacción IN Tipo de Mensaje MT R-MIM (Modelo de información refinado de mensaje) RM Escenario ST Narrativa de escenario SN Evento disparador TE Versión número de ballot Identificador único de seis dígitos asignado por TC Con Con el el tiempo tiempo usando usando el el estándar, aprende uno uno de de memoria los los tipos tipos de de artefacto y la la sección y dominio y esto esto es es de de gran gran ayuda. ayuda

14 Storyboard Primero una descripción del propósito del storyboard. Diagrama de interacción, con: Roles de aplicación involucrados. Interacciones entre ellos. Listado de interacciones. Hipervínculo a sus descripciones. Mas abajo 27 Storyboard Ya Ya que que esta esta es es la la interacción interacción que que necesitamos, necesitamos, exploramos exploramos su su contenido... contenido... Narrativa del escenario Explica el escenario en forma narrativa, incluyendo y definiendo las interacciones habituales Nuestro Escenario Servicio Urgencias Hospital ABC. Admisión de Urgencias identifica un paciente joven con fiebre y esputos hemoptoicos

15 Interacción La interacción nos define: Evento Disparador. Capa de Transmisión. Capa de Control de Actos. Tipo de Mensaje. Roles de Aplicación. 29 Evento Disparador En el apartado del evento, se incluye: Nombre estructurado. Tipo del evento. Código de Evento (PRPA_TE403001) El código de evento se envía en el Control Act Wrapper. Equivalencia con v2. Transición de estados (ver siguiente diapositiva)

16 Diagrama de Estados El El cambio cambio de de estado estado inicial inicial es es de de NULO NULO a a ACTIVO ACTIVO 31 Definición del Mensaje Un mensaje v3 está compuesto (en general) por: <mensaje> Capa de Transmisión / Message Transmission Wrapper... (datos del mensaje: identificación, tipo, origen, destino...) Capa de Control de Actos / Control Act Wrapper <control act>... (datos del evento: quien, cuando, donde, porque ) <payload> Tipo de Mensaje / Message Type (El mensaje: datos específicos del dominio ) </payload> </control act> </mensaje> Vamos a definir cada una de ellas y verlas en un ejemplo de mensaje ya creado

17 Capa de Transmisión Listado Listado de de CMETs CMETs utilizados utilizados Ver Ver en en Modo Modo Tabla Tabla Descripción del Mensaje Base Ver Ver R-MIM R-MIM del del Mensaje Mensaje Base Base Ver Ver en en Modo Modo Tabla Tabla El mensaje base sirve como definición de varios tipos de mensaje que restringen la definición se usan para distintos eventos (esto se aplica a las tres capas). Ver Ver en en Modo Modo Excel Excel Ver Ver Interacciones Interacciones Ver Ver Schema Schema XML XML Descripción del Tipo de Mensaje 33 Mensaje base: CMET s utilizados Documentación y modelo modelo de de los los CMET s utilizados en en el el mensaje

18 Taller de Interoperabilidad HL7 V3/CDA Mensaje Base: Descripción del R-MIM Vinculo Vinculoalalgráfico gráfico Detalle Detalledel delr-mim R-MIMpara paraesta estacapa, capa,realiza realizaun un walk-through : walk-through :explica explicauno unopor poruno unolos los elementos elementosrequeridos. requeridos. 35 SPAIN Mensaje Base Gráfico del R-MIM Es Eselelmomento momentode dever verelelmensaje, mensaje,para para comparar compararcon conelelrmim. RMIM.Abramos Abramos mensaje_admision_in.xml mensaje_admision_in.xmlen enelel Oxygen Oxygen 36 SPAIN 18

19 Mensaje Base: Visión Tabular 37 Mensaje Base: Visión en Excel 38 19

20 Tipo de Mensaje: Ver Schema XML Schema: la la definición del del Schema XML XML para para esta esta capa capa 39 Tipo de Mensaje: Visión Tabular Es Es un un refinamiento de de la la definición jerárquica del del mensaje 40 20

21 Control de Actos / Tipo de Mensaje Este procedimiento debe repetirse para las otras capas: Control de Actos Tipo de Mensaje Realizaremos ahora este proceso en forma específica para nuestro ejemplo. Síganme los buenos 41 Rol de Aplicación (sender) Roles Roles de de Aplicación: define define la la responsabilidad de de las las aplicaciones SENDER y RECEIVER

22 Rol de Aplicación (receiver) Roles Roles de de Aplicación: define define la la responsabilidad de de las las aplicaciones SENDER y RECEIVER 43 Definir los artefactos aplicables Aplicaremos ahora este conocimiento para formalizar nuestro ejemplo, recorriendo las tres capas de transmisión y las responsabilidades de las aplicaciones

23 Definir los artefactos aplicables DESCRIPCION COMPONENTE NOMBRE MODELO R-MIM VISTA TABULAR SCHEMA Interacción PRPA_IN Emergency Encounter Activate Notification Evento Disparador: PRPA_TE Emergency Encounter Started Capa de Mensajería: MCCI_MT Send Message Payload MCCI_RM MCCI_HD MCCI_RM Capa de Control de Actos MCAI_MT Trigger Event Control Act MCAI_MT MCAI_HD MCAI_MT Capa de Mensaje: PRPA_MT Active Emergency Encounter PRPA_RM PRPA_RM PRPA_RM Rol de Aplicación que Envía PRPA_AR Emergency Encounter Comprehensive Informer Rol de Aplicación que Recibe PRPA_AR Emergency Encounter Comprehensive Tracker Cambio de Estado null to "active" EncounterEvent Ver excel Ejercicio Admisión - Componentes Utilizados.xls 45 Que esquemas debo usar? Hemos visto tres esquemas referenciados (o más) por cada mensaje, para cada capa. Pero HL7 nos ofrece un único esquema con el cual podemos crear y validar nuestros mensajes: 46 23

24 Validando en Oxygen Este procedimiento debe repetirse para las otras capas: Es importante que esté dentro de la estructura de la versión 3 hace referencia a muchos otros esquemas. Se pueden extraer los necesarios. Exploremos un poco en el Oxygen Los XSD de cada capa: MCCI_MT000100UV01.xsd (capa mensajería). MCAI_MT700201UV01.xsd (capa control de acto). PRPA_MT xsd (el payload o contenido). Y los xsd de los CMET s referenciados por cada una de ellas (veamos). El payload por mencionar uno tiene 12 CMET s, varios de ellos con sus propios CMET s internos! Infrastructureroot.xsd, que incluye: Voc.xsd con el vocabulario codificado de HL7 v3. Datatype.xsd con los tipos de datos compuestos de HL7 v3. Que incluye datatypes-base.xsd con los tipos de datos básicos de HL7 v3. NarrativeBlock.xsd con la estructura general de bloques narrativos (CDA). Mucho esfuerzo como ven, y muy complejo por esto el problema de que muchas aplicaciones se ahogan con los esquemas de v3! Mensaje HL7 v3 Mensaje HL7 v3 HL7 Transmission Wrapper Trigger Event Control Act Wrapper HL7 Domain Content El contenido propio del mensaje, conocido como payload. 47 Capa de Mensajería id: identificador único del mensaje MSH-10 creationtime: Fecha de creación MSH-7 responsemodecode: Tiempo en el cual se espera la respuesta interactionid: Identificador de la interacción MSH-9 processingcode: Código de procesamiento MSH-11/1 processingmodecode: Código de Modo de Procesamiento MSH/2 acceptackcode: Codigo de aceptación NE=Nunca/ER=Solo errores MSH-15 receiver: Datos del Receptor del Mensaje sender: Datos de la aplicación que envía el mensaje 48 24

25 Capa de Control de Actos id: Identificador del Acto, en este caso nro. de encuentro, episodio o historia clínica. code: Código del Evento Disparador. authororperformer: Autor del Acto. dataenterer: Quien ingresó los datos. 49 Payload id: Id del encuentro. code: Tipo del Encuentro. statuscode : ACTIVO (ver diagrama de estados). effectivetime: Fecha de Comienzo / Fin. PriorityCode: Emergencia. confidentialitycode: Confidencialidad. subject/patient: Datos personales del paciente atendido. id: Identificación del paciente en archivo de pacientes CENAP. addr: Domicilio del paciente

26 Payload person/id:identificacion del paciente en archivo de personas nacional /regional name: Apellido y nombres del paciente administrativegendercode: Genero o Sexo birthdate: Fecha de Nacimiento responsibleparty: Organización que se hace cargo del paciente durante el transcurso del encuentro Admitter : Medico responsable del encuentro, debe coincidir con AuthorPerformer de ActControlProcess notificationcontact:familiar a cargo (next of kin) location : Lugar fisico donde se realiza el encuentro reason : Diagnostico de admision 51 Vocabulario Para nuestro ejemplo, los requerimientos de vocabulario son sencillos: Vocabulario estructural HL7 (voc.xsd). Vocabulario HL7 (códigos simples, ejemplo Sexo ). Vocabulario para el diagnostico de admisión (ICD9, Codigos V, SNOMED, etc.)

27 Identificadores Ver oid s y tablas en Excel Identificadores Escenario.xls. Básicamente: OID s para responsables de tablas. Organizaciones. personal medico y no medico. pacientes (locales). Ubicaciones. personas (regionales o nacionales). aplicaciones y dispositivos. 53 Para terminar Para terminar con el tema de admisión, una breve reseña del dominio de admisión de pacientes completo, tópico por tópico. Los dividiremos en tres áreas: Sujetos Participantes Encuentros Ver DMIM de dominio en archivo DMIM Patient Administration. Tienen ustedes impreso del RMIM de Emergency Encounter

28 Reseña del dominio adm. de pacientes Sujetos Person, registro de personas: activar, revisar, anular, resolver duplicados, consultas (demográficos, candidatos, identificadores asociados), agregar persona, revisar persona. PatientLivingSubject, registry de pacientes (sean personas o no): activar, revisar, anular. Resolver duplicados. 55 Reseña del dominio adm. de pacientes Participantes y Asociaciones: Attending Practitioner: Definir el profesional a cargo del paciente (agregar, borrar, revisar). Encounter Location: Definir la ubicación física asignada a un paciente actual o futura. Encounter Organization: Definir el prestador de salud a cargo del paciente. Service Delivery Location: Notificaciónes de cambios en archivos maestros para lugares donde se prestan servicios de salud

29 Reseña del dominio adm. de pacientes Encuentros. Ambulatory Encounter: encuentro ambulatorio, con intención y evento. Estadía programada menor de 24 horas, pero no emergencia. Short Stay Encounter: encuentro para tratamiento, de tiempo definido, generalmente menor a 24 horas, intención y evento. Inpatient Encounter: encuentro de internación con cuidado por enfermeras en una habitación fija por un tiempo prolongado, intención y evento. Emergency Encounter: encuentro de emergencia. No hay intención, solo evento. Home Health Encounter: el encuentro se produce en el domicilio del paciente. Intención y evento. 57 Parte 2 Resultados de laboratorio con mensajes v3 SISTEMA DE LABORATORIO SILAB MENSAJE DE RESULTADOS v3 SISTEMA PUNTO DE ASISTENCIA CENAP En este caso, espero más ayuda de parte vuestra! 58 29

30 Metodología 1. Entender los requerimientos de interoperabilidad 2. Definir para cada caso el estándar aplicable y los artefactos (mensajes, llamadas, documentos) requeridos 3. Trabajar el vocabulario y los identificadores 4. Especificar el entorno de comunicaciones 5. Determinar el movimiento de datos a artefacto y viceversa. 6. Construir/Documentar la interface 59 Entender los requerimientos Para el escenario simplificado del mensaje de resultados, lo único que se requiere es enviar los resultados de laboratorio al servicio de urgencias en el momento en que se validan los resultados

31 Definir estándar y artefactos aplicables Aquí es más difícil optar entre Mensajes v3 y CDA, ya que el reporte final de laboratorio es también un buen candidato a ser expresado como documento CDA (lleva firma digital, puede ser almacenado en forma permanente, etc., características que veremos son parte de un mensaje CDA). Lo expresaremos como mensaje v3 (el envío de resultados de laboratorio es un uso clásico de mensajería HL7) De todas maneras, veremos mañana también un ejemplo de reporte de laboratorio como documento CDA. 61 Definir los artefactos aplicables Resulta entonces, que queremos enviar un mensaje v3 al Centro de Atención Primaria cada vez que se valida un resultado en el laboratorio. Ahora bien, Qué mensaje v3? 62 31

32 Qué mensaje v3? En busca del escenario... Vemos que el tópico Result no tiene storyboards... Seleccionamos el el tópico Interactions without Receiver Responsability del del dominio Laboratory de de la la carpeta Health and and Clinical Management. 63 Qué mensaje v3? Revisemos los los escenarios presentados

33 Qué mensaje v3? Los escenarios son mucho más complejos comparados con nuestro requerimiento, en general incluyen: Activar Orden Analítica (placer). Activar Promesa de Respuesta (filler). Extracción o recolección de la(s) muestra(s) (filler). Envío de Resultado Final (filler). Confirmación de respuesta de resultado final (placer). Otras variantes (corrección de resultados, múltiples muestras, valores pánico, reflex testing, derivaciones a laboratorios de referencia, microbiología, etc.) El El adecuado parece ser ser Placer Order and andresults 65 Qué mensaje v3? Revisamos el el escenario leyendo su su descripción 66 33

34 Qué mensaje v3? Cual Cual interacción creen que que debemos escoger? Seleccionamos la la interacción: POLB_IN Qué mensaje v3? La interacción nos define: Evento Disparador. Capa de Transmisión. Capa de Control de Actos. Tipo de Mensaje. Roles de Aplicación

35 Evento Disparador Información incluida: Código de Evento (POLB_TE004200), se envía en el Control Act Wrapper. Referencia al equivalente en v2: el evento OML^021. Transición de Estados: de null a Completado o de Activo a Completado 69 Capas Transmisión / Control de Acto Se mantienen las mismas que en el caso de admisión. Esto es así porque esta interacción es sin responsabilidades del receptor no existe ACK. Si hubiéramos seleccionado with R/R, cambian ambos wrappers y se solicita una respuesta de aplicación del receptor (no de aceptación). Veamos un ejemplo 70 35

36 Roles de Aplicación Responsabilidades del del receptor y del del emisor 71 Definir los artefactos aplicables DESCRIPCION COMPONENTE NOMBRE MODELO R-MIM VISTA TABULAR SCHEMA Interacción POLB_IN Result complete w/o RR Evento Disparador: POLB_TE Result complete Capa de Mensajería: MCCI_MT Send Message Payload MCCI_RM MCCI_HD MCCI_RM Capa de Control de Actos MCAI_MT Trigger Event Control Act MCAI_MT MCAI_HD MCAI_MT Capa de Mensaje: POLB_MT00400 Result Event PRPA_RM PRPA_RM PRPA_RM Rol de Aplicación que Envía POLB_AR02000 Order Fulfiller Rol de Aplicación que Recibe POLB_AR03400 Result Receiver Rol de Aplicación que Recibe POLB_AR Order Placer Cambio de Estado null to "complete" Observation Event Choice No No analizaremos en en este este caso el el Trigger Event Control Act Act (se (se agregó solamente informationrecipient ) y el el Send Message Payload, por por ser ser similares al al de de admisión

37 Tipo de Mensaje Descripción de de la la clase de de mensaje requerida. 73 Tipo de Mensaje En cuanto al tipo de mensaje, es de los más complejos. Con el RMIM en la mano, analicemos primero a grandes rasgos qué información incluye: Datos del paciente. Datos de la orden. Datos de la muestra. Datos de resultado(s). CHOICE: Seleccionar qué quétipo de de mensaje de de resultados vamos a enviar En En nuestro caso, observationbattery 74 37

38 Payload - Header General al payload: id: Id de la observación (número interno dado por el laboratorio a la petición recibida). code: Código LOINC de la batería. statuscode : COMPLETO (ver diagrama de estados). effectivetime: Fecha de Comienzo / Fin. PriorityCode: Emergencia. confidentialitycode: Confidencialidad normal. 75 Payload - Muestra subject: datos de la muestra specimen: identificador de la muestra specimennatural: code = Tipo de Muestra (suero, sangre, orina, etc.). ascontent asidentifiedentity: código de barras que identifica al tubo en el que está la muestra. aslocatedentity: ubicación y fecha de la muestra. additive: aditivos de la muestra en el tubo

39 Payload Identificación de Paciente recordtarget / patientclinical, datos del paciente: id: Identificación del paciente en archivo de pacientes CENAP /SILAB. addr: Domicilio del paciente. telecom: Teléfono del paciente. patientperson, datos personales: id: Identificación en RENAP. name: apellidos y nombres. administrativegender: sexo. birthtime: fecha de nacimiento. 77 Payload Cobertura de Salud ascoveredparty: cobertura o aseguradora de salud (seguro nacional de salud o mutua): id: Número de carnet. statuscode: situación. policyoraccount/id: id de plan de salud. effectivetime: vigencia. author / carrierrole / id-name: mutua o aseguradora de salud

40 Payload - Responsabilidades author: analizador o persona que realizo las pruebas. dataenterer: dispositivo o persona que ingresó los resultados. verifier: persona que validó o verificó los resultados. 79 Payload Orden o Petición Médica infulfillmentof / observationrequest: id: identificación de la orden o petición en el sistema que originó la petición. code: código de batería o prueba solicitada confidentialitycode: nivel de confidencialidad. author: identificación del profesional solicitante

41 Payload - Encuentro Puede asociarse la observación con un encuentro componentof Encounter Id: Identificación del encuentro subject: patient: id: Identificación del paciente 81 Payload : Resultados ( POR FIN!) Component2: batería) ObservationEvent id: identificación. code: código LOINC. (1 por cada resultado de la effectivetime: hora de la observación. value: aquí va el valor de la observación. methodcode: el código del método analítico. subject: la muestra. referencerange: el rango de valores normales y su interpretación para este caso

42 Mensaje completo Vemos el mensaje completo de laboratorio... mensaje_laboratorio_in.xml 83 Vocabulario Para nuestro ejemplo, los requerimientos de vocabulario son: Vocabulario estructural HL7 (voc.xsd). Vocabulario HL7 (códigos simples, ejemplo Sexo ). Vocabulario para solicitar baterías o servicios: LOINC, CPT, etc. Vocabulario para los resultados de las pruebas: LOINC, etc

43 Identificadores Ver oid s y tablas en Excel Identificadores Escenario.xls (los mismos que antes ) Básicamente: OID s para responsables de tablas. Organizaciones. personal medico y no medico. pacientes (locales). Ubicaciones. personas (regionales o nacionales). aplicaciones y dispositivos. 85 Identificadores Pero además, aparecen otros no en nuestras tablas: Personas (regionales o nacionales). Aplicaciones y dispositivos. Muestras. Ordenes. Resultados. Analizadores

44 Pasos de Implementación (1) Para implementar, se sugieren estos pasos generales: 1. Comprender los requerimientos de interoperabilidad de la situación especifica. Quienes están involucrados, que información intercambian, cuando, contenido de los intercambios, respuestas esperadas. 2. Definir los mensajes a ser usados (mediante los pasos que hemos visto hoy). 3. Definir el vocabulario a utilizar. Puede ser expandido en el futuro, no se tiene que considerar todo ahora. En muchos casos tendremos un vocabulario interno paralelo a otra codificación general. 4. Especificar el medio de comunicación. Por debajo del nivel 7, podemos aplicar experiencia de v2. Hay que considerar seguridad, garantía de envío, logging, etc. El uso de web services ha sido preferido. 87 Pasos de Implementación (2) 5. Diseñar el movimiento de datos desde arquitectura interna hasta los mensajes escogidos. Es probablemente la etapa más compleja, costosa y con posibilidad de errores (junto con construcción). El mapeo es extenso. Están surgiendo herramientas, similares a las que yá existen para v3. Si es un sistema nuevo, es beneficioso basar diseño de BBDD en el RIM (ya existen varios así. 6. Construir el interfaz. Existe información de experiencias que han tenido países o organizaciones, y herramientas comunes de fuente abierta como el HL7 SDK. Escoger buenas herramientas de XML (esquemas complejos). La formación del equipo en XML avanzado es esencial. HL7 no recomienda ninguna plataforma, pero java se ha usado mucho. 7. Documentar la implementación y su conformidad

45 Pasos de Implementación (3) 7. Documentar la implementación y su conformidad. Para indicar como se está usando HL7 v3: Partes de los RMIM s que no estamos usando. Decisiones acerca de asociaciones y atributos opcionales. Valores usados en los dominios de vocabularios definidos. OID s utilizados y asignados. Simplificaciones de los tipos de datos. Estructuras agregadas al modelo oficial. Decisiones de seguridad y transporte. Para indicar como está realizada nuestra implementación: Mapeo realizado entre campos internos y atributos en los mensajes. Herramientas usadas, métodos para captación y procesamiento de mensajes, etc. Así los programadores (por lo general) lo odiemos, mientras más formalizado, será mejor al final. Adoptar una metodología y seguirla. 89 Conclusiones Mensajería v3: no es una tarea sencilla. Pero la experiencia global es que en implementaciones grandes, se justifica. Estrategia: APRENDER a leer los R-MIM. CONOCER los tipos de datos. LEER los HMD (narrativa y visión tabular). ARMAR la tabla de artefactos requeridos y usarla como referencia. Contar con un buen editor de XML. DEFINIR identificadores/vocabulario según el entorno global (mapear lo local)

46 Preguntas? Juan Miguel Venturello HL7Spain 91 46