Why ViewDefinition can't simply be declared a FHIR resource, and a `repeat` directive for data that nests all the way down — Oct 15, 2025

Why ViewDefinition can't just be declared

FHIR refers to resources by short name almost everywhere — reference targets, search parameter targets, capability statements — and most of those places won't accept a full URL. So the name has to be controlled centrally, or ten groups define ten different things called ViewDefinition and nobody knows which is authoritative.

A registry for this already exists, and ViewDefinition is already in it — put there speculatively while someone was tinkering, not authorised.

The bar is higher than the FHIR Community Process

A resource definition has to live in an IG that has been through HL7 International's STU and balloting process.

Two routes:

• File a PSS and become an official project sponsored by FHIR-I
• Ask FHIR-I to publish a separate IG holding just the resource definition and keep the group's own IG outside it

The group chose the first, on the grounds that the second means handing the thing over to somebody else's process.

What formalising costs day to day

The calendar moves onto HL7's, you need a sponsoring work group, and spec changes need Jira tickets and votes.

In practice FHIR-I runs block votes — thirty dispositions at once, and almost nobody objects, because the people who care are already the people doing the work.

Other work groups vary wildly; some grind through every ticket live on a call because that's the only place their members show up.

The framing underneath — FHIR as a closed world

A large part of the industry insists FHIR is a closed world: if a US Core diagnosis cites a resource you've never heard of, you can't parse it, so it isn't a valid US Core diagnosis.

Splitting things out of core is therefore about modularising a core that stays closed, not about extensibility.

Someone pushed back on calling the result an incubator — that implies unfinished, when a module might legitimately stay separate forever — but module is already a taken word in FHIR.

The repeat directive

ViewDefinition has no answer for recursive structures, and QuestionnaireResponse nests to arbitrary depth: today you hand-unnest and your view ends up coupled to however deep your data happens to go.

The proposal takes one or more paths, walks down the tree collecting each, unions them, and applies the selection to the union — you need the multiple paths because questionnaire items live at both item.item and item.answer.item.

Left open:

• It behaves more like FHIRPath's repeatAll than repeat
• A SQL transpiler has to solve the recursion somehow (CTEs, or possibly Postgres JSON path)
• The order has to be spelled out when repeat and forEach land on the same node