Le problème
R6 déplace environ 27 ressources immatures hors de la spécification principale vers des IGs incubateurs distincts, afin que ce qui reste dans le noyau puisse être figé comme normatif. Mais les ressources se pointent mutuellement. Quand l'une d'elles part, chaque élément qui la référençait devient une flèche sans destination — et ces éléments se trouvent dans des ressources qui restent, et qui sont sur le point d'être verrouillées pour toujours.
Un exemple. StructureMap et le langage de correspondance FHIR ont été déplacés vers un incubateur. Trois ressources qui restent — ActivityDefinition, PlanDefinition et RequestOrchestration — déclarent chacune un élément de type canonical(StructureMap) : ce champ peut pointer vers une StructureMap, et rien d'autre. L'unique type vers lequel il est autorisé à pointer a disparu. La sécurité présente le même problème : Permission a été déplacé, Consent est resté et y fait toujours référence.
Que mettre alors dans cet élément ? On ne peut pas le laisser tel quel — il nomme un type que la spécification ne définit plus. Et quel que soit le choix retenu, il deviendra permanent le jour où R6 passera en normatif. C'est la question que Brian Postlethwaite a soumise au FMG : supprimer simplement la contrainte de type, ou supprimer carrément la propriété ?
Deux cas simples, un cas difficile
Gino Canessa a exposé la règle. Pour deux cas sur trois, la réponse est mécanique :
- Cible déjà tous les types — aucun changement nécessaire.
- Cible des types du noyau et des types déplacés — supprimer les types déplacés de la liste des cibles.
- Cible uniquement des types déplacés — pas de bonne réponse.
C'est le troisième cas qui concentre le débat. Supprimer la dernière cible entraîne la promotion de la référence vers « any » — et dans une ressource normative, « any » c'est pour toujours.
Quatre mauvaises options
Élargir à Any. C'est ce qu'on obtient par défaut en supprimant simplement le type cible. La sécurité emprunte cette voie pour Permission lors de ce scrutin, dans l'espoir d'une solution plus claire par la suite.
« Je pense que le seul choix est de l'élever à "any". Ce qui est malheureux, c'est que ça le rendra "any" pour toujours. » — Lloyd McKenzie
Pointer vers Basic. L'alternative de Lloyd : canonical(Basic) maintient l'élément étroit, puisque Basic a peu de chances d'être utilisé par quiconque, sauf pour exposer des ressources supplémentaires. L'objection de Gino est que dans R6, Basic ne sera pas utilisé pour des ressources additionnelles, car celles-ci pourront être utilisées directement. La contre-réponse de Lloyd : même ainsi, c'est anodin et bien moins susceptible d'être détourné que Any.
Supprimer l'élément. Orders & Observations l'a déjà fait partout où la seule cible supportée était une ressource additionnelle, et Grahame Grieve l'énonce comme une orientation établie.
« Si un élément ne fait référence qu'à une ressource qui a été déplacée vers l'incubation, alors l'élément doit être supprimé. » — Grahame Grieve
En faire une extension. Retirer l'élément du noyau et définir l'extension dans le même IG incubateur que la cible — ce qui, comme le note Gino, rend le fardeau d'une extension par rapport à un élément pratiquement équivalent.
Le consensus relève du jugement, pas d'une règle. Si la relation est véritablement nécessaire et que la cible n'est simplement pas encore normative, conserver l'élément : il ne sert à rien de forcer des extensions et des contournements dans une ressource normative simplement parce que la cible n'en est pas encore là. Si l'existence et la conception de la cible sont encore trop précoces, une extension est le signal honnête à envoyer.
Si vous effectuez une migration
- Éléments qui ont disparu. Quelque chose que vous utilisez en R4/R5 peut simplement ne plus figurer dans R6. Vérifiez l'IG incubateur pertinent pour trouver une extension de même signification avant d'en inventer une.
- Éléments devenus
Any. La sécurité de type sur laquelle vous comptiez a disparu de la spécification de base. Si vous en avez besoin, intégrez-la dans votre propre profil — contrairement à la spécification de base, vous pouvez modifier le vôtre ultérieurement. - Les liens, pas seulement les données. Les pages qui pointent désormais vers un incubateur portent aussi des marqueurs de changement de scrutin — en pratique, il s'agit uniquement des pages rXdiffs et de la page des liens de documentation.
À retenir
L'objectif derrière tout cela est d'obtenir un noyau R6 solide : figer ce qui est mature, déplacer le reste, et donner aux implémenteurs une fondation stable. Cela vaut la peine d'être fait — mais la facture arrive aux marges, dans des décisions qui n'ont rien de mécanique.
Notez qu'aucune des quatre options n'est gratuite. Supprimer un élément est un changement cassant : quiconque alimentait ce champ en R5 n'a nulle part où mettre ces données en R6, et ses instances cessent d'être valides — c'est précisément pourquoi Lloyd a averti que cela pousse les implémenteurs vers des extensions personnalisées. Élargir à Any ne casse rien aujourd'hui, mais une fois livré dans une ressource normative, la contrainte disparaît définitivement et personne ne pourra la réduire par la suite. Le choix est donc entre une rupture visible maintenant et une perte impossible à annuler — et ce choix se fait élément par élément, quelques semaines avant un scrutin.
Source : chat.fhir.org — #fmg > R6 Review. Voir aussi : R6 : Soustraction par ressources additionnelles et Date de sortie de FHIR R6 et nouveautés.
