See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/237793033

Proyecto de integración de sistemas de

información sanitaria mediante un motor de
integración y el estándar HL7

Article

CITATION READS

1 5

5 authors, including:

P. Ferriol Monserrat
iBit Foundation
12 PUBLICATIONS 12 CITATIONS

SEE PROFILE

Available from: P. Ferriol Monserrat

Retrieved on: 29 May 2016
 Proyecto de integración de sistemas de información sanitaria
mediante un motor de integración y el estándar HL7
S. Ramis Oliver, P. M. Hurtado Garí, F. Tous Llull, P. Ferriol Montserrat
Fundació IBIT, Palma de Mallorca, España, {sramis, phurtado, xtous, pferriol}@ibit.org
Resumen
En este artículo se tratará el caso real de un proyecto piloto en
el Hospital Universitario Son Dureta, de Palma de Mallorca
para la implantación de un portal médico único. En el marco de
desarrollo de este proyecto, trataremos la necesidad de
integración de aplicaciones en el entorno sanitario, mediante la
utilización de un motor de integración y un estándar de
comunicaciones como es HL7 [1].
También se tratará la implantación de un repositorio de
documentación clínica como es Healthcare Transaction Base
(HTB) de Oracle [2] que utiliza mensajería HL7 en versión 3,
para la gestión de toda la información generada en el entorno.
1. Introducción
En el marco de los sistemas de información (SI) en el
entorno sanitario es imprescindible tener en cuenta la
problemática habitual: existen múltiples sistemas de
información independientes, de diferentes proveedores de
software, que constituyen islas de información dentro del
entorno. El principal objetivo a alcanzar en dicho entorno
es la interoperabilidad [3]: intercomunicar e integrar los
diferentes SI, para lograr el intercambio de información
entre ellos.
Vamos a presentar el caso concreto de la integración de
aplicaciones en el marco del proyecto piloto del ib-salut
en el Hospital Son Dureta, en las Illes Balears.
El objetivo principal de este proyecto ha sido la
implementación de un portal médico único para el
servicio de urgencias del hospital, que permita a los
médicos generar peticiones a los laboratorios, así como la
visualización de los resultados recibidos desde estos.
Tanto las peticiones como los resultados del laboratorio
son almacenados en un repositorio único de información.
Dentro de este proyecto, se ha hecho patente la necesidad
de integrar los diferentes SI implicados, por ejemplo los
SI de cada uno de los laboratorios o el HIS (Hospital
Information System) de pacientes. Para la integración de
estos SI existen múltiples alternativas, en nuestro caso
veremos el uso del estándar de comunicación HL7 [4] y la
utilización de un motor de integración.
2. Arquitectura
Como ya hemos introducido anteriormente, para lograr la
integración de las aplicaciones del hospital implicadas,
con el portal médico y el repositorio de información,
hemos utilizado un motor de integración y el estándar de
comunicación HL7 que nos permite la implementación de
una mensajería común para el intercambio de la
información entre las aplicaciones, el portal médico y el
repositorio.
Para el repositorio de documentos clínicos, se seleccionó
un producto de Oracle, Healthcare Transaction Base
(HTB), por estar diseñado sobre el modelo de
información del estándar HL7 v3 (HL7 RIM, Reference
Information Model) [5] y ser ideal para almacenar la
información contenida en esta mensajería.
El portal médico es una implementación de la empresa
Orion Health de su herramienta Concerto, que se sirve de
otra herramienta llamada Soprano para la generación y
envío de las peticiones realizadas por los médicos.
Como motor de integración se utiliza también un producto
de Orion, llamado Rhapsody.
Al ser un proyecto piloto se planificó la integración de
algunos de los SI existentes, concretamente:
• La aplicación del laboratorio de Anatomía Patológica
(APA), llamada Patwin de iSoft.
• La aplicación utilizada en el laboratorio de Análisis
Clínicos (Lab), de Bayer.
• Y la aplicación de Radiología (Rad), de Amersham
Health.
Además de los laboratorios, al estar tratando con
peticiones de pruebas y resultados de laboratorio, es
necesario incorporar información que permita identificar
al médico solicitante de la prueba, así como identificación
del paciente. Para ello era necesario integrar, también:
• El SI de administración de pacientes, HIS de HP.
• Y la aplicación custom de Personal del hospital.
Personal
Lab
Concerto Rhapsody APA
Rad
HIS HTB
 Figura 1.Arquitectura almacenadas en HTB. También se mapean las peticiones
El problema para intercomunicar todos estos SI y para el laboratorio de APA a HL7 v2.3.1 para que las
compartir la información necesaria, era que no todos ellos pueda manejar e interpretar Patwin, la aplicación de este
generaban mensajería que nos permitiera comunicar unos laboratorio.
con otros, incluso que no todos los que la generaban lo XML a ORM
hacían usando un estándar: HL7 v2.3.1 APA (HL7 v2.3.1)
• Amersham no genera mensajería, sino que Portal
almacenaba las peticiones y los resultados en una médico
XML a HL7 v3
base de datos de SQL Server. (XML) HTB (HL7 v3)
• Bayer proporciona mensajería en un estándar anterior
a HL7, denominado ASTM.
Figura 2. Comunicación para peticiones
• Patwin produce mensajería en HL7 v2.3.1 con ciertas
restricciones propias. El formato XML del portal reproduce los campos de las
peticiones del HL7 v2.3 (ORM). Por lo que este mapeo
• HIS genera mensajería HL7 v2.3.1.
resulta bastante sencillo.
• Personal genera una mensajería propia y no estándar.
• HTB usa mensajería en HL7 v3. 3.2. Ruta para resultados entre laboratorios y HTB
• El portal médico genera mensajes en un formato Los resultados que se recogen de Patwin / APA se
XML propio, pero orientado a un fácil mapeo a HL7 traducen de HL7 v2.3.1 a HL7 v3, mientras que los
v2.x. mensajes de resultados del laboratorio se traducen de
Debido a estas diferencias en las capacidades de ASTM a HL7 v3, para ser enviados al HTB. El mensaje
intercomunicación de cada una de las aplicaciones de APA es un mensaje tipo ORU de HL7, mientras que el
implicadas, era necesario el uso de un motor de de laboratorio también es un ORU pero de ASTM.
integración que nos permitiera implementar las rutas o Ambos mensajes son similares pero no idénticos, por lo
vías de comunicación necesarias para el adecuado que los mapeos son diferentes.
intercambio de datos entre los SI.
ORU v2.3.1 a v3
APA (HL7 v2.3.1)
3. Rutas de comunicación entre SI
HTB
Las rutas se organizan en función del tipo de información (HL7 v3)
que transmiten, del origen y del destino de dichos datos: Lab (ASTM)
ORU ASTM a v3
• Rutas que recogen las peticiones generadas en el
portal médico y las clasifican por laboratorio de Figura 3. Comunicación para resultados
destino, mapean al formato correcto y envían a la
aplicación destino correspondiente. 3.3. Ruta para alta/modificación de pacientes
• Rutas que recogen las peticiones generadas en el Los mensajes de alta/modificación de los pacientes del
portal médico las mapean a HL7 v3 y envían a HTB. HIS deben ser registrados en HTB se obtienen por una
• Rutas que recogen los resultados generados por cada conexión TCP. Estos mensajes tienen el formato
uno de los laboratorios, mapean a HL7 v3 y envían a ADTA08 HL7 v2.3.1, y se deben traducir a HL7 v3 para
HTB. HTB.
• Ruta que recoge los mensajes de alta/modificación de
pacientes del HIS a HTB. Alta paciente HL7 v3

• Ruta que recoge los mensajes de alta/modificación de HIS

HTB
empleados de Personal a HTB. (HL7 v2.3.1) (HL7 v3)
• Ruta para los mensajes de cancelación de la petición
desde la aplicación del laboratorio, y la envían Figura 4.Comunicación para alta pacientes
paralelamente al portal médico y a HTB.
La visualización de resultados en el portal médico, se 3.4. Ruta para alta/modificación de personal
realiza mediante un java API de Oracle para el acceso y Los mensajes de alta/modificación de personal se reciben
gestión de la información del HTB. a través de una conexión FTP y llegan en un formato
propio. Deben ser traducidos a HL7 v3 para enviarlos a
3.1. Comunicación para peticiones entre el portal,
HTB.
los laboratorios y el HTB
Las peticiones para los distintos laboratorios que son
generadas por los médicos desde el portal, son
“traducidas” desde el formato xml propio en el que se
generan las peticiones a HL7 v3, para ser enviadas y

Alta personal en HL7 v3
HTB
Personal
(HL7 v3)
Figura 5.Comunicación para personal
3.5. Ruta para cancelaciones de peticiones desde
laboratorio
Las peticiones de APA pueden ser canceladas una vez que
llegan a la aplicación, este hecho debe ser comunicado y
actualizada la información en el portal médico.
Para ello se deben diferenciar los mensajes de cancelación
de los mensajes de resultados, porque vienen por el
mismo canal de comunicación que estos. Las
cancelaciones son mensajes de petición con un código
que lo identifica como petición cancelada. Para cada
petición cancelada debe generarse un mensaje de
cancelación para el portal, y otro para HTB.
HTB
Cancelación en v3
(HL7 v3)
APA
(HL7 v2.3.1) Portal médico
Cancelación en XML (XML)
Figura 6.Comunicación para cancelaciones
4. HL7 v3 y HTB
Debido a la utilización de HTB como repositorio, ha sido
necesario familiarizarse con la mensajería de la versión 3
de HL7. La estructura de HTB se basa en el modelo de
información de dicha versión de HL7, pero con ciertas
restricciones adicionales en cuanto a la obligatoriedad de
algunos campos, que en el estándar son opcionales.
Las aplicaciones puede que usen terminologías propias o
que usen algún estándar como CIE, SNOMED o LOINC,
o puede que las empleen también para la codificación de
algunos datos como sexo, tipo de muestra, etc.
El HTB proporciona una serie de herramientas
adicionales para la gestión de terminologías y tablas de
conceptos, de forma que se puedan establecer
correlaciones entre distintos conceptos de dichas tablas.
La mensajería generada es de distintos tipos:
• Person Registry, es el tipo de mensaje para el alta
/modificación de personas, que se ha usado en la ruta
de comunicación de alta de pacientes. También se ha
usado para la ruta del personal, porque es necesario
primero dar de alta en HTB a la persona, y luego
asignarle un rol (un rol es el papel que desempeña en
un escenario concreto) como empleado dentro de la
organización.
• Staff Registry, para el alta/modificación de roles de
empleado (conjuntamente con el Person Registry).
Para cada rol (cada tipo de identificador que se desea
usar: categoría, puesto trabajo, código del servicio al
que pertenecen, etc.) se necesita un mensaje de Staff
diferente.
• Specimen Observation Order, para las peticiones de
pruebas a los laboratorios y los mensajes de
cancelación de peticiones.
• Specimen Observation Event, para los resultados de
las peticiones.
• Observation Order, para las peticiones de pruebas a
radiología que van al HTB.
5. OID (Object Identifier)
Para cada una de las aplicaciones que participan en alguna
de las rutas anteriores, se necesita un identificador único
para usarlo en los mensajes e identificar a dicha
aplicación como emisor o receptor del mensaje. Para ello,
el ib-salut solicitó de forma gratuita un OID [6] a la
organización HL7, de forma que a partir de dicho OID se
puede establecer una jerarquía de entidades,
organizaciones y aplicaciones que dependen de dicha
entidad, y que se pueden identificar a nivel internacional
de forma única, a partir del número correspondiente.
Usando un OID como base, en este caso el del ib-salut, y
añadiendo un número correspondiente a una secuencia,
para todas aquellas entidades que dependan directamente
del OID base, establecemos un primer nivel de la
jerarquía, y así sucesivamente para identificar todos los SI
necesarios.
Este sistema cuenta con la ventaja adicional de que en
cualquier momento se pueden asignar nuevos OIDs en el
entorno, simplemente siguiendo la secuencia iniciada. Por
lo que nunca nos encontraremos limitados en cuanto al
número máximo de OIDs a asignar, incluso
incrementando el número de niveles en la jerarquía de
forma sencilla y limpia.
6. Formato de mensaje HL7 v3
La mensajería del la v3 es en formato XML. Se compone
de tres capas, siguiendo el modelo de información del
estándar:
• Message / Transport Wrapper
• Control / Event Wrapper
• Message Domain Payload
Según el tipo de mensaje a generar, debemos usar un
Message y un Control Wrapper concretos, para ello
existen unas tablas de correspondencias. Una vez
seleccionado el tipo de mensaje y las capas, hay que
identificar el tipo de evento que vamos a usar, es decir el
código que identifica si el mensaje es de alta,
modificación, actualización, cancelación, entre otros. Para
ello, existe un diagrama de estados que los describe, para
cada tipo de mensaje. Es el mismo concepto de trigger
event de las versiones anteriores de HL7, pero con valores
diferentes, al igual que los tipos de mensajes.
El Message Wrapper es la cabecera del mensaje y controlar si los mensajes son almacenados correctamente
contiene la información de identificación única del o no en HTB.
mensaje, y la información de transporte: quién es el
Los mensajes de respuesta de HTB son de tipo
emisor del mensaje, quién el receptor y quién se
Application Acknowledgement Wrapper. En él se indica si
responsabiliza de la respuesta. También contiene la
el mensaje ha sido aceptado o rechazado, y el
información del trigger event correspondiente.
identificador del mensaje enviado.
El Control Wrapper describe el tipo de evento o acto
De esta forma se puede controlar el buen funcionamiento
médico del mensaje. Puede incluir información del autor
de la comunicación con HTB, detectar si los mensajes
del mensaje, la persona que introduce los datos, la razón
contienen errores de sintaxis, identificar cuáles son los
por la que se crea el mensaje, etc.
mensajes erróneos y tomar medidas en caso necesario
El Message Domain Payload constituye el cuerpo del para corregirlos.
mensaje HL7 v3, y contiene la información del acto
médico a registrar, por ejemplo el alta de un paciente, o
Mensajes en HL7 v3
una petición al laboratorio. HTB
SI (HL7 v3)
La versión 3 de HL7, parte de un modelo de información
de referencia, denominado RIM. El RIM es un diagrama ACK en HL7 v3
de clases que modela toda la información del dominio de
la salud. Está formado por un núcleo de 5 clases
principales, que son: Figura 7. Respuestas del HTB

• Entidad: es una instancia de una cosa física, persona,

8. Conclusiones
u organización, con capacidad para participar en
alguna actuación. Uno de los principales obstáculos al principio del
• Rol: es una clasificación de los papeles que puede proyecto fue la falta de experiencia con HL7 v3 y HTB, lo
desempeñar una entidad, independientemente de la que supuso invertir cierto tiempo en su aprendizaje.
actuación. El motor de integración ha sido un elemento clave en el
• Actuación: es una acción en el dominio de la salud, éxito del proyecto, facilitando la tarea de interconexión de
que ha sido realizada, se está realizando o se los distintos SI implicados.
realizará. La arquitectura seleccionada permite extender fácilmente
• Participación: es una asociación entre un rol y una la solución de integración a nuevos SI del hospital,
actuación. Está limitada por el alcance de la proporcionando una buena alternativa para la evolución
actuación, a diferencia del rol. del entorno del hospital en el futuro.
• Actuación relacionada (Act Relationship): es una
asociación entre un par de actuaciones. Agradecimientos
Message Control Nuestros agradecimientos a todas las empresas, entidades
Capa Payload y personas que han participado en este proyecto y nos han
Wrapper Wrapper
proporcionado su ayuda y soporte en la realización de este
Person MCCI_MT000 MFMI_MT70 PRPA_MT201 artículo.
Registry 100HT02 0700HT01 000HT02

Staff MCCI_MT000 MFMI_MT70 MFPM_MT01 Referencias

Registry 100HT02 0700HT01 0000HT02
[1] Oracle Healthcare Transaction Base. HL7 Version 3
Conformance Specification Release 11i-v5 Messaging
Specimen
MCCI_MT000 MCAI_MT000 POXX_MT12 Services. Oracle Corporation. 2005.
Observation 100HT03 001HT03 1000HT02
Order [2] Oracle Healthcare Transaction Base. Implementation Guide
Release 11i. Oracle Corporation. 2005.
Specimen
MCCI_MT000 MCAI_MT000 POXX_MT11 [3] Ferriol P, Tous F, Oliver J, Ramis S. Interoperabilidad
Observation 100HT02 001HT02 1000HT01 entre aplicaciones sanitarias. XXIII Congreso Anual de la
Result
Sociedad Española de Ingeniería Biomédica (CASEIB
Observation MCCI_MT000 MCAI_MT000 POXX_MT12 2005), pp 499-502 (ISBN: 84-7402-325-4)
Order 100HT03 001HT03 0000HT03
[4] Página web de Health Level Seven. http://www.hl7.org
(Consultada: agosto 2006).
Tabla 1. Formato HL7 v3
[5] Understanding Version 3. A primer on the HL7 Version 3
Communication Standard. Andrew Hinchley. ISBN 3-
7. Respuestas de HTB 933819-18-0; Alexander Moench Publishing, Munich, 83
páginas.
HTB responde con mensajes de aceptación o rechazo a la
mensajería que se le envía. De este modo podemos
[6] Página web de registro de OID de Health Level Seven.
http://www.hl7.org/oid/index.cfm (Consultada en
agosto 2006)