.png)
Oracle Health Integration Guide
Integrate Oracle Health with enterprise systems through REST and FHIR APIs, OAuth 2.0, selective event notifications, and scheduled or bulk data workflows.
Oracle Health integration options at a glance
Oracle Health provides REST-based healthcare APIs, including FHIR-oriented APIs for supported products and tenants. Martini can consume these APIs, authenticate with OAuth 2.0 or applicable SMART on FHIR flows, process paginated FHIR Bundles, and map JSON resources into downstream applications or data platforms. Selected Oracle Health environments may support subscriptions or event notifications, but coverage varies by resource, product, FHIR version, and tenant. Bulk or asynchronous processing may be available for approved population-level use cases. Clinical documents may use DocumentReference and Binary rather than a general file-transfer interface. Scheduled polling remains an important option when event delivery is unavailable.
| Integration point | Supported by Oracle Health? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Oracle Health REST APIs support healthcare interoperability operations, including retrieval, search, and supported create or update actions for FHIR resources. Available resources, search parameters, and write permissions vary by product and tenant. | Martini can consume Oracle Health REST endpoints from workflows, pass bearer tokens, follow response links, transform JSON, and expose REST APIs for downstream callers. |
| FHIR APIs | Yes | FHIR provides the principal standards-based model for many Oracle Health interoperability APIs, including Patient, Encounter, Observation, Condition, and MedicationRequest resources. | Martini can map FHIR JSON, preserve identifiers and references, validate profiles and required fields, and apply business rules before writing to Oracle Health or another system. |
| Webhooks / outbound callbacks | Limited | Selected Oracle Health products or FHIR implementations may support subscriptions or event notifications. Coverage is product-, resource-, version-, and tenant-specific rather than universal. | Martini can receive supported notifications, validate the request, retrieve the current resource when the notification contains only an identifier, and route the result through a workflow. |
| Bulk / async / batch APIs | Limited | Bulk Data Access or asynchronous processing may be available for approved population-level data movement and larger exports. | Martini can orchestrate asynchronous job initiation and polling, process paginated or bulk results, checkpoint progress, and load validated data into approved targets. |
| File / attachment APIs | Limited | DocumentReference and Binary may represent clinical documents or content where enabled. These resources should not be treated as a general-purpose file-transfer API. | Martini can retrieve and route supported document content, preserve MIME types and references, and apply access, size, and retention rules defined for the environment. |
| Authentication | Yes | Oracle Health APIs commonly use OAuth 2.0. SMART on FHIR patterns may apply to user-authorized clinical applications, with scopes, access tokens, and launch context where applicable. | Martini can store client credentials and endpoint configuration securely, obtain or use access tokens, and separate development, test, and production settings. |
| GraphQL APIs | Not confirmed | No authoritative Oracle Health GraphQL API was confirmed for this integration scope. | Martini should use documented REST and FHIR endpoints unless Oracle provides product-specific GraphQL documentation. |
| SOAP APIs | Legacy | Older Oracle or Cerner deployments may expose legacy interfaces, but a current SOAP API was not confirmed as the recommended approach for new integrations. | Martini can consume SOAP services when a specific deployment confirms and provisions them, but the interface should be verified before implementation. |
How Oracle Health exposes data and business events
Oracle Health REST and FHIR APIs
Oracle Health provides REST-based healthcare APIs, with FHIR as the principal standards-based model for many interoperability use cases. Supported resources, FHIR versions, profiles, search parameters, and write operations depend on the product and tenant.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the configured Oracle Health endpoint, retrieves or submits supported FHIR resources, follows pagination links, maps FHIR JSON to a canonical or target model, and applies validation and business rules before completing the transaction.
Implementation sequence
Oracle Health subscriptions and notifications
Selected Oracle Health products or FHIR implementations may provide subscriptions, callbacks, or other event notifications. Coverage is not universal and must be confirmed for each resource, event type, tenant, and delivery model.
Martini implementation pattern
Martini implementation pattern: Martini receives the supported notification, validates the request, determines whether it contains a complete resource or only an identifier, retrieves the current FHIR resource when necessary, and routes it to downstream workflows. Where notifications are unavailable, the equivalent workflow uses scheduled incremental polling.
Implementation sequence
Oracle Health bulk and asynchronous processing
Bulk Data Access or asynchronous processing may be available for approved population-level exports and larger data movement. Availability and job behavior must be confirmed from the target capability statement.
Martini implementation pattern
Martini implementation pattern: a workflow starts an approved asynchronous or bulk operation, stores the job reference, polls under controlled timing, retrieves result files or pages, transforms resources, and checkpoints progress so interrupted processing can resume safely.
Implementation sequence
Oracle Health clinical documents
FHIR DocumentReference and Binary may represent clinical documents or document content when enabled by the relevant Oracle Health implementation. This capability is not equivalent to a general file-transfer service.
Martini implementation pattern
Martini implementation pattern: Martini retrieves the authorized document metadata or content, validates MIME type and access conditions, maps references and metadata, and routes the document to an approved system without exposing protected health information in routine logs.
Implementation sequence
Common Oracle Health integration patterns
Pattern 1: Synchronize Oracle Health patients and encounters to Salesforce
When to use this pattern
Use this pattern for approved care-coordination, provider-service, or patient-service workflows that require selected Oracle Health data in Salesforce. The integration should minimize protected health information and use an explicit cross-system identity strategy.
Integration direction
Example Mapping
| Oracle Health Field | Canonical Field | Target Field |
|---|---|---|
| Patient.id | sourcePatientId | External_Patient_ID__c |
| Patient.name | patientName | Name |
| Encounter.status | encounterStatus | Encounter_Status__c |
| Encounter.period | encounterPeriod | Last_Encounter_Date__c |
Martini implementation pattern
A scheduled Martini workflow queries authorized Patient and Encounter resources using supported incremental filters, follows FHIR pagination, and maps only approved fields to Salesforce. It matches on stable source identifiers, applies consent and minimum-necessary rules, performs idempotent upserts, and retries only transient API failures.
Martini capabilities used
- workflows
- API consumption
- OAuth 2.0 configuration
- data mapping
- business rules
- error handling
Pattern 2: Route Salesforce or ServiceNow requests to Oracle Health
When to use this pattern
Use this pattern when an operational or care-coordination application needs to request an Oracle Health action or retrieve a supported resource. The relevant Oracle Health resource and write operation must be explicitly permitted.
Integration direction
Example Mapping
| Oracle Health Field | Canonical Field | Target Field |
|---|---|---|
| request.patientIdentifier | patientIdentifier | Patient.identifier |
| request.requestType | operationType | FHIR resource or operation |
| request.requestedBy | requestingPractitioner | Practitioner reference |
| request.correlationId | correlationId | Request metadata |
Martini implementation pattern
Martini exposes a controlled REST API, authenticates and validates the caller, maps the request into a supported Oracle Health or FHIR operation, and returns a normalized response. Validation and authorization failures are rejected without retry, while throttling and transient server errors follow bounded retry policies.
Martini capabilities used
- API exposure
- workflow orchestration
- authentication and authorization
- data mapping
- validation
- error handling
Pattern 3: Export Oracle Health clinical data to an analytics platform
When to use this pattern
Use this pattern for approved operational reporting, population health, or analytical workloads involving Patient, Encounter, Observation, Condition, or MedicationRequest data. Bulk or asynchronous processing should be preferred when available for larger populations.
Integration direction
Example Mapping
| Oracle Health Field | Canonical Field | Target Field |
|---|---|---|
| Observation.code | clinicalCode | Observation_Code |
| Observation.value | observationValue | Measured_Value |
| Observation.effective | effectiveDateTime | Effective_Timestamp |
| Condition.code | conditionCode | Condition_Code |
Martini implementation pattern
A scheduled Martini workflow starts an approved bulk or asynchronous export where available, or uses controlled paginated searches for smaller incremental workloads. It transforms FHIR resources into analytical structures, removes fields not required for the use case, checkpoints progress, and isolates malformed resources for review.
Martini capabilities used
- scheduled workflows
- asynchronous orchestration
- API consumption
- JSON and FHIR mapping
- data transformation
- checkpointing
- monitoring
Pattern 4: Process Oracle Health event notifications
When to use this pattern
Use this pattern only when the target Oracle Health product and tenant support the required subscription, callback, or event mechanism. It is useful for selected clinical changes that need operational routing without waiting for a broad polling cycle.
Integration direction
Example Mapping
| Oracle Health Field | Canonical Field | Target Field |
|---|---|---|
| notification.resourceType | eventResourceType | Request_Type__c or Record_Type |
| notification.resourceId | sourceResourceId | External_Resource_ID__c |
| resource.meta.lastUpdated | sourceVersionTime | Source_Last_Updated__c |
| resource.status | businessStatus | Status |
Martini implementation pattern
Martini receives the notification through an API workflow, validates and deduplicates it, retrieves the current resource if needed, and applies routing rules based on resource type and status. If event delivery is not available, a scheduler uses an overlap window and durable watermark instead; all downstream writes use stable source identifiers.
Martini capabilities used
- API exposure
- webhook consumption
- event-driven workflows
- data mapping
- business rules
- idempotency
- retry handling
Applications commonly integrated with Oracle Health
Oracle Health integrations commonly connect approved clinical and operational data with enterprise applications. The exact objects, direction, permissions, and privacy controls must be confirmed for each product, tenant, and use case.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize approved patient-service, provider, referral, or care-coordination information with CRM workflows. | Oracle Health → Martini → Salesforce | Martini retrieves authorized Patient, Encounter, or related resources, maps FHIR JSON to Salesforce data, applies identity and minimum-necessary-data rules, and performs idempotent updates with retry handling. |
| ServiceNow | Route healthcare IT, operational, access, or service requests based on Oracle Health data or selected event notifications. | Oracle Health → Martini → ServiceNow | Martini receives an Oracle Health notification or scheduled result, retrieves the current resource when needed, transforms it into a ServiceNow request or case payload, and routes validation and transient failures for controlled retry. |
| Workday | Coordinate workforce, practitioner, department, or organizational data where healthcare workforce processes require synchronization. | Workday → Martini → Oracle Health | Martini compares approved Workday and Oracle Health identifiers, maps practitioner or organizational attributes to the supported Oracle Health operation, validates permissions, and records rejected changes without retrying non-retryable authorization failures. |
| Oracle Integration | Coordinate Oracle Health data with other Oracle Cloud applications and enterprise endpoints in a wider integration landscape. | Oracle Health → Martini → Oracle Integration | Martini acts as an API and workflow layer between Oracle Health and Oracle Integration, normalizing FHIR resources, applying routing rules, and exposing stable downstream contracts while product-specific API coverage is verified. |
| Oracle Analytics Cloud | Deliver approved clinical or operational data for reporting, population health, and analytics workloads. | Oracle Health → Martini → Oracle Analytics Cloud | A scheduled or asynchronous Martini workflow extracts supported resources, follows pagination or approved bulk export behavior, removes or transforms sensitive fields as required, and loads validated analytical data. |
| Epic | Exchange authorized patient, clinical, referral, or interoperability data between healthcare organizations using standards-based interfaces. | Oracle Health → Martini → Epic | Martini mediates the exchange between independently authorized healthcare APIs, preserves FHIR identifiers and references, applies consent and minimum-necessary rules, and isolates resource-level validation failures. |
| Cerner Millennium | Support integrations with legacy or existing Oracle Health environments associated with the Cerner product family. | Cerner Millennium → Martini → Oracle Health | Martini consumes the specific interface or API provisioned for the deployment, maps legacy or product-specific payloads into a canonical model, and keeps environment-specific endpoints and credentials outside workflow logic. |
How to build a Oracle Health integration in Martini
Objective
Establish environment-specific access to the Oracle Health product, tenant, and API base URL without embedding credentials in workflow logic.
Instructions in Martini
- Confirm the Oracle Health product, tenant, FHIR version, endpoint, and permitted operations.
- Register the Martini client using the required OAuth 2.0 or SMART on FHIR process.
- Store client secrets, tokens, scopes, and endpoint settings in secure environment configuration.
- Use separate configuration for development, test, and production.
Objective
Select an event, API request, or scheduled trigger based on the capabilities confirmed for the Oracle Health environment.
Instructions in Martini
- Use a supported Oracle Health subscription or notification only for confirmed resources and events.
- Use a Martini REST API when another application initiates the transaction.
- Use a scheduler with a durable watermark when event delivery is unavailable.
- Select bulk or asynchronous processing for approved larger data movements.
Objective
Obtain the current Oracle Health resource or result set while respecting pagination, authorization, and tenant-specific limits.
Instructions in Martini
- Call the documented REST or FHIR endpoint with the required bearer token and scopes.
- Follow server-provided next links for paginated Bundles.
- Use supported updated filters, change tokens, or bulk jobs for incremental extraction.
- Avoid assuming that read access permits create or update operations.
Objective
Coordinate retrieval, enrichment, routing, target writes, and recovery as a maintainable Martini workflow.
Instructions in Martini
- Separate notification receipt from resource retrieval when notifications contain only identifiers.
- Apply correlation IDs and preserve source resource identifiers.
- Use conditional routing for resource type, status, consent, and target system.
- Keep reusable validation and transformation logic in shared integration assets where appropriate.
Objective
Transform FHIR JSON and product-specific extensions into the canonical or target data model without losing important clinical context.
Instructions in Martini
- Preserve identifiers, references, coding systems, timestamps, and relevant extensions.
- Validate required fields, profiles, terminology, and target-specific constraints.
- Apply minimum-necessary-data rules before sending protected health information downstream.
- Handle missing, repeated, and unknown fields deliberately.
Objective
Deliver approved data to Salesforce, ServiceNow, analytics platforms, databases, or other authorized endpoints with safe update behavior.
Instructions in Martini
- Use idempotent upserts or stable source identifiers where supported.
- Confirm the Oracle Health API explicitly permits each create or update operation.
- Return normalized responses from Martini APIs to calling applications.
- Avoid duplicate clinical or operational records when a retry follows an uncertain response.
Common Oracle Health data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Patient | Demographic and identifying information used for approved care coordination, service workflows, and clinical data exchange. | Salesforce, Epic, Oracle Analytics Cloud, approved data platforms | Martini preserves the FHIR resource ID and identifiers, applies minimum-necessary-data rules, validates the target profile, and uses an identity cross-reference to prevent duplicates. |
| Encounter | Patient visits, appointments, admissions, and other clinical interactions. | Salesforce, ServiceNow, Oracle Analytics Cloud, approved data warehouses | Martini maps encounter status, dates, participants, locations, and references while applying business rules for permitted downstream use and handling paginated retrieval. |
| Observation | Clinical measurements, laboratory values, and other observations. | Oracle Analytics Cloud, population health platforms, approved data warehouses | Martini preserves coding systems, values, units, timestamps, references, and relevant extensions, then validates and transforms the resource for analytical or operational use. |
| Condition | Diagnoses and clinical conditions associated with a patient. | Analytics platforms, care-coordination applications, approved clinical systems | Martini maps clinical codes and statuses without discarding source references, applies privacy and authorization rules, and routes invalid terminology or profile data for review. |
| MedicationRequest | Medication orders or prescriptions and their clinical status. | Care-coordination applications, analytics platforms, approved clinical systems | Martini preserves medication references, intent, status, authored dates, and patient references, while allowing only explicitly authorized write operations. |
| Practitioner | Clinicians and other healthcare professionals participating in care or organizational processes. | Workday, Salesforce, Oracle Analytics Cloud, approved provider directories | Martini maps stable identifiers, names, roles, and organization references, applies cross-system identity rules, and avoids assuming that every standard field is available in the tenant. |
Authentication and security considerations
OAuth 2.0 and SMART on FHIR
Oracle Health APIs commonly use OAuth 2.0. SMART on FHIR authorization may apply to user-facing clinical applications and can introduce launch context, scopes, and user-authorized flows. The exact grant type, audience, token endpoint, and registration process depend on the product and environment.
Protect clinical information
- Store client secrets, tokens, scopes, and endpoint configuration in Martini secure environment configuration.
- Use TLS-secured HTTPS communication and separate credentials for development, test, and production.
- Apply minimum-necessary-data, consent, authorization, retention, and audit requirements.
- Do not place complete FHIR resources or protected health information in routine diagnostic logs.
Operational considerations for Oracle Health integrations
Pagination and incremental synchronization
FHIR searches commonly return paginated Bundles. Follow server-provided continuation links, use safe page sizes, and store a durable watermark. An overlap window can reduce missed changes, but requires deduplication using stable resource identifiers.
Limits and recovery
- Confirm tenant-specific quotas and implement exponential backoff for throttling and transient server errors.
- Use idempotent writes, source identifiers, and correlation IDs to make retries safe.
- Separate authentication, authorization, validation, throttling, and server failures so only transient conditions are retried.
- Monitor FHIR capability statements, profiles, terminology, extensions, and release changes.
- Test with representative data, including missing fields, repeated fields, extensions, references, and malformed resources.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than API calls
Scripts can call an endpoint, but enterprise Oracle Health integrations also require authentication management, pagination, incremental checkpoints, FHIR-aware mapping, privacy rules, idempotency, retries, and operational visibility. Martini provides a workflow layer for coordinating these concerns.
Maintainable integration assets
- Expose stable APIs for Salesforce, ServiceNow, and other callers while keeping Oracle Health-specific details behind a controlled workflow.
- Reuse mappings, validation, security configuration, and error-handling patterns across resources and environments.
- Switch between event notifications, scheduled polling, and bulk processing without redesigning every downstream connection.
- Apply business rules and transformations consistently instead of duplicating point-to-point code.
Frequently asked questions
Oracle Health can be integrated through its REST-based healthcare APIs, including FHIR APIs for supported products and tenants. Enterprise workflows can retrieve, search, and, where permitted, create or update FHIR resources using OAuth 2.0 or applicable SMART on FHIR authorization. Selected environments may also support subscriptions or event notifications, while scheduled polling and bulk or asynchronous processing can support other synchronization needs.
Yes. Martini can integrate with Oracle Health by consuming documented REST and FHIR APIs, authenticating with the required OAuth 2.0 or SMART on FHIR configuration, mapping FHIR JSON, receiving supported notifications, and exposing APIs for downstream applications. The exact resources, operations, and event capabilities depend on the Oracle Health product and tenant.
No. A dedicated Oracle Health connector is not required. Martini can use Oracle Health's confirmed native integration mechanisms, including REST and FHIR APIs, OAuth 2.0, supported notifications, scheduled polling, and approved bulk or asynchronous endpoints.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Oracle Health. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Oracle, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
REST and FHIR APIs are the primary methods for new integrations. Use OAuth 2.0 or SMART on FHIR as required by the target API, and consider bulk or asynchronous processing for approved population-level workloads. GraphQL was not confirmed, and current SOAP support was not confirmed as a recommended mechanism.
Selected Oracle Health products or FHIR implementations may support subscriptions, callbacks, or event notifications, but coverage is partial and product-specific. Confirm the resource, event types, payload behavior, delivery retries, and tenant provisioning requirements. Martini can receive supported notifications or use scheduled incremental polling when events are unavailable.
Martini can use FHIR search parameters, updated filters, change tokens, subscriptions, or bulk jobs to retrieve data. Workflows follow pagination, store durable watermarks, apply overlap windows and deduplication, and map identifiers, references, coding systems, extensions, and timestamps into downstream models.
Martini can distinguish authentication, authorization, validation, throttling, and transient server errors; retry transient failures with bounded backoff; and route non-retryable issues for review. Stable FHIR identifiers, correlation IDs, and idempotent target writes help prevent duplicates. Martini can also expose a controlled REST API façade for Salesforce, ServiceNow, or other applications.
Related Martini documentation
Integrate Oracle Health with confidence
Use Martini to build secure, maintainable Oracle Health integrations around documented APIs, FHIR resources, approved event mechanisms, and enterprise workflow requirements.