An open, community-owned corpus of healthcare quality measures, and a shared record of what the community has learned about each one.
Publish a measure in CQL, SQL, or SQL-on-FHIR. Everything is validated, versioned, and open for review. Alongside the measures sits the part that usually gets lost: a typed record of interpretation questions, defects, and test cases, attached to the measure and pinned to a version.
Site: https://openquality.vercel.app
Quality measurement is rebuilt from scratch inside every organization that does it. Payers, health systems, and vendors each staff teams to implement the same national measures against their own data, then pay auditors to certify the result. The same ambiguities in the same specifications get rediscovered independently, the code is rarely shared, and what one team learns about a measure rarely reaches the next.
There is no common unit for exchanging measure logic, and no shared place to record what the community has figured out. Open Quality is an attempt at both: a package format anyone can publish, and a knowledge corpus anyone can read.
Today, getting an answer about a measure depends on knowing the right person.
A recent example. A PhD candidate wrote a Hospital at Home eligibility library that ran at 30 to 40 seconds per patient. He could not tell whether the cause was his logic, his engine, or his data. Someone made an introduction to an engineer who had spent years optimizing CQL. That engineer explained it in one email: defines cache, functions do not, every retrieve iterates the whole bundle. The library now runs in under a second, and returns the same results.
That answer existed because of one introduction. It is not searchable, it is not attached to a measure, and the next person will not find it.
Most people doing this work are not on Zulip, do not attend connectathons, hold no NCQA support contract, and do not work at an insurer with a staff of analysts. As quality measurement moves from manual abstraction to digital, they need somewhere to go that does not depend on who they happen to know.
This is early and honest about it. The package format and the validation core work; the hosted registry does not exist yet. See Status.
Open Quality is not another measure engine and not a competitor to the tools people already rely on. It is the open corpus and community layer that sits alongside them.
- cqframework builds the CQL language, the translator, the execution engines, and the annual eCQM/dQM content. Open Quality reuses that tooling and shared libraries rather than reinventing them, and points its content at the same connectathons.
- HL7 CRMI (Canonical Resource Management
Infrastructure) defines how knowledge artifacts are packaged, versioned, and moved
through a lifecycle. Open Quality's package format maps onto CRMI so a package can be
emitted as a CRMI artifact bundle and consumed by CRMI-aware tooling. See
spec/. - Reason Health / ReasonHub and other CRMI-native platforms are authoring and syndication systems. Open Quality is deliberately the open, public-good end of the same space, and aims to interoperate, not overlap.
- The FHIR package registry distributes FHIR conformance artifacts, and does that well. It answers "where do I get this package." It is not built to answer "why is this measure slow," "does a missing HbA1c count as poor control," or "how did someone else read this denominator." Different problem, not a smaller one.
- NCQA's Digital Quality Implementers Community (DQIC) is a consensus effort focused, in NCQA's own description, first on CQL engines, with other tooling and languages as future work. Engines are well covered. Measures and analytics practice are not.
What Open Quality adds that isn't already covered: radical openness, first-class support for SQL and SQL-on-FHIR (not just FHIR-canonical artifacts), and the knowledge corpus of interpretation issues.
Being open source is also what makes the corpus possible. There is no HEDIS license to negotiate and no legacy vendor to pay for the right to discuss a measure in public.
Pre-launch.
| Piece | State | What it is |
|---|---|---|
| Package format | shipped | Manifest schema, conformance levels, license policy, content scanning, provenance |
| Validation core | shipped | Validates a package directory and computes its level |
oq CLI |
shipped | oq validate, oq validate-all and oq pack |
| Seed corpus | shipped | 52 CC0 eCQM packages imported from cqframework, with a CI drift check |
| Deep validators | next | CQL to ELM, FHIR profile validation, SQL parsing, VSAC resolution |
| Registry | planned | Publish, search, install |
| Typed feedback | planned | Questions, interpretation issues, defect reports, implementation notes |
Local validation stops at Level 1, and so does the seeded corpus. Level 2 needs the deep validators, which do not exist yet.
This is a single repository, laid out so the intent is legible at a glance.
| Path | What lives here |
|---|---|
spec/ |
The package format, the conformance levels, and the CRMI mapping |
measures/ |
Measure package collections, indexed by data model and year |
knowledge/ |
The interpretation-issue corpus — questions, defects, and test cases per measure |
TERMINOLOGY.md |
Which code systems may be redistributed, and with or without display text |
packages/ |
The tooling: @openquality/core and the oq CLI |
site/ |
The openquality.vercel.app front end |
docs/ |
Design specs and implementation plans |
Requires Node 22 and pnpm.
pnpm install
pnpm test
pnpm oq validate-all measures/cms-fhir-2026Expected output:
Checked 52 packages, 0 below Level 1
A package is a directory with an openquality.yaml manifest and the artifacts the
manifest declares.
id: cms/diabetes-glycemic-status-assessment-greater-than-9
version: 0.5.0
license: CC0-1.0
measurementPeriod: 2026
measure:
title: "Diabetes: Glycemic Status Assessment Greater Than 9%"
steward: National Committee for Quality Assurance
identifiers: [CMS122FHIR]
dataModel: qi-core
artifacts:
- path: cql/CMS122FHIRDiabetesAssessGreaterThan9Percent.cql
type: cql
valueSets:
- oid: 2.16.840.1.113883.3.464.1003.198.12.1013
url: http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.3.464.1003.198.12.1013
source: vsacTrimmed from the real package in
measures/cms-fhir-2026/diabetes-glycemic-status-assessment-greater-than-9/,
which declares nine artifacts and nine value sets in full.
A package references value sets by OID and never embeds the expansions. This keeps VSAC and CPT licensed content out of the artifact, so the file is safe to publish.
dataModel is what makes shared SQL usable by anyone other than its author. SQL written
against an undeclared warehouse schema is unreadable to a stranger.
Levels measure rigor, not FHIR adoption. A SQL-only package can reach the top. Most organizations doing quality measurement write SQL against a warehouse, not CQL. A level system that required FHIR to reach the top would exclude them.
- Level 0, Shared. Valid manifest, open license, at least one artifact. Any language.
- Level 1, Described. Declared data model, typed artifacts, resolvable value sets, and a README stating intent, known limitations, and provenance.
- Level 2, Verified. Deep validation passes for every artifact. CQL translates to ELM. FHIR resources validate against the CRMI and QI-Core profiles. SQL parses against its declared dialect and ships its schema.
Full definitions, including the CRMI mapping, are in spec/.
The measures are half the value. The other half is what the community learns about them.
knowledge/ holds typed feedback attached to a measure and pinned to a
version — a question, an interpretation issue, a defect report, an implementation note, or
a validation result. "Known interpretation issues for CMS122" becomes a query instead of
an archaeology project.
This is also the contribution an employer will often approve when they will not approve releasing the SQL itself. The schema is built as a machine-readable superset of the categories in the ONC eCQM Issue Tracker, so the corpus is continuous with where implementers already file questions.
Open licenses only. No HEDIS logic. No redistributed VSAC expansions. No CPT display descriptors, which are AMA licensed; a CPT code and code system may be referenced. Full rules per code system are in TERMINOLOGY.
NCQA holds copyright on the HEDIS specifications, so that logic cannot be published here. You can publish your own implementation written against a public specification. You can also publish test cases and review comments, which is often the part an employer will approve releasing even when they will not release the SQL.
The forbidden content scanner is a heuristic first filter. It will miss things and it will produce false positives. It is backed by a takedown process, not presented as a guarantee.
Community is the point. There are three ways in, and none of them require you to publish code:
- Publish a measure package. See CONTRIBUTING.
- File an interpretation issue or a test case against a measure in
knowledge/. This is the highest-value, lowest-friction contribution. - Review what others have published.
The measure and clinical-reasoning community mostly gathers on the FHIR Zulip
(#cql) and in the HL7 Clinical
Quality Information work group. We show up there too.
Please read the Code of Conduct and the Governance model. Governance is worth a look up front: Open Quality is founded and stewarded by FHIR IQ today, with a written commitment to broaden to community governance as it grows.
Open Quality is not a measure steward and is not affiliated with or endorsed by CMS, NCQA, or HL7. Seeded content is redistributed from public sources with provenance stated on each package.
MIT. See LICENSE.