--- { "title": "Integración de Aidbox con MatrixCare EHR (paso a paso)", "description": "Cómo integrar el EHR MatrixCare con Aidbox mediante una arquitectura basada en colas, mapeos FHIR y sincronización resiliente, con un patrón de proyecto real.", "date": "2022-07-18", "author": "Artem Alekseev", "reading-time": "6 min read", "tags": [ "Integrations", "Aidbox" ], "seo-tags": [ "fhir", "fhir integration", "fhir server", "fhir platform", "ehr integration", "matrixcare" ] } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- ## Resumen Hasta la fecha, no existe ninguna solución milagrosa para establecer un pipeline ETL funcional que transmita un flujo de mensajes [HL7v2](/blog/getting-started-with-hl7-messaging-over-mllp-using-a-vpn) 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](https://www.health-samurai.io/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: ![MatrixCare & Aidbox Integration pipeline](image-1.avif) ## 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 ![MatrixCare HL7v2 Feed](image-2.avif) Nuestra fuente de datos es MatrixCare EHR. Produce [mensajes HL7v2](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185) 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](https://github.com/HL7/v2-to-fhir/tree/master/mappings), [HL7v2 to FHIR converter by Linux For Health](https://github.com/LinuxForHealth/hl7v2-fhir-converter)), aunque [Aidbox](https://www.health-samurai.io/aidbox) ofrece una funcionalidad integrada para [analizar mensajes y persistir el resultado](https://www.health-samurai.io/docs/aidbox/modules-1/hl7-v2-integration). Nuestra fuente produce una gran cantidad de mensajes HL7v2 como este: ![HL7v2 Message Example](image-3.avif) 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](https://hl7-definition.caristix.com/v2/HL7v2.5.1/Segments/MSH) ## Cola ![MatrixCare & Amazon SQS Integration](image-4.avif) 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! ![Amazon SQS & DLQ & Aidbox Integration](image-5.avif) 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: - [https://www.youtube.com/watch?v=iSDX4UZpYO4](https://www.youtube.com/watch?v=iSDX4UZpYO4) 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](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](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](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»**; ![HL7v2 to Aidbox](image-6.avif) - una vez que el sistema Aidbox detecta el mensaje, este es **analizado** por [**Aidbox**](https://www.health-samurai.io/fhir-server): 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: ![HL7v2 statuses within Aidbox](image-7.avif) - 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](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: ![FHIR mapping](image-8.avif) ## 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](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](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](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: ![Aidbox Mapping Resource example / JUTE](image-9.avif) 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](https://www.health-samurai.io/aidbox#run). 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](https://www.health-samurai.io/fhir-server) 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** [![Aidbox FHIR Platform Free Trial](image-10.avif)](https://www.health-samurai.io/aidbox) Véase también: [Cómo abordar la integración con sistemas heredados](/blog/tackling-legacy-system-integration-with-fhir).