HL7 v3.pdf

Estándar HL7

C/Marie Curie, 6 – Edificio CITICParque Tecnológico de Andalucía

29590 Campanillas (Málaga)Teléfono 952 02 86 10 – Fax 951 231 029

www.citic.es

Estándar HL7

Índice de contenidoIntroducción..........................................................................................................................................4HL7 versión 2.X...................................................................................................................................6

Mensaje abstracto HL7....................................................................................................................6Mensajes v2.X en formato XML.....................................................................................................9Modelo básico de transacciones HL7............................................................................................10

HL7 v3................................................................................................................................................12Metodología HL7 v3......................................................................................................................13Reference Information Model (RIM)............................................................................................14

Atributos y especializaciones....................................................................................................15Especificación de mensajes HL7 V3.............................................................................................17

Domain Message Information Model - DMIM.........................................................................17Refined Message Information Model - RMIM.........................................................................19Hierarchical Message Description - HMD................................................................................20Type Message - MT..................................................................................................................22Esquemas XML.........................................................................................................................23

Infraestructura de Transmisión .....................................................................................................25Transmission Wrapper...............................................................................................................26Trigger Event Control Act Wrapper..........................................................................................27

Especificaciones de Implementación.............................................................................................29Especificaciones de Transporte......................................................................................................30Artefactos.......................................................................................................................................31

Interacción.................................................................................................................................32Rol de Aplicación (Aplication Role).........................................................................................33Trigger Events...........................................................................................................................34Storyboard - Storyboard Narrative...........................................................................................34

Tipos de Datos...............................................................................................................................35Vocabulario....................................................................................................................................37

HL7 Vocabulary Domain Values...............................................................................................37Common Message Element Types - CMET's...............................................................................38

C/Marie Curie ∙ Edificio CITIC ∙ Parque Tecnológico de Andalucía 29590 ∙ Campanillas (Málaga)Tfno.: 952 028 610 ∙ Fax: 951 231 029 - www.citic.es 2

Estándar HL7

Índice de ilustracionesfig 1: Estructura de un mensaje HL7 v 2.X..........................................................................................6fig 2: Transacción HL7 v2.X..............................................................................................................11fig 3: Artefactos de HL7 v3 y los procesos asociados........................................................................13fig 4: Clases base del RIM.................................................................................................................15fig 5: RIM...........................................................................................................................................16fig 6: Proceso de refinamiento del RIM al Type Message..................................................................17fig 7: DMIM del dominio "Administración de pacientes".................................................................18fig 8: RMIM del mensaje "cambio de la localización asignada a un paciente".................................19fig 9: Segmento del HMD del mensaje "cambio de la localización asignada a un paciente"............22fig 10: Segmento del HMD (superior) y TM (inferior) del mensaje "cambio de la localización asignada a un paciente"......................................................................................................................23fig 11: Diagrama del Message Control dentro del RIM.....................................................................25fig 12: Componentes de un mensaje HL7 v3.....................................................................................26fig 13: Diagrama del DMIM del Transmission Wrapper....................................................................27fig 14: Diagrama del DMIM del Trigger Event Control Act Wrapper...............................................28fig 15: Artefactos definidos por HL7 v3.............................................................................................31fig 16: Dominios y sub-secciones definidos por HL7 v3...................................................................31fig 17: interacción "transferir al paciente a una nueva localización".................................................32fig 18: Diagrama del Rol de Aplicación para el evento "cambio de la localización de un paciente" 33fig 19: Definición del evento disparador "cambio de la localización de un paciente".......................34fig 20: Storyboard y Storyboard Narrative para el "cambio de localización de un paciente"............35fig 21: Fragmento de la tabla vocabulario para la clase Entidad........................................................38fig 22: CMET persona en el rol de paciente.......................................................................................38


Estándar HL7

Introducción

Desde los años setenta los Sistemas de Información se han ido implantando en los Sistemas de Salud a fin de reducir costes y mejorar la calidad de la atención. A pesar de algunos intentos, ningún sistema era capaz de responder a todas las necesidades y por ello se desarrollaron numerosos sistemas departamentales los cuales respondían a necesidades específicas de los diferentes servicios, llevando a la existencia de un mosaico de sistemas de información desarrollados por diferentes proveedores.

Con el tiempo las necesidades de gestión han hecho necesario la comunicación entre estos sistemas departamentales, empleándose en un principio interfaces (API's) diseñadas específicamente para cada caso. El número de interfaces (I) crece aproximadamente como la mitad del cuadrado de la cantidad de sistemas a integrar. Esto se puede representar con la siguiente fórmula:

I = (n x (n-1)) / 2

Nº de Sistemas Nº de Interfaces

2 1

4 6

6 15

8 28

10 45

Así el número de interfaces necesarias crece rápidamente con un ligero incremento de la cantidad de sistemas. No sólo se presenta el problema de la cantidad de interfaces necesarias, si se produce algún cambio en uno de los sistemas es probable la necesidad de modificar la interfaz desarrollada par el mismo.

Un enfoque para resolver este problema de interfaces múltiples es HL7, un sistema que desarrolla mensajes estandarizados (sintaxis) que viajan a través de una única interface, sin que sea necesaria la definición de mensajes específicos para cada nuevo sistema que se desee interconectar. Estos mensajes utilizan a la vez datos estandarizados (semántica), como la identificación del paciente, los datos del laboratorio, y valores definidos como posibles para esos campos basados en un vocabulario estándar y controlado. HL7 es un protocolo para el intercambio de datos. Define el formato y el contenido de los mensajes que una aplicación debe usar cuando intercambia datos con otra pero no especifica como los mensajes serán enviados entre las aplicaciones. Es una implementación de la capa 7 del modelo de redes OSI, capa de aplicaciones destinada a utilizarse en el ámbito de la salud, de aquí proviene su nombre.

El empleo de un protocolo para el intercambio electrónico de datos entre sistemas de información


Estándar HL7

en el ámbito de la Salud como HL7 , permite que las aplicaciones clínicas se comuniquen entre sí independientemente de su plataforma tecnológica o de su lenguaje de desarrollo, facilitando la inserción de un nuevo sistema o el reemplazo de un sistema por otro.

HL7 es una organización internacional, iniciada en los Estados Unidos en 1987, que pretende promover el desarrollo y evolución del estándar HL7 (abreviación de Health Level Seven, nivel 7 del modelo OSI aplicado al área de la salud) para el formato de datos e intercambio de información entre diferentes Sistemas de Información de Salud. Ejemplo de estos son los sistemas de información hospitalarios, sistemas de información de laboratorios clínicos, farmacia, etc.

HL7 está abierta a todos los diferentes actores del ámbito de las Tecnologías de la Información y la Salud (prestadores de servicios de salud, desarrolladores de software, consultores, usuarios finales, organizaciones gubernamentales, universidades y otras organizaciones) y desarrolla estándares por consenso en un entorno abierto.

En la actualidad está ampliamente difundida la utilización de las versiones 2.X (2.1 a la 2.5) del estándar. Sin embargo, debido a inconvenientes que presentan estas versiones que hace que sea necesaria una adaptación en cada sitio donde se la implementa, HL7 comenzó a desarrollar una nueva versión del estándar, la versión 3.

HL7 versión 3 es una iniciativa que comenzó en 1997, e implica un cambio de orientación total, a fin de solventar los problemas que se presentan en las versiones 2.X del estándar. Para esto, ha desarrollado un Modelo de Información de Referencia a partir del cual se deriva, estrictamente, la estructura de todos los mensajes a intercambiar. Esta versión del estándar no está completamente desarrollada, encontrándose algunas partes en proceso de definición, revisión y votación.

HL7 ha desarrollado también el estándar CDA (siglas en ingles de Arquitectura de Documento Clínico), el cual es un modelo genérico para el intercambio de documentos clínicos. CDA convierte a los documentos clínicos, en objetos interpretables por multitud de aplicaciones y transferibles a través de cualquier medio electrónico y puede incluir texto, imágenes y otros tipos de información multimedia. La CDA fue aprobada como un estándar ANSI-HL7 en noviembre de 2000.


Estándar HL7

HL7 versión 2.X

Se presenta aquí una breve descripción de los mensajes HL7 v2.X y el modelo de transacciones para el envío y recepción de los mismos.

Mensaje abstracto HL7

Los mensajes HL7 v2.x son mensajes ASCII formados por segmentos que son delimitados por caracteres de “retorno de carro”. Cada línea de un mensaje HL7 representa un segmento y a su vez cada segmento esta compuesto por “campos” cada uno con su propia semántica. Estos campos están compuestos por componentes los cuales pueden contener sub-componentes.HL7 permite en cada implementación definir, por parte del usuario, segmentos específicos para intercambiar información no prevista, los llamados segmentos Z.

Los segmentos dentro de un mensaje se identifican por un código único de tres caracteres denominado ‘SEGMENT ID’ e indica el tipo de información que contiene siendo de un tipo específico para cada segmento; así un segmento contendrá información sobre el mensaje en sí, otro la información sobre el paciente , etc.


fig 1: Estructura de un mensaje HL7 v 2.X

Estándar HL7

Ejemplos de segmentos y sus ID son: MSH : contiene información sobre el emisor y el receptor, tipo de mensaje, hora , etc.

EVN: contiene información sobre el tipo de mensaje

PID: contiene información sobre los datos demográficos del paciente tales como nombre,

códigos de identificación, dirección , etc.

PV1: contiene información respecto a la estancia del paciente en el hospital, como cuarto y

cama asignada, doctor , etc.

A su vez los segmento pueden ser “Requeridos” u “Opcionales” es decir si es obligatoria su presencia en el mensaje o no y si pueden “Ocurrir una sola vez” o “Permitir repeticiones” esto es si aparecerán una sola vez en el mensaje o pueden presentarse multiples segmentos del mismo tipo (con información distinta).

A modo de ejemplo se presenta el mensaje la estructura del mensaje ADT^A01, el cual se envia a causa del ingreso hospitalario de un paciente.

MSH Encabezado de MensajeEVN Tipo de eventoPID Identificación del paciente[ PD1 ] Datos adicionales demográficos[{ NK1 }] Familiares a cargoPV1 Información del episodio[ PV2 ] Información adicional del episodio[{ DB1 }] Información de discapacidades[{ ALG }] Información sobre alergias[{ DG1 }] Diagnóstico[ DRG ] Grupo relacionado de Diagnóstico[{ PR1 Procedimiento [{ ROL }] Rol}][{ GT1 }] Garante[{ IN1 Datos del Seguro Médico [ IN2 ] Datos del Seguro Médico - Adicionales [ IN3 ] Datos del Seguro Médico - Adicionales}][ ACC ] Información de Accidente

Los corchetes [] indican que el segmento es opcional y las llaves {} que puede repetirse. En este caso los segmentos MSH, EVN, PID y PV1 deben estar presentes obligatoriamente en el mensaje mientras que el resto de segmentos pueden aparecer o no. Si la persona tiene algún tipo de alergia el segmento ALG estará incluido en el mensaje y si tiene varios tipos de alergias el segmento ALG aparecerá varias veces, una para cada tipo de alergia.


Estándar HL7

El siguiente es un ejemplo de un mensaje tipo ADTÂ01 MSH|^~\&|NSI||LAB||20010827120759||ADTÂ01|NSI1|P|2.3||||AL<cr>EVN|A01|20010827120757<cr>PID|1||60719^^^^HI|26690949^^^^DNI|TORRALBAÂIDA||19780113000000|F|||AGUA 10^^MALAGA^^29004||952-4959|952-0353~952-0354<cr>NK1|1|CAMUSÂLBERTO|PAD||42539686<cr>PV1|1|I|301|R|||1436^PEREZ^JORGEÂLBERTO|1026^LOPEZ^NORBERTO|998^GARCIAÂLEJANDRO|M|||A|4|A0|N|1026^LOPEZ^NORBERTO|OB|H0100240|||||||||||||||||ALV||||||||20010823095130|20010823102455<cr>IN1|1|INT^^HI|2^^^^HI~347^^^^NSI|SEGURIDAD SOCIAL<cr>

El primer segmento (MSH) identifica el tipo de mensaje (ADT) y el evento disparador (A01) es el hecho que genera la transmisión del mensaje.Los distintos delimitadores: separador de campos, separador de componentes, separador de subcomponentes, separador de repetición y carácter de escape, están definidos en el segmento MSH a partir del 4to. carácter, en este caso :Separador de Campo | (ASCII 124)

(

Separador de Componente ^ (ASCII 94)

(

Separador de Subcomponente & (ASCII 38)

(

Carácter de Repetición ~ (ASCII 126)

(

Carácter de Escape \ (ASCII 92)

(

Terminador de Segmento <CR> (ASCII 13)

(

Todos estos separadores pueden ser modificados libremente, a excepción del Terminador de Segmento el cual debe ser siempre el carácter “retorno de carro” (<cr>).

Como puede observarse en el ejemplo cada segmento cuenta con una serie de campos separados por el carácter “|” . Un campo es una cadena de caracteres definida por un tipo de datos de HL7.El apéndice A del estándar, el diccionario de datos, brinda un listado alfabético de los campos, listados de codificación recomendada, y una referencia cruzada de los campos contra los segmentos.

Un campo también puede tener partes componentes ‘separables’, los componentes. Por ejemplo, el nombre del paciente se registra como Apellido, Nombre; en el ejemplo el sexto campo del segmento PID es TORRALBAÂIDA Algunos campos permiten incluir valores repetitivos. Por ejemplo: el campo ‘Teléfono’ permite incluir varios distintos como puede ser visto en el campo nº 16 del segmento PID del ejemplo, 952-0353~952-0354.A continuación se presenta como ejemplo la definición del campo “Patient name” con los componentes que lo conforman.


Estándar HL7

3.3.2.5 Patient name (XPN) 00108

Components: <family name (ST)> ^ <given name (ST)> ^<middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)>^ <name type code (ID) >

Los valores entre paréntesis especifican el tipo de datos que define al campo, a continuación se presentan los tipos de datos definidos por HL7

Alfanuméricos (ST,TX,FT)Numéricos (CQ,MO,NM,SI,SN)Identificadores (ID,IS,HD,EI,RP,PL,PT)Fecha/Hora (DT,TM,TS)Valores Codificados (CE,CF,CK,CN,CX,XCN)Genéricos (CM)Forma de Onda (CD,MA,NA,ED)Precios (CP)Finanzas (FC)Consultas extendidas (QSC,QIP,RCD)Archivos maestros (DLN,JCC,VH)Registros médicos (PPN)Series temporales (DR,RI,TQ)Datos Demográficos (AD,PN,TN,XAD,XPN,XON,XTN)

Donde , por ejemplo, ST es una cadena de caracteres, TX es Texto preparado para su visualización o impresión y FT es Texto Formateado el cual permite la inserción de instrucciones de formateo embebidas

Mensajes v2.X en formato XML

A partir de la versión 2.3.1 en adelante se ha definido el protocolo para representar mensajes en formato XML. El mismo se deriva directamente de las versiones en texto plano realizando una conversion del texto plano ASCII a formato xml mediante la asignación de tags para cada uno de los segmentos, campos, y componentes, manteniendo su estructura

Por ejemplo un mensaje del tipo ORMÔ01, empleado para tansmitir información sobre una orden (nueva orden, cancelación, información, actualización , etc ), en formato ASCII:MSH|^~\&|MESA_OP|XYZ_HOSPITAL|MESA_OF|XYZ_RADIOLOGY|||ORMÔ01|241104|P|2.3.1||||||||PID|||MM241^^ÂDT1||MODALITY^241||19500121|M||BL|537 PURDUE AVE^^ST. LOUIS^MO^63130|||||||20-95-MM241||||||||||||


Estándar HL7

se presentaría en formato XML de la siguiente forma:<?xml version="1.0"?><Order> <MSH> <MSH.1>|</MSH.1> <MSH.2>^~\&</MSH.2> <MSH.3> <EI.1>MESA_OP</EI.1> </MSH.3> <MSH.4> <EI.1>XYZ_HOSPITAL</EI.1> </MSH.4> <MSH.5> <EI.1>MESA_OF</EI.1> </MSH.5> <MSH.6> <EI.1>XYZ_RADIOLOGY</EI.1> </MSH.6><MSH.9> <CM_MSH.1>ORM</CM_MSH.1> <CM_MSH.2>O01</CM_MSH.2> </MSH.9> <MSH.10>241104</MSH.10> <MSH.11> <PT.1>P</PT.1> </MSH.11> <MSH.12>2.3.1</MSH.12> </MSH> <Order.PATIENT> <PID> <PID.3> <CX.1>MM241</CX.1> <CX.4> <HD.1>ADT1</HD.1> </CX.4> </PID.3>...

Modelo básico de transacciones HL7

La secuencia del intercambio de mensajes HL7 es la siguiente:


Estándar HL7

1. El sistema emisor construye un mensaje HL7 basado en datos de la aplicación y lo envía al

sistema receptor.

2. El sistema receptor recibe el mensaje y

a) Valida sintácticamente el mensaje de acuerdo a reglas de iniciación basadas en el

segmento MSH. Si falla envía un mensaje de rechazo al emisor; si no continua

b) Pasa el mensaje a la aplicación, la cual envía un mensaje de respuesta, de error o de

rechazo,

El mensaje devuelto al emisor es el mensaje ACK, definido por el protocolo ACKnowledgment.Cada vez que una aplicación acepta , y “consume”, un dato se espera que esa aplicación envíe un mensaje ACK a la aplicación emisora. El emisor continuará enviando el mensaje hasta que reciba el mensaje ACK. Esto impide que se pierdan mensajes

El concepto clave del protocolo ACK protocol es el Message Control Id, un número único que cada mensaje HL7 tiene en el campo 10 del segmento MSH. Un mensaje ACK válido enviará este ID en el segundo campo de un segmento y en el primer campo el tipo de ACK, “AA” para un ACK positivo y “AE” o “AR” para un ACK negativo, como se muestra en el siguiente ejemplo de mensaje ACK:

MSH|^~\&|MESA_OP|XYZ_HOSPITAL|MESA_OF|XYZ_RADIOLOGY|||ACK|241104|P|2.3.1||||||||MSA|AA|241104|


fig 2: Transacción HL7 v2.X

Estándar HL7

HL7 v3

A pesar de la amplia difusión y empleo de las versiones 2.X, las mismas presentan una serie de inconvenientes que pueden ser subsanados, como ser:

el proceso de desarrollo de HL7 v2.x es completamente ad hoc, no hay ninguna metodología explícita.

los miembros no reciben ninguna dirección formal respecto a la construcción de mensajes.

los eventos desencadenantes y los campos de datos son descritos únicamente en la lenguaje natural.

las relaciones estructurales entre campos de datos no están claras.

los segmentos son reutilizados en muchos mensajes y las definiciones de mensaje son reutilizadas para muchos eventos desencadenantes.

la mayor parte de campos de datos son opcionales y añadiendo el hecho de la existencia de segmentos Z, hace que existan muchos “sabores” para una misma versión con lo cual no es un sistema totalmente “plug and play”

Esto ha llevado al desarrollo de una nueva versión, la version 3, la cual está construida a partir de conocidos estándares de la industria, como son UML (Unified Modeling Language) y XML (Extensible MarkupLanguage). Todos sus elementos estructurales proceden de un núcleo compacto denominado RIM (Reference Information Model), lo que facilita enormemente su adaptabilidad y reusabilidad.

La nueva versión reduce la opcionalidad, lo cual redunda en mensajes más específicos y facilita un enfoque “plug and play” . Por otra parte, trabaja junto a otras iniciativas de estándar, como ser DICOM, genera o adopta especificaciones para los niveles 5 y 6 (XML) Y 4 (MLLP, ebXML, SOAP)

S

y permite múltiples especificaciones de implementación (XML, CORBA, etc..)

Por otro lado HL7 ya no es solamente un estándar para el intercambio de mensajes sino que se ha convertido en un familia de estándares:

Version 3 Messaging: la cual se enfoca en el intercambio de datos

Clinical Document Architecture (CDA)

C

: define una estructura común para documentos clínicos persistentes

Clinical Context Object Workgroup (CCOW)

C

: permite enlazar aplicaciones de escritorio de tal forma que distintas aplicaciones puedan trabajar coordinadamente

Arden Syntax for Medical Logic: formalismo para expresar reglas lógicas médicas

SPL HL7 (Structured Product Labeling): estándar electrónico de etiquetado de


Estándar HL7

medicamentos.

HL7 Medical Records: estándar de administración de Registros Médicos.

GELLO: estándar para la expresión de reglas de soporte de decisiones clínicas.

Metodología HL7 v3

Para un mejor comprensión del estándar HL7 v3 es necesario conocer los diferentes procesos que

están involucrados en la metodología para las especificaciones de un mensaje, y los elementos,

llamados “Artefactos”, que se desarrollan durante la misma.

Entre los artefactos se encuentran:

Storyboards (Escenarios), diagramas de estado: son el medio para proveer un contexto a los eventos activadores

Modelos de Información (RIM, DMIM y RMIM) : el medio por el cual se especifica el contenido de información de los mensajes a través de un modelo de información común que clarifica la definición y asegura que ellos se emplean consistentemente en todos los dominios.


fig 3: Artefactos de HL7 v3 y los procesos asociados

Estándar HL7

Descripción Jerárquica de Mensajes (Hierarchical Message Descriptions, HMD) : una descripción común de los campos exactos de un mensaje y su agrupamiento, secuencia, cardinalidad y opcionalidad

Modelos de Interacción: el medio de especificar las responsabilidades del emisor y del receptor de los mensajes

Especificaciones de Tecnologías de Implementación (Implementation Technology Specifications, ITS): especificaciones de sintaxis separadas, describiendo los algoritmos empleados para codificar y transmitir el mensaje basados en un documento XML.

Reference Information Model (RIM)

R

Un modelo de información es la especificación estructurada de la información en un dominio específico y consiste de los siguientes componentes: clases, sus atributos y relaciones entre las clases; tipos de datos para todos los atributos y un vocabulario de dominio para los atributos codificados; y modelos de estado de transición para algunas de las clases

El RIM es la base desde la cual todas las especificaciones del estándar diseñan su contenido relacionado con la información. Proporciona una representación explícita de las conexiones semánticas y léxicas que existen entre la información transportada por los campos de los mensajes HL7. Representa la lógica de negocio de cualquier contexto sanitario.

El RIM es muy abstracto. Solo contiene 4 clases principales y dos clases de “enlace”, las que en conjunto representan las clases fundamentales del RIM:

Actuación (ACT): representa acciones ejecutadas en el area de la salud.“Algo que se está haciendo, se hizo, puede ser hecho o se prevé o solicita hacer.”Ejemplos: observación o diagnóstico clínico, tratamiento, asistencia, monitorización, educación, edición o mantenimiento de documentos

Participante (Participation): representa el contexto del acto. Quién participó, donde fue, etc.“Una asociación entre un acto, un rol, y la entidad que desempeña ese rol ”. Cada entidad involucrada está vinculada por una Participación (typeCode)

i

Ejemplos: efectores, sujetos, ubicaciones,autores, testigos.

Entidad (Entity): representa las cosas y personas sujetos u objetos del acto de salud.“Una cosa física, grupo de cosas físicas u organización capaz de participar en actos desempeñando un rol.” No incluye eventos, acciones, actos o roles que las entidades puedan desempeñar.

Rol (Role): representa el rol que cada entidad juega en su participación. “El rol define la competencia de una entidad más allá de su participación en un acto determinado”. Una entidad participa en un acto particular en un rol determinado. Los roles son desempeñados por las entidades (player) y enmarcados por otras entidades (scooper). Ejemplo: una persona puede ser un paciente de una institución pero un médico en otra o en la misma.

Actuación Relacionada (ActRelationship): representa la relación entre actos: composición, secuencialidad, precondición, postcondición, pertinencia

Rol Relacionado (RoleLink): representa el vínculo entre roles expresando una dependencia entre los mismos. Ejemplos: relaciones jerárquicas estructurales en una empresa, relaciones


Estándar HL7

entre un empleado y sus asignaciones.

Cada clase posee un nombre, una descripción, un conjunto de atributos, un conjunto de relaciones y un conjunto de estados.

Atributos y especializaciones

Los atributos son la fuente de todo el contenido de información de HL7. La mayoría de los atributos son atributos descriptivos, que describen aspectos de la clase a la que pertenecen y son importantes para la comunicación entre los sistemas de información sanitarios. Ademas de los atributos descriptivos, hay 3 clases especiales de atributos:

Atributos identificadores: empleados para identificar una instancia de una clase, Ejemplos incluyen Entity.id y Act.id, donde Entity.id puede incluir número de serie de un dispositivo, números de la seguridad social , número de licencia de conducir, etc.

Atributos clasificadores: usados para indicar cual de las especializaciones es el foco de una clase. Los atributos clasificadores son llamados "classCode"y están definidos en el vocabulario del dominio. Por ej., Entity.classCode incluye individuo, organización, lugar y material.

Atributos estado: describen el estado actual (condición) de una clase, por ejemplo,


fig 4: Clases base del RIM

Estándar HL7

Act.status_cd puede tener los valores activo, suspendido, cancelado, completado, y abortado.

Por otra parte, todas las demás clases del RIM son especializaciones de las seis clases fundamentales. La especialización es el acto derivar una nueva clase a partir de otra de clases del RIM. Cada clase especializada añade nuevos atributos para definir su especialización.

Por ejemplo, “Persona” es una especialización de la Clase Entidad “Forma de Vida” y añade atributos como “domicilio”, “código de discapacidad”, etc.

El RIM puede ser encontrado, para una mejor visualización, en el siguiente enlace:

http://www.hl7.org/v3ballot2008MAY/html/infrastructure/rim/Graphics/RIM_billboard.pdf


fig 5: RIM

http://www.hl7.org/v3ballot2008MAY/html/infrastructure/rim/Graphics/RIM_billboard.pdf

Estándar HL7

Especificación de mensajes HL7 V3

El contenido de la información a ser intercambiado en los mensajes se especifica mediante un proceso llamado refinamiento, el cual parte del RIM y genera en cada etapa diferentes artefactos, el Domain Message Information Model (DMIM), el Refined Message Information Model (RMIM), el Hierarchical Message Description (HMD), y finalmente el Type Message (TM).

Domain Message Information Model DMIM

El DMIM es un modelo de información para un dominio en particular. Presenta un diagrama de las clases, atributos y asociaciones requeridas por los mensajes definidos en el dominio. Para obtener el DMIM a partir del RIM se realiza un clonado (copiado y adaptación) y renombrado de las clases del RIM de acuerdo a la forma en que serán empleadas en el contexto del dominio y al mismo tiempo se especifica el tipo de datos y el vocabulario para los atributos de las clases. Los pasos son los siguientes:

1. Se seleccionan las clases el RIM , relevantes para el dominio, que serán incluidas en el DMIM creando tantos “clones” como sean necesarios (ej, un clon Entidad para “paciente”, otro para el mñedico, etc)

2. Agregan relaciones entre los clones del DMIM en forma consistente con la clases realacionales en el RIM

3. Se selecciona un subconjunto de los atributos de las clases a partir de los atributos de la clase base del RIM

4. Se selecciona un subconjunto de los tipos de datos y vocabulario del dominio asignándolos a los atributos del DMIM en forma consistente con los del RIM

El propósito de un DMIM es suministrar un punto de referencia común para los mensajes de todo el dominio y validar la compatibilidad de los RMIM de un mismo dominio (Ej.- Farmacia, Laboratorio, Radiología, etc.).A modo de ejemplo a continuación se presenta el diagrama del DMIM correspondiente al dominio “Administración de pacientes”. Para una mejor visualización ell mismo puede encontrarse en:http://www.hl7.org/v3ballot2008MAY/html/domains/uvpa/editable/images/PRPA_DM000000UV.png


fig 6: Proceso de refinamiento del RIM al Type Message

RIM DMIM HDMRMIM TM

Estándar HL7


fig 7: DMIM del dominio "Administración de pacientes"

Estándar HL7

Refined Message Information Model RMIM

Un RMIM es un modelo de el contenido de un mensaje o grupo de mensajes relacionados, es decir define un conjunto relacionado de mensajes correspondiente a un sector de un dominio concreto.

Los RMIMs son desarrollados para especificar claramente el contenido de los mensajes y repesentan la información que contendrán la estructura abstracta de mensaje llamada HMD.Los RMIM refinan al DMIM al que pertenecen, simplificándolo o aplicándole nueva restricciones.

También junto al diagrama del RMIM se proporciona información detallada sobre las clases definidas, a continuación se presenta un fragmento de dicho detalle:

DescriptionParent: Patient Administration (PRPA_DM000000UV)

The Encounter Location Change R-MIM defines the message used to report that a patient has been transferred from one assigned location to another during an active encounter.

EncounterEventThe entry point to the Encounter Location Change R-MIM is the focal encounter, EncounterEvent. The R-MIM assumes encounter location change messages would be exchanged between systems are closely coupled with respect to patient location assignments so EncounterEvent.id and the subject association to R_Patient [identified] CMET is the only information sent about the encounter.


fig 8: RMIM del mensaje "cambio de la localización asignada a un paciente"

Estándar HL7

ocation1The location1 class describes the patient's assigned location following the change action. The attributes statusCode (set to "active") and time (populated with the assignment starting date-time) are mandatory. The location is sent as a ServiceDeliveryLocation role played by a place sent in an E_Place CMET.

location2The location2 class describes the patient's assigned location prior to the change action. The attributes statusCode and time are mandatory. For a statusCode other than "nullified" the time attribute should contain the time range (starting and ending date-time) for the assignment. For a statusCode of "nullified" the time attribute would contain the start date-time reported in the record that was nullified. The location is sent as a ServiceDeliveryLocation role played by a place sent in an E_Place CMET.

Either ServiceDeliveryLocation.id or E_Place.name must be valued.

AccommodationEventA given patient location assignment may be associated with one or more AccommodationEvents, that is, a service (usually billable) provided for a Person in which a place is provided for the subject to reside for a period of time. Commonly used to track the provision of ward, private and semi-private accommodations for a patient.

Hierarchical Message Description HMD

El HMD se deriva directamente del RMIM, de hecho es una versión seralizada de este modelo. De esta forma, el HMD organiza las clases del RMIM en una secuencia lineal específica a fín de ajustarse a los requistos lógicos de mensajería. Dentro de cada clase los atributos son tambien ordenados en base a el orden de aparición en el RMIM. Al mismo tiempo que se realiza esta serialización se puede llevar a cabo un refinamiento de la cardinalidad de las cklases y atributos, refinar el vocabulario del dominio e imponer ciertas restricciones a los atributosPor lo tanto el HMD representa una lista lineal de atributos, organizados por clases, y define las reglas que controlan esos atributos dentro de una instancia particular de un mensaje.Los HMDs son abstractos debido a que ellos definen la estructura de los mensajes sin hacer referencia a la tecnologia para implementarlo.


Estándar HL7


Estándar HL7

Type Message MT

Es un conjunto de reglas para construir un mensaje dado con un conjunto específicos de datos, por ello tambien sirve como guia para parsing un mensaje para recupar los datos que contiene. Cada MT representa un conjunto único de restricciones aplicadas al HMD, Los tipos de mensaje se diferencian en función del evento disparador particular que aplica.

La siguente figura presenta un segmento del TM correspondiente al mensaje "cambio de la localización asignada a un paciente" asi como el segmento correspondiente de su HMD. En el mismo puede observarse que se ha establecido que debe sera asignaod un valor para el atributo Date-Time y que el codigo de estado (StatusCode) toma por defecto el valor “completado”.


fig 9: Segmento del HMD del mensaje "cambio de la localización asignada a un paciente"

Estándar HL7

Esquemas XML

HL7 proporciona por conveniencia esquemas XML (hojas XSD), derivados de cada Type Message definido, ya que esta es una forma compacta y especifica para describir una representación XML de los mensajes. Es conveniente aclarar que los esquemas no son parte normativa del estándar.

Estos esquemas facilitan la creación de los mensajes a partir de un conjunto de datos a transmitir,así como la validación y recuperación de los datos desde un mensaje.

A continuación se presenta un extracto del esquema correspondiente al mensaje "cambio de la localización asignada a un paciente".


fig 10: Segmento del HMD (superior) y TM (inferior) del mensaje "cambio de la localización asignada a un paciente"

Estándar HL7

<xs:schema targetNamespace="urn:hl7-org:v3" elementFormDefault="qualified"> <xs:annotation> <xs:documentation>Generated using schema builder version 3.1.4. Stylesheets: StaticMifToXsd.xsl version2.0 </xs:documentation> </xs:annotation> <xs:include schemaLocation="../coreschemas/infrastructureRoot.xsd"/> <xs:include schemaLocation="COCT_MT050001UV.xsd"/> <xs:include schemaLocation="COCT_MT710000UV.xsd"/> <xs:include schemaLocation="COCT_MT150001UV01.xsd"/> <xs:complexType name="PRPA_MT302011UV01.AccommodationEvent"> <xs:sequence> <xs:group ref="InfrastructureRootElements"/> <xs:element name="code" type="CD" minOccurs="0" maxOccurs="1"/> <xs:element name="effectiveTime" type="IVL_TS" minOccurs="0" maxOccurs="1"/> <xs:element name="reasonCode" type="CE" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attributeGroup ref="InfrastructureRootAttributes"/> <xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/> <xs:attribute name="classCode" type="ActClass" use="required" fixed="ACCM"/> <xs:attribute name="moodCode" type="ActMood" use="required" fixed="EVN"/> </xs:complexType> <xs:complexType name="PRPA_MT302011UV01.EncounterEvent"> <xs:sequence> <xs:group ref="InfrastructureRootElements"/> <xs:element name="id" type="II" minOccurs="1" maxOccurs="unbounded"/> <xs:element name="code" type="CD" minOccurs="0" maxOccurs="1"/> <xs:element name="subject" type="PRPA_MT302011UV01.Subject" nillable="true" minOccurs="1" maxOccurs="1"/> <xs:element name="location1" type="PRPA_MT302011UV01.Location1" minOccurs="1" maxOccurs="1"/> <xs:element name="location2" type="PRPA_MT302011UV01.Location2" minOccurs="1" maxOccurs="1"/> </xs:sequence> <xs:attributeGroup ref="InfrastructureRootAttributes"/> <xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/> <xs:attribute name="classCode" type="ActClass" use="required" fixed="ENC"/> <xs:attribute name="moodCode" type="ActMood" use="required" fixed="EVN"/> </xs:complexType> <xs:complexType name="PRPA_MT302011UV01.Location1"> <xs:sequence> <xs:group ref="InfrastructureRootElements"/> <xs:element name="time" type="IVL_TS" minOccurs="1" maxOccurs="1"/> <xs:element name="id" type="II" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="statusCode" type="CS" minOccurs="1" maxOccurs="1"/> <xs:element name="serviceDeliveryLocation" type="PRPA_MT302011UV01.ServiceDeliveryLocation" minOccurs="1" maxOccurs="1"/> </xs:sequence> <xs:attributeGroup ref="InfrastructureRootAttributes"/> <xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/> <xs:attribute name="typeCode" type="ParticipationTargetLocation" use="required"/> </xs:complexType>... Pueden observarse referencias a otros esquemas xsd generales, COCT_MT050001UV.xsd, COCT_MT710000UV.xsd y COCT_MT150001UV01.xsd; la referencia al tipo de mensaje name="PRPA_MT302011UV01.AccommodationEvent; y los distintos atributos que incluyen, así


Estándar HL7

como el tipo de datos y las restricciones aplicadas. Todos estos elementos son detallados, y explicados, en cada uno de los artefactos asociados al mensaje (RMIM, HMD y TM).

Infraestructura de Transmisión El dominio de infraestructura de transmisión trata sobre elementos referidos específicamente al mensaje: quién lo envía, a través de que medio, en que condiciones de seguridad, etc. Este dominio es parte de la porción “Message Control” del RIM.

Este dominio define dos niveles de envoltorio (wrapper) para el mensaje en sí, el Transmission Wrapper y el Trigger Event Control Act Wrapper. Estos son componentes comunes a cualquier mensaje que “envuelven” el contenido (Payload), es decir los campos definidos por el TM específico para un tipo de mensaje dentro de un dominio.

Del mismo modo que los mensaje estos wrappers están definidos a partir de un TM derivado a su vez de un HMD y un DMIM, el cual es derivado a su vez del RIM.


fig 11: Diagrama del Message Control dentro del RIM

Observation

. ..

SubstanceAdministration

routeCode : CE...

Procedure

...

Supply

...

D iet

...

Document

...

ContainercapacityQuantity : PQheightQuantity : PQdiameterQuantity : PQcapTypeCode : CE...

AccessapproachSiteCode : CD......

DevicemanufacturerModelName : SCsoftwareName : SClocalRemoteControlStateCode : CE......

EmployeejobCode : CEjobTitleName : SCjobClassCode : CEsalaryTypeCode : CE...

LivingSubjectadministrativeGenderCode : CE...bir thTime : TSdeceasedInd : BLdeceasedTime : TS...

Mater ialformCode : CE...

LicensedEntityrecertificationTime : TS. ..Place

mobileInd : BLaddr : AD

directionsText : ED......

Manufactur edMateriallotNumberText : ST...

NonPersonLivingSubject...

Patient

...Organization

...

Account

...

P erson

addr : BAG<AD>...m aritalStatusCode : CE......

WorkingList

ownershipLevelCode : CE...

PublicHealthCase

...

P ati entE ncounterpreAdmitTestInd : BLadmissionReferralSourceCode : CElengthOfStayQuantity : PQdischargeDispositionCode : CEspecialCourtesiesCode : SET<CE>...

Other

Acts

Infrastructure (Structured documents)

HEALTH LEVEL 7 REFERENCE INFORMATION MODEL VERSION 1.23 (RIM_0123)

Reflects changes to RIM in RIM Harmonization Meeting 03/20/2003.

Bi l l board produced by:Rochest er O utdoor Advert i si ng

Roles

DiagnosticImage

subjectOrientationCode : CE...

QueryAck

...

Q ueryCont inuat ion

...

Table

summary : ST......

TableStructur e

...

TableColumnStructure

span :

TableCell

scope : CS...

LocalAttr

...

LocalMarkup

...

LinkHtml

...

ContextStructure

l ocalI d : S T

Infrastructure (Structured documents)

Infrastructure (Communications)

Enitites

Message Control

FinancialTransaction

...

InvoiceElement

modifierCode : SET<CE>......

FinancialContract

paymentTermsCode : CE...

RoleHeir

E nti tyH eir

SortControlsequenceNumber : INT......

QuerySpecm odifyCode : CSr esponseElementGroupId : SET<II>...r esponseModalityCode : CSr esponsePriorityCode : CS...

0..n

1

0..n

1

RelationalExpression

...

QueryBySelection SelectionExpression

0..n

1

0..n

1

LogicalExpression

relationalConjunctionCode : CS. ..

0..n

0..1

userAsRight

0..n

r ightSide 0..1

0..n

0 ..1

userAsLeft0..n

leftSide0 ..1

Q ueryByP arameter

ParameterList

Parameter

id : II0..n 0..10..n 0..1

0..1

0..n

0..1

0..n

P arameterI tem

...

DeviceTask

parameterValue : LIST<ANY>...

ManagedParticipation. ..

ActHeir

ActRelationship

typeCode : CSinversionInd : BL...contextControlCode : CS...contextConductionInd : BL......

A ct

classCode : CSmoodCode : CSid : SET<II>code : CDnegationInd : BLderivationExpr : ST......

0. . n1

inboundRelat ionship

0. . n

t ar ge t

1

0. . n1

out boundRelat ionship

0. . n

source

1

ParticipationtypeCode : CSfunctionCode : CDcontextControlCode : CSsequenceNumber : INTnegationInd : BLnoteText : EDtime : IVL<TS>modeCode : CE...

0. . n1

0. . n1

RoleLink...

RoleclassCode : CSid : SET<II>code : CEnegationInd : BLaddr : BAG<AD>telecom : BAG<TEL>statusCode : SET<CS>...

0. . n

1

0. . n

1

0. . n1

out boundLink

0. . n

source

1

0. . n1

inboundLink

0. . n

t arget

1

LanguageCommunicationlanguageCode : CEmodeCode : CE...

AttentionLine...

BatchreferenceControlId : IIname : SC...

EntityclassCode : CSdeterminerCode : CSid : SET<II>code : CEquantity : SET<PQ>name : BAG<EN>desc : EDstatusCode : SET<CS>...

0. . n0. . 1

playedRole

0. . n

player

0. . 1

0. . n0. . 1

scopedRole

0. . n

scoper

0. . 1

10 ..n 10 ..n

Transmissionid : II...

0..n

1

0..n

1

0..1

0..n

0..1

0..n

CommunicationFunction

typeCode : CStelecom : TEL

1..n

0..*

1..n

0..*

1..*

0 ..*

1..*

0 ..* InfrastructureRoot

...QueryEvent

...

ControlAct

...

0..1

1

0..1

1

MessageversionId : STinteractionId : IIprofileId : SET<II>processingCode : CS

processingModeCode : CSacceptAckCode : CSapplicationAckCode : CS...

0. . 1

0. . n

0. . 1

payload

0. . n

Acknowledgement

...

0. . n

1

acknowledgedBy0. . n

acknowledges1

0. . 1

1

conveyedAcknowledgem ent0. . 1

conveyingM essage1

AcknowledgementDetail

...

1

0..n

1

0..n

Estándar HL7

Transmission Wrapper

El "Transmission wrapper" incluye la información necesaria para que una aplicación emisora empaquete y enrute el mensaje hacia la aplicación receptora, así como para identificar el mensaje y los protocolos de reconocimiento (ACK protocol). También incluye atributos que identifican un modo de mensajería genérico. Este modo de mensajería genérico tiene que manejar un comportamiento consistente con la interacción para la cual el mensaje ha sido definido.

Ejemplos de TM para Transmission Wrapper son:

● Send Message Payload● Accept Acknowledgement● Application Acknowledgement● Polling● Send Poll Response w/ Message● Send Accept Ack/Poll Next Msg● Send Poll Request


fig 12: Componentes de un mensaje HL7 v3

Estándar HL7

Trigger Event Control Act Wrapper

El Trigger Event Control Act Wrapper es un envoltorio que contiene la información administrativa específica de un dominio relacionado con el evento disparador (trigger event) que está siendo comunicado como una interacción de la mensajería. La mayor parte de los mensajes incluyen el Trigger Event Control Act Wrapper; la excepción son los “accept level acknowledgements “ que sólo son usados para transportar el estado de comunicaciones de mensaje

Esta capa tiene algo de superposición con la información enviada en el payload, pero es una estructura coherente e idéntica para todos los dominios.También define la manera de informar errores de aplicación en el procesamiento de los mensajes: ‘Ya se cerró el período de facturación’,’Paciente dado de alta hace 72 horas’, etc.


fig 13: Diagrama del DMIM del Transmission Wrapper

Estándar HL7

La clase ControlActProcess puede ser vista como una generalización del segmento “EVN” de HL7 v2.x. Este segmento especifica el nombre del evento así como la hora y fecha del evento , la persona responsable para el evento, etc.

El siguiente es una síntesis de un esquema XSD de mensaje completo donde se puede observar cada una de las partes del mensaje, la sección correspondiente al Transmission Wrapper, al Trigger Event Control Act Wrapper y al mensaje en sí mismo (Payload)

<?xml version="1.0" encoding="utf-8" standalone="no"?><Message xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2002/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3/MCCI_MT000101 MCCI_MT000101.xsd"> … <application_ack_cd code="ER"/> <executedByRespondToOrg> …. </executedByRespondToOrg> <executedBySendApp> … </executedBySendApp> <executedByRcvApp> … </executedByRcvApp>


fig 14: Diagrama del DMIM del Trigger Event Control Act Wrapper

Estándar HL7

... <has_payload_ControlActEvent xsi:type="MCAI_HD700200"> <response_cd code="N"/> <verifier> <participant_COCT_MT090100> <id root="2.16.840.1.113883.1122" extension="444-444-4444"/> </participant_COCT_MT090100> </verifier> <interactionTarget xsi:type="POLB_MT004101"> </interactionTarget> ... <interactionTarget xsi:type="POLB_MT004101"> <ObservationEvent> … <participant>

… </participant> <patient> … </patient> <inFulfillmentOf> … </inFulfillmentOf> <referenceRange> … </referenceRange> </ObservationEvent> </interactionTarget> </has_payload_ControlActEvent></Message>

Especificaciones de ImplementaciónUna especificación de implementación (ITS) define como se representan los objetos del RIM para transmitir mensajes. Cubre los niveles ISO 5 y 6. La ITS debe tener soporte para objetos, atributos y tipos de datos definidos , o basados, en el RIM.

HL7 adoptó XML como su primera ITS. Puesto que se requiere que la ITS provea definiciones para todos los tipos de componentes definidos por HL7: tipos de datos, nombres de clases, asociaciones, y nombres de atributo, se desarrolló un esquema XML dentro de un solo namespace.

Los esquemas permiten definir qué es válido dentro de un documento XML y saber si un mensaje HL7 recibido es o no válido.


Estándar HL7

Especificaciones de TransporteLas especificaciones de transporte proveen detalles sobre el uso de diversos protocolos de comunicación para el transporte de mensajes o documentos HL7.

Dentro de los protocolos contemplados actualmente por HL7 se encuentran:

● MLLP: una especificación muy simple y muy utilizada en la comunidad HL7, que usa sólo un byte de comienzo y uno de final

● ebXML: soporta la mensajería confiable, el cifrado, autenticación y firmas digitales, y el cambio de mensajes sobre una variedad de transportes de nivel inferiores como HTTP, SMTP Y TCP/IP.

● Web Services: proporciona directrices de puesta en práctica para promover la interoperabilidad entre implementadores que quiere cambiar mensajes conforme a la definición general de Servicios de Web.

● Removable Media: especifica la transferencia de mensajes HL7 o documentos mediante medios de almacenamiento extraíbles ISO 9660. Los ejemplos de estos son el formato común de CDs y tarjetas de memoria USB


Estándar HL7

ArtefactosLos componentes de documentación dentro del estándar HL7 v3 son conocidos como “artefactos”.

A fin de identificar cada uno de los artefactos se ha definido una nomenclatura basada en el tipo de artefacto y al dominio al que pertenece.

La siguiente es una lista de los artefactos, de los dominios y sus sub-secciones, definidos para HL7 v3 y el código asignado


fig 15: Artefactos definidos por HL7 v3

fig 16: Dominios y sub-secciones definidos por HL7 v3

Estándar HL7

Así el nombre identificatorio que da establecido por el código de dominio, un código de subsección, el código de artefacto y un número de 6 dígitos que asegura su unicidad

por ejemplo el nombre de artefacto PRPA_MT00001 identifica a un MT perteneciente al dominio administración de pacientes , sub-sección práctica.

donde:

PR = Subsection: Practice

PA = Dominio: Patient Administration

MT = Artefacto: Message Type

00001 =número de 6 dígitos

A continuación se presenta una breve descripción de los artefactos, a excepción de los DMIM, RMIM, HMD, Message Type los cuales ya han sido comentados anteriormente.

Interacción

La interacción es el corazón de la mensajería. Realiza una definición donde especifica qué aplicación envía un tipo de mensaje particular (sender role), a qué aplicación se lo envía (receiver role), cómo determina cuando enviarlo (trigger event) y qué tipo de mensaje es (message type).


fig 17: interacción "transferir al paciente a una nueva localización"

Estándar HL7

Rol de Aplicación (Aplication Role)

Los Roles de Aplicación son una abstracción que normaliza los roles desempeñados por componentes de sistemas de información sanitarios cuando envían o reciben un mensaje HL7

Representan un conjunto de responsabilidades de comunicación que pueden ser implementadas por una aplicación. Cuando se define una interacción HL7, un rol de aplicación es la responsabilidad asignada para enviar (iniciar) ésta la interacción, y un rol de aplicación es la responsabilidad asignada para la interacción e iniciar las respuestas apropiadas. Las responsabilidades de envío y recepción para una interacción en particular pueden ser asignadas a único Rol de aplicación .

Se han definido 5 tipos de Rol de Aplicación:

● Placer: Puede notificar a otra sobre un evento significativo, y que espera que el receptor actúe al recibir el mensaje.

● Fulfiller: Puede recibir una solicitud de una aplicación Placer.

● Confirmation Receiver: Un Placer que indica que tipos de confirmación acepta.

● Informer: Puede informar a otras aplicaciones sobre un evento significativo pero no espera acciones en consecuencia.

● Tracker: Puede recibir información sobre un evento pero no actúa en consecuencia


fig 18: Diagrama del Rol de Aplicación para el evento "cambio de la localización de un paciente"

Estándar HL7

Trigger Events

Los eventos disparadores (trigger events) son el motivo por el cual se intercambian los mensajes. Es un conjunto explicito de condiciones que inician la transferencia de información entre componentes de sistema ( Roles de aplicación)

Se han definido 3 Tipos de eventos disparadores:

● Interacción: esta basado en otra interacción; por ejemplo, la respuesta a un query ( el cual es una interacción) .

● Transición de estados: se produce una transición de estados que debe informarse (la mayor parte de los casos) ; por ejemplo la cancelación de un documento.

● Usuario: un usuario solicita que el evento se produzca.

Storyboard Storyboard Narrative

Es un concepto tomado de la industria del cine y la animación. Cada cuadro representa un momento significativo en la secuencia, ilustra los participantes clave y su interacción con los demás. El conjunto de storyboards provee una descripción coherente de todos los procesos. Cuando no hay storyboards genéricos, se presentan en esta sección vínculos a los storyboards de cada tópico. Este ‘artefacto’ es la base de todo el proceso de desarrollo de HL7 e incluye:

● Un diagrama de interacción.

● Una lista de interacciones.

● Una descripción narrativa (Storyboard Narrative)


fig 19: Definición del evento disparador "cambio de la localización de un paciente"

Estándar HL7

Tipos de DatosEl tipo de datos abstracto es la mínima expresión con la que se arma todo el resto: mensajes, documentos, etc. se diferencian de los objetos definidos en la versión 3 en que no tienen estados ni identidad: solo importa su valor.

La especificación de los tipos de datos de HL7 es semántica: independiente de la representación. Esto permite mayor escalabilidad e independencia de la plataforma y la implementación.

HL7 define un nuevo estándar para los tipos de datos debido a que HL7 v3 requería una definición totalmente independiente de la tecnología y porque pocas implementaciones tecnológicas cubren aspectos de la informática en salud como precisión, rango o información no disponible

Por otra parte, HL7 v3 necesita esta clase de especificación semántica abstracta de tipos de datos para propósitos prácticos. Una característica importante de la versión 3 es su apertura hacia tecnologías de representación e implementación. La tecnología avanza velozmente y así HL7 v3 puede ser válido aún con cambios de tecnología.

Por ejemplo, la representación de valores Booleanos puede ser las palabras "verdadero" y "falso", "sí" y "No", los números 0 y 1, o dos signos cualesquiera que sean distintos uno del otro. La representación de tipos de datos no importa mientras esto se conforma a la definición semántica del tipo de datos.


fig 20: Storyboard y Storyboard Narrative para el "cambio de localización de un paciente"

Estándar HL7

Dentro de los tipos de datos abstractos básico tenemos:

Al mismo tiempo el valor NULL tiene una serie de variantes a fin de especificar porque toma el valor nulo. Esta variedad puede ser aplicada a cualquier tipo de datos, salvo especificación o restricción en contrario.

Los tipos de datos abstractos se pueden agrupar de la siguiente forma:

● Valores codificados

● Conjuntos

● Entidades

● Identificadores

● Valores numéricos

● Textos

● Tiempo, fechas


Nombre Símbolo Descripción

DataValue ANY Tipo de datos abstracto. Cualquier tipo de datos es ANY.

Boolean BL Binario: para lógica de dos valores. Solo puede ser VERDADERO O FALSO, o como cualquier otro valor: NULO

BooleanNonNull BN Una restricción del Boolean para que no admita nulos. Creado para usar cuando no es apropiado un valor nulo.

codigo nombre definicion

NI NoInformation

not applicableunknown Hay un valor apropiado, pero se desconoce.not asked La información no ha sido solicitada - Por. Ej: no se preguntó

La información fue solicitada, pero no hubo respuesta.

La información no está disponible pero lo estará más adelante.other El valor no es un elemento en el dominio.positive infinity Infinito positivonegative infinity Infinito negativo

masked

NP not present

No puede ser inferida informacion de este valor. Es el mas general y el valor por omisión.

NANo hay un valor apropiado en este contexto (p.ej: periodo menstrual para un varon)

UNK NASK

ASKUasked but unknown

NAVtemporarily unavailable

OTH PINF NINF

MSKHay informacion sobre el item pero no ha sido provista por el emisor por razones de seguridad.Valor no presente en el mensaje. Se define para mensajes. NUNCA para datos grabados enaplicaciones. Los valores no presentes en mensajes deben ser reemplazados por el valor por omisión o por NI

Estándar HL7

● Probabilidades

Los valores de datos también pueden poseer propiedades especificadas por su tipo de datos. Los campos de “tipos de datos compuestos " - por ej. la característica de “unidades" de una medida (kg, mts, etc) - son el ejemplo más común de tales propiedades. Sin embargo, más generalmente habría que pensar en las propiedades del valor de datos como predicados lógicos o como funciones matemáticas. En una forma más simple se puede decir que las propiedades son las respuestas a preguntas que uno puede preguntar sobre un valor de datos.

VocabularioEn HL7, un dominio de vocabulario es un conjunto de todos los conceptos que pueden ser tomados como valores válidos para una instancia de un atributo con un tipo de datos codificado. Un vocabulario es un conjunto de conceptos, no de palabras o códigos.

Esta diseñado para permitir un conocimiento compartido, bien definido y no ambiguo del significado de los datos transferidos. Es importante cuando tal información puede ser representada de diferentes formas.

En muchas áreas de la informática de la salud un vocabulario es representado en términos codificado. Esto facilita la comunicación y a veces la independencia del lenguaje pero requiere que los sistemas comunicantes sean capaces de interpretar los códigos correctamente

Una característica importante del vocabulario en v3 son los calificadores de vocabulario:

● CWE: coded with exceptions : el conjunto de códigos puede ser expandido para cumplir con especificaciones locales. Cuando se envía un atributo codificado en un mensaje, se puede enviar sólo el texto o un código local si el concepto que se desea representar no está en el dominio.

● CNE: coded with no exceptions: el conjunto de códigos es fijo y no puede ser extendido. Si el concepto que se desea representar no está en la lista el mensaje no puede ser enviado.

● Dominios Especiales : Realm : un dominio puede ser especializado para un area geográfica/organizacional o política donde se use el standard.

● Restricciones: un dominio puede ser restringido en niveles de detalle mas específicos (R-MIM,D-MIM) pero no expandido.

HL7 Vocabulary Domain Values

Son tablas con los dominios de vocabulario de HL7. Contienen un código mnemónico, un identificador de concepto, un nombre y una definición o descripción


Estándar HL7

Common Message Element Types CMET'sUn Common Message Element Types (CMET) es un fragmento de mensaje reusable definido por un comité a partir de un D-MIM (modelo de información de un dominio). Permite representar un concepto usual de manera resumida. Ejemplo: persona en el rol de paciente.


fig 21: Fragmento de la tabla vocabulario para la clase Entidad

fig 22: CMET persona en el rol de paciente

Estándar HL7

Los CMET se clasifican según dos ejes:

Nivel de especificidad (attribution): un CMET es implementado como un tipo de mensaje derivado a partir de un HMD y un RMIM la misma manera puesto en práctica como un tipo de mensaje sacado de un HMD y la R-MIM en la misma manera que todos otros tipos de mensaje. El tipo de mensaje puede contener la información completa sobre un concepto, o la información mínima sobre el mismo. El extremo completo, se lo ha llamado nivel Universal del CMET, mientras que el otro extremo se lo ha denominado nivel Identificado del CMET, o variantes universales e identificadas, respectivamente. La variante universal de un CMET está siempre presente, y todas las otras variantes, si existen, son derivadas restringiendo la variante universal. Las variantes más comunes de CMET's son:

● Universal: todos los atributos del R-MIM

● Contacto: contiene lo suficiente información para contactar a un sujeto

● Identificable y Confirmable: con un identificador y datos para corroborar la identidad

● Identificable: solamente un identificador

Nivel de Generalización-Especialización: permite escoger entre varias especializaciones de un concepto en un CMET. Estas opciones siempre están entre las especializaciones de una clase del RIM que juega el papel central en el concepto modelado por el CMET. Por ejemplo, podemos modelar una Entidad de tipo LivingSubject en la misma manera que una Entidad de tipo Person o NonPersonLivingSubject (a excepción de la especialización de Entidad sí mismo). Esto resulta en un CMET generalizado llamado E_LivingSubject, y varios CMETS especializados llamados E_Person y E_NonPersonLivingSubject.


HL7 v3.pdf

Documents

Transcript of HL7 v3.pdf