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.
This commit is contained in:
colinislit
2026-07-19 11:07:21 +02:00
parent 37beef14be
commit 2a1278936b
20 changed files with 6169 additions and 6 deletions

View File

@@ -0,0 +1,623 @@
# Feitenmodel instroom — eerste FCO-IM-ronde
**Status:** concept voor domeinreview, geen logisch model
**Datum:** 18 juli 2026, gesynchroniseerd 19 juli 2026
**Scope:** zorgverzoek, afzonderlijke binnenkomst, aanmeldingstraject en acceptatie
**Autoriteit:** `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft leidend
**Aanleiding:** afgesproken vervolg in `../sessielogs/sessielog-2026-07-18.md` §13
**Synchronisatie:** §2 (Care Acceptance Decision), §3.4§3.5, §4 en §7 zijn op
19 juli 2026 bijgewerkt conform de screening=acceptatie-beslissing uit
`../sessielogs/sessielog-2026-07-19.md` §5§9. `Screening Recommendation` als apart
besluitobject vervalt daarmee; de begrippenlijst en `../deelmodellen/model-aanmelding.md`
volgen in een latere synchronisatiestap.
## 1. Doel van deze ronde
Deze ronde formuleert elementaire feiten vóórdat entiteiten, attributen,
cardinaliteiten of SQL worden vastgelegd. De feiten worden getoetst met vier
praktijkscenario's:
1. een huisarts verwijst een cliënt;
2. een cliënt meldt zichzelf aan;
3. later komt aanvullende informatie binnen;
4. twee binnenkomsten blijken dubbel of overlappend.
De centrale open vraag is of `Referral Request` een eigen identiteit nodig
heeft naast `Referral Submission` en `Referral Case`.
## 2. Werkbegrippen
De Engelse namen zijn werktermen en worden pas na domeinreview in de
begrippenlijst vastgesteld.
### Referral Request — `referral_request`
Het inhoudelijke verzoek om zorg of beoordeling voor één of meer
samenhangende geuite zorgvragen. Het verzoek kan afkomstig zijn van een
professional, organisatie, cliënt of vertegenwoordiger. Splitsing is pas
nodig wanneer zorgvragen afzonderlijk moeten worden beoordeeld.
Een Referral Request is niet:
- de technische of administratieve ontvangst van het verzoek;
- de documentenbundel;
- het interne beoordelingstraject;
- een bewijs dat de zorg is geaccepteerd;
- noodzakelijk een formele Nederlandse verwijzing.
### Referral Submission — `referral_submission`
Eén afzonderlijke binnenkomst bij de instelling, via één kanaal en op één
ontvangstmoment. Een submission bewaart wat daadwerkelijk is ontvangen,
inclusief bron, documenten en oorspronkelijke formulering.
Een Referral Submission is niet:
- automatisch een nieuw zorgverzoek;
- automatisch een nieuw aanmeldingstraject;
- een overschrijfbare actuele versie van eerder ontvangen informatie.
### Referral Case — `referral_case`
Het institutionele aanmeldingstraject waarin de instelling één samenhangende
zorgvraag beoordeelt. Een case kan informatie uit meerdere submissions
gebruiken.
Een Referral Case is niet:
- een klinische intake;
- een zorgepisode;
- een financieel traject;
- de zorgvraag of verwijzing zelf.
### Professional Referral — `professional_referral`
Voorlopige naam voor de formele Nederlandse **VERWIJZING**: een door een
toegestane verwijzer uitgegeven object met verwijzer, verwijsdatum,
geldigheid en eventuele verwijsspecifieke gegevens.
De formele verwijzing heeft een eigen identiteit en wordt gekoppeld aan het
bredere Referral Request. Een zelfaanmelding kan zo al worden beoordeeld en,
bij spoed of crisis, tot zorg leiden voordat een formele verwijzing is
ontvangen. De latere verwijzing verandert de identiteit en herkomst van het
oorspronkelijke zorgverzoek niet.
### Care Acceptance Decision — `care_acceptance_decision`
Het formele besluit waarin de instelling de beoordeling van een Referral Case
afrondt. Het besluit draagt zelf de onderliggende beoordelingen — inhoudelijke
match, beschikbare plek en capaciteit — samen met de besluituitkomst, de
vervolgroute en, bij afwijzing, de onderbouwing. Er bestaat geen los,
voorafgaand screeningsadvies: het screeningsbesluit **is** het
acceptatiebesluit (bevestigd in domeinreview 19 juli 2026). Een positief
besluit geeft toegang tot de zorginhoudelijke intake; het is niet het latere
behandeladvies.
Screening blijft wel bestaan als de verzameling activiteiten (contact,
onderzoek, informatie-uitvraag) waarmee de beoordelingsfeiten tot stand
komen — alleen de uitkomst ervan wordt niet meer als apart, voorlopig advies
vastgelegd.
Acceptatie bewijst niet automatisch:
- een behandelovereenkomst;
- behandeltoestemming;
- zorgplicht;
- toewijzing van een behandelaar;
- organisatorische of klinische verantwoordelijkheid.
## 3. Elementaire feitzinnen
### 3.1 Zorgverzoek
R1. *Zorgverzoek R-101 betreft persoon Jan de Vries.*
R2. *Zorgverzoek R-101 is op 1 juli 2026 geïnitieerd.*
R3. *Zorgverzoek R-101 is geïnitieerd door huisarts P. Pietersen.*
R4. *Zorgverzoek R-101 vraagt om beoordeling voor gespecialiseerde GGZ.*
R5. *Bij zorgverzoek R-101 is als zorgvraag geuit: “somberheidsklachten en
slaapproblemen”.*
R6. *Professionele verwijzing V-111 betreft zorgverzoek R-101.*
R7. *Professionele verwijzing V-111 is afgegeven op 1 juli 2026.*
R8. *Professionele verwijzing V-111 is afgegeven door huisarts P. Pietersen.*
R9. *Professionele verwijzing V-111 vermeldt echelon “gespecialiseerde
GGZ”.*
R10. *Professionele verwijzing V-111 vermeldt als vermoeden “depressieve
stoornis”.*
R11. *Zorgverzoek R-102 is op 14 juli 2026 geïnitieerd door Jan de Vries
voor zichzelf.*
R12. *Zorgverzoek R-102 vraagt om beoordeling voor dezelfde geuite zorgvraag
als zorgverzoek R-101.*
**Besloten in domeinreview:**
- Eén request mag meerdere samenhangende zorgvragen bevatten.
- Zorgvragen worden gesplitst over requests wanneer ze afzonderlijk moeten
worden beoordeeld.
- Een formele verwijzing is een zelfstandig object dat aan een request wordt
gekoppeld.
- Het ontbreken van een formele verwijzing blokkeert zorg niet generiek; bij
spoed of crisis kan zorg al worden geleverd voordat de verwijzing is
ontvangen.
**Te toetsen:**
- Is “dezelfde geuite zorgvraag” een expliciete relatie tussen verzoeken, of
wordt samenhang uitsluitend binnen de Referral Case beoordeeld?
- Is een verzoek zonder bekende persoon tijdelijk toegestaan?
### 3.2 Afzonderlijke binnenkomst
S1. *Submission S-201 is op 14 juli 2026 om 09:14 ontvangen door instelling
Triqura GGZ.*
S2. *Submission S-201 is ontvangen via ZorgDomein.*
S3. *Submission S-201 is verzonden door huisarts P. Pietersen.*
S4. *Submission S-201 bevat document D-301 van type verwijsbrief.*
S5. *Submission S-201 representeert zorgverzoek R-101.*
S6. *Submission S-202 is op 16 juli 2026 om 11:32 ontvangen via beveiligde
e-mail.*
S7. *Submission S-202 is verzonden door huisarts P. Pietersen.*
S8. *Submission S-202 bevat document D-302 van type diagnostische
aanvulling.*
S9. *Submission S-202 vult zorgverzoek R-101 aan.*
S10. *Submission S-203 is op 16 juli 2026 om 15:05 telefonisch vastgelegd
door medewerker K. Jansen.*
S11. *De informatiebron van submission S-203 is Jan de Vries.*
S12. *Submission S-203 representeert zorgverzoek R-102.*
S13. *Submission S-204 is op 17 juli 2026 als duplicaat van submission S-201
beoordeeld.*
S14. *Medewerker K. Jansen heeft de duplicaatbeoordeling op 17 juli 2026
vastgelegd met reden “identieke ZorgDomein-berichtidentificatie”.*
**Besloten in domeinreview:**
- Eén submission kan meerdere inhoudelijke requests bevatten of
representeren.
- Ieder request krijgt een expliciete koppeling met de submission; de
oorspronkelijke binnenkomst wordt niet administratief gekopieerd of
gesplitst.
**Te toetsen:**
- Kan één request via meerdere submissions worden ontvangen?
- Is “vult aan” een directe relatie met een request, met een eerdere
submission, of met beide?
- Is een telefonisch geregistreerde binnenkomst altijd een submission?
### 3.3 Aanmeldingstraject en toewijzing
C1. *Referral Case C-401 is op 14 juli 2026 geopend voor Jan de Vries.*
C2. *Referral Case C-401 beoordeelt de samenhangende zorgvraag
“somberheidsklachten en slaapproblemen”.*
C3. *Submission S-201 is op 14 juli 2026 toegewezen aan Referral Case C-401.*
C4. *Medewerker K. Jansen heeft submission S-201 aan Referral Case C-401
toegewezen.*
C5. *De reden voor de toewijzing van submission S-201 is “eerste binnenkomst
voor deze zorgvraag”.*
C6. *Submission S-202 is op 16 juli 2026 toegewezen aan Referral Case C-401.*
C7. *Submission S-203 is op 17 juli 2026 toegewezen aan Referral Case C-401.*
C8. *Zorgverzoek R-101 wordt sinds 14 juli 2026 behandeld in Referral Case
C-401.*
C9. *Zorgverzoek R-102 wordt sinds 17 juli 2026 behandeld in Referral Case
C-401.*
C10. *Referral Case C-402 is op 17 juli 2026 als overlappend met Referral
Case C-401 beoordeeld.*
C11. *Medewerker K. Jansen heeft op 17 juli 2026 Referral Case C-401 als
leidend aangewezen ten opzichte van Referral Case C-402.*
C12. *De reden voor de leidende aanwijzing is “dezelfde zorgvraag, tweede
case onbedoeld geopend”.*
C13. *Referral Case C-402 behoudt zijn identiteit en historie na de leidende
aanwijzing.*
**Besloten in domeinreview:**
- Eén request kan uitzonderlijk in meerdere Referral Cases worden behandeld
wanneer verschillende proces- of wettelijke kaders dat vereisen.
- Iedere parallelle behandeling krijgt een expliciete reden en volledige
tijdgebonden historie.
**Te toetsen:**
- Hoort een Referral Case bij precies één cliënt, of bij een persoon die pas
tijdens de beoordeling cliënt wordt?
- Moet een toewijzing een geldigheidsperiode hebben, of volstaan
toewijzings- en correctiegebeurtenissen?
- Is “leidend” voldoende, of zijn aparte relaties nodig voor duplicaat,
overlap, splitsing en consolidatie?
### 3.4 Screeningsactiviteiten
G1. *Screening G-501 wordt uitgevoerd binnen Referral Case C-401.*
G2. *Screeningsactiviteit G-502 is op 15 juli 2026 uitgevoerd binnen
screening G-501.*
G3. *Screeningsactiviteit G-502 is van type telefonisch contact.*
G4. *Medewerker K. Jansen heeft screeningsactiviteit G-502 uitgevoerd.*
Screening G-501 leidt niet tot een apart screeningsadvies. De activiteiten
binnen de screening leveren de informatie waarop de beoordelingsfeiten in
§3.5 worden vastgesteld, als onderdeel van hetzelfde acceptatiebesluit.
**Besloten in domeinreview:**
- Screening toetst of de instelling een match ziet met de zorgvraag.
- Screening toetst daarnaast beschikbare plek, capaciteit en inhoudelijke
passendheid.
- Tijdens screening kan beperkt contact met de cliënt of verwijzer
plaatsvinden.
- Screeningscontact is meestal niet gefinancierd, maar kan dat bij
uitzondering wel zijn.
- Het screeningsbesluit **is** het acceptatiebesluit; er is geen los
tussenliggend advies (sessielog 19 juli 2026 §5).
- Een positief besluit geeft toegang tot een zorginhoudelijke intake. Contact
binnen de intake is doorgaans wel gefinancierd.
- Uit de intake volgt een afzonderlijk behandeladvies; de mogelijke
uitkomsten daarvan zijn nog niet vastgesteld (nader onderzoek, zie §7).
### 3.5 Beoordeling en acceptatiebesluit
**Route 1 — inhoudelijke match en capaciteit beschikbaar**
A1. *Beoordeling van Referral Case C-401 bevestigt op 17 juli 2026 een
inhoudelijke match met de geuite zorgvraag.*
A2. *Beoordeling van Referral Case C-401 bevestigt op 17 juli 2026
beschikbare capaciteit bij zorgprogramma Stemming.*
A3. *Acceptatiebesluit A-701 betreft Referral Case C-401.*
A4. *Acceptatiebesluit A-701 is genomen op 17 juli 2026 door medewerker
K. Jansen.*
A5. *Medewerker K. Jansen handelde bij acceptatiebesluit A-701 op grond van
beslisbevoegdheid B-801.*
A6. *Acceptatiebesluit A-701 heeft besluituitkomst “geaccepteerd”.*
A7. *Acceptatiebesluit A-701 heeft vervolgroute “intake direct plannen” bij
zorgprogramma Stemming.*
A8. *Zorgepisode E-901 is ontstaan uit acceptatiebesluit A-701.*
A9. *Zorgepisode E-901 is gestart op 17 juli 2026.*
A10. *Referral Case C-401 is na acceptatiebesluit A-701 afgesloten met
uitkomst “geaccepteerd”.*
**Route 2A — inhoudelijke match, geen capaciteit: accepteren en wachten**
A11. *Beoordeling van Referral Case C-403 bevestigt op 20 juli 2026 een
inhoudelijke match met de geuite zorgvraag.*
A12. *Beoordeling van Referral Case C-403 constateert op 20 juli 2026 geen
beschikbare capaciteit bij zorgprogramma Trauma.*
A13. *Acceptatiebesluit A-711 betreft Referral Case C-403.*
A14. *Acceptatiebesluit A-711 heeft besluituitkomst “geaccepteerd”.*
A15. *Acceptatiebesluit A-711 heeft vervolgroute “intakewachtlijst” bij
zorgprogramma Trauma.*
A16. *Zorgepisode E-902 is ontstaan uit acceptatiebesluit A-711, ook al is de
intake nog niet gestart.*
**Route 2B — inhoudelijke match, geen capaciteit: afwijzen**
A17. *Beoordeling van Referral Case C-404 bevestigt op 21 juli 2026 een
inhoudelijke match met de geuite zorgvraag.*
A18. *Beoordeling van Referral Case C-404 constateert op 21 juli 2026 geen
beschikbare capaciteit bij zorgprogramma Trauma.*
A19. *Acceptatiebesluit A-721 betreft Referral Case C-404.*
A20. *Acceptatiebesluit A-721 heeft besluituitkomst “afgewezen”.*
A21. *Acceptatiebesluit A-721 motiveert de afwijzing met “geen capaciteit bij
zorgprogramma Trauma”.*
A22. *Acceptatiebesluit A-721 heeft vervolgroute “doorverwijzen”.*
A23. *Referral Case C-404 is na acceptatiebesluit A-721 afgesloten met
uitkomst “afgewezen”; er ontstaat geen zorgepisode.*
Route 2A en 2B tonen dat capaciteit invoer is voor het besluit, maar de
uitkomst niet automatisch bepaalt (sessielog 19 juli 2026 §6). Bij afwijzing
is een concrete onderbouwing verplicht; “geen capaciteit” of “geen
acceptatie” zonder verdere duiding is onvoldoende, omdat dat laatste alleen
de uitkomst herhaalt.
**Beantwoord in domeinreview (19 juli 2026):**
- Besluituitkomst is beperkt tot `geaccepteerd` / `afgewezen`. `Doorverwijzen`
en het afsluiten van de case zijn vervolgroutes, geen besluituitkomsten.
- Elk positief besluit laat een zorgepisode ontstaan, ook wanneer de
vervolgroute intakewachtlijst is — niet pas bij de feitelijke start van de
intake.
**Nog te toetsen:**
- Is `aanvullende_informatie_nodig` een open processtatus vóór een definitief
besluit, of toch een derde besluituitkomst? Voorlopige aanname: open
processtatus, geen besluituitkomst (sessielog 19 juli 2026 §7).
- Kan een case meerdere opeenvolgende besluiten hebben na heroverweging?
- Welk besluit is dan geldig en hoe wordt intrekking of correctie vastgelegd?
- Kan een geaccepteerde case vóór de feitelijke start van de intake alsnog
worden ingetrokken, en wat gebeurt dan met de al ontstane zorgepisode?
### 3.6 Zorginhoudelijke intake en behandeladvies
I1. *Klinische intake I-1001 is gestart na acceptatiebesluit A-701.*
I2. *Intakecontact I-1002 is op 20 juli 2026 uitgevoerd binnen klinische
intake I-1001.*
I3. *Intakecontact I-1002 is een gefinancierd contact.*
I4. *Klinische intake I-1001 heeft geleid tot behandeladvies B-1101.*
I5. *Behandeladvies B-1101 adviseert behandeling binnen zorgprogramma
Stemming.*
De financiering van een concreet contact is een afzonderlijk feit. Het type
fase bepaalt niet zonder uitzondering of een contact declarabel is.
## 4. Voorlopige uniqueness- en optionaliteitsregels
Deze regels zijn hypotheses voor domeinreview, geen definitieve
cardinaliteiten.
### Referral Request
- Elk request heeft één stabiele identiteit.
- Elk request betreft op enig moment precies één persoon of cliënt.
- Elk request heeft minstens één initiator.
- Elk request bevat één of meer samenhangende geuite zorgvragen.
- Zorgvragen die afzonderlijk moeten worden beoordeeld horen in afzonderlijke
requests.
- Een request kan zonder formele verwijzing bestaan.
- Een formele verwijzing heeft een eigen identiteit en wordt gekoppeld aan
het request waarop zij betrekking heeft.
- Acceptatie of zorgverlening vereist niet generiek dat de formele verwijzing
al is ontvangen; toepasselijke juridische en financiële gevolgen worden
afzonderlijk door protocolregels bewaakt.
- Een request kan door meerdere submissions worden gerepresenteerd of
aangevuld.
- Een request kan alleen bij uitzondering aan meer dan één case worden
gekoppeld, vanwege verschillende proces- of wettelijke kaders en met een
expliciete reden en tijdgebonden historie.
### Referral Submission
- Elke submission heeft één stabiele identiteit.
- Elke submission heeft precies één ontvangstmoment en één ontvangstkanaal.
- Elke submission heeft minstens één informatiebron of afzender, eventueel
“onbekend”.
- Een submission kan nul documenten bevatten, bijvoorbeeld bij telefoon.
- Een submission kan nul, één of meerdere requests representeren; iedere
bekende relatie wordt expliciet vastgelegd.
- Een submission wordt nooit overschreven door een latere aanvulling.
- De koppeling van een submission aan een case is historiseerbaar en wordt
door een mens bevestigd.
### Referral Case
- Elke case heeft één stabiele identiteit.
- Elke case behandelt één institutioneel als samenhangend beoordeelde
zorgvraag.
- Een case kan door meerdere submissions en requests worden gevoed.
- Parallelle cases zijn toegestaan met een expliciete reden.
- Logische consolidatie verwijdert geen case, request of submission.
- Een afgesloten case kan bij herbeoordeling een nieuwe besluitronde krijgen;
de precieze statusmachine staat nog open.
### Care Acceptance Decision
- Elk besluit betreft precies één Referral Case.
- Elk besluit heeft precies één beslisser en besluitdatum.
- De beslisser moet op het beslismoment de vereiste bevoegdheid hebben.
- Elk besluit heeft precies één besluituitkomst: `geaccepteerd` of
`afgewezen`.
- De onderliggende beoordelingen (inhoudelijke match, beschikbare plek,
capaciteit) zijn losse feiten bij hetzelfde besluit, geen aparte
voorafgaande beslissing.
- Elk besluit heeft precies één vervolgroute, bijvoorbeeld intake direct
plannen, intakewachtlijst, spoedroute, doorverwijzen of case afsluiten.
- Bij besluituitkomst `afgewezen` is een concrete onderbouwing verplicht;
het herhalen van de uitkomst (“geen acceptatie”) is geen geldige
onderbouwing.
- Capaciteit is invoer voor het besluit maar bepaalt de besluituitkomst niet
automatisch: bij ontbrekende capaciteit zijn zowel `geaccepteerd` met
vervolgroute intakewachtlijst als `afgewezen` met onderbouwing
capaciteitstekort geldige uitkomsten.
- Alleen een besluit met uitkomst `geaccepteerd` kan een zorgepisode laten
ontstaan, ongeacht de gekozen vervolgroute.
- Een zorgepisode verwijst naar het acceptatiebesluit waaruit zij ontstond.
- Een besluit bewijst geen behandeltoestemming of verantwoordelijkheid.
- Het behandeladvies na de intake is een afzonderlijk klinisch feit en geen
herhaling van het acceptatiebesluit; welke vervolgrichtingen het
behandeladvies kent en wie daartoe bevoegd is, is nog niet vastgesteld
(nader onderzoek, zie §7).
## 5. Scenariotoets
### Scenario 1 — huisartsverwijzing
Benodigde objecten:
- één Referral Request;
- één zelfstandig Professional Referral, gekoppeld aan het request;
- één Referral Submission;
- één Referral Case;
- na positief besluit één Care Acceptance Decision en één Clinical Care
Episode.
Dit scenario toont dat verwijsdatum en ontvangstdatum verschillende feiten
zijn.
### Scenario 2 — zelfaanmelding
Benodigde objecten:
- één Referral Request, geïnitieerd door de cliënt;
- één Referral Submission, bijvoorbeeld telefonisch of via het portaal;
- één Referral Case;
- geen Professional Referral.
Dit scenario toont dat `Referral Request` breder moet zijn dan de Nederlandse
VERWIJZING.
### Scenario 3 — spoed of crisis vóór formele verwijzing
Benodigde objecten:
- één Referral Request, bijvoorbeeld geïnitieerd door de cliënt, crisisdienst
of andere informatiebron;
- minstens één Referral Submission;
- één Referral Case;
- eventueel een positief Care Acceptance Decision en Clinical Care Episode
voordat een Professional Referral is ontvangen;
- een later ontvangen Professional Referral met een eigen Submission en een
koppeling aan hetzelfde Referral Request.
Dit scenario toont dat een formele verwijzing geen bestaansvoorwaarde is voor
het request, de case of generiek voor zorgverlening. Financiële en juridische
vereisten blijven afzonderlijke protocolregels.
### Scenario 4 — aanvullende informatie
Benodigde objecten:
- hetzelfde Referral Request;
- een nieuwe Referral Submission met eigen bron, tijdstip en documenten;
- dezelfde Referral Case, na menselijke toewijzing.
Dit scenario toont waarom request, submission en case niet tot één record
kunnen worden samengevoegd.
### Scenario 5 — dubbele of overlappende instroom
Benodigde objecten:
- oorspronkelijke requests en submissions blijven behouden;
- een mens beoordeelt duplicaat of overlap;
- submissions en requests worden aan de passende case gekoppeld;
- bij twee cases wordt één case eventueel als leidend aangewezen;
- de andere case wordt niet verwijderd of technisch samengevoegd.
Dit scenario toont dat samenvoegen een expliciete, geaudite relatie is.
### Scenario 6 — capaciteitstekort bij inhoudelijke match
Benodigde objecten:
- twee vergelijkbare Referral Cases met bevestigde inhoudelijke match en
bevestigd capaciteitstekort bij hetzelfde zorgprogramma;
- Route 2A: één Care Acceptance Decision met uitkomst `geaccepteerd` en
vervolgroute intakewachtlijst, gevolgd door een Clinical Care Episode die
al ontstaat vóór de feitelijke start van de intake;
- Route 2B: één Care Acceptance Decision met uitkomst `afgewezen`, een
concrete capaciteitsonderbouwing en vervolgroute doorverwijzen, zonder dat
een Clinical Care Episode ontstaat.
Dit scenario toont dat capaciteit een beoordelingsfeit is en geen
automatische bepaler van de besluituitkomst, en dat "geaccepteerd" niet
gelijkstaat aan "intake gestart".
## 6. Voorlopige conclusie over Referral Request
`Referral Request` heeft naar verwachting een eigen identiteit nodig.
Zonder dit object ontstaan twee problemen:
1. meerdere submissions van hetzelfde zorgverzoek zijn alleen via vrije
interpretatie aan elkaar te relateren;
2. een formele verwijzing en een zelfaanmelding moeten kunstmatig in één
Nederlands begrip VERWIJZING worden gedwongen.
De Nederlandse **VERWIJZING** valt daarom niet volledig samen met Referral
Request. Zij is een zelfstandig, professioneel geïnitieerd object met eigen
feiten, zoals verwijzer, verwijsdatum, echelon en geldigheid, dat aan het
zorgverzoek wordt gekoppeld.
Hierdoor kan het zorgverzoek al bestaan en kan in spoed- of crisissituaties
zorg worden geleverd voordat de formele verwijzing binnenkomt. De latere
verwijzing vult de formele en financiële onderbouwing aan, maar herschrijft
het oorspronkelijke request niet.
Of één request achtereenvolgens meerdere formele verwijzingen kan hebben,
bijvoorbeeld bij correctie of vervanging, wordt pas in het logische model
uitgewerkt. De append-only audit voorkomt ondertussen informatieverlies.
## 7. Eerste domeinreview
**Beantwoord (domeinreview 19 juli 2026):**
1. Screeningsadvies en acceptatie zijn in de praktijk hetzelfde vastgelegde
besluit. Dit is verwerkt in §2§5 hierboven: er is geen apart, voorafgaand
screeningsadvies meer, en het besluit draagt zelf de onderliggende
beoordelingen, de besluituitkomst, de vervolgroute en, bij afwijzing, de
onderbouwing.
**Nog open, nader onderzoek nodig:**
2. Welke mogelijke uitkomsten heeft het behandeladvies na de intake, en wie
is bevoegd die vast te stellen? Vastgesteld is alleen dat het
behandeladvies zelf al de vervolgrichting geeft — net als het
acceptatiebesluit is er geen apart, voorafgaand advies. De concrete
vervolgrichtingen en de bijbehorende bevoegdheid zijn geparkeerd (sessielog
19 juli 2026).
3. Kan een case meerdere opeenvolgende acceptatiebesluiten hebben na
heroverweging, en zo ja, welk besluit is dan geldig?
4. Kan een geaccepteerde case vóór de feitelijke start van de intake alsnog
worden ingetrokken, en wat gebeurt dan met de al ontstane zorgepisode?
5. Is `aanvullende_informatie_nodig` een open processtatus of een derde
besluituitkomst?
Na beantwoording van 35 volgen pas:
1. definitieve uniqueness- en optionaliteitsconstraints (§4 hierboven is een
tussenstand, nog niet definitief bevestigd);
2. de statusmachine van Referral Case en Care Acceptance Decision;
3. afleiding van entiteiten en cardinaliteiten;
4. verwerking in `../besluiten/besluitenlog-datamodel-2026-07-18.md`;
5. synchronisatie van `../begrippenlijst-kernmodel.md` en
`../deelmodellen/model-aanmelding.md`.