Does this replace a certified reporting engine?

It covers CMS eCQMs, state measure sets, and custom VBC measures that do not require the same certification path. Official HEDIS submission remains with licensed, NCQA-certified calculation systems.

Who writes the SQL measures?

CQL-to-SQL translation is AI-assisted, then checked patient by patient against published reference MeasureReports before the measure is included.

What happens when a measure is updated?

Measures are versioned resources in the package. New annual versions can be distributed as package updates, while organization-specific 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 measure queries use PostgreSQL syntax and may require adaptation for another database.

We already have a data warehouse. Why calculate measures in Aidbox?

A warehouse calculates over a copy of the clinical population that must be loaded and synchronized. In Aidbox, the rate, patient records, evidence, and logic remain connected to the FHIR store serving 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.

Measures that run in your own database

Install one FHIR package into Aidbox. Measures execute as SQL against the store you already run, behind the standard Measure/$evaluate-measure API. No second engine to deploy.

Run one measure on your data See the open example

A dozen CMS eCQMs, verified against CMS reference outputStandard FHIR packageOpen on GitHub

Where numerators disappear

A patient gets screened. The lab sends the result under a local code instead of LOINC. The measure finds nothing and drops that patient.No error, no alert. The rate is just lower.

Patient screenedLocal lab codeNo matchNumerator −1

On one 160,000-patient store we watched numerators fall close to zero — with the measure logic entirely correct.

The same rate, two different causes

outreach

The care did not happen.

Send the kit, book the visit.

data

The care happened and you cannot prove it.

Fix the mapping, the rate corrects itself.

Telling them apart means opening the measure. Most products will not let you.

What you install

One FHIR package, installed the way an Implementation Guide is. Results come back as an ordinary MeasureReport.

Measure queries	43
Value sets	107
ViewDefinitions	10
Code systems	10
Total	170

rate → patients → evidence → logic

Follow any number down

Every population is a named query you can run yourself. Your care gap work list is one of them.

Rate

Measure dashboard in the open example showing 12 CMS eCQMs with their scores and open gap counts

The rate.

Patients

CMS130 Colorectal Cancer Screening summary report with population counts and the patient list behind them

The patients behind it.

Evidence

The resource that decided each one.

Logic

Named SQL query steps for CMS130 with the CTE behind each step and its yes or no result

The line of SQL that made the call.

The application that ships with it

Both screens come from the open example, running the measures against its synthetic dataset.

A cross-measure gap worklist

Patients ranked by how many measures they are still open on, with the next action for each.

Cross-measure gap worklist ranking patients by open care gaps, with the top action per patient

Exportable outreach lists

Per-measure cohorts with the action to take, ready to hand to the team doing the outreach.

Per-measure outreach lists showing open gap counts and the action for each measure

Already on CQL?

Your measures stay authored in CQL. We translate them into SQL on FHIR and check the result patient by patient against the reference MeasureReport until the numbers match exactly. That is how every measure in the public example was built.You keep the standard. Production stops paying for a second runtime.

Check the data before you trust the rate

Validate your entire store against the profiles a measure expects, in bulk, before a number gets published. You get back the resources that failed and why, not a score with no explanation.Run it before an annual submission, or before you migrate to a new profile version.

Proof

Public example on GitHub

A dozen CMS eCQMs on Aidbox and PostgreSQL, 530 sample patients, demo app included.Open example on GitHub

Verified against CMS reference output

Checked patient by patient against CMS published reference output, in a public repository anyone can check.Calculating CMS Quality Measures as SQL on FHIR

Benchmarked on 100,000 patients

The measure set was run end to end against a synthetic store of that size, on the same PostgreSQL that serves the operational API.

Built on SQL on FHIR

An HL7 specification. We chair the working group.

Explore the open example

Who this is for

MSSP ACOs losing the MIPS CQM option at PY2027
Hospitals whose required eCQM count rises from 8 to 11 by CY2028
Plans and ACOs with engineering teams running gap lists and scorecards all year
Analytics vendors who need the layer underneath their own product
State and contract measures nobody ships out of the box

Why not just buy an engine

Turnkey vendors work on day one. You give up the ability to ask why a number came out the way it did, and the bill grows with your membership.

A separate runtime

FHIR storeCQL enginedata and terminology callsMeasureReport

Standards-based engines got the bigger idea right, then pay for it in production: every run lifts your population out to a separate runtime.

SQL inside Aidbox

FHIR resourcesSQL-on-FHIR viewsmeasure SQLMeasureReport

We keep the standard and remove the runtime.

FAQ

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

One measure, your data, two weeks

The rate, the patient list behind every gap, and the reason for each one. If coding mismatches are eating your numerators, it shows in the first week.

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