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 defines the actors and transactions in this implementation guide.
Figure 1:54.1-1 shows the actors directly involved in the DSUBm Profile and the relevant transactions between them.
Table 1:54.1-1 lists the transactions for each actor directly involved in the DSUBm Profile. To claim compliance with this profile, an actor SHALL support all REQUIRED transactions (labeled “R”) and MAY support the optional transactions (labeled “O”).
Table 1:54.1-1: DSUBm Profile - Actors and Transactions
Actors | Transactions | Initiator or Responder | Optionality |
Resource Notification Broker | Resource Subscription [ITI-110] | Responder | R |
Resource Publish [ITI-111] | Responder | O | |
Resource Notify [ITI-112] | Initiator | R | |
Resource Subscription Search [ITI-113] | Responder | R | |
Resource SubscriptionTopic Search [ITI-114] | Responder | R | |
Resource Notification Subscriber | Resource Subscription [ITI-110] | Initiator | R |
Resource Subscription Search [ITI-113] | Initiator | O | |
Resource SubscriptionTopic Search [ITI-114] | Initiator | O | |
Resource Notification Publisher | Resource Publish [ITI-111] | Initiator | R |
Resource Notification Recipient | Resource Notify [ITI-112] | Responder | R |
The actors in this profile are described in more detail in the following sections.
The Resource Notification Broker receives the Resource Subscription transaction containing a subscription request or a subscription cancellation. It keeps track of all subscriptions it receives, including the time limits of subscriptions. Based on the subscription criteria, this actor sends notifications to interested subscribers when events occur. This actor MAY receive Resource Publish transactions representing the stream of events against which the existing subscriptions are matched. It supports the search and retrieval of Subscription and SubscriptionTopic resources.
The following CapabilityStatements define the actor capabilities given the various options:
FHIR Capability Statement for Resource Notification Broker
FHIR Capability Statement for Resource Notification Broker that supports the DocumentReference Subscription for Minimal Update Option
FHIR Capability Statement for Resource Notification Broker that supports the DocumentReference Subscription for Full Events Option
FHIR Capability Statement for Resource Notification Broker that supports the Basic Folder Subscription Option
FHIR Capability Statement for Resource Notification Broker that supports the Folder Subscription for Minimal Update Option
FHIR Capability Statement for Resource Notification Broker that supports the Folder Subscription for Update Option
FHIR Capability Statement for Resource Notification Broker that supports the Folder Subscription for Full Events Option
The Resource Notification Subscriber initiates and terminates subscriptions on behalf of a Resource Notification Recipient. It can perform a Resource Subscription Search transaction to the Resource Notification Broker for existing subscription search. It also can perform a Resource SubscriptionTopic Search transaction to the Resource Notification Broker for searching the SubscriptionTopic resources.
The following CapabilityStatements define the actor capabilities given the various options:
FHIR Capability Statement for Resource Notification Subscriber
FHIR Capability Statement for Resource Notification Subscriber that supports the DocumentReference Subscription for Minimal Update Option
FHIR Capability Statement for Resource Notification Subscriber that supports the DocumentReference Subscription for Full Events Option
FHIR Capability Statement for Resource Notification Subscriber that supports the Basic Folder Subscription Option
FHIR Capability Statement for Resource Notification Subscriber that supports the Folder Subscription for Minimal Update Option
FHIR Capability Statement for Resource Notification Subscriber that supports the Folder Subscription for Update Option
FHIR Capability Statement for Resource Notification Subscriber that supports the Folder Subscription for Full Events Option
The Resource Notification Publisher sends a Resource Publish transaction to the Resource Notification Broker when an event occurs for which a subscription MAY exist. Note that this profile does not specify how the Resource Notification Publisher becomes aware of those events.
The following CapabilityStatements define the actor capabilities given the various Options:
FHIR Capability Statement for Resource Notification Publisher
FHIR Capability Statement for Resource Notification Publisher that supports the DocumentReference Subscription for Minimal Update Option
FHIR Capability Statement for Resource Notification Publisher that supports the DocumentReference Subscription for Full Events Option
FHIR Capability Statement for Resource Notification Publisher that supports the Basic Folder Subscription Option
FHIR Capability Statement for Resource Notification Publisher that supports the Folder Subscription for Minimal Update Option
FHIR Capability Statement for Resource Notification Publisher that supports the Folder Subscription for Update Option
FHIR Capability Statement for Resource Notification Publisher that supports the Folder Subscription for Full Events Option
The Resource Notification Recipient receives the notification about an event when the subscription filters specified for this Document Resource Notification Recipient are satisfied.
FHIR Capability Statement for Resource Notification Recipient.
The transactions in this profile are summarized in the sections below.
This transaction is used for subscribing to Documents, by using a particular set of filters, or to unsubscribe, using Subscription
resources.
For more details see the detailed [ITI-110] transaction description.
This transaction delivers information from the Resource Notification Publisher to the Resource Notification Broker about an event that MAY have a subscription.
For more details see the detailed [ITI-111] transaction description.
This transaction is used for sending notifications to a Resource Notification Recipient related to a subscription.
For more details see the detailed [ITI-112] transaction description.
This transaction is used for searching existing Subscription
resources.
For more details see the detailed [ITI-113] transaction description.
This transaction is used for searching existing SubscriptionTopic
resources.
For more details see the detailed [ITI-114] transaction description.
Optional functionality that MAY be implemented for each actor in this implementation guide are listed in Table 1:54.2-1 below. Dependencies between options when applicable are specified in notes.
Table 1:54.2-1: Actor Options
This option extends the basic trigger events considered for a DocumentReference Subscription.
This option extends the triggers for the creation of a DocumentReference resource to also include updates of the document “status” and delete events of a DocumentReference Resource.
This option limited the Update events because Resource Notification Brokers that are not operating as native FHIR servers might not have the ability to notify for all possible update events.
The Resource Notification Broker that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.1 Subscription with DocumentReference Subscription for Minimal Update Option and the related SubscriptionTopic, accepting this type of Subscription sent from a Resource Notification Subscriber.
The Resource Notification Subscriber that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.1 Subscription with DocumentReference Subscription for Minimal Update Option.
The Resource Notification Publisher that declares support for this option SHALL implement the Resource Publish [ITI-111] transaction for the trigger events defined in Section 2:3.111.4.1.1.1 DocumentReference Subscription for Minimal Update Option Trigger Events and to communicate the stream of events to the Resource Notification Broker as defined in Section 2:3.111.4.1.2.1 DocumentReference Subscription for Minimal Update Option Bundle.
This option extends the basic trigger events considered for a DocumentReference Subscription.
This option extends the triggers for the creation of a DocumentReference resource to include all possible update events and delete events of a DocumentReference Resource.
The Resource Notification Broker that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.2 Subscription with DocumentReference Subscription for Full Events Option, and the related SubscriptionTopic, accepting this type of Subscription sent from a Resource Notification Subscriber.
The Resource Notification Subscriber that declares support for this option SHALL support the Subscription defined in Section 2:3.110.4.1.2.1.2 Subscription with DocumentReference Subscription for Full Events Option.
The Resource Notification Publisher that declares support for this option SHALL implement the Resource Publish [ITI-111] transaction for the trigger events defined in Section in Section 2:3.111.4.1.1.2 DocumentReference Subscription for Full Events Option Trigger Events and to communicate the stream of events to the Resource Notification Broker as defined in Section 2:3.111.4.1.2.2 DocumentReference Subscription for Full Events Option Bundle.
This option allows subscriptions to Folder type List resources and describes the basic trigger events considered for a Folder Subscription.
This option includes triggers about the creation and limited update events on a Folder type List resource. The limited update event considered is the insertion of a new document in the Folder.
This option limits the update events to reduce the effort on the Resource Notification Broker. This limitation has been introduced because the Resource Notification Brokers that are not operating as native FHIR servers might not have the ability to notify for all the possible update events.
The Resource Notification Broker that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.3 Subscription with Basic Folder Subscription Option, and the related SubscriptionTopic, accepting this type of Subscription sent from a Resource Notification Subscriber.
The Resource Notification Subscriber that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.3 Subscription with Basic Folder Subscription Option.
The Resource Notification Publisher that declares support for this option SHALL also implement in the Resource Publish [ITI-111] transaction the trigger events defined in Section 2:3.111.4.1.1.3 Basic Folder Subscription Option Trigger Events and to communicate the stream of events to the Resource Notification Broker as defined in Section 2:3.111.4.1.2.3 Subscription with Basic Folder Subscription Option Bundle.
This option allows subscriptions to Folder type List resources and extends the basic trigger events considered for a Folder Subscription.
This option includes triggers about the creation of a Folder type List resource and the update of a Folder type List resource. The update of this resource considers only the following possible events:
This option limits the triggers related to update events for Folder Subscription in order to reduce the effort on the Resource Notification Brokers considering only the most common update events on Folder objects. This limitation has been introduced because the Resource Notification Brokers that are not operating as native FHIR servers might not have the ability to notify for all Update events.
The Resource Notification Broker that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.4 Subscription with Folder Subscription for Minimal Update Option, and the related SubscriptionTopic, accepting this type of Subscription sent from a Resource Notification Subscriber.
The Resource Notification Subscriber that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.4 Subscription with Folder Subscription for Minimal Update Option.
The Resource Notification Publisher that declares support for this option SHALL also implement in the Resource Publish [ITI-111] transaction the trigger events defined in Section 2:3.111.4.1.1.4 Folder Subscription for Minimal Update Option Trigger Events and to communicate the stream of events to the Resource Notification Broker as defined in Section 2:3.111.4.1.2.4 Folder Subscription for Minimal Update Option Bundle.
This option allows subscriptions to Folder type List resources and extends the trigger events considered for a Folder Subscription.
This option includes the creation of a Folder type List Resource and all possible update events of a Folder type List Resource events. (The delete event of a Folder is not included.)
The Resource Notification Broker that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.5 Subscription with Folder Subscription for Update Option, and the related SubscriptionTopic, accepting this type of Subscription sent from a Resource Notification Subscriber.
The Resource Notification Subscriber that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.5 Subscription with Folder Subscription for Update Option.
The Resource Notification Publisher that declares support for this option SHALL also implement in the Resource Publish [ITI-111] transaction the trigger events defined in Section 2:3.111.4.1.1.5 Folder Subscription for Update option Trigger Events and to communicate the stream of events to the Resource Notification Broker as defined in Section 2:3.111.4.1.2.5 Folder Subscription for Update option Bundle.
This option allows subscriptions to Folder type List resources and extends the trigger events considered for a Folder Subscription.
This option includes as triggers all the possible events on a Folder resource. This option includes as triggers: the creation of a Folder type List Resource, all possible update events of a Folder type List resource and the delete event of a Folder type List resource.
The Resource Notification Broker that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.6 Subscription with Folder Subscription for Full Events Option, and the related SubscriptionTopic, accepting this type of Subscription sent from a Resource Notification Subscriber.
The Resource Notification Subscriber that declares support for this option SHALL implement the Subscription defined in Section 2:3.110.4.1.2.1.6 Subscription with Folder Subscription for Full Events Option.
The Resource Notification Publisher that declares support for this option SHALL also implement in the Resource Publish [ITI-111] transaction the trigger events defined in Section 2:3.111.4.1.1.6 Folder Subscription for Full Events Option Trigger Events and to communicate the stream of events to the Resource Notification Broker as defined in Section 2:3.111.4.1.2.6 Folder Subscription for Full Events Option Bundle.
This section covers a practical overview of the events on patient documents that are considered in this profile and the options that allow these events to be notified. Additionally, the transactions which link these events in the principal document sharing environment, Mobile Health Document Sharing and XDS.b.
Table 1:54.2.7-1 shows the events related to the DocumentReference and SubmissionSet type List resources. The “Basic implementation” is an implementations with actors that have not declared support for any option. Table 1:54.2.7-2 shows the events related to the Folder type List resources.
Table 1:54.2.7-1: Events and Options Overview for DocumentReference and SubmissionSet type List resources
Event | MHDS environment transaction | XDS environment transaction | Basic implementation | DocumentReference Subscription for Minimal Update Option | DocumentReference Subscription for Full Events Option |
---|---|---|---|---|---|
Creation of a new SubmissionSet (i.e., the creation of a SubmissionSet type List resource) | Provide Document Bundle [ITI-65] | Register Document Set-b [ITI-42] Register On-Demand Document Entry [ITI-61] |
X | ||
New document available (i.e., creation of a DocumentReference resource) | Provide Document Bundle [ITI-65] | Register Document Set-b [ITI-42] Register On-Demand Document Entry [ITI-61] |
X | X | X |
Update of the metadata status of a document (i.e., update of the DocumentReference status) | Provide Document Bundle [ITI-65] | Register Document Set-b [ITI-42] Register On-Demand Document Entry [ITI-61] Update Document Set [ITI-57] |
X | X | |
Delete of a document (i.e., delete of a DocumentReference resource) | Remove Metadata [ITI-62] | X | X | ||
Update of all the metadata of a document (i.e., update of the DocumentReference resource) | Provide Document Bundle [ITI-65] | Register Document Set-b [ITI-42] Register On-Demand Document Entry [ITI-61] Update Document Set [ITI-57] Restricted Update Document Set [ITI-92] |
X |
Table 1:54.2.7-2: Events and Options Overview for Folder type List resource
Event | MHDS environment transaction | XDS environment transaction | Basic Folder Subscription Option | Folder Subscription for Minimal Update Option | Folder Subscription for Update Option |
---|---|---|---|---|---|
Creation of a new Folder (i.e., the creation of a Folder type List resource) | Provide Document Bundle [ITI-65] | Register Document Set-b [ITI-42] Register On-Demand Document Entry [ITI-61] |
X | X | X |
Insert a new document in a Folder (i.e., update a Folder type List resource with a new DocumentReference link) | Provide Document Bundle [ITI-65] | Register Document Set-b [ITI-42] Update Document Set [ITI-57] Register On-Demand Document Entry [ITI-61] |
X | X | X |
Removal of a document from a Folder (i.e., update a Folder type List resource erasing a DocumentReference link) | Update Document Set [ITI-57] Remove Metadata [ITI-62] |
X | X | ||
Update of the metadata status of a Folder (i.e., update of the Folder type List status) | Provide Document Bundle [ITI-65] | Update Document Set [ITI-57] | X | X | |
Update of a Folder (i.e., the update of a Folder type List resource) | Provide Document Bundle [ITI-65] | Register Document Set-b [ITI-42] Update Document Set [ITI-57] Register On-Demand Document Entry [ITI-61] |
X |
This profile does not mandate grouping with other actors.
This section shows how the transactions and content modules of the profile are combined to address the use cases.
The DSUBm profile enables mobile subscriptions for patient documents. The subscription mechanism is very flexible and can be adapted to many use cases depending on the type of subscription used and the environment in which DSUBm is implemented, especially where that environment works for sharing these documents. Other IHE profiles, chiefly Cross-Enterprise Document Sharing (XDS.b) and Mobile access to Health Documents (MHD), describe sharing of patient documents, and many of the sharing document concepts used in this profile are explained there. Also, for more information on IHE Document Sharing, see the Health Information Exchange: Enabling Document Sharing Using IHE Profiles White Paper.
In the following use cases, different subscription types are presented. These subscriptions can be explicit for a specific patient (patient-dependent subscription) or can be expressed without a specific patient; hence, covering all patients (in this case they are referred as multi-patient subscriptions). The use cases cover both a fully mobile environment, for example MHDS implementations (see Mobile Health Document Sharing) and environments in which the main infrastructure is XDS.b. These use cases present also the possibility in which DSUB and DSUBm coexist and both are available to the users.
The availability of a document is notified to Hospital systems, where the main sharing infrastructure is based on MHDS.
Mr. Smith, a cardiac patient, is hospitalized in the cardiology ward at the Goodcare General Hospital. Dr. Roose, who is the only doctor working in this ward at that moment, prescribes some blood tests to decide which medicine is suitable for the patient. The medicine will be administrated by Nurse Davis only after Dr. Roose’s ePrescription.
In order to be notified when the laboratory report is ready, the software of Dr. Roose submits a subscription for all the laboratory reports that will be produced for Mr. Smith during his hospitalization. Meanwhile Nurse Davis, that works in the cardiology ward, is waiting to receive the notification of the ePrescription on her tablet, to know what medication has to be given to her patients in the cardiology ward.
When the laboratory has produced the report for Mr. Smith, Dr. Roose is promptly notified and, once he has examined the report, he can make an ePrescription for the correct medicine that is needed to be given to the patient. Once the ePrescription has been created a notification is sent to Nurse Davis’s tablet. After downloading the ePrescription, the nurse can give Mr. Smith the medication that Dr. Roose prescribed.
At the end of Mr. Smith’s hospitalization, Dr. Roose’s software automatically unsubscribes from the laboratory documents.
Pre-conditions:
The assumption is that systems share the information in an MHDS Environment. A Central Infrastructure is implemented in the environment where the MHDS Registry is grouped with the DSUBm Resource Notification Broker. The systems share and retrieve the documents by implementing an MHD Document Source and/or MHD Document Consumer.
Main Flow:
The update of a collection of documents (Folder), using a patient national Electronic Healthcare Record (EHR), notifies a mobile Diabetological Healthcare Record (DHR).
Dr. Rooney is taking care of Ms. Williams, a newly discovered type 2 diabetic patient. In order to start and adjust over time the therapy the doctor and the patient will perform a visit every month for the next 2 years. During the first visit, Dr. Rooney uses the mobile DHR application to create a Folder for the patient and makes a subscription to it on the National Electronic Healthcare Record (EHR) in order to be notified of any updates regarding Ms. Williams’s clinical data. After the visit, the patient is sent home with the standard therapy. Between the first and second visit, the patient is not feeling well and is admitted in the emergency department where some blood tests are performed and the acute symptoms are taken care of. When the blood tests are published on the EHR a notification is sent to the mobile DHR used by Dr. Rooney and the new update is retrieved. During the second visit, Dr. Rooney uses the latest clinical information and adjusts the therapy. A few days after the second visit Ms. Williams is admitted again into the emergency room. Other tests are performed and the medical report is updated in the EHR. A new notification is sent to the mobile DHR used by Dr. Rooney and the new update is retrieved. During the third visit, Ms. Williams decides that a different physician will take charge of her therapy. Therefore, Dr. Rooney closes the episode of care for Ms. Williams on his mobile DHR and the subscription to the EHR is deleted.
Pre-conditions:
The assumption is that systems share the information in an MHDS Environment. The national EHR of a patient has been maintained thanks to the implementation of an MHDS Registry and it is grouped by the DSUBm Resource Notification Broker. The systems share and retrieve the documents by implementing MHD Document Source and/or MHD Document Consumer. The Resource Notification Subscriber has implemented the Resource Subscription Search [ITI-113] transaction. The Resource Notification Subscriber and the Resource Notification Broker support the Folder Subscription for Minimal Update Option.
Main Flow:
The availability of a specific document for a Patient shared in an XDS on FHIR infrastructure is sent to his personal mobile device.
Mr. Brown went to see his doctor. During the examination, the doctor considered it important to check the blood test results before making a medication prescription. Meanwhile, Mr. Brown is sent home because he has already submitted a subscription in order to receive a notification on his mobile app when the prescription is ready.
When the doctor was notified that the blood test results were ready, he retrieved them and, after checking them, the doctor prescribed the medication to Mr. Brown. Mr. Brown receives a notification on his phone when the prescription is ready (created). From the app, he can now retrieve the prescription required to purchase the medication in the local pharmacy.
Pre-conditions: The assumption is that systems share the information in an XDS on FHIR Environment. In the central infrastructure, the XDS Registry is grouped with the DSUBm Resource Notification Publisher. The system shares and retrieves the documents by implementing an MHD Document Source and/or MHD Document Consumer thanks to an MHD interface on XDS (see the XDS on FHIR Option of the MHD Profile). Since the Mobile Device is interested in only the creation of DocumentReference resources, no additional option is supported by the DSUBm actors.
Main Flow:
The availability of documents for a Patient is sent to a mobile device.
Mr. Wayne has a prescription for a radiographic exam and he needs to book a Radiology Appointment. With a phone call to the local hospital, an appointment is proposed and Mr. Wayne accepts the slot. After some minutes, the radiology booking system produces a document for the booking reservation. Since Mr. Wayne is a user of the booking mobile app, a subscription has been already made to the Central Infrastructure in order to receive a notification when the booking reservation is produced. When the notification arrives on Mr. Wayne’s mobile device, he can consult the information regarding his appointment.
Pre-conditions:
The assumption is that systems share the information in an XDS on FHIR Environment. In the central infrastructure, the XDS Registry is grouped with the DSUB Document Metadata Publisher/Document Metadata Broker. The DSUBm extends the DSUB subscription to mobile systems grouping the Resource Notification Broker with the DSUB Document Metadata Subscriber and DSUB Document Metadata Recipient. The systems share and retrieve the documents by implementing the MHD Document Source and/or MHD Document Consumer thanks to an MHD interface on XDS (see XDS on FHIR Option of MHD Profile).
Main Flow:
The availability of a specific document is notified in a Mobile Alert System with a multi-patient subscription.
Dr. Gordon is a new medic hired by the geriatric ward of the Goodcare General Hospital. In this facility, there is a Mobile Alert System in order to mitigate the spreading of highly contagious diseases. In order to do this, each employee has an app on his personal mobile device that is connected to the mobile Alert System. When a highly contagious disease is reported inside the geriatric ward, an alert is spread to follow immediately the specific quarantine protocol expected for the reported disease.
Pre-conditions:
The assumption is that systems share the information in an XDS on FHIR Environment. In the central infrastructure, the XDS Registry is grouped with the DSUB Document Metadata Publisher. The Notification Manager System manages both mobile and non-mobile subscriptions, grouping DSUB Document Metadata Broker with the Resource Notification Broker. The systems share and retrieve the documents by implementing MHD Document Source and/or MHD Document Consumer thanks to an MHD interface on XDS (see XDS on FHIR Option of MHD Profile).
Main Flow:
The availability of a new document containing an error in the metadata is sent to a personal mobile device. The author of the document deprecates the document and a new notification is sent to communicate the update.
Mr. Adam uses an app on his phone to consult his diagnostic reports emitted after doctor visits or diagnostics exams during his hospitalization. After one radiographic exam a report has been produced. Due to a human error, this report contains some errors and is sent to Mr. Adam’s phone. When Mr. Adam looks at the information related to this document he understands that an error has occurred. After a couple seconds Mr. Adam receives a second notification generated by the update of the metadata of the document that was previously submitted. Mr. Adam understands that it was a mistake made by the doctor and now the document has been deprecated so there is no need to ask the hospital for more information regarding the first notification.
Pre-conditions:
The assumption is that systems share the information in an XDS on FHIR Environment. In the central infrastructure, the XDS Registry is grouped with the Resource Notification Publisher/Resource Notification Broker. The system shares and retrieves the documents by implementing an MHD Document Source and/or MHD Document Consumer thanks to an MHD interface on XDS (see the XDS on FHIR Option of the MHD Profile). The Resource Notification Broker, Resource Notification Publisher and Resource Notification Subscriber are supporting the DocumentReference Subscription for Minimal Update Option.
Main Flow:
The availability of an updated metadata document (shared in an XDS on FHIR infrastructure) for a Patient is notified to a personal mobile device.
Ms. Fox uses an app on her phone to consult her diagnostic reports, emitted after doctor visits or diagnostics exams. After one radiographic exam, a report has been produced but the doctor that produced the report wants to have a consultation with a specialist before letting it be visible to the patient. So that, after the consultation of the report by the specialist and sure that there are no further issues, the report is visible to the patient. Thus, Ms. Fox receives the notification on her app and consults the reports.
Pre-conditions:
The assumption is that systems share the information in an XDS on FHIR Environment. In the central infrastructure, the XDS Registry is grouped with the Resource Notification Publisher/Resource Notification Broker. The system shares and retrieves the documents by implementing MHD Document Source and/or MHD Document Consumer thanks to an MHD interface on XDS (see the XDS on FHIR Option of the MHD Profile). The Resource Notification Broker, Resource Notification Publisher and Resource Notification Subscriber are supporting the DocumentReference Subscription for Full Events Option.
Main Flow:
In this use case, a system desires to subscribe to a submissionSet with a specific intended recipient of clinical information. A source of clinical content can identify the intended target for a submissionSet using the XDSSubmissionSet.IntendedRecipient
metadata attribute.
Dr. Brown is a clinician and can request exams for many patients. He works in multiple hospital and due to his obligations he is not always connected and available to review the documents that are produced from other hospitals. So the doctor uses a mobile app in order to get notifications for documents produced from other hospital that are intended for him (the subscription created has the intendedRecipient as Subscription criteria). Mr. White attends a consultation with Dr. Brown, who requests a Laboratory Report for the patient. The app that the doctor is using creates a mobile subscription with an intendedRecipient of Dr. Brown. This mobile subscription is replicated by a middleware (DSUB/FHIR interface) in order to intercept XDS documents with the same filter criteria of the mobile subscription created by the app. The patient receives the exam in a Clinical Laboratory. The Laboratory Information System produces a report and submits the document in the Document Sharing Infrastructure identifying Dr. Brown as the intended Recipient for the submission. This publishing event matches the existing subscription performed by the middleware and a notification is sent to the middleware. The middleware converts the notification in a mobile notification that is sent to Dr. Brown’s mobile system (identified as the Resource Notification Recipient in the mobile subscription created). Dr. Brown, after seeing the notification on his app, can access the EMR system, retrieve the laboratory report, quickly analyze the report published, and make other clinical decisions in an efficient way.
Pre-conditions:
The assumption is that systems share the information in an XDS Environment where a DSUB and DSUBm are used a the same time. In the central infrastructure, the XDS Registry is grouped with an XDS document Repository and the Document Notification Publisher. The DSUB Document Metadata Subscriber and the DSUB Document Metadata Recipient are grouped with a DSUBm Resource Notification Broker.
Main Flow:
This profile requires actors to audit the transactions that create subscriptions and send notifications, grouping with an ATNA Secure Node or Secure Application is strongly RECOMMENDED in order to track the subscriptions and the notification sent. For further considerations about Audit record refer to BALP Profile. User authentication/authorization represents another important factor to consider in order to avoid malicious creation/updating of subscriptions. Grouping DSUBm actors with actors in the Internet User Authorization (IUA) Profile enables deployments to mitigate these security issues. See ITI TF-2x: Appendix Z.8 “Mobile Security Considerations”.
The reader SHOULD also consider the information included in Safety and Security section of the Subscription Backport IG.
The DSUBm actor and transaction model is very flexible. Integration with other IHE profiles is possible and highly RECOMMENDED in order to utilize the subscription/notification mobile feature in different types of environments. In this section, some information about possible cross-profile interaction is presented.
Within a RESTfull infrastructure that is implementing the MHDS model there are two possible groupings.
In the first proposed grouping:
In the second proposed grouping:
Within an XDS infrastructure there are two possible groupings.
In the first proposed grouping:
If in the infrastructure is also implemented the “XDS on FHIR Option” of MHD for a mobile interface:
Note that in this scenario, developers SHOULD be aware about what events on DocumentEntry, Folder, Association, and SubmissionSet Objects could determine events on DocumentReference, Folder type List, and SubmissionSet type List resources and the supporting of “Updates to document sharing resources” Option.
In the second proposed grouping:
Note that in this scenario, developers SHOULD be aware about what events on DocumentEntry, Folder, Association, and SubmissionSet Objects could determine events on DocumentReference, Folder type List, and SubmissionSet type List resources and the supporting of “Updates to document sharing resources” Option.
Document Metadata Subscriber and the Document Metadata Notification Recipient will most likely be grouped with a Resource Notification Broker creating the mobile DSUB interface that translates Resource Subscription [ITI-110] into Document Metadata Subscribe [ITI-52] and Document Metadata Notify [ITI-53] into Resource Notify [ITI-112]. The existing DSUB Document Metadata Notification Broker is unaware of the presence of the functionality introduced by the DSUBm Profile and therefore can maintain its already implemented logic.
Note that in this scenario, developers SHOULD be aware about the usage of status
parameter in the Subscriptions and about implementation of DSUB supplement Folder Subscription Option and Patient-Independent Subscription Option.