Why ViewDefinition can't be a proper resource in R4, and every workaround costs more than moving to R6 — Aug 5, 2025
The closed door in R4
There is no conformant way to define your own resource type. You can't put it in a capability statement, you can't write search parameters for it, you can't write an operation definition against it. Every one of those had to be modified for R6, which is precisely why the R6 work exists.
The implementer's view vs the definitional view
On the ground it's "I don't care if it's conformant, I want an operation on ViewDefinition in R4, because that's what customers are doing" — and at the implementation level nobody does care.
The problem is the definitional side: he doubted any committee would agree to publish an HL7-supported IG full of non-conformant artefacts.
He wondered aloud about an R4C that adds additional-resource support, then admitted he hasn't raised it with Graham because he might figure out a way to reach through the computer and strangle me.
John — it matters less than it looks
ViewDefinition isn't a generic resource you add to a server as another data model and you're done — if you implement it at all you're adding special functionality anyway, so first-class status buys less here than elsewhere.
His advice: leave it, adopt the mechanism when FHIR has one, move the IG to R6 when R6 lands.
The concrete blocker — and the workaround
IG Publisher rejects an operation definition bound to ViewDefinition. Gino's workaround: a system-level operation taking a canonical URL that points at the ViewDefinition, so no resource type is needed.
It's the same game played in the Subscriptions backport IG, where there are no SubscriptionTopic resources, only URLs — if you just happen to say that URL points to a subscription topic, then that's what it means.
John — MIMIC-IV's derived views as an exercise
Parquet on FHIR needs a second implementation running alongside his before it graduates from interesting to standards-worthy.
He also floated rebuilding MIMIC-IV's derived views as ViewDefinitions: mimic-derived is a set of value-added tables researchers reach for because they're more consumable than the raw ones, so publishing them as views over MIMIC-IV on FHIR would exercise the spec and make the whole chain reproducible with standard tooling.