# Datamodelvoorstel — Deelgebied Intake

**Status:** **vervangen door `model-intake-behandeladvies.md`** (19 juli
2026) — Engelstalige entiteiten, gecorrigeerde episode-timing (intake start
ná het acceptatiebesluit, niet bij aanmelding-uitkomst "intake"), en het
behandeladvies uitgewerkt als eigen `treatment_advice`-object in plaats van
platte velden op INTAKE. Deze tekst blijft als historisch werkdocument
staan — de kindcheck-/contactmoment-inhoud is grotendeels 1-op-1 hergebruikt
(niet-destructief), gebruik dit document zelf niet als basis voor SQL.
**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 | **vervallen** — context uit §5.1 #9: episode ontstaat bij aanmelding-uitkomst `intake`; afgewezen aanmelding heeft nooit een episode. Overruled door B22: de episode ontstaat al bij het acceptatiebesluit zelf, zie `model-instroom.md` §2.18. |
| 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. **Niet gevolgd — herzien door B22 (19 juli 2026):** de episode ontstaat al bij het acceptatiebesluit zelf, óók bij vervolgroute intakewachtlijst, niet pas bij aanmelding-uitkomst "intake". Zie `model-intake-behandeladvies.md` §1.1.
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 |
