Informática Sana: el blog de Caduceus

Caso práctico 1.1: el nuevo HIS y las viejas aplicaciones

Sin comentarios

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 del Caso Práctico 1.


En este artículo planteamos un caso práctico de 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

Tele vieja

Imagen cortesía de Supertrooper / FreeDigitalPhotos.net

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
CAMPOTIPO DE DATOREQUERIDODESCRIPCIÓN
nhcintegerSNúmero de historia clínica del paciente, PK en OldPlainHIS y PharmaCoolX 1.0
nombrestringSNombre del paciente
apellidosstringSApellidos del paciente
fec_nacimientostringNFecha de nacimiento del paciente, en formato ‘dd/mm/yyyy’
sexocharNSexo del paciente, con valores ‘H’ hombre, ‘M’ mujer
exituscharSÉxitus del paciente, con valores ‘S’ Sí, ‘N’ No
fec_exitusstringNFecha 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

Sala de servidores

Imagen cortesía of tigger11th / FreeDigitalPhotos.net

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|N
ADT^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|N
ADT^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|N

Problemas

Otro error

Imagen cortesía de jesadaphorn / FreeDigitalPhotos.net

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

CAMPOTIPO DE DATOREQUERIDODESCRIPCIÓN
MSH.1STSCarácter separador de campos, valor fijo a ‘|’
MSH.2STSCodificación de caracteres, valor fijo a ‘^~\&’
MSH.3HDSAplicación emisora del mensaje, valor fijo a ‘NEWHIS’
MSH.5HDSAplicación receptora del mensaje, valor fijo a ‘PHARMACOOLX1.0’
MSH.7TSSFecha y hora del mensaje, en formato ‘yyyymmddhh24miss’
MSH.9MSGSTipo 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.10STSIdentificador único del mensaje
MSH.11PTSEntorno de ejecución del mensaje, valor fijo a ‘T’ en el entorno de desarrollo, y a ‘P’ en el entorno de producción
MSH.12VIDSVersión de HL7 utilizada, valor fijo a ‘2.5’
MSH.15IDSACK de confirmación de recepción, valor fijo a ‘AL’ para requerir siempre este tipo de ACK
MSH.16IDSACK de aplicación, valor fijo a ‘NE’ para no requerir nunca este tipo de ACK

Segmento EVN

CAMPOTIPO DE DATOREQUERIDODESCRIPCIÓN
EVN.1IDSEvento del mensaje
(en el caso práctico podrá ser ‘A08’, ‘A28’ y ‘A03’)
EVN.2TSSFecha y hora del evento, en formato ‘yyyymmddhh24miss’

Segmento PID

CAMPOTIPO DE DATOREQUERIDODESCRIPCIÓN
PID.1SISIdentificador de segmento PID dentro del mensaje HL7, valor fijo a ‘1’
PID.3CXSNHC del paciente
PID.5XPNSNombre y apellidos del paciente, en formato APELLIDO1^NOMBRE^APELLIDO2
PID.7TSNFecha y hora de nacimiento del paciente, en formato ‘yyyymmddhh24miss’
PID.8ISNSexo del paciente, con valores ‘M’ Hombre, ‘F’ Mujer, ‘O’ Otro
PID.29TSNFecha y hora del éxitus del paciente, en formato ‘yyyymmddhh24miss’
PID.30IDSIndicador del éxitus del paciente, con valores ‘Y’ Sí, ‘N’ No

Segmento PV1

CAMPOTIPO DE DATOREQUERIDODESCRIPCIÓN
PVN.1SISIdentificador de segmento PV1 dentro del mensaje HL7, valor fijo a ‘1’
PVN.2ISSTipo de episodio, valor fijo a ‘N’ para indicar que no aplica
Francisco J. CarrascoCaso práctico 1.1: el nuevo HIS y las viejas aplicaciones

Entradas Relacionadas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *