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

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

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.