Use Case: CMS Measures
Run your CMS quality measures on FHIR data with an open CQL engine. See where you stand while the performance period is still open, not after the submission deadline has passed.
What you can do with Firely
Run measure logic as published
Execute eCQM logic expressed in CQL against your FHIR data. No re-implementation of published specifications into a proprietary rules engine, and no waiting on a vendor release to see what a specification change does to your rate.
One logic layer across programs
The same CQL layer serves Hospital IQR and Promoting Interoperability, MIPS and MVPs, your ACO’s APP Plus set, and the payer contracts built on the same clinical concepts. Implement once instead of once per program.
Calculate continuously, not at submission time
Measures run against live FHIR data, so gaps surface while the performance period is still open and there is still something you can do about them.
Trace every result to its data
Standardized CQL artefacts and FHIR MeasureReports let you follow a rate back to the patients and data elements behind it. For your own quality team, your auditor, and the clinicians you are asking to change something.
Your measure logic is locked inside your reporting stack
Most provider organizations do not own their measure logic. It lives inside a certified EHR module or a registry vendor’s platform, expressed in a form you cannot read, on a release cycle you do not control.
That is workable when you report once a year and accept the number that comes out. It stops being workable the moment you want to know where you stand in month four, model what a specification change does to a rate, or run the same measure for a payer contract your reporting vendor does not cover.
And the programs keep stacking. A single health system typically reports into all of these at once:
- Hospital Inpatient Quality Reporting (IQR) — for the hospital
- Merit-based Incentive Payment System (MIPS), or a MIPS Value Pathway (MVP) — for its clinicians
- APM Performance Pathway Plus (APP Plus) — for its accountable care organization
- Contractual quality measures — for two or three payers
Same clinical concepts, separate implementations, different answers.
Where CMS is heading, and what is actually settled
CMS is moving toward FHIR-based quality measurement. Every program you report into is on that path, Hospital IQR, MIPS, MVPs and APP Plus alike. How far each one has actually traveled is another matter.
Hospital IQR and Promoting Interoperability take QRDA Category I; MIPS takes Category III. No CMS program accepts FHIR-based measure submission in production.
Since February 2026, three draft FHIR measure packages are out for comment, built on QI-Core. CMS reports FHIR specifications for more than 70 measures. None of it is reportable until finalized through rulemaking.
The CY2027 Physician Fee Schedule raises optional digital reporting for Shared Savings Program ACOs from PY2028 and mandatory FHIR from PY2030 — in a Request for Information, which is a consultation rather than a proposal.
The submission format is not changing this year, CMS has set no industry-wide deadline, and the one set of dates that exists sits in a consultation about one program. What has not been contradicted in any CMS document since 2022 is the direction.
Your FHIR data is arriving regardless
You are not being asked to bet on FHIR. You are already getting it.
ONC / ASTP CERTIFICATION
Your certified EHR is required to expose a standardized FHIR
API.
CMS Interoperability & Prior Authorization
Your payers must stand up FHIR APIs for patient access, provider access and prior authorization by January 2027.
USCDI defines the data elements. TEFCA defines the exchange. None of it depends on digital quality measurement going anywhere at all.
So the question is not whether FHIR will happen. It is whether you do anything with the FHIR data you are going to have. If CMS slows down on digital quality measures, that data does not disappear. A measure layer built on it sits on infrastructure that exists for other reasons, and stays useful whatever CMS decides next.
Where measure performance turns into payment
Quality reporting is not one obligation with one consequence. Depending on which programs you are in, the same clinical logic feeds three different payment mechanics.
A penalty
Hospital IQR & Promoting Interoperability
Hospitals that do not meet Inpatient Quality Reporting requirements lose a quarter of their annual payment update. The eCQM set is fixed and shared between the two programs: eight measures, all four quarters, one deadline.
A quarter of the annual payment update
A sliding scale
MIPS and MVPs
The 2026 performance threshold is 75 points, and adjustments are applied two years after the performance year. Quality is the largest scored category for most clinicians.
Up to ±9% of Medicare Part B payment
A gate
Shared Savings Program ACOs
Quality performance gates shared savings. Miss the standard and the savings you generated are not paid out.
The shared savings you earned
For ACOs, CMS has also added an eCQM collection type that allows reporting on assigned beneficiaries rather than the full all-payer population, a materially lower data bar for electronic reporting.
Same measures. Different moment.
Nothing about the measures changes. What changes is the point at which you see the result, and whether there is still anything you can do with it.
How most organizations measure today
After the performance period closesYou learn what your score will be.
By the time the number exists, the period is closed.
With measures running on live FHIR data
Throughout the performance periodYou learn what you can still change.
A gap found in month four is still a gap you can close.
How it works
Your FHIR data stays where it is. Firely Server runs inside your environment, against your existing pipelines and governance. No rip-and-replace, and no second copy of your clinical data.
FHIR Measure + Library containing CQL — the form CMS publishes its draft FHIR measures in
Clinical · claims · registry feeds, in your existing pipelines
Production CQL engine
$evaluate-measure
Patient level and population level, for your analytics, dashboards or care management
Your existing certified submission path. You keep reporting to CMS the way you do today, through your certified system, in QRDA Category I or III. Firely runs alongside it.
Want the technical detail? Read about CQL on FHIR →
Questions we get asked
Does this replace our certified EHR reporting?
No. Certification for capturing, calculating and reporting CQMs sits with your Health IT Module under the ONC/ASTP Health IT Certification Program, and submission to CMS still goes through QRDA. Firely is the measure execution layer next to it: the place where you can run the logic yourself, on your own schedule, against your own FHIR data.
Is there a CMS certification for CQL engines?
No. CMS does not certify measure calculation engines. The certification that applies in CMS programs is ONC/ASTP health IT certification under the CQM criteria at §170.315(c)(1)–(c)(4), and it attaches to the Health IT Module you report through — not to a calculation engine. This is a real difference from the HEDIS world, where NCQA certifies engines directly.
What if CMS never finalizes FHIR-based reporting?
Then you keep submitting QRDA exactly as you do now — Firely was never the submission path. What you would still have is visibility into where you stand during the performance period, one logic layer instead of one per program, and measure logic you can read and change yourself. None of that depends on a rulemaking.
Can we use this before CMS accepts FHIR submissions?
That is the normal case today, and it is where most of the value sits. Running measures on live FHIR data during the performance period gives you visibility you do not have now, whatever format you submit in at the end of it.
Does CQL hold up at scale?
Firely Server is a production FHIR server with a built-in CQL engine, deployed on-premises and in cloud. Performance at scale is where we focus.
We report HEDIS measures too. Is that a separate implementation?
No. Same engine, same CQL layer, different measure artefacts. Plans, and the vendors reporting on their behalf, run HEDIS® and CMS measures through one deployment.
Why Firely
- We maintain the CQL engine this runs on. The open-source .NET CQL SDK is ours. It has been tested against current CMS and NCQA measure content, and when the logic does something unexpected, you can read the code and so can we.
- We helped build the standard this runs on. Firely's team contributes to HL7 FHIR and its implementation guides. You are working with the specification, not with one vendor’s reading of it.
- The industry builds on our tooling. The Firely .NET SDK has passed 5 million downloads, across 13 years of FHIR work and more than 32,000 commits.
- We teach this work. Our course Implementing CQL based Quality Measures covers measure logic, data requirements, testing and reporting. Because CQL is approachable and operationalizing it across measure sets, data quality and governance is where teams actually get stuck.
- Nothing is a black box. Open CQL artefacts in, FHIR MeasureReports out, and a documented path from a number back to the patients behind it.
Ready to run your CMS measures on FHIR?
You do not need to change how you report. Start with one program and a handful of measures, check the numbers against what your current system produces, and widen from there.
In 30 minutes we will walk through which programs you report, where your data sits today, and what running those measures on FHIR would actually take. No commitment.