R6 : La soustraction par ressources supplémentaires

Le problème que R6 devait résoudre

R6 est la première version entièrement normative de FHIR. Une fois publiée, aucun changement incompatible n'est autorisé. Pourtant, de nombreuses ressources FHIR sont encore au niveau FMM (FHIR Maturity Model) 0 à 2 — elles ne sont pas suffisamment stables pour être figées. Les figer de manière normative bloquerait soit leur évolution, soit forcerait des changements incompatibles ultérieurs, ce qui va à l'encontre de l'objectif de la normalisation.

La solution : déplacer les ressources immatures hors du noyau vers des guides d'implémentation distincts appelés IGs incubateurs. Ces ressources sont appelées ressources supplémentaires. Elles fonctionnent comme des ressources FHIR de première classe — même API REST, même recherche, même profilage — mais évoluent selon leur propre cycle de publication, indépendamment de la spécification de base. Par exemple, ViewDefinition de SQL on FHIR est une ressource supplémentaire dans R6 — elle est publiée dans son propre IG, et non dans la spécification de base.

« Les retours du marché sont très clairs : les modifications apportées aux ressources FHIR deviennent très coûteuses, et l'une des rares incitations pour le marché à passer à R6 est la stabilité. » — Grahame Grieve

Comment elles fonctionnent

Une ressource supplémentaire est définie par une StructureDefinition publiée dans un IG incubateur. Elle doit avoir kind: resource, derivation: specialization, être basée sur Resource ou DomainResource, et posséder une URL canonique en dehors de http://hl7.org/fhir.

En JSON, les instances de ressources supplémentaires comportent une propriété supplémentaire resourceDefinition — une référence canonique versionnée à leur StructureDefinition :

{
  "resourceType": "ViewDefinition",
  "resourceDefinition": "http://hl7.org/fhir/uv/sql-on-fhir/StructureDefinition/ViewDefinition|2.0.0-pre",
  "id": "example-1"
}

Cette propriété est absente pour les ressources du noyau. Elle indique au serveur quelle définition utiliser pour la validation.

Dans les CapabilityStatements, les ressources supplémentaires apparaissent dans rest.resource comme n'importe quelle autre ressource, mais avec un élément definition pointant vers la StructureDefinition spécifique à la version.

Toutes les ressources supplémentaires doivent être enregistrées auprès de HL7 et approuvées. Les propositions transitent par le canal Zulip #Additional-Resource-Proposals.

Ressources supplémentaires vs ressources personnalisées

Les ressources supplémentaires et les ressources personnalisées utilisent le même mécanisme de StructureDefinition — les deux définissent kind: resource avec derivation: specialization et une URL canonique en dehors du noyau. La différence tient à la gouvernance, non à la technologie.

Une ressource supplémentaire est enregistrée auprès de HL7, reçoit un nom officiel, est soumise à une révision de qualité et publiée dans un IG incubateur. Elle est sur la voie d'intégration au noyau. Les serveurs qui déclarent leur conformité à un IG incubateur sont tenus de la prendre en charge. Lorsqu'elle arrive à maturité, elle est migrée dans la spécification de base.

Une ressource personnalisée est définie par n'importe qui — un fournisseur, un projet, un programme national. Elle n'est pas enregistrée auprès de HL7, pas révisée et ne suit aucune voie vers le noyau. Elle fonctionne techniquement (même API REST, même validation), mais n'offre aucune garantie d'interopérabilité au-delà des parties qui ont convenu de l'utiliser.

La conséquence pratique : si vous avez besoin d'un type de ressource qui n'existe pas dans le noyau, vérifiez d'abord les IGs incubateurs. Quelqu'un l'aura peut-être déjà définie comme ressource supplémentaire. Dans le cas contraire, vous pouvez définir une ressource personnalisée — mais sachez que vous êtes seul responsable de l'interopérabilité.

Ce qui a quitté le noyau

Le FMG (FHIR Management Group) a évalué chaque ressource à l'aide des niveaux FMM, des données d'utilisation de Simplifier, de l'historique des commits git, de l'activité Jira et du nombre de références aux exemples et aux extensions. Résultat : environ 27 ressources ont été déplacées vers des IGs incubateurs.

ConditionDefinition (Patient Care) et les ressources de définition des médicaments (MedicinalProductDefinition, PackagedProductDefinition, Ingredient, etc.) sont également en cours d'examen par les comités.

Certaines ressources ont été entièrement supprimées — non pas déplacées vers des ressources supplémentaires, mais disparues : SubstanceNucleicAcid, SubstancePolymer, SubstanceProtein, SubstanceReferenceInformation, SubstanceSourceMaterial. Leur contenu a été absorbé dans d'autres ressources par le groupe de travail Biomedical Research and Regulation (BRR).

Problèmes ouverts

Gestion des versions. Les ressources supplémentaires évoluent selon leur propre calendrier. Un serveur qui prend en charge à la fois le noyau R6 et trois IGs incubateurs doit gérer plusieurs matrices de versions. Cela accroît la complexité des tests de conformité et de la validation.

Outillage. SUSHI ne gère pas bien les ressources supplémentaires — il répertorie incorrectement les ensembles de paramètres de recherche et exige des instantanés que les StructureDefinitions des incubateurs n'incluent pas. Des contournements existent, mais ils sont fragiles. IG Publisher fonctionne si vous suivez le modèle du fhir-testing-ig.

Lacunes temporaires. Certaines ressources déplacées hors du noyau sont temporairement indisponibles pendant que les groupes de travail mettent en place leurs environnements CI de l'IG incubateur. Au début de 2026, tous les IGs ne sont pas encore opérationnels.

Consent vs. Permission. Permission a été déplacée vers les ressources supplémentaires, tandis que Consent est restée dans le noyau. Dans les contextes européens où le RGPD définit six bases juridiques pour le traitement des données (et pas seulement le consentement), les implémenteurs pourraient être tentés d'étirer Consent pour couvrir ce que Permission devrait gérer — parce que Permission est moins visible en tant que ressource « supplémentaire ».

Ce que cela signifie pour les implémenteurs

Si vous utilisez l'une des ressources concernées, voici ce qui change dans R6 :

1. Elles disparaissent de la spécification de base. Vous devez les trouver dans leur IG incubateur.
2. Les instances JSON ont besoin de resourceDefinition. Ajoutez la référence canonique versionnée en parallèle de resourceType.
3. Les CapabilityStatements ont besoin de definition. Pointez vers la StructureDefinition spécifique à la version.
4. Les paramètres de recherche suivent la ressource. Les URL canoniques restent les mêmes ; les versions peuvent changer.
5. Les références provenant des ressources du noyau deviennent des extensions. Coverage référençait InsurancePlan, DeviceDefinition référençait ChargeItemDefinition — ce sont désormais des extensions dans les IGs incubateurs.

Ce qui ne change pas : les ressources supplémentaires sont toujours des ressources FHIR. Même API REST. Même recherche. Même profilage. Le mécanisme est administratif, non technique — les ressources fonctionnent de la même façon, elles résident simplement dans un autre paquet. Et la voie de retour vers le noyau existe — lorsqu'une ressource arrive à maturité, son groupe de travail peut demander l'approbation du FMG pour la réintégrer dans le prochain cycle de scrutin.

Pour Aidbox, il s'agit d'un changement mineur. Nous prenons en charge les ressources personnalisées depuis le premier jour — les ressources supplémentaires utilisent le même mécanisme. Le seul ajustement nécessaire est la validation de la propriété resourceDefinition.

Références

Spécification :

• Resource — Additional Resources
• JSON — resourceDefinition
• StructureDefinition — Notes

Discussions communautaires (chat.fhir.org) :

• Additional Resources — migration process
• Assessment of Resources for removal from R6
• Permission as additional resource — GDPR concerns

HL7 :

• Exemple de gabarit d'IG incubateur

Voir aussi : FHIR R4 vs FHIR R5.