Interopérabilité : FHIR, IPS et le dossier patient

Un logiciel de santé qui fonctionne seul est un logiciel incomplet. En pratique, il s’insère dans un écosystème : dossiers patients, laboratoires, imagerie, pharmacie, plateformes régionales. L’interopérabilité — la capacité à échanger des données de manière fiable et compréhensible — n’est donc pas une option technique ajoutée en fin de projet. C’est une exigence structurante, et elle se conçoit dès le début.

Pourquoi l’échange de données est un problème de conception

Échanger des données de santé revient à transmettre du sens, pas seulement des octets. Un résultat d’analyse, une prescription, un antécédent : chacun doit arriver avec le contexte qui permet de l’interpréter correctement, et d’être compris de la même manière par deux systèmes différents. Un message techniquement lisible mais sémantiquement ambigu est une source d’erreur, pas une interopérabilité.

C’est là que les standards jouent leur rôle. FHIR, porté par HL7, définit une manière moderne et structurée de représenter et d’échanger des données de santé, ressource par ressource. Ce n’est pas un simple format de fichier : c’est un modèle de représentation, avec ses ressources, ses règles, ses profils. Choisir FHIR, c’est choisir un langage commun — et un langage se parle bien ou mal.

L’IPS : un cas concret de socle partagé

L’International Patient Summary illustre bien l’enjeu. L’idée est de disposer d’un résumé minimal et standardisé du patient, exploitable au-delà d’une organisation et d’un pays, pour les situations où un soignant doit avoir l’essentiel sans accès au dossier complet. C’est un objet normalisé, construit sur des briques standard, qui doit rester compréhensible par des systèmes hétérogènes.

Pour un éditeur, l’IPS est un excellent révélateur : il oblige à penser en termes de périmètre minimal, de priorités de contenu et de fidélité de restitution. Ce qui compte n’est pas la richesse des données échangées, mais leur justesse et leur lisibilité dans un contexte contraint.

L’erreur classique : traiter l’interopérabilité comme une couche finale

Beaucoup d’équipes construisent leur modèle de données « maison », puis tentent d’y plaquer, en fin de parcours, une couche d’export vers FHIR ou vers un autre standard. Le résultat est presque toujours une traduction approximative : le modèle interne ne se laisse pas convertir proprement, et chaque échange devient un bricolage.

La bonne approche consiste à concevoir le modèle interne en dialogue avec les standards, en décidant tôt ce qui est nativement représentable et ce qui doit être projeté. C’est un arbitrage de conception, pas un ajout cosmétique. Plus il est tard, plus il coûte cher.

Ce que cela change selon la taille de l’entreprise

**Côté startup et PME.** L’interopérabilité ouvre des portes : un produit qui sait parler FHIR s’intègre à des écosystèmes cliniques sans développement spécifique à chaque client. C’est un levier de déploiement, pas une contrainte.

**Côté ETI.** Avec plusieurs produits dans un même groupe, l’interopérabilité devient un choix d’architecture partagé : mêmes briques d’échange, mêmes profils, même gouvernance des versions. Sans cela, chaque produit réinvente sa couche.

**Côté grand groupe.** L’enjeu est la coexistence : plusieurs produits, plusieurs standards, des sites hétérogènes. L’interopérabilité devient une politique, avec des profils de référence et une gestion rigoureuse des évolutions de standards.

L’idée à retenir

L’interopérabilité n’est pas un module qu’on branche à la fin. C’est une exigence de conception, portée par des standards comme FHIR et des objets comme l’IPS. Elle se joue au niveau du modèle de données, pas au niveau du format d’export. Traitée tôt, elle devient un avantage ; traitée tard, elle devient une dette.

Vous concevez un logiciel destiné à s’intégrer dans un écosystème de soins ? Parlons interopérabilité. → bonjour@numedikal.com