Does this replace a certified reporting engine?

No. When a reporting program requires licensed and certified measure logic, that engine remains in the official submission path. Aidbox covers CMS, state, and custom measures that do not have the same certification gate. It also supports the year-round data and care-gap work that determines the eventual result.

Who writes the SQL measures?

Translation from published CQL is AI-assisted. The resulting SQL is checked patient by patient against published reference MeasureReports, and the measure is accepted only when the expected populations match.

What happens when CMS updates a measure?

Measures are versioned resources inside the package. An annual update is distributed as a new package version, while organization-specific terminology mappings and normalization rules remain under the customer’s control.

Can the package run outside Aidbox?

The package uses the standard FHIR NPM format, and its ViewDefinitions can run on other SQL-on-FHIR implementations. The SQLQuery bodies use PostgreSQL syntax and may need to be adapted or reimplemented for another database.

We already have a data warehouse. Why calculate measures here?

A warehouse can calculate measures, but it operates on a copy of the clinical population that must be loaded and synchronized. Investigation can also stop at the ETL boundary between the calculated result and the operational FHIR data. In Aidbox, the rate, patients, evidence, and logic remain connected inside the store that serves the operational API.

Pricing follows the Aidbox infrastructure deployed rather than the number of covered lives. The commercial model is deployment-based, not a published per-member fee.

CMS eCQMs · State measure sets · Custom VBC measures

Calculate quality measures. Explain every gap.

Name: Quality Measures on FHIR
Brand: Aidbox by Health Samurai
Author: Health Samurai

Run quality measures as SQL inside Aidbox and trace every result from rate to patient, evidence, and logic—all in the same FHIR store.

Run one measure on your data Explore the open example

12 CMS eCQMsMatched against CMS reference MeasureReportsShipped as one versioned FHIR package

A low rate does not tell you what to do next

A low numerator can mean missing care or missing evidence. One calls for patient outreach; the other, a data fix.

Missing care and missing evidence look identical

A quality report shows who qualified and who did not. It rarely explains whether the result reflects an open care gap or clinical evidence the calculation failed to find.

Coding mismatches lower the numerator silently

Different EHRs and laboratories can record the same event under different codes, code-system URLs, or FHIR resource types. Exact-match measure logic may miss the record without producing an error, so the calculation completes normally with a lower rate.

The answer often arrives too late

Quality reporting is periodic, but the work that changes the result happens throughout the year. When teams discover the problem near the reporting deadline, there may be little time left to retrieve evidence, correct mappings, or reach patients who still need care.

See the result while there is still time to change it

Run measures during the performance period rather than waiting for the final reporting cycle. As new evidence reaches the FHIR store and the measure is recalculated, teams can see which gaps have closed and which patients still require action.

Run one measure on your data

Quality teams

Focus outreach on genuine care gaps rather than on records the measure could not read.

Engineering teams

Investigate terminology and data-model mismatches before they continue lowering the rate.

From the rate to the reason

The rate shows the scale of the problem. The patient list shows where to act, while the evidence and measure logic explain why each patient received that result.

Rate → Patients → Evidence → Logic

The chain shows whether the measure found no qualifying care or found evidence that failed a coding or terminology match. The same result now leads to the correct next action.

Rate

Start with the MeasureReport and its population counts. Review the denominator, numerator, exclusions, and exceptions for the measurement period.

Patients

Open the patients behind each population. Move from the aggregate result to the individual records that contributed to it.

Evidence

Select a patient and inspect the FHIR resources evaluated by the measure. See the clinical event, code, source, and date behind the result.

Logic

Open the SQL condition that included or excluded the patient. Named query steps make it possible to inspect a population without reconstructing an opaque engine execution.

The calculation stays with the data

To keep that chain intact, the calculation has to stay close to the resources it evaluates. Most deployments put it in a separate runtime beside the clinical store.

Separate measure runtime

FHIR storemeasure engineterminology & patient-data callsresultThe source data and calculation live in different systems. Teams must maintain the connection between them during both execution and investigation.

Measures inside Aidbox

FHIR resourcesSQL-on-FHIR viewsmeasure SQLMeasureReportAidbox pushes the calculation into the same PostgreSQL-backed FHIR store that serves the operational API. There is no second measure runtime to deploy, no patient population copied into another analytics system, and no ETL boundary between the result and its evidence.

One package for calculation and investigation

Measures are delivered as versioned FHIR resources installed into Aidbox. The package contains the calculation logic, terminology, SQL-on-FHIR views, and patient-level evidence queries required by the application.

Measure logic as readable SQL

Each measure is stored as a SQLQuery Library resource rather than as application code inside a proprietary runtime. Engineering teams can review the logic alongside the data it evaluates.

Terminology included

The package contains the CodeSystems and ValueSets required by the measures. Expanded concepts are joined during SQL execution instead of requested separately for every patient.

Standard FHIR results

Measures run behind the standard operation Measure/$evaluate-measure. The operation returns a MeasureReport that existing FHIR applications and workflows can consume.

An application on top

The open example includes measure rates, a cross-measure gap worklist, patient-level evidence drill-down, and exportable outreach lists. Teams can move from the reported result to the records behind it without leaving the FHIR workflow.

Package contents

43SQLQuery Libraries 107ValueSets 10ViewDefinitions 10CodeSystems 170 versioned resources, delivered as one FHIR NPM package.

Built for teams that own the quality-data pipeline

This solution is designed for organizations that already have engineering capacity and need control over data preparation, measure execution, and patient-level investigation. State measure sets and custom VBC measures use the same calculation and evidence workflow, including measures that standard vendor packages do not cover.

ACOs often aggregate data from multiple practices and EHRs, each with its own coding habits and resource models.

Aidbox brings multi-source FHIR data, terminology normalization, and measure execution into the same platform, so the rate and the records behind it stay in one place.

Vendors keep their measure portfolio, customer workflows, and any certifications required for official reporting.

Aidbox provides the underlying ingestion, normalization, terminology, and execution layer beneath that portfolio.

Internal teams can run CMS, state, contract-specific, and operational measures without handing the entire workflow to a turnkey analytics vendor.

They retain control of the data, the calculation, and the investigation process.

The manual routes are narrowing

Each program moves on its own schedule, so the deadline that matters depends on yours. For MSSP ACOs, removing the MIPS CQM option means all-payer reporting requires computed eCQMs — the only alternative is a Medicare-only CQM population.

PY2027

MSSP / APP Plus

MIPS CQM collection type removed.

CY2026–2028

Hospital IQR / Promoting Interoperability

Required eCQMs increase from 8 to 9 to 11.

MY2029

NCQA HEDIS

Hybrid chart review retired.

MY2030

NCQA HEDIS

Reporting becomes fully digital.

PY2027

MSSP / APP Plus

MIPS CQM collection type removed.

CY2026–2028

Hospital IQR / Promoting Interoperability

Required eCQMs increase from 8 to 9 to 11.

MY2029

NCQA HEDIS

Hybrid chart review retired.

MY2030

NCQA HEDIS

Reporting becomes fully digital.

CMS and NCQA are on separate timelines CMS has committed to a FHIR-based digital-measure direction but has not set a final transition date. Today’s mandated eCQMs still use QDM, so the CMS and NCQA timelines should not be presented as one 2030 mandate.

Public, runnable, and externally checkable

The measures, the dataset, and the validation method are open, so the claim can be verified rather than taken on trust.

12 CMS eCQMs

Colorectal and breast cancer screening, blood pressure control, diabetic eye exam, and more — running as SQL on Aidbox and PostgreSQL behind Measure/$evaluate-measure on a dataset of 500+ synthetic patients.Calculating CMS Quality Measures as SQL on FHIROpen example on GitHub

Patient-level validation

Each measure was compared patient by patient with published reference MeasureReport fixtures until the expected populations matched. Correctness can therefore be checked against an external reference rather than accepted as a product assertion.

Standard packaging

The suite contains 170 versioned resources in one FHIR NPM package. Its ViewDefinitions use SQL-on-FHIR, an HL7 specification whose working group is led by Health Samurai.

Run one measure on your data

Not a replacement for official HEDIS submission Official HEDIS submission requires licensed measure content and an NCQA-certified calculation system, and Aidbox is not positioned as a replacement for a certified HEDIS reporting vendor. The solution covers CMS eCQMs, state measure sets, custom VBC measures, and the year-round investigation of care and data gaps. In HEDIS workflows, Aidbox can support data preparation and investigation while certified logic remains in the official submission path.

FAQ

Common questions about scope, correctness, and packaging. Can’t find what you’re looking for? Our team is happy to help.

Start with one measure on a prepared FHIR dataset

We calculate one measure and return the rate, the patients behind each population, and the evidence behind individual results. The analysis shows where the measure found missing care and where terminology, coding, or resource-model differences prevented it from recognizing existing evidence. The starting scope assumes that the relevant clinical data is already available as a prepared FHIR dataset — data ingestion, identity resolution, and broader normalization work are scoped separately when required.

Address: Health Samurai Inc. 1891 N Gaffey St Ste O, San Pedro, CA 90731
Telephone: +1 (818) 731-1279
Email: hello@health-samurai.io