RelativeRepository
Component Detail
Data Layer
medium complexity
backend
0
Dependencies
0
Dependents
1
Entities
0
Integrations
Description
Data access layer responsible for persisting and querying relative contact records in the database. Each relative is stored as an independent record linked to a support case. It provides CRUD operations and supports filtered queries by case ID or relationship role.
relative-repository
Sources & reasoning
Source lines 121-122 explicitly define the relative registration requirement as unique to Barnekreftforeningen. Line 161 (priority matrix) marks it MUST with Phase 1. Line 438 reconfirms Fase 1 MUST status. Phase 1 maps to MVP by ordinal. This is the foundational record-creation step the other two relatives features depend on.
-
docs/source/likeperson.md · line 121-122Pårørende-database: Barnekreftforeningen jobber primært med familier rundt barn med kreft, ikke kun med de berørte selv. Appen må støtte registrering av pårørende (foreldre, søsken, nærmeste omsorgsperson) som egne kontaktsubjekter knyttet til samme
-
docs/source/likeperson.md · line 161Pårørende database | ✓ | - | - | - | ✓ | MUST (Barnekreft) | 1
-
docs/source/likeperson.md · line 438Pårørende-database er Fase 1 MUST for Barnekreftforeningen
Responsibilities
- Persist new relative contact records with case association and relationship role
- Retrieve all relatives linked to a specific case ID
- Update existing relative contact details
- Soft-delete relative records while preserving audit history
- Query relatives by relationship role for reporting or filtering
Interfaces
create(data: RelativeInput): Promise<Relative>
findByCaseId(caseId: string): Promise<Relative[]>
findById(relativeId: string): Promise<Relative | null>
update(relativeId: string, data: Partial<RelativeInput>): Promise<Relative>
softDelete(relativeId: string): Promise<void>