Document Subscription for Mobile profile describes the use of document subscription and notification mechanisms for RESTful applications.
Home Page: https://profiles.ihe.net/ITI/DSUBm/index.html
License: Creative Commons Attribution 4.0 International
Section Number
2:3.114 Resource SubscriptionTopic Search [ITI-114]
Issue
Given my recommendation to move to FHIR R4 (see issue #65), this section would need to be updated to cover Basic resources that use cross-version extensions to represent a SubscriptionTopic.
Proposed Change
Either expand this section to cover both options (using either R4B+ with SubscriptionTopic and R4 with Basic) or add another section covering Basic resource usage.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
1:54.4.2.6
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
Use Case #6 shows use of the Updates to document sharing resources option, but the use case is a problematic demonstration of that option.
In Use Case #6, the document is not visible to the subscriber when it is created due to policy. Later, the document confidentiality code is updated, which allows the document to be visible to the subscriber and an update notification is sent.
I don't think this is a good example of the Updates to document sharing resources option, since in this case, from the perspective of the subscriber, the document has been "created" when it was updated. And I think the Resource Notification Broker should be allowed to treat it as such (meaning a create notification would be sent even when the option is not implemented)
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Revise Use Case #6 to present a case where the Resource Notification Recipient needs to learn of an update to a DocumentReference Resource that they are already aware of.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.110.11
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
I am not sure what the following text means:
"The Resource Notification Broker might maintain a whitelist of acceptable senders for the rest-create/rest-update methods. "
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Please rephrase and/or clarify.
Priority:
Section Number
2:3.11x.3 Referenced Standards
Issue
FHIR R4B is not widely implemented and I do not expect to see that change.
Proposed Change
Backport IG STU 1.2 (currently in ballot) and tooling improvements brought functional parity for FHIR R4 and R4B in subscriptions. I recommend moving DSUBm to FHIR R4 for wider compatibility.
Note that STU 1.2 also adds functionality for "Notified Pull".
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.110.8.4
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
SubscriptionTopics are provided that allow the subscriber to subscribe to SubmissionSets. However, I don't see anything in the use cases to suggest this functionality is needed.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
If there is a use case for subscribing to SubmissionSets, include one in the use cases section. If not, then remove the SubmissionSet topics.
Priority:
If the following resource are directly used (with dependency) from MHD profiles:
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)
(see comparison Domain resource from R4 and R4B).
The TEMPORARY SOLUTION for now is to replicate some MHD content that is used in DSUBm in R4B. (files in folder "DSUBm_DocumentRelatedResources")
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.113.5
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
ITI-113 lists a set of "allowed" search parameters. It does not say if they are required to be supported by the Resource Notification Broker.
I think it would be more useful to specify the list of search parameters the Resource Notification Broker is required to support, where that list contains only the parameters we expect clients to need. I think readers will know that the parameters defined in FHIR are optionally available beyond what is required.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Define a set of required search parameters for the Subscription search. I propose
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
26.2.2
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The IG adds an option to DSUB to use the ITI-113 transaction, but it is not clear how the DSUB actors would use such a transaction.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Clarify the transaction interaction expectations for DSUB actors implementing ITI-113.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.112.6.3
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The text says:
"If the Resource Notification Broker has been able to send the Handshake Notification Message but it has not received any Hearthbeat Notification Message from the Resource Notification Recipient, it should deactivate the Subscription, setting the Subscription.status=error."
Based on text in FHIR R5 and the backport IG, it seems the intent is that a deactivated subscription has a status of off, while error simply means there was at least one error.
From the subscription-status code system:
| error | Error | The server has an error executing the notification. |
|---|---|---|
| off | Off | Too many errors have occurred or the subscription has expired. |
From the Handling Errors section of the backport IG
"A server MAY:
Continue to send heartbeat messages (with an error status set)."
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Clarify when the status should be error vs off and the Notification Broker's expected actions for each state.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
1:54.2.1
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
Right now, when the Updates to document sharing resources option is not implemented, only Create events generate notifications. When that option is implemented, then all create, update, and delete events shall be reported.
Resource Notification Brokers that are not operating as native FHIR servers might not have the ability to notify for all Updates. However, I think the most common updates that a Resource Notification Recipient will be interested in are changes to the status element of the subject resource. So, it would be useful to have an option where only the following events need to be reported on:
Create
Update of status only
Delete
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Create an option that allows Resource Notification Brokers to notify on resource Create and Delete, and updates to the .status element only.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.110.5.3
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The section states that the Resource Notification Broker shall verify that "all requested filters are defined in the requested topic and are implemented in the Resource Notification Broker"
Must the Resource Notification Broker implement all of the filters defined in this IG? Or is it allowed to support only some of them?
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Clarify the expectations of which filter parameters are supported by the Resource Notification Broker.
Priority:
(see DSUBm_003 in issues.html)
The DUSBm profile proposed a changes to the DSUB profile in order to extend DSUB with a RESTfull search functionality of the subscriptions. It is present here the proposed changes. Is this functionality something useful to extend DSUB or the proposed change is too challenging?
Attached are the PDFs with my review comments.
Priority: medium/low
202311 - 2:3.113 Resource Subscription Search [ITI-113] - Document Subscription for Mobile (DSUBm) v1.0.0-bal.pdf
202311 - 2:3.114 Resource SubscriptionTopic Search [ITI-114] - Document Subscription for Mobile (DSUBm) v1.0..pdf
202311 - Artifacts Summary - Document Subscription for Mobile (DSUBm) v1.0.0-ballot.pdf
202311 - DSUBm Home - Document Subscription for Mobile (DSUBm) v1.0.0-ballot.pdf
202311 - 1:54 Document Subscription for Mobile (DSUBm) - Document Subscription for Mobile (DSUBm) v1.0.0-ball.pdf
202311 - 2:3.110 Resource Subscription [ITI-110] - Document Subscription for Mobile (DSUBm) v1.0.0-ballot.pdf
202311 - 2:3.112 Resource Notify [ITI-112] - Document Subscription for Mobile (DSUBm) v1.0.0-ballot.pdf
For sanity, I am collecting all of my editorial and linguistic comments into a single issue. Section numbers are shown for each instance individually below. I believe most of these are Low or Medium priority, as they are not substantive.
2:3.112.4 Interactions and 2:3.113.4 Interactions contain links to all the messages. For consistency, I would recommend either adding links to 110.4, 111.4, and 114.4 or removing them from 112.4 and 113.3.code elements.code elements.Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.114.5.2
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The Description of the status search parameter says: "Should be valued with active"
Is this trying to say that the Resource Notification Subscriber must supply the status parameter with the value of "active"? This seems unnecessarily restrictive.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Allow the Resource Notification Subscriber to specify the status parameter as needed.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
1:54.4.1 Concepts
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
patient-independent is mentioned here, but was removed from a lower section.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Update this to match what was done to replace patient-independent in other sections and search for any other usage in the profile.
Priority:
Low
Should there be some management of SubscriptionTopics as outlined in R4B/R5? I'm not sure the R4B implementation has everything needed so maybe this needs to wait until an R5 update, but it seems worth a discussion.
(See the complete example DSUBm_007 in DSUBm issues)
The DSUBm profile propose notifications in a push mechanism. The Extensions to the Document Metadata Subscription (DSUB)
profile also include a pull modality for the notification. Should also the DSUBm profile 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.
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
1:54.4.2
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
Use Case #1 describes two subscriptions for very different purposes. These seem like separate use cases.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Split Use Case #1 into two use cases.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
3.110, 3.112, 3.113
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The response messages should be right after the request message when there are multiple messages for the transaction instead of all the requests followed by all the responses.
Proposed Change
Place the response sections directly after the request sections
Priority:
The section heading levels are wrong. (For example 2:3.110.5 should be 2:3.110.4.1 and then everything underneath needs to be updated, too. This is true for all the transaction pages).
I then realized that my changes broke any internal references to the section numbers (because I changed them).
I reverted the 2 files I updated (ITI-110 and ITI-11) back to the original content. I think for public comment we should leave then as is and I can submit comments about this during the public comment period.
Mary
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
SubscriptionTopic Artifacts
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The Notification Shapes for the subscription topics all specify Includes of :patient&iterate=Patient.link. I think including the Patient in the notification is unnecessary. In many cases, the Notification Recipient might already have the patient's identifier or FHIR ID cached, so it does not need the Patient Resource. If it does, it can always do a FHIR read to get the Patient.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Do not include the "includes" in the SubscriptionTopic instances.
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
Subscription Profiles
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
When the channel type is rest-hook, Subscription.endpoint is needed so that the Resource Notification Broker can send notifications to the Resource Notification Recipient. However, the Subscription Profiles in the IG have channel.type=rest-hook but endpoint is 0..1.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Update the profiles to make endpoint 1..1
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
1:54.6
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The descriptions of how to group cross profile actors don't align with the diagrams.
For Figure 1:54.6.1-1, you say:
"MHDS Document Registry will most likely be grouped with a Resource Notification Publisher because all publication events are submitted to the MHDS Document Registry.
MHDS Document Registry will likely be grouped with a Resource Notification Broker."
These are two alternatives, but the diagram only shows the MHD Document Responder and the DSUBm Resource Notification Publisher as being grouped.
You also say:
"The MHD Document Consumer will most likely be grouped with a Resource Notification Recipient. This grouping makes sense since the receiver of the notification is most likely the user of the information.
The MHD Document Consumer, will likely be grouped with a Resource Notification Subscriber."
But the MHD Document Consumer is only shown grouped with the DSUBm Resource Notification Recipient. I think the DSUBm Resource Notification Subscriber should also be included in that grouping.
Figure 1:54.6.2-1 is similarly affected.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Create alternative diagrams to show common groupings, and ensure diagrams match the suggestions in the text.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
1:54.4.2.2.2
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
This use case shows the ITI-68 transaction happening between the MHD Document Consumer and the MHD Document Source. However, the MHD Document Source does not participate in the ITI-68 transaction.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
The transaction should be between the MHD Document Consumer and the MHDS Document Registry.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
1:54.5 Security Considerations
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The security considerations should discuss any further security needs when the full resource is part of the subscription/notification to the recipient. All of the use cases show the recipient queries for the document which implies that server does have access to retriever it, but if it is sent as part of the subscription notification, no such access check occurs.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Priority:
Medium
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
3.112
Issue
Should the transaction be based off a FHIR Create interaction? You mention the URL format that should be used, but for create that would be POST to BASE/Bundle which may not be the case since this is a notification to the Subscription endpoint. Also I don't think the recipient should process it as a create since it doesn't need to create the Bundle, it just processes the notification.
Proposed Change
Don't base the notifications on FHIR create.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.112.8
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The Subscription Deactivation Notification Message does not seem to be aligned with the Subscriptions Framework, and it is not clear why we need this message.
If the concern is that the client does not know when a subscription is deactivated due to an error state, well it seems unlikely the client will be in a position to receive the deactivation message in that case anyway.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Remove the Subscription Deactivation Notification Message.
Priority:
(see DSUBm_005 issues.html)
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 puntually 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?
Section Number
All sections.
Issue
BCP 14 indicates that "only UPPERCASE usage of the key words have the defined special meanings." I see many instances of lowercase conformance language (e.g., shall) and no instances of uppercase. Is the intention that none of these are actually conformance language, or are they missing the correct casing?
Proposed Change
Reviewing all instances of conformance language to set correct casing.
Priority:
I believe this is High, as it sets conformance expectations.
Attached are the PDFs with my review comments.
SubscriptionTopic for DocumentReference Patient-Dependent resource with DocumentReference Subscripti.pdf
SubscriptionTopic for DocumentReference Multi-Patient resource with DocumentReference Subscription f.pdf
2:3.113 Resource Subscription Search [ITI-113] - Document Subscription for Mobile (DSUBm) v1.0.0-com.pdf
Document Subscription for Mobile (DSUBm) Home - Document Subscription for Mobile (DSUBm) v1.0.0-comm.pdf
DSUBm Resource Notification Broker Actor - Document Subscription for Mobile (DSUBm) v1.0.0-comment.pdf
DSUBm Resource Notification Subscriber Actor - Document Subscription for Mobile (DSUBm) v1.0.0-comme.pdf
1:54 Document Subscription for Mobile (DSUBm) - Document Subscription for Mobile (DSUBm) v1.0.0-comm.pdf
2:3.110 Resource Subscription [ITI-110] - Document Subscription for Mobile (DSUBm) v1.0.0-comment.pdf
2:3.112 Resource Notify [ITI-112] - Document Subscription for Mobile (DSUBm) v1.0.0-comment.pdf
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.110.6
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The section states:
"This message uses the HTTP PUT method on the target Resource Notification Broker endpoint to update an existing Subscription resource in order to deactivate it and unsubscribe."
However, I think this message is also needed to re-activate a subscription that has been deactivated due to errors.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Allow using the Update Subscription message to re-activate errored subscriptions.
Priority:
(see DSUBm_002 in issues.html)
The AuditEvents for each transaction are not yet profiled bacause the IG publisher, at the moment, does not allow to further constrain a Profile coming from a different FHIR version of the IG.
(see DSUBm_001 in issues.html)
This Profile define a Subscriptione 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?
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.110.8.3
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
identifier is listed as a criteria parameter for the Patient-Dependent Folder Subscription Topic. I'm not sure that makes sense as a filter parameter, since I wouldn't expect multiple Folders to be created with the same identifier.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Remove identifier from the list of criteria parameters.
Priority:
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.110.8
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
Each subscription topic in ITI-110 lists the filter parameters and defines them. The definitions appear to be copied from MHD. Would it be better to simply list the parameters and simply link to MHD for the definitions? Doing so would ensure the definitions are always the same between the two profiles.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Link to MHD for the filter parameter definitions rather than duplicating them in DSUBm
Priority:
(see DSUBm_004 in issues.html)
For the Resource Notify [ITI-112] transaction the DSUBm profiles 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?
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
1:54.2 and 1:54.3
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The tables here need a table number and caption. The first sentence in 54.2 refers to table 3.2-1. The SubscriptionTopic Search option isn't in the table.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Add Table 1:54.2-1: Actor Options and Table 1:54.3-1: Required Actor Groups above the tables.
Update the first sentence in 1:54.2 to be:
Options that may be selected for each actor in this implementation guide, are listed in Table 1:54.2-1 below
Add SubscriptionTopic Search to the options table.
Priority:
Low
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
2:3.114.5.3
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
Right now, it is required for the Resource Notification Broker to support the Patient-Dependent Folder SubscriptionTopic. Resource Notification Brokers might not support Folder objects, so support for this topic should be optional.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Make an option for support of the Patient-Dependent Folder SubscriptionTopic.
Priority:
Attached are 2 PDFs with my review comments.
Priority: medium/low
20230726RQIHE.ITI.DSUBM Volume 1 - FHIR v4.0.pdf
20230727RQ-IHE.ITI.DSUBM-2-3.114 Resource SubscriptionTopic Search - FHIR v4.0.pdf
Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
DSUBm Home
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The first two paragraphs of the DSUBm Home page say that IHE does not provide a common framework for subscribing to document sharing artifacts. However, that is the purpose of this IG, so IHE does do that with this IG.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
I think the first two paragraphs can simply be removed.
Priority:
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.