R6: Subtraktion durch Additional Resources

Das Problem, das R6 lösen musste

R6 ist das erste vollständig normative FHIR-Release. Nach der Veröffentlichung sind keine Breaking Changes mehr erlaubt. Viele FHIR-Ressourcen befinden sich jedoch noch auf FMM-Level (FHIR Maturity Model) 0–2 – sie sind nicht stabil genug, um eingefroren zu werden. Sie normativ einzufrieren würde entweder ihre Weiterentwicklung blockieren oder später Breaking Changes erzwingen, was den Sinn der Normativität unterläuft.

Die Lösung: Unreife Ressourcen werden aus dem Kern in separate Implementation Guides, sogenannte Incubator-IGs, ausgelagert. Diese Ressourcen werden als Additional Resources bezeichnet. Sie funktionieren wie erstklassige FHIR-Ressourcen – gleiche REST-API, gleiche Suche, gleiches Profiling – entwickeln sich aber in ihrem eigenen Release-Zyklus weiter, unabhängig von der Kernspezifikation. So ist beispielsweise ViewDefinition aus SQL on FHIR eine Additional Resource in R6 – sie wird in einem eigenen IG ausgeliefert, nicht in der Kernspezifikation.

„Unser Marktfeedback ist sehr eindeutig: Weitere Änderungen an den FHIR-Ressourcen werden sehr teuer, und einer der wenigen Anreize für den Markt, auf R6 umzusteigen, ist Stabilität." — Grahame Grieve

Wie sie funktionieren

Eine Additional Resource wird durch eine StructureDefinition definiert, die in einem Incubator-IG veröffentlicht wird. Sie muss kind: resource, derivation: specialization aufweisen, auf Resource oder DomainResource basieren und eine kanonische URL außerhalb von http://hl7.org/fhir besitzen.

In JSON tragen Instanzen von Additional Resources eine zusätzliche Eigenschaft resourceDefinition – eine versionierte kanonische Referenz auf ihre StructureDefinition:

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

Diese Eigenschaft fehlt bei Kernressourcen. Sie teilt dem Server mit, anhand welcher Definition validiert werden soll.

In CapabilityStatements erscheinen Additional Resources in rest.resource wie jede andere Ressource, jedoch mit einem definition-Element, das auf die versionsspezifische StructureDefinition verweist.

Alle Additional Resources müssen bei HL7 registriert und genehmigt werden. Vorschläge werden über den Zulip-Kanal #Additional-Resource-Proposals eingereicht.

Additional Resources vs. Custom Resources

Additional Resources und Custom Resources verwenden denselben StructureDefinition-Mechanismus – beide definieren kind: resource mit derivation: specialization und einer kanonischen URL außerhalb des Kerns. Der Unterschied liegt in der Governance, nicht in der Technologie.

Eine Additional Resource ist bei HL7 registriert, erhält einen offiziellen Namen, wird auf Qualität geprüft und in einem Incubator-IG veröffentlicht. Sie befindet sich auf dem Weg in den Kern. Server, die die Konformität mit einem Incubator-IG beanspruchen, sind verpflichtet, sie zu unterstützen. Wenn sie ausreift, wird sie in die Kernspezifikation überführt.

Eine Custom Resource wird von beliebigen Parteien definiert – einem Anbieter, einem Projekt, einem nationalen Programm. Sie ist nicht bei HL7 registriert, wird nicht geprüft und befindet sich auf keinem Weg in den Kern. Sie funktioniert technisch (gleiche REST-API, gleiche Validierung), bietet aber keine Interoperabilitätsgarantie über die Parteien hinaus, die sich auf ihre Nutzung geeinigt haben.

Die praktische Konsequenz: Wenn Sie einen Ressourcentyp benötigen, der im Kern nicht existiert, prüfen Sie zuerst die Incubator-IGs. Möglicherweise hat jemand ihn bereits als Additional Resource definiert. Falls nicht, können Sie eine Custom Resource definieren – wissen Sie jedoch, dass Sie für die Interoperabilität auf sich allein gestellt sind.

Was aus dem Kern ausgelagert wurde

Die FMG (FHIR Management Group) hat jede Ressource anhand von FMM-Levels, Simplifier-Nutzungsdaten, Git-Commit-Historie, Jira-Aktivität sowie der Anzahl von Beispiel- und Extension-Referenzen bewertet. Das Ergebnis: ~27 Ressourcen wurden in Incubator-IGs verschoben.

ConditionDefinition (Patient Care) sowie Ressourcen zur Medikamentendefinition (MedicinalProductDefinition, PackagedProductDefinition, Ingredient usw.) befinden sich ebenfalls in der Ausschussprüfung.

Einige Ressourcen wurden vollständig entfernt – nicht in Additional Resources überführt, sondern ersatzlos gestrichen: SubstanceNucleicAcid, SubstancePolymer, SubstanceProtein, SubstanceReferenceInformation, SubstanceSourceMaterial. Ihr Inhalt wurde durch die Arbeitsgruppe Biomedical Research and Regulation (BRR) in andere Ressourcen integriert.

Offene Probleme

Versionsverwaltung. Additional Resources entwickeln sich nach eigenem Zeitplan weiter. Ein Server, der sowohl den Kern R6 als auch drei Incubator-IGs unterstützt, muss mehrere Versionsmatrizen verwalten. Das erhöht die Komplexität bei Konformitätstests und der Validierung.

Tooling. SUSHI unterstützt Additional Resources nur unzureichend – es listet Suchparameter-Bundles fehlerhaft auf und erfordert Snapshots, die Incubator-StructureDefinitions nicht enthalten. Workarounds existieren, sind aber fragil. Der IG Publisher funktioniert, wenn Sie dem Muster aus fhir-testing-ig folgen.

Temporäre Lücken. Einige Ressourcen, die aus dem Kern ausgelagert wurden, sind vorübergehend nicht verfügbar, während Arbeitsgruppen ihre Incubator-IG-CI-Builds einrichten. Stand Anfang 2026 sind noch nicht alle IGs in Betrieb.

Consent vs. Permission. Permission wurde in Additional Resources verschoben, Consent verblieb im Kern. In EU-Kontexten, in denen die DSGVO sechs Rechtsgrundlagen für die Datenverarbeitung definiert (nicht nur Einwilligung), könnten Implementierende Consent so ausdehnen, dass er abdeckt, was eigentlich Permission behandeln sollte – weil Permission als „Additional Resource" weniger sichtbar ist.

Was das für Implementierende bedeutet

Wenn Sie eine der betroffenen Ressourcen verwenden, ändert sich in R6 Folgendes:

1. Sie verschwinden aus der Kernspezifikation. Sie müssen sie in ihrem Incubator-IG suchen.
2. JSON-Instanzen benötigen resourceDefinition. Fügen Sie die versionierte kanonische Referenz neben resourceType hinzu.
3. CapabilityStatements benötigen definition. Verweisen Sie auf die versionsspezifische StructureDefinition.
4. Suchparameter werden mit der Ressource verschoben. Kanonische URLs bleiben gleich; Versionen können sich ändern.
5. Referenzen aus Kernressourcen werden zu Extensions. Coverage referenzierte InsurancePlan, DeviceDefinition referenzierte ChargeItemDefinition – diese sind nun Extensions in Incubator-IGs.

Was sich nicht ändert: Additional Resources sind weiterhin FHIR-Ressourcen. Gleiche REST-API. Gleiche Suche. Gleiches Profiling. Der Mechanismus ist administrativer, nicht technischer Natur – die Ressourcen funktionieren auf dieselbe Weise, sie befinden sich lediglich in einem anderen Paket. Und der Weg zurück in den Kern ist vorhanden – wenn eine Ressource ausreift, kann ihre Arbeitsgruppe beim FMG die Überführung in den nächsten Ballot-Zyklus beantragen.

Für Aidbox ist dies eine geringfügige Änderung. Wir unterstützen Custom Resources von Anfang an – Additional Resources verwenden denselben Mechanismus. Die einzige notwendige Anpassung ist die Validierung der Eigenschaft resourceDefinition.

Referenzen

Spezifikation:

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

Community-Diskussionen (chat.fhir.org):

• Additional Resources — Migrationsprozess
• Bewertung von Ressourcen zur Entfernung aus R6
• Permission als Additional Resource — DSGVO-Bedenken

HL7:

• Beispiel-Incubator-IG-Vorlage

Siehe auch: FHIR R4 vs. FHIR R5.