About the OpenDQM calculator
A calculator that accounts for every patient it did not count.
The OpenDQM calculator is an open-core measure calculation tool for the digital quality measures (dQMs) converted from electronic clinical quality measures, about 70 measures in all. It runs the published measure packages exactly as written, against real FHIR exports from working EHRs. For every patient it does not count, it records:
- which retrieve came back empty;
- which data element was missing;
- which data source it came from;
- who owns the fix: the standards, the EHR vendor, or the site.
The problem it solves
Section titled “The problem it solves”Open-source dQM tooling exists, and it is good. Each measure is published as a complete package with test cases and expected results, and open engines execute them. Against the published synthetic test patients they pass.
Against a real FHIR export from a working EHR they fail, and often silently, returning a plausible rate instead of an error. Three reasons:
- Published packages don’t load as published. The breast cancer screening measure (CMS125) needed 43 disclosed changes before the reference engine would load it at all.
- EHRs declare US Core, measures retrieve QI-Core. We read the public capability statements of five certified EHR products in September 2026. All five declare US Core and none declares QI-Core, which is the set of profiles the measures retrieve by. At the engines’ default settings, every retrieve against a real export comes back empty and the measure scores zero with no error.
- Certified data can be conformant and still fail the measure. In US Core the clinical sex extension is optional and administrative gender is mandatory. A measure written against clinical sex finds nothing in an export that only carries gender.
Every organisation that measures quality from EHR data closes this gap the same way: with private adapters, one per vendor, rebuilt by every implementer. The engine is not the duplicated part. It is already open. The duplicated part is the layer that makes a certified export readable by the measures.
The approach
Section titled “The approach”OpenDQM publishes that layer in the open, as versioned HL7® FHIR® artifacts organised by data source, not by measure, in three tiers:
| Tier | Covers |
|---|---|
| Standards | Rules that follow from the specifications |
| Vendor | Rules for one EHR product |
| Site | Rules for one organisation’s build of that product |
An open adapter corrects a non-conformant export today. The vendor, seeing that the adaptation was needed, can fix it at the source tomorrow. Organisations can report in FHIR without waiting for every vendor to become fully conformant first.
Only repairs and signed rules count in a reporting result. Everything else is marked, counted separately, and shown. See How it works.
Why rules by data source
Section titled “Why rules by data source”The rule library grows with platforms, not measures. One signed vendor-tier rule reaches every organisation on that product, including a small or critical access hospital that could not have written it. Bridged privately, the cost multiplies by every data source and every implementer. Bridged once per source in the open, it is paid once.
Where to go next
Section titled “Where to go next”- The big idea: the adaptive-optics analogy, for a non-technical audience.
- How it works: load, conform, evaluate, account.
- Prototype results: what the prototype measures today.
- Example run report: an interactive report from a live eClinicalWorks export.
- Roadmap: the minimum viable product and what follows.