docs(datamodel): discovery uitgebreid t/m behandelplan + sessielog 17 juli

- datamodel-discovery.md: scopeverbreding ronde 1 (wachtlijst, diagnose,
  behandelplan), besluiten zorgepisode als eigen entiteit, DSM-5-TR
  primair met ICD-10-mapping, wachtlijstplaatsing op twee momenten
  (Treeknormen), behandelplan-kern; bevindingen prototype-verkenning
- entiteitenkaart-instroom.html: samenhang-diagram (aanmelding als
  besluitproces vs zorgepisode als periode van zorg), diagram 3 met
  wachtlijst/diagnose/behandelplan, nieuwe waardelijsten
- sessielog 17 juli: 13 besluiten, bevindingen en open vragen

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/datamodel/datamodel-discovery.md

@@ -60,7 +60,9 @@ Het datamodel ontwerpen we volledig op eigen termen, vanuit de feitzinnen. FHIR,
 - **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: instroomflow
+## 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)
 
@@ -96,26 +98,101 @@ Het datamodel ontwerpen we volledig op eigen termen, vanuit de feitzinnen. FHIR,
 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 (volgende ronde — nog te bespreken)
+### 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. *Screeningsactiviteit "telefonisch contact" is op 16 juli 2026 uitgevoerd door verpleegkundige K. Jansen.*
-3. *Het screeningsbesluit voor de aanmelding van Jan de Vries luidt "geschikt voor afdeling Volwassenen".*
-4. *Voor cliënt Jan de Vries is op 20 juli 2026 een intake gestart op afdeling Volwassenen.*
-5. *De intake van Jan de Vries heeft status "bezig".*
-6. *Het intakegesprek van 22 juli 2026 is gevoerd door psycholoog M. de Boer.*
-7. *De kindcheck voor de intake van Jan de Vries is uitgevoerd met uitkomst "geen minderjarige kinderen".*
-8. *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.*
+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.*
 
-Vragen voor die ronde:
-- Is een screening verplicht vóór elke intake, of kan die worden overgeslagen (bijv. bij crisis)?
-- Wat maakt een intake "afgerond" — en wie mag dat besluiten?
-- Welke afdelingen bestaan er echt (screening bood er 5, intake accepteerde er 3)?
+**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