Interoperable EHR platforms and FQHC FHIR reporting: what UDS+ reveals about your EHR infrastructure

For more than two decades, federally qualified health centers (FQHC) have filed their Uniform Data System (UDS) reports the same way: aggregate counts in fixed tables, submitted through HRSA’s Electronic Handbooks. The data was standardized. The process was familiar. And for most health centers, it ran on the strength of institutional memory, a capable analyst, and a spreadsheet.

That era is over.

In 2024, HRSA-funded health centers served more than 32.4 million patients across over 16,200 service delivery sites, with approximately 90% of those patients living at or below 200% of the federal poverty level. Medicaid and CHIP together accounted for approximately 48.6% of patients at program awardees making these health centers structurally dependent on the federal payer infrastructure in a way that most provider types simply are not. UDS is the mechanism HRSA uses to demonstrate the value of that investment to Congress. It is also the mechanism through which funding levels are justified, monitored, and renewed.^[1]

Beginning with calendar year 2024 data, HRSA now requires all health centers including awardees and look-alikes alike to submit de-identified patient-level data through HL7 FHIR R4 standards as part of the UDS+ program^[2].The legacy aggregate report did not disappear; it still has to be filed by February 15 each year. But alongside it, health centers must now deliver structured, patient-level FHIR data to a federal data receiver.^[3] The CY2024 UDS+ submission deadline was May 30, 2025. Failure to submit a timely, accurate, and complete UDS report may result in conditions being placed on a grant award and restriction of all drawdowns of Health Center Program funds.

The question facing every FQHC CIO right now is not whether their organization can complete a UDS+ submission. The question is whether their EHR platform is built in a way that makes FHIR-based data obligations manageable at scale or whether every new federal mandate becomes another emergency workaround.

Understanding the technical demand matters before evaluating any vendor’s claims about readiness.

UDS+ is built on HL7 FHIR R4. The Implementation Guide^[4], published by HRSA’s Bureau of Primary Health Care (BPHC) and based on FHIR 4.0.1, specifies the exact resources, profiles, and workflows required for compliant submission. At a high level, the process involves four capabilities that must exist natively in, or be supported by, the health center’s EHR environment.

• The EHR platform must identify and group the relevant patient population using FHIR’s Group resource and standard APIs.
• It must support Bulk data Access, specifically the $export operation, to extract patient-level data across that population at scale.
• It must generate required FHIR resource types accurately, including Patient demographics with race and ethnicity coded to the CDC race code value sets, Encounter records, and Observation resources for clinical quality measures.
• It must de-identify the extracted data according to HRSA’s defined protocol before transmission.
• Transmitting the manifest file to HRSA’s data receiver using the $import operation over authenticated FHIR APIs — requires the health center and its EHR vendor to complete a formal onboarding process with HRSA, including security registration, IP whitelisting, and synthetic data testing.

HRSA has acknowledged that the majority of health centers will need to work through their HIT vendors to complete UDS+ submissions.

Each step depends on the previous one. A gap at any point — an EHR platform that produces incomplete FHIR resources, a Bulk data implementation that cannot handle population-level exports reliably, a de-identification layer bolted on outside the core system — creates friction that compounds under audit scrutiny.

The transition to UDS+ has surfaced an infrastructure gap that predates the mandate itself. For health centers operating on legacy or partially modernized EHR platforms, FHIR readiness was never a design principle. It was something to be patched in later — through middleware, API wrappers, or vendor-supplied integration modules that approximate FHIR compliance without being built on it.

The distinction matters in practice. An EHR platform that stores clinical data in proprietary formats and maps it to FHIR on export faces two compounding problems.

The first is data quality: the fidelity of the FHIR output is only as good as the underlying data model. If the source system does not capture structured data in the right fields — race and ethnicity codes, standardized clinical observation codes, properly linked encounter records — the FHIR export reflects those gaps. A patient whose race is recorded as a free-text note rather than a coded value does not translate cleanly into a FHIR Patient resource conformant with the UDS+ Implementation Guide.

The second problem is operational. Every new FHIR-based mandate requires the health center’s IT team to re-examine how the workaround holds up against the new requirement. That is not a sustainable posture when the federal regulatory pipeline is producing new FHIR obligations on an accelerating timeline.

Industry analysis has been direct on this point: health centers whose EHR platforms lack automated FHIR-based data extraction face a reporting burden that is unsustainable without significant additional staffing. That assessment was made before the CY2024 submission became mandatory. It is more relevant today, not less.

Vendor marketing has made ‘FHIR-ready’ nearly meaningless as a standalone claim. Every major EHR platform has some FHIR story. The relevant question for a Health IT leader evaluating platforms is what layer FHIR operates at in the underlying system.

A genuinely FHIR-native architecture stores and manages clinical data in structures that map natively to FHIR resources. Patient demographics, encounters, observations, conditions, and medications are not post-processed into FHIR — they are FHIR-shaped from the point of capture. The ONC 21st Century Cures Act Final Rule adopted the HL7 FHIR Bulk data Access API as a required component of certified health IT^[5], enabling population-level data extraction — a requirement that has been in effect since 2023. An EHR platform whose Bulk data capability was built to satisfy ONC certification rather than as a core architectural feature will show the difference under operational load.

In contrast, an EHR platform with a FHIR layer grafted onto a legacy relational database produces output of variable completeness. The implementation may pass basic API conformance tests while still generating FHIR resources with missing elements, incorrect code bindings, or population-level export performance that degrades at the scale an FQHC with tens of thousands of patients requires.

Use this in any vendor conversation — whether you are evaluating a new EHR platform or pressure-testing your current one. The answers separate genuine architectural readiness from marketing positioning.

1. Does the system support the $export Bulk data operation natively?

What you need to hear: native support within the core EHR data layer, not through a third-party integration module or middleware. Ask the vendor to demonstrate a population-level $export against a test dataset and confirm the output is NDJSON-formatted FHIR. If the answer involves a separate tool or vendor partner, the capability is not native.

2. How does the system handle race and ethnicity coding at the data capture level?

The UDS+ Implementation Guide requires Patient resources with race and ethnicity extensions conformant to the CDC race code value set. If your EHR stores race and ethnicity as free-text, dropdown labels, or custom codes that map to FHIR only at export, the de-identified output will be incomplete or non-conformant. Ask where in the workflow the CDC codes are applied — at capture, or at translation.

3. Has the vendor completed HRSA onboarding for UDS+ FHIR-based submission, or begun the process?

HRSA requires EHR vendors and health centers to complete a formal onboarding process before any live submission — including security registration, IP whitelisting, client credential issuance, and synthetic data testing. A vendor who has not started this process cannot support your CY2025 UDS+ submission regardless of what their FHIR capability looks like on paper.

4. What version of FHIR does the platform’s core data model support?

FHIR R4 is the current UDS+ requirement. FHIR R5 is the most recent release and the direction federal standards are heading. An EHR platform running on R5 architecture is positioned for forward compatibility. Ask which version the platform was built on, not which version it can export to.

5. What is the vendor’s roadmap for TEFCA and CMS Prior Authorization API compliance?

UDS+ is not the last FHIR mandate your organization will face. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), finalized in January 2024, is projected to generate approximately $15 billion in savings over 10 years by digitizing prior authorization workflows. FHIR API compliance deadlines under that rule run through January 2027. Ask the vendor for specific implementation timelines, not assurances.

UDS reporting is the primary mechanism through which HRSA demonstrates to Congress how Section 330 grant funds are being used. For FY 2023, Section 330 funding totaled more than $5.7 billion. The data submitted through UDS directly informs patient target assessments and funding levels. Errors, inaccuracies, or incomplete submissions create financial risk and an inaccurate picture of a health center’s impact.

The consequences of non-compliance are explicit. Failure to submit a timely, accurate, and complete UDS report may result in conditions being placed on a grant award. Health centers that fail to comply with UDS reporting requirements risk losing HRSA grant and federal assistance funding eligibility, and may face penalties, audits, or additional reporting obligations. For look-alike designees, the stakes are identical — UDS compliance is required to maintain the designation.

As UDS+ FHIR-based submission matures toward becoming the primary submission of record, an EHR platform that cannot reliably generate compliant FHIR data is not simply a technical inconvenience. It is a funding risk. Health IT leaders who frame the EHR infrastructure conversation in those terms — rather than as an IT modernization project — tend to move faster and with stronger organizational support.

The FQHC sector is not facing an isolated regulatory event. UDS+ is a visible and urgent expression of a federal policy direction that is broad, consistent, and accelerating.

The ONC 21st Century Cures Act Final Rule adopted the HL7 FHIR Bulk data Access API as a required component of certified health IT feature^[6]
, enabling population-level data extraction across patient populations for public health, research, and reporting use cases. This requirement has been in effect since 2023.

The CMS Interoperability and Prior Authorization Final Rule ^[7] (CMS-0057-F), finalized January 17, 2024, requires Medicare Advantage organizations, Medicaid managed care plans, CHIP, and qualified health plan issuers to implement FHIR-based APIs for patient access, provider access, payer-to-payer exchange, and prior authorization. Non-technical compliance provisions took effect January 1, 2026; full API compliance is required by January 1, 2027. With Medicaid and CHIP together accounting for nearly half of all patient visits at FQHC awardees, virtually every health center is subject to these payer workflows.

TEFCA, the Trusted Exchange Framework and Common Agreement, provides a national on ramp for health information exchange. While participation is not mandatory, it is FHIR-forward in its technical direction, and payers, hospitals, and public health agencies connecting through TEFCA will increasingly expect FHIR-capable counterparts.

The pattern is clear. Federal regulators have chosen FHIR as the interoperability standard for the U.S. healthcare system. The question for a Health IT leader at an FQHC is not whether to engage with FHIR, but whether the EHR platform they are running today — or evaluating for the next five years — is built in a way that makes each new FHIR obligation a routine implementation rather than a crisis.

The opening question this article posed was deceptively simple: does your EHR platform have a real FHIR backbone, or just a FHIR veneer? UDS+ has made that question answerable in practice, not just in theory. For the first time, health centers have had to put their EHR infrastructure through a live, federally mandated FHIR data workflow — and the results have exposed the difference between platforms built on genuine interoperability architecture and those that assembled a FHIR facade to check a certification box.

That difference will only become more consequential. UDS+ is not the end state; it is the opening condition. The federal regulatory pipeline — ONC’s certification requirements, the CMS Prior Authorization rule^[8], TEFCA — is producing FHIR-based obligations on a timeline that leaves no room for infrastructure debt. Health centers that entered the UDS+ era with an EHR designed for FHIR will absorb each new mandate as a routine implementation. Those that didn’t will be re-engineering their data layer under compliance pressure, cycle after cycle.

For Health IT leaders at FQHCs, the decision in front of you is not primarily about UDS+ reporting. It is about whether your organization is positioned to meet the next five years of federal interoperability requirements without treating each one as a crisis. That is an infrastructure decision. And it is a compliance decision.