Section Number https://profiles.ihe.net/ITI/MHD/ITI-65.html#message-semantics and elsewhere

Issue "Refer to ITI TF-3: 4.5.1 for details on the FHIR Resources and how Document Sharing metadata attributes are mapped." There is no link for the 4.5.1 reference, and it doesn't exist here. In https://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html#comprehensive-metadata-option, you have the same reference to ITI TF-3: 4.5.1, and the hyperlink goes to here https://profiles.ihe.net/ITI/MHD/metadata_maps.html, which is "Section 9".

Proposed Change I don't know the right answer, but I don't think that ITI TF-3: 4.5.1 has any meaning in this IG.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number 11.4.1.3

Issue There is a need for a minimal processing model to be defined for Submission Set List.extension:intendedRecipient. This need has been identified while working on the work item MHD to a Federation. In addition, there isn't a clear error or warning code that could be returned in the case a recipient was unknown or could not be reached, as there is for communities.

Proposed Change Define codes UnknownRecipient and UnreachableRecipient (may need to add these to Vol 3 for XDR to use as well, in which case just point to them). Define processing model like the following:

• If intendedRecipient is specified, the Document Recipient SHALL make reasonable efforts to determine whether each recipient can be notified. If not possible, the Document Recipient MAY do any of the following:
  • Fail the transaction with the code UnknownRecipient or UnreachableRecipient
  • Accept the transaction with the code UnknownRecipient or UnreachableRecipient as a warning
  • Succeed silently

Priority: Medium

Section Number https://profiles.ihe.net/ITI/MHD/ITI-65.html#expected-actions

Issue In XDS, a Registry shall support replace, transform, append and folders, but these are optional for the Source. In ITI-65, you have specifies warning or error messages for a Doc Recipient that does not support these, but I think those warnings could only be returned by a Doc Recipient w/ no options (ie minimal metadata). A Doc Recipient that supports XDS on FHIR option certainly should not return those errors. I'm not sure about a Recip that only supports the Comprehensive Metadata option

Proposed Change If the above is true, we need to say that.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number 11.4.1.2

Issue In XDS, Document Entries may only be added to Folders, not removed. Because the association is a separate object, each FD-DE association is immutable, even after the DE is deprecated. However, in FHIR the List resource allows items to be added or removed from it.

Proposed Change We should consider constraining Folder List.entry.item in MHD to be "add only" to match the XDS semantics, and allow the MHD Document Recipient to ignore removals without error. This would have the added benefit of reducing the impact of resource contention in competing updates to Lists without needing to support versioning and If-Match, which is problematic (see here).

Priority: Medium

Section Numberhttps://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html#actors

Issue A profile/actor with no options has different requirements than a profile/actor that supports an option, so I find "Document Source with no options or all options" to be a confusing term

Proposed Change Use "Actor X with no options", which implies the baseline requirements to be compliant with the profile for that actor

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to

This is not formally MHD_065, but that is the next number.. and it was mentioned in the readme, so it is somewhat an open issue (sorry).

Is it needed to have a mapping between XDS RegistryError and FHIR OperationOutcome? add to mappings page a mapping between XDS RegistryError and FHIR OperationOutcome. At the element level, and also addressing OperationOutcome.issue.code vocabulary could be mapped to the XDS error vocabulary. between XDS https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html#4.2.4.1 and FHIR OperationOutcome.

Section Number https://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html

Issue

1. In 3.1.x, would like to understand the rationale for itemizing the options under each actor when this information exists more succinctly in the very next section.
2. You have included the actor definition here. Will IG's deviate from IHE's effort to harmonize actor definitions in the General Introduction?
3. We have lost Vol 1 Sec 33.1.1 Actor Descriptions and Actor Profile Requirements

Proposed Change *

1. Eliminate the " implementing " text
   1a if you keep it, then make it accurate (the Document Responder has an option)
   1b. If you keep it, get rid of < actor> with no options or all options. I don't l know what that means
2. Link to the actor definition in the common appendix, rather than duplicating (or changing) the definition here.
   2b. If you do this, do the same with Transaction Descriptions in https://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html#transaction-descriptions
3. Remove the existing contents of https://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html#actors and replace it with "Actor Descriptions and Actor Profile Requirements. This section was added to the Supplement Template because we often have a need to specify actor requirements that are not transaction or option-related

Priority: Medium

Section Number
https://profiles.ihe.net/ITI/MHD/qa.html

Issue
MHD is dependent on the terminology defined in ihe.formatcode.fhir#current. current is the last built version on the ci-build. the dependency should be probably fixed to the last published version 0.2.4?

https://profiles.ihe.net/fhir/ihe.formatcode.fhir/history.html

Proposed Change
Add dependency to latest published version, maybe with an X that updated patched versions will be considered: 0.2.x

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number
https://profiles.ihe.net/ITI/MHD/List-593cd04e-b696-45c1-bc32-39e55a340a45.json.html

Issue
entry.item.reference points to the example list instance itself (593cd04e-b696-45c1-bc32-39e55a340a46), should this not be to a DocumentReference?

Proposed Change *
Fix example

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number 15.12.6.3, 15.4.6.3, 11.4.1.3

Issue There are two issues with Folder List.status when grouping MHD with XDS/XDR/XCDR: 1. The mappings to XDS in section 15.12.6.3 and 15.4.6.3 do not map the value "current" to "Approved" 2. XDS Submission Sets and Folders are not allowed to be deprecated. What should happen if an ITI-65 request includes a different status?

Proposed Change 1. Add mappings to 15.12.6.3 and 15.4.6.3. 2. Add guidance to reject any List.status other than "current".

Priority: Medium

see FHIR managed valueSet
http://build.fhir.org/valueset-endpoint-connection-type.html

MHD could define a value in the IHE space, or we could request adding a value to the HL7 managed codeSystem

MHD_057: On-Demand and Delayed-Assembly are not addressed in MHD. This could be a future work item. The available solution is that a Document Consumer can tell stable from On-Demand or Delayed-Assembly through the hash and size elements, but can’t determine the difference between On-Demand and Delayed-Assembly. The only solution available for publication of On-Demand or Delayed-Assembly is that the Document Source can place any URL into the DocumentReference.content.attachment.url, and thus that URL might be to a service that dynamically creates the content. However this solution does not require (IHE requirement) that the On-Demand or Delayed-Assembly post processing of the DocumentReference update or snapshot happen. Thus there is not comprehensive solution provided.

CP-ITI-1116: Dissonance between FHIR concept of Transaction, and XDS Provide and Register transaction. This is partially addressed in CP-ITI-1095 regarding PartialFolderContentNotProcessed. In that a Document Responder is allowed to fail the full transaction according to FHIR transaction rules but is also allowed to soft warn. The soft warn would most likely be needed when implementing XDS-on-FHIR, as the XDS actors will have returned warnings. Thus, the Document Recipient must be allowed to return these soft warnings. In this case the MHD Document Recipient can’t undo the XDS transaction, so it must be allowed to return success with warnings.

Section Number https://profiles.ihe.net/ITI/MHD/1_overview.html

*Issue Is there a reason why the Vol 1 content can't more closely follow the order of sections in the current Vol 1 template for PDF? I understand that Vol 2 and 3 will more closely follow an IG pattern

Proposed Change *
-- Ditch Figure 33-1 and remove surrounding text, or move what you want to keep into https://profiles.ihe.net/ITI/MHD/1_overview.html#mobile-access-to-health-documents-mhd
-- start the "Overview" page (which the TOC tells me is Volume 1) with what is in Section 33 in today's PDF (with any modifications you made for this revision).
-- Continue with the order of content , and ideally the section headings, that we have in Vol 1 today

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number https://profiles.ihe.net/ITI/MHD/ITI-65.html#patient-identity

Issue All DocumentReference.subject, and List.subject values shall be References to a FHIR Patient Resource. This value may be a relative reference to a Patient Resource within the Bundle or an absolute external reference (URL). This value should be an absolute external reference that may be obtained through use of PDQm or PIXm, or by some other means. The Patient Resource needs to be accessible to both the Document Source and the Document Recipient.

Proposed Change Now that the Patient Resource may be in the Bundle, should we remove the last sentence above? It seemed more accurate when it was always external

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number
https://profiles.ihe.net/ITI/MHD/ITI-65.html

Issue
There is no profile/example for a Provide Document Bundle Response Message

Proposed Change
PR with profile/example

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number
https://profiles.ihe.net/ITI/MHD/ITI-66.html
https://profiles.ihe.net/ITI/MHD/ITI-67.html

Issue
Message Semantics declares that:
The Document Consumer executes an HTTP GET against the .. URL

It is not clear if a Document Consumer can also execute a HTTP POST for the query and if a server shall support also a FHIR POST Query. Above sentence implies that a only a HTTP GET might be needed.

The FHIR specification requires both:

Because of the way that some user agents and proxies treat GET and POST requests, in addition to the get based search method above, servers that support search SHALL also support a POST based search:
For a server it is not difficult to support both methods, it should be up to the client or actual deployment or regulation which method should be chosen.

Discussion about HTTP POST in Zulip

Proposed Change *
The Document Consumer executes an HTTP GET or HTTP POST ...

Priority:

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Section Number 11.4.1.2.1

Issue ITI-65 constrains each bundle entry request to POST. This would mean if an MHD Document Source wanted to add Document References to an existing Folder, it would have to do it outside an ITI-65, e.g. in a single PUT.

Proposed Change Because ITI-65 adds valuable context and provenance, we should allow Folder Lists to use the PUT request in ITI-65. Additionally, we should consider guidance that ITI-65 should be the only mechanism used to update Folder Lists. We enforce this in the eHealth Exchange, but it is a cross-community environment. It may be the case that inside a community, systems may want to allow more flexibility.

Priority: Medium

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

Issue As we move FHIR-based profiles to IG format, I want to find a standard home for what is current in Vol 1 33.3 in MHD (PDF). It took a long time for IHE to create a common home for that in the supplement template, and I don't want to lose "one stop shopping" for those requirements. (Note that in your case, the requirements are stated in the XDS on FHIR option section, but the whole point is not to have to fish through the Vol 1 text to find grouping rqmts. Note that these grouping rqmts are encoded in Gazelle Master Model, just like actors/transactions/options so that they are enforced in connectathon registration & testing

Proposed Change seems like it belongs as a subsection in https://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html

Priority: Medium

Section Number
https://profiles.ihe.net/ITI/MHD/ITI-66.html#actors-roles

Issue
Wording for Document Consumer Actor

in https://profiles.ihe.net/ITI/MHD/ITI-67.html#actors-roles it is written Requests a list of DocumentReference Resources, so this would give:

Requests a list of List Resources

which does not sound good

Proposed Change

Requests List Resources, matching ....

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number
https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.Minimal.ProvideBundle.html

Issue
Profiles enforces entry SubmissionSet but does then not enforce included resource.

Proposed Change
upcoming PR which tightens resource to 1..1 in the different slices

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number throughout

Issue We still have an MHD "Profile", right? The "implementation guide" is just the documentation vehicle for specifying it, right? It's unclear how you decided to use one term vs another in here.
e.g. https://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html#transaction-descriptions, you say "This section defines the actors and transactions in this implementation guide." I think the actors are in the profile. MHD Doc Source, MHD Doc Recipient. Yes, the exist "in" the IG, but that's just because you have write about them on these pages.

I know this is a 'dancing on the head of a pin' argument, but we are setting precedent here for future IGs.

Proposed Change You might say "IG" is a term we are going to adopt now. Then, is "MHD Profile" even accurate anymore (I hope so). If so, when?

Priority: medium

MHD_053: Note that there is an emerging issue that FHIR has not addressed and that is how distributed systems behave, and how Patient links affect recorded data. Thus, it is difficult to determine today that the response Bundle content all will be pointing at the exact same Patient, although they should all be referring to the same human.

Section Number
https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.FindDocumentReferencesComprehensiveResponseMessage.html
https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.FindDocumentReferencesResponseMessage.html

Issue
Should be ITI-67 instead of ITI-68

Proposed Change *
PR

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number several

Issue there are numerous links into https://profiles.ihe.net/ITI/MHD/appendix_z.html. Does that mean that content is "in scope" for this public commen t?

Proposed Change separate public comment for Appx Z

Priority: medium

MHD_055: List.source does not allow for Organization which is needed for SubmissionSet.author. So created an extension (SourceOrg) to hold the SubmissionSet sourceId as a Reference(Organization). This could be reverted if the submitted CR changes R5 https://jira.hl7.org/browse/FHIR-30154

Section Number
https://profiles.ihe.net/ITI/MHD/ITI-66.html

Issue
There is no profile for a Find Document Lists Response Message

Proposed Change
Add with upcoming Pull Request.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number https://profiles.ihe.net/ITI/MHD/ITI-65.html#bundle-resources

Issue If a reader is determining rqmts for ITI-65 for the Doc Source or Doc Recipient, and s/he starts in Vol 1 and then gets to this section, I believe this is the first time the reader encounters the term "Minimal Metadata"

Proposed Change Associate the Minimal Metadata Requirements here with the Doc Source / Recip w/o any options.
Fix this sentence to refer to options for the Source actor since we are in semantics for the submission request... "The FHIR Bundle.meta.profile shall have the following value depending on the use of Comprehensive metadata, Minimal metadata, or UnContained metadata:"

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

package name 4.0.0-comment does not work with IG Publisher for dependent packages: Failed to resolve package ihe.mhd.fhir#4.0.0-comment from server: http://packages.fhir.org and Error reading http://ihe.net/fhir/ihe.mhd.fhir/4.0.0-comment/package.tgz

The issue is that current tooling does not accept suffix -comment (pre-release and build metadata)

Proposed Change
For this review no issues since master branch is the same, however for a next version it would be helpful to have a specific version for pubic commit.

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

MHD_063: Should MHD defined CapabilityStatement requirements so that a client can determine that the server supports MHD and which MHD server actor? Today we do require servers to support metadata endpoint returning their CapabilityStatment, but do not require it to contain anything specifically. We could first require that the CapabilityStatment.implementationGuide be populated with MHD canonical IG URL. We could additionally require specific .transaction values for DocumentRecipient, and .rest.resource.supportedProfile for DocumentResponder. Might we need an extension in .transaction to be more specific for Document Recipient? Should a DocumentRecipient need to publish that it is capable of receiving a create/update on these .rest resources (which we only defined thru the transaction, not individually REST)? Might we add an extension on CapabilityStatement.implementationGuide to hold the actor name and options? – with no objection this is likely to be added as a server requirement.

Section Number
https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.Comprehensive.SubmissionSet-mappings.html

Issue
identifier is mapped to SubmissionSet.entryUUID and SubmissionSet.uniqueId

it is not clear how the identifier should be mapped to entryUUID or uniqueId, it could be differentiated by oid/uuid but this seems not obvious.

Proposed Change

For MHD Rev. 3.2 – 2020-08-28 it was specified for Folder that "When the List.identifier carries the entryUUID, then the List.identifier.use shall be ‘official’. When the List.identifier carries the uniqueId, then the List.identifier.use shall be ‘usual’.", I propose this concept should be incorporated in the MHD List profile for Folder and SubmissionSet.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number https://profiles.ihe.net/ITI/MHD/ITI-65.html#message-semantics

Issue suggested rewording

Proposed Change T
he Document Source shall initiate a FHIR “transaction” using a “create” action by sending an HTTP POST request method composed of a FHIR Bundle Resource containing :
one List Resource of type SubmissionSet, ("one" not "the)
one or more DocumentReference Resources,
zero or more List Resources of type Folder
zero or more Binary Resources to the Document Recipient.

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Issue
Slicing evaluation for minimalProvideDocumentBundle

Proposed Change
See Pull Request For Details: #10

Priority:

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Section 1 on the home page states:

" The following figure shows one possible way to implement MHD within a document sharing environment (that may be, but is not necessarily, XDS-based)"

Unfortunately, "the following figure" appears to be missing.

This is also the case in the first paragraph of section 2.

Section Number

https://profiles.ihe.net/ITI/MHD/a_issues.html
CP-ITI-1119: Made clear that Document Source must not populate any entryUUID.

Issue
CP-ITI-1119: Made clear that Document Source must not populate any entryUUID.

According to the original CP I cannot find out the summary of the above sentence.

In addition Table 4.3.1-3: Sending Actor Metadata Attribute Optionality sets entryUUID as Required for the sending Actor.

See also discussion in google group

Proposed Change
Remove the summary of CP-ITI-1119 and enforce entryUUID also in MHD, see also #13.

Priority:

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Section Number *https://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html#uncontained-reference-option

Issue we changed the actor name in PMIR

Proposed Change change PMIR Patient Identity Manager to PMIR Patient Identity Registry

Priority: Low

CP-ITI-1100: Need a way to find DocumentReference that hold attachments with a specified creation date/time. For the time during FHIR R4, we have guided the implementer to use the .date element to hold the created date/time. This solution requires careful duplication of the date value in both date and the attachment. This duplication enables use of the elements and query against date. The .date element in FHIR is defined as when the DocumentReference was created, which might be later than the document creation date/time. GF#19823 requested query parameter for the attachment created date/time for R5

R5 has a "creation" parameter that searches DocumentReference.content.attachment.creation

So this open-issue will be resolved by R5.

MHD_060: Header numbers are auto assigned by the Implementation Guide building tools, and thus are not the numbers in the IHE Volumes that they should be. This should be fixed by Trial Implementation.

http://hl7.org/fhir/search.html#chaining

Section Number general

Issue Context for requirements; navigation

Proposed Change The more time I spend in this IG, the more I think that the access to the artifacts like structure definitions, capability statements, and mappings needs to be from within a transaction and not from Vol 1. When you are in the transaction, you have the context for the actor (sender or receiver) and the message semantics (req/rsp), and then the links to the artifacts make sense. Every time I landed in a CapabilityStatement from a link in Vol 1, I felt like I stepped into a black hole

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

MHD_058: The profile requires that the document submitted is encoded in a FHIR Binary. Is there interest in also allowing a Bundle of type Document? This would be useful when publishing FHIR-Documents. The FHIR-Document would still need to be seralized into a Bundle of type Document, but that Bundle would not need to be further encoded into a Binary (e.g. base64 encoding). Note that the mime-type in this case would be forced to be the same mime-type as the ITI-65 Bundle, where a Document Source wants to encode ITI-65 in a mime-type that is different than the document, the Binary methodology would need to be used.

MHD_061: The new IUA supplement includes guidance on use of OAuth scopes when grouped with MHD. That text seems should be brought into this IG, but it is unclear where this text should be maintained going forward. For now this text is left only in IUA, but after public comment this text will likely be brought into MHD. see https://profiles.ihe.net/ITI/IUA/index.html#33-mhd-profile

Thus removing it from IUA.

Section Number https://profiles.ihe.net/ITI/MHD/1_overview.html Section 2 MHD Actors, and Transactions

Issue * There are two section 2's on the Overview page, and the contents of "MHD Actors and Transactions" is in complete, and what you really want comes later.

Proposed Change Take the content in https://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html and use it to replace Section 2 on https://profiles.ihe.net/ITI/MHD/1_overview.html That way, the actors are introduced before you do use cases.

Priority: Medium

CapabilityStatement-IHE.MHD.DocumentResponder.html

The others have some narrative.

Section Number 11.4.1.3

Issue MHD allows grouping with XDR/XCDR in addition to XDS, but only provides details for XDS. For example, in section 11.4.1.3.1, the instructions for transforming the ITI-65 into an ITI-41 could easily be reused for at least XDR.

Proposed Change Either define XDR-on-FHIR, XCDR-on-FHIR, etc. or provide non-normative guidance to implementers to follow the XDS transformations.

Priority:

• Medium

This might make MHD_063 easier? #25

Currently, the transaction pages are named Transaction ITI-XX. I suggest we add the human readable transaciton name to the page names, ie. Transaction ITI-XX Provide Document Bundle

MHD_062: Should the structureDefinition profiles forbid modifier extensions? It seems we have no reason for modifierExtensions, and modifierExtensions are allowed to radically change the meaning of the resource. – with no objection this is likely to be added as a constraint.

Section Number https://profiles.ihe.net/ITI/MHD/ITI-65.html#expected-actions

Issue change should to shall in the 1st sentence below, since the following 2 sentences contain shall

Proposed Change The Document Recipient should verify the FHIR resource elements for consistency with the Document Sharing metadata requirements as specified for attributes ITI TF-3: Table 4.3.1-3: “Sending Actor Metadata Attribute Optionality”. The Document Recipient that supports the “Comprehensive Metadata” or the “XDS on FHIR” Option shall validate against column “XDS DS”; otherwise the Document Recipient should validate against column “XDR MS”.

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number https://profiles.ihe.net/ITI/MHD/CapabilityStatement-IHE.MHD.DocumentSource.Comprehensive.html. Perhaps elswhere

Issue *This page refers to the "Comprehensive Option" It is Comprehensive Metadata Option

Proposed Change The option names are correct here: https://profiles.ihe.net/ITI/MHD/2_actors_and_transactions.html

Priority: Low