With Cerner you can use both, and the right choice follows the shape of the data flow rather than the age of the standard. HL7 v2 through Cerner Open Integration is event-driven: the EHR pushes a message the moment something happens — a patient is admitted, an order is placed, a result comes back — which is why ADT, ORM and ORU feeds still run on it in almost every production estate. FHIR through the Ignite APIs is request-driven: your application asks for data when it needs it, in a user or patient context, which is what app-style integrations and SMART-launched tools require. If your integration needs to know about events as they happen and at volume, v2 is still the correct engineering answer. If it needs to read or write specific records in response to a user action, FHIR is. Choosing FHIR for an event feed because it is newer is a common and expensive mistake.
The Short Answer: Match the Standard to the Data Flow
The industry line is “FHIR is the future, v2 is legacy,” and it’s a convenient framing that’s wrong for a lot of real production work. Age isn’t the variable that should decide this. The shape of your data flow is: is it event-driven, pushed the instant something happens, or is it request-driven, pulled on demand in response to a user or app? Get that answer right and the standard picks itself.
What HL7 v2 Does Well (and Still Owns)
HL7 v2, a standard dating back to 1987, is still running in more than 95% of U.S. hospitals — and that’s not inertia, it’s because event-driven clinical messaging is exactly what it was built for. Admit-discharge-transfer feeds, orders, results, scheduling updates: these are events that a downstream system needs to know about the moment they happen, at real hospital volume, and Cerner Open Integration is how that traffic moves through an Oracle Health environment. The tooling around v2 — interface engines, established message-handling patterns, decades of production hardening — is mature in a way FHIR simply hasn’t had time to become yet for this specific job.
What FHIR R4 Does Well
FHIR is the right tool when your integration is request/response and resource-oriented — an app asking “what does this patient’s problem list look like right now” rather than needing to be told the instant it changes. It’s web-native, which means modern tooling and modern engineers can pick it up fast, and it’s what SMART on FHIR app launches and user-context integrations are built around. Oracle Health’s Ignite APIs implement FHIR R4 against US Core profiles, which is the practical entry point if this is the pattern your integration needs.
A Side-by-Side Comparison
| HL7 v2 (Cerner Open Integration) | FHIR R4 (Ignite) | |
|---|---|---|
| Data flow model | Event-driven push | Request/response pull |
| Best fit | High-volume clinical messaging: ADT, orders, results | App-style, user- or patient-context integrations |
| Tooling maturity | Decades of production hardening, established interface engines | Modern, web-native, growing fast but younger |
| Typical use case | Real-time bed status, lab result feeds, scheduling updates | SMART-launched apps, patient portals, on-demand data pulls |
Five Real Scenarios and the Right Answer for Each
- A lab result feed into a data warehouse → v2. You need every result the moment it posts, at volume, without polling.
- A patient-facing app pulling the problem list → FHIR. Request-driven, user-context, exactly what SMART on FHIR was designed for.
- A real-time bed and ADT status board → v2. This is the textbook event-driven use case.
- A clinical decision-support tool launched in-chart → FHIR (SMART). It needs patient and encounter context at the moment a clinician opens it, not a standing event feed.
- Writing a note back into the record → FHIR, through a governed write scope. I go into exactly what that governance looks like in a full breakdown of write-back integration (Epic-specific detail, but the governance pattern transfers directly to Cerner).
Notice the pattern: it’s never about which standard is “better.” It’s about which one matches the actual shape of what you’re trying to move.
When You Need Both
Most real production Cerner integrations end up hybrid — an interface engine handling the v2 event traffic alongside a FHIR client for the app-style reads and writes, because most real healthcare software touches both kinds of data flow eventually. I go through when standing up an actual integration engine is worth the operational overhead, and when it isn’t, in a dedicated comparison of Mirth Connect against building the integration layer directly.
What This Means for Cost
Here’s a correction worth making plainly: the standard you pick isn’t what actually drives integration cost. Message volume, mapping complexity, and environment access are what drive cost — and those apply whether you’re building against v2 or FHIR. Picking FHIR because it feels modern doesn’t make a complex mapping simpler, and picking v2 because it’s established doesn’t make environment access faster. I go deeper into what genuinely moves the number in a full breakdown of what actually drives HL7 and FHIR integration cost.
Next Steps
Start every Cerner integration conversation with the data-flow question — event-driven or request-driven — before you pick a standard, and most of the architecture decisions after that follow naturally. If you want the deeper walkthrough on either side, I’ve covered the practical FHIR integration process and what an actual Cerner build looks like separately. Or talk to our team directly about which pattern fits the workflow you’re trying to build.