Use Case: CMS Measures
Run your CMS quality measures on FHIR data with Firely dQM. 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 release cycle between you and a specification change.
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.
Know where you stand mid-period
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 already 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.
None of the specifics are settled: no submission format change this year, no industry-wide deadline set by CMS, and the one set of dates that do exist sit inside a consultation about one program. What is settled is the direction, which no CMS document has contradicted since 2022.
You are not starting from zero
Certified EHRs already share data through a standard FHIR interface. That is a head start, though not the whole answer: hospital measures especially need detail a standard feed does not carry, like when a medication was actually given rather than just ordered.
When you must submit in FHIR. That is the question CMS has not answered. It is not the question of whether the data exists.
So the work is the same either way. If CMS moves on schedule, you are ready. If CMS takes longer, you still see where you stand during the period, and that is the part you cannot get today.
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
Miss Inpatient Quality Reporting requirements and you lose a quarter of your annual payment update. Miss Promoting Interoperability too and the rest of it goes with it. Both programs run on the same eight eCQMs, all four quarters, one deadline.
Up to the full annual payment update
A sliding scale
MIPS and MVPs
The 2026 performance threshold is 75 points. Fall below it and the cut reaches 9% of Medicare Part B payment. Clear it and the bonus is small: the program is budget-neutral, and a perfect score paid 1.05% this year.
Up to a 9% cut 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 proposed a new Medicare eCQM option starting in 2027. It would let ACOs report on their Medicare patients only, instead of every patient they serve, a much lower 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 helped build the standard this runs on. Firely's team contributes to HL7 FHIR and its implementation guides, and is part of the Digital Quility Implementers Community (DQIC).
- 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.
- 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. The published measure logic goes in, FHIR MeasureReports come out, and every number traces back to the patients behind it.
Ready to run your CMS measures on FHIR?
You do not need to change how you report. 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.