Context
Gene Vestel, FHIR IQ. This follows the email thread with you, Tim Schwirtlich, and Evan Machusak about CQL-to-SQL and open measure sharing.
I have built the first piece of Open Quality, an open registry for healthcare quality measures.
This is a proposal for the 3.x series, not a bug report. Close it if the direction is wrong.
Problem
An author finishes a measure in CQL Studio. To share it, they send a repo link or a zip file. The recipient receives no declared data model, no license, no value set inventory, and no statement of intent or known limitations. The measure is not citable and a machine cannot validate it.
CQL Studio already covers "developing, testing, and publication of CQL and FHIR-based artifacts". The missing piece is a portable unit of publication that another tool can read.
Proposal
Add import and export of an Open Quality package.
A package is a directory with an openquality.yaml manifest and the artifacts the manifest declares:
id: northwestern/hospital-at-home-eligibility
version: 1.0.0
license: CC-BY-4.0
measurementPeriod: 2026
measure:
title: Hospital at Home Eligibility
steward: Northwestern
type: process
dataModel: fhir-r4
artifacts:
- path: cql/Eligibility.cql
type: cql
valueSets:
- oid: 2.16.840.1.113883.3.464.1003.101.12.1061
source: vsacA 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.
Why this fits CQL Studio
The manifest is small and declarative. Writing one needs no server and no patient data, so it fits the browser-side authoring scope you described for the 2.x series.
CQL Studio also already holds most of the fields. Library name, library version, FHIR version, and the valueset declarations in the CQL header map onto the manifest directly. The remaining fields are license, steward, and data model, which is a short form.
Export is a file write. Import is a file read plus a workspace scaffold.
Suggested scope
- Export. Generate
openquality.yaml from an open workspace and download the package. Pre-fill the fields CQL Studio already knows and prompt for the rest.
- Import. Read a package and open its artifacts as a workspace.
- Validate in the UI. Show the conformance level and any findings.
Phase 1 is useful on its own. Phases 2 and 3 can follow.
What we supply
- The manifest schema and the format specification.
@openquality/core, the validator: manifest parsing, license allowlist, value set reference checks, README section checks, forbidden content scanning, and conformance level computation. 91 tests.- The
oq CLI, which runs the same checks outside a browser.
- MIT licensed.
One accurate note on embedding the validator, since it affects phase 3. Seven of the nine core modules are pure and browser-safe: report, manifest, licenses, valuesets, readme, scanner, and level. Two are Node-only: validate reads a directory with node:fs, and pack uses node:fs, node:crypto, and tar. The current barrel export re-exports all nine, so importing the package root pulls the Node-only modules into a browser bundle.
We would add a browser-safe subpath export and an injectable file-reader interface so the orchestrator works against an in-memory workspace. That is our work, not yours, and we will do it before phase 3 lands.
Conformance levels
Three levels, and 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.
- Level 1, Described: declared data model, typed artifacts, resolvable value sets, README stating intent, known limitations, and provenance.
- Level 2, Verified: deep validation passes. CQL translates to ELM, FHIR resources validate against the CRMI and ECR profiles, SQL parses against its declared dialect.
Next step
I am happy to write the pull request rather than hand you a feature request. Tell me whether the direction is useful and I will scope it against your 3.x plans.
Context
Gene Vestel, FHIR IQ. This follows the email thread with you, Tim Schwirtlich, and Evan Machusak about CQL-to-SQL and open measure sharing.
I have built the first piece of Open Quality, an open registry for healthcare quality measures.
This is a proposal for the 3.x series, not a bug report. Close it if the direction is wrong.
Problem
An author finishes a measure in CQL Studio. To share it, they send a repo link or a zip file. The recipient receives no declared data model, no license, no value set inventory, and no statement of intent or known limitations. The measure is not citable and a machine cannot validate it.
CQL Studio already covers "developing, testing, and publication of CQL and FHIR-based artifacts". The missing piece is a portable unit of publication that another tool can read.
Proposal
Add import and export of an Open Quality package.
A package is a directory with an
openquality.yamlmanifest and the artifacts the manifest declares: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.
Why this fits CQL Studio
The manifest is small and declarative. Writing one needs no server and no patient data, so it fits the browser-side authoring scope you described for the 2.x series.
CQL Studio also already holds most of the fields. Library name, library version, FHIR version, and the
valuesetdeclarations in the CQL header map onto the manifest directly. The remaining fields are license, steward, and data model, which is a short form.Export is a file write. Import is a file read plus a workspace scaffold.
Suggested scope
openquality.yamlfrom an open workspace and download the package. Pre-fill the fields CQL Studio already knows and prompt for the rest.Phase 1 is useful on its own. Phases 2 and 3 can follow.
What we supply
@openquality/core, the validator: manifest parsing, license allowlist, value set reference checks, README section checks, forbidden content scanning, and conformance level computation. 91 tests.oqCLI, which runs the same checks outside a browser.One accurate note on embedding the validator, since it affects phase 3. Seven of the nine core modules are pure and browser-safe:
report,manifest,licenses,valuesets,readme,scanner, andlevel. Two are Node-only:validatereads a directory withnode:fs, andpackusesnode:fs,node:crypto, andtar. The current barrel export re-exports all nine, so importing the package root pulls the Node-only modules into a browser bundle.We would add a browser-safe subpath export and an injectable file-reader interface so the orchestrator works against an in-memory workspace. That is our work, not yours, and we will do it before phase 3 lands.
Conformance levels
Three levels, and 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.
Next step
I am happy to write the pull request rather than hand you a feature request. Tell me whether the direction is useful and I will scope it against your 3.x plans.