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

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