--- { "title": "Aidbox + Intégration du DSE MatrixCare (étape par étape)", "description": "Comment intégrer le DSE MatrixCare avec Aidbox en utilisant une architecture basée sur les files d'attente, des mappages FHIR et une synchronisation résiliente — avec un modèle de projet réel.", "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" ] } --- ## Résumé À ce jour, il n'existe pas de solution miracle pour établir un pipeline ETL fonctionnel permettant de transmettre un flux de messages [HL7v2](/blog/getting-started-with-hl7-messaging-over-mllp-using-a-vpn) d'un DSE vers des données FHIR prêtes à l'emploi. Le DSE MatrixCare ne fait pas exception dès lors qu'il comporte des points de personnalisation. Dans cet article, nous allons présenter des exemples illustrant la façon dont nous avons réussi à simplifier le processus d'intégration et quels outils nous avons utilisés (indice : [Aidbox](https://www.health-samurai.io/aidbox)). Nous décrirons également les principes fondamentaux de la configuration d'un système HL7v2 vers FHIR, au bénéfice de quiconque souhaiterait bâtir son propre système à partir de zéro. Les données FHIR constituent un modèle informationnel idéal pour : - l'agrégation de données en vue d'analyses ultérieures ; - la création d'un magasin d'applications FHIR pour la santé et la fourniture de données aux applications intelligentes ; - l'amélioration progressive de l'application actuelle ou la recherche de solutions personnalisées pour des tâches particulières. Afin de vous donner un aperçu rapide de l'ensemble du système, veuillez consulter ce diagramme qui illustre le pipeline ETL complet pour le DSE MatrixCare par Health Samurai : ![MatrixCare & Aidbox Integration pipeline](image-1.avif) ## Architecture générale Dans cet article, nous traiterons du DSE MatrixCare, bien que les lecteurs attentifs puissent remarquer que l'expérience décrite est tout à fait applicable à n'importe quel autre DSE, car presque tout système conçu pour exécuter un pipeline ETL efficace repose sur les mêmes principes. Ainsi, la consommation de données provenant d'une source externe commence par la **SOURCE** de ces données ! ## Source de données ![MatrixCare HL7v2 Feed](image-2.avif) Notre source de données est le DSE MatrixCare. Il produit des [messages HL7v2](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185) bruts. Si vous avez oublié ou ne saviez pas à quoi ressemblent les messages HL7v2 bruts, voici un bref exemple. Il s'agit d'un format de données assez ancien qui n'est en fait qu'une chaîne de caractères divisée en segments (et sous-segments), chacun contenant des informations médicales utiles. Les chaînes de caractères ne constituent pas le type de données le plus pratique ; elles sont donc généralement analysées en structures de données lisibles par les humains et les machines (JSON, YAML ou EDN). Il existe des analyseurs syntaxiques libres pour les messages HL7v2 (p. ex. [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)), bien qu'[Aidbox](https://www.health-samurai.io/aidbox) offre une fonctionnalité intégrée pour [l'analyse des messages et la persistance du résultat](https://www.health-samurai.io/docs/aidbox/modules-1/hl7-v2-integration). Notre source produit un grand nombre de messages HL7v2 comme celui-ci : ![HL7v2 Message Example](image-3.avif) Le DSE MatrixCare envoie un message HL7v2 ADT (Admission, Sortie, Transfert). Il utilise la version 2.5 de la norme HL7. Un message est composé des segments suivants : - MSH (En-tête de message), NK1 (Proche parent), AL1 (Allergies), DG1 (Diagnostic), PV1 (Visite du patient), PV2 (Visite du patient — informations complémentaires), GT1 (Garant) - il existe une documentation complète pour chaque segment, p. ex. : [https://hl7-definition.caristix.com/v2/HL7v2.5.1/Segments/MSH](https://hl7-definition.caristix.com/v2/HL7v2.5.1/Segments/MSH) ## File d'attente ![MatrixCare & Amazon SQS Integration](image-4.avif) Il est difficile d'imaginer un système complexe sans faire appel à des structures de données offrant un accès discipliné. Les systèmes médicaux utilisent des files d'attente aux fins suivantes : - **calcul différé** — personne ne s'attend à ce que tous les systèmes traitent immédiatement toutes les données entrantes ; il suffit de savoir que cela se produira à un moment prévisible dans un avenir proche ; - **problèmes d'évolutivité** — il est possible d'ajouter davantage de consommateurs afin de traiter les données plus rapidement ; - **charges de pointe** — on ne s'attend pas à ce que le flux de données soit toujours linéaire. Dans notre exemple, nous utilisons Amazon SQS (bien que nous puissions configurer notre adaptateur d'application pour fonctionner avec presque n'importe quel service de file d'attente). Amazon SQS présente quelques caractéristiques intéressantes. Outre l'accès parallèle, un mécanisme de déduplication, l'interrogation longue et une belle visualisation, il possède une fonctionnalité que nous apprécions tout particulièrement. Il s'agit de sa **DLQ** ou **file d'attente des lettres mortes** (*dead letters queue*). Si quelque chose d'inattendu se produit lors de la consommation d'un message, SQS tentera de livrer ce message au consommateur, mais après plusieurs tentatives, il sera stocké dans la DLQ, d'où il pourra être consommé manuellement ou de façon programmatique (indice : oui, notre application **Lilly Adapter** dispose d'une **API pour retraiter les messages DLQ — POST "/$sqs-dlq-reprocess"**). ## C'est là que la magie commence ! ![Amazon SQS & DLQ & Aidbox Integration](image-5.avif) Après l'**extraction** du message HL7v2, nous devons effectuer une transformation vers FHIR. Nous disposons d'ailleurs d'un guide vidéo pour ce processus : - [https://www.youtube.com/watch?v=iSDX4UZpYO4](https://www.youtube.com/watch?v=iSDX4UZpYO4) Comme nous l'avons mentionné précédemment, il existe divers analyseurs syntaxiques libres pour HL7v2, mais Aidbox fournit des fonctionnalités intégrées pour couvrir l'**ensemble du pipeline ETL** : - Persister les messages entrants dans la base de données (Aidbox DB [https://www.health-samurai.io/docs/aidbox/storage-1/database](https://www.health-samurai.io/docs/aidbox/storage-1/database)) afin d'éviter toute perte ou altération de données ; - Analyser le message en structures de données lisibles par les humains et les machines (analyseur 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)) ; - Analyser le message en données FHIR à l'aide du langage de mappage JUTE (DSL de données par Health Samurai [https://github.com/HealthSamurai/jute.clj](https://github.com/HealthSamurai/jute.clj)) ; - Persister les ressources FHIR créées dans une base de données (AidboxDB à nouveau). Voici comment cela se déroule exactement : - **Lilly Adapter** fournit un écouteur (ou consommateur) qui interroge constamment SQS pour de nouveaux messages et, s'il en existe, lance le traitement du message HL7v2, - les nouveaux messages HL7v2 entrants sont sauvegardés dans la ressource HL7v2Message : src: "HL7V2MESSAGE" status: received - **Aidbox** fournit un **travail** (*job*) qui attend les nouveaux messages ayant le statut **'received'**, ![HL7v2 to Aidbox](image-6.avif) - une fois que le message est détecté par le système Aidbox, le message est **analysé** par [**Aidbox**](https://www.health-samurai.io/fhir-server), le message HL7v2 brut devient une structure de données lisible par l'humain pouvant être retournée en YAML ou en JSON, et est stocké sous la clé **'parsed'** dans la même ressource HL7v2Message : ![HL7v2 statuses within Aidbox](image-7.avif) - le champ **config** doit également être pris en charge — **config** définit quel ensemble de **mappages** (vous pouvez en lire davantage à l'adresse [https://www.health-samurai.io/docs/aidbox/tools/mappings](https://www.health-samurai.io/docs/aidbox/tools/mappings)) sera appliqué. **Config** est stocké dans la ressource HL7v2Config, les mappages sont stockés en tant que ressource Mapping ; - ainsi, les données **analysées** (*parsed*) constituent les données d'entrée pour les **mappages**, et le résultat de l'application des mappages est stocké dans le champ **outcome** : > outcome = all_mappings_from_hl7v2config(parsed_field_data) - selon que l'analyse syntaxique et le processus de création des ressources réussissent ou non, le **statut** du message passe de **'received'** à **'processed'**. En cas d'échec, le statut **'error'** lui est attribué. L'application **Lilly Adapter** dispose d'une API pour le retraitement des messages. Elle peut retraiter les messages selon différents critères tels que le statut, le type d'événement, la période, etc. Le statut **'Processed'** signifie que toutes les ressources FHIR requises ont été créées avec succès : ![FHIR mapping](image-8.avif) ## Un peu plus sur les mappages Les **mappages** remplissent plusieurs fonctions : - ils assurent la **transformation** des données **analysées** vers le résultat (*outcome*) selon la **logique personnalisée** spécifiée dans les mappages ; - ils fournissent un mécanisme de **persistance** des données (certains affirment que FHIR a été créé pour l'échange de données et non pour leur persistance, mais nous avons un point de vue opposé : [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)) ; - l'ensemble des mappages appliqués au champ analysé est configuré via la ressource HL7v2Config, dont vous pouvez en apprendre davantage ici : [https://www.health-samurai.io/docs/aidbox/modules-1/hl7-v2-integration](https://www.health-samurai.io/docs/aidbox/modules-1/hl7-v2-integration). Les mappages sont rédigés dans un DSL spécial développé par l'équipe Health Samurai — le langage de mappage **JUTE**. Il s'agit d'un DSL léger et bien documenté, dont la courbe d'apprentissage est quasi nulle, et conçu de telle sorte que vous **n'avez même pas besoin d'être programmeur** pour écrire vos mappages. Néanmoins, vous serez parfois confronté à des cas complexes qui nécessitent des mappages sophistiqués. Lien : [https://github.com/HealthSamurai/jute.clj](https://github.com/HealthSamurai/jute.clj) Vous vous demandez peut-être comment l'application des mappages aboutit à la **persistance** des données. Nous allons tenter de vous l'expliquer : ![Aidbox Mapping Resource example / JUTE](image-9.avif) Les mappages doivent contenir un champ **'request'** qui est en réalité un appel à l'API Aidbox, lequel sera exécuté à la suite d'une application de mappage. En conséquence de l'application du mappage, des ressources seront créées et persistées dans la base de données Aidbox. Pour explorer comment Aidbox peut améliorer votre intégration avec le DSE MatrixCare, essayez la [version gratuite d'Aidbox](https://www.health-samurai.io/aidbox#run). Elle offre un environnement complet pour tester et affiner les processus d'intégration, en fournissant tous les outils nécessaires sans aucune limitation de fonctionnalités. ## En résumé Voici les étapes à suivre pour établir une intégration avec MatrixCare : - fournir une entité qui récupère les messages de MatrixCare (il peut s'agir de presque n'importe quelle entité, notamment Kafka ou RabbitMQ, mais nous avons utilisé AmazonSQS ici) ; - trouver un moyen de consommer ce message (depuis une file d'attente ou directement depuis le DSE) ; - analyser le message HL7v2 d'une chaîne de caractères vers une structure de données ; - transformer le HL7v2 analysé en ressources FHIR ; - sauvegarder le résultat. Vous pourriez en effet réinventer la roue, mais [Aidbox](https://www.health-samurai.io/fhir-server) est déjà configuré pour que toute la magie se produise en son sein. Nous persistons et analysons les messages, les traduisons au format FHIR, puis persistons le résultat. Comme vous avez pu le constater, l'application adaptateur est légère et vous pouvez certainement développer votre propre version, mais nous ne pensons pas que cela soit nécessaire. Les mappages (utilisés pour transformer les données du HL7v2 analysé vers les ressources FHIR) constituent un point de **personnalisation**. Chaque DSE aura probablement besoin d'un ensemble unique de mappages, mais nous disposons également de mappages prêts à l'emploi pour le DSE MatrixCare qui pourraient s'avérer pratiques. Nous pouvons fournir une assistance à toute étape du processus d'intégration. --- **Auteur : Artem Alexeev** [![Aidbox FHIR Platform Free Trial](image-10.avif)](https://www.health-samurai.io/aidbox) Voir aussi : [Aborder l'intégration des systèmes patrimoniaux](/blog/tackling-legacy-system-integration-with-fhir).