🔥 R6: Subtraction by Additional Resources

The Problem R6 Had to Solve

R6 is the first fully normative FHIR release. Once published, no breaking changes are allowed. But many FHIR resources are still at FMM 0–2 — they are not stable enough to freeze. Freezing them normatively would either block their evolution or force breaking changes later, which defeats the purpose of going normative.

The solution: move immature resources out of core into separate Implementation Guides called incubator IGs. These resources are called additional resources. They function as first-class FHIR resources — same REST API, same search, same profiling — but they evolve on their own release cycle, independent of the core spec. For example, ViewDefinition from SQL on FHIR is an additional resource in R6 — it ships in its own IG, not in the core spec.

"Our market feedback is very strong that further change to the FHIR resources is getting very expensive, and one of the few incentives for the market to move to R6 is stability." — Grahame Grieve

How They Work

An additional resource is defined by a StructureDefinition published in an incubator IG. It must have kind: resource, derivation: specialization, based on Resource or DomainResource, and a canonical URL outside http://hl7.org/fhir.

In JSON, additional resources carry an extra property resourceDefinition — a versioned canonical reference to their StructureDefinition:

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

This property is absent for core resources. It tells the server which definition to validate against.

In CapabilityStatements, additional resources appear in rest.resource like any other resource, but with a definition element pointing to the version-specific StructureDefinition.

All additional resources must be registered with HL7 and approved. Proposals go through the #Additional-Resource-Proposals Zulip channel.

Additional Resources vs. Custom Resources

Additional resources and custom resources use the same StructureDefinition mechanism — both define kind: resource with derivation: specialization and a canonical URL outside core. The difference is governance, not technology.

An additional resource is registered with HL7, assigned an official name, reviewed for quality, and published in an incubator IG. It is on a path toward core. Servers that claim conformance to an incubator IG are expected to support it. When it matures, it migrates into the core spec.

A custom resource is defined by anyone — a vendor, a project, a national program. It is not registered with HL7, not reviewed, and not on any path to core. It works technically (same REST API, same validation) but has no interoperability guarantee beyond the parties that agreed to use it.

The practical implication: if you need a resource type that doesn't exist in core, check the incubator IGs first. Someone may have already defined it as an additional resource. If not, you can define a custom resource — but know that you are on your own for interoperability.

What Moved Out of Core

FMG evaluated every resource using FMM levels, Simplifier usage data, git commit history, Jira activity, and example/extension reference counts. The result: ~27 resources moved to incubator IGs.

Incubator IG	Status	Resources
fhir-testing-ig	Moved	TestScript, TestPlan, TestReport
admin-incubator	Moved	PersonalRelationship, EncounterHistory, InsuranceProduct
oo-incubator	Moved	DeviceDispense, BiologicallyDerivedProductDispense, Transport, DeviceAssociation, DeviceUsage, FormularyItem, InventoryItem, InventoryReport
data-access-policies	Moved	Permission
cg-incubator	Under review	GenomicStudy, MolecularDefinition, MolecularSequence
ebm-incubator	Under review	Citation, Evidence, EvidenceVariable, ArtifactAssessment

ConditionDefinition (Patient Care) and medication definition resources (MedicinalProductDefinition, PackagedProductDefinition, Ingredient, etc.) are also under committee review.

Some resources were removed entirely — not moved to additional, just gone: SubstanceNucleicAcid, SubstancePolymer, SubstanceProtein, SubstanceReferenceInformation, SubstanceSourceMaterial. Their content was absorbed into other resources by BRR WG.

Open Problems

Version management. Additional resources evolve on their own schedule. A server that supports both core R6 and three incubator IGs must track multiple version matrices. This adds complexity to conformance testing and validation.

Tooling. SUSHI does not handle additional resources well — it auto-lists search parameter bundles incorrectly and requires snapshots that incubator StructureDefinitions don't include. Workarounds exist but are fragile. IG Publisher works if you follow the pattern from fhir-testing-ig.

Temporary gaps. Some resources that moved out of core are temporarily unavailable while work groups set up their incubator IG CI-builds. As of early 2026, not all IGs are running.

Consent vs. Permission. Permission moved to additional, Consent stayed in core. In EU contexts where GDPR defines six legal bases for data processing (not just consent), implementers may stretch Consent to cover what Permission should handle — because Permission is less visible as an "additional" resource.

What This Means for Implementers

If you use any of the affected resources, here is what changes in R6:

They disappear from the core spec. You need to find them in their incubator IG.
JSON instances need resourceDefinition. Add the versioned canonical reference alongside resourceType.
CapabilityStatements need definition. Point to the version-specific StructureDefinition.
Search parameters move with the resource. Canonical URLs stay the same; versions may change.
References from core resources become extensions. Coverage referenced InsurancePlan, DeviceDefinition referenced ChargeItemDefinition — these are now extensions in incubator IGs.

What does not change: additional resources are still FHIR resources. Same REST API. Same search. Same profiling. The mechanism is administrative, not technical — the resources work the same way, they just live in a different package. And the path back to core exists — when a resource matures, its work group can request FMG approval to move it back into the next ballot cycle.

For Aidbox, this is a minor change. We have supported custom resources since day one — additional resources use the same mechanism. The only adjustment needed is validation for the resourceDefinition property.