Stream: ihe
Topic: DocumentManifest vs List
John Moehrke (Dec 19 2019 at 21:55):
Please discuss the pro/con of having IHE MHD switch from using DocumentManifest for SubmissionSet, to using List for SubmissionSet? I am wondering if this is a better long term strategy given the limited interest in DocumentManifest vs the more broad interest in List for many use-cases. Yes it would require merging in some functionality not currently found in List, but it seems a better fit than a special case resource like DocumentManifest.
Elliot Silver (Dec 19 2019 at 21:56):
Can you refresh my memory on the advantage of List vs Bundle?
Grahame Grieve (Dec 19 2019 at 21:59):
Bundle is just a packaging mechanism. It says nothing about the relationships between the resources, List is the opposite
Grahame Grieve (Dec 19 2019 at 21:59):
What does DocumentManifest achieve?
Grahame Grieve (Dec 19 2019 at 22:00):
(in XDS, I mean)
Elliot Silver (Dec 19 2019 at 22:04):
Thanks. In XDS, there are two "bundling" concepts: Submission Set which gathers all content submitted together; and Folder which gathers content related to a particular topic (e.g., the patient's knee injury). Folders can be updated over time as new documents become relevant to the topic, and anyone (with authorization) can add to it. Alternatively, a provider could define a "patient's documents interesting to me" folder. Submission Set is (largely) immutable and is created by the system that publishes the documents as part of the publication process.
Elliot Silver (Dec 19 2019 at 22:06):
Note that neither concept is required when using XCA (the cross-community layer on top of XDS).
Grahame Grieve (Dec 19 2019 at 22:06):
"List" is an appropriate resource for both (squarely in it's scope) and also a more appropriate word than 'manifest'
Elliot Silver (Dec 19 2019 at 22:07):
@John Moehrke, it is the fact that neither folder nor bundle is required in XCA that I think removing them from the profile is safe, and would allow us to wait to see if anyone else moves DocumentManifest forward.
Elliot Silver (Dec 19 2019 at 22:09):
(Agree, I always trip over "manifest". It isn't obvious. But makes sense when you think of it as the list :thinking: of things in this package.
John Moehrke (Dec 19 2019 at 22:10):
you mean DocumentManifest, not bundle... but I get the point. Understood, but that leaves MHD only as a Query/Retrieve function. No publication pathway.
John Moehrke (Dec 19 2019 at 22:11):
so yes... a SubmissionSet is a list of documents as part of the submission... a packing list. aka manifest
John Moehrke (Dec 19 2019 at 22:12):
a folder in XDS is a list of documents for a specific purpose
John Moehrke (Dec 19 2019 at 22:12):
SubmissionSet is fixed at publication time, and can't be changed. Folders change over time.
Elliot Silver (Dec 19 2019 at 22:13):
Actually, I meant SubmissionSet, but yes. Does it leave only Q/R functionality? And if so, is that a problem? XCA survives with Q/R only.
John Moehrke (Dec 19 2019 at 22:13):
You can get Folders and SubmissionSet in XCA. They are not missing... they are just read-only, and not typically thought of.. so unlikely to be queried for.
Grahame Grieve (Dec 19 2019 at 22:13):
I think it's a problem, yes, but I don't know if it's true. Replacing Manifest with list is a problem?
Grahame Grieve (Dec 19 2019 at 22:14):
but... isn't the scope of the transaction what is submitted in the transaction?
John Moehrke (Dec 19 2019 at 22:15):
a SubmissionSet does indeed define the publication transaction. But it is also an object that can be queried for as Provenance evidence.
Elliot Silver (Dec 19 2019 at 22:15):
@John Moehrke Support for folders and submissions is not required of a community.
@Grahame Grieve I think it is only a problem in that its a change of the profile, and that there are elements in DocumentManifest that aren't in List.
Grahame Grieve (Dec 19 2019 at 22:15):
So it should actually be Provenance then?
John Moehrke (Dec 19 2019 at 22:16):
well, one might argue that it is also CommunicationRequest
John Moehrke (Dec 19 2019 at 22:16):
or even MessageHeader
John Moehrke (Dec 19 2019 at 22:17):
depending on the use-case (aka XDR the SubmissionSet is much closer to MessageHeader), but XDS it is much more like Provenance+List
Elliot Silver (Dec 19 2019 at 22:17):
Maybe that's the answer then: Provenance+List.
John Moehrke (Dec 19 2019 at 22:19):
I don't think Provenance actually adds much.. I might need to do the exercise of mapping SubmissionSet into List to see what is missing. Clearly IntendedRecipient, and some clinical purpose/setting. but I expected these would be reasonable core extensions on List
Grahame Grieve (Dec 19 2019 at 22:20):
I've never really understood IntendedRecipient at the functional requirements level... it's the repository, surely
John Moehrke (Dec 19 2019 at 22:21):
no IntendedRecipient is really only intended to be used in XDR.. the "who" should receive this push. It was intended to be a human or service at the endpoint
John Moehrke (Dec 19 2019 at 22:22):
but some liked it for XDS, as they liked that it indicated the original target audience of a publication... so that person could be notified when something was published with them listed
John Moehrke (Dec 19 2019 at 22:22):
hence... communicationRequest
Grahame Grieve (Dec 19 2019 at 22:26):
actually that sounds more like a message header...
Reinhard Egelkraut (Jan 03 2020 at 13:59):
Hi,
personally I like the idea of replacing DocumentManifest with List for the XDS SubmissionSet in order to move MHD forward.
But out of curiosity, since the current version of MHD declares XDS Folders already as List and an XDS SubmissionSet could become a List as well, how would they be distinguished? Via different codes for the list (http://hl7.org/fhir/r4/valueset-list-example-codes.html) or some new attribute?
John Moehrke (Jan 03 2020 at 14:02):
Yes. I figure we would use the .code element to distinguish between submissionSet and Folder. Thus carrying the SubmissionSet.contentTypeCode and List.codeList in an extension element. I had asked for another codeableConcept (0..*) but that got rejected by FHIR-I last month.
John Moehrke (Jan 03 2020 at 14:03):
we can't use the List.code for much anyway as it is 0..1; and our uses are 0..*
John Moehrke (Jan 03 2020 at 14:08):
correction, they decided to add a core extension element "category" (0..*) CodeableConcept FHIR-19822
so we would have that as a core extension
Reinhard Egelkraut (Jan 03 2020 at 14:15):
sounds good, but just to clarify - the distinction between Folder and SubmissionSet would be part of list.code and SubmissionSet.contentTypeCode would go to the new core extension "category"
or
would both values be mapped to "category"?
John Moehrke (Jan 03 2020 at 14:49):
I think... that the best mapping is to use the List.code only to distinguish between submissionSet and Folder.. This is most visible element, vs extension.. but is also based on the fact that List.code is a 0..1 element, so can't be used for much.
Reinhard Egelkraut (Jan 03 2020 at 15:17):
I agree in this case the distinction will be a vital information for MHD and should not be "hidden" in an extension
Last updated: Apr 12 2022 at 19:14 UTC
