R6: Was passiert mit einer Referenz, wenn ihr Ziel in einen Inkubator wandert

Das Problem

R6 verschiebt etwa 27 unreife Ressourcen aus der Kernspezifikation in separate Inkubator-IGs, damit das, was im Kern verbleibt, als normativ eingefroren werden kann. Ressourcen verweisen jedoch aufeinander. Wenn eine von ihnen den Kern verlässt, wird jedes Element, das auf sie verwiesen hat, zu einem Pfeil ohne Ziel – und diese Elemente befinden sich in Ressourcen, die verbleiben und die bald dauerhaft festgeschrieben werden.

Ein Beispiel: StructureMap und die FHIR Mapping Language wurden in einen Inkubator verschoben. Drei Ressourcen, die im Kern verbleiben – ActivityDefinition, PlanDefinition und RequestOrchestration – deklarieren jeweils ein Element als canonical(StructureMap): Dieses Feld darf auf eine StructureMap verweisen und auf nichts anderes. Der einzige Typ, auf den es zeigen darf, ist weggefallen. Security hat dasselbe Problem: Permission wurde ausgelagert, Consent blieb und verweist nach wie vor darauf.

Was kommt also in dieses Element? Man kann es nicht so lassen – es benennt einen Typ, den die Spezifikation nicht mehr definiert. Und was auch immer man wählt, wird dauerhaft, sobald R6 normativ wird. Das ist die Frage, die Brian Postlethwaite an das FMG gestellt hat: Einfach die Typbeschränkung entfernen oder die Property vollständig streichen?

Zwei einfache Fälle, ein schwieriger

Gino Canessa legte die Regel dar. Bei zwei von drei Fällen ist das Vorgehen mechanisch:

• Verweist bereits auf alle Typen – keine Änderung erforderlich.
• Verweist auf Kerntypen und verschobene Typen – die verschobenen aus der Zielliste entfernen.
• Verweist ausschließlich auf verschobene Typen – keine gute Antwort vorhanden.

Der dritte Fall ist der Kern der Diskussion. Entfernt man das letzte Ziel, wird die Referenz auf „any" ausgeweitet – und in einer normativen Ressource bedeutet „any" für immer.

Vier schlechte Optionen

Ausweitung auf Any. Das Ergebnis, wenn man einfach den Zieltyp löscht. Security geht diesen Weg für Permission in diesem Ballot und hofft auf eine klarere Lösung danach.

„Ich glaube, die einzige Möglichkeit ist, es auf ‚any' anzuheben. Das Unglückliche daran ist, dass es dann für immer ‚any' bleibt." — Lloyd McKenzie

Verweis auf Basic. Lloyds Alternative: canonical(Basic) hält das Element eng gefasst, da Basic voraussichtlich von niemandem genutzt wird – außer um zusätzliche Ressourcen zugänglich zu machen. Ginos Einwand: In R6 wird Basic für zusätzliche Ressourcen gar nicht verwendet, da diese direkt genutzt werden können. Lloyds Gegenargument: Selbst dann ist es harmlos und weit weniger anfällig für Missbrauch als Any.

Das Element löschen. Orders & Observations hat dies bereits überall dort getan, wo das einzige unterstützte Ziel eine zusätzliche Ressource war, und Grahame Grieve stellt dies als feststehende Leitlinie dar.

„Wenn ein Element nur auf eine Ressource verweist, die in den Inkubator verschoben wurde, muss das Element entfernt werden." — Grahame Grieve

In eine Extension umwandeln. Das Element aus dem Kern entfernen und die Extension in demselben Inkubator-IG wie das Ziel definieren – was, wie Gino anmerkt, den Aufwand von Extension gegenüber Element nahezu ausgleicht.

Der Konsens ist ein Ermessensentscheid, keine Regel. Wenn die Beziehung wirklich benötigt wird und das Ziel lediglich noch nicht normativ ist, sollte das Element erhalten bleiben: Es macht keinen Sinn, Extensions und Workarounds in eine normative Ressource zu zwingen, nur weil das Ziel noch nicht ganz bereit ist. Wenn Existenz und Design des Ziels noch zu früh sind, ist eine Extension das ehrliche Signal.

Wenn Sie migrieren

1. Weggefallene Elemente. Etwas, das Sie in R4/R5 verwenden, ist in R6 möglicherweise einfach nicht mehr vorhanden. Prüfen Sie das entsprechende Inkubator-IG auf eine Extension mit derselben Bedeutung, bevor Sie eine eigene erfinden.
2. Elemente, die zu Any wurden. Die Typsicherheit, auf die Sie sich verlassen haben, ist in der Basisspezifikation nicht mehr vorhanden. Wenn Sie sie zurückbrauchen, legen Sie sie in Ihrem eigenen Profil fest – im Gegensatz zur Basisspezifikation können Sie Ihres später noch ändern.
3. Verknüpfungen, nicht nur Daten. Seiten, die jetzt auf einen Inkubator verlinken, tragen ebenfalls Ballot-Change-Markierungen – in der Praxis betrifft das nur die rXdiffs-Seiten und die Dokumentations-Links-Seite.

Fazit

Das Ziel hinter alldem ist ein solider R6-Kern: Einfrieren, was ausgereift ist, den Rest auslagern und Implementierern ein Fundament geben, das nicht unter ihnen wegbricht. Das ist es wert – aber die Rechnung wird an den Rändern fällig, in Entscheidungen, die alles andere als mechanisch sind.

Beachten Sie, dass keine der vier Optionen kostenfrei ist. Ein Element zu löschen ist eine Breaking Change: Wer dieses Feld in R5 befüllt hat, hat in R6 keinen Ort mehr, die Daten unterzubringen, und die Instanzen werden ungültig – genau deshalb warnte Lloyd, dass Implementierende dadurch in benutzerdefinierte Extensions gedrängt werden. Eine Ausweitung auf Any bricht heute nichts, aber sobald es in einer normativen Ressource ausgeliefert wird, ist die Einschränkung für immer verschwunden und niemand kann sie später enger fassen. Die Wahl liegt also zwischen einem Bruch, der jetzt sichtbar ist, und einem Verlust, der nie rückgängig gemacht werden kann – und sie wird Element für Element getroffen, wenige Wochen vor einem Ballot.

Quelle: chat.fhir.org — #fmg > R6 Review. Siehe auch: R6: Subtraktion durch zusätzliche Ressourcen und FHIR R6-Erscheinungsdatum & Neuerungen.