SIS09 Segarra Diaz

See
discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/271445156
SIS-Interfaces HL7 para una implementación

RIS
Article · January 2009
CITATIONS READS
0 503
2 authors, including:
Martín M. Diaz Maffini

Hospital Alemán
22 PUBLICATIONS 11 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
BackOffice de Internación View project
HCI-REPRO View project
All content following this page was uploaded by Martín M. Diaz Maffini on 27 January 2015.
The user has requested enhancement of the downloaded file.

Desarrollo e implementación de una interfaz HIS/RIS-PACS
usando mensajería HL7
Segarra G.1, Diaz M.2

1Áreade Desarrollo de Sistemas Hospital Alemán de Buenos Aires,2 Área de Informática
Médica del Hospital Alemán de Buenos Aires
Resumen
En el servicio de Imágenes del Hospital Alemán se decidió mejorar la calidad y reducir la impresión de
placas incorporando un sistema RIS/PACS. Una de las premisas fue que tuviera una interfaz con la
historia clínica del Hospital, para compartir las imágenes y los resultados ,como así también los
procesos administrativos.
Este artículo describe las características principales de esa implementación usando las interfaces
provistas por el RIS adquirido para cumplir con el mencionado fin y una breve descripción de cómo se
desarrollo la mensajería..
Palabras Clave
HL7, RIS, HIS, PACS,XML
Introducción
Un Sistema de Información Radiológica RIS (Radiology Information System), es la
herramienta informática que nos permite realizar los procesos de gestión de un
departamento de radiología; gestiona la información y sostiene la comunicación del
departamento con otros servicios de información del hospital.
DICOM (Digital Imaging and Communication in Medicine) es el estándar reconocido

mundialmente para el intercambio de imágenes médicas, pensado para el manejo,
almacenamiento, impresión y transmisión de las mismas. Incluye la definición de un
formato de archivo y de un protocolo de comunicación de red. Los ficheros DICOM
pueden intercambiarse entre dos entidades que tengan capacidad de recibir imágenes y
datos de pacientes en formato DICOM.1
El PACS (Picture Archiving and Communication System) automatiza el proceso de

obtención de imágenes digitales desde equipos de imagenología existentes
(Tomógrafos, Ecógrafos, Resonadores), generalmente utilizando el estándar DICOM.
Trabaja en forma integrada con el RIS, ya que este es el encargado de enviarle las
ordenes médicas, la información con respecto a los pacientes, los médicos y también de
administrar las agendas de turnos de las diferentes modalidades y salas del
departamento de imágenes.2
Parte conformante del HIS (Hospital Information System), es el sistema que administra
los servicios del Hospital, las agendas, la generación de las ordenes médicas como así
también la facturación de los mismos. Tambien forma parte del HIS el servidor de
resultados que permite cargar los informes de los estudios complementarios realizados
en el hospital y comunica a los diferentes usuarios los mismos.3
HL7 (Health Level Seven) es una organización sin fines de lucro que desarrolla
estándares para maximizar las compatibilidades entre sistemas de información en salud,
permitiendo la interacción y el intercambio productivo de datos entre aplicaciones
heterogéneas, independientemente de su plataforma tecnológica o de su lenguaje de
desarrollo.4
Diferentes sectores: prestadores de servicios de salud, desarrolladores de software,

consultores, usuarios finales, organizaciones gubernamentales y no gubernamentales;
participan en forma colaborativa en la discusión y en el desarrollo de estándares por
consenso, en un entorno abierto. Estos estándares ofrecen un marco que permite a los
diferentes sistemas de información, comunicarse a través de mensajes que viajan por
una única interfaz.
En el sector de salud, cada vez se toma más como un estándar, para poder integrarse con
aplicaciones ya existentes, simplificando la integración y reutilización de herramientas
ya desarrolladas. También reduce la posibilidad de error ya que habitualmente HL7 ya
se encuentra en uso.
No se consideró ningún RIS que no tuviera HL7 incorporado.
Descripción de escenario inicial

El Hospital Alemán cuenta con desarrollos de sistemas propios para el sector
administrativo desde hace más de una década. En los últimos años, ha desarrollado un
registro de datos clínicos centralizado y digital, con acceso universal desde el propio
hospital y los consultorios periféricos y sedes anexas.
En el último año se incorporó el estándar de mensajería HL7 en el sector de Terapia

Intensiva, para aceptar y enviar mensajes de los monitores de signos vitales. Este
proyecto fue desarrollado por completo y está actualmente en la etapa de
implementación.
A mediados de 2007 se tomó la decisión de incorporar las imágenes médicas generadas

en el HA a la Historia Clínica Electrónica en desarrollo en ese momento y brindar
acceso digital a las imágenes desde cualquier punto del hospital o incluso fuera de él. Se
evaluaron varios sistemas de PACS y RIS, de distintos empresas, open source y hasta
eventualmente se barajó la posibilidad de desarrollar uno propio.
La reducción de las impresiones de las placas radiográficas fue otro factor determinante
para llevar adelante el proyecto. Finalmente se tomo la decisión de instalar PACS y RIS
tercerizado de la misma empresa.
Al contar con algunas funciones de RIS en el HIS propio desarrollado oportunamente
por la gerencia de Sistemas del Hospital, la evaluación sobre que íbamos a usar del RIS,
que íbamos a poner el Hospital y como se iban a comunicar los distinto componentes de
la implementación (HIS-RIS-PACS) fue un factor clave en la etapa de relevamiento y
negociación con la empresa proveedora del RIS-PACS.5
Para la incorporación del RIS, fue siempre una condición que las interfaces fueran HL7,
pues ya contábamos con gateways HL7 y experiencia en el manejo del estándar, y que
se modificaran la menor cantidad de aplicaciones existentes, para que fuera transparente
para los usuarios que no lo usaban directamente (empleados administrativos de atención
al cliente, ingreso de altas, etc.).
El Departamento de Imágenes del hospital cuenta con equipos de diversas marcas por lo
que era necesario que se pudiera establecer la comunicación con cada uno de ellos de
manera eficaz.
Descripción de la solución
El primer paso de la implementación fue definir la información que iba a ser

compartida entre HIS y RIS y cuáles eran los flujos de trabajo de cada una de ellas, para
determinar los sistemas a integrar y en qué lugares podía afectar la implementación.
Una vez obtenido esto, se diagramaron cada uno de los flujos de trabajo, especificando
donde se usaba la mensajería y cuáles eran los mensajes que iban a ser utilizados.
También se definió quienes y que sectores participaban de los procesos.
Las interfaces más importantes a definir eran las que afectaban la operatoria diaria, ya
que no se debía empeorar la calidad de la atención. Estas son :
Ingreso de Ordenes Médicas
Informe de los estudios complementarios
Definición de Imágenes
Las otras interfaces que se tuvieron que definir fueron :
Gestión de Pacientes
Gestión de Médicos
Procesos de Facturación
Ingreso de Ordenes Médicas

Esta fue la más complicada de definir. El RIS adquirido incluye la admisión de
pacientes y el agendamiento de turnos. En un principio se propuso que el ingreso de los
pacientes se hiciera desde el RIS. Esto implicaba que el Hospital tenía que cambiar el
sistema de ingreso de ordenes médicas para el servicio de Imágenes. Esto no era
aceptado por el área administrativa que exigía el mismo sistema para todo el Hospital,
ya que existe un número muy grande de usuarios que rota regularmente.
Lo mismo ocurría con el sistema de turnos, donde se hubiera tenido un sistema para los
estudios de imágenes y otro para los demás estudios que realiza el Hospital (al momento
de implementar el RIS se estaba terminando de desarrollar un nuevo sistema de turnos
que se adaptaba exactamente a las necesidades de todos los servicios del Hospital ).
Después de analizar con detalle todos los escenarios posibles, se decidió a que el
ingreso se hiciera por el HIS del Hospital. Al finalizar el ingreso se llama al RIS, donde
se escanea la orden médica y se arriba al paciente, donde queda ya disponible para ser
llamado para la realización del estudio.
El RIS informa los estados en los que va estando la orden médica (Iniciada, Finalizada,
etc) y la orden escaneada.
Los turnos asignados se iban a mantener en ambos sistemas, pero se decidió que no era
necesario y que no aportaba mayor información. Igualmente fue desarrollada la interfaz.
Los ingresos de las ordenes médicas se pueden realizar, tanto desde el servicio de
Imágenes, como desde el servicio de Emergencias y Pediatría.
HIS RIS
Ingreso orden médica
Estado de la orden
Los estudios que realiza el Hospital debieron ser relevados uno por uno para poder
establecer una relación con los definidos para el RIS. Para hacer esto se tuvo que contar
con un usuario clave en cada área para definir estas relaciones. Esto no fue un tema
trivial ya que la apertura desde el punto de vista administrativo o de la orden médica, al
definido en el RIS es muy diferente y conllevo el desarrollo de un modelo de datos ad
hoc que será material de otra comunicación.
Informe de los estudios
El Hospital cuenta con un sistema de informes desarrollado hace varios años. Todos los
informes son ingresados desde este sistema y es el que se visualiza desde la historia
clínica.
Con la incorporación del RIS, todos los informes del departamento de Imágenes
empezaron a ingresarse desde la nueva herramienta. Era importante para el Hospital
conservar todos los informes anteriores y respetar el formato actual de los mismos, por
lo que se adaptó el informe del RIS al formato actual de tal manera que no haya
diferencias con los que se venían haciendo, ni con los demás informes que se realizan
actualmente. Este fue otro factor clave de éxito para el desarrollo del proyecto, ya que
para los usuarios el cambio de sistema fue transparente.
Una vez generado el informe este es enviado al HIS para poder ser visualizado. Los
informes tienen cuatro estados posibles
Pre-Informe
Validado
Invalidado
Eliminado
El pre-informe es el informe preliminar que es importante para los servicios de

emergencia y de internación. Se discutió mucho sobre si debía mostrarse el resultado del
informe en la historia clínica o solo informar el estado. Se decidió por ambas. Los pre-
informes se muestran con una leyenda donde se indica que es un informe preliminar. Al
generarse el informe validado se cambia el estado del informe y el contenido, de ser
necesario.
El ingreso de los informes y su administración es realizada toda desde el RIS.
RIS Historia Clínica
Informe
Imágenes
Para la visualización de las imágenes, hubo que instalar una pieza de software (cliente
PACS) en cada equipo donde se deba utilizarse. El cliente permite realizar diferentes
operaciones con las imágenes, como aumentarlas o rotarlas.
Se tomó la decisión de imprimir a demanda los estudios de los pacientes internados, es

decir, la placa no se imprime a menos que sea explícitamente solicitada por algún actor
del circuito; por lo que se equipo cada pabellón de internación, los quirófanos y el
servicio de emergencias con el equipamiento necesario para poder visualizar los
informes y las imágenes. Estas estaciones de visualización están conformadas por
monitores no diagnósticos, es decir LCD de 19 pulgadas estándar y una PC de alta
performance en la cual se ejecuta el cliente PACS.
Con el uso del cliente PACS no hubo que desarrollar un aplicativo especial para el
manejo de imágenes. Están son administradas exclusivamente por el RIS/PACS,
inclusive el almacenamiento.
El sistema de historia clínicas se comunica con el cliente PACS, pasándole la

información recibida vía mensajería HL7 y este se encarga de mostrar las imágenes
pertinentes.
Pacientes
Los pacientes son administrados exclusivamente por el HIS. Este informa todos los
cambios que se producen en el momento. Se hizo una migración con todos los pacientes
existentes al comenzar la implementación.
Las internaciones de los pacientes al hospital son ingresadas en el HIS y enviadas al

RIS. Se mantienen también todos los cambios de habitación que se realiza en el
Hospital, los egresos y cualquier otro cambio de la internación.
La sincronización del sistema ADT (Admision, Discharge and Transfer) del HIS con el
RIS fue otra herraienta de mensajería fundamental para el funcionamiento integrado del
RIS-HIS. Se discuten posteriormente los mensajes HL7 elegidos para tal integración.
Profesionales de la salud
Los profesionales de la salud (médicos, técnicos radiólogos, enfermeras) también son

administrados exclusivamente por el HIS. Este informa todas las altas y bajas de
médicos que se registran.
Implementación de la mensajería
Los mensajes que fueron utilizados para realizar la implementación fueron los siguientes:
- ADT : Sincronización de Pacientes

- ORM: Ordenes Médicas
- DFT : Facturación (Ordenes realizadas e Insumos utilizados)
- ORU : Resultado de los estudios
- EPR : Imágenes de estudios
- MFN : Sincronización de Médicos
Se realizó una división entre los flujo de entrada y de salida al RIS. Los flujos de
entrada se denominaron Inbound y los de salida outbound.
ADT
Introducción
Esta sección explica el funcionamiento de la interfaz ADT (Admission/ Discharge/

Transmission) con el fin de aportar al RIS la información en tiempo real de los
pacientes del HA.
En el próximo párrafo se describen algunos antecedentes generales que se tomaron en
cuenta en el proceso de construcción de la interfaz ADT, así como también las
restricciones y dependencias.
Antecedentes Generales
La interfaz ADT fue desarrollada utilizando mensajería HL7 v2.4.

La comunicación entre los servidores HL7 es vía TCP/IP – Winsocks.
Restricciones Generales
Todo ingreso de pacientes debe contener un identificador interno único para el

sistema.
Los identificadores de ciudades, países, médicos y servicios deben estar
sincronizados en las bases de datos RIS y HIS.
Debe ser posible fusionar a dos pacientes a partir de la información recibida
desde el HIS.
No es posible fusionar a más de dos pacientes a la vez.
En el sistema RIS no se realizarán admisiones, creaciones ni actualizaciones de
pacientes.
Estas acciones deben ser ejecutadas por la aplicación respectiva del HA, el
sistema RIS tan sólo replicará estos datos.
Dependencias
El RIS depende del correcto funcionamiento de todos los sistemas del HA, que
estén relacionados con el funcionamiento de interfaces.
El RIS depende de los sistemas del HA para la creación de pacientes, médicos,
gestión de turnos, gestión de la orden médica y cobro-facturación de las
prácticas.
Responsabilidades
El HIS es el responsable de generar las transacciones de actualización de

pacientes.
El HIS es el responsable por la integridad de los datos. El RIS no verificará la
validez de ningún dato.
Eventos Soportados
En la siguiente sección se indican los eventos ADT a utilizar para sincronizar la

información demográfica y de admisión de los pacientes.
Eventos de gestión de datos demográficos
La siguiente tabla muestra los eventos soportados por la integración HIS-RIS:
A04 Registro de un nuevo paciente.

A08 Modificación de dados demográficos de un paciente.
A40 Fusión de 2 pacientes.
A47 Cambio del identificador adicional del paciente
Eventos de gestión de admisiones
La siguiente tabla muestra los eventos soportados por la integración HIS-RIS:
A01 Admisión de pacientes.

A11 Cancelación de la admisión.
A02 Traslado de paciente.
A12 Cancelación del traslado de paciente
A03 Alta de un paciente (sano o muerte). Genera el cierre de la admisión del
paciente hospitalizado.
A13 Cancelación de un alta.
Segmentos Soportados
En esta sección se enumeran los segmentos HL7 soportados por el RIS.
Segmentos requeridos
La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de

un mensaje HL7:
MSH Segmento correspondiente al encabezado del mensaje.

EVN Este segmento entrega información asociada al evento a procesar.
PID Este segmento especifica la información demográfica del paciente.
PV1 Este segmento contiene información relevante a una admisión de un
paciente
Segmentos opcionales
La siguiente tabla muestra los segmentos opcionales para el procesamiento de un

mensaje
NK1 Este segmento contiene información relevante al acompañante del paciente.

MRG Este segmento contiene la información del paciente a fusionar.
PD1 Este segmento contiene información adicional del paciente.
AL1 Este segmento contiene información sobre alergias que padece el paciente.
Tabla de relación Requerimientos Funcionales – Campo HL7
FR_ADT05 MSH-10 Nro. de transacción (no el PID-1)

FR_ADT08 PID-3 Id Paciente
FR_ADT09 PID-4 Tipo y Nro. de documento.
FR_ADT10 PID-7 Fecha de Nacimiento (YYYYMMDD)
FR_ADT11 PID-8 Sexo * (F/M)
FR_ADT12 PID-5 Apellido ^ Nombre
FT_ADT13 PID-11 Dirección
FR_ADT14 PID-13 Teléfono
FR_ADT15 PID-16 Estado Civil (S/M/W/D)
FR_ADT16 PID-26 Id País de Residencia
FR_ADT19 NK1-2 y NK1-3 Información del acompañante
FR_ADT23 PV1-19 Nro. de admisión = internación
FR_ADT24 PV1-3 Ubicación del paciente
FR_ADT26 Nuevo lugar en PV1-3
Traslado (Evento A02)
FR_ADT27 PV1-3 Lugar original Cancelación Traslado
(Evento A12)
FR_ADT28 PV1-44 PID-29 y 30 (en Información del alta administrativa
caso de muerte)
FR_ADT29 PV1-45 Cancelación Alta Administrativa
FR_ADT30 PID-30 Fecha del alta administrativa.
FR_ADT33 PV1-4 Tipo de admisión
FR_ADT35 PV1-2 Tipo de paciente (E. I)
ORM
Introducción
En esta sección se explica el funcionamiento de la interfaz ORM Inbound con el fin de
entregar al HIS la información necesaria para generar los procedimientos requeridos en
su base de datos que reflejen como resultado el envió automático de solicitudes desde el
HIS al RIS.
En esta sección se describen algunos antecedentes generales que se tomaron en cuenta
en el proceso de construcción de la interfaz ORM Inbound, así como también las
restricciones, dependencias y responsabilidades.
La interfaz ORM fue desarrollada utilizando mensajería HL7 v2.4.

La comunicación entre los servidores HL7 es vía TCP/IP – Winsocks.
El RIS supone que los códigos de facturación serán definidos por HA y serán
únicos para cada examen, producto o insumo.
Todo ingreso de pacientes debe contener un identificador interno para el sistema.

El HIS debe asegurar la unicidad de este identificador (Identificador único de
paciente).
Los médicos y departamentos solicitantes deben poseer un identificador único
dentro del HIS que debe ser parametrizado por el personal de imágenes dentro
del RIS.
El RIS solo aceptará exámenes que estén asociados a un examen válido en el
HIS.
Dependencias
El RIS depende del correcto funcionamiento de todos los sistemas del HA que
estén relacionados con el funcionamiento de la interfaz ORM.
El RIS depende de la inserción del un número único para la solicitud y examen,
estos números generados por el HIS serán el único enlace que permitirá la
identificación de la solicitud en posibles modificaciones, cancelaciones, etc.
Responsabilidades
El RIS depende del oportuno y correcto envío de las solicitudes para informar al
servicio de imágenes las prácticas a realizar.
El HIS debe asegurar la unicidad de los identificadores de solicitudes y de
exámenes asociados a una solicitud
Eventos Soportados
La siguiente tabla muestra el único evento soportado para la integración HIS-RIS:
O01 Order Message

un mensaje HL7:

paciente

mensaje
ORC Este segmento contiene información relevante a la orden

OBR Este segmento contiene la información del detalle.
OBX Este segmento contiene información de los resultados
FR_ORM_IN1 ORC-25 Turnos (Solicitudes) en estado = “Por aprobar”

FR_ORM_IN6 OBR-13 Información adicional de la solicitud
FR_ORM_ IN7 OBR-4.1 Identificador del examen (codigo^descripcion)
FR_ORM_IN8 ORC-2 Identificador de la solicitud/evento
FR_ORM_IN10 ORC-4 y ORC-2 Agrupador de exámenes
FR_ORM_IN11 OBR-3 Orden/Número de llamado
FR_ORM_IN16 ORC-7.6 Prioridad del examen Alta o Normal
FR_ORM_IN17 ORC-25 Estado solicitud paciente hospitalizado = “Aprobado
FR_ORM_IN18 ORC-25 Estado solicitud paciente de guardia = “Aprobado”
FR_ORM_IN19 ORC-25 Estado solicitud al cobrar/autorizar el pago =“Aprobado”
FR_ORM_IN20 ORC-25 Estado solicitud del paciente ambulatorio = “Aprobado”
FR_ORM_IN23 OBR-2 Concatenación del nro. de evento y nro. de examen.
FR_ORM_IN24 OBR-6 Fecha y hora del turno (uso de referencia)
MFN
Introducción
Esta sección explica el funcionamiento de la interfaz MFN (Master File Notification)

con el fin de aportar al RIS la información en tiempo real de los médicos tratantes del
HA.
cuenta en el proceso de construcción de la interfaz MFN, así como también las
La interfaz ADT será desarrollada utilizando mensajería HL7 v2.4.

La comunicación entre los servidores HL7 será vía TCP/IP – Winsocks.
Todo ingreso de médicos debe contener un identificador único en el sistema.

EL RIS no realiza validación alguna sobre la matrícula nacional informada.
Dependencias
estén relacionados con el funcionamiento de la interfaz MFN.
Dependemos de la unicidad del HIS CODE. Es decir, este código debe ser
único.
Responsabilidades
El HIS es el responsable de generar las transacciones de actualización de

médicos.
El HIS es el responsable por la integridad de los datos. El RIS no verificará la
validez de ningún dato.
Eventos Soportados

M02 Tabla maestra de médico de staff

un mensaje HL7:

MFI Este segmento especifica la tabla maestra de identificación

mensaje
MFE Este segmento contiene información relevante a la orden

STF Este segmento contiene la identificación del staff.
PRA Este segmento contiene información del practicante
FR_MFN2 STF-2 Matricula Nacional *

FR_MFN3 STF-3 Nombre y Apellido del médico solicitante
FR_MFN4 STF-11 Dirección completa
FR_MFN5 STF-10 Teléfono de contacto
FR_MFN6 PRA-5 Especialidad del médico solicitante
Mensajes Outbound
ADT
Introducción
En este documento se explica el funcionamiento de la interfaz ORM Outbound con el

fin de informar al HIS el estado de las peticiones e informes médicos.
En esta sección se describen algunos antecedentes generales que se tomaron en cuenta
en el proceso de construcción de la interfaz ORM Outbound, así como también las
restricciones, dependencias y responsabilidades.
La interfaz ORM Outbound será desarrollada utilizando mensajería HL7 v2.4.

Todo ingreso de pacientes debe contener un identificador interno para el sistema.

El HIS debe asegurar la unicidad de este identificador (Identificador único de
paciente).
Los médicos y departamentos solicitantes deben poseer un identificador único
dentro del HIS que debe ser parametrizado por el personal de imágenes dentro
del RIS.
El RIS solo aceptará exámenes que estén asociados a un examen válido en el
HIS.
Dependencias
estén relacionados con el funcionamiento de la interfaz ORM Outbound.
El RIS depende de la inserción del un número único para la solicitud y examen,
estos números generados por el HIS serán el único enlace que permitirá la
identificación de la solicitud en posibles modificaciones, cancelaciones, etc.
Responsabilidades
El RIS depende del oportuno y correcto envío de las solicitudes para informar al
servicio de imágenes las prácticas a realizar.
El HIS debe asegurar la unicidad de los identificadores de solicitudes y de
exámenes asociados a una solicitud
Eventos Soportados
O01 Order Message

un mensaje HL7:

paciente

mensaje

FR_ORM-OUT1 ORC-25 Estado = “AR” - “Arribado”

FR_ORM-OUT2 ORC-25 Estado = “Escaneado”
FR_ORM-OUT2 OBX-5 Ruta a la orden digitalizada
FR_ORM-OUT4 ORC-25 Estado = “No encontrado
FR_ORM-OUT5 ORC-25 Estado = “A la espera del efecto”
FR_ORM-OUT6 ORC-25 Estado = “Iniciado
FR_ORM-OUT7 ORC-25 Estado = “Pausado”
FR_ORM-OUT8 ORC-25 Estado = “Finalizado”
FR_ORM-OUT9 ORC-25 Estado = “Cancelar”
FR_ORM-OUT10 ORC-2 Identificador original de la petición/evento
FR_ORM-OUT11 OBR-34.5 Número de vestidor/cambiador (el nro de llamado lo
deberan tomar del id de la solicitud).
FR_ORM-OUT12 OBR-18 Accession Number del RIS.
OBR-4 Id del examen o instancia del HA.
ORU
Introducción
Esta sección explica el funcionamiento de la interfaz ORU (Report Outbound) con el fin
de aportar al HIS la información en tiempo real de los informes de Diagnóstico por
Imágenes.
cuenta en el proceso de construcción de la interfaz ORU, así como también las
restricciones y dependencias
La interfaz ORM Outbound será desarrollada utilizando mensajería HL7 v2.4.

Los identificadores de ciudades, países, médicos y servicios deben estar

sincronizadosen las bases de datos RIS y HIS.
Esta interfaz será utilizada para enviar informes desde el RIS al HIS.
Dependencias
El RIS depende del correcto funcionamiento de todos los sistemas del HA, que
estén relacionados con el funcionamiento de interfazs.
El RIS depende de los sistemas del HA para la creación de pacientes, médicos,
gestión de turnos, gestión de la orden médica y cobro-facturación de las
prácticas
Responsabilidades
El RIS es el responsable de generar las transacciones de actualización de

pacientes
El HIS es el responsable por la integridad de los datos. El RIS no verificará la validez de
ningún dato.
Eventos Soportados
R01 Resultado de Informe Radiológico.


un mensaje HL7:

OBR Este segmento contiene observaciones relevantes

mensaje

paciente
NTE Este segmento contiene notas y cometentarios adicionales
FR_ORU1 ORC-2 Identificador HIS de la solicitud

FR_ORU2 PID-2 = PID-3 Identificador del Paciente (PID)
FR_ORU2 OBR-18 Accessión Number
FR_ORU4 OBR-33 ID Medico Informante

FR_ORU5 OBR-25 Status del informe= “Preinforme”
FR_ORU6 OBR-25 Status del informe=”validado”
FR_ORU7 OBR-25=”F” Status del informe = “validado” sin texto del informe
FR_ORU8 OBR-25=”D” Status del informe = “eliminado” sin texto del informe
FR_ORU9 OBX-5 Texto del informe
EPR
Introducción
Esta sección explica el funcionamiento de la interfaz EPR con el fin de aportar al HIS la
información necesaria que permita cerrar el ciclo de realización de un examen.
cuenta en el proceso de construcción de la interfaz EPR, así como también las
La interfaz EPR será desarrollada utilizando mensajería HL7 v2.4.

Eventos Soportados
O01 Order Message

un mensaje HL7:

paciente

mensaje


FR_EPR1 Imagen en el cache Online
FR_EPR2 OBR-18 Accessión Number
FR_EPR3 PID-2 = PID-3 Patient ID
FR_EPR4 PID-5 Nombre del paciente
FR_EPR5 Imagen fuera del Cache Online
Descripción de la solución técnica
El Hospital ya contaba con un servidor de mensajería HL7 corriendo en un servidor

Windows 2003. Un servidor de mensajería, como su nombre lo indica, es un servidor
que recibe mensajes, los procesa y devuelve una respuesta. A este proceso se le puede
aplicar reglas, modificando su contenido o devolviendo un resultado. Dichas reglas
puede generar acciones de de distintos tipo tal como enviar mails de alerta para avisar si
ocurrió algún tipo de error.
La comunicación para el envío de la información desde el HIS es por un puerto TCP/IP

y para recibir los mensajes se graba directamente sobre una tabla en la base de datos
Oracle (Previamente hubo que instalar el Oracle Data Provider para .NET (ODP.NET).
Este usa rutinas Oracle para brindar un acceso rápido y confiable a datos Oracle desde
cualquier aplicación .NET).
La solución desde el lado de la base de datos fue desarrollada completamente en

PL/SQL, con paquetes y funciones que se almacenan en la base de datos. El PL/SQL es
el lenguaje de programación de SQL de Oracle y las rutinas utilizadas son las que
vienen en la instalación del producto. La versión de Oracle fue la 10.2.0.1.0.
Las funciones utilizadas para comunicarse con el servidor, son muy parecidas en otros
lenguajes de programación (C, C#, Java).
Las rutinas de manejo del XML6 están incorporadas en la versión actual de la base de
datos. Oracle implementa funciones estándar que permite hacer consultas relacionales y
devolver documentos XML. Todas estas funciones forman parte del estándar ANSI/ISO
SQL. Este ha tenido gran aceptación entre las empresas de desarrollo de base de datos (
IBM, Microsoft, Oracle).
En la Figura 1 se ve puede ver un diagrama de la solución implementada. Los

“Mensajes Outbound son para el envío de información desde el RIS al HIS. Los
“Mensajes Inbound” y “Grabación Oracle”, son para recibir la información. El envío y
recepción de información son sucesos independientes.
El “Mensaje Inbound XML” esta especificado así, por que se genera en XML pero el
servidor de Mensajería lo pasa en texto para que pueda ser interpretado correctamente
por el RIS. Esta es una funcionalidad que provee el servidor de mensajería.
Mensajería Inbound
Mensajes Outbound Mensajes Inbound XML
Base de datos
Oracle
Grabación Oracle
Servidor de
Mensajería
-Figura.1-
Descripción del desarrollo
Mensajes Inbound XML
A continuación se describe la rutina que se utiliza para el envío de la mensajería.

Primero se graba en una tabla, luego se abre la conexión TCP , se envía la información,
se cierre y se actualiza la tabla.
Este procedimiento me permite verificar el estado del mensaje enviado.

PROCEDURE SEND_MSG(p_msgXml xmltype)
BEGIN
INSERT
INTO HA.HL7_SENT_MESSAGES(MSG,CDATE,ESTADO)
VALUES (p_msgXml,SYSTIMESTAMP,NULL)
RETURNING ROWID
INTO v_rowid;
msg_text_encoded := CHR(11)||p_msgXml.getStringVal()||CHR(28)||CHR(13);
BEGIN
c := UTL_TCP.OPEN_CONNECTION(remote_host =>HL7_HOST,
remote_port =>HL7_PORT,
tx_timeout => HL7_TIMEOUT );
rc := UTL_TCP.write_text(c, msg_text_encoded);
v_tcp_ok := TRUE;
EXCEPTION
WHEN OTHERS THEN
v_tcp_ok := FALSE;
END;
IF v_tcp_ok THEN
utl_tcp.flush(c);
msg_response :=NULL;
BEGIN
LOOP
v_response := utl_tcp.get_text(c,1);
v_estado := 'P';
EXIT WHEN ASCII(v_response)=13 AND v_ascii_ant=28;
msg_response := msg_response ||v_response ;

v_ascii_ant := ASCII(v_response);
END LOOP;
msg_response := SUBSTR(msg_response,2,Length(msg_response)-2);
v_msg_answer := xmltype(msg_response);
EXCEPTION
WHEN OTHERS THEN
v_estado := 'E';
IF sqlcode = -29276 THEN
v_msg_answer := xmltype('TIMEOUT:'||sqlcode);
ELSE
v_msg_answer := xmltype('ERROR:'||sqlerrm);
END IF;
END ;
UPDATE HA.HL7_SENT_MESSAGES
SET ESTADO = v_estado,
ANSWER = v_msg_answer
WHERE ROWID = v_rowid;
COMMIT;
END IF;
-- Cierro TCP con o sin error.

BEGIN
UTL_TCP.CLOSE_CONNECTION(c);
EXCEPTION
WHEN OTHERS THEN NULL;
END;
Mensajes Outbound
El servidor de mensajes graba en la tabla HL7_MESSAGES(MSG XMLTYPE). Una

veza grabado se ejecuta el trigger que lo pasa a la tabla COLA_MSG_XML y luego se
ejecuta la rutina encargada de procesar el mensaje.
Este proceso el que administra la cola de los mensajes y reintenta procesar el mensaje 3
veces, con un intervalo de tiempo determinado.
BEGIN
v_xml := Xmltype(:NEW.Msg);
INSERT
INTO HA.COLA_MSG_XML(MSG_ID,MSG,CDATE,ESTADO)
VALUES(v_Msg_Id,v_xml,SYSTIMESTAMP,'E');
END;
HA.Procesar_Cola_Xml;
Para procesar el mensaje se llama a una rutina que analiza cual es el origen del mensaje
para saber cual es el proceso a seguir.
Programación de las rutinas
Se utilizo el PL/SQL de Oracle y se manejaron los mensajes como XML. Esto facilito
mucho el desarrollo de las interfaces, ya que Oracle cumple los estándares para manejo
de documentos XML (Xpath) que permite inclusive usarlo en sentencias SQL.
Ejemplo de la generación de un ADT.

SELECT xmlelement("ADT_A01",XMLATTRIBUTES(PK_HL7.xmlns_urn AS "xmlns"),
xmlagg(
xmlConcat(PK_HL7.MSH('ADT',p_evento,'ADT^A01'),
PK_HL7.EVN(SYSDATE),
PK_HL7.PID(p_paciente),
PK_HL7.PV1(NULL,NULL,NULL,NULL)
)
)
)
INTO v_msgXml
FROM Dual;
FUNCTION MSH(p_msgType VARCHAR2,p_trigger VARCHAR2, p_msgStructure VARCHAR2:=NULL)

RETURN xmltype
IS
mshXml xmltype;
msgControlId NUMBER;
v_msgStructure VARCHAR2(10):=NVL(p_msgStructure,p_msgtype||'^'||p_trigger);
BEGIN
SELECT HA.SEQ_HL7.Nextval INTO msgControlid FROM DUAL;
--- MSH
mshXml:=xmltype('<MSH>'||
'<MSH.1>|</MSH.1> '||
'<MSH.2>^~\&</MSH.2>'||
'<MSH.3><HD.1>HIS_HA</HD.1></MSH.3>'||
'<MSH.7><TS.1>'||TO_CHAR(SYSDATE,c_dateFormat)||'</TS.1></MSH.7>' ||
'<MSH.9><CM_MSG.1>'||p_msgType ||'</CM_MSG.1>'||
'<CM_MSG.2>'||p_trigger ||'</CM_MSG.2>'||
'<CM_MSG.3>'||v_msgStructure||'</CM_MSG.3>'||
'</MSH.9>'||
'<MSH.10>'||TO_CHAR(msgControlId) ||'</MSH.10>'||
'<MSH.11>
<PT.1>'||PK_HL7.p_processingId ||'</PT.1></MSH.11>'||
'<MSH.12><VID.1>2.4</VID.1></MSH.12>'||
'<MSH.17>ARG</MSH.17>'||
'</MSH>');
RETURN mshXml;
END MSH;
FUNCTION PID(p_paciente NUMBER)

RETURN xmltype
IS
pacienteXml xmltype;
BEGIN
SELECT xmlelement("PID",
xmlagg(
xmlelement("PID.3",
xmlelement("CX.1",p.paciente),
xmlelement("CX.4",
xmlelement("HD.1",'HA')
),
xmlelement("CX.5",'MR')
)
),
DECODE(MIN(p.nrodoc),NULL,NULL,
xmlagg(
xmlelement("PID.4",
xmlelement("CX.1",HA.CONVIERTE_CHAR_ESP(p.nrodoc)),
xmlelement("CX.4",
xmlelement("HD.1",'ARG')
),
xmlelement("CX.5",DECODE(p.tipdoc,'PPT','PAS',p.tipdoc))
)
)
),
xmlagg(
xmlelement("PID.5",
xmlelement("XPN.1",
xmlelement("FN.1",p.priape||' '||p.otrosape)
xmlelement("XPN.2",p.prinom||' '||p.otrosnom)
)
),
xmlagg(
xmlelement("PID.7",
xmlelement("TS.1",TO_CHAR(p.fecnac,c_dateFormat_short))
)
),
xmlagg(
xmlelement("PID.8",p.sexo
)
),
xmlagg(
xmlelement("PID.11",
xmlelement("XAD.1",
xmlelement("SAD.1",HA.CONVIERTE_CHAR_ESP(p.domic))
),
xmlelement("XAD.3",HA.CONVIERTE_CHAR_ESP(p.local)),
xmlelement("XAD.4",HA.CONVIERTE_CHAR_ESP(p.prov)),
xmlelement("XAD.5",HA.CONVIERTE_CHAR_ESP(p.codpost)),
xmlelement("XAD.6",'ARG') -- Country
)
),
xmlagg(
xmlelement("XTN.4",HA.CONVIERTE_CHAR_ESP(p.email)),
xmlelement("XTN.7",
DECODE(p.contactel,'F',p.telef,'O',p.telefc,telefcel))
)
),
xmlagg(
xmlelement("CE.1",
DECODE(p.estcivil,'1','S','2','M','3','W','4','D'))
)
),
xmlagg(
xmlelement("PID.30",DECODE(p.fallecio,'1','Y','N'))
)
)
INTO pacienteXml
FROM hospital.paciente p
WHERE p.paciente = p_paciente;
RETURN pacienteXml;
END PID;
Discusión
El uso de interfaces HL7 en la adaptación de un sistema RIS/PACS es clave para el

éxito del proyecto. Contar con un estándar ya definido simplifica el trabajo y disminuye
la posibilidad de error, tanto desde el HIS como desde el RIS.
Otro factor importante fue logar que el HIS siga siendo el generador de ordenes
médicas. Esto fue fundamental, no solo para poder contar con el apoyo de todas las
áreas intervinientes, ya que se modificó lo menos posible el trabajo de las mismas, sino
también para disminuir los posibles errores.
Igualmente es importante destacar que los flujos de trabajos sufrieron muchos cambios
cuando estos se aplicaron a la real dinámica de los sectores. Muchas situaciones ideales
fueron cambiadas debido a errores en la confección de las órdenes médicas, ya sea por
la elección del estudio incorrecto, como el agregado de nuevos estudios a las órdenes.
El modelo de datos de estudios del RIS demando más trabajo del provisto
originalmente, en parte por la gran apertura que se tenía en el HIS y otra por la manera
de trabajar de algunos equipos DICOM compatibles, que tomaban una sola muestra de
varios estudios, lo que traía problemas al informar.
No obstante toda la problemática antes mencionada, la incorporación del RIS significo

una mejora sustancial en la calidad de los informes y en la atención de los pacientes.
Finalmente, el desarrollo de las interfaces fue menos complicado de lo previsto, usando

estándares de uso cotidiano, y la experiencia del uso mensajería HL7 deja al Hospital
preparado para nuevas interfaces a desarrollar.
Referencias
1. NEMA. PROCEDURES for the DICOM Standards Committee. 2007. Available at:
http://medical.nema.org/Dicom/Geninfo/Procedures.pdf.
2. PACS. Available at: http://renux.dmed.ed.ac.uk/EdREN/PACSpres/PACS.html [Accessed June

14, 2009].
3. Manzotti M, Diaz M, Segarra G. Informatización de la actividad médica asistencial en un

hospital de la comunidad en Argentina. In: ; 2007. Available at:
http://www.sais.org.ar/Portals/2/SIS/SIS2007/Trabajos/09_Manzotti.pdf.
4. Catálogo de Recursos de HL7 - HL7 - Argentina. Available at:

http://hl7.org.ar/index.php?option=com_content&task=view&id=53&Itemid=89 [Accessed
June 14, 2009].
5. Espinoza M, Maldonado S, Segarra G. Integración RIS/PACS Comunicación HL7 vs. DICOM.

Visualización de imágenes en un sistema PACS dentro de una aplicación de Historia Clínica de
Pacientes (EPR). In: Asociación Médica Argentina.
6. Extensible Markup Language (XML). Available at: http://www.w3.org/XML/ [Accessed June

14, 2009].
View publication stats

SIS09 Segarra Diaz

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SIS09 Segarra Diaz

Enviado por

Direitos autorais:

Formatos disponíveis

See

SIS-Interfaces HL7 para una implementación

Article · January 2009

Martín M. Diaz Maffini

BackOffice de Internación View project

HCI-REPRO View project

The user has requested enhancement of the downloaded file.

Segarra G.1, Diaz M.2

DICOM (Digital Imaging and Communication in Medicine) es el estándar reconocido

El PACS (Picture Archiving and Communication System) automatiza el proceso de

Diferentes sectores: prestadores de servicios de salud, desarrolladores de software,

No se consideró ningún RIS que no tuviera HL7 incorporado.

Descripción de escenario inicial

En el último año se incorporó el estándar de mensajería HL7 en el sector de Terapia

A mediados de 2007 se tomó la decisión de incorporar las imágenes médicas generadas

El primer paso de la implementación fue definir la información que iba a ser

Ingreso de Ordenes Médicas

Informe de los estudios complementarios

Las otras interfaces que se tuvieron que definir fueron :

Ingreso de Ordenes Médicas

Ingreso orden médica

Informe de los estudios

El pre-informe es el informe preliminar que es importante para los servicios de

El ingreso de los informes y su administración es realizada toda desde el RIS.

RIS Historia Clínica

Se tomó la decisión de imprimir a demanda los estudios de los pacientes internados, es

El sistema de historia clínicas se comunica con el cliente PACS, pasándole la

Las internaciones de los pacientes al hospital son ingresadas en el HIS y enviadas al

Los profesionales de la salud (médicos, técnicos radiólogos, enfermeras) también son

- ADT : Sincronización de Pacientes

Esta sección explica el funcionamiento de la interfaz ADT (Admission/ Discharge/

La interfaz ADT fue desarrollada utilizando mensajería HL7 v2.4.

Todo ingreso de pacientes debe contener un identificador interno único para el

El HIS es el responsable de generar las transacciones de actualización de

En la siguiente sección se indican los eventos ADT a utilizar para sincronizar la

Eventos de gestión de datos demográficos

La siguiente tabla muestra los eventos soportados por la integración HIS-RIS:

A04 Registro de un nuevo paciente.

Eventos de gestión de admisiones

La siguiente tabla muestra los eventos soportados por la integración HIS-RIS:

A01 Admisión de pacientes.

En esta sección se enumeran los segmentos HL7 soportados por el RIS.

La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de

MSH Segmento correspondiente al encabezado del mensaje.

La siguiente tabla muestra los segmentos opcionales para el procesamiento de un

NK1 Este segmento contiene información relevante al acompañante del paciente.

Tabla de relación Requerimientos Funcionales – Campo HL7

FR_ADT05 MSH-10 Nro. de transacción (no el PID-1)

La interfaz ORM fue desarrollada utilizando mensajería HL7 v2.4.

Todo ingreso de pacientes debe contener un identificador interno para el sistema.

La siguiente tabla muestra el único evento soportado para la integración HIS-RIS:

O01 Order Message

La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de

MSH Segmento correspondiente al encabezado del mensaje.

La siguiente tabla muestra los segmentos opcionales para el procesamiento de un

ORC Este segmento contiene información relevante a la orden

Tabla de relación Requerimientos Funcionales – Campo HL7

FR_ORM_IN1 ORC-25 Turnos (Solicitudes) en estado = “Por aprobar”

Esta sección explica el funcionamiento de la interfaz MFN (Master File Notification)

La interfaz ADT será desarrollada utilizando mensajería HL7 v2.4.

Todo ingreso de médicos debe contener un identificador único en el sistema.

El HIS es el responsable de generar las transacciones de actualización de

La siguiente tabla muestra el único evento soportado para la integración HIS-RIS:

La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de