What a ViewDefinition builder needs from the server, and CRMI once ViewDefinition is canonical — Jun 5, 2024

A visual builder needs two things the spec doesn't yet give

• Somewhere to keep views
• Something to run them against while you iterate — a REST API to store and list ViewDefinitions, and an operation to evaluate one against sample data in a loop

Whether any of that belongs in the spec was the open question. The position taken: if ViewDefinition is a canonical resource, ordinary FHIR CRUD plus a couple of operations mostly covers it.

CRMI applies once ViewDefinition is canonical

Canonical resource management infrastructure is being built out for CQL artefacts, but it is really about any canonical resource: CRUD and search, plus an operation to get the dependency graph of a canonical and an operation to package it. If ViewDefinition is canonical then CRMI applies more or less as-is.

The pattern worth borrowing from SDC is the role split: a repository role that serves ViewDefinitions and an engine role that runs them, so one builder can talk to any implementation.

1.0 timing

The remaining blockers came to two column-ordering issues and three test issues, with everything else editorial. End of July was proposed so it lands ahead of the September connectathon, with the line to give people who ask being simply over the summer.

Should the prose be more formal?

The answer was no — the informal, readable style is a feature, and plenty of good specs are written without heavyweight jargon.

What it does need is consistency: use must and may the same way every time, remove ambiguity, add a glossary, and stop non-goals appearing in two different sections.

Rename "Implementer Guidance" to "Processing Model"

The current name reads as optional advice when the section is actually the semantics — it goes straight into how a view is evaluated, and the heading undersells that it is part of the spec proper rather than a set of tips.