Your email address will not be published. Required fields are marked *
Our expert reaches out shortly after receiving your request and analyzing your requirements.
If needed, we sign an NDA to protect your privacy.
We request additional information to better understand and analyze your project.
We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.
If you're satisfied, we finalize the agreement and start your project.
Oracle completed its acquisition of Cerner Corporation in June 2022 for $28.3 billion, making it the largest acquisition in Oracle’s history. The rebranding from Cerner to Oracle Health was not just cosmetic — it signals fundamental changes to the platform, infrastructure, and developer ecosystem.
What changed:
Infrastructure migration. Oracle is migrating Cerner’s hosting infrastructure from Cerner-managed data centers to Oracle Cloud Infrastructure (OCI). This affects network connectivity, API endpoints, security architecture, and performance characteristics for integrations.
API management layer. Oracle is introducing Oracle API Gateway and Oracle Identity Cloud Service as management layers on top of existing Cerner APIs. Developers building new integrations may encounter Oracle-specific authentication and API management requirements that did not exist in the pre-acquisition Cerner environment.
Developer program restructuring. The Cerner Open Developer Experience (code.cerner.com) is transitioning to Oracle Health developer resources. Documentation, sandbox environments, and developer support are being consolidated under Oracle’s umbrella. During this transition, some documentation may reference Cerner-era conventions while new resources use Oracle Health terminology.
Product roadmap shift. Oracle has announced plans for a new cloud-native EHR platform alongside the existing Millennium product. This creates a dual-track environment where current integrations target Millennium while future integrations may need to support the new Oracle Health platform.
What did NOT change (yet):
Millennium remains the core product. Despite the acquisition, Cerner Millennium is still the EHR system running in production at thousands of healthcare organizations. Your existing Millennium integrations continue to function. New integrations still target Millennium for the foreseeable future.
FHIR and HL7 v2 standards remain. The underlying integration standards (FHIR R4, HL7 v2, CCDA) are unchanged. Oracle has committed to open standards and continued FHIR API support.
What this means for developers building integrations today: Build for Millennium using current APIs and standards, but architect with flexibility. Use FHIR R4 as your primary integration method where possible — it is the most future-proof approach as Oracle Health evolves. Avoid deep dependencies on proprietary Millennium APIs that may not carry forward to the new Oracle Health platform.
Understanding Millennium’s architecture is essential for choosing the right integration approach.
Cerner Millennium is the core clinical and administrative platform. It includes modules for clinical documentation, order entry (CPOE), pharmacy, lab, radiology, scheduling, registration, and revenue cycle. Millennium uses a centralized database architecture — unlike Epic’s per-site deployment model, many Cerner Millennium instances are hosted centrally (either by Cerner/Oracle or in a healthcare organization’s data center).
Millennium Objects (MObj) is Millennium’s internal data model. Clinical data is stored in Millennium Objects, and APIs expose this data through various access layers. Understanding MObj structure helps when troubleshooting data mapping issues.
PowerChart is the primary clinician-facing interface. Physicians and nurses interact with Millennium through PowerChart for charting, order entry, and clinical documentation.
HealtheLife is Cerner’s patient-facing portal, comparable to Epic’s MyChart. Integrations that surface data to patients may interact with HealtheLife or replace it with a custom patient portal.
Cerner Open Interface (COI) is the HL7 v2 messaging engine. COI handles inbound and outbound HL7 v2 messages for ADT, orders, results, scheduling, and other clinical events. It is comparable to Epic Bridges.
Millennium Gateway hosts the FHIR and proprietary REST APIs. API-based integrations connect through this gateway layer.
CareAware is Cerner’s medical device integration platform. If your integration involves bedside medical devices, patient monitors, or infusion pumps, CareAware is the connectivity layer.
Oracle Health Cloud Infrastructure (OHCI) is the emerging Oracle-managed cloud environment. Organizations migrating to OHCI will have their Millennium instances hosted on Oracle Cloud Infrastructure with Oracle-managed networking, security, and API management.
| Method | Best For | Data Direction | Standards | Future-Proof Rating |
|---|---|---|---|---|
| FHIR R4 (Ignite APIs) | Modern app integration, patient access, third-party apps | Read and write | HL7 FHIR R4, OAuth 2.0, SMART on FHIR | ★★★★★ Highest |
| HL7 v2 (COI) | Real-time clinical events, ADT feeds, lab results, orders | Bidirectional real-time | HL7 v2.x over MLLP | ★★★☆☆ Stable but legacy |
| Millennium Proprietary APIs | Deep workflow integration, advanced clinical functions | Varies | Cerner-specific REST/SOAP | ★★☆☆☆ Migration risk |
| CCDA Document Exchange | Clinical document sharing, care transitions | Document exchange | C-CDA, Direct messaging | ★★★☆☆ Standard-based |
| CDS Hooks | Clinical decision support within PowerChart | Real-time triggers | CDS Hooks specification | ★★★★☆ Growing adoption |
Recommendation for new integrations in 2026: Use FHIR R4 (Ignite APIs) as your primary method. Supplement with HL7 v2 through COI only when you need real-time event-driven data that FHIR Subscriptions cannot yet deliver reliably. Avoid new development on proprietary Millennium APIs unless your use case has no FHIR equivalent — these carry the highest migration risk as Oracle evolves the platform.
Oracle Health’s FHIR R4 implementation — branded as Ignite APIs — provides RESTful access to clinical, financial, and administrative data in Millennium.
Oracle Health supports an extensive set of FHIR R4 resources. The most commonly used in integrations:
Clinical data:
Orders and results:
Scheduling:
Administrative:
Financial:
Base URL pattern: https://{fhir-server}/r4/{tenant-id}/
Example API calls:
GET /Patient/{id}GET /Patient?name=Smith&birthdate=1980-01-15GET /Condition?patient={id}&clinical-status=activeGET /MedicationRequest?patient={id}&status=activeGET /Observation?patient={id}&category=laboratory&date=ge2025-01-01GET /Observation?patient={id}&category=vital-signsGET /Appointment?patient={id}&date=ge2026-01-01GET /DocumentReference?patient={id}&type=clinical-noteOracle Health FHIR APIs support write operations for select resources:
Write access requires specific scopes and may require additional approval from the Oracle Health customer site. Not all resources support all write operations — check the capability statement for each Millennium instance.
Oracle Health is expanding support for FHIR Subscriptions — a mechanism for receiving notifications when data changes. This bridges the gap between polling-based FHIR queries and real-time HL7 v2 event feeds.
Currently, FHIR Subscriptions on Oracle Health support a limited set of resource types. For comprehensive real-time event notification, HL7 v2 through COI remains more reliable in 2026. However, FHIR Subscriptions are the long-term direction and should be evaluated for new integrations.
Oracle Health FHIR APIs return paginated results using Bundle resources with next links. Default page sizes vary by resource. Use the _count parameter to control page size.
Rate limits are enforced per application and per tenant. Oracle Health does not publish specific rate limit numbers — they vary by hosting environment and customer configuration. Implement retry logic with exponential backoff and cache frequently accessed data (patient demographics, provider directories) to minimize API calls.
HL7 v2 messaging through Cerner Open Interface (COI) remains the primary method for real-time clinical event data exchange with Oracle Health Millennium.
| Message Type | Trigger | Use Case | Millennium-Specific Notes |
|---|---|---|---|
| ADT^A01 | Admission | New inpatient admission notification | Millennium sends FIN (Financial Number) in PV1-19 as the visit identifier |
| ADT^A03 | Discharge | Discharge notification, triggers billing | May include DG1 segments with discharge diagnoses |
| ADT^A04 | Registration | Outpatient/ED registration | Most common ADT event in ambulatory settings |
| ADT^A08 | Update | Demographics or visit update | High volume — filter for relevant changes |
| ORM^O01 | New order | Lab, radiology, medication orders | Millennium uses ORC segment extensively for order control |
| ORU^R01 | Result | Lab results, radiology reports | OBX segments contain result values; OBR contains order info |
| SIU^S12 | New appointment | Scheduling notification | SCH segment contains appointment details |
| SIU^S14 | Appointment update | Reschedule notification | |
| SIU^S15 | Appointment cancel | Cancellation notification | |
| MDM^T02 | Document | Clinical document notification | TXA segment contains document metadata |
| RDE^O11 | Pharmacy encode | Medication order details | Millennium-preferred over ORM for pharmacy orders |
| DFT^P03 | Charge posting | Financial transaction | Used for charge capture interfaces |
Oracle Health Millennium has specific conventions that differ from other EHR implementations:
Identifiers. Millennium uses multiple patient identifier types in PID-3: MRN (Medical Record Number), FIN (Financial Number/visit number), CMRN (Community MRN for multi-facility organizations), and Millennium Person ID. Your integration must handle the correct identifier type for your use case — MRN for longitudinal patient data, FIN for visit-specific data.
Code sets. Millennium uses internal code values (Cerner Code Values or CVs) alongside standard terminologies. A lab result may include both a LOINC code and a Cerner internal code value. Your message transformation must be able to resolve Cerner code values to standard terminologies.
Event sets. Orders in Millennium are organized by event sets (categories like Laboratory, Radiology, Pharmacy). ORM/RDE messages include event set information that helps route and categorize orders correctly.
Custom segments. Millennium can be configured to include custom Z-segments in HL7 messages for site-specific data elements. If you are integrating with a specific Oracle Health customer site, check their interface specification for Z-segments.
Cerner Open Interface is configured by the Oracle Health customer’s technical team (or by Oracle Health support for hosted clients). Key COI configuration points:
Your integration team will need to work with the Oracle Health customer’s interface analyst to configure COI for your specific requirements.
Beyond FHIR and HL7 v2, Millennium exposes proprietary APIs for functionality not yet available through standard interfaces.
Cerner developed proprietary REST APIs predating their FHIR implementation. These APIs provide access to Millennium-specific functionality:
Use proprietary Millennium APIs only when FHIR does not cover your use case. Common scenarios:
Proprietary Millennium APIs carry significant migration risk. As Oracle evolves the platform toward Oracle Health Cloud, proprietary APIs may be deprecated, restructured, or replaced. Oracle has not published a detailed deprecation timeline, but the strategic direction is clear: FHIR is the long-term API standard.
Taction Software advises clients to build all new integrations on FHIR R4 and migrate existing proprietary API integrations to FHIR when feasible. The migration cost now is lower than the forced migration cost when Oracle eventually deprecates legacy APIs.
Oracle Health Millennium supports C-CDA document generation and consumption for clinical document exchange.
CommonWell Health Alliance. Cerner was a founding member of CommonWell, a health information exchange network. Millennium has native integration with CommonWell for document query and retrieval across participating organizations.
Carequality. CommonWell connects to Carequality, enabling document exchange with Epic (via Care Everywhere) and other Carequality-participating networks. This provides cross-vendor document exchange without point-to-point integration.
Direct messaging. Millennium supports Direct secure messaging for sending C-CDA documents to specific recipients.
FHIR DocumentReference. C-CDA documents generated by Millennium can be accessed through the FHIR DocumentReference and Binary resources, providing API-based access to clinical documents.
For organizations participating in health information exchanges, the CommonWell/Carequality pathway provides the broadest document exchange network with minimal custom integration work.
Oracle Health Millennium supports the SMART App Launch Framework, enabling third-party applications to launch within the PowerChart clinical context.
EHR Launch flow:
Standalone Launch flow:
Oracle Health supports the CDS Hooks specification for real-time clinical decision support:
Supported hooks:
patient-view — triggered when clinician opens a patient chartorder-select — triggered when clinician selects an orderorder-sign — triggered when clinician signs ordersencounter-start — triggered at encounter creationencounter-discharge — triggered at dischargeCDS Hook response types:
CDS Hooks integration with Oracle Health requires registration of your CDS service endpoint with the Millennium instance. Each customer site configures which hooks are active and which services are called.
Mirth Connect is widely used for HL7 v2 integration with Oracle Health Millennium. The channel architecture patterns are similar to other EHR integrations but with Millennium-specific considerations.
ADT Inbound Channel:
ORU Results Inbound Channel:
ORM/RDE Orders Outbound Channel:
Identifier handling. Build transformer logic that correctly routes based on identifier type. A channel receiving ADT messages must parse PID-3 repeats to extract the right identifier (MRN for patient matching, FIN for visit context).
Code value resolution. Millennium HL7 messages frequently include Cerner code values (numeric codes) rather than standard terminology codes. Your Mirth Connect channels need a lookup mechanism — either a database table mapping Cerner CVs to LOINC/SNOMED/ICD codes, or a filter that only processes messages containing standard codes.
High-volume ADT filtering. Millennium generates ADT^A08 (update) messages at very high volume — any change to a patient record can trigger an A08. Filter A08 messages to process only the specific changes your application cares about (demographic changes, insurance updates, location transfers) rather than processing every A08.
Multi-facility environments. Large Oracle Health customers often run multi-facility Millennium domains where a single Millennium instance serves multiple hospitals and clinics. COI messages include facility identifiers that your Mirth Connect routing must use to direct data to the correct application context.
Oracle Health uses OAuth 2.0 for all FHIR API authentication, conforming to the SMART on FHIR specification:
Authorization Code Grant (user-facing apps):
Client Credentials Grant (system-to-system):
SMART Scopes: Oracle Health supports SMART scopes for fine-grained access control:
patient/*.read — read all resources for a specific patientpatient/Observation.read — read only Observation resources for a patientuser/*.read — read resources accessible to the authenticated usersystem/*.read — system-level access (for backend services)launch — support EHR launch contextopenid fhirUser — identity scopes for user informationSame as other HL7 v2 implementations — MLLP does not include native security:
For integrations targeting Oracle Health Cloud Infrastructure (OHCI), Oracle Identity Cloud Service (IDCS) or OCI Identity and Access Management (IAM) may be involved as an additional authentication layer. This is an evolving area — check with the specific Oracle Health customer’s technical team for current authentication requirements.
Millennium uses an internal code value system for clinical terminologies. Every coded element in Millennium — diagnoses, procedures, medications, lab tests, allergy reactions, order types — has a Cerner Code Value (CV) that maps to standard terminologies.
Example: A lab test might have:
Your integration must resolve Cerner code values to standard terminologies (ICD-10, SNOMED CT, LOINC, RxNorm, CPT) for interoperability with other systems and for regulatory compliance.
Resolution approaches:
Date/time format. Millennium stores all dates in UTC internally. HL7 v2 messages may include timezone offsets, or may be in the local timezone of the facility. Clarify timezone handling with the interface analyst for each customer site.
Name format. Millennium supports multiple name types (Legal, Display, Maiden, Alias). HL7 PID-5 may contain multiple repetitions for different name types. Your integration should use the Legal name for patient matching and the Display name for user-facing presentation.
Encounter model. Millennium uses a specific encounter hierarchy: Person → Patient (facility-specific) → Encounter → Visit. Understanding this hierarchy is important for correctly associating clinical data with the right patient context, particularly in multi-facility environments.
The Cerner Code program (transitioning to Oracle Health developer resources) provides:
| Factor | Oracle Health (Cerner Code) | Epic (App Orchard/Showroom) |
|---|---|---|
| Registration process | Developer portal self-service | Application submission and review |
| Sandbox availability | Multi-tenant sandbox, immediate access | Sandbox through App Orchard, may require approval |
| Review timeline | 4–8 weeks typical | 2–4 months typical |
| Per-site activation | Required | Required |
| Marketplace listing | Optional (no formal marketplace equivalent to App Orchard) | Recommended (many sites require it) |
| Documentation quality | Good, transitioning to Oracle format | Comprehensive |
Oracle Health Cloud Infrastructure is Oracle’s managed cloud environment for hosting Millennium and future Oracle Health products. Organizations migrating to OHCI have their Millennium instances hosted on Oracle Cloud Infrastructure (OCI) with:
Network connectivity changes. Organizations migrating from on-premises Millennium to OHCI will have different network endpoints. HL7 v2 interfaces that previously connected to a local data center will need to connect to OCI via VPN or Oracle FastConnect (private network connection).
API endpoint changes. FHIR API base URLs may change when migrating to OHCI. Applications using hardcoded endpoint URLs will break — use configuration-driven endpoint management.
Authentication layer changes. OHCI may introduce OCI IAM as an additional authentication layer for API access. Existing OAuth flows should continue to work, but additional identity provider configuration may be required.
Performance characteristics. OHCI hosting can improve API response times and reliability compared to some on-premises deployments. However, network latency may increase for organizations that previously connected to a local Millennium instance on the same network.
If your Oracle Health customer is planning to migrate to OHCI:
Stage 1: Sandbox Development (4–8 weeks)
Stage 2: Customer-Specific Testing (3–6 weeks)
Stage 3: Security Review (2–4 weeks)
Stage 4: User Acceptance Testing (2–3 weeks)
Stage 5: Production Go-Live (1–2 weeks)
One advantage of Oracle Health’s centralized hosting model: many Oracle Health customers share centrally managed Millennium infrastructure. This can simplify per-site activation compared to Epic’s per-site deployment model.
However, multi-facility Millennium domains mean your integration must correctly handle facility-specific data, routing, and configuration even when connecting to a single Millennium instance. A message for Hospital A within the domain must be processed differently than a message for Clinic B within the same domain.
Problem: HL7 v2 messages from Millennium contain Cerner-internal code values instead of standard terminologies. Your downstream system expects ICD-10, LOINC, or SNOMED CT codes.
Solution: Build a code value translation layer. Request a Cerner code value export from the customer’s interface analyst. Load these mappings into your integration engine or a shared terminology service. Implement fallback logic for unmapped codes — log them for manual review rather than dropping the message.
Problem: Millennium generates A08 (patient update) messages for every change to a patient record. In a busy hospital, this can mean thousands of A08 messages per hour, most of which are irrelevant to your application.
Solution: Build intelligent A08 filtering in your integration engine. Compare the incoming A08 against the previously stored patient data and process only when fields your application cares about have changed. Alternatively, configure COI to filter A08 events to only specific trigger reasons (if the customer’s interface team supports this level of filtering).
Problem: In multi-facility Millennium domains, a single patient may have different MRNs at different facilities within the same Millennium instance. Using the wrong identifier causes data to associate with the wrong patient context.
Solution: Use CMRN (Community MRN) for cross-facility patient identification when available. When CMRN is not available, maintain a facility-to-MRN mapping. Always include facility context in your patient matching logic. Confirm identifier strategy with the customer’s interface analyst before building.
Problem: Developers are uncertain which APIs and integration methods will be supported long-term as Oracle evolves the platform.
Solution: Build on FHIR R4 wherever possible — Oracle has committed to FHIR as a long-term standard. Avoid new development on proprietary Millennium APIs. Architect integrations with abstraction layers so the underlying API can be swapped without rebuilding application logic. Monitor Oracle Health developer communications for roadmap updates.
Problem: Integration works perfectly in the Oracle Health sandbox but encounters issues in a customer’s production Millennium environment due to configuration differences.
Solution: Treat sandbox development as proof-of-concept, not final validation. Always plan for customer-specific testing in their environment. Build your integration to be configurable (endpoint URLs, code value mappings, identifier types, message filtering rules) rather than hardcoded to sandbox conventions.
| Integration Type | Cost Range | Timeline | Key Cost Drivers |
|---|---|---|---|
| FHIR R4 read-only (demographics, labs, conditions) | $35,000 – $70,000 | 2–4 months | Number of FHIR resources, OAuth implementation |
| FHIR R4 read/write (orders, notes, scheduling) | $70,000 – $160,000 | 4–7 months | Write access approval, workflow complexity |
| HL7 v2 single interface (ADT feed) | $25,000 – $55,000 | 2–3 months | Message transformation, code value mapping |
| HL7 v2 multi-interface (ADT + orders + results) | $70,000 – $180,000 | 4–8 months | Number of message types, Cerner CV resolution |
| SMART on FHIR embedded app | $50,000 – $130,000 | 3–6 months | App complexity, CDS Hooks, PowerChart embedding |
| HealtheLife / patient portal integration | $50,000 – $110,000 | 3–5 months | Patient data scope, scheduling, messaging |
| Full bidirectional (FHIR + HL7 v2 + SMART) | $130,000 – $300,000+ | 6–12 months | Combined complexity |
Additional costs:
For a broader view of healthcare software development costs including integration budgeting, see our complete pricing guide.
Oracle Health integration requires navigating both the current Millennium platform and the evolving Oracle Health ecosystem. Building on FHIR R4 standards, architecting for configurability, and planning for the Oracle platform transition will protect your integration investment long-term.
If you are planning an Oracle Health integration and want guidance on the right approach for your specific use case, connect with our healthcare integration team or explore our healthcare interoperability services.
Related Resources:
This guide was developed by the healthcare interoperability team at Taction Software, drawing on direct experience with Oracle Health Millennium integrations across US hospital networks, multi-facility health systems, and health tech companies building on the Oracle Health platform.
Cerner Millennium remains the production EHR system and is not being discontinued. Oracle is investing in both maintaining Millennium and developing new Oracle Health cloud-native capabilities. The brand is transitioning to Oracle Health, but the underlying Millennium product continues to operate and receive updates. Plan for Millennium as your integration target for the near and medium term.
In 2026, they are effectively the same — Oracle Health APIs are the evolution of Cerner APIs. Build on FHIR R4 (Ignite APIs) for maximum future-proofing. Avoid new development on legacy proprietary Millennium APIs.
Oracle Health integrations are typically 15–20% faster to deploy due to centralized hosting (less per-site infrastructure variation) and a more accessible sandbox environment. However, Cerner code value resolution adds complexity not present in Epic integrations. Both require per-site testing and activation.
For HL7 v2 integrations, an integration engine like Mirth Connect is essential. For FHIR-only integrations, your application can make direct API calls without an integration engine. Most comprehensive integrations use both FHIR and HL7 v2, making Mirth Connect valuable for the HL7 v2 component.
Your integration logic and application code should continue to work. Network endpoints, connectivity method, and possibly authentication configuration will change. Plan for reconfiguration and testing when a customer announces OHCI migration. The earlier you know about the migration timeline, the less disruptive it will be.
Your core integration code is reusable. However, each site requires configuration for site-specific Cerner code values, facility identifiers, interface settings, and network connectivity. Multi-facility Millennium domains add additional complexity. Budget for per-site configuration and testing.
Yes. Oracle Health’s FHIR R4 APIs meet the ONC certification requirements for the 21st Century Cures Act, including USCDI data element support, SMART on FHIR authorization, and Bulk Data Access capabilities.
