Vertaalt de FCO-IM-feitenrondes en logische modellen naar 37 nieuwe
PostgreSQL-tabellen, verdeeld over vier migraties:
- create_reference_data: één generieke value_list_item-tabel (spelregel
3.1 #1) i.p.v. ~30 losse waardelijst-tabellen, met alle startwaarden uit
model-aanmelding.md/model-instroom.md/model-intake-behandeladvies.md.
- create_person_client_domain: person, address, contact_detail, client,
client_relation, referrer, practice_organization,
client_general_practitioner, insurance, consent, client_portal_account
(model-aanmelding.md §2.1-2.9, 2.14, 2.16). BSN als bsn_hash (SHA-256),
conform de platform-privacyregel — geen raw BSN, geen reversibele
encryptie.
- create_referral_domain: 20 entiteiten uit model-instroom.md (referral_
request t/m episode_team_involvement), inclusief de vervangt-constraints
als partial unique index (voorkomt vertakking) en de XOR-check op
clinical_care_episode tussen acceptatiebesluit en Wvggz-mandaat.
- create_intake_treatment_advice_domain: 5 entiteiten uit
model-intake-behandeladvies.md.
Scope: dit zijn nieuwe, additieve tabellen naast de bestaande prototype-
tabellen (patients, screenings, intakes, patients.is_john_doe,
intakes.kindcheck_data) — die tabellen zijn bewust niet aangeraakt.
Wiring van de live app op dit schema, en migratie van prototype-data, is
een aparte, nog te nemen beslissing. Migraties zijn nog niet toegepast op
een database.
decision_authority_id (care_acceptance_decision) is tijdelijk nullable
zonder FK — het doeltabel volgt uit de bevoegdheidsronde (B16). Perifere
waardelijst-kolommen zijn TEXT met een verwijzing naar de bedoelde lijst in
een comment, geen harde FK naar value_list_item — applicatievalidatie (Zod)
dekt die laag; business-kritieke uitkomsten (decision_outcome,
treatment_advice_outcome, mandate_type) hebben wel een CHECK-constraint.
ea4c0c836f