I’ve been researching the topic of “Managing Family Units” in FHIR as a part of product research for a while and here are a couple of challenging questions around data modeling of the family unit and relationships in general:
Using Link.other or. contact.extension.related-person?
From the following FHIR link: “The link element is used to assert that patient resources refer to the same patient”.
To me that is a clear indication that the Patient.link should NOT be used to manage family relationships.
On the other hand, I do see the following usage of the Patient.link to document mother-newborn relationship (is this an outlier due to the sensitive nature of the new-born phase?)
The other alternative for effectively managing family relationships is via Patient contact.related-person extension.
This seems to be very logical though it does carry a few data challenges:
contact.relationship dataset is limited to Next Of Kin as the closest type. Is anyone I consider family considered NOK? An uncle I am helping to manage care for? Foster child? etc.
As an extension, is it harder to make use of _include and _revinclude in searches for easily looking up family relationships?
any other thoughts on a preferred approach?
Managing family relationships
Let’s take a simple case of a Mother and two children (Son and Daughter).
The explicit relationships known to us are from the mother’s input in a registration system:
Mother-to-Son (Child)
Mother-to-Daughter (Child)
Both documented in the following manner:
Create the 2 Patient resources that represent the mother and the child, then create a RelatedPerson resource that directly references the child (the ‘to’ of the relationship) through the RelatedPerson.patient element, and then use the mothers Patient.link to refer to that RelatedPerson (the ‘from’).
But since we know both children have a common parent we COULD also create the following 4 explicit-implicit relationships:
Brother-to-sister (sibling)
Sister-to-Brother (Sibling)
Son-to-Mother (Parent)
Daughter-to-Mother (Parent)
This would ensure that all relationships are documented for all persons bi-directionally (without making any unreasonable inferences.
What are the benefits drawbacks of creating and managing so many relationships that grow exponentially with every addition of a family member? What would the diagram above look like when adding another parent/child?
What limits (legal/practical) exist on inferred relationship types that have not been formally defined (brother-sister example above)?
Other thoughts and comments?
Thank you for your time and thinking into this topic,
Patient.contact - used to capture people who might be contacted about the patient’s care - could be parents, children, neighbor or anyone else. There’s enough information to contact them, and that’s about it. In many systems, this is all you’ll have
Patient.ink - used to link mother to child via a “see also” link in newborn encounters (where the record for mom often contains information about the fetus)
RelatedPerson - used to link people who ‘act’ in a healthcare context. I.e. performers, informers, recipients, witnesses, etc. If you’re acting on behalf of the patient based on personal relationship, you’re represented as a RelatedPerson - though it might be a ‘contained’ resource if there isn’t a specific record
FamilyMemberHistory - captures health information about a patient’s relatives
Very sophisticated systems (that can handle the potential privacy issues) MAY link Patient to RelatedPerson either directly through Patient.link or via Person to say “This RelatedPerson who is the patient’s mom is the same as Patient #123 in our system”. The Person approach allows maintaining shared demographics and contact information irrespective of role. (Technically, it’ll allow sharing information with Practitioner instances too.) There still need to be tight boundaries around information sharing. The RelatedPerson and FamilyMemberHistory resources are ‘owned’ by a single Patient and access to them is through that patient’s record. There might be a mirroring RelatedPerson in a relative’s patient’s record, but that one is owned by them. What’s asserted about a relative in FamilyMemberHistory of a patient might be quite different than what that family member’s on patient record says. And, due to consent and privacy considerations, the discrepancy isn’t something that can generally be corrected.
Thanks a lot, @lloyd for your responses.
I appreciate the overview.
The business requirement we are trying to account for is a family administrator (e.g. mother) to access and manage appointments and health records (of a child or other dependent) through our enterprise application. Members of the family may or may not share demographics and we want to maintain those separately.
Both the family administrator and dependents MAY be known patients in our system.
So I’m trying to design some version of:
‘link Patient to RelatedPerson either directly through Patient.link or via Person to say “This RelatedPerson who is the patient’s mom is the same as Patient #123 in our system”.’
Two questions and a comment:
Patient.link (a repeated question but want to make sure I fully understand your reading of it) - mother-newborn relationship aside (which is special and temporary), should Patient.link (“see also”) be used to describe linking to multiple RelatedPersons who do NOT "refer to the same patient” as the specs define?
Could we leverage the Group resource to achieve the family relationship mapping by extending it to include relationship types between its members and the group administrator? This approach would reduce the required resource management and mirroring between related Patient resources.
FamilyMemberHistory will not fulfill our requirement but is indeed very useful for clinical care purposes.
My reading is ‘no’, but I’ll get someone from the Patient Administration work group to respond authoritatively
Group is intended for things like “this cage of rats”, “everyone signed up for the smoking cessation workshop”, “males between the ages of 35 and 50 with type 2 diabetes”, or “everyone within 2 miles of the spill”. You certainly could have a Group that is “all people who can be administered by person XYZ”, but capturing the individual personal relationships wouldn’t really make sense.
You might also look at Contract or Consent. They allow you to assert formal relationships between multiple parties. If you want to capture a record that says “this person has the authority to act on behalf of these other people”, that would be a way to represent the legal relationship. It wouldn’t necessarily expose the personal relationship though.
Would love to hear back from the Pat Adm WG on that topic. I have spoken recently with a couple of folks whose assessment was that Patient.link would be the place to go for linking to family members. My sense is that a bit more clarity and consistency on the intended and unintended uses of Patient.link would be helpful in the specs. In particular, the mother-newborn examples seems to be opening the gate to a wider adoption of Patient.link as a catch-all mechanism.
Will go study Group, Contract and Consent more closely in this context of family relationship and granting management.
Your top diagram is pretty close - in terms of resources, it is spot on. The only change that I would make is that you’ve labelled the yellow RelatedPerson hexagons with 2 way relationships, where it is a single relationship.
Lower 2 would be of relationship type “sibbling” or “brother” / “sister”
Outer 2 would be either “child” or “son” / “daughter”
Upper 2 would be “mother” or “parent”
If you consider this as a database ER diagram, the RelatedPerson is the many to many link table that has the relationship type on it. And there is just enough detail on it to be able to function without having the linked entity too.
As for the patient.contact - that travels around with the patient everywhere and is really there to assist in knowing who to contact for specific reasons. (the extension from the patient.contact to the related person assists in cases where you want to manage that data and the linkage is known - sometimes a contact number is all that is known/needed)
In short, patient.link and person both join instances of the same individual represented in multiple resource instances, they do not link to different people.
I’d qualify that last paragraph a bit. In the case of mother & newborn, they are indeed “different people”, however they’re being linked because they may share information from the same ‘chart’.
Thank you @brian_pos for that great info and validation. Agreed that the diagram would be improved by referencing the appropriate relatedperson-relationshiptype rather than the labels assigned to the 3 patients.
I must say, though, your last paragraph left me in limbo since after confirming the theoretical accuracy of the diagram, your summary clearly states that the Patient.link should “not link to different people” thus rendering the diagram fundamentally wrong.
So to put a pin in it: is it correct that while the diagram might be technically accurate, we SHOULD NOT implement such logic? And if so, how would one most aptly describe a family unit allowing for clearly defined relationships in your opinion? I would add that we wish to grant (perhaps via Consent resource) to some family members (parent, legal guardians, etc.) access to medical information of other members (children, power of attorney scenario, etc.). One such idea is the Group resource.
Again thank you for your thoughtful responses, Yuval.
The RelatedPerson (name property on this resource) and the Patient joined by the link property represent the same individual. (and also a Person resource referencing a Patient via Person.link is also the same individual)
However the Patient linked to the RelatedPerson via the RelatedPerson.subject are different people.
The RelatedPerson can stand alone and does not require the Patient (mother) to exist
Patient.link joins the same individual, RelatedPerson.subject associated different people (with relationship describing how)
This was super helpful @brian_pos. You readjusted my perspective on the boundary between the related-person resource and the actual patient it refers to.
In other words, the Patient.link to a RelatedPerson is augmenting our understanding of the SAME Patient’s familial relationships (in my use case) with or without an actual patient being pointed to by the RelatedPerson.patient.
This part of the diagram then is sufficient for a consuming application to reconstruct the mother’s with a Patient.link “see also” type.
Thanks a bunch for seeing this topic through with me, Yuval.
