Resumen
Hasta la fecha, no existe ninguna solución milagrosa para establecer un pipeline ETL funcional que transmita un flujo de mensajes HL7v2 desde un EHR hacia datos FHIR de forma inmediata. MatrixCare EHR no es una excepción, ya que existen puntos de personalización. En este artículo vamos a mostrar ejemplos de cómo conseguimos aliviar las dificultades de la integración y qué herramientas utilizamos (adelanto: Aidbox). También describiremos los principios básicos de la configuración de un sistema HL7v2 a FHIR, en beneficio de quienes deseen construir su propio sistema desde cero.
Los datos FHIR constituyen un modelo informacional ideal para:
- la agregación de datos para análisis posteriores;
- la creación de una tienda de aplicaciones FHIR para la salud y el suministro de datos a aplicaciones inteligentes;
- la mejora evolutiva de la aplicación actual o la búsqueda de soluciones personalizadas para tareas específicas.
Para ofrecerle una visión general del sistema completo, consulte este diagrama, que muestra el pipeline ETL completo para MatrixCare EHR desarrollado por Health Samurai:
Arquitectura general
En esta entrada hablaremos de MatrixCare EHR, aunque los lectores atentos podrán observar que la experiencia descrita es aplicable a cualquier otro EHR, puesto que casi todos los sistemas construidos para ejecutar un pipeline ETL eficiente operan bajo los mismos principios.
Así pues, el consumo de datos procedentes de otra fuente comienza con la FUENTE de esos datos.
Fuente de datos
Nuestra fuente de datos es MatrixCare EHR. Produce mensajes HL7v2 en formato RAW. Si no recuerda o desconoce el aspecto de los mensajes HL7v2 en bruto, aquí tiene un breve ejemplo. Se trata de un formato de datos bastante antiguo que, en esencia, es una cadena de texto dividida en segmentos (y subsegmentos), cada uno de los cuales almacena información médica de utilidad.
Las cadenas de texto no son el tipo de dato más cómodo, por lo que normalmente se analizan y se convierten en estructuras de datos legibles por personas y máquinas (JSON, YAML o EDN). Existen analizadores de código abierto para mensajes HL7v2 (p. ej., v2 to FHIR, HL7v2 to FHIR converter by Linux For Health), aunque Aidbox ofrece una funcionalidad integrada para analizar mensajes y persistir el resultado.
Nuestra fuente produce una gran cantidad de mensajes HL7v2 como este:
MatrixCare EHR envía un mensaje HL7v2 de tipo ADT (Admisión, Alta, Traslado). Utiliza la versión 2.5 del estándar HL7. Un mensaje se compone de los siguientes segmentos:
- MSH (Cabecera del mensaje), NK1 (Familiar más próximo), AL1 (Alergias), DG1 (Diagnóstico), PV1 (Visita del paciente), PV2 (Información adicional de la visita del paciente), GT1 (Garante)
- existe documentación exhaustiva para cada segmento, p. ej.: https://hl7-definition.caristix.com/v2/HL7v2.5.1/Segments/MSH
Cola
Es difícil imaginar un sistema complejo sin estructuras de datos que proporcionen un acceso controlado. Los sistemas médicos utilizan colas con los siguientes fines:
- cómputo diferido: nadie espera que todos los sistemas procesen inmediatamente todos los datos entrantes; simplemente necesitamos saber que ocurrirá en un momento predecible en el futuro próximo;
- problemas de escalabilidad: podemos añadir más consumidores para procesar los datos con mayor rapidez;
- picos de carga: no se espera que el flujo de datos sea siempre lineal.
En nuestro ejemplo utilizamos Amazon SQS (aunque podemos configurar nuestro Adaptador de Aplicación para trabajar con casi cualquier servicio de colas). Amazon SQS cuenta con algunas características interesantes. Además del acceso paralelo, un mecanismo de deduplicación, el sondeo largo y una visualización elegante, dispone de una funcionalidad que nos resulta especialmente atractiva: la DLQ o cola de mensajes fallidos (dead letters queue). Si ocurre algo inesperado durante el consumo de un mensaje, SQS intentará entregárselo al consumidor, pero tras varios intentos fallidos lo almacenará en la DLQ, desde donde podrá ser consumido de forma manual o programática (adelanto: sí, nuestra aplicación Lilly Adapter dispone de una API para reprocesar mensajes de la DLQ – POST «/$sqs-dlq-reprocess»).
¡Aquí empieza la magia!
Tras la extracción del mensaje HL7v2, es necesario realizar una transformación a FHIR. Disponemos de una guía en vídeo para este proceso:
Como mencionamos anteriormente, existen diversos analizadores de código abierto para HL7v2, pero Aidbox proporciona funcionalidades integradas que cubren el pipeline ETL completo:
- Persistir los mensajes entrantes en la base de datos (Aidbox DB https://www.health-samurai.io/docs/aidbox/storage-1/database) para evitar la pérdida o malformación de datos;
- Analizar el mensaje en estructuras de datos legibles por personas y máquinas (analizador HL7v2 https://www.health-samurai.io/docs/aidbox/modules-1/hl7-v2-integration);
- Analizar el mensaje en datos FHIR mediante el lenguaje de mapeo JUTE (data-DSL de Health Samurai https://github.com/HealthSamurai/jute.clj);
- Persistir los recursos FHIR creados en una base de datos (AidboxDB nuevamente).
Así es exactamente como sucede:
- Lilly Adapter proporciona un listener (o consumidor) que consulta continuamente SQS en busca de nuevos mensajes y, si los hay, inicia el procesamiento del mensaje HL7v2;
- los nuevos mensajes HL7v2 entrantes se guardan en el recurso HL7v2Message: src: "HL7V2MESSAGE" status: received
- Aidbox proporciona un job que espera nuevos mensajes con el estado «received»;
- una vez que el sistema Aidbox detecta el mensaje, este es analizado por Aidbox: el mensaje HL7v2 en bruto se convierte en una estructura de datos legible por personas, que puede devolvérsele como YAML o JSON, y se almacena bajo la clave «parsed» en el mismo recurso HL7v2Message:
- el campo config también debe estar soportado: config define qué conjunto de mappings (puede leer sobre ellos en https://www.health-samurai.io/docs/aidbox/tools/mappings) se aplicará. Config se almacena en el recurso HL7v2Config; los mappings se almacenan como recurso Mapping;
- así, los datos parsed constituyen los datos de entrada para los mappings, y el resultado de la aplicación del mapping se almacena en el campo outcome:
outcome = all_mappings_from_hl7v2config(parsed_field_data)
- en función de si el proceso de análisis y creación de recursos se completa correctamente, el estado del mensaje cambia de «received» a «processed». Si falla, se le asigna el estado «error». La aplicación Lilly Adapter dispone de una API para el reprocesamiento de mensajes. Puede reprocesar mensajes con distintos criterios, como estado, tipo de evento, período de tiempo, etc. El estado «processed» indica que todos los recursos FHIR requeridos se crearon con éxito:
Un poco más sobre los mappings
Los mappings cumplen varias funciones:
- proporcionan la transformación de los datos parsed al resultado (outcome) de acuerdo con la lógica personalizada especificada en los mappings;
- ofrecen un mecanismo para persistir datos (hay quienes sostienen que FHIR fue creado para el intercambio de datos y no para persistirlos, pero nosotros tenemos una opinión contraria: https://www.health-samurai.io/articles/should-you-use-fhir-resources-as-your-data-storage-format);
- el conjunto de mappings aplicado al campo analizado se configura a través del recurso HL7v2Config, sobre el que puede leer más aquí: https://www.health-samurai.io/docs/aidbox/modules-1/hl7-v2-integration.
Los mappings se escriben en un DSL especial desarrollado por el equipo de Health Samurai: el lenguaje de mapeo JUTE. Es un DSL ligero y bien documentado con una curva de aprendizaje prácticamente nula, diseñado de tal manera que ni siquiera es necesario ser programador para escribir sus propios mappings. No obstante, en ocasiones se encontrará con casos complejos que requieren mappings sofisticados.
Enlace: https://github.com/HealthSamurai/jute.clj
Puede que se pregunte cómo la aplicación de mappings da lugar a la persistencia de datos. Intentaremos explicárselo:
Los mappings deben contener un campo «request», que es en realidad una llamada a la API de Aidbox que se ejecutará como resultado de la aplicación del mapping. Como consecuencia de dicha aplicación, los recursos se crearán y persistirán en Aidbox Database.
Para explorar cómo Aidbox puede mejorar su integración con MatrixCare EHR, pruebe la versión gratuita de Aidbox. Ofrece un entorno completo para probar y perfeccionar los procesos de integración, proporcionando todas las herramientas necesarias sin ninguna limitación de funcionalidades.
En resumen
Estos son los pasos necesarios para establecer la integración con MatrixCare:
- proporcionar una entidad que obtenga los mensajes de MatrixCare (puede ser casi cualquier entidad, incluidas Kafka o RabbitMQ, aunque aquí hemos utilizado AmazonSQS);
- encontrar la manera de consumir ese mensaje (desde una cola o directamente desde el EHR);
- analizar el mensaje HL7v2 de cadena de texto a estructura de datos;
- transformar el HL7v2 analizado en recursos FHIR;
- guardar el resultado.
Podría reinventar la rueda, pero Aidbox ya está configurado para que toda la magia ocurra en su interior. Persistimos y analizamos los mensajes, los traducimos al formato FHIR y luego persistimos el resultado. Como habrá podido observar, la aplicación adaptadora es ligera y, sin duda, puede desarrollar su propia versión, aunque no creemos que sea necesario.
Los mappings (utilizados para transformar los datos del HL7v2 analizado en recursos FHIR) son el punto de personalización. Es probable que cada EHR necesite un conjunto único de mappings, pero también disponemos de algunos mappings predefinidos para MatrixCare EHR que pueden resultar de utilidad. Podemos ofrecer asistencia en cualquier fase del proceso de integración.
Autor: Artem Alexeev
Véase también: Cómo abordar la integración con sistemas heredados.
