--- type: "resource" title: "Subscription" resource: "Subscription" --- # Subscription ## Introduction ## Scope and Usage This document contains information about the `Subscription` resource and details specific to options in it. See [Subscriptions](subscriptions) for general information about using Subscriptions in FHIR. The `Subscription` resource is used to establish proactive event notifications from a FHIR server to another system. Notifications are triggered by state changes or events defined by a [SubscriptionTopic](subscriptiontopic) that the server supports, referenced by a canonical URL. Notifications can be further refined by supplying filters specific to an individual client. Each `SubscriptionTopic` resource defines a set of allowed filters (`SubscriptionTopic.trigger.canFilterBy`), which can be used by a `Subscription` resource (`Subscription.filterBy`) to restrict the set of notifications generated by a SubscriptionTopic for that Subscription. Once a subscription is created, any state change or event covered by the specified `SubscriptionTopic` that meets the filtering criteria will cause a notification to be sent using the provided channel. Notifications are [Bundle](bundle#subscription-notification) resources, of type `subscription-notification`. Subscription resources do not represent concrete physical objects; they are representations of a state of the server. Changes from clients (e.g., requesting a new Subscription, changing configuration, etc.) are interpreted as requests to a server. The server SHOULD only accept requests it expects to honor. A server will only activate Subscriptions (set the status to `active` and send notifications) if it supports the requested [SubscriptionTopic](subscriptiontopic), channel, payload, etc.. The subscription is not active when the `Subscription.status` field is not set to `active` or when the Subscription is deleted from the server. Using the `Subscription.content`, subscriptions can be configured to send notifications that include full resource content, just the ID of the triggering resource, or an empty notification body. Several channels are defined in the core specification: - [**rest-hook**](#rest-hook): Notifications are sent via HTTPS POST to the `Subscription.endpoint` URL (e.g., `https://...`) - [**websocket**](#websockets): Notifications are sent via WS/S to a client connected via a WebSocket - [**email**](#email): Notifications are sent via SMTP/S, S/MIME, or Direct SMTP to the `Subscription.endpoint` email URI (e.g., `mailto:...`) - [**message**](#messaging): Notifications are sent via [FHIR messaging](messaging) to the application identified in the `Subscription.endpoint` URI Additional channel types can be [defined](#channel-extending) by external implementation guides. See below for further discussion of the various channels. ## Boundaries and Relationships The `Subscription` resource is used in the [Subscriptions Framework](subscriptions). Information about the Boundaries and Relationships both within the Subscriptions Framework and to other areas of the FHIR specification can be found [here](subscriptions#bnr). ## Notes ## Safety and Security Applications are responsible for following [FHIR security guidance](security). Some recommendations specific to subscriptions are provided on the [Subscriptions Framework](subscriptions#safety) page. ## Multi-Resource Subscriptions As indicated on the [Subscriptions Framework](subscriptions#multi-resource-topics) and [SubscriptionTopic resource](subscriptiontopic#resource-scope) pages, subscriptions can have more than a single resource in scope (e.g., a subscription that triggers on both `Condition` and `Observation` resources, a topic tied to all resources, etc.). If there are filters that do not apply to every resource available in a topic, clients SHOULD ensure that the `Subscription.filterBy.resourceType` element is filled appropriately. More detail can be found in the [Filters and Resource Types](subscriptions#resource-filters) section of the Subscriptions Framework page. ## Notification Content There are three options available when specifying the amount of content a notification will contain: `empty`, `id-only`, and `full-resource`. These options change the level of detail conveyed in the notification `Bundle`. When deciding which payload type to request, systems SHOULD consider both ease of processing and security of PHI (Personal health information). To mitigate the risk of information leakage, systems SHOULD use the minimum level of detail consistent with the use case. In practice, `id-only` provides a good balance between security and performance for many real-world scenarios. If a server cannot or will not honor a payload type (e.g., will not send `full-resource` over HTTP), it SHOULD reject the Subscription request. A server MAY instead accept the subscription with modifications and return the accepted and modified version to the client. When sending event notifications servers SHALL populate the [SubscriptionStatus.notificationEvent](subscriptionstatus-definitions#SubscriptionStatus.notificationEvent) structure with relevant information, depending on the payload type. ### empty An example notification with an `empty` payload can be found [here](notification-empty). With the content type of `empty`, all information about the resources involved in triggering the notification is only available via channels other than the Subscription itself (e.g., the REST API or [$events](subscription-operation-events) operation). This mitigates many security concerns by both removing most PHI from the notification and allows servers to consolidate authorization and authentication logic. When the subscriber receives a notification of this type, it may query the server to fetch all the relevant resources based on the `SubscriptionTopic` and applicable filters. The client might include a `_lastUpdated` query parameter, supplying its last query timestamp to retrieve only the most recent resources. For example, if the notification is for a topic about patient admission, the subscriber will generally query for recent Encounters for a patient or group of patients, then fetch them as needed. When populating the `SubscriptionStatus.notificationEvent` structure for a notification with an `empty` payload, a server SHALL NOT include references to resources (e.g., [SubscriptionStatus.notificationEvent.focus](subscriptionstatus-definitions#SubscriptionStatus.notificationEvent.focus) and [SubscriptionStatus.notificationEvent.additionalContext](subscriptionstatus-definitions#SubscriptionStatus.notificationEvent.additionalContext) SHALL NOT be present). When the content type is `empty`, notification bundles SHALL NOT contain `Bundle.entry` elements other than the `SubscriptionStatus` for the notification. ### id-only An example notification with an `id-only` payload can be found [here](notification-id-only). With the content type of `id-only`, the resources involved in triggering the notification are only available through other channels (e.g., REST API), but notifications include URLs which can be used to access those resources. This allows servers to consolidate authorization and authentication logic, while removing the need for expensive queries by subscribers. When a subscriber receives a notification of this type, it may directly fetch all the relevant resources using the supplied resource ids. For example, if the notification is for a topic about patient admission, the subscriber may fetch the Encounter(s) for a patient or group of patients. When the content type is `id-only`, the `SubscriptionStatus.notificationEvent` structure SHALL include references to the appropriate focus resources in the [SubscriptionStatus.notificationEvent.focus](subscriptionstatus-definitions#SubscriptionStatus.notificationEvent.focus) element. This provides clients a fixed location to consolidate IDs for all notification types. Additionally, notification bundles MAY contain, in addition to the `SubscriptionStatus`, at least one `Bundle.entry` for each resource relevant to the notification. For example, a notification for a topic based on Encounter MAY include a reference to the Encounter and MAY also include additional resources deemed relevant (e.g., the linked Patient). ### full-resource An example notification with a `full-resource` payload can be found [here](notification-full-resource). With the content type of `full-resource`, the resources involved in triggering the notification are included in the notification bundle. When a subscriber receives a notification of this type, resources are already present in the bundle, though the subscriber may need to fetch additional resources from the server. For example, the if the notification is for a topic about patient admission, the subscriber may require related `Observation` resources. When the content type is `full-resource`, the `SubscriptionStatus.notificationEvent` structure SHALL include references to the appropriate focus resources in the [SubscriptionStatus.notificationEvent.focus](subscriptionstatus-definitions#SubscriptionStatus.notificationEvent.focus) element. This provides clients a fixed location to consolidate IDs for all notification types. Notification bundles for `full-resource` subscriptions SHALL contain, in addition to the `SubscriptionStatus`, at least one `Bundle.entry` for each resource relevant to the notification. For example, a notification for a topic based on Encounter SHALL include an Encounter and MAY include additional resources deemed relevant (e.g., the relevant Patient). Each `Bundle.entry` for a `full-resource` notification SHALL contain a relevant resource in the `entry.resource` element. If a server cannot include the resource contents due to an issue with a specific notification, the server SHALL populate the `entry.request` and/or `entry.response` elements. ## Batching Results Subscriptions allow servers to batch multiple notifications into a single `subscription-notification` Bundle. For example, if a server has a high-frequency of updates (e.g., several per second), it could be beneficial to combine notifications to reduce traffic and overhead. Note that servers SHALL NOT delay sending notification longer than time span specified by `Subscription.heartbeat`. The `Subscription.maxCount` element allows clients to specify the maximum number of events that can be combined in a single notification. When present, servers SHALL NOT include more than the specified number of events in a notification bundle. Note that this is not a strict limit on the total number of entries in a bundle, as dependent resources (e.g., included related resources) can be present in Bundles, in addition to the event notifications. ## Channels ### Deciding on Channel Type This specification defines a core set of channel types to cover the majority of common use cases. Servers MAY define additional channel types as needed. Below is some guidance for implementers to consider when selecting a channel type. #### REST-Hook The FHIR standard makes extensive use of the RESTful model. Given the popularity of REST and widespread adoption, most implementers should consider using REST-hook channels whenever possible. In general, REST-based systems are well-supported (e.g., tooling, infrastructure, documentation, etc.), and will present the lowest bar for implementation. #### Websocket Websockets are unique in the pre-defined channel types in being the only channel that does not require the client to have an endpoint. Due to this property, the websocket channel is very useful for clients where creating an endpoint would be difficult or impossible (e.g., mobile clients, web-based clients, etc.). The websocket channel type is still undergoing testing and refinement - current details can be found in the [FHIR Subscriptions Backport Implementation Guide](https://hl7.org/fhir/uv/subscriptions-backport/). #### Email The Email channel is the only channel that could contest REST in non-FHIR implementations. That said, Email communication is often high-latency and is typically used for communication to individuals - not applications. Email channels are particularly useful in the context of these non-application use cases, such as public health notifications. For example, if a public health agency does not have the ability or desire to build a custom RESTful solution (e.g., creating and maintaining an endpoint to receive notifications, as well as software to consume those notifications), it is straightforward to map notifications to email addresses or aliases. #### FHIR Messaging FHIR Messaging is a mechanism defined to allow for non-RESTful communication between FHIR servers and clients. One common use case is when connectivity is an issue (e.g., remote sites that batch all communications when connections are available). This channel defines how to integrate topic-based subscriptions with the FHIR Messaging model. #### Custom Channels For use cases that are not well-met by any of the predefined channels, the Subscriptions Framework allows for custom channel definitions. Some examples of scenarios where custom channels may be applicable include: - requirements for reliable (guaranteed) delivery (e.g., message queues) - implementations using other communication protocols (e.g., protocols specific to a cloud-based provider) - implementations using a non-standard serialization format ### REST Hook To receive notifications via HTTP/S POST, a client requests a subscription with the channel type of \`rest-hook\` (from the `subscription-channel-type` Code System) and and an endpoint (`Subscription.endpoint`) with the desired URL. Note that this URL must be accessible by the hosting server. To convey an event notification, the server POSTs a `notification Bundle` to the client's nominated endpoint URL per the format requests in the Subscription: - The `content-type` of the POST SHALL match the MIME type on the Subscription [Subscription.contentType](subscription-definitions#Subscription.contentType). - Each [Subscription.parameter](subscription-definitions#Subscription.parameter) indicates an HTTP request header and SHALL be sent as `{parameter.name}: {parameter.value}`. When a subscription is created for a REST Hook channel type, the server SHALL set initial status to `requested`, pending verification of the nominated endpoint URL. After a successful `handshake` notification has been sent and accepted, the server SHALL update the status to `active`. Any errors in the initial `handshake` SHALL result in the status being changed to `error`. An example workflow for establishing a `rest-hook` subscription is shown below. ![](subscription-channel-rest-hook.svg) Diagram showing a possible workflow for rest-hook subscriptions 1. Client creates a `Subscription` with the `channelType` set to `rest-hook`. 2. Server responds with a success code and creates the subscription with a state of `requested`. 3. Server performs an HTTP POST to the requested endpoint with a `handshake` notification. 4. Client Endpoint accepts the POST and returns a success HTTP code (e.g., `200`). 5. Server sends a notification of type `heartbeat` at any time (SHOULD at least once per `heartbeatPeriod`). 6. Client Endpoint accepts a `heartbeat` via HTTP POST and returns an HTTP success code (e.g., `200`). 7. Server sends a notification of type `event-notification` when triggered. 8. Client Endpoint accepts an `event-notification` via HTTP POST and returns an HTTP code (e.g., `200`). #### Channel Security Notes HTTP is neither a secure nor an encrypted channel, nor does it provide endpoint verification. It is strongly recommended that implementations refuse requests to send notifications to URLs using the HTTP protocol (use HTTPS instead). ### Email While the primary interface for FHIR servers is the FHIR REST API, notifications need not occur via REST. Indeed, some subscribers may be unable to maintain an outward-facing HTTP server to receive triggered notifications. For example, a public health organization may want to be notified of outbreaks of various illnesses. This can be accomplished using an `email` notification channel. To receive notifications via Email, a client requests a subscription with the channel type (`Subscription.channelType`) of `email` (from the `subscription-channel-type` Code System) and an endpoint (`Subscription.endpoint`) with the desired email URI (e.g., `mailto:public_health_notifications@example.org`). The server will send a new message each time a notification should be sent (e.g., per event or per batch). The server will create a message based on the values present in the `Subscription.contentType` and `Subscription.content` fields. If a server cannot honor the requested combination, the server should reject the Subscription request rather than send unexpected email messages. The email channel sets two guidelines about content: - Message Body content SHALL be human readable - Message Attachments SHOULD be machine readable Due to these guidelines, the `Subscription.contentType` refers to the content of the body of the message. Attachment type information can be appended as a MIME parameter, for example: - `text/plain`: a plain-text body with no attachment - `text/html`: an HTML body with no attachment - `text/plain;attach=application/fhir+json`: a plain-text body with a FHIR JSON bundle attached - `text/html;attach=application/fhir+xml`: an HTML body with a FHIR XML bundle attached The `Subscription.content` field SHALL be applied to any attachments, and MAY be applied to body contents (depending on server implementation). However, a server must not include a body which exceeds the specified content level. For example, a server may choose to always include a standard message in the body of the message containing no PHI and vary the attachment, but cannot include PHI in the body of an email when the content is set to `empty`. An example workflow using the `email` channel type is included below. ![](subscription-channel-email.svg) Diagram showing a possible workflow for email subscriptions 1. Client creates a `Subscription` with the `channelType` set to `email`. 2. Server MAY respond with a success code and create the subscription with a state of `active`. 3. Server MAY respond with a success code and create the subscription with a state of `requested`. 4. Server sends an initial message via the specified email server (e.g., verify the request, opt-out instructions, etc.). 5. Email Server responds with a channel appropriate response code (e.g., `250: OK`). 6. Server may send an email for a notification of type `heartbeat` at any time (SHOULD at least once per `heartbeatPeriod`). 7. Server may send an email for a notification of type `event-notification` at any time. #### Channel Security Notes Email (SMTP) is not a secure channel. Implementers must ensure that any messages containing PHI have been secured according to their policy requirements (e.g., use of a system such as [Direct](https://directtrust.org/standards/the-direct-standard)). ### Messaging There are times when it is desirable to use Subscriptions as a communication channel between FHIR servers that are connected via Messaging instead of REST. This can be accomplished using a `Subscription` with the channel type of `message`. To receive notifications via messaging, a client should request a subscription with the channel type (`Subscription.channelType`) of `message` and set the endpoint (`Subscription.endpoint`) to the destination FHIR server base URL. Note that this URL must be accessible by the hosting server. The FHIR server hosting the subscription (server) will send FHIR messages to the destination FHIR server (endpoint) as needed. These messages will, as the contents of the message, have a fully-formed `subscription-notification` Bundle. An example message can be found [here](notification-message-full-resource.xml). An example workflow using the `message` channel type is included below. ![](subscription-channel-messaging.svg) Diagram showing a possible workflow for FHIR Messaging subscriptions 1. Client creates a `Subscription` with the `channelType` set to `message`. 2. Server responds with a success code and creates the subscription with a state of `requested`. 3. Server sends a FHIR Message to the requested endpoint with a `handshake` notification. 4. Client Endpoint accepts the Message and returns success. 5. Server may send a Message containing a notification of type `heartbeat` at any time (SHOULD at least once per `heartbeatPeriod`). 6. Server may send a Message containing a notification of type `event-notification` at any time. \[%stu-note msg%\] The Messaging channel type needs more testing and feedback to ensure all requirements are met before finalizing the specification. \[%end-note%\] #### Channel Security Notes Servers MAY require that the end-point is white-listed prior to allowing these kinds of subscriptions. Additionally, servers MAY impose authorization/authentication requirements for server to server communication (e.g., certificate pinning, etc.). ## Defining Channel Types Defining a new channel type requires clear communication to implementers of both clients and servers around requirements and expectations. Below are some areas which should be considered when creating a channel. Anyone defining a channel type is encouraged to publish their definition at [registry.fhir.org](https://registry.fhir.org/). \[%stu-note ch%\] Warning: This section is still in early drafting; feedback from topic authors is welcome to refine the following guidance. \[%end-note%\] ### Channel Basics At a minimum, the following items should be defined: - A system for Subscription.channelType that reflects the publisher of the definition (e.g., "https://myorg.example.org" instead of "urn:uuid:be35238b-0ed6-4062-93cf-818b8023a103") - A generally descriptive code for `Subscription.channelType` (e.g., 'secure-mq' instead of 'channel') - The type of data required in `Subscription.endpoint` (e.g., URI, etc.)- The meaning of `Subscription.parameter` field values (e.g., [REST-hook](#rest-hook) defines as HTTP headers included in a POST). Note that channels can specify general behavior and/or specific parameters by `name`. - Any additions or variations on MIME types for `Subscription.contentType` (e.g., [email](#email) defines this as the email body, with allowable attachments.) - Whether `handshake` notifications are used, and guidance on usage if they are - Whether `heartbeat` notifications are used, and guidance on timings if they are ### Channel Security Considerations Defining a channel has security implications. While it is not expected that authors cover all aspects of security, guidance specific to the channel SHOULD be provided. For example, when discussing REST-hooks, this specification includes guidance about using HTTPS over HTTP. If the channel CANNOT be secured, that should be stated with a warning not to transfer PHI. If the channel is or can be secured, guidance should be given on how configurations relate to PHI safety, for example: - Does the channel determine the legitimacy of both endpoints? - Is the channel secure from third-party monitoring? ## Managing Subscriptions and Errors Subscriptions can be used to manage long-lived requests for notifications. For details about management and expectations regarding errors, see [Managing Subscriptions and Errors](subscriptions#errors) on the Subscriptions Framework page. ## Authorization Hinting in Notifications It can be appropriate for a server to include authorization information alongside notifications. This information could be used to inform a recipient about how authorization should be done when querying-for or retrieving resources from a notification (e.g., when querying based on an `empty` notification), or to provide tokens or other information needed to access resources referenced in the notification (e.g., when retrieving resources based on an `id-only` notification). Depending on the channel used, notifications MAY or MAY NOT be secure from third parties. Implementers SHOULD ensure that any authorization information included complies with security best practices (e.g., providing a token exchanged during an OAuth workflow, along with other data such as a client authentication token, for an access token). When including authorization information in a notification, servers SHOULD use security best practices (e.g., short-lived and single-use tokens, temporary access codes, etc). For more information, see the [FHIR Security Guidance](security) document. ## StructureDefinition ### Elements (Simplified) - **[Subscription](/subscription-definitions#Subscription)** [0..*]: - Information about a request for notifications to a client based on a SubscriptionTopic - **[Subscription.identifier](/subscription-definitions#Subscription.identifier)** [0..*]: [Identifier](/Identifier) Additional identifiers (business identifier) - **[Subscription.name](/subscription-definitions#Subscription.name)** [0..1]: [string](/string) Human readable name for this subscription - **[Subscription.status](/subscription-definitions#Subscription.status)** [1..1]: [code](/code) required:[subscription-status](/valueset-subscription-status) requested | active | error | off | entered-in-error - **[Subscription.topic](/subscription-definitions#Subscription.topic)** [1..1]: [canonical](/canonical) Reference to the subscription topic being subscribed to - **[Subscription.contact](/subscription-definitions#Subscription.contact)** [0..*]: [ContactPoint](/ContactPoint) Contact details for source (e.g. troubleshooting) - **[Subscription.end](/subscription-definitions#Subscription.end)** [0..1]: [instant](/instant) When to automatically delete the subscription - **[Subscription.managingEntity](/subscription-definitions#Subscription.managingEntity)** [0..1]: [Reference(CareTeam](/Reference(CareTeam), [Device](/Device), [Group](/Group), [HealthcareService](/HealthcareService), [Organization](/Organization), [RelatedPerson](/RelatedPerson), [Patient](/Patient), [Practitioner](/Practitioner), [PractitionerRole)](/PractitionerRole)) Entity responsible for Subscription changes - **[Subscription.reason](/subscription-definitions#Subscription.reason)** [0..1]: [string](/string) Description of why this subscription was created - **[Subscription.filterBy](/subscription-definitions#Subscription.filterBy)** [0..*]: [BackboneElement](/BackboneElement) Criteria for narrowing the subscription topic stream - **[Subscription.filterBy.resource](/subscription-definitions#Subscription.filterBy.resource)** [0..1]: [uri](/uri) extensible:[subscription-types](/valueset-subscription-types) Allowed Resource (reference to definition) for this Subscription filter - **[Subscription.filterBy.filterParameter](/subscription-definitions#Subscription.filterBy.filterParameter)** [1..1]: [string](/string) Filter label defined in SubscriptionTopic - **[Subscription.filterBy.comparator](/subscription-definitions#Subscription.filterBy.comparator)** [0..1]: [code](/code) required:[search-comparator](/valueset-search-comparator) eq | ne | gt | lt | ge | le | sa | eb | ap - **[Subscription.filterBy.modifier](/subscription-definitions#Subscription.filterBy.modifier)** [0..1]: [code](/code) required:[search-modifier-code](/valueset-search-modifier-code) missing | exact | contains | not | text | in | not-in | below | above | type | identifier | of-type | code-text | text-advanced | iterate - **[Subscription.filterBy.value](/subscription-definitions#Subscription.filterBy.value)** [1..1]: [string](/string) Literal value or resource path - **[Subscription.filterBy.event](/subscription-definitions#Subscription.filterBy.event)** [0..*]: [CodeableConcept](/CodeableConcept) example:[v2-0003](/valueset-v2-0003) Event to filter by - **[Subscription.channelType](/subscription-definitions#Subscription.channelType)** [1..1]: [Coding](/Coding) extensible:[subscription-channel-type](/valueset-subscription-channel-type) Channel type for notifications - **[Subscription.endpoint](/subscription-definitions#Subscription.endpoint)** [0..1]: [url](/url) URL where the channel sends notifications - **[Subscription.parameter](/subscription-definitions#Subscription.parameter)** [0..*]: [BackboneElement](/BackboneElement) Channel type dependent information - **[Subscription.parameter.name](/subscription-definitions#Subscription.parameter.name)** [1..1]: [string](/string) Name (key) of the parameter - **[Subscription.parameter.value](/subscription-definitions#Subscription.parameter.value)** [1..1]: [string](/string) Value of the parameter to use or pass through - **[Subscription.heartbeatPeriod](/subscription-definitions#Subscription.heartbeatPeriod)** [0..1]: [unsignedInt](/unsignedInt) Interval in seconds to send 'heartbeat' notification - **[Subscription.timeout](/subscription-definitions#Subscription.timeout)** [0..1]: [unsignedInt](/unsignedInt) Timeout in seconds to attempt notification delivery - **[Subscription.contentType](/subscription-definitions#Subscription.contentType)** [0..1]: [code](/code) required:[mimetypes](/valueset-mimetypes) MIME type to send, or omit for no payload - **[Subscription.content](/subscription-definitions#Subscription.content)** [0..1]: [code](/code) required:[subscription-payload-content](/valueset-subscription-payload-content) empty | id-only | full-resource - **[Subscription.maxCount](/subscription-definitions#Subscription.maxCount)** [0..1]: [positiveInt](/positiveInt) Maximum number of events that can be combined in a single notification ## Mappings - [Subscription Mappings](/subscription-mappings) — 9 mapping entries ## Operations - [events](/subscription-operation-events) — Search and retrieve prior events for a Subscription — This operation is used to search for and return notifications that have been previously triggered by a topic-based Subscription. - [status](/subscription-operation-status) — Get Current Subscription Status for One or More Subscriptions — This operation is used to get current status information about one or more topic-based Subscriptions, each described by a SubscriptionStatus resource. [Full Operations](/subscription-operations) ## Resource Packs ### list-Subscription-packs.xml ```xml ``` ## Search Parameters - [contact](/subscription-search#contact) — **token** — Contact details for the subscription — `Subscription.contact` - [content-level](/subscription-search#content-level) — **token** — Content level included in notifications — `Subscription.content` - [filter-value](/subscription-search#filter-value) — **string** — Filter value used to narrow notifications — `Subscription.filterBy.value` - [filter-event](/subscription-search#filter-event) — **token** — Filter event used to narrow notifications — `Subscription.filterBy.event` - [identifier](/subscription-search#identifier) — **token** — A subscription identifier — `Subscription.identifier` - [name](/subscription-search#name) — **string** — A human-readable name — `Subscription.name` - [owner](/subscription-search#owner) — **reference** — The managing entity — `Subscription.managingEntity` - [payload](/subscription-search#payload) — **token** — The mime-type of notifications — `-` - [status](/subscription-search#status) — **token** — The current state of the subscription — `Subscription.status` - [topic](/subscription-search#topic) — **uri** — The canonical topic url that triggers notifications — `Subscription.topic` - [type](/subscription-search#type) — **token** — The type of channel for the sent notifications — `Subscription.channelType` - [url](/subscription-search#url) — **uri** — The uri that will receive the notifications — `Subscription.endpoint` [Full Search Parameters](/subscription-search) ## Examples - [admission](/subscription-example-admission) — subscription-admission — Example of subscription for beginning of a clinical encounter - [example](/subscription-example-example) — subscription-example — Example of subscription - [subscription-example](/subscription-example-subscription-example) — subscription-example - [subscription-examples-header](/subscription-example-subscription-examples-header) — subscription-examples-header [Full Examples](/subscription-examples) ## Mapping Exceptions ### subscription-fivews-mapping-exceptions.xml ### Unmapped Elements - **FiveWs.recorded** — Not relevant for this resource - **FiveWs.actor** — Not relevant for this resource - **FiveWs.cause** — Not relevant for this resource - **FiveWs.version** — Not relevant for this resource - **FiveWs.witness** — Not relevant for this resource - **FiveWs.class** — Not relevant for this resource - **FiveWs.where** — Not relevant for this resource - **FiveWs.context** — Not relevant for this resource - **FiveWs.init** — Not relevant for this resource - **FiveWs.source** — Not relevant for this resource - **FiveWs.who** — Not relevant for this resource - **FiveWs.grade** — Not relevant for this resource - **FiveWs.planned** — Not relevant for this resource