Interopérabilité FHIR : par où commencer quand rien ne communique
Des systèmes hospitaliers hétérogènes, aucun standard commun, des budgets limités. Un ordre d'action pour démarrer l'interopérabilité avec FHIR sans remplacer l'existant ni viser le tout-connecté d'emblée.
Un laboratoire, un service d’imagerie, une pharmacie, trois logiciels différents, aucun ne parle à l’autre. Les échanges se font par papier, par courriel ou par ressaisie. Cette situation est courante, dans les pays à ressources limitées comme dans des systèmes très équipés. L’interopérabilité FHIR offre un cadre commun, mais encore faut-il savoir par où commencer sans paralyser les équipes. Voici un ordre d’action réaliste.
Comprendre ce qu’est FHIR, en trois phrases
FHIR est un standard de HL7 qui décrit les données de santé comme des ressources (un patient, une observation, une prescription, une rencontre) échangées au moyen d’interfaces web usuelles. Il est conçu pour être plus simple à mettre en œuvre que les standards HL7 antérieurs. Plusieurs versions coexistent : la R4 (2019), la plus déployée, et la R5 (2023). Choisir une version et s’y tenir est la première décision.
Six étapes, dans l’ordre
- Cartographier les systèmes et les flux. Qui produit quelle donnée, dans quel format, vers qui ? Une page par flux suffit. Cette carte révèle souvent des échanges manuels qu’on n’avait pas comptés.
- Fiabiliser l’identité du patient. Sans identifiant partagé, les échanges produisent des erreurs de rattachement. C’est un préalable, pas une option.
- Choisir un premier cas d’usage étroit. Par exemple l’envoi des résultats de laboratoire vers le dossier de l’établissement. Un cas, deux systèmes, un résultat visible.
- Entourer l’existant d’une couche d’échange. Un serveur FHIR ou une passerelle traduit les données du système en place vers les ressources FHIR. Le logiciel d’origine n’est pas modifié.
- Aligner les terminologies. Des codes communs pour les diagnostics, les analyses, les médicaments : par exemple LOINC pour les examens de laboratoire et SNOMED CT pour les concepts cliniques, selon l’accès disponible dans le pays. Sans cela, on échange des données que l’autre ne comprend pas.
- Mesurer, puis étendre. Délai d’acheminement, taux d’erreurs, temps de ressaisie évité. Ces mesures justifient l’extension à un deuxième cas d’usage.
- Système existantformats propres
- Couche d’adaptationtraduction vers FHIR
- Serveur FHIRressources, contrôle d’accès
- Systèmes consommateursdossier, portail, analyse
Choisir FHIR ne règle ni l’identité, ni les terminologies, ni la gouvernance. Ces trois sujets sont la vraie difficulté ; le standard n’en est que le véhicule.
Sécurité et gouvernance
Les données de santé sont sensibles. Un serveur FHIR doit être protégé par une authentification solide, des autorisations par rôle et une journalisation des accès. Le cadre SMART on FHIR décrit une manière standard d’autoriser des applications à accéder aux données. Côté gouvernance, désigner qui décide des profils utilisés (les règles d’usage de chaque ressource), qui valide les terminologies et qui répond en cas d’incident.
- une version de FHIR retenue et documentée ;
- un propriétaire pour chaque flux de données ;
- des profils d’usage écrits, par exemple pour un résumé patient (le résumé international du patient, IPS, peut servir de modèle) ;
- un jeu de tests pour vérifier chaque connexion avant la mise en service ;
- un plan de gestion des erreurs : que fait-on d’un message refusé ?
Pour aller plus loin
La démarche détaillée relève de notre expertise santé numérique, et la solution Betz en présente la mise en œuvre. Le diagnostic permet de cartographier vos flux avant de choisir un premier cas d’usage.
Questions fréquentes
Qu'est-ce que FHIR ?
FHIR (Fast Healthcare Interoperability Resources) est un standard publié par HL7 pour échanger des données de santé sous forme de ressources (patient, observation, médicament…) via des interfaces web. Plusieurs versions coexistent, dont la R4 (2019) très répandue et la R5 (2023).
Faut-il changer de logiciel pour utiliser FHIR ?
Non. On peut exposer les données d'un système existant par une couche d'adaptation qui traduit ses formats vers FHIR, ou faire évoluer le logiciel quand son éditeur le permet.
Par quel cas d'usage commencer ?
Un cas où l'échange manque cruellement et où les données sont simples : résumé patient, résultats de laboratoire, ou demande et compte rendu d'examen. Un cas précis permet de valider l'approche avant d'élargir.