--- { "title": "Développement de microservices en santé : une approche FHIR-native", "description": "Découvrez comment une approche de microservices FHIR-native simplifie le développement de systèmes de santé. Apprenez à créer des services évolutifs et interopérables en tirant parti des API prêtes à l'emploi, des modèles de domaine et des outils Terminology de FHIR — idéal pour les projets vierges et la modernisation des systèmes existants.", "date": "2025-03-27", "author": "Aleksandr Kislitsyn", "reading-time": "15 minutes", "tags": [ "System Design", "FHIR Standard" ] } --- ## Architecture de microservices en santé Les [microservices](/blog/thoughts-about-microservices) constituent un patron d'architecture largement adopté qui structure les applications sous forme d'un ensemble de services faiblement couplés et déployables de manière indépendante. Cette approche permet à plusieurs équipes de développer des composants en parallèle en utilisant différents langages de programmation. Chaque équipe peut choisir la technologie la mieux adaptée à son service et le faire évoluer selon ses besoins propres sans affecter les autres services. Par exemple, dans un système de santé : - Le service d'inscription des patients pourrait être écrit en Java et traiter 1 000 requêtes par minute - Le service de prise de rendez-vous pourrait être en Node.js et traiter 500 requêtes par minute - Le service d'aide à la décision clinique pourrait utiliser Python avec TensorFlow pour traiter 2 000 dossiers patients par minute, en analysant les résultats de laboratoire et en suggérant des diagnostics L'un des principaux défis de l'architecture en microservices réside dans la gestion de la communication entre les services. Les API doivent être bien définies et stables pour garantir une interaction fluide tout en préservant l'indépendance de chaque service. C'est là qu'intervient HL7 FHIR (Fast Healthcare Interoperability Resources). ## Pourquoi FHIR convient bien aux architectures en microservices Conçu à l'origine comme une norme d'interopérabilité, FHIR offre plusieurs avantages clés qui le rendent particulièrement bien adapté aux architectures en microservices : **1. Modèle de domaine prédéfini** Disposer d'un modèle de domaine bien défini est essentiel dans les architectures en microservices. Toute modification du modèle peut affecter les API exposées, ce qui nécessite une coordination entre les équipes. Par exemple, l'ajout d'un nouveau champ « preferredPharmacy » à la ressource Patient exigerait des mises à jour du service de gestion des patients, du service de médicaments, de l'interface du portail patient et de toutes leurs API — requérant une coordination minutieuse entre plusieurs équipes. FHIR fournit : - [**Des ressources propres au domaine de la santé**](https://hl7.org/fhir/resourcelist.html) : Un ensemble complet de 145 ressources prêtes à l'emploi (Patient, Encounter, Observation, etc.) élaborées par des experts du domaine de la santé à travers des milliers d'heures de travail collaboratif. Chaque type de ressource est une [racine d'agrégat](https://martinfowler.com/bliki/DDD_Aggregate.html) au sens de la conception pilotée par le domaine (Domain Driven Design). - [**Un cadre d'extensibilité**](https://hl7.org/fhir/extensibility.html) : La possibilité d'étendre et de contraindre les ressources de base pour des cas d'utilisation spécifiques grâce au [Profiling](https://build.fhir.org/profiling.html). Par exemple, vous pouvez ajouter des extensions à la ressource Patient pour stocker des informations non incluses dans la spécification FHIR, ou rendre certains éléments de la ressource Patient obligatoires sans enfreindre les règles d'interopérabilité. Consultez le [US Core Patient Profile](https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-patient.html) à titre d'exemple. - [**Des guides d'implémentation**](https://build.fhir.org/implementationguide.html) : Des plans directeurs prêts à l'emploi pour implémenter des domaines de santé spécifiques dans FHIR. Ces guides fournissent des extensions, des profils et des opérations pour des sous-domaines particuliers (comme la [planification](https://fhir.org/guides/argonaut/scheduling/), l'[oncologie](https://build.fhir.org/ig/HL7/fhir-mCODE-ig/index.html), etc.). **2. Gestion standardisée de la terminologie** Il existe quelques grands systèmes de codes très utilisés en santé : - SNOMED CT (plus de 350 000 concepts médicaux) - LOINC (près de 100 000 codes de tests de laboratoire) - ICD-10 (environ 70 000 codes de diagnostics) - RxNorm (plus de 100 000 codes de médicaments) - etc. Concevoir une façon de stocker et d'utiliser les concepts issus de ces systèmes de codes dans vos microservices représente un défi de taille. Par exemple, lors de l'enregistrement du diagnostic d'un patient : - Le code « I21.3 » dans ICD-10 signifie « infarctus du myocarde avec sus-décalage du segment ST de siège non précisé » - La même affection dans SNOMED CT correspond au code « 401303003 » - Différents services peuvent utiliser des systèmes de codes différents - Les codes doivent être validés et mis en correspondance entre les systèmes - Les systèmes de codes sont régulièrement mis à jour avec de nouvelles versions FHIR fournit : - [**Des systèmes de codage intégrés**](https://hl7.org/fhir/terminologies.html) : La prise en charge des terminologies médicales standard (SNOMED CT, LOINC, ICD-10, RxNorm, etc.) - [**Des services de vocabulaire**](https://hl7.org/fhir/terminology-service.html) : Des API standard pour la validation et la recherche de terminologie. Exemple : lorsqu'un clinicien saisit le diagnostic d'un patient dans un système de DSE, au lieu de taper manuellement le diagnostic, il sélectionne un code à partir d'un service de [terminologie FHIR](/articles/two-phase-fhir-terminology) qui fournit des codes SNOMED CT en temps réel. Une fois saisi, les données peuvent être validées par le serveur FHIR avant d'être enregistrées sous forme de ressource [Condition](https://www.hl7.org/fhir/condition.html). - [**La gestion des ensembles de valeurs**](https://hl7.org/fhir/valueset.html) : Une approche définie pour gérer les ensembles de codes. Exemple : vous pouvez définir un sous-ensemble réutilisable de codes SNOMED CT sous forme de ressource ValueSet afin de proposer aux cliniciens une liste ciblée de codes de diagnostics pertinents pour leur spécialité. - [**La correspondance entre versions**](https://hl7.org/fhir/conceptmap.html) : La prise en charge du versionnage et de la mise en correspondance des terminologies. Exemple : si ICD-10 est mis à jour, le système peut faire correspondre les anciens codes de diagnostics aux nouveaux. **3. Modèle d'API prédéfini** La gestion des API est un élément essentiel de l'architecture en microservices. Vous devez concevoir les patrons de communication pour les interactions synchrones et asynchrones entre les services. Par exemple, dans un flux de congé d'un patient : - Le service clinique doit vérifier de façon synchrone si les médicaments sont disponibles - Le service de pharmacie doit être notifié de façon asynchrone pour préparer les médicaments - Le service de planification doit être notifié pour réserver les rendez-vous de suivi - Le service de facturation doit recevoir le résumé final du congé Sans patrons standardisés, chacune de ces interactions nécessiterait une conception et une implémentation d'API personnalisées. FHIR a déjà fait ce travail pour vous. - [**Interface RESTful**](https://hl7.org/fhir/http.html) : Opérations CRUD standard alignées sur les méthodes HTTP. - [**Prise en charge des transactions**](https://hl7.org/fhir/http.html#transaction) : Support intégré des opérations atomiques sur plusieurs ressources qui préviennent les mises à jour partielles dangereuses. Exemple : lors de la prescription d'un médicament pour un nouveau diagnostic, soit le diagnostic et l'ordonnance sont enregistrés ensemble, soit aucun des deux ne l'est. Cela évite les situations dangereuses où un médicament existerait sans son diagnostic associé, ou inversement, ce qui pourrait entraîner des erreurs médicales. Si une partie quelconque de la transaction échoue (par exemple, une vérification d'interaction médicamenteuse), l'ensemble de l'opération est automatiquement annulé. - [**Cadre de recherche**](https://hl7.org/fhir/search.html) : Des capacités de recherche complètes avec des paramètres standard. Exemple : vous pouvez créer une seule requête de recherche FHIR qui retournera tous les patients ayant consenti à partager leurs données avec un praticien particulier et inclure les Encounter associés dans les résultats : ```javascript GET /fhir/Patient?_has:Consent:patient:actor=&_has:Consent:patient:scope=Encounter&_revinclude=Encounter:subject ``` - [**Cadre des abonnements**](https://hl7.org/fhir/subscriptions.html) : Support intégré pour la communication pilotée par les événements — les applications peuvent réagir aux modifications de ressources. Exemple : si un résultat de laboratoire est mis à jour, le système du médecin reçoit automatiquement une alerte. ## Architecture cible d'une solution de microservices FHIR-native La première étape pour bâtir une solution de microservices FHIR-native consiste à choisir le stockage des données. Deux patrons populaires existent : - [**Base de données (serveur FHIR) par service**](https://microservices.io/patterns/data/database-per-service.html) — chaque service dispose de son propre stockage FHIR isolé - [**Base de données partagée (serveur FHIR)**](https://microservices.io/patterns/data/shared-database.html) — tous les services utilisent le même serveur FHIR pour stocker l'ensemble des ressources FHIR L'architecture **base de données par service** contribue à assurer le faible couplage des services. Les modifications apportées à la base de données d'un service n'ont aucune incidence sur les autres services. Les inconvénients sont les suivants : - Gestion et implémentation de plusieurs [serveurs FHIR](https://www.health-samurai.io/fhir-server) - Effort supplémentaire pour implémenter des transactions couvrant plusieurs services - Implémentation de la recherche entre services plus complexe La **base de données partagée** apparaît comme étant plus naturelle pour une solution de microservices FHIR-native, en raison des avantages suivants : - **Réduction de l'effort d'implémentation** : Opérations CRUD et capacités de recherche prédéfinies pour toutes les ressources - Support des transactions intégré pour toutes les ressources - Gestion simplifiée de la cohérence des données - **Cohérence des données** : Source unique de vérité pour toutes les ressources FHIR - Transactions atomiques sur plusieurs ressources - Gestion de l'intégrité référentielle simplifiée - **Risque de couplage réduit** : Bien que les bases de données partagées mènent souvent à un couplage étroit, ce risque est atténué dans les architectures FHIR-natives. Le modèle FHIR est intrinsèquement stable et extensible, ce qui élimine le besoin de modifications de schéma coordonnées Le diagramme suivant illustre l'architecture cible d'une solution de microservices FHIR-native : ![](image-1.avif) ### Principaux composants de l'architecture - **Services de santé** Microservices spécialisés par domaine qui implémentent la logique métier pour différents flux de travail en santé (par exemple, gestion des patients, planification, documentation clinique). Ils interagissent avec le serveur FHIR via les API REST FHIR standard et consomment des événements via les abonnements. - **Serveur FHIR** — Stockage de données partagé qui : fournit des API FHIR pour le stockage, la récupération et la recherche de ressources - Notifie les consommateurs des événements liés aux ressources via des abonnements - Assure la validation des données. - **Serveur de terminologie** Gère les vocabulaires et les systèmes de codes du domaine de la santé (SNOMED CT, LOINC, ICD-10, etc.). Fournit des opérations de validation, de recherche et de mise en correspondance des terminologies pour assurer l'interopérabilité sémantique sur l'ensemble de la plateforme. - **Services d'infrastructure et de sécurité** — Préoccupations transversales comprenant : l'authentification et l'autorisation - La [passerelle API](/articles/using-api-gateway-with-fhir-api) et le routage - La journalisation des audits et la surveillance - Le PACS (Picture Archiving and Communication System) ## Étapes pour construire un système FHIR-native à l'aide d'une architecture en microservices L'approche d'implémentation diffère considérablement entre les projets vierges et la modernisation des systèmes existants. Alors que les nouveaux systèmes peuvent être conçus selon les principes FHIR-natifs dès le départ, les systèmes de santé existants requièrent une stratégie de migration soigneusement élaborée. ### Projet vierge Pour les nouveaux systèmes de santé, vous pouvez appliquer les principes FHIR-natifs dès le départ en suivant ces étapes : - **Décomposition du domaine pilotée par les ressources** — Faire correspondre les domaines métier aux ressources FHIR Exemple de correspondance : Gestion des patients → Patient, Person, RelatedPerson - Planification → Appointment, Schedule, Slot - Documentation clinique → Observation, DiagnosticReport, Condition - Définir les frontières entre les microservices Bien que les frontières de service optimales dépendent fortement de votre cas d'utilisation spécifique et du contexte du système, voici quelques lignes directrices pour vous aider dans cette décision :- FHIR propose des orientations sur l'organisation des ressources en groupes logiques : [https://hl7.org/fhir/overview-arch.html#organizing](https://hl7.org/fhir/overview-arch.html#organizing) - Consultez les [guides d'implémentation FHIR](/articles/how-to-create-a-fhir-implementation-guide) (IG) pertinents pour des orientations propres à chaque domaine, par exemple pour la planification : [https://build.fhir.org/ig/IHE/ITI.Scheduling/volume-1.html](https://build.fhir.org/ig/IHE/ITI.Scheduling/volume-1.html) - Les définitions de ressources dans la spécification FHIR constituent également une bonne source d'inspiration, car elles fournissent souvent des informations sur les ressources connexes et leur utilisation prévue. Par exemple : [https://hl7.org/fhir/appointment.html#scope](https://hl7.org/fhir/appointment.html#scope) - **Mise en place de l'infrastructure** — Déployer un [serveur FHIR](https://www.health-samurai.io/fhir-server) de qualité production - Implémenter les services de sécurité et d'authentification - Mettre en place l'infrastructure de surveillance et de journalisation - Configurer les services de terminologie - **Implémentation des services** Commencer par les services essentiels (gestion des patients, planification) - Utiliser les API CRUD et de recherche FHIR du serveur FHIR pour travailler avec les ressources FHIR depuis les microservices - Implémenter la logique métier dans les microservices en concevant et en implémentant des opérations sur les ressources FHIR. S'inspirer de la spécification FHIR ou des guides d'implémentation. Par exemple, le [FHIR Scheduling IG](https://build.fhir.org/ig/IHE/ITI.Scheduling/artifacts.html#behavior-operation-definitions) a défini un ensemble d'opérations pour la gestion des rendez-vous **Exemple d'architecture** ![](image-2.avif) - **Implémenter des services supplémentaires** Implémenter des services additionnels (par exemple, la collecte de rétroaction) - Ajouter des fonctionnalités (par exemple, les notifications) - Utiliser les abonnements FHIR pour la communication pilotée par les événements ### Modernisation des systèmes existants - **Sélection stratégique du service** — Choisir un service initial bien délimité pour un projet pilote (POC) - Envisager des candidats à haute valeur ajoutée et à faible risque, comme le portail patient ou l'index des [patients maîtres](/articles/master-patient-index-and-record-linkage) - **Architecture d'intégration** Établir une intégration bidirectionnelle entre les systèmes existants et les nouveaux microservices FHIR-natifs. ![](image-3.avif) - **Élargissement progressif de l'empreinte FHIR-native** Migrer les services supplémentaires de manière incrémentielle : Valider le service pilote en environnement de production - Identifier et prioriser les services suivants à migrer - Élargir progressivement l'empreinte FHIR-native en ajoutant de nouveaux microservices et en migrant les services existants ![](image-4.avif) - **Exemple : portail patient permettant aux patients de planifier et de gérer leurs visites** Étape 1 : Démarrer avec un projet pilote — un portail patient permettant aux patients de consulter leurs informations et leurs rendez-vous. ![](image-5.avif) Étape 2 : Ajouter un nouveau service pour la prise de rendez-vous. ![](image-6.avif) Étape 3 : Ajouter un service supplémentaire pour recueillir la rétroaction des patients sur leurs visites. ![](image-7.avif) ## Conclusion Bien que l'adoption d'une approche FHIR-native nécessite un investissement initial pour apprendre la norme FHIR et ses patrons d'implémentation, les avantages à long terme l'emportent largement sur la courbe d'apprentissage initiale. Une plateforme FHIR-native est : - **Pérenne** — Assurant l'interopérabilité à long terme avec les autres systèmes de santé - **Efficace** — Réduisant le temps de développement grâce à des patrons standardisés - **Robuste** — S'appuyant sur une norme mature et propre au domaine de la santé - **Conforme** — Simplifiant le respect des réglementations telles que les profils US Core pour la loi 21st Century Cures Act - **Riche en écosystème** — Bénéficiant de l'écosystème FHIR en pleine croissance d'outils et d'implémentations Prêt à implémenter des microservices FHIR-natifs dans votre organisation de santé ? Chez Health Samurai, nous avons aidé des dizaines d'organisations de santé à réussir leur transition vers des plateformes FHIR-natives. Que vous démarriez un nouveau projet ou que vous modernisiez des systèmes existants, notre équipe peut vous accompagner. Connectez-vous avec moi, [Aleksandr Kislitsyn](https://www.linkedin.com/in/aleksandr-kislitsyn-297854112/), sur LinkedIn pour discuter de votre cas d'utilisation spécifique et découvrir comment nous pouvons vous aider à atteindre vos objectifs d'interopérabilité en santé. Voir aussi : [Pourquoi vous avez besoin d'un serveur FHIR indépendant](/blog/why-you-need-independent-fhir-server-side-by-side-with-your-ehr-system).