Document Subscription for Mobile (DSUBm)
1.0.0 - Trial-Implementation
Document Subscription for Mobile (DSUBm)
1.0.0 - Trial-Implementation
This page is part of the Document Subscription for Mobile (DSUBm) (v1.0.0: Publication) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
This section corresponds to the Resource Subscription [ITI-110] transaction of the IHE Technical Framework. The Resource Subscription [ITI-110] transaction is used by the Resource Notification Subscriber and Resource Notification Broker Actors to submit a subscription in order to receive a notification.
The Resource Subscription [ITI-110] transaction passes a Resource Subscription Request from a Resource Notification Subscriber to a Resource Notification Broker. This transaction can be used to create a new Subscription or to update an existing Subscription. The update of the subscription is intended to be used only to unsubscribe (deactivate) an existing Subscription or re-activate an already existing Subscription (in case of errors or deactivation).
Table 2:3.110.2-1: Actor Roles
| Actor | Role |
|---|---|
| Resource Notification Subscriber | Sends the Subscription request to the Resource Notification Broker |
| Resource Notification Broker | Receives and processes the Subscription request |
FHIR-R4 HL7 FHIR Release 4.0.1
This message uses the HTTP POST method on the target Resource Notification Broker endpoint to submit the Subscription resource.
This method is invoked when the Resource Notification Subscriber needs to submit a new subscription resource to the Resource Notification Broker. The Resource Notification Subscriber SHALL have already discovered the SubscriptionTopics supported by the Resource Notification Broker in order to create a subscription. The discovery SHOULD be performed by the Resource SubscriptionTopic Search [ITI-114] transaction or MAY be performed by any other methods that are out of the scope of this profile.
The Resource Notification Subscriber SHALL initiate an HTTP request according to the requirements defined in the HL7® FHIR® standard for the “create” interaction. The message uses an HTTP POST method to submit a Subscription FHIR Resource as specified in 3.110.5.2.1 Subscription Resource paragraph.
The Resource Notification Subscriber SHALL submit the FHIR Subscription resource in either XML format or JSON format thus the media type of the HTTP body SHALL be either application/fhir+json or application/fhir+xml respectively.
The Subscription is sent to the base URL as defined in FHIR. See http://hl7.org/fhir/R4/http.html for the definition of “HTTP” access methods and “base.”
It is possible to use HTTP protocol or HTTPS protocol. The HTTPS protocol is highly recommended.
The Subscription resource SHALL be compliant with the Subscription resource and SHALL be compliant with the Profile: R4/B Topic-Based Subscription.
The Subscription.criteria element SHALL include the canonical URL to a Basic resource that represents the Topic that the Subscription resource is related to. The Subscription.criteria element SHALL support the FilterBy Criteria extension. This extension SHALL be used to narrow the subscription triggering events defined in the topic represented in the Basic resource.
All the Subscription resources SHALL support the following extensions:
The Resource Notification Subscriber SHALL indicate in the Subscription.payload.content element the level of detail of the future notification that the Resource Notification Broker will send. The payload content extension defines three types of payload:
empty = No resource content is transmitted in the notification payload.id-only = Only the resource id is transmitted in the notification payload.full-resource = The entire resource is transmitted in the notification payload.All the Subscription resources SHALL have Subscription.status="requested", channel.type = "rest-hook", and channel.endpoint SHALL contain the URL that identifies where the Resource Notification Recipient receives the notification.
All the Subscription resources MAY have Subscription.end element set, indicating the instant when the subscription automatically terminates.
For documents, different types of subscription resources MAY be submitted to the Resource Notification Broker.
This profile defines the following types of Subscriptions with related SubscriptionTopics, which the Resource Notification Broker SHALL support and the Resource Notification Subscriber SHALL support at least one of them:
2:3.110.4.1.2.1.1 Subscription with DocumentReference Subscription for Minimal Update Option
When supporting the DocumentReference Subscription for Minimal Update Option, this profile also defines the following types of Subscriptions with related SubscriptionTopics:
2:3.110.4.1.2.1.2 Subscription with DocumentReference Subscription for Full Events Option
When supporting the DocumentReference Subscription for Full Events Option, this profile also defines the following types of Subscriptions with related SubscriptionTopics:
2:3.110.4.1.2.1.3 Subscription with Basic Folder Subscription Option
When supporting the Basic Folder Subscription Option, this profile also defines the following types of Subscriptions with related SubscriptionTopics:
| Subscription type | SubscriptionTopic |
|---|---|
| Basic Folder Subscriptions | Basic Folder SubscriptionTopic |
2:3.110.4.1.2.1.4 Subscription with Folder Subscription for Minimal Update Option
When supporting the Folder Subscription for Minimal Update Option, this profile also defines the following types of Subscriptions with related SubscriptionTopics:
| Subscription type | SubscriptionTopic |
|---|---|
| Folder Subscriptions with Folder Subscription for Minimal Update Option | Folder SubscriptionTopic with Folder Subscription for Minimal Update Option |
2:3.110.4.1.2.1.5 Subscription with Folder Subscription for Update Option
When supporting the Folder Subscription for Update Option, this profile also defines the following types of Subscriptions with related SubscriptionTopics:
| Subscription type | SubscriptionTopic |
|---|---|
| Folder Subscriptions with Folder Subscription for Update Option | Folder SubscriptionTopic with Folder Subscription for Update Option |
2:3.110.4.1.2.1.6 Subscription with Folder Subscription for Full Events Option
When supporting the Folder Subscription for Full Events Option, this profile also defines the following types of Subscriptions with related SubscriptionTopics:
| Subscription type | SubscriptionTopic |
|---|---|
| Folder Subscriptions with Folder Subscription for Full Events Option | Folder SubscriptionTopic with Folder Subscription for Full Events Option |
Upon receiving the request message the Resource Notification Broker SHALL verify the following conditions:
Basic resource (that represents the topic which the Subscription resource is related to) referred in the Subscription.criteria element received in the Subscription resource is valid;rest-hook;Subscription.end), if present, express a valid timestamp in the future.The Resource Notification Broker shall enforce all the Security Considerations.
The Resource Notification Broker MAY enforce to not duplicate a Subscription on the basis of the information transmitted in the request message (e.g., criteria, endpoint, user authentication, etc.) in order to prevent multiple Subscriptions and Notifications.
Based on the outcome of the conditions above, the Resource Notification Broker SHALL accept or reject the subscription resource received. If one or more of the conditions are false the Resource Notification Broker SHALL reject the Subscription resource and respond with an error message, which is defined in Subscription Error Response Message [ITI-110]. Otherwise, the Resource Notification Broker SHALL accept the Subscription resource, create the subscription, respond with a success message, which is defined in Create Subscription Response Message [ITI-110] and proceed to performing the handshake process.
The Resource Notification Broker SHALL support the handshake process to verify that the endpoint that identifies the Resource Notification Recipient, in the Subscription.channel.endpoint element of the subscription resource, is reachable before effectively activating the subscription.
The Resource Notification Broker SHALL set initial status to requested, pending verification of the nominated endpoint URL. Then, the Resource Notification Broker SHALL send to the Resource Notification Recipient a Handshake Notification Message [ITI-112]. After a successful handshake notification has been sent and accepted, the Resource Notification Broker SHALL update the status to active. Any errors in the initial handshake SHALL result in the status being changed to error. Note that the Resource Notification Subscriber SHOULD implement the Subscription Search [ITI-113] transaction in order to verify the activation of the subscription.
When the Subscription resource uses the heartbeatPeriod, if accepted, the Resource Notification Broker SHOULD send one Heartbeat Notification Message [ITI-112] per interval on the accepted and active subscription.
Once the Subscription is activated, the Resource Notification Broker SHALL monitor resources based on the Subscription criteria and, if matches, SHALL send the appropriate Resource Notification Recipient a Event Notification Message [ITI-112].
Further considerations needs to be done, for the activation of a Subscription, considering DSUBm as an interface for a DSUB environment.
If the Resource Notification Broker is grouped with DSUB Document Metadata Subscriber and DSUB Document Metadata Notification Recipient, considering DSUBm as an interface for DSUB model, if the subscription is accepted, the Resource Notification Broker SHALL also trigger a Subscribe Request message towards the DSUB Document Metadata Notification Broker from the DSUB Document Metadata Subscriber with an Document Metadata Subscribe [ITI-52] transaction.
The mapping between the Subscription resource contained in the Resource Subscription [ITI-110] transaction and the Document Metadata Subscribe [ITI-52] transaction SHALL be as following:
If the Subscription resource has a Subscription.payload = "full-resource" the Document Metadata Subscribe [ITI-52] transaction SHALL have a “ihe:FullDocumentEntry” Topic Expression. Otherwise a “ihe:MinimalDocumentEntry” Topic Expression SHALL be used.
Depending on the type of the Subscription, the AdHocQuery/@id attribute and the Filters parameter of the Document Metadata Subscribe [ITI-52] transaction SHALL be set as follows:
| Subscription type | AdHocQuery/@id | Filter parameter |
|---|---|---|
| Patient-Dependent DocumentReference Subscriptions | urn:uuid:aa2332d0-f8fe-11e0-be50-0800200c9a66 |
Mapping based on Table 2:3.110.4.7-1 |
| Multi-Patient DocumentReference Subscriptions | urn:uuid:742790e0-aba6-43d6-9f1fe43ed9790b79 |
Mapping based on Table 2:3.110.4.7-1 |
| Patient-Dependent SubmissionSet Subscriptions | urn:uuid:fbede94e-dbdc-4f6b-bc1f-d730e677cece |
Mapping based on Table 2:3.110.4.7-2 |
| Multi-Patient SubmissionSet Subscriptions | urn:uuid:868cad3d-ec09-4565-b66c-1be10d034399 |
Mapping based on Table 2:3.110.4.7-2 |
| Basic Folder Subscriptions | urn:uuid:9376254e-da05-41f5-9af3-ac56d63d8ebd |
Mapping based on Table 2:3.110.4.7-3 |
If the Subscription resource has the Subscription.end element set, the Document Metadata Subscribe [ITI-52] transaction SHALL have a wsnt:InitialTerminationTime element set.
When the Document Metadata Subscribe [ITI-52] transaction has a successful result, the Resource Notification Broker SHALL maintain the coupling between the Subscription Resource id and the webservice endpoint present in the Address element of the Document Metadata Subscribe [ITI-52] response message, in order to be capable of managing a later unsubscribe.
If the DSUB Document Metadata Notification Broker sends an assigned duration for the subscription, the Resource Notification Broker SHALL associate the assigned duration with the accepted subscription request and eventually unsubscribe towards the DSUB Document Metadata Notification Broker when expired.
The Resource Notification Broker sends a Resource Subscription Response Message to respond to a Create Subscription Request Message.
When the Resource Notification Broker has finished successfully evaluating the subscription received and the operation, the Resource Notification Broker sends this message to the Resource Notification Subscriber acknowledging the result of the creation of the resource.
The Resource Notification Broker SHALL respond with an HTTP 201 Created status code as indicated for “create” and the Resource Notification Broker SHALL return the entire resource in which the status SHALL be requested. If the Resource Notification Broker has assigned a termination time, the element end SHALL be set.
The Resource Notification Subscriber processes the response according to application-defined rules.
For the Subscription creation:
If the Resource Notification Subscriber had not indicated a requested duration for the subscription, the Resource Notification Broker MAY send an assigned duration for the subscription (if any), using the Subscription.end element.
If the Resource Notification Broker sends an assigned duration for the subscription, the Resource Notification Subscriber SHALL associate the assigned duration with the accepted subscription request.
The Resource Notification Subscriber SHALL associate the accepted subscription request with the subscription id assigned by the Resource Notification Broker in order to be able to send cancellations for existing subscriptions.
This message uses the HTTP PUT method on the target Resource Notification Broker endpoint to update an existing Subscription resource in order to:
This method is invoked when the Resource Notification Subscriber needs to:
so it sends an update of the Subscription resource to the Resource Notification Broker.
The Resource Notification Subscriber SHALL initiate an HTTP request according to requirements defined in the HL7® FHIR® standard for “update” interaction. The message uses an HTTP PUT method to update a Subscription FHIR Resource previously created (see section 2:3.110.4.1 Create Subscription Request Message).
The Subscription.id element SHALL be valued with the id of the Subscription to be updated.
In order to unsubscribe, the Subscription Resource SHALL have status=off.
In order to re-activate an already existing Subscription, the Subscription Resource SHALL have status=requested.
The Resource Notification Subscriber SHALL submit the FHIR Subscription resource in either XML format or JSON format thus the media type of the HTTP body SHALL be either application/fhir+json or application/fhir+xml respectively.
The Resource Subscription message is sent to the base URL as defined in FHIR. See http://hl7.org/fhir/R4/http.html for the definition of “HTTP” access methods and “base”.
It is possible to use HTTP protocol or HTTPS protocol. The HTTPS protocol is highly recommended.
Upon receiving the request message the Resource Notification Broker SHALL verify the following conditions:
off or the Subscription.status sended is requested and the actual Subscription.status is error or off.The Resource Notification Broker SHALL enforce all the Security Considerations.
Based on the outcome of the conditions above the Resource Notification Broker SHALL accept or reject the update of the subscription resource received. If all the conditions are true the Resource Notification Broker SHALL:
status=off). When deactivated, the Resource Notification Broker SHOULD sent a Subscription Deactivation Notification [ITI-112] to the Resource Notification Recipient. No other notification SHALL be sent.Further considerations needs to be done in the following paragraph, considering DSUBm as an interface for DSUB environment.
If the Resource Notification Broker is grouped with DSUB Document Metadata Subscriber and DSUB Document Metadata Notification Recipient, considering DSUBm as an interface for DSUB model, if the update of the subscription is accepted, the Resource Notification Broker SHALL trigger the Document Metadata Subscriber to send an Unsubscribe Request message towards the Document Metadata Notification Broker with an [ITI-52] Document Metadata Subscribe transaction. The message SHALL be sent to the webservice endpoint previously associated to the Subscription id (see section 2:3.110.4.1.3.1 Expected Actions section).
If the Resource Notification Broker is grouped with DSUB Document Metadata Subscriber and DSUB Document Metadata Notification Recipient, considering DSUBm as an interface for DSUB model, when the update is for re-activate errored Subscription (Subscription.status sended is requested and the actual Subscription.status is error) this grouping does not require further Expected Actions.
Instead, for this grouping, when the update is for re-activate turned off Subscription (Subscription.status sended is requested and the actual Subscription.status is off) the Resource Notification Broker SHALL consider the re-activation like a new Subscription that SHALL be propagated to the DSUB Document Metadata Notification Broker. So, the Resource Notification Broker SHALL trigger a Subscribe Request message towards the DSUB Document Metadata Notification Broker from the DSUB Document Metadata Subscriber with an Document Metadata Subscribe [ITI-52] transaction, following what is defined in Section Expected Actions with DSUBm as an interface for DSUB.
The Resource Notification Broker sends a Resource Subscription Response Message to respond to an Update Subscription Request Message.
When the Resource Notification Broker has finished successfully evaluating the subscription received and the operation, the Resource Notification Broker sends this message to the Resource Notification Subscriber acknowledging the result the update of the resource.
The Resource Notification Broker SHALL respond with an HTTP 200 OK status code as indicated for “update” and the Resource Notification Broker SHALL return the entire resource in which the status SHALL be off for subscription deactivation or requested for subscription re-activation from error.
The Resource Notification Subscriber processes the response according to application-defined rules.
The Resource Notification Broker sends a Resource Subscription Response Message to respond in case of error to an Create Subscription Request Message or to an Update Subscription Request Message.
When the Resource Notification Broker has finished evaluating the Subscription received and the operation, evaluating that it cannot proceeds due to error(s), the Resource Notification Broker sends this message to the Resource Notification Subscriber acknowledging the result the creation or the update of the resource.
The Resource Notification Broker SHALL respond with an appropriate HTTP failure status code, based on the issue found. Further specifics, including the use of the OperationOutcome resource in the response message, SHALL follow what is indicated in “create” and “rejecting-updates” sections of FHIR core, based on the operation that is occurring on the Subscription resource.
The Resource Notification Subscriber processes the response according to application-defined rules.
This section clarifies the Subscription Topics and the filter parameters for each type of Subscription that this profile defines.
Further, for each type of subscription, the events for which subscriptions are possible are specified that the Resource Notification Broker SHALL evaluate. The Resource Notification Broker becomes aware of such events either via a Resource Publish [ITI-111] transaction, or via other mechanisms not specified by this profile.
For this type of subscription, the stream of events for which subscriptions are possible is limited to events representing the creation of DocumentReference Resources related to Documents. Note that these events could be determined by Document Entry Objects creation in XDS environment. Note that these creation events could be happened with other events.
For this type of subscription, the possible subscription filter parameters are:
author.given and author.familycategoryeventfacilityformatpatientpatient.identifiersecurity-labelsettingtypestatusFor the definition of these parameters see ITI-67 Query Search Parameters.
At least one of the patient or patient.identifier parameters SHALL be used.
With the exception of status and patient or patient.identifier, all parameters MAY be multi-valued.
The canonical URL of this SubscriptionTopic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-DocumentReference-PatientDependent.
The Resource Notification Broker SHALL support all the filter parameters that are expressed in the SubscriptionTopic. The Resource Notification Broker SHALL determine if there is a Subscription which matches any of the DocumentReference resources in an event. The evaluation performed is likely a search operation using the criteria in the Subscription. If it matches, the Resource Notification Broker SHALL send an Event Notification Message [ITI-112]. If the Subscription.payload.content includes resources, the DocumentReference resources SHALL be present.
The canonical instance of this SubscriptionTopic is reported here: Patient-Dependent DocumentReference SubscriptionTopic.
When supporting the DocumentReference Subscription for Minimal Update Option, this Subscription Topic extends the Patient-Dependent DocumentReference SubscriptionTopic in this way:
The canonical URL of this SubscriptionTopic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-DocReference-PatientDependent-MinUpdate.
The canonical instance of this SubscriptionTopic is reported here: Patient-Dependent DocumentReference SubscriptionTopic with DocumentReference Subscription for Minimal Update Option.
When supporting the DocumentReference Subscription for Full Events Option, this Subscription Topic extends the Patient-Dependent DocumentReference SubscriptionTopic in this way:
The canonical URL of this SubscriptionTopic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-DocReference-PatientDependent-AllEvents.
The canonical instance of this SubscriptionTopic is reported here: Patient-Dependent DocumentReference SubscriptionTopic with Updates to document sharing resources Option.
For this type of subscription, the stream of events for which subscriptions are possible is limited to events representing the creation of DocumentReference Resources related to Documents. Note that these events could be determined from Document Entry Objects created in an XDS environment. Note that these creation events could happen with other events.
For this type of subscription, the possible subscription filter parameters are:
author.given and author.familycategoryeventfacilityformatsecurity-labelsettingtypestatusFor the definition of these parameters see ITI-67 Query Search Parameters.
With the exception of status, all parameters MAY be multi-valued.
The canonical URL of this SubscriptionTopic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-DocumentReference-MultiPatient.
The Resource Notification Broker SHALL support all the filter parameters that are expressed in the SubscriptionTopic. The Resource Notification Broker SHALL determine if there is a Subscription which matches any of the DocumentReference resources in an event. The evaluation performed is likely a search operation using the criteria in the Subscription. If it matches, the Resource Notification Broker SHALL send a Event Notification Message [ITI-112]. If the Subscription.payload.content includes resources, the DocumentReference resources SHALL be present.
The canonical instance of this SubscriptionTopic is reported here: Multi-Patient DocumentReference SubscriptionTopic.
When the DocumentReference Subscription for Minimal Update Option is supported, the following Subscription Topic extends the Multi-Patient DocumentReference Subscriptions Topic in this way:
The canonical URL of this SubscriptionTopic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-DocReference-MultiPatient-MinUpdate.
The canonical instance of this extended SubscriptionTopic is reported here: Multi-Patient DocumentReference SubscriptionTopic with DocumentReference Subscription for Minimal Update Option.
When the DocumentReference Subscription for Full Events Option is supported, the following Subscription Topic extends the Multi-Patient DocumentReference Subscriptions Topic in this way:
The canonical URL of this SubscriptionTopic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-DocReference-MultiPatient-AllEvents.
The canonical instance of this extended SubscriptionTopic is reported here: Multi-Patient DocumentReference SubscriptionTopic with DocumentReference Subscription for Full Events Option.
For this type of subscription, the stream of events for which subscriptions are possible is limited to events representing the creation of SubmissionSet type List Resources related to SubmissionSet. Note that these events could be determined from SubmissionSet Objects created in an XDS environment. Note that these creation events could be happened with other events.
For this type of subscription, the possible subscription filter parameters are:
codepatientpatient.identifiersource.given and source.familysourceIdintendedRecipientFor the definition of these parameters see ITI-66 Query Search Parameters.
At least one of the patient or patient.identifier parameters SHALL be used.
Only the source.given, source.family, sourceId and intendedRecipient parameters MAY be multi-valued.
The canonical URL of this Subscription Topic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-SubmissionSet-PatientDependent.
The Resource Notification Broker SHALL support all the filter parameters that are expressed in the SubscriptionTopic. The Resource Notification Broker SHALL determine if there is a Subscription which matches any of the SubmissionSet type List resources in an event. The evaluation performed is likely a search operation using the criteria in the Subscription. If it matches, the Resource Notification Broker SHALL send an Event Notification Message [ITI-112]. If the Subscription.payload.content includes resources, the SubmissionSet type List resources SHALL be present.
The canonical instance of this SubscriptionTopic is reported here: Patient-Dependent SubmissionSet SubscriptionTopic.
For this type of subscription, the stream of events for which subscriptions are possible is limited to events representing the creation of SubmissionSet type List Resources related to SubmissionSet. Note that these events could be determined from SubmissionSet Objects creation in an XDS environment. Note that these creation events could happen with other events.
For this type of subscription, the possible subscription filter parameters are:
codesource.given and source.familysourceIdintendedRecipientFor the definition of these parameters see ITI-66 Query Search Parameters.
All the parameters MAY be multi-valued.
The canonical URL of this SubscriptionTopic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-SubmissionSet-MultiPatient.
The Resource Notification Broker SHALL support all the filter parameters that are expressed in the SubscriptionTopic. The Resource Notification Broker SHALL determine if there is a Subscription which matches any of the SubmissionSet type List resources in an event. The evaluation performed is likely a search operation using the criteria in the Subscription. If it matches, the Resource Notification Broker SHALL send an Event Notification Message [ITI-112]. If the Subscription.payload.content includes resources, the SubmissionSet type List resources SHALL be present.
The canonical instance of this SubscriptionTopic is reported here: Multi-Patient SubmissionSet SubscriptionTopic.
When the Basic Folder Subscription Option is supported, this type of subscription is admitted. For this type of subscription, the stream of events for which subscriptions are possible is limited to events representing the creation of Folder type List Resources and the update to insert new documents in Folder. Note that these events could be determined from Folder Objects created or updated and Association Object creation in an XDS environment. Note that these creation or updating events could happen with other events.
For this type of subscription, the possible subscription filter parameters are:
codepatientpatient.identifieridentifierdesignationTypestatusFor the definition of these parameters see ITI-66 Query Search Parameters.
At least one of the patient or patient.identifier parameters SHALL be used.
Only the identifier and designationType parameters MAY be multi-valued.
The canonical URL of this SubscriptionTopic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-Basic-Folder-Subscription.
The Resource Notification Broker SHALL support all the filter parameters that are expressed in the SubscriptionTopic. The Resource Notification Broker SHALL determine if there is a Subscription which matches any of the Folder type List resources in an event. The evaluation performed is likely a search operation using the criteria in the Subscription. If it matches, the Resource Notification Broker SHALL send an Event Notification Message [ITI-112]. If the Subscription.payload.content includes resources, the Folder type List resources SHALL be present.
The canonical instance of this SubscriptionTopic is reported here: Basic Folder SubscriptionTopic.
When the Folder Subscription for Minimal Update Option is supported, this Subscription Topic extends the Basic Folder Subscription Topic in this way:
The canonical URL of this Subscription Topic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-Folder-Subscription-MinUpdateOpt.
The canonical instance of this SubscriptionTopic is reported here: Folder SubscriptionTopic with Folder Subscription for Minimal Update Option.
When the Folder Subscription for Update Option is supported, this Subscription Topic extends the Basic Folder Subscription Topic in this way:
The canonical URL of this Subscription Topic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-Folder-Subscription-UpdateOpt.
The canonical instance of this SubscriptionTopic is reported here: Folder SubscriptionTopic with Folder Subscription for Minimal Update Option.
When the Folder Subscription for Full Events Option is supported, this Subscription Topic extends the Basic Folder Subscription Topic in this way:
The canonical URL of this Subscription Topic that SHALL be used in the Subscription.criteria element is https://profiles.ihe.net/ITI/DSUBm/DSUBm-SubscriptionTopic-Folder-Subscription-for-Full-Events.
The canonical instance of this SubscriptionTopic is reported here: Folder SubscriptionTopic with Folder Subscription for Full Events Optionn.
If the Resource Notification Broker is grouped with Document Metadata Subscriber and Document Metadata Notification Recipient, considering DSUBm as an interface for DSUB model, the Subscription.criteria available parameters in the Subscription resource SHALL be mapped with the DSUB filter Expression.
Table 2:3.110.4.7-1: DSUBm DocumentReference subscription criteria mapping to DSUB DocumentEntry Filters
| DSUBm Subscription.criteria |
DSUB DocumentEntry Filters |
|---|---|
| author.given / author.family | $XDSDocumentEntryAuthorPerson |
| category | $XDSDocumentEntryClassCode |
| event | $XDSDocumentEntryEventCodeList |
| facility | $XDSDocumentEntryHealthcareFacilityTypeCode |
| format | $XDSDocumentEntryFormatCode |
| patient or patient.identifier | $XDSDocumentEntryPatientId |
| security-label | $XDSDocumentEntryConfidentialityCode |
| type | $XDSDocumentEntryTypeCode |
| status | none |
Table 2:3.110.4.7-2: DSUBm SubmissionSet subscription criteria mapping to DSUB DocumentEntry Filters
| DSUBm Subscription.criteria |
DSUB SubmissionSet Filters |
|---|---|
| code | none |
| patient or patient.identifier | $XDSSubmissionSetPatientId |
| source.given or source.family | $XDSSubmissionSetAuthorPerson |
| sourceId | $XDSSubmissionSetSourceId |
| intendedRecipient | $XDSSubmissionSetIntendedRecipient |
Table 2:3.110.4.7-3: DSUBm Folder subscription criteria mapping to DSUB DocumentEntry Filters
| DSUBm Subscription.criteria |
DSUB Folder Filters |
|---|---|
| code | none |
| patient or patient.identifier | $XDSFolderPatientId |
| identifier | $XDSFolderUniqueId |
| designationType | $XDSFolderCodeList |
| status | none |
The Resource Notification Subscriber implementing this transaction SHALL provide a CapabilityStatement Resource as described in ITI TF-2x: Appendix Z.3 indicating the transaction has been implemented. The possible CapabilityStatements for the Resource Notification Subscriber ar listed in Section 1:54.1.1.2 Resource Notification Subscriber.
The Resource Notification Broker implementing this transaction SHALL provide a CapabilityStatement Resource as described in ITI TF-2x: Appendix Z.3 indicating the transaction has been implemented. The possible CapabilityStatements for the Resource Notification Broker ar listed in Section 1:54.1.1.1 Resource Notification Broker.
See DSUBm Security Considerations.
The Resource Notification Broker SHALL control that the Resource Notification Subscriber is acceptable and authorized to create or update a Subscription Resource. It’s highly RECOMMENDED that the Resource Notification Subscriber SHOULD use some form of authentication method when creating or updating a Subscription. The Resource Notification Broker SHALL also be aware and enforce any agreed policy in order to control that the Subscription criteria received, that describe the notification event, are permitted to the authenticated Resource Notification Subscriber. For example a veterinary clinical record MAY be allowed to request a subscription but the Resource Notification Broker SHALL verify that the Subscription is related only to documents produced for animal subjects and SHALL reject any subscription made for documents produced for human subjects.
If there is a policy that needs to be enforced in order to control which subscriber can Subscribe or Unsubscribe then, the Resource Notification Broker might maintain a whitelist of acceptable senders for the ITI-110 transactions.
The Resource Notification Broker MAY enforce some control on the channel.endpoint element of the Subscription resource received in order to control where the notification will be sent. The Resource Notification Broker might maintain an allow-list of acceptable endpoints or trusted certificate authorities for rest-hook channels.
The Resource Notification Broker MAY control the Subscription.payload element of Subscription resource received in order to mitigate the risk of disclosing sensitive information. For example, if the Subscription criteria includes sensitive documents, the Resource Notification Broker MAY allow just ‘id-only’ payloads. In this way further authorization mechanisms SHALL be enforced when the Resource Notification Recipient tries to retrieve the information using the id.
The Resource Notification Subscriber, when grouped with ATNA Secure Node or Secure Application Actor, SHALL be able to record fundamental AuditEvents for:
The Resource Notification Broker, when grouped with ATNA Secure Node or Secure Application Actor, SHALL be able to record fundamental AuditEvents for:
IG © 2023+ IHE IT Infrastructure Technical Committee. Package ihe.iti.dsubm#1.0.0 based on FHIR 4.0.1. Generated 2024-02-29
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change