The problem
R6 moves about 27 immature resources out of the core spec into separate incubator IGs, so what stays in core can be frozen as normative. But resources point at each other. When one leaves, every element that pointed at it becomes an arrow with nothing on the end — and those elements sit in resources that are staying, and that are about to be locked forever.
An example. StructureMap and the FHIR Mapping Language moved to an incubator. Three resources that stay — ActivityDefinition, PlanDefinition and RequestOrchestration — each declare an element as canonical(StructureMap): this field may link to a StructureMap, and nothing else. The only type it is allowed to point at is gone. Security has the same problem: Permission moved out, Consent stayed and still refers to it.
So what goes in that element now? You cannot leave it — it names a type the spec no longer defines. And whatever you pick becomes permanent the day R6 goes normative. That is the question Brian Postlethwaite put to FMG: just remove the type constraint, or remove the property entirely?
Two easy cases, one hard one
Gino Canessa laid out the rule. For two cases out of three it is mechanical:
- Already targets all types — no change needed.
- Targets core types and moved types — drop the moved ones from the target list.
- Targets only moved types — no good answer.
The third is where the argument lives. Remove the last target and the reference is promoted to "any" — and in a normative resource, "any" is forever.
Four bad options
Widen to Any. What you get by default if you just delete the target type. Security is taking this route for Permission this ballot, hoping for a clearer solution afterwards.
"I think the only choice is to elevate it to 'any'. The unfortunate thing is that'll make it 'any' forever." — Lloyd McKenzie
Point at Basic. Lloyd's alternative: canonical(Basic) keeps the element narrow, since Basic is unlikely to be used by anyone except for surfacing extra resources. Gino's objection is that in R6 Basic will not be used for additional resources at all, because they can be used directly. Lloyd's counter: even so, it is innocuous and much less likely to get abused than Any.
Delete the element. Orders & Observations already did this wherever the only supported target was an additional resource, and Grahame Grieve states it as settled guidance.
"If an element only refers to a resource that has been moved to incubation, then the element needs to be removed." — Grahame Grieve
Turn it into an extension. Drop the element from core and define the extension in the same incubator IG as the target — which, as Gino notes, makes the burden of extension versus element close to a wash.
The consensus is a judgement call, not a rule. If the relationship is genuinely needed and the target is only not-yet-normative, keep the element: there is no point forcing extensions and workarounds into a normative resource just because the target is not quite there. If the target's existence and design are still too early, an extension is the honest signal.
If you are migrating
- Elements that vanished. Something you use in R4/R5 may simply not be in R6. Check the relevant incubator IG for an extension with the same meaning before inventing your own.
- Elements that became
Any. The type safety you relied on is gone from the base spec. If you need it back, put it in your own profile — unlike the base spec, you can change yours later. - Links, not just data. Pages that now link into an incubator carry ballot-change markers too — in practice just the rXdiffs pages and the documentation links page.
Takeaway
The goal behind all of this is a solid R6 core: freeze what is mature, move the rest out, and give implementers a foundation that will not shift under them. That is worth doing — but the bill comes due at the edges, in decisions that are anything but mechanical.
Notice that none of the four options is free. Deleting an element is a breaking change: anyone who populated that field in R5 has nowhere to put the data in R6, and their instances stop being valid — which is exactly why Lloyd warned it pushes implementers into custom extensions. Widening to Any breaks nothing today, but once it ships in a normative resource the constraint is gone for good and nobody can narrow it later. So the choice is between a break you can see now and a loss you can never undo — and it is being made element by element, weeks before a ballot.
Source: chat.fhir.org — #fmg > R6 Review. See also: R6: Subtraction by Additional Resources and FHIR R6 release date & what's new.
