FHIR R5 : Utiliser ou attendre ?

02/07/2023

Adopter la version R5 de FHIR® ou rester en R4. Si la question est simple, intéressante, et doit être posée, la réponse me paraît complexe, demande une analyse et de la concertation.

Contexte

Plusieurs versions HL7 FHIR, ont été publiées depuis 10 ans, les versions majeures étant :

• FHIR R3 : version 3, STU
• FHIR R4 : version 4, première version normative
• FHIR R5 : version 5, STU

Dans la terminologie HL7, STU signifie Standard for Trial Use. La qualification normative signifie que la version est considérée comme stable et utilisable en production.

Que veut dire utiliser la R4 ou la R5 ?

Les ressources FHIR sont rarement utilisées en dehors d’un contexte. Le but étant bien d’avoir un échange interopérable, l’utilisation des ressources suivent des règles définies et partagées. Ces règles sont transcrites dans des profils et des guides d’implémentation (IG).

Qui produit les profils/IG ?

Plusieurs acteurs en produisent :

• les organisations internationales : HL7, IHE. voir le registre FHIR
• les organisations nationales : Angleterre, Suisse, etc.

En France :

• interop’Santé produit des profils qui servent de référence et de socle aux autres profils.
• L’ANS produit des profils pour le cadre d’interopérabilité des systèmes d’information de santé (CI-SIS). Ils sont produits en collaboration avec interop’Santé en se basant sur ceux d’interop’Santé.
• Les éditeurs de logiciel, établissements de santé, groupements régionaux ou autres organismes sont également potentiellement producteurs de profils. Il est alors recommandé de se baser sur ceux d’interop’Santé et de l’ANS lorsqu’ils sont disponibles.

Quelle version de FHIR est utilisée en France ?

Les travaux d’interop’santé sur le profilage des ressources a commencé avec la STU3, et une adaptation a été faite pour finaliser en version 4. C’est dans cette version que les profils sont actuellement disponibles, que ce soit du côté d’interop’Santé ou de l’ANS.

Qu’apporte la version 5 ?

En premier lieu, de nombreuses ressources ont gagné en maturité. En R4, nous avions 13 ressources de maturité 5 (et N). En R5, on en dénombre 24 (avec 2 ressources de plus en statut N). Sans compter celles qui sont arrivées au niveau de maturité 4, proches d’une maturité maximale. Par ailleurs, 17 ressources ont fait leur apparition, soit près de 10% de ressources en plus.

Interop’Santé a profilé pour la France, les ressources suivantes : Appointment, Encounter, HealthcareService, Location, MedicationAdministration, Observation, Organization, Patient, Practitioner, PractitionerRole, RelatedPerson, Schedule, Slot.

Tableau de comparaison des ressources profilées par Interop’Santé :

La version R5 apporte donc des évolutions très intéressantes sur la majorité des ressources utilisées.

Quels sont les changements pour les ressources déjà profilées (fr.core)?

Sur les 13 ressources profilées par interop’Santé, examinons les changements apportés par la version R5.

Appointment

La ressource Appointment subit les changements suivants :

• ajout des attributs : class, replaces, virtualService, previousAppointment, originatingAppointment, account, cancellationDate, subject, recurrenceId, occurrenceChanged, recurrenceTemplate
• ajout de types réferencés pour participant.actor, basedOn
  
• changements de nom d’attribut : cancelationReason devient cancellationReason, reasonCode devient reason
• changements de type : le type de reason (CodeableConcept) devient CodeableReference, le type de serviceType (CodeableConcept) devient CodeableReference, le type de priority (unsignedInt) devient CodeableConcept, le type de participant.required (code) devient boolean, le type de patientInstruction (string) devient CodeableReference et sa cardinalité passe de 1 à *
• l’attribut comment change de nom et dévient note. Son type (string) devient Annotation et la cardinalité max passe de 1 à *
• l’attribut reasonReference est déplacé dans reason.reference

Encounter

La ressource Encounter subit les changements suivants :

• ajout d’attributs : subjectStatus, careTeam, virtualService, plannedStartDate, plannedEndDate, reason.use , reason.value
  

• ajout de types réferencés pour participant.actor, basedOn

• changement des valeurs du ValueSet utilisé pour la propriété status

• changements de type : le type de class (Coding) devient CodeableConcept et sa cardinalité passe de 1..1 à 0..*. Le type de serviceType (CodeableConcept) devient CodeableReference et sa cardinalité max passe de 1 à *. L’attribut diagnosis.condition change de type (Reference) et devient CodeableReference et sa cardinalité passe de 1..1 à 0..*.

• changements de nom d’attribut : la propriété individual devient participant.actor, location.physicalType devient location.form, reasonReference devient reason.reference, hospitalization devient admission

• changement de localisation d’attributs : dietPreference, specialArrangement, specialCourtesy précédemment sous hospitalization sont déplacés à la racine de Encounter. Les attributs statusHistory, classHistory sont déplacés dans une nouvelle ressource EncounterHistory. L’attribut diagnosis.rank est déplacé dans la ressource Account (-> Account.diagnosis.sequence)

• l’attribut diagnosis.condition change de type (Reference) et devient CodeableReference et change de cardinalité 1..1 à 0..*

• l’attribut diagnosis.use change de cardinalité max 1 à *

HealthcareService

La ressource HealthcareService subit les changements suivants :

• ajout des attributs : offeredIn, contact, availability
• changement de type : le type de comment (string) devient markdown
• changement de contrainte sur l’attribut communication : passage de preferred à required, et de ValueSet
• changements de localisation d’attribut : telecom est déplacé dans contact. Les attributs availableTime, notAvailable, availabilityExceptions sont déplacés dans availability

Location

La ressource Location subit les changements suivants :

• ajout des attributs : contact, characteristic, virtualService
• changement de type : le type de description (string) devient markdown
• changement de nom d’attribut : physicalType devient form
• changements de localisation de l’attribut hoursOfOperation dans availability et availabilityExceptions dans hoursOfOperation.notAvailable. L’attribut telecom est déplacé dans contact, les attributs daysOfWeek, allDay, openingTime, closingTime de hoursOfOperation sont déplacés dans hoursOfOperation.availableTime

MedicationAdministration

La ressource MedicationAdministration subit les changements suivants :

• ajout des attributs : basedOn, encounter, recorded, isSubPotent, subPotentReason, reason
• ajout d’un type référencé pour l’attribut partOf (MedicationDispense)
• changement de cardinalité : occurence devient obligatoire, category passe de 1 à *
• suppression des propriétés : instantiates, context, effective
• changements de nom d’attribut : les propriétés reasonCode, reasonReference sont remplacées par reason.reference
• changements de type d’attribut : les types de device et performer.actor (Reference) deviennent CodeableReference. L’attribut medication devient une CodeableReference

Observation

La ressource Observation subit les changements suivants :

• ajout des attributs : instantiates, triggeredBy, bodyStructure, referenceRange.normalValue
  
• ajouts de type référencé pour les attributs partOf (ajout de GenomicStudy), specimen (ajout de Group), subject (7 types ajoutés), derivedFrom (ajout de ImagingSelection, GenomicStudy et suppression de Media)
• ajout des types de valeurs (value[x]) valueAttachment et valueReference (vers MolecularSequence)
• changement de type : le type de l’attribut referenceRange.text (string) devient markdown

Organization

La ressource Organization subit les changements suivants :

• ajout des attributs : description, qualification
• changement de localisation des attributs telecom, address dans contact
• changement de type : le type de contact devient un type à part entière (ExtendedContactDetail)

Patient

La ressource Patient subit les changements suivants :

• changement de version de ValueSet pour l’attribut gender et contact.gender, et l’attribut link.type
• changement de ValueSet pour l’attribut communication.language

Practitioner

La ressource Practitioner subit les changements suivants :

• ajout des attributs : deceased, communication.preferred
• changement de contrainte sur l’attribut communication.langague qui devient requis
• ajout de la propriété Modifier sur l’attribut active
• changement de type pour l’attribut communication (CodeableConcept) qui devient BackboneElement et changement de ValueSet

PractitionerRole

La ressource PractitionerRole subit les changements suivants :

• ajout des attributs : contact, characteristic, communication, availability
• changements de localisation d’attribut : telecom est déplacé dans contact. Les attributs availableTime, notAvailable sont déplacés dans availability et availabilityExceptions dans notAvailableTime

RelatedPerson

La ressource RelatedPerson subit les changements suivants :

• changement de version de ValueSet pour l’attribut gender
• changement de contrainte sur l’attribut communication.langague qui devient requis

Schedule

La ressource Schedule subit les changements suivants :

• ajout de l’attribut name
• ajout du type référencé CareTeam pour l’attribut actor
• changements de type : l’attribut comment (string) devient markdown, l’attibut serviceType (CodeableConcept) devient CodeableReference

Slot

La ressource Slot subit les changements suivants :

• changement de type : l’attribut serviceType (CodeableConcept) devient CodeableReference
• changement de cardinalité max: l’attribut appointmentType passe de 1 à *

Quels impacts sur les ressources profilées par Interop’Santé ?

Passer les profils actuels en R5 semble :

• peu impactant pour les ressources Slot, Schedule, RelatedPerson, PractitionerRole, Practitioner, Patient, Organization, Observation, Location, HealthcareService
• plus impactant pour les ressources MedicationAdministration, Appointment et Encounter

Que veut dire implémenter 2 versions de FHIR ?

La version de FHIR est définie par le paramètre fhirVersion dans le CapabilityStatement de l’application. Le CapabilityStatement définit les capacités de l’application. Un serveur peut alors :

• supporter 1 seul CapabilityStatement et donc une seule version de FHIR ;
• supporter plusieurs CapabilityStatement et donc plusieurs versions de FHIR.

L’opération $versions permet de connaitre les versions de FHIR supportées par le serveur.

Le standard prévoit donc de supporter plusieurs versions de façon native. Cependant, il convient de noter que la version est un élément structurant du serveur. Les ressources utilisées seront cohérentes dans une version ou dans une autre.

Que les deux versions soient déployées sur le même serveur ou sur deux serveurs différents, le fonctionnement restera la même.

Avoir les ressources dans une version homogène et donc sur le même serveur permet notamment de bénéficier des fonctionnalités avancées, telles que :

• la recherche exploitant le contenu des ressources liées,
• l’utilisation d’actions comme $everything,
• ou la production des ressources de type Bundle, pour le volet Document.

Avoir des ressources dans différentes versions limite de fait l’utilisation de ces fonctionnalités. Par ailleurs, le lien entre les ressources ne peut être qu’un lien absolu. Le lien relatif ne permet pas d’adresser des ressources d’une autre version, de même pour le lien canonique.

Pour illustrer, plaçons-nous dans un cas où deux typologies de ressources sont définies :

• mise en œuvre de la version R4 via le profil IHE PDQm pour interroger les données Patient
• mise en œuvre de la version R5 pour un nouveau profil de gestion des organisations

Un patient hospitalisé en rhumatologie peut être représenté ainsi :

L’expression de la connaissance est possible et le graphe de ressources complet. Mais la recherche “patient dépendant de la rhumatologie” qui s’exprime par

GET [base]/Patient?organization.name=rhumatologie

ne renverra aucun résultat. De même créer un document contenant le patient et les informations de l’UF et du pole associé ne fonctionnera dans cette configuration.

Pour y parvenir d’autres traitement sont nécessaires, par exemple :

• côté client, en faisant plus de requêtes et en consolidant l’information ;
• côté serveur, en dupliquant les ressources (avoir une copie des ressources R5 en R4 ou inversement). Le langage de mapping FHIR et les moteurs de transformation peuvent être utilisés pour cela.

Versions en HL7 v2 et en FHIR

La cohabitation des versions de standards est une réalité dans les SI depuis longtemps. Au sein du SIH circulent des messages HL7 v2 en version 2.3, 2.5 voire 2.6. Cela ne pose pas de problème car chaque information est dupliquée dans des messages. Ceux-ci n’ont pas de lien entre eux. Un message HL7 v2 ADT en version 2.5 contiendra plus d’informations que son homologue en version 2.3. Mais leur indépendance leur permet de coexister sans problème.

FHIR introduit une nouvelle architecture. Il est également possible de penser les ressources ou des groupes de ressources de façon indépendante. Dans ce cas, plusieurs versions de FHIR ne sont pas problématiques, à l’image de la v2 d’HL7, l’information (donc les ressources) est dupliquée.

Mais profiter pleinement de la conception en graphe de FHIR, c’est utiliser les liens entre les ressources. La spécification définit alors plusieurs mécanismes pour bénéficier du graphe de connaissances. Profiter de ces opérations ou des possibilités avancées de recherche apporte alors une contrainte sur la gestion des versions des ressources.

Utiliser la R5 : bénéfices / risques

Quels sont les bénéfices et les risques de l’utilisation ou non de la R5 ?

Bénéfices à utiliser en R5

Bénéficier des retours sur la R4

La version R5 prend en compte les retours du terrain remontés durant la phase d’adoption de la version R4 (3 ans d’ajustements). De nombreuses ressources utilisées ont gagné en maturité, ce qui augmente le niveau de confiance dans leur utilisation future.

Bénéficier des nouveautés

Plusieurs ressources parmi celles utilisées dans le package de base sont plus matures en R5 qu’en R4.

Les nouveautés intégrées au standard peuvent, de fait, réduire le nombre d’extensions à créer. L’introduction d’extension rend la migration vers une nouvelle version plus coûteuse. Adopter la R5 permet d’utiliser les nouveautés qui nécessitent des extensions en R4.

Attendre la version R6, c’est se priver des avancées de la R5. C’est figer l’adoption de FHIR pendant 5 ans (3 ans R4/R5 + 2 ans R5/R6), ce qui dans ce contexte itératif et innovant semble très long.

Nombre encore limité de ressources profilées

Actuellement le nombre de ressources profilées est faible. Une adoption plus large de FHIR, conduira à profiler de nouvelles ressources en R4 pendant les prochaines années.

Coût de la migration

L’augmentation du nombre de ressources profilées dans le temps augmentera le coût de migration en restant en R4. Adopter la R5 permet de le réduire en lissant la migration dans le temps.

Participer à l’évolution du standard

Adopter la R5 permet d’implémenter les nouvelles fonctionnalités, de remonter concrètement les problèmes rencontrés et d’être actif dans l’évolution du standard. Actuellement, la France, en retard sur l’adoption de FHIR, est en position d’observateur. Adopter la version R5 permettrait de changer de rôle.

Risques à utiliser la R5

STU vs Normative

Les versions R4 et R5 contiennent des éléments normatifs et des éléments STU. Le statut Normatif de la R4 est un avantage, même si les ressources au stade normatif peuvent évoluer également. La version R4 apporte une stabilité en figeant la version des ressources utilisées.

Écosysteme

Nombre de profils publiés sont en R4. La cohabitation est possible mais peut potentiellement poser des problèmes de compatibilité. Tout dépend de la mise en œuvre. En fonction de l’architecture choisie et de la structuration du stockage des données (indépendance ou non vis-à-vis d’une version des ressources), la possibilité de traiter la R4 et la R5 est plus ou moins aisée.

Conclusion

Utiliser la version R4, et attendre la version R6 est une voie. C’est la voie de la stabilité, de la montée en compétences et en puissance des acteurs.

Intégrer dans le processus de profilage la coexistence des versions et les outils de migration automatique en adoptant la R5 en est une autre. L’adoption de la R5 sera progressive dans le temps. Des profils en R5 existent déjà. Il faut a priori s’attendre à une utilisation conjointe des deux versions dans le temps. Il en sera de même avec la R6 : adoption lente et progressive, conduisant à une cohabitation des versions.

N’est-ce pas l’opportunité de traiter dès à présent cette problématique de cohabitation ? Des mécanismes de conversion existent et pourraient être utilisés et éprouvés, rendant l’existence des différentes versions moins complexe à gérer.

La décision d'adopter la version R5 au niveau français est, à mon sens, à discuter collectivement. Le fonctionnement même d'interop’Santé repose sur le consensus pour une adhésion large. La réponse à la question initiale n'est donc pas triviale.