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

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