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
Significant Changes From Previous Public Comment Version:
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).
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:
$events
operation.DECISION: based on discussions and survey on FHIR version, decided to switch to R4 version.
DECISION: switched from R4B to R4 and proceeded to profile AuditEvent.
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:
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.