Utiliser les FHIR pour demander un deuxième avis

Dans un précédent article, nous expliquions comment un patient peut tirer parti de FHIR (Fast Healthcare Interoperability Resources) afin de transférer des documents et des résultats à un radiologue pour une demande de deuxième avis. Au lieu de clés USB, de CD et de saisies manuelles, les systèmes communiquent directement entre eux via des interfaces standardisées.

Mais concrètement, comment tout cela fonctionne-t-il ? Dans cet article, nous plongeons dans les aspects techniques de ce cas concret : quelles ressources FHIR entrent en jeu, comment le guide d’implémentation CH RAD-Order et SDC (Structured Data Capture) peut s’intègrent dans cet ensemble, et à quoi ressemblerait une mise en œuvre réaliste ?

Il s’agit du deuxième article d’une série consacrée aux FHIR.

Les FHIR est un standard moderne d’échange de données de santé. Il a été conçu à partir des enseignements tirés de HL7 v2 et v3, ainsi que des pratiques issues plus largement du monde du web.

Voici, selon moi, l’essentiel des FHIR :

• C’est tout simplement de la technologie web moderne  : FHIR s’appuie sur des API REST via HTTP et représente les données en JSON ou en XML — comme la plupart des services web actuels. Cela rend l’intégration de services cloud, d’applications mobiles et d’autres plateformes de télémédecine naturellement compatibles. Et nul besoin de repartir de zéro côté outillage : une grande partie des technologies et outils de l’écosystème web peut être réutilisée.
• Un modèle basé sur des ressources  : au lieu des énormes blocs de HL7 v3, ou des extensions ad hoc et spécifiques à chaque site souvent rencontrées avec HL7 v2, FHIR définit de petites ressources modulaires et combinables, comme Patient, ServiceRequest, DiagnosticReport, ImagingStudy, DocumentReference, et bien d’autres. Les workflows complexes se construisent en combinant ces ressources et les références entre elles.
• Conçu pour l’extensibilité (la règle des 80/20)  : FHIR vise à couvrir environ 80 % des cas mondiaux. Les 20 % restants sont volontairement laissés aux profils et aux guides d’implémentation (Implementation Guides, IG), qui adaptent FHIR à un pays, une région ou une organisation. Dans cette logique, les extensions et les contraintes font pleinement partie du standard.

Dans cet article, nous allons voir comment cela se concrétise dans notre scénario de demande de deuxième avis.

Reprenons, de façon simplifiée, ce qui est arrivé à Mara.

Acteurs

• La patiente (Mara) et son  DEP  (Dossier Électronique du Patient)
• Le médecin prescripteur (Dr Meier) et son logiciel de gestion de cabinet
• Un cabinet de radiologie et son système d’information radiologique

Déroulement

• Le Dr Meier crée une demande pour un deuxième avis et l’envoie au cabinet de radiologie.
• Le cabinet de radiologie récupère la demande ainsi que les informations cliniques associées.
• Le radiologue examine les résultats existants, rédige un rapport et dépose les résultats dans le DEP.
• Le système du Dr Meier reçoit automatiquement les résultats.

Dans cet article, nous nous concentrons sur la première étape : comment le système primaire du Dr Meier crée une demande de deuxième avis de manière à ce que d’autres systèmes, comme celui du cabinet de radiologie, puissent la comprendre et la traiter de façon optimale.

La première étape technique consiste à représenter la demande ainsi que les informations patient nécessaires à l’obtention d’un deuxième avis. Autrement dit : comment le Dr Meier indique-t-il, de manière lisible par une machine, au cabinet de radiologie qu’il doit fournir un deuxième avis sur une radiographie existante ?

Nous partons de la ressource  ServiceRequest, qui formalise la demande de radiologie elle-même. Au passage, nous aborderons des notions fondamentales de FHIR telles que les ressources, les références, les profils et les guides d’implémentation. Nous verrons ensuite comment  CH RAD-Order  et  SDC  (Structured Data Capture) viennent superposer à cela un questionnaire structuré afin de capturer l’ensemble des détails de la demande.

Dans notre cas :

« Veuillez fournir un  deuxième avis  sur la radiographie existante de la jambe droite de Mara. La question clinique est la suivante : pouvez-vous confirmer une fracture de fatigue du tibia droit ? »

Cette demande est représentée sous forme de  ressource FHIR. Les ressources sont le cœur de FHIR : Fast Healthcare Interoperability Resources. Elles constituent des « briques » d’information clinique structurées, lisibles par une machine et bien documentées. Il s’agit ici des informations nécessaires pour émettre une demande de radiologie (radiographie, CT, IRM, etc.) ou solliciter un deuxième avis.

Une instance simplifiée de ServiceRequest pour le deuxième avis de Mara sur une radiographie existante pourrait ressembler à ceci :

Même sans connaître FHIR en détail, on peut déjà repérer quelques informations clés :

• Le champ  category  indique qu’il s’agit d’une demande de  deuxième avis  (SecondOpinion).
• Les champs  subject  et  requester  font référence à Mara et au Dr Meier.
• Le champ  supportingInfo  pointe vers des données existantes à prendre en compte : le formulaire de demande rempli (QuestionnaireResponse), l’ImagingStudy  existant (la radiographie) et le  DiagnosticReport précédent.

Comment le logiciel sait-il comment produire ce JSON ? C’est là qu’interviennent les  profils  et les  Implementation Guides

On peut voir un  profil  comme un modèle « lisible par une machine » pour un type de ressource FHIR donné. Il précise quels éléments sont obligatoires, optionnels ou interdits, quels jeux de valeurs (value sets) et/ou systèmes de codage doivent être utilisés (nous y reviendrons), quelles extensions sont autorisées, etc.

Si l’on revient à notre JSON, on voit qu’il indique suivre (ou, dans le jargon, « être conforme à ») le profil dont la définition est disponible ici.

Mais un profil, pris isolément, n’est pas très utile : le plus souvent, il fait partie d’un  Implementation Guide (IG). Dans notre cas, l’Implementation Guide s’appelle  CH RAD-Order. Il décrit comment définir une manière commune et interopérable de représenter des demandes de radiologie (rappel : une demande de deuxième avis en imagerie est aussi une demande de radiologie) dans le système de santé suisse.

Et si l’on regarde de plus près,  CH RAD-Order  ne sort pas de nulle part : il s’appuie sur un autre guide suisse :

• Le guide d’implémentation  Order & Referral by Form (CH ORF)  définit comment des formulaires pour des eReferrals et des demandes d’information (par exemple des résultats d’imagerie diagnostique, des résultats de laboratoire, des rapports de sortie, etc.) peuvent être définis, déployés et utilisés.
• CH ORF  définit un profil  CH ORF ServiceRequest.
• CH RAD-Order  vient ensuite  affiner  ce profil CH ORF ServiceRequest pour répondre à des besoins spécifiques à la radiologie (p. ex. région d’imagerie, site anatomique, modalité d’imagerie demandée).
• Cette approche par couches ressemble beaucoup au développement logiciel classique :

  • la plupart des projets s’appuient sur des bibliothèques et des frameworks existants plutôt que de tout réinventer ;
  • de la même manière,  CH RAD-Order  s’appuie sur  CH ORF, qui lui-même s’appuie sur la définition internationale de la ressource FHIR  ServiceRequest.

Jusqu’ici, nous avons considéré la  demande comme une ressource clinique  : un  ServiceRequest  qui dit, en substance :

« Veuillez fournir un deuxième avis sur cette radiographie existante pour Mara, pour cette raison. »

C’est ce que les systèmes en aval utilisent pour gérer le flux de travail, la planification et le reporting.

Mais cela soulève une question très concrète : comment le Dr Meier saisit-il réellement toutes les informations qui se retrouvent ensuite dans le  ServiceRequest  ?

Une option consisterait à coder en dur un formulaire de demande de radiologie spécifique dans chaque logiciel de cabinet et dans chaque système d’information radiologique. Avec m systèmes primaires différents et n formulaires différents, on aboutit à m × n implémentations distinctes. Les lecteurs ayant un profil de développeur auront peut-être une impression de déjà-vu : on retrouve un schéma similaire dans les éditeurs de code, avec m éditeurs qui devraient idéalement supporter n langages de programmation. La solution, dans ce cas, consiste à  standardiser le protocole d’échange  entre l’éditeur et le serveur de langage, et à l’implémenter une fois de chaque côté. En développement logiciel, on a vu cette approche avec le  Language Server Protocol  pour les éditeurs de code (c’est ce qui permet à des éditeurs spécialisés de proposer « gratuitement » complétion intelligente, navigation vers la définition, etc.), ou encore avec le  Model Context Protocol  pour les outils d’IA (là aussi, différents outils peuvent intégrer plus facilement des IA de différents fournisseurs).

FHIR propose exactement ce type de protocole commun pour les  formulaires, via le guide d’implémentation  Structured Data Capture (SDC)  :

• Un  Questionnaire  décrit un formulaire : quelles questions sont posées, quels types de réponses sont autorisés, comment les sections sont structurées, etc.
• Un  QuestionnaireResponse  contient un jeu de réponses concret, pour un cas donné.

CH RAD-Order  s’appuie sur ces mécanismes pour décrire le formulaire de demande de radiologie lui-même (QuestionnaireRadiologyOrder), ainsi que les réponses remplies et soumises par le Dr Meier. L’intérêt, pour les éditeurs de systèmes primaires, est qu’ils n’ont besoin que d’un  moteur générique  capable d’afficher un Questionnaire et d’envoyer les réponses : le scénario du deuxième avis devient alors « simplement » un questionnaire de plus, régi par les mêmes règles.

Pour résumer :

• Le formulaire que le Dr Meier voit à l’écran est décrit par le  QuestionnaireRadiologyOrder  de CH RAD-Order : une définition structurée de toutes les questions qui composent un formulaire de demande de radiologie (question clinique, région à imager, points d’attention, etc.).
• Lorsque le Dr Meier remplit ce formulaire pour Mara, le résultat est un  QuestionnaireResponse  : un ensemble de réponses pour ce cas précis, qui sera envoyé au cabinet de radiologie.

Un  QuestionnaireResponse  pour la demande de deuxième avis pourrait ressembler à ceci (tronqué pour les besoins de cet article) :

Ici, je voudrais mettre en avant quelques points :

• requestedService.service  indique qu’il s’agit d’une demande de  deuxième avis. Le questionnaire est multi-usage : avec un code différent, il pourrait servir à d’autres prestations (par ex. une « nouvelle demande d’imagerie »). À cet égard, ce type est encodé via une ressource  ValueSet. On peut les voir comme des « enums », mais en bien plus puissant, comme on le verra au point suivant.
• Vous remarquerez peut-être que, dans  requestedService.service, un  system  est défini via une URL. Cela indique quelles  données de référence  utiliser. Elles peuvent être définies à l’intérieur d’un IG (comme pour  requestedService), mais aussi à l’extérieur, par exemple pour  imagingRegion. C’est particulièrement utile lorsqu’on souhaite s’appuyer sur un système ontologique externe (comme  LOINC,  SNOMED CT  et, dans notre cas,  RadLex). Associer un concept ou un objet à un identifiant unique est un besoin très courant en santé. Cela présente plusieurs avantages, notamment :

  • réduit l’ambiguïté, car une « fièvre » peut renvoyer à des notions différentes (symptôme général, diagnostic, maladie spécifique, etc.) ;
  • favorise l’interopérabilité sémantique : des systèmes différents peuvent interpréter les données de la même manière et permettre des traitements automatisés ;
  • facilite le multilinguisme et, plus largement, le traitement automatique (y compris en machine learning / IA).
• Et comme cette idée est centrale, FHIR y consacre un module entier :  Terminology.

• Les formulaires sont définis une seule fois  sous forme de ressources  Questionnaire  dans un guide d’implémentation (ici : CH RAD-Order, basé sur CH ORF et SDC).
• Les systèmes primaires  (logiciels de cabinet) implémentent un moteur générique de  Questionnaire. Ce moteur affiche les formulaires, collecte les réponses et les envoie sous forme de  QuestionnaireResponse. La forme que prend l’implémentation (formulaire web, application mobile, assistant IA lisant les questions et recueillant les réponses du radiologue…) n’a pas d’importance tant qu’un  QuestionnaireResponse  est généré.
• Une demande clinique formelle  est envoyée en parallèle des réponses au questionnaire. Dans cet exemple, on peut supposer que la ressource  ServiceRequest  est créée à partir du  QuestionnaireResponse.
• Des profils et des systèmes de codage  convenus au niveau national garantissent que les systèmes de différents éditeurs interprètent les données de la même manière.

Dans cet article, nous nous sommes concentrés sur la première étape du parcours radiologique de Mara : la création d’une demande clinique à destination d’un cabinet de radiologie. Qu’avons-nous appris ?

• Les concepts fondamentaux de FHIR : ressources, guides d’implémentation, profils, et leurs relations
• Comment modéliser une demande de deuxième avis en radiologie avec FHIR
• Comment CH RAD-Order s’appuie sur CH ORF et sur la ressource de base  ServiceRequest
• Comment SDC,  Questionnaire  et  QuestionnaireResponse  offrent une approche réutilisable pour implémenter des formulaires