Stream: implementers
Topic: Patient.link to a RelatedPerson
Josh Mandel (Jul 09 2021 at 16:29):
Looking at the definitions for Patient.link
, all the link types (replaces
, replaced-by
, refer
, seealso
) explicitly describe linking from a Patient to a Patient. When/how would linking to a RelatedPerson occur? The comment at http://hl7.org/fhir/patient-definitions.html#Patient.link.other mentions "Referencing a RelatedPerson here removes the need to use a Person record to associate a Patient and RelatedPerson as the same individual.", but I'm not clear on where or how this would happen.
Maybe it's designed for scenarios like: Alice is a patient, and Alice is also a caregiver for Bob, so we'd have 3 resources
Patient/alice
: links asseealso
toRelatedPerson/alice-as-caregiver-for-bob
Patient/bob
RelatedPerson/alice-as-caregiver-for-bob
It's not clear to me that this is a good/helpful thing to declare in Alice's Patient record. Are there real-world systems that use this behavior today? If so we might want to update the link types to reflect this usage; if not we might want to deprecate this usage.
Lloyd McKenzie (Jul 09 2021 at 17:35):
@Brian Postlethwaite ?
Brian Postlethwaite (Jul 10 2021 at 00:15):
You're exactly right that this is the case that it's there to cover.
And I thought there was an example on that page like that, with mother and child, which would be common in maternity. Both exist as patients, and the relationship too.
Brian Postlethwaite (Jul 10 2021 at 00:17):
We could clarify that text a little further though.
Brian Postlethwaite (Jul 10 2021 at 00:18):
We definitely have that linkage in our DB on multiple independent products in our portfolio too.
@Cooper Thompson (and others) do you guys store that linkage internally too?
Josh Mandel (Jul 10 2021 at 03:38):
If this is an intended use case, the text I want to clarify is on the codes in the link type value set, so it's clear which would apply (also giving a more detailed example in the element definition couldn't hurt).
Last updated: Apr 12 2022 at 19:14 UTC