La aplicación PharmaCoolX 1.0 está integrada con el viejo sistema de información hospitalario OldPlainHIS de forma no estándar. Con la llegada del nuevo NewModernHIS y su uso de HL7 y estándares se plantea el problema: ¿Cómo mantenemos la interoperabilidad con nuestra vieja aplicación?
Este artículo es parte de la serie de nuestro Tutorial de Mirth Connect.
En este artículo planteamos un ejercicio del uso de HL7 con las herramientas Mirth Connect y 7Edit.
En esta serie de artículos describiremos escenarios típicos en las integraciones sanitarias, partiendo de la implantación de un nuevo HIS en un hospital, y desde el punto de vista de una aplicación ya integrada con el antiguo HIS.
Cada escenario representará un problema típico en integraciones sanitarias que resolveremos de forma sencilla mediante un canal simple en Mirth Connect. Mediante el uso de la herramienta 7Edit, simularemos el envío de mensajería HL7 por parte del HIS para realizar las pruebas.
Situación con el antiguo HIS
Una aplicación llamada PharmaCoolX 1.0 está integrada (o más bien incrustada) con un HIS de un Sistema de Información Hospitalario, llamado OldPlainHIS. Para implementar su lógica de negocio, PharmaCoolX 1.0 necesita mantener una base de datos con los pacientes activos del hospital, así que recibe las altas de nuevos usuarios y modificaciones de datos demográficos (incluidos los casos de éxitus), mediante ficheros en formato XML ubicados en un recurso compartido de la red hospitalaria.
Estos ficheros XML tienen el mismo formato independientemente de la operación que se vaya a realizar (alta, modificación o éxitus). El NHC será el identificador único del paciente, por lo que PharmaCoolX 1.0 dará de alta a un paciente si no encuentra su NHC en su base de datos y modificará sus datos en el caso contrario. Supondremos que el indicador de éxitus se implementa como un dato demográfico más del paciente en PharmaCoolX 1.0.
Por simplicidad, supondremos que no se implementan fusiones de historias clínicas, anulación de fusiones de historias clínicas ni eliminación de historias clínicas.
Descripción de los ficheros XML utilizados por PharmaCoolX 1.0 para el mantenimiento de pacientes
Campos utilizados en los ficheros XML requeridos por PharmaCoolX 1.0
| CAMPO | TIPO DE DATO | REQUERIDO | DESCRIPCIÓN |
|---|---|---|---|
nhc | integer | S | Número de historia clínica del paciente, PK en OldPlainHIS y PharmaCoolX 1.0 |
nombre | string | S | Nombre del paciente |
apellidos | string | S | Apellidos del paciente |
fec_nacimiento | string | N | Fecha de nacimiento del paciente, en formato ‘dd/mm/yyyy’ |
sexo | char | N | Sexo del paciente, con valores ‘H’ hombre, ‘M’ mujer |
exitus | char | S | Éxitus del paciente, con valores ‘S’ Sí, ‘N’ No |
fec_exitus | string | N | Fecha de éxitus del paciente, en formato ‘dd/mm/yyyy’ |
Ejemplo de fichero XML requerido por PharmaCoolX 1.0
<paciente>
<nhc>NHC</nhc>
<nombre>Nombre</nombre>
<apellidos>Apellido1 Apellido2</apellidos>
<fec_nacimiento>01/01/2000</fec_nacimiento>
<sexo>M</sexo>
<exitus>N</exitus>
<fec_exitus/>
</paciente>Situación con el nuevo HIS
En el hospital se implanta un nuevo HIS más moderno y sofisticado, NewModernHIS, que utiliza mensajería HL7 para notificar al resto de sistemas de las altas de nuevos usuarios, modificaciones de sus datos demográficos y éxitus.
La versión de HL7 utilizada por NewModernHIS es la v2.5 en la nomenclatura de pipes. Los mensajes para altas, modificaciones y éxitus se implementan mediante los siguientes tipos y eventos:
- Altas de nuevos usuarios: ADT^A28.
- Modificaciones de datos demográficos: ADT^A08.
- Éxitus: ADT^A03.
Por simplicidad, supondremos que NewModernHIS utiliza el mismo identificador único del paciente que OldPlainHIS, el NHC, y que éste se mantiene tal cual tras el cambio de HIS.
Descripción de los mensajes HL7 utilizados por NewModernHIS para el mantenimiento de pacientes
De nuevo por simplicidad, vamos especificar tan sólo los campos necesarios para llevar a cabo el caso práctico, y que los campos requeridos por PharmaCoolX 1.0, son los mismos que los requeridos por NewModernHIS.
Al final de este artículo se puede encontrar un anexo con el detalle los campos informados por NewModernHIS en los mensajes HL7.
Ejemplos de mensajes HL7 de NewModernHIS
ADT^A28
MSH|^~\&|NEWHIS||PHARMACOOLX1.0||20140601123154||ADT^A28|NEWHIS_ALTA_1|T|2.5|||AL|NE
EVN|A28|20140601123153
PID|1||NHC||APELLIDO1^NOMBRE^APELLIDO2||19840101000000|M||||||||||||||||||||||N
PV1|1|NADT^A08
MSH|^~\&|NEWHIS||PHARMACOOLX1.0||20140601123154||ADT^A08|NEWHIS_MODIF_1|T|2.5|||AL|NE
EVN|A08|20140601123153
PID|1||NHC||APELLIDO1^nuevo_NOMBRE^APELLIDO2||19840101000000|M||||||||||||||||||||||N
PV1|1|NADT^A03
MSH|^~\&|NEWHIS||PHARMACOOLX1.0||20140601123154||ADT^A03|NEWHIS_EXITUS_1|T|2.5|||AL|NE
EVN|A03|20140601123153
PID|1||NHC||APELLIDO1^NOMBRE^APELLIDO2||19840101000000|M|||||||||||||||||||||20140601123000|Y
PV1|1|NProblemas
Actualmente, PharmaCoolX 1.0 interpreta un único formato de fichero XML que lee de un recurso compartido de red, y tenemos 3 tipos de mensajes HL7 diferentes transferidos mediante el protocolo LLP.
También cambia el formato para los siguientes campos:
- Nombre y apellidos: PharmaCoolX 1.0 los espera en 2 campos separados, pero NewModernHIS los informa en un único campo mediante 3 componentes.
- Fecha de nacimiento: PharmaCoolX 1.0 espera el formato ‘dd/mm/yyyy’, pero NewModernHIS informa el campo en formato ‘yyyymmddhh24miss’.
- Sexo: PharmaCoolX 1.0 espera los valores ‘H’ Hombre, ‘M’ Mujer, pero NewModernHIS informa el campo con los valores ‘M’ Hombre, ‘F’ Mujer, ‘O’ Otro.
- Éxitus: PharmaCoolX 1.0 espera los valores ‘S’ Sí y ‘N’ No, pero NewModernHIS informa el campo con los valores ‘Y’ Sí, ‘N’ No.
- Fecha de éxitus: PharmaCoolX 1.0 espera el formato ‘dd/mm/yyyy’, pero NewModernHIS informa el campo en formato ‘yyyymmddhh24miss’.
Por último, el proveedor de PharmaCoolX 1.0 no sabe nada de HL7 y tan sólo quiere que su sistema continúe funcionando tal y como está tras la implantación de NewModernHIS.
¿La solución a estos problemas?
Una posible solución pasa por la implementación de un canal con Mirth Connect que reciba los mensajes HL7 mediante el protocolo LLP, los transforme en los ficheros XML con el formato que PharmaCoolX 1.0 necesita y los deje en el recurso de red compartido. De esta forma, el cambio de HIS le resultará completamente transparente a PharmaCoolX 1.0.
Para la implementación de este canal en Mirth Connect, veremos conectores comúnmente utilizados como:
- Source: LLP Listener.
- Destination: File Writer.
En los conectores se hará uso de filtros para distinguir el evento del mensaje HL7 recibido, así como de transformadores para convertir cada uno de los campos al formato requerido por PharmaCoolX 1.0.
Veremos cómo implementar esta solución en detalle en el siguiente artículo: el nuevo HIS y las viejas aplicaciones (II).
Anexo: Campos informados por NewModernHIS en los mensajes HL7
Segmento MSH
| CAMPO | TIPO DE DATO | REQUERIDO | DESCRIPCIÓN |
|---|---|---|---|
MSH.1 | ST | S | Carácter separador de campos, valor fijo a ‘|’ |
MSH.2 | ST | S | Codificación de caracteres, valor fijo a ‘^~\&’ |
MSH.3 | HD | S | Aplicación emisora del mensaje, valor fijo a ‘NEWHIS’ |
MSH.5 | HD | S | Aplicación receptora del mensaje, valor fijo a ‘PHARMACOOLX1.0’ |
MSH.7 | TS | S | Fecha y hora del mensaje, en formato ‘yyyymmddhh24miss’ |
MSH.9 | MSG | S | Tipo y evento del mensaje, en formato TIPO^EVENTO(en el caso práctico, el tipo irá fijo a ‘ADT’ y el EVENTO podrá ser ‘A08’, ‘A28’ y ‘A03’) |
MSH.10 | ST | S | Identificador único del mensaje |
MSH.11 | PT | S | Entorno de ejecución del mensaje, valor fijo a ‘T’ en el entorno de desarrollo, y a ‘P’ en el entorno de producción |
MSH.12 | VID | S | Versión de HL7 utilizada, valor fijo a ‘2.5’ |
MSH.15 | ID | S | ACK de confirmación de recepción, valor fijo a ‘AL’ para requerir siempre este tipo de ACK |
MSH.16 | ID | S | ACK de aplicación, valor fijo a ‘NE’ para no requerir nunca este tipo de ACK |
Segmento EVN
| CAMPO | TIPO DE DATO | REQUERIDO | DESCRIPCIÓN |
|---|---|---|---|
EVN.1 | ID | S | Evento del mensaje (en el caso práctico podrá ser ‘A08’, ‘A28’ y ‘A03’) |
EVN.2 | TS | S | Fecha y hora del evento, en formato ‘yyyymmddhh24miss’ |
Segmento PID
| CAMPO | TIPO DE DATO | REQUERIDO | DESCRIPCIÓN |
|---|---|---|---|
PID.1 | SI | S | Identificador de segmento PID dentro del mensaje HL7, valor fijo a ‘1’ |
PID.3 | CX | S | NHC del paciente |
PID.5 | XPN | S | Nombre y apellidos del paciente, en formato APELLIDO1^NOMBRE^APELLIDO2 |
PID.7 | TS | N | Fecha y hora de nacimiento del paciente, en formato ‘yyyymmddhh24miss’ |
PID.8 | IS | N | Sexo del paciente, con valores ‘M’ Hombre, ‘F’ Mujer, ‘O’ Otro |
PID.29 | TS | N | Fecha y hora del éxitus del paciente, en formato ‘yyyymmddhh24miss’ |
PID.30 | ID | S | Indicador del éxitus del paciente, con valores ‘Y’ Sí, ‘N’ No |
Segmento PV1
| CAMPO | TIPO DE DATO | REQUERIDO | DESCRIPCIÓN |
|---|---|---|---|
PVN.1 | SI | S | Identificador de segmento PV1 dentro del mensaje HL7, valor fijo a ‘1’ |
PVN.2 | IS | S | Tipo de episodio, valor fijo a ‘N’ para indicar que no aplica |
Deja una respuesta