This Bundle provides an example of an full-resource notification that includes a related resource (e.g., the triggering resource of Encounter and the related Patient). This Bundle is typical of what may be posted to a notification endpoint (e.g., a listening HTTP server, etc.).

Bundle r4b-notification-multi-resource of type history

Entry 1 - fullUrl = urn:uuid:f05e460f-4d56-4fa0-8e60-502404e68be5

Request:

GET https://example.org/fhir/Subscription/admission/$status

Response:

200

Resource SubscriptionStatus:

Generated Narrative: SubscriptionStatus

ResourceSubscriptionStatus "f05e460f-4d56-4fa0-8e60-502404e68be5"

status: ACTIVE

type: EVENTNOTIFICATION

eventsSinceSubscriptionStart: 2

NotificationEvents

-	EventNumber	Timestamp	Focus	AdditionalContext
*	2	May 29, 2020, 4:44:13 PM	See on this page: https://example.org/fhir/Encounter/86009987-eabe-42bf-8c02-b112b18cb616	See on this page: https://example.org/fhir/Patient/1599eb66-431a-447c-a3de-6897fe9ae9a1

subscription: https://example.org/fhir/Subscription/admission

topic: http://hl7.org/SubscriptionTopic/admission

Entry 2 - fullUrl = https://example.org/fhir/Encounter/86009987-eabe-42bf-8c02-b112b18cb616

Request:

POST Encounter

Response:

201

Resource Encounter:

Not done yet

Entry 3 - fullUrl = https://example.org/fhir/Patient/1599eb66-431a-447c-a3de-6897fe9ae9a1

Request:

GET Patient/1599eb66-431a-447c-a3de-6897fe9ae9a1

Response:

200

Resource Patient:

Anonymous Patient null, DoB:

In order to satisfy the requirements of a history Bundle (specifically bdl-3 and bdl-4), note that Bundle.entry.request must exist.

For the status resource (entry[0]), the request is filled out to match a request to the $status operation.

For additional entries, the request SHOULD be filled out in a way that makes sense given the subscription (e.g., a POST or PUT operation on the resource). However, a server MAY choose to simply include a GET to the relevant resource instead.