Integrating with Oracle Health (Cerner): What's Different from Epic
Last updated: November 2026
If you have built an Epic integration, about 70% of what you know transfers to Oracle Health (Cerner). The FHIR R4 surface looks similar, HL7v2 feeds use the same message types, and the OAuth dance follows the same SMART on FHIR spec. But the remaining 30% -- developer portal mechanics, FHIR implementation quirks, scheduling patterns, and the VA dimension -- is where teams burn time assuming equivalence.
This page covers the Cerner-specific differences. For the general Epic integration patterns (ADT routing, ORU processing, CDS Hooks), see our Epic integration reference. For HL7v2-to-FHIR field mappings, see the migration guide.
Developer portal: code.cerner.com vs App Orchard
The onboarding experience is noticeably different.
| Dimension | Epic (App Orchard / Connection Hub) | Oracle Health (code.cerner.com) |
|---|---|---|
| Sandbox access | Requires App Orchard registration first | Public sandbox, no approval needed |
| Client ID provisioning | Nightly batch -- wait 24 hours | Near-instant for sandbox |
| Production approval | 4-8 weeks (read-only), 6-14 months (bidirectional) | 2-6 weeks typical, but varies by site |
| Per-site activation | Required at every health system | Required, but lighter process at many sites |
| Proprietary API fees | Vendor Services membership for non-standard FHIR | No separate fee tier for most APIs |
The big practical difference: you can start coding against a Cerner sandbox on the same day you register. With Epic, you are waiting a day for client ID propagation and potentially weeks for App Orchard listing before you touch production-like data. This makes Cerner a better choice for initial prototyping if you eventually need to support both EHRs.
Millennium FHIR: where it diverges
Oracle Health's FHIR R4 implementation (the "Millennium FHIR" surface) is generally closer to the base R4 spec than Epic's, with fewer proprietary extensions. But it has its own patterns.
Pagination. Millennium uses a cursor-based pagination model via the _count parameter and next link in the Bundle. Epic uses similar mechanics, but Cerner's cursor tokens are opaque and expire. If you pause mid-pagination for more than a few minutes, the cursor can go stale and you have to restart the query. Do not store cursors across sessions.
Search parameters. Cerner supports a narrower set of search parameters per resource than Epic. For example, searching Observations by category and date works, but compound searches with code and value-quantity may not be supported on all resources. Always check the CapabilityStatement for a given site -- do not assume because it works on Epic it will work here.
Resource availability by site. This is where Cerner and Epic differ most. Epic sites tend to expose a broad, relatively consistent set of FHIR resources. Cerner sites vary more. A large academic medical center on Millennium might expose 40+ resource types; a smaller community hospital might expose 15. Your app needs to degrade gracefully.
Extensions. Cerner uses fewer proprietary extensions than Epic but still includes some, particularly around scheduling and encounter classification. The urn:oid: identifier patterns differ from Epic's. If you built a FHIR client that strips anything it does not recognize, you will lose data silently from either vendor.
HL7v2 feeds: more consistent, but SIU is the standout
Cerner sites produce more consistent HL7v2 messages across installations than Epic sites. Epic's flexibility means each health system can heavily customize message structure, Z-segments, and field usage. Cerner's Millennium platform constrains this more, which means your HL7v2 parser will need fewer site-specific adjustments.
The one message type where Cerner shines compared to Epic is SIU (Scheduling Information Unsolicited). SIU messages push scheduling events -- appointment booked, rescheduled, canceled, no-showed -- in real time over MLLP.
A typical SIU^S12 (new appointment) from Millennium:
MSH|^~\&|MILLENNIUM|HOSP|YOURAPP|YOURORG|20261101090000-0500||SIU^S12|CTRL001|P|2.5.1
SCH|APPT12345|||||^^^ROUTINE|30|MIN|1||||||PROVIDER^NPI1234567|||CONFIRMED|||20261115100000-0500|20261115103000-0500
PID|1||MRN54321^^^HOSP^MR||DOE^JANE||19850622|F
PV1|1|O||||||1234567^JONES^SARAH^^^MD
AIG|1||1234567^JONES^SARAH^^^MD|ATTENDING
AIL|1||CLINIC-A^ROOM-3^HOSP
Key segments:
- SCH maps to FHIR
Appointment. SCH-11 is the appointment start/end. SCH-25 is the status. - AIG (Appointment Information - General resource) identifies the provider.
- AIL (Appointment Information - Location) identifies the room/clinic.
Epic sites tend to handle scheduling through their FHIR APIs or proprietary Cadence APIs rather than SIU feeds. If your product is scheduling-centric (patient intake, referral coordination, waitlist management), the SIU feed from Cerner is often the most reliable real-time signal.
API endpoint patterns
Cerner's FHIR base URLs follow a predictable pattern:
# Sandbox
https://fhir-ehr-code.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d
# Production (site-specific)
https://fhir-ehr.cerner.com/r4/{tenant-id}
The tenant ID is a UUID assigned per Millennium instance. You will collect one per site, similar to how Epic requires per-site client credentials. Store these in your configuration alongside the OAuth client ID and secret for each site.
Token endpoints:
# Authorization
https://authorization.cerner.com/tenants/{tenant-id}/protocols/oauth2/profiles/smart-v1/personas/provider/authorize
# Token
https://authorization.cerner.com/tenants/{tenant-id}/protocols/oauth2/profiles/smart-v1/token
Access tokens from Cerner typically expire in 570 seconds (9.5 minutes), which is slightly longer than Epic's 5-minute window. Still short enough that you need proactive refresh logic. See the token management section in our Epic lessons post -- the same patterns apply.
VA considerations
The Department of Veterans Affairs is running Oracle Health (Cerner) at a growing number of sites, replacing the legacy VistA system. If you are building for the VA ecosystem, you need to know:
Which system is the target? The VA's Cerner deployment (branded "Oracle Health Federal") is rolling out site by site. Some VA facilities are on VistA, some are on Cerner, and some are mid-migration. Confirm the target system before you design anything.
Federal compliance requirements. VA integrations require FedRAMP authorization for any cloud components that touch VA data. FISMA controls apply. This is not a checkbox exercise -- FedRAMP authorization takes 6-18 months and significant investment. If your product is not already FedRAMP-authorized, factor that into your timeline before the integration work even starts.
API endpoints are different. VA's Cerner instance uses separate API endpoints from commercial Cerner sites. The Lighthouse API platform (developer.va.gov) provides the FHIR-based access layer for VA data, with its own OAuth registration and approval process.
Data sensitivity. VA patient data includes service-connected disability ratings, combat exposure flags, and behavioral health records that carry additional handling requirements under 38 CFR. Your data model needs to accommodate these, and your access controls need to respect them.
Practical differences at a glance
| Dimension | Epic | Oracle Health (Cerner) |
|---|---|---|
| Sandbox friction | Moderate (App Orchard + 24h client ID delay) | Low (public sandbox, instant access) |
| FHIR extensions | Heavy use of proprietary extensions | Closer to base R4 spec |
| HL7v2 consistency across sites | Highly variable | More standardized |
| Scheduling integration | FHIR APIs or Cadence | SIU feeds widely available |
| Token lifetime | ~5 minutes | ~9.5 minutes |
| Per-site variation in resource availability | Moderate | Higher |
| VA pathway | N/A | Yes (Oracle Health Federal + Lighthouse) |
What this means for multi-EHR products
If you are building a product that needs to work across both Epic and Cerner, the pragmatic approach: build your core data model against US Core FHIR profiles (not either vendor's extensions), use HL7v2 for real-time feeds from both (the message structures are more similar than the FHIR surfaces), and maintain per-vendor adapter layers for authentication, pagination, and extension handling. Do not try to build one generic FHIR client and point it at both vendors. It will work in the sandbox and fail in production.
For the HL7v2 side, the migration guide covers the segment-to-resource mapping that works across both vendors. For integration engine options to manage multi-EHR pipelines, see our engine comparison.
If you are building a Cerner integration and coming from an Epic background -- or planning to support both -- we can walk you through the specific differences for your use case. Reach out here.