Integrate With Oracle Health (Cerner).
The Millennium Platform, code Console registration, SMART on FHIR R4, and the per-tenant "Ignite APIs" activation model that makes Oracle Health different from Epic — mapped by engineers who ship it, not a rebrand press release.
Cerner Is Oracle Health Now — Here's What That Means
Oracle acquired Cerner in 2022, and "Cerner" is steadily becoming Oracle Health. For integration, the target you build against is the Oracle Health Millennium Platform (the rebranded Cerner Millennium EHR), and clinicians launch your SMART app from PowerChart — its table-of-contents column (with patient context) or the Organizer view (without). The good news: the developer plumbing — code Console, CernerCare, the FHIR endpoints — is stable through the rebrand, even though some names still say "Cerner."
Two things make Oracle Health genuinely different from Epic, and both catch teams off guard. First, SMART is still on STU1 (App Launch 1.0.0) — not SMART 2.0 — so don't assume the newer granular scope syntax. Second, and bigger: going live is per-tenant. You register your app once with Oracle, but each customer then has to opt your app in through a Service Request — registration is not activation. Get those two right and Oracle Health is a clean, well-documented FHIR integration.
The Stack — And What You Actually Integrate With
Oracle Health has its own vocabulary. Here's the map, sorted by what a third party connects to versus what lives inside the customer's system. Pick a layer.
The surfaces a third party actually connects to today — all on the Millennium Platform.
The core REST surface — US Core resources on /r4/<tenant>. R4 (4.0.1); DSTU2 is retired.
App Launch 1.0.0 + Backend Services 1.0.1. Flows: EHR launch, contextless (patient), client-credentials (backend).
Where you register the app, test scopes, and get your application ID + client ID. Needs a free CernerCare account.
"Cerner Ignite APIs for Millennium" — the solution each customer files a Service Request against to provision your app to their tenant.
Provider apps open from PowerChart's TOC (patient context) or Organizer (no context) — the clinician entry point.
fhir-open (read-only), fhir-ehr-code (provider), fhir-myrecord (patient) — public sandbox tenants to build against.
Around the FHIR surface sit products you'll hear about but mostly don't self-serve — they're customer- or implementation-gated.
The former HealtheIntent population-health line (also marketed as the AI Data Platform). Exposes RESTful B2B APIs that are explicitly not FHIR, tenant-gated to customers.
Cerner's device-connectivity / medical-device integration layer. Typically arranged through the customer's implementation, not a self-serve developer API.
The operational EHR/database itself. You read/write it through FHIR — you don't touch the database directly.
The clinician application. Relevant as your launch surface, but it's Oracle's client, not an API.
Legacy real-time interfaces still run at most Cerner sites — arranged via the customer's integration team, not the self-serve FHIR program.
Oracle's newest, most-hyped pieces — genuinely new, but not yet third-party integration points. Know what they are so you're not caught out.
An all-new, cloud-native, voice-first EHR on OCI, launched for US ambulatory providers Aug 2025 (ONC-certified late 2025). Separate from Millennium; its third-party surface isn't documented yet.
Oracle's ambient/voice assistant — as of Feb 2026 it drafts orders (labs, imaging, Rx, follow-ups) for clinician review. An Oracle-native capability, not a third-party API.
Oracle Cloud Infrastructure — where the new EHR and Oracle Health's cloud services run. Context, not an integration point for clinical apps.
Verified July 2026 against Oracle/Cerner primary docs (docs.oracle.com/en/industries/health, fhir.cerner.com, oracle.com/health). Some ecosystem items (CDS Hooks, Bulk Data, CareAware specifics) are implementation-dependent — we confirm per environment.
Registration Isn't Go-Live: The Per-Tenant Model
Unlike a single global switch, Oracle Health makes activation the customer's job, per tenant. Here's the real sequence.
Register in Code Console
Create the app (free CernerCare account); declare your FHIR resources & scopes; get an application ID + client ID.
Oracle Validates
Oracle reviews which resources and READ/WRITE operations your app uses (for provider apps) and registers it.
Available to Consider
Now the app is merely "available for clients to consider" — it is not auto-activated anywhere.▲ not live yet
Customer Files an SR
Each customer logs a Service Request to Cerner Ignite APIs for Millennium to provision your IDs against their tenant.▲ per customer
Domain & Role Opt-In
The customer decides domain-by-domain and which users/roles can use it — then you're live at that site.
This is the single biggest structural difference from Epic's model. We build the repeatable per-customer onboarding so each new tenant is a fast checklist, not another project.
The Rebrand Decoder
Docs, blogs, and Oracle's own pages mix old and new names. Here's what changed, what didn't, and what to actually call things in 2026.
If You Know Epic, Here's What's Different
The two dominant EHRs share the FHIR spine but diverge on the details that decide your architecture.
c/r/u/d/s scopescode Console + CernerCare accountfhir.epic.com — dual (prod/non-prod) client IDs, immutable record_since$export onlyShowroom marketplace + Connection HubBuilding for both? A shared US Core layer covers most reads — we abstract the auth-version and activation differences so your product isn't forked per vendor. See our Epic integration guide and all-EHR overview.
Where Oracle Health Builds Go Wrong
The mistakes we're most often called in to fix.
Oracle Health is on STU1 (App Launch 1.0.0). Don't build against v2 granular scope syntax — match the STU1 framework.
Registration only makes you "available to consider." Each customer must file an Ignite APIs Service Request to actually turn you on.
DSTU2 is retired (~Dec 2025). New apps must be R4 (4.0.1); legacy Cerner DSTU2 integrations need migrating.
Sandbox is fhir-ehr.sandboxcerner.com; production is fhir-ehr.cerner.com (with regional hosts). Different domains — a classic misconfig.
Oracle Health (Cerner) Integration, Answered
The questions teams ask before they start.
Is It "Cerner" or "Oracle Health" Now?
code Console, CernerCare, and "Cerner Ignite APIs" still carry the Cerner name in 2026 docs. See our rebrand decoder above for what maps to what.How Do I Register an App with Oracle Health?
code-console.cerner.com), which needs a free CernerCare account. There you test authentication and your declared scopes and receive an application ID + client ID. There are two paths — a consumer-access app (attest to the CARIN Code of Conduct) and a provider/system-access app (accept API terms; Oracle reviews the FHIR resources and READ/WRITE operations you use).Why Isn't My App Live After I Registered It?
Which FHIR and SMART Versions Does Oracle Health Use?
How Is Oracle Health Different from Epic to Integrate?
code Console vs Epic's fhir.epic.com (immutable dual client IDs). And go-live differs: Oracle uses a per-customer Ignite APIs Service Request, while Epic is federated with a Showroom marketplace. Our vs-Epic table above breaks it down.What Does It Cost to Integrate with Oracle Health?
More on EHR Integration
Epic Integration, End to End →
The other giant — ecosystem, programs, SMART, and the vendor journey.
EHR Integration Across Vendors →
Epic, Oracle Health, athenahealth, MEDITECH and more, compared.
Healthcare Interoperability →
How EHRs, labs, devices, and payers connect into one FHIR data layer.
Skip the Guesswork — Get Your Path Mapped.
Tell us what you're building and which Oracle Health / Cerner customers you're targeting. We'll send back a specific plan: the FHIR resources, the SMART flow, the code Console + per-tenant steps, and a realistic timeline.
Thanks — We've Got It.
Your Oracle Health integration plan is on the way, within one business day.