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 hemos utilizado un motor de integración y el estándar de

En este artículo se tratará el caso real de un proyecto piloto en comunicación HL7 que nos permite la implementación de
el Hospital Universitario Son Dureta, de Palma de Mallorca una mensajería común para el intercambio de la
para la implantación de un portal médico único. En el marco de información entre las aplicaciones, el portal médico y el
desarrollo de este proyecto, trataremos la necesidad de repositorio.
integración de aplicaciones en el entorno sanitario, mediante la
utilización de un motor de integración y un estándar de Para el repositorio de documentos clínicos, se seleccionó
comunicaciones como es HL7 [1]. un producto de Oracle, Healthcare Transaction Base
(HTB), por estar diseñado sobre el modelo de
También se tratará la implantación de un repositorio de información del estándar HL7 v3 (HL7 RIM, Reference
documentación clínica como es Healthcare Transaction Base Information Model) [5] y ser ideal para almacenar la
(HTB) de Oracle [2] que utiliza mensajería HL7 en versión 3, información contenida en esta mensajería.
para la gestión de toda la información generada en el entorno.
El portal médico es una implementación de la empresa
Orion Health de su herramienta Concerto, que se sirve de
1. Introducción otra herramienta llamada Soprano para la generación y
envío de las peticiones realizadas por los médicos.
En el marco de los sistemas de información (SI) en el
entorno sanitario es imprescindible tener en cuenta la Como motor de integración se utiliza también un producto
problemática habitual: existen múltiples sistemas de de Orion, llamado Rhapsody.
información independientes, de diferentes proveedores de
Al ser un proyecto piloto se planificó la integración de
software, que constituyen islas de información dentro del
algunos de los SI existentes, concretamente:
entorno. El principal objetivo a alcanzar en dicho entorno
es la interoperabilidad [3]: intercomunicar e integrar los • La aplicación del laboratorio de Anatomía Patológica
diferentes SI, para lograr el intercambio de información (APA), llamada Patwin de iSoft.
entre ellos. • La aplicación utilizada en el laboratorio de Análisis
Vamos a presentar el caso concreto de la integración de Clínicos (Lab), de Bayer.
aplicaciones en el marco del proyecto piloto del ib-salut • Y la aplicación de Radiología (Rad), de Amersham
en el Hospital Son Dureta, en las Illes Balears. Health.
El objetivo principal de este proyecto ha sido la Además de los laboratorios, al estar tratando con
implementación de un portal médico único para el peticiones de pruebas y resultados de laboratorio, es
servicio de urgencias del hospital, que permita a los necesario incorporar información que permita identificar
médicos generar peticiones a los laboratorios, así como la al médico solicitante de la prueba, así como identificación
visualización de los resultados recibidos desde estos. del paciente. Para ello era necesario integrar, también:
Tanto las peticiones como los resultados del laboratorio
• El SI de administración de pacientes, HIS de HP.
son almacenados en un repositorio único de información.
• Y la aplicación custom de Personal del hospital.
Dentro de este proyecto, se ha hecho patente la necesidad
de integrar los diferentes SI implicados, por ejemplo los
Personal
SI de cada uno de los laboratorios o el HIS (Hospital Lab
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 Concerto Rhapsody APA
utilización de un motor de integración.

2. Arquitectura Rad
HIS HTB
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,
 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
 Para cada rol (cada tipo de identificador que se desea
Alta personal en HL7 v3 usar: categoría, puesto trabajo, código del servicio al
HTB que pertenecen, etc.) se necesita un mensaje de Staff
Personal diferente.
(HL7 v3)
• Specimen Observation Order, para las peticiones de
Figura 5.Comunicación para personal pruebas a los laboratorios y los mensajes de
cancelación de peticiones.
3.5. Ruta para cancelaciones de peticiones desde • Specimen Observation Event, para los resultados de
laboratorio las peticiones.
Las peticiones de APA pueden ser canceladas una vez que • Observation Order, para las peticiones de pruebas a
llegan a la aplicación, este hecho debe ser comunicado y radiología que van al HTB.
actualizada la información en el portal médico.
5. OID (Object Identifier)
Para ello se deben diferenciar los mensajes de cancelación
de los mensajes de resultados, porque vienen por el Para cada una de las aplicaciones que participan en alguna
mismo canal de comunicación que estos. Las de las rutas anteriores, se necesita un identificador único
cancelaciones son mensajes de petición con un código para usarlo en los mensajes e identificar a dicha
que lo identifica como petición cancelada. Para cada aplicación como emisor o receptor del mensaje. Para ello,
petición cancelada debe generarse un mensaje de el ib-salut solicitó de forma gratuita un OID [6] a la
cancelación para el portal, y otro para HTB. 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
HTB entidad, y que se pueden identificar a nivel internacional
Cancelación en v3
(HL7 v3) de forma única, a partir del número correspondiente.
APA
Usando un OID como base, en este caso el del ib-salut, y
(HL7 v2.3.1) Portal médico añadiendo un número correspondiente a una secuencia,
para todas aquellas entidades que dependan directamente
Cancelación en XML (XML) del OID base, establecemos un primer nivel de la
jerarquía, y así sucesivamente para identificar todos los SI
Figura 6.Comunicación para cancelaciones necesarios.
Este sistema cuenta con la ventaja adicional de que en
4. HL7 v3 y HTB cualquier momento se pueden asignar nuevos OIDs en el
entorno, simplemente siguiendo la secuencia iniciada. Por
Debido a la utilización de HTB como repositorio, ha sido
lo que nunca nos encontraremos limitados en cuanto al
necesario familiarizarse con la mensajería de la versión 3
número máximo de OIDs a asignar, incluso
de HL7. La estructura de HTB se basa en el modelo de
incrementando el número de niveles en la jerarquía de
información de dicha versión de HL7, pero con ciertas
forma sencilla y limpia.
restricciones adicionales en cuanto a la obligatoriedad de
algunos campos, que en el estándar son opcionales.
6. Formato de mensaje HL7 v3
Las aplicaciones puede que usen terminologías propias o
que usen algún estándar como CIE, SNOMED o LOINC, La mensajería del la v3 es en formato XML. Se compone
o puede que las empleen también para la codificación de de tres capas, siguiendo el modelo de información del
algunos datos como sexo, tipo de muestra, etc. estándar:

El HTB proporciona una serie de herramientas • Message / Transport Wrapper

adicionales para la gestión de terminologías y tablas de • Control / Event Wrapper
conceptos, de forma que se puedan establecer • Message Domain Payload
correlaciones entre distintos conceptos de dichas tablas.
Según el tipo de mensaje a generar, debemos usar un
La mensajería generada es de distintos tipos: Message y un Control Wrapper concretos, para ello
• Person Registry, es el tipo de mensaje para el alta existen unas tablas de correspondencias. Una vez
/modificación de personas, que se ha usado en la ruta seleccionado el tipo de mensaje y las capas, hay que
de comunicación de alta de pacientes. También se ha identificar el tipo de evento que vamos a usar, es decir el
usado para la ruta del personal, porque es necesario código que identifica si el mensaje es de alta,
primero dar de alta en HTB a la persona, y luego modificación, actualización, cancelación, entre otros. Para
asignarle un rol (un rol es el papel que desempeña en ello, existe un diagrama de estados que los describe, para
un escenario concreto) como empleado dentro de la cada tipo de mensaje. Es el mismo concepto de trigger
organización. event de las versiones anteriores de HL7, pero con valores
diferentes, al igual que los tipos de mensajes.
• Staff Registry, para el alta/modificación de roles de
empleado (conjuntamente con el Person Registry).
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)