Overview
FHIR R4 (Release 4, version 4.0.1) is the first normative release of the Fast Healthcare Interoperability Resources specification and is the baseline version required by essentially every major US healthcare interoperability regulation. Published by HL7 in late 2019, R4 stabilized the core FHIR resources and data model so that implementers could build to a non-breaking baseline; prior releases (DSTU2, STU3) made significant breaking changes across versions and are not suitable for regulated production use.
FHIR as a standard represents a fundamental architectural departure from HL7 v2 messaging. Where v2 used pipe-delimited messages over MLLP links, FHIR uses RESTful HTTP APIs with JSON or XML representations of modular resources (Patient, Encounter, Observation, MedicationRequest, Claim, etc.). This API-first architecture enables modern web and mobile application development to connect to healthcare data in ways that v2 messaging could not practically support.
R4 contains approximately 145 resource types covering clinical, administrative, financial, and workflow domains. Core clinical resources (Patient, Practitioner, Encounter, Condition, Observation, Procedure, MedicationRequest, AllergyIntolerance) are normative — their structure will not change in future releases without formal deprecation processes. Many workflow and specialized resources remain in trial-use status and may evolve.
The ONC Cures Act regulations require certified EHR technology to expose patient data via FHIR R4 APIs. The USCDI (United States Core Data for Interoperability) defines the data elements that must be exposed; FHIR R4 is the technical standard used to expose them. Patient-access apps built on this infrastructure can pull a patient's clinical data across EHR vendors using a uniform API.
CMS regulations (Patient Access API, Provider Directory API, Payer-to-Payer API, Prior Authorization API) all require FHIR R4. The Da Vinci Implementation Guides that govern these APIs layer specific profiles on top of base R4 resources to define payload structures for each use case.
For RCM vendors and EHR operators, FHIR R4 capability has become a baseline expectation. Integration conversations that once centered on HL7 v2 interfaces now routinely specify FHIR R4 endpoints. v2 remains prevalent in internal hospital workflows (ADT feeds, lab orders, pharmacy orders) but external integration with patient apps, payers, and registries has largely transitioned to FHIR.
Version successors (R5, R6) are in various stages of development. R5 released in 2023 with incremental improvements but limited US regulatory adoption; R4 remains the compliance baseline through at least the mid-2020s and likely into the late decade.
From a board-reporting standpoint, FHIR R4 (Release 4) belongs in the compliance committee's quarterly dashboard. The reporting line should include volume, exception rate, and any open remediation action; reviewers tie FHIR R4 (Release 4) metrics to the broader compliance program KPIs so an emerging FHIR R4 (Release 4) risk surfaces before it becomes a formal finding. Pairing the FHIR R4 (Release 4) trend with fhir api gives the committee a single view of whether the control environment is strengthening or drifting.
Industry benchmark
ONC Cures Act certification requires FHIR R4 API exposure as of 2023. 100% of certified EHRs now support FHIR R4 Patient Access endpoints. US Core R4 Implementation Guide defines required US-specific profiles.
Worked example
An EHR vendor exposes FHIR R4 Patient Access endpoints for 2,400 hospital clients. A patient-facing app uses the FHIR R4 Patient and Observation resources to pull lab results across hospitals the patient has visited. The app authenticates with SMART on FHIR OAuth scopes; data returned conforms to US Core R4 profiles.
Frequently asked questions — FHIR R4 (Release 4)
Why R4 specifically vs other FHIR versions?
R4 is the first normative FHIR release — prior versions (DSTU2, STU3) had breaking changes across revisions. R4 provides stability for regulated production use; R5 (2023) adds incremental improvements but is not yet the US regulatory baseline.
Does FHIR R4 replace HL7 v2?
Gradually. v2 remains prevalent in internal hospital workflows; external integration with patient apps, payers, and registries has largely moved to FHIR. Full v2-to-FHIR transition is a multi-decade trajectory.
What are FHIR profiles?
Profiles are constraints that specialize a base FHIR resource for a specific use case. US Core defines US-specific Patient profile with required fields; Da Vinci CRD defines profiles for coverage-requirements-discovery workflows. Profiles enable interoperability without bloating the base spec.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.