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-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`.