--- { "title": "Choisir FHIR pour l'intégration laboratoire", "description": "Choisir la norme de données de santé la plus adaptée peut s'avérer complexe. Nous avons évalué si HL7 v2, v3 & CDA, ou FHIR constituait le meilleur choix pour un projet d'intégration laboratoire. Nous avons conclu que FHIR est la meilleure option, car l'API FHIR complète parfaitement l'API personnalisée du système de laboratoire.", "date": "2015-01-08", "author": "Nikolai Ryzhikov", "reading-time": "3 min read", "tags": [ "Integrations", "System Design" ] } --- *Publié le 8 janvier 2015 par Nicola Rizhikov* Le gouvernement de Saint-Pétersbourg a lancé un projet visant à créer un bus d'intégration unifié pour l'échange d'ordonnances et de résultats de laboratoire entre les cliniques ambulatoires, les hôpitaux et les laboratoires de l'État. De nombreux objectifs sont visés : ordonnances sans papier, accès rapide aux résultats pour les médecins et les patients, planification et optimisation des ressources, ainsi que production d'information à des fins d'analyse et d'exploration de données par les organisations gouvernementales de santé. La première itération consistait à analyser les processus existants et à créer un prototype fonctionnel. Cette itération a été complétée par la mise en place d'une API SOAP personnalisée et l'intégration de certaines organisations du groupe pilote. À la fin du projet pilote, il est devenu évident qu'une norme internationale devrait servir de fondation. Nous avons été invités à aider dans le choix entre les différentes normes (nous avons de l'expérience en intégration, principalement dans le contexte américain). Nous avons examiné HL7 v2, HL7 v3 & FHIR et les avons comparés à une API personnalisée. ### HL7 v2 À première vue, [HL7 v2](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185) semble être le meilleur candidat. Cela pourrait être vrai pour les États-Unis, où de nombreux systèmes opérationnels (SIH, DSÉ, SIL) échangent déjà des messages HL7 v2. Mais la situation en Russie est différente : la plupart des systèmes d'information de laboratoire sont développés sur mesure et n'utilisent pas HL7 v2. L'argument principal en faveur de HL7 v2 ne tient donc pas, et toutes les lacunes congénitales de la version 2 entrent en jeu. Le protocole HL7 v2 a évolué de façon ad hoc, ce qui lui confère un format de messages archaïque, l'absence d'extensibilité intégrée, de profilage et de contraintes lisibles par machine, ainsi qu'aucune perspective d'avenir (la norme n'est plus qu'en mode maintenance, sans développement actif). Le format de messages archaïque oblige à implémenter des analyseurs syntaxiques et des constructeurs maladroits pratiquement de zéro. Seuls les développeurs Java et .Net peuvent réutiliser les bibliothèques [HAPI](http://hl7api.sourceforge.net/) et [nHAPI](http://nhapi.sourceforge.net/home.php), tandis que les autres plateformes populaires (node.js, erlang, php, python, ruby, etc.) ne disposent pas de bibliothèques pratiques et robustes. L'absence d'extensibilité et de profilage/contraintes pourrait être palliée par une approche telle que [LRI](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279). Mais au moins la moitié de LRI se résume à des correctifs et des rustines pour les bogues de HL7 v2, sans apporter de valeur réelle. ***En résumé*** : HL7 v2 nécessite un travail considérable et peu pertinent pour déployer une norme obsolète. ### HL7 v3 & CDA Un autre candidat est HL7 v3 & CDA. Deux arguments **favorables** méritent d'être mentionnés : certaines normes HL7 v3 sont désormais normatives en Russie et le groupe de travail HL7 a publié en 2013 un DSTU pour les ordonnances et résultats de laboratoire. HL7 v3 repose sur des fondements théoriques solides et est conçu pour une véritable interopérabilité sémantique, mais il lui manque une propriété essentielle — l'implémentabilité. Cela se traduit notamment par le fait que, encore aujourd'hui, il n'existe pas de bonnes bibliothèques d'implémentation. La courbe d'apprentissage est également abrupte et la complexité est élevée pour les développeurs. HL7 v3 n'est pas une seule norme, mais un empilement profond de normes, de sorte que même la localisation de cette norme paraît très chronophage. Le projet dispose d'un délai d'environ 6 mois, et il ne semble pas réaliste d'utiliser HL7 v3 & CDA pour le démarrer. Tout ce temps serait consacré à la formation des développeurs. ### FHIR L'option suivante est [FHIR](https://hl7.org/fhir/R4/). Il s'agit d'une norme moderne pour une interopérabilité **rapide**. Elle est conçue pour trouver le bon équilibre entre les besoins d'échange d'informations de santé sémantiques et la complexité d'implémentation. FHIR offre une extensibilité et un profilage intégrés, ainsi qu'une bonne boîte à outils de bibliothèques et de services. FHIR vous permet de n'implémenter que la partie requise de la norme, ce qui peut simplifier considérablement le démarrage du projet et rend possible l'ajout incrémental de nouvelles fonctionnalités. Nous avons comparé l'API personnalisée développée lors de la première itération avec l'API FHIR et avons constaté une correspondance quasi parfaite. Pour être conforme à FHIR, l'API actuelle ne devrait réimplémenter que quelques ressources : [Organization](https://hl7.org/fhir/R4/organization.html), [Practitioner](https://hl7.org/fhir/R4/practitioner.html), [Patient](https://hl7.org/fhir/R4/patient.html), [Encounter](https://hl7.org/fhir/R4/encounter.html), DiagnosticOrder, [DiagnosticReport](https://hl7.org/fhir/R4/diagnosticreport.html) & [Observation](https://hl7.org/fhir/R4/observation.html). Les règles d'affaires requises pourraient être exprimées sous forme d'[extensions FHIR](/articles/extending-fhir-resources). Les systèmes de laboratoire, hospitaliers et ambulatoires pourraient communiquer avec le bus via une API REST, en utilisant une implémentation de référence disponible et des bibliothèques clientes. Des services FHIR publics pourraient être utilisés comme environnements bac à sable pour le développement. Health Samurai, avec le soutien de HL7 Russia, a déjà localisé la majeure partie de la documentation FHIR. Il existe certes de nombreuses petites questions techniques, mais nous pouvons affirmer que FHIR répond parfaitement aux besoins et aux exigences de ce projet. Nous espérons que les gestionnaires et les décideurs feront le bon choix avec FHIR et atteindront leurs objectifs. > Commencez avec le [serveur FHIR](https://www.health-samurai.io/aidbox) Aidbox pour le stockage de données, les intégrations, l'analyse en santé et bien plus encore, ou [faites appel à notre équipe](https://www.health-samurai.io/services) pour répondre à vos besoins en développement logiciel. [![Aidbox FHIR Platform Free Trial](image-1.avif)](https://www.health-samurai.io/aidbox) Voir aussi : [Relever les défis de l'intégration des systèmes existants](/blog/tackling-legacy-system-integration-with-fhir) et [Utiliser FHIR pour simplifier le développement en santé](/blog/using-fhir-to-simplify-healthcare-application-development).