Before you promise a health system an Oracle Health (Cerner) integration, you need to know which FHIR R4 interactions, scopes and exports the Millennium Platform documents. Agnotic Technologies maps them from Oracle's developer documentation, then builds and tests the integration for you, sandbox first.
Trusted by global innovators
Cerner FHIR capabilities are the FHIR R4 APIs, SMART authorization and Bulk Data exports that Oracle Health documents for the Millennium Platform behind its Oracle Health (Cerner) EHRs. Agnotic Technologies reads that documentation, confirms what each health system has enabled, and builds the integration that reads, writes and searches the data for you.
Oracle completed its acquisition of Cerner in 2022, and the developer documentation now sits on Oracle Help Center. Older fhir.cerner.com links redirect there.
This page is a developer reference. Our Oracle Health (Cerner) integration services page covers the engagement itself.
API surface
Oracle documents three API families for the Millennium Platform. Most integrations start with FHIR R4 and add the others only where a workflow needs them.
Capability table
Built only from Oracle's Millennium Platform documentation. What a given tenant has enabled for your app is confirmed in testing.
| Area | Interactions | Auth model | Notes from Oracle's docs |
|---|---|---|---|
| Patient | Read, search; create and update scopes published | SMART patient, user or system scopes | Search needs _id, or a combination such as identifier, name, birthdate, phone or email |
| Condition | Read, search; create and update scopes published | SMART patient, user or system scopes | Supported categories are problem-list-item and encounter-diagnosis |
| Encounter | Read, search | SMART patient, user or system scopes | _count is not honoured when _id is set |
| Writes | POST to create, PUT to update; PATCH through a method override | Write scopes (v1 .write, or v2 c and u) | Stale versions return 409; business rule failures return 422 |
| Bulk Data Group Export | Export for a group the health system manages | Authenticated SMART app; open endpoints not supported | Groups are managed by the organization in Ignite Management Tooling |
| Bulk Data Patient Export | Export for a list of patient IDs | Authenticated SMART app | No export of all patients; a patient ID list is required |
| Patient and proxy access | Patient persona reads through a separate service root | SMART patient scopes | Some data is filtered, such as non-instructional notes; proxy access to adolescent records may be restricted |
Oracle states that Millennium ids and identifiers only have meaning with their full service root URL. The same Patient id or MRN in another tenant may identify a different person.
Sandboxes
Oracle publishes three sandbox service roots for R4. Each one answers a different testing question.
| Code | Name | Typical use |
|---|---|---|
| Open sandbox | fhir-open.cerner.com, no authentication | Read-only proofs of concept and request shape checks. No writes are available here. |
| Secure sandbox (provider) | fhir-ehr-code.cerner.com, authorized | Provider and system flows, including writes, with SMART authorization in place. |
| Secure sandbox (patient) | fhir-myrecord.cerner.com, authorized | Patient and proxy flows, where data filtering differs from provider access. |
Failure points
These come straight from Oracle's documentation, and each one shows up late if nobody plans for it.
Challenge
Treating a Patient id as global
Agnotic approach
We key every stored record on tenant and id together, because Oracle says ids only have meaning with the full service root URL.
Challenge
Building on DSTU 2
Agnotic approach
Oracle no longer supports DSTU 2. We build on R4 only and move any legacy DSTU 2 calls to R4 first.
Challenge
Testing writes against the open sandbox
Agnotic approach
The open sandbox is read only. Write paths are tested in the secure sandbox with synthetic patients.
Challenge
Bulk exports that pull more than the app needs
Agnotic approach
Oracle asks that bulk queries capture only the data an application needs, so we limit resource types and agree groups with the organization.
Challenge
No plan for throttling
Agnotic approach
Bulk endpoints can return 429 when too many requests are sent. Our clients back off and retry instead of failing the export.
Challenge
Patient apps that expect provider data
Agnotic approach
Patient access filters some data and may return masked values, so the patient experience is designed and tested on that persona.
HIPAA applies to your product as well as the health system. These are the decisions we make up front.
Agnotic signs a BAA before any PHI is shared. Development uses Oracle's sandboxes and synthetic patients.
Your app requests only the patient, user or system scopes its use case needs, in SMART v1 or v2 syntax.
Each health system is a separate tenant in our data model, so records and credentials never cross between customers.
Every FHIR call is logged with user, patient, tenant and time, so access questions have an answer.
Who builds on Oracle Health
Oracle's own bulk data examples, plus the app types we build most often.
Study data pulled through Bulk Data into an internal warehouse.
Training data extracted from the EHR under an agreed group and purpose.
Cohort data moved between the EHR and a population health system.
Data transferred to a payer database for care quality assessment.
Reportable disease and other registry feeds built on FHIR exports.
SMART apps that read and write chart data for providers, patients and proxies.
Four steps, with a fixed first release agreed before build starts.
We check request shapes and resource content against the read-only open sandbox before any registration work.
We register the app, request the narrowest scopes and test reads and writes in the secure sandbox for providers and patients.
With the health system we confirm the tenant, enabled scopes and any bulk groups, so production matches what we tested.
We monitor auth errors, throttling and failed writes, and keep the integration on R4 as Oracle updates its APIs.
Scope drivers
We do not quote a price before scoping. These factors move the effort most on Oracle Health builds.
Reads and searches are the smaller build. Writes add validation, conflict handling for 409 and 422 responses, and more testing.
Each health system is its own tenant with its own setup, so rollout effort grows with every site.
Group or Patient Export brings group setup, long-running jobs, NDJSON processing and throttling into scope.
Workflows that need the Oracle Health EHR APIs add a second API family with its own scopes.
Patient-facing apps need their own persona testing, because data filtering differs from provider access.
Oracle publishes its own API access and app registration fee information. We help you read it but do not set those fees.
Standards in scope
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Short facts we design around, each linked to its primary source.
The Oracle Health Millennium Platform FHIR R4 APIs implement FHIR 4.0.1, return JSON only, and support SMART v1 and SMART v2 scopes for patient, user and system access.
Source: Oracle Help Center, FHIR R4 APIs for Millennium Platform: R4 OverviewOracle no longer supports the DSTU 2 FHIR APIs on the Millennium Platform and tells developers to move applications to the R4 APIs.
Source: Oracle Help Center, Oracle Health Millennium PlatformOracle Health supports Bulk Data Group Export at v1.0.1 of the Bulk Data Access guide and Patient Export at v2.0.0. Patient Export needs a list of patient IDs, and open endpoints do not support bulk export.
Source: Oracle Help Center, FHIR R4 Bulk Data Access APIsOracle Health's open sandbox exposes read-only FHIR resources without authentication. Writes need the secure sandbox, which uses separate service root URLs for provider and patient access.
Source: Oracle Help Center, FHIR R4 APIs: Service Root URLOracle completed its acquisition of Cerner in June 2022.
Source: Oracle press release, June 2022
