Lessons from NCQA Summit 2026: the FHIR data you already have

Again and again at this year’s NCQA Health Innovation Summit, someone walked up to our booth, told us that their organization didn’t have any FHIR data, and then paused when we asked who handles their prior authorization interoperability work, realizing their team probably does have FHIR data already.

We heard it from quality teams across the board, including payers, providers, value-based care organizations, and others. We heard it from people who’ve been doing quality measurement for twenty years and from people who got handed a FHIR project a few months ago and told to sort it out.

The pattern was the same almost every time: a lot of organizations have more FHIR data than they realize, and the slowest part of getting ready for digital quality measures is mapping the data.

The FHIR data gap that probably isn’t as big as you think 

That booth exchange points to what’s underneath all of this: interoperability teams and quality teams often aren’t talking to each other. Quality staff don’t always know what’s already been mapped and sitting there for them to use, so the answer to almost every version of “we don’t have FHIR data” started the same way: go talk to your interoperability team. 

If you’re a payer covered by CMS interoperability rules, you likely already have FHIR data somewhere in your organization. Patient Access APIs have been required since CMS-9115-F in 2021, and CMS-0057-F, the prior authorization rule, adds more FHIR APIs from 2027.

If you’re a provider, the same is usually true. If your EHR is ONC-certified, it has had to meet the (g)(10) API requirements, which means it already exposes a baseline set of FHIR APIs, including bulk export for patient populations. Either way, the data often already exists. 

Of course, that’s not universal. If you’re not covered by requirements like these, you might still have FHIR data (e.g. through a health information exchange you participate in, or a vendor that runs on FHIR under the hood), but it may not be something you can assume the way a payer or provider can right now. 

A few people also asked whether the FHIR server converts their existing data automatically once it’s switched on. It doesn’t. The data has to be mapped to FHIR first, but that’s something our consulting team and tooling can help with. 

Important to note that what’s available through prior authorization or a certified EHR is a starting point. It covers only part of what a full measure set needs, so the next step is a gap analysis: list what your interoperability team has already mapped, and what’s still missing. That list shows you how much mapping is left.

From spreadsheets to scalable quality 

That same thread ran through Rich Almeida’s poster session with Denise St. Clair of Global Alliant. Denise described the starting point for the federal programs she’s worked on: Excel spreadsheets uploaded to a web form. 

Rich and Denise’s approach breaks the move to FHIR into three steps: map the data, write and share the CQL so the logic is open for everyone to review, then build and run the FHIR APIs. Some people hear “move to FHIR” and picture a multi-year rebuild. Rich and Denise’s point was that you don’t have to. Start with the data you already have, structured in a spreadsheet if that’s what you’re working with, and convert it to FHIR once it’s properly mapped. As Denise put it: the problem isn’t a spreadsheet, it’s an unmapped spreadsheet. 

It’s the same lesson as the booth conversations, from a different angle. Mapping to FHIR is still real, technical work, but most of the effort comes up front. Rich and Denise’s framing for this was “map once, reuse everywhere”: a mapped data element can serve every measure that needs it, instead of being rebuilt each time a new measure comes along. Mappings still need upkeep as source systems and FHIR profiles change, but you’re not starting over every reporting cycle.

What we showed at the booth 

Erika Bricker, one of our Technical Consultants, ran our dQM demos this year, showing HEDIS measures with patient-level drill-down, the CQL logic behind each measure, and browsable value sets and libraries, all a few clicks away instead of through APIs. 

The biggest reaction came from a simple point. A lot of organizations only run their measures once or twice a year because it’s too slow and expensive to do more often. Seeing measures run on demand, without waiting for the next cycle, changed what a lot of people thought was realistic for their own teams. 

Drilling into a measure showed exactly which patients fell out of it, with the CQL logic and the patient data side by side. For hospitals and providers, a patient falling out of a measure can mean lost revenue, so seeing who dropped out is more than a reporting exercise.

Where this leaves things 

A few years ago, most of these conversations were about whether digital quality measures were actually coming. Nobody at the booth was asking that this year, but that doesn’t mean everyone’s ready. 

For a lot of organizations, this was the year NCQA’s goal of fully digital HEDIS reporting by 2030 started to feel real, and they’re still figuring out what it means for them. A few are further along, already running pilots to see what their data actually looks like once it’s mapped, but most are still at the stage of explaining to their own leadership why this needs attention now, not in three years. 

By the end of the week, one thing was clear: the FHIR standard itself isn’t the barrier. The bigger shift is treating this as a business decision that sits across interoperability and quality teams, rather than handing it to one of them. 

Once the data’s mapped, running measures against it is where a tool like Firely dQM comes in: taking the FHIR data and CQL you’ve already invested in, and running it as digital HEDIS and CMS measures on demand, as often as you need, without rebuilding your process every time a new measure or spec update comes along.

For the fuller picture, our dQM blog series covers the shift from eCQM to dQM and the cost case for making the move. To see how Firely dQM fits into your own plans, visit our digital quality measures page.