From f68d63145a9d09293be3c62126cf7f09d145660b Mon Sep 17 00:00:00 2001
From: colinislit <colin@ikbenlit.nl>
Date: Sun, 19 Jul 2026 17:46:57 +0200
Subject: [PATCH] docs(datamodel): instroom entiteiten/cardinaliteiten + vier
 reviewrondes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Voegt model-instroom.md toe: de eerste entiteiten-/cardinaliteitenafleiding
uit feitenmodel-instroom.md (20 entiteiten, Engelstalig conform B20,
vervangt-patroon voor herzieningen, tijdlijn i.p.v. statusmachine voor
Referral Case).

Vier reviewrondes verwerkt:
- technische en GGZ-domeinreview (vertakkende vervangt-keten gefixed,
  timestamp-precisie, ontbrekende ZPM-velden hersteld);
- tweede ronde met datamodel-, GGZ-domein- en UX-expert-agents (lege
  screening-entiteit vervallen, naamgeving, cardinaliteitsfout, read-model-eis);
- GGZ-wetgeving-onderzoek (Wvggz, Wmo/Jeugdwet, 275-dagentoets,
  365-dagenregel, crisisdocumentatie) vertaald naar nieuwe entiteiten
  (municipal_care_assignment, legal_mandate, crisis_encounter_note);
- domeinreview eigenaarschap/urgentie met Colin: herhaalbare
  urgentiebeoordeling (case_urgency_assessment) en een bewust minimale hook
  voor teambetrokkenheid (episode_team_involvement) — het volledige
  zorgteam-model blijft een aparte, nog te plannen ronde.

feitenmodel-instroom.md: "verzoek zonder bekende persoon" (crisisaanmelding)
beantwoord — geen placeholder-persoon, koppeling als eigen gedateerd feit.
---
 docs/datamodel/deelmodellen/model-instroom.md | 849 ++++++++++++++++++
 .../feitenmodellen/feitenmodel-instroom.md    |  18 +-
 2 files changed, 865 insertions(+), 2 deletions(-)
 create mode 100644 docs/datamodel/deelmodellen/model-instroom.md

diff --git a/docs/datamodel/deelmodellen/model-instroom.md b/docs/datamodel/deelmodellen/model-instroom.md
new file mode 100644
index 0000000..611c41d
--- /dev/null
+++ b/docs/datamodel/deelmodellen/model-instroom.md
@@ -0,0 +1,849 @@
+# Datamodelvoorstel — Instroom (Referral Request/Submission/Case, acceptatiebesluit)
+
+**Status:** voorstel ter review — eerste entiteiten- en cardinaliteitenafleiding,
+op 19 juli 2026 drie reviewrondes doorlopen (technisch, GGZ-domein, UX, en
+GGZ-wetgeving — zie §9)
+**Datum:** 19 juli 2026
+**Scope:** Referral Request, Referral Submission, Referral Case, Professional
+Referral, Care Acceptance Decision, de gebeurtenissen rond een case
+(screening, informatieverzoek, intrekking, consolidatie), Wmo/Jeugdwet-
+toewijzing en Wvggz-mandaat als alternatieve instroomroutes, crisis­
+documentatie vóór identificatie, en het ontstaan/einde van Clinical Care
+Episode. Behandeladvies/intake-uitkomst blijft buiten scope (nog open
+onderzoek, zie feitenmodel §7 vraag 2).
+**Kader:** bouwt rechtstreeks op de bevestigde feitzinnen in
+`../feitenmodellen/feitenmodel-instroom.md`. Alle vragen uit diens §7 zijn
+beantwoord, behalve vraag 2. Dit is de stap "afleiding van entiteiten en
+cardinaliteiten" uit die §7.
+**Naamgeving:** entiteiten en attributen zijn Engelstalig, conform besluit
+B20. Dit wijkt af van het oudere, Nederlandstalige `model-aanmelding.md` —
+die synchronisatie (AANMELDING/VERWIJZING/ZORGEPISODE vervangen door dit
+voorstel) is een aparte, latere stap, niet in dit document.
+**Autoriteit:** `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft
+leidend.
+
+---
+
+## 1. Ontwerpprincipe: tijdlijn in plaats van statusmachine
+
+`Referral Case` heeft geen vaste, eenrichtings-statusmachine (feitenmodel §4,
+domeinreview 19 juli 2026). In plaats daarvan zijn dit de gebeurtenis-
+entiteiten die aan een case kunnen hangen, in willekeurige volgorde en
+herhaalbaar:
+
+- `submission_case_assignment` — een submission wordt aan de case toegewezen;
+- `screening_activity` — een screeningscontact of -onderzoek;
+- `case_information_request` — een informatieverzoek;
+- `care_acceptance_decision` — een (vervangend) acceptatiebesluit;
+- `case_withdrawal` — een cliënt-intrekking;
+- `case_consolidation` — een leidend-aanwijzing tussen twee cases.
+
+§7 werkt uit hoe de actuele stand van een case uit deze gebeurtenissen wordt
+afgeleid.
+
+## 2. Entiteiten
+
+### 2.1 referral_request
+
+**Doel:** het inhoudelijke verzoek om zorg of beoordeling. Eigen identiteit,
+los van de submission die het aanleverde en los van een eventuele formele
+verwijzing (feitenmodel §2, §6).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| person_id | ref PERSOON | nee *(zie hieronder — crisisaanmelding met onbekende identiteit)* |
+| person_identified_at | tijdstip | verplicht zodra `person_id` gevuld is |
+| person_identified_by | ref medewerker | verplicht zodra `person_id` gevuld is |
+| initiated_at | tijdstip | ja |
+| initiator_type | waardelijst `initiator_type` (professional/organisatie/cliënt/vertegenwoordiger) | ja |
+| initiator_reference | tekst of ref VERWIJZER | nee |
+| requested_scope | tekst (bv. “gespecialiseerde GGZ”) | ja |
+| presenting_need_text | tekst (de geuite zorgvraag) | ja |
+
+**Uniciteit:** één stabiele identiteit; zodra bekend precies één
+persoon/cliënt; minstens één initiator; bevat één of meer samenhangende
+geuite zorgvragen (geen los attribuut — volgt uit de scope van het request
+zelf, splitsing gebeurt door een nieuw request aan te maken).
+
+**Waarom `person_id` optioneel is:** bij crisisaanmeldingen kan de
+identiteit nog onbekend zijn op het moment dat het request al geregistreerd
+moet worden. Een placeholder- of "John Doe"-persoon die later wordt
+vervangen is bewust geen oplossing — dat vereist achteraf alle gekoppelde
+feiten naar de echte persoon te verplaatsen, wat tegen append-only ingaat.
+`person_identified_at`/`_by` maken de koppeling zelf een gedateerd,
+toegeschreven feit in plaats van een stille invulling (domeinreview 19 juli
+2026, was open punt 1).
+
+### 2.2 referral_submission
+
+**Doel:** één afzonderlijke binnenkomst, via één kanaal en op één
+ontvangstmoment (feitenmodel §2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| received_at | tijdstip | ja |
+| channel | waardelijst `submission_channel` (ZorgDomein/e-mail/telefoon/portaal/…) | ja |
+| source_reference | tekst of ref VERWIJZER | nee *(“onbekend” toegestaan)* |
+| recorded_by | ref medewerker | nee *(verplicht bij telefonische/handmatige registratie)* |
+| raw_note | tekst | nee |
+
+**Uniciteit:** één ontvangstmoment en kanaal; minstens één bron (evt.
+onbekend); nul of meer documenten; nooit overschreven door een latere
+aanvulling — een aanvulling is een nieuwe submission.
+
+### 2.3 submission_document
+
+**Doel:** een document dat bij een submission is ontvangen (S4, S8).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| submission_id | ref referral_submission | ja |
+| document_type | waardelijst `document_type` (verwijsbrief/diagnostische aanvulling/…) | ja |
+| document_reference | ref documentopslag (UUID) | ja |
+
+**Uniciteit:** geen — meerdere documenten per submission toegestaan.
+
+### 2.4 submission_request_link
+
+**Doel:** de expliciete koppeling van een submission aan één of meer
+requests (S5, S9, S12) — de submission zelf wordt nooit gekopieerd of
+gesplitst (feitenmodel §3.2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| submission_id | ref referral_submission | ja |
+| referral_request_id | ref referral_request | ja |
+| established_at | tijdstip | ja |
+
+**Uniciteit:** een submission kan 0..n requests representeren of aanvullen;
+elke bekende relatie is een eigen rij.
+
+**`link_type` vervalt (voorstel, ter evaluatie):** “representeert” versus
+“vult_aan” bleek bij toetsing geen zelfstandig feit met eigen gedrag of
+regels — geen enkele uniciteits- of optionaliteitsregel behandelt ze
+verschillend. Het onderscheid is puur chronologisch: de vroegste
+`submission_request_link` voor een request is per definitie degene die het
+representeerde, latere zijn per definitie aanvullingen. Dat volgt al uit
+`established_at` in combinatie met de al bestaande volgorde van submissions;
+een apart, door een mens te zetten waardelijst-veld zou dezelfde informatie
+dubbel opslaan. `established_at` wordt daarom verplicht (was optioneel) om
+deze afleiding altijd mogelijk te maken.
+
+### 2.5 submission_duplicate_assessment
+
+**Doel:** vastleggen dat een submission als duplicaat van een andere is
+beoordeeld (S13, S14).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| submission_id | ref referral_submission (het duplicaat) | ja |
+| duplicate_of_submission_id | ref referral_submission (het origineel) | ja |
+| assessed_by | ref medewerker | ja |
+| assessed_at | tijdstip | ja |
+| reason | tekst | ja |
+
+**Uniciteit:** geen destructieve werking — beide submissions blijven bestaan.
+
+### 2.6 referral_case
+
+**Doel:** het institutionele aanmeldingstraject voor één samenhangend
+beoordeelde zorgvraag (feitenmodel §2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| person_id | ref PERSOON | nee *(zelfde reden als bij referral_request — crisisaanmelding)* |
+| person_identified_at | tijdstip | verplicht zodra `person_id` gevuld is |
+| person_identified_by | ref medewerker | verplicht zodra `person_id` gevuld is |
+| opened_at | tijdstip | ja |
+| presenting_need_summary | tekst | ja |
+| wettelijk_kader | waardelijst `wettelijk_kader` (zvw/wmo/jeugdwet/wvggz) | ja *(overgenomen van AANMELDING in `model-aanmelding.md` §2.10 / discovery §5.0 besluit 4, was in dit voorstel per abuis niet meegenomen; bepaalt welke instroomroute — `professional_referral`, `municipal_care_assignment`, `legal_mandate` — van toepassing is, reviewronde 19 juli 2026)* |
+| zpm_verwijstype | waardelijst `zpm_verwijstype` | nee *(afleidbaar uit professional_referral/initiator_type, overschrijfbaar; verplicht richting declaratie bij Zvw — overgenomen van AANMELDING in `model-aanmelding.md` §2.10, was in dit voorstel per abuis niet meegenomen)* |
+| huisarts_geinformeerd_op | datum | nee *(instroom zonder verwijzing; nudge harde termijn 60 dagen — overgenomen van AANMELDING in `model-aanmelding.md` §2.10)* |
+
+**Uniciteit:** één stabiele identiteit; één institutioneel als samenhangend
+beoordeelde zorgvraag; gevoed door 1..n submissions (via
+`submission_case_assignment`) en 1..n requests (via `request_case_link`); geen
+vast statusveld (zie §1 en §7).
+
+**AGB-code en correspondentietoestemming:** geen nieuwe velden nodig — AGB
+van de verwijzer/praktijk loopt via `professional_referral.referrer_id` →
+VERWIJZER/PRAKTIJK_INSTELLING (al aanwezig, `model-aanmelding.md` §2.6–§2.7);
+correspondentietoestemming (verwijstype 04) valt onder de al bestaande
+generieke TOESTEMMING-entiteit (`model-aanmelding.md` §2.14), met
+`scope_aanmelding_id` wijzend naar deze case.
+
+### 2.7 submission_case_assignment
+
+**Doel:** de historiseerbare toewijzing van een submission aan een case
+(C3–C7).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| submission_id | ref referral_submission | ja |
+| referral_case_id | ref referral_case | ja |
+| assigned_at | tijdstip | ja |
+| assigned_by | ref medewerker | ja |
+| reason | tekst | nee |
+
+**Uniciteit:** een submission kan aan meerdere cases worden toegewezen
+(uitzondering, feitenmodel §3.3); toewijzing is een gebeurtenis, geen
+overschrijfbaar veld.
+
+### 2.8 request_case_link
+
+**Doel:** welke requests binnen een case worden behandeld, en sinds wanneer
+(C8, C9).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_request_id | ref referral_request | ja |
+| referral_case_id | ref referral_case | ja |
+| since | datum | ja |
+| reason | tekst | nee *(verplicht zodra een request aan meer dan één case gekoppeld is — uitzondering, feitenmodel §4)* |
+
+**Uniciteit:** een request hoort normaliter bij precies één case; koppeling
+aan meer dan één case is een expliciete uitzondering met reden en
+tijdgebonden historie.
+
+### 2.9 case_consolidation
+
+**Doel:** niet-destructieve leidend-aanwijzing tussen twee overlappende cases
+(C10–C13).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| primary_case_id | ref referral_case (leidend) | ja |
+| related_case_id | ref referral_case (niet-leidend, blijft bestaan) | ja |
+| overlap_assessed_at | tijdstip | nee |
+| designated_at | tijdstip | ja |
+| designated_by | ref medewerker | ja |
+| reason | tekst | ja |
+
+**Bevoegdheid (voorstel, ter evaluatie):** geen speciale `decision_authority`
+vereist — elke medewerker die de case behandelt kan consolideren, net als bij
+`submission_case_assignment` en `submission_duplicate_assessment`. Consolidatie
+is een administratieve correctie (welke case leidend is voor rapportage),
+geen inhoudelijk besluit over zorgtoegang; zij creëert of beëindigt geen
+zorgconsequentie zoals `care_acceptance_decision` dat wel doet. Alleen een
+mens mag dit vaststellen — AI mag hooguit een match voorstellen (B1) — maar
+dat is een ander soort eis dan beslisbevoegdheid.
+
+**Uniciteit:** beide cases behouden hun eigen identiteit en historie na
+aanwijzing; geen merge, geen verwijdering. `related_case_id` is uniek: een
+case kan in hoogstens één consolidatie de niet-leidende rol vervullen
+(`UNIQUE(related_case_id)`); `primary_case_id` blijft vrij herhaalbaar. Een
+case mag zichzelf niet consolideren (`CHECK(primary_case_id <>
+related_case_id)`). Transitieve cykels (A leidend over B, B leidend over A)
+worden hierdoor niet uitgesloten en blijven een proces-/applicatie­
+verantwoordelijkheid (reviewronde 19 juli 2026, zie §9).
+
+### 2.10 screening_activity
+
+**Doel:** een concrete screeningsactiviteit binnen een case (G1–G4). Levert
+zelf geen apart advies op (feitenmodel §3.4). *(De aparte, lege
+`screening`-groeperingsentiteit uit de eerste versie is vervallen — geen
+enkel eigen attribuut, geen onderscheidend kenmerk tussen meerdere
+groeperingen; als een echte, benoembare screeningsronde ooit nodig blijkt,
+komt die terug als event-entiteit met eigen attributen. Reviewronde 19 juli
+2026, zie §9.)*
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| performed_at | tijdstip | ja |
+| activity_type | waardelijst `screening_activity_type` (telefonisch contact/dossieronderzoek/vragenlijst/…) | ja |
+| performed_by | ref medewerker | ja |
+| notes | tekst | nee |
+| funded | ja/nee | nee *(default nee — screeningscontact is meestal niet gefinancierd, feitenmodel §3.4)* |
+
+**Uniciteit:** geen — 0..n activiteiten per screening.
+
+### 2.11 case_information_request
+
+**Doel:** een informatieverzoek als eigen gebeurtenisfeit, niet als
+besluituitkomst of statusveld (feitenmodel §7 vraag 5, A28–A29).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| requested_at | tijdstip | ja |
+| requested_by | ref medewerker | ja |
+| requested_information | tekst | ja |
+| resolved_by_submission_id | ref referral_submission | nee |
+
+**Uniciteit:** geen — een case kan meerdere informatieverzoeken hebben, ook
+ná een eerder acceptatiebesluit tijdens een heroverweging.
+
+### 2.12 care_acceptance_decision
+
+**Doel:** het formele besluit dat de beoordeling van een case afrondt: draagt
+zelf de onderliggende beoordelingen, de besluituitkomst, de vervolgroute en,
+bij afwijzing, de onderbouwing (feitenmodel §2, §3.5, §4).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| decided_at | tijdstip | ja |
+| decided_by | ref medewerker | ja |
+| decision_authority_id | ref decision_authority | ja |
+| content_match | ja/nee | ja |
+| capacity_available | ja/nee | nee |
+| program_context | ref care_program of tekst | nee |
+| decision_outcome | waardelijst `decision_outcome` (`geaccepteerd`/`afgewezen`) | ja |
+| follow_up_route | waardelijst `follow_up_route` (intake_direct/intakewachtlijst/spoedroute/doorverwijzen/case_afsluiten) | ja |
+| rationale | tekst | verplicht bij `afgewezen`, anders optioneel |
+| replaces_decision_id | ref care_acceptance_decision (zelfreferentie) | nee |
+| replacement_reason | tekst | verplicht als `replaces_decision_id` gevuld is |
+
+**Uniciteit:** precies één case, beslisser, besluitdatum, besluituitkomst en
+vervolgroute per besluit. Optioneel precies één eerder besluit van dezelfde
+case vervangen — het vervangen besluit blijft ongewijzigd bewaard (feitenmodel
+§4, §7 vraag 3). Capaciteit bepaalt de uitkomst niet automatisch (Route 2A/2B).
+`replaces_decision_id` is uniek indien gevuld (partial unique index): een
+besluit kan door hoogstens één ander besluit worden vervangen, zodat de
+vervangt-keten nooit vertakt. Zonder die garantie zouden twee besluiten
+tegelijk "niet vervangen" kunnen zijn en zou de afleidingsregel in §5 geen
+eenduidig geldig besluit meer opleveren. Het geldige besluit van een case is
+het laatste, niet-vervangen besluit in de keten. *(Concurrency bij
+gelijktijdige heroverwegingen — bijvoorbeeld via `SELECT ... FOR UPDATE` op
+de keten-tail — is een implementatiedetail voor de migratie-/API-laag, niet
+voor dit document.)*
+
+**Kettingdiepte (voorstel, ter evaluatie):** onbeperkt toegestaan, geen aparte
+constraint. De afleidingsregel in §5 ("volg de vervangt-keten naar het
+laatste, niet-vervangen besluit") werkt voor elke kettinglengte zonder extra
+modellering. Een harde grens van één niveau zou een legitieme
+correctie-op-een-correctie blokkeren zonder dat daar een aantoonbare
+praktijkreden voor is — de feitzinnen tonen alleen één niveau omdat dat het
+scenario was, niet omdat een tweede niveau problematisch zou zijn.
+
+### 2.13 case_withdrawal
+
+**Doel:** cliënt-intrekking van een case, geen besluit en geen
+bevoegdheidseis (feitenmodel §3.5 Route 4, §7 vraag 4).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| withdrawn_at | tijdstip | ja |
+| recorded_by | ref medewerker | ja |
+| note | tekst | nee |
+
+**Uniciteit:** geen — kan op elk moment plaatsvinden, ook ná een positief
+besluit.
+
+### 2.14 professional_referral
+
+**Doel:** de formele Nederlandse VERWIJZING, zelfstandig object gekoppeld aan
+een request (R6–R10, feitenmodel §2, §6).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_request_id | ref referral_request | ja |
+| referrer_id | ref VERWIJZER | ja |
+| referral_date | datum | ja |
+| echelon | waardelijst `echelon` | nee |
+| suspected_condition | tekst | nee |
+| heraanmelding | ja/nee | ja (default nee) *(overgenomen van VERWIJZING in `model-aanmelding.md` §2.11, was in dit voorstel per abuis niet meegenomen)* |
+| replaces_referral_id | ref professional_referral (zelfreferentie) | nee |
+| replacement_reason | tekst | verplicht als `replaces_referral_id` gevuld is |
+
+**Uniciteit:** eigen identiteit, gekoppeld aan precies één request. Een
+request kan 0..n professional referrals hebben: een correctie of aanvulling
+op een eerdere verwijzing is geen nieuw request maar een nieuwe
+`professional_referral` die de vorige vervangt — dezelfde
+vervangt-constructie als bij `care_acceptance_decision` (domeinreview 19 juli
+2026, was open punt 1). De vervangen verwijzing blijft ongewijzigd bewaard;
+het geldige exemplaar is het laatste, niet-vervangen record in de keten.
+`replaces_referral_id` is, net als bij `care_acceptance_decision`, uniek
+indien gevuld — zelfde reden: voorkomt vertakking van de keten.
+
+**AGB-code:** geen apart veld — loopt via `referrer_id` → VERWIJZER, dat al
+een `agb_code` draagt (`model-aanmelding.md` §2.6).
+
+### 2.15 municipal_care_assignment *(voorstel, gebaseerd op juridisch onderzoek 19 juli 2026 — zie §9)*
+
+**Doel:** de gemeentelijke beschikking/toewijzing (Wmo/Jeugdwet, iWmo/iJw
+301-bericht) als toegangsticket naast — niet in plaats van — een eventuele
+`professional_referral`. Bij Jeugdwet bestaat een zelfstandige professionele
+verwijsroute náást de gemeentelijke toewijzing (een cliënt kan dus beide
+hebben); bij Wmo bestaat geen professionele verwijsroute, alleen de
+gemeentelijke toegang.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_request_id | ref referral_request | ja |
+| legal_framework | waardelijst `municipal_legal_framework` (wmo/jeugdwet) | ja |
+| municipality_code | tekst (CBS-gemeentecode) | ja |
+| assignment_number | tekst (toewijzings-/beschikkingsnummer) | ja |
+| product_category | waardelijst `municipal_product_category` | ja |
+| product_code | tekst | ja |
+| volume | getal | ja |
+| unit | waardelijst `municipal_product_unit` | ja |
+| frequency | tekst | ja |
+| start_date | datum | ja |
+| end_date | datum | nee |
+| issued_at | tijdstip | ja |
+| replaces_assignment_id | ref municipal_care_assignment (zelfreferentie) | nee |
+| replacement_reason | tekst | verplicht als `replaces_assignment_id` gevuld is |
+
+BSN, geboortedatum, geslacht en adres van de cliënt komen niet terug als
+eigen velden — die lopen via PERSOON (al bestaand, niet dubbel modelleren).
+AGB-code van de aanbieder loopt via de bestaande PRAKTIJK_INSTELLING-entiteit.
+
+**Uniciteit:** `assignment_number` uniek per `municipality_code`. Zelfde
+vervangt-mechaniek als `professional_referral`/`care_acceptance_decision`
+(gemeenten sturen herziene 301-berichten) — `replaces_assignment_id` uniek
+indien gevuld, onbeperkte kettingdiepte.
+
+### 2.16 legal_mandate *(voorstel, gebaseerd op juridisch onderzoek 19 juli 2026 — zie §9)*
+
+**Doel:** het wettelijke mandaat bij gedwongen zorg (Wvggz): crisismaatregel
+of zorgmachtiging. Bij een crisismaatregel heeft de instelling geen
+discretionaire ruimte — het burgemeesterlijk besluit (op basis van een
+medische verklaring) is zelf bindend; er bestaat geen apart institutioneel
+acceptatiebesluit ernaast. Dit vervangt dus geen `care_acceptance_decision`,
+het is een eigen soort feit met een andere aard (wettelijke plicht, geen
+discretionaire beoordeling).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| mandate_type | waardelijst `mandate_type` (crisismaatregel/zorgmachtiging) | ja |
+| decision_reference | tekst (besluit-/beschikkingsnummer) | ja |
+| decided_by_role | waardelijst `mandate_decider_role` (burgemeester/rechter) | ja |
+| decided_at | tijdstip | ja |
+| medical_statement_reference | ref document (medische verklaring psychiater) | verplicht bij `crisismaatregel` |
+| effectuated_at | tijdstip (tenuitvoerlegging) | ja |
+| valid_from | tijdstip | ja |
+| valid_until | tijdstip | nee |
+
+*(Aanname, te bevestigen door een jurist: geen apart institutioneel
+acceptatiebesluit náást een mandaat, ook niet bij zorgmachtiging — het
+juridisch onderzoek noemt dit "aannemelijk", niet met een wetsartikel
+bevestigd. De 24-uurstermijn voor tenuitvoerlegging bij een crisismaatregel
+is een nudge-regel, geen opgeslagen constraint.)*
+
+**Uniciteit:** geen vervangt-mechaniek voorgesteld — een crisismaatregel kan
+overgaan in een machtiging tot voortzetting/zorgmachtiging, maar dat is een
+nieuw mandaat met eigen `decision_reference`, geen correctie van het vorige.
+
+### 2.17 crisis_encounter_note *(voorstel, gebaseerd op juridisch onderzoek 19 juli 2026 — zie §9)*
+
+**Doel:** gestructureerde vastlegging van crisisgerelateerd handelen vóórdat
+identificatie of volledige dossiervorming heeft plaatsgevonden (gesignaleerd
+thema, zie §6-geschiedenis in §9). Losstaand van `screening_activity`, dat
+over het beoordelingsproces gaat, niet over klinisch handelen.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| occurred_at | tijdstip | ja |
+| recorded_by | ref medewerker | ja |
+| fact_type | waardelijst `crisis_fact_type` (medicatie_toegediend/risico_inschatting/vitale_functie/dwangmaatregel/overig) | ja |
+| description | tekst | ja |
+| structured_value | tekst/JSON | nee |
+
+**Onderbouwing:** geen expliciet wetsartikel gevonden dat gestructureerde
+vastlegging tíjdens de crisisinterventie zelf verplicht (juridisch onderzoek
+19 juli 2026) — de algemene WGBO-dossierplicht ondersteunt dit wel in
+algemene zin. Alle gestructureerde velden blijven daarom optioneel op
+`description` na. `fact_type = dwangmaatregel` verwijst waar mogelijk naar de
+formele Wvggz-dwangregistratie in plaats van die te dupliceren.
+
+**Nudge, geen constraint:** een generieke termijn van 14 dagen na de
+behandeling waarbinnen een cliënt zich alsnog moet identificeren is
+gevonden (juridisch onderzoek 19 juli 2026, bron niet met artikelnummer
+bevestigd). Dit wordt een signaal-nudge gekoppeld aan
+`referral_request.person_identified_at IS NULL`, geen blokkerende regel en
+geen attribuut op deze entiteit — de termijn hangt aan identificatie, niet
+aan de crisisnotitie.
+
+### 2.18 clinical_care_episode *(alleen ontstaan/einde — volledig episodemodel is een ander deelgebied)*
+
+**Doel:** de geaccepteerde zorgperiode die ontstaat uit een positief
+acceptatiebesluit óf een geldig wettelijk mandaat, ook vóór de feitelijke
+start van de intake (feitenmodel §3.5, §4; mandaat-route: juridisch
+onderzoek 19 juli 2026).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| originating_decision_id | ref care_acceptance_decision | nee *(zie XOR-regel hieronder)* |
+| originating_mandate_id | ref legal_mandate | nee *(zie XOR-regel hieronder)* |
+| started_at | tijdstip | ja |
+| ended_at | tijdstip | nee |
+| end_reason | waardelijst `episode_end_reason` | verplicht zodra `ended_at` gevuld is |
+| possible_continuation_of_episode_id | ref clinical_care_episode (zelfreferentie) | nee |
+
+**Uniciteit:** `CHECK` dat precies één van `originating_decision_id` /
+`originating_mandate_id` gevuld is — een episode ontstaat óf uit een
+acceptatiebesluit óf uit een mandaat, nooit uit beide of geen van beide.
+Maximaal één episode per geldig positief acceptatiebesluit of geldig
+mandaat. Een episode wordt nooit verwijderd; intrekking of correctie sluit
+haar af met een reden (`ingetrokken_door_client`, `acceptatiebesluit_herzien`,
+…) in plaats van haar te laten vervallen. Overige einde-redenen (bijvoorbeeld
+“behandeling afgerond”) horen bij een later deelgebied.
+
+**`possible_continuation_of_episode_id` (voorstel, tussenoplossing — zie
+§9):** systeem-gesuggereerd op basis van een gap ≤ 365 dagen tussen
+`ended_at` van de vorige episode (zelfde `person_id`) en `started_at` van
+deze episode; een mens bevestigt. **Expliciete disclaimer:** dit is een
+zorginhoudelijke continuïteitsaanwijzing voor het behandelteam, **geen**
+autoritatieve NZa-toets voor zorgtrajectnummer-hergebruik — die toets hangt
+aan de datum van de laatst geleverde prestatie bij dezelfde zorgaanbieder
+(niet aan de episode-einddatum) en hoort bij een nog niet bestaand
+declaratie-/prestatieregistratie-deelgebied. Bewust niet "heraanmelding"
+genoemd om verwarring met `professional_referral.heraanmelding` (een
+ZPM-verwijstype-vlag, ander begrip) te voorkomen.
+
+### 2.19 case_urgency_assessment *(voorstel, domeinreview 19 juli 2026 — zie §9)*
+
+**Doel:** urgentie als herhaalbare beoordeling, geen vast veld. Vastgesteld
+tijdens screening/triage door de rol screener of triagist, en kan later
+worden aangepast door het intake-team of in een MDO. Consistent met het
+tijdlijn-principe van dit document (§1): geen vervangt-relatie nodig zoals
+bij `care_acceptance_decision` — de laatste beoordeling geldt, de inzet is
+lager dan bij een acceptatiebesluit.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| assessed_at | tijdstip | ja |
+| assessed_by | ref medewerker | ja |
+| assessed_in_role | waardelijst `urgency_assessor_role` (screener/triagist/intake_team/mdo) | ja |
+| urgency_level | waardelijst `urgency_level` | ja |
+
+**Uniciteit:** geen — 0..n beoordelingen per case; de meest recente bepaalt
+de actuele urgentie (zelfde afleidingspatroon als §5). Geen verplichte
+onderbouwing bij de urgentiewaarde zelf (bevestigd door Colin — eenvoudige
+waardelijst volstaat).
+
+### 2.20 episode_team_involvement *(minimale, voorlopige hook — zie §9)*
+
+**Doel:** vastleggen dat een team bij een episode betrokken is, ook wanneer
+er nog geen individuele behandelaar is toegewezen (bijvoorbeeld: geaccepteerd
+met vervolgroute intakewachtlijst, Route 2A). Dit is **niet** het volledige
+zorgteam-concept — zorgteam (het team van betrokken behandelaren, met
+regie-/hoofdbehandelaarschap en rollen, en later mogelijk cliëntautorisatie)
+is een zelfstandig begrip, los van zorgprogramma en organisatorische eenheid,
+en krijgt een eigen feitenronde (besluitenlog §10 punt 3; begrippenlijst
+`Episode Clinical Team`). Deze entiteit is een minimale, voorlopige hook die
+door die toekomstige ronde wordt vervangen of geabsorbeerd — geen rollen,
+geen bevoegdheid, geen individueel lidmaatschap.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| clinical_care_episode_id | ref clinical_care_episode | ja |
+| team_reference | tekst *(voorlopig vrije tekst — geen Team-entiteit vóór de zorgteam-ronde)* | ja |
+| involved_since | tijdstip | ja |
+| recorded_by | ref medewerker | ja |
+
+**Uniciteit:** geen — een episode kan door de tijd heen bij meerdere teams
+betrokken zijn (bijvoorbeeld bij op-/afschalen); geen statusveld, zelfde
+tijdlijn-principe.
+
+## 3. Relaties met cardinaliteit
+
+**Legenda:** `Van | Naar | A..B..C` — A is de multipliciteit van *Van* per
+één rij *Naar* (meestal `1` bij een verplichte FK op *Naar*; is die FK
+optioneel, dan wordt A zelf `0..1` en vervalt het derde token, dus `A..B`).
+`B..C` is de multipliciteit van *Naar* per één rij *Van*, als min..max
+(`n` = onbegrensd). Rijen met `(self)` beschrijven alleen het
+zelfreferentie-FK-veld, geen relatie tussen twee tabellen (reviewronde 19
+juli 2026, zie §9).
+
+| Van | Naar | Cardinaliteit | Toelichting |
+|---|---|---|---|
+| referral_request | PERSOON | n..0..1 | optioneel — zie person_identified_at |
+| referral_case | PERSOON | n..0..1 | optioneel — zie person_identified_at |
+| referral_request | professional_referral | 1..0..n | correctie/aanvulling is een vervangend record, geen nieuw request |
+| referral_submission | submission_document | 1..0..n | een submission kan zonder documenten bestaan |
+| referral_submission | submission_request_link | 1..0..n | een submission kan nul, één of meerdere requests representeren/aanvullen |
+| referral_request | submission_request_link | 1..1..n | elk request is via minstens één submission binnengekomen |
+| referral_submission | submission_duplicate_assessment | 1..0..n | een submission kan als duplicaat van meerdere andere zijn beoordeeld (zeldzaam, toegestaan) |
+| referral_case | submission_case_assignment | 1..1..n | een case wordt door minstens één submission gevoed |
+| referral_submission | submission_case_assignment | 1..0..n | een submission kan (uitzonderlijk) aan meerdere cases zijn toegewezen |
+| referral_case | request_case_link | 1..1..n | een case behandelt minstens één request |
+| referral_request | request_case_link | 1..1..n(uitzondering) | normaliter 1 case, bij uitzondering meer (feitenmodel §4) |
+| referral_case | case_consolidation | 1..0..n | een case kan leidend zijn over meerdere andere, of zelf niet-leidend zijn in precies één consolidatie (UNIQUE(related_case_id)) |
+| referral_case | screening_activity | 1..0..n | direct aan de case, geen aparte groeperingsentiteit meer |
+| referral_case | case_information_request | 1..0..n | |
+| referral_submission | case_information_request | 0..1 | een submission kan een reactie zijn op hoogstens één informatieverzoek (beide kanten optioneel-enkelvoudig, vandaar geen derde token) |
+| referral_case | care_acceptance_decision | 1..0..n | 0 zolang nog geen besluit; n bij heroverweging/correctie |
+| care_acceptance_decision | care_acceptance_decision | 0..1 (self) | `replaces_decision_id`, optioneel en uniek indien gevuld — voorkomt vertakking; onbeperkte kettingdiepte (voorstel) |
+| professional_referral | professional_referral | 0..1 (self) | `replaces_referral_id`, optioneel en uniek indien gevuld — voorkomt vertakking; onbeperkte kettingdiepte (voorstel) |
+| referral_case | case_withdrawal | 1..0..n | doorgaans 0 of 1, technisch meerdere niet uitgesloten |
+| referral_request | municipal_care_assignment | 1..0..n | naast, niet in plaats van `professional_referral` (voorstel) |
+| municipal_care_assignment | municipal_care_assignment | 0..1 (self) | `replaces_assignment_id`, optioneel en uniek indien gevuld (voorstel) |
+| referral_case | legal_mandate | 1..0..n | crisismaatregel kan overgaan in zorgmachtiging: nieuw mandaat, geen vervangt-relatie (voorstel) |
+| referral_case | crisis_encounter_note | 1..0..n | werkt al zonder `person_id` (voorstel) |
+| care_acceptance_decision | clinical_care_episode | 1..0..1 | XOR met `legal_mandate`; alleen bij uitkomst `geaccepteerd` |
+| legal_mandate | clinical_care_episode | 1..0..1 | XOR met `care_acceptance_decision` (voorstel) |
+| clinical_care_episode | clinical_care_episode | 0..1 (self) | `possible_continuation_of_episode_id`, optioneel, tussenoplossing (voorstel) |
+| referral_case | case_urgency_assessment | 1..0..n | herhaalbaar, laatste geldt (voorstel) |
+| clinical_care_episode | episode_team_involvement | 1..0..n | minimale hook, geen individueel lidmaatschap (voorstel) |
+
+## 4. Waardelijsten (startlijsten, te bevestigen)
+
+| Waardelijst | Voorlopige waarden |
+|---|---|
+| `initiator_type` | professional, organisatie, cliënt, vertegenwoordiger |
+| `submission_channel` | ZorgDomein, e-mail, telefoon, portaal, post, overig |
+| `document_type` | verwijsbrief, diagnostische aanvulling, beschikking, overig |
+| `screening_activity_type` | telefonisch contact, dossieronderzoek, vragenlijst, overig |
+| `decision_outcome` | geaccepteerd, afgewezen |
+| `follow_up_route` | intake_direct, intakewachtlijst, spoedroute, doorverwijzen, case_afsluiten |
+| `episode_end_reason` | ingetrokken_door_client, acceptatiebesluit_herzien, *(overige waarden: later deelgebied)* |
+| `echelon` | over te nemen uit `model-aanmelding.md` §2.11 (bestaande waardelijst) |
+| `zpm_verwijstype` | over te nemen uit `model-aanmelding.md` §2.10 (bestaande waardelijst, ZPM-verwijstypen 01–07) |
+| `wettelijk_kader` | over te nemen uit `model-aanmelding.md` §2.10 (bestaande waardelijst: zvw, wmo, jeugdwet, *(wvggz toe te voegen)*) |
+| `municipal_legal_framework` | wmo, jeugdwet *(voorstel)* |
+| `municipal_product_category` / `municipal_product_unit` | over te nemen uit iWmo/iJw-standaard (voorstel, nog niet uitgezocht) |
+| `mandate_type` | crisismaatregel, zorgmachtiging *(voorstel)* |
+| `mandate_decider_role` | burgemeester, rechter *(voorstel)* |
+| `crisis_fact_type` | medicatie_toegediend, risico_inschatting, vitale_functie, dwangmaatregel, overig *(voorstel)* |
+| `urgency_assessor_role` | screener, triagist, intake_team, mdo *(voorstel)* |
+| `urgency_level` | laag, normaal, hoog, spoed *(voorstel)* |
+
+Alle waardelijsten volgen het bestaande patroon (referentietabel met
+`code`, `omschrijving`, `geldig_van`/`geldig_tot`, `actief` — spelregel 3.1
+#1) en zijn hier nog geen definitieve besluiten.
+
+## 5. Waardelijst-vervanging: geen klassieke statusmachine
+
+`referral_case` heeft bewust geen `status`-kolom met vaste overgangen. De
+actuele stand wordt afgeleid door de gebeurtenissen in tijdsvolgorde te
+lezen:
+
+1. Is er een `case_withdrawal` zonder latere `care_acceptance_decision`? →
+   case is ingetrokken.
+2. Is er een `care_acceptance_decision` die niet door een ander besluit is
+   vervangen (`replaces_decision_id` wijst niet naar dit besluit)? → dat is
+   het geldige besluit; de case is besloten met die uitkomst.
+3. Is er een openstaand `case_information_request` zonder latere
+   `care_acceptance_decision` of `case_withdrawal`? → case wacht op
+   aanvullende informatie.
+4. Geen van bovenstaande? → case is in beoordeling (screening loopt of moet
+   nog beginnen).
+
+Dit is een leesregel voor de applicatielaag, geen opgeslagen veld — zo blijft
+de volledige tijdlijn de bron (consistent met B7 wachtlijst).
+
+**Implementatie-eis (UX-review 19 juli 2026, zie §9):** deze afleidingsregel
+wordt precies één keer geïmplementeerd, in één centrale, herbruikbare
+projectie (bijvoorbeeld een view of materialized read-model), niet los per
+scherm. Werklijst, dashboard en detailpagina lezen allemaal diezelfde
+projectie, nooit de losse events elk apart opnieuw. Zonder die eis ontstaat
+het risico dat schermen subtiel verschillende interpretaties van "de actuele
+stand" tonen — precies de drift die het tijdlijn-principe moest voorkomen.
+
+## 6. Buiten scope van dit document
+
+- Het volledige `clinical_care_episode`-model (programma-/organisatie-
+  betrokkenheid, zorgteam) — apart deelgebied, alleen ontstaan/einde hier.
+- `clinical_intake_assessment` en het behandeladvies — vraag 2 uit het
+  feitenmodel is nog open onderzoek.
+- PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING — al uitgewerkt in
+  `model-aanmelding.md` §2.1–§2.9; dit voorstel refereert ernaar zonder te
+  dupliceren.
+- Waardelijst-governance (wie mag waarden toevoegen) — ADM-ronde.
+- Declaratie-/prestatieregistratie-deelgebied — nodig voor de autoritatieve
+  NZa-365-dagentoets voor zorgtrajectnummer-hergebruik (zie
+  `possible_continuation_of_episode_id`, §2.18); dit voorstel modelleert
+  alleen een zorginhoudelijke benadering, geen declaratie-waarheid.
+- Productcodes/volumes bij `municipal_care_assignment` — minimale variant nu
+  (§2.15), net als bij TOEWIJZING in `model-aanmelding.md` §2.13; verdere
+  detaillering in de declaratie-ronde.
+- ~~Gestructureerde crisisdocumentatie vóór identificatie~~ — geadresseerd
+  met `crisis_encounter_note` (§2.17), gebaseerd op juridisch onderzoek 19
+  juli 2026 (zie §9).
+
+## 7. Open punten voor Colin
+
+**Beantwoord:**
+
+- ~~`person_id` verplicht op referral_request/referral_case?~~ Nee, optioneel
+  — komt voor bij crisisaanmeldingen met nog onbekende identiteit. Geen
+  placeholder-persoon; de koppeling wordt een eigen gedateerd feit
+  (`person_identified_at`/`_by`) zodra de identiteit vaststaat (domeinreview
+  19 juli 2026).
+- ~~Kan een request meerdere professional referrals hebben?~~ Ja — een
+  correctie of aanvulling is een wijziging, geen nieuwe verwijzing. Dezelfde
+  vervangt-constructie als bij `care_acceptance_decision`
+  (`replaces_referral_id` + verplichte reden); de oude verwijzing blijft
+  bewaard (domeinreview 19 juli 2026).
+
+**Voorstel op basis van precedent (ter evaluatie — nog niet door jou
+bevestigd):**
+
+- **Bevoegdheid bij case_consolidation.** Geen speciale
+  `decision_authority` vereist, zoals bij `submission_case_assignment` en
+  `submission_duplicate_assessment` — een administratieve correctie, geen
+  inhoudelijk zorgbesluit. Verwerkt in §2.9.
+- **Diepte van de vervangt-keten.** Onbeperkt, geen aparte constraint — de
+  afleidingsregel in §5 werkt voor elke lengte en een harde grens zou een
+  legitieme correctie-op-een-correctie zonder aantoonbare reden blokkeren.
+  Verwerkt in §2.12, §2.14, §3.
+- **`submission_link_type` vervalt.** Representeert/vult_aan is geen
+  zelfstandig feit met eigen regels, puur chronologisch afleidbaar uit
+  `established_at` (nu verplicht). Verwerkt in §2.4, §4.
+- **`request_case_link.reason`:** bevestigd zoals al voorgesteld — verplicht
+  alleen bij de uitzondering (meer dan één case per request), optioneel bij
+  de normale, enkelvoudige koppeling. Consistent met `submission_case_assignment`,
+  waar de reden ook alleen bij de eerste/bijzondere toewijzing werd genoemd.
+
+**Nog echt open:**
+
+1. **Startwaarden van de waardelijsten in §4** — met name `submission_channel`,
+   `document_type` en `screening_activity_type` zijn nu overgenomen uit de
+   voorbeeldfeiten, niet uit een volledige inventarisatie.
+2. **Volledig zorgteam-model.** `episode_team_involvement` (§2.20) is bewust
+   een minimale hook, geen individueel lidmaatschap, geen rollen, geen
+   regie-/hoofdbehandelaarschap, geen bevoegdheid, geen toekomstige
+   cliëntautorisatie. Het volledige zorgteam-concept — los van zorgprogramma
+   en organisatorische eenheid, die op hun beurt gekoppeld kunnen worden
+   (een organisatorische eenheid kan één of meer zorgprogramma's verzorgen)
+   — krijgt een eigen feitenronde (besluitenlog §10 punt 3; begrippenlijst
+   `Episode Clinical Team`/`Episode Team Assignment`/`Episode Team Role`/
+   `Lead Clinician Role`/`Decision Authority`). Deze hook wordt daardoor
+   vervangen of geabsorbeerd, niet doorontwikkeld binnen dit document.
+3. **Juridische aannames in §2.15–§2.17 die een jurist moet bevestigen**
+   (uit het onderzoek van 19 juli 2026, zie §9): geen apart institutioneel
+   acceptatiebesluit náást een Wvggz-mandaat (ook niet bij zorgmachtiging);
+   de 24-uurstermijn voor tenuitvoerlegging als nudge, niet als constraint;
+   de 14-dagentermijn voor identificatie als signaal-nudge; en of de
+   Jeugdwet-verwijsroute specifiek voor jeugd-ggz hetzelfde "naast elkaar,
+   geen vervanging"-patroon volgt als voor jeugdhulp in het algemeen. Deze
+   aannames blokkeren de modellering niet, maar moeten vóór productie
+   geverifieerd worden.
+
+## 8. Bronverwijzingen
+
+| Onderdeel | Bron |
+|---|---|
+| Alle feitzinnen, besloten regels en scenario's | `../feitenmodellen/feitenmodel-instroom.md` |
+| Screening=acceptatie, capaciteitsroutes, episodevorming | `../sessielogs/sessielog-2026-07-19.md` §5–§9 |
+| Tijdlijn i.p.v. statusmachine-principe | `../sessielogs/sessielog-2026-07-18.md` §5 (B7 wachtlijst), discovery §5.1 #5 |
+| PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING (hergebruikt, niet gedupliceerd) | `model-aanmelding.md` §2.1–§2.9 |
+| Engelstalig technisch model | besluit B20, `../besluiten/besluitenlog-datamodel-2026-07-18.md` §9 |
+
+## 9. Reviewronde 19 juli 2026
+
+Twee onafhankelijke reviews (technisch datamodel-perspectief, GGZ-domein-
+perspectief) op de eerste versie van dit document leverden 9 bevindingen op.
+Direct verwerkt in dit document, zonder verdere domeinvraag omdat het
+technische correcties of het herstellen van een omissie betrof:
+
+1. **Vervangt-keten kon vertakken.** `replaces_decision_id`/
+   `replaces_referral_id` zijn nu uniek indien gevuld — anders zou §5's
+   afleidingsregel geen eenduidig geldig besluit meer opleveren. Verwerkt in
+   §2.12, §2.14, §3.
+2. **Timestamp-precisie ondermijnde de tijdlijn-aanpak.** Event-velden die
+   ten onrechte op `datum` (dagprecisie) stonden zijn naar `tijdstip`
+   gebracht, consistent met `referral_submission.received_at` — anders zijn
+   gebeurtenissen op dezelfde kalenderdag niet eenduidig te ordenen. Verwerkt
+   op alle event-attributen behalve `professional_referral.referral_date`
+   (een extern documentdatum, geen systeemgebeurtenis) en
+   `request_case_link.since`.
+3. **ZPM-verplichte velden ontbraken.** `professional_referral.heraanmelding`
+   en `referral_case.zpm_verwijstype`/`huisarts_geinformeerd_op` stonden al
+   in het oudere `model-aanmelding.md` (AANMELDING/VERWIJZING) en zijn bij
+   het opnieuw opbouwen van dit deelgebied per abuis niet meegenomen — dit is
+   hersteld, geen nieuwe ontwerpvraag. AGB-code en correspondentietoestemming
+   bleken al gedekt via bestaande entiteiten (VERWIJZER, TOESTEMMING) en
+   kregen alleen een verduidelijkende notitie.
+
+Vervolgens is een tweede reviewronde uitgevoerd door drie onafhankelijke
+expert-agents: een datamodel-expert op de resterende technische punten, een
+GGZ-domein-expert op de domeinvragen, en een UX-expert op bruikbaarheid voor
+de uiteindelijke gebruikersinterface.
+
+**Technische punten (datamodel-expert) — direct verwerkt, mechanische
+correcties zonder domeinvraag:**
+
+- de lege, inconsistent gecardinaliseerde `screening`-entiteit is vervallen;
+  `screening_activity` hangt nu direct aan `referral_case` (§2.10);
+- naamgeving gecorrigeerd: `signal_case_assignment` → `submission_case_
+  assignment`, `access_case_consolidation` → `case_consolidation`,
+  `decision_authority_id`/`program_context` kregen Engelse ref-namen
+  conform B20 (§2.6, §2.7, §2.9, §2.12);
+- cardinaliteitsfout `referral_submission → case_information_request`
+  gecorrigeerd naar `0..1`; notatie-legenda toegevoegd aan §3;
+- unique constraint + check toegevoegd op `case_consolidation` (§2.9).
+
+**UX-punt (UX-expert) — direct verwerkt, implementatie-eis zonder
+domeinvraag:**
+
+- de afleidingsregel in §5 moet als één centrale projectie/read-model
+  geïmplementeerd worden, niet los per scherm — toegevoegd als expliciete
+  eis in §5.
+
+**Derde ronde — GGZ-wetgeving-expert (juridisch onderzoek) gevolgd door
+datamodel-expert (schema-integratie), verwerkt in dit document:**
+
+Een jurist-georiënteerd onderzoek naar Wvggz, Wmo/Jeugdwet, ZPM-regels en
+WGBO onderbouwde de vijf GGZ-scope-vragen uit de tweede ronde. De datamodel-
+expert vertaalde de bevindingen naar concreet schema. Verwerkt:
+
+- **Aanmelddatum.** Bevestigd als leesregel (geen nieuw veld): de vroegste
+  `referral_submission.received_at` die via `submission_request_link` aan het
+  request hangt, is het regelgevend juiste aanmelddatum-moment voor de
+  275-dagentoets. Redelijk zekere juridische basis (NZa-veldafspraken; exact
+  artikelnummer niet geverifieerd).
+- **Wmo/Jeugdwet.** `municipal_care_assignment` toegevoegd (§2.15) —
+  bestaat náást, niet in plaats van `professional_referral` (Jeugdwet kent
+  een zelfstandige professionele verwijsroute; Wmo niet). `referral_case.
+  wettelijk_kader` hersteld (§2.6). *Juridisch minder zeker: of dit patroon
+  specifiek voor jeugd-ggz identiek is aan jeugdhulp in het algemeen — zie §7
+  punt 3.*
+- **Wvggz.** `legal_mandate` toegevoegd (§2.16) — geen vervangt-relatie met
+  `care_acceptance_decision`, want geen institutionele discretie bij een
+  crisismaatregel (bindend burgemeesterlijk besluit). `clinical_care_episode`
+  aangepast: `originating_decision_id` optioneel, nieuw `originating_
+  mandate_id`, met een XOR-regel — een episode ontstaat óf uit een
+  acceptatiebesluit óf uit een mandaat (§2.18). *Juridisch minder zeker: of
+  dit ook voor de zorgmachtiging-route (rechter/officier van justitie) klopt
+  — zie §7 punt 3.*
+- **Heraanmelding/zorgtrajectnummer.** Herzien ten opzichte van het eerdere
+  voorstel: de NZa-365-dagenregel hangt aan de datum van de laatst geleverde
+  prestatie bij dezelfde aanbieder, niet aan de episode-einddatum, en is een
+  ander begrip dan `professional_referral.heraanmelding`. Omdat
+  prestatieregistratie nog geen deelgebied is, is `possible_continuation_
+  of_episode_id` toegevoegd (§2.18) als zorginhoudelijke
+  continuïteitsaanwijzing (episode-einddatum als benadering), expliciet
+  gemarkeerd als **geen** autoritatieve declaratietoets.
+- **Crisisdocumentatie vóór identificatie.** `crisis_encounter_note`
+  toegevoegd (§2.17), alle gestructureerde velden optioneel — geen expliciet
+  wetsartikel gevonden dat gestructureerde vastlegging tíjdens de
+  interventie verplicht, wel de algemene WGBO-dossierplicht. De gevonden
+  14-dagen-identificatietermijn is een signaal-nudge, geen constraint.
+
+Daarna is het eigenaarschap/urgentie-punt met Colin doorgesproken
+(domeinreview 19 juli 2026), met een scherpere uitkomst dan het
+UX-voorstel:
+
+- **Urgentie** is geen vast veld maar een herhaalbare beoordeling —
+  vastgesteld tijdens screening/triage door de rol screener/triagist, later
+  aan te passen door het intake-team of in een MDO. `case_urgency_assessment`
+  toegevoegd (§2.19): herhaalbaar, laatste geldt, geen vervangt-relatie nodig
+  (lagere inzet dan een acceptatiebesluit), geen verplichte onderbouwing
+  (bevestigd: eenvoudige waardelijst volstaat).
+- **Eigenaarschap** bleek eigenlijk een onderdeel van een groter, apart
+  begrip: **zorgteam** — het team van betrokken behandelaren (soms 1 persoon,
+  soms multidisciplinair, kan een organisatorische eenheid overstijgen), met
+  regie-/hoofdbehandelaarschap en later mogelijk cliëntautorisatie. Dat is
+  zelfstandig ten opzichte van zorgprogramma (inhoudelijk aanbod) en
+  organisatorische eenheid (die aan elkaar gekoppeld kunnen worden — een OE
+  kan één of meer zorgprogramma's verzorgen), en hoort bij een cliënt/case
+  kunnen staan zonder dat er al een individuele behandelaar is toegewezen
+  (bijvoorbeeld: geaccepteerd, intakewachtlijst — Route 2A). Op uitdrukkelijk
+  verzoek van Colin blijft dit nu beperkt tot een minimale, voorlopige hook
+  — `episode_team_involvement` (§2.20), geen rollen, geen bevoegdheid, geen
+  individueel lidmaatschap. Het volledige zorgteam-model krijgt een eigen
+  feitenronde (zie §7 punt 2).
+
+**Nog open:**
+
+- De juridische aannames uit de derde ronde (§7 punt 3) zijn in het schema
+  verwerkt maar nog niet door een jurist bevestigd.
+- Het volledige zorgteam-model (§7 punt 2).
diff --git a/docs/datamodel/feitenmodellen/feitenmodel-instroom.md b/docs/datamodel/feitenmodellen/feitenmodel-instroom.md
index 08096a9..ef6ab91 100644
--- a/docs/datamodel/feitenmodellen/feitenmodel-instroom.md
+++ b/docs/datamodel/feitenmodellen/feitenmodel-instroom.md
@@ -150,11 +150,21 @@ als zorgverzoek R-101.*
   spoed of crisis kan zorg al worden geleverd voordat de verwijzing is
   ontvangen.
 
+**Beantwoord in domeinreview (19 juli 2026):**
+
+- Een request kan zonder bekende persoon bestaan. Dit komt voor bij
+  crisisaanmeldingen waarbij de identiteit nog niet vaststaat. Een
+  placeholder- of "John Doe"-persoon die later moet worden om-gehangen is
+  bewust geen oplossing — dat vereist het achteraf verplaatsen van alle
+  gekoppelde feiten naar de echte persoon, wat tegen append-only ingaat. In
+  plaats daarvan is `person_id` optioneel en wordt de koppeling vastgelegd
+  als een eigen, gedateerd en toegeschreven feit zodra de identiteit bekend
+  wordt.
+
 **Te toetsen:**
 
 - Is “dezelfde geuite zorgvraag” een expliciete relatie tussen verzoeken, of
   wordt samenhang uitsluitend binnen de Referral Case beoordeeld?
-- Is een verzoek zonder bekende persoon tijdelijk toegestaan?
 
 ### 3.2 Afzonderlijke binnenkomst
 
@@ -489,7 +499,11 @@ cardinaliteiten.
 ### Referral Request
 
 - Elk request heeft één stabiele identiteit.
-- Elk request betreft op enig moment precies één persoon of cliënt.
+- Een request kan zonder bekende persoon bestaan (crisisaanmelding met nog
+  onbekende identiteit). Zodra de persoon bekend is, betreft het request
+  precies één persoon of cliënt; de koppeling zelf is een gedateerd,
+  toegeschreven feit, geen stille invulling van een placeholder (domeinreview
+  19 juli 2026).
 - Elk request heeft minstens één initiator.
 - Elk request bevat één of meer samenhangende geuite zorgvragen.
 - Zorgvragen die afzonderlijk moeten worden beoordeeld horen in afzonderlijke