identifier 2..* cardinality on SubmissionSet unclear

[simoneOnFhir]

It is unclear which two identifiers are required here, since only one of the slices in mandatory.
See discussion on Zulip: https://chat.fhir.org/#narrow/stream/179223-ihe

[JohnMoehrke]

see ITI email thread - https://groups.google.com/g/ititech/c/uxgZtypI7Oo/m/wUNKXjHmBAAJ?utm_medium=email&utm_source=footer

[JohnMoehrke]

It is seeming to me that the entryUUID is to eb-Registry as the FHIR Reference elements are to FHIR. Thus at the MHD clients there should be no mention of entryUUID, except to allow it to be carried. There is nothing a MHD client can do with the entryUUID, and any Document Source actions in MHD need to use the Reference elements, and not entryUUID.

MHD Document Source would use Reference elements for everything that an XDS Document Source would entryUUID values for. For example replacing a previous document, would be done by an MHD Document Source through DocumentReference.relatesTo.target (Reference).

Further there is no way for a MHD Document Source to properly process entryUUID. Indeed even on a create the MHD Document Source is expected to set the DocumentReference.id according to FHIR rules, but has no rules that it would know how to properly set the entryUUID.

Where MHD is an api to XDS, the MHD Document Responder should translate entryUUID into the FHIR resources. the MHD Document Consumer should expect to sometimes see entryUUID, there is a small use-case where a MHD Document Consumer may need to lookup an XDS object by the entryUUID (unusual, but possible).

Thus the profiles should

• continue to define proper placement for entryUUID
• stop requiring entryUUID

This would mean that in an MHDS environment, there would be no entryUUID at all, as FHIR Resource elements would fulfill all of these requirements. (Not clear that MHDS should forbid entryUUID values. This could be done, but not clear it adds any benefit or prevents any problem).

[oliveregger]

this applies also to the DocumentEntry.identifier requirement 1...* for the entryUUID.

[oliveregger]

Should adapt slicing/cardinalities that for MHD entryUUID can be provided but for MHDS entryUUID is not required.

[oliveregger]

could the entryUUID be made optional for MHD and the Document Responder would need to provide the entryUUID .

[JohnMoehrke]

For DocumentReference

The MHD Document Source is already forbidden from providing an entryUUID (section 2:3.65.4.1.2), while the .identifier element is required

-> Should be "May", or do we want it to be shall not?

So, changing the .identifier to 0..*

[JohnMoehrke]

For SubmissionSet

changed identifier from 2..* to 0..*, and added a short explaining what might be placed here.

inserted in expected actions (ITI-65) a requirement to create entryUUID values as needed.

[JohnMoehrke]

For Folder

dropped to 0..*, and added short explaining

[JohnMoehrke]

http://build.fhir.org/ig/IHE/ITI.MHD/branches/identifier-cardionality/index.html