Draft MaterializedView resource, native FHIR data quality checks, and formalising CQL-to-SQL under the FHIR Foundation — Jul 14, 2026
Draft MaterializedView — a resource for persisted view intent
Nikolai walked a draft MaterializedView resource: an infrastructure-level resource that points at a ViewDefinition or SQLView and declares intent to persist it to a destination — a Postgres schema, a Parquet file, a columnar store, a bucket. The framing he keeps returning to is that it's the same shape as Subscription: a topic (the view) plus a delivery target (the destination), with the runtime doing the work.
The key design constraint Nikolai built in: within a given destination, only one materialisation per canonical view is allowed. That sounds arbitrary until you have views built on views — then the constraint is what keeps dependency resolution from turning into a puzzle when the runner has to decide which specific materialisation of an upstream view to reuse.
Destination is not a great name — it's really a namespace or a schema. Servers that only support one destination effectively get one-to-one view-to-materialisation for free; servers that support many can materialise the same view into Postgres and ClickHouse at the same time.
John pushed on whether the constraint has to live at the spec level rather than being server-specific — if he only needs the leaf view materialised to Parquet, why force the constraint on upstream views he isn't materialising at all? Nikolai's answer was that the constraint only bites once you're materialising — the runner needs a single lookup rule to know whether it can reuse an existing materialisation of a dependency or has to create one. Brian's question was different: does this belong in the spec at all, or is it just a demonstration of what's possible on top?
It's not a canonical resource — it's an infrastructure resource, the same category as Subscription. It's completely optional; you can live entirely with ViewDefinition and SQLView. But if you want performance, it's better to have a specification for how the persistence layer is wired.
Gino noted there's a broader gap the group has been circling: FHIR doesn't yet have a clean name for this third category — not canonical, not domain, but infrastructure/configuration. John framed the same point operationally: because materialisation is a stateful thing that needs verbs (create, remove, refresh), a resource is the right vehicle.
The real test is putting it in the spec and trying to implement it across multiple codebases. That's the only way we'll find out whether it fits together — I can see it mapping onto Pathling's existing cache mechanism, where the user declares what to cache and how stale it can be.
Nikolai has a JavaScript implementation with two destinations wired up (CSV files, SQLite tables) as a playground. Steve said the design made sense from an implementer's perspective and he couldn't see a way he'd do it differently.
FHIR-native data quality checks on top of SQL on FHIR
Nikolai's FHIR-to-OMOP transformation passed all golden tests at the connectathon and, along the way, exposed a few inconsistencies in the reference R code. That turned the conversation to data quality — specifically, whether the SQL on FHIR spec should carry a small vocabulary for expressing checks natively.
The proposed model is thin: a data quality check is an ordinary SQLQuery Library that returns the "bad" rows, with extensions declaring the check type (value completeness, referential integrity, plausibility) and a threshold (e.g. bad rows must be under 5%). The taxonomy maps straight from the OMOP / Kahn framework — Conformance, Completeness, Plausibility — and Nikolai wants to write the extensions into the spec, with domain-specific check libraries built as IGs on top.
Brian raised the obvious overlap: don't profile invariants already do this? The group's read is no, not quite — invariants look at one resource at a time, so they can say a code is wrong but not that 30% of a million rows are missing it. Statistical, cross-resource, and threshold-based checks need a different substrate.
Native data quality tooling is one of the things FHIR plainly lacks. This is a compelling use case for SQL on FHIR generally — the spec contribution would be the extension definitions plus a base layer of general-purpose checks, with IGs building domain-specific checks on top.
Evan and Brian on compiling CQL to SQL
Evan has a working C# implementation that compiles CQL to relational algebra (RA) and then to SQL on FHIR view definitions, and is porting it to TypeScript. Brian has independently built extensions to the same base RA and has an early online playground with a lowering check, view emission, and SQL emission wired in. The shared architecture is the same both ways: CQL → RA → ViewDefinition → SQL, where the RA step is the portable core and the final SQL emission can be dialect-specific.
Both landed on the same handling for value sets — a simple value_set table with code, system, and value_set_id columns, produced by a standard system ViewDefinition. Evan flagged that there's still utility work needed before the interesting parts land: notably a transform that converts context-patient measures to context-unfiltered measures returning lists of IDs instead of Booleans.
The performance signal is real: Nikolai ran Evan's CQL measure (CMS131 Diabetes Eye Exam), compiled to Postgres SQL, against 100,000 patients in 10 seconds.
CQL-to-SQL IG: formalising under the FHIR Foundation
The group wants to formalise this work under the FHIR Foundation from the start rather than beginning as a community project and migrating later. Gino spelled out why — migration means extra IP assignment, project history reconciliation, and TSC/exec approval steps that are avoidable if you start inside the tent.
Once Evan sends me a project brief I can spin the repo up and handle the approvals. Starting inside the FHIR Foundation avoids the migration overhead entirely.
Evan will email Gino a brief at his Optum address by Wednesday, July 15. Because Evan still needs general Optum approval before creating a public repo himself, contributing to a repo someone else creates is the cleaner path — Nikolai offered to create the repo if that becomes the faster route.
The working-group affiliation is still open: SQL on FHIR sits under FHIR-I and the CQL work under CDS, and only one can be primary. Gino's suggestion was to house it under whichever group is easier to actually get work done in; Evan leans CDS but acknowledged that group is busy. Nikolai's other ask was a separate recurring meeting for this work, distinct from the SQL on FHIR call, and he wants to invite the person who implemented FHIRPath in C and built a FHIR-for-data-science DuckDB connector (name not recalled on the call).