A proposal sketch for the SQL on FHIR community — how to express data-quality checks on top of the primitives we already have (ViewDefinition, SQLQuery Library, and query-to-query dependencies).
Compiled by Claude, working with @niquola, as background for discussion. Feedback very welcome.
SQL on FHIR — draft for community discussion (branch).
Maturity Level: 1 · Standards Status: Draft · Security Category: Patient · Compartments: Patient, Group
A MaterializedView is a server-managed, persisted representation of the output of a single ViewDefinition or SQLView (a SQLQuery Library) — its data processed into an efficient form for future query or load, such as a SQL table or view, or a Parquet/CSV file.
Research in support of the SQL-on-FHIR $materialize operation design (issue #326). Question: how does the industry (a) create / refresh / drop materializations, and (b) let clients control acceptable data staleness? Sourced from official documentation (links at the bottom).
The current $materialize proposal uses 3 HTTP verbs on one URL (POST = create-or-refresh idempotently, GET = status, DELETE = drop), an async poll pattern, a parameter expressing acceptable staleness (working name freshnessTarget / maxAge, a Duration; absent = manual, 0 = always-live, PT5M = lag ≤ 5 min, server may accept or reject), and a validAsOf output reporting actual freshness.
In agentic workflows, communication between human and AI is mostly text — chat messages back and forth. But many interactions are better served by structured UI: a form to fill, a table to review, a dashboard to monitor, a diff to approve.
What if the agent could create UI as easily as it creates files?
This document demonstrates how Clinical Quality Language (CQL) artifacts — both quality measures (CQM) and clinical decision support (CDS) — can be expressed as SQL against the OMOP Common Data Model.
The example uses two versions of the same clinical logic: the Chlamydia Screening for Women measure (CMS153 / NQF0033).
| name | omop-kg |
|---|---|
| description | OMOP CDM Knowledge Graph — ontology of 643 canonical concepts, 1067 relationships, 1099 doc chunks with embeddings. Extracted from CommonDataModel docs + The Book of OHDSI. Use when user asks about OMOP CDM tables, fields, concepts, ETL, cohorts, vocabularies, or needs to search OMOP documentation. |
| allowed-tools | Bash(curl *https://omop-kg.apki.dev*) |
643 canonical concepts, 1057 raw extractions, 1067 canonical relationships, 1099 chunks, 66 pages, 1666 embeddings.