Skip to main content

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.

Note

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

  1. The key FHIR Resources used to model relationships
  2. A decision guide for how to choose the right data model for your use case
  3. Recommended approaches for modeling family relationships in FHIR
  4. Example use cases and queries for each approach

Key Resources

PatientThis resource represents a human who receives clinical services such as physician visits, medications, diagnostic labs, and/or imaging.
RelatedPersonThis 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).
GroupThe 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.

Family members participate in clinical activities?Patients share family members?Focus of treatmentCommon Use Cases
Patient with Contact InformationNoRarelyIndividual Patient
  • At-home lab testing
  • Adult mental health therapy
RelatedPersonPatientYesRarelyIndividual Patient
  • Modeling insurance beneficiaries and subscribers
  • Parents acting on behalf of minors
PatientRelatedPersonPatientYesFrequentlyIndividual Patient
  • Pediatric Care
  • Neonatal Care
  • Family Medicine
  • Parents acting on behalf of minors
Group of PatientsYesFrequentlyFamily Unit
  • Family Counseling
  • Training & Education
  • Group Therapy
  • Population Health
  • Veterinary Care

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

Approach #1;

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:

InformationProperty
NamePatient.contact[i].name
GenderPatient.contact[i].gender
AddressPatient.contact[i].address
Phone NumberPatient.contact[i].telecom
EmailPatient.contact[i].telecom
Relationship TypePatient.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.

ProsConsUse IfExample Use Cases
  • Simplest data model
  • Single resource type to manage
  • Duplication of data for shared family members
  • Family members do not participate in clinical or billing activities
  • Patients share family members infrequently
  • At-home lab testing
  • Adult mental health therapy

Approach #2: RelatedPersonPatient

Approach #2

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.

Note

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.

ProsConsUse IfExample Use Cases
  • Simplest data model that explicitly models family members
  • Track the participation of family members in clinical activities
  • Family members do participate in clinical or billing activities
  • Patients share family members infrequently
  • Insurance coverage where the beneficiary (Patient) is not the insurance subscriber (RelatedPerson)
  • Parents acting on behalf of minors

Approach #3: PatientRelatedPersonPatient

Approach #3

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.

Note

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.

ProsConsUse IfExample Use Cases
  • Avoid data duplication for shared family members
  • Track the participation of family members in clinical activities
  • Adds another layer of indirection compared to Approach #2
  • Family members do participate in clinical or billing activities
  • Patients often share family members
  • Pediatric Care
  • Neonatal Care
  • Family Medicine
  • Parents acting on behalf of minors

Approach #4: Group of Patients

Approach #4

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 of people as a single unit, and in some places can be used instead of the Patient resource. Some common examples are:

Use CaseGroup 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.subject
MedicationDispense.subject
Observation.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.

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.

ProsConsUse IfExample Use Cases
  • Single resource to reference the complete family group
  • Can be used to model abstract groups
  • Doesn't model specific relationships between individuals. Need to supplement with Approaches #2 or #3
  • Focus of clinical, billing, or analytic activities is the family unit / group.
  • Family Counseling
  • Training & Education
  • Group Therapy
  • Population Health
  • Veterinary Care

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.