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

CodeAGB verplicht
huisartsja
medisch_specialistte bevestigen
ggz_instellingte bevestigen
bedrijfsartste bevestigen
gemeentenee
zelfaanmeldingnee
crisiste 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.