Stream: ihe
Topic: DocumentManifest
René Spronk (Dec 04 2017 at 16:54):
In case one doesn't use the "grouping" capability of DocumentManifest (i.e. XDS Submissionset) it seems the role of DocumentManifest in MHD is limited to that of "Provenance". I understand why the resource exists if one wishes to be compatible with XDS, but if one starts looking at MHD from a FHIR perspective without knowing anything about XDS.b it may be difficult to explain as to why it exists.
If the use of DocumentManifest resource is required in MHD, how would one explain its use (its raison 'detre) to someone who is not familiar with XDS.b at all ? I'm sure I'll be asked that question in upcoming FHIR training courses.. (we're adding MHD to its contents)
John Moehrke (Dec 04 2017 at 18:24):
Hi Rene, I addressed this on my blog last week. It is indeed not that useful for a Document Consumer except in exceptional cases. The purpose of a DocumentManifest is like any manifest (think packing slip in a box delivered by the postal carrier), as a listing of the things included in a package that was sent. Thus even in XDS, the SubmissionSet (DocumentManifest) is there to group the set of DocumentEntry (DocumentReference) as a 'set'... The consumer use-case is to answer the question: Given I am looking at this document, what else did the publishing actor publish at the same time. so, from a document consumer perspective, the DocumentReference and document are the main things to care about; and in MHD the DocumentManifest is mostly ignore-able. A Server can choose to not ever return a DocumentManifest, which would be the case if you didn't have any... See https://healthcaresecprivacy.blogspot.com/2017/11/hie-future-bright-fhir-api-to-document.html
René Spronk (Dec 05 2017 at 10:22):
Thanks, I somehow missed that blogpost.
As you point out SubmissionSets/DocumentManifest has only a few edge use cases, they're not part of the 80% of MHD. As such I'd expect the support for DocumentManifest to be an actor-option for the DocumentResponder actor, and not a required feature.
I would even argue that we should remove DocumentManifest from FHIR, given the exotic use cases for it, and the fact that it could be easily replaced by a) adding the SubmissionSet.uniqueId as one of the DocumentReference.context.related.identifiers [thus allowing for querying on things contained in a submission set should that ever be necessary], b) adding a Provenance resource that links to all the resources contained in the MHD submit transaction bundle.
Again: given that alternative, why does DocumentManifest even exist as a resource?
John Moehrke (Dec 05 2017 at 13:26):
Given my argument in my blog, I think DocumentManifest is essentially optional on the consumption side. There is nothing compelling a Document Consumer to show they have implemented it, and there is no requirements on a Document Responder that it return anything other than zero results. Given this, I don't see why it is stressing you.
John Moehrke (Dec 05 2017 at 13:30):
When you focus only on the consumption side, it might seem unnecessary. But if you do need it on the consumption side, and you don't have it, then there are problems.
John Moehrke (Dec 05 2017 at 13:31):
Note that this is exactly the same way that SubmissionSet is handled in XCA. so there is precedent.
John Moehrke (Dec 05 2017 at 13:32):
On the Publication side, it is important to add context to a set of DocumentReferences. When pushing toward an XDS environment, it is critical to fill out the SubmissionSet. When doing a end-to-end push, this context of the transaction is defined in the DocumentManifest. When used with another infrastructure like Direct, the DocumentManifest identifies the target Direct address to send the package to. Where as DocumentReference is purely metadata about the document regardless of transnational context. SubmissionSet is all about defining the context.
John Moehrke (Dec 05 2017 at 13:34):
As to 80%... it is used quite often. More so for organization-to-organization; less so for an terminal application doing nothing but displaying the document. But we can not pick use-cases to fit a pre-conceived notion of 80%; we must truly look at current market.
John Moehrke (Dec 05 2017 at 13:34):
What harm do you see because DocumentManifest exists?
René Spronk (Dec 05 2017 at 14:43):
It doesn't do any harm, although in general we have to take care to avoid the creation of resources types if they're rarely ever used. I can see the use case in the case of XDR (Direct). I'm not familiar with the XCA case for SubmissionSet, so I'll have to read up on that. Anyway, I'd suggest support for DocumentReference be an option (in MHD), and not mandatory.
At this point in time I see DocumentReference doesn't allow for on-demand documents. A reference to a Compostion resource would be desirable in that case. Attachment.url could be a URL which includes the $document operation.. I take it the limitation to stable documents was done to keep things simple?
John Moehrke (Dec 05 2017 at 14:47):
My point on XCA is that SubmissionSet is handled the same way as I handle it in MHD. It is allowed to be carried, and there are query capabilities; but no mandate.
John Moehrke (Dec 05 2017 at 14:47):
I don't understand what the effect on option as you mention would be. The result would be the same as it is without the option.
John Moehrke (Dec 05 2017 at 14:49):
There is nothing special in MHD to support on-demand. In fact the wording on attachment.uri is very careful to allow for any format of the URI, and that a consumer must simply do a GET on the URI. Thus on-demand is just as supported as anything.
René Spronk (Dec 05 2017 at 16:16):
Well, currently as a document submitter MHD requires me to create a DocumentManifest, even if there is no use case for it. DocumentReference plus Binary would be sufficient in most mobile use cases.
The MHD spec mentions DocumentManifest, DocumentReference, List and Binary as resources. I gather List is only used to represent the Folder concept ? (if so I can safely ignore it, nobody seems to be using Folders)
Last updated: Apr 12 2022 at 19:14 UTC
