Stream: ihe
Topic: identifier 2..* on SubmissionSet
Simone Heckmann (Sep 23 2021 at 18:57):
What's the expectation of how the 2 required identifier should be populated?
https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.Minimal.SubmissionSet.html
Does that mean the cardinality of the second slice entryUUID in the underlying profile is constrained to 1..1 ?
https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.List.html
John Moehrke (Sep 23 2021 at 19:03):
it very much depends on the use-case.. and sorry if that is not clear. What is your use-case? Are you Publishing, or are you Pushing? Are you looking to do minimal metadata, or XDS-on-FHIR? I presume you are implementing the Document Source?
John Moehrke (Sep 23 2021 at 19:08):
I guess these specific element level profiling are not too specific to those questions.
John Moehrke (Sep 23 2021 at 19:09):
a Document Source is NOT expected to include an entryUUID, that would tend to be added by the Registry, as that is the unique identifier the Registry understands. In a pure FHIR world, this is fully redundant with the .id . but is included in the model to support widest interoperability.
Simone Heckmann (Sep 23 2021 at 19:09):
I don't have a use case (yet), I'm just randomly browsing the spec, trying to understand it :D
John Moehrke (Sep 23 2021 at 19:10):
the other .identifier is expected to be assigned by the Document Source
John Moehrke (Sep 23 2021 at 19:11):
in a pure FHIR environment, these are both not very useful... as the .id is what everyone will use.
John Moehrke (Sep 23 2021 at 19:11):
but I couldn't use the .id because the .id can't be an OID, and the entryUUID in XDS/XCA must be an OID.
John Moehrke (Sep 23 2021 at 19:11):
so this dissonance had to be supported by using the .identifier
Simone Heckmann (Sep 23 2021 at 19:13):
I think the scenario currently in my head is the following: I have several Documents with DocumentReferences in my system and I want to send a single one of them via MHD: How do I populate the fields in ITI-65? What can I resuse, what is additional information a user would have to put in...?
John Moehrke (Sep 23 2021 at 19:14):
so a PUSH scenario.. expected that you need to create a SubmissionSet. The role of this is to explain to the recipient who sent this, why they sent it, etc.... may again seem redundant to the details in the DocumentReference, but this potential redundancy enables you to send content that someone else authored.
John Moehrke (Sep 23 2021 at 19:20):
I guess we should have a third use-cases that is specifically just a push distinguished from publish in 1 -- https://profiles.ihe.net/ITI/MHD/1334_overview.html#13342-use-case-1-publication-of-new-documents
Simone Heckmann (Sep 23 2021 at 19:22):
Sorry, I still don't understand the difference between PUSH and Publish. :thinking:
John Moehrke (Sep 23 2021 at 19:24):
push can get away without fully filling out the metadata. Publish needs to fill out the comprehensive metadata. This because publishing is for the purpose of supporting searching. if the metadata is not filled out, then it is not discoverable.. where as with push, if the recipient doesn't understand something, they can pick up the phone and ask "WHAT?"
Simone Heckmann (Sep 23 2021 at 19:37):
Hm, ok. In that case, I want to "publish".
Let me rephrase my scenario: I want to build my internal document exchange and storage as sustainable and interoperable as possible.
I want to make sending my Documents through MHD(optionally with XDS) as easy as possible. One of the things I would do is make sure, I have all the comprehensive Metadata captured, make sure that my document type codes can be mapped to XDS etc. So if my user decides to send/publish(?) a document (e.g. into a Patient's EHR), all that needs to happen in my system is a bit of terminology $translate magic, Bundle everything up and the document is on it's way.
The submission set however isn't a thing that I already have in my system, it needs to be created at runtime based on the existing information plus maybe some user input. So I'm trying to figure out. Which of the required List elements can be automatically populated and which can't.
Simone Heckmann (Sep 23 2021 at 19:51):
Backstory: We're currently working on hammering out the requirements for document exchange within hospitals in Germany. FHIR-based document exchange between subsystems and EHR systems will be mandatory and have to comply with the specification. Germany has an XDS-ish PHR and many of the documents in the hospitals will have to be published to the Patient's PHR. We want to make sure, that all requirements are met as early as possible in the chain to allow for an easy transition between internal and external document exchange either via MHD Gateway or directly via MHD when the PHRs are updated with RESTtful APIs at some point in the future.
John Moehrke (Sep 23 2021 at 20:00):
okay, then you need to follow the https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.Comprehensive.ProvideBundle.html
John Moehrke (Sep 23 2021 at 20:01):
see the Definition on that page
John Moehrke (Sep 23 2021 at 20:02):
It still should be easy to populate this, as in your case it seems like the SubmissionSet is just needing to express why is this document being published now. This can be many fixed values, or values pulled from the DocumentReference.
Simone Heckmann (Sep 23 2021 at 20:15):
OK, back to my initial question: For my SubmissionSet List to validate against the 2..* constraint on identifier, I have to put in a uniqueId and...?
John Moehrke (Sep 23 2021 at 20:17):
you as a Document Source must populate one. you can't put in the entryUUID.
John Moehrke (Sep 23 2021 at 20:18):
hmmm, interesting.. I need to look into that.
Simone Heckmann (Sep 23 2021 at 20:23):
Yes, I think the cardinality on the identifier element doesn't make sense,
1..* would work because one of the slices is mandatory anyway,
On I side note: For the UUID-Slice, the system should be fixed to urn:ietf:rfc:3986
And all identifier slices might benefit from a 1..1 constraint on system and value.
John Moehrke (Sep 23 2021 at 20:24):
yup, good comment. but only the entryUUID must be an OID.
John Moehrke (Sep 23 2021 at 20:24):
so, looking at the IHE normative specification about SubmissionSet and Document Source... seems both are manditory - https://profiles.ihe.net/ITI/TF/Volume3/ch-4.3.html#4.3.1
John Moehrke (Sep 23 2021 at 20:24):
not clear to me why. but that is why I have 2..*
Simone Heckmann (Sep 23 2021 at 20:25):
I'll put in some issues in github for these...
Simone Heckmann (Sep 23 2021 at 20:33):
https://github.com/IHE/ITI.MHD/issues/93
https://github.com/IHE/ITI.MHD/issues/92
Simone Heckmann (Sep 23 2021 at 20:40):
Would it cause any issues if I put the same UUID into both...?
<identifier>
<use value = "official"/>
<system value="urn:ietf:rfc:3986"/>
<value value ="56a0b15e-1e24-40db-b976-cf13e409c079"/>
</identifier>
<identifier>
<use value = "usual"/>
<system value="urn:ietf:rfc:3986"/>
<value value ="56a0b15e-1e24-40db-b976-cf13e409c079"/>
</identifier>
...I mean it's stupid, but it's probably what I would do as a maliciously compliant implementer :smiling_devil:
John Moehrke (Sep 24 2021 at 12:53):
we are having spirited discussion in IHE. replicating would not be proper, but I fully get why that would be the natural reaction. Hence the reason I have started the spirited discussion in IHE. The essence I am coming to understand is that the MHD clients should never need these values and should never populate them. The problem is that today the spec mandates them.
John Moehrke (Sep 24 2021 at 12:54):
I would recommend you just, for now, create yet-another GUID.
Last updated: Apr 12 2022 at 19:14 UTC
