docs(datamodel): FCO-IM feitenronde instroom, besluitenlog + herstructurering

Voegt de discovery- en besluitvormingsronde van 18-19 juli toe (besluitenlog,
begrippenlijst, feitenmodel-instroom met scenariotoetsen, terminologie- en
leveranciersonderzoek) en synchroniseert feitenmodel-instroom.md met de
screening=acceptatie-beslissing (§5). Herstructureert docs/datamodel/ naar
submappen per documentsoort (besluiten/sessielogs/feitenmodellen/deelmodellen/
onderzoek/entiteitenkaarten) zodat toekomstige besluitenlogs en feitenrondes
per deelgebied een vaste plek krijgen.

docs/datamodel/deelmodellen/datamodel-discovery.md

@@ -0,0 +1,214 @@
+# Datamodel Discovery — ECD
+
+**Status:** verkenning, geen ontwerp  
+**Besluitenupdate:** zie `../besluiten/besluitenlog-datamodel-2026-07-18.md`. Dit besluitenlog is leidend waar de eerdere discovery of deelmodellen ermee conflicteren.
+**Datum:** 16 juli 2026
+**Werkwijze:** FCO-IM-geïnspireerd (feitzinnen eerst), visualisaties in HTML op verzoek
+**Kader:** ECD bevat ECD-data (proces-state blijft in TIP) · FHIR is niet heilig · huidig prototype-schema is géén vertrekpunt
+
+---
+
+## 1. Waarom deze discovery
+
+Het prototype-datamodel is de bron van vrijwel alle gevonden gebreken: labels vs. codes, twee modules op één tabel, schema niet reproduceerbaar, regels die alleen in de UI leven. We bouwen het ECD opnieuw op een eigen model. Dit document verkent de uitgangspunten en de werkvorm — er wordt nog niets gebouwd.
+
+## 2. Methode: feiten eerst (FCO-IM)
+
+We modelleren niet met tabellen als startpunt, maar met **feitzinnen in natuurlijke taal**, uitgesproken door de domeinexpert (Colin). Uit die zinnen leiden we elementaire feiten af, en dááruit het model. Dit is de kern van FCO-IM: het model legt de *communicatie* over het domein vast, en daarmee blijft de betekenis (semantiek) bewaard — leesbaar voor behandelaar én ontwikkelaar. Vanuit een elementair feitenmodel zijn ER-diagrammen, relationele schema's en zelfs graph-modellen af te leiden.
+
+**Werkvorm per flow:**
+1. Claude stelt een startlijst feitzinnen op vanuit de bestaande schermen en use-cases
+2. Colin corrigeert, schrapt en vult aan ("zo zeggen wij dat niet", "dit feit ontbreekt")
+3. Samen benoemen we per feit: uniciteit (kan dit feit maar één keer waar zijn?), verplichtheid, wie het feit mag vastleggen/wijzigen
+4. Claude leidt er de entiteitenkaart uit af (HTML-visualisatie) → review → pas daarna SQL
+
+## 3. Uitgangspunten voor het datamodel
+
+### 3.1 Harde spelregels
+1. **Waardelijsten op één plek** — types, statussen, afdelingen als data (referentietabellen), UI en database delen dezelfde bron. Directe les uit de kapotte intake-tabs.
+2. **Herkomst (provenance) op elk klinisch record** — auteur (mens/AI), bij AI: model + bronverwijzingen; content-hash zodat gewijzigde tekst automatisch her-embedding triggert.
+3. **Append-only audit** — geen UPDATE/DELETE op audit; hash-chaining (elk event hasht het vorige) maakt manipulatie detecteerbaar; NEN 7510: 5 jaar bewaren.
+4. **Soft delete overal** — `deleted_at`, nooit hard delete; definitieve verwijdering na wettelijke termijn via batchjob.
+5. **Stabiele UUID's** — één identiteit per record; vector-hits en (later) graph-nodes wijzen altijd terug naar hetzelfde PostgreSQL-record.
+6. **BSN: opslaan, maar afgeschermd** — zorgaanbieders zijn wettelijk verplicht het BSN te gebruiken (Wabvpz: declaraties, Vecozo, verwijzingen), dus het ECD slaat het op — versleuteld in de database, toegang op need-to-know, elke inzage gelogd. De echte regel: het BSN komt **nooit** in AI-prompts, embeddings, logs of events richting TIP. (Wijkt bewust af van het architectuurdocument v0.1 — "alleen bsn_hash" past bij een AI-laag boven een bestaand EPD, niet bij een zelfstandig ECD; correctie meenemen in v0.2.)
+7. **Regels in het model, niet alleen in de UI** — "max één hoofddiagnose per traject" is een database-constraint.
+8. **Reproduceerbaar schema** — alles in migrations vanaf een verse baseline; de `conditions`-tabel-zonder-migration mag nooit meer gebeuren.
+9. **Statusmachines expliciet** — per entiteit: welke statussen, welke overgangen, wie mag ze zetten. In een referentietabel of check-constraint, niet impliciet in schermcode.
+
+### 3.2 AI-voorbereiding (vector + graph)
+- **Tekst en structuur in hetzelfde record** — elk verslag heeft gestructureerde velden (voor regels/filters) én vrije tekst (voor embeddings).
+- **pgvector vanaf dag één** — extensie in dezelfde PostgreSQL; embeddings in een aparte tabel (`record_id`, `chunk_index`, `embedding`, `model`, `content_hash`) zodat her-embedden en modelwissel geen schemawijziging zijn. Productie-les uit het veld: event-driven her-embedding (trigger bij mutatie) boven periodieke batch.
+- **Neo4j: ontwerpen, niet aanzetten** — de graph-vragen (ZPM: diagnose → prestatiecode → bevoegdheid) komen uit dezelfde bron-records; zolang ID's stabiel zijn kan de graaf later zonder migratie worden opgebouwd.
+
+### 3.3 Grensvlak met TIP
+- ECD = klinische feiten (bron van waarheid voor het dossier). TIP = proces-state en beslislogica.
+- Per entiteit leggen we in de discovery een kolom **eigenaarschap** vast: leidend in ECD, en welke gebeurtenissen als event naar TIP gaan.
+
+**Afstemming Joshua (17 juli 2026):**
+1. **TIP-eigen beslis-state** (workspaces, intents, taken) heeft geen ECD-tegenhanger — per definitie geen dubbeling. Brondata hoort bij de bron; het ECD is leidend.
+2. **Auditkopie**: TIP maakt een snapshot van de data waarop een intentie/nudge/actie is gebaseerd — doelgebonden, met herkomst erop. Zonder snapshot is niet herleidbaar waarop een besluit rustte; dit is juist het onderscheidend vermogen.
+3. **Longitudinale IE's**: voor trendmeting houdt TIP relevante informatie-elementen door de tijd vast. Bewuste, minimale dubbeling — TIP slaat alleen de IE's op die nodig zijn om tot intenties/nudges/acties te komen.
+4. **Koppelafspraak nodig**: hoe valt een wijziging in het ECD (correctie, soft delete) door naar TIP zodat de kopie niet veroudert? Het ECD-model levert hiervoor de bouwstenen die er al in zitten: stabiele UUID's, content-hash per record en mutatie-events (zelfde mechanisme als event-driven her-embedding, §3.2).
+
+Kortom: wel een bewuste, minimale, herleidbare kopie waar nodig; geen schaduwadministratie.
+
+## 4. Context: standaarden en koppelvlakken (geen datamodel-regels)
+
+Het datamodel ontwerpen we volledig op eigen termen, vanuit de feitzinnen. FHIR, zibs en openEHR zijn koppelvlak- en uitwisselingszaken; uitwisseling loopt via onze eigen API's. Deze learnings zijn relevant als achtergrond, maar stellen geen eisen aan het model:
+
+- **FHIR**: puur uitwisselformaat. Komt alleen ooit terug in een adapter of export (deployment model B richting bestaande EPD's).
+- **zibs (Nictiz)**: semantische definities van klinische begrippen. Bruikbaar als gratis checklist per entiteit ("welke velden hoort een verwijzing te hebben?", Wvggz-registratie-eisen) — het model blijft van ons.
+- **openEHR**: nemen we niet over; alleen de ontwerples "stabiele kern als schema, veranderlijke inhoud als data" — die al in het Triqura-architectuurdocument stond (ADR-03).
+- **Aandachtspunt** (geen regel): drijf semantisch niet nodeloos af van wat de Nederlandse zorg onder een begrip verstaat — dat houdt een eventuele adapter later goedkoop.
+
+## 5. Scope ronde 1: instroom t/m behandelplan
+
+**Scopeverbreding (sessie 17 juli 2026):** ronde 1 loopt van aanmelding t/m het opstellen van het behandelplan — dus inclusief wachtlijstbeheer (§5.3), diagnose stellen (§5.4) en behandelplan opstellen (§5.5). Agenda en rapportage & overdracht blijven latere rondes.
+
+### 5.0 Besluiten basis (sessie 16 juli, Colin)
+
+1. **Terminologie: "cliënt"** — overal, ook in tabelnamen. (Prototype mixte patients/cliënten.)
+2. **Persoon ≠ patiënt-zijn**: één CLIËNT-record per persoon; zorg is episodisch via AANMELDING (1 cliënt → meerdere aanmeldingen door de tijd).
+3. **Verwijzer is een eigen begrip** met type uit een waardelijst: huisarts, medisch specialist, GGZ-instelling, bedrijfsarts, gemeente, zelfaanmelding, crisis. Routes niet hardcoden.
+4. **Wettelijk kader hoort bij de aanmelding** (Zvw, Jeugdwet, Wmo, Wlz, forensisch) — bepaalt ook de financierings-/declaratiekant. Jeugd loopt onder de huidige wetgeving indirect via de gemeente.
+5. **Parallelle aanmeldingen**: nog geen besluit. Structuur ondersteunt meerdere; "max één actief" wordt een aan/uit-zetbare bedrijfsregel, geen schemabeperking.
+
+### 5.1 Feitzinnen basis (herzien na besluiten)
+
+1. *Persoon Jan de Vries is geboren op 12-03-1988.*
+2. *Jan de Vries is sinds 14 juli 2026 cliënt bij de instelling, onder cliëntnummer 427.*
+3. *Jan de Vries heeft zich op 14 juli 2026 aangemeld bij de instelling.*
+4. *Verwijzer P. Pietersen is van het type huisarts.*
+5. *Verwijzer P. Pietersen is verbonden aan praktijk/instelling "Huisartsenpraktijk De Vries & Pietersen".*
+6. *Praktijk/instelling "Huisartsenpraktijk De Vries & Pietersen" heeft AGB-code 12345678.*
+7. *Verwijzer P. Pietersen heeft zelf ook AGB-code 87654321 (persoonlijk, naast de praktijk-AGB).*
+8. *De aanmelding van 14 juli 2026 is ontvangen via verwijzer P. Pietersen.*
+9. *De aanmelding van 14 juli 2026 valt onder wettelijk kader Zvw.*
+10. *De aanmelding van 14 juli 2026 heeft als hulpvraag "somberheidsklachten, slaapproblemen".*
+11. *De aanmelding van 14 juli 2026 heeft status "nieuw".*
+12. *Bij de aanmelding van 14 juli 2026 is verwijsdocument document-812 (type: verwijsbrief) ontvangen.*
+13. *Cliënt Jan de Vries heeft toegang tot het cliëntportaal.*
+
+**Besluiten (sessie 17 juli 2026, Colin):**
+1. **PERSOON en CLIENT gesplitst.** PERSOON draagt de identiteit (naam, geboortedatum, BSN) en blijft bestaan onafhankelijk van zorg. CLIENT is een rol/koppeltabel op PERSOON (cliëntnummer, cliënt-sinds-datum), niet meer één platte entiteit. Reden: dezelfde persoon kan later ook een andere rol hebben (contactpersoon, wettelijk vertegenwoordiger van iemand anders' dossier, medewerker) zonder een dubbel persoonsrecord. Dit verfijnt besluit 5.0.2 ("persoon ≠ patiënt-zijn") — die tekst benoemde het onderscheid al, maar modelleerde nog één CLIENT-record; nu krijgt PERSOON zijn eigen entiteit.
+   - **BSN is optioneel op PERSOON.** Niet elke persoon heeft een BSN nodig in het systeem — een medewerker is ook een persoon. De verplichting hoort bij de rol: voor de cliëntrol is het BSN nodig (Wabvpz: declaraties, Vecozo, verwijzingen — zie spelregel 3.1 #6), voor andere rollen niet. Of dat een nudge wordt ("cliënt zonder BSN") of een rolgebonden eis, bepalen we bij de rollenronde.
+2. **VERWIJZER en PRAKTIJK_INSTELLING zijn twee losse entiteiten** — een verwijzer kan zonder praktijk bestaan (bijv. gemeente-ambtenaar), een praktijk kan meerdere verwijzers hebben.
+3. **AGB-verplichting hangt aan verwijzertype**, niet hardcoded per type in de applicatie: waardelijst `verwijzertype` krijgt attribuut `agb_verplicht (ja/nee)`. Huisarts/medisch specialist → ja, gemeente → nee. Zowel verwijzer als praktijk/instelling kunnen een eigen AGB-code hebben.
+4. **Geen AGB-validatie tegen Vecozo nu** — vrije invoer, validatie tegen een echte AGB-tabel parkeren we tot de declaratie-ronde.
+5. **Aanmelding-status is flexibel** — geen eenrichtingsflow, een besloten aanmelding kan terug naar "in screening" bij heropening. Basisstatussen: `nieuw → in screening → besloten`. Uitkomst bij `besloten`: `intake` / `afgewezen` / `doorverwezen` / `wachtlijst`.
+6. **Wie de status mag zetten blijft open** — rollen/disciplines zijn nog niet gemodelleerd; komt terug in die ronde.
+7. **Verwijsbrief blijft een nudge, geen harde schema-eis.** Ontbrekende verwijzing wordt een protocolregel (Nudge Engine), met severity die kan verschillen per financieringtype/regelgeving (bijv. `blokkade` bij Zvw-huisartsroute, `signaal` bij Wmo/Jeugdwet). Een beschikking telt ook als verwijzing: waardelijst `verwijsdocument_type` (verwijsbrief, beschikking, ...) i.p.v. één vast veld.
+8. **Cliëntportaaltoegang als losse entiteit `CLIENTPORTAAL_ACCOUNT`**, 1-op-0..1 op CLIENT (niet elke cliënt heeft portaaltoegang; een persoon zonder cliëntrol kan sowieso geen portaalaccount hebben). Authenticatiedetails (e-mail, provider-koppeling, status uitgenodigd/actief/geblokkeerd) werken we pas uit in de auth/ADM-ronde — hier alleen de relatie vastgelegd zodat de entiteitenkaart klopt.
+9. **ZORGEPISODE is een eigen entiteit** tussen aanmelding en de klinische records. De AANMELDING is de binnenkomst-*gebeurtenis* (verwijzer, hulpvraag, besluit); de ZORGEPISODE is de *periode van zorg* die bij uitkomst "intake" start. Aan de episode hangen: intakes (regulier én intern), diagnoses, behandelplannen en de behandelwachttijd. Bij de aanmelding blijven: screening en aanmeldwachttijd. Een afgewezen aanmelding heeft nooit een episode. Sluit straks aan op het ZPM-zorgtraject (declaratie-ronde). Open detail: ontstaat de episode al bij uitkomst "wachtlijst", of pas bij "intake"?
+
+**Open idee, nog geen besluit:** mogelijk krijgt ook een verwijzer toegang tot de status van zijn verwijzingen (verwijzersportaal, analoog aan `CLIENTPORTAAL_ACCOUNT` maar dan op VERWIJZER). Nog niet uitgewerkt en niet in de entiteitenkaart opgenomen — apart onderwerp voor een volgende ronde als dit een echte behoefte blijkt.
+
+Aanmelding → screening → intake. Dit is de eerste rebuild-module én de TIP-proefflow. Latere rondes: diagnose & behandeltraject, agenda, rapportage & overdracht.
+
+### 5.2 Feitzinnen screening & intake (herzien na sessie 17 juli)
+
+1. *Voor de aanmelding van Jan de Vries is op 15 juli 2026 een screening gestart.*
+2. *Bij de screening is op 16 juli 2026 een activiteit van type "telefonisch contact" geregistreerd door verpleegkundige K. Jansen, met toelichting "huisarts gesproken over medicatiehistorie".*
+3. *Het screeningsbesluit voor de aanmelding luidt "geschikt", met geadviseerde afdeling Volwassenen, genomen op 17 juli 2026.*
+4. *Op basis van de aanmelding van Jan de Vries is op 20 juli 2026 een intake gestart op afdeling Volwassenen, met aanleiding "regulier".*
+5. *De intake heeft status "bezig".*
+6. *Contactmoment van type "intakegesprek" op 22 juli 2026 is gevoerd door psycholoog M. de Boer.*
+7. *De kindcheck voor de intake is op 22 juli 2026 uitgevoerd: thuiswonende kinderen: nee.*
+8. *De intake is op 30 juli 2026 afgerond met uitkomst "in zorg".*
+9. *Verslag X is op 22 juli 2026 geschreven door M. de Boer.* / *Verslag Y is gegenereerd door AI-model Z op basis van bronnen A en B, en bevestigd door M. de Boer.*
+
+**Bevindingen prototype (verkenning 17 juli 2026):**
+- Afdelingen: drie onderling inconsistente hardcoded lijsten — screening biedt er 6 (incl. FACT, Verslaving), intake accepteert er 3 (andere labels: "Jeugd" vs "Jeugd (< 18 jaar)"), behandeladvies heeft een vierde lijst plus 4 "zorgprogramma's" (Algemeen GGZ, FACT, Verslaving, Trauma). FACT is op de ene plek afdeling, op de andere zorgprogramma.
+- Screeningsactiviteiten zijn nu vrije tekst zonder typering; contactmomenten in de intake hebben wél een typed lijst (Intakegesprek, Aanvullend onderzoek, Telefonisch contact, Huisbezoek, Overig).
+- Screeningsbesluit: `geschikt`/`niet_geschikt` + afdeling als vrije string.
+- Kindcheck is geen enkele uitkomstwaarde maar drie ja/nee-vlaggen + tekst (thuiswonende kinderen?, zorgen over veiligheid?, actie ondernomen?).
+- Intake afronden loopt via de behandeladvies-tab: checkbox + verplichte vervolgkeuze `in_zorg`/`doorverwijzing`/`extra_diagnostiek`, zet status `afgerond` + einddatum. Statussen: alleen `bezig`/`afgerond`.
+
+**Besluiten (sessie 17 juli 2026, Colin):**
+1. **Intake hangt aan de ZORGEPISODE** (aanvankelijk aan de aanmelding gemodelleerd; herzien met besluit §5.1 #9), niet direct aan de cliënt. Eén episode kan **meerdere intakes** hebben: naast de reguliere intake bestaan er interne intakes binnen een lopende episode (bijv. overgang naar een andere afdeling). De intake krijgt een **aanleiding** uit een waardelijst (regulier / intern / crisis — lijst te bevestigen).
+2. **AFDELING en ZORGPROGRAMMA zijn twee aparte waardelijsten.** Afdeling = organisatorische eenheid (Volwassenen, Jeugd, Ouderen, Forensisch, ...), zorgprogramma = inhoudelijk aanbod (FACT, Verslaving, Trauma, ...). FACT is een programma, geen afdeling. Welke afdelingen echt bestaan is per instelling configureerbaar — waardelijst, geen hardcoded lijst.
+3. **Screeningsactiviteiten krijgen een type uit een waardelijst + vrije toelichting** (telefonisch contact, dossieronderzoek, vragenlijst, overig — startlijst te bevestigen). Maakt nudges mogelijk ("nog geen contact geweest bij deze screening").
+4. **Screening vóór intake is een nudge, geen harde eis** — zelfde patroon als de verwijsbrief. Interne intakes en crisis maken een harde volgorde-eis onhoudbaar; hooguit een protocolregel bij de eerste intake van een episode.
+
+**Open vragen voor een volgende ronde:**
+- Verhouding screeningsbesluit ↔ aanmelding-uitkomst: "geschikt" (screening) en uitkomst "intake" (aanmelding) overlappen — is het besluit hetzelfde feit als de uitkomst, of twee aparte feiten?
+- Intake-uitkomstwaarden bevestigen: `in_zorg` / `doorverwijzing` / `extra_diagnostiek` (nu uit het prototype overgenomen).
+- Kindcheck: gestructureerde velden zoals het prototype (drie ja/nee-vlaggen + tekst) aanhouden, of anders?
+- Wie mag een intake afronden → rollenronde.
+- Verslagen (feitzin 9, provenance) → rapportage-ronde; de provenance-spelregel (3.1 #2) ligt al vast.
+
+### 5.3 Feitzinnen wachtlijstbeheer (startlijst — te corrigeren)
+
+Wachtlijst bestaat niet in het prototype (geen tabel, geen scherm) — alleen als roadmap-idee (prioriteit `spoed`/`normaal`/`laag`, wachtdagen, Treeknorm-nudges). We ontwerpen dit vanaf nul. Aanmelding-uitkomst `wachtlijst` bestaat al (§5.1 besluit 5); de vraag is wat daarachter zit.
+
+1. *De aanmelding van Jan de Vries is op 18 juli 2026 op de wachtlijst geplaatst voor afdeling Volwassenen.*
+2. *De wachtlijstplaatsing heeft prioriteit "normaal".*
+3. *De wachttijd van de plaatsing telt vanaf de aanmelddatum 14 juli 2026.*
+4. *De wachtlijstplaatsing is op 20 augustus 2026 beëindigd met reden "intake gestart".*
+5. *(nudge) Bij overschrijding van de Treeknorm voor aanmeldwachttijd volgt een signaal.*
+
+**Besluit (sessie 17 juli 2026, Colin):** WACHTLIJSTPLAATSING wordt een **eigen entiteit** (afdeling, prioriteit, begin/eind, beëindigingsreden), inzetbaar op **twee momenten**: vóór de intake (aanmeldwachttijd) én na de intake wachtend op behandeling (behandelwachttijd) — sluit aan op de Treeknormen die beide kennen. Soort plaatsing als waardelijst (`aanmeld`/`behandel`). Met besluit §5.1 #9: de aanmeldwachttijd hangt aan de AANMELDING, de behandelwachttijd aan de ZORGEPISODE.
+
+**Nog open:**
+- Wachtlijst per afdeling, per zorgprogramma, of beide?
+- Welke beëindigingsredenen: intake gestart / behandeling gestart / doorverwezen / cliënt trekt zich terug / ...?
+
+### 5.4 Feitzinnen diagnose stellen (startlijst — te corrigeren)
+
+Bevinding prototype: de module heet DSM-5 maar registreert feitelijk **ICD-10 F-codes** (`code_system: 'ICD-10'`, regex `F##.#`); "DSM-5" is een optioneel vrijetekstveld. Werkdiagnose-vs-definitief (FHIR `verification_status`) zit in de tabel maar de UI gebruikt het niet. Velden nu: ernst `licht`/`matig`/`ernstig`, type hoofd-/nevendiagnose, status `active`/`remission`/`resolved`/`inactive`. Diagnose hangt in het prototype aan de intake.
+
+1. *Voor de zorgepisode van Jan de Vries is op 24 juli 2026 diagnose F32.1 "matige depressieve episode" geregistreerd door psycholoog M. de Boer, gesteld tijdens de intake van 22 juli.*
+2. *Diagnose F32.1 is de hoofddiagnose.*
+3. *Diagnose F32.1 heeft ernst "matig".*
+4. *Diagnose F32.1 is een werkdiagnose.* / *Diagnose F32.1 is op 30 juli 2026 definitief vastgesteld.*
+5. *Diagnose F32.1 heeft status "actief".*
+6. *Diagnose F32.1 is op 1 december 2026 in remissie verklaard.*
+
+**Besluiten (sessie 17 juli 2026, Colin):**
+1. **DSM-5-TR is de primaire classificatie, met ICD-10-mapping** voor declaratie/uitwisseling. Behandelaren registreren in DSM-termen (bronregistratie), de ICD-10-code wordt afgeleid via een mappingtabel — geen dubbele handmatige invoer. (Het prototype deed het omgekeerd: ICD-10 als registratie, DSM als vrije tekst.)
+2. **De diagnose hangt aan de ZORGEPISODE** (besluit §5.1 #9), niet aan de intake. De diagnose overleeft de intake en wordt tijdens de behandeling bijgesteld; de intake waarin hij gesteld is wordt als herkomst vastgelegd (optionele verwijzing), niet als eigenaar.
+
+**Nog open:**
+- Werkdiagnose vs. definitief: aparte status-as naast klinische status (actief/remissie/opgelost) — voorlopig zo gemodelleerd (verificatiestatus + klinische status), bevestigen.
+- "Max één hoofddiagnose" (spelregel §3.1 #7): per wat — per episode, per moment in de tijd?
+- Wie mag een diagnose (definitief) stellen → rollenronde (regiebehandelaar).
+
+### 5.5 Feitzinnen behandelplan opstellen (startlijst — te corrigeren)
+
+Bevinding prototype: module gestript (AI-generatie negeerde diagnose/ernst), maar het typemodel is bekend: behandelstructuur (duur, frequentie, vorm), SMART-doelen (1-6, met cliëntversie in B1-taal, leefgebied, prioriteit), interventies (1-5, gekoppeld aan doelen), sessieplanning, evaluatiemomenten, veiligheidsplan (bij ernstige diagnose), leefgebieden-scores (7 domeinen, 0-10). Statussen waren inconsistent per laag (TS: `concept/actief/in_evaluatie/afgerond/gearchiveerd`; DB: `draft/active/on-hold/revoked/completed`).
+
+1. *Voor de zorgepisode van Jan de Vries is op 1 augustus 2026 een behandelplan opgesteld door M. de Boer.*
+2. *Het behandelplan heeft status "concept".*
+3. *Het behandelplan is gebaseerd op de intake van 20 juli 2026 en adresseert diagnose F32.1.*
+4. *Het behandelplan bevat behandeldoel "weer drie nachten per week doorslapen" met prioriteit hoog en beoogde termijn 12 weken.*
+5. *Behandeldoel X heeft een cliëntversie in B1-taal.*
+6. *Aan behandeldoel X is interventie "CGT" gekoppeld.*
+7. *Het behandelplan kent een evaluatiemoment in week 6.*
+8. *Cliënt Jan de Vries heeft op 5 augustus 2026 ingestemd met het behandelplan.*
+9. *Behandelplanversie 2 vervangt versie 1 per 15 september 2026.*
+
+**Besluit (sessie 17 juli 2026, Colin):** deze ronde modelleert de **plan-kern**: doelen, interventies, evaluatiemomenten, status, versiebeheer en cliëntakkoord. Sessieplanning → agenda-ronde; leefgebieden en veiligheidsplan → aparte beslissing later.
+
+**Nog open:**
+- Statusmachine: welke statussen echt (prototype-lagen waren inconsistent), en is cliëntakkoord een status of een los feit (WGBO)?
+- Versiebeheer: nieuw record per versie (zoals `care_plans.version` deed) of muteren met audit?
+- ~~Waar hangt het plan aan~~ — besloten: aan de ZORGEPISODE (besluit §5.1 #9), consistent met de diagnose.
+- Is een behandelplan verplicht vóór start behandeling — harde eis of nudge (ZPM kent `behandelplan_check` als regeltrigger)?
+
+## 6. Vervolg
+
+| Stap | Wat | Wie |
+|---|---|---|
+| 1 | Feitzinnen instroom corrigeren en aanvullen | Colin |
+| 2 | Entiteitenkaart instroom (HTML-visualisatie) | Claude |
+| 3 | Statussen + eigenaarschap (ECD/TIP) per entiteit | samen |
+| 4 | Zelfde cyclus voor diagnose/traject, agenda, rapportage | samen |
+| 5 | Pas daarna: schema-baseline (migrations) + `lib/dat/` | Claude |
+
+## Bronnen
+
+- [FCO-IM (Wikipedia)](https://en.wikipedia.org/wiki/FCO-IM) · [CaseTalk — About FCO-IM](https://www.casetalk.com/articles/introduction) · [Zwart e.a., Fact Oriented Modeling with FCO-IM](https://www.goodreads.com/book/show/27818248-fact-oriented-modeling-with-fco-im)
+- [Nictiz — Zorginformatiebouwstenen (zibs)](https://www.nictiz.nl/wat-we-doen/activiteiten/zibs/) · [Registratie aan de bron — zibs](https://www.registratieaandebron.nl/zorginformatiebouwstenen)
+- [openEHR — Design Principles](https://specifications.openehr.org/releases/1.0.1/html/architecture/overview/Output/design_principles.html) · [Archetype relational mapping (PMC)](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4636072/)
+- [dbi services — Embedding versioning met pgvector / event-driven her-embedding](https://www.dbi-services.com/blog/rag-series-embedding-versioning-with-pgvector-why-event-driven-architecture-is-a-precondition-to-ai-data-workflows/) · [pgvector RAG op managed PostgreSQL (2026)](https://danubedata.ro/blog/pgvector-rag-managed-postgres-2026)
+- [Append-only audit trails — designgurus](https://www.designgurus.io/answers/detail/how-do-you-enforce-immutability-and-appendonly-audit-trails) · [EHR audit trail — compliance & best practices](https://www.accountablehq.com/post/ehr-audit-trail-explained-what-it-is-compliance-requirements-and-best-practices)

docs/datamodel/deelmodellen/model-aanmelding.md

@@ -0,0 +1,511 @@
+# Datamodelvoorstel — Aanmelding & instroombasis
+
+**Status:** herziening nodig — structureel deels achterhaald door `../besluiten/besluitenlog-datamodel-2026-07-18.md`  
+**Datum:** 18 juli 2026
+**Deelgebied:** PERSOON, CLIENT, VERWIJZER, PRAKTIJK_INSTELLING, AANMELDING, ZORGEPISODE, CLIENTPORTAAL_ACCOUNT + aanvullingen voor een volwassen instroommodel
+**Bronnen:** `datamodel-discovery.md`, onderzoek-proces, onderzoek-leveranciers, onderzoek-standaarden, onderzoek-rapportage (details in §8)
+
+> **Let op:** het besluitenlog splitst de huidige AANMELDING in AANMELDSIGNAAL en AANMELDINGSTRAJECT. De ZORGEPISODE ontstaat bij formele acceptatie en heeft een onafhankelijke levenscyclus. Gebruik de huidige entiteiten, cardinaliteiten en statusmachines daarom nog niet als basis voor SQL.
+
+**Conventies (gelden voor alle entiteiten, niet per entiteit herhaald):**
+- Elke entiteit heeft `id` (UUID, stabiel — spelregel 3.1 #5), `created_at`, `updated_at`, `deleted_at` (soft delete — spelregel 3.1 #4) en auditvelden conform spelregel 3.1 #3.
+- Elke waardelijst is een referentietabel (spelregel 3.1 #1) met per rij: `code`, `omschrijving`, optioneel `externe_code` + `codesysteem` (FHIR/NZa-koppelbaarheid), `geldig_van`, `geldig_tot`, `actief`. De geldigheidsperiode per waarde is een les uit de NZa-codelijsten bij Nedap (onderzoek-leveranciers §2.2, §7.1).
+- "Wie mag zetten" is overal **rollenronde** (discovery §5.1 besluit 6), tenzij anders vermeld.
+
+---
+
+## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.1)
+
+### Persoon, contactgegevens en adres
+
+1. *(gewijzigd t.o.v. §5.1 feitzin 1)* Persoon Jan de Vries heeft naamdelen: achternaam "Vries", voorvoegsel "de", voornamen "Jan Willem", initialen "J.W.", roepnaam "Jan". *(gestructureerde naam i.p.v. één naamveld — zib Patient)*
+2. Persoon Jan de Vries heeft geslacht "man" (uit waardelijst).
+3. Persoon Jan de Vries heeft genderidentiteit "man" (optioneel, uit waardelijst — GGZ-relevant, zib Patient v4.3).
+4. Persoon Jan de Vries heeft BSN 123456782. *(optioneel op PERSOON — discovery §5.1 besluit 1; versleuteld — spelregel 3.1 #6)*
+5. Persoon Jan de Vries is overleden op 3 maart 2071. *(optioneel expliciet feit — zib Patient)*
+6. Persoon Jan de Vries heeft een adres van type "woonadres": Dorpsstraat 1, 1234 AB Ons Dorp, geldig sinds 1 januari 2020.
+7. Persoon Jan de Vries heeft contactgegeven van type "telefoon", soort "mobiel privé", waarde "06-12345678", met voorkeursmarkering.
+8. Persoon Jan de Vries heeft contactgegeven van type "e-mail", waarde "jan@example.nl".
+
+### Contactpersonen en wettelijk vertegenwoordiger (relatie via PERSOON)
+
+9. Persoon Maria de Vries staat tot cliënt Jan de Vries in relatie "partner" en vervult daarbij de rol "eerste contactpersoon", sinds 14 juli 2026.
+10. Persoon K. Bos vervult voor cliënt Jan de Vries de rol "wettelijk vertegenwoordiger" met vertegenwoordigingsgrond "mentor", sinds 1 februari 2026.
+11. De relatie van Maria de Vries tot cliënt Jan de Vries is op 1 mei 2027 beëindigd.
+
+### Vaste huisarts
+
+12. Cliënt Jan de Vries heeft huisarts-situatie "huisarts bekend" *(alternatieven: "geen huisarts", "cliënt staat correspondentie met huisarts niet toe" — ZPM-verwijstype 04/05, onderzoek-proces §2.8)*.
+13. Cliënt Jan de Vries heeft als vaste huisarts P. Pietersen, verbonden aan Huisartsenpraktijk De Vries & Pietersen, sinds 14 juli 2026. *(vaste huisarts ≠ incidentele verwijzer; kan dezelfde persoon zijn)*
+
+### Verzekering en financiering per wettelijk kader
+
+14. Cliënt Jan de Vries is verzekerd bij zorgverzekeraar met UZOVI-code 3311 onder polisnummer 987654, geldig vanaf 1 januari 2026.
+15. De verzekering van Jan de Vries is op 14 juli 2026 geverifieerd via een COV-controle.
+16. Bij de aanmelding van 14 juli 2026 onder wettelijk kader "Jeugdwet" hoort gemeentelijke toewijzing 301-20260714-001 van gemeente Utrecht (gemeentecode 0344), met periode 1 augustus 2026 t/m 31 januari 2027. *(alleen bij kader Jeugdwet/Wmo — iJw/iWmo, onderzoek-standaarden §7)*
+
+### Verwijzing (verrijking van de aanmelding)
+
+17. *(verfijnt §5.1 feitzin 8)* Bij de aanmelding van 14 juli 2026 hoort een verwijzing, afgegeven op 1 juli 2026 door verwijzer P. Pietersen. *(verwijsdatum ≠ aanmelddatum; 275-dagentoets en per 2026 verplicht op de declaratie — onderzoek-proces §2.3/§2.10)*
+18. De verwijzing vermeldt echelon "gespecialiseerde ggz".
+19. De verwijzing vermeldt een vermoeden van een DSM-benoemde psychische stoornis: "depressieve klachten".
+20. De verwijzing betreft een heraanmelding: nee.
+21. De aanmelding van 14 juli 2026 heeft ZPM-verwijstype "01 — verwijzing aanwezig". *(afleidbaar, maar overschrijfbaar registreerbaar — onderzoek-standaarden §6.3)*
+22. De aanmelding van 14 juli 2026 volgt doorverwijsroute "doorverwijzing tussen ggz-aanbieders". *(optioneel; alleen bij één van de vijf erkende routes — onderzoek-proces §2.7)*
+23. Voor de aanmelding van 15 juli 2026 zonder verwijzing (crisis) is de huisarts op 20 juli 2026 geïnformeerd. *(60-dagentermijn — onderzoek-proces §2.6)*
+
+### Aanmelding (aanvullingen)
+
+24. De aanmelding van 14 juli 2026 is ontvangen via aanmeldkanaal "ZorgDomein".
+25. *(verfijnt §5.1 besluit 5)* De aanmelding van 14 juli 2026 heeft uitkomst "intake", vastgesteld op 17 juli 2026. *(uitkomst + uitkomstdatum als aparte feiten naast de status)*
+
+### Toestemmingen (WGBO/AVG)
+
+26. Cliënt Jan de Vries heeft op 14 juli 2026 toestemming van type "correspondentie met huisarts/verwijzer" verleend, vastgelegd door K. Jansen, wijze "mondeling".
+27. Cliënt Jan de Vries heeft op 1 september 2026 de toestemming van type "vermelding DSM-hoofdgroep op factuur" geweigerd.
+28. Cliënt Jan de Vries heeft de toestemming van type "correspondentie met huisarts/verwijzer" op 1 december 2026 ingetrokken.
+
+### Zorgepisode
+
+29. Voor cliënt Jan de Vries is op 17 juli 2026 een zorgepisode gestart, voortkomend uit de aanmelding van 14 juli 2026. *(ontstaat bij uitkomst "intake" — zie §5 en besluitpunt 1)*
+30. De zorgepisode van Jan de Vries is op 15 maart 2027 afgesloten met reden "behandeling afgerond".
+
+---
+
+## 2. Entiteiten
+
+### 2.1 PERSOON
+
+**Doel:** draagt de identiteit van een natuurlijk persoon, onafhankelijk van rollen (cliënt, contactpersoon, vertegenwoordiger, later medewerker). Discovery §5.1 besluit 1.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| achternaam | tekst | ja |
+| voorvoegsels | tekst | nee |
+| voornamen | tekst | nee |
+| initialen | tekst | nee |
+| roepnaam | tekst | nee |
+| geboortedatum | datum | ja |
+| geslacht | waardelijst `geslacht` | ja |
+| genderidentiteit | waardelijst `genderidentiteit` | nee |
+| bsn | tekst, versleuteld (pgcrypto), inzage gelogd | nee *(rolgebonden eis via nudge — §5.1 besluit 1)* |
+| overleden | ja/nee | ja (default nee) |
+| overlijdensdatum | datum | nee |
+
+**Uniciteit:** BSN uniek indien gevuld (op hash-index over de versleutelde waarde). Geen andere harde uniciteitsregel — naam+geboortedatum-duplicaten worden een nudge ("mogelijke dubbele persoon"), geen constraint.
+
+### 2.2 ADRES
+
+**Doel:** 0..n adressen per persoon (zib Patient: meerdere adressen mogelijk).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| persoon_id | ref PERSOON | ja |
+| adrestype | waardelijst `adrestype` | ja |
+| straat | tekst | ja |
+| huisnummer | tekst | ja |
+| huisnummertoevoeging | tekst | nee |
+| postcode | tekst | ja |
+| plaats | tekst | ja |
+| land | tekst (default NL) | ja |
+| geldig_van | datum | nee |
+| geldig_tot | datum | nee |
+
+**Uniciteit:** max één actueel (geldig_tot leeg) adres per persoon per adrestype.
+
+### 2.3 CONTACTGEGEVEN
+
+**Doel:** telefoonnummers en e-mailadressen per persoon.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| persoon_id | ref PERSOON | ja |
+| contacttype | waardelijst `contactgegeven_type` (telefoon/e-mail) | ja |
+| soort | waardelijst `contactgegeven_soort` (mobiel privé/vast privé/werk/…) | nee |
+| waarde | tekst | ja |
+| voorkeur | ja/nee | ja (default nee) |
+
+**Uniciteit:** max één voorkeursgegeven per persoon per contacttype.
+
+### 2.4 CLIENT
+
+**Doel:** rol op PERSOON: dit persoon is cliënt bij de instelling. Discovery §5.0 besluit 2 + §5.1 besluit 1.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| persoon_id | ref PERSOON | ja |
+| clientnummer | geheel getal (reeks per instelling) | ja |
+| client_sinds | datum | ja |
+| huisarts_situatie | waardelijst `huisarts_situatie` | ja (default "onbekend") |
+
+**Uniciteit:** max één CLIENT-rol per PERSOON; clientnummer uniek. Nudge (geen constraint): "cliënt zonder BSN" (Wabvpz — §5.1 besluit 1).
+
+### 2.5 CLIENTRELATIE
+
+**Doel:** contactpersonen en (wettelijk) vertegenwoordigers als relatie tussen een CLIENT en een PERSOON — twee gescheiden assen *relatie* en *rol*, conform zib Contactpersoon (onderzoek-standaarden §2.2). Dekt ook gezaghebbende ouders (jeugd) en mentoren/curatoren (Wvggz/WGBO — onderzoek-proces §8).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| client_id | ref CLIENT | ja |
+| persoon_id | ref PERSOON | ja |
+| relatie | waardelijst `relatie` (partner, ouder, kind, …) | nee |
+| rol | waardelijst `relatierol` (eerste contactpersoon, wettelijk vertegenwoordiger, …) | ja |
+| vertegenwoordigingsgrond | waardelijst `vertegenwoordigingsgrond` | nee (alleen bij rol wettelijk vertegenwoordiger) |
+| geldig_van | datum | ja |
+| geldig_tot | datum | nee |
+| toelichting | tekst | nee |
+
+**Uniciteit:** max één actuele rij per (client, persoon, rol). Meerdere rollen per persoon mogelijk (moeder = ouder + gezaghebbend + eerste contactpersoon = drie assen, twee rijen: rol "gezaghebbende ouder" en rol "eerste contactpersoon", beide relatie "ouder"). Zelfrelatie (persoon = cliënt-persoon) niet toegestaan. Leeftijdsafhankelijke rechten (12/16-grenzen WGBO) zijn autorisatie, geen schema — rollenronde.
+
+### 2.6 VERWIJZER
+
+**Doel:** persoon of functionaris die verwijst. Eigen begrip (discovery §5.0 besluit 3), los van PRAKTIJK_INSTELLING (§5.1 besluit 2). Wordt óók gebruikt als referent voor de vaste huisarts (zie CLIENT_HUISARTS en besluitpunt 3).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| naam | tekst | ja |
+| verwijzertype | waardelijst `verwijzertype` | ja |
+| agb_code | tekst (vrije invoer — §5.1 besluit 4) | nee *(nudge indien `agb_verplicht` op het type — §5.1 besluit 3)* |
+| praktijk_instelling_id | ref PRAKTIJK_INSTELLING | nee |
+| telefoon | tekst | nee |
+| e-mail | tekst | nee |
+
+**Uniciteit:** agb_code uniek indien gevuld. Verwijzer kan zonder praktijk bestaan (gemeente-ambtenaar).
+
+### 2.7 PRAKTIJK_INSTELLING
+
+**Doel:** organisatie waaraan verwijzers/huisartsen verbonden zijn. Discovery §5.1 besluit 2.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| naam | tekst | ja |
+| soort | waardelijst `praktijk_soort` (huisartsenpraktijk, ziekenhuis, ggz-instelling, gemeente, arbodienst, overig) | nee |
+| agb_code | tekst | nee |
+| adres/plaats | tekst | nee |
+| telefoon | tekst | nee |
+
+**Uniciteit:** agb_code uniek indien gevuld.
+
+### 2.8 CLIENT_HUISARTS
+
+**Doel:** de **vaste huisarts** van de cliënt, los van de incidentele verwijzer. Nodig omdat de huisarts ook informatie-ontvanger is wanneer hij níet de verwijzer is (intakebrief, beloopsbrief, 60-dagenmelding — onderzoek-proces §2.9, §10.2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| client_id | ref CLIENT | ja |
+| verwijzer_id | ref VERWIJZER (type huisarts) | nee |
+| praktijk_instelling_id | ref PRAKTIJK_INSTELLING | nee |
+| geldig_van | datum | ja |
+| geldig_tot | datum | nee |
+
+**Uniciteit:** max één actuele registratie per cliënt. Minstens één van verwijzer_id/praktijk_instelling_id gevuld (soms is alleen de praktijk bekend). De situatie "geen huisarts"/"geen toestemming" staat op CLIENT.huisarts_situatie, niet hier.
+
+### 2.9 VERZEKERING
+
+**Doel:** Zvw-verzekeringsgegevens van de cliënt (financieringskant bij kader Zvw). Historisch, want verzekeraars wisselen per jaar.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| client_id | ref CLIENT | ja |
+| uzovi_code | tekst | ja |
+| verzekeraar_naam | tekst | nee |
+| polisnummer | tekst | nee |
+| geldig_van | datum | ja |
+| geldig_tot | datum | nee |
+| cov_gecontroleerd_op | datum | nee |
+
+**Uniciteit:** max één actuele verzekering per cliënt. Nudge: "Zvw-aanmelding zonder actuele COV-controle". Wlz-indicatie en forensische titel: declaratie-ronde (besluitpunt 7).
+
+### 2.10 AANMELDING
+
+**Doel:** de binnenkomst-*gebeurtenis* (discovery §5.1 besluit 9). Draagt aanmelddatum (wettelijk controleerbaar gegeven — onderzoek-proces §2.3), kanaal, kader, hulpvraag, status en uitkomst. Screening en aanmeldwachttijd hangen hieraan (§5.2, §5.3).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| client_id | ref CLIENT | ja |
+| aanmelddatum | datum | ja |
+| aanmeldkanaal | waardelijst `aanmeldkanaal` | nee |
+| wettelijk_kader | waardelijst `wettelijk_kader` | ja (§5.0 besluit 4) |
+| hulpvraag | tekst | ja |
+| status | waardelijst `aanmelding_status` | ja (default "nieuw") |
+| uitkomst | waardelijst `aanmelding_uitkomst` | nee (verplicht bij status "besloten") |
+| uitkomst_datum | datum | nee (verplicht bij uitkomst) |
+| zpm_verwijstype | waardelijst `zpm_verwijstype` | nee *(afleidbaar uit verwijzing/toestemmingen, overschrijfbaar; verplicht richting declaratie bij Zvw)* |
+| doorverwijsroute | waardelijst `doorverwijsroute` | nee |
+| huisarts_geinformeerd_op | datum | nee *(instroom zonder verwijzing; nudge harde termijn 60 dagen)* |
+| toelichting | tekst | nee |
+
+**Uniciteit:** geen harde beperking op parallelle aanmeldingen; "max één actieve aanmelding per cliënt" is een aan/uit-zetbare bedrijfsregel (§5.0 besluit 5) — in TIP/Nudge, niet in schema.
+
+### 2.11 VERWIJZING *(nieuw — besluitpunt 2)*
+
+**Doel:** de verwijzing als eigen registratie-object bij de aanmelding. Verfijnt §5.1 feitzin 8: "ontvangen via verwijzer X" blijft waar, maar de verwijzing draagt eigen wettelijk relevante feiten die niet op de aanmelding of de verwijzer thuishoren: **verwijsdatum** (275-dagentoets; per 1-1-2026 verplicht op elke declaratie), echelon, DSM-vermoeden, heraanmelding-vlag (onderzoek-proces §2, onderzoek-standaarden §8). Een zelfaanmelding heeft géén verwijzing.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| aanmelding_id | ref AANMELDING | ja |
+| verwijzer_id | ref VERWIJZER | ja |
+| verwijsdatum | datum | ja |
+| echelon | waardelijst `echelon` | nee *(ontbreekt op verwijzing → aanbieder kiest zelf, onderzoek-proces §2.5)* |
+| vermoeden_dsm_stoornis | tekst | nee |
+| heraanmelding | ja/nee | ja (default nee) |
+| toelichting | tekst | nee |
+
+**Uniciteit:** max één verwijzing per aanmelding. Geldigheidstoets (aanmelddatum − verwijsdatum ≤ 275 dagen) is een nudge, geen constraint (onvolledige/late verwijzing mag — inspanningsverplichting, onderzoek-proces §2.5).
+
+### 2.12 VERWIJSDOCUMENT
+
+**Doel:** ontvangen documenten bij de aanmelding, getypeerd (verwijsbrief, beschikking, …) — discovery §5.1 besluit 7.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| aanmelding_id | ref AANMELDING | ja |
+| documenttype | waardelijst `verwijsdocument_type` | ja |
+| document_referentie | ref documentopslag (UUID) | ja |
+| ontvangen_op | datum | ja |
+
+**Uniciteit:** geen (meerdere documenten per aanmelding toegestaan).
+
+### 2.13 TOEWIJZING *(nieuw — gemeentelijk kader)*
+
+**Doel:** bij kader Jeugdwet/Wmo is de "verwijzing" feitelijk een gemeentelijke beschikking/toewijzing met eigen sleutelgegevens (iWmo/iJw 301-bericht) — meer structuur dan een document alleen (onderzoek-standaarden §7). Minimale variant nu; productcodes/volume volgen in de declaratie-ronde (besluitpunt 6).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| aanmelding_id | ref AANMELDING | ja |
+| gemeentecode | tekst (CBS-code) | ja |
+| gemeente_naam | tekst | nee |
+| toewijzingsnummer | tekst | ja |
+| ingangsdatum | datum | ja |
+| einddatum | datum | nee |
+
+**Uniciteit:** toewijzingsnummer uniek per gemeentecode.
+
+### 2.14 TOESTEMMING *(nieuw — besluitpunt 4)*
+
+**Doel:** één generieke toestemmingsentiteit (WGBO/AVG). Toestemmingen duiken in de instroom al op drie plekken op: correspondentie huisarts/verwijzer (verwijstype 04!), DSM-hoofdgroep op factuur (opt-in sinds 2025), privacyverklaring zorgvraagtypering (onderzoek-standaarden §9.5; onderzoek-proces §2.8/§7). Cliëntakkoord op het behandelplan blijft een **apart feit bij het behandelplan** (deelgebied §5.5), geen TOESTEMMING-rij.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| client_id | ref CLIENT | ja |
+| toestemmingstype | waardelijst `toestemming_type` | ja |
+| status | waardelijst `toestemming_status` | ja |
+| datum | datum | ja |
+| wijze | waardelijst `toestemming_wijze` | nee |
+| vastgelegd_door | ref medewerker (rollenronde) | ja |
+| geldig_tot | datum | nee |
+| ingetrokken_op | datum | nee |
+| scope_aanmelding_id / scope_episode_id | ref (optioneel) | nee *(default: cliëntbreed)* |
+| toelichting | tekst | nee |
+
+**Uniciteit:** max één actuele (niet-ingetrokken) rij per (client, toestemmingstype, scope). Intrekken = nieuw statusfeit, historie blijft (append-only audit).
+
+### 2.15 ZORGEPISODE
+
+**Doel:** de periode van zorg (discovery §5.1 besluit 9). Draagt intakes, diagnoses, behandelplannen, behandelwachttijd, zorgvraagtypering (latere ronde). Klinisch object, **niet** het ZPM-zorgtraject — verwant, gekoppeld, geen 1-op-1 (onderzoek-standaarden §6.1; onderzoek-leveranciers §2.3).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| client_id | ref CLIENT | ja |
+| aanmelding_id | ref AANMELDING (herkomst) | ja |
+| startdatum | datum | ja |
+| status | waardelijst `episode_status` | ja (default "lopend") |
+| echelon_actueel | waardelijst `echelon` | nee *(kan wijzigen door op-/afschalen — besluitpunt 5)* |
+| einddatum | datum | nee |
+| einde_reden | waardelijst `episode_einde_reden` | nee (verplicht bij afsluiten; startlijst te bevestigen, sluit t.z.t. aan op iStd-redenen) |
+| zorgtrajectnummer | tekst | nee *(gereserveerd; invulling declaratie-ronde)* |
+
+**Uniciteit:** max één episode per aanmelding (een aanmelding met uitkomst "intake" leidt tot precies één episode; afgewezen/doorverwezen aanmeldingen hebben er nooit één — §5.1 besluit 9). Meerdere episodes per cliënt door de tijd. **Ontstaansmoment: bij uitkomst "intake", niet bij "wachtlijst"** — zie §5 en besluitpunt 1.
+
+### 2.16 CLIENTPORTAAL_ACCOUNT
+
+**Doel:** relatie-placeholder (discovery §5.1 besluit 8). Wettelijke basis: elektronische inzage Wabvpz (onderzoek-proces §8).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| client_id | ref CLIENT | ja |
+
+**Uniciteit:** max één account per CLIENT (1-op-0..1). Authenticatiedetails en statussen: auth/ADM-ronde. Portaaltoegang voor vertegenwoordigers (ouders, 12–16-regels) raakt CLIENTRELATIE — ook auth-ronde.
+
+---
+
+## 3. Relaties met cardinaliteit
+
+| Van | Naar | Cardinaliteit | Toelichting |
+|---|---|---|---|
+| PERSOON | ADRES | 1 — 0..n | max 1 actueel per adrestype |
+| PERSOON | CONTACTGEGEVEN | 1 — 0..n | |
+| PERSOON | CLIENT | 1 — 0..1 | rol; één cliëntrol per persoon |
+| CLIENT | CLIENTRELATIE | 1 — 0..n | contactpersonen/vertegenwoordigers |
+| PERSOON | CLIENTRELATIE | 1 — 0..n | de relatie-persoon |
+| VERWIJZER | PRAKTIJK_INSTELLING | 0..n — 0..1 | verwijzer kan zonder praktijk |
+| CLIENT | CLIENT_HUISARTS | 1 — 0..n | max 1 actueel |
+| CLIENT_HUISARTS | VERWIJZER / PRAKTIJK_INSTELLING | — 0..1 / 0..1 | minstens één gevuld |
+| CLIENT | VERZEKERING | 1 — 0..n | max 1 actueel |
+| CLIENT | AANMELDING | 1 — 0..n | episodisch (§5.0 besluit 2) |
+| AANMELDING | VERWIJZING | 1 — 0..1 | zelfaanmelding: geen |
+| VERWIJZING | VERWIJZER | 0..n — 1 | |
+| AANMELDING | VERWIJSDOCUMENT | 1 — 0..n | |
+| AANMELDING | TOEWIJZING | 1 — 0..n | alleen kader Jeugdwet/Wmo |
+| AANMELDING | ZORGEPISODE | 1 — 0..1 | alleen bij uitkomst "intake" |
+| CLIENT | ZORGEPISODE | 1 — 0..n | |
+| CLIENT | TOESTEMMING | 1 — 0..n | |
+| CLIENT | CLIENTPORTAAL_ACCOUNT | 1 — 0..1 | |
+
+**Naar andere deelgebieden:**
+
+| Van | Naar (deelgebied) | Cardinaliteit |
+|---|---|---|
+| AANMELDING | SCREENING (§5.2) | 1 — 0..1 |
+| AANMELDING | WACHTLIJSTPLAATSING soort "aanmeld" (§5.3) | 1 — 0..n |
+| ZORGEPISODE | INTAKE (§5.2) | 1 — 0..n (regulier + intern) |
+| ZORGEPISODE | WACHTLIJSTPLAATSING soort "behandel" (§5.3) | 1 — 0..n |
+| ZORGEPISODE | DIAGNOSE (§5.4) | 1 — 0..n |
+| ZORGEPISODE | BEHANDELPLAN (§5.5) | 1 — 0..n (versies) |
+| ZORGEPISODE | ZORGVRAAGTYPERING (latere ronde) | 1 — 0..n |
+| ZORGEPISODE | regiebehandelaar-toewijzing (rollenronde) | 1 — 0..n |
+| TOESTEMMING | correspondentie-verplichtingen (latere ronde: intakebrief, beloopsbrief) | grondslag per verstrekking |
+
+---
+
+## 4. Waardelijsten
+
+Alle lijsten volgen het conventie-patroon (code, omschrijving, externe code, geldigheid). Startwaarden:
+
+1. **geslacht** — man, vrouw, anders, onbekend *(externe code: HL7 AdministrativeGender)*
+2. **genderidentiteit** — man, vrouw, non-binair, anders, zegt_het_niet *(zib Patient v4.3)*
+3. **adrestype** — woonadres, postadres, tijdelijk_verblijf
+4. **contactgegeven_type** — telefoon, email
+5. **contactgegeven_soort** — mobiel_prive, vast_prive, werk, overig
+6. **relatie** — partner, ouder, kind, broer_zus, familielid_overig, vriend_kennis, professional, overig
+7. **relatierol** — eerste_contactpersoon, wettelijk_vertegenwoordiger, gezaghebbende_ouder, mantelzorger, naaste *(twee assen relatie × rol — zib Contactpersoon)*
+8. **vertegenwoordigingsgrond** — curator, mentor, schriftelijk_gemachtigde, ouder_voogd, partner_familie *(WGBO-volgorde, onderzoek-proces §8)*
+9. **huisarts_situatie** — bekend, geen_huisarts, geen_toestemming_correspondentie, onbekend *(voedt ZPM-verwijstype 04/05)*
+10. **verwijzertype** — met attribuut `agb_verplicht` (ja/nee), §5.1 besluit 3. Startwaarden (discovery §5.0 besluit 3 + Verwijsafspraken GGZ, onderzoek-proces §2.2):
+
+| code | agb_verplicht |
+|---|---|
+| huisarts | ja |
+| medisch_specialist | ja |
+| straatdokter | ja |
+| bedrijfsarts | ja |
+| regiebehandelaar | ja |
+| ggz_instelling | ja |
+| gemeente | nee |
+| zelfaanmelding | nee |
+| crisis | nee |
+
+11. **praktijk_soort** — huisartsenpraktijk, ziekenhuis, ggz_instelling, gemeente, arbodienst, overig
+12. **wettelijk_kader** — met attribuut `verwijsnudge_severity` (§5.1 besluit 7): zvw (blokkade), jeugdwet (signaal), wmo (signaal), wlz (waarschuwing), forensisch (waarschuwing) *(severity-startwaarden te bevestigen in de nudge-ronde; NB bij Zvw zonder spoed/Wvggz is ontbrekende verwijzing feitelijk declaratie-blokkerend — onderzoek-proces §10.3)*
+13. **aanmeldkanaal** — zorgdomein, brief_post, e_mail, telefonisch, clientportaal, crisis, intern, overig
+14. **aanmelding_status** — nieuw, in_screening, besloten *(§5.1 besluit 5)*
+15. **aanmelding_uitkomst** — intake, afgewezen, doorverwezen, wachtlijst *(§5.1 besluit 5)*
+16. **verwijsdocument_type** — verwijsbrief, beschikking, wlz_indicatiebesluit, huisartsmelding_60dagen, medische_verklaring_wvggz, overig *(§5.1 besluit 7, uitgebreid)*
+17. **echelon** — gb_ggz, g_ggz, onbekend
+18. **zpm_verwijstype** — 01 t/m 07 conform ZPM-veldafspraken (externe code = Vektis/ZPM-code; onderzoek-standaarden §6.3): 01 verwijzing_aanwezig, 02 doorverwijzing_regiebehandelaar, 03 geen_verwijzing_verlate_correspondentie, 04 geen_verwijzing_correspondentie_niet_toegestaan, 05 geen_verwijzing_niet_declarabel, 06 geen_verwijzing_andere_grond_fz, 07 verwijzing_zonder_agb
+19. **doorverwijsroute** — justitieel_traject, einde_wlz_indicatie, overgang_jeugdwet, vervolg_acute_ggz, ggz_naar_ggz *(de vijf erkende routes; moet uit het dossier blijken — onderzoek-proces §2.7)*
+20. **toestemming_type** — met attribuut `grondslag` (tekst): correspondentie_huisarts_verwijzer (WGBO/verwijsafspraken), dsm_hoofdgroep_op_factuur (Stcrt. 2025-11955, opt-in), privacyverklaring_zorgvraagtypering (NZa), gegevensdeling_derden (AVG), inzage_naasten (WGBO)
+21. **toestemming_status** — verleend, geweigerd, ingetrokken
+22. **toestemming_wijze** — mondeling, schriftelijk, portaal
+23. **episode_status** — lopend, afgesloten
+24. **episode_einde_reden** — behandeling_afgerond, doorverwezen, client_beeindigt, geen_contact, overleden, overig *(startlijst; mapping op iStandaarden-redenen in de declaratie-ronde)*
+
+---
+
+## 5. Statusmachine
+
+### AANMELDING
+
+Statussen: `nieuw` → `in_screening` → `besloten`. Flexibel, geen eenrichtingsflow (§5.1 besluit 5).
+
+| Van | Naar | Voorwaarde |
+|---|---|---|
+| nieuw | in_screening | — |
+| nieuw | besloten | direct besluit toegestaan (bijv. evidente doorverwijzing) |
+| in_screening | besloten | uitkomst + uitkomst_datum verplicht |
+| besloten | in_screening | heropening; uitkomst en uitkomst_datum worden gearchiveerd in de audit, velden leeg |
+
+Regels in het model (spelregel 3.1 #7/#9): check-constraint "status = besloten ⇒ uitkomst en uitkomst_datum gevuld"; overgangen in een referentietabel `statusovergang` (entiteit, van, naar), niet in schermcode. Bij uitkomst `intake`: ZORGEPISODE wordt aangemaakt (zie hieronder). Bij uitkomst `wachtlijst`: WACHTLIJSTPLAATSING soort "aanmeld" aan de AANMELDING — **geen episode**.
+
+**Wie mag zetten: rollenronde** (§5.1 besluit 6). Kandidaat-inperking om daar te toetsen: `besloten` alleen door een rol met indicatiebevoegdheid (LKS: indicerende rol regiebehandelaar).
+
+### ZORGEPISODE
+
+Statussen: `lopend` → `afgesloten`.
+
+| Van | Naar | Voorwaarde |
+|---|---|---|
+| lopend | afgesloten | einddatum + einde_reden verplicht |
+| afgesloten | lopend | heropening bij administratieve fout; terugval krijgt een **nieuwe episode** (besluitpunt 8) |
+
+**Ontstaansregel (beantwoording open detail §5.1 besluit 9):** de episode ontstaat op het moment dat de aanmelding uitkomst **"intake"** krijgt; startdatum = uitkomst_datum. Bij uitkomst "wachtlijst" ontstaat géén episode. Onderbouwing: de NZa-behandelwachttijd loopt vanaf de intake en de verantwoordelijkheidsoverdracht van verwijzer naar aanbieder ligt ná de intake bij de regiebehandelaar (LKS 4.0; onderzoek-proces §1, §4.2, §10.3 — "episode pas bij intake, aanmeldwachttijd op de aanmelding"). De aanmeldwachtlijst hangt aan de AANMELDING (§5.3-besluit), dus er gaat niets verloren. Komt de cliënt van de aanmeldwachtlijst alsnog naar intake, dan wordt de uitkomst bijgewerkt naar "intake" (heropening → besloten) en ontstaat de episode alsnog. **Wie mag zetten: rollenronde.**
+
+### Overige entiteiten
+
+PERSOON, CLIENT, VERWIJZER, PRAKTIJK_INSTELLING, VERWIJZING, TOEWIJZING, CLIENT_HUISARTS, VERZEKERING: geen statusmachine — levenscyclus via geldigheidsperioden en soft delete. TOESTEMMING: `verleend`/`geweigerd` → `ingetrokken` (eenrichting; nieuwe toestemming = nieuwe rij). CLIENTPORTAAL_ACCOUNT: statusmachine in de auth/ADM-ronde.
+
+---
+
+## 6. ECD/TIP-eigenaarschap en events richting TIP
+
+**Eigenaarschap:** alle entiteiten in dit deelgebied zijn **leidend in het ECD** (klinische/administratieve feiten — discovery §3.3). TIP houdt de proces-state: screeningstaken, termijnbewaking, wachtlijst-nudges, "max één actieve aanmelding"-bedrijfsregel.
+
+**Events naar TIP** (mutatie-events, zelfde mechanisme als her-embedding — §3.3 koppelafspraak; payload bevat UUID + content-hash, **nooit BSN** — spelregel 3.1 #6):
+
+| Event | Trigger | Waarvoor TIP het nodig heeft |
+|---|---|---|
+| `client_geregistreerd` | nieuwe CLIENT | workspace/dossiercontext aanmaken |
+| `aanmelding_geregistreerd` | nieuwe AANMELDING | screeningstaak starten; Treeknorm-klok aanmeldwachttijd (4 wkn); 275-dagentoets als verwijzing volgt |
+| `aanmelding_status_gewijzigd` | statusovergang | procesbewaking, heropening detecteren |
+| `aanmelding_besloten` | status besloten (incl. uitkomst) | vervolgacties: intake plannen / wachtlijst / terugverwijsbrief |
+| `verwijzing_geregistreerd` | nieuwe/gewijzigde VERWIJZING | 275-dagen-geldigheidsnudge; "verwijzing onvolledig"-inspanningsnudge |
+| `verwijzing_ontbreekt` | aanmelding zonder VERWIJZING onder Zvw | nudge met severity per wettelijk kader (§5.1 besluit 7); 60-dagen-huisartsmelding-termijn |
+| `toewijzing_geregistreerd` | nieuwe TOEWIJZING | iWmo/iJw-startberichten (305) t.z.t. |
+| `zorgepisode_gestart` | nieuwe ZORGEPISODE | Treeknorm-klok behandelwachttijd (10 wkn); regiebehandelaar-toewijzing agenderen |
+| `zorgepisode_afgesloten` | status afgesloten | afrondingsbrief-taak; terugval-venster 1 jaar (ZPM) bewaken |
+| `toestemming_gewijzigd` | TOESTEMMING-mutatie | correspondentie-taken blokkeren/vrijgeven (intakebrief vereist toestemming) |
+| `clientrelatie_gewijzigd` | CLIENTRELATIE-mutatie | vertegenwoordiger-afhankelijke rechten/portaal |
+| `huisarts_gewijzigd` | CLIENT_HUISARTS / huisarts_situatie | correspondentie-adressering; verwijstype-afleiding |
+
+TIP-snapshots van deze data zijn doelgebonden auditkopieën met herkomst (afstemming Joshua, discovery §3.3) — het ECD blijft bron.
+
+---
+
+## 7. Open besluitpunten voor Colin
+
+1. **Ontstaansmoment ZORGEPISODE — ter bekrachtiging.** Voorstel: episode ontstaat bij uitkomst "intake", niet bij "wachtlijst" (onderbouwing §5). **Advies: bekrachtigen** — alle bronnen (LKS-verantwoordelijkheidsoverdracht, NZa-wachttijddefinities) wijzen dezelfde kant op, en de aanmeldwachtlijst hangt toch al aan de AANMELDING.
+2. **VERWIJZING als eigen entiteit** tussen AANMELDING en VERWIJZER (verwijsdatum, echelon, DSM-vermoeden, heraanmelding). **Advies: ja** — de verwijsdatum is per 2026 verplicht op elke declaratie en de 275-dagentoets vereist verwijsdatum ≠ aanmelddatum; dat hoort niet als los veld op de aanmelding (zelfaanmelding heeft er geen) en niet op de verwijzer (die verwijst vaker).
+3. **Vaste huisarts via hergebruik van VERWIJZER/PRAKTIJK_INSTELLING** (CLIENT_HUISARTS verwijst ernaar) of een aparte generalisatie EXTERNE_ZORGVERLENER. **Advies: hergebruik nu** — een huisarts is per definitie een potentiële verwijzer; generaliseren pas als er meer externe rollen bijkomen (ketenpartners, apotheek). Semantische scheefheid ("verwijzer die nooit verwees") accepteren als bekende schuld.
+4. **TOESTEMMING nu al als generieke entiteit opnemen** (i.p.v. uitstellen naar een latere ronde zoals onderzoek-standaarden §9.5 suggereert). **Advies: nu opnemen met kleine startwaardelijst** — verwijstype 04 en de intakebrief maken toestemming al in de instroomflow nodig; uitstellen betekent losse vlaggen die later gemigreerd moeten worden.
+5. **Echelon op twee plekken:** bron-echelon op VERWIJZING én actueel echelon op ZORGEPISODE (op-/afschalen binnen één aanbieder is geen doorverwijzing). **Advies: beide, episode-veld optioneel** — nodig voor wachttijd-uitsplitsing en factuurinhoud (g-ggz vs gb-ggz).
+6. **TOEWIJZING minimaal nu** (gemeente, nummer, periode) en productcategorie/-code/volume in de declaratie-ronde. **Advies: akkoord met minimale variant** — het toewijzingsnummer is de sleutel die alle latere iWmo/iJw-berichten nodig hebben; de rest is declaratie-detail.
+7. **Financieringsdetail Wlz/forensisch** (indicatiebesluit, strafrechtelijke titel) doorschuiven naar de declaratie-ronde; nu alleen VERZEKERING (Zvw) en TOEWIJZING (gemeentelijk). **Advies: doorschuiven** — het wettelijk kader zelf staat al op de aanmelding; de bronnen geven voor Wlz/fz nog te weinig structuurzekerheid.
+8. **Terugval binnen 1 jaar:** nieuwe ZORGEPISODE met hergebruik van het ZPM-zorgtrajectnummer, of heropening van de oude episode? **Advies: nieuwe episode** — klinisch is het een nieuwe zorgperiode; het trajectnummer-hergebruik (NZa-regel) is een declaratie-koppeling, geen reden om episodes samen te smelten. Definitief te maken in de declaratie-ronde (episode ↔ zorgtraject niet 1-op-1).
+9. **Huisarts-informeren als attribuut** (`huisarts_geinformeerd_op` op AANMELDING) of als onderdeel van een toekomstige CORRESPONDENTIE-entiteit (intakebrief, beloopsbrief, afrondingsbrief). **Advies: attribuut nu, CORRESPONDENTIE-entiteit in de rapportage-ronde** — de 60-dagentermijn is een hard wettelijk feit dat nu al een nudge nodig heeft; de brievenstroom is een groter onderwerp dat een eigen ronde verdient (onderzoek-proces §10.3 verrijking 9).
+10. **Startwaarden `verwijsnudge_severity` per wettelijk kader** (waardelijst 12): bij Zvw is ontbrekende verwijzing zonder spoed/Wvggz-grond feitelijk declaratie-blokkerend — is `blokkade` daar de juiste severity, en welke voor Wlz/forensisch? **Advies: vaststellen in de nudge-/declaratie-ronde**, waardelijst-attribuut staat er klaar voor.
+
+---
+
+## 8. Bronverwijzingen
+
+| Onderdeel | Bron |
+|---|---|
+| PERSOON/CLIENT-splitsing, BSN optioneel | discovery §5.1 besluit 1; spelregel 3.1 #6 |
+| Gestructureerde naam, meerdere adressen, geslacht/genderidentiteit, overlijden | onderzoek-standaarden §2.2 (zib Patient v4.3), §8 |
+| CLIENTRELATIE met twee assen relatie × rol | onderzoek-standaarden §2.2 (zib Contactpersoon v5.0); onderzoek-leveranciers §2.2 (Nedap ClientContactRelation + Type) |
+| Vertegenwoordiging, leeftijdsgrenzen 12/16 | onderzoek-proces §8 (WGBO/KNMG) |
+| Vaste huisarts als informatie-ontvanger, huisarts onbekend/geen toestemming | onderzoek-proces §2.8–§2.9 |
+| VERWIJZING: verwijsdatum, 275 dagen, echelon, heraanmelding, DSM-vermoeden | onderzoek-proces §2.3–§2.5, §2.10 (Verwijsafspraken GGZ, NHG-richtlijn, NR/REG-2616a); onderzoek-standaarden §2.2, §8 |
+| ZPM-verwijstypen 01–07, zorglabels | onderzoek-standaarden §6.3 (ZPM-veldafspraken jan 2022) |
+| Doorverwijsroutes (5 erkende) | onderzoek-proces §2.7 |
+| 60-dagen-huisartsmelding | onderzoek-proces §2.6 |
+| Referral-decompositie marktconform | onderzoek-leveranciers §2.2 (Nedap Referral) |
+| TOEWIJZING (iWmo/iJw 301, woonplaatsbeginsel) | onderzoek-standaarden §7 |
+| VERZEKERING/COV | onderzoek-proces §10.1 stap 2; iStandaarden/Vecozo-praktijk |
+| TOESTEMMING generiek (drie vindplaatsen) | onderzoek-standaarden §9.5; onderzoek-proces §2.8, §7 (opt-in DSM, privacyverklaring) |
+| Episode-ontstaan bij intake | onderzoek-proces §1 (LKS-verantwoordelijkheidsoverdracht), §4.1–§4.2 (Treeknorm/NZa-definities), §10.3 |
+| Episode ≠ ZPM-zorgtraject, trajectnummer-hergebruik | onderzoek-standaarden §6.1; onderzoek-leveranciers §2.3 |
+| Statusmachine expliciet, regels in model | spelregels 3.1 #7/#9; discovery §5.1 besluiten 5–6 |
+| Waardelijsten met geldigheidsperioden en externe codes | onderzoek-leveranciers §2.2/§7.1; onderzoek-standaarden §8 |
+| TIP-grensvlak, events, snapshots | discovery §3.3 (afstemming Joshua 17-7-2026) |
+| Wachtlijst aan aanmelding/episode | discovery §5.3-besluit; onderzoek-proces §4 |

docs/datamodel/deelmodellen/model-behandelplan.md

@@ -0,0 +1,279 @@
+# Datamodelvoorstel — Behandelplan (deelgebied §5.5)
+
+**Status:** structurele herziening nodig — het snapshotbesluit in `../besluiten/besluitenlog-datamodel-2026-07-18.md` is leidend
+**Datum:** 18 juli 2026
+**Kader:** bouwt voort op `datamodel-discovery.md` (spelregels §3.1, TIP-grensvlak §3.3, besluiten §5). Geen enkel genomen besluit wordt teruggedraaid. Scope conform besluit §5.5: plan-kern — doelen, interventies, evaluatiemomenten, status, versiebeheer, cliëntakkoord. Sessieplanning → agenda-ronde; leefgebieden en veiligheidsplan → aparte beslissing later.
+
+> **Let op:** de kernopzet hieronder — één volledig nieuw BEHANDELPLAN-record per versie — is vervangen door één logisch, levend behandelplan per zorgepisode met onveranderlijke formele snapshots. Ook MDO, evaluatie, behandelvisieconfiguratie, planakkoord en multidisciplinaire bijdragen zijn in het besluitenlog nader bepaald. Gebruik dit voorstel nog niet als basis voor SQL.
+
+**Kernkeuzes in dit voorstel** (onderbouwing in §5.5-open-vragen → bronnen):
+
+1. **Versiebeheer = nieuw record per versie.** Een vastgesteld plan is onveranderlijk; elke inhoudelijke wijziging is een nieuwe planversie die de vorige vervangt. Gedragen door LKS 4.0 ("substantiële aanpassing ⇒ nieuw behandelplan"), de Nedap-praktijk (DRAFT/ACTIVE/OLD, versie = nieuw plan) en spelregel §3.1 #3 (append-only denken). Muteren mag alleen in status `concept`.
+2. **Cliëntakkoord = los feit, geen status.** Eigen entiteit BEHANDELPLAN_AKKOORD met datum, wijze van bespreken en wie akkoord gaf (cliënt of vertegenwoordiger, WGBO 12/16-grenzen). Gedragen door LKS 4.0 (toestemming is een gebeurtenis vóór vaststelling), WGBO informed consent, FHIR-patroon (CarePlan.status ≠ Consent) en Nedap (CarePlanAgreement + discussionType).
+3. **Statusmachine minimaal:** `concept → vastgesteld → vervangen | afgesloten`, plus `vervallen` voor ingetrokken concepten. Proces-toestanden als "in evaluatie" zijn TIP-terrein, geen ECD-status.
+4. **Kwaliteitsstatuut-eisen als vaststellings-voorwaarden:** regiebehandelaar, ≥1 doel, ≥1 evaluatiemoment, crisis- en waarnemingsafspraken zijn verplicht op het moment van vaststellen (niet al in concept).
+
+---
+
+## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.5)
+
+Discovery-feitzinnen 1 t/m 9 blijven geldig; hieronder de uitgewerkte en nieuwe set. **[G]** = gewijzigd/verfijnd t.o.v. discovery, **[N]** = nieuw.
+
+**Plan en versie**
+
+1. [G] *Voor de zorgepisode van Jan de Vries is op 1 augustus 2026 behandelplan-versie 1 opgesteld door M. de Boer.* (versienummer expliciet vanaf versie 1)
+2. *Het behandelplan heeft status "concept".*
+3. [G] *Het behandelplan is gebaseerd op de intake van 20 juli 2026 (herkomst, optioneel) en adresseert diagnose F32.1 (verplicht bij vaststelling, meerdere mogelijk).*
+4. [N] *In het behandelplan is vastgelegd dat psychiater A. Visser de rol van regiebehandelaar vervult in de behandelfase.* (LKS §3.6.2 onderdeel 5)
+5. [N] *Het behandelplan bevat afspraken hoe te handelen bij crisis en wie waarneemt bij afwezigheid van de regiebehandelaar.* (LKS §3.6.2 onderdeel 4)
+6. [N] *Behandelplan-versie 1 is op 6 augustus 2026 vastgesteld door regiebehandelaar A. Visser.*
+7. [G] *Behandelplan-versie 2 vervangt versie 1; bij vaststelling van versie 2 op 15 september 2026 kreeg versie 1 status "vervangen".*
+8. [N] *Behandelplan-versie 1 is als concept ingetrokken (status "vervallen") zonder ooit te zijn vastgesteld.*
+9. [N] *Het behandelplan is bij afronding van de behandeling op 1 maart 2027 afgesloten.*
+
+**Doelen**
+
+10. [G] *Behandelplan-versie 1 bevat behandeldoel "weer drie nachten per week doorslapen" met prioriteit "hoog" en streefdatum 24 oktober 2026 (beoogde termijn 12 weken).* (LKS: doelen voor een bepaalde, te evalueren periode)
+11. *Behandeldoel X heeft een cliëntversie in B1-taal.*
+12. [N] *Behandeldoel X richt zich op diagnose F32.1.* (optionele verwijzing per doel, naast de plan-brede koppeling)
+13. [N] *Behandeldoel X in versie 2 is de voortzetting van behandeldoel X' in versie 1.* (keten voor trendmeting over versies heen)
+14. [N] *Behandeldoel X heeft status "behaald" sinds 15 september 2026.*
+
+**Interventies**
+
+15. [G] *Behandelplan-versie 1 bevat interventie van type "CGT", uitgevoerd door psycholoog M. de Boer.* (LKS §3.6.2 onderdeel 3: wie voert uit)
+16. [G] *Interventie "CGT" is gekoppeld aan behandeldoel X en behandeldoel Y.* (m:n, minimaal één doel)
+17. [N] *Interventie "eHealth-module slaaptraining" verwijst naar externe activiteit met systeem "Koppeltaal" en kenmerk "AD-1234".* (Koppeltaal-voorbereiding, onderzoek-standaarden §4)
+
+**Evaluatiemomenten**
+
+18. [G] *Behandelplan-versie 1 kent een gepland evaluatiemoment van type "tussenevaluatie" op 12 september 2026 (week 6).*
+19. [N] *Het evaluatiemoment van 12 september 2026 is op 14 september 2026 uitgevoerd met uitkomst "bijstellen".* (LKS: op-/afschalen vast onderdeel van elke evaluatie; bijstelling leidt tot nieuwe planversie)
+20. [N] *Het evaluatiemoment van type "jaarevaluatie" is uiterlijk 12 maanden na vaststelling gepland.* (LKS: evaluatie minimaal éénmaal per jaar — bewaking via nudge)
+
+**Cliëntakkoord**
+
+21. [G] *Cliënt Jan de Vries heeft op 5 augustus 2026 ingestemd met behandelplan-versie 1; het plan is met hem besproken.*
+22. [N] *Voor behandelplan-versie 1 is vastgelegd dat het plan is besproken maar dat de cliënt (nog) geen akkoord heeft gegeven.* (WGBO-realiteit: besproken ≠ akkoord)
+23. [N] *Wettelijk vertegenwoordiger P. de Vries heeft op 5 augustus 2026 namens de cliënt ingestemd met behandelplan-versie 1.* (WGBO <12 / 12–16 / wilsonbekwaam)
+
+**Richting andere deelgebieden (context, hier niet gemodelleerd)**
+
+24. [N] *Na vaststelling van het behandelplan is de verwijzer schriftelijk geïnformeerd (met toestemming van de cliënt).* → correspondentie-ronde; hier alleen het TIP-event (§6).
+
+## 2. Entiteiten
+
+Algemeen (spelregels §3.1, geldt voor alle entiteiten hieronder, niet herhaald per tabel): `id` UUID stabiel, `created_at`/`created_by`, provenance (mens/AI + model + bronnen + content-hash) op klinische records, `deleted_at` soft delete, audit append-only.
+
+### 2.1 BEHANDELPLAN
+
+**Doel:** één versie van het behandelplan van een zorgepisode. Een nieuwe versie is een nieuw record; de keten van versies vormt samen "het plan".
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| zorgepisode_id | UUID → ZORGEPISODE | ja | besluit §5.1 #9 / §5.5 |
+| versienummer | integer ≥ 1 | ja | oplopend per episode |
+| vervangt_plan_id | UUID → BEHANDELPLAN | nee | gevuld vanaf versie 2 |
+| status | code → `behandelplan_status` | ja | zie §5 |
+| opgesteld_door | UUID → MEDEWERKER | ja | rollenronde: entiteit MEDEWERKER volgt |
+| opgesteld_op | datum | ja | |
+| gebaseerd_op_intake_id | UUID → INTAKE | nee | herkomst, geen eigenaar (patroon §5.4 #2) |
+| regiebehandelaar_id | UUID → MEDEWERKER | bij vaststelling | LKS §3.6.2 #5: regiebehandelaar behandelfase |
+| aanpak_toelichting | tekst | nee | LKS #2 "wijze waarop" op hoofdlijnen; detail zit in interventies |
+| crisisafspraken | tekst | bij vaststelling | LKS §3.6.2 #4 |
+| waarnemingsafspraken | tekst | bij vaststelling | LKS §3.6.2 #4 |
+| vastgesteld_op | datum | bij status ≥ vastgesteld | |
+| vastgesteld_door | UUID → MEDEWERKER | bij status ≥ vastgesteld | LKS: regiebehandelaar (indicerende rol) stelt vast |
+| einde_op / einde_status | datum + afleidbaar | bij vervangen/afgesloten/vervallen | |
+
+**Uniciteit:**
+- (`zorgepisode_id`, `versienummer`) uniek.
+- **Max één plan met status `vastgesteld` per zorgepisode** (partial unique index) — spelregel §3.1 #7: regel in het model.
+- `vervangt_plan_id` uniek waar gevuld (een versie wordt door hoogstens één opvolger vervangen).
+
+"Verplicht bij vaststelling" = afgedwongen in de statusovergang `concept → vastgesteld` (check-constraint/trigger), niet bij aanmaken van het concept.
+
+### 2.2 BEHANDELPLAN_DIAGNOSE (koppel)
+
+**Doel:** welke diagnoses het plan adresseert (feitzin 3). M:n omdat een plan meerdere diagnoses kan adresseren en een diagnose door opeenvolgende planversies geadresseerd blijft.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| behandelplan_id | UUID → BEHANDELPLAN | ja |
+| diagnose_id | UUID → DIAGNOSE | ja |
+
+**Uniciteit:** (`behandelplan_id`, `diagnose_id`) uniek. **Regel:** ≥ 1 rij verplicht bij vaststelling (zib Behandeldoel: relatie doel/plan → diagnose is een echte verwijzing, geen tekst).
+
+### 2.3 BEHANDELDOEL
+
+**Doel:** één doel binnen één planversie, met cliëntversie en evalueerbare termijn.
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| behandelplan_id | UUID → BEHANDELPLAN | ja | doel leeft binnen één versie |
+| volgnummer | integer | ja | volgorde/weergave (prototype: 1–6, geen harde limiet in schema) |
+| omschrijving | tekst | ja | professionele formulering (SMART) |
+| clientversie | tekst | nee | B1-taal; nudge als hij ontbreekt, geen harde eis |
+| prioriteit | code → `doel_prioriteit` | ja | |
+| streefdatum | datum | nee | LKS: doelen voor een te evalueren periode; nudge als leeg |
+| diagnose_id | UUID → DIAGNOSE | nee | doel-specifieke reden (zib Behandeldoel: RedenBehandeling) |
+| status | code → `doel_status` | ja | default `actief` |
+| status_gewijzigd_op | datum | nee | |
+| overgenomen_van_doel_id | UUID → BEHANDELDOEL | nee | keten over versies heen (feitzin 13) — maakt trendmeting (TIP-longitudinale IE's, §3.3 #3) en "rapporteren op doel" over versies mogelijk |
+
+**Uniciteit:** (`behandelplan_id`, `volgnummer`) uniek. **Regel:** ≥ 1 doel verplicht bij vaststelling (LKS §3.6.2 #1). `overgenomen_van_doel_id` moet naar een doel in de direct voorafgaande versie van dezelfde episode wijzen.
+
+### 2.4 INTERVENTIE
+
+**Doel:** één interventie binnen één planversie: wat wordt ingezet, door wie (LKS #3), en — bij eHealth — met welke externe referentie.
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| behandelplan_id | UUID → BEHANDELPLAN | ja | |
+| interventietype | code → `interventietype` | ja | |
+| omschrijving | tekst | nee | vrije specificatie ("anders"-patroon uit zibs) |
+| uitvoerder_id | UUID → MEDEWERKER | bij vaststelling | LKS #3: wie voert uit; discipline/beroep via rollenronde |
+| frequentie_toelichting | tekst | nee | "wekelijks", "2×/week" — echte planning is agenda-ronde |
+| extern_systeem | tekst/code | nee | bijv. "koppeltaal" |
+| extern_kenmerk | tekst | nee | ID van de eHealth-activiteit; samen met extern_systeem gevuld of samen leeg |
+
+**Uniciteit:** geen natuurlijke sleutel buiten id; zelfde type mag vaker voorkomen (bijv. twee eHealth-modules).
+
+### 2.5 INTERVENTIE_DOEL (koppel)
+
+**Doel:** welke doelen een interventie dient (prototype: interventies gekoppeld aan doelen; m:n).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| interventie_id | UUID → INTERVENTIE | ja |
+| behandeldoel_id | UUID → BEHANDELDOEL | ja |
+
+**Uniciteit:** (`interventie_id`, `behandeldoel_id`) uniek. **Regel:** ≥ 1 doelkoppeling per interventie bij vaststelling; interventie en doel moeten tot hetzelfde behandelplan behoren (constraint).
+
+### 2.6 EVALUATIEMOMENT
+
+**Doel:** gepland én uitgevoerd evaluatiemoment van een planversie (LKS #6: na hoeveel tijd wordt geëvalueerd; evaluatie minimaal jaarlijks).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| behandelplan_id | UUID → BEHANDELPLAN | ja | |
+| evaluatietype | code → `evaluatietype` | ja | |
+| gepland_op | datum | ja | feitzin "week 6" wordt bij vaststelling een concrete datum |
+| status | code → `evaluatiemoment_status` | ja | default `gepland` |
+| uitgevoerd_op | datum | bij status uitgevoerd | |
+| uitgevoerd_door | UUID → MEDEWERKER | bij status uitgevoerd | LKS: regiebehandelaar zorgt voor evaluatiemomenten; MDT-toets → rollenronde |
+| uitkomst | code → `evaluatie_uitkomst` | bij status uitgevoerd | op-/afschalen is vast onderdeel van elke evaluatie (LKS) |
+| toelichting | tekst | nee | het inhoudelijke evaluatieverslag is een RAPPORTAGE (rapportage-ronde) die naar dit moment verwijst |
+
+**Uniciteit:** geen buiten id. **Regel:** ≥ 1 evaluatiemoment met status `gepland` verplicht bij vaststelling van het plan.
+
+### 2.7 BEHANDELPLAN_AKKOORD
+
+**Doel:** het WGBO/informed-consent-feit, los van de planstatus. Legt vast óf en hoe het plan met de cliënt is besproken en wie instemde — ook het níet-akkoord is een registreerbaar feit (Nedap discussionType; LKS: vaststellen "nadat waar mogelijk toestemming is verkregen").
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| behandelplan_id | UUID → BEHANDELPLAN | ja | akkoord hoort bij één specifieke versie |
+| datum | datum | ja | |
+| wijze | code → `akkoord_wijze` | ja | besproken-en-akkoord / akkoord-volgt / niet-besproken / geen-akkoord |
+| gegeven_door_type | code → `akkoord_partij` | ja | cliënt zelf / wettelijk vertegenwoordiger / gezaghebbende ouder |
+| gegeven_door_persoon_id | UUID → PERSOON | nee | bij vertegenwoordiger: welke persoon (PERSOON-rollenmodel §5.1 #1) |
+| vastgelegd_door | UUID → MEDEWERKER | ja | |
+| toelichting | tekst | nee | bijv. reden geen akkoord |
+
+**Uniciteit:** geen — meerdere akkoord-feiten per planversie zijn legitiem (kind én ouders bij 12–16 jaar; eerst "akkoord volgt", later het akkoord zelf). Het meest recente feit per partij telt functioneel.
+
+## 3. Relaties met cardinaliteit
+
+| Relatie | Cardinaliteit | Toelichting |
+|---|---|---|
+| ZORGEPISODE — BEHANDELPLAN | 1 — 0..n | alle versies hangen aan de episode (besluit §5.1 #9 / §5.5) |
+| BEHANDELPLAN — BEHANDELPLAN (vervangt) | 0..1 — 0..1 | versieketen; opvolger uniek |
+| BEHANDELPLAN — DIAGNOSE (via BEHANDELPLAN_DIAGNOSE) | m — n | ≥ 1 bij vaststelling; DIAGNOSE uit deelgebied §5.4 |
+| BEHANDELPLAN — INTAKE (gebaseerd op) | 0..n — 0..1 | herkomstverwijzing, optioneel; INTAKE uit deelgebied §5.2 |
+| BEHANDELPLAN — BEHANDELDOEL | 1 — 0..n (≥ 1 bij vaststelling) | doel leeft binnen één versie |
+| BEHANDELDOEL — DIAGNOSE | 0..n — 0..1 | doel-specifieke reden, optioneel |
+| BEHANDELDOEL — BEHANDELDOEL (overgenomen van) | 0..1 — 0..n theoretisch, praktisch 0..1 — 0..1 | keten over versies; splitsing van een doel in twee opvolgers is toegestaan |
+| BEHANDELPLAN — INTERVENTIE | 1 — 0..n | |
+| INTERVENTIE — BEHANDELDOEL (via INTERVENTIE_DOEL) | m — n (≥ 1 doel per interventie bij vaststelling) | binnen hetzelfde plan |
+| BEHANDELPLAN — EVALUATIEMOMENT | 1 — 0..n (≥ 1 gepland bij vaststelling) | |
+| BEHANDELPLAN — BEHANDELPLAN_AKKOORD | 1 — 0..n | los consent-feit per versie |
+| MEDEWERKER — BEHANDELPLAN | 1 — 0..n | als opsteller, vaststeller, regiebehandelaar (drie aparte verwijzingen; MEDEWERKER/rollen → rollenronde) |
+| PERSOON — BEHANDELPLAN_AKKOORD | 0..1 — 0..n | vertegenwoordiger als persoon-met-rol (besluit §5.1 #1) |
+| RAPPORTAGE — EVALUATIEMOMENT / BEHANDELDOEL / BEHANDELPLAN | latere ronde | evaluatieverslag en "rapporteren op doel" verwijzen hierheen (onderzoek-rapportage §4, §9.1) |
+
+## 4. Waardelijsten
+
+Conform spelregel §3.1 #1 als referentietabellen; elke rij optioneel met externe code + codesysteem-URI + geldig-van/geldig-tot (patroon uit onderzoek-standaarden §8).
+
+| Waardelijst | Startwaarden | Extra attributen |
+|---|---|---|
+| `behandelplan_status` | concept, vastgesteld, vervangen, afgesloten, vervallen | is_eindstatus (ja/nee) |
+| `doel_prioriteit` | hoog, middel, laag | — |
+| `doel_status` | actief, behaald, gestaakt, vervallen | is_eindstatus |
+| `interventietype` | CGT, EMDR, schematherapie, systeemtherapie, farmacotherapie, vaktherapie, groepstherapie, eHealth-module, sociaal-psychiatrische begeleiding, overig | is_ehealth (ja/nee) — stuurt of extern_systeem/kenmerk relevant is; startlijst te bevestigen |
+| `evaluatietype` | tussenevaluatie, jaarevaluatie, eindevaluatie | — |
+| `evaluatiemoment_status` | gepland, uitgevoerd, vervallen | — |
+| `evaluatie_uitkomst` | voortzetten, bijstellen, opschalen, afschalen, afronden | leidt_tot_nieuwe_versie (ja/nee — bijstellen/opschalen/afschalen → ja, als hint voor TIP, geen harde regel) |
+| `akkoord_wijze` | besproken_en_akkoord, besproken_akkoord_volgt, niet_besproken, besproken_geen_akkoord | telt_als_consent (alleen besproken_en_akkoord → ja) |
+| `akkoord_partij` | client, wettelijk_vertegenwoordiger, gezaghebbende_ouder | — |
+
+## 5. Statusmachine BEHANDELPLAN
+
+Expliciet per spelregel §3.1 #9, in een referentietabel `behandelplan_statusovergang` (van, naar, voorwaarde, rol).
+
+| Van | Naar | Voorwaarden (afgedwongen in de overgang) | Wie mag zetten |
+|---|---|---|---|
+| — | concept | — | behandelaar (rollenronde) |
+| concept | vastgesteld | regiebehandelaar_id, crisisafspraken, waarnemingsafspraken gevuld; ≥ 1 diagnose-koppeling; ≥ 1 doel; elke interventie ≥ 1 doel; ≥ 1 gepland evaluatiemoment; geen ander vastgesteld plan op de episode (of: die overgang zet de vorige tegelijk op `vervangen`) | regiebehandelaar, indicerende rol (LKS) — definitieve rolbinding in rollenronde |
+| concept | vervallen | — | opsteller/regiebehandelaar → rollenronde |
+| vastgesteld | vervangen | uitsluitend als effect van het vaststellen van de opvolgende versie (zelfde transactie); nooit handmatig | systeem, getriggerd door vaststelling opvolger |
+| vastgesteld | afgesloten | einde behandeling/episode | regiebehandelaar → rollenronde |
+| vervangen / afgesloten / vervallen | — | eindstatussen; heropening = nieuwe versie (concept) die op de laatste versie voortbouwt | — |
+
+**Bewust géén statussen:** `in_evaluatie` (proces-toestand: het feit is een EVALUATIEMOMENT, de bewaking is TIP), `on-hold` (pauzering is een episode-/behandelingsfeit, geen planstatus), `gearchiveerd` (dat is `vervangen`/`afgesloten` + soft delete-regime). Cliëntakkoord is géén status (kernkeuze 2).
+
+**Mutatieregels per status:** `concept` vrij muteerbaar (met audit). `vastgesteld` en eindstatussen: inhoud onveranderlijk — wijziging = nieuwe versie (zie open besluitpunt 3). Doel-status en evaluatiemoment-status mogen wél muteren op een vastgesteld plan (dat zijn feiten óver de uitvoering, niet het plan zelf), altijd met audit-event.
+
+**Rollen:** alle "wie mag"-cellen zijn kandidaat-invullingen op basis van LKS 4.0; definitieve toewijzing in de rollenronde (consistent met discovery §5.1 besluit 6).
+
+## 6. ECD/TIP-eigenaarschap en events richting TIP
+
+**Eigenaarschap:** alle entiteiten in dit voorstel zijn **leidend in het ECD** (klinische feiten, bron van waarheid). TIP bezit: termijnbewaking, taken/reminders, nudge-evaluatie en de doelgebonden audit-snapshots (§3.3-afstemming Joshua). TIP houdt als longitudinale IE's hoogstens bij: doel-statusverloop en evaluatie-uitkomsten per episode (trend), via de `overgenomen_van`-keten — minimale, herleidbare kopie.
+
+**Events ECD → TIP** (elk met record-UUID + content-hash, zelfde mechanisme als her-embedding, §3.2/§3.3 #4):
+
+| Event | Payload-kern | Waarvoor TIP het gebruikt |
+|---|---|---|
+| `behandelplan.concept_aangemaakt` | plan-id, episode-id, versienr | taak "akkoord ophalen", "plan vaststellen" |
+| `behandelplan.vastgesteld` | plan-id, versienr, vastgesteld_op, regiebehandelaar | nudge terugkoppelbrief verwijzer (LKS, met cliënt-toestemming — correspondentie-ronde); ZPM `behandelplan_check` vervalt; jaarevaluatie-termijn start |
+| `behandelplan.vervangen` / `afgesloten` / `vervallen` | plan-id, opvolger-id | kopie-veroudering voorkomen; taken sluiten |
+| `behandelplan.gemuteerd` (alleen concept) | plan-id, content-hash | snapshot-verversing, her-embedding |
+| `akkoord.geregistreerd` | plan-id, wijze, partij | nudge bij `besproken_geen_akkoord` (LKS: geen overeenstemming → doorverwijzen bespreken) en bij vaststellen zonder consent-feit |
+| `evaluatiemoment.gepland` / `uitgevoerd` / `vervallen` | moment-id, gepland_op, uitkomst | termijnbewaking (Treek-achtig: "evaluatie over 2 weken", "jaarevaluatie > 12 mnd → waarschuwing"); uitkomst `bijstellen` → taak "nieuwe planversie opstellen" |
+| `doel.status_gewijzigd` | doel-id, keten-id, status | trend/voortgang (longitudinale IE) |
+
+**Nudge-regels (TIP/Nudge Engine, geen schema-eisen):** behandeling gestart zonder vastgesteld plan (ZPM-trigger `behandelplan_check` — zie open besluitpunt 2); vastgesteld plan zonder consent-feit (`telt_als_consent`); jaarevaluatie-termijn (LKS: minimaal 1×/jaar); doel zonder cliëntversie of streefdatum; terugkoppeling verwijzer niet geregistreerd na vaststelling.
+
+## 7. Open besluitpunten voor Colin
+
+1. **Vaststellen zonder cliëntakkoord: toestaan met waarschuwing?** LKS zegt "nadat waar mogelijk toestemming is verkregen" — "waar mogelijk" impliceert dat vaststellen zonder akkoord soms legitiem is (crisis, wilsonbekwaam zonder bereikbare vertegenwoordiger). **Advies:** toestaan; ontbrekend of negatief consent-feit wordt een `waarschuwing`-nudge, geen blokkade. Het niet-akkoord zelf altijd registreerbaar houden (akkoord_wijze `besproken_geen_akkoord`).
+2. **Behandelplan verplicht vóór start behandeling: nudge-severity.** Discovery §5.5 hield dit open. **Advies:** nudge, geen schema-eis (crisis en interne intakes maken een harde volgorde onhoudbaar — zelfde argument als screening-vóór-intake, §5.2 besluit 4); severity `waarschuwing` bij Zvw-regulier, `signaal` elders — configureerbaar per kader, zoals de verwijsbrief-regel (§5.1 #7).
+3. **Strikte onveranderlijkheid na vaststelling — ook voor typo's?** **Advies:** strikt. Elke inhoudelijke wijziging = nieuwe versie; een pure verschrijving corrigeren mag niet stilzwijgend (WGBO-correctiesystematiek: geen stille edits in een dossier). Wie het te zwaar vindt: alternatief is een audit-gelogde "tekstuele correctie" op vastgestelde plannen — ik raad het af, twee regimes maken het model en de uitleg aan behandelaren complexer.
+4. **Crisis- en waarnemingsafspraken hard verplicht bij vaststelling?** LKS noemt ze als verplicht onderdeel ("bevat in ieder geval"). **Advies:** ja, harde voorwaarde in de statusovergang — het zijn twee tekstvelden, de drempel is laag en de dekking is een Kwaliteitsstatuut-eis. Alternatief (nudge) alleen kiezen als de praktijk kort-durende trajecten kent waar dit knelt.
+5. **Doel-keten (`overgenomen_van`) als mechanisme voor trend over versies — akkoord?** Nodig zodat "rapporteren op doel" en TIP-trendmeting versiewissels overleven. **Advies:** overnemen; kost één optionele kolom.
+6. **Startlijst `interventietype` bevestigen** (CGT, EMDR, schematherapie, systeemtherapie, farmacotherapie, vaktherapie, groepstherapie, eHealth-module, sociaal-psychiatrische begeleiding, overig) en of de lijst per instelling uitbreidbaar is (zoals afdelingen, §5.2 besluit 2). **Advies:** instellingsconfigureerbaar met deze lijst als default.
+7. **"Max één vastgesteld plan per episode" als DB-constraint — akkoord?** Nedap doet één ACTIVE per cliënt; hier per episode (consistent met §5.1 #9). **Advies:** ja, partial unique index; parallel lopende deelplannen (bijv. apart veiligheidsplan) komen in de latere veiligheidsplan-beslissing, niet als tweede vastgesteld behandelplan.
+8. **Evaluatie-uitkomst `bijstellen`: automatisch een concept-opvolger klaarzetten (TIP-taak) of alleen signaleren?** **Advies:** alleen signaleren via event + taak; het ECD maakt nooit zelf records aan (human-in-the-loop hard constraint).
+
+## 8. Bronverwijzingen
+
+| Onderwerp | Bron |
+|---|---|
+| Scope, genomen besluiten, spelregels | `datamodel-discovery.md` §3.1, §3.3, §5.1 #9, §5.4 #2, §5.5 |
+| Verplichte planonderdelen (doelen/periode, wie voert uit, crisis/waarneming, regiebehandelaar, evaluatietermijn), toestemming vóór vaststelling, terugkoppeling verwijzer, jaarlijkse evaluatie, substantiële aanpassing ⇒ nieuw plan | `onderzoek-proces.md` §5–6 (LKS 4.0 §3.6.2), §10.1 stap 10–12, §10.3 verrijking 8 |
+| Statusmachine minimaal + versie=nieuw record + cliëntakkoord als los feit met besprekingsstatus (Nedap CarePlan/CarePlanAgreement) | `../onderzoek/onderzoek-leveranciers.md` §2.6, §7 punt 6 |
+| Doel→diagnose als echte relatie, streefdatum, planstatus ≠ consent (FHIR CarePlan/Consent), interventie met externe eHealth-referentie (Koppeltaal), waardelijst-patroon (externe code + geldigheidsperiode, "anders"-optie) | `../onderzoek/onderzoek-standaarden.md` §2.2 (zib Behandeldoel), §3, §4, §8 |
+| Evaluatieverslag en rapporteren-op-doel als rapportage-verwijzingen; geen stille edits (WGBO-correctie) | `../onderzoek/onderzoek-rapportage.md` §4, §1.1, §9.1 |
+| WGBO informed consent, vertegenwoordiging 12/16/wilsonbekwaam | `onderzoek-proces.md` §8 |
+| ZPM `behandelplan_check` als regeltrigger | discovery §5.5 open vraag; triqura-cortex regelset (CLAUDE.md) |

docs/datamodel/deelmodellen/model-diagnose.md

@@ -0,0 +1,286 @@
+# Datamodelvoorstel — deelgebied Diagnose
+
+**Status:** voorstel ter review (bouwt voort op `datamodel-discovery.md` §5.4)
+**Datum:** 18 juli 2026
+**Modelleur:** Claude (deelgebied-agent "diagnose")
+**Kader:** genomen besluiten uit de discovery zijn niet teruggedraaid. Uitgangspunten: DSM-5-TR primair met ICD-10-mapping als entiteit (besluit §5.4 #1), diagnose aan de ZORGEPISODE met intake als optionele herkomst (besluit §5.4 #2), spelregels §3.1 (waardelijsten als data, provenance, soft delete, statusmachines expliciet, regels in het model).
+
+---
+
+## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.4)
+
+Gewijzigd betekent: de startlijst-feitzin is herschreven naar DSM-bronregistratie en de twee status-assen. Nieuw betekent: het feit ontbrak in de discovery.
+
+1. **(gewijzigd, was §5.4 #1)** *Voor de zorgepisode van Jan de Vries is op 24 juli 2026 een diagnose geregistreerd met DSM-5-TR-classificatie "depressieve stoornis, eenmalige episode, matig" door psycholoog M. de Boer.*
+2. **(gewijzigd, was deel van §5.4 #1)** *De diagnose is gesteld tijdens de intake van 22 juli 2026.* (herkomst, optioneel — een diagnose kan ook tijdens de behandeling worden geregistreerd)
+3. **(nieuw)** *Uit de DSM-classificatie van de diagnose is via mappinglijstversie "WHO-FIC 2026-01" de ICD-10-code F32.1 afgeleid.*
+4. **(ongewijzigd, §5.4 #3)** *De diagnose heeft ernst "matig".*
+5. **(gewijzigd, was §5.4 #4)** *De diagnose heeft verificatiestatus "werkdiagnose".*
+6. **(gewijzigd, was §5.4 #4)** *De diagnose is op 30 juli 2026 definitief vastgesteld door regiebehandelaar S. el Amrani.*
+7. **(gewijzigd, was §5.4 #5/#6)** *De diagnose heeft klinische status "actief".* / *De diagnose is op 1 december 2026 in remissie verklaard door M. de Boer.*
+8. **(gewijzigd, was §5.4 #2)** *De diagnose "depressieve stoornis, eenmalige episode, matig" is sinds 30 juli 2026 de hoofddiagnose van de zorgepisode van Jan de Vries.* (hoofddiagnose-zijn is een feit met een geldigheidsperiode, geen vaste eigenschap van het diagnoserecord)
+9. **(nieuw)** *Per 15 oktober 2026 is de diagnose "bipolaire-I-stoornis" de hoofddiagnose van de zorgepisode; de eerdere hoofddiagnose-aanwijzing is per die datum beëindigd.*
+10. **(nieuw, comorbiditeit)** *Voor de zorgepisode van Jan de Vries is daarnaast de diagnose "gegeneraliseerde-angststoornis" geregistreerd; deze is geen hoofddiagnose (nevendiagnose).*
+11. **(nieuw)** *De diagnose X is op 2 september 2026 vervallen verklaard met reden "foutregistratie" en vervangen door diagnose Y.*
+12. **(nieuw, zorgvraagtypering)** *Voor de zorgepisode van Jan de Vries is op 30 juli 2026 een HoNOS+-afname gedaan door M. de Boer; item 2 "opzettelijke zelfverwonding" heeft score 1.*
+13. **(nieuw)** *Op basis van de HoNOS+-afname van 30 juli 2026 adviseerde de NZa-zorgvraagtyperingstool (algoritmeversie 3.2) zorgvraagtype 4; behandelaar M. de Boer heeft op 30 juli 2026 zorgvraagtype 4 gekozen.*
+14. **(nieuw)** *De zorgvraagtypering van de zorgepisode is voor het laatst vastgesteld op 30 juli 2026.* (basis voor de nudge "hertypering minimaal jaarlijks")
+15. **(nieuw, registratiefeit)** *Cliënt Jan de Vries heeft op 5 augustus 2026 een privacyverklaring afgegeven tegen aanlevering van zorgvraagtyperingsgegevens aan de NZa.* (structuur volgt in de toestemmings-ronde; zie open besluit 7)
+
+## 2. Entiteiten
+
+### 2.1 DIAGNOSE
+
+**Doel:** één klinische diagnose van een cliënt binnen een zorgepisode, geregistreerd in DSM-5-TR-termen (bronregistratie), met afgeleide ICD-10-code en twee onafhankelijke status-assen (verificatie + klinisch).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| id | uuid | ja | stabiele identiteit (spelregel §3.1 #5) |
+| zorgepisode_id | uuid → ZORGEPISODE | ja | eigenaar van de diagnose (besluit §5.4 #2) |
+| dsm_classificatie_id | uuid → DSM_CLASSIFICATIE | ja | de DSM-5-TR-classificatie (bronregistratie) |
+| afgeleide_icd10_code | tekst | nee | automatisch afgeleid via DSM_ICD10_MAPPING; leeg als de mapping (nog) geen resultaat geeft → nudge |
+| mapping_lijstversie | tekst | nee | versie van de WHO-FIC-codelijst waarmee de afleiding is gedaan (reproduceerbaarheid bij controle/herdeclaratie) |
+| ernst | waardelijst `diagnose_ernst` | nee | zie open besluit 5 (deels redundant met DSM-specificatie) |
+| verificatiestatus | waardelijst `diagnose_verificatiestatus` | ja | default `werkdiagnose` |
+| definitief_op | datum | nee | gezet bij overgang naar `definitief` |
+| definitief_door | uuid → MEDEWERKER | nee | idem; rolvereiste volgt in de rollenronde |
+| klinische_status | waardelijst `diagnose_klinische_status` | ja | default `actief` |
+| klinische_status_sinds | datum | ja | ingangsdatum van de huidige klinische status |
+| begindatum_aandoening | datum | nee | klinisch begin (onset), kan vóór de registratie liggen (zib Diagnose) |
+| wijze_van_vaststellen | waardelijst `wijze_van_vaststellen` | nee | zib Diagnose-element |
+| gesteld_tijdens_intake_id | uuid → INTAKE | nee | herkomst, geen eigenaar (besluit §5.4 #2) |
+| geregistreerd_op | timestamp | ja | |
+| geregistreerd_door | uuid → MEDEWERKER | ja | |
+| toelichting | tekst | nee | vrije tekst (AI-voorbereiding §3.2: structuur + tekst in één record) |
+| vervalreden | waardelijst `diagnose_vervalreden` | nee | verplicht zodra verificatiestatus `vervallen` is |
+| vervangen_door_diagnose_id | uuid → DIAGNOSE | nee | correctieketen: vervallen record wijst naar zijn opvolger |
+| auteur_type, ai_model, ai_bronnen, content_hash | provenance-velden | ja (patroon) | spelregel §3.1 #2; content_hash triggert her-embedding en het TIP-mutatie-event |
+| deleted_at | timestamp | nee | soft delete (spelregel §3.1 #4) |
+
+**Uniciteitsregels:**
+- `id` uniek.
+- Binnen één zorgepisode maximaal één **niet-vervallen, niet-verwijderde** diagnose per DSM-classificatie (partiële unieke index op `(zorgepisode_id, dsm_classificatie_id)` waar `verificatiestatus <> 'vervallen' and deleted_at is null`). Dezelfde classificatie mag wél terugkomen nadat een eerder record is vervallen.
+- `vervalreden` is verplicht ⇔ `verificatiestatus = 'vervallen'` (check-constraint).
+- Na `definitief`: `dsm_classificatie_id` is onveranderbaar (correctie = vervallen + nieuw record, zie statusmachine). Vergelijk Nedaps `immutable`-vlag.
+
+### 2.2 DSM_CLASSIFICATIE (referentietabel, geïmporteerd)
+
+**Doel:** de DSM-5-TR-classificaties als versioneerde referentiedata (import-patroon uit onderzoek-standaarden §8) — niet door behandelaars muteerbaar, nooit hardcoded.
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| id | uuid | ja | |
+| dsm_code | tekst | ja | code volgens de gebruikte DSM-uitgave/codelijst |
+| omschrijving | tekst | ja | let op licentie Boom/APA (open besluit 2) |
+| dsm_hoofdgroep_id | uuid → DSM_HOOFDGROEP | ja | t.b.v. factuur (g-ggz) en NZa-wachttijduitsplitsing per hoofddiagnosegroep |
+| selecteerbaar | boolean | ja | niet elke rij is een registreerbare einddiagnose (Nedap-patroon `selecteerbaar`) |
+| lijstversie | tekst | ja | importversie |
+| geldig_van / geldig_tot | datum | ja / nee | geldigheidsperiode per waarde (les uit Nedap-codetabellen) |
+
+**Uniciteit:** `(dsm_code, lijstversie)` uniek.
+
+### 2.3 DSM_HOOFDGROEP (referentietabel)
+
+**Doel:** NZa-diagnosehoofdgroepen; afleidbaar gegeven voor factuur en wachttijdrapportage. Attributen: id, code, omschrijving, geldig_van/geldig_tot. Uniciteit: `(code)` uniek binnen geldigheidsperiode.
+
+### 2.4 DSM_ICD10_MAPPING (referentietabel, geïmporteerd — de mappingtabel als entiteit)
+
+**Doel:** de officiële "Codelijst DSM-5(-TR) met ICD-10 afleidingen" (WHO-FIC CC Nederland/RIVM) als versioneerde m:n-mappingtabel. Eén DSM-classificatie kan naar meerdere ICD-10-codes leiden en omgekeerd — daarom een eigen entiteit, geen kolom met uniciteitsaanname (onderzoek-standaarden §5, checklistpunt 3).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| id | uuid | ja | |
+| dsm_classificatie_id | uuid → DSM_CLASSIFICATIE | ja | |
+| icd10_code | tekst | ja | ICD-10 zoals in NL gebruikt |
+| icd10_omschrijving | tekst | nee | |
+| voorkeur | boolean | ja | bij meerdere afleidingen: welke is de standaard voor declaratie |
+| lijstversie | tekst | ja | bijv. "publicatie 15-12-2023, geldig per 1-1-2024" |
+| geldig_van / geldig_tot | datum | ja / nee | de lijst wisselt periodiek; op het diagnoserecord staat vastgelegd met welke versie is afgeleid |
+
+**Uniciteit:** `(dsm_classificatie_id, icd10_code, lijstversie)` uniek; maximaal één `voorkeur = true` per `(dsm_classificatie_id, lijstversie)`.
+
+### 2.5 HOOFDDIAGNOSE_AANWIJZING
+
+**Doel:** het tijdgebonden feit "diagnose X is de hoofddiagnose van episode E van datum A tot datum B". Hiermee is "max één hoofddiagnose" een database-constraint (spelregel §3.1 #7) én blijft de historie behouden — nodig omdat de hoofddiagnose op de factuur en in de NZa-wachttijdrapportage per periode reproduceerbaar moet zijn. Alle overige actuele diagnoses van de episode zijn daarmee per definitie nevendiagnoses (comorbiditeit): geen apart type-veld nodig.
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| id | uuid | ja | |
+| zorgepisode_id | uuid → ZORGEPISODE | ja | redundant met diagnose→episode, maar nodig voor de uniciteitsconstraint |
+| diagnose_id | uuid → DIAGNOSE | ja | |
+| geldig_van | datum | ja | |
+| geldig_tot | datum | nee | leeg = actueel |
+| aangewezen_door | uuid → MEDEWERKER | ja | |
+| aangewezen_op | timestamp | ja | |
+
+**Uniciteitsregels:**
+- Geen overlappende geldigheidsperiodes binnen één zorgepisode (PostgreSQL exclusion-constraint op `(zorgepisode_id, daterange(geldig_van, geldig_tot))`) — dit ís het besluit "max één hoofddiagnose per moment in de tijd" (zie open besluit 1).
+- `diagnose_id` moet bij dezelfde `zorgepisode_id` horen (constraint/trigger).
+- Alleen een niet-vervallen diagnose kan als hoofddiagnose worden aangewezen; vervalt de diagnose, dan wordt de lopende aanwijzing beëindigd (`geldig_tot` gezet).
+
+### 2.6 HONOS_AFNAME
+
+**Doel:** één afname van de HoNOS+-vragenlijst (19 items, score 0–4) voor een zorgepisode. Generiek meetinstrument-patroon; HoNOS+ is de eerste invulling (onderzoek-standaarden §6.4).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| id | uuid | ja | |
+| zorgepisode_id | uuid → ZORGEPISODE | ja | |
+| instrument | tekst | ja | vast `HoNOS+` met versie, t.b.v. toekomstige instrumentwissel |
+| afgenomen_op | datum | ja | |
+| afgenomen_door | uuid → MEDEWERKER | ja | |
+| toelichting | tekst | nee | |
+| deleted_at | timestamp | nee | |
+
+**Uniciteit:** geen beperking op aantal afnames per episode (herhaalde metingen zijn de bedoeling).
+
+### 2.7 HONOS_ITEMSCORE
+
+**Doel:** de score per HoNOS+-item van één afname, als gestructureerde data (geen JSON-blob — spelregel §3.1 #1 en AI-voorbereiding: scores moeten filterbaar/regelbaar zijn).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| id | uuid | ja | |
+| honos_afname_id | uuid → HONOS_AFNAME | ja | |
+| honos_item_id | uuid → waardelijst `honos_item` | ja | |
+| score | geheel getal | ja | 0–4, of 9 = "onbekend/niet van toepassing" (HoNOS-conventie); check-constraint |
+
+**Uniciteit:** `(honos_afname_id, honos_item_id)` uniek.
+
+### 2.8 ZORGVRAAGTYPERING
+
+**Doel:** het aanpalende record naast de diagnose (ZPM-verplichting g-ggz/fz): op basis van een HoNOS+-afname adviseert de NZa-tool een zorgvraagtype, de behandelaar kiest. Advies ≠ keuze: twee vastgelegde feiten met eigen herkomst — schoolvoorbeeld van het provenance-patroon (algoritme-advies vs. menselijke keuze, spelregel §3.1 #2).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| id | uuid | ja | |
+| zorgepisode_id | uuid → ZORGEPISODE | ja | |
+| honos_afname_id | uuid → HONOS_AFNAME | ja | de afname waarop advies en keuze rusten |
+| soort | waardelijst `zorgvraagtypering_soort` | ja | `initieel` / `hertypering` |
+| algoritmeversie | tekst | ja | versie van de NZa-zorgvraagtyperingstool (reproduceerbaarheid) |
+| gekozen_zorgvraagtype_id | uuid → waardelijst `zorgvraagtype` | ja | de keuze van de behandelaar (komt op de factuur) |
+| gekozen_door | uuid → MEDEWERKER | ja | |
+| gekozen_op | datum | ja | basis voor de jaarlijkse-hertypering-nudge |
+| afwijking_toelichting | tekst | nee | aanbevolen in te vullen als de keuze afwijkt van het advies |
+| deleted_at | timestamp | nee | |
+
+**Uniciteit:** maximaal één typering per HoNOS-afname (`honos_afname_id` uniek); meerdere typeringen per episode door de tijd (hertypering).
+
+### 2.9 ZORGVRAAGTYPE_ADVIES
+
+**Doel:** de door het algoritme geadviseerde zorgvraagtypes (de tool kan meerdere kandidaten met rangorde geven) — apart van de keuze vastgelegd.
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| id | uuid | ja | |
+| zorgvraagtypering_id | uuid → ZORGVRAAGTYPERING | ja | |
+| zorgvraagtype_id | uuid → waardelijst `zorgvraagtype` | ja | |
+| rangorde | geheel getal | ja | 1 = eerste advies |
+
+**Uniciteit:** `(zorgvraagtypering_id, zorgvraagtype_id)` uniek en `(zorgvraagtypering_id, rangorde)` uniek.
+
+## 3. Relaties met cardinaliteit
+
+| Relatie | Cardinaliteit | Toelichting |
+|---|---|---|
+| ZORGEPISODE — DIAGNOSE | 1 — 0..n | besluit §5.4 #2; een episode zonder diagnose kan (vroege fase) |
+| INTAKE — DIAGNOSE | 0..1 — 0..n | herkomst, optioneel (besluit §5.4 #2); intake uit deelgebied §5.2 |
+| DSM_CLASSIFICATIE — DIAGNOSE | 1 — 0..n | bronregistratie |
+| DSM_CLASSIFICATIE — DSM_HOOFDGROEP | n — 1 | afleiding factuur/wachttijden |
+| DSM_CLASSIFICATIE — ICD-10-code (via DSM_ICD10_MAPPING) | m — n, per lijstversie | mappingtabel als entiteit (besluit §5.4 #1) |
+| ZORGEPISODE — HOOFDDIAGNOSE_AANWIJZING | 1 — 0..n | max 1 met overlappende geldigheid (constraint) |
+| DIAGNOSE — HOOFDDIAGNOSE_AANWIJZING | 1 — 0..n | dezelfde diagnose kan meerdere periodes hoofddiagnose zijn |
+| DIAGNOSE — DIAGNOSE (`vervangen_door`) | 0..1 — 0..1 | correctieketen na vervallen |
+| ZORGEPISODE — HONOS_AFNAME | 1 — 0..n | |
+| HONOS_AFNAME — HONOS_ITEMSCORE | 1 — 19 (bij volledige afname) | itemlijst uit waardelijst |
+| HONOS_AFNAME — ZORGVRAAGTYPERING | 1 — 0..1 | niet elke afname leidt tot (her)typering |
+| ZORGEPISODE — ZORGVRAAGTYPERING | 1 — 0..n | initieel + hertyperingen |
+| ZORGVRAAGTYPERING — ZORGVRAAGTYPE_ADVIES | 1 — 0..n | algoritme-advies |
+| MEDEWERKER — DIAGNOSE / HONOS_AFNAME / ZORGVRAAGTYPERING / HOOFDDIAGNOSE_AANWIJZING | 1 — 0..n | registrerende/kiezende medewerker; rolvereisten volgen in de rollenronde |
+| BEHANDELPLAN — DIAGNOSE | m — n | "het plan adresseert diagnose X" (§5.5 feitzin 3); relatie wordt in deelgebied behandelplan uitgewerkt, hier alleen benoemd |
+
+## 4. Waardelijsten
+
+Conform spelregel §3.1 #1 als referentietabellen, met per rij optioneel `externe_code`, `codesysteem_uri` en `geldig_van`/`geldig_tot` (patroon uit onderzoek-standaarden §8).
+
+| Waardelijst | Startwaarden | Extra attributen |
+|---|---|---|
+| `diagnose_verificatiestatus` | `werkdiagnose`, `definitief`, `vervallen` | — |
+| `diagnose_klinische_status` | `actief`, `in_remissie`, `hersteld` | — (prototype-waarde `inactive` vervalt, zie open besluit 4) |
+| `diagnose_ernst` | `licht`, `matig`, `ernstig` | — |
+| `diagnose_vervalreden` | `foutregistratie`, `diagnose_herzien`, `ontkracht_na_onderzoek`, `overig` | `vervanger_verplicht` (ja/nee): bij `diagnose_herzien` is een vervangend record verplicht — zelfde patroon als `agb_verplicht` |
+| `wijze_van_vaststellen` | `klinisch_onderzoek`, `gestructureerd_interview`, `psychodiagnostisch_onderzoek`, `heteroanamnese`, `overgenomen_van_verwijzer`, `overig` | — (zib Diagnose; "overig" met specificatieveld, zib-patroon "anders") |
+| `honos_item` | de 19 HoNOS+-items: 1–12 (klassieke HoNOS), 13, A–E, Q | `volgnummer`, `omschrijving`; instrumentversie via geldigheidsperiode |
+| `zorgvraagtype` | NZa-zorgvraagtypes ggz (import uit NZa-codetabel, versioneerd) | `externe_code` (NZa), `geldig_van`/`geldig_tot` |
+| `zorgvraagtypering_soort` | `initieel`, `hertypering` | — |
+
+`DSM_CLASSIFICATIE`, `DSM_HOOFDGROEP` en `DSM_ICD10_MAPPING` zijn geen waardelijsten maar **geïmporteerde, versioneerde referentiedata** (zelfde importmechanisme als NZa-prestatietabellen; onderzoek-standaarden §8, rij "Referentiedata-import").
+
+## 5. Statusmachine
+
+Twee onafhankelijke assen op DIAGNOSE (bevestigt de voorlopige modellering uit discovery §5.4 "nog open" — Nedap `certainty` + status en FHIR `verificationStatus` + `clinicalStatus` tonen dat dit staande praktijk is). Hoofddiagnose-zijn is bewust **geen** status maar een tijdgebonden aanwijzing (entiteit 2.5).
+
+### 5.1 Verificatiestatus
+
+| Van | Naar | Voorwaarde | Wie mag zetten |
+|---|---|---|---|
+| — | `werkdiagnose` | registratie | behandelaar (rollenronde) |
+| `werkdiagnose` | `definitief` | — | regiebehandelaar, indicerende rol (LKS 4.0: verantwoordelijk voor het (doen) vaststellen van de diagnose) — precieze rolafdwinging in de **rollenronde**; tot die tijd wordt `definitief_door` wel vastgelegd |
+| `werkdiagnose` | `vervallen` | vervalreden verplicht | behandelaar (rollenronde) |
+| `definitief` | `vervallen` | vervalreden verplicht; bij reden `diagnose_herzien` ook `vervangen_door_diagnose_id` | regiebehandelaar (rollenronde) |
+
+Geen overgang `definitief` → `werkdiagnose`: een definitieve diagnose wordt niet "teruggezet" maar vervalt en krijgt een opvolger (correctieketen). Na `definitief` is de DSM-classificatie onveranderbaar; de klinische status en toelichting blijven muteerbaar (met audit).
+
+### 5.2 Klinische status
+
+| Van | Naar | Wie mag zetten |
+|---|---|---|
+| `actief` | `in_remissie` | behandelaar (rollenronde) |
+| `in_remissie` | `actief` | behandelaar (terugval) |
+| `actief` / `in_remissie` | `hersteld` | behandelaar |
+| `hersteld` | `actief` | behandelaar (heropleving binnen dezelfde episode); bij een nieuwe episode hoort een nieuw diagnoserecord |
+
+De klinische status is alleen betekenisvol op niet-vervallen diagnoses; bij `vervallen` wordt de klinische as bevroren.
+
+### 5.3 Toegestane overgangen als data
+
+Conform spelregel §3.1 #9 worden de overgangen vastgelegd in een referentietabel `status_overgang` (entiteit, as, van, naar, rol-eis) — dezelfde structuur die de aanmelding-statussen (§5.1 besluit 5) gaan gebruiken. De rol-kolom blijft leeg tot de rollenronde.
+
+## 6. ECD/TIP-eigenaarschap en events richting TIP
+
+**Eigenaarschap:** alle entiteiten in dit deelgebied zijn **leidend in het ECD** (klinische feiten, bron van waarheid — §3.3). TIP houdt geen eigen diagnose-administratie; TIP maakt doelgebonden snapshots van de data waarop een intentie/nudge rust (afstemming Joshua §3.3 #2) en mag als longitudinaal informatie-element o.a. hoofddiagnose en zorgvraagtype door de tijd bijhouden (§3.3 #3).
+
+**Events van ECD naar TIP** (zelfde mutatie-eventmechanisme als her-embedding, §3.2/§3.3 #4; payload met record-UUID + content-hash, nooit BSN):
+
+| Event | Trigger | Waarvoor TIP het nodig heeft |
+|---|---|---|
+| `diagnose_geregistreerd` | nieuw DIAGNOSE-record | bestaat al als regeltrigger in de ZPM-regelengine (`diagnose_geregistreerd`); start nudges "zorgvraagtypering ontbreekt", "behandelplan ontbreekt" |
+| `diagnose_definitief_vastgesteld` | verificatiestatus → `definitief` | HoNOS+ moet ná de DSM-diagnose worden ingevuld; factuur-/opt-in-checks |
+| `diagnose_vervallen` | verificatiestatus → `vervallen` | koppelafspraak §3.3 #4: TIP-kopieën en lopende nudges op basis van dit record verouderen |
+| `hoofddiagnose_gewijzigd` | nieuwe of beëindigde HOOFDDIAGNOSE_AANWIJZING | wachttijd-uitsplitsing per hoofddiagnosegroep; declaratiecontext |
+| `diagnose_klinische_status_gewijzigd` | klinische status-overgang | trendbewaking, evaluatie-nudges |
+| `honos_afname_geregistreerd` | nieuw HONOS_AFNAME-record | longitudinale IE's (trend itemscores) |
+| `zorgvraagtypering_vastgesteld` | nieuw ZORGVRAAGTYPERING-record | reset van de jaarlijkse hertyperings-termijn |
+| `diagnose_gewijzigd` (generiek mutatie-event) | content-hash wijzigt | her-embedding + verversen TIP-snapshots |
+
+**Kandidaat-nudges (TIP/Nudge Engine, geen schema-eisen):** hertypering ouder dan 12 maanden (`waarschuwing`; NZa: minimaal jaarlijks); definitieve diagnose zonder zorgvraagtypering in g-ggz (`waarschuwing`); werkdiagnose ouder dan X weken zonder definitieve vaststelling (`signaal`); diagnose zonder afgeleide ICD-10-code doordat de mappingversie geen resultaat geeft (`signaal`); DSM-hoofdgroep op factuur zonder opt-in-toestemming (`blokkade` — declaratieronde).
+
+## 7. Open besluitpunten voor Colin
+
+1. **Hoofddiagnose: per episode of per moment in de tijd?** — *Advies: per moment in de tijd*, gemodelleerd als HOOFDDIAGNOSE_AANWIJZING met geldigheidsperiode en een exclusion-constraint (geen overlap per episode). Zo is spelregel §3.1 #7 een echte database-constraint, kan de hoofddiagnose tijdens de behandeling verschuiven (klinische realiteit; prototype ondersteunde dit niet) én blijft reproduceerbaar welke hoofddiagnose gold op elk declaratie-/rapportagemoment (NZa-wachttijden per hoofddiagnosegroep, DSM-hoofdgroep op factuur). "Max één per episode ooit" zou herziening onmogelijk maken zonder geschiedenis te wissen.
+2. **DSM-licentie en actuele mappingversie.** Gebruik van DSM-5-TR-omschrijvingen in een commercieel ECD vereist vermoedelijk een licentie bij Boom/APA; de WHO-FIC-codelijst is alleen vrijgegeven voor NZa-doeleinden, en de versie van 15-12-2023 is per 1-1-2026 vervallen. — *Advies: vóór de bouw van de diagnosemodule uitzoeken (licentie + geldige opvolgerversie); het model is er niet van afhankelijk — referentietabellen blijven identiek, alleen de importbron/licentievorm verschilt.*
+3. **Correctiepatroon na definitieve vaststelling.** — *Advies: vervallen + nieuw record met `vervangen_door`-keten* (geen mutatie van de DSM-code op een definitief record). Past bij de append-only-geest (§3.1 #3), het Nedap-`immutable`-patroon en de WGBO-correctiesystematiek; de keten houdt herleidbaar wat wanneer gold.
+4. **Startlijst klinische status bevestigen: `actief` / `in_remissie` / `hersteld`.** — *Advies: prototype-waarde `inactive` laten vervallen* — hij overlapt semantisch met zowel remissie als hersteld en niemand kan uitleggen wanneer welke geldt (het labels-vs-codes-probleem in het klein). Terugval binnen de episode = `hersteld` → `actief`; een nieuwe zorgvraag na afsluiting = nieuwe episode met nieuw diagnoserecord.
+5. **Ernst-veld behouden naast de DSM-classificatie?** DSM-5-TR codeert ernst bij sommige stoornissen ín de classificatie (de matige depressieve episode uit de feitzin), bij andere niet. — *Advies: behouden als optioneel veld*; waar de classificatie de ernst al draagt is het veld afleidbaar/redundant — eventueel later een consistentie-nudge ("ernst wijkt af van classificatie").
+6. **Zorgvraagtypering ook voor gb-ggz?** De HoNOS+-verplichting geldt g-ggz/fz; de basis-ggz kent een eigen profiel op de factuur. — *Advies: de entiteiten generiek houden (afname + typering) en het gb-ggz-profiel pas in de declaratieronde toevoegen*; niets in dit model blokkeert dat.
+7. **Privacyverklaring/opt-in als generieke TOESTEMMING-entiteit.** Toestemmingsfeiten duiken op drie plekken op (DSM-hoofdgroep op factuur, huisarts-correspondentie verwijstype 04, privacyverklaring zorgvraagtypering). — *Advies: één generieke TOESTEMMING-entiteit in een latere ronde (zoals onderzoek-standaarden §9.5 voorstelt); tot die tijd dit deelgebied niet belasten met een eigen toestemmingsveld — wel feitzin 15 als geregistreerd feit erkennen.*
+8. **Wie mag een diagnose definitief vaststellen** blijft, conform discovery §5.4, expliciet voor de **rollenronde** (LKS: regiebehandelaar, indicerende rol; in settings 3–8 moet bovendien de bij diagnostiek betrokken discipline in het dossier worden vastgelegd — dat laatste veld toevoegen in de rollenronde). Geen besluit nodig nu; genoemd zodat het niet wegvalt.
+
+## 8. Bronverwijzingen
+
+- **Discovery:** `datamodel-discovery.md` §3.1 (spelregels #1, #2, #4, #5, #7, #9), §3.2 (structuur + tekst, content-hash), §3.3 (TIP-grensvlak, afstemming Joshua), §5.1 #9 (ZORGEPISODE), §5.4 (besluiten DSM-primair + episode-eigenaarschap; open vragen verificatiestatus, hoofddiagnose, rollen).
+- **Onderzoek proces** (`scratchpad/onderzoek-proces.md`): §5 (regiebehandelaar indicerende rol, LKS 4.0), §6.2 (DSM-5-classificatie verplicht voor alle ggz; betrokken discipline als dossiereis), §7 (zorgvraagtypering HoNOS+ na DSM-diagnose, hertypering minimaal jaarlijks, privacyverklaring als registratiefeit), §10.1 rij 8–9.
+- **Onderzoek leveranciers** (`../onderzoek/onderzoek-leveranciers.md`): §2.3 (DiagnoseToekenning met `primair`-boolean en NZa-codetabel met ICD-10-mapping als data), §2.4 (Nedap `certainty` + status = twee assen; `immutable` na vaststelling; waarschuwing GAF/DSM-IV-erfgoed), §7.5.
+- **Onderzoek standaarden** (`../onderzoek/onderzoek-standaarden.md`): §2.2 (zib Diagnose v2.0: code-systeem-display-drieluik, steller, datum, wijze van vaststellen; DSM-5 erkend codesysteem), §3 (FHIR Condition `clinicalStatus`/`verificationStatus`), §5 (WHO-FIC-codelijst, m:n-mapping, lijstversie op het record, DSM-hoofdgroep, opt-in, licentierisico), §6.4 (HoNOS+ 19 items 0–4, zorgvraagtyperingstool met algoritmeversie, advies ≠ keuze), §8 (checklist DIAGNOSE-rij, referentiedata-importpatroon), §9 (open punten 1, 2, 5, 6).
+- **Onderzoek rapportage** (`../onderzoek/onderzoek-rapportage.md`): §1.1 (WGBO-correctiesystematiek: feitelijke onjuistheden vs. klinische conclusies — onderbouwing correctieketen i.p.v. stille mutatie).
+- **Standaarden/regelgeving:** LKS GGZ 4.0 (zorginzicht.nl); Codelijst DSM-5(-TR) met ICD-10-afleidingen (whofic.nl); NZa V&A zorgvraagtypering en Handleiding zorgvraagtypering (zorgprestatiemodel.nl); zib Diagnose v2.0 (zibs.nl); FHIR nl-core Condition (Nictiz R4 zib2020).

docs/datamodel/deelmodellen/model-intake.md

@@ -0,0 +1,224 @@
+# Datamodelvoorstel — Deelgebied Intake
+
+**Status:** herziening nodig — deels achterhaald door `../besluiten/besluitenlog-datamodel-2026-07-18.md`
+**Datum:** 18 juli 2026
+**Modelleur:** Claude (deelgebied "Intake", discovery §5.2)
+**Scope:** INTAKE, CONTACTMOMENT, KINDCHECK, intake-uitkomst, relatie intake–zorgepisode
+**Kader:** bouwt voort op de besluiten in `datamodel-discovery.md` (§3.1 spelregels, §5.1 #9 ZORGEPISODE, §5.2 besluiten 1–4). Geen enkel besluit is teruggedraaid.
+
+> **Let op:** de intake is nader besloten als één onderzoekstraject per samenhangende zorgvraag, met meerdere contacten, onderzoeken en disciplines. Interne overgangen vormen geen nieuwe intake. De precieze relatie met AANMELDINGSTRAJECT en ZORGEPISODE volgt uit de nog uit te werken formele acceptatie.
+
+Standaardvelden op elk record (spelregels §3.1, hier niet per entiteit herhaald): `id` (UUID, stabiel), `created_at`/`created_by`, `updated_at`/`updated_by`, `deleted_at` (soft delete), append-only audit met hash-chaining.
+
+---
+
+## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.2)
+
+Gewijzigde zinnen vervangen de genoemde discovery-zin; nieuwe zinnen komen erbij.
+
+1. **(gewijzigd, §5.2 #4)** *Voor de zorgepisode van Jan de Vries is op 20 juli 2026 een intake gestart op afdeling Volwassenen, met aanleiding "regulier".* — De intake hangt aan de ZORGEPISODE (besluit §5.2 #1), niet meer "op basis van de aanmelding"; de aanmelding is via de episode bereikbaar.
+2. **(nieuw)** *De intake voor de zorgepisode van Jan de Vries is op 18 juli 2026 aangemaakt met status "gepland".* — Er zit tijd tussen het besluit tot intake en het eerste gesprek (aanmeldwachttijd, NZa: wachttijd loopt tot het moment dat de cliënt voor de intake terecht kan).
+3. **(gewijzigd, §5.2 #5)** *De intake heeft status "bezig" sinds 22 juli 2026.*
+4. **(gewijzigd, §5.2 #6)** *Bij de intake is een contactmoment van type "intakegesprek" geregistreerd op 22 juli 2026, uitgevoerd door psycholoog M. de Boer, met toelichting "eerste gesprek, anamnese afgenomen".*
+5. **(nieuw)** *Het contactmoment van 22 juli 2026 had een geplande duur van 60 minuten.* — Optioneel veld; voorbereiding op ZPM-consultregistratie ("planning = realisatie"), uitwerking in de agenda-/declaratieronde.
+6. **(gewijzigd, §5.2 #7)** *De kindcheck voor de intake is op 22 juli 2026 uitgevoerd door M. de Boer: cliënt is verantwoordelijk voor minderjarige kinderen: nee.* — Uitvoerder en datum zijn verplicht; de vlag is verbreed van "thuiswonend" naar "verantwoordelijk voor" (kindcheck-norm KNMG-meldcode: ook co-ouderschap en andere zorgrelaties tellen).
+7. **(nieuw)** *Bij de kindcheck van cliënt X is vastgelegd: verantwoordelijk voor 2 minderjarige kinderen (leeftijden "4 en 7"); zorgen over veiligheid: ja, met toelichting "moeder oververmoeid, geen netwerk"; actie ondernomen: ja, met toelichting "adviesvraag Veilig Thuis, 23 juli".* — Bij "ja" op een vlag is de bijbehorende toelichting verplicht.
+8. **(gewijzigd, §5.2 #8)** *De intake is op 30 juli 2026 afgerond met uitkomst "in zorg", met geadviseerd zorgprogramma "Algemeen GGZ".* — Uitkomst is verplicht bij afronden; zorgprogramma-advies is optioneel en komt uit de waardelijst ZORGPROGRAMMA (besluit §5.2 #2).
+9. **(nieuw)** *De intake van cliënt Y is op 30 juli 2026 afgerond met uitkomst "terugverwijzing", met toelichting "advies aan huisarts: begeleiding POH-GGZ".* — Terugverwijzing naar de verwijzer met advies is in het LKS een aparte uitkomst naast doorverwijzing naar een andere aanbieder.
+10. **(nieuw)** *De intake van cliënt Z is op 25 juli 2026 afgebroken met reden "cliënt trekt zich terug".* — Afbreken is een status met reden, geen uitkomst.
+11. **(nieuw)** *Binnen de lopende zorgepisode van Jan de Vries is op 1 oktober 2026 een tweede intake gestart met aanleiding "intern", op afdeling Ouderen.* — Meerdere intakes per episode (besluit §5.2 #1).
+12. **(nieuw)** *Voor de zorgepisode van cliënt W is op 2 augustus 2026 een intake met aanleiding "crisis" gestart, zonder voorafgaande screening.* — Screening vóór intake is een nudge, geen harde eis (besluit §5.2 #4).
+13. **(nieuw)** *De afgeronde intake van 30 juli 2026 is op 15 augustus 2026 heropend en heeft weer status "bezig".* — Zelfde flexibiliteitsprincipe als de aanmelding-status (besluit §5.1 #5); heropening laat een audit-event achter.
+
+---
+
+## 2. Entiteiten
+
+### 2.1 INTAKE
+
+**Doel:** de intake als afgebakend onderzoeks-/kennismakingstraject binnen een zorgepisode: van gepland eerste contact tot een uitkomstbesluit. Eén episode kan meerdere intakes hebben (regulier, intern, crisis).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `zorgepisode_id` | UUID → ZORGEPISODE | ja | eigenaar van de intake (besluit §5.2 #1) |
+| `aanleiding_id` | ref → waardelijst `intake_aanleiding` | ja | regulier / intern / crisis |
+| `afdeling_id` | ref → waardelijst `afdeling` | ja | organisatorische eenheid (besluit §5.2 #2) |
+| `status` | ref → waardelijst `intake_status` | ja | zie statusmachine (§5); default `gepland` |
+| `startdatum` | date | ja | datum waarop de intake start (gepland of feitelijk) |
+| `einddatum` | date | nee* | *verplicht zodra status `afgerond` of `afgebroken` (check-constraint) |
+| `uitkomst_id` | ref → waardelijst `intake_uitkomst` | nee* | *verplicht bij status `afgerond`, leeg bij elke andere status (check-constraint, spelregel §3.1 #7) |
+| `uitkomst_toelichting` | text | nee | vrije toelichting bij de uitkomst (bijv. advies aan verwijzer) |
+| `geadviseerd_zorgprogramma_id` | ref → waardelijst `zorgprogramma` | nee | inhoudelijk advies bij uitkomst `in_zorg` |
+| `doorverwijzing_bestemming` | text | nee | bij uitkomst `doorverwijzing`/`terugverwijzing`: waarheen; in de correspondentieronde te vervangen door FK naar PRAKTIJK_INSTELLING |
+| `afbreekreden_id` | ref → waardelijst `intake_afbreekreden` | nee* | *verplicht bij status `afgebroken`, anders leeg |
+
+**Uniciteitsregels:**
+- Geen natuurlijke sleutel; identiteit via UUID.
+- "Max één lopende intake (status `gepland`/`bezig`) per episode" wordt een **aan/uit-zetbare bedrijfsregel**, geen schemabeperking — zelfde patroon als parallelle aanmeldingen (besluit §5.0 #5). Een crisis-intake kan naast een lopende reguliere intake nodig zijn.
+- Check-constraints: (`status = afgerond` ⇔ `uitkomst_id` gevuld ∧ `einddatum` gevuld); (`status = afgebroken` ⇔ `afbreekreden_id` gevuld ∧ `einddatum` gevuld).
+
+**Bewust nog niet gemodelleerd (rollenronde):** wie de intake verricht, wie indiceert, wie regiebehandelaar wordt, het centrale aanspreekpunt tussen intake en start behandeling en de crisis-/waarnemingsafspraken (LKS 4.0-dossiereisen). Deze landen in de REGIEBEHANDELAAR_TOEWIJZING-structuur van de rollenronde (onderzoek-proces §10.3, verrijking 7 en 11); het intakemodel hoeft daarvoor niet te wijzigen omdat die toewijzingen aan de episode/intake refereren, niet andersom.
+
+### 2.2 CONTACTMOMENT
+
+**Doel:** een feitelijk contact (gesprek, telefonisch contact, huisbezoek, onderzoek) dat in het kader van een intake heeft plaatsgevonden. Klinisch feit; de declarabele consultregistratie (ZPM) is een latere, aparte structuur die hiernaar kan verwijzen (onderzoek-rapportage §1.5: rapportage ≠ consultregistratie).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `intake_id` | UUID → INTAKE | ja | in deze ronde hangt elk contactmoment aan een intake; generalisatie (contactmoment bij behandeling/agenda) volgt in de agenda-ronde met een eigen besluit |
+| `type_id` | ref → waardelijst `contactmoment_type` | ja | intakegesprek, telefonisch contact, ... |
+| `datum_tijd` | timestamp | ja | wanneer het contact plaatsvond |
+| `uitgevoerd_door` | UUID → MEDEWERKER | ja | uitvoerder; MEDEWERKER wordt in de rollenronde uitgewerkt, de FK ligt hier al vast |
+| `toelichting` | text | nee | vrije tekst |
+| `geplande_duur_minuten` | integer | nee | ZPM-voorbereiding (prestatiecode-as "duur"); type diagnostiek/behandeling, beroepscode en setting volgen in de agenda-/declaratieronde |
+
+**Uniciteitsregels:** geen — meerdere contactmomenten van hetzelfde type op dezelfde dag zijn legitiem (twee telefonische contacten). Identiteit via UUID.
+
+### 2.3 KINDCHECK
+
+**Doel:** de wettelijk verankerde kindcheck (Wet verplichte meldcode huiselijk geweld en kindermishandeling; KNMG-meldcode) bij de intake van een volwassen cliënt: zijn er minderjarigen die van de cliënt afhankelijk zijn, zijn er zorgen over hun veiligheid, en is daarop actie ondernomen. De prototype-structuur (drie ja/nee-vlaggen + tekst) blijft de kern — bevestigd als goed patroon — met drie verbeteringen: (a) vlag 1 verbreed van "thuiswonend" naar "verantwoordelijk voor minderjarigen", (b) uitvoerder + datum verplicht (provenance), (c) toelichting verplicht zodra een vlag op "ja" staat (conditionele check-constraint, spelregel §3.1 #7 — regel in het model, niet alleen in de UI).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `intake_id` | UUID → INTAKE | ja | max één kindcheck per intake |
+| `uitgevoerd_op` | date | ja | |
+| `uitgevoerd_door` | UUID → MEDEWERKER | ja | |
+| `verantwoordelijk_voor_minderjarigen` | boolean | ja | vlag 1 (was: "thuiswonende kinderen") |
+| `aantal_kinderen` | integer | nee | alleen zinvol bij vlag 1 = ja |
+| `leeftijden` | text | nee | vrije tekst ("4 en 7"); bewust géén kindrecords — dataminimalisatie, de kinderen zijn geen cliënt |
+| `zorgen_over_veiligheid` | boolean | ja | vlag 2 |
+| `zorgen_toelichting` | text | nee* | *verplicht indien vlag 2 = ja (check-constraint) |
+| `actie_ondernomen` | boolean | ja | vlag 3 (bijv. adviesvraag Veilig Thuis, stap in de meldcode) |
+| `actie_toelichting` | text | nee* | *verplicht indien vlag 3 = ja (check-constraint) |
+| `notitie` | text | nee | algemene vrije tekst |
+
+**Uniciteitsregels:** unieke constraint op `intake_id` (1-op-0..1). Herziening van een kindcheck = wijziging met audit-trail, geen tweede record; bij een nieuwe intake in dezelfde episode hoort een nieuwe kindcheck (situatie kan veranderd zijn).
+
+**Wat bewust níet in het ECD-schema zit:** het meldcode-stappenplan (5 stappen, termijnen, Veilig Thuis-procesgang) is proces-state en beslislogica — TIP-terrein (§3.3). Het ECD legt de klinische feiten vast (de drie vlaggen + toelichtingen); TIP bewaakt het vervolg via nudges (zie §6).
+
+---
+
+## 3. Relaties met cardinaliteit
+
+| Relatie | Cardinaliteit | Toelichting |
+|---|---|---|
+| ZORGEPISODE — INTAKE | 1 — 0..* | besluit §5.2 #1; een episode kan (nog) geen intake hebben (crisisinstroom in aanmeldfase) en meerdere intakes (regulier + intern + crisis) |
+| AANMELDING — ZORGEPISODE | 1 — 0..1 | context uit §5.1 #9: episode ontstaat bij aanmelding-uitkomst `intake`; afgewezen aanmelding heeft nooit een episode |
+| INTAKE — CONTACTMOMENT | 1 — 0..* | een geplande intake heeft nog geen contactmomenten |
+| INTAKE — KINDCHECK | 1 — 0..1 | 0..1 in het schema; "verplicht vóór afronden" is een nudge (zie §6), geen schema-eis — bij een geplande of afgebroken intake kan hij ontbreken |
+| INTAKE — waardelijst AFDELING | * — 1 | besluit §5.2 #2 |
+| INTAKE — waardelijst ZORGPROGRAMMA | * — 0..1 | advies bij uitkomst `in_zorg` |
+| CONTACTMOMENT — MEDEWERKER | * — 1 | MEDEWERKER volgt in de rollenronde; FK ligt vast |
+| KINDCHECK — MEDEWERKER | * — 1 | idem |
+| DIAGNOSE — INTAKE | * — 0..1 | uit deelgebied diagnose (besluit §5.4 #2): intake is optionele *herkomst* van een diagnose, geen eigenaar |
+| BEHANDELPLAN — INTAKE | * — 0..1 | uit deelgebied behandelplan (feitzin §5.5 #3): "gebaseerd op de intake van ..." |
+| WACHTLIJSTPLAATSING (soort `behandel`) — ZORGEPISODE | * — 1 | §5.3: behandelwachttijd start na de intake; beëindigingsreden "behandeling gestart" — raakt de intake alleen via de episode |
+
+---
+
+## 4. Waardelijsten
+
+Alle waardelijsten volgen het referentietabel-patroon (spelregel §3.1 #1) met per rij: `code`, `omschrijving`, `actief`, optioneel `externe_code` + `codesysteem_uri`, en `geldig_van`/`geldig_tot` (les uit Nedaps NZa-tabellen, onderzoek-leveranciers §2.2/§7.1). Waar zinvol een `overig`-waarde met specificatie-vrij-veld (zib-patroon "anders + SpecificatieAnders", onderzoek-standaarden §2.2).
+
+### 4.1 `intake_aanleiding`
+Startwaarden (bevestiging van besluit §5.2 #1): `regulier`, `intern`, `crisis`.
+Geen extra attribuut nodig. Mogelijk later attribuut `screening_verwacht` (ja/nee) als input voor de nudge "screening vóór eerste intake" — nu niet nodig, de nudge kan op aanleiding-code werken.
+
+### 4.2 `intake_status`
+Startwaarden: `gepland`, `bezig`, `afgerond`, `afgebroken`. Zie §5.
+
+### 4.3 `intake_uitkomst`
+Voorstel (verbetering t.o.v. prototype-drietal; open besluitpunt 1 en 2):
+
+| Code | Omschrijving | Onderbouwing |
+|---|---|---|
+| `in_zorg` | cliënt komt in behandeling bij de instelling | prototype, bevestigd door LKS-fase indicatiestelling |
+| `terugverwijzing` | terug naar de verwijzer/huisarts, met advies voor passend vervolg | **nieuw** — LKS 4.0 §6.1: bij geen passend aanbod terugverwijzen "met advies"; ander feit dan doorverwijzing (andere brief, andere ontvanger) |
+| `doorverwijzing` | door naar een andere (beter passende) zorgaanbieder | prototype, verscherpt: alleen nog externe doorverwijzing; ZPM kent "doorverwijzing tussen GGZ-aanbieders" als erkende route zonder nieuwe verwijzing |
+| `extra_diagnostiek` | intake afgerond, maar het indicatiebesluit vergt aanvullend (psychodiagnostisch/somatisch) onderzoek | prototype, behouden — praktijk kent dit als reële uitkomst (onderzoek-proces §3, stap 4) |
+
+`afgewezen` is bewust géén intake-uitkomst: afwijzen gebeurt bij de aanmelding (uitkomst `afgewezen`, besluit §5.1 #5); wie een intake bereikt wordt niet meer "afgewezen" maar terug- of doorverwezen. Staken door de cliënt is geen uitkomst maar status `afgebroken` + reden.
+
+### 4.4 `intake_afbreekreden`
+Startwaarden: `client_trekt_terug`, `geen_contact_meer`, `overleden`, `overig` (+ specificatieveld). Consistent met de beëindigingsredenen-richting van §5.3 (wachtlijst).
+
+### 4.5 `contactmoment_type`
+Startwaarden (prototype-lijst bevestigd, één toevoeging): `intakegesprek`, `aanvullend_onderzoek`, `telefonisch_contact`, `huisbezoek`, `beeldcontact` (nieuw — beeldbellen is in de GGZ-praktijk een standaard contactvorm en ZPM-relevant via zorglabels digitale zorg), `overig` (+ specificatieveld).
+
+### 4.6 Bestaande lijsten uit andere deelgebieden (hier alleen gebruikt)
+`afdeling` (instellingsconfigureerbaar, besluit §5.2 #2), `zorgprogramma` (idem).
+
+---
+
+## 5. Statusmachine INTAKE
+
+Statussen: `gepland` → `bezig` → `afgerond` / `afgebroken`.
+
+| Van | Naar | Betekenis / voorwaarde |
+|---|---|---|
+| — | `gepland` | intake aangemaakt (besluit tot intake genomen, eerste gesprek nog niet gevoerd) |
+| `gepland` | `bezig` | eerste contactmoment geregistreerd (systeemgedreven) of handmatig gezet |
+| `gepland` | `afgebroken` | reden verplicht (bijv. cliënt trekt zich terug vóór het eerste gesprek) |
+| `bezig` | `afgerond` | uitkomst + einddatum verplicht (check-constraint) |
+| `bezig` | `afgebroken` | reden + einddatum verplicht |
+| `afgerond` | `bezig` | heropening; uitkomst en einddatum worden geleegd, audit-event verplicht — zelfde flexibiliteit als aanmelding-status (besluit §5.1 #5) |
+| `afgebroken` | `bezig` | heropening (cliënt meldt zich alsnog); reden wordt geleegd, audit-event verplicht |
+
+Niet toegestaan: `gepland` → `afgerond` (afronden zonder enig geregistreerd contact is klinisch onzinnig; wil men toch, dan eerst een contactmoment registreren), `afgerond` ↔ `afgebroken` rechtstreeks.
+
+**Wie mag welke overgang zetten: rollenronde.** Het prototype kent geen rollen; de discovery (§5.2 open vraag "wie mag een intake afronden") verwijst dit expliciet naar de rollenronde. De statusmachine zelf komt conform spelregel §3.1 #9 in een referentietabel (`status_overgang`: van, naar, actief), zodat de rol-kolom daar later aan toegevoegd wordt zonder schemawijziging van INTAKE.
+
+De status van het prototype (`bezig`/`afgerond`) blijft een subset; `gepland` en `afgebroken` zijn toevoegingen (open besluitpunt 4).
+
+---
+
+## 6. ECD/TIP-eigenaarschap en events richting TIP
+
+**Eigenaarschap:** INTAKE, CONTACTMOMENT en KINDCHECK zijn klinische feiten — **leidend in het ECD** (§3.3). TIP houdt geen kopie van deze entiteiten behalve doelgebonden snapshots bij intenties/nudges (afstemming Joshua, §3.3 #2) en eventuele longitudinale IE's (bijv. kindcheck-vlaggen voor trendbewaking, §3.3 #3). Mutatie-events (create/update/soft delete, met UUID + content-hash) zijn het koppelmechanisme (§3.3 #4). Het BSN komt nooit in events richting TIP (spelregel §3.1 #6).
+
+**Events richting TIP:**
+
+| Event | Payload (kern) | Waarom TIP dit nodig heeft |
+|---|---|---|
+| `intake.aangemaakt` | intake-id, episode-id, aanleiding, afdeling, startdatum | proces-start; nudge "screening ontbreekt bij eerste reguliere intake van de episode" (besluit §5.2 #4); behandelwachttijd-bewaking voorbereiden |
+| `intake.status_gewijzigd` | intake-id, oude/nieuwe status, datum | procesbewaking; heropening detecteren |
+| `intake.contactmoment_geregistreerd` | contactmoment-id, intake-id, type, datum | nudge "intake gepland maar al X dagen geen contact"; NZa-aanmeldwachttijd eindigt bij het eerste intakecontact |
+| `intake.kindcheck_vastgelegd` | kindcheck-id, intake-id, drie vlaggen (géén vrije tekst met persoonsgegevens van derden) | nudges: "zorgen = ja, actie = nee" (meldcode-stap open, urgentie `waarschuwing`); trend/longitudinale IE |
+| `intake.afgerond` | intake-id, uitkomst, einddatum, geadviseerd zorgprogramma | vervolg-nudges: bij `in_zorg` → "behandelplan opstellen", "behandelwachttijd gestart (Treeknorm 10 wkn)", "intakebrief aan verwijzer (toestemming cliënt)"; bij `extra_diagnostiek` → "vervolg binnen X dagen?"; bij `terugverwijzing`/`doorverwijzing` → "brief aan verwijzer/ontvanger" |
+| `intake.afgebroken` | intake-id, reden, einddatum | proces afsluiten, eventueel aanmelding-heropening voorstellen |
+
+**Nudges (protocolregels in TIP, geen schema-eisen):** kindcheck ontbreekt bij afronden intake (`waarschuwing`); zorgen zonder actie (`waarschuwing`, escalatie naar `blokkade` denkbaar bij crisiscontext); screening ontbreekt vóór eerste reguliere intake (`signaal`); geen contactmoment X dagen na plandatum (`signaal`); LKS-aanspreekpunt tussen intake en start behandeling niet vastgelegd (`signaal` — pas actief na de rollenronde).
+
+---
+
+## 7. Open besluitpunten voor Colin
+
+1. **Uitkomst splitsen: `terugverwijzing` naast `doorverwijzing`?** Het prototype kent alleen `doorverwijzing`. Het LKS onderscheidt terugverwijzing naar de huisarts (met advies) van doorverwijzing naar een andere aanbieder — andere ontvanger, andere correspondentieplicht, ander ZPM-verwijstype bij de ontvangende partij. **Advies: splitsen** (twee waarden in de waardelijst; kost niets, voorkomt een vrije-tekst-onderscheid later).
+2. **`extra_diagnostiek` behouden als einduitkomst?** Alternatief: de intake open laten tot alle diagnostiek klaar is. **Advies: behouden.** De praktijk sluit de intakefase administratief af terwijl aanvullend onderzoek loopt; het vervolg is dan óf een nieuw contactmoment binnen een nieuwe (interne) intake, óf de diagnostiekstructuur van een latere ronde. Heropening (`afgerond` → `bezig`) dekt de gevallen waarin het toch één traject blijkt.
+3. **Kindcheck: vierde vlag "cliënt (of partner) zwanger"?** De KNMG-kindcheck rekent zwangerschap expliciet mee (het ongeboren kind telt). **Advies: toevoegen** als optionele boolean `zwangerschap` — kleine toevoeging, wettelijk gedekt gat. (Let op: KNMG-meldcode-detail is algemene kennis, niet uit de vier onderzoeksrapporten — bij twijfel kort verifiëren in de meldcode-tekst.)
+4. **Statussen `gepland` en `afgebroken` toevoegen** naast prototype-`bezig`/`afgerond`. **Advies: ja.** Zonder `gepland` is de aanmeldwachttijd (aanmelding → eerste intakecontact) niet uit het model af te leiden; zonder `afgebroken` wordt staken door de cliënt een oneigenlijke "uitkomst".
+5. **Kinderen als platte velden (`aantal_kinderen` + `leeftijden`-tekst) of als aparte kindrecords?** **Advies: plat houden.** De kinderen zijn geen cliënt; aparte persoonsrecords van derden in het dossier schuren met dataminimalisatie. Wordt een kind zelf cliënt, dan ontstaat een eigen PERSOON via de normale route.
+6. **"Max één lopende intake per episode" als aan/uit-bedrijfsregel — standaard aan of uit?** **Advies: standaard uit** (crisis-intake naast lopende reguliere intake moet kunnen), met een `signaal`-nudge bij een tweede lopende intake.
+7. **Episode-ontstaan bevestigen: pas bij aanmelding-uitkomst `intake`, niet bij `wachtlijst`** (open detail §5.1 #9). Onderzoek-proces §10.3 ondersteunt dit: aanmeldwachttijd hoort bij de AANMELDING, verantwoordelijkheidsoverdracht ligt ná de intake. **Advies: bevestigen zoals al voorgesorteerd** — geen wijziging, alleen het open detail sluiten.
+8. **`beeldcontact` toevoegen aan `contactmoment_type`?** **Advies: ja** — gangbare contactvorm, en ZPM-zorglabels voor digitale zorg (S-labels) vragen er later om. De waardelijst is instellingsconfigureerbaar, dus dit is alleen een startwaarde-keuze.
+9. **Contactmoment nu exclusief aan INTAKE hangen** (deze ronde) en generalisatie naar behandeling/agenda uitstellen tot de agenda-ronde. **Advies: akkoord gaan met deze scope-afbakening**; de agenda-ronde beslist of CONTACTMOMENT opgaat in een generieke consult-/afspraakstructuur of ernaast blijft bestaan (ZPM: planning ≠ geleverde prestatie, onderzoek-leveranciers §2.8).
+
+---
+
+## 8. Bronverwijzingen
+
+| Onderwerp | Bron |
+|---|---|
+| Intake aan zorgepisode, meerdere intakes, aanleiding-waardelijst | discovery §5.2 besluit 1; §5.1 #9 |
+| Afdeling/zorgprogramma gescheiden waardelijsten | discovery §5.2 besluit 2 |
+| Screening-vóór-intake als nudge | discovery §5.2 besluit 4 |
+| Prototype kindcheck (3 vlaggen + tekst), intake-afronding via behandeladvies-tab, statussen bezig/afgerond | discovery §5.2 bevindingen; prototype `app/epd/patients/[id]/intakes/[intakeId]/kindcheck/` en `actions.ts` (encounters) |
+| LKS 4.0: intakefase, terugverwijzing met advies, doorverwijzing, aanspreekpunt intake→behandeling, verantwoordelijkheidsoverdracht ná intake | onderzoek-proces §1, §6.1, §10.1 (stappen 7–8) |
+| NZa-wachttijddefinities (aanmeldwachttijd tot intake; behandelwachttijd vanaf intake), Treeknormen 4/10 weken | onderzoek-proces §4.1–4.2 |
+| Episode pas bij intake, aanmeldwachttijd op aanmelding | onderzoek-proces §10.3 (open vragen) |
+| ZPM-consult-assen (beroep, type, duur, setting) als voorbereiding op CONTACTMOMENT-velden | onderzoek-standaarden §6.2, §8 (checklist CONTACTMOMENT) |
+| Waardelijst-rijen met geldigheidsperioden en externe codes; "anders + specificatie"-patroon | onderzoek-leveranciers §2.2, §7.1; onderzoek-standaarden §2.2 (zib BehandelAanwijzing2), §8 |
+| Consultregistratie ≠ klinische rapportage (twee feiten) | onderzoek-rapportage §1.5 |
+| Statusmachine in referentietabel, check-constraints, soft delete, provenance | discovery §3.1 spelregels #1, #3, #4, #7, #9 |
+| ECD/TIP-grensvlak: snapshots, longitudinale IE's, mutatie-events, meldcode-proces als TIP-terrein | discovery §3.3 (afstemming Joshua); onderzoek-standaarden §4 checklist 3 (proces-state → TIP) |
+| Kindcheck-grondslag (Wet verplichte meldcode, KNMG-kindcheck incl. zwangerschap) | algemene domeinkennis, niet in de vier rapporten — expliciet gemarkeerd bij open besluitpunt 3 |

docs/datamodel/deelmodellen/model-rapportage.md

@@ -0,0 +1,366 @@
+# Datamodelvoorstel — Deelgebied Voortgangsrapportage
+
+**Status:** deels herzien — zie `../besluiten/besluitenlog-datamodel-2026-07-18.md` §§6 en 8
+**Datum:** 18 juli 2026
+**Modelleur:** Claude (deelgebied rapportage & overdracht)
+**Kader:** bouwt voort op `datamodel-discovery.md` (spelregels §3.1, AI-voorbereiding §3.2, TIP-grensvlak §3.3, besluiten §5). Geen enkel genomen besluit wordt teruggedraaid. Onderbouwing uit `../onderzoek/onderzoek-rapportage.md`, `onderzoek-proces.md`, `../onderzoek/onderzoek-leveranciers.md`, `../onderzoek/onderzoek-standaarden.md`.
+
+> **Let op:** een klinische rapportage heeft één primaire zorgepisode en kan naar andere context verwijzen zonder daarmee toegang te verlenen. Een MDO-verslag is alleen de verslagcomponent van een afzonderlijke MDO-workflow; hetzelfde geldt voor rapportage bij een formele evaluatie.
+
+---
+
+## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery)
+
+Feitzin 9 uit discovery §5.2 ("Verslag X is geschreven door… / gegenereerd door AI-model Z…") wordt in deze ronde uitgewerkt; alle overige zinnen zijn nieuw. Nummering R1–R24.
+
+**Kernrapportage**
+
+1. *R1 — Voor de zorgepisode van Jan de Vries is op 2 augustus 2026 een rapportage van type "voortgang" vastgelegd door psycholoog M. de Boer.*
+2. *R2 — De rapportage van 2 augustus gaat over een gebeurtenis van 2 augustus 2026, 16:30.*
+3. *R3 — De rapportage van 2 augustus heeft als vrije tekst "…".*
+4. *R4 — De rapportage van 2 augustus is geschreven volgens methodiek "SOEP" en heeft als sectie "Plan" de tekst "…".* (methodiek is optioneel; een rapportage zonder methodiek heeft alleen vrije tekst)
+5. *R5 — De rapportage van 2 augustus hoort bij het contactmoment van 2 augustus 2026.* (optioneel)
+6. *R6 — De rapportage van 2 augustus rapporteert op behandeldoel "weer drie nachten per week doorslapen" met voortgangsindicatie "lichte vooruitgang".* (0..n doelen per rapportage, indicatie optioneel per doelkoppeling)
+7. *R7 — De rapportage van 2 augustus heeft status "definitief" sinds 2 augustus 2026, 17:04.*
+8. *R8 — Rapportageversie 2 van 5 augustus 2026 vervangt rapportageversie 1 van 2 augustus 2026; versie 1 heeft sindsdien status "vervangen".* (correctie ná definitief = nieuwe versie, nooit stille edit)
+
+**Provenance (spelregel 3.1 #2)**
+
+9. *R9 — De rapportage van 2 augustus heeft herkomst "mens" en als auteur medewerker M. de Boer.*
+10. *R10 — Rapportage Y is gegenereerd door AI-model Z (versie …) op basis van bronrecords A (content-hash h1) en B (content-hash h2).*
+11. *R11 — Rapportage Y is op 3 augustus 2026 bevestigd door M. de Boer; pas daarna kreeg hij status "definitief".* (AI-record wordt nooit definitief zonder menselijke bevestiging)
+12. *R12 — De rapportage van 2 augustus heeft content-hash h3.* (wijziging tekst ⇒ nieuwe hash ⇒ her-embedding + mutatie-event, discovery §3.2/§3.3.4)
+
+**Dienst, dagdeel en overdracht**
+
+13. *R13 — Verpleegkundige K. Jansen heeft op 3 augustus 2026 om 06:30 een rapportage van type "verpleegkundig" vastgelegd; deze telt bij dienstdag 2 augustus, dagdeel "nacht".* (grens ligt vast als instellingsconfiguratie, standaard 07:00 — niet hardcoded)
+14. *R14 — De verpleegkundige rapportage van 3 augustus is gemarkeerd voor de overdracht.*
+15. *R15 — Voor de zorgepisode van Jan de Vries is op 3 augustus 2026 een overdrachtssamenvatting over de periode 2–3 augustus gegenereerd door AI-model Z, op basis van de rapportages R13 en R14 (met content-hashes).*
+16. *R16 — De overdrachtssamenvatting van 3 augustus is bevestigd door verpleegkundige K. Jansen.*
+
+**Zichtbaarheid en cliëntrechten (WGBO/Wabvpz)**
+
+17. *R17 — De rapportage van 2 augustus is zichtbaar voor de cliënt in het portaal.* (vlag stuurt portaalweergave; het wettelijk inzagerecht blijft altijd bestaan)
+18. *R18 — Cliënt Jan de Vries heeft op 6 augustus 2026 een eigen verklaring aan zijn dossier laten toevoegen.* (rapportagetype "clientverklaring", auteurtype "cliënt"; opname is verplicht voor de instelling)
+
+**Incident (Wkkgz art. 10 lid 3 — dossierspoor)**
+
+19. *R19 — Op 5 augustus 2026 om 21:15 heeft zich rond cliënt Jan de Vries een incident van categorie "medicatie-incident" voorgedaan.*
+20. *R20 — Van het incident van 5 augustus zijn aard, toedracht en tijdstip in het dossier aangetekend.*
+21. *R21 — Bij het incident van 5 augustus was medewerker K. Jansen direct betrokken.* (0..n betrokkenen per incident)
+
+**Episodeniveau en doelrelatie**
+
+22. *R22 — Het MDO van 1 september 2026 over de zorgepisode van Jan de Vries is vastgelegd in een rapportage van type "MDO-verslag", met betrokken disciplines psychiatrie en verpleegkunde.*
+23. *R23 — De evaluatierapportage van 15 september 2026 hoort bij behandelplan versie 1 (evaluatiemoment week 6).*
+24. *R24 — De rapportage van 2 augustus is een verslag over de intake van 20 juli 2026.* (optionele verwijzing; vervangt de prototype-rapporttypen `intake`/`behandeladvies` — zie open besluitpunt 2)
+
+---
+
+## 2. Entiteiten
+
+### 2.1 RAPPORTAGE (kern)
+
+**Doel:** één klinisch verslag-record in het cliëntdossier: gestructureerde velden + vrije tekst in hetzelfde record (spelregel §3.2), met verplichte provenance (spelregel 3.1 #2). Vervangt de prototype-tabel `reports` inclusief de drie impliciete typologieën (onderzoek-rapportage §8.2).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| id | uuid | ja | stabiel (spelregel 3.1 #5) |
+| zorgepisode_id | uuid → ZORGEPISODE | ja | eigenaar van het verslag; cliënt is afleidbaar via de episode (geen dubbele FK) |
+| rapportagetype_code | code → waardelijst `rapportagetype` | ja | |
+| gebeurtenis_datumtijd | timestamptz | ja | wanneer het gerapporteerde plaatsvond (≠ moment van vastleggen) |
+| vrije_tekst | text | ja | embeddings-bron (§3.2); minimumlengte per type via typeconfiguratie |
+| methodiek_code | code → waardelijst `rapportagemethodiek` | nee | SOEP/DAP/TIP; leeg = alleen vrije tekst. Methodiek is optie, geen dwang |
+| dienst_datum | date | nee* | *verplicht als het type `dienstweergave = ja` heeft; berekend bij vastleggen (vóór dienstgrens ⇒ vorige dag) en daarna bevroren |
+| dagdeel_code | code → waardelijst `dagdeel` | nee* | idem; afgeleid uit gebeurtenis_datumtijd + dagdeel-tijdvakken |
+| overdracht_markering | boolean | ja (default per type) | "neem mee in overdracht" |
+| client_zichtbaar | boolean | ja (default per type) | portaalweergave; heft Wabvpz-inzagerecht nooit op |
+| herkomst | code → waardelijst `herkomst` (`mens`/`ai`) | ja | spelregel 3.1 #2 |
+| auteur_type_code | code → waardelijst `auteur_type` | ja | medewerker / cliënt / naaste / extern / ai |
+| auteur_medewerker_id | uuid → MEDEWERKER | ja indien herkomst=mens én auteur_type=medewerker | |
+| auteur_persoon_id | uuid → PERSOON | ja indien auteur_type=cliënt/naaste | cliëntverklaring, naaste-notitie |
+| ai_model | text | ja indien herkomst=ai | modelnaam + versie |
+| bevestigd_door_medewerker_id | uuid → MEDEWERKER | ja vóór status definitief indien herkomst=ai | human-in-the-loop, harde platformregel |
+| bevestigd_op | timestamptz | idem | |
+| status_code | code → waardelijst `rapportagestatus` | ja | zie statusmachine (§5) |
+| definitief_op | timestamptz | ja bij status ≥ definitief | |
+| versienummer | integer | ja (default 1) | |
+| vorige_versie_id | uuid → RAPPORTAGE | nee | versieketen; nieuw record per versie |
+| intake_id | uuid → INTAKE | nee | "verslag over" een intake |
+| contactmoment_id | uuid → CONTACTMOMENT | nee | koppeling aan consult; consultregistratie (ZPM) blijft een apart feit |
+| behandelplan_id | uuid → BEHANDELPLAN | nee | voor evaluatie- en MDO-verslagen |
+| content_hash | text (sha-256) | ja | trigger her-embedding + TIP-koppelafspraak (§3.3.4) |
+| created_at / updated_at / deleted_at / created_by | — | ja/ja/nee/ja | soft delete (spelregel 3.1 #4) |
+
+**Uniciteitsregels**
+- `vorige_versie_id` is uniek indien gevuld (max. één opvolger per versie; de keten is een lijst, geen boom).
+- Per versieketen is er hoogstens één record met status `concept` of `definitief`; alle voorgangers hebben status `vervangen`.
+- Content-hash + updated_at maken elke tekstwijziging detecteerbaar (append-only audit, spelregel 3.1 #3, logt de rest).
+
+### 2.2 RAPPORTAGESECTIE
+
+**Doel:** optionele gestructureerde secties per methodiek (S/O/E/P, D/A/P, T/I/P) naast de vrije tekst — methodiekwissel is configuratie, geen migratie (onderzoek-rapportage §3, §9.1; Nedap `soapReportEntries`, onderzoek-leveranciers §2.5).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| id | uuid | ja |
+| rapportage_id | uuid → RAPPORTAGE | ja |
+| sectietype_code | code → waardelijst `sectietype` | ja |
+| tekst | text | ja |
+
+**Uniciteit:** (rapportage_id, sectietype_code) uniek — één sectie "Plan" per rapportage. Secties zijn alleen toegestaan als hun sectietype bij de methodiek van de rapportage hoort (check-constraint via waardelijst, spelregel 3.1 #7).
+
+### 2.3 RAPPORTAGE_DOELKOPPELING
+
+**Doel:** rapporteren-op-doel (onderzoek-rapportage §4; Nedap/ZilliZ-praktijk). Een rapportage refereert 0..n behandeldoelen; per koppeling optioneel een voortgangsindicatie.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| rapportage_id | uuid → RAPPORTAGE | ja |
+| behandeldoel_id | uuid → BEHANDELDOEL | ja |
+| voortgang_code | code → waardelijst `voortgang_indicatie` | nee |
+
+**Uniciteit:** (rapportage_id, behandeldoel_id) uniek.
+
+### 2.4 AI_BRONVERWIJZING
+
+**Doel:** verplichte bronverwijzingen bij AI-gegenereerde records (spelregel 3.1 #2) — generiek bruikbaar voor RAPPORTAGE én OVERDRACHTSSAMENVATTING (en later andere AI-output). Legt vast waaróp de generatie rustte, inclusief content-hash van de bron op dat moment (zelfde mechanisme als TIP-snapshot, discovery §3.3.2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| id | uuid | ja |
+| eigenaar_entiteit | code (`rapportage`/`overdrachtssamenvatting`) | ja |
+| eigenaar_id | uuid | ja |
+| bron_entiteit | code (bv. `rapportage`, `intake`, `diagnose`, `behandelplan`) | ja |
+| bron_id | uuid | ja |
+| bron_content_hash | text | ja | hash van de bron ten tijde van generatie |
+| volgorde | integer | nee |
+
+**Uniciteit:** (eigenaar_entiteit, eigenaar_id, bron_entiteit, bron_id) uniek.
+**Regel:** een record met herkomst `ai` moet ≥ 1 bronverwijzing hebben vóór het definitief kan worden.
+
+### 2.5 INCIDENTDETAIL
+
+**Doel:** de Wkkgz art. 10 lid 3-dossieraantekening: bij een rapportage van type `incident` horen gestructureerde velden aard, toedracht, tijdstip en betrokkenen (onderzoek-rapportage §1.3, §6, §9.3). 1-op-1 op RAPPORTAGE; de vrije tekst van de rapportage blijft het verhalende deel (spelregel §3.2: structuur + tekst in hetzelfde record).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| rapportage_id | uuid → RAPPORTAGE (PK) | ja |
+| incidentcategorie_code | code → waardelijst `incidentcategorie` | ja |
+| aard | text | ja |
+| toedracht | text | ja |
+| incident_datumtijd | timestamptz | ja |
+| merkbare_gevolgen | boolean | ja | art. 10-criterium; ook "mogelijk in de toekomst" telt |
+| client_geinformeerd_op | date | nee | meldplicht aan cliënt; nudge indien leeg |
+
+**Uniciteit:** rapportage_id is PK (1-op-1). Verplicht aanwezig als rapportagetype = `incident` (check-constraint).
+
+### 2.6 INCIDENT_BETROKKENE
+
+**Doel:** namen van direct betrokkenen bij het incident (wettelijk vereist veld).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| id | uuid | ja |
+| incident_rapportage_id | uuid → INCIDENTDETAIL | ja |
+| medewerker_id | uuid → MEDEWERKER | nee* |
+| naam_vrij | text | nee* |
+
+\* Precies één van beide gevuld: interne betrokkene via referentie, externe via vrije naam.
+**Uniciteit:** (incident_rapportage_id, medewerker_id) uniek indien medewerker_id gevuld.
+
+> **Bewust buiten deze entiteit:** de VIM-melding (Wkkgz art. 9) is een apart register buiten het cliëntdossier met eigen autorisatie en levenscyclus — zie open besluitpunt 4. De IGJ-calamiteitenmelding is proces-state (TIP-kandidaat).
+
+### 2.7 OVERDRACHTSSAMENVATTING
+
+**Doel:** de vastgelegde (AI-)overdracht per episode over een periode/dienst, mét provenance en bronverwijzingen naar de onderliggende rapportages (onderzoek-rapportage §9.2; discovery §3.3.2 — zonder snapshot is niet herleidbaar waarop de overdracht rustte).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| id | uuid | ja |
+| zorgepisode_id | uuid → ZORGEPISODE | ja |
+| periode_van / periode_tot | timestamptz | ja |
+| dagdeel_code | code → waardelijst `dagdeel` | nee | bij dienst-gebonden overdracht |
+| samenvatting_tekst | text | ja |
+| herkomst | code (`mens`/`ai`) | ja |
+| ai_model | text | ja indien herkomst=ai |
+| bevestigd_door_medewerker_id | uuid → MEDEWERKER | ja vóór status definitief indien herkomst=ai |
+| bevestigd_op | timestamptz | idem |
+| status_code | code → waardelijst `rapportagestatus` | ja | zelfde statusmachine als RAPPORTAGE |
+| content_hash | text | ja |
+| created_at / deleted_at / created_by | — | ja/nee/ja |
+
+**Uniciteit:** geen harde uniciteit op (episode, periode) — hergenereren levert een nieuw record; het oude krijgt status `vervangen`. Bronnen via AI_BRONVERWIJZING (≥ 1 verplicht bij herkomst `ai`).
+
+### 2.8 Configuratie (geen eigen entiteitenkaart-blok, wel vastgelegd)
+
+- **INSTELLINGSCONFIG `dienstgrens`** — tijdstip (default 07:00) waarvóór een rapportage bij de vorige dienstdag telt. Data, niet hardcoded (lost prototype-gebrek §8.2.5 op).
+- **Dagdeel-tijdvakken** — als attributen op de waardelijst `dagdeel` (van/tot), zelfde reden.
+
+---
+
+## 3. Relaties met cardinaliteit
+
+| Relatie | Cardinaliteit | Toelichting |
+|---|---|---|
+| RAPPORTAGE → ZORGEPISODE | n : 1 (verplicht) | eigenaar; cliënt afleidbaar. Eén episode per rapportage (Nedap doet m:n — bewust niet gevolgd, zie open besluitpunt 3) |
+| RAPPORTAGE → waardelijst `rapportagetype` | n : 1 (verplicht) | |
+| RAPPORTAGE → MEDEWERKER (auteur) | n : 0..1 | verplicht bij herkomst mens/auteur medewerker |
+| RAPPORTAGE → PERSOON (auteur) | n : 0..1 | cliëntverklaring / naaste |
+| RAPPORTAGE → MEDEWERKER (bevestiger) | n : 0..1 | verplicht vóór definitief bij herkomst AI |
+| RAPPORTAGE → RAPPORTAGE (vorige versie) | 1 : 0..1 | versieketen, opvolger uniek |
+| RAPPORTAGE → CONTACTMOMENT | n : 0..1 | consult (ZPM-registratie) en verslag zijn twee feiten die verwijzen, geen één record (onderzoek-rapportage §1.5) |
+| RAPPORTAGE → INTAKE | n : 0..1 | verslag-over |
+| RAPPORTAGE → BEHANDELPLAN | n : 0..1 | evaluatie-/MDO-verslag |
+| RAPPORTAGE ↔ BEHANDELDOEL | n : m via RAPPORTAGE_DOELKOPPELING | 0..n doelen per rapportage; voortgangsindicatie optioneel |
+| RAPPORTAGESECTIE → RAPPORTAGE | n : 1 | max. één per sectietype |
+| INCIDENTDETAIL → RAPPORTAGE | 1 : 1 | alleen bij type `incident` |
+| INCIDENT_BETROKKENE → INCIDENTDETAIL | n : 1 | |
+| AI_BRONVERWIJZING → (RAPPORTAGE \| OVERDRACHTSSAMENVATTING) | n : 1 (polymorf) | stabiele UUID's maken dit veilig (spelregel 3.1 #5) |
+| OVERDRACHTSSAMENVATTING → ZORGEPISODE | n : 1 (verplicht) | |
+| OVERDRACHTSSAMENVATTING → MEDEWERKER (bevestiger) | n : 0..1 | |
+
+**Naar andere deelgebieden:** ZORGEPISODE (discovery §5.1 #9), INTAKE (§5.2), BEHANDELPLAN + BEHANDELDOEL (§5.5), CONTACTMOMENT (agenda-ronde; FK nu al gereserveerd), MEDEWERKER en PERSOON (rollenronde). Verslaglegging in de aanmeld-/screeningsfase loopt via SCREENINGSACTIVITEIT (bestaat al, §5.2 besluit 3) — een RAPPORTAGE zonder episode bestaat in dit voorstel niet (open besluitpunt 1).
+
+---
+
+## 4. Waardelijsten
+
+Alle lijsten conform spelregel 3.1 #1: referentietabellen, UI en database delen één bron. Elke rij krijgt (patroon uit onderzoek-standaarden §8): `code`, `naam`, `actief`, optioneel `externe_code` + `codesysteem_uri`, `geldig_van`/`geldig_tot`.
+
+### 4.1 `rapportagetype` — met typeconfiguratie als attributen
+
+Attributen per waarde: `overdracht_default` (ja/nee), `client_zichtbaar_default` (ja/nee), `dienstweergave` (telt mee in dienst/dagdeel-overzicht), `standaard_methodiek` (0..1), `episode_niveau` (ja = niet per se één cliëntcontact, bv. MDO), `min_lengte`/`max_lengte`. Dit vervangt de drie hardcoded prototype-lijsten (`REPORT_TYPES`, `VERPLEEG_REPORT_TYPES`, `CATEGORY_CONFIG`) door één configuratiebron — het Nedap-patroon "rapporttypen zijn beheerconfiguratie", zonder de Nedap-fout van magic numbers in de docs.
+
+| Code | Overdracht | Cliëntzichtbaar | Dienstweergave | Herkomst |
+|---|---|---|---|---|
+| `voortgang` | nee | ja | nee | prototype |
+| `observatie` | ja | ja | ja | prototype |
+| `incident` | ja | ja | ja | prototype (nu mét art. 10-structuur) |
+| `medicatie` | ja | ja | ja | prototype |
+| `contact` | nee | ja | nee | prototype |
+| `crisis` | ja | ja | ja | prototype |
+| `verpleegkundig` | ja | ja | ja | prototype |
+| `vrije_notitie` | nee | ja | nee | prototype |
+| `evaluatie` | nee | ja | nee | nieuw (LKS: evaluatie ≥ 1×/jaar aantoonbaar) |
+| `mdo_verslag` | nee | ja | nee | nieuw (LKS/Verenso; episode_niveau = ja) |
+| `clientverklaring` | nee | ja | nee | nieuw (WGBO-aanvullingsrecht; auteur_type cliënt) |
+
+Prototype-typen `intake` en `behandeladvies` **vervallen als rapportagetype** (open besluitpunt 2): een verslag *over* een intake is een rapportage met `intake_id`; het behandeladvies is al een eigen entiteit in de intake-flow (discovery §5.2). De verpleegkundige subcategorie (medicatie/adl/gedrag/incident/observatie) vervalt als aparte JSON-dimensie: adl en gedrag kunnen desgewenst als extra rapportagetypen worden toegevoegd — dat is nu configuratie, geen code.
+
+### 4.2 `rapportagemethodiek`
+
+`vrij` (default), `soep`, `dap`, `tip`, `sbar`. Optionele structuur, geen dwang (onderzoek-rapportage §3: geen landelijk verplichte notitievorm; methodiek = configuratie).
+
+### 4.3 `sectietype` — attribuut: `methodiek_code`, `volgorde`
+
+| Methodiek | Secties |
+|---|---|
+| soep | `soep_s` Subjectief · `soep_o` Objectief · `soep_e` Evaluatie · `soep_p` Plan |
+| dap | `dap_d` Data · `dap_a` Assessment · `dap_p` Plan |
+| tip | `tip_t` Thema · `tip_i` Interventie · `tip_p` Plan |
+| sbar | `sbar_s` Situation · `sbar_b` Background · `sbar_a` Assessment · `sbar_r` Recommendation |
+
+### 4.4 `dagdeel` — attributen: `tijd_van`, `tijd_tot`
+
+`nacht` (23:00–07:00), `ochtend` (07:00–15:00), `middag` (15:00–19:00), `avond` (19:00–23:00). Tijdvakken zijn data (per instelling aanpasbaar); startwaarden uit het prototype-timelinepatroon.
+
+### 4.5 `voortgang_indicatie` (op doelkoppeling)
+
+`achteruitgang`, `gelijk`, `lichte_vooruitgang`, `duidelijke_vooruitgang`, `behaald`. (Startlijst; Nedap gebruikt een vergelijkbare voortgangsmaat — te bevestigen, open besluitpunt 9.)
+
+### 4.6 `incidentcategorie`
+
+`agressie_geweld`, `medicatie_incident`, `val`, `suicide_poging_automutilatie`, `vermissing_onttrekking`, `seksueel_grensoverschrijdend`, `middelengebruik`, `overig` (met specificatieveld — zib-patroon "anders + specificatie"). Bron: IGJ-meldingscategorieën GGZ.
+
+### 4.7 `auteur_type`
+
+`medewerker`, `client`, `naaste`, `extern`, `ai`. (Nedap kent employee/caren/extern; AI is de Triqura-uitbreiding conform spelregel 3.1 #2.)
+
+### 4.8 `herkomst`
+
+`mens`, `ai`. Bewust een eigen as naast auteur_type: een AI-gegenereerd-en-bevestigd verslag blijft herkomst `ai` — de bevestiging maakt de mens verantwoordelijk, niet de auteur.
+
+### 4.9 `rapportagestatus`
+
+`concept`, `definitief`, `vervangen`. (Zib TekstUitslag kent pending/preliminary/final/corrected — ons `vervangen` + nieuwe versie dekt "corrected" semantisch; export-mapping is triviaal.)
+
+---
+
+## 5. Statusmachine
+
+Statussen en overgangen in een referentietabel (spelregel 3.1 #9). Geldt voor RAPPORTAGE én OVERDRACHTSSAMENVATTING.
+
+| Van | Naar | Trigger | Wie mag |
+|---|---|---|---|
+| — | `concept` | aanmaken | elke medewerker met dossiertoegang; AI (via pipeline) maakt altijd en alleen `concept` |
+| `concept` | `concept` | bewerken | auteur (bij AI: de beoogd bevestiger); vrij bewerken toegestaan zolang concept |
+| `concept` | `definitief` | accorderen | **alleen een mens** (nooit AI — human-in-the-loop is platform-hard). Bij herkomst `ai`: pas na `bevestigd_door` + `bevestigd_op` én ≥ 1 bronverwijzing. Welke rollen precies → **rollenronde** |
+| `concept` | *(soft delete)* | verwijderen | auteur; `deleted_at`, nooit hard delete |
+| `definitief` | `vervangen` | nieuwe versie wordt definitief | automatisch (systeem), atomair met de definitief-overgang van de opvolger |
+| `definitief` | *(soft delete)* | WGBO-vernietigingsverzoek | **niet** via de normale flow; aparte, gelogde procedure (batchjob/verzoekafhandeling, spelregel 3.1 #4 + KNMG 2024: het vernietigingsverzoek zelf bewaren) |
+
+**Expliciet verboden:** `definitief` → `concept` (geen stille heropening; correctie = nieuwe versie via `vorige_versie_id`), elke UPDATE van `vrije_tekst`/secties op een definitief record (append-only gedachte; DB-constraint), status zetten door een AI-component.
+
+**Nudge-kansen (Nudge Engine, geen schema-eis):** "verslag nog concept na X dagen", "consult zonder verslag", "incident met merkbare gevolgen zonder cliënt-geïnformeerd-datum", "evaluatie langer dan een jaar geleden".
+
+---
+
+## 6. ECD/TIP-eigenaarschap en events richting TIP
+
+**Eigenaarschap:** RAPPORTAGE, RAPPORTAGESECTIE, RAPPORTAGE_DOELKOPPELING, INCIDENTDETAIL(+BETROKKENE), OVERDRACHTSSAMENVATTING en AI_BRONVERWIJZING zijn **leidend in het ECD** (klinische feiten, discovery §3.3). TIP houdt geen kopie van verslagteksten; TIP mag doelgebonden snapshots maken op basis van uuid + content_hash (afspraak Joshua §3.3.2) en longitudinale IE's bijhouden (bv. voortgangsindicaties per doel, §3.3.3).
+
+**Events ECD → TIP** (payload: record-uuid, entiteittype, rapportagetype, zorgepisode-uuid, content_hash, tijdstip — **geen vrije tekst, nooit BSN**, spelregel 3.1 #6):
+
+| Event | Wanneer | TIP-gebruik |
+|---|---|---|
+| `rapportage.definitief` | concept → definitief | nudge-evaluatie na actie; trend op doelvoortgang |
+| `rapportage.versie_vervangen` | nieuwe versie definitief | koppelafspraak §3.3.4: TIP-snapshot veroudert aantoonbaar; her-embedding trigger deelt dit mechanisme |
+| `rapportage.verwijderd` | soft delete | idem — TIP-kopieën doelgebonden opruimen |
+| `incident.aangetekend` | incidentrapportage definitief | termijn-nudges (cliënt informeren; evt. VIM/IGJ-spoor) |
+| `overdracht.bevestigd` | overdrachtssamenvatting definitief | overdracht-workflow, taken |
+| `rapportage.concept_aangemaakt` (optioneel) | AI-generatie klaar | TIP-taak "bevestigen" voor de behandelaar |
+
+**Proces-state die bewust in TIP blijft (niet in het ECD):** overdrachts-workflow (wie moet nog lezen/bevestigen — Nedap's `reportActions`-patroon is bij ons TIP-terrein), VIM-analyse-workflow, IGJ-meldtermijnbewaking, "verslag vergeten"-signalering. Het ECD levert alleen de klinische feiten waaruit TIP die state afleidt.
+
+---
+
+## 7. Open besluitpunten voor Colin
+
+1. **Rapportage zonder zorgepisode (screenings-/aanmeldfase)?** Voorstel: **nee** — RAPPORTAGE vereist een episode; verslaglegging vóór de episode loopt via SCREENINGSACTIVITEIT (type + toelichting, al besloten §5.2 #3). Houdt het model schoon en volgt het LKS (verwijzer is eerstverantwoordelijke tot de intake). *Advies: bevestigen.*
+2. **`intake` en `behandeladvies` schrappen als rapportagetype?** Ze dupliceren eigen entiteiten (onderzoek-rapportage §8.2.3). Voorstel: schrappen; "verslag over een intake" = rapportage met `intake_id`. *Advies: schrappen; bij migratie van prototypedata krijgen oude records type `vrije_notitie` + intake-verwijzing.*
+3. **Eén episode per rapportage, of meerdere (Nedap: `episodeIds[]` m:n)?** Voorstel: **één** — parallelle episodes zijn bij ons een aan/uit-bedrijfsregel (§5.0.5) en een verslag dat twee episodes raakt is zeldzaam; m:n compliceert autorisatie en TIP-events. *Advies: 1:n houden; heroverwegen als parallelle episodes aangezet worden.*
+4. **VIM binnen of buiten het ECD?** De VIM-melding hoort wettelijk búiten het cliëntdossier (eigen register, eigen autorisatie). Voorstel: **buiten scope van het ECD-dossierdeel deze ronde**; alleen de dossieraantekening (INCIDENTDETAIL) modelleren; VIM als aparte module/ronde besluiten, met hooguit een optionele verwijzing VIM → rapportage-uuid. *Advies: buiten deze ronde plaatsen.*
+5. **Overdrachtssamenvatting persisteren of vluchtig?** Voorstel: **persisteren** (entiteit §2.7) — zonder vastlegging is niet herleidbaar op welke bronnen een overdracht rustte (spelregel 3.1 #2 + §3.3.2), en de bevestiging door een mens is een klinisch relevant feit. *Advies: persisteren.*
+6. **Dienstgrens en dagdeel-tijdvakken per instelling of per afdeling?** Voorstel: per **instelling** starten (één configwaarde), model zo dat een afdelings-override later een extra configrij is, geen migratie. *Advies: instelling nu, afdeling later.*
+7. **Cliëntverklaring (WGBO-aanvulling) als rapportagetype of eigen entiteit?** Voorstel: **rapportagetype** `clientverklaring` met auteur_type `client` — de verklaring is inhoudelijk een dossierstuk met dezelfde levenscyclus; een eigen entiteit voegt nu niets toe. *Advies: rapportagetype.*
+8. **Termijn-nudge "verslag nog concept"**: verplichte accordering binnen X dagen als protocolregel — welke X (config per instelling)? *Advies: nudge met default 3 werkdagen, severity `waarschuwing`; geen harde blokkade.*
+9. **Waardelijst-startwaarden bevestigen:** voortgangsindicatie (§4.5), incidentcategorieën (§4.6), dagdeel-tijdvakken (§4.4), en de overdracht-/zichtbaarheids-defaults per rapportagetype (§4.1). *Advies: startwaarden overnemen en in de praktijk bijstellen — het zijn referentiedata, geen schema.*
+10. **Vertrouwelijkheid per discipline** ("groen slotje", Nedap; vertrouwelijkheid zelfs per SOEP-sectie): voorstel **doorschuiven naar de rollenronde**, maar nu vastleggen dát autorisatie op rapportage-niveau (en mogelijk sectie-niveau) komt, zodat de entiteiten er geen schemawijziging voor nodig hebben. *Advies: doorschuiven, kolomreservering niet nodig (aparte autorisatietabel t.z.t.).*
+11. **Persoonlijke werkaantekeningen**: NIP zegt géén dossier-entiteit. Voorstel: **niet faciliteren** in het ECD (simpelste, juridisch schoonste). *Advies: niet faciliteren; expliciet zo vastleggen in de discovery.*
+
+---
+
+## 8. Bronverwijzingen
+
+| Onderwerp | Bron |
+|---|---|
+| Spelregels waardelijsten, provenance, audit, soft delete, UUID's, statusmachines | discovery §3.1 (#1–#5, #7, #9) |
+| Tekst + structuur in één record; content-hash → her-embedding | discovery §3.2 |
+| TIP-grensvlak, snapshot- en koppelafspraak (Joshua) | discovery §3.3 (#1–#4) |
+| ZORGEPISODE als eigenaar van klinische records | discovery §5.1 besluit #9; §5.4 besluit #2 |
+| Behandeldoel, evaluatiemoment, behandelplan-kern | discovery §5.5 |
+| Verslag-feitzin + provenance-verwijzing naar deze ronde | discovery §5.2 feitzin 9 + open vragen |
+| WGBO dossierplicht, 20 jaar, correctie/aanvulling/vernietiging | onderzoek-rapportage §1.1; onderzoek-proces §8 |
+| Wabvpz elektronische inzage, NEN 7513-logging | onderzoek-rapportage §1.2 |
+| Wkkgz art. 10 lid 3 (aard/toedracht/tijdstip/betrokkenen) en VIM-scheiding | onderzoek-rapportage §1.3, §6 |
+| LKS 4.0: regiebehandelaar-verslaglegging, MDO, jaarlijkse evaluatie | onderzoek-rapportage §1.4; onderzoek-proces §1, §5, §10.1 (#12) |
+| ZPM: consultregistratie ≠ inhoudelijke rapportage | onderzoek-rapportage §1.5; onderzoek-standaarden §6.2 |
+| SOEP/DAP/TIP/SBAR als configuratie, niet als dwang | onderzoek-rapportage §3 |
+| Rapporteren op doel + voortgangsmaat | onderzoek-rapportage §4 |
+| Overdracht/dienst, eOverdracht als koppelvlak | onderzoek-rapportage §5, §9.2 |
+| Prototype-analyse en gebreken (`app/api/reports`, `lib/types/report.ts`) | onderzoek-rapportage §8 |
+| Nedap-patronen: ReportType-configuratie, SOEP-secties, auteurstype, verbergen-met-reden, cliëntakkoord als los feit | onderzoek-leveranciers §2.5, §2.6, §7 (#1, #7) |
+| zib TekstUitslag (type/datum/status concept-definitief-gecorrigeerd) | onderzoek-standaarden §2.2 |
+| Waardelijst-patroon: externe code + codesysteem + geldigheidsperiode | onderzoek-standaarden §8; onderzoek-leveranciers §7 #1 |
+| NIP: werkaantekeningen geen dossier | onderzoek-rapportage §2.3 |

docs/datamodel/deelmodellen/model-screening.md

@@ -0,0 +1,269 @@
+# Datamodelvoorstel — deelgebied Screening / triage
+
+**Status:** gerichte herziening nodig — zie `../besluiten/besluitenlog-datamodel-2026-07-18.md` §§2 en 3
+**Datum:** 18 juli 2026
+**Scope:** SCREENING, SCREENING_ACTIVITEIT, SCREENING_BESLUIT + wat triage in de praktijk nodig heeft: urgentiebepaling/crisissignalering, informatie-uitvraag, wie screent.
+**Kader:** genomen besluiten uit `datamodel-discovery.md` zijn heilig; dit voorstel draait niets terug. De open vraag "screeningsbesluit ↔ aanmelding-uitkomst" wordt hier opgelost met een onderbouwd voorstel (§7 punt 1).
+
+> **Let op:** SCREENING hoort voortaan bij het AANMELDINGSTRAJECT en kan informatie uit meerdere AANMELDSIGNALEN gebruiken. Het screeningsbesluit blijft een inhoudelijk advies en is niet hetzelfde als het formele acceptatiebesluit.
+
+---
+
+## 0. Kernkeuze vooraf: besluit ≠ uitkomst (twee feiten)
+
+De open vraag uit discovery §5.2 ("is het screeningsbesluit hetzelfde feit als de aanmelding-uitkomst?") beantwoordt dit voorstel met: **twee aparte feiten**.
+
+Onderbouwing:
+- Het LKS 4.0 kent geen aparte screeningsfase; landelijk is alleen de intake/indicatiestelling normatief. Screening is een **interne processtap** van de instelling (onderzoek-proces §3, §10.3). Het screeningsbesluit is daarmee een *inhoudelijk advies* ("geschikt, afdeling Volwassenen, urgentie spoed"), de aanmelding-uitkomst is het *formele instellingsbesluit* ("intake" / "afgewezen" / "doorverwezen" / "wachtlijst" — discovery §5.1 #5).
+- De twee vallen aantoonbaar niet samen: een screening kan "geschikt" adviseren terwijl de aanmelding op "wachtlijst" of (wegens aanmeldpauze/capaciteit) op "doorverwezen" uitkomt. Eén samengevouwen feit kan dat verschil niet uitdrukken.
+- Samenvouwen zou bovendien besluit §5.1 #5 (aanmelding-uitkomstwaarden) impliciet wijzigen — dat doen we niet.
+
+Gevolg: SCREENING_BESLUIT blijft een eigen entiteit onder SCREENING; de uitkomst op AANMELDING blijft eigendom van het deelgebied instroom. Discrepantie tussen beide is géén schemafout maar een **nudge** ("aanmelding-uitkomst wijkt af van screeningsadvies — motiveer"), zie §6.
+
+---
+
+## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.2)
+
+Feitzinnen 1–3 van discovery §5.2 blijven gelden; S3 verfijnt discoveryzin 3. Nieuw/gewijzigd:
+
+1. **(S1, gewijzigd)** *Voor de aanmelding van Jan de Vries is op 15 juli 2026 een screening gestart; screener is verpleegkundige K. Jansen.*
+2. **(S2, gewijzigd)** *Bij de screening is op 16 juli 2026 een activiteit van type "telefonisch contact" geregistreerd door K. Jansen, met toelichting "huisarts gesproken over medicatiehistorie".*
+3. **(S3, gewijzigd)** *Het screeningsbesluit voor de screening luidt "geschikt", met geadviseerde afdeling Volwassenen, geadviseerd zorgprogramma "Algemeen GGZ" en urgentie "regulier"; het is op 17 juli 2026 genomen door K. Jansen, met motivatie "past binnen reguliere volwassenenzorg".* — het besluit hangt aan de SCREENING (niet rechtstreeks aan de aanmelding) en draagt urgentie en optioneel zorgprogramma.
+4. **(S4, nieuw)** *De screening heeft status "lopend".* / *De screening is op 17 juli 2026 afgerond.*
+5. **(S5, nieuw)** *Bij de screening is op 16 juli 2026 urgentie "spoed" ingeschat door K. Jansen.* — tussentijdse urgentie-inschatting, vóór het besluit (onderzoek-proces §3: urgentie wordt vaak al bíj de screening bepaald, vóór er een wachtlijstplaatsing is).
+6. **(S6, nieuw)** *Bij de activiteit van 16 juli 2026 is een crisissignaal afgegeven.* — elk contactmoment tijdens de screening kan een crisissignaal opleveren; dit gaat direct als event naar TIP.
+7. **(S7, nieuw)** *Voor de screening is op 15 juli 2026 een informatie-uitvraag van type "medicatieoverzicht" gedaan bij verwijzer P. Pietersen, door K. Jansen.*
+8. **(S8, nieuw)** *De informatie-uitvraag van 15 juli 2026 heeft status "uitstaand".* / *...is op 16 juli 2026 beantwoord met document document-813.*
+9. **(S9, nieuw)** *De aanmelding van Jan de Vries heeft op 17 juli 2026 uitkomst "intake" gekregen; dit besluit verwijst naar het screeningsbesluit van 17 juli als onderbouwing.* — de uitkomst blijft een feit op AANMELDING (instroom-deelgebied); de verwijzing legt de relatie vast.
+10. **(S10, nieuw)** *De screening is op 20 juli 2026 afgebroken met reden "cliënt trekt aanmelding in".*
+11. **(S11, nieuw)** *Activiteittype "dossieronderzoek" telt niet als cliëntcontact; activiteittype "telefonisch contact" wel.* — eigenschap van de waardelijstwaarde, maakt de nudge "nog geen contact geweest bij deze screening" (discovery §5.2 besluit 3) berekenbaar.
+
+---
+
+## 2. Entiteiten
+
+Alle entiteiten volgen de harde spelregels (discovery §3.1): stabiele UUID, soft delete (`deleted_at`), append-only audit, statussen/typen als referentiedata. Auditvelden (`created_at`, `created_by`, ...) worden hieronder niet herhaald.
+
+### 2.1 SCREENING
+
+**Doel:** de interne triagefase van één aanmelding — de periode waarin de instelling beoordeelt of, waar en hoe urgent de cliënt geholpen moet worden. Container voor activiteiten, informatie-uitvragen en het besluit.
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `id` | uuid | ja | |
+| `aanmelding_id` | uuid → AANMELDING | ja | |
+| `gestart_op` | date | ja | |
+| `status` | ref → `screening_status` | ja | zie statusmachine §5 |
+| `screener_id` | uuid → MEDEWERKER | nee | verantwoordelijk screener/triagist; invulling en verplichtheid → rollenronde |
+| `urgentie_id` | ref → `urgentie` | nee | actuele tussentijdse inschatting (S5); definitieve urgentie staat op het besluit |
+| `urgentie_ingeschat_op` | timestamp | nee | verplicht zodra `urgentie_id` gevuld |
+| `afgerond_op` | date | nee | verplicht bij status `afgerond`/`afgebroken` |
+| `afbreekreden` | ref → `screening_afbreekreden` | nee | verplicht bij status `afgebroken` |
+
+**Uniciteit:** max **één screening met status `lopend` per aanmelding** (partial unique index op `aanmelding_id` where status = lopend en `deleted_at is null`). Meerdere afgeronde screenings per aanmelding zijn toegestaan: heropening van een besloten aanmelding (discovery §5.1 #5) start een **nieuwe** screening in plaats van een status-terugdraai — historie blijft intact.
+
+### 2.2 SCREENING_ACTIVITEIT
+
+**Doel:** één uitgevoerde triagehandeling (contact, dossieronderzoek, vragenlijst, ...), getypeerd conform discovery-besluit §5.2 #3. Maakt de aantoonbaarheid van de inspanningsverplichting bij onvolledige verwijzing concreet (onderzoek-proces §2.5: "aantoonbaar in het dossier").
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `id` | uuid | ja | |
+| `screening_id` | uuid → SCREENING | ja | |
+| `type_id` | ref → `screening_activiteit_type` | ja | |
+| `uitgevoerd_op` | timestamp | ja | |
+| `uitgevoerd_door` | uuid → MEDEWERKER | ja | feitzin S2; beroep/rol-detail → rollenronde |
+| `toelichting` | text | nee | vrije tekst (embedbaar conform §3.2 discovery: structuur + tekst in één record) |
+| `crisis_signaal` | boolean | ja (default nee) | S6; `true` triggert direct TIP-event, zie §6 |
+
+**Uniciteit:** geen natuurlijke sleutel naast `id`; meerdere activiteiten van hetzelfde type per dag zijn legitiem (twee telefoontjes).
+
+### 2.3 SCREENING_BESLUIT
+
+**Doel:** het inhoudelijke triage-advies dat de screening afsluit: geschiktheid, geadviseerde plek en urgentie. Dit is het *advies*-feit; het *formele* besluit blijft de uitkomst op AANMELDING (§0).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `id` | uuid | ja | |
+| `screening_id` | uuid → SCREENING | ja | |
+| `uitkomst_id` | ref → `screening_uitkomst` | ja | vervangt prototype-veld `geschikt`/`niet_geschikt` |
+| `geadviseerde_afdeling_id` | ref → `afdeling` | voorwaardelijk | verplicht als de uitkomstwaarde `vereist_afdeling = ja` heeft (waardelijst-attribuut, §4); geen vrije string meer (prototype-gebrek) |
+| `geadviseerd_zorgprogramma_id` | ref → `zorgprogramma` | nee | afdeling ≠ zorgprogramma (discovery-besluit §5.2 #2) |
+| `urgentie_id` | ref → `urgentie` | ja | definitieve urgentie; voedt straks `WACHTLIJSTPLAATSING.prioriteit` (aanmeld) en de intakeplanning |
+| `genomen_op` | date | ja | |
+| `genomen_door` | uuid → MEDEWERKER | ja | wie dit mág → rollenronde |
+| `motivatie` | text | nee | verplicht maken bij `niet_geschikt`/`doorverwijzing_elders` is een kandidaat-protocolregel (nudge), geen schema-eis |
+
+**Uniciteit:** max **één besluit per screening** (unique op `screening_id` where `deleted_at is null`). Correctie = soft delete + nieuw besluit (audit-hoofdstuk dekt de herleidbaarheid); geen stille updates op een genomen besluit.
+
+### 2.4 INFORMATIE_UITVRAAG (nieuw)
+
+**Doel:** vastleggen wat de instelling tijdens de triage aan aanvullende informatie heeft uitgevraagd, bij wie, en of het ontvangen is. Rechtstreekse eis uit de verwijsafspraken: bij onvolledige verwijzing geldt een **inspanningsverplichting die aantoonbaar moet zijn in het dossier** (onderzoek-proces §2.5, §10.1 stap 4). Ook de basis voor nudges ("uitvraag staat 14 dagen open").
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `id` | uuid | ja | |
+| `screening_id` | uuid → SCREENING | ja | zie open punt §7.6 voor generiek gebruik buiten de screening |
+| `type_id` | ref → `informatie_uitvraag_type` | ja | |
+| `gericht_aan_verwijzer_id` | uuid → VERWIJZER | nee | gevuld als de uitvraag bij de verwijzer ligt |
+| `gericht_aan_omschrijving` | text | nee | vrij veld voor andere partijen (cliënt, vorige zorgaanbieder, gemeente); verplicht als `gericht_aan_verwijzer_id` leeg is |
+| `uitgevraagd_op` | date | ja | |
+| `uitgevraagd_door` | uuid → MEDEWERKER | ja | |
+| `status` | ref → `informatie_uitvraag_status` | ja | zie §5 |
+| `ontvangen_op` | date | nee | verplicht bij status `ontvangen` |
+| `ontvangen_document_id` | uuid → DOCUMENT | nee | koppeling naar het ontvangen stuk (zelfde documentmechanisme als verwijsdocument, discovery §5.1 #7) |
+| `toelichting` | text | nee | |
+
+**Uniciteit:** geen; meerdere uitvragen van hetzelfde type mogen (herinnering = nieuwe uitvraag of statusloos herinner-event — keuze bij de bouw).
+
+---
+
+## 3. Relaties met cardinaliteit
+
+| Relatie | Cardinaliteit | Toelichting |
+|---|---|---|
+| AANMELDING — SCREENING | 1 : 0..n | max één `lopend` per aanmelding (§2.1); heropening = nieuwe screening |
+| SCREENING — SCREENING_ACTIVITEIT | 1 : 0..n | |
+| SCREENING — SCREENING_BESLUIT | 1 : 0..1 | besluit sluit de screening inhoudelijk af |
+| SCREENING — INFORMATIE_UITVRAAG | 1 : 0..n | |
+| SCREENING_BESLUIT — `afdeling` (waardelijst) | n : 0..1 | geadviseerde afdeling |
+| SCREENING_BESLUIT — `zorgprogramma` (waardelijst) | n : 0..1 | geadviseerd programma |
+| SCREENING / SCREENING_BESLUIT — `urgentie` (waardelijst) | n : 0..1 resp. n : 1 | tussentijds resp. definitief |
+| SCREENING_ACTIVITEIT — MEDEWERKER | n : 1 | uitvoerder; MEDEWERKER wordt in de rollenronde uitgewerkt (rol op PERSOON, conform discovery §5.1 #1) |
+| SCREENING — MEDEWERKER (screener) | n : 0..1 | |
+| SCREENING_BESLUIT — MEDEWERKER (genomen_door) | n : 1 | |
+| INFORMATIE_UITVRAAG — VERWIJZER | n : 0..1 | uitvraag bij de verwijzer (instroom-deelgebied) |
+| INFORMATIE_UITVRAAG — DOCUMENT | n : 0..1 | ontvangen stuk |
+| AANMELDING(uitkomst) — SCREENING_BESLUIT | 0..1 : 0..1 | **verwijzing als onderbouwing** (S9): op het aanmelding-uitkomstfeit een optionele `screening_besluit_id`. Eigenaar van dit veld is het instroom-deelgebied; hier alleen de relatie benoemd |
+| SCREENING_BESLUIT ⇒ WACHTLIJSTPLAATSING | afleiding, geen FK | urgentie van het besluit is de voorgestelde prioriteit bij een aanmeld-wachtlijstplaatsing (discovery §5.3); overname is een handeling, geen automatisme |
+| SCREENING ⇒ INTAKE | geen directe FK | screening vóór intake blijft een **nudge**, geen harde volgorde-eis (discovery-besluit §5.2 #4); de intake hangt aan de ZORGEPISODE, niet aan de screening |
+
+---
+
+## 4. Waardelijsten
+
+Conform spelregel §3.1 #1 (één bron, referentietabellen) en de standaarden-les (onderzoek-standaarden §8): elke rij krijgt optioneel `externe_code` + `codesysteem_uri` en `geldig_van`/`geldig_tot`; waar zinvol een "overig/anders"-waarde met specificatie in het vrije-tekstveld.
+
+### `screening_status`
+| code | omschrijving |
+|---|---|
+| `lopend` | screening gestart, nog geen eindtoestand |
+| `afgerond` | besluit genomen, screening klaar |
+| `afgebroken` | gestopt zonder besluit |
+
+### `screening_afbreekreden` (startwaarden)
+`client_trekt_terug` · `aanmelding_ingetrokken` · `geen_contact_mogelijk` · `overleden` · `overig`
+
+### `screening_activiteit_type` — met attribuut `is_clientcontact` (ja/nee)
+Startlijst = discovery-besluit §5.2 #3, aangevuld vanuit de praktijk (onderzoek-proces §3: telefonische screening en generalistisch aanmeldgesprek):
+
+| code | omschrijving | is_clientcontact |
+|---|---|---|
+| `telefonisch_contact` | telefonisch contact met cliënt of derden | ja |
+| `aanmeldgesprek` | (generalistisch) aanmeld-/triagegesprek | ja |
+| `dossieronderzoek` | beoordeling verwijsbrief/dossier | nee |
+| `vragenlijst` | uitgezette/beoordeelde vragenlijst | nee |
+| `mdo_bespreking` | bespreking in (aanmeld-)MDO | nee |
+| `overig` | anders, zie toelichting | nee |
+
+Het attribuut `is_clientcontact` volgt het `agb_verplicht`-patroon (discovery §5.1 #3): gedragsregels als data op de waardelijst, niet in applicatiecode. Nudge "nog geen contact geweest" telt activiteiten met `is_clientcontact = ja`.
+
+### `screening_uitkomst` — met attribuut `vereist_afdeling` (ja/nee)
+| code | omschrijving | vereist_afdeling |
+|---|---|---|
+| `geschikt` | geschikt voor intake bij deze instelling | ja |
+| `niet_geschikt` | niet geschikt; terugverwijzing naar verwijzer/huisarts met advies (LKS §6.1) | nee |
+| `doorverwijzing_elders` | beter passende aanbieder; doorverwijzen | nee |
+
+Bewust **géén** waarde `wachtlijst`: wachtlijst is geen triage-oordeel maar een capaciteitsuitkomst op de AANMELDING (§0). Bevestigen → §7.2.
+
+### `urgentie` — met attributen `volgorde` (int) en `reactietermijn_dagen` (int, optioneel, instellingsconfiguratie)
+| code | omschrijving |
+|---|---|
+| `crisis` | acute keten; buiten reguliere flow (GMAP-triagewijzer kent eigen urgentiegraden — aparte module, §7.7) |
+| `spoed` | versneld beoordelen/plaatsen |
+| `regulier` | normale flow |
+
+Sluit aan op het roadmap-idee prioriteit `spoed`/`normaal`/`laag` (discovery §5.3); de wachtlijst-prioriteitslijst kan dezelfde referentietabel gebruiken of ernaar mappen — afstemmen met de wachtlijst-modelleur.
+
+### `informatie_uitvraag_type` (startwaarden)
+`verwijsinformatie_aanvullen` · `medicatieoverzicht` · `medische_voorgeschiedenis` · `eerdere_behandelverslagen` · `vragenlijst_client` · `beschikking_gemeente` · `overig`
+
+### `informatie_uitvraag_status`
+`uitstaand` · `ontvangen` · `niet_ontvangen` (opgegeven na inspanning — het registreren hiervan ís de aantoonbare inspanning) · `vervallen` (niet meer nodig)
+
+---
+
+## 5. Statusmachine
+
+### SCREENING
+| Van | Naar | Voorwaarde |
+|---|---|---|
+| — | `lopend` | aanmaken; aanmelding bestaat en heeft geen andere lopende screening |
+| `lopend` | `afgerond` | er bestaat een SCREENING_BESLUIT voor deze screening (database-constraint, spelregel §3.1 #7); `afgerond_op` gevuld |
+| `lopend` | `afgebroken` | `afbreekreden` + `afgerond_op` gevuld |
+| `afgerond`/`afgebroken` | — | eindtoestanden; heropening = nieuwe SCREENING (§2.1) |
+
+**Wie mag zetten: → rollenronde** (expliciet open, conform discovery §5.1 #6). Werkhypothese voor die ronde: activiteiten en uitvragen registreren mag elke betrokken zorgmedewerker; het besluit nemen en de screening afronden is voorbehouden aan een daartoe aangewezen rol (triagist/regiebehandelaar-indicerend).
+
+### SCREENING_BESLUIT
+Geen statusmachine: een besluit is een gebeurtenisfeit. Correctie = soft delete + nieuw besluit (append-vriendelijk, audit §3.1 #3).
+
+### INFORMATIE_UITVRAAG
+`uitstaand` → `ontvangen` | `niet_ontvangen` | `vervallen`. Eindtoestanden; nieuwe behoefte = nieuwe uitvraag. Wie mag zetten: → rollenronde.
+
+---
+
+## 6. ECD/TIP-eigenaarschap en events richting TIP
+
+**Eigenaarschap:** alle vier entiteiten zijn **klinische feiten, leidend in het ECD** (grensvlak §3.3). De *procesbewaking* — termijnen, volgordebewaking, prioriteitsstelling van werk — is TIP-terrein en wordt gevoed door onderstaande events. TIP maakt per intentie/nudge zijn eigen doelgebonden snapshot (afstemming Joshua §3.3); mutatie-doorval loopt via de standaard mutatie-events + content-hash.
+
+| Event | Trigger | Payload-kern (nooit BSN, spelregel §3.1 #6) |
+|---|---|---|
+| `screening.gestart` | nieuwe SCREENING | screening_id, aanmelding_id, gestart_op |
+| `screening.activiteit_geregistreerd` | nieuwe activiteit | activiteit_id, type, is_clientcontact, uitgevoerd_op |
+| `screening.crisis_gesignaleerd` | activiteit met `crisis_signaal = true` óf urgentie op `crisis` | screening_id, bron (activiteit/urgentie), tijdstip — **hoogste prioriteit**, TIP escaleert richting acute keten |
+| `screening.urgentie_gewijzigd` | (her)inschatting urgentie op SCREENING | oude/nieuwe urgentie, tijdstip |
+| `screening.informatie_uitvraag_gestart` / `.afgesloten` | nieuwe uitvraag / eindstatus | uitvraag_id, type, status, uitgevraagd_op |
+| `screening.besluit_genomen` | nieuw SCREENING_BESLUIT | besluit_id, uitkomst, afdeling, zorgprogramma, urgentie |
+| `screening.afgerond` / `screening.afgebroken` | eindstatus SCREENING | screening_id, status, (afbreekreden) |
+| `screening.record_gemuteerd` | correctie/soft delete op elk record | record_id, content_hash (koppelafspraak §3.3 #4) |
+
+**Kandidaat-nudges (Protocol Rules Registry, ter illustratie — geen schema-eisen):**
+- "Screening lopend, nog geen activiteit met cliëntcontact" (discovery-besluit §5.2 #3).
+- "Informatie-uitvraag staat > N dagen op `uitstaand`" (inspanningsverplichting, onderzoek-proces §2.5).
+- "Aanmelding nadert Treeknorm aanmeldwachttijd (4 weken) en screening is nog `lopend`" (onderzoek-proces §4.1).
+- "Aanmelding-uitkomst wijkt af van screeningsadvies — motivatie vastleggen" (§0).
+- "Screeningsbesluit `geschikt` maar nog geen intake of wachtlijstplaatsing na N dagen."
+- "Crisissignaal afgegeven — acute-keten-route (GMAP) starten": severity `blokkade`-achtig qua urgentie, maar via TIP, niet via het schema.
+
+---
+
+## 7. Open besluitpunten voor Colin
+
+1. **Besluit ≠ uitkomst bevestigen (kernkeuze §0).** Screeningsbesluit = inhoudelijk advies (eigen feit onder SCREENING); aanmelding-uitkomst = formeel besluit (blijft op AANMELDING), met optionele verwijzing `screening_besluit_id` als onderbouwing en een discrepantie-nudge. **Advies: akkoord** — gedragen door onderzoek-proces §10.3 (LKS kent geen normatieve screeningsfase) en het bestaan van uitkomsten (wachtlijst, aanmeldpauze) die geen triage-oordeel zijn.
+2. **Startwaarden `screening_uitkomst`**: `geschikt` / `niet_geschikt` / `doorverwijzing_elders`, en bewust géén `wachtlijst`. **Advies: overnemen**; `niet_geschikt` impliceert terugverwijzing-met-advies (LKS §6.1) — als jullie "terugverwijzing" als aparte waarde naast "afwijzen" willen, splitsen we hem.
+3. **Urgentie op twee plekken**: tussentijdse inschatting op SCREENING (muteerbaar, ge-audit) én definitieve urgentie verplicht op het BESLUIT. **Advies: beide** — de praktijk bepaalt urgentie vaak al vóór het besluit (onderzoek-proces §3/§10.3) en de wachtlijstprioriteit heeft een definitieve waarde nodig. Alternatief (alleen op besluit) is simpeler maar verliest de vroege crisis-/spoedsignalering.
+4. **Startwaarden `urgentie`**: `crisis` / `spoed` / `regulier`, met `reactietermijn_dagen` als instellingsconfiguratie. **Advies: zo starten**; afstemmen met de wachtlijst-ronde of prioriteit dezelfde lijst hergebruikt (mijn voorkeur) of een eigen lijst met mapping krijgt.
+5. **Heropening = nieuwe SCREENING** (max één lopende per aanmelding; afgeronde blijven staan). **Advies: akkoord** — past bij append-only/historiebehoud en bij discovery §5.1 #5 (besloten aanmelding kan terug naar "in screening") zonder status-terugdraai op een afgeronde screening.
+6. **INFORMATIE_UITVRAAG: nu alleen onder SCREENING, of direct generiek?** Ook de intake vraagt aanvullende informatie op (onderzoek-proces §3 stap 4). **Advies: nu onder SCREENING houden** en in de intake-ronde besluiten of hij generiek wordt (bijv. polymorf aan aanmelding/episode); voortijdig generaliseren maakt het eigenaarschap vaag.
+7. **Crisissignalering als vlag + TIP-event, geen eigen entiteit.** De acute keten (GMAP-triagewijzer met urgentiegraden en beoordelingstijden) is een eigen module/route buiten deze ronde. **Advies: akkoord**; als crisisscreening een echt werkproces wordt, verdient dat een eigen deelgebied.
+8. **Startlijst `screening_activiteit_type` bevestigen**, incl. de toevoegingen `aanmeldgesprek` en `mdo_bespreking` en het attribuut `is_clientcontact`. **Advies: overnemen** — dekt de discovery-startlijst plus de praktijk (generalistisch aanmeldgesprek, aanmeld-MDO).
+9. **Wie screent / wie besluit → rollenronde** (bevestiging dat dit daar landt, conform discovery §5.1 #6). Werkhypothese in §5 meenemen als input voor die ronde.
+
+---
+
+## 8. Bronverwijzingen
+
+| Onderwerp | Bron |
+|---|---|
+| Uitgangspunten, spelregels, TIP-grensvlak | `datamodel-discovery.md` §3.1, §3.2, §3.3 |
+| Bestaande besluiten screening (activiteittypen, afdeling/zorgprogramma, screening-als-nudge) | discovery §5.2 besluiten 1–4; §5.1 #5 (aanmelding-status), #9 (zorgepisode) |
+| Open vraag besluit ↔ uitkomst | discovery §5.2 "Open vragen"; `onderzoek-proces.md` §10.3 (LKS kent geen aparte screeningsfase) |
+| Triagepraktijk (telefonische screening, aanmeldgesprek, uitkomsten, urgentie vóór wachtlijst) | `onderzoek-proces.md` §3, §10.1 stap 5 |
+| Inspanningsverplichting onvolledige verwijzing (basis INFORMATIE_UITVRAAG) | `onderzoek-proces.md` §2.5, §10.1 stap 4; Verwijsafspraken GGZ (VWS, dec 2024) |
+| Treeknormen / aanmeldwachttijd (nudge-context) | `onderzoek-proces.md` §4.1 |
+| Acute ggz / GMAP-triagewijzer (crisisroute) | `onderzoek-proces.md` §3; Generieke Module Acute Psychiatrie |
+| Waardelijst-patronen (externe code, geldigheidsperioden, "anders"-optie) | `../onderzoek/onderzoek-standaarden.md` §8; `../onderzoek/onderzoek-leveranciers.md` §7.1 (Nedap: waardelijsten met begindatum/einddatum) |
+| Instellingsconfigureerbare triage-/wachtwaardelijsten | `../onderzoek/onderzoek-leveranciers.md` §2.7 ("possible values are defined by the care organisation") |
+| Prototype-gebreken (afdeling als vrije string, activiteiten zonder type) | discovery §5.2 "Bevindingen prototype" |

docs/datamodel/deelmodellen/model-wachtlijst.md

@@ -0,0 +1,239 @@
+# Datamodelvoorstel — Wachtlijstplaatsing
+
+**Status:** voorlopig onderzoeksmodel — niet bouwrijp; zie `../besluiten/besluitenlog-datamodel-2026-07-18.md` §4
+**Datum:** 18 juli 2026
+**Bouwt voort op:** `datamodel-discovery.md` §5.3 (besluit sessie 17 juli: WACHTLIJSTPLAATSING als eigen entiteit, twee momenten aanmeld/behandel), §5.1 #9 (ZORGEPISODE), §5.1 #5 (aanmelding-uitkomst `wachtlijst`), spelregels §3.1
+**Onderzoeksinput:** onderzoek-proces §4 (Treeknormen, NZa Transparantieregeling, praktijkfenomenen), onderzoek-leveranciers §2.7 (Nedap-wachtlijst), onderzoek-standaarden §8 (waardelijst-patroon met geldigheidsperioden)
+
+> **Let op:** alleen de volledige, append-only tijdlijn en het zichtbaar houden van bruto wachttijd zijn als uitgangspunt bekrachtigd. Cardinaliteiten, dragers, teldatums, aftrekregels, redenlijsten en concrete NZa-/Treeknormberekeningen vragen nader GGZ-onderzoek. De voorstellen hieronder zijn op die punten niet definitief.
+
+---
+
+## 1. Feitzinnen
+
+Genummerd; **(≈ §5.3 #n)** = herkomst uit de discovery-startlijst, **(nieuw)** = toegevoegd in deze ronde.
+
+1. *De aanmelding van Jan de Vries is op 18 juli 2026 op de wachtlijst geplaatst met soort "aanmeld", voor afdeling Volwassenen.* (≈ §5.3 #1, gewijzigd: soort expliciet erbij)
+2. *De wachtlijstplaatsing van 18 juli is gericht op zorgprogramma "Trauma".* (nieuw, optioneel feit)
+3. *De wachtlijstplaatsing van 18 juli heeft prioriteit "normaal".* (= §5.3 #2)
+4. *De wachttijd van de aanmeldplaatsing telt vanaf de aanmelddatum 14 juli 2026.* (= §5.3 #3, verduidelijkt: de teldatum is een eigen attribuut, standaard afgeleid van de aanmelddatum)
+5. *De wachtlijstplaatsing van 18 juli is op 20 augustus 2026 beëindigd met reden "intake gestart".* (= §5.3 #4)
+6. *Voor de zorgepisode van Jan de Vries is op 1 augustus 2026 een wachtlijstplaatsing van soort "behandel" aangemaakt voor afdeling Volwassenen; de wachttijd telt vanaf de datum van het eerste intakegesprek, 22 juli 2026.* (nieuw — de behandelwachttijd uit het §5.3-besluit als eigen feit)
+7. *De behandelplaatsing van 1 augustus is op 15 oktober 2026 beëindigd met reden "behandeling gestart".* (nieuw)
+8. *Bij de wachtlijstplaatsing is op 12 augustus 2026 een activiteit van type "cliënt geïnformeerd over Treeknorm-overschrijding" geregistreerd door medewerker K. Jansen, met toelichting "gewezen op zorgbemiddeling Zilveren Kruis".* (nieuw — LKS-plicht: cliënt informeren bij overschrijding en wijzen op zorgbemiddeling verzekeraar)
+9. *Bij de wachtlijstplaatsing is op 20 augustus 2026 een activiteit van type "overbruggingszorg afgesproken" geregistreerd.* (nieuw — LKS: regiebehandelaar beoordeelt overbruggingszorg voor de wachtende cliënt)
+10. *De wachtlijstplaatsing is van 1 t/m 14 september 2026 opgeschort met reden "op verzoek cliënt".* (nieuw — cliënt kiest zelf voor uitstel; apart geregistreerd zodat bruto- én netto-wachttijd berekenbaar blijven)
+11. *De prioriteit van de wachtlijstplaatsing is op 5 augustus 2026 gewijzigd van "normaal" naar "spoed" na herbeoordeling.* (nieuw — mutatie, loopt via audit + activiteit "herbeoordeling prioriteit")
+12. *(nudge) Bij (dreigende) overschrijding van de Treeknorm van de plaatsingssoort volgt een signaal.* (= §5.3 #5, gegeneraliseerd naar beide soorten: aanmeld 4 weken, behandel 10 weken)
+13. *(afleiding) De aanmeldingswachttijd van de plaatsing bedraagt 5 weken (van teldatum tot beëindiging met reden "intake gestart", minus opschortingen indien netto gerekend).* (nieuw — geen opgeslagen feit maar een gedefinieerde afleiding, zie §6.1)
+
+---
+
+## 2. Entiteiten
+
+### 2.1 WACHTLIJSTPLAATSING
+
+**Doel:** vastleggen dat een cliënt op enig moment wacht — vóór de intake (aan de AANMELDING, aanmeldwachttijd) of na de intake wachtend op behandeling (aan de ZORGEPISODE, behandelwachttijd) — met de dimensies die de Treeknorm-bewaking en de NZa-wachttijdaanlevering nodig hebben.
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `id` | uuid | ja | stabiele identiteit (spelregel 3.1 #5) |
+| `soort` | FK → waardelijst `wachtlijst_soort` | ja | `aanmeld` / `behandel` (besluit §5.3) |
+| `aanmelding_id` | FK → AANMELDING | conditioneel | verplicht bij soort `aanmeld`, leeg bij `behandel` |
+| `zorgepisode_id` | FK → ZORGEPISODE | conditioneel | verplicht bij soort `behandel`, leeg bij `aanmeld` |
+| `afdeling_id` | FK → waardelijst AFDELING | ja | organisatorische eenheid waarvoor gewacht wordt (§5.2 besluit #2) |
+| `zorgprogramma_id` | FK → waardelijst ZORGPROGRAMMA | nee | inhoudelijk aanbod waarvoor gewacht wordt; optioneel (zie §7 punt 1) |
+| `prioriteit_id` | FK → waardelijst `wachtlijst_prioriteit` | ja | default `normaal` |
+| `plaatsingsdatum` | date | ja | datum waarop de plaatsing is geregistreerd |
+| `teldatum` | date | ja | datum waarop de wachttijd begint te tellen; default afgeleid (aanmeld → aanmelddatum AANMELDING; behandel → datum eerste intakegesprek van de episode), overschrijfbaar met auditspoor |
+| `status` | FK → statusmachine (§5) | ja | `actief` / `opgeschort` / `beëindigd` |
+| `einddatum` | date | conditioneel | verplicht bij status `beëindigd`, anders leeg |
+| `beeindigingsreden_id` | FK → waardelijst `wachtlijst_beeindigingsreden` | conditioneel | verplicht bij status `beëindigd`, anders leeg |
+| `toelichting` | text | nee | vrije tekst |
+| `deleted_at` | timestamp | nee | soft delete (spelregel 3.1 #4) |
+| audit-velden | — | ja | created_at/by, updated_at/by; mutaties append-only in audittrail (3.1 #3) |
+
+**Uniciteitsregels:**
+- Precies één van `aanmelding_id` / `zorgepisode_id` gevuld, consistent met `soort` (check-constraint — regel in het model, spelregel 3.1 #7).
+- Maximaal één plaatsing met status ≠ `beëindigd` per (`aanmelding_id`, `soort`) resp. (`zorgepisode_id`, `soort`) — partial unique index. Historie (meerdere beëindigde plaatsingen na heropening) blijft mogelijk. Zie §7 punt 4 voor de vraag of parallel wachten op meerdere afdelingen ooit nodig wordt.
+- `einddatum` ≥ `teldatum` (check-constraint).
+
+### 2.2 WACHTLIJSTACTIVITEIT
+
+**Doel:** gebeurtenissen tijdens het wachten vastleggen. Uit het procesonderzoek (§4.3–4.4): informeren van de cliënt bij Treeknorm-overschrijding, wijzen op zorgbemiddeling van de verzekeraar en overbruggingszorg-afspraken zijn LKS-plichten die aantoonbaar in het dossier horen. Zelfde patroon als SCREENINGSACTIVITEIT (discovery §5.2 besluit #3): type uit waardelijst + vrije toelichting, zodat nudges mogelijk zijn ("Treeknorm overschreden maar cliënt nog niet geïnformeerd").
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `id` | uuid | ja | |
+| `wachtlijstplaatsing_id` | FK → WACHTLIJSTPLAATSING | ja | |
+| `type_id` | FK → waardelijst `wachtlijst_activiteittype` | ja | |
+| `datum` | date | ja | |
+| `uitgevoerd_door` | FK → MEDEWERKER | ja | rollenronde bepaalt wie welk type mag registreren |
+| `toelichting` | text | nee | |
+| `deleted_at` / audit-velden | — | — | conform spelregels |
+
+**Uniciteit:** geen natuurlijke uniciteit buiten `id`; hetzelfde activiteitstype mag vaker voorkomen (cliënt kan meermaals geïnformeerd worden).
+
+### 2.3 WACHTLIJSTOPSCHORTING
+
+**Doel:** perioden vastleggen waarin het wachten niet aan de aanbieder ligt (cliënt kiest bewust een latere datum, is tijdelijk niet beschikbaar). Door opschortingen apart te registreren blijven zowel bruto-wachttijd (NZa-definitie rekent in kale weken) als netto-wachttijd (interne sturing) afleidbaar — het model dwingt geen rekenkeuze af (zie §7 punt 5).
+
+| Attribuut | Type | Verplicht | Toelichting |
+|---|---|---|---|
+| `id` | uuid | ja | |
+| `wachtlijstplaatsing_id` | FK → WACHTLIJSTPLAATSING | ja | |
+| `begindatum` | date | ja | |
+| `einddatum` | date | nee | leeg zolang de opschorting loopt |
+| `reden_id` | FK → waardelijst `wachtlijst_opschortingsreden` | ja | |
+| `toelichting` | text | nee | |
+| `deleted_at` / audit-velden | — | — | |
+
+**Uniciteitsregels:** opschortingen van dezelfde plaatsing mogen niet overlappen (exclusion-constraint op de periode); maximaal één opschorting zonder `einddatum` per plaatsing.
+
+---
+
+## 3. Relaties met cardinaliteit
+
+| Relatie | Cardinaliteit | Toelichting |
+|---|---|---|
+| AANMELDING — WACHTLIJSTPLAATSING (soort `aanmeld`) | 1 — 0..n | historie mogelijk; max 1 niet-beëindigd (§2.1). Aanmeldwachttijd hangt aan de AANMELDING (besluit §5.3 + §5.1 #9) |
+| ZORGEPISODE — WACHTLIJSTPLAATSING (soort `behandel`) | 1 — 0..n | idem; behandelwachttijd hangt aan de ZORGEPISODE. Episode ontstaat bij uitkomst `intake` (open detail §5.1 #9; het procesonderzoek §10.3 ondersteunt precies deze verdeling: aanmeldwachttijd op de aanmelding, episode pas bij intake) |
+| WACHTLIJSTPLAATSING — AFDELING | n — 1 | verplichte dimensie |
+| WACHTLIJSTPLAATSING — ZORGPROGRAMMA | n — 0..1 | optionele dimensie |
+| WACHTLIJSTPLAATSING — WACHTLIJSTACTIVITEIT | 1 — 0..n | |
+| WACHTLIJSTPLAATSING — WACHTLIJSTOPSCHORTING | 1 — 0..n | niet-overlappend |
+| WACHTLIJSTACTIVITEIT — MEDEWERKER | n — 1 | entiteit MEDEWERKER volgt in de rollenronde; hier alleen de referentie |
+| AFDELING — VESTIGING | n — 0..1 | **voorgesteld nieuw attribuut** op de waardelijst AFDELING t.b.v. de NZa-uitsplitsing per vestigingslocatie (§6.2); zie §7 punt 2 |
+
+**Samenhang met de aanmelding-uitkomst `wachtlijst` (besluit §5.1 #5):** uitkomst `wachtlijst` en het bestaan van een actieve aanmeldplaatsing zijn twee feiten die bij elkaar horen maar niet hetzelfde zijn. Consistentie wordt een nudge ("uitkomst wachtlijst zonder actieve wachtlijstplaatsing"), geen schema-koppeling — zelfde patroon als verwijsbrief (§5.1 #7) en screening-vóór-intake (§5.2 #4). Omgekeerd bij de behandelkant: intake-uitkomst `in_zorg` zonder direct gestarte behandeling → nudge "behandelwachttijd nog niet geregistreerd".
+
+---
+
+## 4. Waardelijsten
+
+Alle lijsten volgen de spelregels: referentietabel, één bron voor UI en database (3.1 #1), en per rij optioneel `externe_code`, `codesysteem_uri`, `geldig_van`, `geldig_tot` (les uit onderzoek-leveranciers §7.1 en onderzoek-standaarden §8: NZa-achtige lijsten hebben geldigheidsperioden).
+
+### 4.1 `wachtlijst_soort`
+
+| Code | Omschrijving | `drager` | `telt_vanaf` | `treeknorm_weken` |
+|---|---|---|---|---|
+| `aanmeld` | Aanmeldwachttijd | AANMELDING | aanmelddatum | 4 |
+| `behandel` | Behandelwachttijd | ZORGEPISODE | datum eerste intakegesprek | 10 |
+
+De Treeknorm zit als **attribuut op de waardelijst**, niet in code — de totaalnorm (14 weken) is afleidbaar. Bron: Treeknormen (onderzoek-proces §4.1); NZa-definities aanmeldings-/behandelingswachttijd (§4.2) vallen samen met deze twee soorten.
+
+### 4.2 `wachtlijst_prioriteit`
+
+Startwaarden: `spoed`, `normaal`, `laag` (conform het roadmap-idee uit discovery §5.3; praktijk kent urgentie-inschatting al bij screening — onderzoek-proces §3). Attribuut `sorteervolgorde` (int). Instellingsconfigureerbaar (Nedap-les, onderzoek-leveranciers §2.7: prioriteit/urgentie als configureerbare lijst).
+
+### 4.3 `wachtlijst_beeindigingsreden`
+
+Lost de tweede open vraag uit §5.3 op. Startlijst uit de praktijk (onderzoek-proces §4.4) plus attributen:
+
+| Code | Omschrijving | `geldig_voor_soort` | `zorg_gestart` |
+|---|---|---|---|
+| `intake_gestart` | Intake gestart | aanmeld | ja |
+| `behandeling_gestart` | Behandeling gestart | behandel | ja |
+| `intern_doorgeplaatst` | Doorgeplaatst naar andere afdeling/programma (nieuwe plaatsing volgt) | beide | nee |
+| `doorverwezen_extern` | Doorverwezen naar andere aanbieder | beide | nee |
+| `bemiddeld_verzekeraar` | Via zorgbemiddeling verzekeraar elders geplaatst | beide | nee |
+| `client_trekt_terug` | Cliënt trekt zich terug | beide | nee |
+| `geen_contact` | Geen contact meer te krijgen met cliënt | beide | nee |
+| `overleden` | Cliënt overleden | beide | nee |
+| `administratief_vervallen` | Plaatsing onterecht/dubbel aangemaakt | beide | nee |
+| `overig` | Anders, zie toelichting | beide | nee |
+
+- `geldig_voor_soort` (aanmeld/behandel/beide) voorkomt betekenisloze combinaties ("behandeling gestart" op een aanmeldplaatsing) als datagedreven regel, niet hardcoded.
+- `zorg_gestart` (ja/nee) markeert de redenen die meetellen in de retrospectieve NZa-wachttijdberekening (gerealiseerde wachttijd van cliënten die daadwerkelijk zijn ingestroomd, §6.1).
+- Patroon "overig + verplichte toelichting" volgt het zib-ontwerppatroon "anders-optie met specificatieveld" (onderzoek-standaarden §2.2).
+
+### 4.4 `wachtlijst_activiteittype`
+
+Startwaarden: `client_geinformeerd_treeknorm` (LKS-plicht), `gewezen_op_zorgbemiddeling` (LKS-plicht), `overbruggingszorg_afgesproken` (LKS: regiebehandelaar beoordeelt overbruggingszorg), `contactmoment` (tussentijds contact met wachtende), `herbeoordeling_prioriteit`, `overig`.
+
+### 4.5 `wachtlijst_opschortingsreden`
+
+Startwaarden: `verzoek_client` (cliënt kiest latere datum), `client_niet_beschikbaar` (vakantie, detentie, opname elders), `overig`.
+
+---
+
+## 5. Statusmachine WACHTLIJSTPLAATSING
+
+Conform spelregel 3.1 #9: statussen en overgangen als data (referentietabel `wachtlijst_status` + overgangstabel), niet in schermcode.
+
+| Van | Naar | Trigger/betekenis |
+|---|---|---|
+| — | `actief` | plaatsing aangemaakt (begintoestand) |
+| `actief` | `opgeschort` | WACHTLIJSTOPSCHORTING zonder einddatum geopend |
+| `opgeschort` | `actief` | lopende opschorting krijgt einddatum |
+| `actief` | `beëindigd` | einddatum + beëindigingsreden gezet |
+| `opgeschort` | `beëindigd` | idem; lopende opschorting wordt daarbij afgesloten |
+| `beëindigd` | `actief` | heropening (correctie of cliënt meldt zich terug); consistent met de flexibele-statusfilosofie van §5.1 #5. Heropening wist einddatum/reden en logt append-only |
+
+De status `opgeschort` is afleidbaar uit een open WACHTLIJSTOPSCHORTING; hij staat toch expliciet op de plaatsing zodat lijstweergaven en nudges niet hoeven te joinen en de statusmachine compleet is. Consistentie (status ↔ open opschorting) is een check-constraint/trigger.
+
+**Wie mag welke overgang zetten: expliciet doorgeschoven naar de rollenronde** (zelfde lijn als discovery §5.1 #6). Kandidaat om daar te bespreken: beëindigen met reden `overleden` en heropenen als beperkte acties.
+
+Prioriteitswijziging (feitzin 11) is géén statusovergang: het is een attribuutmutatie met auditspoor plus optioneel een activiteit `herbeoordeling_prioriteit`.
+
+---
+
+## 6. Treeknormen, NZa-aanlevering en ECD/TIP-eigenaarschap
+
+### 6.1 Afleidbaarheid van de wachttijden (geen opgeslagen velden)
+
+De verplichte cijfers zijn **afleidingen** uit het model, geen extra administratie:
+
+- **Wachttijd per plaatsing (bruto)** = weken tussen `teldatum` en `einddatum` (lopend: peildatum). Dit volgt de NZa-definities: aanmeldingswachttijd = weken tussen eerste afspraak/aanmelding en het moment dat de cliënt terecht kan voor intake; behandelingswachttijd = weken tussen eerste intake en start behandeling (onderzoek-proces §4.2).
+- **Netto-variant** = bruto minus de som van WACHTLIJSTOPSCHORTING-perioden (voor interne sturing; zie §7 punt 5).
+- **Retrospectieve NZa-aanlevering** (berekeningswijze 1): gemiddelde bruto-wachttijd van plaatsingen die in de laatste twee maanden zijn beëindigd met een reden waar `zorg_gestart = ja`, uitgesplitst per **vestigingslocatie** (via AFDELING → VESTIGING) en per **hoofddiagnosegroep** (alleen g-ggz; via de hoofddiagnose van de gestarte ZORGEPISODE — voor aanmeldplaatsingen de episode die uit de aanmelding is voortgekomen). Maandelijks, uiterlijk de 10e, via het NZa Zorgbeeldportaal; eenlocatie-aanbieders zijn per 2026 vrijgesteld (afleiding uit declaratiedata).
+- **Actuele berekeningswijze** (berekeningswijze 2: "derde beschikbare mogelijkheid in de agenda") komt niet uit de wachtlijst maar uit de agenda — agenda-ronde. Het model hoeft die keuze niet af te dwingen; de aanbieder kiest de methode.
+- **Treeknorm-bewaking**: (peildatum − `teldatum`) > `treeknorm_weken` van de soort ⇒ overschrijding. Nudges: `signaal` bij dreigende overschrijding (bijv. 75% van de norm), `waarschuwing` bij overschrijding zonder activiteit `client_geinformeerd_treeknorm` (LKS-plicht), `signaal` voor overbruggingszorg-beoordeling bij lopende behandelplaatsing (regiebehandelaar eerstverantwoordelijk).
+
+Benodigde dimensies die (nog) buiten dit deelgebied liggen: **vestiging** (§7 punt 2), **echelon gb-ggz/g-ggz** op de aanmelding (§7 punt 6; hoofddiagnosegroep-uitsplitsing geldt alleen g-ggz) en **zorgverzekeraar** (alleen bij omzetplafond-afhankelijke wachttijden; declaratie-ronde, §7 punt 7).
+
+### 6.2 Eigenaarschap en events richting TIP (conform §3.3)
+
+**Eigenaarschap: WACHTLIJSTPLAATSING, -ACTIVITEIT en -OPSCHORTING zijn leidend in het ECD.** Het zijn dossier-/registratiefeiten met wettelijke bewijsfunctie (LKS: aantoonbaar informeren; NZa: bron van de aanlevering). TIP houdt er geen kopie-administratie op na buiten de afgesproken snapshot-/IE-mechanismen (afstemming Joshua, §3.3).
+
+**Events ECD → TIP** (zelfde mutatie-eventmechanisme als her-embedding, §3.2/§3.3 punt 4):
+
+| Event | Payload (minimaal) | TIP-gebruik |
+|---|---|---|
+| `wachtlijstplaatsing.aangemaakt` | plaatsing-id, soort, drager-id, afdeling, zorgprogramma, prioriteit, teldatum | start Treeknorm-bewaking (timer/nudgeplanning) |
+| `wachtlijstplaatsing.prioriteit_gewijzigd` | plaatsing-id, oud/nieuw | herprioritering werkvoorraad |
+| `wachtlijstplaatsing.opgeschort` / `.hervat` | plaatsing-id, periode, reden | Treeknorm-timer pauzeren/hervatten (indien netto-bewaking gekozen) |
+| `wachtlijstplaatsing.beeindigd` | plaatsing-id, einddatum, reden, zorg_gestart | bewaking stoppen; instroom-funnel-statistiek |
+| `wachtlijstactiviteit.geregistreerd` | activiteit-id, plaatsing-id, type, datum | plicht-nudges afvinken (cliënt geïnformeerd, overbrugging geregeld) |
+
+**Proces-state die bij TIP hoort, niet in het ECD:** de Treeknorm-timers zelf, de taak "NZa-aanlevering klaarzetten vóór de 10e" en de opvolging van nudges. Het ECD levert de feiten; TIP de bewaking en beslislogica. De maandelijkse aanleverset zelf is een afgeleide rapportage (view/export) uit het ECD — als het verzendmoment vastgelegd moet worden, is dat een auditfeit, geen nieuwe entiteit.
+
+---
+
+## 7. Open besluitpunten voor Colin
+
+1. **Afdeling verplicht, zorgprogramma optioneel — bevestigen.** Advies: zo doen. De afdeling is de organisatorische eenheid waar capaciteit en wachtlijstbeheer leven (discovery §5.2 besluit #2); het zorgprogramma is een verfijning die niet altijd bekend is bij plaatsing. "Beide" als twee optionele velden zonder verplichting zou de NZa-afleiding en de nudges hun ankerdimensie ontnemen. Wat kan misgaan: instellingen die puur programma-gericht werken moeten dan een (rest)afdeling kiezen — acceptabel, afdelingen zijn per instelling configureerbaar.
+2. **VESTIGING als waardelijst + optionele koppeling AFDELING → VESTIGING nu al opnemen?** De NZa-aanlevering splitst per vestigingslocatie (clustering binnen gemeente/10 km toegestaan). Advies: waardelijst VESTIGING nu aanmaken met optionele FK op AFDELING; verplicht maken zodra de aanleverexport gebouwd wordt. Alternatief (vestiging pas in de ADM-ronde) maakt de aanlevering tijdelijk niet afleidbaar.
+3. **Startlijst beëindigingsredenen (§4.3) bevestigen**, inclusief de attributen `geldig_voor_soort` en `zorg_gestart`. Advies: overnemen; de lijst komt rechtstreeks uit praktijk + LKS/NZa (onderzoek-proces §4.4) en is instellingsuitbreidbaar (Nedap-les: configureerbare `closingReason`).
+4. **Max één niet-beëindigde plaatsing per drager per soort: harde constraint of aan/uit-bedrijfsregel?** Advies: harde partial-unique constraint (spelregel 3.1 #7). Parallel wachten op twee afdelingen tegelijk is in de praktijk een keuze-/bemiddelingsvraagstuk, geen registratiefeit; mocht het ooit nodig zijn, dan is de constraint versoepelen goedkoper dan dubbelingen opruimen. (Bewust strakker dan het parallelle-aanmeldingen-patroon §5.0 #5 — dáár ging het om meerdere zorgvragen, hier om dezelfde wachtvraag.)
+5. **Pauzeert een opschorting de Treeknorm-telling (netto) of niet (bruto)?** De NZa-definitie rekent in kale weken en kent geen expliciete pauzeregeling; het model registreert opschortingen apart zodat beide berekeningen mogelijk blijven. Advies: extern (NZa-aanlevering) bruto rapporteren, intern (nudges/sturing) netto bewaken — en dit als instellingsinstelling op de nudge-regel zetten, niet in het schema.
+6. **Echelon (gb-ggz/g-ggz) op de AANMELDING toevoegen** (verrijking uit onderzoek-proces §10.3 punt 3). Nodig omdat de hoofddiagnosegroep-uitsplitsing van de wachttijden alleen voor g-ggz geldt en het echelon op de verwijsbrief hoort te staan. Advies: overnemen in het instroom-deelgebied (hoort daar, niet bij de wachtlijst); hier alleen gesignaleerd als afhankelijkheid.
+7. **Zorgverzekeraar-dimensie** (alleen aanleveren als de wachttijd per verzekeraar verschilt, omzetplafonds). Advies: parkeren tot de declaratie-/financieringsronde; het model blokkeert niets omdat de verzekeraar t.z.t. via de financieringskant van de aanmelding afleidbaar wordt.
+8. **Aanmeldpauze/patiëntenstop** (praktijkfenomeen, instellings-/afdelingsniveau — onderzoek-proces §4.4). Geen cliëntgebonden feit maar capaciteitsconfiguratie. Advies: niet in dit deelgebied; kandidaat voor de ADM-/capaciteitsronde, eventueel als periode-attribuut op AFDELING.
+9. **Urgentie al bij de screening vastleggen** (vóór er een wachtlijstplaatsing is — onderzoek-proces §3/§10.3). Advies: screeningsbesluit uitbreiden met een optionele geadviseerde prioriteit uit dezelfde waardelijst `wachtlijst_prioriteit` (hergebruik, geen tweede lijst); besluit hoort formeel bij het screening-deelgebied.
+
+---
+
+## 8. Bronverwijzingen
+
+| Onderwerp | Bron |
+|---|---|
+| Besluit WACHTLIJSTPLAATSING eigen entiteit, twee momenten, soort-waardelijst; open vragen | `datamodel-discovery.md` §5.3; drager-besluiten §5.1 #9 (ZORGEPISODE), §5.1 #5 (uitkomst `wachtlijst`) |
+| Spelregels (waardelijsten, statusmachines, constraints, soft delete, audit) | `datamodel-discovery.md` §3.1 #1, #3, #4, #7, #9 |
+| TIP-grensvlak en eventmechanisme | `datamodel-discovery.md` §3.3 |
+| Treeknormen 4/10/14 weken; NZa-definities aanmeldings-/behandelingswachttijd; Transparantieregeling (uitsplitsing vestiging × hoofddiagnosegroep × evt. verzekeraar; maandelijks ≤ 10e; Zorgbeeldportaal; 2026: eenlocatie via declaratiedata); LKS-plichten (informeren, zorgbemiddeling, overbruggingszorg); beëindigingsredenen uit de praktijk | `onderzoek-proces.md` §4.1–4.4, §10.1 (rij 6 en 11), §10.3 |
+| Verwijsdatum op declaratie 2026 (IZA-wachttijdinzicht, verklaart automatische afleiding eenlocatie) | `onderzoek-proces.md` §2.10 |
+| Nedap-wachtlijst als "tijdelijke oplossing"; configureerbare waardelijsten voor prioriteit/wachtreden/beëindigingsreden | `../onderzoek/onderzoek-leveranciers.md` §2.7, §7.4 |
+| Waardelijst-patroon: externe code + codesysteem + geldigheidsperiode; "anders"-optie met specificatieveld | `../onderzoek/onderzoek-standaarden.md` §2.2 (BehandelAanwijzing2-patroon), §8; `../onderzoek/onderzoek-leveranciers.md` §7.1 |
+| Episode-ontstaan bij intake ondersteunt aanmeldwachttijd-op-aanmelding | `onderzoek-proces.md` §10.3 (open-vragensectie) |
+| Standaarden extern: NZa Transparantieregeling (NR/REG-2024 e.v.), LKS GGZ 4.0, Treeknormen (veldnorm) | via bronnenlijsten van de onderzoeksrapporten |