FHIR Messaging is one of several ways FHIR systems communicate. Understanding when to use messaging vs. REST vs. Subscription prevents architecture confusion.
Three FHIR communication patterns
1. REST. Synchronous, request-response. Best for user-initiated queries. 2. Messaging. Asynchronous, message-based. Best for reliable delivery of state changes. 3. Subscription. Event-driven notifications. Best for real-time reactive workflows.
When to use FHIR Messaging
1. Legacy integration where message queues are already established. 2. Cross-organization data exchange with different security domains. 3. Reliable delivery required with retry semantics. 4. Async processing where response isn't immediately needed.
Messaging structure
Message is a Bundle with:
- type: message - First entry: MessageHeader with event code, source, destination. - Subsequent entries: message payload resources.
MessageHeader semantics
1. eventCoding — what event this is (patient-link, admission, etc.). 2. source — sender. 3. destination — receiver. 4. response.identifier — reply to previous message. 5. response.code — ok, transient-error, fatal-error.
Delivery via various transports
1. HTTP POST. Standard REST-like endpoint accepts messages. 2. Message queue. RabbitMQ, Kafka, or similar. Broker delivers to consumer. 3. Email. SMTP for low-volume cross-org exchange (rare in production).
Common Messaging use cases
1. Public health case reporting (eCR). 2. Cross-organization patient transfers. 3. Reliable event delivery when Subscription isn't sufficient.
Vendor state (mid-2026)
| Server | Messaging support |
|---|---|
| HAPI FHIR | Full |
| Aidbox | Full |
| Medplum | Bots-based |
| Microsoft FHIR Server | Partial |
When NOT to use Messaging
1. User-initiated queries → use REST. 2. Real-time UI updates → use Subscription. 3. Bulk analytics → use $export.
FHIR Messaging is a specific tool for specific problems. Use it where async reliable delivery matters; use REST/Subscription elsewhere.
