Device Data FHIR Service FAQs

Use the DDFS FHIR metadata endpoint to discover capability information for supported APIs. DDFS exposes resources under /api/fhir/r4 and /api/fhir/r6-ballot4 depending on the resource family. DDFS does not expose authorization, token, or authentication configuration endpoints. For more information, see Capability Statements.

Device Data FHIR Service (DDFS) is an OCI-native service for device-data FHIR workflows. DDFS exposes FHIR APIs for supported R4 and R6 resources so API clients can work with device, patient, observation, and related healthcare data. For more information, see Device Data FHIR Service Overview.

Start by confirming the DDFS instance and endpoint information, configuring OAuth access through OCI Identity Domains, checking the FHIR metadata endpoint for supported capabilities, and then using the R4 or R6 API path for the resource workflow you need. For more information, see Getting Started.

Create or select the DDFS service instance in OCI, then use the instance details or developer integration information to find the FHIR API base URLs. DDFS exposes versioned FHIR endpoints under /api/fhir/r4 and /api/fhir/r6-ballot4 depending on the resource family. For more information, see FHIR Endpoints Reference.

Use the DDFS FHIR metadata endpoint and the R4 and R6 resource documentation to confirm the supported resource list. Resource support differs by FHIR version, so check the version-specific documentation before building an integration. For more information, see FHIR R4 Resources, FHIR R6 Resources, and Capability Statements.

Use the version-specific R4 or R6 search endpoint for the resource and only the search parameters supported by DDFS for that resource. Check the metadata endpoint or resource documentation for supported filters, pagination behavior, and parameters such as _count and _total. For more information, see FHIR R4 Search, and FHIR R6 Search.

Use the DDFS Device search endpoint for the FHIR version you are calling. Check the Device documentation for supported parameters such as identifier, manufacturer (Device?manufacturer=Example), model, status, type, and version-specific patient or association behavior. For more information, see Device, and Device R6.

Use R6 DeviceAssociation when your workflow needs to represent an association between a device and another subject, such as a patient. Check the R6 DeviceAssociation documentation for supported fields, search behavior, and how it relates to Device and Observation workflows. For more information, see Device Association.

DDFS supports Observation searches by patient, device, and encounter on both the R4 and R6 API surfaces. Refer to the version-specific API documentation for all supported parameters. For more information, see Search Observations, FHIR R4 Observation, and FHIR R6 Observation.

Use the Provenance resource documentation for the FHIR version you are calling to understand supported Provenance search parameters. Provenance helps clients inspect source, authorship, and audit-related metadata associated with FHIR resources. For more information, see FHIR R4 Provenance, and FHIR R6 Provenance.

Use supported FHIR date search parameters with FHIR date prefixes, such as greater-than or less-than, when the target resource and parameter support range-style search. Check the version-specific resource documentation before relying on a date or birthdate range filter. For more information, see Reference: Supported Search Parameters.

DDFS returns FHIR OperationOutcome responses for many validation and business-rule failures. Check the HTTP status code, issue severity, diagnostics, and the request payload or query parameters to identify whether the problem is invalid JSON, unsupported search criteria, authorization failure, or a resource state conflict. For more information, see Reference: OperationOutcome Errors, and FHIR Status Codes.

Use resource-specific documentation and examples to confirm where DDFS supports FHIR extensions and primitive extensions. Primitive extension support can vary by resource, field, datatype, and FHIR version, so validate the target resource before sending extension content. For more information, see Reference: Primitive Extensions.

Configure manufacturer access by combining OCI Identity Domains authorization, DDFS resource scopes, supported Device or Observation searches, and R6 subscription workflows when event notifications are needed. For Device data, use supported manufacturer search such as Device?manufacturer=Example. For related Observations, use only supported Observation search parameters; when manufacturer filtering is required, use the documented chained search form such as Observation?device.manufacturer=Example if supported for the DDFS FHIR version. Avoid unsupported patient/... scopes and Patient _id or identifier scope constraints for manufacturer access. Use least-privilege scopes and version-specific API documentation for the resources the manufacturer must access. For more information, see Scenario: Device Manufacturer Access Device and Patient Data for FHIR R4 + R6.

Start by checking the endpoint path, FHIR version, OAuth token audience and scopes, supported resource and search parameters, request payload validity, and HTTP status or OperationOutcome diagnostics. The DDFS metadata endpoint and version-specific resource documentation can help confirm whether the operation is supported. For more information, see Troubleshooting, and FHIR Status Codes.

Use the FHIR R6 DeviceAssociation resource. Search DeviceAssociation resources using the patient or subject search parameter. For a patient-device association, represent the patient in DeviceAssociation.subject. The current DDFS API does not expose a focus search parameter. See Device Association.

Device data is represented as FHIR Observation resources. Use the Observation search operation to search by supported parameters such as category, code, date, device, encounter, patient, and status.

FHIR R6 is the recommended version for new integrations. FHIR R4 endpoints are also supported for workflows that require R4 compatibility. Because supported resources and capabilities differ between versions, review the version-specific documentation before selecting an endpoint.

Yes. Applications can create Observations with the appropriate FHIR status. Represent verification state through Observation.status, such as changing an Observation from preliminary to final, depending on the application workflow.

Yes. Applications can update an Observation resource, for example to change Observation.status.

Use the FHIR Subscription resource. DDFS supports Subscription, and the intended pattern is to create a Subscription so DDFS can send updates based on the events or changes requested in that Subscription.

Applications manage the Observation lifecycle by setting Observation.status and using supported update or delete operations when a workflow requires a change.

No. DDFS exposes the DeviceAssociation resource, but applications are responsible for clinical association, disassociation, and collision rules.

DDFS is a FHIR server. Applications can decide how much Patient, Encounter, and Location information they need to write. FHIR idioms such as profiles and tags should be used for interoperability. EHR teams may choose to send EHR client IDs with device association information rather than fully replicating all clinical data, depending on their workflow.

DDFS and the IoT Platform are separate platforms. IoT is one way data may get to DDFS, but that transport path should not be relevant to EHR consumers. From the EHR perspective, device data lives in DDFS, and the EHR should connect to DDFS rather than directly to IoT. How data is transported into DDFS should be abstracted away from the EHR.

DDFS already supports POST APIs by implementing the FHIR standard, which enables systems such as IoT to post FHIR resources into DDFS.

Applications can use the DDFS FHIR APIs to create supported FHIR resources. An upstream system, such as an IoT platform or gateway, must send valid FHIR requests to the appropriate DDFS FHIR endpoint. For supported resources and request requirements, see the version-specific DDFS API documentation.

Yes. DDFS implements the FHIR standard and can accept POSTs of FHIR resources. For device workflows, this typically means systems can post resources such as Observation, Device, DeviceAssociation, Patient, Encounter, Location, and Provenance when those resources are needed for the workflow.

IoT handles device telemetry and operational device data. This can include raw or normalized device measurements, device events, alarms, gateway metadata, device identifiers, message timestamps, and other transport-level details. The IoT Platform collects and routes data emitted by devices.

DDFS handles healthcare data represented as FHIR resources. Device measurements can be represented as FHIR Observation resources and linked to clinical context such as Patient, Encounter, Device, DeviceAssociation, Location, Practitioner, Organization, ServiceRequest, Provenance, Specimen, and DiagnosticReport resources.

In short, IoT is message and telemetry oriented, while DDFS is FHIR and clinical resource oriented. The EHR should consume device data from DDFS using the supported FHIR APIs. Device telemetry ingestion is outside this FHIR API workflow.

IoT may partition or route data by device, gateway, tenant, topic, region, environment, or time. DDFS and FHIR organize data around clinical resources and references, such as Patient, Encounter, Device, DeviceAssociation, Location, and Observation. Patient and encounter references are what make a device measurement clinically meaningful to the EHR.

The application that creates FHIR resources is responsible for supplying the patient and encounter references appropriate to its workflow.

No. DDFS exposes FHIR APIs and does not provide device-specific integrations or drivers. Devices, applications, gateways, or other systems integrate with DDFS by sending FHIR-compliant requests.

DDFS uses OCI Identity Domains to issue OAuth access tokens and validate JWTs. In OCI Identity Domains, configure a protected resource server, define the DDFS FHIR system/... scopes on the resource server, and grant the needed ddfs-prefixed scopes to the client application. DDFS does not expose authorization, token, or authentication configuration endpoints. For more information, see Create Integrated Application, and DDFS Authentication Reference.

Use an OCI Identity Domains confidential client application for server-side integrations that can protect a client secret. Grant the client only the DDFS resource scopes needed for its workflow, request the fixed ddfs-prefixed scopes in the token request, and store or rotate client credentials according to your security standard. For more information, see Create an Integrated Application and Security Best Practices.

DDFS resource-server scope definitions use the canonical form, such as system/Device.rs. Client grants and token requests use the fixed ddfs-prefixed form, such as ddfssystem/Device.rs. The issued token's scope claim contains the canonical form, such as system/Device.rs. The scope prefix is independent of the token audience. For more information, see DDFS Authentication and Authorization Reference.

DDFS supports constrained system/... scopes by adding supported FHIR-style search criteria after ?. For example, a Device read and search grant can be limited by manufacturer with system/Device.rs?manufacturer=Example. Define constrained scopes without the client-facing ddfs prefix on the DDFS resource server, and request the ddfs-prefixed form from the client application. Do not model DDFS API access with unsupported patient/... scopes or Patient _id or identifier scope constraints unless the DDFS documentation explicitly lists that constraint as supported. For more information, see DDFS Authentication and Authorization.

DDFS rejects tokens that do not match the expected issuer, tenant issuer, audience, subject type, or supported scope forms. FHIR access tokens must contain the supported canonical system/... resource scopes required by the request. Client grants and token requests use the corresponding ddfs-prefixed form. For more information, see DDFS Authentication and Authorization, and Troubleshooting.

DDFS hard-delete and purge-deleted routes require two scopes in the caller's token: the canonical custom hard-delete scope and a matching canonical resource delete scope, such as system/Patient.d. Grant and request the corresponding resource scope with the fixed prefix, such as ddfssystem/Patient.d. The custom hard-delete scope alone is not enough, and a normal delete scope alone does not allow $hardDelete or $purgeDeleted. For more information, see Reference: Purge Deleted, Hard Delete, and Subscription Status.

Create a FHIR R6 SubscriptionTopic with a supported trigger resource and valid FHIR-style criteria. DDFS requires the topic URL to be unique among current, nondeleted SubscriptionTopic resources and validates trigger resources, query criteria, and canFilterBy parameters before accepting the topic. For more information, see Create SubscriptionTopic and Subscription Topic.

A DDFS SubscriptionTopic can fail validation if its topic URL is already used by another current, nondeleted topic, its trigger resource is not supported, its query criteria are not valid, or a declared canFilterBy parameter is not supported for the trigger resource. DDFS returns a FHIR OperationOutcome for unsupported resources or search parameters. For more information, see Subscription Topic and OperationOutcome errors.

Create a FHIR R6 Subscription with status set to requested, a topic that resolves to an existing SubscriptionTopic, channelType set to rest-hook, and a publicly routable HTTPS endpoint that uses port 443. DDFS sends a REST-hook handshake and sets the Subscription status to active if the handshake succeeds. For more information, see Create Subscription and Subscription.

Check that the request is a valid FHIR R6 Subscription, that its referenced SubscriptionTopic exists and is active, and that the request uses supported resource fields and operations. For the supported workflow and operation references, see FHIR R6 Subscription Workflow.

For authenticated notification delivery, use the DDFS custom OCI Vault extension to reference a server-managed authorization secret. See FHIR R6 Subscription OCI Vault Secret Extension.

A failed handshake changes the Subscription status to error. Use GET /api/fhir/r6-ballot4/Subscription/{rid}/$status to retrieve status information for the Subscription. An unsuccessful response to a later event notification is a delivery failure and is not a new handshake result.

Use standard FHIR delete first. After the resource is deleted, an authorized administrator can call POST /api/fhir/{r4|r6-ballot4}/{Resource}/{id}/$hardDelete to permanently remove that deleted resource. $hardDelete returns a FHIR OperationOutcome. For more information, see Scenario: Delete, Purge Deleted, and Hard Delete, and Reference: Purge Deleted, Hard Delete, and Subscription Status.

Use POST /api/fhir/{r4|r6-ballot4}/{Resource}/$purgeDeleted to purge eligible deleted resources. Send required before as Parameters.parameter.valueDateTime and optional limit as Parameters.parameter.valueInteger in a FHIR Parameters request body. The operation applies the hard-delete authorization model to each candidate, returns a FHIR OperationOutcome, and caps limit at 50. For more information, see Reference: Purge Deleted, Hard Delete, and Subscription Status.

A DDFS hard-delete or purge request can fail if the resource is not already soft-deleted, the token is missing the custom hard-delete scope, the token is missing the matching canonical system/... delete scope, or a constrained delete scope does not cover the candidate resource. Client grants and token requests use the corresponding ddfssystem/... form. Authorization failures are rejected before purge behavior completes. For more information, see Reference: Operations Purge and Status, and Reference: OperationOutcome Errors.