docs(datamodel): FCO-IM feitenronde instroom, besluitenlog + herstructurering

Voegt de discovery- en besluitvormingsronde van 18-19 juli toe (besluitenlog,
begrippenlijst, feitenmodel-instroom met scenariotoetsen, terminologie- en
leveranciersonderzoek) en synchroniseert feitenmodel-instroom.md met de
screening=acceptatie-beslissing (§5). Herstructureert docs/datamodel/ naar
submappen per documentsoort (besluiten/sessielogs/feitenmodellen/deelmodellen/
onderzoek/entiteitenkaarten) zodat toekomstige besluitenlogs en feitenrondes
per deelgebied een vaste plek krijgen.

docs/datamodel/deelmodellen/model-screening.md

@@ -0,0 +1,269 @@
+# 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" |