HL7 FHIR R4 — Fast Healthcare Interoperability Resources, Release 4 — has been the dominant interoperability standard for new health IT integrations since CMS finalized its interoperability rule in 2020. For regional hospitals building or evaluating operational analytics tools, understanding what FHIR R4 can actually deliver for patient flow and bed management is more practical than understanding the standard’s technical architecture in the abstract.
The short version: FHIR R4 makes it significantly easier to build real-time operational data integrations with Epic and Cerner than prior HL7 v2 interfaces allowed. But the practical benefits depend on how the integration is configured and what data types are in scope.
FHIR R4 organizes hospital data into resource types — Patient, Encounter, Location, Observation, Condition, Appointment, and others. For patient flow applications, the most relevant resource types are Encounter (which captures ADT events including admission, transfer, and discharge), Location (bed and unit assignments), and ServiceRequest (which includes OR scheduling events in Epic’s implementation).
These resources are published through FHIR R4 endpoints that Epic and Cerner maintain as part of their standard API offerings. An application with appropriate OAuth scopes can subscribe to event notifications — rather than polling for changes — using FHIR’s Subscriptions mechanism. This means a patient flow tool can receive notification of a new bed assignment, a discharge-readiness flag from the care-management workflow, or an OR case completion within seconds of the event occurring in the EHR.
For bed management specifically, this event-driven architecture is what enables a 15-minute rolling prediction loop. The prediction model does not need to query the EHR repeatedly — it receives the events as they happen and updates its forecast in near real time.
The FHIR R4 endpoints are present in most current Epic and Cerner installations, but not all resource types and scopes are enabled by default. A hospital implementing a patient flow integration typically needs to configure three things with their Epic or Cerner administrator:
Most regional hospitals running Epic or Cerner have existing HL7 v2 interfaces built for specific integrations — Teletracking bed management, laboratory systems, pharmacy systems. These interfaces work, but they are brittle. HL7 v2 message formats require custom parsing code for each integration, and changes to EHR configuration often break existing v2 interfaces in ways that are not immediately visible.
FHIR R4 interfaces are more maintainable because they use standardized resource schemas rather than custom message formats. An Epic version upgrade that modifies an ADT event’s internal data structure will update the FHIR resource accordingly without breaking an application that reads standard FHIR Encounter resources. The same upgrade frequently breaks legacy v2 parsers that were written against a specific Epic message format version.
For new integrations, FHIR R4 is the better choice on a total-cost-of-ownership basis, even when the initial configuration work is more involved than a legacy v2 interface. Teletracking itself has shifted toward FHIR-compatible data exchange in its newer integration offerings, allowing hospitals that already have Teletracking deployed to connect patient flow tools through a FHIR layer rather than maintaining a separate v2 interface.
FHIR R4 integrations involve patient-level data, which requires the same HIPAA compliance framework as any other EHR integration. For operational analytics applications that read ADT events without writing to the clinical record, the data use agreement and BAA structure is straightforward. But health IT and compliance teams should confirm that the integration application’s data retention policy is consistent with the hospital’s minimum-necessary standard for operational data use.
The practical implication is that patient flow prediction tools should use the ADT stream for real-time census computation and discard individual patient identifiers after the relevant bed-assignment event has been processed. Storing identified patient data for historical pattern modeling is technically possible through FHIR R4 but requires a more extensive data governance review than the operational use case warrants. Most regional hospitals are better served by models calibrated against de-identified historical census data rather than retained identified event streams.
