Identify or define the SubscriptionTopic URL that represents the event of interest — for a standard use case like new lab results, use the canonical SubscriptionTopic URL defined in the FHIR R4B/R5 backport IG (e.g., http://hl7.org/fhir/uv/subscriptions-backport/SubscriptionTopic/admission)
Create a Subscription resource using the backport profile with Subscription.criteria set to the SubscriptionTopic URL, Subscription.channel.type set to rest-hook, and Subscription.channel.endpoint set to your webhook URL
Include a Subscription.channel.payload element specifying the notification shape (empty for id-only, resource for full resource, or full-resource for complete notification Bundle)
POST the Subscription to the FHIR server and verify the server responds with 201 Created; the server may send a handshake notification to your webhook endpoint that must return 200 OK
Process incoming notification Bundles at your webhook: extract the SubscriptionStatus resource from the first entry to verify the subscription ID and event count, then process the notification entries according to the payload type
Known gotchas
The backport IG uses an extension-based approach on the R4 Subscription resource to convey R5 topic-based semantics — the server must explicitly support the backport IG and not just standard R4 Subscriptions, which use a different criteria syntax
Webhook endpoints must be HTTPS and publicly reachable by the FHIR server; localhost or internal network endpoints require a tunnel or the use of a websocket or SMART messaging channel instead of rest-hook
The SubscriptionStatus resource in notification Bundles uses the type backport-subscription-status — receiving systems must handle this non-standard resource type and must not reject the Bundle because of it
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp