Taller de Interoperabilidad HL7 v3/CDA DIA 2dns.uls.cl/~ej/web_Elect_2012/Lect_Elect_2010/compil...Taller de Interoperabilidad HL7 v3/CDA – Madrid – España – Noviembre 2005
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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.
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
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
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
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.
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
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’.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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’.
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
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.
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
¿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.
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
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.
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
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).
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
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...
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
Definir los artefactos aplicables
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
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
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:
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
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!
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
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
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
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
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
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.
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
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.
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
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.
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
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.
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
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.
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
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?
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
¿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.)
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
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
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
Definir los artefactos aplicables
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
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
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
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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).