Architecture and deployment
One container, many scales
dQMGrid is a self-contained measure calculation tool that retrieves from FHIR endpoints and runs inside the data owner’s own boundary. The same container serves a single practice, a registry or ACO operating it for its members, and a CMS reference instance.
Connecting to data
Section titled “Connecting to data”Certified EHRs. dQMGrid reads FHIR R4 Bulk Data export output — the standardized API every EHR
certified to ONC criterion 170.315(g)(10) exposes. It authenticates with SMART Backend Services and
calls $export at the group or system level.
Enterprise data warehouses. A warehouse that emits the same FHIR NDJSON is indistinguishable to the calculator. There is no separate warehouse connector to build or maintain; the conformance rules for the warehouse’s data apply exactly as they would to an EHR.
Measure content. Measure packages come from the eCQI Resource Center at pinned versions. Value sets are expanded from the shipped expansions and versioned with the run.
Where it runs
Section titled “Where it runs”dQMGrid runs inside the data owner’s boundary under the Health Insurance Portability and Accountability Act (HIPAA). Patient data does not leave the environment that already holds it.
| Deployment | Who runs it | Typical use |
|---|---|---|
| Single container beside an EHR | A practice or facility with technical staff | Calculate its own measures; read its own account |
| Shared service | A registry or ACO, for its members | One operation, signed vendor-tier rules applied to every member on that product |
| Reference instance | CMS — self-hosted from the open container, or operated by MDinteractive on its behalf | A neutral arbiter when implementers disagree; a channel returning defects to measure stewards |
A hosted, government-facing instance would need Federal Risk and Authorization Management Program (FedRAMP) authorization. That is not part of the first release.
How it scales
Section titled “How it scales”Per-patient evaluation is stateless: each patient is evaluated independently against the loaded measure. Throughput therefore grows with the number of engine instances, from one container beside a clinic’s EHR to a horizontally scaled national deployment.
Measured on the prototype: about 0.2 seconds per patient on HAPI FHIR Clinical Reasoning against a loaded test deck.
Scaling to a high-performance environment
Section titled “Scaling to a high-performance environment”Because the workload splits cleanly by patient, dQMGrid scales out on ordinary cloud or cluster compute. It does not need a specialized high-performance computing cluster — but it runs on one, if that is what an operator has.
The project provides the implementation and the automation to deploy it at any size:
| Deliverable | What it does | Status |
|---|---|---|
| Container image | Runs the calculator on one server, beside an EHR or a data warehouse | TodayprototypeNextpublic release |
| Helm chart | Deploys the calculator on a Kubernetes cluster and scales the number of engine workers | Next |
| Terraform modules | Provision elastic compute on a cloud, starting with AWS, for large batch runs | Planned |
Where a high-performance environment matters. A single practice or ACO does not need one. A national-scale run does. As an illustration only — extrapolated from the single-node figure above, not yet benchmarked at scale — evaluating 1 million patients against 10 measures is about 555 CPU-hours: roughly 9 hours on 64 cores, or under an hour on 600. That is the scale of a CMS reference instance recalculating every submitter’s results.
Who provides the infrastructure. dQMGrid provides the software and the deployment automation; the operator provides the compute. A hosted, multi-tenant instance operated by MDinteractive is available as a separate service, outside the scope of the QualTech proposal, and a government-facing instance would require FedRAMP authorization. See Stewardship.
The rule library scales differently from the calculator. Because rules are organized by data source, the library grows with the number of EHR platforms, not the number of measures. One signed vendor-tier rule reaches every organization on that product — including a critical access hospital that could never have written it.
Near-real-time results
Section titled “Near-real-time results”Real time follows from the design rather than requiring a separate system:
- Daily delta. A daily export using the Bulk Data
_sinceparameter returns only resources changed since the last run. dQMGrid re-evaluates only the patients those resources belong to, so a care gap is visible within one export cycle. - On request. A single-patient read re-evaluates one patient immediately — for example, at the point of care, after a result is filed.
Measure isolation
Section titled “Measure isolation”Published packages collide on content: two packages can publish value sets under one canonical URL with different identifiers. In our testing, loading CMS122 beside CMS125 broke 15 of 55 test cases. The first release evaluates each measure in isolation, which removes the collision at the cost of loading shared libraries more than once.
Outputs
Section titled “Outputs”- MeasureReports — standard FHIR, one per measure and counting mode.
- Care-gap list — per patient.
- The account — for every patient not counted: the empty retrieve, the missing element, the source, and the owner of the fix.
- Manifest — every change made to a published package, travelling with every result.
- Bias report — the difference between reporting and quality-improvement modes, per measure and per source. (Designed; an first release deliverable.)
Attribution, eligibility and submission remain program rules outside the calculator.