InterweaveRelatedPerson

FHIR Profile

Definition Information about a person that has a relationship with a patient. The person may be involved in the care or support of a patient, but is not the target of the care/support.

Notts Guidance

NB: Whilst the term "Patient" is used by FHIR, the profile is equally relevant to a "citizen", "service user" or "client" in other contexts such as Social Care.

This profile sets minimum expectations for the RelatedPerson resource to record information about a person who has a relationship with a patient. The related person is always defined from the position of the patient e.g. This related person is the patient's mother, spouse, brother, neighbour etc.

Relationship v Roles(s)

In addiiton to the 'personal' relationship (i.e. family member, freind, neighbour, roommate etc.) that is shared as the RelatedPerson.relationship (using the PatientRelationshipType ValueSet), the related person may also provide one or more specifc roles with regards to the Patient. These roles (along with the contact details) will often be the most valuable to data consumers - for example, undertanding that the related person is the carer, or has lasting power of attorney for the Patient.

The ful list of roles is detailed below - Data Providers may choose to only map and provide a subset of the related persons from thier line of business systems

Note: if ‘Other’ is used, then it is essential to provide additional detail of the role within the text field

Mandatory fields

The following fields are mandatory:

• name - "usual" name, what they liked to be known as, including given and family names. Its only relevant to capture the person's current name, no history is required.

• active - A mandatory flag to indicate whether the relatedPerson record is active.

• patient - To whom this person has a relationship with.

• relationship - How this person is related to the patient e.g. mother, spouse, brother, neighbour etc.
  Uses the PatientRelationshipType ValueSet - Where there is no obvious mapping from the local system codes, O (Other) or FAMMEMB (family member) can be used, however in these cases the local display should be used for the relationship.text
  Note The PatientRelationshipType ValueSet takes codes from multiple CodeSystems (e.g. 'O' is from http://hl7.org/fhir/v2/0131 and 'FAMMEMB' is from http://hl7.org/fhir/v3/RoleCode), so it may not be posisble to fix the 'coding.system' value in any templates

Must Support fields

In addition, the following fields are "Must Support" - i.e. they must be populated if relevant and known:

• telecom - how the related person can be contacted e.g. phone and/or email details. It's only relevant to capture the person's current contact details, no telecom history is appropriate.

• socialCareSupportRole (Extension) - see Relationship v Roles(s) section above.

• period - The period during which the relationship existed.

Period Note

Both the RelatedPerson Resource as whole and each supportRole have an effective period – Implementers may choose to only show the current support roles … i.e. if one support role is removed/ended just remove it from the new version of the resource (rather than ending it)

When the whole RelatedPerson is ended in the Patient’s record in the PAS/LoBS (e.g. they die and a new person added in replacement), Data Providers have a couple of options

1. DELETE the Resource from the FHIR Store
2. Update active to false, add a period.end date, also end all open support roles with the same date

The Portal currently shows inactive and active RelatedPersons, in an emergency a user might not spot that one of the Resources has been ended, so option a) may be preferable