docs(datamodel): instroom entiteiten/cardinaliteiten + vier reviewrondes
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.
This commit is contained in:
colinislit
849
docs/datamodel/deelmodellen/model-instroom.md
Normal file
849
docs/datamodel/deelmodellen/model-instroom.md
Normal file
@@ -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).
|
||||||
@@ -150,11 +150,21 @@ als zorgverzoek R-101.*
|
|||||||
spoed of crisis kan zorg al worden geleverd voordat de verwijzing is
|
spoed of crisis kan zorg al worden geleverd voordat de verwijzing is
|
||||||
ontvangen.
|
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:**
|
**Te toetsen:**
|
||||||
|
|
||||||
- Is “dezelfde geuite zorgvraag” een expliciete relatie tussen verzoeken, of
|
- Is “dezelfde geuite zorgvraag” een expliciete relatie tussen verzoeken, of
|
||||||
wordt samenhang uitsluitend binnen de Referral Case beoordeeld?
|
wordt samenhang uitsluitend binnen de Referral Case beoordeeld?
|
||||||
- Is een verzoek zonder bekende persoon tijdelijk toegestaan?
|
|
||||||
|
|
||||||
### 3.2 Afzonderlijke binnenkomst
|
### 3.2 Afzonderlijke binnenkomst
|
||||||
|
|
||||||
@@ -489,7 +499,11 @@ cardinaliteiten.
|
|||||||
### Referral Request
|
### Referral Request
|
||||||
|
|
||||||
- Elk request heeft één stabiele identiteit.
|
- 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 heeft minstens één initiator.
|
||||||
- Elk request bevat één of meer samenhangende geuite zorgvragen.
|
- Elk request bevat één of meer samenhangende geuite zorgvragen.
|
||||||
- Zorgvragen die afzonderlijk moeten worden beoordeeld horen in afzonderlijke
|
- Zorgvragen die afzonderlijk moeten worden beoordeeld horen in afzonderlijke
|
||||||
|
|||||||
Reference in New Issue
Block a user