First sketch of a query resource, and how much of IG integration the publisher already does — Jan 8, 2025

First concrete shape of the query resource

Something simple whose body is a SQL query, probably reusing FHIR's existing Expression datatype so the dialect and the expression travel together, with a link to the set of ViewDefinitions it runs against — those views being its schema.

The open questions are the interesting ones:

• What are the table names, and can the view's name serve?
• Should there be parameters, since you often want to inject something rather than query everything?
• And a proposal worth more than it sounds — a canonical mapping from ViewDefinition column types to SQL types, because today the type in a view is only a suggestion from whoever wrote it, and a query you distribute can't rely on a suggestion.

CRMI as the obvious neighbour

An IG consolidating what it means for a knowledge artifact to be shareable, computable and executable — how you package it, version it, distribute it, resolve its dependencies. It already covers value sets, libraries, measures, plan definitions, structure definitions.

A ViewDefinition is a knowledge artifact by that definition, so the suggestion: align rather than reinvent — take the basic CRUD and search parts, skip the rest, and see whether ViewDefinition eventually belongs there.

The IG publisher already does more than people expected

Given a ViewDefinition in a guide, it:

• Validates it with SQL-on-FHIR-specific logic
• Registers the view as a table in the publisher's internal SQLite database
• Runs the view over the resources in the IG, and populates the table

A page can render the output of a SQL query against that database. That is a decent chunk of what IG integration was meant to mean, already built.

The fork in the road behind it

The publisher's output is deliberately static, and an HL7-balloted publication has to use the stock template, so the interactive parts people actually want — visual builders, live runners, evaluating a view to see what it does — can't live there.

Custom templates carrying React components exist for clinical guidelines and quality measures, but you cannot publish official content with them.

The suggestion: split it — the static official publication in the IG, the interactive exploration hosted separately as a community project, with narrative links bridging the two.

Is FHIR Shorthand the right way to write a view?

A related doubt: the comparison drawn was CQL, where a .cql file gets a first-class editing experience through editor plugins, versus writing views in shorthand because that's what IGs happen to use.

Either way, what has to come out of the far end is a FHIR package, and you can build one of those without the IG publisher.

Separately, the Parquet schema was promoted out of the parking lot into a work stream of its own; value sets and terminology stayed parked.