FHIR1 input → 1 output

FHIR Update

Updates an existing FHIR resource on the server using a full resource replacement (PUT).

Inputs

payload.access_token string: Access token for FHIR server authentication (required)
payload.resource object: Complete FHIR resource object to update. Must include resourceType. Overrides node configuration
payload.resourceId string: ID of the resource to update. Overrides node configuration. Falls back to resource.id
payload.resourceType string: FHIR resource type to override the one in the resource object

Outputs

payload object

The updated FHIR resource as returned by the server

fhir object

Metadata about the FHIR operation:

resourceType - Type of resource updated
resourceId - ID of updated resource
url - Full FHIR URL of updated resource
integrationId - Integration used
operation - Always "update"

Details

This node performs a FHIR update operation (HTTP PUT) to replace an existing resource on the server.

The node requires an access token to be provided in msg.payload.access_token. This token should have appropriate permissions to update the requested resource type.

The FHIR resource can be provided in the node configuration or via msg.payload.resource. Message values take precedence over node configuration.

The resource must be a valid FHIR resource object with at minimum a resourceType field. The resource ID is resolved in order from msg.payload.resourceId, node configuration, then resource.id. The resource body's id is always set to the resolved ID so the body and target URL agree.

Important: Update is a full replacement - the resource you send replaces the entire server-side resource. Any fields you omit will be removed. Use a read-modify-write pattern: read the current resource first, modify the fields you need, then send the complete resource back.

Scope Validation

The node checks if the selected resource type is included in the integration's scopes. Update operations require write or update permissions.

Scopes follow the format: [user|patient|system]/[ResourceType|*].[permissions]

For update operations, valid permissions include:

u - Update permission
w or write - Write permission (includes update)
* - All permissions
Combined permissions like crud, cud, etc.

Examples:

patient/*.u - Can update all resource types in patient context
user/Patient.write - Can write/update Patient resources in user context
system/Observation.* - Can perform all operations on Observations

Examples

Read-Modify-Write Flow:

┌──────────┐   ┌───────────┐   ┌──────────┐   ┌─────────────┐
│ Auth     │──▶│ FHIR Read │──▶│ Modify   │──▶│ FHIR Update │
│ Backend  │   │           │   │ Fields   │   │             │
└──────────┘   └───────────┘   └──────────┘   └─────────────┘

Input Message:

msg.payload = {
    access_token: "eyJhbGciOiJSUzI1NiIs...",
    resourceId: "patient-123",
    resource: {
        resourceType: "Patient",
        id: "patient-123",
        name: [{ family: "Smith", given: ["John"] }],
        birthDate: "1990-01-01"
    }
};

Best Practices

Always read the current resource before updating to avoid losing fields
Preserve the meta element from the read resource when the server uses version-aware updates
Always include required FHIR fields (resourceType, id)
Handle version conflict errors (HTTP 409/412) gracefully
Validate against FHIR profiles when required by integration
Log update operations for audit purposes

┌──────────┐ ┌───────────┐ ┌──────────┐ ┌─────────────┐ │ Auth │──▶│ FHIR Read │──▶│ Modify │──▶│ FHIR Update │ │ Backend │ │ │ │ Fields │ │ │ └──────────┘ └───────────┘ └──────────┘ └─────────────┘

msg.payload = { access_token: "eyJhbGciOiJSUzI1NiIs...", resourceId: "patient-123", resource: { resourceType: "Patient", id: "patient-123", name: [{ family: "Smith", given: ["John"] }], birthDate: "1990-01-01" } };