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 §4 waardelijst 17 (bestaande waardelijst)
zpm_verwijstype	over te nemen uit model-aanmelding.md §4 waardelijst 18 (bestaande waardelijst, ZPM-verwijstypen 01–07)
wettelijk_kader	over te nemen uit model-aanmelding.md §4 waardelijst 12 (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).