AI Integration
Epic FHIR API: What You Can and Can't Do
Epic FHIR API capabilities and limits for healthtech teams. Covers FHIR R4 resources, SMART on FHIR auth, sandbox testing, write access, and HL7 v2 gaps.
October 23, 2026Read more
Oracle Health (formerly Cerner) no longer supports its older DSTU2 APIs, so new Oracle Health integration work should target FHIR R4, according to Oracle's Millennium Platform API documentation. Engineering leads must coordinate application registration, interface coverage and customer-controlled activation before a working prototype can reach production. This guide covers those decisions, the sandbox checks between them and the evidence each responsible party should provide.
Oracle Health Integration Today
Oracle acquired Cerner for $28.3 billion in June 2022, according to Fierce Healthcare's coverage of KLAS market-share data. The Oracle Health Information Network was then designated a TEFCA Qualified Health Information Network (QHIN) on November 28, 2025, as recorded in ASTP/ONC's history of TEFCA. That exchange-network designation shouldn't be treated as application registration or permission to access a customer's Millennium environment.
The practical model has three parties: the developer builds the application, Oracle registers it and supplies the platform, and the customer authorizes its use locally. The Oracle Health developer API portal is the starting point for identifying the available API surfaces. The engineering problem is determining which surface supports the workflow and who owns each deployment decision.
Think of the platform as a building with several entrances and separate badge offices. Registration establishes the application's identity, but it doesn't establish every customer permission or interface entitlement.
We use this ownership model when planning EHR integration services. Oracle's documentation establishes platform behavior; the capability matrices, evidence requirements and release gates below are our engineering recommendations. Because vendor capabilities change, confirm the documentation and customer configuration again before committing a production release.
Registering an App in the Oracle Health Developer Program
Oracle's documentation calls the registration interface code Console. It requires a CernerCare account, and new or updated application configurations can take about 15 minutes to take effect.
Turn that sequence into delivery tasks with explicit owners:
The developer registers the application in the Oracle Health Developer Program console. Record its identity, intended workflow, FHIR version and required resources and operations. New development should target R4.
Engineering builds and tests against the sandbox. Keep registration settings, requested permissions and application configuration under review together rather than maintaining unrelated lists.
The customer submits the activation service request. Oracle and the customer then own dependencies that the application developer can track but can't independently complete.
Registration is required before accessing protected resources. A successful unauthenticated sandbox read therefore proves only a limited part of the implementation.
Put customer activation on the delivery plan when registration starts, with an owner and an escalation path.
The registration artifact should describe what the executable does. If the application declares read access but later requests broader permissions, engineering must reconcile that mismatch before interpreting an authorization failure as a platform defect.
Keep the requested scope set narrow and test denied access deliberately. A delivery lead should be able to trace each requested permission to a product requirement and a test, without relying on someone's memory of a console setting.
FHIR R4 APIs and HL7 v2 Interfaces Compared
Choose interfaces by workflow coverage, not by a preference for a single protocol. Oracle's Millennium Web Services and FHIR guidance describes person-centric SOAP and REST APIs for demographics, clinical results, documentation, reporting and scheduling, with migration toward FHIR where an equivalent standard resource exists.
FHIR R4 is the starting point for new applications. Existing DSTU2 implementations need migration and regression testing, rather than a base-URL substitution. For any EHR integration API, document capability at the operation level.
| Interface family | Where to evaluate it | Evidence to obtain |
|---|---|---|
| FHIR R4 | Resource-oriented clinical reads and supported operations | Resource, search parameters, operation, scopes and representative response |
| Millennium Web Services | Required workflows without adequate FHIR coverage | Available service, authorization requirements and business semantics |
| Customer HL7 v2 interfaces | Existing local feeds relevant to the workflow | Customer interface specification, identifiers, event handling and operational owner |
Don't infer the local HL7 v2 estate from the public API catalog. During discovery, have the customer identify available feeds and the interface team responsible for them. Treat every non-FHIR dependency as a controlled boundary with its own acceptance criteria. Our comparison of FHIR and HL7 v2 and our HL7 v2 to FHIR migration roadmap cover the trade-offs in more detail.
Our recommended matrix also records patient identifiers, terminology mappings, provenance and reconciliation behavior. In a mixed architecture, test whether a patient represented in a feed resolves to the intended FHIR record, and whether both paths preserve the same clinical meaning.
A technically valid response doesn't prove that a local result code or workflow state has been interpreted correctly. Assign semantic review to someone who understands the customer's clinical data, not only the HTTP client.
Provider, Patient and System App Types
The launch model determines the authorization design. Oracle documents support for HL7 SMART App Launch 1.0.0 (STU1), HL7 SMART App Launch 2.0.0 (STU2) and SMART Backend Services in its authorization framework. Confirm which variant the application implements before configuring its authorization flow. For background on the standard itself, see our SMART on FHIR guide.
SMART app types and who decides what
| App type | Authorization model | User context | Placement or launch | Deployment decision owner |
|---|---|---|---|---|
| Provider-facing | SMART App Launch | Authorized clinical user and applicable launch context | PowerChart table of contents, Organizer view or embedded MPages component | Customer selects domains, users, roles and placement |
| Patient-facing | Applicable SMART user authorization | Authorized patient or consumer | Oracle Health Patient Portal | Customer controls local availability; developer verifies intended access |
| System backend | SMART Backend Services | Service identity rather than interactive user launch | Server-to-server execution | Developer manages credentials; customer governs deployment access |
Oracle's SMART developer overview says Oracle validates and registers SMART applications and checks declared FHIR resources and operations. It also states that Oracle doesn't validate FHIR-resource use for direct-to-consumer applications. That exception requires explicit developer validation rather than an assumption that registration covers resource correctness.
Customer approval remains domain-specific. Registration doesn't decide which local users or roles can launch an application.
For a workflow such as a clinical AI assistant, decide whether a clinician must launch it in context or whether processing runs independently. Those are different deployment designs. Backend credentials shouldn't become a shortcut around a user-context requirement; document governed scopes, key-management ownership and the intended service boundary separately.
Testing in the Oracle Health Sandbox First
Keep environment configuration separate from application logic. According to Oracle's service root URL documentation, the open sandbox (fhir-open.cerner.com) allows read-only requests without authentication, while the secure sandbox uses fhir-ehr-code.cerner.com for provider and system access and fhir-myrecord.cerner.com for patient access. Production service roots vary by tenant: a SMART app receives its service root at launch, and a standalone app must be configured for each customer tenant.
Oracle's authorization framework says each FHIR server advertises its authorization endpoints in a Well-Known SMART Configuration document at /.well-known/smart-configuration relative to the FHIR base URL. Oracle's build and test guide recommends starting with the open sandbox for proof-of-concept reads, then registering in code Console and using the secure sandbox to test authentication and every declared scope.
Validate configuration and clinical meaning separately
Run the deployment checks in order:
Confirm the FHIR base URL and expected environment before sending requests.
Retrieve SMART discovery and verify authorization endpoints, token endpoints and supported launch capabilities.
Compare requested scopes with those granted to the registered application.
Exercise representative identities, results, documents and scheduling actions where supported.
Test pagination, search behavior, malformed responses, token expiry, insufficient permissions and audit logging.
Hypothetical worked example: A provider-facing results viewer launches with a patient context and retrieves clinical observations. The application first validates the configured service root, completes authorization and requests the supported observation data. Its processing layer then resolves local codes through an approved mapping before displaying the result with provenance.
If a code is unmapped, the proposed behavior is to withhold interpretation and expose a reviewable exception. Test that branch alongside empty results and denied access.
Preserve the request context and mapping decision needed to explain a displayed result, without placing unnecessary patient data in diagnostic logs.
Sandbox tests establish development evidence. Customer-specific codes, permissions and workflow behavior still need controlled production validation.
Customer Activation and Planning Beyond Epic
Customer activation is a delivery dependency. The customer submits the service request, decides domain-level availability and configures user access and launch placement. Engineering should require evidence that those decisions have been implemented, rather than accepting a registered application as proof of readiness.
Oracle Health's installed base is still large but shrinking. KLAS estimates placed it at 21.9% of the US acute-care hospital EHR market in 2025, down from 22.9% a year earlier, after a net loss of 56 hospitals, according to Fierce Healthcare's summary of the KLAS report. That reach still makes per-customer configuration a material planning concern.
Evidence to require before committing a launch date
Request a documented activation path, customer-provided elapsed-time expectations, named escalation contacts and a fallback when the environment blocks deployment. Also identify who owns release notices, credential changes, interface incidents and post-go-live reconciliation.
Customer sentiment is a reason to examine those operating arrangements. In the same KLAS report, 30% of sampled Oracle Health customers said Oracle Health is not part of their long-term plans, and 35% said they might leave or want to leave but can't. These are survey findings, not evidence that every customer will encounter the same problems.
Keep vendor comparisons evidence-based
For a product expanding from Epic, carry over workflow requirements and test objectives, then establish a separate Oracle deployment record. Don't assume an existing registration, scope set, launch configuration or customer approval transfers.
Epic has its own registration, scope and activation model, covered in our guides to the Epic FHIR API and Epic EHR integration. Don't carry assumptions from one vendor to the other; broader types of EHR systems provide context, not deployment evidence.
When integrating AI into existing healthcare systems, our engineering recommendation is to maintain a customer-specific release gate. It should include successful authorization, approved launch placement, representative clinical validation and an agreed incident owner.
Conclusion
Require an integration plan that connects each workflow to an interface, each permission to an owner and each release decision to evidence. Register early, isolate legacy dependencies and reserve delivery capacity for customer activation and ongoing operations.
The strongest acceptance criteria cover both technical access and clinical meaning. A successful request is useful evidence, but production readiness also requires confirmed identity handling, understood terminology, customer-approved access and a support path that someone has agreed to operate.
Frequently Asked Questions
Should new Oracle Health applications use FHIR R4?
Yes. Oracle's Millennium platform documentation identifies R4 as the supported direction and states that DSTU2 APIs are no longer supported. Verify resource and operation coverage before committing the product workflow.
Do older Cerner DSTU2 integrations still work?
Don't plan around continued DSTU2 availability. Oracle directs applications to migrate to R4 to avoid service interruptions. Treat migration as a compatibility project with authorization, resource-model and clinical regression tests.
What is SMART Backend Services used for?
SMART Backend Services supports system-to-system authorization without an interactive user launch. Use it for an appropriate service workflow, with governed scopes and explicit ownership of credentials and keys. Oracle lists it separately from the SMART App Launch variants in its authorization framework.
What is the difference between the open and secure sandbox?
The open sandbox accepts read-only requests without authentication and is meant for early proof-of-concept work. The secure sandbox requires a registered application and is where you test authorization and every declared scope. A successful open-sandbox read doesn't validate the application's OAuth configuration.
What must a customer do to activate an application?
The customer must submit an activation service request through the documented provisioning process. It also decides where the application may run and which users and roles may access it. Require confirmation of those settings and a successful customer-environment test before release.
Book a consultation with Ekipa's HealthTech engineers to plan EHR integration work across interface selection, authorization, customer activation and production validation.
