Qu'est-ce que FHIR et pourquoi cela compte pour votre dossier médical

Si vous avez déjà cherché une application pour votre dossier médical, vous avez croisé le sigle FHIR. Il apparaît dans les descriptions, sur les pages « sécurité et conformité », dans les annonces des hôpitaux et des ministères. Il est rarement expliqué. Ce guide le fait sans faire de vous un programmeur : ce qu'est FHIR, quel problème il résout, ce qu'il signifie concrètement pour vous, et comment savoir si une application l'utilise vraiment ou l'écrit seulement sur son site.

Le problème : chaque système parle une langue différente

Une analyse de sang faite dans un laboratoire vous parvient en PDF. La même analyse, dans le système de l'hôpital, est une ligne dans une base de données au format maison. Chez votre médecin traitant, c'est peut-être une note en texte libre. Trois endroits, trois formats, aucun lien entre eux. Quand vous voulez les rassembler, le seul outil est une personne qui lit et ressaisit.

Pendant des décennies, les systèmes de santé ont été construits exactement ainsi : chacun avec son format, échangeant des données avec les autres uniquement par des « passerelles » écrites sur mesure, coûteuses et fragiles. Les normes plus anciennes (HL7 version 2, des années 1980, ou CDA) ont partiellement résolu le problème pour les hôpitaux, mais elles sont difficiles à utiliser pour les applications modernes et presque impossibles à lire pour une personne.

Ce qu'est FHIR

FHIR (prononcé « fire ») signifie Fast Healthcare Interoperability Resources. C'est une norme publiée par HL7 International, l'organisation qui définit depuis plus de 35 ans comment les données de santé circulent entre systèmes. La version largement utilisée aujourd'hui est R4 (4.0.1), publiée en 2019 ; une version plus récente, R5, existe depuis 2023, mais la plupart des systèmes dans le monde, y compris les exigences légales de l'UE et des États-Unis, reposent sur R4.

L'idée centrale est simple : toute information médicale est décrite comme une ressource avec une structure connue. Il existe une ressource pour le patient (Patient), une pour une analyse ou une mesure (Observation), une pour un diagnostic (Condition), une pour un médicament prescrit (MedicationRequest), une pour une allergie (AllergyIntolerance), une pour un vaccin (Immunization), une pour un document (DocumentReference), et ainsi de suite, environ 150 au total. Chaque ressource a des champs définis : une Observation a un code pour ce qui a été mesuré, une valeur, une unité, une date, qui a mesuré, pour qui.

Les ressources s'écrivent en JSON ou en XML, des formats que tout langage de programmation lit, et circulent sur internet exactement comme les pages web, par des adresses et des requêtes HTTP. C'est la différence avec les anciennes normes : FHIR utilise les outils que tout programmeur connaît déjà, donc il est peu coûteux à mettre en œuvre et difficile à mal mettre en œuvre.

Les codes : pour que tout le monde comprenne la même chose

La structure ne suffit pas. Si un système écrit « glycémie » et un autre « glucose sérique », ils ne se comprennent toujours pas. FHIR résout cela en exigeant des codes standard pour le contenu :

• LOINC pour les analyses et les mesures : la glycémie à jeun porte le code 1558-6, partout dans le monde.
• SNOMED CT et CIM-10 pour les diagnostics et les actes.
• ATC (classification de l'OMS) pour les médicaments, par substance active.
• UCUM pour les unités : mg/dL et mmol/L s'écrivent de façon identique partout, et la conversion est automatique.

Avec la structure et les codes, une ressource FHIR produite par un laboratoire de Sibiu est lue correctement par un hôpital de Vienne ou une application en Californie, sans que personne n'ait écrit de « passerelle » entre eux.

Ce que cela signifie pour vous, concrètement

Quatre choses, de la plus visible à la plus importante.

Vos données peuvent être déplacées. Si votre dossier est stocké en FHIR, il peut être exporté intégralement et importé dans tout autre système compatible. Vous ne dépendez pas d'une seule application et vous n'êtes pas otage d'un format qu'elle seule comprend. « À vous » signifie, en pratique, « exportable dans un format standard ».

Vos données peuvent être comprises par les médecins. Un nouveau médecin, un hôpital dans un autre pays, un service d'urgence : tous peuvent recevoir un résumé FHIR (généralement sous forme de Résumé international du patient) et le lire dans leur système, avec leurs codes, dans leur langue. Pas un PDF de 40 pages, mais des données qu'ils peuvent chercher, filtrer et comparer.

Vos données peuvent être rassemblées. Analyses de laboratoires différents, mesures de la montre, médicaments des ordonnances, documents scannés : quand tout est ressource FHIR avec codes LOINC et dates, tout tient sur la même ligne du temps et se compare. Une bonne application le fait automatiquement.

Vos données sont protégées par une norme, pas par une promesse. FHIR décrit aussi comment l'accès aux données est accordé : par SMART on FHIR, un cadre fondé sur OAuth 2, dans lequel vous approuvez explicitement quelle application voit quelle partie du dossier, pour combien de temps, et vous pouvez retirer l'accès. C'est le même mécanisme que « se connecter avec Google » sur un site, appliqué aux données de santé, avec des permissions fines (seulement les analyses, seulement les médicaments, lecture seule).

Où FHIR est déjà utilisé

FHIR n'est pas une norme « d'avenir ». Elle est déjà obligatoire ou en usage dans des endroits que vous connaissez :

• Les États-Unis exigent par la loi (21st Century Cures Act et règles ONC de 2020) que tout système médical certifié expose les données du patient via une API FHIR R4, et que le patient puisse récupérer ses données avec l'application de son choix.
• Apple Health Records apporte le dossier de centaines d'hôpitaux dans l'app Santé de l'iPhone, via FHIR.
• L'Union européenne a choisi FHIR pour le format européen d'échange des dossiers de santé électroniques (EEHRxF), que le règlement EHDS impose aux États membres ; les résumés patient échangés entre pays via MyHealth@EU sont construits dessus.
• Le Royaume-Uni, les Pays-Bas, l'Allemagne et les pays nordiques utilisent FHIR dans leurs infrastructures nationales, de l'ordonnance électronique allemande au dossier néerlandais.
• L'Organisation mondiale de la santé a choisi le Résumé international du patient, fondé sur FHIR, pour son réseau mondial de certificats de santé numériques.

Pour vous, cela signifie qu'une application qui garde votre dossier en FHIR R4 n'est pas une île : elle parle la langue que parlent déjà les hôpitaux et les autorités, aujourd'hui et pour la prochaine décennie.

Comment reconnaître une application qui utilise vraiment FHIR

N'importe qui peut écrire « FHIR » sur un site. Les questions ci-dessous séparent le mot de la réalité.

1. Puis-je exporter tout mon dossier en FHIR ? Pas « un rapport PDF », mais un fichier avec les ressources (un Bundle) qu'un autre système peut importer. Si la réponse est « non » ou « seulement sur demande, par e-mail », les données ne sont pas vraiment à vous.
2. Les analyses ont-elles des codes LOINC et des unités UCUM ? Une application qui ne retient que « Cholestérol : 210 » en texte ne peut pas comparer avec la valeur de l'an dernier d'un autre laboratoire. Une qui retient le code et l'unité, si.
3. Puis-je donner accès à quelqu'un d'autre, de façon limitée et révocable ? Un médecin, une clinique, une autre application : avec SMART on FHIR, vous choisissez ce qu'ils voient et pour combien de temps, et vous voyez qui a lu quoi.
4. Puis-je générer un résumé IPS ? C'est le test pratique de l'« interopérabilité » : si l'application peut produire le résumé standard que lit tout hôpital européen, la structure derrière est réelle.
5. Existe-t-il une documentation publique pour les développeurs ? Une API FHIR documentée, avec une déclaration de capacités (CapabilityStatement) publique, signifie que d'autres systèmes peuvent vraiment se connecter. S'il n'y en a pas, « interopérable » n'est qu'un adjectif.

Ce que FHIR ne résout pas

Il est honnête de dire aussi les limites. FHIR décrit le format et le transport des données, pas leur qualité : une analyse mal saisie reste fausse, seulement dans un joli format. FHIR ne garantit pas votre confidentialité ; elle dépend de qui héberge les données, dans quel pays et avec quelles règles d'accès. Et FHIR ne donne pas aux systèmes l'envie d'échanger : beaucoup d'hôpitaux ont une API FHIR et ne l'ouvrent à personne, et c'est précisément pour cela que la législation (aux États-Unis, et dans l'UE via l'EHDS) existe pour les y obliger.

Comment Anpheros utilise FHIR

Anpheros stocke le dossier de chaque personne sous forme de ressources HL7 FHIR R4 (26 types de ressources, de Patient et Observation à DocumentReference et Consent), avec des codes LOINC, CIM-10, ATC et UCUM, dans l'Union européenne. L'application Anpheros Daily est un client de la même API publique qu'utilisent les cliniques et les développeurs ; il n'existe pas de format « interne » séparé. Vous pouvez exporter à tout moment le dossier complet ou un résumé IPS, validé avec le validateur officiel HL7. L'accès d'autres applications passe par SMART on FHIR, avec un consentement à durée limitée, révocable, et un journal que vous voyez. La documentation de l'API et la déclaration de capacités sont publiques sur developers.anpheros.com.

Questions fréquentes

Dois-je connaître FHIR pour utiliser mon dossier ?

Non. FHIR est sous le capot. Vous voyez des analyses, des médicaments et des documents ; la norme fait qu'ils peuvent être déplacés, comparés et lus par les médecins. Il vaut la peine de savoir qu'elle existe seulement pour bien choisir où vous gardez vos données.

FHIR est-il la même chose que Mon espace santé ?

Non. FHIR est un format et un mode de transport ; le dossier national est un système. Beaucoup de systèmes nationaux utilisent ou adoptent FHIR, mais le fait qu'un pays ait un dossier électronique ne signifie pas que vous puissiez en sortir vos données en FHIR. Dans l'UE, l'EHDS exigera exactement cela.

Quelle différence entre FHIR R4 et R5 ?

R5 (2023) apporte des affinements, mais n'est pas encore exigé par la législation et peu de systèmes l'utilisent. R4 (2019) est la base des exigences américaines et européennes et des implémentations existantes. Une application en R4 est le choix sûr aujourd'hui ; le passage à R5 se fera progressivement, avec compatibilité.

Si mon export est en FHIR, puis-je vraiment l'importer dans une autre application ?

Si l'autre application accepte l'import FHIR, oui, à une condition : des codes standard. Les ressources avec LOINC, CIM-10 et UCUM se transposent proprement ; celles en texte libre finissent en notes. C'est pourquoi il importe que l'application d'origine ait codé les données dès le départ.

FHIR est-il sécurisé ?

FHIR en soi n'est ni sécurisé ni non sécurisé ; c'est un format. La sécurité vient de la mise en œuvre : chiffrement, hébergement, authentification, consentement. SMART on FHIR offre un bon cadre pour un accès contrôlé, mais il faut toujours regarder qui détient les données et où.