Cerner FHIR API Integration Guide: What's Different from Epic

Cerner vs. Epic: The FHIR Difference That Matters

Both Cerner (now Oracle Health) and Epic expose FHIR R4 APIs, but their implementations diverge in ways that matter. Teams who build for Epic and then port to Cerner typically discover profile differences large enough to require a separate mapping layer.

Getting Access: Cerner Code

Cerner's FHIR APIs are accessed through the Cerner Code developer program (code.cerner.com). Unlike Epic's App Orchard, Cerner Code is more open — you can register an application, get sandbox credentials, and start making calls the same day.

The sandbox environment (fhir-ehr.sandboxcerner.com) uses synthetic patient data and supports all major FHIR R4 resource types. Early prototyping is significantly faster than with Epic.

Authentication: SMART on FHIR with Cerner-Specific Details

Cerner uses SMART on FHIR but with important differences from Epic:

1. Authorization endpoint: Must be discovered via /.well-known/smart-configuration — never hardcode it
2. Token lifetime: Cerner access tokens expire after 570 seconds (9.5 minutes) — much shorter than Epic's 8 hours
3. System scopes: Cerner supports system/ scopes for server-to-server integrations that Epic doesn't enable by default

// Discover Cerner's auth endpoints dynamically
const smartConfig = await fetch(
    `${cernerFhirBaseUrl}/.well-known/smart-configuration`
).then(r => r.json());

const { authorization_endpoint, token_endpoint } = smartConfig;

Cerner-Specific FHIR Profile Requirements

The most common integration failures come from Cerner's required extensions on standard resources:

• Patient: Requires the US Core Patient profile. Race, ethnicity, and birth sex extensions are mandatory in many configurations
• Observation: Cerner uses a cerner-encounter-id extension to link observations to encounters — generic FHIR code may be rejected
• MedicationRequest: Cerner requires medication coding from their specific code systems; SNOMED CT alone is insufficient

These profile differences are why a middleware translation layer pays off at scale. Your application calls one internal API; the middleware handles Epic profile requirements, Cerner profile requirements, and any future EHR your clients add. See the Epic ↔ Cerner integration reference architecture for how this is structured.

For the comparison between FHIR and older HL7 v2 integrations, see FHIR vs HL7 v2. For Athenahealth's proprietary API model, see the Athenahealth integration guide.

The EHR / EMR Middleware service handles Cerner FHIR alongside Epic — abstracting vendor profile differences behind one internal API.