Material Teórico

Introducción a la Interoperabilidad entre Sistemas
de Información en Salud
Ing. Pablo Pazos Gutiérrez <
pablo.pazos@cabolabs.com
>
Versión Fecha Autor

1.0 20151107 Pablo Pazos
1
Índice
1. Introducción
2. Protocolos de Comunicación
2.1. TCP
2.1.1. Paquetes TCP
2.1.2. Sockets TCP
2.1.3. Números de puerto conocidos
2.2. MLLP
2.2.1. Definición de bloques
2.3. HTTP
2.3.1. URL
2.3.2. Métodos HTTP
2.3.3. Estructura de pedidos y respuestas HTTP
2.3.4. Códigos de estado HTTP
2.4. SOAP
2.4.1. Terminología SOAP 1.2
2.4.2. Estructura de mensajes SOAP
2.4.3. Ejemplos de mensajes SOAP sobre HTTP
3. Formatos de Mensajería
3.1. XML
3.1.1. Comentarios sobre el formato XML
3.2. JSON
3.2.1. Comentarios sobre el formato JSON
3.3. ER7
4. Estándares XML
4.1. XPath
4.1.1. Especificadores de ejes
4.1.2. Prueba de nodo
4.1.3. Predicados
4.2. XSD
4.2.1. Esquema para documentos HL7 CDA
4.2.1.1. Definición de tipo para el elemento ClinicalDocument
4.2.1.2. Definición de tipo para el elemento recordTarget
4.2.2. Validación de XML contra XSD
5. HL7
5.1. HL7 v2.x
5.1.1. Formato de mensajes HL7 v2.x
5.1.2. Tipos de mensajes
5.1.3. Eventos disparadores
5.1.3.1. Eventos para admisiones, altas y transferencias (ADT)
5.1.4. Tipos de segmentos
5.1.5. Tipos de datos
5.1.6. Definiciones de mensajes
5.1.7. HL7 v2.5 codificado como XML
5.2. HL7 v3
5.2.1. Reference Information Model (RIM)
5.2.2. Clinical Document Architecture (CDA)
5.2.2.1. Estructura del CDA en XML
5.2.2.2. Paciente
2
5.2.2.3. Autor del documento (ej. médico responsable)
5.2.2.4. Organización encargada de custodiar los documentos (ej. Ministerio de Salud)
5.2.2.5. Ejemplo de una sección Nivel 2 dentro del cuerpo del CDA
5.2.3. Validando CDA
6. Servicios Web
6.1. REST
6.1.1. Métodos HTTP y operaciones REST
6.2. REST vs SOAP
3
1. Introducción
Este documento es una guía introductoria a varios elementos básicos para la interoperabilidad entre sistemas de
información en salud, incluyendo: protocolos de comunicación, formatos de mensajes, y estándares. El estudio de
estos elementos permitirá la comprensión de otros conceptos, estándares y guías más complejas que hacen uso
exhaustivo de los mismos.
2. Protocolos de Comunicación
Los protocolos de comunicación son la piedra angular de la interoperabilidad, ya que sin ellos la interoperabilidad es
imposible. Los protocolos de comunicación tienen diferentes capas según la ISO OSI1 (Open Systems Interconnection
Model), siete capas en el modelo OSI. Estas siete capas fueron simplificadas a 4 en la pila de protocolos TCP/IP
utilizados en la Internet y en la Web como aplicación sobre la Internet. En este documento nos concentraremos en la
pila TCP/IP, y en protocolos de las capas de Transporte y Aplicación2.
2.1. TCP
Transmisión Control Protocol es un protocolo de comunicación que permite definir canales de comunicación
bidireccionales (full duplex) entre procesos corriendo en distintas computadoras. Para TCP los datos a comunicar son
vistos como un flujo de datos divididos en paquetes de tamaño fijo, aproximadamente de 1500 bytes. La
comunicación mediante un flujo continuo de datos implica que si se envían dos mensajes desde un proceso a otro, el
proceso que recibe puede no distinguir cuándo termina un mensaje y comienza el otro (ver MLLP).
TCP implementa transporte confiable de datos, es decir que se reciben todos los paquetes enviados en el orden
correcto. TCP se implementa sobre IP (Internet Protocol) que es un protocolo no confiable, es decir que los paquetes
pueden perderse o llegar en el orden incorrecto. TCP e IP son los protocolos que sirven como base para la Web.
TCP implementa mecanismos de control de flujo, que permiten ajustar la cantidad de datos a enviar según la
capacidad de recepción, es decir, si el proceso que emite datos puede enviar más datos de los que el proceso
receptor puede recibir, disminuye el volumen de datos según la capacidad del receptor. De forma análoga, se
aumenta el volumen de datos ante una mayor capacidad de recepción.
Los canales de comunicación TCP son orientados a conexión, es decir que previo al envío de datos, es necesario
establecer una conexión entre dos procesos distribuidos, uno será el servidor (proceso que escucha pasivamente por
solicitudes de conexión) y cliente (proceso que solicita activamente una conexión al servidor).
En el siguiente RFC puede encontrar la especificación del protocolo aunque ha tenido varias mejoras y extensiones
también definidas desde entonces (1981): https://www.ietf.org/rfc/rfc793.txt
1
ttps://es.wikipedia.org/wiki/Modelo_OSI
h
2

https://en.wikipedia.org/wiki/Internet_protocol_suite
4
2.1.1. Paquetes TCP
Los paquetes están compuestos de un cabezal y de un conjunto de datos. El cabezal TCP tiene un tamaño mínimo de
20 bytes. El cabezal TCP incluye todos los datos necesarios para proveer transporte confiable: entrega de todos los
paquetes y en el orden correcto.
Del cabezal podemos destacar que contiene los números de puerto origen y destino (16 bits cada uno) que
identifican a los procesos que se están comunicando. El número de secuencia se utiliza para ordenar los paquetes
recibidos. El número de acknowledgement permite saber si algún paquete se perdió en la comunicación, en cuyo
caso TCP solicita la retransmisión del paquete perdido. Checksum se utiliza para detectar posibles datos corruptos en
la comunicación (por ejemplo que un bit 0 cambie a 1).
Como puede notar, las direcciones IP de las computadoras donde corren los procesos que se comunican no aparecen
en el cabezal TCP, sino que se encuentran en el cabezal IP que se utiliza para comunicar los paquetes TCP entre
distintas computadoras.
Figura 1: Paquete TCP
2.1.2. Sockets TCP
Los sockets son construcciones abstractas que funcionan como interfaces entre las aplicaciones y la capa de
transporte. Los procesos corriendo en computadoras distintas utilizarán entonces sockets para conectarse e
intercambiar datos. Un socket TCP es identificado mediante las direcciones IP del cliente y el servidor, y los números
de puerto asignados a los proceso del cliente y del servidor, por lo tanto dos conexiones entre los el mismo cliente y
mismo servidor deberán utilizar números de puerto distintos en uno de los extremos, en general en el cliente.
Para manipular conexiones y transmitir datos mediante sockets TCP desde las aplicaciones, es necesario utilizar un
conjunto de operaciones básicas definidas sobre los sockets. Estas operaciones pueden variar según el lenguaje de
programación.
Operación Descripción
Socket Crea una nueva interfaz de comunicación.
Bind Asocia un número de puerto local al socket.
Abre el socket para esperar por solicitudes de conexión, especificando el
Listen tamaño de la cola de conexión (número de conexiones simultáneas
soportadas).
Accept Bloquea el proceso esperando por solicitudes de conexión.
5
Connect Envío de una solicitud de conexión.
Send Envía datos sobre la conexión.
Receive Recibe datos desde la conexión.
Close Cierra la conexión.
A continuación se describe el orden habitual de invocación de las primitivas, tanto del lado del servidor como del lado
del cliente.
El servidor comienza por crear un nuevo socket, lo asocia a un puerto (bind) e indica que ese socket será utilizado
para escuchar por conexiones (listen). Luego el servidor espera por conexiones desde clientes (accept). Mientras
tanto, el cliente crea un socket y, especificando IP y puerto del servidor, realiza una solicitud de conexión (connect).
El servidor que estaba bloqueado por el “accept” crea un nuevo socket donde atenderá la conexión con ese cliente
particular, y vuelve a escuchar por conexiones en el socket original, es decir que el proceso servidor se bloquea de
nuevo, mientras en un proceso paralelo se maneja la conexión con el cliente. De este modo el servidor queda listo
para recibir una nueva solicitud de conexión de otro cliente, mientras maneja la comunicación con los clientes que se
encuentran conectados. Una vez que hay clientes conectados, tanto el proceso servidor como el proceso cliente
pueden enviar (send) y recibir (receive) datos utilizando el canal TCP. En cualquier momento, tanto cliente como
servidor pueden cerrar la conexión (close).
Figura 2: Primitivas de sockets TCP
Como se pudo apreciar, el servidor puede atender conexiones de distintos clientes en paralelo, para esto necesita
que tanto el proceso que escucha por conexiones (proceso que se bloquea) y los procesos que manejan las
comunicaciones con distintos clientes corran en paralelo. A estos subprocesos se les llaman “hilos” (threads en
inglés), y la posibilidad de correr múltiples hilos en paralelo se le llama “multi-threading”.
6
2.1.3. Números de puerto conocidos
Existen algunos números de puerto fijos para protocolos o aplicaciones bien conocidas, en general son todos
menores a 1024, por lo tanto, para no tener conflicto de puertos las aplicaciones que no utilicen estos protocolos
deben utilizar números de puerto mayores a 1024. Incluso en algunos sistemas operativos no está permitida la
creación de puertos con número menor a 1024. A continuación se muestra una lista reducida de números de puertos
conocidos:
● 7: ECHO
● 20: FTP (puerto de datos)
● 21: FTP (puerto de control)
● 22: SSH
● 23: TELNET
● 25: SMTP
● 53: DNS
● 80: HTTP
● 104: DICOM
● 110: POP3
● 143: IMAP
● 443: HTTPS (HTTP sobre SSL/TLS)
● 445: Active Directory
2.2. MLLP
Minimal Lower Layer Protocol3 es un protocolo muy simple implementado sobre TCP. El objetivo de MLLP es agregar
marcadores de principio y fin de los mensajes que se envían sobre TCP, para que el receptor sepa cuándo termina un
mensaje y comienza el siguiente, tarea que debe implementarse en las aplicaciones que reciben mensajes usando
solo TCP. MLLP es utilizado para implementar la comunicación de mensajería HL7 v2.x, aunque no es el único
protocolo sobre el que pueden enviarse mensajes HL7.
2.2.1. Definición de bloques
MLLP define bloques de datos delimitados en un flujo de datos TCP. El bloque debe comenzar con un byte llamado SB
(start block) con valor 0x0B (ASCII 11). Luego de SB se envían los datos del mensaje. Para marcar el fin del bloque se
utilizan dos bytes, el primero es EB (end block) con valor 0x1C (ASCII 28) y luego CR (carriage return) con valor 0x0D
(ASCII 13).
En definitiva, un paquete MLLP tendrá la forma: <SB>data<EB><CR>
Debe considerarse que los datos deben enviarse con una codificación orientada a bytes, dado que los caracteres
delimitadores son bytes. Por lo tanto no es posible usar MLLP con codificaciones como UTF-16 (2 bytes por carácter).
Considerando los ejemplos de cliente y servidor TCP de la sección previa, agregando los caracteres delimitadores
podrá implementar sus propios clientes y servidores MLLP.
http://www.hl7.org/documentcenter/public_temp_5E749496-1C23-BA17-0CCB6FA1750CF529/wg/inm/mllp_transport_specification.P
DF
7
2.3. HTTP
HyperText Transfer Protocol es un protocolo de capa de aplicación en la pila de protocolos de Internet. HTTP utiliza
TCP como protocolo de transporte, por lo tanto HTTP es un protocolo confiable. HTTP funciona en base al envío y
recepción de mensajes que tienen un formato estándar. Las aplicaciones cliente envían pedidos (request), y para
cada pedido el servidor envía una respuesta (response). Un pedido o respuesta HTTP podría transportarse en más de
un paquete TCP.
La Web (apócope de World Wide Web) está implementada sobre HTTP, razón por la cual a los servidores HTTP se les
llama “servidores Web”. La Web es la aplicación más utilizada para intercambio de recursos sobre Internet. Un
servidor Web puede atender pedidos de múltiples clientes de forma simultánea, los cuales solicitan recursos
mediante pedidos. Los recursos se solicitan mediante una URL (Localizador Universal de Recursos).
HTTP está especificado en:

http://www.w3.org/Protocols/rfc2616/rfc2616.html
2.3.1. URL
Las URLs son cadenas de caracteres que siguen el estándar RFC 1738. Las URLs se utilizan para localizar recursos que
serán solicitados a un servidor Web mediante un pedido HTTP, y el servidor Web devolverá el recurso solicitado en
una respuesta HTTP.
Formato de URL:
esquema
://
dominio
:
puerto
/
ruta
?
query_string
#
fragment_id
Esquema
Para acceder a recursos en la web se utiliza “http” o “https” en el caso de comunicación segura. También se utiliza
“mailto” cuando el recurso es una dirección de correo (ejemplo: mailto:pablo@openehr.org.es).
Dominio
Nombre del dominio donde está el servidor Web, por ejemplo “openehr.org.es”.
Puerto
Es el número de puerto donde el servidor Web espera llamadas, si se omite en la URL, se toma el puerto “80”.
Ruta
Es similar a una ruta de directorios para localizar un archivo, por ejemplo “dir1/dir2/dir3”.
Query String
Permite especificar un conjunto de parámetros en la URL, por ejemplo “nombre=pablo&curso=openehr”.
Fragment ID
Es un nombre que permite identificar una porción o fragmento del recurso solicitado. Por ejemplo, si el recurso es
una página HTML con un fragmento llamado “seccion2”, al usar ese nombre en la URL, el navegador web mostrará
directamente esa sección en lugar de mostrar el inicio de la página.
8
2.3.2. Métodos HTTP
Los pedidos HTTP deben especificar un método, el cual indica la acción a realizar sobre el recurso identificador por la
URL enviada en el mismo pedido. A continuación se comentan lo métodos más utilizados:
GET
Este método se utiliza para solicitar información del recurso identificador con la URL.
HEAD
Este método es idéntico a GET pero el servidor no devuelve el recurso solicitado. Se utiliza para realizar pruebas de
conexión o para solicitar información sobre el recurso sin tener que comunicar el mismo.
POST
Este método se utiliza para enviar datos al servidor, por ejemplo para agregar información a un recurso existente,
para agregar un recurso a una base de datos, para publicar un mensaje en un foro o lista de correos, entre otros usos.
PUT
Este método se utiliza para enviar datos de un recurso, los cuales deben ser modificados en el recurso residente en el
servidor. Si el recurso en esa URL no existe en el servidor, el servidor puede crear el recurso.
DELETE
Este método es utilizado para solicitar la eliminación de un recurso en el servidor.
2.3.3. Estructura de pedidos y respuestas HTTP
HTTP define el formato de los mensajes de pedido4 y respuesta5 . Ambos tienen un conjunto de cabezales y un
cuerpo. Los cabezales se especifican por su nombre, cada uno tiene un significado bien definido (ver RFC
2616-sec5.3), y por cada nombre hay un valor. El cuerpo de los mensajes se utiliza para transportar datos, por
ejemplo en un pedido que envía un archivo al servidor, el contenido del archivo es ubicado en el cuerpo del mensaje
de pedido. En el caso de solicitar un recurso, el contenido del recurso es ubicado en el cuerpo del mensaje de
respuesta.
Ejemplo de pedido HTTP sin cabezales:
GET http://www.google.com HTTP/1.1
Como se puede apreciar en el ejemplo, primero se indica el método HTTP a utilizar, luego el recurso que se está
pidiendo, puede indicarse como una URL absoluta o relativa, y por último la versión de HTTP utilizada.
El mismo ejemplo utilizando el cabezal “Host” y una URL relativa:
GET / HTTP/1.1
Host: www.google.com
Todos los cabezales se deben especificar con el formato “Nombre-Cabezal: Valor”6 .
4
ttp://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5
h
5

http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6
6

http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
9
Se debe notar que cada línea en el pedido debe terminar en <CR><LF> lo que es lo mismo que “\r\n” en un lenguaje
de programación como Java o Groovy. Para marcar la terminación del pedido y para separar entre cabezales y cuerpo
se utiliza <CR><LF><CR><LF>. Entonces el ejemplo anterior sería:
GET / HTTP/1.1<CR><LF>
Host: www.google.com<CR><LF>
<CR><LF>
Probar este ejemplo en TELNET (

http://es.wikipedia.org/wiki/Telnet
):
Nota: por cada “<CR><LF>” presionar la tecla enter.
telnet google.com 80<CR><LF>

GET / HTTP/1.1<CR><LF>
Host: www.google.com<CR><LF>
<CR><LF>
Podrá ver una respuesta del servidor similar a esta:
HTTP/1.1 302 Found

Location: http://www.google.com.uy
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Date: Sun, 26 Jan 2014 22:02:20 GMT
Server: gws
Content-Length: 262
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">

<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved <A HREF="http://www.google.com.uy/">here</A>.
</BODY></HTML>
La primera línea de la respuesta especifica la versión de HTTP utilizada, un código de estado y el nombre asociado al
código. En la siguiente sección se describirán distintos códigos de estado. Luego hay una lista de cabezales de
respuesta, por ejemplo “Content-Type” indica que en el cuerpo de la respuesta se esperan datos de tipo text/html, o
sea una página Web. La respuesta puede contener cualquier tipo de recurso, tanto una página web como una imagen
o un archivo PDF. A continuación se listan algunos tipos comunes:
text/plain
La respuesta contiene datos en texto plano (sin estructura).
text/html
La respuesta contiene datos HTML (una página Web).
text/xml
La respuesta contiene datos estructurados en formato XML (ver sección 6.2)
application/xml
10
Similar a la anterior, pero es preferida por no tener problemas con la codificación.7
image/jpeg
La respuesta contiene datos binarios de una imagen codificada en JPEG.
image/jp2
La respuesta contiene datos binarios de una imagen codificada en JPEG2000.
application/pdf
La respuesta contiene datos binarios de un documento PDF.
application/json
La respuesta contiene datos estructurados en formato JSON (ver sección 6.1).
IANA (Internet Assigned Numbers Authority) es la organización que mantiene y asigna estos identificadores para
distintos tipos de medios. En su sitio Web puede encontrarse una lista completa de tipos:
http://www.iana.org/assignments/media-types/media-types.xhtml
El cabezal “Content-Length” indica la cantidad de caracteres (bytes) contenidos en el cuerpo de la respuesta HTTP.
Luego del último cabezal, dónde aparece la tira de caracteres <CR><LF><CR><LF>, se encuentra el código HTML
devuelto por el servidor.
Algunos comentarios sobre TELNET. Este programa funciona tanto con nombres de dominio como con direcciones IP.
Cuando se especifica un nombre de dominio como en el caso de “telnet google.com 80”, internamente se realiza una
búsqueda DNS, que básicamente busca la dirección IP correspondiente al dominio 8. Existen herramientas Web que
permiten hacer búsquedas DNS fácilmente, como:
http://mxtoolbox.com/SuperTool.aspx?action=a%3agoogle.com&run=toolpage
.
Notar que se utilizó el puerto 80 que es el puerto por defecto utilizado por servidores HTTP.
2.3.4. Códigos de estado HTTP
Los códigos de estado se utilizan en las respuestas HTTP para darle al cliente información sobre el pedido que fue
realizado y la respuesta a ese pedido enviada desde el servidor.
Los códigos de estado se clasifican en cinco grandes grupos:
● 1xx: Códigos de información

● 2xx: Códigos de éxito
● 3xx: Códigos de redirección de pedidos
● 4xx: Códigos de error en el cliente
● 5xx: Códigos de error en el servidor
7
ttp://www.grauw.nl/blog/entry/489
h
8

http://es.wikipedia.org/wiki/Domain_Name_System
11
Los códigos de redirección se utilizan para indicar que un cierto recurso fue movido (su URL cambió) y el servidor
devuelve la URL donde el cliente puede encontrar el recurso. Entonces se realiza un nuevo pedido, en cuyo caso
debería recibir un código 2xx.
A continuación se listan algunos de códigos más comunes:
● 200 OK: respuesta ante una solicitud correcta.

● 301 Moved Permanently: este y todos los pedidos futuros deben ser redirigidos a una URL dada ya que, en la
URL solicitada, el recurso ya no existe.
● 302 Found: el pedido debe ser redirigido a una URL dada.
● 304 Not modified: el recurso solicitado no fue modificado en el servidor desde el último pedido, permite
obtenerlo del caché local.
● 400 Bad Request: no se puede resolver el pedido porque contiene errores de sintaxis.
● 403 Forbidden: acceso no autorizado a un recurso.
● 500 Internal Server Error: ocurrió algún error en el servidor al intentar resolver el pedido.
● 503 Service Unavailable: el servidor no se encuentra disponible (ej. por mantenimiento).
Aquí puede encontrar una lista completa de códigos de estado HTTP:

http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
12
2.4. SOAP
Simple Object Access Protocol permite el intercambio de información estructurada utilizando el formato XML y el
protocolo HTTP para el transporte. Si bien HTTP es solo uno de los protocolos que pueden usarse para SOAP, es el
más usado. SOAP no define la semántica de la información a ser intercambiada, se limita a definir las reglas de
codificación y decodificación de objetos y estructuras de datos para ser comunicadas entre sistemas heterogéneos y
distribuidos. Además define tipos de datos para las estructuras a ser comunicadas. Inicialmente, SOAP surgió como
una evolución del protocolo XML-RPC http://xmlrpc.scripting.com/spec.html
SOAP se recomienda cuando se necesita trabajar con objetos que residen en sistemas remotos como si fueran
objetos locales. No se recomienda cuando se necesita intercambiar bloques de texto o mensajes con un formato
definido por otro protocolo de comunicación y ese formato no es XML, como el caso de los mensajes HL7 v2.x.
Es importante destacar que a nivel de las tecnologías utilizadas en las aplicaciones que se comunican mediante SOAP,
es frecuente encontrar generadores de código que trabajan en función de las definiciones de los servicios SOAP.
Estas definiciones están expresadas en WSDL9 (Web Service Definition Language). El código generado permite a las
aplicaciones comunicarse abstrayendo la capa de comunicación de la capa de aplicación, por lo que el cliente SOAP
trabaja contra objetos que "viven" dentro de la aplicación, pero esos objetos son obtenidos de servicios remotos
(servidores SOAP). Herramientas como wsdl2java 10 del framework Apache CXF permiten hacer esto.
Tampoco hay que confundir el protocolo SOAP con la Arquitectura Orientada a Servicios (SOA). SOA está compuesta
de una serie de principios y buenas prácticas para la implementación de sistemas distribuidos, donde SOAP es solo
uno de los posibles protocolos que pueden usarse para implementar una SOA. Otra posibilidad es utilizar los
principios REST11 12 13 para crear servicios sobre HTTP utilizando JSON o XML como codificación de recursos
(mensajes).
Recursos útiles:
Ejemplos de servicios SOAP online para probar clientes:

http://www.service-repository.com
Explicación de Web Services SOAP en Java:
https://www.youtube.com/watch?v=mKjvKPlb1rA
2.4.1. Terminología SOAP 1.2
En esta sección se presentan algunos de los términos utilizados para describir los componentes de SOAP14 .
SOAP Binding
Conjunto de reglas que especifican cómo comunicar mensajes SOAP dentro de, o sobre otro, protocolo. Ver SOAP
Protocol Binding Framework15 .
SOAP Node
9
ttp://www.w3.org/TR/wsdl
h
10

http://cxf.apache.org/docs/wsdl-to-java.html
11

https://www.servage.net/blog/2013/04/08/rest-principles-explained/
12

https://github.com/WhiteHouse/api-standards
13

https://www.nsa.gov/ia/_files/support/guidelines_implementation_rest.pdf
14

http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
15

http://www.w3.org/TR/soap12-part1/#transpbindframew
13
Es una unidad lógica de procesamiento de mensajes SOAP que puede transmitir, recibir, procesar y retransmitir
mensajes.
SOAP Message
El mensaje es la unidad básica de comunicación entre nodos SOAP. Puede ser una invocación a un servicio o una
respuesta a una invocación. Si ocurrió un error, el body de la respuesta contendrá un elemento SOAP Fault.
SOAP Part
El concepto de parte se agrega en la extensión de SOAP para soportar datos adjuntos. Un mensaje SOAP tiene una
parte principal que contiene el sobre (envelope) y cero o más partes secundarias donde ubicar datos adjuntos. Estos
datos pueden no ser codificados en XML, por lo que pueden incluirse datos binarios y en otras codificaciones no
compatibles con la codificación de datos XML en el body del envelope16 .
SOAP Envelope
El sobre es el elemento de información más externo en un mensaje SOAP que aparece en el XML del mensaje.
SOAP Header
Colección de cero o más bloques de cabezal SOAP, cada uno de los cuales puede estar destinado a un receptor en el
camino del mensaje SOAP17 .
SOAP Header Block

Elemento de información utilizado para delimitar los datos que constituyen lógicamente una única unidad
computacional en el cabezal SOAP. El tipo del SOAP Header Block es definido por el nombre expandido del XML del
SOAP Header Block18
SOAP Body
Colección de cero o más elementos de información destinados para el receptor final en el camino del mensaje SOAP19
.
SOAP Fault
Elemento de información SOAP que contiene información de errores generados por un nodo SOAP20 .
SOAP Sender
Nodo que transmite un mensaje SOAP.
SOAP Receiver
Nodo que acepta un mensaje SOAP.
SOAP Message Path

Conjunto de nodos SOAP por los que ha pasado un único mensaje SOAP. El uso más común es la comunicación entre
dos nodos. Los nodos intermedios son a la vez Receiver y Sender.
16
ttp://www.w3.org/TR/soap12-af/
h
17

http://www.w3schools.com/soap/soap_envelope.asp
18

http://www.w3schools.com/soap/soap_header.asp
19

http://www.w3.org/TR/soap12-part1/#soapbody
20

http://www.w3schools.com/soap/soap_fault.asp
14
2.4.2. Estructura de mensajes SOAP
El siguiente diagrama muestra todos los componentes de un mensaje SOAP. En el caso de envío de mensajes sin
adjuntos, el receptor del mensaje solo verá contenido XML correspondiente al SOAP Envelope. En la siguiente sección
se muestran ejemplos de mensajes de invocación y respuesta de servicios SOAP.
Figura 3: estructura de mensajes SOAP
Puede tomar como referencia la implementación de SOAPMessage en Java21 , donde verá que cada parte del mensaje
se puede obtener mediante métodos cómo:
SOAPPart sp = message.getSOAPPart();
SOAPEnvelope se = sp.getEnvelope();
SOAPBody sb = se.getBody();
SOAPHeader sh = se.getHeader();
21

http://docs.oracle.com/javase/7/docs/api/javax/xml/soap/SOAPMessage.html
15
2.4.3. Ejemplos de mensajes SOAP sobre HTTP
Si bien los mensajes SOAP pueden ser transportados en distintos protocolos de comunicación, el protocolo más
utilizado para este fin es HTTP. Si utilizamos alguna herramienta para visualizar las invocaciones y respuestas SOAP,
como Wireshark22 o SoapUI23 , a nivel de HTTP veremos mensajes que siguen las siguientes estructuras.
Invocación del servicio GetLastTradePrice con un parámetro symbol=DIS
POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:
GetLastTradePricexmlns:m="Some-URI">
<symbol>
DIS
</symbol>
</m:
GetLastTradePrice
>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Respuesta del servicio con una variable Price=34.5
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<
Price
>
34.5
</
Price
>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Más ejemplos:
● http://en.wikipedia.org/wiki/SOAP
● http://es.wikipedia.org/wiki/Simple_Object_Access_Protocol
La primera característica que podemos notar de estos mensajes es que el método HTTP utilizado en el pedido es
POST y que los datos del pedido van en el cuerpo del mensaje HTTP. Lo segundo es que el Content-Type del pedido es
"text/xml", debido a que los datos están en formato XML. Este valor es utilizado por SOAP 1.1, pero en SOAP 1.2 se
utiliza el valor "application/soap+xml".
Otro elemento a notar es que SOAP 1.1 define un cabezal nuevo para HTTP: SOAPAction24 , que es utilizado para
indicar la intención del pedido SOAP HTTP mediante una URI. Esta URI puede ser resuelta (ser una URL) o no, y SOAP
no establece ninguna regla sobre su formato. Un cliente HTTP debe utilizar este cabezal cuando envía pedidos SOAP
22
ttps://www.wireshark.org/
h
23

http://www.soapui.org/
24

http://static.userland.com/xmlRpcCom/soap/SOAPv11.htm#_Toc478383528
16
HTTP. En SOAP 1.2 el valor del SOAP Action es incluido en el cabezal Content-Type25 . La ocurrencia del cabezal
SOAPAction en el pedido HTTP puede utilizarse para que los componentes de una red diferencien entre tráfico HTTP
puro y SOAP HTTP. Su valor puede ser vacío, en donde se entiende que la intención del pedido está dada por la URL
del pedido HTTP.
¿Cómo distinguir entre mensajes SOAP 1.1. y SOAP 1.2?
El primer factor es que el cabezal HTTP SOAPAction es exclusivo de SOAP 1.1. Por otro lado los esquemas para 1.1 y
para 1.2 son distintos. SOAP 1.1 utiliza "http://schemas.xmlsoap.org/soap/envelope/", mientras que SOAP 1.2 utiliza
"
http://www.w3.org/2001/12/soap-envelope ".
25

http://www.xml.com/pub/a/ws/2003/06/10/salz.html
17
3. Formatos de Mensajería
En esta sección veremos distintos formatos utilizados comúnmente para intercambiar información clínica y
administrativa entre sistemas de información en salud.
3.1. XML
EXtensible Markup Language26 es una sintaxis basada en etiquetas que representan elementos, los cuales pueden
tener atributos. XML es un estándar del W3C27 . El objetivo de XML es poder ser legible por humanos pero también
procesable por programa. Comparado con JSON es más complejo de leer por humanos por contener más información
para representar los mismos datos, pero ambos formatos son igualmente procesables por programa.
Cualquier estructura de datos puede ser representada en XML. Como ya se mencionó, el protocolo SOAP utiliza XML
para representar objetos estructurados. Todos los lenguajes de programación modernos ofrecen soporte para el
procesamiento de XML.
Aparte de SOAP, existen otros estándares que utilizan XML como formato para representar datos, como RSS, Atom y
XHTML. También las versiones modernas de los formatos de MS Office utilizan XML, por ejemplo documentos DOCX
o u hojas de cálculo XSLX.
3.1.1. Comentarios sobre el formato XML
A continuación se muestra un ejemplo de cómo podría codificarse el registro de una persona utilizando XML:
<person>
<firstname>Pablo</firstname>
<lastname>Pazos</lastname>
<age>32</age>
<isAnEHealthNerd>true</isAnEHealthNerd>
<likes>
<item>medical informatics</item>
<item>old music</item>
<item>thriller movies</item>
</likes>
</person>
Una alternative utilizando atributos de elementos:
<person>
<names firstname="Pablo" lastname="Pazos" />
<age>32</age>
<isAnEHealthNerd>true</isAnEHealthNerd>
<likes>
<item>medical informatics</item>
<item>old music</item>
<item>thriller movies</item>
</likes>
</person>
26
ttp://www.w3.org/XML/
h
27

http://www.w3.org/
18
Algunas reglas generales de XML:
● Las etiquetas representan un elemento por su nombre.

● Siempre debe haber una etiqueta raíz que englobe todo el documento XML, en este caso “person”.
● Todas las etiquetas deben abrirse <a> y cerrarse </a>. Cuando la etiqueta no tiene un valor de texto, se
puede especificar como <a />
● Todas las etiquetas tienen un nombre, y para cerrar una etiqueta debe usarse el mismo nombre que para
abrirla.
● No se pueden intercalar aperturas y cerraduras, ej. <a><b></a></b> es inválido.
● Los elementos de una lista también deben estar dentro de etiquetas, en este caso para “likes”, cada
elemento está marcado en “item”.
● Los atributos de los elementos deben declararse dentro de la apertura de la etiqueta.
● Los valores de los atributos deben estar siempre entre comillas.
Existen múltiples herramientas para validar documentos XML, por ejemplo:

http://www.xmlvalidation.com/
3.2. JSON
JavaScript Object Notation28 es un formato liviano de intercambio de datos estructurados entre sistemas. Está basado
en un subconjunto de la sintaxis del lenguaje de programación Javascript, por lo que un objeto JSON es un objeto
Javascript válido. JSON es muy utilizado en aplicaciones Web ya que Javascript es implementado por todos los
navegadores Web modernos, incluso en dispositivos móviles. Por este motivo, JSON es una gran herramienta para la
comunicación entre navegadores y servidores Web, sin necesidad de instalar agregados o extensiones al navegador
ni utilizar otras tecnologías como Flash o Applets Java.
JSON es un formato fácilmente legible por humanos, y su sintaxis puede ser procesada por cualquier lenguaje de
programación moderno.
Frente a alternativas para representar datos estructurados, como XML, tiene las ventajas antes mencionadas: más
liviano y más fácil de leer por humanos.
En su sitio oficial es posible acceder a la especificación de la sintaxis y encontrar decenas de herramientas que
implementan JSON en distintas tecnologías.
3.2.1. Comentarios sobre el formato JSON
A continuación se muestra un ejemplo de cómo se podría representar una persona utilizando JSON:
{
"firstname": "Pablo",
"lastname": "Pazos",
"age": 32,
"isAnEHealthNerd": true,
"likes": [
"medical informatics",
"old music",
"thriller movies"
]
}
28

http://www.json.org/
19
Para validar las estructuras JSON se utiliza la herramienta JSONLint29 , construida por el creador de JSON, Douglas
Crockford. Existen múltiples herramientas online30 tanto para editar JSON como para validar su estructura.
3.3. ER7
Encoding Rules para HL7 es una serie de reglas de codificación basada en el formato EDI (Electronic Data
Interchange), donde se representa un mensaje como un conjunto de segmentos y campos definidos mediante
delimitadores.
ER7 define los segmentos separándolos mediante un salto de línea <CR> (ASCII 0x0D). Cada segmento tiene un
identificador codificado en tres caracteres, y está compuesto de varios campos separados por el delimitador de
segmento, por defecto es una barra vertical “|”. Cada campo puede tener varios componentes, que en general se
separan utilizando el carácter “^” como delimitador. La estructura interna de cada campo dependerá del tipo de dato
asociado al mismo.
Ejemplo de mensaje HL7 v2.5 para admitir a un paciente:
MSH
|^~\&|SRC_APP|SRC_CNTR|TARGET_APP|TARGET_CNTR|201401271408||ADTÂ04ÂDT_A01|123456|T|2.5|
PID
|||PATID||PAZOS^PABLO||19811024|M|||1234 MIGUEL BARREIRO^^Montevideo^Montevideo^11300ÛY||(598)123-4567|
PV1
|||BOX 1^^^DEPTO. EMERGENCIA^^ÊDIFICIO CENTRAL||||123^HOUSE^GREGORY|
En la sección 5.1.1 se verá el formato de mensajes HL7 v2.x.
HL7 también define reglas de codificación de mensajes en XML 31. Si bien XML puede presentar algunas ventajas como
legibilidad y facilidad de procesamiento, también presenta un gran aumento en el tamaño total de los mensajes32 .
29
ttp://jsonlint.com/
h
30

http://jsonviewer.stack.hu/
31

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=275
32

https://msdn.microsoft.com/en-us/library/ee409267.aspx
20
4. Estándares XML
4.1. XPath
XPath, el lenguaje de rutas de XML, es un lenguaje de consultas el cual, utilizando la estructura jerárquica de XML,
permite seleccionar nodos de un documento XML. Una ruta consiste en una secuencia de pasos, y cada paso tiene
tres componentes:
● eje: especifica la relación entre los árboles de los nodos seleccionados por el paso y el nodo de contexto.
● prueba de nodo: especifica el tipo de nodo y el nombre expandido de los nodos seleccionados por el paso.
● predicado: cero o más predicados pueden ser parte de un paso, son expresiones que permiten refinar la
selección de nodos del paso.
Ejemplo de paso: eje::prueba[predicado/s]
En una XPath el primer "/" representa al nodo raíz, mientras que "/" subsecuentes representan los separadores de
pasos. Debe tener en cuenta que cada paso puede retornar una secuencia de nodos o valores atómicos, pero no
ambos.
4.1.1. Especificadores de ejes
Las especificaciones de ejes indican el sentido del recorrido del árbol representado por el XML. Los ejes disponibles
son:
Sintaxis completa Sintaxis abreviada Comentarios

ancestor Devuelve los nodos ancestros del nodo actual.
ancestor-or-self Devuelve los ancestros del nodo actual y el nodo actual.
Devuelve los atributos del nodo actual.
@attr abrevia attribute::attr
Ejemplo
: todos los atributos del typeId de un CDA
attribute @ /a:ClinicalDocument/a:typeId/@*
Ejemplo
: todos los atributos de los nodos hijo de recordTarget en un
CDA:
/a:ClinicalDocument/a:recordTarget//*/@*
Devuelve los nodos hijos del nodo actual.
child nombre_del_nodo nombre_del_nodo abrevia child::nombre_del_nodo
Ejemplo
: selecciona todos los nodos hijos directos del nodo padre
21
"ClinicalDocument"
/a:ClinicalDocument/*
http://www.quackit.com/xml/tutorial/xpath_axis.cfm
descendant Ejemplo
: selecciona todos los descendientes de "ClinicalDocument"
/a:ClinicalDocument/descendant::*
Ejemplo: selecciona todos los nodos descendientes de "recordTarget"
dentro de un CDA
descendant-or-self //
/a:ClinicalDocument/a:recordTarget//*
following Nodos que aparecen luego del nodo actual.
following-sibling Nodos hermanos que aparecen luego del nodo actual.
namespace Espacio de nombres del nodo actual.
.. abrevia parent::node()
Ejemplo
: selecciona el "recordTarget" en un CDA, yendo hacia su
parent ..
subnodo "patientRole" y seleccionando su parent
/a:ClinicalDocument/a:recordTarget/a:patientRole/..
Nodos que aparecen antesdel nodo actual.
Ejemplo: selecciona todos los nodos que aparecen antes del nodo
preceding
"patientRole" en un CDA
/a:ClinicalDocument/a:recordTarget/a:patientRole/preceding::*
Nodos hermanos que aparecen antes del nodo actual.
Ejemplo
: selecciona todo los nodos hermanos que aparecen antes del
preceding-sibling nodo "patient" en un CDA
/a:ClinicalDocument/a:recordTarget/a:patientRole/a:patient/preceding-si
bling::*
self . . abrevia self::node()
4.1.2. Prueba de nodo

Las pruebas de nodo son condiciones sobre los nombres de nodos o tipos de nodos (elemento, atributo, texto,
comentario, etc.) Permiten determinar cuáles nodos del eje actual son seleccionados por un paso en la XPath.
Prueba Comentario Ejemplos

Ejemplo
: Selecciona todos los atributos del elemento "code" en un
CDA
Encuentra todos los nodos,
independientemente del /a:ClinicalDocument/a:code/@*
*
nombre. Sirve para
elementos o atributos. Ejemplo: Selecciona todos los elementos hijos del elemento
"recordTarget/patientRole"
22
/a:ClinicalDocument/a:recordTarget/a:patientRole/*
Si el documento XML define
Si en un CDA al espacio de nombres xmlns="urn:hl7-org:v3" se le
prefijo: un espacio de nombres
asigna el prefijo "a", ver ejemplos de arriba para *
(namespace).
Ejemplo : Encuentra los comentarios dentro del elemento
"ClinicalDocument" en un CDA
/a:ClinicalDocument/comment()
Encuentra comentarios en en
comment()
el XML. Ejemplo
: Encuentra los comentarios dentro del cuerpo de un
documento CDA (dentro de cualquier nodo descendiente, notar el eje
"//")
/a:ClinicalDocument/a:component//comment()
Ejemplo
: Encuentra el texto del elemento "title" en un CDA
Encuentra nodos de texto en
text()
el XML.
/a:ClinicalDocument/a:title/text()
Ejemplo : Encuentra todos los nodos hijos, incluyendo comentarios, de
"ClinicalDocument" en un CDA
node() Encuentra cualquier nodo.
/a:ClinicalDocument/node()
4.1.3. Predicados
Los predicados permiten seleccionar nodos específicos mediante condiciones, que cuando se evalúan a "verdadero",
devuelven el nodo correspondiente. Los predicados se especifican entre paréntesis rectos dentro de la XPath.
Función /
Comentario Ejemplos
Operador
| Unión de dos conjuntos de nodos
Ejemplo: selecciona todos los nodos cuyo nombre
Operadores booleanos, not es una no tiene largo 6
and, or, not()
función.
//*[not(string-length(local-name()) = 6)]
+, -, *, div, mod Operadores aritméticos.
Ejemplo
: Selecciona la sección de un CDA
=, !=, <, >, <=, >= Operadores de comparación.
/a:ClinicalDocument//a:component/a:section[a:co
de/@code="10155-0"]
Ejemplo
: selecciona todos los nodos cuyo nombre
empieza con "effective"
concat(),
Funciones sobre tiras de caracteres.
substring(), //*[starts-with(local-name(), "effective")]
substring-before(),
Referencia:
contains(),
http://www.quackit.com/xml/tutorial/xpa
string-length(), Ejemplo : selecciona todos los nodos cuyo nombre
th_string_functions.cfm
starts-with() tiene largo 6
//*[string-length(local-name()) = 6]
23
sum(), round(),
Funciones sobre números.
floor(), ceiling()
Ejemplo: seleccionar todos los nodos "id" dentro
de un CDA
Funciones para obtener propiedades de
los nodos.
//*[local-name() = "id"]
+local-name
: nombre sin el prefijo del
espacio de nombres.
Ejemplo: seleccionar todos los nodos dentro del
espacio de nombres "urn:hl7-org:v3"
name(), +name : nombre del nodo actual
local-name(), incluyendo el prefijo asignado al espacio
//*[namespace-uri() = "urn:hl7-org:v3"]
namespace-uri() de nombres, se diferencia de local-name
cuando los nodos tienen prefijo en el
XML, si no es el mismo valor.
Ejemplo : selecciona todos los nodos
"effectiveTime" dentro del espacio de nombres
+
namespace-uri
: uri del namespace del
"urn:hl7-org:v3"
nodo actual.
//*[local-name() = "effectiveTime" and
namespace-uri() = "urn:hl7-org:v3"]
Ejemplo : selecciona todos los nodos descendientes
de "ClinicalDocument" que tienen más de 1
atributo
/a:ClinicalDocument//*[count(@*) > 1]
Ejemplo
: selecciona los nodos que tiene uno o más
Funciones para obtener información
subnodos "id" dentro de un CDA
sobre el contexto de procesamiento.
//*[count(a:id) > 0]
+
position: número que representa la
posición del nodo en la secuencia actual
de nodos que están siendo procesados.
Ejemplo: selecciona todas los nodos, que dentro
position(), last(),
de su nodo padre sean el segundo nodo
count() +last
: última aparición de un nodo hijo
dentro de un nodo padre, si sólo hay un
//*[position() = 2]
subnodo, ese será el primero y el último.
+
count: cuenta las ocurrencias de un
Ejemplo: selecciona todos los últimos nodos hijo
nodo o atributo.
dentro de cada nodo padre
//*[last()]
Ejemplo: selecciona todos los penúltimos nodos

dentro de cada nodo padre
//*[position() = last()-1]
string(), number(),
Funciones de conversión de tipos.
boolean()
Ejemplo: selecciona todos los subnodos con un
Devuelve los nodos que tienen un atributo "code" de un CDA
@atributo
atributo llamado "atributo".
//*[@code]
24
Ejemplo: selecciona todos los subnodos con
atributos "code" y "codeSystem" de un CDA
//*[@code and @codeSystem]
4.2. XSD
XML Schema Definition (XSD) es una recomendación del W3C, donde se especifica un tipo especial de documento
XML que es utilizado para describir los elementos de cualquier documento XML. Estas descripciones se especifican
como un conjunto de reglas y restricciones, las cuales se pueden verificar contra un documento XML para decir si el
mismo cumple o no con un XSD. En el caso de intercambio de datos entre sistemas, utilizando XML, el uso de XSD es
importante para verificar la validez de los datos emitidos y recibidos, para evitar errores de programación, errores de
comunicación y errores de procesamiento.
Un XSD está compuesto por los siguientes elementos:
1. Declaración de elementos : define las propiedades de los elementos del XML, como su nombre, espacio de
nombres, el tipo asociado al elemento, qué restricciones tendrá, que atributos tendrá, etc.
2. Declaración de atributos : define las propiedades de los atributos de un elemento XML, como su nombre,
espacio de nombres, al tipo asociado al atributo y restricciones sobre los posibles valores que podrá tener el
atributo.
3. Declaración de tipos : los tipos pueden ser simples o complejos, los tipos simples pueden contener
restricciones sobre los tipos primitivos, los tipos complejos pueden contener restricciones, sub-elementos y
atributos.
4. Tipos de datos primitivos :
a. anyURI: representa URIs absolutas ó relativas.
b. base64Binary: representa datos binarios codificados como caracteres en base 64.
c. hexBinary: representa datos binarios codificados como caracteres hexadecimales.
d. boolean: representa valores binarios de verdad (true, false).
e. decimal: representa un subconjunto de los números reales, obtenidos de multiplicar un número
entero por una potencia de 10 no positiva (i * 10^-n, donde i, n son enteros, y n >= 0).
f. double: representa números de punto flotante de precisión doble de 64 bits (m * 2ê, donde m es un
número entero, |m| < 2^53, y e es un entero tal que -1075 <= e <= 970).
g. duration: representa una duración temporal de 6 componentes: año, mes, día, horas, minutos,
segundos.
h. float: representa números de punto flotante de 32 bits (m * 2ê, donde m es un entero, |n| < 2^24, y
e es un entero tal que -149 <= e <= 104).
i. gDay: representa un día específico en cualquier mes.
j. gMonth: representa un mes específico en cualquier año.
k. gMonthDay: representa un día específico dentro de un mes específico.
l. gYear: representa un año específico.
m. gYearMonth: representa un mes específico en un año específico.
n. NOTATION: representa el tipo de atributo NOTATION de la especificación XML 1.0
o. QName: representa un nombre calificado dentro del XML, se va a quitar de la recomendación.
p. string: representa una cadena de caracteres de tamaño acotado.
q. dateTime: representa un punto en el tiempo, con valores para el año, mes, día , horas, minutos,
segundos, y zona horaria.
r. date: representa un intervalo de tiempo de exáctamente un día de duración, que comienza al inicio
del día en cada zona horaria. y termina en el momento que comienza el nuevo día.
s. time: representa un instante de tiempo que se repite diariamente.
25
5. Tipos de datos derivados :
a. normalizedString: representa un string que no contiene los caracteres de retorno de carro, nueva
línea, o tabulador.
b. token: es un normalizedString que no contiene espacios en blanco ni al inicio ni al final, y no tiene
secuencias de dos o más espacios consecutivos.
c. language: representa un identificador de lenguage según la RFC 306633 . Es un token.
d. NMTOKEN: representa el tipo de atributo NMTOKEN de XML 1.0. Es un token.
e. NMTOKENS: representa el tipo de atributo NMTOKENS de XML 1.0. Es un NMTOKEN.
f. Name: representa los nombres válidos en XML, es un token que comienza con una letra o con alguno
de estos caracteres: '_' | ':'.
g. NCName: representa nombres "no colonizados", básicamente es un Name que no puede tener ":".
h. ID: representa el tipo de atributo ID de XML. Es un NCName que aparece una sola vez en un
documento.
i. IDREF: representa el tipo de atributo IDREF de XML. Es un NCName que se utiliza como referencia a
otro elemento que tiene un atributo ID.
j. IDREFS: representa el tipo de atributo IDREFS de XML. Es un conjunto no vacío de IDREF.
k. ENTITY: representa el tipo de atributo ENTITY de XML. Es un NCName que representa de forma
simbólica información dentro de un XML. Por ejemplo la entidad "&" representa el caracter "&".
l. ENTITIES: representa el tipo de atributo ENTITIES de XML. Es un conjunto no vacío de ENTITY.
m. integer: representa un decimal cuyo atributo "fractionDigits" es 0, no permitiendo dígitos decimales.
n. nonPositiveInteger: es un integer cuyo atributo "maxInclusive" es 0.
o. negativeInteger: es un nonPositiveInteger cuyo atributo "maxInclusive" es -1.
p. long: es un integer cuyo atributo "maxInclusive" es 9223372036854775807 y su atributo
"minInclusive" es -9223372036854775808.
q. int: es un long cuyo atributo "maxInclusive" es 2147483647, y "minInclusive" es -2147483648.
r. short: es un int cuyo atributo "maxInclusive" es 32767, y "minInclusive" es -32768.
s. byte: es un short cuyo atributo "maxInclusive" es 127, y "minInclusive" es -128.
t. nonNegativeInteger: es un integer cuyo atributo "minInclusive" es 0.
u. unsignedLong: es un nonNegativeInteger cuyo atributo "maxInclusive" es 18446744073709551615.
v. unsignedInt: es un unsignedLong cuyo atributo "maxInclusive" es 4294967295.
w. unsignedShort: es un unsignedInt cuyo atributo "maxInclusive" es 65535.
x. unsignedByte: es un unsignedShort cuyo atributo "maxInclusive" es 255.
y. positiveInteger: es un nonNegativeInteger cuyo atributo "minInclusive" es 1.
33

http://www.w3.org/International/articles/language-tags/
26
Diagrama de tipos de XML34
Nota: El protocolo SOAP hace uso extensivo de esquemas XML, donde se definen las estructuras internas de los
objetos, serializados a XML, que se intercambian entre el cliente y el proveedor del servicio SOAP.
34

http://www.w3.org/TR/xmlschema-2
27
4.2.1. Esquema para documentos HL7 CDA
En esta sección expondremos un fragmento del XSD de CDA, como ejemplo aplicado a la interoperabilidad en salud.
4.2.1.1. Definición de tipo para el elemento ClinicalDocument
En esta definición podemos ver los elementos correspondientes a los datos del paciente (recordTarget), del autor del
documento (author) y de la organización encargada de la custodia del documento (custodian), entre otros
elementos.
<xs:complexType name="POCD_MT000040.ClinicalDocument">
<xs:sequence>
<xs:element name="
realmCode
" type="CS" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="
typeId
" type="POCD_MT000040.InfrastructureRoot.typeId"/>
<xs:element name="
templateId
" type="II" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="
id
" type="II"/>
<xs:element name="
code
" type="CE"/>
<xs:element name="
title
" type="ST" minOccurs="0"/>
<xs:element name="
effectiveTime
" type="TS"/>
<xs:element name="
confidentialityCode
" type="CE"/>
<xs:element name="
languageCode
" type="CS" minOccurs="0"/>
<xs:element name="
setId
" type="II" minOccurs="0"/>
<xs:element name="
versionNumber
" type="INT" minOccurs="0"/>
<xs:element name="
copyTime
" type="TS" minOccurs="0"/>
<xs:element name="
recordTarget
" type="POCD_MT000040.RecordTarget" maxOccurs="unbounded"/>
<xs:element name="
author
" type="POCD_MT000040.Author" maxOccurs="unbounded"/>
<xs:element name="
dataEnterer
" type="POCD_MT000040.DataEnterer" minOccurs="0"/>
<xs:element name="
informant
" type="POCD_MT000040.Informant12" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="
custodian
" type="POCD_MT000040.Custodian"/>
<xs:element name="
informationRecipient
" type="POCD_MT000040.InformationRecipient" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="
legalAuthenticator
" type="POCD_MT000040.LegalAuthenticator" minOccurs="0"/>
<xs:element name="
authenticator
" type="POCD_MT000040.Authenticator" minOccurs="0"
<xs:element name="
participant
" type="POCD_MT000040.Participant1" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="
inFulfillmentOf
" type="POCD_MT000040.InFulfillmentOf" minOccurs="0"
<xs:element name="
documentationOf
" type="POCD_MT000040.DocumentationOf" minOccurs="0"
<xs:element name="
relatedDocument
" type="POCD_MT000040.RelatedDocument" minOccurs="0"
<xs:element name="
authorization
" type="POCD_MT000040.Authorization" minOccurs="0"
<xs:element name="
componentOf
" type="POCD_MT000040.Component1" minOccurs="0"/>
<xs:element name="
component
" type="POCD_MT000040.Component2"/>
</xs:sequence>
<xs:attribute name="
nullFlavor
" type="NullFlavor" use="optional"/>
classCode
" type="ActClassClinicalDocument" use="optional" fixed="DOCCLIN"/>
moodCode
" type="ActMood" use="optional" fixed="EVN"/>
</xs:complexType>
28
4.2.1.2. Definición de tipo para el elemento recordTarget
El siguiente extracto de XSD define la estructura interna del nodo que representa al paciente dentro de los
documentos CDA.
<xs:complexType name="POCD_MT000040.RecordTarget">
<xs:sequence>
<xs:element name="
realmCode
" type="CS" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="
typeId
" type="POCD_MT000040.InfrastructureRoot.typeId" minOccurs="0"/>
<xs:element name="
templateId
" type="II" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="
patientRole
" type="POCD_MT000040.PatientRole"/>
</xs:sequence>
nullFlavor
" type="NullFlavor" use="optional"/>
typeCode
" type="ParticipationType" use="optional" fixed="RCT"/>
contextControlCode
" type="ContextControl" use="optional" fixed="OP"/>
</xs:complexType>
Este es un fragmento de CDA que es válido según los fragmentos de XSD expuestos anteriormente:
<
ClinicalDocumentxmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:mif="urn:hl7-org:v3/mif"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<
typeIdextension="POCD_HD000040" root="2.16.840.1.113883.1.3"/>
<
idroot="2.16.858.2.10002886.67430.20130530150748.1" />
<
codecode="28574-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Nota de alta"
/>
<
title
>Nota de alta</title>
<
effectiveTimevalue="20121224093000-0300" />
<
confidentialityCodecode="N" codeSystem="2.16.840.1.113883.5.25" />
<
languageCodecode="es-UY"/>
<
setIdroot="db734647-fc99-424c-a864-7e3cda82e703"/>
<
versionNumbervalue="1" />
<
recordTarget
>
<
patientRole
>
<
idroot="2.16.858.1.858.68909" extension="41162380" />
<
patient
>
<
name
>
<
given
>Pablo</
given
>
<
given
>Federico</
given
>
<
family
>Pazos</
family
>
<
family
>Gutiérrez</
family
>
</
name
>
<
administrativeGenderCodecode="1" displayName="Masculino" codeSystem="2.16.858.2.10000675.69600" />
<
birthTimevalue="19811024" />
</
patient
>
</
patientRole
>
</
recordTarget
>
<
author
>
<
timevalue="20121224093000-0300" />
<
assignedAuthor
>
<
idroot="2.16.858.2.10000675.69586" extension="12345" />
<
assignedPerson
>
<
name
>
<
prefix
>Dr.</
prefix
>
<
given
>Juan</
given
>
<
family
>Perez</
family
>
29
</
name
>
</
assignedPerson
>
<
representedOrganization
>
<
idroot="2.16.858.0.2.16.86.1.0.0.123" />
<
name
>Hospital X</
name
>
</
representedOrganization
>
</
assignedAuthor
>
</
author
>
<
custodian
>
<
assignedCustodian
>
<
representedCustodianOrganization
>
<
idroot="2.16.858.0.2.16.86.1.0.0.123" />
<
name
>Hospital X</
name
>
</
representedCustodianOrganization
>
</
assignedCustodian
>
</
custodian
>
<
component
>
<
structuredBody
>
...
</
structuredBody
>
</
component
>
</
ClinicalDocument
>
4.2.2. Validación de XML contra XSD
Existen numerosas herramientas para validar documentos XML, y esta tarea también puede ser realizada mediante
programación.
En Windows, se puede utilizar la herramienta Notepad++ con el plugin XML Tools:

https://notepad-plus-plus.org/
En Linux, se puede utilizar la herramienta xmlint:

http://xmlsoft.org/xmllint.html
Para validación en línea, existen un sinnúmero de opciones, una de ellas:

http://www.freeformatter.com/xml-validator-xsd.html
30
5. HL7
Health Level Seven es una familia de estándares con dos grandes versiones, v2 y v3. Aunque v2 y v3 no son versiones
del mismo estándar, sino estándares distintos, lo que lleva muchas veces a confusión. Dentro de v2 existen a su vez
muchas subversiones, desde 2.1 a 2.8.2, las que notaremos como HL7 v2.x.
HL7 v2.x se divide en capítulos, como por ejemplo gestión de pacientes, gestión de órdenes, reporte de resultados,
coordinación, entre otros, y también define vocabularios comunes a ser utilizados dentro de los mensajes.
5.1. HL7 v2.x
Las especificaciones de HL7 v2.x se dividen en 15 capítulos más algunos anexos. A continuación se listan estos
capítulos. Los capítulos que se tomarán como referencia para este curso son los marcados en negrita.
• CH01: Introducción
• CH02: Control, Tipos de datos
• CH03: Gestión de pacientes
• CH04: Ingreso de órdenes
• CH05: Consultas de datos
• CH06: Gestión financiera
• CH07: Reporte de observaciones (resultados)
• CH08: Archivos maestros
• CH09: Gestión de archivos médicos
• CH10: Coordinación (citas, estudios)
• CH11: Derivación de pacientes
• CH12: Atención al paciente
• CH13: Laboratorio clínico
• CH14: Gestión de aplicaciones
• CH15: Gestión de personal
Estos capítulos incluyen la definición de mensajes y vocabularios comunes a ser utilizados dentro de los mensajes.
Estos vocabularios definen conjuntos de términos como tablas, donde cada término tiene un identificador único.
Además cada tabla también tiene un identificador único.
En HL7 v2.x, el protocolo de comunicación está orientado a transacciones que se implementan mediante el
intercambio de mensajes, en general se envía un mensaje y se recibe otro como respuesta. Las especificaciones
indican todos los tipos de mensajes que pueden ser enviados, y sus respuestas asociadas. En general para
implementar un caso de uso completo se necesitan varias de estas transacciones, por ejemplo en el caso de los
31
estudios de laboratorio, el envío de la orden desde la HCE al LAB es una transacción y el envío de resultados desde el
LAB a la HCE es otra. Como protocolo de transporte, HL7 v2.x utiliza MLLP en la mayoría de los casos, pero también
es posible utilizar HTTP u otro protocolo, pero estos casos son menos frecuentes. La ventaja de utilizar MLLP es la
performance y el uso óptimo de recursos.
HL7 v2.x define elementos básicos del protocolo que sirven para controlar las transacciones y permitir una
comunicación efectiva de datos. El primer elemento es el evento disparador (trigger event), que es un evento que
ocurre en el mundo real o dentro de un sistema, cuyo resultado es el envío de un mensaje. Por lo tanto, todo envío
de mensajes en HL7 debe tener asociado un evento disparador. La especificación de HL7 define la semántica de cada
evento y asigna un código único para que los sistemas lo interpreten sin ambigüedad. Un segundo elemento son los
mensajes de reconocimiento (acknowledge o ACK), que permiten enviar una respuesta ante la recepción de un
mensaje, indicando si el mensaje ha sido recibido y procesado de forma correcta. Ante errores, los mensajes ACK
pueden contener descripciones detalladas de los problemas encontrados. Esta característica permite asegurar que
todos los mensajes enviados fueron recibidos y procesados. Un tercer elemento es el tipo de transacción. Existen
mensajes orientados a la creación, modificación, eliminación y consulta de datos, en el sistema receptor.
Los mensajes HL7 v2.x pueden codificarse en ER7 (ver sección 3.3) o en XML.
5.1.1. Formato de mensajes HL7 v2.x
Como fue mencionado anteriormente (ver sección 6.3), los mensajes HL7 v2.x siguen la codificación ER7, que se basa
en delimitadores. Los delimitadores se definen al principio de cada mensaje y en general son los mismos, aunque
pueden variar. Por lo tanto el procesamiento de mensajes no debería suponer cuáles son los delimitadores utilizados,
sino que debería tomar los que vienen en cada mensaje.
Los delimitadores marcan el comienzo y fin de distintos elementos que conforman los mensajes HL7 v2.x. A
continuación se mencionan los delimitadores utilizados por defecto:
Posición dentro
Delimitador Valor sugerido Uso
de MSH-2
Terminación de ASCII 0x0D (retorno Este valor no puede ser modificado en la
-
segmento de carro) implementación
Separa dos campos de datos adyacentes dentro de un
Separador de
ASCII 0x7C (“|”) - segmento. También separa el identificador del
campos
segmento del primer campo.
Separador de Separa componentes adyacentes dentro de un campo.
ASCII 0x5E (“^”) 1
componentes
Separador de Separa múltiples ocurrencias de componentes dentro
ASCII 0x7E (“~”) 2
repetición de un campo.
Utilizado dentro de campos de tipo texto (ST, TX, FT) o
Carácter de
ASCII 0x5C (“\”) 3 dentro de componentes que contienen tiras de
escape
caracteres, donde aparecen caracteres de control.
Separador de Separa subcomponentes adyacentes dentro de un
ASCII 0x26 (“&”) 4
subcomponente componente.
Entonces, el primer segmento de todos los mensajes deberá tener el mismo formato:
MSH|^~\&|...
32
A continuación se describen los distintos elementos que conforman los mensajes HL7.
Figura 4: modelo general de mensajes HL7 v2.x
5.1.3.1. Mensaje
Un mensaje está conformado por un conjunto de segmentos, el primero de los cuales es el cabezal del mensaje,
donde se representa información necesaria para la transferencia de datos en una red y procesamiento del mensaje
por parte de las aplicaciones receptoras. Al resto de los segmentos se les llama “cuerpo” del mensaje. El segmento
cabezal está identificador por los caracteres “MSH” (Message Header).
5.1.3.2. Segmento
Todos los mensajes contienen más de un segmento. Cada segmento es de un tipo específico que se identifica con
tres caracteres. El tipo de segmento determina qué información será contenida en ese segmento. Cada tipo de
segmento tiene una estructura predefinida en el estándar, la cual contiene la definición de un conjunto de campos y
sus características, por ejemplo si son obligatorios o no, si se puede repetir, etc.
5.1.3.3. Campo
Un segmento está conformado por un conjunto de campos o atributos. Para identificar un campo dentro de un
segmento se utiliza un índice, por ejemplo el campo MSH-9 referencia al campo “message type” del segmento MSH.
Cada segmento tiene un tipo de dato asociado, un nombre que indica lo que representa el campo, por ejemplo
“identificador del paciente”. Si el campo representa un código, en la definición del segmento también se incluye de
qué tabla se debe sacar el valor para dicho campo, por ejemplo el campo “sexo administrativo” debe tomar su valor
de la tabla “0001” donde están los valores válidos de “sexo” para HL7.
5.1.3.4. Tipo de dato
Los tipos de datos determinan cómo se codifican los campos internamente. Los tipos de datos especifican estructuras
de componentes y subcomponentes donde se colocan datos simples, estos podrían ser de ocurrencia múltiple
(delimitados mediante el separador de repetición).
33
5.1.2. Tipos de mensajes
Los tipos de mensaje se identifican mediante códigos de tres caracteres. Estos códigos están definidos en la tabla
0076 de HL7. Algunos de los tipos más usados son35 :
5.1.4.1. ACK
Mensaje general de confirmación (acknowledge), utilizado para confirmar la recepción de un mensaje e informar de
posibles errores en el procesamiento del mensaje por parte del receptor. Ejemplos:
MSH|^~\&|HIS|System|Hosp|HL7 Genie|20071016055244||ACKÂ01|A234242|P|2.3.1|
MSA|AA|234242|Message Received Successfully|
MSH|^~\&|BROKER.RECEIVER.FLOW||ADT|767543|20090824222730||ACK|XX3657|P|2.5
MSA|AE|ZZ9380|MSH parsing or validation error: MSH.3.Sending Application is null|1
5.1.4.2. ADT
Mensaje utilizado para comunicar información del paciente al momento ser admitido (Admission), dado de alta
(Discharge), o transferido (Transfer) a otro servicio o centro asistencial (T). Este mensaje incluye también información
del lugar físico (centro asistencial y punto de atención), del médico que va a atender al paciente, información de
contactos, etc. Incluso permite comunicar alguna información clínica útil para la atención médica que se le brindará
al paciente, por ejemplo alergias, resultados de estudios, información de un accidente (ej. para una atención de
urgencia), etc. Ejemplo:
MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADTÂ04|1817457|D|2.5
EVN|A04|199912271300
PID||0493575^^^2ÎD 1|454721||DOE^JOHN|DOE^JOHN|19480203|M||B|254 MYSTREET
AVE^^MYTOWNÔH^44123ÛSA||(216)123-4567|||M|NON|400003403
NK1|1|ROE^MARIE|SPO||(216)123-4567||EC
PV1||O|BOX1^^ÊR||||277ÂLLEN
MYLASTNAME^BONNIE||||||||||||2688684|||||||||||||||||||||||||199912271408||||||002376853
5.1.4.3. OML
Mensaje para órdenes, tanto de estudios de laboratorio como otros tipos de órdenes. Aunque el mensaje ORM
puede ser utilizado con este propósito, OML tiene la ventaja de permitir utilizar datos referidos a la muestra y al
contenedor de muestras. El evento disparador de este mensaje es cualquiera que altere el estado de una orden,
desde la creación hasta su ejecución, pasando por cancelación o modificación.
MSH|^~\&|OP|Ent-gastric|OF|Chem|200309060820||OMLÔ21ÔML_O21|msgOP123|T|2.5.1|123
PID|1||12345^5^M10^Memphis_Hosp^PI||EVERYMANÂDAM^^JR^^^L||19800101|M
PV1|1|O|Ward|||||||||||||||12345
ORC|NW|12345^gastric||666^gastric|||||200309060710|2221^NURSE^NANCY|||||||||||Ent-gastric^^^^^^FI^^ÊG02
TQ1|||||||||A
OBR||12345678^gastric||82951^Glucose Tolerance Test^C4||||||1234^BLEEDER|P|||||222222^PHYSICIAN^^^^DR|821
OBX|1|NM|GLUCOSE||75|g|||||F|||200309060735
SPM|1|123456781^gastric||SER|||||||P||||||200309060735|||||||||1
SPM|2|123456782^gastric||SER|||||||P||||||200309060755|||||||||1
SPM|3|123456783^gastric||SER|||||||P||||||200309060815|||||||||1
35

http://www.hl7.org/special/committees/vocab/v26_appendix_a.pdf
34
5.1.4.4. OMP
Mensaje para órdenes de farmacia o tratamientos.
MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||OMPÔ09ÔMP_O09| ...
PID|...
ORC|NW|1000ÔE||||E|^Q6H^D10^^^R|...
RXO|^Polycillin 500 mg TAB^|500||MG|||||Y||40|...
RXR|PO|...
5.1.4.5. ORL
Respuesta a mensajes de órdenes de laboratorio (OML). Se utiliza como acknowledge. Ejemplo:
MSH|^~\&|OF|Automation|OP|Cytology|200310060826||ORLÔ34ÔRL_O34|301|T|2.5.1
MSA|AA|101
PID|1||6543210^^Âbbeville Hospital^PI||ILL^JOHN^^^^^L||19810101|M
SPM|1|456_1^Cytology||BLD|||||||P||||||200310060735|200310060821||||||||1
ORC|OK|||555Ûrology|SC||||200310060710|^NURSE^JANET|||||||||||Urology^^^^^^FI^^ÛR01
TQ1|1||||||||R
OBR|1|456^Cytology||85027^Hemogram and platelet count, automated^C4||||||^COLLECT^JOHN|S|||||ÛRO^^^^DR
ORC|OK|||555Ûrology|SC||||200310060710|^NURSE^JANET|||||||||||Urology^^^^^^FI^^ÛR01
TQ1|1||||||||R
OBR|1|457^Cytology||85009^Differential WBC Count, buffy coat^C4||||||^COLLECT^JOHN|S|||||ÛRO^^^^DR
5.1.4.6. ORM
Mensaje para órdenes en general, se utiliza por compatibilidad hacia atrás. Se recomienda utilizar mensajes más
específicos para las órdenes como OML para órdenes de laboratorio. ORM permite crear órdenes, o notificar de
cancelación o modificación de las mismas. Ejemplo:
MSH|^~\&|MESA_OF|XYZ_RADIOLOGY|MESA_IM|XYZ_IMAGE_MANAGER|||ORMÔ01|100112|P|2.3.1||
PID|||M4000^^ÂDT1||KING^MARTIN||19450804|M||WH|82 0 JORIE BLVD^^CHICAGOÎL^60523|||||||20-98-4000|
PV1||E|ED||||1234^WEAVER^TIMOTHY^P^^DR|5101^NELL^F REDERICK^P^^DR|||||||||||V100^^ÂDT1||||||||||||||
|||||||||||200008201100|||||||V|
ORC|NW|A100Z^MESA_ORDPLC|B100Z^MESA_ORDFIL||SC||1ônce^^^^S||200008161510|^ROSEWOOD^RANDOLPH||7101ÊSTRADA^J
AIME^P^^DR||(314)555-1212|200008161510||922229-10ÎHE-RADÎHE-CODE-231||
OBR|1|A100Z^MESA_ORDPLC|B100Z^MESA_ORDFIL|P1^Proce dure 1ÊRL_MESA^X1_A1^SP Action Item
X1_A1^DSS_MESA|||||||||xxx||Radiology^^^^R|7101ÊS
TRADA^JAIME^P^^DR||XR999999|RP123456|SPS123456||||MR|||1ônce^^^^S|||WALK|||||||||||A|||RP_X1^RP Action Item
RP_X1^DSS_MESA
ZDS|1.2.1^100Âpplication^DICOM
5.1.4.7. ORU
Mensaje de observaciones. Se utiliza para comunicar resultados de laboratorio y de imagenología vinculados a una
orden, hacia diversos sistemas. Ejemplo:
MSH|^~\&|LAB|SCC|STOCKELL|0010|201201020155||ORU^R01|25238212|P|2.3
PID|1||222225||Pluto^DogÂ||19560101|M|||1248 KINNEYS
LANE^^PORTSMOUTH^PORTSMOUTHÔH^45662||7402565000|||M||1111115|
PV1|1||ERF||5780629||1111ÊPMGÎNC.||||||||||1111ÊPMGÎNC.|||||||||||||||||||||||||||201201020110
ORC|RE|017161095-001|73020326-6|73020326|||^^^201201020119^^S||201201020120|INF-O||8480^MCKAIN^CHRISTINE|ERF
35
OBR|1|||LIP^Lipase|||201201020133|||SND||||201201020134||8480^MCKAIN^CHRISTINE|||||||||F
OBX|1|NM|LIP^Lipase^SL^LIPL||200|U/L|65-230||||F|||201201020154
5.1.4.8. OUL
Mensaje de observaciones de laboratorio, se utiliza para enviar resultados de estudios vinculados a una muestra. Se
utiliza frecuentemente en la gestión de estudios y resultados dentro del laboratorio. Ejemplo:
MSH|^~\&|OF|Chemistry|ORT||200309060825||OUL^R22ÔUL_R22|msgOF103|T|2.5.1
PID|1||12345^5^M10^Memphis_Hosp^PI||EVERYMANÂDAM^^JR^^^L||19800101|M
PV1|1|O|Ward|||||||||||||||12345
ORC|SC|12345^gastric||666^gastric|IP||||200309060824|222221^NURSE^NANCY|||||||||||Ent-gastric^^^^^^FI^^ÊG02
OBR||12345678^gastric|555^chemistry|82951^Glucose Tolerance
Test^C4||||||1234^BLEEDER|P|||||222222^PHYSICIAN^^^^DR|821||||||||I
TQ1|||||||||A
OBX|1|NM|GLUCOSE||75|g|||||F|||200309060735
OBX|2|NM|30264-6^GLUCOSE 40M POST DOSE GLUCOSE^LN||||||||X
SPM|1|123451^gastric||SER|||||||P||||||200309060735|200309060821||Y||||||1
SPM|2|123452^gastric||SER|||||||P||||||200309060755|200309060821||Y||||||1
SPM|3|123453^gastric||SER|||||||P||||||200309060815|200309060821||N|RB^Broken container|||||1
5.1.4.9. RDS
Mensaje de dispensación de farmacia o tratamiento. Suele utilizarse como notificación desde los sistemas de
enfermería donde se gestiona la ejecución de la administración de un medicamento o el cumplimiento de cierto
tratamiento.
MSH|^&~\|PIMS|GenHosp|IE||1998052911150700||RDSÔ13^RDS_O13||...
PID|||555444222111^^^MPI&GenHosp&L^MR||EverymanÂdam||19600614|M||C|99 Oakland #
106^^Pasadena^CA^91131||^^^^^626^5641111|^^^^^626^5647654|||||3431322 66|||N|...
ORC|RE||89968665||||||1998052910300700|||77^Hippocrates^Harold^HÎII^DR^ MD||^^^^^510^ 2673600|...
RXE|1^BID^^19980529|^Verapamil|120||mg^milligram^FDB.MDDB||... RXD|1|00378112001^Verapamil Hydrochloride 120
mg TAB^NDC |199805291115- 0700|100|||1331665|3|...
RXR|PO|...
FT1|1|||199805291115-0700||CO^Co-Pay^HL70017 |00378112001^Verapamil Hydrochloride 120 mg TAB^NDC
|||1|5&USD^TP|...
FT1|2|||199805291115-0700||PY^Payment^HL70017 |00378112001^Verapamil Hydrochloride 120 mg TAB^NDC
|||1|5&USD|...
5.1.4.10. RRD
Mensaje de respuesta a la dispensación de farmacia o tratamiento (RDS). Se utiliza como acknowledge.
36
5.1.3. Eventos disparadores
El protocolo HL7 v2.x se basa en el envío de mensajes y todo mensaje enviado debe tener asociado un evento
disparador. Este evento ocurre tanto por acción de una persona como de un sistema en el mundo real, y ayuda a
diferenciar las condiciones bajo las cuales se recibe un mensaje de cierto tipo, debido a que mensajes de un mismo
tipo pueden ser disparados por distintos eventos bajo distintas condiciones. Los eventos están definidos en la tabla
0003 de HL7. A continuación se describen algunos de los eventos disparadores más utilizados.
5.1.3.1. Eventos para admisiones, altas y transferencias (ADT)
Los siguientes eventos disparan mensajes de tipo ADT:
A01
Notificación de visita o admisión. Se utiliza cuando el paciente es hospitalizado y se le asigna un lugar físico como un
cuarto o cama.
A02
Notificación de transferencia. Se utiliza cuando el paciente es transferido de una ubicación a otra.
A03
Notificación de alta. Se utiliza cuando finaliza la atención al paciente y el lugar que ocupaba queda libre para ser
asignado a otro paciente.
A04
Notificación de registro de paciente. Se utiliza para notificar cuando un paciente ambulatorio es recibido para una
consulta.
A05
Notificación de preadmisión del paciente. Se utiliza para notificar el comienzo del proceso de preadmisión, o sea el
registro del paciente previo a ser hospitalizado (A01).
A08
Notificación de modificación de información del paciente. Se utiliza para notificar cambios tanto de la visita o
encuentro, como datos demográficos del paciente. Se utiliza cuando no existe otro evento AXX más específico.
A11
Notificación de cancelación de admisión.
A12
Notificación de cancelación de transferencia.
A40
Notificación de unión de identificadores del paciente. Se utiliza cuando dos o más registros de pacientes, que
corresponden al mismo paciente, son consolidados.
Por una lista completa de eventos, vea la tabla 0003 en las especificaciones de HL7 v2.536 .
36

https://www.hl7.org/implement/standards/product_brief.cfm?product_id=143
37
5.1.4. Tipos de segmentos
Cómo se comentó previamente, un mensaje está compuesto de una serie de segmentos, donde el primero es el
cabezal del mensaje MSH (message header). Los segmentos se utilizarán en la sección 7.6 donde se describirán
distintos tipo de mensajes HL7. A continuación se describen algunos de los tipos de segmentos más utilizados.
5.1.4.1. MSH (Message Header)
Información del cabezal del mensaje, incluye campos con la identificación del emisor y receptor del mensaje, versión
de HL7 utilizada, identificador de la transacción, fecha de envío, etc.
5.1.4.2. EVN (Event)
Segmento con información sobre el tipo de evento. Se utiliza para comunicar información de contexto necesaria
sobre el evento disparador para que el mensaje sea procesado correctamente por el receptor.
5.1.4.3. PID (Patient Identification)
Este segmento contiene información de identificación del paciente. Se utiliza en todo tipo de mensajes para saber a
qué paciente corresponde una orden, un resultado, una admisión, etc. Contiene información de identificadores,
nombres y apellidos, fecha de nacimiento, sexo, información de contacto, etc.
5.1.4.4. NK1 (Next of Kin)
Este segmento se utiliza para especificar información de personas asociadas al paciente, como una persona de
contacto, un acompañante, un familiar, etc. Incluye información como nombres y apellidos, tipo de relación con el
paciente, información de contacto, etc.
5.1.4.5. PV1 (Patient Visit)
Este segmento es utilizado por aplicaciones de registración o gestión de pacientes para comunicar información sobre
una cuenta o sobre la visita del paciente (ej. una hospitalización o consulta médica). Contiene información acerca del
tipo de paciente, identificadores de preadmisión y de admisión, tipo de admisión, el servicio al que fue admitido,
información sobre los médicos (quien admite, quien refiere, médico consultante, etc.), información financiera, etc.
5.1.4.6. OBX (Observation)
Segmento de observaciones, en general contiene el resultado de un estudio individual.
5.1.4.7. OBR (Observation Request)
Segmento de pedido de observación, es utilizado en las órdenes de estudios para indicar cada estudio pedido dentro
de una orden.
38
5.1.4.8. ORC (Common Order)
Segmento que representa una orden que puede contener varios pedidos de estudios. Contiene información como
quién ordena el estudio, quién lo debe ejecutar, fecha y hora del pedido, desde que lugar o servicio se solicitaron los
estudios, etc.
5.1.4.9. AL1 (Allergies)
Segmento que contiene información de las alergias del paciente, como el tipo de alérgeno, la reacción y la gravedad.
5.1.4.10. NTE (Notes and Comments)
Este segmento se utiliza para agregar comentarios en texto plano asociados a otros segmentos. Por ejemplo, en un
mensaje de resultados de laboratorio cada resultado contenido en un segmento OBX puede tener cero o más
comentarios asociados.
5.1.4.11. MSA
Segmento de message acknowledgement que contiene la información principal de los mensajes ACK y se da
información general del procesamiento del mensaje recibido por el receptor.
5.1.4.12. ERR
Segmento que incluye información de errores, utilizado en los mensajes ACK.
5.1.4.13. RXO (Prescription Order)
Este segmento se utiliza para especificar información de órdenes de farmacia o tratamientos medicamentosos.
Contiene información de la sustancia a administrar, la dosis, forma farmacéutica (comprimidos, cápsulas, polvo,
crema, etc.), etc.
39
5.1.5. Tipos de datos
Cada campo de un segmento tiene asociado un tipo de dato que define la estructura interna de los datos en un
mensaje HL7. Los tipos de datos están definidos en el capítulo 2, anexo A del estándar. A continuación se describen
algunos de los tipos de datos más utilizados:
5.1.5.1. AD (Address)
Especifica la dirección de una persona, lugar u organización.
5.1.5.2. CE (Coded Element)
Este tipo de dato fue reemplazado por CWE.
5.1.5.3. CWE (Coded with Exceptions)
Especifica datos codificados con detalles asociados, como código alternativo y también permite omitir el código
cuando hay un texto asociado.
5.1.5.4. CX (Extended Composite ID with Check Digit)
Especifica Identificadores con información administrativa vinculada.
5.1.5.5. DT (Date)
Se utiliza el formato YYYYMMDD con DD y MM opcionales, por lo que este tipo de dato puede tener un largo máximo
de ocho caracteres.
5.1.5.6. DTM (Date/Time)
Especifica un punto de tiempo formado con la fecha, tiempo y zona horaria.
5.1.5.7. HD (Hierarchic Designator)
Identifica una entidad responsable de asignar o gestionar identificadores de objetos (pacientes, médicos, etc.).
5.1.5.8. ID (Coded Value from HL7 Defined Tables)
Es un valor codificado que se obtiene de las tablas ya definidas dentro de HL7.
40
5.1.5.9. EI (Entity Identifier)
Se utiliza en general para colocar identificadores generados automáticamente. Contiene información del sistema que
generó el identificador.
5.1.5.10. FT (Formatted Text)
Este tipo de dato deriva de TX, y lo extiende permitiendo la inclusión de caracteres de formateo, los cuales deben
comenzar con un punto “.”, y para incluir caracteres de formateo en un campo es necesario rodearlos con el carácter
de escape, en general “\”. A continuación se comentan algunos de estos caracteres:
".br": Termina la línea actual y comienza una nueva.

".in<N>": Indentación del texto con N espacios en blanco.
Resaltado de texto:
● \H\: Comienza el modo resaltado (highlighted text).

● \N\: Termina el modo resaltado (normal text).
Inserción de caracteres especiales en el texto:
● \F\: Separador de campos "|"

● \S\: Separador de componente "^"
● \T\: Separador de subcomponente "&"
● \R\: Separador de repetición "~"
● \E\: Carácter de escape "\"
Un ejemplo de dato FT con caracteres de formateo:
|First line.\.br\\in4\Second line.\.br\\.br\

\.H\Table mode:\N\\.br\+------------+-----------+\.br\
\F\ cell 1/1 \F\ cell 2/1 \F\\.br\+------------+-----------+\.br\
\F\ cell 1/2 \F\ cell 2/2 \F\\.br\+------------+-----------+\.br\
Un usuario final lo vería como:
First line.
Second line.
Table mode:
+------------+-----------+
| cell 1/1 | cell 2/1 |
+------------+-----------+
| cell 1/2 | cell 2/2 |
+------------+-----------+
41
5.1.5.11. IS (Coded Value from User Defined Tables)
Es un valor codificado que se obtiene de tablas definidas por el usuario.
5.1.5.12. MSG (Message Type)
Contiene el tipo de mensaje, evento disparador y código de estructura del mensaje dentro del segmento MSH.
5.1.5.13. NM (Numeric)
Representa un dato numérico, que puede contener signo y punto decimal. El tamaño máximo es de 16 caracteres.
5.1.5.14. PL (Person Location)
Este tipo de dato contiene información sobre el lugar físico de una persona, como punto de cuidado, cuarto, cama,
centro, edificio, piso, etc.
5.1.5.15. SI (Sequence ID)
Contiene un dato numérico positivo de largo máximo de 4 dígitos.

5.1.5.16. ST (String Data)
Representa datos en texto libre, para textos cortos (menos de 1000 caracteres). Puede incluir cualquier carácter de
control de HL7 menos el terminador de segmento, pero se debe utilizar el carácter de escape ante dichos caracteres
de control.
5.1.5.17. TS (Time Stamp)
Este tipo de dato fue sustituido por DTM en HL7 v2.5.
5.1.5.18. TX (Text Data)
Contiene datos en texto libre, orientados a ser visualizados mediante alguna interfaz de usuario o a ser impresos en
papel. El separador de repetición (~) se interpreta como terminador de párrafo. Se respetan los espacios que
aparecen antes del texto, y el largo máximo es 65536 caracteres.
5.1.5.19. XCN (Extended Composite ID number and name for persons)
Contiene información que permite identificar a una persona. Este tipo de dato es complejo y se define en función de
otros tipos de datos. Es similar a XPN, pero agrega información de identificación de la persona.
5.1.5.20. XPN (Extended Person Name)
42
Contiene información de los nombres y apellidos de una persona, más prefijos, sufijos y otra información que puede
ser incluida en el nombre completo de una persona.
5.1.5.21. XTN (Extended Telecommunication Number)
Permite representar números de teléfono, números de fax, correos electrónicos, tanto del trabajo como del hogar,
más información contextual.
43
5.1.6. Definiciones de mensajes
Para implementar HL7 v2.x es necesario saber leer las especificaciones del estándar y sus perfiles. Comprender la
definición de mensajes es sumamente necesario. En esta sección se verán las distintas formas de especificación de
mensajes y transacciones que tiene HL7 v2.x.
5.1.6.1. Definición estática de mensajes HL7
Este tipo de definición hace foco en la parte estructural de los mensajes, definiendo estructuras de mensajes,
segmentos y campos. Para la definición de mensajes se utiliza la sintaxis abstracta de mensajes basada en segmentos,
contenidos entre llaves { } para denotar multiplicidad y entre paréntesis rectos [ ] para denotar ocurrencia opcional.
Ejemplos de definiciones estáticas a nivel de mensajes:
ADTÂ01ÂDT_A01 ADT Message
MSH Message Header
[ { SFT } ] Software Segment
EVN Event Type
PID Patient Identification
[ PD1 ] Additional Demographics
Tabla 2: extracto de la definición estática del mensaje ADT para el evento A01
ACK^variesÂCK ACK Message
MSH Message Header
MSA Message Acknowledgement
[ { ERR } ] Error Segment
Tabla 3: definición estática del mensaje ACK para cualquier evento
44
En la tabla 2 se define parte del mensaje ADT que se lanza ante el evento disparador A01. Los segmentos de este
mensaje cumplen:
● MSH es obligatorio.
● SFT es opcional y puede tener múltiples ocurrencias.
● EVN y PID son obligatorios.
● PD1 es opcional y puede tener solo una ocurrencia.
Se debe notar que el identificador del mensaje se compone del tipo de mensaje (ADT), del evento disparador (A01) y
del identificador de estructura (ADT_A01). La utilidad del identificador de estructura es para poder reutilizar la misma
estructura para otro mensaje del mismo tipo, pero con distinto evento disparador. Esto tiene un efecto a nivel de
software que es necesario considerar cuando se desarrolla: puede parecer que algunos mensajes no están definidos
pero es porque esos mensajes reutilizan estructuras de otros.
Por ejemplo el mensaje ADT con evento A04 utiliza la estructura ADT_A01:
ADTÂ04ÂDT_A01 ADT Message
MSH Message Header
EVN Event Type
PID Patient Identification
[ PD1 ] Additional Demographics
Tabla 4: extracto de la definición estática del mensaje ADT para el evento A04
45
5.1.6.2. Definición estática de segmentos
La definición estática a nivel de segmentos tiene la siguiente estructura:
SEQ LEN DT Usage Cardinality TBL# Element Name
1 4 SI X Set ID - PID
2 20 CX RE [0..1] Patient ID
3 20 CX R [1..*] Patient Identifier List
4 20 CX X Alternate Patient ID - PID
5 48 XPN R [1..*] Patient Name
6 48 XPN RE [0..*] Mother’s Maiden Name
7 26 TS RE [0..1] Date/Time of Birth
8 1 IS RE [0..1] 0001 Sex
… … … … … … …
Tabla 5: extracto de definición estática a nivel de segmentos para PID
Esta tabla define los campos dentro de un segmento PID, indicando:
● Lugar del campo dentro del segmento

● Largo del campo en bytes
● Tipo de dato correspondiente a cada campo
● Uso del campo, donde:
o R = Requerido
o RE = Requerido pero puede estar vacío
▪ La aplicación emisora debe enviar datos si los tiene.
▪ La aplicación receptora debe procesar correctamente el mensaje aunque no vengan datos.
o O = Opcional
o C = Condicional
o CE = Condicional pero puede estar vacío
o X = No soportado / No corresponde
● Cardinalidad de cada campo
o Define la cantidad de ocurrencias posibles de datos en cada campo.
● Número de tabla
o Si el dato para el campo debe obtenerse de una tabla.
● Nombre del campo
46
5.1.6.3. Definición estática de campos
La definición a nivel de campos tiene la siguiente estructura:
SEQ LEN DT OPT TBL# COMPONENT NAME
1 20 ST O Identifier
2 199 ST O Text
3 20 ID O 0396 Name of Coding System
4 20 ST O Alternate Identifier
5 199 ST O Alternate Text
6 20 ID O 0396 Name of Alternate Coding System
7 10 ST C Coding System Version ID
Alternate Coding System Version

8 10 ST O
ID
9 199 ST O Original Text
Tabla 6: definición estática de campos de tipo CWE
Como se puede apreciar, la definición a nivel de campos describe la estructura interna de los tipos de datos asociados
a cada campo. En la tabla anterior se describe el tipo de dato CWE (Coded With Exceptions). En esta tabla se definen:
● Lugar que ocupa cada componente dentro del tipo de dato

● Largo de cada componente en bytes
● Tipo de dato de cada componente
o Se utiliza para tipos de datos complejos que dependen de otros tipos de datos.
● Número de la tabla de donde se obtienen los valores válidos para el componente.
● Nombre del componente.
● Referencia al capítulo y sección donde se define cada componente.
47
5.1.7. HL7 v2.5 codificado como XML
La codificación más común de los mensajes HL7 v2.x es ER7 (ver sección 3.3), pero los mensajes HL7 v2.x pueden ser
codificados en XML. A modo de ejemplo, aquí se muestra el mismo mensaje ADT de la sección 5.1.4.2, pero en XML
(los segmentos NK1 y PV1 se removieron para simplificar el ejemplo):
<?xml version="1.0" encoding="UTF-8"?>

<ADT_A01 xmlns="urn:hl7-org:v2xml">
<MSH>
<MSH.1>|</MSH.1>
<MSH.2>^~\&</MSH.2>
<MSH.3>
<HD.1>EPIC</HD.1>
</MSH.3>
<MSH.4>
<HD.1>EPICADT</HD.1>
</MSH.4>
<MSH.5>
<HD.1>SMS</HD.1>
</MSH.5>
<MSH.6>
<HD.1>SMSADT</HD.1>
</MSH.6>
<MSH.7>
<TS.1>199912271408</TS.1>
</MSH.7>
<MSH.8>CHARRIS</MSH.8>
<MSH.9>
<MSG.1>ADT</MSG.1>
<MSG.2>A04</MSG.2>
</MSH.9>
<MSH.10>1817457</MSH.10>
<MSH.11>
<PT.1>D</PT.1>
</MSH.11>
<MSH.12>
<VID.1>2.5</VID.1>
</MSH.12>
</MSH>
<EVN>
<EVN.1>A04</EVN.1>
<EVN.2>
<TS.1>199912271300</TS.1>
</EVN.2>
</EVN>
<PID>
<PID.2>
<CX.1>0493575</CX.1>
<CX.4>
<HD.1>2</HD.1>
</CX.4>
<CX.5>ID 1</CX.5>
</PID.2>
<PID.3>
<CX.1>454721</CX.1>
</PID.3>
<PID.5>
<XPN.1>
48
<FN.1>DOE</FN.1>
</XPN.1>
<XPN.2>JOHN</XPN.2>
</PID.5>
<PID.6>
<XPN.1>
<FN.1>DOE</FN.1>
</XPN.1>
<XPN.2>JOHN</XPN.2>
</PID.6>
<PID.7>
<TS.1>19480203</TS.1>
</PID.7>
<PID.8>M</PID.8>
<PID.10>
<CE.1>B</CE.1>
</PID.10>
<PID.11>
<XAD.1>
<SAD.1>254 MYSTREET AVE</SAD.1>
</XAD.1>
<XAD.3>MYTOWN</XAD.3>
<XAD.4>OH</XAD.4>
<XAD.5>44123</XAD.5>
<XAD.6>USA</XAD.6>
</PID.11>
<PID.13>
<XTN.1>(216)123-4567</XTN.1>
</PID.13>
<PID.16>
<CE.1>M</CE.1>
</PID.16>
<PID.17>
<CE.1>NON</CE.1>
</PID.17>
<PID.18>
<CX.1>400003403</CX.1>
</PID.18>
</PID>
</ADT_A01>
Una forma sencilla de obtener el XML a partir de ER7 es mediante la herramienta HAPI TestPanel37 .
37

http://hl7api.sourceforge.net/hapi-testpanel/
49
5.2. HL7 v3
HL7 v3 está dividido en 23 dominios, similares a los capítulos de HL7 v2.x, cada uno especializado en definir mensajes
o documentos en función de conceptos específicos. Todos esos mensajes y documentos siguen el Reference
Information Model de HL7 v3, por lo que mantienen cierto grado de compatibilidad a nivel del modelo básico.
Los dominios son:
1. Contabilidad y facturación : Cubre la creación y gestión de las cuentas de pago de los pacientes, con el fin de
recolectar los pagos y créditos (transacciones financieras) para apoyar la presentación de reclamos o
reembolsos de facturas.
2. Prestación de atención médica : Habilita la información necesaria para el cuidado continuo de los individuos,
poblaciones y otros sujetos de atención.
3. Reclamos y reembolso : Refiere a la facturación (incluyendo la verificación de autorización y elegibilidad),
adjudicación y pagos (incluyendo ajustes y consultas de las cuentas) de servicios de salud.
4. Apoyo a las decisiones clínicas : Se encarga de definir mensajería para infobuttons. Los infobuttons son
instrumentos de información en puntos de atención, que generan consultas online automáticamente sobre
recursos de información de salud, utilizando información extraída de la Historia Clínica Electrónica (HCE) del
paciente y de información del contexto (datos demográficos, datos de la atención médica actual, etc). Estas
consultas sirven para proveer al profesional de la salud de información útil en el cuidado de ese paciente
específico.
5. Arquitectura de documento clínico : Define una sintaxis basada en XML para definir documentación clínica
estructurada. Un documento CDA puede incluir información de distintos tipos: texto, imágenes, sonidos, y
otros contenidos multimedia. La estructura de documentos CDA es flexible, pudiendo representar muchos
tipos de documentos clínicos diferentes.
6. Clínica genómica : Permite la interrelación de información clínica y genómica. Gran parte de la información
genómica, aún es genérica, por ejemplo el genoma humano son las secuencias de ADN que se creen comunes
a todo ser humano. La visión de medicina personalizada está basada en dichas correlaciones, que hacen uso
de información genómica personal, que se diferencia entre dos personas cualesquiera.
7. Declaraciones clínicas : Define mensajería útil para la comunicación de declaraciones clínicas. Está definido de
forma amplia, por lo que una misma declaración clínica podría tener múltiples formas de representación. Por
lo tanto, para ser usado efectivamente, es necesario definir restricciones sobre el modelo de mensajes para
cada contexto determinado.
8. Tipos de mensajes de elementos comunes : Este dominio se encarga de definir partes de estructuras
comunes y reutilizables para los mensajes de diversos dominios.
9. Medidas de calidad : Define un estándar para la representación de medidas de calidad en salud, como un
documento electrónico. Una medida de calidad es una herramienta cuantitativa que proporciona indicadores
de rendimiento de un individuo u organización, en relación con una acción o proceso específico, o como
medida de resultados clínicos.
10. Inmunización : Refiere a la comunicación de información sobre la inmunización: administración de vacunas y
sueros a las personas, para prevenir enfermedades infecciosas.
11. Laboratorio : Consta de los mensajes necesarios para la comunicación de información de estudios y
observaciones de laboratorio, incluyendo áreas como: química, hematología, serología, histología, citología,
anatomía patológica, microbiología y virología.
12. Registros médicos : Apoya la gestión y consulta de documentos clínicos.
13. Administración de pacientes : Define la información demográfica del paciente, la cual será consumida desde
otros sistemas como registros clínicos o sistemas financieros.
14. Administración de personal: Contiene la definición de roles, relaciones, credenciales, certificados,
capacidades, competencias, cualificaciones, privilegios, responsabilidades y asignación de tareas, emitidos
para, o gestionados por, distintas entidades (personas, organizaciones, dispositivos, etc).
15. Farmacia : Se encarga de definir mensajería para la prescripción, dispensación, y administración de
medicamentos, tanto en farmacias externas como internas a la institución. También define mensajería para la
solicitud de información del registro de medicación de un paciente (drogras, recetas, etc).
50
16. Registros: Se encarga de los registros administrativos de personas, pacientes, proveedores, equipamiento y
lugares de prestación de servicios sanitarios.
17. Reportes de Salud Pública : Incluye los mensajes para apoyar la denuncia e investigación de enfermedades en
el contexto de la Salud Pública.
18. Productos regulados : Incluye las normas elaboradas para la aprobación de productos regulados, y los
mensajes para comunicar información de estos productos.
19. Estudios regulados : Incluye normas elaboradas para el intercambio de información sobre la realización de
estudios regulados, y la comunicación de la información recolectada durante esos estudios.
20. Coordinación : Ofrece un conjunto genérico de mensajes para poder implementar cualquier contexto de
coordinación.
21. Mensajes compartidos : Contiene definiciones de tipos de mensajes comunes, que son reutilizados por otros
dominios.
22. Muestras : Comprende los mensajes relacionados con cualquier tipo de muestra. La información contenido es
de la propia muestra, de su envase, y de los contenidos de este antes, durante y después de que la muestra
fue colocada en este.
23. Dispositivos terapéuticos : Comprende mensajes necesarios para la comunicación relacionada con la terapia y
las observaciones hechas por dispositivos médicos. En la actualidad está centrado en los dispositivos
cardíacos implantables.
En este curso nos concentraremos en el dominio de CDA (Arquitectura de Documento Clínico).
5.2.1. Reference Information Model (RIM)
El modelo de referencia de HL7 v3 sirve como base para los mensajes y documentos definidos en todos los dominios.
El corazón del RIM está compuesto por seis clases básicas de información:
Elementos centrales del HL7 v3 RIM
Entity: es un objeto físico o grupo de objetos físicos, u organizaciones capaces de participar en actos a través de un
rol. Personas, animales, y dispositivos son algunos ejemplos.
Role
: competencia de una entidad que juega un rol en un acto
Participation
: representa la asociación entre un rol y un acto.
Act
: permite registrar algo que fue realizado, que está siendo realizado, que puede ser realizado o que fue pedido
para ser realizado en el futuro. La administración de medicamentos, el registro de signos vitales, los resultados de
estudios de laboratorio, son algunos ejemplos.
51
Visión completa del HL7 v3 RIM
5.2.2. Clinical Document Architecture (CDA)
Los documentos CDA contienen un cabezal con los datos del paciente, médico, centro, etc. y un cuerpo con el
registro de una consulta, visita o contacto médico. CDA tiene un formato XML, donde es posible definir 3 niveles:
● Nivel 1: No estructurado (cuerpo en datos binarios, texto libre, etc)

● Nivel 2: Estructurado, texto libre (dividido en secciones donde los registros se realizan en texto libre)
● Nivel 3: Estructurado, codificado (las secciones tienen a su vez entradas codificadas)
5.2.2.1. Estructura del CDA en XML
El elemento raíz del XML es "ClinicalDocument", donde se pueden destacar los subelementos que corresponden al
cabezal y al cuerpo del CDA. En este caso, el cuerpo es estructurado (niveles 2 o 3):
<
ClinicalDocument...>
... cabezal (header) ...
<component>

<structuredBody>
<component>
<section>
<title></title>
...
</section>
</component>

</structuredBody>
</component>
</
ClinicalDocument
>
52
Dentro del cabezal, encontramos algunos elementos como:

<typeId ... />
<id ... />
<code ... />
<title>...</title>
<effectiveTime ... />
<confidentialityCode ... />
<languageCode ... />
<recordTarget>... información del paciente ...</recordTarget>
<author>... información del médico responsable ...</author>
<custodian>... información del custodio del documento ...</custodian>
...
Tipo de documento CDA (valores fijos):
<typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3" />
Identificador del documento:
<id root="db734647-fc99-424c-a864-7e3cda82e703" />
Código indicador del tipo de documento particular:
<code code="34133-9" codeSystem="2.16.840.1.113883.6.1" displayName="Summarization of episode note" />
Título del documento:
<title>Consulta Ambulatoria</title>
Día y hora en la que se creó el documento:
<effectiveTime value="20121224093000-0300" />
Código de confidencialidad:
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25" />
Idioma en el que está expresado el documento:
<languageCode code="es-AR" />
5.2.2.2. Paciente

<
recordTarget
>

<patientRole>

<id extension="4116238-0" root="2.16.858.1.858.68909" />
<patient>
<name>
53
<given>Pablo</given>
<given>Federico</given>
<family>Pazos</family>
<family>Gutiérrez</family>
</name>
<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" />
<birthTime value="19811024" />
<ethnicGroupCode code="Blanca" codeSystem="1.2.3.4.5.6.11111" />
</patient>
</patientRole>
</
recordTarget
>
5.2.2.3. Autor del documento (ej. médico responsable)
Es el responsable de la autoría, puede no ser quien ingresa los datos en el sistema. El autor tiene otros atributos que
se pueden usar como el rol y la función particular que cumple en la atención.

<
author
>

<time value="20000407130000+0500"/>
<assignedAuthor>
<id root="20cf14fb-b65c-4c8c-a54d-b0cca834c18c"/>
<assignedPerson>
<name><prefix>Dr.</prefix><given>Robert</given><family>Dolin</family></name>
</assignedPerson>

<representedOrganization>
<id root="2.16.840.1.113883.19.5"/>
<name>Hospital Madariaga</name>
</representedOrganization>
</assignedAuthor>
</
author
>
5.2.2.4. Organización encargada de custodiar los documentos (ej. Ministerio de Salud)

<
custodian
>
<assignedCustodian>
<representedCustodianOrganization>
<id root="2.16.840.1.113883.19.6"/>
<name>Ministerio de Salud</name>
</representedCustodianOrganization>
</assignedCustodian>
</
custodian
>
5.2.2.5. Ejemplo de una sección Nivel 2 dentro del cuerpo del CDA
Esta es una sección simple que contiene información de signos vitales en texto libre (nivel 2) en un formato de tabla.
<component>
<section>
<code code="1234-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Signos"/>
54
<title>Signos</title>
<text>
<table>
<tbody>
<tr>
<th>Signo</th>
<th>Valor</th>
<th>Observación</th>
</tr>
<tr>
<td>Presión arterial</td>
<td>120/90 mmHg</td>
</tr>
<tr>
<td>Frecuencia cardiaca</td>
<td>75 latidos/min</td>
</tr>
<tr>
<td>Frecuencia respiratoria</td>
<td>16 respiraciones/min</td>
</tr>
<tr>
<td>Temperatura</td>
<td>37
°C
</td>
</tr>
</tbody>
</table>
</text>
</section>
</component>
5.2.3. Validando CDA
HL7 provee una serie de esquemas XML (XSD) que permite validar sintácticamente los documentos clínicos
generados o recibidos por un sistema. Dentro del curso utilizaremos una versión unificada del esquema para poder
validar nuestros documentos CDA.
55
6. Servicios Web
Los Servicios Web usualmente están asociados con SOAP, pero el término "Servicio Web" es más amplio y refiere a
cualquier tipo de servicio que se provee sobre la Web, independientemente del protocolo de comunicación que se
utilice para implementarlo. REST (REpresentational State Transfer en inglés) surge como una alternativa liviana a
SOAP para la implementación de Servicios Web, pero a diferencia de SOAP, REST es no es un protocolo de
comunicación, sino un conjunto de prácticas que definen un estilo arquitectónico para implementar Servicios Web
más simples y livianos.
6.1. REST
REST define ciertas reglas que permiten ejecutar operaciones sobre recursos. La implementación más frecuente es
utilizando HTTP como protocolo de transporte y los métodos HTTP como operaciones o verbos a ser ejecutados
sobre cierto recurso. Cada recurso de una aplicación es identificado mediante una URL. REST no define las
estructuras de datos que debe responder el servidor, esto debe ser un acuerdo entre cliente y servidor, por ejemplo
se podría devolver XML, JSON y otro formato, y su estructura interna dependerá de cada recurso.
Una de las características básicas de REST es que es "stateless", o sea que cada pedido contiene todo el estado
necesario para ejecutar cierta función, y un pedido no depende del estado de otro pedido anterior.
Otra característica es que los recursos pueden vincularse entre sí mediante links. Por ejemplo si una historia clínica
contuviera un conjunto de documentos, desde el recurso "historia" se podrían tener links a los recursos
"documento", ya sea a la colección de documentos o a cada documento individual.
6.1.1. Métodos HTTP y operaciones REST
Tal como vimos en la sección de Protocolos de Comunicación, HTTP provee métodos que indican al servidor cómo
debe procesar el pedido HTTP.
Método HTTP Operación REST Acción
GET Obtiene un recurso. Obtener conjuntos de objetos u objetos individuales.
POST Cambia el estado de un recurso. Crear objetos dentro de recursos.
Crear o modificar objetos. Sirve para crear cuando el

Crea o modifica el contenido de un
PUT cliente conoce la URL del recurso a crear, sino se
recurso existente.
conoce la URL del objeto a crear, se debe usar POST.
Elimina contenido de un recurso

DELETE Eliminar objetos.
existente.
56
Idempotencia y caché HTTP
Los método GET, PUT y DELETE son idempotentes, lo que significa que sucesivas llamadas idénticas, utilizando uno de
esos métodos, retornarán el mismo resultado. Se debe tener cuidado en la implementación del método DELETE,
porque si se hace una eliminación física del recurso, el DELETE no sería idempotente. Por otro lado, POST no es
idempotente, ya que sucesivas llamadas a POST sobre un recurso, crearán nuevas instancias del recurso, y devolverá
resultados distintos.
Una de las tantas características del protocolo HTTP es el caché, que permite acelerar las transacciones
notablemente, almacenando resultados asociados a ciertas URLs del lado del cliente. De este modo se evita la
ejecución de acciones y obtención de datos desde el servidor, lo que es más lento que solamente leer de nuevo los
datos del lado del cliente. El caché de HTTP funciona cuando se utilizan métodos idempotentes, por lo tanto en todas
las operaciones que se implementan por REST menos las que utilizan el método POST.
Ejemplos
Por ejemplo, podríamos decir que en el ámbito hospitalario tenemos los siguientes recursos:
● Historias: Historia Clínica Electrónica de los pacientes

● Paciente: pacientes de nuestro hospital
● Órdenes: órdenes de estudios diagnósticos
● Resultados: resultados de estudios diagnósticos
● Prescripciones: prescripciones de medicamentos
● Dispensaciones: dispensaciones de medicamentos a pacientes
Si quisiéramos operar sobre estos recursos, podríamos definir las siguientes URLs para identificarlos:
● /historias
● /pacientes
● /ordenes
● /resultados
● /prescripciones
● /dispensaciones
Métodos HTTP y recursos
Pedido HTTP Acción
GET /historias Obtiene todas las historias clínicas.
GET /historias/1234 Obtiene la historia clínica 1234.
POST /historias Crea una nueva historia clínica, la URL será determinada por el servidor.
PUT /historias/9876 Crea una nueva historia clínica "9876", la URL es determinada por el cliente.
PUT /historias/1234 Modifica el contenido de la historia clínica "1234".
57
DELETE /historias/1234 Elimia la historia clínica "1234"
En los casos de POST y PUT, es probable que el cliente envíe un objeto en el cuerpo del pedido HTTP, con la
información del recurso a crear o a ser modificado. Por ejemplo, un pedido HTTP completo para crear una historia
clínica, usando objetos JSON, sería:
POST /historias HTTP/1.1

Host: www.mihospital.com
Content-Type: application/json
{
"hce_uid": 4455,
"paciente_uid": 4567,
"creado": "2015-12-01T00:00:00.000Z",
"documentos": []
}
Si quisiéramos modificar el recurso creado, agregando un documento, podríamos enviar el siguiente pedido HTTP:
PUT /historias/4455 HTTP/1.1

Content-Type: application/json
{
"hce_uid": 1234,
"paciente_uid": 4567,
"creado": "2015-12-01T00:00:00.000Z",
"documentos": [
{
"fecha": "2015-12-02T00:00:00.000Z",
"tipo": "nota de consulta",
"texto": "el paciente presenta ..."
}
]
}
Esta sería una forma de agregar un documento a la historia clínica de un paciente, o sea modificando el recurso
/historias. Sin embargo, podría tenerse un recurso
/documentos que dependa del recurso /historias
, porque los
documento sólo existen en el contexto de una historia clínica. Entonces se podría tener la siguiente URL:
/historias/{hce_uid}/documentos , donde un GET obtendría todos los documentos dentro de una historia, un POST
crearía un nuevo documento dentro de la historia, etc.
Y para obtener la lista de todas las historias clínicas existentes, sólo haríamos:
GET /historias HTTP/1.1

La respuesta del servidor debería ser consistente con los formatos de objetos utilizados para crear recursos y
modificar recursos con pedidos POST y PUT. Pero utilizando el cabezal "Accept" podríamos solicitarle al servidor que
en lugar de retornar un objeto JSON, retorne un objeto XML, con los mismos datos / estructura de nuestros recursos.
XML:
58
Accept: application/xml
JSON:

Accept: application/json
Dado que el mismo recurso puede pedirse en distintos formatos (XML, JSON, HTML, etc.), decimos que un mismo
recurso tiene distintas representaciones.
Debe señalarse que no todos los métodos HTTP tienen siempre un correspondiente funcional dentro de un sistema,
por ejemplo se podría convenir que las historias clínicas no pueden eliminarse, por lo tanto DELETE no aplicaría al
recurso
/historias
.
Como puede apreciarse hay elementos REST que quedan abiertas a la implementación, dado que REST es un estilo
arquitectónico, una guía, no una especificación rigurosa de un protocolo de comunicación.
Resumen de características:
● Cada recurso tiene un identificador, la URL.

● Los recursos pueden vincularse mediante links.
● REST utiliza métodos estándar de HTTP.
● Un recurso puede tener múltiples representaciones.
● No se mantiene el estado entre pedidos (stateless).
REST y códigos de estado HTTP
REST reutiliza los código de estado definidos por HTTP (ver sección 2.3.4). Por ejemplo, si se intenta acceder a un
recurso y no se tienen los permisos para accederlo, la respuesta del servidor contendrá el estado 403 Forbidden. Si se
intenta crear un recurso enviando un pedido POST, si se pudo crear el recurso, el servidor retornará 201 Created.
Aquí puede encontrar una lista completa de códigos de estado de HTTP:

http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
Aquí puede encontrar una lista de códigos de estado HTTP que son utilizados comúnmente en REST:
http://www.restapitutorial.com/httpstatuscodes.html
59
6.2. REST vs SOAP
En la siguiente tabla se comparan algunos aspectos del enfoque de REST contra el protocolo SOAP para la
implementación de Servicios Web.
Característica REST SOAP
Protocolo Reutiliza HTTP Define uno nuevo (sobre HTTP en general)
Representación Cualquiera (XML, JSON, HTML, PDF, ...) XML
Estado Stateless Stateless ó Stateful
Contrato Documentación WSDL
Métodos HTTP GET, POST, PUT, DELETE POST
Caché HTTP Si, para operaciones GET, PUT y DELETE No, porque POST no es idempotente
Reutiliza los códigos de estado de HTTP para No utiliza códigos HTTP, utiliza el elemento
Estado informar al cliente de errores e información SOAP Fault para informar de errores.
sobre las respuestas.
60

Material Teórico

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Material Teórico

Hochgeladen von

Copyright:

Verfügbare Formate

Introducción a la Interoperabilidad entre Sistemas

Versión Fecha Autor

Figura 1: Paquete TCP

2.1.2. Sockets TCP

Figura 2: Primitivas de sockets TCP

2.2.1. Definición de bloques

En definitiva, un paquete MLLP tendrá la forma: <SB>data<EB><CR>

HTTP está especificado en: ​

2.3.3. Estructura de pedidos y respuestas HTTP

Ejemplo de pedido HTTP sin cabezales:

GET http://www.google.com HTTP/1.1

El mismo ejemplo utilizando el cabezal “Host” y una URL relativa:

Todos los cabezales se deben especificar con el formato “Nombre-Cabezal: Valor”6 .

Probar este ejemplo en TELNET (​

Nota: por cada “<CR><LF>” presionar la tecla enter.

telnet google.com 80<CR><LF>

Podrá ver una respuesta del servidor similar a esta:

HTTP/1.1 302 Found

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">

2.3.4. Códigos de estado HTTP

Los códigos de estado se clasifican en cinco grandes grupos:

● 1xx: Códigos de información

A continuación se listan algunos de códigos más comunes:

● 200 OK: respuesta ante una solicitud correcta.

Aquí puede encontrar una lista completa de códigos de estado HTTP:

Ejemplos de servicios SOAP online para probar clientes: ​

2.4.1. Terminología SOAP 1.2

SOAP Header Block

SOAP Message Path

Figura 3: estructura de mensajes SOAP

Invocación del servicio GetLastTradePrice con un parámetro symbol=DIS

POST /StockQuote HTTP/1.1

Respuesta del servicio con una variable Price=34.5

¿Cómo distinguir entre mensajes SOAP 1.1. y SOAP 1.2?

3.1.1. Comentarios sobre el formato XML

Una alternative utilizando atributos de elementos:

● Las etiquetas representan un elemento por su nombre.

Existen múltiples herramientas para validar documentos XML, por ejemplo: ​

3.2.1. Comentarios sobre el formato JSON

Ejemplo de mensaje HL7 v2.5 para admitir a un paciente:

En la sección 5.1.1 se verá el formato de mensajes HL7 v2.x.

Ejemplo de paso: eje::prueba[predicado/s]

4.1.1. Especificadores de ejes

Sintaxis completa Sintaxis abreviada Comentarios

@attr abrevia attribute::attr

child nombre_del_nodo nombre_del_nodo abrevia child::nombre_del_nodo

4.1.2. Prueba de nodo

Prueba Comentario Ejemplos

Ejemplo​: selecciona todos los penúltimos nodos

//*[@code and @codeSystem]

Un XSD está compuesto por los siguientes elementos:

4.2.1.1. Definición de tipo para el elemento ClinicalDocument

4.2.2. Validación de XML contra XSD

En Windows, se puede utilizar la herramienta Notepad++ con el plugin XML Tools: ​

En Linux, se puede utilizar la herramienta xmlint: ​

Para validación en línea, existen un sinnúmero de opciones, una de ellas:

5.1. HL7 v2.x

5.1.1. Formato de mensajes HL7 v2.x

Figura 4: modelo general de mensajes HL7 v2.x

5.1.3.4. Tipo de dato

Mensaje para órdenes de farmacia o tratamientos.

Respuesta a mensajes de órdenes de laboratorio (OML). Se utiliza como acknowledge. Ejemplo:

Mensaje de respuesta a la dispensación de farmacia o tratamiento (RDS). Se utiliza como acknowledge.

5.1.3.1. Eventos para admisiones, altas y transferencias (ADT)

HTTP está especificado en:

Probar este ejemplo en TELNET (

Ejemplos de servicios SOAP online para probar clientes:

Existen múltiples herramientas para validar documentos XML, por ejemplo:

Ejemplo: selecciona todos los penúltimos nodos

En Windows, se puede utilizar la herramienta Notepad++ con el plugin XML Tools:

En Linux, se puede utilizar la herramienta xmlint: