Intro
Dynamic Health IT’s team attended CMS FHIR Connectathon 7, held July 14 to 16, 2026, joining healthcare organizations, technology vendors, standards organizations, and government stakeholders working through some of the industry’s biggest interoperability challenges.
FHIR based quality measurement is moving from a future concept toward practical implementation.
The discussions were no longer focused solely on whether digital quality measures (dQMs) can be represented in FHIR. Increasingly, the questions are becoming more practical: Can organizations retrieve the necessary data at scale? Can different systems calculate the same measure consistently? Is the data actually mapped correctly? And can these workflows reduce, rather than simply relocate, the burden on providers?
Several developments stood out to our team, including the continued transition from QDM based eCQMs to FHIR based dQMs, the emergence of US Quality Core, the new HL7 Quality Improvement Accelerator, and continued progress on FHIR based prior authorization and quality data exchange.
Digital Quality Measures Are Closer to Production Than Many Realize
One of the clearest signals came from the Data Exchange for Quality Measures (DEQM) track, where participants tested the 2025 Annual Update digital quality measures.
The results were encouraging:
- 74 measures
- 3,964 test cases
- 3,891 passing
- 98.16% pass rate
- Only three measures had remaining discrepancies
The measures were authored in MADiE, based on QDM 2025 Annual Update content, and expressed using QI-Core 6. The testing focused on whether the measure content produced the expected results against the reference Java engine used by the CQF VS Code plugin.
That distinction is important. A 98.16% pass rate does not mean every vendor’s implementation will produce identical results. It demonstrates that the underlying measure content and reference implementation are becoming mature. The Connectathon also gave implementers a chance to run the same test cases through alternate measure engines, which will matter more as dQMs move toward broader implementation.
Six measures were exercised in an end to end payer and provider scenario, including:
- CMS122 (Diabetes HbA1c Poor Control)
- CMS124 (Cervical Cancer Screening)
- CMS125 (Breast Cancer Screening)
- CMS165 (Controlling High Blood Pressure) on the eligible clinician side
- CMS71 (Anticoagulation Therapy for AFib/Flutter) and
- CMS1028 (Severe Obstetric Complications) for eligible hospitals.
The transition timeline is becoming clearer
CMS continues to move toward FHIR based digital quality measurement. Discussions at the Connectathon reiterated the direction toward QDM based eCQMs and FHIR based dQMs both being accepted through 2028, with FHIR based dQMs becoming the expected approach beyond 2029.
For anyone involved in quality measurement, that makes the transition difficult to keep treating as a distant project. The question is shifting from “Will we need to support dQMs?” to “How do we implement them reliably?”
What We Tested: Care Insights Against 72 Digital Quality Measures
Our own goal for the week was concrete. We wanted to run the track’s test patients through the Care Insights application and confirm that our measure calculation produced the expected results, measure by measure and test case by test case.
Here is what our discrepancy report showed, generated July 15, 2026:
| Result | Value |
|---|---|
| Total measures tested | 72 |
| Total test cases | 5,826 |
| Measures with discrepancies | 3 |
| Test cases with discrepancies | 4 |
| Measures with no discrepancies | 69 |
| Pass rate | 99.93% |
Breaking that down: zero missing results, zero missing populations, and four mismatched test cases spread across three measures. The engine produced a population and a result for every case it was handed.
The two things that actually broke
The four mismatches traced back to two root causes:
- Patient identifier mapping. How a patient is identified in the incoming bundle has to line up with how the evaluation expects to find that patient. When it does not, the measure quietly evaluates against the wrong slice of data.
- Patient sex crosswalk differences. Sex is a gating element in a number of measures, with cervical cancer screening and breast cancer screening as the obvious examples. Different representations of the same concept across systems produce different denominators, and a denominator difference reads as a calculation discrepancy even when the calculation itself is correct.
After resolving both, we successfully produced results for all measures. Once the measure logic is sound, the remaining risk concentrates in identifiers, terminology crosswalks, and how faithfully the source data was mapped before it left the EHR.
Can FHIR Quality Measurement Scale?
While the measure testing results were encouraging, another discussion highlighted one of the biggest challenges still facing the industry: scale.
Today, registries and quality reporting organizations may need patient level data for populations of 100,000 or more patients. Patient level dQMs are effectively the FHIR equivalent of the data traditionally exchanged through QRDA I. That creates a significant architectural question.
Bulk FHIR can be slow, and some EHR systems limit the number of patients that can be returned in a single request. During the Connectathon, current implementations reported reasonable performance using patient at a time access, retrieving only the data needed for the relevant measures rather than exporting an entire dataset and filtering it afterward.
That may work well in some environments, but what works for a Connectathon dataset will not necessarily work for a six figure patient population. Retrieval strategy affects performance, infrastructure, and the design of the entire quality reporting pipeline.
The broader Next Generation of Quality Measures discussions reinforced that the challenge isn’t limited to retrieval speed. Other issues include:
- Getting FHIR data out of EHRs for large populations
- Measure relevant data that isn’t currently available through FHIR
- Calculation engines that cannot consume or produce data in standardized FHIR formats
- Incorrect mappings within EHRs that result in technically conformant data producing incorrect measure results
In other words, the standards are becoming more mature, but the data infrastructure underneath them still presents significant challenges.
US Quality Core: Connecting Quality Requirements to FHIR
Another major development was the continued work around the US Quality Core Implementation Guide.
USCDI provides a foundation for interoperable clinical data, but it does not contain every data element required for quality measurement. USCDI+ Quality addresses additional data elements needed by quality programs, while US Quality Core provides a FHIR implementation framework for representing those elements.
The current USCDI+ Quality work includes 179 elements across 29 data classes, with the US Quality Core IG mapping these elements to US Core and US Quality Core profiles. A draft version 2 was open for public comment during the Connectathon week and expands that to 188 elements across 30 data classes.
The Connectathon also included testing around the US Quality Core IG and its test kit, which works much like the US Core test kit and includes a basic patient bundle, simulated client, and server conformance testing. The current target is for US Quality Core v1 to enter the September 2026 HL7 ballot cycle.
Prior authorization
The three Da Vinci Burden Reduction guides are now named directly in ONC certification criteria, with specific versions attached:
- (g)(31) HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.1.0, STU 2.1
- (g)(32) HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) Implementation Guide, Version 2.1.0, STU 2.1
- (g)(33) HL7 FHIR Da Vinci Prior Authorization Support (PAS) Implementation Guide, Version 2.1.0, STU 2.1
CRD answers “is prior authorization required for this service?” and returns coverage information through a CDS Hooks system action. DTR answers “what documentation is needed for this prior authorization?” and returns a computable questionnaire plus pre population logic through FHIR Questionnaire and CQL. PAS carries the submission itself and returns the adjudication result as a FHIR ClaimResponse.
The track spent most of its energy on the gap between the design and what implementations are actually shipping, and the sharpest session came from the AMA’s Celine Lefebvre. It was less a technical talk than an argument: being conformant to the Burden Reduction IGs does not mean you have reduced burden.
The specific failure modes:
- Generic questionnaires. A payer can populate very little of a DTR questionnaire and still meet the IG. Pre populating as much as possible is where the value is.
- CRD in the wrong place. Coverage Requirements Discovery is useful during the encounter, while the patient is still in the room.
- Skipping DTR. Running CRD straight to PAS is contrary to both the intent of the IGs and CMS’s intent. There were reports at the track of organizations planning to skip DTR entirely and have PAS return “further documentation needed,” and of a path that bypasses CRD and DTR altogether in favor of the attachment workflow, the single hardest workflow for a clinician to complete. Closing that loophole is a job for the next rule.
- CDEX as an escape hatch. CDEX is drifting toward becoming the default substitute for DTR pre population. It should be the exception and the last resort.
- The IGs end at the decision. There is no FHIR guide for appeals. If PAS returns a denial, the process reverts to manual and time consuming, entirely outside the standard.
- Automating bad criteria. If a payer’s medical necessity criteria are poor, an automated pipeline just delivers poor decisions faster.
PAS version 2.2 adds a claim response reviewer extension that lets the reviewer’s identity and credentials, down to the NPI, travel with the decision. Payer pledges ask for reviewer qualifications to be honored on a voluntary, self reported basis. The standard makes it verifiable. But neither the pledge, the regulation, nor the IG requires the extension be populated. Only about one in three physicians believes the latest round of payer pledges will produce meaningful change.
Two other useful items from the track:
The AMA mapping project is publishing SNOMED CT to CPT maps for the prior auth use case at no cost: as a JSON API returning CPT codes with an equivalence rating, as CSV, and as a ConceptMap for FHIR based mapping. It’s separate from CPT licensing (it assumes you already hold one). This addresses a real gap, since CRD requests often arrive at the payer without enough clinical context, and nobody has agreed on which CPT codes populate the dropdowns.
FAST Security is coming to CDS Hooks. Work is underway to extend CDS Hooks to support FAST Security, including pushing a token in the CRD request and codifying which systems have been registered with whom. Trust establishment today is still manual, still JWT based, and some participants are running security that isn’t acceptable. The CDS Hooks security model needs a review against current RFCs.
Where Dynamic Health IT stands on prior authorization testing
We attended Drummond’s Fireplace testing and attempted a connection, but ran into issues we were not able to resolve during the event.
Our initial prior authorization testing is running through Inferno and through our EHR clients’ payer sandboxes. We will continue to keep an open ear on the status of prior authorization testing across the industry, and we will report back as that picture develops.
Credit where it is due
A big kudos to Jeff Brown for leading such an open and productive discussion on prior authorization during the track. His willingness to open the floor to questions and perspectives from implementers, payers, observers, intermediaries, and providers created exactly the kind of dialogue a Connectathon is intended to foster.
The discussion allowed the real world burden and challenges of prior authorization to be laid out directly by the people experiencing and implementing the process. It also reinforced an important point: we cannot skip over portions of the prior authorization implementation guides simply because they are difficult or create implementation challenges. Those challenges need to be surfaced, understood, and addressed.
Julia Skapik, MD, also brought valuable experience and clinical expertise to the discussion. Her perspective clearly highlighted where the burden of prior authorization exists today, and why true burden reduction requires more than simply moving the existing process into a FHIR based workflow.
Having providers articulate those challenges directly, while implementers and payers are in the room, lets everyone hear the problem firsthand. That is really the purpose of a Connectathon: find the failures, blockers, ambiguities, and design issues rather than hide them, early enough that the community can solve them before they get embedded in production.
CMS is using FHIR for patient assessments for the first time
The Connectathon also highlighted another practical application of FHIR: standardizing the collection and submission of assessment data.
CMS has proposed a new patient assessment instrument, the Inpatient Psychiatric Facilities Patient Assessment Instrument (IPF-PAI), for use in the IPF Quality Reporting Program. The track used the proposed IPF-PAI to demonstrate FHIR based functionality for patient assessment instruments end to end, across three CMS built components:
- CMS Data Element Library (DEL) FHIR API. Provides the assessment instrument in FHIR format, delivered as a FHIR Questionnaire.
- PARIT, the Patient Assessment Reporting Interoperability Tool. A SMART on FHIR web application that renders the questionnaire into a user friendly form, collects responses, and prepares them as a FHIR QuestionnaireResponse. It is free, requires no download, and works for facilities with or without an EHR.
- iQIES FHIR Receiving System. The Internet Quality Improvement and Evaluation System receives the submitted assessment data through the Receiving System API.
The reporting options CMS presented are the part worth studying. An assessment is retrieved from the DEL FHIR API and submitted to the iQIES FHIR Receiving API, but the middle of that path is deliberately open. A facility can use PARIT in a web browser, use PARIT launched from inside an EHR through SMART, or go through vendor provided tools, meaning either a third party vendor platform or the EHR itself.
If assessment instruments are centrally defined and distributed as standardized FHIR structures, EHR vendors collect consistent structured data that is already fit for downstream reporting, and quality reporting organizations get consistent assessment data across EHR environments without a translation layer in the middle.
CMS asked attendees to watch QualityNet and the IPF Quality Reporting Program listserv for IPF-PAI and PARIT announcements, including the FY 2027 IPF PPS final rule.
A New HL7 Quality Improvement Accelerator
Another development that caught our attention was HL7’s new Quality Improvement Accelerator. HL7 has many “accelerator” programs, but this is the first centered around quality.
HL7’s board has approved the launch of the Accelerator, with ten organizations submitting Letters of Intent, including CMS, CDC, VHA, NCQA, Firely, and others. The purpose is broader than creating another implementation guide. It is intended to bring stakeholders together to develop shared FHIR solutions around quality improvement rather than having each organization independently solve the same interoperability problems.
The formation process is now underway, with organizations that sign the Statement of Understanding by September 30, 2026 eligible to be considered founding members and participate in the Formation Phase.
Data quality: PIQI
One of the more interesting developments was the Patient Information Quality Improvement (PIQI) Framework, which we’ve mentioned before on this blog. The premise is simple: exchanging data in FHIR doesn’t automatically mean the data is good.
PIQI is designed to provide a common approach for evaluating and improving the quality of patient information regardless of the format in which it is exchanged. Its design includes a simplified patient information model, a healthcare data quality taxonomy, and configurable evaluation profiles.
The project is also moving toward a more open model through the PIQI Alliance and engagement with HL7. The team notes also highlighted PICQL, a library intended to run CQL against PIQI.
As healthcare organizations exchange more data through APIs, the industry needs ways to evaluate not just whether data can be exchanged, but whether the data is complete, valid, usable, and appropriate for the intended purpose. FHIR solves a major part of the interoperability problem. It doesn’t eliminate the classic “garbage in, garbage out” problem.
What We’re Taking Away
CMS FHIR Connectathon 7 reinforced a broader shift taking place across healthcare interoperability.
FHIR based digital quality measurement is becoming real. Our results and the track’s both show measure content reaching a maturity where implementation, not specification, is the primary challenge. Organizations still leaning on QDM based eCQMs should be planning now rather than waiting for the transition to become mandatory.
The failures worth finding are in the plumbing. Identifier mapping and terminology crosswalks accounted for every discrepancy we hit. Having a FHIR API does not mean an organization has all the data a measure needs, or that the data is mapped correctly. That is where we would tell anyone else to look first.
Scale remains an open question. Patient level measurement across tens or hundreds of thousands of patients is a different problem than testing a handful, and it needs to be tested against real populations rather than assumed.
The quality data model is becoming more defined. USCDI+ Quality and US Quality Core are meaningful steps toward standardizing the additional information digital quality measurement actually requires.
Interoperability needs to reduce burden, not just digitize it. This is clearest in prior authorization, where pre-population and clinical workflow integration are what deliver the intended benefit. It is also why data quality is now inseparable from interoperability: exchanging standardized resources is only valuable if those resources contain accurate, usable information.
For healthcare technology vendors and organizations involved in quality reporting, now is the time to understand what that future requires and begin testing against it.