Subscriptions R5 Backport
1.2.0-ballot - ballot

Subscriptions R5 Backport, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 1.2.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-subscription-backport-ig/ and changes regularly. See the Directory of published versions

## Example Bundle: R4 Notification: Id Only

This Bundle provides an example of an `id-only` notification. This `Bundle` is typical of what may be posted to a notification endpoint (e.g., a listening HTTP server, etc.).

Bundle r4-notification-id-only of type history

Entry 1 - fullUrl = urn:uuid:292d3c72-edc1-4d8a-afaa-d85e19c7f563

Request:

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

Response:

    200

Resource Parameters:

> ## Parameters

> subscription | https://example.org/fhir/Subscription/admission
> topic | http://hl7.org/SubscriptionTopic/admission
> status | active
> type | event-notification
> events-since-subscription-start | 2
> notification-event |
> event-number | 2
> timestamp | 2020-05-29 11:44:13-0500
> focus | https://example.org/fhir/Encounter/86009987-eabe-42bf-8c02-b112b18cb616

### Notes:

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.