Creating FHIR Resources

Create a FHIR resource by checking the deployed capability statement, sending a POST request to the matching versioned API base URL, and verifying the response.

The FHIR create interaction assigns a logical ID and an initial version to a new resource. This procedure uses a FHIR R4 Patient resource as the example.

Before you begin

Confirm that:

You have access to a DDFS instance and its FHIR API base URL. An administrator must grant access to the DDFS service resources that you intend to manage. See DDFS policies. These IAM policies grant access to DDFS service resources; they do not authorize protected FHIR API requests.
You have configured a confidential application in OCI Identity Domains and obtained an OAuth access token with permission to create the resource. For this Patient example, the client requests an approved Patient create or write scope, such as ddfssystem/Patient.c or ddfssystem/Patient.write. See authentication and scope syntax.
Your resource body is valid for the selected FHIR version and any profiles required by your workflow.

Step 1: Create a DDFS instance

If you do not already have an instance, see Creating a DDFS Instance.

Step 2: Get your FHIR API URL

Use the R4 base URL for FHIR R4 (4.0.1) resources and the R6 base URL for FHIR R6 ballot4 (6.0.0-ballot4) resources:

FHIR R4 (4.0.1) base URL:

https://<ddfs-instance-id>.ddfs.<region>.oci.oraclecloud.com/api/fhir/r4

FHIR R6 ballot4 (6.0.0-ballot4) base URL:

https://<ddfs-instance-id>.ddfs.<region>.oci.oraclecloud.com/api/fhir/r6-ballot4

1. Open the navigation menu, select Developer Services, and then select Device Data FHIR Service.
2. Select the DDFS Instance you want to work with.
3. In the Instance details, find the FHIR service endpoint.
4. Copy the R4 or R6 FHIR API base URL required by your workflow.
Use the oci ddfs instance get command to retrieve the instance details:
```
oci ddfs instance get --instance-id <instance-OCID>
```
Use the returned FHIR service endpoint to construct the required R4 or R6 base URL.
Run the GetInstance operation to retrieve the DDFS instance details.

Use the returned FHIR service endpoint to construct the required R4 or R6 base URL.

Step 3: Confirm Resource and Create Support

Call GET <FHIR_API_BASE_URL>/metadata. The returned CapabilityStatement is the authority for the deployed DDFS instance.

GET <FHIR_API_BASE_URL>/metadata
Accept: application/fhir+json

For this example, find the rest.resource entry whose type is Patient, confirm that its interaction list contains create, and confirm support for application/fhir+json.

$metadata = Invoke-RestMethod `
  -Method Get `
  -Uri "<FHIR_API_BASE_URL>/metadata" `
  -Headers @{ Accept = "application/fhir+json" }

$patient = $metadata.rest.resource | Where-Object { $_.type -eq "Patient" }
$patient.interaction.code -contains "create"

For more information, see FHIR Capability Statements.

Step 4: Construct the JSON Request Body

Save the following FHIR Patient resource as create-patient.json:

{
  "resourceType": "Patient",
  "identifier": [
    {
      "system": "urn:oid:1.2.36.146.595.217.0.1",
      "value": "12345"
    }
  ],
  "name": [
    {
      "family": "Silva",
      "given": ["Ana", "Carolina"]
    }
  ],
  "gender": "female",
  "birthDate": "1992-02-10"
}

Step 5: Send the Request

The examples set Prefer: return=representation because the next step inspects the response resource. Send the resource as application/fhir+json.

curl -sS -X POST \
  -H "Authorization: Bearer <access-token>" \
  -H "Accept: application/fhir+json" \
  -H "Content-Type: application/fhir+json" \
  -H "Prefer: return=representation" \
  --data @create-patient.json \
  "<FHIR_API_BASE_URL>/Patient"

$headers = @{
  Authorization = "Bearer <access-token>"
  Accept = "application/fhir+json"
  "Content-Type" = "application/fhir+json"
  Prefer = "return=representation"
}

Invoke-RestMethod `
  -Method Post `
  -Uri "<FHIR_API_BASE_URL>/Patient" `
  -Headers $headers `
  -InFile ".\create-patient.json"

Step 6: Verify the Response

A successful create returns 201 Created. Because the request uses Prefer: return=representation, verify the response body as well as the headers. The following response is an excerpt; the server can return additional elements:

201 Created
Location: <FHIR_API_BASE_URL>/Patient/{rid}/_history/{vid}
ETag: W/"{vid}"
Content-Type: application/fhir+json

{
  "resourceType": "Patient",
  "id": "{rid}",
  "meta": {
    "versionId": "{vid}",
    "lastUpdated": "{timestamp}"
  },
  "identifier": [
    {
      "system": "urn:oid:1.2.36.146.595.217.0.1",
      "value": "12345"
    }
  ]
}

The versioned Location identifies the created logical resource and its new version.
The weak ETag version matches meta.versionId.
The response resource contains the assigned id, meta.versionId, and meta.lastUpdated.

Store the logical ID for later read, update, or delete requests. Do not treat the version ID as the logical ID.

Oracle Cloud Infrastructure Documentation