triqura-ecd/docs/datamodel/deelmodellen/model-instroom.md

# 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).