Oracle Health (Cerner) FHIR Integration: Millennium APIs and Developer Access

Oracle’s Millennium Platform documentation covers the FHIR R4 APIs, authorization, SMART application provisioning and bulk data. Developers register applications in code Console, which requires a CernerCare account created on first use. Many URLs and tool names still carry the Cerner brand.

• Register the app in code Console, declaring its type and the scopes it needs, so you can test authentication and every declared scope.
• Test in the sandboxes. Oracle documents an open sandbox (unauthenticated, useful for exploring APIs) and a secure sandbox (exercising OAuth 2.0 and SMART authorization).
• Provision with each customer. For production, the developer shares the application details from code Console with the healthcare organization, which activates the app for its own environment.

R4 is the current FHIR version for the Millennium Platform. Oracle states it no longer supports its DSTU2 FHIR APIs and advises developers to move to R4. If you inherit an older integration built on DSTU2, treat migration as a prerequisite rather than a future improvement; our FHIR migration service overview covers what that involves.

The R4 documentation lists, per resource, the supported interactions, search parameters and any Oracle-specific notes, and it references USCDI and US Core. As with any EHR, verify each resource and operation you depend on rather than assuming parity with the base FHIR specification. Our FHIR R4 vs R5 guide explains why R4 remains the production baseline.

Use the open sandbox first to explore resource shapes and search behaviour without authorization overhead, then move to the secure sandbox to exercise the full OAuth 2.0 flow with every scope your app declares. Oracle’s guidance recommends testing each declared scope, and it is worth taking literally: a call that works in the open sandbox can fail once authorization is enforced.

• Build test fixtures from sandbox responses, versioned alongside your code.
• Write mapping code that tolerates missing optional elements, since production records are less tidy than curated sandbox patients.
• Test token expiry and refresh paths, not only the first successful call.
• Before each go-live, run a smoke test against the customer’s non-production environment where one is provided.

Oracle’s documentation includes a SMART on FHIR tutorial and guidance on building and testing SMART apps, including the SMART App Launch framework. See our SMART on FHIR guide for the general flow.

GET [base]/Patient/<patient-id>
Accept: application/fhir+json
Authorization: Bearer <access_token>

• Tenant-specific base URLs. Each customer has its own FHIR base URL and authorization server configuration; build discovery into your app.
• Codified data. Oracle’s provisioning guidance notes that customers may need to set up codable concepts your app relies on. Plan time for terminology alignment.
• Write support is narrower than read. Check the documented interactions for each resource before committing to a write-back design.
• Sandbox data differs from production. Synthetic records will not reflect each organization’s build.

• Whether your app is patient-facing, provider-facing or system-level, since provisioning differs.
• Migration effort if you are coming from DSTU2 APIs.
• Customer resources for provisioning, terminology setup and testing.
• Any additional non-FHIR interfaces required for real-time events.

See FHIR integration cost for how these factors translate into effort.

• Have you provisioned SMART apps with Oracle Health customers, and what did the customer need to do?
• Have you migrated integrations from DSTU2 to R4?
• How do you handle tenant discovery and per-customer configuration?
• Which of our write requirements can be met through FHIR R4?

Browse EHR integration vendors and filter by Oracle Health.