Stream: implementers
Topic: patient relationship differences
Tim Berezny (Dec 18 2019 at 00:06):
Why do patient.contact.relationship and. relatedPerson.relationship use different valuesets?
Lloyd McKenzie (Dec 18 2019 at 04:40):
RelatedPerson.relationship defines their basis for acting, while contact.relationship defines why you might want to contact them, so they're not identical use-cases. But I don't know why different code systems were chosen. @Brian Postlethwaite ?
Tim Berezny (Dec 18 2019 at 04:44):
@Lloyd McKenzie what do you mean by "basis for acting"?
Lloyd McKenzie (Dec 18 2019 at 04:46):
RelatedPerson is someone who can act on behalf of the patient on the basis of their relationship with the patient - that's the primary reason for the existence of the resource. They can report, perform, author, approve, etc. Patient.contact entries can't do anything - they can't be pointed to by any other resource.
Tim Berezny (Dec 18 2019 at 05:07):
Interesting, my reading of the opening paragraph to RelatedPerson gives me the opposite impression, that the patient.contact is the more "important" of the two options when it comes to doing actions (decision making vs "attribution of information") with the the patient.
Related Person Narrative
```RelatedPersons typically have a personal or non-healthcare-specific professional relationship to the patient. A RelatedPerson resource is primarily used for attribution of information, since RelatedPersons are often a source of information about the patient. For keeping information about people for contact purposes for a patient, use a Patient's Contact element. Some individuals may serve as both a Patient's Contact and a Related Person.
Example RelatedPersons are:
- A patient's wife or husband
- A patient's relatives or friends
- A neighbor bringing a patient to the hospital
- The owner or trainer of a horse
- A patient's attorney or guardian
- A Guide Dog```
Lloyd McKenzie (Dec 18 2019 at 05:08):
It's certainly possible for the same individual to appear in both places, but they can only be pointed to by other resources if they're a RelatedPerson.
Lloyd McKenzie (Dec 18 2019 at 05:08):
contacts is really just to provide a list of next of kin or other key people who might need to have information communicated to them.
Tim Berezny (Dec 18 2019 at 05:10):
Would it be fair to say that if i were to choose ONE way to communicate this type of information, that "Related Person" would be the generally more robust and flexible approach?
Lloyd McKenzie (Dec 18 2019 at 05:14):
You shouldn't plan to use just one way. You use Patient.contact for information about patient contacts. You use RelatedPerson for anyone who is authoring, performing, receiving or otherwise acting on behalf of a patient. Other systems are going to expect contacts to be in Patient.contact - they're not going to go searching for RelatedPersons. (And there may well be many contacts who don't have RelatedPerson records because they aren't 'actors'.)
Craig Newman (Dec 18 2019 at 13:16):
I asked a similar question a while back (https://chat.fhir.org/#narrow/stream/179166-implementers/topic/relationship.20in.20Patient.2Econtact.20and.20RelatedPerson) but I don't think we ever resolved it. In my mind there is a distinction between the relationship the person has to the patient and the role they play. An "aunt" may be an emergency contact or may be a guardian. The relationship is not necessarily indicative of a particular role.
Tim Berezny (Dec 18 2019 at 14:08):
I agree that the concept of "relationship" and "role" can be different things. The patient.relationship valueSet is conceptually sticks to just "role" (insurance, emergency contact) than a "relationship" (aunt, uncle, neighbour) - while the valueset for related person covers both of the concepts of role and relationship. Both lists are missing some fairly common and important roles like legal guardian, power of attorney, teacher, caregiver ...)
Brian Postlethwaite (Jan 08 2020 at 20:36):
And are both extensible too.
Last updated: Apr 12 2022 at 19:14 UTC
