core PK: id 10 required 1 unique

Description

Represents a family member, caregiver, or next-of-kin linked to a contact in the Meander platform. Introduced as a Barnekreftforeningen MVP requirement to support registering people surrounding a child with cancer (parents, siblings, primary caregivers) as distinct contact subjects tied to the same case.

16
Attributes
6
Indexes
8
Validation Rules
11
CRUD Operations

Data Structure

Name Type Description Constraints
id uuid Primary key, globally unique identifier for the relative record
PKrequiredunique
contact_id uuid Foreign key to the contacts table — the primary contact (e.g. the child) this relative is associated with
required
organization_id uuid Foreign key to the owning organization; enforces tenant isolation so relatives are never visible across org boundaries
required
first_name string Relative's given name
required
last_name string Relative's family name
required
phone_number string Contact phone number for the relative; optional, stored in E.164 format
-
email string Email address for the relative; optional
-
relative_role_id uuid Foreign key to relative_roles — the structured role label (e.g. Parent, Sibling, Caregiver) assigned to this relative
-
notes text Free-text field for additional context about this relative (e.g. language preferences, accessibility needs, communication notes)
-
is_primary_caregiver boolean Flags the relative as the primary caregiver — used to surface the most important family contact quickly in UI
required
consent_given boolean Records whether the relative has given explicit consent for their data to be stored and processed on this platform, per GDPR requirements
required
consent_given_at datetime Timestamp of when consent was recorded; null if consent has not been given
-
created_by uuid Foreign key to the user (peer mentor or coordinator) who registered this relative record
required
created_at datetime Timestamp of record creation
required
updated_at datetime Timestamp of last update, maintained automatically on every write
required
deleted_at datetime Soft-delete timestamp; null means active. Deleted relatives are excluded from all normal queries but retained for audit purposes
-

Database Indexes

idx_relatives_contact_id
btree

Columns: contact_id

idx_relatives_organization_id
btree

Columns: organization_id

idx_relatives_contact_org
btree

Columns: contact_id, organization_id

idx_relatives_relative_role_id
btree

Columns: relative_role_id

idx_relatives_created_by
btree

Columns: created_by

idx_relatives_deleted_at
btree

Columns: deleted_at

Validation Rules

first_name_not_empty error

Validation failed

last_name_not_empty error

Validation failed

valid_contact_reference error

Validation failed

valid_organization_reference error

Validation failed

phone_number_format error

Validation failed

email_format error

Validation failed

consent_timestamp_consistency error

Validation failed

valid_relative_role_reference error

Validation failed

Business Rules

org_scoped_access
always

A relative record is only accessible to users belonging to the same organization. Peer mentors and coordinators can only see relatives within their own org context. Global Admins require time-bounded support access granted via Organization Settings.

contact_must_exist_and_be_active
on_create

A relative can only be created or remain active if the associated contact record exists and is not soft-deleted. Deleting the parent contact triggers a cascade soft-delete on all linked relatives.

Enforced by: Relative Service
single_primary_caregiver_per_contact
on_create

At most one relative per contact may have is_primary_caregiver = true. Setting a new relative as primary caregiver automatically clears the flag on any previously flagged relative for the same contact.

consent_required_for_sensitive_fields
on_create

Fields containing personal data (phone_number, email, notes) should only be populated if consent_given = true. The UI enforces this by showing a consent confirmation step before saving contact details.

soft_delete_only
on_delete

Relatives must never be hard-deleted. All deletions set deleted_at to the current timestamp. This preserves referential integrity with relative_case_links and supports audit requirements.

Enforced by: Relative Service
offline_sync_eligibility
always

Relative records for contacts the peer mentor is actively working with are included in the offline sync payload so they remain accessible without connectivity. Mutation outbox handles create/update while offline.

Storage Configuration

Storage Type
primary_table
Location
main_db
Partitioning
No Partitioning
Retention
Permanent Storage