Création de microservices en santé : une approche FHIR-native

Architecture de microservices en santé

Les microservices constituent un patron d'architecture largement adopté qui structure les applications comme un ensemble de services faiblement couplés et déployables indépendamment. 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 meilleure technologie pour son service particulier 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 à la minute
• Le service de planification des rendez-vous pourrait être en Node.js et traiter 500 requêtes à la minute
• Le service d'aide à la décision clinique pourrait utiliser Python avec TensorFlow pour traiter 2 000 dossiers patients à la 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 des services.

C'est là qu'intervient HL7 FHIR (Fast Healthcare Interoperability Resources).

Pourquoi FHIR convient bien aux architectures en microservices

Initialement conçu 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 pour les architectures en microservices. Modifier le modèle peut affecter les API exposées, ce qui exige une coordination entre les équipes.

Par exemple, ajouter un nouveau champ « preferredPharmacy » à la ressource Patient nécessiterait 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 — ce qui requiert une coordination rigoureuse entre plusieurs équipes.

FHIR fournit :

• Ressources propres au domaine de la santé : Un ensemble complet de 145 ressources prêtes à l'emploi (Patient, Encounter, Observation, etc.) élaborées par des experts du domaine de la santé au terme de milliers d'heures de travail collaboratif. Chaque type de ressource est une racine d'agrégat au sens du DDD (Domain Driven Design).
• Cadre d'extensibilité : Capacité d'étendre et de contraindre les ressources de base pour des cas d'usage précis grâce au profilage. Par exemple, vous pouvez ajouter des extensions à la ressource Patient pour stocker des informations non prévues 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 profil US Core Patient à titre d'exemple.
• Guides d'implémentation : Des modèles prêts à l'emploi pour implémenter des domaines de santé précis en FHIR. Ces guides fournissent des extensions, des profils et des opérations pour des sous-domaines particuliers (comme la planification, l'oncologie, etc.).

2. Gestion normalisée de la terminologie

Il existe quelques grands systèmes de codes très répandus en santé :

• SNOMED CT (plus de 350 000 concepts médicaux)
• LOINC (près de 100 000 codes d'analyses 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 de ces systèmes de codes dans vos microservices représente un défi. 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 est « 401303003 »
• Des services différents 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 :

• Systèmes de codage intégrés : Prise en charge des terminologies médicales normalisées (SNOMED CT, LOINC, ICD-10, RxNorm, etc.)
• Services de vocabulaire : API normalisées pour la validation et la recherche terminologique. Exemple : lorsqu'un clinicien saisit le diagnostic d'un patient dans un système de DSÉ, au lieu de taper manuellement le diagnostic, il le sélectionne à partir d'un service de terminologie FHIR qui fournit des codes SNOMED CT en temps réel. Une fois saisi, le serveur FHIR peut valider la donnée avant de la stocker sous forme de ressource Condition.
• Gestion des ensembles de valeurs : Approche définie pour la gestion des ensembles de codes. Exemple : vous pouvez définir un sous-ensemble réutilisable de codes SNOMED CT sous forme de ressource ValueSet afin d'offrir aux cliniciens une liste ciblée de codes de diagnostics pertinents pour leur spécialité.
• Mise en correspondance entre versions : Prise en charge du versionnage et de la mise en correspondance terminologique. 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 une composante essentielle de l'architecture en microservices. Vous devez concevoir les schémas de communication pour les interactions synchrones et asynchrones entre les services.

Par exemple, considérez un flux de travail de sortie d'hospitalisation :

• Le service clinique doit vérifier de façon synchrone la disponibilité des médicaments
• 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 des rendez-vous de suivi
• Le service de facturation doit recevoir le résumé final de sortie

Sans schémas normalisés, chacune de ces interactions nécessiterait une conception et une implémentation d'API personnalisée.

FHIR l'a fait pour vous.

• Interface RESTful : Opérations CRUD normalisées alignées sur les méthodes HTTP.
• Prise en charge des transactions : Prise en charge intégrée des opérations atomiques multi-ressources qui évitent 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 sauvegardés ensemble, soit aucun des deux ne l'est. Cela prévient les situations dangereuses où un médicament existerait sans son diagnostic associé, ou inversement, ce qui pourrait mener à des erreurs médicales. Si une partie de la transaction échoue (par ex., une vérification d'interaction médicamenteuse), l'ensemble de l'opération est annulé automatiquement.
• Cadre de recherche : Capacités de recherche complètes avec des paramètres normalisés. Exemple : vous pouvez créer une seule requête FHIR Search 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 :

GET /fhir/Patient?_has:Consent:patient:actor=<practitioner-id>&_has:Consent:patient:scope=Encounter&_revinclude=Encounter:subject

• Cadre de souscriptions : Prise en charge intégrée de la communication pilotée par é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 une alerte automatique.

Architecture cible d'une solution de microservices FHIR-native

La première étape pour construire une solution de microservices FHIR-native consiste à choisir le stockage des données.

Deux patrons répandus sont :

• Base de données (serveur FHIR) par service — où chaque service dispose de son propre stockage FHIR isolé
• Base de données partagée (serveur FHIR) — tous les services utilisent le serveur FHIR partagé pour stocker l'ensemble des ressources FHIR

L'architecture base de données par service contribue à garantir que les services sont faiblement couplés. Les modifications apportées à la base de données d'un service n'ont aucun impact sur les autres services. Les inconvénients sont :

• La gestion et l'implémentation de plusieurs serveurs FHIR
• Un effort supplémentaire pour implémenter des transactions couvrant plusieurs services
• Une plus grande complexité pour implémenter des recherches transversales aux services

La base de données partagée semble plus naturelle pour une solution de microservices FHIR-native, en raison des avantages suivants :

• Effort d'implémentation réduit : Opérations CRUD et capacités de recherche prédéfinies sur toutes les ressources

• Prise en charge intégrée des transactions sur 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 facilitée de l'intégrité référentielle

• 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, éliminant le besoin de modifications de schéma coordonnées

Le diagramme suivant illustre l'architecture cible d'une solution de microservices FHIR-native :

Composantes principales de l'architecture

• Services de santé

Microservices propres à un domaine qui implémentent la logique métier pour différents flux de travail en santé (par ex., gestion des patients, planification, documentation clinique). Ils interagissent avec le serveur FHIR via les API REST FHIR normalisées et consomment des événements via les souscriptions.

• Serveur FHIR : Stockage de données partagé qui : fournit les 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 souscriptions

• Gère la validation des données.

• Serveur de terminologie

Gère les vocabulaires et systèmes de codes en santé (SNOMED CT, LOINC, ICD-10, etc.). Fournit des opérations de validation, de recherche et de mise en correspondance terminologique pour assurer l'interopérabilité sémantique sur toute la plateforme.

• Services d'infrastructure et de sécurité : Préoccupations transversales incluant : l'authentification et l'autorisation
• La passerelle API et le routage
• La journalisation des audits et la surveillance
• PACS (Picture Archiving and Communication System)

Étapes pour construire un système FHIR-native en architecture de microservices

L'approche d'implémentation diffère considérablement entre les projets en table rase et la modernisation de systèmes patrimoniaux. Alors que les nouveaux systèmes peuvent être conçus avec des principes FHIR-natifs dès le départ, les systèmes de santé existants nécessitent une stratégie de migration rigoureuse.

Projet en table rase

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 guidée par les ressources : Faites 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éfinissez les frontières entre les microservices Les frontières de service optimales dépendent fortement de votre cas d'usage et du contexte de votre système, mais voici quelques lignes directrices pour orienter la décision :- FHIR fournit des orientations pour organiser les ressources en groupes logiques : https://hl7.org/fhir/overview-arch.html#organizing

• Consultez les guides d'implémentation FHIR (IG) pertinents pour des orientations propres au domaine, par ex. pour la planification : https://build.fhir.org/ig/IHE/ITI.Scheduling/volume-1.html

• Les définitions de ressources dans la spécification FHIR sont é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

• Mise en place de l'infrastructure : Déployez un serveur FHIR de niveau production

• Implémentez les services de sécurité et d'authentification

• Configurez l'infrastructure de surveillance et de journalisation

• Configurez les services de terminologie

• Implémentation des services Commencez par les services de base (gestion des patients, planification)

• Utilisez les API CRUD et Search FHIR du serveur FHIR pour travailler avec les ressources FHIR depuis les microservices

• Implémentez la logique métier dans les microservices en concevant et en implémentant des opérations sur les ressources FHIR. Inspirez-vous de la spécification FHIR ou des guides d'implémentation. Par exemple, le FHIR Scheduling IG a défini un ensemble d'opérations pour la gestion des rendez-vous

Exemple d'architecture

Implémenter des services supplémentaires

Implémentez des services additionnels (par ex., la collecte de rétroaction)

• Ajoutez des fonctionnalités (par ex., les notifications)

• Utilisez les souscriptions FHIR pour la communication pilotée par événements

Modernisation d'un système patrimonial

• Sélection stratégique des services : Choisissez un service initial bien délimité pour une preuve de concept (PDC)

• Envisagez des candidats à valeur élevée et à risque faible, comme le portail patient ou l'index maître des patients

• Architecture d'intégration

Établissez une intégration bidirectionnelle entre les systèmes patrimoniaux et les nouveaux microservices FHIR-natifs.

Élargissement progressif de l'empreinte FHIR-native

Migrez les services supplémentaires de façon incrémentielle :

Validez le service PDC en environnement de production

• Identifiez et priorisez les services suivants à migrer

• Élargissez progressivement l'empreinte FHIR-native en ajoutant de nouveaux microservices et en migrant les existants

Exemple : portail patient permettant aux patients de planifier et de gérer leurs visites

Étape 1 : Commencez par une PDC — un portail patient qui permet aux patients de consulter leurs informations et leurs rendez-vous. Étape 2 : Ajoutez un nouveau service pour la planification des rendez-vous. Étape 3 : Ajoutez un service supplémentaire pour recueillir la rétroaction des patients sur leurs visites.

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 dépassent largement la courbe d'apprentissage initiale.

Une plateforme FHIR-native est :

• Pérenne — Garantissant une interopérabilité à long terme avec les autres systèmes de santé
• Efficace — Réduisant le temps de développement grâce à des patrons normalisés
• Robuste — S'appuyant sur une norme mature propre au domaine de la santé
• Conforme — Simplifiant le respect de réglementations telles que les profils US Core pour le 21st Century Cures Act
• Riche en écosystème — Bénéficiant de l'écosystème FHIR croissant 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é à passer avec succès à des plateformes FHIR-natives. Que vous démarriez un nouveau projet ou que vous modernisiez des systèmes patrimoniaux, notre équipe peut vous aider.

Connectez-vous avec moi, Aleksandr Kislitsyn, sur LinkedIn pour discuter de votre cas d'usage particulier 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.