ECD · datamodel discovery

# Entiteitenkaart — instroomflow

Afgeleid uit de feitzinnen in `datamodel-discovery.md` §5.1–5.5: van persoon en aanmelding via screening, intake en wachtlijst tot diagnose en behandelplan, met de bijbehorende waardelijsten. Status: concept, ter review — vóór dit naar SQL gaat, checkt Colin de entiteiten, kardinaliteiten en waardelijst-waarden.

## Samenhang — de keten in één oogopslag

Aanmelding en zorgepisode zijn géén gelijke niveaus: de aanmelding is de binnenkomst en het besluitproces (daar horen screening en aanmeldwachttijd bij), de zorgepisode is de periode van zorg die pas ontstaat als het besluit "intake" is. Alles in de onderste doos hangt aan de episode. De pijlen binnen de episode tonen de chronologie (intake → diagnose → behandelplan); in het datamodel hangen alle drie rechtstreeks aan de episode, met de intake als optionele herkomst van de diagnose.

    flowchart TB
        CL["CLIËNT (rol op PERSOON)"] -->|"meldt zich aan — 1 op veel"| AANM
        subgraph AANMBOX["AANMELDING — binnenkomst en besluitproces"]
            direction TB
            AANM["Aanmelding
    verwijzer · wettelijk kader · hulpvraag"]
            AANM --> SCR["Screening
    activiteiten + besluit"]
            AANM -.-> WLA["Wachtlijstplaatsing
    soort: aanmeld"]
            SCR --> UIT{"Uitkomst
    bij status besloten"}
        end
        UIT -->|"afgewezen · doorverwezen"| EINDE["geen episode"]
        UIT -->|"wachtlijst"| WLA
        UIT ==>|"intake"| EPI
        subgraph EPIBOX["ZORGEPISODE — periode van zorg, 0..1 per aanmelding"]
            direction TB
            EPI["Zorgepisode"]
            EPI --> INT["Intake(s)
    aanleiding: regulier · intern · crisis"]
            EPI -.-> WLB["Wachtlijstplaatsing
    soort: behandel"]
            INT --> DIA["Diagnose(s)
    DSM-5-TR · gesteld tijdens intake"]
            DIA --> PLAN["Behandelplan
    doelen · interventies · evaluaties"]
        end

## Diagram 1 — persoon & aanmelding (§5.1)

Rechthoeken met een sleutel (`PK`) zijn entiteiten met een eigen identiteit; entiteiten met alleen een `code`-sleutel zijn waardelijsten (referentiedata, geen eigen levenscyclus).

    erDiagram
        PERSOON ||--o| CLIENT : "is cliënt sinds"
        CLIENT ||--o{ AANMELDING : "meldt zich aan"
        CLIENT ||--o| CLIENTPORTAAL_ACCOUNT : "heeft toegang via"
        AANMELDING ||--o| ZORGEPISODE : "start bij uitkomst intake"
        AANMELDING }o--|| WETTELIJK_KADER : "valt onder"
        AANMELDING }o--|| AANMELDING_STATUS : "heeft"
        AANMELDING }o--o| AANMELDING_UITKOMST : "heeft, bij besloten"
        AANMELDING }o--o| VERWIJZER : "komt binnen via"
        AANMELDING ||--o{ VERWIJSDOCUMENT : "ontvangt"
        VERWIJSDOCUMENT }o--|| VERWIJSDOCUMENT_TYPE : "is van type"
        VERWIJZER }o--|| VERWIJZERTYPE : "is van type"
        VERWIJZER }o--o| PRAKTIJK_INSTELLING : "verbonden aan"

        PERSOON {
            uuid id PK
            string naam
            date geboortedatum
            string bsn_encrypted "optioneel"
        }
        CLIENT {
            uuid id PK
            uuid persoon_id FK
            string clientnummer UK
            date sinds
        }
        CLIENTPORTAAL_ACCOUNT {
            uuid id PK
            uuid client_id FK
            string status
        }
        AANMELDING {
            uuid id PK
            uuid client_id FK
            date datum
            string hulpvraag
        }
        ZORGEPISODE {
            uuid id PK
            uuid aanmelding_id FK
            date gestart_op
            date beeindigd_op "optioneel"
        }
        VERWIJZER {
            uuid id PK
            string naam
            string agb_code
        }
        PRAKTIJK_INSTELLING {
            uuid id PK
            string naam
            string agb_code
        }
        VERWIJSDOCUMENT {
            uuid id PK
            uuid aanmelding_id FK
            date ontvangen_datum
        }
        VERWIJZERTYPE {
            string code PK
            string label
            boolean agb_verplicht
        }
        WETTELIJK_KADER {
            string code PK
            string label
        }
        AANMELDING_STATUS {
            string code PK
            string label
        }
        AANMELDING_UITKOMST {
            string code PK
            string label
        }
        VERWIJSDOCUMENT_TYPE {
            string code PK
            string label
        }

Niet in het diagram, maar op elke entiteit van toepassing (spelregels §3.1): `id` (uuid), `created_at`/`updated_at`, `deleted_at` (soft delete), en een append-only audit-event per mutatie. Weggelaten voor leesbaarheid, niet omdat ze niet gelden.

## Diagram 2 — screening & intake (§5.2)

De screening hoort bij de aanmelding (besluitproces); intakes horen bij de zorgepisode. Eén episode kan meerdere intakes hebben — naast de reguliere intake bestaan interne intakes binnen een lopende episode; de `aanleiding` legt het verschil vast. Screening vóór intake is een nudge, geen harde volgorde-eis in het schema.

    erDiagram
        AANMELDING ||--o| SCREENING : "wordt gescreend in"
        SCREENING ||--o{ SCREENING_ACTIVITEIT : "omvat"
        SCREENING_ACTIVITEIT }o--|| SCREENING_ACTIVITEIT_TYPE : "is van type"
        SCREENING }o--o| SCREENING_BESLUIT : "besluit, bij afronding"
        SCREENING }o--o| AFDELING : "adviseert"
        ZORGEPISODE ||--o{ INTAKE : "omvat"
        INTAKE }o--|| INTAKE_AANLEIDING : "gestart vanwege"
        INTAKE }o--|| INTAKE_STATUS : "heeft"
        INTAKE }o--o| INTAKE_UITKOMST : "heeft, bij afgerond"
        INTAKE }o--|| AFDELING : "op afdeling"
        INTAKE ||--o{ CONTACTMOMENT : "omvat"
        CONTACTMOMENT }o--|| CONTACTMOMENT_TYPE : "is van type"
        INTAKE ||--o| KINDCHECK : "heeft"

        SCREENING {
            uuid id PK
            uuid aanmelding_id FK
            date gestart_op
            date besluit_datum "optioneel"
        }
        SCREENING_ACTIVITEIT {
            uuid id PK
            uuid screening_id FK
            date datum
            string toelichting
            uuid uitgevoerd_door "rollenronde"
        }
        INTAKE {
            uuid id PK
            uuid zorgepisode_id FK
            date gestart_op
            date afgerond_op "optioneel"
        }
        CONTACTMOMENT {
            uuid id PK
            uuid intake_id FK
            date datum
            uuid gevoerd_door "rollenronde"
        }
        KINDCHECK {
            uuid id PK
            uuid intake_id FK
            date uitgevoerd_op
            boolean thuiswonende_kinderen
            boolean zorgen_veiligheid
            boolean actie_ondernomen
            string toelichting
        }
        SCREENING_ACTIVITEIT_TYPE {
            string code PK
            string label
        }
        SCREENING_BESLUIT {
            string code PK
            string label
        }
        AFDELING {
            string code PK
            string label
        }
        INTAKE_AANLEIDING {
            string code PK
            string label
        }
        INTAKE_STATUS {
            string code PK
            string label
        }
        INTAKE_UITKOMST {
            string code PK
            string label
        }
        CONTACTMOMENT_TYPE {
            string code PK
            string label
        }

ZORGPROGRAMMA (FACT, Verslaving, Trauma, ...) is als waardelijst besloten maar heeft nog geen relatie in dit diagram — de koppeling (aan behandeladvies of traject) volgt in de ronde diagnose & behandeltraject. Verslagen (feitzin 9, provenance) volgen in de rapportage-ronde.

## Diagram 3 — wachtlijst, diagnose & behandelplan (§5.3–5.5)

De aanmeldwachttijd hangt aan de AANMELDING (besluitproces); diagnoses, behandelplannen en de behandelwachttijd hangen aan de ZORGEPISODE. De diagnose wordt in DSM-5-TR geregistreerd; de ICD-10-code wordt via een mappingtabel afgeleid. Het behandelplan is hier de kern — sessieplanning, leefgebieden en veiligheidsplan volgen in latere rondes.

    erDiagram
        AANMELDING ||--o{ WACHTLIJSTPLAATSING : "aanmeldwachttijd"
        ZORGEPISODE ||--o{ WACHTLIJSTPLAATSING : "behandelwachttijd"
        WACHTLIJSTPLAATSING }o--|| WACHTLIJST_SOORT : "is van soort"
        WACHTLIJSTPLAATSING }o--|| PRIORITEIT : "heeft"
        WACHTLIJSTPLAATSING }o--|| AFDELING : "voor afdeling"
        WACHTLIJSTPLAATSING }o--o| WACHTLIJST_EINDREDEN : "beëindigd met"

        ZORGEPISODE ||--o{ DIAGNOSE : "heeft"
        DIAGNOSE }o--|| ERNST : "heeft"
        DIAGNOSE }o--|| DIAGNOSE_STATUS : "klinische status"
        DIAGNOSE }o--|| VERIFICATIESTATUS : "werkdiagnose of definitief"
        DIAGNOSE }o--o| INTAKE : "gesteld tijdens"
        DIAGNOSE }o--|| DSM_ICD_MAPPING : "geclassificeerd als"

        ZORGEPISODE ||--o{ BEHANDELPLAN : "heeft"
        BEHANDELPLAN }o--|| PLAN_STATUS : "heeft"
        BEHANDELPLAN }o--o{ DIAGNOSE : "adresseert"
        BEHANDELPLAN }o--o| INTAKE : "gebaseerd op"
        BEHANDELPLAN ||--o{ BEHANDELDOEL : "bevat"
        BEHANDELDOEL }o--|| DOEL_STATUS : "heeft"
        BEHANDELPLAN ||--o{ INTERVENTIE : "bevat"
        INTERVENTIE }o--o{ BEHANDELDOEL : "werkt aan"
        BEHANDELPLAN ||--o{ EVALUATIEMOMENT : "kent"
        EVALUATIEMOMENT }o--|| EVALUATIE_TYPE : "is van type"

        WACHTLIJSTPLAATSING {
            uuid id PK
            uuid aanmelding_id FK "bij soort aanmeld"
            uuid zorgepisode_id FK "bij soort behandel"
            date geplaatst_op
            date telt_vanaf
            date beeindigd_op "optioneel"
        }
        DIAGNOSE {
            uuid id PK
            uuid zorgepisode_id FK
            string dsm_code
            string omschrijving
            boolean hoofddiagnose
            date gesteld_op
            uuid gesteld_door "rollenronde"
        }
        DSM_ICD_MAPPING {
            string dsm_code PK
            string icd10_code
            string dsm_omschrijving
        }
        BEHANDELPLAN {
            uuid id PK
            uuid zorgepisode_id FK
            int versie
            date opgesteld_op
            date client_akkoord_op "optioneel"
        }
        BEHANDELDOEL {
            uuid id PK
            uuid behandelplan_id FK
            string titel
            string clientversie_b1
            string prioriteit
            int termijn_weken
        }
        INTERVENTIE {
            uuid id PK
            uuid behandelplan_id FK
            string naam
            string rationale
        }
        EVALUATIEMOMENT {
            uuid id PK
            uuid behandelplan_id FK
            int week
            date gepland_op
            date uitgevoerd_op "optioneel"
        }
        WACHTLIJST_SOORT {
            string code PK
            string label
        }
        PRIORITEIT {
            string code PK
            string label
        }
        WACHTLIJST_EINDREDEN {
            string code PK
            string label
        }
        ERNST {
            string code PK
            string label
        }
        DIAGNOSE_STATUS {
            string code PK
            string label
        }
        VERIFICATIESTATUS {
            string code PK
            string label
        }
        PLAN_STATUS {
            string code PK
            string label
        }
        DOEL_STATUS {
            string code PK
            string label
        }
        EVALUATIE_TYPE {
            string code PK
            string label
        }

Aannames ter bevestiging: versiebeheer als nieuw record per versie (`versie`-veld) · cliëntakkoord als datum-feit, niet als status · "max één hoofddiagnose" als constraint — maar per wat (episode / moment) is nog open. WACHTLIJSTPLAATSING heeft twee optionele FK's; welke gevuld is volgt uit de soort (aanmeld → aanmelding, behandel → episode).

## Waardelijsten

De daadwerkelijke waarden per referentietabel, zodat je kunt controleren of de lijst klopt en compleet is.

### VERWIJZERTYPE

Code | AGB verplicht
--- | ---
huisarts | ja
medisch_specialist | te bevestigen
ggz_instelling | te bevestigen
bedrijfsarts | te bevestigen
gemeente | nee
zelfaanmelding | nee
crisis | te bevestigen

### WETTELIJK_KADER

Code
zvw
jeugdwet
wmo
wlz
forensisch

### AANMELDING_STATUS

Code
nieuw
in_screening
besloten

Overgangen zijn vrij — een `besloten` aanmelding kan terug naar `in_screening` bij heropening. Geen eenrichtingsflow.

### AANMELDING_UITKOMST

Code
intake
afgewezen
doorverwezen
wachtlijst

Alleen gezet zodra status = `besloten`.

### VERWIJSDOCUMENT_TYPE

Code
verwijsbrief
beschikking

Lijst waarschijnlijk niet compleet — open voor aanvulling.

### AFDELING

Code
volwassenen
jeugd
ouderen
forensisch

Organisatorische eenheid; per instelling configureerbaar. Startlijst te bevestigen — FACT en Verslaving zijn bewust géén afdeling (zie ZORGPROGRAMMA).

### ZORGPROGRAMMA

Code
algemeen_ggz
fact
verslaving
trauma

Inhoudelijk aanbod, los van afdeling. Koppeling volgt in de ronde diagnose & behandeltraject.

### SCREENING_ACTIVITEIT_TYPE

Code
telefonisch_contact
dossieronderzoek
vragenlijst
overig

Type + vrije toelichting per activiteit. Startlijst te bevestigen.

### SCREENING_BESLUIT

Code
geschikt
niet_geschikt

Verhouding tot AANMELDING_UITKOMST is een open vraag (overlap "geschikt" ↔ "intake").

### INTAKE_AANLEIDING

Code
regulier
intern
crisis

Regulier = vanuit aanmelding/screening; intern = tweede intake binnen lopende episode (bijv. afdelingsovergang). Lijst te bevestigen.

### INTAKE_STATUS

Code
bezig
afgerond

Uit het prototype overgenomen; mogelijk komt er nog een status bij (bijv. gepland).

### INTAKE_UITKOMST

Code
in_zorg
doorverwijzing
extra_diagnostiek

Alleen gezet bij status = `afgerond`. Waarden uit het prototype — te bevestigen.

### CONTACTMOMENT_TYPE

Code
intakegesprek
aanvullend_onderzoek
telefonisch_contact
huisbezoek
overig

### WACHTLIJST_SOORT

Code
aanmeld
behandel

Volgt de Treeknormen: aanmeldwachttijd (vóór intake) en behandelwachttijd (na intake).

### PRIORITEIT

Code
spoed
normaal
laag

### WACHTLIJST_EINDREDEN

Code
intake_gestart
behandeling_gestart
doorverwezen
teruggetrokken

Startlijst te bevestigen.

### ERNST

Code
licht
matig
ernstig

### DIAGNOSE_STATUS

Code
actief
in_remissie
opgelost
inactief

Klinische status — losse as naast VERIFICATIESTATUS.

### VERIFICATIESTATUS

Code
werkdiagnose
definitief

Aparte status-as — te bevestigen (zat in het prototype-model maar werd niet gebruikt).

### PLAN_STATUS

Code
concept
actief
afgerond
vervallen

Voorstel — de statusmachine (incl. plaats van cliëntakkoord) is nog een open vraag.

### DOEL_STATUS

Code
niet_gestart
bezig
gehaald
bijgesteld

### EVALUATIE_TYPE

Code
tussentijds
eind
crisis

## Openstaand / geparkeerd

1. AGB-validatie tegen een echte Vecozo-tabel — nu vrije invoer, geen validatie.
   Geparkeerd tot de declaratie-ronde.
2. Wie mag de aanmelding-status zetten — nog geen rollen/disciplines gemodelleerd.
   Komt terug zodra die ronde wordt gedaan.
3. AGB-verplichting per verwijzertype — alleen huisarts (ja) en gemeente (nee) zijn expliciet besproken; de overige vier staan als "te bevestigen" in de tabel hierboven.
4. Verwijsbrief/beschikking is een nudge, geen schema-constraint — leeft in de Protocol Rules Registry (Nudge Engine), niet zichtbaar als FK-verplichting in dit diagram.
5. CLIENTPORTAAL_ACCOUNT is nog een lege huls — alleen de relatie (1-op-0..1 op CLIENT) staat vast.
   Authenticatiedetails (e-mail, provider-koppeling, status) volgen in de auth/ADM-ronde.
6. Verwijzersportaal — nog geen besluit, alleen een idee. Mogelijk krijgt een verwijzer ook toegang tot de status van zijn verwijzingen, analoog aan `CLIENTPORTAAL_ACCOUNT`.
   Niet in dit diagram opgenomen — apart onderwerp voor een volgende ronde als het een echte behoefte blijkt.
7. BSN is optioneel op PERSOON — een medewerker is ook een persoon en heeft geen BSN in het systeem nodig. De verplichting hoort bij de rol (voor cliënten: Wabvpz).
   Nudge ("cliënt zonder BSN") of rolgebonden eis — te bepalen in de rollenronde.
8. Screeningsbesluit ↔ aanmelding-uitkomst — "geschikt" (screening) en uitkomst "intake" (aanmelding) overlappen mogelijk: één feit of twee?
   Open vraag voor een volgende sessie.
9. Startlijsten te bevestigen — AFDELING, ZORGPROGRAMMA, SCREENING_ACTIVITEIT_TYPE, INTAKE_AANLEIDING en INTAKE_UITKOMST zijn afgeleid uit het prototype en nog niet definitief.
10. Kindcheck-structuur — nu gemodelleerd als drie ja/nee-vlaggen + toelichting (zoals het prototype), niet als één uitkomstwaarde.
    Bevestigen of dit de juiste registratievorm is (Meldcode-eisen meenemen).
11. Screening vóór intake is een nudge — geen harde volgorde-eis in het schema; protocolregel bij de eerste intake van een episode.
12. Behandelplan: statusmachine, versiebeheer-vorm en verplichting nog open — cliëntakkoord als status of feit (WGBO), nieuw record per versie of muteren met audit, en behandelplan-verplicht-vóór-behandeling als nudge of harde eis.
13. Wanneer ontstaat de ZORGEPISODE precies — pas bij aanmelding-uitkomst "intake", of al bij "wachtlijst"?
    Bepaalt waar de behandelwachttijd van een nog-niet-gestarte episode aan hangt.
14. DSM-ICD-mappingtabel heeft een bron nodig — wie levert en onderhoudt de mapping (en de DSM-5-TR-lijst zelf, licentie APA)?
    Uitzoeken vóór de schema-baseline; raakt ook de declaratie-ronde.
15. Wachtlijst per afdeling en/of zorgprogramma — nu alleen afdeling gemodelleerd; en de beëindigingsredenen-startlijst is te bevestigen.