Stream: implementers
Topic: document RelatesTo
Rik Smithies (Mar 10 2021 at 17:39):
Composition, and DocumentReference, have a relatesTo relationship. But the codes seem to be limited to versions or parts of the same document (replaces, transforms, signs, appends). Is it not meant for a general purpose link?
What is the way to say "this other document relates to this one". They may share a subject, but this would be a more precise link than "all the documents about a patient".
Lloyd McKenzie (Mar 10 2021 at 18:17):
In general, we prefer to avoid 'typed' relationships and instead have specific elements for each type of relationship
Rik Smithies (Mar 10 2021 at 18:36):
that makes sense. But in the absence of that, how then can this be achieved? The use case is that documents about products come in sets. It's not all the documents about a product ever, and it's not parts of one document. But documents can be released together such as the version with and without certain sections, or the version for experts and the version for patients. How could they be related to each other? The documents themselves have types, so if there was a general "other" relatesTo code, then you could see what other type you were linking to and it wouldn't be a semantic-less relationship overall.
Gino Canessa (Mar 10 2021 at 18:39):
Would a List of documents work?
Rik Smithies (Mar 10 2021 at 18:41):
I had considered that. To relate A and B would need A, B, a List, and maybe 2 DocumentReferences. A bit much and hard to query. But maybe the DocumentReferences are not needed, now I think of it.
Rik Smithies (Mar 10 2021 at 18:43):
but still it seems odd to have an element called Composition.relatesTo, and not be able to use it for a related Composition...
John Moehrke (Mar 10 2021 at 18:53):
How this would be done in an XDS world would be through a Folder. In FHIR we use List resoruce for the purpose of grouping DocumetReferenc resources into a folder
Gino Canessa (Mar 10 2021 at 18:53):
Fair enough. Could also try an extension on Composition to start (e.g., partOfGroup) and go for an addition to R5.
John Moehrke (Mar 10 2021 at 18:54):
To make that more clear, we group them by way of a List. This way the List can be modified independent of the DocumentReference
John Moehrke (Mar 10 2021 at 18:56):
The other possibility is to use the DocumentReference.context.related. This is used in XDS as well for grouping, and has the advantage that it is more flexibile to allow for a grouping accross many registries. The disadvantage is that it is harder to understand the reason for the related link
Rik Smithies (Mar 10 2021 at 19:54):
DocumentReference.context.related seems to have gone in R5 with no obvious replacement.
Is it necessary to use a DocumentReference to refer to a directly referenceable Composition (if I don't need the metadata that it offers)?
DocumentReference is intended as a FHIR enabling wrapper for "real" (non-FHIR) documents, at URLs, I assume.
I am thinking that a List of references to Compositions may do the job.
Gino Canessa (Mar 10 2021 at 19:54):
Is there a problem with List not being allowed as a target (e.g., can it be used as 'include all these docs')? If not, that may be awkward.
Rik Smithies (Mar 10 2021 at 20:18):
I'm not sure what you mean about List not being allowed as a target Gino?
You can (I assume) have a List of Compositions, that points to them as targets.
You could also have List of Compositions inside the Bundle, so that each document points to itself and all the others.
Updating that could be a problem however.
Elliot Silver (Mar 10 2021 at 20:57):
I believe DocumentReference.context.related has moved to DocumentReference.relatesTo, which allows specific relationships to other document references be listed, or DocumentReference.related which can point to any resource, but doesn't indicate the relationship.
Rik Smithies (Mar 10 2021 at 22:28):
thanks @Elliot Silver. But relatesTo only seems to allow links to what is essentially the same document (a version, a translation etc). Can you confirm that is the intention?
Elliot Silver (Mar 10 2021 at 22:33):
I believe that is the intention.
By the way, what relationship are you trying to model that can't be expressed using searches based on basedOn, type, category, encounter, event, practiceSetting, or the standard episode-of-care extension?
Rik Smithies (Mar 10 2021 at 22:34):
relations between the different documents that apply to drug products, such as the full data sheet and the one that the patient sees
Rik Smithies (Mar 10 2021 at 22:35):
these documents are not patient related, so those patient fields don't apply
Rik Smithies (Mar 10 2021 at 22:36):
I guess that normally clinical documents are linked by being in the same part of the patient record, so there has not been a need to group documents by other criteria
Elliot Silver (Mar 10 2021 at 22:36):
That could be modeled as a translation.
Rik Smithies (Mar 10 2021 at 22:37):
well it is not a literal translation. But that is another concept we may also need.
Rik Smithies (Mar 10 2021 at 22:38):
but if the sense of translation means "about the same thing" then it might work. but that isn't really what I understand by "translation"
Elliot Silver (Mar 10 2021 at 22:38):
Actually, the code is "transform" and I'd be happy to defend that use as a transformation of the document.
Rik Smithies (Mar 10 2021 at 22:39):
but then all documents are transforms of each other even if they are neither subsets or supersets. A bit of a broad definition :-) Certainly no machine could do the transform.
Elliot Silver (Mar 10 2021 at 22:41):
Or, look at using an extension for subject to point to the drug product resource, and the type/category of the document would indicate full or patient data sheet.
Rik Smithies (Mar 10 2021 at 22:44):
Composition.subject can already point at the drug, so that is ok. But the idea is not to find all the documents about the drug, but to have certain documents relate to others.
John Moehrke (Mar 10 2021 at 22:53):
DocumentReference.relatesTo is for lifecycle revisions and transforms of a document. That is why the .relatesTo.code valueset is so limited.
John Moehrke (Mar 10 2021 at 22:55):
the element name "relatesTo" might be the thing that is confusing. as it is really close to "baseOn" found in other resources. In DocumentReference the concept of "basedOn" is handled by the .context.related.
Rik Smithies (Mar 10 2021 at 22:55):
So it seems. That isn't conveyed well in its name or description however imho.
John Moehrke (Mar 10 2021 at 22:56):
please submit a CR with a recommendation.
Rik Smithies (Mar 10 2021 at 22:59):
in R4 I guess "basedOn" could be either relatesTo or Context, which is perhaps why only relatesTo is there in R5.
Rik Smithies (Mar 10 2021 at 23:00):
hard to think of a good name but maybe "relatedVersion" would work
Last updated: Apr 12 2022 at 19:14 UTC
