Community input needed - MHD move away from DocumentManifest

50 views
Skip to first unread message

John Moehrke

unread,
Nov 18, 2020, 12:15:05 PM11/18/20
to IHE MHD Implementors, eleonor...@a-thon.it, stephan...@gevko.de, hunter...@hyland.com, Conrad, Thorsten (VISUS), tobia...@tiani-spirit.com, fai...@medtronic.com, lapo.b...@dedalus.eu, vincenzo....@eng.it, christia...@icw.de
Hi MHD implementer community 

As many of you know, I am the author of MHD and also part of the HL7 FHIR core team. 

ASK: Please consider this message and provide feedback. I want to represent the interests of the MHD community, but also need that community to be active in HL7 and IHE. I am especially interested in concerns with the approach described below. I am also eager to get engagement in the ITI-Tech work we are starting on MHD (see below).

I have been thinking about a maturity problem that is coming up in FHIR R5 related to the FHIR Resources used by MHD. 

Patient is already normative.

DocumentReference is likely to be pushed to be normative in FHIR R5. It is part of US-Core so has a group of people beyond MHD working on it.

List (MHD uses for Folder) is used by a couple of use-cases outside of MHD. So there is multiple groups working on it.

but DocumentManifest is not getting the proper attention to help move it to normative state. If that does not happen, then MHD will stay as Trial Implementation when it should be a consideration for Final Text.

Many of the MHD use-cases are recognized in US-Core, but they use only DocumentReference and don't have use-cases for DocumentManifest or List (Folder). I bring in US-Core only to express where the motivation is to push DocumentReference to normative. IHE is of course Internationally focused.

The only use of DocumentManifest is in MHD...
  1. We (IHE) can do what is necessary to make this normative. I will still need the IHE community to step forward within the HL7 community to push the workgroup owning DocumentManifest to do HL7 governance. Note that this is a big problem as well since DocumentManifest is still owned by Struct Doc WG; where DocumentReference has moved over to OO. Thus this pathway has many organisational challenges.
  2. We (IHE) can switch MHD away from DocumentManifest, using List. There would then be two kinds of list in MHD, one as the SubmisstionSet, the other as a Folder.
  3. We (IHE) can switch MHD away from DocumentManifest toward some other resource. 

ITI-Tech has agreed to #2. That is to stop using DocumentManifest for SubmissionSet, and profile a use of List for SubmissionSet functionality. This might produce some update requests to List to add elements necessary for that use-case. Adding elements to List should not be seen as a problem. List maturity would be needed by MHD for Folder anyway, so putting our efforts toward the same resource would be helpful.

Yes there are functionality differences between a SubmissionSet and a Folder. These differences can easily be profiled into the same List resource.

Note that ITI-Tech is also going to formally move MHD out of supplement form, and into the IG Authoring form. Thus we would benefit from community engagement, such as providing examples and review.

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

Neil Robinson

unread,
Nov 19, 2020, 6:09:27 AM11/19/20
to IHE MHD Implementors
Hi All. I am in favour of moving away from DocumentManifest. Within the UK NHS Digital uses DocumentReference as the "pointer" construct as part of a National Record Locator Service (NRL). I have proposed a "Metadata Value Set". I would have liked to include the DocumentManifest.type as a placeholder for the overarching event triggering publication - but its not supported by NRL. My dirty fix was to propose eventCodeList - context.event - as a suitable location. So I see documentManifest as a complicationnot needed. A separate issue is whether documentReference is always needed if the the "payload" is a composition.

Martí Pàmies Solà

unread,
Nov 23, 2020, 2:42:05 AM11/23/20
to ihe-mhd-im...@googlegroups.com

Hi at all,

I am also in favour of moving away from DocumentManifest. We are using MHD in a production environment at a Hospital at Barcelona, as it is the standard interface to query documents form and standardized document repository (CDA). W always implement queries at DocumentReference Level.

Regards

--
You received this message because you are subscribed to the Google Groups "IHE MHD Implementors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-mhd-implemen...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-mhd-implementors/6a6c2ca7-4d92-40cd-a3fa-09d80c07e3dan%40googlegroups.com.



Avast logo

Aquest correu electrònic s'ha verificat mitjançant l'Avast antivirus.
www.avast.com


christ...@gmail.com

unread,
Dec 1, 2020, 6:30:51 AM12/1/20
to IHE MHD Implementors
Hi,

for all those having an XDS backend there must remain the possibility to map a "manifest list" to an XDS SubmissionSet and back. 
And as MHD is in pretty wide-spread use already (although being still in trial impl phase), consideration of backwards compatibility is necessary. Otherwise the willingness of the community to actually try out these preliminary specifications in real environments will surely decrease in the long run, which will prevent development of profiles in the future.

One more detailed note: We have been using List/Folders in MHD contexts already using its code attribute to group DocumentReferences outside of an Encounter context (others might have done that, too), so I would refrain from using the List code to differentiate the two fundamental types of List (in XDS terms, modelling SubmissionSet and Folder).  I would prefer having a new attribute like "purpose" or "use" (or an extension with similar semantics).

regards
Christian
Reply all
Reply to author
Forward
0 new messages