Every vendor in healthcare software claims to integrate with Epic. Most of those claims are technically true at a surface level and operationally misleading in practice. What matters is not whether a connection exists, but what data flows across it, at what latency, with what reliability, and through which integration pathway your IT team will be responsible for maintaining.
The Three Integration Pathways: What They Mean for Flow Analytics
Epic organizations have three primary pathways through which external applications can receive patient data: HL7 v2 ADT feeds via Epic Bridges, HL7 FHIR R4 APIs (either via Epic's native FHIR server or through the App Orchard / MyChart SMART on FHIR framework), and direct database access via Epic Cogito (the data warehouse). Each pathway has distinct characteristics relevant to patient flow analytics.
HL7 v2 ADT via Bridges: This is the most commonly used integration pathway for real-time patient flow applications. Epic Bridges is Epic's interface engine, which can be configured to send outbound ADT messages to external systems. For patient flow analytics, the relevant message types are A01 (admit/visit notification), A02 (transfer a patient), A03 (discharge a patient), A04 (register a patient — often used for ED registration), A08 (update patient information — used for ADT record corrections and status changes), and A11 (cancel admit/visit notification). The ADT v2 pathway is well-established, widely supported by interface teams, and produces near-real-time event notifications — typically latency of under 30 seconds from event occurrence to message delivery.
HL7 FHIR R4 APIs: Epic's FHIR R4 server exposes standardized resources including Patient, Encounter, Location, and Observation. FHIR APIs are the preferred pathway for applications built on the App Orchard framework or for use cases requiring bidirectional data exchange (not just outbound feeds). For read-only operational analytics, FHIR R4 offers cleaner resource modeling than v2 ADT — the Encounter resource contains status, period, location, and participant information in a structured JSON format without the segmented parsing complexity of v2 messages. The tradeoff is that FHIR API polling at short intervals generates higher query load than event-driven ADT feeds. Epic's FHIR Subscriptions (notifications) capability addresses this by pushing change notifications rather than requiring polling, but Subscription support varies across Epic versions.
Cogito data warehouse: Epic Cogito is a SQL-accessible data warehouse that contains historical and near-real-time operational data derived from the transactional Epic environment. Cogito is excellent for retrospective analytics, trend reporting, and dashboard development — it is the foundation of Epic's own reporting dashboards and is queryable by organizations with appropriate access. For real-time patient flow applications, Cogito is less suitable because data pipeline latency from the transactional system to the warehouse can range from 15 minutes to several hours depending on configuration, which is too slow for live bed management decisions.
ADT Message Events: What Each Type Contains
For CIO and CMIO readers who haven't worked closely with HL7 v2 ADT message content, a brief primer on what each event type contains is useful for understanding what a flow analytics platform can derive from ADT feeds alone.
A01 - Admit/Visit Notification: Triggered when a patient is admitted to an inpatient bed or an ED encounter is initiated. Contains: patient identification (PID segment — name, DOB, MRN), patient visit details (PV1 segment — assigned bed, admission type, attending provider, admission datetime). For ED flow analytics, the A01 captures ED arrival registration and bed assignment.
A02 - Transfer a Patient: Triggered when a patient moves from one location to another. For patient flow analytics, A02 messages capture ED-to-inpatient transfers (the physical movement that ends the admit-to-bed interval), as well as unit-to-unit inpatient transfers. The prior and new location are both present in the PV1 segment, enabling accurate bed assignment tracking.
A03 - Discharge a Patient: Triggered at discharge. Contains discharge datetime and discharge disposition. This event triggers bed turnover workflows (EVS notification in integrated environments) and closes the ED LOS or inpatient LOS interval. A03 messages are critical for accurate census calculation — a patient who has left the building but whose A03 hasn't been processed creates a phantom census overcount.
A08 - Update Patient Information: A general-purpose update event triggered by demographic corrections, insurance updates, or clinical status changes. A08 messages are the noisiest event type by volume in most Epic environments — a single encounter may generate dozens of A08 messages for minor record updates. Flow analytics applications must handle A08 messages efficiently without treating every update as a meaningful flow event.
A11 - Cancel Admit/Visit Notification: Triggers when an A01 is reversed — a patient who was admitted is returned to a prior status. These messages are important for accurate real-time census: without A11 processing, a cancelled admit continues to count against census until a subsequent event resolves it.
Practical Latency Considerations for Real-Time Flow Analytics
The latency question for a patient flow analytics platform is not "can you receive ADT messages" but "what is the end-to-end latency from clinical event to actionable display in your platform." The chain has multiple links: time from nurse documentation or physician order to ADT event generation in Epic, time from Epic Bridges processing to message delivery, time from message receipt to database ingestion, time from ingestion to dashboard refresh.
In a well-configured environment, the Epic-to-delivery latency for ADT v2 via Bridges is typically under 60 seconds. Interface processing and delivery adds another 15–30 seconds. Database ingestion and dashboard refresh in a well-architected analytics platform adds another 15–60 seconds. End-to-end latency of 2–3 minutes from clinical event to visible dashboard update is achievable and sufficient for bed management and census coordination use cases, where actions are taken on a minute-to-minute timescale, not a second-to-second one.
We're not saying that sub-minute latency is unachievable — it is, with more complex streaming architectures. We're saying that for ED boarding management, bed placement decisions, and census tracking, 2–3 minute latency is operationally sufficient and that pursuing lower latency by complicating the integration architecture introduces reliability tradeoffs that are usually not worth the operational benefit.
Epic App Orchard: Context and Appropriate Use
Epic's App Orchard is a marketplace of third-party applications that integrate with Epic via SMART on FHIR and Epic-published APIs. App Orchard applications go through Epic's review process before listing, and App Orchard listing signals a baseline level of Epic API compatibility validation.
For patient flow analytics, App Orchard context is valuable primarily for applications that need to display within Epic's interface (embedded dashboards visible to clinicians inside their Epic workflow) rather than for standalone operations center displays used by bed control coordinators. A standalone patient flow dashboard in a capacity command center doesn't require App Orchard listing — it connects directly to ADT feeds or FHIR APIs through standard interface agreements. The distinction matters because some hospital IT teams default to requiring App Orchard listing for all Epic integrations, which creates an unnecessary barrier for operationally viable integration patterns that don't require embedded Epic UI.
Cerner Oracle Health, Meditech, and Allscripts Patterns
The ADT integration patterns described above translate directly to Cerner Oracle Health environments, where HL7 v2 ADT feeds are available via Cerner's interface engine (typically Cerner CareAware or a standard Mirth Connect / Rhapsody intermediary). The same A01/A02/A03/A08/A11 event types apply. Cerner Oracle Health also exposes FHIR R4 APIs aligned with USCDI requirements following the 21st Century Cures Act mandate for certified EHR technology.
Meditech Expanse generates HL7 ADT feeds through its Bridges-equivalent interface layer, with event coverage that varies by module configuration. Allscripts Sunrise and Allscripts Paragon support standard ADT feed generation with similar event type coverage. The normalization challenge — converting ADT feeds from different EHRs into a consistent operational data model — is where analytics platform architecture matters. A platform that has hardcoded Epic-specific field mappings will require significant reconfiguration for a Cerner or Meditech implementation; a platform built around a normalized ADT schema with EHR-specific mapping layers handles multi-EHR health system environments more gracefully.
What to Ask Before Integration Scoping
Before beginning integration scoping with any patient flow analytics vendor, hospital IT teams benefit from having answers to four questions: (1) Which ADT event types are currently configured for outbound delivery via your EHR interface engine, and are they all firing reliably in production? (2) What is the current interface load on your Bridges or equivalent system, and is there capacity headroom for an additional outbound feed? (3) Does your organization have existing FHIR R4 API consumption in production, and if so, what authorization model is in use? (4) Is a BAA with the analytics vendor required before data connection discussions, and who in your organization owns BAA execution?
Mediflowly's integration team conducts a technical intake session before any scoping to map your specific EHR configuration — Epic version, interface engine setup, currently active ADT event types — to our data ingestion architecture. If you're at the early stages of evaluating a flow analytics platform and want to understand the integration work involved in your environment, request a technical demo with our integration team.