Oracle Health and Cerner EHR Integration Services

Yes. Oracle acquired Cerner in 2022 and the EHR platform is now Oracle Health Millennium, formerly Cerner Millennium. Developer tools and endpoints still carry Cerner names, such as the Cerner Code Console and fhir-ehr.cerner.com, and hospitals often still say Cerner.

The Code Console at code-console.cerner.com is where developers register Oracle Health Millennium apps: app type (provider, patient or system), FHIR version, scopes, redirect and launch URLs. It gives you sandbox access; each hospital then provisions the app in its own domain for production.

Oracle offers an open R4 endpoint at fhir-open.cerner.com that needs no authorization and is read-only, and a secure sandbox tenant for authorized testing once your app is registered in the Code Console. Writes, scopes and launches are tested in the secure tenant.

Millennium implements FHIR R4 (4.0.1) with US Core 6.1.0 profiles, secured with OAuth 2.0 and SMART v1 and v2, with patient, user and system scopes. The capability statement lists create, update or patch for resources including Patient, Encounter, Observation, Condition, DocumentReference, Appointment and Coverage.

Yes, for the resources the target domain enables. Writes are strict: in our run the vitals write rejected generic LOINC codes and filed 8331-1, 3141-9 and 3137-7 only with the signed-in Practitioner as performer, the performer-function extension and the issued time. We test every write in the secure sandbox and again in the hospital's domain.

Cost follows the resources and write paths, the app types, whether HL7 v2 interfaces are needed, the number of hospitals and any DSTU2 migration. We fix the scope after a short discovery and list hospital, Oracle and middleware charges separately.

A focused FHIR integration is typically built and tested in Oracle's sandbox in 6 to 10 weeks. The first hospital then adds provisioning, interface work and validation on its own calendar, commonly several months. Later hospitals reuse the code and runbook.

Yes. Many Millennium hospitals exchange admissions, orders, results and scheduling as HL7 v2 through Oracle's Open Engine or an engine such as Mirth Connect, Rhapsody or Cloverleaf. We work from the hospital's interface specification and test messages, and build the listener, mapping and acknowledgements on your side.

CareAware is Oracle Health's device connectivity platform that brings monitor, pump and ventilator data into the Millennium record. Integrations run through the hospital's CareAware set-up and its biomedical and interface teams. We scope the data path, the mapping to clinical documentation and the validation plan with them.

Yes. Millennium supports Group and Patient $export with _type, _typeFilter and _since, groups of up to 20,000 patients (10,000 or fewer recommended), and files that expire after 30 days. Unlike Epic, incremental loads with _since are available.

You can reuse your data model, FHIR clients and much of the SMART code. Registration, scope behavior, token lifetimes, write rules and hospital provisioning differ, so we keep vendor-specific adapters and configuration separate and test each vendor on its own.

Discovery against the target hospital's Millennium domain, Code Console registration, the build in Oracle's secure sandbox, HL7 v2 interfaces where FHIR does not cover the workflow, hospital provisioning and validation, and monitoring after go-live. You receive the resource and scope matrix, the code and tests, the interface specification and a per-hospital onboarding runbook.

Yes, where the hospital's domain exposes them. Clinical documents such as continuity of care documents and discharge summaries are read through DocumentReference and Binary, and we map their sections to FHIR resources when your product works in FHIR. Filing documents back follows the hospital's document types and routing rules.

CDS Hooks lets an external service return decision support cards inside the clinician's workflow. Support and the hooks available depend on the hospital's Millennium configuration, so we confirm them with the hospital before design. We have built CDS Hooks services, including coverage requirements discovery, and test them with the Inferno tools.

The common ones are writes that work in the sandbox but are not enabled in the hospital's domain, provisioning that waits on the hospital's calendar, legacy DSTU2 calls that must move to R4, strict code and performer rules on writes, and HL7 v2 feeds that fail silently. We name each risk in the plan with its owner and the test that proves it closed.

You register your app in the Cerner Code Console and accept its developer terms to get sandbox access, and each hospital provisions your app in its own Millennium domain. For multi-tenant domains, Oracle also requires Oracle Validated Integration (OVI) through Oracle's OPN Healthcare track if your app writes data or is an embedded SMART launch. What applies depends on the deployment type and what your app does, so we confirm it during discovery and help you prepare the registration, validation and provisioning steps.

Yes. Oracle no longer supports the DSTU2 FHIR APIs. We compare your DSTU2 calls with the R4 capability statement, remap resources such as MedicationOrder to MedicationRequest, run regression tests and plan cutover and rollback with each hospital.