Stream: implementers
Topic: Document Reference
Jeremy Chapman (Sep 09 2019 at 18:36):
I have a cda document and several related attachments (pdf, etc). I'm planning out a messaging system. MessageHeader.focus points to a Communication resource. I will have a payload in the communication resource with a contentReference element referencing a DocumentReference entry, which contains an attachment element with a url pointing to the cda document.
For the attachments, should I reference those from within the Communication resource using a payload element with a contentAttachment, or should I reference them using additional content.attachment elements inside the DocumentReference. On one hand, putting all the content.attachment elements inside a single DocumentReference encapsulates them, which makes sense because they have a relationship together. But referencing seperately them in the communication resource distinguishes them between the primary document (via the payload.contentReference pointing to the DocumentReference entry) and the attachments (via the payload.contentAttachment). Any advise?
Lloyd McKenzie (Sep 09 2019 at 19:01):
What's the purpose of the Communication resource in your instance? (A message is itself a type of communication and identifies sender and recipient)
John Moehrke (Sep 09 2019 at 19:30):
Within the IHE specifications this use-case is defined in the MHD profile. It uses an Operation with one DocumentManifest, 1..* DocumentReference, 1..* Binary, and 0..* List. The document bits are always carried in a Binary, never using the attachment data element. The DocumentManifest is used in the way you describe for Communication. The List is available for supporting the concept of Folders. All aligned with XDR and XDS.
John Moehrke (Sep 09 2019 at 19:31):
https://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)
Jeremy Chapman (Sep 09 2019 at 20:33):
@Lloyd McKenzie Does the message identifier sender AND recipients (multiple)? I see the message header has sender and destination, but destination seems more system oriented even though it has receiver. We have multiple recipients and it seemed that a communication resource modeled what we wanted better. In one use-case we would have a lab report sent to 1 or more providers. It seemed that would be a style of communication where the lab report is the main aspect of the communication.
Lloyd McKenzie (Sep 09 2019 at 21:39):
MessageHeader.destination includes both the technical destination "endpoint" as well as a list of Practitioners/Organizations who are the real-world recipients.
Jeremy Chapman (Sep 10 2019 at 15:04):
It's interesting. I noticed that The Communication resource can have recipients that are a superset of what MessageHeader.destination.receivers can have. We have a Care Team concept, which only seems to apply to that resource. So even if you have a communication resource, should you still populate the MessageHeader.destination.receivers? I'm trying to get a clearer understanding of when you would use one or the other. are there example use cases described somewhere which would help contrast the two approaches?
Jeremy Chapman (Sep 10 2019 at 15:14):
Butt getting back to attachments... if I use a communication resource should I reference those from within the Communication resource using a payload element with a contentAttachment, or should I reference them using additional content.attachment elements inside the DocumentReference. I'm not clear on what should guide my decision
Lloyd McKenzie (Sep 10 2019 at 15:25):
If you have a message whose focus is a Communication, what you're typically doing is saying "Tell the users referenced in the message header that this information was communicated to the people listed in the COmmunication. I.e. the Communication is a record of exchange, not a mechanism of exchange.
Lloyd McKenzie (Sep 10 2019 at 15:25):
That's not the only way it can be used, but it's the main way it makes sense to be used when wrapped in a MessageHeader.
Jeremy Chapman (Sep 10 2019 at 16:14):
Great. Thanks for the explanation, very much appreciated. but why then can a destination only have 1 receiver? If I want to tell the users, a destination application could have more than 1 in the real world, but it's not modeled with that cardinality in MessageHeader.destination.receiver . I'm assuming when you say "users referenced in message header" you mean MessageHeader.destination.receiver...
Lloyd McKenzie (Sep 10 2019 at 17:47):
Good question. Suggest submitting a change request. If you're requesting an action, it often makes sense to limit to only 1. But if you're sending a notification, no reason not to have multiple
Last updated: Apr 12 2022 at 19:14 UTC
