FHIR : de la connexion à l’interopérabilité réelle

Ce que FHIR change pour les éditeurs de logiciels santé qui veulent rendre leurs intégrations réutilisables et déployables à l’échelle.

Un logiciel peut être très connecté sans être réellement interopérable. FHIR fournit un modèle commun pour structurer et échanger la donnée. Pour un éditeur, sa valeur apparaît lorsque les profils, mappings et règles de transformation deviennent des actifs gouvernés, testables et réutilisables d’un déploiement à l’autre.

Votre logiciel échange déjà des données avec des hôpitaux, des laboratoires, des DPI ou d’autres applications métiers. Pourtant, chaque nouveau déploiement peut encore faire réapparaître les mêmes difficultés : formats particuliers, règles locales, identifiants différents, codifications divergentes et interfaces à reconstruire.

Pour un éditeur de logiciels santé, le sujet n’est donc plus seulement de savoir faire circuler une information d’un point A vers un point B. Il est de permettre à un système qui n’a pas été conçu pour son émetteur de comprendre cette information et de la réutiliser, sans recréer à chaque client l’ensemble du travail d’intégration.

La distinction entre compatibilité et interopérabilité permet de comprendre le changement attendu. Deux équipements utilisant des prises différentes peuvent fonctionner grâce à un adaptateur : ils deviennent compatibles. Mais si chaque nouveau branchement impose un nouvel adaptateur, le système reste dépendant d’une traduction conçue pour ce couple précis.

Compatibilité : A → adaptateur spécifique → B

Le lien fonctionne, mais dépend d’une traduction propre à ce couple de systèmes.

Interopérabilité : A → convention commune ← B

Les systèmes partagent suffisamment de règles pour échanger et réutiliser la donnée.

Dans une architecture interopérable, l’effort porte moins sur chaque connexion que sur la définition et l’adoption d’un cadre commun. Pour l’éditeur, cela change l’unité de travail : il ne s’agit plus seulement de livrer une interface, mais de construire une capacité intégrée au produit, capitalisable d’un client à l’autre.

Avant de parler de FHIR, il faut revenir à l’objet que l’on souhaite réellement partager : la donnée. Un compte rendu PDF peut parfaitement contenir l’information « potassium sanguin : 4,2 mmol/L » et être immédiatement compréhensible par un professionnel de santé. Pour un logiciel, identifier de façon fiable le concept mesuré, la valeur, l’unité, le patient, la date et le contexte clinique est beaucoup plus difficile.

Structurer la donnée permet d’isoler ces éléments et de rendre l’information calculable, recherchable, contrôlable et réutilisable. Mais une donnée structurée n’est pas nécessairement standardisée : deux systèmes peuvent représenter le même examen avec des champs, des unités ou des codes différents.

Trois dimensions doivent donc être distinguées :

1. la structure : les éléments qui composent la donnée et leur organisation ;
2. la syntaxe : la manière dont cette structure est transmise — JSON, XML, HL7 v2, CSV ou format propriétaire ;
3. la sémantique : le sens des informations et les terminologies utilisées pour le partager.

Changer de format ne suffit pas. Une donnée peut être techniquement valide et correctement transportée, tout en restant difficile à exploiter si son sens n’est pas aligné. Pour un éditeur, la valeur apparaît lorsque la donnée reçue peut alimenter un workflow, une règle de décision, un entrepôt ou un usage Data et IA sans recommencer à chaque fois le travail de compréhension.

FHIR, pour Fast Healthcare Interoperability Resources, est un standard HL7 conçu pour représenter et échanger des informations de santé. Le réduire à une API REST en JSON est utile pour l’introduire, mais insuffisant pour comprendre son apport.

FHIR combine un modèle commun d’objets de santé avec des mécanismes standardisés pour les contraindre, les valider et les échanger. Les ressources décrivent des concepts récurrents ; les profils précisent, pour un contexte donné, les éléments obligatoires, les cardinalités, les terminologies et les règles de validation. FHIR ne prescrit pas pour autant le stockage interne du logiciel : une application peut conserver son propre modèle, dès lors qu’elle sait exposer ou consommer le modèle attendu.

L’intérêt architectural est la possibilité de traiter profils, ValueSets, ConceptMaps, StructureMaps et règles de transformation comme des artefacts explicites, versionnés et testables. Cette capitalisation permet de réduire la part de compréhension et de traduction reconstruite à chaque projet.

Retour d’expérience Fyrstain : laboratoire et EHDS

Lors d’un travail de préparation de six hôpitaux au modèle européen de laboratoire, les établissements disposaient déjà de codifications LOINC. Pourtant, les correspondances observées étaient fortement hétérogènes : pour un même besoin, on ne retrouvait pratiquement pas deux usages identiques. Le standard terminologique était présent ; l’alignement sémantique restait à construire.

Pour un éditeur, l’enseignement est direct : adopter un standard ne supprime pas automatiquement le travail d’alignement. Ce travail devient industrialisable lorsqu’il est gouverné, documenté, versionné et réutilisé au lieu d’être enfoui dans chaque connecteur.

Ce que FHIR apporte

• un modèle partagé pour représenter les concepts de santé les plus courants ;
• des mécanismes communs de profilage et de validation ;
• plusieurs modes d’échange standardisés, au-delà de la seule API REST ;
• des artefacts réutilisables entre projets ;
• un cadre favorable à l’outillage, aux tests automatisés et à la capitalisation.

Ce que FHIR ne garantit pas

• la qualité de la donnée : une mauvaise donnée reste mauvaise, même encodée en FHIR ;
• la cohérence sémantique : deux acteurs peuvent employer des codes différents dans une ressource valide ;
• la gouvernance : le standard ne désigne ni le producteur de référence ni le responsable de la donnée ;
• l’urbanisation et les processus métier : installer un serveur FHIR ne rend pas automatiquement le système interopérable.

Le piège à éviter

Il reste possible de reproduire l’ancien monde avec des technologies modernes : source → mapping spécifique → FHIR → mapping spécifique → cible. Dans ce scénario, FHIR modernise la façade mais ne traite pas le fond.

L’objectif n’est pas de fabriquer plus vite des connecteurs spécifiques. Il est de rendre explicites les mappings, les règles sémantiques et les profils, puis de les gouverner comme des composants du produit. Cela suppose notamment de :

• prioriser les flux et les cas d’usage réellement utiles au produit ;
• définir et versionner les profils, mappings et terminologies ;
• tester les transformations et valider les données échangées ;
• sécuriser, superviser et tracer les échanges ;
• capitaliser sur ces actifs lors des déploiements suivants.

La question pertinente n’est donc pas seulement « sommes-nous compatibles FHIR ? ». Elle est : notre architecture permet-elle de transformer progressivement la donnée en un actif standardisé, compris, gouverné, testable et réutilisable ?

L’intérêt de FHIR n’est pas de remplacer HL7 v2 par du JSON. Il est de permettre un changement de paradigme : passer d’un monde où chaque connexion constitue un nouveau projet à un monde où la donnée, ses règles de transformation et ses modèles d’usage deviennent progressivement des actifs communs. C’est à cette condition que l’interopérabilité peut réellement passer à l’échelle.

Le livre blanc « FHIR pour les éditeurs santé : Passer de l’API à la capacité produit » présente les choix d’architecture à examiner pour standardiser les flux, limiter le spécifique et préparer des usages Data et IA sur une donnée plus fiable et réutilisable.

Télécharger le livre blanc FHIR