Oracle Health (Cerner) integration in 2026 means FHIR R4 on the Millennium Platform. DSTU 2 support ended in December 2025, docs moved to Oracle's Help Center, and apps register in the Oracle Health Developer Program console. Developer fees are optional value-added services ($500 to $5,000 a year); health systems pay for the certified APIs.
If your last Cerner integration was built on DSTU 2 against fhir.cerner.com, a lot has moved. Oracle has consolidated Millennium API documentation under docs.oracle.com, retired DSTU 2, added proprietary "EHR APIs" alongside FHIR, and launched a new AI-centred EHR for ambulatory care that coexists with Millennium. This guide covers what Oracle's own documentation says as of November 2026, with the engineering details that decide whether an integration goes smoothly. BeevR is not an Oracle partner and has no validated integration.
What changed in Oracle Health (Cerner) APIs since 2024?
Four things: DSTU 2 FHIR APIs lost support in December 2025, documentation moved to Oracle's Help Center, registration moved to the Oracle Health Developer Program console, and Oracle introduced a new ambulatory EHR alongside Millennium.
- DSTU 2 is gone. Oracle's DSTU 2 overview states: "As of December, 2025, Oracle will no longer support DSTU 2 FHIR APIs," replaced by R4. Any app still on DSTU 2 is running on unsupported endpoints.
- New doc home. The Millennium Platform APIs index now lists four families: EHR APIs, FHIR R4 APIs, FHIR R4 Bulk Data Access APIs, and the retired DSTU 2 APIs.
- Federal deadlines moved the floor. Under ONC's HTI-1 rule, certified (g)(10) APIs had to support US Core 6.1.0 (USCDI v3) and SMART App Launch 2.0.0 by December 31, 2025, per ONC's HTI-1 key dates. Oracle's R4 docs describe support for both SMART v1 and v2.
- A second EHR. Oracle introduced its new AI-powered EHR in August 2025, and Becker's reported it was ready for US ambulatory customers in November 2025, with a "coexistence" strategy alongside Millennium. Its public API surface is not documented in the Millennium docs, so treat it as a separate discovery item.
Which Oracle Health APIs exist on the Millennium Platform?
Three live families: FHIR R4 (the standard, certified API), FHIR R4 Bulk Data Access (population export), and the newer proprietary "EHR APIs" with nine namespaces. Most integrations should start on FHIR R4 and use EHR APIs only where FHIR does not cover the workflow.
| API family | What it covers | Auth and scopes | Notes |
|---|---|---|---|
| FHIR R4 (4.0.1) | Clinical and administrative resources; read, search, create, update, patch on supported resources | SMART v1 and v2; patient/, user/, system/ scopes | JSON only; open (no-auth) sandbox and secure sandbox |
| FHIR R4 Bulk Data | Group export and Patient export to NDJSON | Registered "Millennium Bulk Data SMART application" | Open endpoints do not support bulk; Patient export needs explicit patient IDs |
| EHR APIs (proprietary) | Allergies, chief complaints, code systems, conditions, locations, nomenclatures, personnel, recipients, messages | One scope per API, e.g. oraclehealth:millennium:condition | Scopes "grant access to all the actions and operations in the service" |
| FHIR DSTU 2 | Legacy | n/a | No longer supported since December 2025 |
The EHR APIs detail matters for security design. Oracle's EHR APIs overview says each scope grants every action in that service, not one operation. If your app only needs to read conditions, the scope still allows whatever else the condition service does. Compensate with your own allow-list of calls in code and in your audit log review.
What does the Oracle Health FHIR R4 API support?
Oracle's R4 overview describes FHIR 4.0.1 with JSON only, GET for reads, POST for create, PUT for update, and JSON Patch sent through POST with a _method=patch parameter or an X-HTTP-Method-Override: patch header. Supported interactions vary by resource and by persona.
Engineering details that cause bugs
- Pagination: follow the server's next links exactly; do not build page URLs yourself.
- Duplicates across pages: search results may contain the same resource ID on more than one page. Keep only the latest version of each ID.
- Optimistic locking: updates with an outdated version return 409. Read, merge, retry; never blind-overwrite.
- Patient persona filtering: data is filtered for patient and proxy access, sensitive notes may be masked, and proxy rules vary by state law. A patient app will see less than a provider app for the same patient, by design.
- Persona-specific resources: some resources (Location, Organization, Practitioner, FinancialTransaction) appear only in
system/oruser/scopes.
Two base URLs appear in the docs: an open sandbox (fhir-open.cerner.com, no authentication) and a secure one (fhir-ehr-code.cerner.com). Test auth, scopes and writes only on the secure sandbox, and test against a customer's non-production domain before go-live.
How do you register an app with Oracle Health?
You register in the Oracle Health Developer Program console (code-console.cerner.com). Consumer (patient) apps are provisioned to all active Millennium and Soarian Clinicals consumer endpoints after registration. Provider and system apps need a gap analysis and a working sandbox demo, and then health systems choose whether to implement them.
From Oracle's API Access and Fees page:
- Accept the Terms and Conditions for Oracle Health APIs.
- Review the Millennium Platform and Soarian Clinicals API docs; for provider or system apps, "document a gap analysis for your app."
- For consumer apps, attest to the CARIN Alliance Code of Conduct (recommended, not required).
- Register in the developer console.
- Build and test against the sandbox; for provider or system apps, a working demo is expected.
The phrase that matters for provider and system apps: once registered, the app "will be available for Oracle Health Developer Program customers to consider for implementation." Registration is not deployment. Each health system still decides, configures and tests.
How much does Oracle Health API access cost?
For developers, Oracle lists optional annual fees: $500 for Oracle PartnerNetwork membership, a $3,000 item available only with OPN membership, and $5,000 for Millennium Platform environment access. Oracle says these value-added services "are not required to develop and deploy apps." Health systems pay subscription and setup fees for the certified FHIR APIs.
| Who pays | Item | Amount (published) |
|---|---|---|
| Developer (optional) | OPN membership | $500/year |
| Developer (optional) | Item "available with OPN membership only" (service name blank on Oracle's page) | $3,000/year |
| Developer (optional) | Millennium Platform environment access | $5,000/year |
| Health system | Oracle Health FHIR APIs and bulk data access | Annual subscription plus one-time setup; rates published by Oracle under Certified API Technology Fees |
| Consumer app developers and patients | Connection or usage fees | None charged, per Oracle's certification disclosure |
Oracle adds that "pricing may vary for developers using noncertified (proprietary) APIs," and that developers who skip validation "may connect to and access API resources" but lose value-added services and must follow the marketing rules in the API terms. The health-system side comes from Oracle's certified health IT disclosure, which also notes extra infrastructure costs for clients that host their own systems. Federal rules in 45 CFR 170.404 constrain what certified API developers may charge for certified APIs.
Does Oracle Health support bulk FHIR export?
Yes, with limits. Group export follows Bulk Data IG v1.0.1 with some v2.0.0 experimental parameters, Patient export follows v2.0.0 but requires a list of patient IDs (no "all patients"), and open endpoints do not support bulk at all.
From Oracle's bulk data docs: groups are managed by the health system in Ignite Management Tooling, so you must agree the cohort with each customer; exports run on shared services, so performance on their side matters; too many requests return 429; unsupported parameters return 422 unless you send Prefer: handling=lenient. Lenient handling is convenient and risky: the server silently ignores what it does not support, so your "filtered" export may not be filtered. Log the exact kick-off request and check the output. More in our bulk FHIR export for analytics and AI guide.
What about Oracle's new AI EHR and agents?
Oracle's new EHR targets ambulatory care first and is built around embedded AI agents. For integrators, the practical point is that it is a different product from Millennium, and its third-party API surface is not covered by the Millennium docs we reviewed. Confirm in discovery which platform each customer site runs.
This matters for AI vendors in particular. If the EHR ships its own documentation and coding agents, a third-party AI product has to be clearly better on a specific job, or integrate where the native agent does not reach (payer workflows, cross-EHR data, specialty logic). For the controls a health system will ask about, see HIPAA-compliant AI agents and our AI agent security checklist.
How should you design an Oracle Health integration for 2027?
Design for FHIR R4 first with SMART v2 scopes, use backend services for server-side work, use bulk only for defined cohorts, wrap proprietary EHR APIs behind your own allow-list, and plan per-customer configuration and testing as real project phases.
- Auth: asymmetric client authentication for backend services, separate keys per environment, short token lifetimes. Details in SMART on FHIR backend services.
- Scopes: SMART v2 granular scopes (for example
system/Observation.rs) instead of wildcards. - Writes: version-aware updates (expect 409), idempotent creates, and a human approval step for anything an AI component proposes.
- Interfaces: if a customer still feeds you HL7 v2 (ADT, ORU), do not rewrite stable feeds just to be "all FHIR". See HL7 v2 to FHIR migration.
- Payer workflows: CMS-0057-F API deadlines start January 1, 2027 for impacted payers, which is driving prior-auth and data-exchange projects on every major EHR.
How BeevR builds this
We build the application and integration layer: SMART on FHIR apps, backend services, bulk export pipelines, and AI features that draft for a clinician or coder to approve. We work from Oracle's public documentation and each customer's environment, we are not an Oracle partner, and we tell you plainly when a native Oracle capability makes a custom build unnecessary. Every action is logged, scopes are minimal, and nothing is written to the record without a person confirming. BeevR signs a BAA as a business associate, AI models can run inside your own AWS account under the AWS BAA, and you own the source code and IP from day one.
Our senior, founder-led team in Hanoi runs a multi-tenant EHR live across four US clinics at about 300 patients a day, with a working demo every Friday and fixed-scope, fixed-price phases from $10K per phase. See our EHR integration services and healthcare AI agent development.
Moving an old Cerner integration to R4, or starting a new one? Book a 30-minute call and we will review your current endpoints, scopes and customer list with you.