FHIR : couteau suisse de l'interopérabilité en santé

L’interopérabilité dans le domaine de la santé s’appuie sur différents standards parmi lesquels on remarque l’émergence de FHIR depuis quelques années. L’échange, le partage et la structuration des données de santé sont de plus en plus critiques au sein des systèmes d’information (SI) de santé et entre les SI de santé. Nous traversons aussi une époque associée à un besoin croissant de capitaliser sur les données de santé, d’être en capacité de les faire circuler et surtout de les exploiter de façon simple et homogène.  La pandémie de covid-19 en est une illustration et FHIR permet de répondre à certains de ces besoins.

Voici un aperçu de ses principales caractéristiques, de ses grandes forces et petites faiblesses.

Un standard taillé pour les données structurées, modulaire, extensible et simple à déployer

FHIR (Fast Healthcare Interoperability Resources) est un standard international élaboré à partir de 2011 par l’organisation HL7 qui lève certaines limites des standards existants sans avoir la prétention de les remplacer. Il a le potentiel de couvrir l’ensemble des flux des systèmes d’information de santé dans tous les contextes imaginables, qu’ils soient administratifs ou purement cliniques et médicaux. Il répond particulièrement bien aux besoins de mobilité et aux développements associés, ainsi qu’à la constitution d’entrepôts de données de santé alimentés en temps réel à travers des flux de données structurées.

Sa conception s’appuie sur un modèle de données reprenant globalement celui du monde HL7/IHE, des « ressources de base » (environ 150 ressources censées couvrir 80% des besoins), des frameworks et des APIs. Une ressource FHIR est une unité atomique d’échange de données : citons par exemple les ressources Patient, Rendez-vous, Problème, Médicament, Praticien, Observation (résultats d’examen, etc.), Rencontre (consultation, admission, etc.), etc. Les ressources sont accessibles et peuvent être manipulées à travers des URL facilitant leur création, lecture, recherche, mise à jour et suppression. FHIR utilise des technologies web classiques (REST, HTTP, JSON ou XML), propose de nombreux outils pédagogiques et d’édition, et ses spécifications sont gratuites, bien documentées, accessibles en ligne et alimentées par une communauté active.

Il poursuit un processus de « maturation » qui a fait de lui en 2019 un véritable standard normatif lors de la publication de la « version 4 » par HL7.

Fhir est complémentaire des standards actuels et répond à de nouveaux usages du terrain

FHIR bénéficie du retour d’expérience d’autres standards en matière d’interopérabilité, notamment du standard CDA (Clinical Document Architecture) qui permet depuis 20 ans de structurer de façon plus ou moins fine le contenu de documents cliniques. CDA est notamment utilisé dans le Dossier Médical Partagé (DMP) comme standard définissant la structure des documents qui peuvent y être déposés. Les logiciels et différents SI de production de documents cliniques sont donc eux-mêmes tenus de respecter cette structuration (DMP compatibilité) soit nativement, soit à travers des composants (API) qui en garantissent la conformité à ce que le DMP « attend » en termes d’alimentation.

Comme CDA, FHIR permet de gérer des documents cliniques. Mais tandis que CDA décrit de façon verbeuse la structure arborescente XML d’un document clinique, un document FHIR est un assemblage de ressources FHIR organisé sous forme de « blocs de données » incorporés ou  sous forme de liens vers des ressources qui peuvent être stockées sur différents serveurs. Un document FHIR peut être converti en document CDA et vice versa, ou encore contenir un lien vers un document CDA. Les principales différences entre FHIR et CDA sont :

• La modularité et flexibilité de FHIR : les ressources FHIR sont nombreuses, de taille limitée et peuvent être reliées et interagir entre elles ; FHIR permet aussi de gérer des messages ;
• L’extensibilité et le profilage de FHIR pour compléter et affiner les ressources selon certains besoins ;
• La rapidité de FHIR (Fast) : pour les développements et pour les transactions temps réel ;
• Une alternative à la centralisation : des ressources peuvent être réparties sur différents serveurs ;
• La capacité de FHIR à prendre en compte d’autres contextes que les seuls documents cliniques.

La doctrine technique du numérique en santé encourage le recours à fhir et son adoption dans le ci-sis

Le Cadre d’Interopérabilité des SI de Santé (CI-SIS) maintenu par l’Agence du Numérique en Santé (ANS) propose en France depuis une dizaine d’années des « volets » décrivant des modèles de contenus métier destinés aux documents CDA.

Depuis 2018, il adopte peu à peu FHIR, principalement pour des cas d’usages en situation de mobilité à travers la couche « Services » du CI-SIS. La définition de « volets » qui décrivent des contenus métier s’appuyant sur FHIR fait actuellement l’objet de travaux par l’ANS, en particulier pour des bases de constantes et de mesures de santé, ainsi que pour des références d’imagerie.

FHIR n’est pas censé remplacer CDA, du moins pas avant longtemps. On peut donc prévoir une cohabitation de ces différents standards, et le choix d’implémenter l’un ou l’autre sera fait selon la pertinence de chaque standard par rapport à l’usage rencontré. Une chose est certaine et doit guider les acteurs de la e-santé : la Doctrine du Numérique en Santé encourage l’adoption de FHIR et, d’autre part, l’ANS encourage les acteurs de terrain à lui exprimer leurs besoins et nouveaux cas d’usage afin d’évaluer la pertinence d’adopter par exemple FHIR ou CDA pour définir un nouveau modèle de document.

Important : La version 5 de FHIR est attendue depuis plusieurs mois, elle permettrait de stabiliser davantage le contenu de la version 4. En effet, seulement 13 ressources sur 148 sont à l’état normatif, ce qui laisse supposer des changements à venir dans la version 5. Il convient donc d’être prudent et pragmatique dans les choix de mise en œuvre de FHIR en raison de changements qui pourraient remettre en question certains postulats ou développements basés sur la version 4. Ces choix devront préférentiellement s’appuyer sur les travaux des structures de gouvernance en interopérabilité en France et respecter le CI-SIS.