Document Subscription for Mobile (DSUBm), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 1.0.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.DSUBm/ and changes regularly. See the Directory of published versions

Significant Changes and Issues

Significant Changes

Significant Changes From Previous Public Comment Version:

• Passed from R4B to R4 version of FHIR
• Profiling the SubscriptionTopic as Basic resource
• Profiling the SubscriptionStatus as Parameter resource
• Eliminated the duplication of MHD artifacts
• Profiled AuditEvent for the transactions
• Closed some Open Issues

Issues

Submit an Issue

IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues can be submitted to the Public Comment form.

As issues are submitted they will be managed at DSUBm GitHub Issues, where discussion and workarounds can be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later).

Open Issues

• DSUBm_003: The DUSBm Profile proposed changes to the DSUB Profile in order to extend DSUB with a RESTfull search functionality of the subscriptions. See here for the proposed changes. Is this functionality something useful to extend DSUB or are the proposed changes too challenging?

• DSUBm_005: The Resource Subscription Search [ITI-113] define the $events operation that permits to retrieve from the Resource Notification Broker the events associated to a Subscription. This operation could be use to retrieve punctually the missed event when, for example, a connection problem occur and the Resource Notification Recipient does note receive the notification. But, this operation requires the Resource Notification Broker to be capable of maintain previous events associated with the Subscriptions. Should the supporting of this operation be required for the Resource Notification Broker or should be maintain optional?

• DSUBm_007: The DSUBm Profile proposes notifications in a push mechanism. The Extensions to the Document Metadata Subscription (DSUB) Profile also include a pull modality for the notification. Should the DSUBm Profile also include a Pull Notification mechanism or is it sufficient to search (e.g., using Find Document Lists [ITI-66] or Find Document References [ITI-67] transactions) on the resources combining query parameters and proper interval of time? At the moment no specific request have been already submitted for this implementation. If the pull notification is needed and a real use case is provided, it is possible to send change proposal during the public comment period. We propose here a possible way to utilize a pure Pull Notification modality using the $events operation of the Resource Subscription Search [ITI-113] transaction. A possible use case is represented below:

  Ms. Smith is a doctor that, during the patient visit, uses a mobile app in order to see the exam reports produced for the current patient. When the doctor switches the context to the current patient, the app retrieves the notification regarding the new documents that were produced since the last time the app was used for that specific patient. During the first visit, Dr. Smith subscribes for documents produced for Mr. Jones. Before the second visit, some medical reports has been produced for Mr. Jones. When Mr. Jones shows up for the second visit, the app, used by Dr. Smith, will retrieve the notifications that were produced between the end of the last visit for Mr. Jones and the start of the current visit. Dr. Smith, based on the notifications retrieved by the app, will retrieve only some of the documents.

  Document Subscription with Pull Notification for Mobile Device in MHDS Environment Process Flow

  
  

  Pre-conditions:

  The assumption is that the visit app is working in a MHDS Environment. In the central infrastructure, the MHDS Registry is grouped by the Resource Notification Publisher and Resource Notification Broker. The Resource Notification Broker is supporting the Pull notification and is grouped with a Resource Notification Recipient.

  Main Flow:

  1. The visit app during the first visit performs a patient-dependent subscription in order to subscribe for the documents produced for the new patient ([ITI-110] Resource Subscription). In the subscription a local endpoint is indicated in order to explicit that the notification are going to be retrieved with pull modality.
  2. After the first visit a medical report has been produced ([ITI-65] Provide Document Bundle).
  3. The Resource Notification Publisher deliver a publication event to the Resource Notification Broker([ITI-111] Resource Publish).
  4. The Resource Notification Broker seeing that the publication event is matching the criteria subscription expressed in the first step, and, recognizing that a local endpoint has been used in the subscription produce a notification towards the grouped Resource Notification Recipient ([ITI-112] Resource Notify).
  5. At the start of the second visit, when Dr.smith choose Mr. Jones on the Visit app the app will retrieve any notification produced and stashed in the Broker([ITI-113] Resource Subscription Search) using the $events operation.
  6. The Visit App will retrieve the Document described in the notification. ([ITI-68] Retrieve Document).

Closed Issues

• DSUBm_001: This profile defines a Subscription framework using R4B version of FHIR, in order to improve the subscription functional from the R4 version. Are there any compelling arguments to use R4 version of FHIR?

DECISION: based on discussions and survey on FHIR version, decided to switch to R4 version.

• DSUBm_002: The AuditEvents for each transaction are not yet profiled because the IG publisher, at the moment, does not allow to further constrain a profile coming from a different FHIR version of the IG.

DECISION: switched from R4B to R4 and proceeded to profile AuditEvent.

• DSUBm_004: For the Resource Notify [ITI-112] transaction, DSUBm defines the expected action for the Resource Notification Broker in order to define a common way to manage errors and connection problems that may occur for all the different type of notifications. Considering the various infrastructure capabilities with which the subscription framework could be implemented, should the expected action be revised? Is it appropriate to define the number of attempts after the first error for the Heartbeat Notification Message and the Event Notification Message? Are there other points to focus on?

DECISION: based on discussions and comments on GitHub, decided that it is not necessary to specify further considerations.

• DSUBm_006: If the following resources are directly used (with dependency) from MHD Profile:

  • Minimal DocumentReference
  • Minimal SubmissionSet
  • Minimal Folder

  there are the following errors in the QA report :

    - The reference http://hl7.org/fhir/ValueSet/identifier-use|4.0.1 could not be resolved
    - The reference http://hl7.org/fhir/ValueSet/list-status|4.0.1 could not be resolved
    - The reference http://hl7.org/fhir/ValueSet/list-mode|4.0.1 could not be resolved
    - The reference http://hl7.org/fhir/ValueSet/c80-doc-typecodes could not be resolved
    - The reference http://hl7.org/fhir/ValueSet/document-classcodes could not be resolved
    - The reference http://hl7.org/fhir/ValueSet/document-relationship-type|4.0.1 could not be resolved
    - The constraint 'dom-3' has an expression 'contained.where((('#'+id in (%resource.descendants().reference | %resource.descendants().as(canonical) | %resource.descendants().as(uri) | %resource.descendants().as(url))) or descendants().where(reference = '#').exists() or descendants().where(as(canonical) = '#').exists() or descendants().where(as(canonical) = '#').exists()).not()).trace('unmatched', id).empty()', which differs from the earlier expression provided of 'contained.where(((id.exists() and ('#'+id in (%resource.descendants().reference | %resource.descendants().as(canonical) | %resource.descendants().as(uri) | %resource.descendants().as(url)))) or descendants().where(reference = '#').exists() or descendants().where(as(canonical) = '#').exists() or descendants().where(as(uri) = '#').exists()).not()).trace('unmatched', id).empty()' (invariants are allowed to repeat, but cannot differ)
  

  The TEMPORARY SOLUTION for now is to replicate some MHD content that is used in DSUBm in R4B. (files in folder “DSUBm_DocumentRelatedResources”)

DECISION: switched from R4B to R4, not needed anymore.