Depuis le 31 mars 2026, comme le détaille Pasquale Pillitteri, chaque compte rendu, lettre de sortie et procès-verbal des urgences doit rejoindre le Dossier de santé électronique 2.0 en HL7 CDA R2, ce format lisible par n'importe quel système régional. Fini le PDF orphelin qu'aucun logiciel ne sait interpréter. Et derrière, FHIR pousse la porte du REST et du JSON. Ça mérite qu'on s'y arrête, non?
Mais d'abord, c'est quoi ce "HL7" qu'on croise sans vraiment le lire?
Health Level Seven — le chiffre 7, c'est le septième niveau du modèle OSI, celui des applications, là où deux programmes échangent des données qui ont un sens clinique (et pas juste des paquets réseau). L'organisation HL7 International, à but non lucratif, publie depuis 1987 les standards qui font dialoguer admissions, labo, radiologie, pharmacie. Bref, tout l'enchevêtrement de SI qu'un hôpital empile depuis des décennies.
Le souci résolu est très concret: sans langage commun, chaque liaison entre deux systèmes exige une intégration sur mesure, et le nombre de connexions explose de façon quadratique avec le nombre d'applications. (Vous voyez le parallèle avec nos dettes techniques favorites, hein — c'est exactement la même galère, version hôpital.)
Du pipe au REST, pourquoi FHIR change la donne pour nous
FHIR, ou Fast Healthcare Interoperability Resources — à prononcer "fire" — a été publié en 2014 avec une ambition simple: appliquer à la santé ce que le web utilise depuis vingt ans, à savoir API REST, JSON, HTTP. Là où HL7 v2 (né en 1989 et toujours le plus répandu au monde) impose des messages textuels à l'ancienne, FHIR se lit comme une API moderne. Et selon Pillitteri, c'est la raison principale pour laquelle, à partir de 2014, toutes les grandes nouveautés réglementaires sur l'interopérabilité de santé ont choisi FHIR comme techno de référence.
Le détail qui tue: un dev web habitué à construire des applis avec des API modernes peut apprendre FHIR en quelques jours, pas en quelques mois. Voilà pourquoi ce standard nous concerne directement, nous qui faisons du web tous les jours.
V2 et FHIR: rivaux ou coéquipiers? Et nous, on fait quoi?
Réflexe de dev: croire qu'un nouveau standard tue l'ancien. Eh bien non! Un hôpital en 2026 utilise presque toujours les deux. HL7 v2 reste le roi pour faire dialoguer les systèmes internes éprouvés depuis vingt ans (on ne refacto pas un SI hospitalier en une nuit, soyons sérieux). FHIR, lui, s'impose dès qu'on expose des données vers les applis patients, les portails et les systèmes externes. L'Union européenne construit d'ailleurs l'Espace européen des données de santé sur FHIR — la messe est dite.
Si vous bossez dans la e-santé, la healthtech ou que vous avez un client qui louche sur l'Italie, c'est le moment de vous y mettre. Le format FHIR parle notre langage: Resources, bundles, endpoints RESTful. Pas besoin de repartir sur un cursus de six mois pour décrypter des specs obscures. Testez, expérimentez, et vous serez prêt quand le marché s'emballera.
Et pour le reste de l'écosystème? On en débat dans les commentaires: vous avez déjà touché à FHIR, ou c'est encore un sigle qu'on croise en conf sans jamais le voir atterrir dans nos sprints?