Imaginez un patient qui sort de l'hôpital avec une ordonnance, va chez son pharmacien, puis consulte son médecin traitant trois semaines plus tard. Si chaque logiciel parle sa propre langue, les informations se perdent, se ressaisissent, se déforment. L'interopérabilité est la capacité de deux systèmes informatiques différents à échanger des données de santé et à les comprendre de la même façon, sans ressaisie ni interprétation hasardeuse.
Concrètement, l'interopérabilité repose sur des standards : des règles communes qui décrivent comment structurer une information (un patient, une prescription, un résultat de biologie) et comment la transmettre. Le standard de référence aujourd'hui s'appelle HL7 FHIR. Il définit des « ressources » — des blocs de données normalisés — échangées via des API sécurisées, c'est-à-dire des interfaces logicielles qui permettent à deux applications de dialoguer directement.
Ce mécanisme ne fonctionne que parce qu'il s'appuie sur des référentiels nationaux : un identifiant patient unique, des annuaires de professionnels, des nomenclatures médicales partagées. Sans ces briques communes, chaque éditeur réinventerait sa propre logique, et l'échange resterait théorique. En France et en Europe, le référencement des logiciels de santé impose désormais ces standards : un éditeur qui veut vendre sa solution à un hôpital doit prouver qu'elle sait parler FHIR.
Exemple concret : un laboratoire d'analyses transmet un résultat de prise de sang. Grâce à FHIR, ce résultat arrive dans le dossier du médecin traitant structuré — valeur, unité, date, intervalle de référence — et non sous forme de PDF scanné à relire à l'œil. Le gain n'est pas seulement du confort : c'est une réduction du risque d'erreur de lecture ou de ressaisie.
La maturité de cette technologie est aujourd'hui qualifiée d'industrialisée : ce n'est plus un sujet de recherche, c'est une obligation réglementaire croissante. Cela change la nature de votre questionnement en entreprise : il ne s'agit plus de savoir « si » il faut s'y mettre, mais « comment » l'exiger et le vérifier chez vos fournisseurs.
Limites et pièges à éviter
Premier piège : confondre « format de fichier commun » et véritable interopérabilité. Échanger un PDF n'est pas interopérable, même si tout le monde peut l'ouvrir : la donnée n'est pas structurée, donc pas exploitable automatiquement. Deuxième piège : croire qu'un logiciel « compatible FHIR » suffit à garantir l'échange réel. Encore faut-il que les deux systèmes utilisent les mêmes ressources, les mêmes identifiants, et que les référentiels nationaux soient correctement raccordés.
💡 Conseil de pro : quand un éditeur vous annonce « nous sommes interopérables », demandez-lui de citer précisément les ressources FHIR qu'il implémente et avec quels référentiels nationaux il est raccordé. Une réponse vague est un signal d'alerte.
Mini-exercice : listez trois situations dans votre environnement professionnel où une donnée circule aujourd'hui par PDF, fax ou ressaisie manuelle. Pour chacune, notez ce que changerait un échange structuré via API.