Taller de Interoperabilidad HL7 v3/CDA DIA...

Taller de Interoperabilidad HL7 V3/CDA

© HL7 Spain, 2005 1

© HL7 Spain, 2005 1

Taller de Interoperabilidad HL7 v3/CDA

DIA 2

Agradecimiento especial a Diego Kaminker, HL7 Argentina,

[email protected]

Juan Miguel VenturelloHL7Spain

[email protected]

© HL7 Spain, 20052

Taller de Interoperabilidad HL7 v3/CDA – Madrid – España – Noviembre 2005Taller de Interoperabilidad HL7 v3/CDA – Madrid – España – Noviembre 2005

S P A I NS P A I N

Agenda

DIA 1Presentación del TallerIntroducción HL7 versión 3Fundamentos de la versión 3 de HL7Arquitectura de Mensajes y Documentos

DIA 2Admisión de un paciente con mensajes v3Resultados de laboratorio con mensajes v3

DIA 3Introducción CDAInforme de alta con un documento CDAHoja de ruta para implantar HL7 v3 & CDA


© HL7 Spain, 2005 2

© HL7 Spain, 20053


S P A I NS P A I N

Recursos DocumentalesEn 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.

© HL7 Spain, 20054


S P A I NS P A I N

Herramientas

Para explorar documentos XML:SyncRO Soft’s Oxygen XML 6.2

http://www.oxygenxml.com/

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.http://www.altova.com/products_ide.html


© HL7 Spain, 2005 3

© HL7 Spain, 20055


S P A I NS P A I N

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

© HL7 Spain, 20056


S P A I NS P A I N

Escenario de Interoperabilidad

CENAP

HOCEM

SILAB

SIMAG

AUSAN


© HL7 Spain, 2005 4

© HL7 Spain, 20057


S P A I NS P A I N

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 asistenciaHOCEN: Hospital de referenciaSILAB: Laboratorio clinicoSIMAG: Diagnostico por imágenesAUSAN: Autoridad sanitaria

© HL7 Spain, 20058


S P A I NS P A I N

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 ‘HealthCare Community Network’.


© HL7 Spain, 2005 5

© HL7 Spain, 20059


S P A I NS P A I N

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.

© HL7 Spain, 200510


S P A I NS P A I N

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.


© HL7 Spain, 2005 6

© HL7 Spain, 200511


S P A I NS P A I N

Escenario (visión simplificada)

En fondo azul, los mensajes que exploraremos a fondo.

En fondo azul, los mensajes que exploraremos a fondo.

MENSAJE DEADMISION v3

MENSAJE ORDENANALITICA v3

MENSAJE DERESULTADOS v3

MENSAJE DERESULTADOS v3

INFO

RM

EAT

ENC

ION

CD

A

INFORMEATENCION CDA

SISTEMA DELABORATORIO

SILAB

SISTEMAPUNTO DE

ASISTENCIACENAP

SISTEMA DERADIOLOGIA

SIMAG

SISTEMAADMISIONHOSPITAL

HOCEN

SISTEMACONTROL

INFECCIONESAUSAN

© HL7 Spain, 200512


S P A I NS P A I N

Vista del Esquema Implantado


© HL7 Spain, 2005 7

© HL7 Spain, 200513


S P A I NS P A I N

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 pacienteCENAP SIMAG

Mensaje v3 de resultados de laboratorioSILAB CENAP

Documento CDA R2 de altaHOCEN AUSAN

© HL7 Spain, 200514


S P A I NS P A I N

¿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

EscenarioEscenario

Caso deUso

Caso deUso

Rol deAplicación

Rol deAplicación

EventoActivadorEvento

Activador

InteracciónInteracción

RIMRIM

D-MIMD-MIM

R-MIMR-MIM

HMDHMD

MensajeMensaje

Especifica

Emisor Receptor

Activa

Instancia

Contiene

Define

Define

DefineEs formalizado


© HL7 Spain, 2005 8

© HL7 Spain, 200515


S P A I NS P A I N

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.

© HL7 Spain, 200516


S P A I NS P A I N

Parte 1

Admisión de un paciente con mensajes v3

MENSAJE DEADMISION v3

SISTEMAPUNTO DE

ASISTENCIACENAP

SISTEMA DERADIOLOGIA

SIMAG


© HL7 Spain, 2005 9

© HL7 Spain, 200517


S P A I NS P A I N

Metodología1. 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.

© HL7 Spain, 200518


S P A I NS P A I N

Entender los RequerimientosPara 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.


© HL7 Spain, 2005 10

© HL7 Spain, 200519


S P A I NS P A I N

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 CDASi no usáramos HL7, podríamos haber utilizado un webservice con un contenido definido por nosotros, un file transfer igualmente con contenido definido, una llamada a RPC, etc.

© HL7 Spain, 200520


S P A I NS P A I N

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 v3’.



© HL7 Spain, 2005 11

© HL7 Spain, 200521


S P A I NS P A I N

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.


© HL7 Spain, 200522


S P A I NS P A I N

¿Qué mensaje v3?

Los dominios clínicos y administrativos están en la carpeta Domains del estándar.

Los dominios clínicos y administrativos están en la carpeta Domains del estándar.

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.


© HL7 Spain, 2005 12

© HL7 Spain, 200523


S P A I NS P A I N

¿Qué mensaje v3?

Seleccionamos el tópico ‘Emergency Encounter’ del dominio ‘Patient Administration’de la carpeta ‘AdministrativeManagement’

Seleccionamos el tópico ‘Emergency Encounter’ del dominio ‘Patient Administration’de la carpeta ‘AdministrativeManagement’

© HL7 Spain, 200524


S P A I NS P A I N

¿Qué mensaje v3?

Ahora veamos si el escenario coincide con el nuestro... Leemos la descripción.


© HL7 Spain, 2005 13

© HL7 Spain, 200525


S P A I NS P A I N

Storyboard

Buscamos entre los Storyboards disponibles y seleccionamos el escenario para ‘EmergencyEncounter’. Será este el correcto?

Pequeña digresión: Como se forma código en los nombre? De que váesto?

Ej. PRPA_ST403001

© HL7 Spain, 200526


S P A I NS P A I N

Cómo se forma el nombre de un artefacto?Subsección Dominio Descripción DetallePO POLB Operaciones LaboratorioPO PORX Operaciones FarmaciaRC RCMR Registros Registros médicosPR PRPA Práctica Administración de PacientesPR PRSC Práctica TurnosPR PRPM Práctica Manejo de PersonalFI FICR Financiero Pagos y reembolsosFI FIAB Financiero Cuentas y facturaciónMC MCCI Control de Mensajes Infraestructura de control de mensajesMC MCAI Control de Mensajes Infraestructura de mensajes de actosMF MFMI Archivos maestros Gestión de archivos maestrosQU QUQI Consultas Infraestructura de consultasCO COMT Contenido común Elementos comunes (CMETs)

PRPA _ST 403001 UV 00

Tipo de Artefacto CODIGORol de aplicación ARD-MIM (Modelo de información de dominio) DMHMD (Descriptor jerárquico de mensaje) HDInteracción INTipo de Mensaje MTR-MIM (Modelo de información refinado de mensaje) RMEscenario STNarrativa de escenario SNEvento disparador TE

Identificador único de seis dígitos asignado por TC

Realm (por ahora solo existe UV=Universal)

Versión – número de ballot

Con el tiempo usando el estándar, aprende uno de memoria los tipos de artefacto y la sección y dominio – y esto es de gran ayuda.

Con el tiempo usando el estándar, aprende uno de memoria los tipos de artefacto y la sección y dominio – y esto es de gran ayuda.


© HL7 Spain, 2005 14

© HL7 Spain, 200527


S P A I NS P A I N

StoryboardPrimero 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…

© HL7 Spain, 200528


S P A I NS P A I N

Storyboard

Narrativa del escenarioExplica 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.

Ya que esta es la interacción que necesitamos, exploramos su contenido...

Ya que esta es la interacción que necesitamos, exploramos su contenido...


© HL7 Spain, 2005 15

© HL7 Spain, 200529


S P A I NS P A I N

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.

© HL7 Spain, 200530


S P A I NS P A I N

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).


© HL7 Spain, 2005 16

© HL7 Spain, 200531


S P A I NS P A I N

Diagrama de Estados

El cambio de estado inicial es de NULO a ACTIVO…

El cambio de estado inicial es de NULO a ACTIVO…

© HL7 Spain, 200532


S P A I NS P A I N

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.


© HL7 Spain, 2005 17

© HL7 Spain, 200533


S P A I NS P A I N

Capa de Transmisión

Descripción del Mensaje Base

Descripción del Tipo de

MensajeEl mensaje base sirve como definición de variostipos de mensaje que restringen la definición – se usan para distintos eventos (esto se aplica a las tres capas).

Ver R-MIM del Mensaje Base

Ver R-MIM del Mensaje Base

Ver en Modo Tabla

Ver en Modo Tabla

Ver en Modo Excel

Ver en Modo Excel

Ver en Modo Tabla

Ver en Modo Tabla

Ver SchemaXML

Ver SchemaXML

Ver Interacciones

Ver Interacciones

Listado de CMETsutilizados

Listado de CMETsutilizados

© HL7 Spain, 200534


S P A I NS P A I N

Mensaje base: CMET’s utilizadosDocumentación y modelo de los CMET’s utilizados en el mensaje.

Documentación y modelo de los CMET’s utilizados en el mensaje.


© HL7 Spain, 2005 18

© HL7 Spain, 200535


S P A I NS P A I N

Mensaje Base: Descripción del R-MIM

Detalle del R-MIM para esta capa, realiza un ‘walk-through’: explica uno por uno los elementos requeridos.

Detalle del R-MIM para esta capa, realiza un ‘walk-through’: explica uno por uno los elementos requeridos.

Vinculo al gráficoVinculo al gráfico

© HL7 Spain, 200536


S P A I NS P A I N

Mensaje Base Gráfico del R-MIM

Es el momento de ver el mensaje, para comparar con el RMIM. Abramos mensaje_admision_IN.xml en el Oxygen…

Es el momento de ver el mensaje, para comparar con el RMIM. Abramos mensaje_admision_IN.xml en el Oxygen…


© HL7 Spain, 2005 19

© HL7 Spain, 200537


S P A I NS P A I N

Mensaje Base: Visión Tabular

© HL7 Spain, 200538


S P A I NS P A I N

Mensaje Base: Visión en Excel


© HL7 Spain, 2005 20

© HL7 Spain, 200539


S P A I NS P A I N

Tipo de Mensaje: Ver Schema XML

Schema: la definición del Schema XML para esta capa

Schema: la definición del Schema XML para esta capa

© HL7 Spain, 200540


S P A I NS P A I N

Tipo de Mensaje: Visión Tabular

Es un refinamiento de la definición jerárquica del mensaje

Es un refinamiento de la definición jerárquica del mensaje


© HL7 Spain, 2005 21

© HL7 Spain, 200541


S P A I NS P A I N

Control de Actos / Tipo de Mensaje

Este procedimiento debe repetirse para las otras capas:

Control de ActosTipo de Mensaje

Realizaremos ahora este proceso en forma específica para nuestro ejemplo.

Síganme los buenos…

© HL7 Spain, 200542


S P A I NS P A I N

Rol de Aplicación (sender)

Roles de Aplicación: define la responsabilidad de las aplicaciones SENDER y RECEIVER.

Roles de Aplicación: define la responsabilidad de las aplicaciones SENDER y RECEIVER.


© HL7 Spain, 2005 22

© HL7 Spain, 200543


S P A I NS P A I N

Rol de Aplicación (receiver)

Roles de Aplicación: define la responsabilidad de las aplicaciones SENDER y RECEIVER

Roles de Aplicación: define la responsabilidad de las aplicaciones SENDER y RECEIVER

© HL7 Spain, 200544


S P A I NS P A I N

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...


© HL7 Spain, 2005 23

© HL7 Spain, 200545


S P A I NS P A I N


Ver excel ‘Ejercicio Admisión - Componentes Utilizados.xls’

DESCRIPCION COMPONENTE NOMBRE MODELO R-MIM VISTA TABULAR SCHEMAInteracción PRPA_IN403001 Emergency Encounter Activate NotificationEvento Disparador: PRPA_TE403001 Emergency Encounter StartedCapa de Mensajería: MCCI_MT002100 Send Message Payload MCCI_RM002100 MCCI_HD002100 MCCI_RM002100Capa de Control de Actos MCAI_MT700201 Trigger Event Control Act MCAI_MT700201 MCAI_HD7000200 MCAI_MT700201Capa de Mensaje: PRPA_MT403001 Active Emergency Encounter PRPA_RM403001 PRPA_RM403001 PRPA_RM403001Rol de Aplicación que Envía PRPA_AR403001 Emergency Encounter Comprehensive InformerRol de Aplicación que Recibe PRPA_AR403002 Emergency Encounter Comprehensive TrackerCambio de Estado null to "active" EncounterEvent

© HL7 Spain, 200546


S P A I NS P A I N

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:


© HL7 Spain, 2005 24

© HL7 Spain, 200547


S P A I NS P A I N

Validando en OxygenEste 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_MT403001.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 v3Mensaje HL7 v3

HL7 TransmissionWrapper

Trigger EventControl ActWrapper

HL7 DomainContent

El contenido propio del mensaje,

conocido como ‘payload’.

© HL7 Spain, 200548


S P A I NS P A I N

Capa de Mensajeríaid: identificador único del mensaje MSH-10 creationTime: Fecha de creación MSH-7 responseModeCode: Tiempo en el cual se espera la

respuestainteractionId: Identificador de la interacción MSH-9 processingCode: Código de procesamiento MSH-11/1processingModeCode: Código de Modo de

Procesamiento MSH/2acceptAckCode: Codigo de aceptación

NE=Nunca/ER=Solo errores MSH-15receiver: Datos del Receptor del Mensajesender: Datos de la aplicación que envía el mensaje


© HL7 Spain, 2005 25

© HL7 Spain, 200549


S P A I NS P A I N

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.

© HL7 Spain, 200550


S P A I NS P A I N

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.


© HL7 Spain, 2005 26

© HL7 Spain, 200551


S P A I NS P A I N

Payload

person/id:Identificacion del paciente en archivo de personas nacional /regionalname: 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 encuentroAdmitter : Medico responsable del encuentro, debe coincidir con AuthorPerformer de ActControlProcessnotificationContact:Familiar a cargo (next of kin) location : Lugar fisico donde se realiza el encuentro reason : Diagnostico de admision

© HL7 Spain, 200552


S P A I NS P A I N

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.).


© HL7 Spain, 2005 27

© HL7 Spain, 200553


S P A I NS P A I N

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.

© HL7 Spain, 200554


S P A I NS P A I N

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:SujetosParticipantesEncuentros

Ver DMIM de dominio en archivo ‘DMIM PatientAdministration´.

Tienen ustedes impreso del RMIM de EmergencyEncounter.


© HL7 Spain, 2005 28

© HL7 Spain, 200555


S P A I NS P A I N

Reseña del dominio adm. de pacientes

SujetosPerson, 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.

© HL7 Spain, 200556


S P A I NS P A I N


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.


© HL7 Spain, 2005 29

© HL7 Spain, 200557


S P A I NS P A I N


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.

© HL7 Spain, 200558


S P A I NS P A I N

Parte 2

Resultados de laboratorio con mensajes v3

MENSAJE DERESULTADOS v3SISTEMA DE

LABORATORIOSILAB

SISTEMAPUNTO DE

ASISTENCIACENAP

En este caso, espero más ayuda de parte vuestra!


© HL7 Spain, 2005 30

© HL7 Spain, 200559


S P A I NS P A I N

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 identificadores4. Especificar el entorno de comunicaciones5. Determinar el movimiento de datos a artefacto

y viceversa.6. Construir/Documentar la interface

© HL7 Spain, 200560


S P A I NS P A I N

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.


© HL7 Spain, 2005 31

© HL7 Spain, 200561


S P A I NS P A I N

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.

© HL7 Spain, 200562


S P A I NS P A I N


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?


© HL7 Spain, 2005 32

© HL7 Spain, 200563


S P A I NS P A I N

¿Qué mensaje v3?

Seleccionamos el tópico ‘Interactions withoutReceiver Responsability’del dominio ‘Laboratory’de la carpeta ‘Health andClinical Management’.

Seleccionamos el tópico ‘Interactions withoutReceiver Responsability’del dominio ‘Laboratory’de la carpeta ‘Health andClinical Management’.

En busca del escenario...

Vemos que el tópico ‘Result’ no tiene storyboards...

© HL7 Spain, 200564


S P A I NS P A I N

¿Qué mensaje v3?

Revisemos los escenarios presentados...

Revisemos los escenarios presentados...


© HL7 Spain, 2005 33

© HL7 Spain, 200565


S P A I NS P A I N

¿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 adecuado parece ser Placer Order and Results

El adecuado parece ser Placer Order and Results

© HL7 Spain, 200566


S P A I NS P A I N

¿Qué mensaje v3?

Revisamos el escenario leyendo su descripción…

Revisamos el escenario leyendo su descripción…


© HL7 Spain, 2005 34

© HL7 Spain, 200567


S P A I NS P A I N

¿Qué mensaje v3?

Seleccionamos la interacción: POLB_IN224200

Seleccionamos la interacción: POLB_IN224200

Cual interacción creen que debemos escoger?

Cual interacción creen que debemos escoger?

© HL7 Spain, 200568


S P A I NS P A I N

¿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.


© HL7 Spain, 2005 35

© HL7 Spain, 200569


S P A I NS P A I N

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

© HL7 Spain, 200570


S P A I NS P A I N

Capas Transmisión / Control de ActoSe 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…


© HL7 Spain, 2005 36

© HL7 Spain, 200571


S P A I NS P A I N

Roles de Aplicación

Responsabilidades del receptor y del emisor

Responsabilidades del receptor y del emisor

© HL7 Spain, 200572


S P A I NS P A I N


No analizaremos en este caso el Trigger EventControl Act (se agregó solamente ‘informationRecipient’) y el Send Message Payload, por ser similares al de admisión.

No analizaremos en este caso el Trigger EventControl Act (se agregó solamente ‘informationRecipient’) y el Send Message Payload, por ser similares al de admisión.

DESCRIPCION COMPONENTE NOMBRE MODELO R-MIM VISTA TABULAR SCHEMAInteracción POLB_IN224200 Result complete w/o RREvento Disparador: POLB_TE004200 Result completeCapa de Mensajería: MCCI_MT002100 Send Message Payload MCCI_RM002100 MCCI_HD002100 MCCI_RM002100Capa de Control de Actos MCAI_MT700201 Trigger Event Control Act MCAI_MT700201 MCAI_HD7000200 MCAI_MT700201Capa de Mensaje: POLB_MT00400 Result Event PRPA_RM403001 PRPA_RM403001 PRPA_RM403001Rol de Aplicación que Envía POLB_AR02000 Order FulfillerRol de Aplicación que Recibe POLB_AR03400 Result ReceiverRol de Aplicación que Recibe POLB_AR010000 Order PlacerCambio de Estado null to "complete" Observation Event Choice


© HL7 Spain, 2005 37

© HL7 Spain, 200573


S P A I NS P A I N

Tipo de Mensaje

Descripción de la clase de mensaje requerida.

Descripción de la clase de mensaje requerida.

© HL7 Spain, 200574


S P A I NS P A I N

Tipo de MensajeEn 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é tipo de mensaje de resultados vamos a enviar

En nuestro caso, observationBattery

CHOICE:

Seleccionar qué tipo de mensaje de resultados vamos a enviar

En nuestro caso, observationBattery


© HL7 Spain, 2005 38

© HL7 Spain, 200575


S P A I NS P A I N

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.

© HL7 Spain, 200576


S P A I NS P A I N

Payload - Muestra

subject: datos de la muestraspecimen: identificador de la muestraspecimenNatural: 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.


© HL7 Spain, 2005 39

© HL7 Spain, 200577


S P A I NS P A I N

Payload – Identificación de PacienterecordTarget / 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.

© HL7 Spain, 200578


S P A I NS P A I N

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.


© HL7 Spain, 2005 40

© HL7 Spain, 200579


S P A I NS P A I N

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.

© HL7 Spain, 200580


S P A I NS P A I N

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 solicitadaconfidentialityCode: nivel de confidencialidad.author: identificación del profesional solicitante.


© HL7 Spain, 2005 41

© HL7 Spain, 200581


S P A I NS P A I N

Payload - Encuentro

Puede asociarse la observación con un encuentro

componentOfEncounter

Id: Identificación del encuentrosubject:

patient: id: Identificación del paciente

© HL7 Spain, 200582


S P A I NS P A I N

Payload : Resultados (¡POR FIN!)

Component2: (1 por cada resultado de la batería)

ObservationEventid: identificación.code: código LOINC.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.


© HL7 Spain, 2005 42

© HL7 Spain, 200583


S P A I NS P A I N

Mensaje completo

Vemos el mensaje completo de laboratorio...mensaje_laboratorio_IN.xml

© HL7 Spain, 200584


S P A I NS P A I N

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.


© HL7 Spain, 2005 43

© HL7 Spain, 200585


S P A I NS P A I N

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.

© HL7 Spain, 200586


S P A I NS P A I N

Identificadores

Pero además, aparecen otros no en ‘nuestras’ tablas:

Personas (regionales o nacionales).Aplicaciones y dispositivos.Muestras.Ordenes.Resultados.Analizadores.


© HL7 Spain, 2005 44

© HL7 Spain, 200587


S P A I NS P A I N

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.

© HL7 Spain, 200588


S P A I NS P A I N

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.


© HL7 Spain, 2005 45

© HL7 Spain, 200589


S P A I NS P A I N

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.

© HL7 Spain, 200590


S P A I NS P A I N

ConclusionesMensajerí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).

Taller de Interoperabilidad HL7 v3/CDA DIA...

Documents

Transcript of Taller de Interoperabilidad HL7 v3/CDA DIA...