Skip to content
This repository has been archived by the owner on Jan 9, 2023. It is now read-only.

Make Patient relationships mutual / bidirectional #398

Open
JDarke opened this issue Jul 9, 2020 · 4 comments
Open

Make Patient relationships mutual / bidirectional #398

JDarke opened this issue Jul 9, 2020 · 4 comments
Labels
needs requirements to be scheduled Issues that still need to be analyzed to be properly conveyed to one or more repositories
Projects

Comments

@JDarke
Copy link

JDarke commented Jul 9, 2020

馃殌 Make Patient relationships mutual / bidirectional

Adding Patient B as a Related Person of Patient A should also add Patient A as a Related person to Patient B, with the appropriate Relationship Type also recorded.

Motivation

Having to record the same relationship twice on two separate records creates extra work for the user.

Example

Currently, if John Doe is added as a related person on Jane Doe's record, this relationship will not be recorded on John's record.

When a relationship is defined in a Patient record, that relationship should be mirrored on the record of the related person.

Further Considerations:

Not all relationships are 'symmetrical', so reference tables will need to be defined to determine the proper labelling, such as:
Partner : Partner
Spouse : Spouse
Sibling : Sibling
Parent : Child
Grandparent : Grandchild
Cousin : Cousin

Things get a little more complicated if gendered versions of the words are needed, especially for Uncle/Aunt/Niece/Nephew, which don't have commonly known gender-neutral equivalents (at least in English), but presumably we'd need a customisable "Other" option to cover all possibilities, anyway.

Further discussion and user stories are required to determine the most appropriate approach to the relationship system.

May affect or be affected by HospitalRun/hospitalrun-frontend#2106

@matteovivona
Copy link
Collaborator

@fox1t Is this just a frontend feature?

@JDarke
Copy link
Author

JDarke commented Jul 9, 2020

I would think so, but I'm not familiar enough with the back end to say for sure.

@blestab
Copy link
Contributor

blestab commented Jul 10, 2020

Great idea @JDarke

Just to add to that, since relationships are free text and trying to cater for all possible mappings might be not so easy to manager, we could consider having the reverse relationship set to be a generic "Related To" i.e.

If John Doe is entered by the user as Spouse to Jane Doe, Jane Doe's related person link back can easily be derived to also be Spouse but in cases where it's not so easy to derive the return relationship then we assume "Related/Relates To" and the good thing is the nature of the relationship can always be derived from the original link the user defined.

e.g. Peter Pan is related to Jane Salt via relationship nephew Jane Salt's link back to Peter will be defined as "Relates To" and if one wants to know the nature of this relationship they can look to Peter Pan's record which will have the nephew ie, Jane Doe "Relates To" nephew Peter Pan.

On the question of whether server or frontend feature, sounds like this feature can be wholly managed in the frontend as by the time the data gets to the server the relationships are all setup as desired?

@matteovivona matteovivona added this to To do in Version 2.0 via automation Jul 11, 2020
@matteovivona matteovivona added needs requirements question Further information is requested to be scheduled Issues that still need to be analyzed to be properly conveyed to one or more repositories and removed question Further information is requested labels Jul 11, 2020
@JDarke
Copy link
Author

JDarke commented Jul 11, 2020

Yes, nice one @blestab !

I like the generic 'Related To' idea.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs requirements to be scheduled Issues that still need to be analyzed to be properly conveyed to one or more repositories
Projects
Version 2.0
  
To do
Development

No branches or pull requests

3 participants