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/sessielogs/sessielog-2026-07-18.md

@@ -0,0 +1,432 @@
+# Sessielog datamodel — 18 juli 2026
+
+**Status:** chronologisch werkverslag  
+**Doel:** context, redenering, correcties en voortgang van de sessie bewaren  
+**Autoriteit:** dit sessielog is niet normatief; `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft leidend voor genomen besluiten  
+**Vervolg:** eerste FCO-IM-feitenronde voor referral/instroom
+
+## 1. Aanleiding
+
+De sessie begon met een beoordeling van de bestaande map `docs/datamodel`. De map bleek een FCO-IM-geïnspireerde discovery en modelleursronde voor het GGZ-ECD te bevatten, van aanmelding tot behandelplan.
+
+De eerste analyse identificeerde:
+
+- een bruikbare scheiding tussen ECD-feiten en TIP-procesbewaking;
+- een voorgestelde ZORGEPISODE als klinisch anker;
+- uitgewerkte modellen voor aanmelding, screening, intake, wachtlijst, diagnose, behandelplan en rapportage;
+- ontbrekende of nog niet uitgewerkte rollen, autorisatie, agenda en declaratie;
+- een achterlopende HTML-entiteitenkaart;
+- een ontbrekend `onderzoek-proces.md`;
+- onderlinge spanningen rond episodevorming, toestemming, wachtlijst en behandelplanversies.
+
+Afgesproken werd de open beslispunten eerst integraal te verzamelen en daarna één voor één inhoudelijk te bespreken.
+
+## 2. Aanmelding, acceptatie en zorgepisode
+
+### 2.1 Financiële en zorginhoudelijke start
+
+Colin corrigeerde het aanvankelijke voorstel dat een zorgepisode eenvoudig bij de uitkomst `intake` ontstaat.
+
+Belangrijke praktijkinzichten:
+
+- de financiële start en zorginhoudelijke start zijn niet hetzelfde;
+- een aanmeldfase kan tot behandeling leiden, maar hoeft dat niet;
+- eerdere aanmeldingen kunnen voor latere zorg relevant zijn;
+- de zorgpraktijk is minder lineair dan regels en datamodellen vaak suggereren;
+- bewaarplicht en bewaardoel verschillen naar gelang daadwerkelijk zorg tot stand komt.
+
+Hieruit volgde de scheiding tussen:
+
+1. aanmelding en institutionele beoordeling;
+2. zorginhoudelijke episode;
+3. financieel traject.
+
+De zorgepisode ontstaat bij een formeel acceptatiebesluit. Daarbij is expliciet vastgelegd dat acceptatie alleen toegang tot het zorgproces betekent en niet automatisch een behandelovereenkomst, zorgplicht, toegewezen behandelaar of organisatorische verantwoordelijkheid bewijst.
+
+Na afsluiting leidt terugkeer tot een nieuwe, gerelateerde zorgepisode. Een historische relatie geeft nooit automatisch inzage.
+
+### 2.2 Instellingbrede episode
+
+Colin verduidelijkte dat één zorgepisode binnen een instelling meerdere zorgprogramma’s en organisatorische eenheden kan omvatten.
+
+Daarom:
+
+- opent een interne overdracht niet automatisch een nieuwe episode;
+- worden programma- en organisatiebetrokkenheid tijdgebonden relaties;
+- zijn meerdere gelijktijdige episodes technisch mogelijk, maar binnen één instelling een gemotiveerde uitzondering;
+- worden autorisatie en historische episodekoppeling afzonderlijk gemodelleerd.
+
+## 3. Binnenkomsten en aanmeldingstrajecten
+
+De mogelijkheid van meerdere aanmeldingen bleek een terminologisch en conceptueel probleem. Een cliënt kan informatie vanuit meerdere stromen of instanties ontvangen, maar iedere binnenkomst hoeft geen nieuw institutioneel traject te openen.
+
+Daarom werd onderscheid gemaakt tussen:
+
+- **aanmeldsignaal:** iedere afzonderlijke binnenkomst;
+- **aanmeldingstraject:** de institutionele beoordeling van één samenhangende zorgvraag.
+
+De UX moet bij overlap ondersteunen:
+
+- koppelen aan een bestaand traject;
+- een parallel traject starten met reden;
+- als duplicaat registreren;
+- logisch samenvoegen.
+
+Samenvoegen blijft niet-destructief. Alle oorspronkelijke bronnen en auditinformatie blijven behouden. AI mag matches voorstellen, maar nooit zelfstandig samenvoegen.
+
+Later in de sessie is de Engelse terminologie voor deze begrippen opnieuw onderzocht; zie §10.
+
+## 4. Intake
+
+De intake werd aangescherpt tot één dynamisch onderzoekstraject per samenhangende zorgvraag.
+
+Een intake kan bestaan uit:
+
+- meerdere gesprekken en contacten;
+- meerdere onderzoeken;
+- meerdere disciplines;
+- meerdere bevindingen en bijdragen.
+
+Een intern afdelingscontact of organisatorische overgang is geen nieuwe intake. Parallelle intakes zijn alleen zinvol voor aantoonbaar verschillende zorgvragen.
+
+Open blijft of de intake altijd na formele acceptatie begint of deels vóór acceptatie kan plaatsvinden. Dat bepaalt of intake primair aan het aanmeldingstraject, de zorgepisode of een overgang tussen beide hangt.
+
+## 5. Wachtlijst
+
+De aanvankelijke modellering van wachtlijstplaatsing met status en opschortingsperioden bleek te eenvoudig voor de GGZ-wachtlijstproblematiek.
+
+Vastgelegde uitgangspunten:
+
+- de volledige tijdlijn blijft behouden;
+- oorspronkelijke aanmeld- en wachtdatum worden niet overschreven;
+- bruto wachttijd blijft altijd zichtbaar;
+- netto of gecorrigeerde wachttijd is een versiegebonden afleiding;
+- verplaatsing tussen teams of programma’s mag wachttijd niet ongemerkt resetten;
+- capaciteitstekort en cliëntgebonden uitstel moeten afzonderlijk herkenbaar zijn.
+
+Nog te onderzoeken:
+
+- regulatoire wachttijd versus operationele wachtrij;
+- teldatums;
+- aftrekbare perioden;
+- aanbodmomenten;
+- prioritering;
+- beëindigingsredenen;
+- actuele NZa-regels en Treeknormrapportage;
+- cardinaliteiten van wachtlijstplaatsingen.
+
+Conclusie: er is genoeg basis om het overkoepelende model voort te zetten, maar het huidige wachtlijstmodel is niet bouwrijp.
+
+## 6. Behandelplan
+
+Het behandelplan kreeg tijdens de sessie een fundamenteel andere opzet dan in het eerdere modelvoorstel.
+
+### 6.1 Eén logisch plan
+
+Colins praktijkervaring is dat deelplannen snel leiden tot wildgroei, afdelingsspecifieke documenten en verlies van gezamenlijk overzicht.
+
+Daarom:
+
+- bestaat per zorgepisode één logisch behandelplan;
+- dragen alle betrokken disciplines aan hetzelfde plan bij;
+- ontstaan geen afzonderlijke afdelings- of disciplineplannen;
+- worden verschillende behoeften opgelost met scopes, filters en weergaven;
+- blijft specialistische documentatie koppelbaar zonder concurrerend intern plan.
+
+### 6.2 Domeinmodel, geen formulier
+
+Het behandelplan wordt geen plat formulier. De stabiele kern bestaat uit:
+
+- aandachtgebieden;
+- doelen;
+- interventies en afspraken;
+- betrokkenen en verantwoordelijkheden;
+- evaluaties;
+- cliëntperspectief en verschillen van inzicht.
+
+Een aandachtgebied kan meerdere perspectieven hebben:
+
+- klacht of diagnose;
+- leefgebied;
+- kracht of beschermende factor;
+- risico;
+- herstel;
+- preventie.
+
+Dit voorkomt dat één instellingsvisie als rigide formulier op alle afdelingen wordt geprojecteerd.
+
+### 6.3 Preventie
+
+Colin benoemde preventie als een onderscheidend thema voor een EPD, juist omdat financieringsmodellen slecht aansluiten op onderwerpen als eenzaamheid, systeem, omgeving en maatschappij.
+
+Preventie wordt daarom een volwaardig perspectief binnen het behandelplan, bijvoorbeeld voor:
+
+- eenzaamheid en sociale verbinding;
+- beschermende factoren;
+- netwerkversterking;
+- vroegsignalering;
+- terugvalpreventie;
+- bewezen helpende strategieën.
+
+Dataminimalisatie blijft een randvoorwaarde: het EPD wordt geen onbeperkt sociaal dossier.
+
+### 6.4 Levend plan en snapshots
+
+Het behandelplan houdt één identiteit tijdens de episode.
+
+- Het werkplan blijft dynamisch.
+- Iedere wijziging krijgt auteurschap en audit.
+- Niet iedere wijziging maakt een nieuw plan.
+- Formele vaststelling, evaluatie en cliëntbespreking leveren onveranderlijke snapshots op.
+- Eerdere snapshots blijven reproduceerbaar.
+
+Dit vervangt het eerdere voorstel waarin iedere planversie een volledig nieuw BEHANDELPLAN-record was.
+
+### 6.5 Procespositie
+
+De hoofdroute is:
+
+```text
+intakebevindingen
+→ conceptplan
+→ MDO
+→ bespreking met cliënt
+→ vastgestelde snapshot
+→ uitvoering en periodiek MDO
+→ formele evaluatie
+→ bijgesteld plan en nieuwe snapshot
+→ afsluiting
+```
+
+Een halfjaarlijkse evaluatie wordt een configureerbare protocolregel. TIP bewaakt de termijn; het ECD bewaart het feit en de uitkomst.
+
+### 6.6 Cliëntakkoord
+
+Planakkoord en behandeltoestemming zijn afzonderlijke concepten.
+
+Per plansnapshot kan worden vastgelegd:
+
+- akkoord;
+- gedeeltelijk akkoord;
+- niet akkoord;
+- akkoord niet verkregen;
+- toelichting en bezwaren;
+- vertegenwoordiging indien van toepassing.
+
+Geen akkoord met het behandelplan blokkeert niet automatisch iedere zorg. Behandeling vereist echter wel toestemming of een expliciete geldige juridische grondslag. Een institutioneel besluit is geen generieke bypass.
+
+## 7. MDO, evaluatie en bevoegdheid
+
+Colin verduidelijkte dat MDO en evaluatie dynamische processen zijn.
+
+Een MDO omvat:
+
+- casusinbreng;
+- vraagstelling;
+- triage en agendering;
+- voorbereiding;
+- sessie en panel;
+- feitelijke deelnemers;
+- gedeelde analyse;
+- advies, besluit of nader onderzoek;
+- actiepunten;
+- planwijzigingsvoorstellen.
+
+Een formele evaluatie is een vergelijkbaar cliëntgericht proces en kan een MDO-bespreking bevatten, maar is niet hetzelfde als een MDO.
+
+Het MDO is niet altijd besluitvormend. Bevoegdheid wordt daarom gekoppeld aan:
+
+- het besluittype;
+- de actuele teamrol;
+- professionele kwalificaties;
+- eventuele consultatie- of quorumeisen.
+
+Professie, teamrol en bevoegdheid blijven afzonderlijke begrippen. Een psychiater of psycholoog is niet uitsluitend door de professie automatisch regiebehandelaar.
+
+## 8. Longitudinale cliëntinformatie en rapportage
+
+Een voorgeschiedenis maakte duidelijk dat sommige informatie episode-overstijgend relevant is.
+
+Vastgelegd is:
+
+- het behandelplan blijft episodegebonden;
+- geselecteerde informatie kan longitudinaal worden;
+- ieder longitudinaal gegeven heeft bron, bronepisode, geldigheid, actualiteit, reviewdatum en eigen autorisatie;
+- er komt geen generieke `CLIENT_GEGEVEN`-vergaarbak;
+- concrete klinische concepten krijgen later eigen definities.
+
+Voor rapportage geldt:
+
+- iedere klinische rapportage heeft één primaire zorgepisode;
+- verwijzingen naar eerdere episodes of longitudinale informatie zijn mogelijk;
+- een verwijzing verleent geen toegang;
+- pre-acceptatieregistraties horen bij instroom/screening en vragen een eigen bewaarbeleid;
+- een MDO-verslag vervangt de MDO-workflow niet.
+
+## 9. Configureerbare behandelvisie
+
+Visie en taal worden configureerbaar zonder het klinische schema per instelling of afdeling te laten variëren.
+
+De configuratielaag bevat:
+
+- versiegebonden behandelvisieprofielen;
+- terminologie;
+- perspectieven en waardelijsten;
+- aanbevolen en verplichte onderdelen;
+- evaluatieprotocollen;
+- instellings- en afdelingsscope;
+- geldigheid en publicatiestatus.
+
+De klinische kern bewaart stabiele concepten. Plansnapshots verwijzen naar de gebruikte profielversie. Afdelingen mogen accenten toevoegen, maar maken geen eigen behandelplanmodel.
+
+## 10. Modellering, taal en terminologieonderzoek
+
+### 10.1 Methode
+
+Besloten is FCO-IM/NIAM-principes te behouden voor de conceptuele laag:
+
+- elementaire feitzinnen;
+- natuurlijke verbalisatie;
+- uniciteit en optionaliteit;
+- temporele geldigheid;
+- expliciete constraints.
+
+Dit wordt aangevuld met:
+
+- procesmodellen;
+- statecharts;
+- eventcatalogi;
+- beslissingstabellen;
+- logisch relationeel model;
+- traceerbaarheid van besluit naar constraint en test.
+
+Volledig formele ORM2-diagrammen zijn niet het doel; de bruikbare fact-oriented discipline staat centraal.
+
+### 10.2 Engelstalig technisch model
+
+Het uiteindelijke technische datamodel wordt Engelstalig:
+
+- entiteiten;
+- attributen;
+- relaties;
+- events;
+- API-velden;
+- constraints.
+
+Nederlandse UI-labels blijven configureerbaar. Officiële Nederlandse zorg- en wettelijke begrippen blijven met brondefinitie beschikbaar in een tweetalige begrippenlijst.
+
+### 10.3 Eerste begrippenlijst
+
+`../begrippenlijst-kernmodel.md` is opgesteld als versie 0.1. De eerste werktermen voor instroom waren:
+
+- `Inbound Care Signal`;
+- `Access Assessment Case`;
+- `Presenting Care Need`;
+- `Care Acceptance Decision`;
+- `Clinical Care Episode`.
+
+Colin gaf terecht aan dat de eerste twee termen onvoldoende duidend waren.
+
+### 10.4 Onderzoek Amerikaanse en Engelstalige EHR’s
+
+Onderzocht zijn:
+
+- Epic;
+- Oracle Health;
+- athenahealth;
+- Netsmart;
+- NextGen;
+- Qualifacts;
+- HL7 FHIR;
+- ONC/360X;
+- NHS-dataterminologie.
+
+Belangrijkste bevindingen:
+
+- generieke en behavioral-health EHR’s gebruiken vrijwel overal `Referral` als beheerd lifecycle-object;
+- `Referral Order` is vaak een provider-authored verzoek en te smal voor generieke instroom;
+- `ServiceRequest`, `Task`, `EpisodeOfCare` en `Encounter` hebben verschillende betekenissen;
+- `signal` is geen herkenbare EHR-term voor een ontvangen aanmelding;
+- `access assessment case` is begrijpelijk maar niet idiomatisch;
+- behavioral-healthsystemen spreken over incoming referrals, referral packets, referral intake en pre-admit;
+- de meeste GGZ-zorg is ambulant, waardoor `admission` en `pre-admission` ongeschikt zijn als generieke kernbegrippen.
+
+Het onderzoeksrapport staat in `../onderzoek/onderzoek-engelstalige-epd-terminologie.md`.
+
+### 10.5 Huidige voorkeursrichting
+
+De huidige, nog niet volledig in de begrippenlijst verwerkte voorkeursrichting is:
+
+```text
+referral_submission  — iedere afzonderlijke binnenkomst
+referral             — het beheerde aanmeldingstraject
+acceptance_decision  — formele acceptatie
+clinical_care_episode — geaccepteerde zorgperiode
+clinical_intake      — klinische intake
+```
+
+Een mogelijke `referral_request` blijft open. Eerst moet worden vastgesteld of de Nederlandse VERWIJZING een zelfstandig inhoudelijk verzoek is naast de ontvangen submission en de beheerde referral.
+
+De zorgsetting wordt geen onderdeel van de episodenaam, maar een afzonderlijk tijdgebonden kenmerk, bijvoorbeeld ambulant, outreach, dagbehandeling, residentieel of klinisch.
+
+## 11. Vastgelegde artefacten
+
+Tijdens deze sessie zijn toegevoegd:
+
+- `../besluiten/besluitenlog-datamodel-2026-07-18.md`;
+- `../begrippenlijst-kernmodel.md`;
+- `../onderzoek/onderzoek-engelstalige-epd-terminologie.md`;
+- `../entiteitenkaarten/ehr-referral-terminology.html`;
+- canvas `EHR-referral-terminology.canvas.tsx`.
+
+De volgende documenten kregen een waarschuwing dat ze geheel of gedeeltelijk zijn achterhaald:
+
+- `../deelmodellen/datamodel-discovery.md`;
+- `../deelmodellen/model-aanmelding.md`;
+- `../deelmodellen/model-screening.md`;
+- `../deelmodellen/model-intake.md`;
+- `../deelmodellen/model-wachtlijst.md`;
+- `../deelmodellen/model-behandelplan.md`;
+- `../deelmodellen/model-rapportage.md`.
+
+De HTML-entiteitenkaart is nog niet bijgewerkt. Die wordt pas opnieuw gegenereerd nadat de Markdown-deelmodellen zijn herzien.
+
+## 12. Open punten
+
+### Instroom
+
+- Is een inhoudelijk Referral Request een zelfstandig object?
+- Valt de Nederlandse VERWIJZING volledig samen met Referral Request?
+- Kan één request via meerdere submissions binnenkomen?
+- Kan één submission meerdere requests bevatten?
+- Welke intakehandelingen mogen vóór formele acceptatie plaatsvinden?
+- Wat zijn de statusmachine en bevoegdheden van het acceptatiebesluit?
+
+### Behandelplan en organisatie
+
+- Welke wijzigingen vereisen een formele snapshot?
+- Hoe wordt cliëntreactie bij gedeeltelijk akkoord precies gescopeerd?
+- Welke longitudinale informatietypen worden als eerste gemodelleerd?
+- Hoe werkt profielmigratie tijdens een lopende episode?
+- Welke bevoegdheidsmatrix geldt per besluittype?
+
+### Onderzoek
+
+- GGZ-wachtlijst en actuele NZa-definities;
+- bewaarbeleid vóór acceptatie en bij afwijzing;
+- juridische betekenis van acceptatie;
+- autorisatie op historische episodeverwijzingen;
+- externe terminologie voor longitudinale en behandelplanconcepten.
+
+## 13. Afgesproken volgende stap
+
+De volgende stap is een eerste FCO-IM-feitenronde voor referral/instroom.
+
+Doel:
+
+1. de voorkeursbegrippen verwerken;
+2. elementaire feiten voor request, submission, referral en acceptatie formuleren;
+3. uniciteit, optionaliteit, tijd en bevoegdheid per feit bepalen;
+4. scenario’s testen met huisartsverwijzing, zelfaanmelding, aanvullende informatie en dubbele instroom;
+5. op basis daarvan besluiten of `Referral Request` een eigen identiteit nodig heeft;
+6. pas daarna entiteiten, cardinaliteiten en een logisch ER-model afleiden.

docs/datamodel/sessielogs/sessielog-2026-07-19.md

@@ -0,0 +1,306 @@
+# Sessielog datamodel — 19 juli 2026
+
+**Status:** chronologisch werkverslag  
+**Doel:** context, redenering, correcties en voortgang van de sessie bewaren  
+**Autoriteit:** dit sessielog is niet normatief; bevestigde besluiten moeten nog worden verwerkt in `../besluiten/besluitenlog-datamodel-2026-07-18.md`  
+**Vervolg:** feitenmodel instroom synchroniseren en de uitkomsten van het behandeladvies bepalen
+
+## 1. Aanleiding
+
+De sessie vervolgde de op 18 juli afgesproken FCO-IM-feitenronde voor
+referral en instroom. Als werkdocument is `../feitenmodellen/feitenmodel-instroom.md`
+opgesteld. Het doel is eerst de elementaire domeinfeiten te bevestigen en pas
+daarna entiteiten, cardinaliteiten, statusmachines en SQL af te leiden.
+
+De ronde richtte zich op:
+
+- het inhoudelijke zorgverzoek;
+- afzonderlijke binnenkomsten;
+- het institutionele aanmeldingstraject;
+- de formele Nederlandse verwijzing;
+- screening, acceptatie en capaciteit;
+- de overgang naar zorginhoudelijke intake.
+
+## 2. Referral Request, Submission en Case
+
+### 2.1 Meerdere samenhangende zorgvragen
+
+Bevestigd is dat één `Referral Request` meerdere samenhangende geuite
+zorgvragen mag bevatten. Splitsing in afzonderlijke requests is pas nodig
+wanneer de zorgvragen afzonderlijk moeten worden beoordeeld.
+
+Daarmee is een request niet beperkt tot één klacht of één tekstveld. Het
+representeert één inhoudelijk verzoek om zorg of beoordeling met een
+samenhangende scope.
+
+### 2.2 Eén submission kan meerdere requests bevatten
+
+Eén `Referral Submission` kan meerdere inhoudelijke requests bevatten of
+representeren, bijvoorbeeld wanneer één ontvangen brief twee onafhankelijk
+te beoordelen verzoeken bevat.
+
+De relaties tussen submission en requests worden expliciet vastgelegd. De
+oorspronkelijke submission wordt niet gekopieerd of administratief gesplitst,
+omdat bron, ontvangstmoment en documentcontext behouden moeten blijven.
+
+### 2.3 Eén request kan uitzonderlijk in meerdere cases lopen
+
+Eén request kan bij uitzondering in meerdere `Referral Cases` worden
+behandeld wanneer verschillende proces- of wettelijke kaders dat vereisen.
+Iedere parallelle behandeling vereist:
+
+- een expliciete reden;
+- tijdgebonden historie;
+- behoud van de oorspronkelijke request- en case-identiteiten;
+- volledige audit.
+
+Dit is een uitzondering en geen standaardroute.
+
+## 3. Formele verwijzing is een zelfstandig object
+
+De formele Nederlandse **VERWIJZING** valt niet samen met het generieke
+zorgverzoek.
+
+Bevestigd is:
+
+- `Referral Request` representeert het inhoudelijke verzoek om zorg of
+  beoordeling;
+- `Professional Referral` representeert de formele verwijzing met onder meer
+  verwijzer, verwijsdatum, geldigheid en verwijsspecifieke gegevens;
+- de formele verwijzing heeft een eigen identiteit;
+- de formele verwijzing wordt gekoppeld aan het request waarop zij betrekking
+  heeft;
+- een zelfaanmelding kan een request vormen zonder formele verwijzing.
+
+Deze scheiding sluit aan op de GGZ-praktijk bij spoed en crisis. Zorg kan
+soms al worden geleverd voordat de formele verwijzing is ontvangen. Een
+later ontvangen verwijzing vult de formele en financiële onderbouwing aan,
+maar herschrijft de identiteit of herkomst van het oorspronkelijke request
+niet.
+
+De vraag hoe correcties en vervangende verwijzingen logisch worden
+gemodelleerd is geparkeerd. Append-only audit voorkomt ondertussen
+informatieverlies. De keuze tussen meerdere verwijzingsidentiteiten en
+versies van één verwijzing hoort bij het logische model.
+
+## 4. Screening in de GGZ-praktijk
+
+Colin beschreef de screeningsfase als de fase waarin de instelling beoordeelt:
+
+- of er een match is met de zorgvraag;
+- of de benodigde inhoudelijke expertise aanwezig is;
+- of er plek beschikbaar is;
+- of er voldoende capaciteit is.
+
+Tijdens screening is meestal beperkt contact met de cliënt, verwijzer of
+andere bron. Dit contact is doorgaans niet gefinancierd, maar kan dat bij
+uitzondering wel zijn.
+
+Na een positieve screening volgt de zorginhoudelijke intake. Contacten binnen
+de intake zijn meestal wel gefinancierd. Uit de intake volgt vervolgens een
+behandeladvies.
+
+De financiering van een contact mag daarom niet uitsluitend uit de procesfase
+worden afgeleid. Per concreet contact moet kunnen worden vastgelegd of en op
+welke grond het gefinancierd of declarabel is.
+
+## 5. Screeningsbesluit is het acceptatiebesluit
+
+Bevestigd is dat het screeningsbesluit geen vrijblijvend advies is waarna nog
+een zelfstandig acceptatiebesluit volgt. Het screeningsbesluit **is** het
+acceptatiebesluit.
+
+Daarmee wordt de eerder veronderstelde scheiding tussen
+`Screening Recommendation` en `Care Acceptance Decision` voor deze flow
+herzien. De onderliggende beoordelingen blijven wel afzonderlijke feiten:
+
+1. inhoudelijke match;
+2. beschikbare plek;
+3. capaciteit;
+4. formeel besluit;
+5. vervolgroute;
+6. onderbouwing.
+
+Het besluit en de onderliggende beoordelingen mogen niet in één statusveld
+worden samengevoegd.
+
+## 6. Capaciteit bepaalt acceptatie niet automatisch
+
+Besproken is dat een inhoudelijke match zonder beschikbare capaciteit in de
+praktijk tot twee geldige routes kan leiden.
+
+### Route A — accepteren en wachten
+
+- inhoudelijke match: ja;
+- capaciteit: nee;
+- acceptatiebesluit: geaccepteerd;
+- vervolgroute: intakewachtlijst;
+- gevolg: er ontstaat een zorgepisode.
+
+### Route B — afwijzen wegens capaciteit
+
+- inhoudelijke match: ja;
+- capaciteit: nee;
+- acceptatiebesluit: afgewezen;
+- onderbouwing: geen capaciteit;
+- eventuele vervolgroute: doorverwijzen;
+- gevolg: er ontstaat geen zorgepisode.
+
+Capaciteit is dus invoer voor het besluit, maar bepaalt de besluituitkomst
+niet automatisch. Het acceptatiebesluit bepaalt of een zorgepisode ontstaat.
+
+Deze scheiding ondersteunt ook andere combinaties:
+
+- inhoudelijke match en capaciteit beschikbaar → geaccepteerd → intake
+  plannen;
+- geen inhoudelijke match → afgewezen met inhoudelijke onderbouwing;
+- onvoldoende informatie → nog geen definitief besluit en aanvullende
+  informatie opvragen.
+
+## 7. Besluituitkomst en vervolgroute
+
+De volgende voorlopige scheiding is ontstaan.
+
+### Besluituitkomst
+
+- geaccepteerd;
+- afgewezen.
+
+Mogelijk is `meer_informatie_nodig` geen besluituitkomst maar een open
+processtatus, omdat er dan nog geen definitief acceptatiebesluit bestaat.
+
+### Vervolgroute
+
+- intake direct plannen;
+- op intakewachtlijst plaatsen;
+- bij spoed direct doorzetten;
+- doorverwijzen;
+- case afsluiten.
+
+`Planning` en `wachtlijst` zijn daarmee geen inhoudelijke besluituitkomsten,
+maar operationele vervolgroutes na of naast het besluit.
+
+### Onderbouwing
+
+Bij afwijzing is een concrete onderbouwing nodig, bijvoorbeeld:
+
+- onvoldoende inhoudelijke match;
+- benodigde expertise ontbreekt;
+- geen capaciteit;
+- zorgvraag valt buiten het aanbod of de toelatingscriteria.
+
+Een onderbouwing als “geen acceptatie” is niet informatief, omdat die alleen
+de besluituitkomst herhaalt.
+
+## 8. Gevolg voor episodevorming
+
+Het huidige inhoudelijke besluit blijft: de zorgepisode ontstaat bij
+acceptatie.
+
+Nu het screeningsbesluit het acceptatiebesluit blijkt te zijn, kan de episode
+al vóór de eerste zorginhoudelijke intake ontstaan. Ook bij acceptatie gevolgd
+door een intakewachtlijst bestaat dan al een zorgepisode.
+
+Dit vervangt het oudere voorstel in `../deelmodellen/model-aanmelding.md` waarin de episode
+pas ontstond bij uitkomst “intake” of bij de feitelijke start van de intake.
+Het feitenmodel en de oudere deelmodellen zijn op dit punt nog niet volledig
+gesynchroniseerd.
+
+## 9. Huidige conceptuele flow
+
+```text
+request en één of meer submissions
+→ referral case
+→ screening van zorgvraagmatch, expertise, plek en capaciteit
+→ screeningsbesluit = acceptatiebesluit
+   ├─ geaccepteerd
+   │  ├─ intake direct plannen
+   │  ├─ intakewachtlijst
+   │  └─ spoedroute
+   │
+   └─ afgewezen
+      ├─ inhoudelijke onderbouwing
+      ├─ capaciteitsonderbouwing
+      └─ eventueel doorverwijzen
+
+geaccepteerd
+→ zorgepisode
+→ zorginhoudelijke intake
+→ behandeladvies
+```
+
+De formele verwijzing kan vóór of na het acceptatiebesluit worden ontvangen
+en blijft een zelfstandig object naast het request.
+
+## 10. Gewijzigde en toegevoegde artefacten
+
+Tijdens deze feitenronde is toegevoegd:
+
+- `../feitenmodellen/feitenmodel-instroom.md`.
+
+Dat document bevat:
+
+- werkdefinities;
+- elementaire feitzinnen;
+- voorlopige uniqueness- en optionaliteitsregels;
+- scenariotoetsen voor huisartsverwijzing, zelfaanmelding, spoed/crisis,
+  aanvullende informatie en dubbele instroom;
+- een voorlopige conclusie over de identiteit van Referral Request.
+
+Het document bevat nog formuleringen die met de besluiten uit deze sessie
+moeten worden gesynchroniseerd, met name:
+
+- screeningsadvies en acceptatie zijn nog deels als afzonderlijke besluiten
+  beschreven;
+- de besluituitkomsten en vervolgroutes moeten worden gescheiden;
+- episodevorming bij acceptatie vóór intake moet expliciet worden verwerkt.
+
+## 11. Open punten
+
+### Instroom en acceptatie
+
+- Welke open processtatussen gelden vóór een definitief screeningsbesluit?
+- Welke gegevens en bevoegdheid zijn minimaal vereist om het
+  screenings-/acceptatiebesluit vast te leggen?
+- Kan een geaccepteerde case later vóór de intake alsnog worden ingetrokken,
+  en zo ja, wat gebeurt dan met de zorgepisode?
+- Hoe worden intakewachtlijst en regulatoire aanmeldwachttijd precies
+  gekoppeld nu de episode vóór intake kan ontstaan?
+
+### Behandeladvies
+
+- Welke uitkomsten kan het behandeladvies na de intake hebben?
+- Is het behandeladvies uitsluitend adviserend, of bevat het ook een bevoegd
+  besluit over de start of vorm van behandeling?
+- Hoe verhoudt het behandeladvies zich tot behandelplan, doorverwijzing en
+  afsluiting van de episode?
+
+### Logische uitwerking
+
+- Hoe worden gecorrigeerde of vervangende formele verwijzingen
+  gehistoriseerd?
+- Welke cardinaliteiten volgen definitief tussen request, submission, case,
+  verwijzing en acceptatiebesluit?
+- Welke statusmachine hoort bij Referral Case wanneer aanvullende informatie,
+  heroverweging of intrekking mogelijk is?
+
+## 12. Afgesproken volgende stap
+
+De eerstvolgende stap is het synchroniseren van
+`../feitenmodellen/feitenmodel-instroom.md` met de besluiten uit deze sessie:
+
+1. screeningsbesluit en acceptatiebesluit samenvoegen;
+2. beoordelingen, besluit, vervolgroute en onderbouwing als afzonderlijke
+   feiten formuleren;
+3. beide routes bij ontbrekende capaciteit opnemen;
+4. episodevorming vóór intake corrigeren;
+5. de mogelijke uitkomsten van het behandeladvies met Colin vaststellen.
+
+Daarna volgen:
+
+1. definitieve uniqueness- en optionaliteitsconstraints;
+2. de statusmachines van Referral Case en het acceptatiebesluit;
+3. afleiding van entiteiten en cardinaliteiten;
+4. verwerking in het besluitenlog;
+5. synchronisatie van `../begrippenlijst-kernmodel.md` en
+   `../deelmodellen/model-aanmelding.md`.