FHIR Read
Reads a specific FHIR resource by type and ID.
Inputs
Outputs
Details
This node performs a FHIR read operation to retrieve a specific resource by its type and ID.
The node requires an access token to be provided in msg.payload.access_token.
This token should have appropriate permissions to read the requested resource type.
Resource type and ID can be configured in the node or provided dynamically via the message. Message values take precedence over node configuration.
The node validates the resource type against the integration's configured scopes and displays a warning if the resource may not be accessible. However, it will still attempt the request, allowing the FHIR server to make the final authorization decision.
Scope Validation
The node checks if the selected resource type is included in the integration's scopes.
Scopes follow the format: [user|patient|system]/[ResourceType|*].[read|write|*]
For example:
patient/*.read- Can read all resource types in patient contextuser/Patient.read- Can read Patient resources in user contextsystem/Observation.*- Can perform all operations on Observations
Examples
Basic Read Flow:
┌──────────┐ ┌─────────────┐ ┌───────────┐ │ Auth │──▶│ FHIR Read │──▶│ Process │ │ Backend │ │ (Patient) │ │ Resource │ └──────────┘ └─────────────┘ └───────────┘
Input Message:
msg.payload = {
access_token: "eyJhbGciOiJSUzI1NiIs...",
resourceType: "Patient",
resourceId: "12345"
};
Output Example:
msg.payload = {
"resourceType": "Patient",
"id": "12345",
"name": [{"family": "Smith", "given": ["John"]}],
"birthDate": "1980-01-01"
};
msg.fhir = {
"operation": "read",
"resourceType": "Patient",
"resourceId": "12345"
};
Best Practices
- Always validate resource ID exists before calling read
- Use error handling to catch 404 (not found) responses
- Cache frequently accessed resources when appropriate
- Check
msg.fhirmetadata for debugging - Consider using search instead of read for unknown IDs