Subscriptions R5 Backport
1.1.0 - Standard for Trial Use
Subscriptions R5 Backport
1.1.0 - Standard for Trial Use
This page is part of the Subscriptions R5 Backport (v1.1.0: STU 1.1) based on FHIR v4.3.0. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions 
This page defines how CapabilityStatements are used and the expectations for mandatory and must support elements. A conformant system SHALL support the resources as profiled by this guide.
Note that the conformance verbs - SHALL, SHOULD, MAY - used in this guide are defined by the FHIR Conformance Rules.
In order to claim conformance with this guide, a server:
Subscription resource (read/write).$status operation on the Subscription resource.SubscriptionTopic resource (read/search).FHIR Servers claiming conformance to this Implementation Guide must conform to the expectations described in the Capability Statement appropriate to the implemented FHIR version. For FHIR R4B servers, this guide defines the R4B Server CapabilityStatement.
Some options of the Subscriptions Framework are not easily expressed in a CapabilityStatement. In addition to the basic support in the CapabilityStatement (e.g., resources, interactions, and operations), a conformant server SHALL support at least one Payload Type and SHOULD support one Channel Type listed in this IG.
Note that the future publication of FHIR R5 may define capabilities included in this specification as cross-version extensions. Since FHIR R5 is currently under development, there are no guarantees these extensions will meet the requirements of this guide. In order to promote widespread compatibility, cross version extensions SHOULD NOT be used on R4 subscriptions to describe any elements described by this guide.
Profile Support refers to the support of the profiles defined in this guide in a system exposing FHIR resources. Specifically, a conformant server:
CapabilityStatement.instantiates element: http://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement/CapabilitySubscriptionServer.CapabilityStatement.rest.resource.supportedProfile element: http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-subscriptionIn this guide, some elements are marked as Must Support. Elements that are flagged as MS are enumerated below, with details on what support means.
The backport-channel-type extension is used to allow for custom channels not described in this guide.
Servers supporting this guide SHALL be able to read values present in this element. A server SHALL reject the subscription request if a client requests an unsupported channel via this element.
Clients supporting this guide MAY support this extension, as necessary for their use case.
The backport-filter-criteria extension is used to describe the actual filters used in a specific instance of a subscription.
Servers supporting this guide SHALL be able to read values in this extension and SHALL be able to apply filters as described by any Subscription Topics the server advertises support for.
If a server is capable of supporting filter criteria in general but unable to support criteria requested in a subscription, the server SHALL reject the subscription.
Clients supporting this guide SHALL be able to write values in this extension.
The backport-payload-content extension is used to describe the amount of detail included in notification payloads.
Servers supporting this guide SHALL be able to read values from this extension. A server SHALL reject the subscription request if a client asks for a content level the server does not intend to support (e.g., does not meet security requirements). Servers SHALL include information in notifications as described in this guide based on this value.
Clients supporting this guide SHALL be able to write values in this extension.
Notification bundles SHALL contain a FHIR R4B SubscriptionStatus as the first entry.
Servers supporting this guide SHALL be able to generate a valid and correct SubscriptionStatus resource for each notification. The status entry SHALL be the first entry of each notification bundle.
Clients supporting this guide SHALL be able to process a valid SubscriptionStatus resource without errors.
The Subscription.criteria element is required (cardinality of 1..1), so any compatible implementation SHALL be able to read and/or write as necessary. Compared with the core specification, this guide specifies that the element SHALL contain the canonical URL for the Subscription Topic.
Servers supporting this guide SHALL be able to read values in this element and process requests for subscription topics referenced by it. If a server does not support a requested topic or will not honor the subscription otherwise, a server SHALL reject the subscription request.
Clients supporting this guide SHALL be able to write subscription topic URLs into this element.
In order to claim conformance with this guide, a server:
Subscription resource (read/write).$status operation on the Subscription resource.Note that in FHIR R4, there is no representation of Subscription Topics. Detailed discussion can be found on the Topic-Based Subscription Components page.
FHIR Servers claiming conformance to this Implementation Guide must conform to the expectations described in the Capability Statement appropriate to the implemented FHIR version. For FHIR R4 servers, this guide defines the R4 Server CapabilityStatement.
Some options of the Subscriptions Framework are not easily expressed in a CapabilityStatement. In addition to the basic support in the CapabilityStatement (e.g., resources, interactions, and operations), a conformant server SHALL support at least one Payload Type and SHOULD support one Channel Type listed in this IG.
Note that the future publication of FHIR R5 may define capabilities included in this specification as cross-version extensions. Since FHIR R5 is currently under development, there are no guarantees these extensions will meet the requirements of this guide. In order to promote widespread compatibility, cross version extensions SHOULD NOT be used on R4 subscriptions to describe any elements described by this guide.
Profile Support refers to the support of the profiles defined in this guide in a system exposing FHIR resources. Specifically, a conformant server:
CapabilityStatement.instantiates element: http://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement/backport-subscription-server-r4.CapabilityStatement.rest.resource.supportedProfile element: http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-subscriptionIn this guide, some elements are marked as Must Support. Elements that are flagged as MS are enumerated below, with details on what support means.
The backport-channel-type extension is used to allow for custom channels not described in this guide.
Servers supporting this guide SHALL be able to read values present in this element. A server SHALL reject the subscription request if a client requests an unsupported channel via this element.
The backport-filter-criteria extension is used to describe the actual filters used in a specific instance of a subscription.
Servers supporting this guide SHALL be able to read values in this extension and SHALL be able to apply filters as described by any Subscription Topics the server advertises support for.
If a server is capable of supporting filter criteria in general but unable to support criteria requested in a subscription, the server SHALL reject the subscription.
Clients supporting this guide SHALL be able to write values in this extension.
The backport-payload-content extension is used to describe the amount of detail included in notification payloads.
Servers supporting this guide SHALL be able to read values from this extension. A server SHALL reject the subscription request if a client asks for a content level the server does not intend to support (e.g., does not meet security requirements). Servers SHALL include information in notifications as described in this guide based on this value.
Clients supporting this guide SHALL be able to write values in this extension.
Notification bundles SHALL contain a FHIR R4 Parameters resource, conforming to the R4 Backported R5 SubscriptionStatus profile, as the first entry.
Servers supporting this guide SHALL be able to generate a valid and correct R4 Backported R5 SubscriptionStatus resource for each notification. The status entry SHALL be the first entry of each notification bundle.
Clients supporting this guide SHALL be able to process a valid R4 Backported R5 SubscriptionStatus resource without errors.
The Subscription.criteria element is required (cardinality of 1..1), so any compatible implementation SHALL be able to read and/or write as necessary. Compared with the core specification, this guide specifies that the element SHALL contain the canonical URL for the Subscription Topic.
Servers supporting this guide SHALL be able to read values in this element and process requests for subscription topics referenced by it. If a server does not support a requested topic or will not honor the subscription otherwise, a server SHALL reject the subscription request.
Clients supporting this guide SHALL be able to write subscription topic URLs into this element.
IG © 2020+ HL7 FHIR Infrastructure WG. Package hl7.fhir.uv.subscriptions-backport#1.1.0 based on FHIR 4.3.0. Generated 2023-01-11
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change