Fwd: IHE ITI Technical Framework Supplement Published for Public Comment

[John Moehrke]

new Public Comment for latest version of MHD

---------- Forwarded message ---------

From: Integrating the Healthcare Enterprise <upd...@ihe.net>
Date: Fri, Apr 2, 2021 at 3:35 PM
Subject: IHE ITI Technical Framework Supplement Published for Public Comment
To: <johnm...@gmail.com>

IHE IT Infrastructure Technical Framework Supplement Published for Public Comment. Is this email not displaying correctly? View it in your browser. IHE IT Infrastructure Technical Framework Supplement Published for Public Comment The ITI Technical Committee has published the following updated supplement (in HTML vs. PDF form) for public comment from April 2 through May 2, 2021: Mobile Access to Health Documents (MHD) - Rev. 4.0.0 The document is available at https://profiles.ihe.net/ITI. Comments submitted by May 2, 2021 will be considered by the IT Infrastructure Technical Committee in developing the trial implementation version of the supplement. Comments can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.  follow on Twitter | forward to a friend  Copyright © 2021 Integrating the Healthcare Enterprise, All rights reserved. We use this email distribution channel for periodic updates on IHE activities. If you wish to respond, please send a message to upd...@ihe.net. Our mailing address is: Integrating the Healthcare Enterprise 820 Jorie Boulevard Oak Brook, Illinois 60523 Add us to your address book  unsubscribe from this list | update subscription preferences

[John Moehrke]

Reminder that MHD version "4.0.0-comment" is out for Public Comment, deadline May 2. I have replicated all the open-issues into github issues. So if you want to comment on the open-issue you could simply comment on the github issue. 

The ITI Technical Committee has published the following updated supplement (in HTML vs. PDF form) for public comment from April 2 through May 2, 2021:

• Mobile Access to Health Documents (MHD) - Rev. 4.0.0

The document is available at https://profiles.ihe.net/ITI. Comments submitted by May 2, 2021 will be considered by the IT Infrastructure Technical Committee in developing the trial implementation version of the supplement. Comments can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.

I am also very interested in receiving examples. The nice thing about the IG-publisher tooling is that it works best when there are many examples. I am missing the following examples

1. Need to figure out how to get a Sushi Bundle with a Binary attached to a DocumentReference.content.attachment.url
2. Add narrative to the examples. Some examples are intended to show edge cases that are not going to be valid.
3. Add examples from US-Core, or elsewhere?
4. bring in the test scripts from Connectathon test infrastructure
5. Full complement of Provide bundle examples
6. example needed - add a new document to a existing Folder
7. example needed - add a existing document to an existing Folder
8. example needed - a new submission set to include existing document
9. example not needed - a new submission set to include existing document from a different patient (mother / child use-case)
10. example needed - replace a document
11. example needed - push to a recipient
12. Example of an Provide bundle response

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

[John Moehrke]

Just a few more days left to the MHD Public Comment -- May 2nd

* public comment version

* current comment issues

I'm interested in responses to the Open Issues (links below are to the github issue I created to track responses. Comment on the issue, or add your own)

Open Issues

• 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.
• MHD_064: Should ITI-65 be an Operation rather than a Transaction? This might make MHD_063 easier?
• 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.
• 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
• 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.
• 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
• 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.
• 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.
• 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
• 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.
• 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_065: mapping between XDS RegistryError and FHIR OperationOutcome

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com