Seed corpus shipped · 52 CMS eCQM packages, provenance verified in CI · registry planned

OPEN
QUALITY

An open corpus of healthcare quality measures — and a shared record of what implementers have learned about each one. CQL, SQL, and SQL‑on‑FHIR. Today every organization rebuilds this logic, and this knowledge, on its own.

Read the spec Why this exists

Why this exists

The argument, from a real email thread

A PhD candidate writes a CQL library to screen patients for a Hospital at Home program. It runs at 30 to 40 seconds per patient. He needs it to run across 300,000. He has no idea whether the problem is his logic, his engine, or his data.

He gets lucky. His email reaches someone who has spent years optimizing CQL, and that person writes back a detailed review: functions are not cached the way defines are, a retrieve iterates every resource in the bundle every time, this correlated query is really a lateral join running dozens of semi‑joins. Rewrite it this way.

It worked. He restructured the library around prefiltered, cached defines. The same logic now runs in under a second and returns the same results, down from 30 to 40.

Four people read that answer. It is not searchable, it is not attached to any measure, and the next person with the same problem will not find it. It existed because somebody made an introduction.

This is a great example of why we need an open community for quality where experts can share their expertise, rather than relying on an introduction to the one person who happened to know someone by pure luck. — from the thread that started this

Every payer, health system, and vendor doing quality measurement staffs its own team to implement the same national measures against its own data, then pays auditors to confirm the implementation is right. The same specification ambiguities get rediscovered independently, over and over. The cost is enormous and none of it reaches a patient.

Open Quality is where that answer should live.

A measure is a package

Manifest, logic, value set references, provenance
// CMS122 — glycemic status > 9% define "Initial Population": AgeInYearsAt(start of "Measurement Period") between 18 and 75 and exists "Diabetes" // no result counts as poor control — // see knowledge/cms122/2026-001 define "Numerator": "Most Recent Result Above 9" or not exists "Result"
CMS
Glycemic Status Assessment > 9%cms/diabetes-glycemic-status-assessment-greater-than-9
L1
Steward
NCQA
Data model
qi-core
Period
2026
CQL
FHIR
SQL
VS
// same measure, SQL-on-FHIR // ViewDefinition, runs on a warehouse { "resource": "Observation", "select": [{ "column": [ { "name": "patient_id" }, { "name": "value_quantity" }, { "name": "effective_date_time" } ]}], "where": [{ "path": "code.coding.exists( system = 'http://loinc.org')" }] }
OQ
The same measure, two wayscommunity/glycemic-status-assessment-sql-on-fhir
L1
Steward
NCQA
Data model
sql-on-fhir
Period
2026
CQL
FHIR
SQL
VS
# openquality.yaml (real, trimmed) id: cms/diabetes-glycemic-status… version: 0.5.0 license: CC0-1.0 dataModel: qi-core valueSets: # referenced, - oid: 2.16.840.1… # never embedded provenance: # CI-verified upstream: github.com/cqframework/… ref: d4e0edd0… relationship: derived modifications: - removed CPT display text (3)
YML
The manifestopenquality.yaml
SPEC
Languages
any
Value sets
by reference
Versions
immutable
CQL
SQL
FHIR
R/PY

Three levels, and SQL can reach the top

Levels measure rigor, not FHIR adoption
LEVEL 0

Shared

A valid manifest, an open license, and at least one artifact. Any language. The bar is low on purpose, so that unfinished work can still be shared.

LEVEL 1

Described

Machine-readable measure identity, a declared data model, every value set resolvable, and a README that states intent, known limitations, and provenance.

LEVEL 2

Verified

Deep validation passes for every artifact. CQL translates to ELM. FHIR validates against the CRMI and QI‑Core profiles. SQL parses against its declared dialect and ships its schema. The deep validators do not exist yet, so nothing has reached this level — including our own seed corpus, which sits at Level 1 and says so.

Most organizations that do quality measurement write SQL against a warehouse, not CQL. A level system that required FHIR to reach the top would exclude them.

Honest status

What exists, what does not
PieceStateWhat it is
Package formatshipped Manifest schema, conformance levels, license policy, terminology scanning, machine-readable provenance.
Validation coreshipped Validates a package directory and computes its level. Runs on real CMS eCQM content.
oq CLIshipped oq validate, oq validate-all, oq pack. Deterministic, content-addressed tarballs.
Seed corpusshipped 52 CC0 CMS eCQM packages for the 2026 reporting year, provenance pinned to the upstream commit and re-verified byte-for-byte in CI on every change.
Knowledge corpusseeded Typed interpretation issues, defects, and test cases, pinned to measure versions. Seven entries on one measure so far — growing it is the point, and the ask.
Deep validatorsnext CQL‑to‑ELM, FHIR profile validation, SQL parsing, VSAC resolution. Level 2 needs these.
Registryplanned Publish, search, install. Git-authored, registry-hosted, versions immutable.
Registry-hosted feedbackplanned The knowledge corpus, searchable and writable from a web UI instead of a pull request.
# what runs today $ oq validate-all measures/cms-fhir-2026 Checked 52 packages, 0 below Level 1 # cql.translate, fhir.validate, and sql.parse will run on publish. # They do not exist yet, which is why nothing is Level 2.

What it will and will not host

Open licenses only. Every package declares an SPDX license from a short allowlist. Value sets are referenced by OID or canonical URL, never embedded as expansions, which makes the licensing rule enforceable by machine rather than by review.

No HEDIS logic. NCQA holds copyright on those specifications. You can publish your own implementation written against a public specification. You can also publish test cases and review comments. Many employers approve releasing that even when they will not release the SQL.