The challenge
The problem dQMGrid addresses
Calculating a quality measure means processing large, multi-source clinical datasets against precisely specified logic. Because there has been no shared way to do that, providers, facilities, registries and other measure stakeholders have each built and maintained their own technology stack — the same work, repeated in private, by everyone who reports.
CMS is moving quality reporting to digital measures. About 70 electronic clinical quality measures (eCQMs) have been converted into digital quality measures (dQMs): HL7® FHIR® measure packages with Clinical Quality Language (CQL) logic, written against the Quality Improvement Core (QI-Core) profiles and published through the eCQI Resource Center. The direction is set.
FHIR-based reporting has a date
Section titled “FHIR-based reporting has a date”Under the calendar-year 2027 Physician Fee Schedule proposed rule, FHIR-based reporting would be voluntary for 2028 and 2029, and mandatory for applicable Alternative Payment Model Performance Pathway (APP) Plus measures in 2030 — the same year the MIPS clinical quality measure (CQM) collection type would sunset. Accountable care organizations (ACOs) move first.
For an ACO, the question is no longer whether to move to FHIR. It is what happens when its EHR vendors are not ready.
The engines are open. The layer in front of them is not.
Section titled “The engines are open. The layer in front of them is not.”Open-source dQM tooling exists, and it is good. Each measure ships as a complete package with test cases and expected results, and open engines run it. Against the published synthetic test patients, they pass.
Against a real FHIR export from a working EHR, they fail — and usually they fail silently, returning a plausible rate instead of an error. In our own testing:
The third number is the mechanism. The measures retrieve data by QI-Core profile. Certified EHRs are tested against, and declare, US Core. At the engines’ default settings, a real export returns empty on every retrieve, and the measure scores zero without raising an error.
This is a gap between layers that each work as specified. The measures are correct for QI-Core. The engines are correct for the measures. The EHRs are correct for US Core certification. Nobody was positioned to see the gap, because it only appears when all three meet on real data.
Every ACO and registry closes the gap the same way, independently
Section titled “Every ACO and registry closes the gap the same way, independently”Today, each registry and each organization measuring quality bridges that gap with its own adapters: one per EHR vendor, kept proprietary. Our own production calculator carries one extractor per EHR platform and one hand-written implementation per measure per year.
Bridged privately, the cost multiplies by every data source and every implementer. A small practice or a critical access hospital cannot afford to build it, so it cannot adopt digital measures on its own terms.
What a solution has to do
Section titled “What a solution has to do”To lower the barrier rather than reproduce it under an open license, a calculator has to:
- run the published dQM packages as published, adding no measure language and re-implementing no logic, so its results can be compared with anyone else’s;
- read real exports from certified EHRs and enterprise data warehouses, not only conformant test data;
- say, for every patient it did not count, why — which data was missing and who can fix it;
- keep any adjustment to the data visible, versioned and attributable, so a reported number can be trusted; and
- be open, so the fix for one vendor’s export is written once and shared.
Next: what dQMGrid is.