Describes a stream of resource state changes or events and annotated with labels useful to filter projections from this topic.

An absolute URL that is used to identify this SubscriptionTopic when it is referenced in a specification, model, design or an instance. This SHALL be a URL, SHOULD be globally unique, and SHOULD be an address at which this Topic is (or will be) published. The URL SHOULD include the major version of the Topic. For more information see Technical and Business Versions.

Allows the SubscriptionTopic to be referenced by a single globally unique identifier.

Can be a urn:uuid: or a urn:oid:, but real http: addresses are preferred. This is the URI that will be used when making canonical references to this resource.

Business identifiers assigned to this SubscriptionTopic by the performer and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server.

Allows identification of the SubscriptionTopic as it is known by various participating systems and in a way that remains consistent across servers.

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

The identifier that is used to identify this version of the SubscriptionTopic when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the Topic author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions are orderable.

There may be multiple different instances of a SubscriptionTopic that have the same identifier but different versions.

A short, descriptive, user-friendly title for the SubscriptionTopic, for example, "admission".

The canonical URL pointing to another FHIR-defined SubscriptionTopic that is adhered to in whole or in part by this SubscriptionTopic.

SubscriptionTopics may be refinements of more generic topics.

The current state of the SubscriptionTopic.

A nominal state-transition diagram can be found in the [[definition.html#statemachine | Definition pattern]] documentation

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is.

A flag to indicate that this TopSubscriptionTopicic is authored for testing purposes (or education/evaluation/marketing), and is not intended to be used for genuine usage.

Enables experimental content to be developed following the same life-cycle as a production-level SubscriptionTopic would.

Allows filtering of SubscriptionTopic that are appropriate for use vs. not.

For draft definitions, indicates the date of initial creation. For active definitions, represents the date of activation. For withdrawn definitions, indicates the date of withdrawal.

Helps establish the "authority/credibility" of the SubscriptionTopic. May also allow for contact.

Usually an organization, but may be an individual. The publisher (or steward) of the SubscriptionTopic is the organization or individual primarily responsible for the maintenance and upkeep of the Topic. This is not necessarily the same individual or organization that developed and initially authored the content. The publisher is the primary point of contact for questions or issues with the Topic. This item SHOULD be populated unless the information is available from context.

Contact details to assist a user in finding and communicating with the publisher.

May be a web site, an email address, a telephone number, etc.

A free text natural language description of the Topic from the consumer's perspective.

This description can be used to capture details such as why the Topic was built, comments about misuse, instructions for clinical use and interpretation, literature references, examples from the paper world, etc. It is not a rendering of the module as conveyed in the text field of the resource itself. This item SHOULD be populated unless the information is available from context.

The content was developed with a focus and intent of supporting the contexts that are listed. These terms may be used to assist with indexing and searching of code system definitions.

Assist in searching for appropriate content.

When multiple usageContexts are specified, there is no expectation for whether all or any of the contexts apply.

A jurisdiction in which the Topic is intended to be used.

Explains why this Topic is needed and why it has been designed as it has.

This element does not describe the usage of the Topic. Rather it is for traceability of ''why'' the resource is either needed or ''why'' it is defined as it is. This may be used to point to source materials or specifications that drove the structure of this Topic.

A copyright statement relating to the SubscriptionTopic and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the SubscriptionTopic.

Consumers of the TSubscriptionTopicopic must be able to determine any legal restrictions on the use of the artifact and/or its content.

The date on which the asset content was approved by the publisher. Approval happens once when the content is officially approved for usage.

The date may be more recent than the approval date because of minor changes / editorial corrections.

The date on which the asset content was last reviewed. Review happens periodically after that, but doesn't change the original approval date.

If specified, this is usually after the approval date.

The period during which the SubscriptionTopic content was or is planned to be effective.

The effective period for a SubscriptionTopic determines when the content is applicable for usage and is independent of publication and review dates. For example, a measure intended to be used for the year 2016 would be published in 2015.

A definition of a resource-based event that triggers a notification based on the SubscriptionTopic. The criteria may be just a human readable description and/or a full FHIR search string or FHIRPath expression. Multiple triggers are considered OR joined (e.g., a resource update matching ANY of the definitions will trigger a notification).

The human readable description of this resource trigger for the SubscriptionTopic - for example, "An Encounter enters the 'in-progress' state".

Implementation of particular subscription topics might not use a computable definition and instead base their design on the definition.

URL of the Resource that is the type used in this resource trigger. Relative URLs are relative to the StructureDefinition root of the implemented FHIR version (e.g., http://hl7.org/fhir/StructureDefinition). For example, "Patient" maps to http://hl7.org/fhir/StructureDefinition/Patient. For more information, see <a href="elementdefinition-definitions.html#ElementDefinition.type.code">ElementDefinition.type.code</a>.

The FHIR RESTful interaction which can be used to trigger a notification for the SubscriptionTopic. Multiple values are considered OR joined (e.g., CREATE or UPDATE).

The FHIR query based rules that the server should use to determine when to trigger a notification for this subscription topic.

The FHIR query based rules are applied to the previous resource state (e.g., state before an update).

The rules are search criteria (without the [base] part). Like Bundle.entry.request.url, it has no leading "/".

What behavior a server will exhibit if the previous state of a resource does NOT exist (e.g., prior to a create).

The FHIR query based rules are applied to the current resource state (e.g., state after an update).

The rules are search criteria (without the [base] part). Like Bundle.entry.request.url, it has no leading "/".

What behavior a server will exhibit if the current state of a resource does NOT exist (e.g., after a DELETE).

If set to true, both current and previous criteria must evaluate true to trigger a notification for this topic. Otherwise a notification for this topic will be triggered if either one evaluates to true.

The FHIRPath based rules that the server should use to determine when to trigger a notification for this topic.

FHIRPath expression with %previous and %current vars.

Event definition which can be used to trigger the SubscriptionTopic.

The human readable description of an event to trigger a notification for the SubscriptionTopic - for example, "Patient Admission, as defined in HL7v2 via message ADT^A01". Multiple values are considered OR joined (e.g., matching any single event listed).

Implementation of particular subscription topics might not use a computable definition and instead base their design on the definition.

A well-defined event which can be used to trigger notifications from the SubscriptionTopic.

URL of the Resource that is the focus type used in this event trigger. Relative URLs are relative to the StructureDefinition root of the implemented FHIR version (e.g., http://hl7.org/fhir/StructureDefinition). For example, "Patient" maps to http://hl7.org/fhir/StructureDefinition/Patient. For more information, see <a href="elementdefinition-definitions.html#ElementDefinition.type.code">ElementDefinition.type.code</a>.

List of properties by which Subscriptions on the SubscriptionTopic can be filtered. May be defined Search Parameters (e.g., Encounter.patient) or parameters defined within this SubscriptionTopic context (e.g., hub.event).

Description of how this filtering parameter is intended to be used.

URL of the Resource that is the type used in this filter. This is the "focus" of the topic (or one of them if there are more than one). It will be the same, a generality, or a specificity of SubscriptionTopic.resourceTrigger.resource or SubscriptionTopic.eventTrigger.resource when they are present.

URL of the Resource that is the type used in this filter. Relative URLs are relative to the StructureDefinition root of the implemented FHIR version (e.g., http://hl7.org/fhir/StructureDefinition). For example, "Patient" maps to http://hl7.org/fhir/StructureDefinition/Patient. For more information, see <a href="elementdefinition-definitions.html#ElementDefinition.type.code">ElementDefinition.type.code</a>.

Either the canonical URL to a search parameter (like "http://hl7.org/fhir/SearchParameter/encounter-patient") or topic-defined parameter (like "hub.event") which is a label for the filter.

Chained parameters are allowed (like "patient.gender") - but can not use colons or modifiers.

Allowable operators to apply when determining matches (Search Modifiers).

List of properties to describe the shape (e.g., resources) included in notifications from this Subscription Topic.

URL of the Resource that is the type used in this shape. This is the "focus" of the topic (or one of them if there are more than one) and the root resource for this shape definition. It will be the same, a generality, or a specificity of SubscriptionTopic.resourceTrigger.resource or SubscriptionTopic.eventTrigger.resource when they are present.

URL of the Resource that is the type used in this shape. Relative URLs are relative to the StructureDefinition root of the implemented FHIR version (e.g., http://hl7.org/fhir/StructureDefinition). For example, "Patient" maps to http://hl7.org/fhir/StructureDefinition/Patient. For more information, see <a href="elementdefinition-definitions.html#ElementDefinition.type.code">ElementDefinition.type.code</a>.

Search-style _include directives, rooted in the resource for this shape. Servers SHOULD include resources listed here, if they exist and the user is authorized to receive them. Clients SHOULD be prepared to receive these additional resources, but SHALL function properly without them.

Search-style _revinclude directives, rooted in the resource for this shape. Servers SHOULD include resources listed here, if they exist and the user is authorized to receive them. Clients SHOULD be prepared to receive these additional resources, but SHALL function properly without them.