Oracle Cloud Infrastructure Documentation

Accessing Patient Data

Confirm deployed capabilities and permissions, read a Patient, and search related clinical resources.

What This Scenario Assumes

Your deployment already has the required identity configuration and your application can obtain an OAuth access token with the approved permissions.

Application registration, consent, scope provisioning, and tenant-specific setup can vary by deployment. Confirm the required setup before onboarding a production client.

Prerequisites

  • An access token provisioned for the intended workflow.
  • The DDFS endpoint origin represented by {base}.
  • The correct versioned API surface for the resources that you need.
  • A Patient logical ID or supported identifier needed by the read and search calls.

Confirm Capabilities

Before making a resource request, retrieve the CapabilityStatement from the metadata endpoint for the deployed DDFS instance. This example uses FHIR R4 (4.0.1):

GET {base}/api/fhir/r4/metadata
Accept: application/fhir+json

Confirm that the capability statement advertises Patient and each related resource, interaction, and search parameter required by the workflow. For a FHIR R6 ballot4 (6.0.0-ballot4) workflow, check GET {base}/api/fhir/r6-ballot4/metadata and keep all resource requests on that API surface.

Plan Permissions

Grant only the read permissions required by the workflow. A Patient access workflow can require Patient, Observation, Condition, or Provenance reads, depending on which resources the application actually requests.

See DDFS Authentication Reference and the DDFS OAuth Scope Matrix.

Call the FHIR API

Retrieve the current Patient by logical ID:

curl -sS \
  -H "Accept: application/fhir+json" \
  -H "Authorization: Bearer {access-token}" \
  "{base}/api/fhir/r4/Patient/{rid}"

Search Observations for the Patient:

curl -sS \
  -H "Accept: application/fhir+json" \
  -H "Authorization: Bearer {access-token}" \
  "{base}/api/fhir/r4/Observation?patient=Patient/{patient-id}"

Search Conditions for the Patient:

curl -sS \
  -H "Accept: application/fhir+json" \
  -H "Authorization: Bearer {access-token}" \
  "{base}/api/fhir/r4/Condition?patient=Patient/{patient-id}"

Search Provenance resources by target:

curl -sS \
  -H "Accept: application/fhir+json" \
  -H "Authorization: Bearer {access-token}" \
  "{base}/api/fhir/r4/Provenance?target=Patient/{patient-id}"

FHIR search URLs can contain sensitive identifiers and PHI. See Protect Sensitive Search Data before enabling request logging or sharing diagnostics.

Validate the Returned Resources

  • Validate each resource against the FHIR version and any profiles required by your application or exchange agreement.
  • Do not infer a profile guarantee from this scenario. Inspect meta.profile when present and validate it against the requirements of your workflow.
  • Handle FHIR-formatted errors as OperationOutcome resources. See OperationOutcome Reference.

Troubleshooting

  • 401 Unauthorized: Verify token validity, audience, and deployment configuration.
  • 403 Forbidden: Verify that the token grants the permission required for the requested resource.
  • 400 Bad Request: Verify the parameter name, value syntax, date prefix, and resource reference.

For more information, see Troubleshooting and FAQs.

References