Who it is for

One framework, several audiences

The opportunity asks for a calculator accessible to providers, facilities and CMS. dQMGrid is built so that each of them runs the same open code against the same published packages — which is what makes their results comparable.

Providers and practices

What changes: you can calculate the converted dQMs from your own FHIR export, and see why any patient was not counted.

• Run the container inside your own environment; your data does not leave it.
• Use the shared rules for your EHR rather than writing an adapter yourself.
• Read the account to tell a real care gap from a data gap: a patient who was not screened, versus a screening recorded somewhere the measure does not look.

Facilities and hospitals

What changes: the same calculator, against an inpatient export.

Encounter-based measures — 30 of the 74 published packages — need inpatient encounter, medication-administration and discharge data that ambulatory exports do not carry. The first hospital data source is on the roadmap for the full converted set and needs a facility partner. If you would like to be that partner, see Stewardship.

ACOs and registries

What changes: FHIR-based reporting without waiting for every member’s EHR vendor to be fully conformant first.

• Operate dQMGrid once for all your members.
• Apply a signed vendor-tier rule set to every member on that product.
• Use reporting mode for submission and quality-improvement mode to find closable gaps, with the bias report showing exactly how much of the rate rests on unsigned adjustments.

This is the audience the CY2027 proposed rule moves first.

EHR vendors

What changes: a public, specific and reproducible record of what had to be corrected in your export before the measures could read it.

Every adaptation is a published, versioned rule tagged with its owner. A vendor-tier rule is a precise bug report against an export, not a complaint: it names the element, the profile the measure expected, and the fix that worked. Fix it at the source and the rule becomes unnecessary for every customer at once.

Measure developers and engine maintainers

What changes: findings from real data, returned to you.

dQMGrid runs your packages and engines as published and records every place they needed help on real exports — a package that does not load, a value set that ships empty, an engine behaviour that returns a plausible result instead of an error. Those findings are disclosed in each run’s manifest and filed upstream. dQMGrid works best alongside the people who write the measures and maintain the engines; it is the layer that tells them what reality looked like.

CMS

What changes: a neutral reference for the converted measures, and a channel back to stewards.

• A reference instance — the same open container — gives the program a neutral arbiter when implementers report different numbers for the same measure.
• The disclosed load changes and defect findings form a channel that returns problems to measure stewards and engine maintainers.
• Attribution, eligibility and submission remain program rules outside the calculator.

A hosted government-facing instance would need FedRAMP authorization, which is not part of the first release.

Measure stewards, regulators and payers

• Measure stewards get a precise record of how real EHR data differs from what each measure expects — feedback to refine future specifications.
• Regulators see FHIR deployment and its variation, EHR by EHR.
• Payers, CMS among them, get faster FHIR adoption and quality data they can trust.