XDS SubmissionSet uniqueId and entryUUID

[John Moehrke]

Why is a Document Source required to fill out both uniqueId and entryUUID. I was expecting that entryUUID should not be required, that it would only be needed if updating an existing entry.

https://profiles.ihe.net/ITI/TF/Volume3/ch-4.3.html#4.3.1

Note that table also makes it mandatory (R) for uniqueId and entryUUID for DocumentEntry and Folder.

Is this the way it has always been?

There is no mention of entryUUID in ITI-41

    https://profiles.ihe.net/ITI/TF/Volume2/ITI-41.html

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

[slag...@epic.com]

Folders and DocumentEntries must be tied to a SubmissionSet via a HasMember association. The HasMember association uses the entryUUID for the source and target attributes. So I think this means that specifying entryUUIDs for all of SubmissionSet, DocumentEntry, and Folder are necessary to produce a valid ITI-41 message. 

[John Moehrke]

So then I might have interpreted it wrong for MHD Document Source. Given the fhir resource references there is no good reason for these. If a mhd document responder is linked to xds that actor can add them. Right?

John Moehrke - Architect: Standards - Interoperability, Privacy, and Security for Bylight.com
https://healthcaresecprivacy.blogspot.com

   

--
You received this message because you are subscribed to the Google Groups "IHE ITI Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ititech+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/1fc80a24-a946-47a2-ac91-49fab4fe2a3cn%40googlegroups.com.

[Gregorio Canal]

Note that the entryUUID filled by the Document Source could be opaque. The registry must update that opaque id with a valid entryUUID.

I remember that in mhd should work in the same way. Resources in ITI-65 should work the same because they are linked each other in a "transaction" Bundle.

The following is extracted by FHIR transaction

"A transaction may include references from one resource to another in the bundle, including circular references where resources refer to each other. When the server assigns a new id to any resource in the bundle which has a POST method as part of the processing rules above, it SHALL also update any references to that resource in the same bundle as they are processed (see about Ids in a bundle)."

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CACDGQjvO_d18MYo1aK81rSbDHoDwyKvtuOXkHC7Pf4hoDd%3DLoQ%40mail.gmail.com.

--

Gregorio Canal

Standardization and Testing Area | Arsenàl.IT

[John Moehrke]

yes that is my point. Given that there are FHIR methods of linking between the resources, these entryUUID values have no purpose. So, I am thinking that specifically for Document Source, they should be optional to populate. 

In an MHDS environment they would never be populated in any transaction, not even the search results. As in MHDS environment they continue to be meaningless. 

Thus the entryUUID is specific to the ebRegistry encoding environment. MHD may need a way to convey them, but not mandate them.

Or are they never needed in MHD even where MHD is used as an API to XDS or XCA? What is the use-case for conveying them to  MHD Document Consumer? When would a MHD Document Consumer need these entryUUID values, and what would they use them for? A MHD Document Consumer would not need these for any retrieval or further queries or further updates as a MHD Document Source.  - I ask, because I really don't know. It just seems to me they are not useful in MHD at all (in addition to not being needed in MHDS). I am not saying they would be forbidden, but wondering why we even give them a place to be carried to a MHD Document Consumer.

Is this correct?

John

[Gregorio Canal]

When using MHD as an API to XDS an MHD Document Consumer (grouped with a source) may need the entryUUID for further replacement or Metadata Updates.

I always logically mapped the documentEntry.entryUUID with the DocumentReference.id since in an MHD replace mechanism you will need to reference the previous documentEntry and in FHIR you have to do it using the resource id.

Gregorio

[John Moehrke]

That was the one case I was thinking that entryUUID was needed... but in that case I would expect the MHD Document Consumer/Source would do the replacement linkage the way we have defined using the DocumentReference.relatesTo with a FHIR Reference. Not using the entryUUID....   We never tell the reader about using entryUUID, and it is not clear how that would work anyway. So, I don't see this use-case as driving for the use of entryUUID.

(Note that a smart MHD Document Responder as an API to XDS would use the XDS entryUUIDs in their MHD .id values. But we didn't put this in as it is not necessary, and because of encoding issues related to OID vs id).

Others, please weight in. It feels like this is something we should fix soon.

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

[Elliott Lavy]

You need the entryUUID if you're going to RPLC/XFRM the documentEntry or add it to a folder or create any other Association.

Elliott

This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc.​ If you prefer not to be contacted by Harris Operating Group please notify us. This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.

---

From: iti...@googlegroups.com <iti...@googlegroups.com> on behalf of John Moehrke <johnm...@gmail.com>
Sent: Friday, September 24, 2021 6:57 AM
To: Gregorio Canal <gca...@consorzioarsenal.it>
Cc: slag...@epic.com <slag...@epic.com>; IHE ITI Technical Committee <iti...@googlegroups.com>
Subject: [EXTERNAL] Re: [ititech:8837] Re: XDS SubmissionSet uniqueId and entryUUID

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CACDGQjsSzQ18bx4zR_5Z3LArChb9kKwn_tXe-1EFacPryCKF3g%40mail.gmail.com.

[John Moehrke]

Elliott. I agree that the MHD Document Recipient grouped with XDS needs to do that. But the way that the MHD Document Source conveys these actions are using FHIR elements, not entryUUID.  The interface between MHD (FHIR) and XDS/XCA (ebRim) is where this needs to be addressed. Not at the edges (MHD consumers and sources).... I think.

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

[cha...@interopehealth.com]

 The major rationale for two different ID is to address two completely different aspects:

• first the unique identifier assigned to a document by the creator.

Téléchargez Outlook pour iOS

---

De : iti...@googlegroups.com <iti...@googlegroups.com> de la part de John Moehrke <johnm...@gmail.com>
Envoyé : Friday, September 24, 2021 2:29:14 PM
À : Elliott Lavy <EL...@harriscomputer.com>
Cc : Gregorio Canal <gca...@consorzioarsenal.it>; slag...@epic.com <slag...@epic.com>; IHE ITI Technical Committee <iti...@googlegroups.com>
Objet : Re: [EXTERNAL] Re: [ititech:8841] Re: XDS SubmissionSet uniqueId and entryUUID

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CACDGQjvuLSZPNHUA4XUV0z2ei_qthbRzpMjyBRF-FCRKaTBsMA%40mail.gmail.com.

[cha...@interopehealth.com]

 

 The major rationale for two different ID is to address two completely different aspects for the document:

• first the unique identifier assigned to a document by the creator.

• Second the unique identifier for the document registry entry that points to a document.

The same for the SubmissionSet Id versus SubmissionSet UUID.  The Later is a Registry Entry identifier, that includes a set of document registry entries versus the SubmissionSet as an object made of a collection of Documents.

We have here the design paradigm of XD* which clear splits the shared objects naming domain external to XDS and the objects naming related to the sharing mechanics. In other term XD* is not an imperialist design.

As we bring FHIR as a sharing mechanics, it is critical not to succomb to the FHIR imperialistic view of the world.  MHD or MHDS should not assume that the shared documents are always identified the way FHIR documents are preferably identified.

 

Does that help ?

Charles

[John Moehrke]

Charles,

That philosophy is not in question. The FHIR model has the very same concepts. The concepts are aligned, the technical implementation is conceptually aligned.  MHD very strongly leverages the Volume 3 abstract model.

The question is: Given that FHIR has these same concepts that the MHD client knows how to manipulate for all the use-cases; why does the client need to be exposed to the entryUUID values that the MHD client has no idea what to do with them and couldn't do anything with them even if it could.    

To repeat, all of the Document Sharing use-cases and abstract concepts are available in the FHIR model MHD uses. There is no misalignment of concepts.  Indeed MHD includes a new section to Volume 3 that shows the FHIR binding to the abstract model, very similar to our section that shows the binding of the eb-Registry model to the abstract model.

so it is not a question of model... it is a question of why are we exposing a eb-Registry specific value that has no meaning and no purpose in the MHD space.  The interface between MHD and XDS does need to deal with this change of concrete models. My understanding is that this is possible without carrying the entryUUID along, and indeed there are dangers to carrying the entryUUID along.

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

[Elliott Lavy]

Conceptually, the entryUUID IS the MHD .id.  Within XDS, it's the unique identifier for a registry entry.  I understand that it cannot be represented as such due to format restrictions.

 

In the absence of an XDS back-end, entryUUID probably has no value.  If there is an XDS back-end and you want to do anything with Associations (create and/or interpret), you need to know the entryUUID.  If you don't care about Associations, then you can probably ignore entryUUID.

 

Elliott

 

This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc.​ If you prefer not to be contacted by Harris Operating Group please notify us. This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.

[John Moehrke]

The Document Source indicates that the new DocumentReference is a replacement for a former DocumentReference using the former DocumetnReference.id value.    The Document Recipient is expected to convert that former DocumentReference.id into the entryUUID as necessary. The Document Recipient is both MHD and XDS aware. so it can do this translation. The MHD Document Source does not need to be bothered with this, and if it was bothered with this it would need to dual code in both FHIR encoding and eb-Registry encoding.

[Ben]

Maybe walk the swim lanes and see if they all work without the UUID getting back to the consumer?

[John Moehrke]

Hi Ben,

I have, and as far as I can tell... there is no need to expose this to the MHD Document Source or MHD Document Consumer. There is nothing I can find that these actors could do with the value.  Everything they need to do, by use-case analysis, is done with the .id value. which is the same abstract model concept. Walked it with not just DocumentEntry but also SubmissionSet and Folder.  So I am either confused and needing guidance from other smart people, or have slammed into a mistake I made in the MHD profiles.

I have some people on zulip who are trying to implement MHD and they have no idea how to populate a required element that has no purpose. Their first reaction was to just put the document uniqueId value in as the entryUUID value.. Which, I see as clearly a bad idea... and that is what kicked off this whole idea of asking "why is this entryUUID mandatory for MHD clients?"

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

[John Moehrke]

I agree that this is necessary in the ITI-41. The same linkage is done using FHIR resource references in the ITI-65.... the MHD Document Responder when interacting with XDS as the XDS Document Source will need to create the entryUUID as the XDS specification defines, and reflect the FHIR resource references using the XDS mechanism.  So the responsibility is on the XDS Document Source, not on the MHD Document Source. The MHD Document Source already has requirements for the relationships between DocumentReference, SubmissionSet, and Folder. 

Similar will happen in the opposite direction between the XDS Registry and the MHD Document Consumer

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

--

[John Moehrke]

We in the smallest way possible cover this... but never say things as bluntly as to mention entryUUID... and I clearly never quite understood this well enough to stop making it mandatory. 

https://profiles.ihe.net/ITI/MHD/ITI-65.html#23654131-grouping-with-actors-in-other-document-sharing-profiles

The Document Recipient shall transform the Bundle content into a proper message for the Given grouped Actor (e.g. the XDS Document Source using the Provide and Register Document Set-b ITI-41 transaction). The Document Recipient shall create appropriate metadata from Resources in the FHIR Bundle Resource, including SubmissionSet, DocumentEntry, Folder, and Associations.

If the Provide Document Bundle Message contains a DocumentReference with a relatesTo element, the code shall be translated using the AssociationType vs RelatesTo ConceptMap.

The Document Recipient shall map Folder type List Resources in the Bundle Resource to XDS Folders, as specified in ITI TF-3: Table 4.5.1.1-1. The Document Registry may apply further constraints on Folder content and revision, for example removal of entries from Folders is not generally allowed.

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

[John Moehrke]

I have captured this discussion in an MHD issue. comments and improvements welcome.

https://github.com/IHE/ITI.MHD/issues/92

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