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