---
{
  "title": "R6: Subtraktion durch Additional Resources",
  "description": "R6 verschiebt unreife Ressourcen aus dem Kern in Incubator-IGs. Hier erfahren Sie, wie Additional Resources funktionieren, was sich geändert hat und was das für Implementierer bedeutet.",
  "date": "2026-03-19",
  "author": "Nikolai Ryzhikov",
  "reading-time": "5 min read",
  "tags": ["FHIR Standard", "FHIR R6", "Infrastructure"],
  "tldr": "FHIR R6 teilt den Monolithen in Kern und Incubator auf! Unreife Ressourcen werden in Incubatoren geführt – damit bleibt der Kern stabil und wird nie gebrochen (hoffe ich :). Und neue Ressourcen können sich in Incubatoren schneller weiterentwickeln!"
}
---
## Das Problem, das R6 lösen musste

[R6](/blog/getting-ready-for-fhir-r6-what-you-need-to-know) 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](/articles/sql-on-fhir-an-inside-look) 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:

```json
{
  "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](https://chat.fhir.org/#narrow/channel/491058-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.

| Incubator-IG | Status | Ressourcen |
|---|---|---|
| [fhir-testing-ig](https://github.com/HL7/fhir-testing-ig) | Verschoben | TestScript, TestPlan, TestReport |
| [admin-incubator](https://github.com/HL7/admin-incubator) | Verschoben | PersonalRelationship, EncounterHistory, InsuranceProduct |
| [oo-incubator](https://github.com/HL7/oo-incubator) | Verschoben | DeviceDispense, BiologicallyDerivedProductDispense, Transport, DeviceAssociation, DeviceUsage, FormularyItem, InventoryItem, InventoryReport |
| [data-access-policies](https://github.com/HL7/data-access-policies) | Verschoben | Permission |
| [cg-incubator](https://github.com/HL7/cg-incubator) | In Prüfung | GenomicStudy, MolecularDefinition, MolecularSequence |
| [ebm-incubator](https://github.com/HL7/ebm-incubator) | In Prüfung | Citation, Evidence, EvidenceVariable, ArtifactAssessment |

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](https://www.health-samurai.io/fhir-server) 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](https://build.fhir.org/resource.html#additional)
- [JSON — resourceDefinition](https://build.fhir.org/json.html)
- [StructureDefinition — Hinweise](https://build.fhir.org/structuredefinition.html)

**Community-Diskussionen (chat.fhir.org):**
- [Additional Resources — Migrationsprozess](https://chat.fhir.org/#narrow/stream/committers/topic/Additional%20Resources)
- [Bewertung von Ressourcen zur Entfernung aus R6](https://chat.fhir.org/#narrow/stream/fmg/topic/Assessment%20of%20Resources%20for%20removal%20from%20R6)
- [Permission als Additional Resource — DSGVO-Bedenken](https://chat.fhir.org/#narrow/stream/Security%20and%20Privacy/topic/Permission%20as%20additional%20resource)

**HL7:**
- [Beispiel-Incubator-IG-Vorlage](https://github.com/HL7/sample-incubator-ig)

Siehe auch: [FHIR R4 vs. FHIR R5](/blog/fhir-r4-vs-fhir-r5-choosing-the-right-version-for-your-implementation).