Family Relationships
Introduction
Delivering healthcare often involves more than a single patient. Spouses, parents, guardians, children, siblings, and even friends can be involved in delivering care and providing financial support.
The FHIR specification provides a number of Resources for modeling interpersonal relationships between patients and other people, and having your data well modeled helps you remain compliant and report compliance metrics such as CMS queries. But how you use these tools will depend on your specific clinical setting and workflow.
This guide provides a framework to help you decide how to model your patients' family relationships, and recommends a few approaches that our users have found useful.
In this guide we will use the term "family member" throughout, as modeling families is a very common use case. However, the same data models can be used to model legal guardians, non-family caregivers, and any other individuals related to the patient.
Use Cases
- Pediatric Health
- Neonatal Health
- Family Medicine
- Group Therapy
- Clinical Trials and Population Health
This guide will show you
- The key FHIR Resources used to model relationships
- A decision guide for how to choose the right data model for your use case
- Recommended approaches for modeling family relationships in FHIR
- Example use cases and queries for each approach
Key Resources
| Patient | This resource represents a human who receives clinical services such as physician visits, medications, diagnostic labs, and/or imaging. |
| RelatedPerson | This models the relationship between two people. For simple use cases, you can store demographic and contact information directly in the RelatedPerson resource itself (see below). |
| Group | The Group resource provides a single resource to reference a collection of individuals. It can be used to model the family unit as a whole instead of a collection of individual resources. |
Decision Guide
How you decide to model family relationships will depend on your clinical setting, your workflow, and your patient population. Below, we provide a few best-practice modeling approaches, as well as questions you can answer to figure out which approach best fits your use case.
These models are just starting points - you can mix and match these strategies to model your data according to your use case.
Do family members participate in clinical or financial activities?
The first question you should ask yourself is whether or not you need track family members' participation in "clinical or financial activities."
Some examples of such participation include:
- Family members attend physician visits with the patient
- A family member is the primary policyholder on the patient's insurance
- A family member is responsible for administering care or medication to the patient
- Family members undergo diagnostic testing or medical imaging to help diagnose and treat the patient
Often times, family members only serve as points of contact but do not participate in clinical and financial activities. In those situations, Approach #1 provides the simplest modeling approach that avoids using many different resource types.
How often will multiple Patients (e.g. siblings) share family members?
If your patients' family members do participate in clinical/billing activities, the next question is how often patients share family members. This tends to happen more frequently in pediatric and family medicine settings. For example, two siblings might be enrolled as separate patients in a pediatric clinic, but they share the same mother and father.
In these situations, it is desireable to "factor out" demographic and contact information for each family member into a single resource to make it easier to maintain, as outlined in Approach #3. However, this approach has some additional complexity since they another resource type to the model.
Is the subject of the treatment an individual patient, or a family unit?
In most cases, the focus of each clinical activity will be a single patient, even if multiple patients participate in the care plan. However, in some cases, the beneficiary of the treatment is the family unit as a whole, not the individual members. This is most common in family behavioral therapy scenarios, where the clinical objective is to help treat behavior of the family as a whole, rather than any specific individual.
Determining whether whether the subject of treatment is an individual or a group can be subtle. One way to do this is to think about your most common query patterns. If you are frequently querying for all activities related to an individual, it makes more sense to model the subject as a Patient, with other Patients as participants.
In contrast, if you're frequently querying the activities of the entire family, you can create a Group resource to treat the family as a single clinical unit, as detailed in Approach #4.
Data Models
After you've answered these questions about your use case, you're ready to make some decisions on how to model your family relationships. Below, we've recommended a few data modeling schemes, but these are not mutually exclusive. You may choose to mix and match the approaches, depending on your use case.
Approach #1: Patient with Contact Information
If your family members do not participate in clinical/billing activities and patients rarely share family members, the simplest approach is just to store information about family members directly on the Patient resource.
The Patient.contact property can store a list the following information about each family member:
| Information | Property |
|---|---|
| Name | Patient.contact[i].name |
| Gender | Patient.contact[i].gender |
| Address | Patient.contact[i].address |
| Phone Number | Patient.contact[i].telecom |
Patient.contact[i].telecom | |
| Relationship Type | Patient.contact[i].relationship |
The benefits of this approach is that you only need to manage one resource type, the Patient, which makes your API calls very simple.
The tradeoff is that if patients share family members (e.g. siblings share the same parents), you'll have to duplicate that family's contact information on each Patient.
| Pros | Cons | Use If | Example Use Cases |
|---|---|---|---|
|
|
|
|
Approach #2: RelatedPerson ➡ Patient
If family members do participate in clinical/billing activities, then it might make sense to model them explicitly as a separate resource.
You can model a family member explicitly as a RelatedPerson resource. The RelatedPerson has one required field, RelatedPerson.patient, which is a reference to the target patient. The RelatedPerson.relationship property is a CodeableConcept that can be used to specify the relationship type. In simple use cases where patients rarely share family members, then you can store basic demographic information and contact information directly in the RelatedPerson resource.
This pattern, along with Approach #3, is especially useful for situations where parents are logging in on behalf of minors. In these settings, the patient, a minor, can be modeled as a Patient, and their parent/legal guardian would be a RelatedPerson. Medplum allows users to be registered either as a Patient or a RelatedPerson (see the user invitation tutorial), and you can create an Access Policy to allow the parent access to minor's clinical information.
This approach is also useful to model different insurance coverage for dependents. You can model the coverage using the Coverage resource, with the Patient as the Coverage.beneficiary and the RelatedPerson as the Coverage.subscriber.
The benefit of this approach is that you can track the family member's role in clinical and billing activities independently of the patient.
The tradeoff is that is that you need to maintain the RelatedPerson resource in addition the Patient Resource.
Each RelatedPerson can only have one patient associated with them it. This is because RelatedPerson is meant to model the relationship between a family member and a patient. Even if two patients the same family member, you'll have to create a new RelatedPerson for each (patient, family member) pair to model each relationship.
| Pros | Cons | Use If | Example Use Cases |
|---|---|---|---|
|
|
|
|
Approach #3: Patient ➡ RelatedPerson ➡ Patient
If your practice begins to have patients who share family members, duplicating their contact information across multiple RelatedPerson resources can quickly become error prone.
For example, consider two Patients who are siblings and share the same father. Because a RelatedPerson resource models the relationship between a person and a Patient, each sibling would need it's own RelatedPerson resource linking them to the father (as shown the the diagram). However, Approach #2 duplicates the father's contact information on each RelatedPerson. If the family moves, you will have to ensure that this address information is updated in both places.
To avoid this duplication, we can "factor out" the father's demographic and contact information into a separate Patient resource. The Patient is then connected to the RelatedPerson using the Patient.link.other property (with Patient.link.type set to "seealso"). This avoids the data duplication, at the expense of adding one more layer of indirection.
In this model, the RelatedPerson does not store specific information about the father. It only stores the relationship between the father and child.
A common use case for this approach is in neonatal care. Many common neonatal workflows, such as newborn hearing tests, postpartum-depression screening, and breastfeeding metrics all require modeling both the mother and child as patients to track their individual encounters, medications, labs, and imaging.
The FHIR spec also allows the use of the Person resource to factor out demographic information. While this is a valid approach in cases where an individual can be both a Patient and a Practitioner, Medplum generally doesn't recommend the additional complexity of mixing Patient and Person resources.
| Pros | Cons | Use If | Example Use Cases |
|---|---|---|---|
|
|
|
|
Approach #4: Group of Patients
For some use cases, it is useful to keep track of the family unit as a whole, rather than as a web of connected Patients, RelatedPersons, and Persons.
The Group resources allows you to specify a single resource that represents the group of people as a single unit, and in some places can be used instead of the Patient resource. Some common examples are:
| Use Case | Group referenced by |
|---|---|
| Family therapy office visit in which the subject of the visit is the entire family, not just the individual members. | Encounter.subject |
| Measuring the effects of a drug administered to a patient population during a clinical trial. | Condition.subjectMedicationDispense.subjectObservation.subject |
For a group of specific individuals, each group member is referenced in the Group.member.entity property.
You can also use the Group resource to model abstract groups, where the specific members are not clinically or financially relevant. To indicate that the group us abstract, set Group.actual to false.
Some examples of abstract groups are:
- A support group like Alcoholics Anonymous.
- A generalized population of patients for a clinical trial.
- A herd of animals for veterinary use cases.
Adding a Group resource for your families an orthogonal choice to Approaches #1-3. You may choose to model the individual relationships via RelatedPersons and also consolidate the entire family into a group. If modeling family groups is important, Medplum recommends modeling all the individuals as Patients, and then referencing them in the Group.member.entity array. If required, Patients can also belong to more than one Group
In the case of abstract groups, you can use the Group.quantity field to record the size of the group, which may be important for analytics or billing workflows.
| Pros | Cons | Use If | Example Use Cases |
|---|---|---|---|
|
|
|
Conclusion
The FHIR spec allows for many different configurations to model family relationships, with different levels of power and complexity. We hope this guide provides some clarity on how to choose the best model for your use case. When in doubt, the Medplum team recommends starting simple, and migrating to a more complicated model over time. If you have any questions about your specific use case, feel free to reach out on Discord or at support@medplum.com.