Skip to content

RelatedPerson Profile

Canonical../StructureDefinition/nexus-emr-core-relatedperson
Statusdraft · 1.26.0
BaseRelatedPerson (constraint)
SourceFSH · JSON

Nexus EMR profile for RelatedPerson, capturing an alternative contact for a patient — a person the practice can reach on the patient's behalf, with a personal relationship, any number of contact purposes, contact details, an optional note, and an optional primary (call-first) flag. Backs the Patient Profile Relationships section.

Overview

Overview

The Nexus EMR Core RelatedPerson profile represents an alternative contact for a patient: a person the practice can reach on the patient's behalf. It carries a personal relationship, any number of contact purposes, contact details, an optional note, and an optional primary (call-first) flag, and it backs the Relationships section of the patient chart. patient is 1..1, constrained to a single Reference(Patient); name and telecom are 0..*, and a work number's extension rides on the nexus-emr-contact-point-phone-extension rather than being packed into telecom.value.

The profile is reachable by SMART on FHIR apps under the widest grant this IG issues: relatedperson:read, relatedperson:write and relatedperson:delete. An app holding the delete permission can destroy a contact record, so request only what the app needs.

It also declares no effective date, deliberately. A contact is a party, not a dated event: birthDate is a demographic fact exactly as it is on Patient, and period is the window over which the contact is valid. Neither is an effective date, and consumers must not synthesize one -- without the explicit declaration a best-effort fallback would date the resource to a birth year and pull it into recency windows it has no business in.

Relationship and contact purpose share one element

relationship is 0..* and carries two different kinds of concept in the same array:

  • The personal relationship, from the official relatedperson-relationshiptype value set (HL7 v3 PersonalRelationshipRoleType plus the v2-0131 O "Other" member), with v3 RoleCode GUARD covering the legal guardian that set has no concept for.
  • Zero or more contact purposes from ../CodeSystem/nexus-emr-contact-purpose: emergency, substitute-decision-maker, next-of-kin, care-giver, power-of-attorney, guarantor, insurance, administrative-staff.

Readers must discriminate by matching system AND code against the relationship value set. Array position carries no meaning, and relationship[0] is not reliably the personal relationship.

The purpose list is local-primary because no single official value set covers it (substitute decision maker and administrative staff have no official code). Where an official concept exists the purpose is dual-coded alongside the local code -- emergency with v2-0131 C, next-of-kin with N, insurance with I, power-of-attorney with v3 RoleCode POWATT, care-giver with v3 RoleClass CAREGIVER, guarantor with v3 RoleClass GUAR. A consumer recognizing only official codes will see most purposes, but not all.

Primary flag and note are extensions

extension[primary] (nexus-emr-contact-primary, 0..1) is a simple boolean marking the call-first contact: value[x] is 1..1 boolean with no sub-extensions. extension[note] (nexus-emr-contact-note, 0..1) is a 1..1 string.

At most one related person per patient should carry primary = true. That rule spans resources, so no validator on this profile can enforce it: writers must maintain it, and readers must tolerate finding zero, one, or -- in imperfect data -- more than one.