Implement FHIR R5 messaging using MessageHeader and Bundle of type message to send a clinical notification between two FHIR systems without using REST
domain: hl7.org/fhir/R5 · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Create a Bundle of type message with the MessageHeader as the first entry; subsequent entries carry the event-specific resources (e.g., Patient, Encounter)
Populate MessageHeader.eventCoding with the message event code (e.g., admin-notify for administrative notifications) and set source with the sending system endpoint
Set MessageHeader.destination with the receiving endpoint URL and MessageHeader.sender referencing the sending organization
POST the Bundle to the receiving system's FHIR messaging endpoint (typically /\$process-message) and handle the acknowledgment Bundle response
Validate that the response Bundle contains a MessageHeader with response.code=ok; handle fatal-error and transient-error response codes with appropriate retry logic
Known gotchas
FHIR messaging is an alternative transport to REST and is not widely supported by all FHIR servers; confirm the receiving system exposes a $process-message endpoint before designing a messaging architecture
Resources within the message Bundle must use full URLs as Bundle entry fullUrl values, not server-relative references; relative references within the Bundle must resolve to entries in the same Bundle
MessageHeader.eventCoding value sets differ between R4 and R5; R5 removed some event codes and restructured the event binding — do not assume R4 event codes are valid in R5
Give your agent this knowledge — and 6,400+ more routes
One MCP install gives any agent live access to the full route map across 2,100+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp