triqura-ecd/docs/datamodel/deelmodellen/model-intake.md

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