ECD · datamodel discovery

# Entiteitenkaart — instroomflow

Afgeleid uit de feitzinnen in `datamodel-discovery.md` §5.1. Persoon, cliëntrol, aanmelding, verwijzer en de bijbehorende waardelijsten. Status: concept, ter review — vóór dit naar SQL gaat, checkt Colin de entiteiten, kardinaliteiten en waardelijst-waarden.

## Diagram

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--|| 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
        }
        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 hierboven 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.

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

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