Overview

The Device Data FHIR Service provides a managed FHIR server on OCI for developers and administrators who need to integrate healthcare device data with applications, middleware, and operational systems.

• Developers: Use FHIR R4 and FHIR R6 6.0.0-ballot4 REST APIs to build client applications, device gateways, EHR extensions, and middleware integrations.

  Use the FHIR server to:

  • Store FHIR resources and use lifecycle features such as versioning, history, logical delete, and purge operations.
  • Validate payloads against supported FHIR schemas and implemented DDFS constraints.
  • Use supported search parameters, modifiers, and chained search parameters to query resources.
  • Configure FHIR R6 6.0.0-ballot4 Subscriptions that use an OCI Vault secret for outbound notification authorization.
• Administrators: Use OCI controls to manage authentication, authorization, networking, IAM policies, metrics, events, and service operations.

The service stores and exposes healthcare device data as FHIR resources. Clients use standard FHIR REST interactions to create, read, update, delete, and search FHIR resources.

• Use version-specific base paths for FHIR R4 and FHIR R6 6.0.0-ballot4 resources.
• Use resource-specific search parameters to query data instead of list-style collection APIs.
• Use CapabilityStatement resources to understand supported resources, interactions, operations, and search parameters for a deployment.
• Use OCI operational features such as work requests, metrics, events, and IAM policies to administer the service.

FHIR clients send REST requests to the versioned FHIR API. The service validates the request, applies lifecycle and authorization controls, stores or retrieves the resource, and returns a FHIR resource, Bundle, or OperationOutcome response.

Oracle Cloud Infrastructure Resources: Create a DDFS Instance to create the FHIR endpoints and server. Use work requests to monitor instance operations.

FHIR resource: A structured healthcare data type such as Patient, Device, Observation, or Subscription.

FHIR Resource instance: One record of a resource type, identified by its logical id. For example, Patient/{rid}.

Logical id: The {rid} value used in FHIR resource instance paths.

Version id: The {vid} value used by FHIR versioned read paths such as /Resource/{rid}/_history/{vid}.

Bundle: A FHIR container used for search results and some operations. Search endpoints return a Bundle with type set to searchset.

OperationOutcome: The FHIR response resource used to describe operation results and many error conditions. See OperationOutcome Reference.

HTTP media type: Use application/fhir+json for FHIR request and response payloads.

DDFS search result controls: Use _count to limit results. To retrieve more results, follow the server-provided Bundle.link URL whose relation is next. Common advertised controls also include _total, _id, _lastUpdated, _profile, and _tag. See Supported Search and Control Parameters.

Resource-specific search parameters: Parameters such as patient, status, code, category, date, name, identifier, topic, and url vary by resource and FHIR version.

Administrative delete operations: Collection-level $purgeDeleted permanently purges deleted resources before a specified date and can be limited by count. Instance-level $hardDelete permanently removes one deleted resource instance. See Scenario: Delete, Purge Deleted, and Hard Delete.

FHIR and OCI resources: FHIR resources represent healthcare data and server behavior. OCI resources represent service infrastructure such as instances, work requests, logs, metrics, and events.

The service supports OCI resources such as instances and work requests. Most OCI resources have an Oracle Cloud ID (OCID). For more information, see Resource Identifiers.

FHIR resources use FHIR logical ids, not OCIDs.

You can access OCI by using the Console, REST APIs, SDKs, CLI, or Cloud Shell. For general REST API guidance, see Using REST APIs.

Access to OCI resources and FHIR endpoints requires the authentication and authorization configuration for your deployment. Contact your administrator if a request returns an unauthorized or forbidden response.

Administrators must configure the required IAM groups, policies, networking, and service access before users and applications can access the FHIR and OCI resources.

DDFS uses OCI Identity Domains for OAuth access tokens and JWT validation. Administrators model DDFS as a protected resource server application and authorize client applications to request DDFS scopes. DDFS is not a SMART on FHIR authorization server and does not expose SMART authorize, token, or SMART configuration endpoints.

Use two integrated application concepts when configuring OAuth access:

• DDFS resource server application: Represents the protected DDFS FHIR API and defines the scopes clients may request. Define resource server scopes without the client-facing ddfs prefix, such as system/Patient.rs.
• Client application: Represents the system calling DDFS. Grant the client only the DDFS resource scopes it needs. Client grants and token requests use the fixed ddfs-prefixed form, such as ddfssystem/Patient.rs. Issued access-token scope claims use the corresponding canonical system/... form.

Supported operation letters are c for create, r for read, u for update, d for delete, and s for search. DDFS also supports aliases such as read, write, and *. Token audience validation is independent of the fixed scope prefix.

Examples of client-facing scopes include ddfssystem/Patient.rs, ddfssystem/Observation.read, ddfssystem/Device.write, ddfssystem/*.r, and ddfssystem/*.*. DDFS also supports constrained scopes by appending FHIR-style search criteria, for example ddfssystem/Device.rs?manufacturer=Demo.

Hard-delete and purge-deleted routes require both a matching ddfs-prefixed delete grant, such as ddfssystem/Patient.d, and the client-facing DDFS hard-delete scope: ddfshttps://docs.oracle.com/iaas/device-data-fhir/scopes/hard-delete.

For detailed setup guidance, see Create Integrated Applications for DDFS OAuth.

OCI IAM policies control access to DDFS service resources such as instances and work requests. These policies are separate from DDFS FHIR OAuth scopes, which authorize FHIR data-plane calls.

For DDFS service resources, use the aggregate resource type ddfs-instance-family or the individual resource types ddfs-instance and ddfs-work-request. For the complete policy and permission mapping, see Details for the Device Data FHIR Service.

Lets a group of users manage OCI device data FHIR resources in a specific compartment.

allow group <group-name> to manage ddfs-instance-family in compartment <compartment-name>

Lets a group of users manage device data FHIR instance in a specific compartment.

allow group <group-name> to manage ddfs-instance in compartment <compartment-name>

Lets a group of users manage device data FHIR work requests in a specific compartment.

allow group <group-name> to manage ddfs-work-request in compartment <compartment-name>

Depending on your deployment configuration, you may also require dependency policies for Identity Domains application administration including, vault secrets, metrics, or events. Configure policies for the compartments in your deployment.

Lets users query metrics for a specific compartment

Allow group <group-name> to read metrics in compartment <compartment-name>

The following DDFS resource limits are regional and per tenancy.

For a list of applicable limits and instructions for requesting a limit increase, see Service Limits.

Oracle provides security of cloud infrastructure and operations, such as cloud operator access controls and infrastructure security patching. You are responsible for securely configuring your cloud resources. Security in the cloud is a shared responsibility between you and Oracle. See DDFS Security Best Practices.

Your responsibilities include limiting privileges, protecting network access, managing credentials and secrets, and limiting physical access to on-premises healthcare devices.