How the calculator works

The OpenDQM calculator is an execution environment for the published dQM packages. It adds no measure language and re-implements no measure logic. A run has four stages.

1. Load

The Measure, Clinical Quality Language (CQL) libraries and value sets from the measure package on the eCQI Resource Center are loaded at their pinned versions.

Published packages do not load as published. For the breast cancer screening measure (CMS125) it took 43 changes:

• 31 value sets ship with an empty definition that expands to zero codes. They are rebuilt from the shipped expansion.
• 10 libraries ship precompiled ELM at a signature level the engine rejects. They are recompiled.
• 2 libraries contain an expression the translator rejects and need a rewrite.

Every change is recorded in a manifest that travels with every result. The default profile is the published content plus these disclosed load changes. No number computed under another profile is reported as “published”.

2. Conform

Data arrives as FHIR R4 Bulk Data export output, the interface every certified EHR exposes. An enterprise data warehouse emitting the same NDJSON looks no different to the calculator.

Before any engine sees the data, the rules for that data source are applied:

• profile declarations derived from signals already in the resource;
• repairs, such as relabelling a code system;
• derivations, such as a missing date supplied from one that is present;
• signed mappings from a platform’s local codes and text strings to standard codes.

Every added element carries provenance naming the rule, its version and its reviewer. The HL7 FHIR validator then checks each output against the profile the measure expects.

3. Evaluate

Conformed data is evaluated one patient at a time, on either of two open engines:

• fqm-execution, behind the Data Exchange for Quality Measures (DEQM) server ($evaluate);
• the HAPI FHIR Clinical Reasoning module ($evaluate-measure).

4. Account

Each run produces standard FHIR MeasureReports and a per-patient care-gap list. For every patient the measure did not count, it also gives the reason: which retrieve returned nothing, which element was missing, which source it came from, and who can fix it (the standards body, the EHR vendor, or the site).

This is possible because the conform stage tagged every added element with the rule that added it. A run can be read backwards, from a population count to the data that produced it.

Rule classes

The class of a rule decides whether its output counts in a reporting result.

Class	What it does to the meaning	Example	Counts in reporting mode
Repair	Re-expresses a fact the source asserted, in the form the measure reads	HCPCS code relabelled from CPT; profile declared from Condition category	Yes
Derivation	Fills a missing element from one present in the same resource	Onset date from recorded date	Only when signed
Inference	Adds meaning the source did not assert	Local radiology order text to LOINC; clinical sex from administrative gender	Only when signed

A rule counts as a repair only if it leaves the expected MeasureReports on the published test decks unchanged and its output passes the HL7 validator against the measures’ own profiles.

Each rule is itself a FHIR artifact: a CodeSystem fragment for the platform’s vocabulary, a ConceptMap to standard codes, profile-declaration and derivation rules, and a Provenance resource naming the signer.

An example: clinical sex versus administrative gender

To compile the breast cancer screening measure, one expression that tests SNOMED-coded clinical sex was rewritten to test administrative gender (female). The two do not classify the same patients: administrative “other” and “unknown” have no clinical equivalent. So the rule is classified as an inference, not a repair. It counts in a reporting result only when a named signer accepts it.

The published test deck cannot detect the difference, because its patients have consistent sex and gender: the cohort is 60 of 60 either way.

Two modes, and the bias report

Both modes read the same tags:

• Quality-improvement mode counts repairs, derivations and inferences, each one marked.
• Reporting mode counts only what the source already coded, plus repairs and signed rules.

The bias report is the difference between the two, per measure and per source. It lists every patient whose population membership depended on an unsigned derivation or inference.

Real time

A daily export using the _since parameter re-evaluates only the patients that changed, so a care gap is visible within one export cycle. A single-patient read re-evaluates one patient on request. Per-patient evaluation is stateless, so throughput grows with the number of engine instances, from one container beside a clinic’s EHR to a national deployment.