Stream: implementers
Topic: DocumentReference relatesTo
Amy Allen (Jan 25 2022 at 18:55):
Looking for some details and input for how to connect documentreference entries using the relatesTo element.
The use case we are needing to accommodate is this - User creates a document entry in the system and saves.
This is saved into the database and assigned an ID, for example ID 25.
User then selects to append to the original document (ID 25) by entering an amendment.
Amendment is saved into the database and assigned an ID, for example ID 45.
So these are saved as unique, separate entries but we have a designation in the db that links the documents together.
In our system we would present these together for viewing to show the complete documentation.
Our understanding of the FHIR spec is that we would use the relatesTo element on the second document,
the amendment (ID 45) using a code of "appends" and target reference to the first original document (ID 25).
QUESTIONS:
Is our interpretation accurate?
Is the relatesTo element the best way to connect these partial documents?
How do we indicate on the first original documentreference entry (ID 25) that there is a second,
amendment documentreference entry (ID 45) that completes the document and needs to be included for a full view?
Yunwei Wang (Jan 25 2022 at 19:17):
I think the solution is correct. You can use _revinclude: DocumentReference?_id=25&_revinclude=DocumentReference.relatesto
Elliot Silver (Jan 25 2022 at 19:35):
Amy Allen said:
How do we indicate on the first original documentreference entry (ID 25) that there is a second,
amendment documentreference entry (ID 45) that completes the document and needs to be included for a full view?
@Amy Allen, In case @Yunwei Wang's answer isn't clear enough, there is no need to update the first DocumentReference to indicate it has been amended. You can structure your search (as indicated) to that anything that relatesTo the DocumentReference is returned in the results. However, depending on whether your "amended" means "adds further content," or "replaces previous content" you may want to mark the orginal DocumentReference as with superseded status.
Amy Allen (Jan 25 2022 at 21:24):
Thank you for the response! I am taking this back to my team for discussion.
Brian Alper (Jan 26 2022 at 10:32):
Other resources (such as Composition and Citation) had the relatesTo element changed to use RelatedArtifact datatype in R5. RelatedArtifact.type has more codes available including amends | amended-with | appends | appended-with so you can document the relations in either direction. This was necessary because sometime the related artifact is not a FHIR Resource so you can not always control the preferred direction of relationship.
Elliot Silver (Jan 26 2022 at 14:02):
Is there a ticket to apply this to DocumentReference? We should be consistent. ( @John Moehrke )
John Moehrke (Jan 26 2022 at 14:11):
there is not a ticket. I didn't know that Composition did that. Unfortunate that RelatedArtifact includes a .document (Attachment) inside. This is going to make relatesTo rather confusing. Even in Composition this seems problematic. I think this use of the metdatatype should be thought thru a bit more. Might need a more trim version of RelatedArtifact that doesn't have this blob inside.
Brian Alper (Jan 26 2022 at 16:12):
If the related artifact is available as an attachment, how would you handle it otherwise? Or are you just suggesting RelatedArtifact.attachment would be a better element name than RelatedArtifact.document where the datatype for that element is Attachment?
Brian Alper (Jan 26 2022 at 16:12):
@John Moehrke
Lloyd McKenzie (Jan 26 2022 at 17:11):
We need to be very careful with RelatedArtifact. It should NOT be widely used as it's actually contrary to FHIR best practices. There are a few limited places where it makes sense (e.g. Citation), but it should absolutely not be something that sees widespread use.
Elliot Silver (Jan 26 2022 at 17:14):
At a quick glance, if it's in composition, it should be in DocumentReference. However, why we need it, and not just use DocumentReference isn't clear.
Brian Alper (Jan 26 2022 at 18:00):
RelatedArtifact is a Datatype and DocumentReference is a Resource. If the relation between artifacts does not require its own resource for exchange as a shareable unit, it seems preferable to use a Datatype to a new Resource. I believe the RelatedArtifact Datatype was developed for relations between artifacts in resources that are often not patient-specific (PlanDefinition, Library, Citation, Evidence, etc.)
Lloyd McKenzie (Jan 26 2022 at 18:31):
In general, we want relationships to be called out by explicit elements (one per relationship) that appropriately control cardinality, direction and mustSupport. We don't want bidirectional relationships. We don't want relationships that aren't "core" showing up as core elements. And we want it to be easy for profiles to place constraints on relationships. Using RelatedArtifact makes all of these things harder. So it should not be used most places.
John Moehrke (Jan 26 2022 at 18:46):
so then Composition should revert
Elliot Silver (Jan 26 2022 at 19:01):
Brian Alper said:
RelatedArtifact is a Datatype and DocumentReference is a Resource. If the relation between artifacts does not require its own resource for exchange as a shareable unit, it seems preferable to use a Datatype to a new Resource.
I don't understand this. We could make the same argument that all of Observation should just be made a datatype that can be included in Compositions.
I believe the RelatedArtifact Datatype was developed for relations between artifacts in resources that are often not patient-specific (PlanDefinition, Library, Citation, Evidence, etc.)
There's nothing about DocumentReference that requires it be patient-centric. IHE even has the NPFS profile of DocumentReference that is specifically tailored for non-patient documents.
Brian Alper (Jan 26 2022 at 19:53):
The relatesTo element and RelatedArtifact Datatype are primarily about the relationship between artifacts/resources, and the Observation and DocumentReference Resources are primarily for the artifact/resource itself, so one does not replace the other. There are schemas like Scholix (http://www.scholix.org/) that represent the relationships/links between artifacts/resources as separate entities but I don't think there is an intention in FHIR to create a Resource to represent the links between resources.
John Moehrke (Jan 27 2022 at 16:57):
I am worried about all of the multi-directionality in the valueset that RelatedArtifact supports. It does not support a deterministic method that FHIR RESTful directionality modeling relies on. Pointers should be a deterministic direction, usually from the resource that is created later toward the resource that was created before. These can be navigated both directions.
Last updated: Apr 12 2022 at 19:14 UTC
