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.
32 KiB
32 KiB