Caregiver & Next-of-Kin

For organizations supporting individuals with disabilities or health challenges, caregiver and next-of-kin information is operationally critical. Peer mentors conducting home visits need immediate access to emergency contacts and family context without having to navigate outside the app. This reduces risk during incidents and ensures that follow-up care can be coordinated efficiently between the peer mentor, the contact, and their support network. The Barnekreftforeningen specifically identified a "pårørende database" (next-of-kin database) as a must-have need in phase 1. Storing this information within the contact record - rather than as a separate module - keeps the workflow cohesive and reduces the number of screens a peer mentor must navigate during or after a visit, directly supporting the platform's low-cognitive-load design principle.

Caregiver records are modeled as a one-to-many relationship from contacts to caregiver_contacts in the database schema. The Drift table is queried reactively alongside the parent contact record, so the contact detail screen receives both the contact and its caregiver list in a single provider stream. Adding or editing a caregiver uses a bottom sheet form to keep the user in context on the contact detail screen rather than navigating to a new route. The caregiver form is a lightweight subset of the contact form - name, relationship type (enum), phone, and notes - and shares the same AppTextField and validation primitives. Relationship type should be an explicit enum on the backend (e.g. parent, spouse, sibling, professional_carer, other) to support future filtering or reporting. All caregiver phone numbers must be tappable tel: links for one-tap calling on mobile. Offline support follows the same mutation outbox pattern as the parent contact record.