colin/triqura-ecd
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(datamodel): FCO-IM feitenronde instroom, besluitenlog + herstructurering

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

484
docs/datamodel/begrippenlijst-kernmodel.md Normal file
View File

@@ -0,0 +1,484 @@
# Begrippenlijst kernmodel — Nederlands/Engels
**Status:** versie 0.1, ter inhoudelijke en terminologische review
**Datum:** 18 juli 2026
**Bron:** `besluiten/besluitenlog-datamodel-2026-07-18.md`
**Terminologieonderzoek:** `onderzoek/onderzoek-engelstalige-epd-terminologie.md` adviseert voor de instroom een driedeling in Referral Request, Referral Submission en Referral Case; nog niet als begrippenbesluit verwerkt
**Doel:** één gedeelde betekenis en één Engelse technische naam per kernbegrip, vóór uitwerking van feitzinnen, ERD of SQL
## 1. Gebruik en naamgeving
- De **Nederlandse domeinterm** en definitie leggen de zorginhoudelijke betekenis vast.
- De **Engelse conceptnaam** is de naam in technische modeldocumentatie.
- De **identifier** is de voorgestelde stam voor tabellen, attributen, events en API-objecten. De fysieke naamgevingsconventie wordt bij het logische model definitief.
- Een term met status **bevestigen** heeft nog expliciete domeinreview nodig; de betekenis staat wel vast.
- Officiële Nederlandse wettelijke of professionele termen blijven als bronterm en metadata beschikbaar.
- Lokale namen impliceren geen directe FHIR-, zib- of andere standaardmapping. Uitwisseling loopt via adapters.
### Vermijden
- `admission` voor aanmelding of acceptatie: dit suggereert klinische opname.
- `trajectory` voor traject: dit is in deze betekenis een Dutchism.
- `encounter` voor intake: een intake is een proces met meerdere contacten.
- `consent` voor planakkoord: planakkoord is niet hetzelfde als behandeltoestemming.
- Ongekwalificeerde namen als `care_plan`, `care_team` en `episode_of_care`: die kunnen ten onrechte een directe FHIR-mapping suggereren.
## 2. Identiteit en cliëntrol
### Person — `person`
**Nederlandse domeinterm:** persoon
**Status Engelse naam:** aanbevolen
Een natuurlijke persoon van wie identiteit en demografische gegevens kunnen worden vastgelegd, onafhankelijk van een zorgrelatie.
**Is niet:** automatisch een cliënt, medewerker, vertegenwoordiger of contactpersoon. Die betekenissen ontstaan via afzonderlijke rollen en relaties.
### Client — `client`
**Nederlandse domeinterm:** cliënt
**Status Engelse naam:** aanbevolen
De instellingsgebonden rol van een persoon voor wie zorg of mogelijke zorg wordt geadministreerd.
**Is niet:** de persoon zelf, een zorgepisode of bewijs dat al een behandelrelatie bestaat.
**Terminologienotitie:** `client` is een bewuste productkeuze. De UI gebruikt “cliënt”; uitwisselingsadapters kunnen waar nodig naar `Patient` mappen.
## 3. Instroom en beoordeling
### Inbound Care Signal — `inbound_care_signal`
**Nederlandse domeinterm:** aanmeldsignaal
**Status Engelse naam:** bevestigen
Eén afzonderlijke binnenkomst bij de instelling, met een eigen bron, tijdstip, documenten en oorspronkelijk geuite zorgvraag.
**Is niet:** een verwijzing, aanmeldingstraject, intake of geaccepteerd zorgverzoek. Een zelfaanmelding en informatie van een derde kunnen beide een aanmeldsignaal zijn.
**Terminologienotitie:** `referral` is te smal; `signal` is internationaal minder gangbaar maar dekt wel dat iedere binnenkomst als zelfstandig bronfeit behouden blijft.
### Access Assessment Case — `access_assessment_case`
**Nederlandse domeinterm:** aanmeldingstraject
**Status Engelse naam:** bevestigen
Het institutionele beoordelingsproces voor één samenhangende zorgvraag, gevoed door één of meer aanmeldsignalen.
**Is niet:** een opname, verwijzing, klinische intake, zorgepisode of financieel traject.
**Terminologienotitie:** `case` duidt hier een behandelbare workflowcase aan, nog geen klinische casus of zorgepisode.
### Presenting Care Need — `presenting_care_need`
**Nederlandse domeinterm:** zorgvraag
**Status Engelse naam:** bevestigen
De door cliënt of bron geuite behoefte, klacht of gewenste ondersteuning waarop de instroombeoordeling en mogelijke zorg zich richten.
**Is niet:** een diagnose, vastgesteld behandeltekort, bestelling van zorg of FHIR `ServiceRequest`.
**Open nuance:** bij de verdere modellering moet onderscheid worden gemaakt tussen de oorspronkelijk geuite zorgvraag en de later professioneel beoordeelde zorgbehoefte.
### Referral — `referral`
**Nederlandse domeinterm:** verwijzing
**Status Engelse naam:** aanbevolen
Een formele verwijzing door een bevoegde of toegestane bron, inclusief relevante verwijzer, context en geldigheid.
**Is niet:** ieder aanmeldsignaal. Een zelfaanmelding of los aanvullend document is niet automatisch een verwijzing.
### Signal-to-Case Assignment — `signal_case_assignment`
**Nederlandse domeinterm:** toewijzing van aanmeldsignaal aan aanmeldingstraject
**Status Engelse naam:** aanbevolen
De historiseerbare koppeling waarmee een aanmeldsignaal aan een beoordelingscase wordt toegewezen.
**Is niet:** destructieve verplaatsing. Het oorspronkelijke signaal en eerdere toewijzingen blijven bestaan.
### Access Case Consolidation — `access_case_consolidation`
**Nederlandse domeinterm:** logische samenvoeging van aanmeldingstrajecten
**Status Engelse naam:** bevestigen
Een niet-destructieve relatie waarbij één aanmeldingstraject als leidend wordt aangewezen en de oorspronkelijke trajecten, signalen en herkomst behouden blijven.
**Is niet:** database-merge, verwijderen, overschrijven of stil hernummeren.
### Screening — `screening`
**Nederlandse domeinterm:** screening
**Status Engelse naam:** aanbevolen
Een institutionele beoordelingsstap binnen het aanmeldingstraject waarin informatie wordt verzameld en een inhoudelijk advies kan worden voorbereid.
**Is niet:** de formele acceptatie, klinische intake of zorgepisode.
### Screening Recommendation — `screening_recommendation`
**Nederlandse domeinterm:** screeningsbesluit / screeningsadvies
**Status Engelse naam:** bevestigen
De inhoudelijke uitkomst van de screening, bijvoorbeeld geschiktheid, geadviseerde bestemming en urgentie.
**Is niet:** het formele acceptatiebesluit. De Engelse naam gebruikt bewust `recommendation`, omdat de screening niet altijd besluitvormend is.
### Care Acceptance Decision — `care_acceptance_decision`
**Nederlandse domeinterm:** acceptatiebesluit
**Status Engelse naam:** aanbevolen
Het formele besluit waarmee een cliënt voor een samenhangende zorgvraag tot het zorgproces wordt toegelaten en een zorgepisode kan ontstaan.
**Is niet:** behandelovereenkomst, behandeltoestemming, opnamebesluit, zorgplicht of toewijzing van verantwoordelijkheid.
## 4. Intake
### Clinical Intake Assessment — `clinical_intake_assessment`
**Nederlandse domeinterm:** intake / intaketraject
**Status Engelse naam:** bevestigen
Een dynamisch klinisch onderzoekstraject voor één samenhangende zorgvraag, met meerdere contacten, onderzoeken, disciplines en bevindingen.
**Is niet:** één gesprek, screening, aanmeldingstraject of FHIR `Encounter`.
**Terminologienotitie:** `assessment` mag niet worden geïnterpreteerd als één meetmoment; dit is een procesobject.
### Intake Contact — `intake_contact`
**Nederlandse domeinterm:** intakecontact
**Status Engelse naam:** aanbevolen
Eén feitelijk contact binnen de intake.
**Is niet:** de intake zelf of automatisch een declarabel consult.
### Intake Assessment Activity — `intake_assessment_activity`
**Nederlandse domeinterm:** intakeonderzoek / onderzoeksactiviteit
**Status Engelse naam:** bevestigen
Een diagnostische, somatische of andere onderzoeksactiviteit binnen de intake.
**Is niet:** de uiteindelijke diagnose of automatisch een uitgevoerde declarabele prestatie.
## 5. Episode en financiering
### Clinical Care Episode — `clinical_care_episode`
**Nederlandse domeinterm:** zorgepisode
**Status Engelse naam:** aanbevolen
De instellingbrede ordening van één formeel geaccepteerde klinische zorgperiode.
**Is niet:** FHIR `EpisodeOfCare`, aanmeldingstraject, afdeling, zorgprogramma, behandelovereenkomst of financieel traject.
Een episode kan meerdere zorgprogramma’s, organisatorische eenheden en disciplines omvatten. Na afsluiting ontstaat bij terugkeer een nieuwe, gerelateerde episode.
### Episode Relationship — `episode_relationship`
**Nederlandse domeinterm:** episoderelatie
**Status Engelse naam:** aanbevolen
Een getypeerde relatie tussen twee zorgepisodes, bijvoorbeeld terugkeer, voortzetting van relevante voorgeschiedenis of andere klinische samenhang.
**Is niet:** autorisatie, toegang of automatische overname van informatie.
### Funding Case — `funding_case`
**Nederlandse domeinterm:** financieel traject
**Status Engelse naam:** bevestigen
Een zelfstandig object dat financierings-, legitimatie- en declaratieregels voor een periode volgt.
**Is niet:** zorgepisode, factuur, declaratieregel of behandelplan.
**Terminologienotitie:** `billing episode` is te smal en `financial trajectory` is een Dutchism. De precieze naam wordt bij de declaratieronde opnieuw beoordeeld.
### Care Program — `care_program`
**Nederlandse domeinterm:** zorgprogramma
**Status Engelse naam:** aanbevolen
Een inhoudelijk georganiseerd zorgaanbod of behandelprogramma dat tijdens een periode bij een zorgepisode betrokken kan zijn.
**Is niet:** organisatorische afdeling, eigenaar van de episode of een aparte zorgepisode.
### Organizational Unit — `organizational_unit`
**Nederlandse domeinterm:** organisatorische eenheid
**Status Engelse naam:** aanbevolen
Een formeel onderdeel van de instelling, zoals afdeling, locatiegebonden team of andere beheerde organisatie-eenheid.
**Is niet:** zorgprogramma, zorgteam rond een cliënt of automatisch een autorisatiegroep.
### Care Program Involvement — `care_program_involvement`
**Nederlandse domeinterm:** zorgprogrammabetrokkenheid
**Status Engelse naam:** aanbevolen
De tijdgebonden betrokkenheid van een zorgprogramma bij een zorgepisode.
**Is niet:** eigenaarschap of klinische verantwoordelijkheid.
### Organizational Unit Involvement — `organizational_unit_involvement`
**Nederlandse domeinterm:** organisatorische betrokkenheid
**Status Engelse naam:** aanbevolen
De tijdgebonden betrokkenheid van een organisatorische eenheid bij een zorgepisode.
**Is niet:** autorisatie of verantwoordelijkheid voor een specifiek besluit.
## 6. Zorgteam, rol en bevoegdheid
### Episode Clinical Team — `episode_clinical_team`
**Nederlandse domeinterm:** zorgteam rond de zorgepisode
**Status Engelse naam:** aanbevolen
De tijdgebonden verzameling professionals die rond een zorgepisode betrokken zijn.
**Is niet:** FHIR `CareTeam`, een afdeling, autorisatiegroep of permanent personeelsteam.
### Episode Team Assignment — `episode_team_assignment`
**Nederlandse domeinterm:** zorgteamlidmaatschap / teamtoewijzing
**Status Engelse naam:** aanbevolen
De tijdgebonden toewijzing van een professional aan het zorgteam, inclusief de functionele teamrol.
**Is niet:** automatisch bewijs van toegang, beslisbevoegdheid of klinische verantwoordelijkheid.
### Episode Team Role — `episode_team_role`
**Nederlandse domeinterm:** teamrol binnen de zorgepisode
**Status Engelse naam:** aanbevolen
De functionele rol die een professional gedurende een periode binnen het zorgteam vervult.
**Is niet:** professie, functiebenaming of beslisbevoegdheid.
### Clinical Responsibility Assignment — `clinical_responsibility_assignment`
**Nederlandse domeinterm:** klinische verantwoordelijkheidstoewijzing
**Status Engelse naam:** aanbevolen
Een expliciete, tijdgebonden verantwoordelijkheid voor een zorgaspect, taak, proces of besluitgebied.
**Is niet:** algemene aansprakelijkheid, toegang, teamlidmaatschap of professie.
### Decision Authority — `decision_authority`
**Nederlandse domeinterm:** beslisbevoegdheid
**Status Engelse naam:** aanbevolen
De bevoegdheid om een bepaald type besluit te nemen, getoetst aan actuele rol, kwalificaties en geldende configuratie.
**Is niet:** aanwezigheid bij overleg, adviesrecht of uitsluitend een BIG-professie.
### Lead Clinician Role — `lead_clinician_role`
**Nederlandse domeinterm:** regiebehandelaar
**Officiële bronterm:** `regiebehandelaar`
**Status Engelse naam:** bevestigen
De Nederlandse GGZ-rol met regieverantwoordelijkheden volgens het toepasselijke kwaliteitsstatuut en de lokale roltoewijzing.
**Is niet:** automatisch de psychiater, hoofdbehandelaar, enige verantwoordelijke, casemanager of `attending physician`.
**Terminologienotitie:** er bestaat geen volledige één-op-éénvertaling. De officiële Nederlandse term en brondefinitie blijven daarom altijd beschikbaar.
## 7. Behandelplan
### Treatment Plan — `treatment_plan`
**Nederlandse domeinterm:** behandelplan
**Status Engelse naam:** aanbevolen
Eén levend, multidisciplinair en episodegebonden plan met een stabiele identiteit.
**Is niet:** FHIR `CarePlan`, plat formulier, plansnapshot of disciplinespecifiek deelplan.
### Treatment Plan Snapshot — `treatment_plan_snapshot`
**Nederlandse domeinterm:** behandelplansnapshot / plansnapshot
**Status Engelse naam:** aanbevolen
Een onveranderlijke formele weergave van het behandelplan bij vaststelling, formele evaluatie of cliëntbespreking.
**Is niet:** een nieuw behandelplan of een vrij bewerkbare werkversie.
### Focus Area — `focus_area`
**Nederlandse domeinterm:** aandachtgebied
**Status Engelse naam:** aanbevolen
Een onderwerp binnen het behandelplan waarop doelen, risico’s, krachten, herstel of preventie betrekking kunnen hebben.
**Is niet:** uitsluitend een probleem, diagnose of leefgebied.
### Focus Perspective — `focus_perspective`
**Nederlandse domeinterm:** perspectief op aandachtgebied
**Status Engelse naam:** aanbevolen
Een duiding van een aandachtgebied, zoals klacht, diagnose, leefgebied, kracht, beschermende factor, risico, herstel of preventie.
**Is niet:** een apart behandelplan of een verplichte enkelvoudige classificatie.
### Care Goal — `care_goal`
**Nederlandse domeinterm:** behandel-/zorgdoel
**Status Engelse naam:** bevestigen
Een gewenste uitkomst binnen het behandelplan, inclusief klinische, maatschappelijke, herstelgerichte en preventieve doelen.
**Is niet:** uitsluitend symptoomreductie of automatisch FHIR `Goal`.
**Terminologienotitie:** `treatment_goal` is mogelijk te smal voor preventieve en maatschappelijke doelen.
### Planned Intervention — `planned_intervention`
**Nederlandse domeinterm:** geplande interventie
**Status Engelse naam:** aanbevolen
Een in het behandelplan afgesproken professionele interventie of activiteit ter ondersteuning van één of meer doelen.
**Is niet:** afspraakmoment, bewijs van uitvoering of automatisch een declarabele prestatie.
### Client Perspective — `client_perspective`
**Nederlandse domeinterm:** cliëntperspectief
**Status Engelse naam:** aanbevolen
De eigen doelen, voorkeuren, bezwaren, context en duiding van de cliënt binnen het behandelplan.
**Is niet:** planakkoord of behandeltoestemming.
### Client Plan Response — `client_plan_response`
**Nederlandse domeinterm:** cliëntreactie op plansnapshot / planakkoord
**Status Engelse naam:** aanbevolen
De snapshotgebonden reactie van de cliënt of vertegenwoordiger: akkoord, gedeeltelijk akkoord, niet akkoord of niet verkregen.
**Is niet:** behandeltoestemming, juridische grondslag of planstatus.
### Treatment Consent — `treatment_consent`
**Nederlandse domeinterm:** behandeltoestemming
**Status Engelse naam:** aanbevolen
Toestemming voor een concrete behandeling of afgebakend geheel van behandelingen.
**Is niet:** akkoord met het behandelplan als geheel.
### Treatment Legal Basis — `treatment_legal_basis`
**Nederlandse domeinterm:** juridische grondslag voor behandeling
**Status Engelse naam:** aanbevolen
De expliciete juridische grondslag waarop behandeling zonder reguliere toestemming in een afgebakende situatie mag plaatsvinden.
**Is niet:** een generieke bypass voor ontbrekend planakkoord of behandeltoestemming.
### Care Planning Profile — `care_planning_profile`
**Nederlandse domeinterm:** behandelvisieprofiel
**Status Engelse naam:** bevestigen
Een versiegebonden ADM-configuratie voor terminologie, perspectieven, vereisten, scope en protocollen rond behandelplanning.
**Is niet:** behandelplan, klinisch schema, UI-thema of FHIR-profiel.
### Care Planning Profile Version — `care_planning_profile_version`
**Nederlandse domeinterm:** behandelvisieprofielversie
**Status Engelse naam:** aanbevolen
Een onveranderlijke, gepubliceerde versie van een behandelvisieprofiel waarnaar een plansnapshot kan verwijzen.
**Is niet:** een planversie of losse wijzigingsaudit.
## 8. MDO en evaluatie
### Multidisciplinary Case Review — `multidisciplinary_case_review`
**Nederlandse domeinterm:** MDO-proces / multidisciplinaire casusbespreking
**Status Engelse naam:** aanbevolen
De workflow van casusinbreng, voorbereiding, overleg, gedeelde analyse, uitkomst, acties en eventuele planwijzigingsvoorstellen.
**Is niet:** één vergadering, MDO-verslag, automatisch bevoegd besluit of planwijziging.
### Multidisciplinary Team Meeting — `multidisciplinary_team_meeting`
**Nederlandse domeinterm:** MDO-sessie
**Status Engelse naam:** aanbevolen
De feitelijke overlegsessie waarin één of meer casussen kunnen worden besproken.
**Is niet:** het volledige MDO-proces of automatisch een besluitvormend orgaan.
### Case Submission — `case_submission`
**Nederlandse domeinterm:** casusinbreng
**Status Engelse naam:** aanbevolen
De formele inbreng van een casus of vraagstelling voor een multidisciplinaire bespreking.
**Is niet:** de bespreking, uitkomst of rapportage.
### Treatment Plan Change Proposal — `treatment_plan_change_proposal`
**Nederlandse domeinterm:** behandelplanwijzigingsvoorstel
**Status Engelse naam:** aanbevolen
Een vanuit MDO, evaluatie of andere bron voorgestelde wijziging van het levende behandelplan.
**Is niet:** een reeds goedgekeurde of automatisch doorgevoerde planwijziging.
### Formal Treatment Review — `formal_treatment_review`
**Nederlandse domeinterm:** formele evaluatie
**Status Engelse naam:** aanbevolen
Een cliëntgericht evaluatieproces met input, doelbeoordeling, deelnemers, conclusies, acties en mogelijke wijzigingen van het behandelplan.
**Is niet:** MDO, losse rapportage, herinnering of automatisch een nieuwe plansnapshot.
## 9. Episode-overstijgende informatie
### Cross-Episode Clinical Concept — `cross_episode_clinical_concept`
**Nederlandse domeinterm:** getypeerd episode-overstijgend klinisch gegeven
**Status Engelse naam:** bevestigen
Expliciet geselecteerde en getypeerde klinische informatie met bron, bronepisode, geldigheid, actualiteit, reviewdatum en eigen autorisatieregels.
**Is niet:** generieke cliëntgegevensbak, tekstkopie of automatisch overgenomen episode-inhoud.
**Ontwerpnotitie:** dit is een voorlopig verzamelbegrip voor de architectuur. Concrete typen zoals vroegsignaal of beschermende factor krijgen later een eigen naam en model.
## 10. Open terminologiebesluiten
De betekenis van onderstaande begrippen staat vast, maar de Engelse naam moet nog expliciet worden bevestigd:
1. `inbound_care_signal` — aanmeldsignaal;
2. `access_assessment_case` — aanmeldingstraject;
3. `presenting_care_need` — zorgvraag;
4. `access_case_consolidation` — logische samenvoeging;
5. `screening_recommendation` — screeningsbesluit/-advies;
6. `clinical_intake_assessment` — intake als proces;
7. `funding_case` — financieel traject;
8. `lead_clinician_role` — regiebehandelaar;
9. `care_goal` — behandel-/zorgdoel;
10. `care_planning_profile` — behandelvisieprofiel;
11. `cross_episode_clinical_concept` — voorlopige naam voor de longitudinale architectuurlaag.
Deze namen worden vóór het logische ER-model één voor één beoordeeld. Tot dat moment zijn ze bruikbaar als werktermen, niet als definitieve database-identifiers.

358
docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md Normal file
View File

@@ -0,0 +1,358 @@
# Besluitenlog datamodel — sessie 18 juli 2026
**Status:** inhoudelijke besluiten en ontwerpuitgangspunten uit gesprek met Colin
**Werking:** dit document is leidend waar het oudere `../deelmodellen/datamodel-discovery.md` of een `model-*.md`-voorstel ermee conflicteert
**Context en verloop:** zie `../sessielogs/sessielog-2026-07-18.md`
**Vervolg:** structurele besluiten verwerken in de deelmodellen voordat SQL of migrations worden gemaakt
## 1. Legenda
- **Besluit:** inhoudelijke richting staat vast.
- **Ontwerpuitwerking:** richting staat vast; precieze entiteiten, attributen of cardinaliteiten moeten nog worden ontworpen.
- **Onderzoek:** onvoldoende basis voor een definitieve modelregel.
## 2. Instroom, acceptatie en zorgepisode
### B1 — Aanmeldsignaal en aanmeldingstraject zijn verschillende begrippen
**Besluit**
- Een **AANMELDSIGNAAL** is iedere afzonderlijke binnenkomst bij de instelling, met eigen bron, tijdstip, documenten en oorspronkelijke zorgvraag.
- Een **AANMELDINGSTRAJECT** is het proces waarmee de instelling één samenhangende zorgvraag beoordeelt.
- Meerdere signalen kunnen één traject voeden, bijvoorbeeld wanneer verschillende onafhankelijke instanties informatie over dezelfde zorgvraag aanleveren.
- Een nieuw signaal wordt niet automatisch een nieuw traject.
- Parallelle trajecten zijn technisch mogelijk, maar alleen bij aantoonbaar verschillende zorgvragen of proceskaders en met een expliciete reden.
- Samenvoegen is logisch en niet-destructief: oorspronkelijke signalen, trajectidentiteiten, herkomst en audit blijven bestaan. Eén traject kan als leidend worden aangewezen.
**Bespreekpunt**
De UX moet mogelijke overlap zichtbaar maken en de gebruiker laten kiezen tussen koppelen, parallel starten, als duplicaat registreren of logisch samenvoegen. AI mag een match voorstellen, maar niet zelfstandig samenvoegen.
### B2 — Drie onafhankelijke levenscycli
**Besluit**
Aanmelding, zorginhoudelijke episode en financieel traject zijn afzonderlijke concepten met eigen begin, einde en status:
1. het aanmeldingstraject beschrijft de institutionele beoordeling;
2. de zorgepisode ordent de geaccepteerde klinische zorgperiode;
3. het financiële traject volgt de regels van het toepasselijke financierings- en declaratiekader.
Een financieel startmoment of aanmeldingsuitkomst start niet automatisch de zorgepisode.
### B3 — Zorgepisode ontstaat bij formele acceptatie
**Besluit**
- Een **ZORGEPISODE** ontstaat bij een formeel acceptatiebesluit.
- Acceptatie betekent toelating tot het zorgproces.
- Acceptatie bewijst op zichzelf geen behandelovereenkomst, zorgplicht, toegewezen behandelaar of organisatorische verantwoordelijkheid.
- Deze verantwoordelijkheden worden als afzonderlijke, tijdgebonden feiten gemodelleerd.
- Na formele afsluiting leidt terugkeer tot een nieuwe zorgepisode die naar de eerdere episode kan verwijzen; een afgesloten episode wordt niet heropend.
**Ontwerpuitwerking**
De definitie, statussen en bevoegdheden van het acceptatiebesluit moeten nog worden uitgewerkt. Ook moet worden bepaald of en wanneer intakehandelingen vóór formele acceptatie kunnen plaatsvinden.
### B4 — Episode is instellingbreed
**Besluit**
- Eén zorgepisode kan opeenvolgend of gelijktijdig meerdere zorgprogramma’s, organisatorische eenheden en disciplines omvatten.
- Betrokkenheid van programma’s en eenheden wordt tijdgebonden vastgelegd.
- Een interne overdracht of toevoeging van een afdeling opent niet automatisch een nieuwe episode.
- Meerdere gelijktijdige episodes blijven technisch mogelijk, maar zijn binnen één instelling een gemotiveerde uitzondering.
### B5 — Relatie geeft geen toegang
**Besluit**
- Een verwijzing naar een eerdere episode verleent nooit automatisch inzage.
- Autorisatie, doelbinding en audit van inzage worden afzonderlijk gemodelleerd.
- Bewaren, relateren en mogen raadplegen zijn drie verschillende zaken.
**Onderzoek**
Bewaarbeleid voor afgewezen trajecten, pre-acceptatiegegevens en screeningsinformatie moet juridisch verder worden onderzocht. De WGBO-bewaartermijn mag niet zonder grondslaganalyse op alle instroomgegevens worden toegepast.
## 3. Intake
### B6 — Eén intaketraject per samenhangende zorgvraag
**Besluit**
- Een intake is één dynamisch onderzoekstraject met meerdere contacten, onderzoeken, betrokken disciplines en bevindingen.
- Een gesprek, onderzoek of interne afdelingsovergang vormt geen nieuwe intake.
- Parallelle intaketrajecten zijn alleen toegestaan bij expliciet verschillende zorgvragen en krijgen een relatie en reden.
**Ontwerpuitwerking**
Het eigenaarschap van de intake — aanmeldingstraject, zorgepisode of een overgang tussen beide — hangt samen met het nog uit te werken acceptatieproces.
## 4. Wachtlijst
### B7 — Volledige tijdlijn is de bron
**Besluit**
- Plaatsing, aanbod, uitstel, opschorting, hervatting, prioriteitswijziging, verplaatsing, beëindiging en correctie blijven als afzonderlijke gebeurtenissen bewaard.
- De oorspronkelijke aanmeld- en wachtdatum worden niet stilzwijgend overschreven.
- Administratieve verplaatsing tussen teams of programma’s mag wachttijd niet ongemerkt resetten.
- Bruto wachttijd blijft altijd zichtbaar.
- Netto of gecorrigeerde wachttijd is een afleiding op basis van een expliciete, versiegebonden regelset.
- Het datamodel bewaart de feiten; rapportage- en rekenregels bepalen de uitkomst.
### O1 — Wachtlijstmodellering vraagt een aparte verdieping
**Onderzoek**
Voor een definitief model moeten de GGZ-praktijk en actuele NZa-regels verder worden onderzocht, waaronder:
- dragers en cardinaliteiten van wachtlijstplaatsingen;
- onderscheid tussen regulatoire wachttijd, operationele wachtrij en cliëntverloop;
- teldatums en aftrekbare perioden;
- cliëntgebonden uitstel versus capaciteitstekort;
- aanbodmomenten en zorgbemiddeling;
- beëindigingsredenen en verplaatsingen;
- Treeknormbewaking en externe aanlevering;
- versiebeheer en historische reproduceerbaarheid van berekeningen.
De bestaande harde cardinaliteiten en concrete rekenregels in `../deelmodellen/model-wachtlijst.md` zijn daarom voorlopig.
## 5. Behandelplan
### B8 — Eén logisch, multidisciplinair behandelplan
**Besluit**
- Per zorgepisode bestaat één logisch behandelplan.
- Alle betrokken disciplines dragen bij aan hetzelfde plan.
- Afdelings- of disciplinespecifieke deelplannen worden niet als afzonderlijke behandelplannen gemodelleerd.
- Relevante specialistische documenten kunnen worden gekoppeld zonder een concurrerend intern plan te vormen.
- Verschillende gebruikersweergaven worden opgelost met structurering, scopes en filters, niet met extra plannen.
**Bespreekpunt**
Eén gezamenlijk plan kan omvangrijk worden. De UX moet daarom kunnen filteren op aandachtgebied, discipline, programma, verantwoordelijkheid en actualiteit, terwijl de samenhang behouden blijft.
### B9 — Het behandelplan is een domeinmodel, geen formulier
**Besluit**
De stabiele plan-kern bevat ten minste:
- aandachtgebieden;
- doelen;
- interventies en afspraken;
- betrokkenen en tijdgebonden verantwoordelijkheden;
- evaluaties en uitkomsten;
- cliëntperspectief en verschillen van inzicht.
Een aandachtgebied kan vanuit meerdere perspectieven worden geduid, waaronder klacht, diagnose, leefgebied, kracht, beschermende factor, risico, herstel en preventie. Het model dwingt geen keuze af tussen behandelen op problemen of op leefgebieden.
Financieringsdekking is een afzonderlijke dimensie en bepaalt niet welke klinische of maatschappelijke doelen in het plan mogen staan.
### B10 — Preventie is een volwaardig perspectief
**Besluit**
Preventie wordt als volwaardig doel- en aandachtsperspectief ondersteund, bijvoorbeeld voor:
- eenzaamheid en sociale verbinding;
- beschermende factoren;
- netwerkversterking;
- vroegsignalering;
- terugvalpreventie;
- bewezen helpende strategieën.
Dataminimalisatie blijft leidend: het ECD wordt geen onbeperkt sociaal dossier.
### B11 — Eén levend plan met formele snapshots
**Besluit**
- `BEHANDELPLAN` heeft één stabiele identiteit gedurende de episode.
- Het werkplan kan voortdurend worden bijgewerkt onder volledige audit en met auteurschap per wijziging.
- Een inhoudelijke wijziging maakt niet automatisch een nieuw behandelplan.
- Bij formele vaststelling, formele evaluatie en cliëntbespreking ontstaat een onveranderlijke snapshot.
- Eerdere snapshots blijven raadpleegbaar en reproduceerbaar.
- MDO, evaluatie, rapportage en AI wijzigen het plan nooit automatisch.
Dit vervangt het eerdere voorstel waarin iedere versie een volledig nieuw `BEHANDELPLAN`-record was.
### B12 — Procespositie van het behandelplan
**Besluit**
De hoofdroute is:
```text
intakebevindingen
→ conceptplan
→ MDO
→ bespreking met cliënt
→ vastgestelde snapshot
→ uitvoering en periodieke MDO-bespreking
→ formele evaluatie
→ bijgesteld plan en nieuwe snapshot
→ afsluiting
```
- Intakebevindingen zijn broninformatie en worden bewust vertaald naar aandachtgebieden en doelen.
- Een halfjaarlijkse evaluatie is een configureerbare protocolregel, geen hardcoded database-eis.
- TIP bewaakt termijnen en taken; het ECD bewaart de klinische feiten en uitkomsten.
- Zorg kan bij noodzaak starten terwijl het plan nog concept is; dit geeft een nudge en geen generieke databaseblokkade.
### B13 — Planakkoord is snapshotgebonden en geen behandeltoestemming
**Besluit**
- De reactie van de cliënt hoort bij een specifieke plansnapshot.
- Mogelijke uitkomsten zijn onder meer akkoord, gedeeltelijk akkoord, niet akkoord en akkoord niet verkregen.
- Bezwaren en verschillen van inzicht blijven zichtbaar.
- Planakkoord is geen planstatus en geen synoniem voor toestemming voor concrete behandeling.
- Behandeling vereist daarnaast toestemming of een expliciete geldige juridische grondslag.
- Een besluit om ondanks ontbrekend planakkoord door te gaan bevat beslisser, bevoegdheid, motivering, reikwijdte, grondslag en evaluatiedatum.
## 6. MDO, evaluatie, zorgteam en bevoegdheid
### B14 — MDO en evaluatie zijn workflows
**Besluit**
Een MDO is geen enkel verslag of datumveld, maar een workflow met:
- casusinbreng en vraagstelling;
- triage, voorbereiding en agendering;
- sessie en panel;
- feitelijke deelnemers en rollen;
- gedeelde analyse;
- advies, besluit, afwijkende mening of nader onderzoek;
- actiepunten;
- planwijzigingsvoorstellen.
Een formele evaluatie is een cliëntgericht proces met input van cliënt, behandelaren en metingen, beoordeling van doelen, eventuele MDO-bespreking, conclusies, acties en een mogelijke nieuwe plansnapshot.
Een evaluatie kan in een MDO worden besproken, maar is niet hetzelfde als een MDO.
### B15 — MDO is niet automatisch besluitvormend
**Besluit**
- Een MDO is een overlegcontext en heeft niet uit zichzelf beslisbevoegdheid.
- Per casus worden doel en type uitkomst vastgelegd, bijvoorbeeld advies, afstemming, besluit, nader onderzoek of opnieuw agenderen.
- Alleen een expliciet bevoegd besluit kan een vervolgactie autoriseren.
- Een MDO-uitkomst of wijzigingsvoorstel wijzigt het behandelplan niet automatisch.
### B16 — Bevoegdheid hoort bij besluittype en actuele rol
**Besluit**
- Rond de episode bestaat een tijdgebonden zorgteam.
- Professie, teamrol en bevoegdheid zijn verschillende begrippen.
- Rollen kunnen onder meer regiebehandelaar, coördinerend behandelaar, uitvoerend behandelaar en consulent zijn.
- Een psychiater of psycholoog is niet uitsluitend door de professie automatisch regiebehandelaar.
- De vereiste bevoegdheid wordt per besluittype geconfigureerd en gecontroleerd tegen de rol op het moment van het besluit.
- Een besluit kan naast een beslisser eisen stellen aan consultatie, paneldeelname of quorum.
## 7. Longitudinale cliëntinformatie
### B17 — Getypeerde episode-overstijgende informatie
**Besluit**
- Het behandelplan blijft episodegebonden.
- Geselecteerde informatie kan episode-overstijgend relevant blijven, zoals voorgeschiedenis, beschermende factoren, vroegsignalen, helpende strategieën en netwerk- of crisisafspraken.
- Deze informatie krijgt een eigen getypeerd klinisch concept met bronrecord, bronepisode, geldigheid, actualiteitsstatus, reviewdatum en autorisatie.
- Informatie wordt niet door tekstkopieën of een generieke `CLIENT_GEGEVEN`-vergaarbak longitudinaal gemaakt.
- Het expliciet selecteren of bevestigen van episode-overstijgende relevantie is een menselijke handeling.
**Ontwerpuitwerking**
De concrete informatietypen, selectiecriteria, beëindiging van geldigheid en autorisatieregels worden in een latere ronde verkend.
## 8. Rapportage
### B18 — Eén primaire episodecontext
**Besluit**
- Iedere klinische rapportage heeft één primaire zorgepisode.
- Een rapportage mag verwijzen naar eerdere episodes, MDO’s, evaluaties, plansnapshots en longitudinale informatie.
- Een verwijzing verleent geen toegang tot het bronobject.
- Pre-acceptatieregistraties horen bij het aanmeldings- of screeningstraject en vallen onder een afzonderlijk te onderzoeken bewaarbeleid.
- Een MDO-verslag is alleen de verslagcomponent van het MDO en vervangt de MDO-workflow niet.
## 9. Configureerbare behandelvisie en taal
### B19 — Stabiele kern, versiegebonden configuratie
**Besluit**
De klinische kern bewaart stabiele semantische conceptcodes. Een afzonderlijke ADM-configuratielaag bepaalt:
- terminologie en cliëntvriendelijke labels;
- beschikbare perspectieven en waardelijsten;
- groepering en volgorde;
- aanbevolen en verplichte onderdelen;
- standaard evaluatieprotocollen;
- instellings- en afdelingsscope;
- geldigheidsperiode en publicatiestatus.
Een gepubliceerd `BEHANDELVISIEPROFIEL` heeft onveranderlijke versies. Een plansnapshot verwijst naar de gebruikte profielversie, zodat historische inhoud reproduceerbaar blijft.
De instelling bepaalt een minimumbasis. Afdelingen mogen accenten en aanvullende vereisten toevoegen, maar maken geen eigen klinisch schema en verwijderen de instellingsbrede kern niet.
Puur visuele details zoals kleuren en kolombreedtes horen niet in het klinische domeinmodel.
### B20 — Het technische datamodel is Engelstalig
**Besluit**
- Canonieke namen van entiteiten, attributen, relaties, events, API-velden en constraints zijn in het Engels.
- Technische identifiers gebruiken één consistente Engelse naamgevingsconventie; er ontstaat geen gemengd Nederlands-Engels schema.
- Nederlandse UI-labels en cliëntvriendelijke teksten komen uit de configuratie- en presentatielaag.
- Nederlandse wettelijke en professionele begrippen behouden hun officiële brontekst en broncode als metadata en krijgen een expliciete koppeling naar het Engelse kernbegrip.
- De tweetalige begrippenlijst `../begrippenlijst-kernmodel.md` bewaakt de vertaling, betekenis en toegestane synoniemen.
- Nieuwe technische modeldocumentatie wordt in het Engels opgesteld zodra de conceptuele besluiten worden omgezet naar het logische model. Besluitvorming en domeinonderzoek mogen Nederlandstalig blijven.
**Bespreekpunt**
Niet ieder Nederlands zorgbegrip heeft een exacte Engelse vertaling. Begrippen zoals `regiebehandelaar`, `zorgvraagtypering` en `beschikking` mogen daarom niet stilzwijgend worden vereenvoudigd. De begrippenlijst legt per begrip de gekozen technische naam, Nederlandse domeindefinitie en eventuele wettelijke bron vast.
## 10. Vervolg en nog open
### Eerst ontwerpen
1. AANMELDSIGNAAL, AANMELDINGSTRAJECT, toewijzing en niet-destructieve samenvoeging.
2. ACCEPTATIEBESLUIT en de relatie met intake en ZORGEPISODE.
3. Tijdgebonden programma-, organisatie- en zorgteambetrokkenheid.
4. Eén levend BEHANDELPLAN met immutable snapshots.
5. MDO- en evaluatieworkflows.
6. Bevoegdheidsmatrix per besluittype en teamrol.
7. Versiegebonden BEHANDELVISIEPROFIEL in ADM.
8. Engelse werktermen in `../begrippenlijst-kernmodel.md` reviewen en vóór het logische model definitief bevestigen.
### Parallel onderzoeken
1. GGZ-wachtlijstpraktijk en actuele NZa-definities.
2. Bewaarbeleid voor signalen, screening en afgewezen/pre-acceptatietrajecten.
3. Juridische betekenis van acceptatie tegenover behandelovereenkomst en zorgplicht.
4. Autorisatie op historische episode- en longitudinale verwijzingen.
5. Concrete typen en governance van longitudinale cliëntinformatie.
6. Profielmigratie wanneer de behandelvisie tijdens een lopende episode wijzigt.
### Documenten synchroniseren
De volgende documenten bevatten nog voorstellen die door dit log 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`
- `../entiteitenkaarten/entiteitenkaart-instroom.html`
De entiteitenkaart wordt pas opnieuw gegenereerd nadat de Markdown-deelmodellen zijn herzien.

3
docs/datamodel/datamodel-discovery.md → docs/datamodel/deelmodellen/datamodel-discovery.md
View File

@@ -1,6 +1,7 @@
# Datamodel Discovery — ECD
**Status:** verkenning, geen ontwerp
**Status:** verkenning, geen ontwerp
**Besluitenupdate:** zie `../besluiten/besluitenlog-datamodel-2026-07-18.md`. Dit besluitenlog is leidend waar de eerdere discovery of deelmodellen ermee conflicteren.
**Datum:** 16 juli 2026
**Werkwijze:** FCO-IM-geïnspireerd (feitzinnen eerst), visualisaties in HTML op verzoek
**Kader:** ECD bevat ECD-data (proces-state blijft in TIP) · FHIR is niet heilig · huidig prototype-schema is géén vertrekpunt

511
docs/datamodel/deelmodellen/model-aanmelding.md Normal file
View File

@@ -0,0 +1,511 @@
# Datamodelvoorstel — Aanmelding & instroombasis
**Status:** herziening nodig — structureel deels achterhaald door `../besluiten/besluitenlog-datamodel-2026-07-18.md`
**Datum:** 18 juli 2026
**Deelgebied:** PERSOON, CLIENT, VERWIJZER, PRAKTIJK_INSTELLING, AANMELDING, ZORGEPISODE, CLIENTPORTAAL_ACCOUNT + aanvullingen voor een volwassen instroommodel
**Bronnen:** `datamodel-discovery.md`, onderzoek-proces, onderzoek-leveranciers, onderzoek-standaarden, onderzoek-rapportage (details in §8)
> **Let op:** het besluitenlog splitst de huidige AANMELDING in AANMELDSIGNAAL en AANMELDINGSTRAJECT. De ZORGEPISODE ontstaat bij formele acceptatie en heeft een onafhankelijke levenscyclus. Gebruik de huidige entiteiten, cardinaliteiten en statusmachines daarom nog niet als basis voor SQL.
**Conventies (gelden voor alle entiteiten, niet per entiteit herhaald):**
- Elke entiteit heeft `id` (UUID, stabiel — spelregel 3.1 #5), `created_at`, `updated_at`, `deleted_at` (soft delete — spelregel 3.1 #4) en auditvelden conform spelregel 3.1 #3.
- Elke waardelijst is een referentietabel (spelregel 3.1 #1) met per rij: `code`, `omschrijving`, optioneel `externe_code` + `codesysteem` (FHIR/NZa-koppelbaarheid), `geldig_van`, `geldig_tot`, `actief`. De geldigheidsperiode per waarde is een les uit de NZa-codelijsten bij Nedap (onderzoek-leveranciers §2.2, §7.1).
- "Wie mag zetten" is overal **rollenronde** (discovery §5.1 besluit 6), tenzij anders vermeld.
---
## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.1)
### Persoon, contactgegevens en adres
1. *(gewijzigd t.o.v. §5.1 feitzin 1)* Persoon Jan de Vries heeft naamdelen: achternaam "Vries", voorvoegsel "de", voornamen "Jan Willem", initialen "J.W.", roepnaam "Jan". *(gestructureerde naam i.p.v. één naamveld — zib Patient)*
2. Persoon Jan de Vries heeft geslacht "man" (uit waardelijst).
3. Persoon Jan de Vries heeft genderidentiteit "man" (optioneel, uit waardelijst — GGZ-relevant, zib Patient v4.3).
4. Persoon Jan de Vries heeft BSN 123456782. *(optioneel op PERSOON — discovery §5.1 besluit 1; versleuteld — spelregel 3.1 #6)*
5. Persoon Jan de Vries is overleden op 3 maart 2071. *(optioneel expliciet feit — zib Patient)*
6. Persoon Jan de Vries heeft een adres van type "woonadres": Dorpsstraat 1, 1234 AB Ons Dorp, geldig sinds 1 januari 2020.
7. Persoon Jan de Vries heeft contactgegeven van type "telefoon", soort "mobiel privé", waarde "06-12345678", met voorkeursmarkering.
8. Persoon Jan de Vries heeft contactgegeven van type "e-mail", waarde "jan@example.nl".
### Contactpersonen en wettelijk vertegenwoordiger (relatie via PERSOON)
9. Persoon Maria de Vries staat tot cliënt Jan de Vries in relatie "partner" en vervult daarbij de rol "eerste contactpersoon", sinds 14 juli 2026.
10. Persoon K. Bos vervult voor cliënt Jan de Vries de rol "wettelijk vertegenwoordiger" met vertegenwoordigingsgrond "mentor", sinds 1 februari 2026.
11. De relatie van Maria de Vries tot cliënt Jan de Vries is op 1 mei 2027 beëindigd.
### Vaste huisarts
12. Cliënt Jan de Vries heeft huisarts-situatie "huisarts bekend" *(alternatieven: "geen huisarts", "cliënt staat correspondentie met huisarts niet toe" — ZPM-verwijstype 04/05, onderzoek-proces §2.8)*.
13. Cliënt Jan de Vries heeft als vaste huisarts P. Pietersen, verbonden aan Huisartsenpraktijk De Vries & Pietersen, sinds 14 juli 2026. *(vaste huisarts ≠ incidentele verwijzer; kan dezelfde persoon zijn)*
### Verzekering en financiering per wettelijk kader
14. Cliënt Jan de Vries is verzekerd bij zorgverzekeraar met UZOVI-code 3311 onder polisnummer 987654, geldig vanaf 1 januari 2026.
15. De verzekering van Jan de Vries is op 14 juli 2026 geverifieerd via een COV-controle.
16. Bij de aanmelding van 14 juli 2026 onder wettelijk kader "Jeugdwet" hoort gemeentelijke toewijzing 301-20260714-001 van gemeente Utrecht (gemeentecode 0344), met periode 1 augustus 2026 t/m 31 januari 2027. *(alleen bij kader Jeugdwet/Wmo — iJw/iWmo, onderzoek-standaarden §7)*
### Verwijzing (verrijking van de aanmelding)
17. *(verfijnt §5.1 feitzin 8)* Bij de aanmelding van 14 juli 2026 hoort een verwijzing, afgegeven op 1 juli 2026 door verwijzer P. Pietersen. *(verwijsdatum ≠ aanmelddatum; 275-dagentoets en per 2026 verplicht op de declaratie — onderzoek-proces §2.3/§2.10)*
18. De verwijzing vermeldt echelon "gespecialiseerde ggz".
19. De verwijzing vermeldt een vermoeden van een DSM-benoemde psychische stoornis: "depressieve klachten".
20. De verwijzing betreft een heraanmelding: nee.
21. De aanmelding van 14 juli 2026 heeft ZPM-verwijstype "01 — verwijzing aanwezig". *(afleidbaar, maar overschrijfbaar registreerbaar — onderzoek-standaarden §6.3)*
22. De aanmelding van 14 juli 2026 volgt doorverwijsroute "doorverwijzing tussen ggz-aanbieders". *(optioneel; alleen bij één van de vijf erkende routes — onderzoek-proces §2.7)*
23. Voor de aanmelding van 15 juli 2026 zonder verwijzing (crisis) is de huisarts op 20 juli 2026 geïnformeerd. *(60-dagentermijn — onderzoek-proces §2.6)*
### Aanmelding (aanvullingen)
24. De aanmelding van 14 juli 2026 is ontvangen via aanmeldkanaal "ZorgDomein".
25. *(verfijnt §5.1 besluit 5)* De aanmelding van 14 juli 2026 heeft uitkomst "intake", vastgesteld op 17 juli 2026. *(uitkomst + uitkomstdatum als aparte feiten naast de status)*
### Toestemmingen (WGBO/AVG)
26. Cliënt Jan de Vries heeft op 14 juli 2026 toestemming van type "correspondentie met huisarts/verwijzer" verleend, vastgelegd door K. Jansen, wijze "mondeling".
27. Cliënt Jan de Vries heeft op 1 september 2026 de toestemming van type "vermelding DSM-hoofdgroep op factuur" geweigerd.
28. Cliënt Jan de Vries heeft de toestemming van type "correspondentie met huisarts/verwijzer" op 1 december 2026 ingetrokken.
### Zorgepisode
29. Voor cliënt Jan de Vries is op 17 juli 2026 een zorgepisode gestart, voortkomend uit de aanmelding van 14 juli 2026. *(ontstaat bij uitkomst "intake" — zie §5 en besluitpunt 1)*
30. De zorgepisode van Jan de Vries is op 15 maart 2027 afgesloten met reden "behandeling afgerond".
---
## 2. Entiteiten
### 2.1 PERSOON
**Doel:** draagt de identiteit van een natuurlijk persoon, onafhankelijk van rollen (cliënt, contactpersoon, vertegenwoordiger, later medewerker). Discovery §5.1 besluit 1.
| Attribuut | Type | Verplicht |
|---|---|---|
| achternaam | tekst | ja |
| voorvoegsels | tekst | nee |
| voornamen | tekst | nee |
| initialen | tekst | nee |
| roepnaam | tekst | nee |
| geboortedatum | datum | ja |
| geslacht | waardelijst `geslacht` | ja |
| genderidentiteit | waardelijst `genderidentiteit` | nee |
| bsn | tekst, versleuteld (pgcrypto), inzage gelogd | nee *(rolgebonden eis via nudge — §5.1 besluit 1)* |
| overleden | ja/nee | ja (default nee) |
| overlijdensdatum | datum | nee |
**Uniciteit:** BSN uniek indien gevuld (op hash-index over de versleutelde waarde). Geen andere harde uniciteitsregel — naam+geboortedatum-duplicaten worden een nudge ("mogelijke dubbele persoon"), geen constraint.
### 2.2 ADRES
**Doel:** 0..n adressen per persoon (zib Patient: meerdere adressen mogelijk).
| Attribuut | Type | Verplicht |
|---|---|---|
| persoon_id | ref PERSOON | ja |
| adrestype | waardelijst `adrestype` | ja |
| straat | tekst | ja |
| huisnummer | tekst | ja |
| huisnummertoevoeging | tekst | nee |
| postcode | tekst | ja |
| plaats | tekst | ja |
| land | tekst (default NL) | ja |
| geldig_van | datum | nee |
| geldig_tot | datum | nee |
**Uniciteit:** max één actueel (geldig_tot leeg) adres per persoon per adrestype.
### 2.3 CONTACTGEGEVEN
**Doel:** telefoonnummers en e-mailadressen per persoon.
| Attribuut | Type | Verplicht |
|---|---|---|
| persoon_id | ref PERSOON | ja |
| contacttype | waardelijst `contactgegeven_type` (telefoon/e-mail) | ja |
| soort | waardelijst `contactgegeven_soort` (mobiel privé/vast privé/werk/…) | nee |
| waarde | tekst | ja |
| voorkeur | ja/nee | ja (default nee) |
**Uniciteit:** max één voorkeursgegeven per persoon per contacttype.
### 2.4 CLIENT
**Doel:** rol op PERSOON: dit persoon is cliënt bij de instelling. Discovery §5.0 besluit 2 + §5.1 besluit 1.
| Attribuut | Type | Verplicht |
|---|---|---|
| persoon_id | ref PERSOON | ja |
| clientnummer | geheel getal (reeks per instelling) | ja |
| client_sinds | datum | ja |
| huisarts_situatie | waardelijst `huisarts_situatie` | ja (default "onbekend") |
**Uniciteit:** max één CLIENT-rol per PERSOON; clientnummer uniek. Nudge (geen constraint): "cliënt zonder BSN" (Wabvpz — §5.1 besluit 1).
### 2.5 CLIENTRELATIE
**Doel:** contactpersonen en (wettelijk) vertegenwoordigers als relatie tussen een CLIENT en een PERSOON — twee gescheiden assen *relatie* en *rol*, conform zib Contactpersoon (onderzoek-standaarden §2.2). Dekt ook gezaghebbende ouders (jeugd) en mentoren/curatoren (Wvggz/WGBO — onderzoek-proces §8).
| Attribuut | Type | Verplicht |
|---|---|---|
| client_id | ref CLIENT | ja |
| persoon_id | ref PERSOON | ja |
| relatie | waardelijst `relatie` (partner, ouder, kind, …) | nee |
| rol | waardelijst `relatierol` (eerste contactpersoon, wettelijk vertegenwoordiger, …) | ja |
| vertegenwoordigingsgrond | waardelijst `vertegenwoordigingsgrond` | nee (alleen bij rol wettelijk vertegenwoordiger) |
| geldig_van | datum | ja |
| geldig_tot | datum | nee |
| toelichting | tekst | nee |
**Uniciteit:** max één actuele rij per (client, persoon, rol). Meerdere rollen per persoon mogelijk (moeder = ouder + gezaghebbend + eerste contactpersoon = drie assen, twee rijen: rol "gezaghebbende ouder" en rol "eerste contactpersoon", beide relatie "ouder"). Zelfrelatie (persoon = cliënt-persoon) niet toegestaan. Leeftijdsafhankelijke rechten (12/16-grenzen WGBO) zijn autorisatie, geen schema — rollenronde.
### 2.6 VERWIJZER
**Doel:** persoon of functionaris die verwijst. Eigen begrip (discovery §5.0 besluit 3), los van PRAKTIJK_INSTELLING (§5.1 besluit 2). Wordt óók gebruikt als referent voor de vaste huisarts (zie CLIENT_HUISARTS en besluitpunt 3).
| Attribuut | Type | Verplicht |
|---|---|---|
| naam | tekst | ja |
| verwijzertype | waardelijst `verwijzertype` | ja |
| agb_code | tekst (vrije invoer — §5.1 besluit 4) | nee *(nudge indien `agb_verplicht` op het type — §5.1 besluit 3)* |
| praktijk_instelling_id | ref PRAKTIJK_INSTELLING | nee |
| telefoon | tekst | nee |
| e-mail | tekst | nee |
**Uniciteit:** agb_code uniek indien gevuld. Verwijzer kan zonder praktijk bestaan (gemeente-ambtenaar).
### 2.7 PRAKTIJK_INSTELLING
**Doel:** organisatie waaraan verwijzers/huisartsen verbonden zijn. Discovery §5.1 besluit 2.
| Attribuut | Type | Verplicht |
|---|---|---|
| naam | tekst | ja |
| soort | waardelijst `praktijk_soort` (huisartsenpraktijk, ziekenhuis, ggz-instelling, gemeente, arbodienst, overig) | nee |
| agb_code | tekst | nee |
| adres/plaats | tekst | nee |
| telefoon | tekst | nee |
**Uniciteit:** agb_code uniek indien gevuld.
### 2.8 CLIENT_HUISARTS
**Doel:** de **vaste huisarts** van de cliënt, los van de incidentele verwijzer. Nodig omdat de huisarts ook informatie-ontvanger is wanneer hij níet de verwijzer is (intakebrief, beloopsbrief, 60-dagenmelding — onderzoek-proces §2.9, §10.2).
| Attribuut | Type | Verplicht |
|---|---|---|
| client_id | ref CLIENT | ja |
| verwijzer_id | ref VERWIJZER (type huisarts) | nee |
| praktijk_instelling_id | ref PRAKTIJK_INSTELLING | nee |
| geldig_van | datum | ja |
| geldig_tot | datum | nee |
**Uniciteit:** max één actuele registratie per cliënt. Minstens één van verwijzer_id/praktijk_instelling_id gevuld (soms is alleen de praktijk bekend). De situatie "geen huisarts"/"geen toestemming" staat op CLIENT.huisarts_situatie, niet hier.
### 2.9 VERZEKERING
**Doel:** Zvw-verzekeringsgegevens van de cliënt (financieringskant bij kader Zvw). Historisch, want verzekeraars wisselen per jaar.
| Attribuut | Type | Verplicht |
|---|---|---|
| client_id | ref CLIENT | ja |
| uzovi_code | tekst | ja |
| verzekeraar_naam | tekst | nee |
| polisnummer | tekst | nee |
| geldig_van | datum | ja |
| geldig_tot | datum | nee |
| cov_gecontroleerd_op | datum | nee |
**Uniciteit:** max één actuele verzekering per cliënt. Nudge: "Zvw-aanmelding zonder actuele COV-controle". Wlz-indicatie en forensische titel: declaratie-ronde (besluitpunt 7).
### 2.10 AANMELDING
**Doel:** de binnenkomst-*gebeurtenis* (discovery §5.1 besluit 9). Draagt aanmelddatum (wettelijk controleerbaar gegeven — onderzoek-proces §2.3), kanaal, kader, hulpvraag, status en uitkomst. Screening en aanmeldwachttijd hangen hieraan (§5.2, §5.3).
| Attribuut | Type | Verplicht |
|---|---|---|
| client_id | ref CLIENT | ja |
| aanmelddatum | datum | ja |
| aanmeldkanaal | waardelijst `aanmeldkanaal` | nee |
| wettelijk_kader | waardelijst `wettelijk_kader` | ja (§5.0 besluit 4) |
| hulpvraag | tekst | ja |
| status | waardelijst `aanmelding_status` | ja (default "nieuw") |
| uitkomst | waardelijst `aanmelding_uitkomst` | nee (verplicht bij status "besloten") |
| uitkomst_datum | datum | nee (verplicht bij uitkomst) |
| zpm_verwijstype | waardelijst `zpm_verwijstype` | nee *(afleidbaar uit verwijzing/toestemmingen, overschrijfbaar; verplicht richting declaratie bij Zvw)* |
| doorverwijsroute | waardelijst `doorverwijsroute` | nee |
| huisarts_geinformeerd_op | datum | nee *(instroom zonder verwijzing; nudge harde termijn 60 dagen)* |
| toelichting | tekst | nee |
**Uniciteit:** geen harde beperking op parallelle aanmeldingen; "max één actieve aanmelding per cliënt" is een aan/uit-zetbare bedrijfsregel (§5.0 besluit 5) — in TIP/Nudge, niet in schema.
### 2.11 VERWIJZING *(nieuw — besluitpunt 2)*
**Doel:** de verwijzing als eigen registratie-object bij de aanmelding. Verfijnt §5.1 feitzin 8: "ontvangen via verwijzer X" blijft waar, maar de verwijzing draagt eigen wettelijk relevante feiten die niet op de aanmelding of de verwijzer thuishoren: **verwijsdatum** (275-dagentoets; per 1-1-2026 verplicht op elke declaratie), echelon, DSM-vermoeden, heraanmelding-vlag (onderzoek-proces §2, onderzoek-standaarden §8). Een zelfaanmelding heeft géén verwijzing.
| Attribuut | Type | Verplicht |
|---|---|---|
| aanmelding_id | ref AANMELDING | ja |
| verwijzer_id | ref VERWIJZER | ja |
| verwijsdatum | datum | ja |
| echelon | waardelijst `echelon` | nee *(ontbreekt op verwijzing → aanbieder kiest zelf, onderzoek-proces §2.5)* |
| vermoeden_dsm_stoornis | tekst | nee |
| heraanmelding | ja/nee | ja (default nee) |
| toelichting | tekst | nee |
**Uniciteit:** max één verwijzing per aanmelding. Geldigheidstoets (aanmelddatum − verwijsdatum ≤ 275 dagen) is een nudge, geen constraint (onvolledige/late verwijzing mag — inspanningsverplichting, onderzoek-proces §2.5).
### 2.12 VERWIJSDOCUMENT
**Doel:** ontvangen documenten bij de aanmelding, getypeerd (verwijsbrief, beschikking, …) — discovery §5.1 besluit 7.
| Attribuut | Type | Verplicht |
|---|---|---|
| aanmelding_id | ref AANMELDING | ja |
| documenttype | waardelijst `verwijsdocument_type` | ja |
| document_referentie | ref documentopslag (UUID) | ja |
| ontvangen_op | datum | ja |
**Uniciteit:** geen (meerdere documenten per aanmelding toegestaan).
### 2.13 TOEWIJZING *(nieuw — gemeentelijk kader)*
**Doel:** bij kader Jeugdwet/Wmo is de "verwijzing" feitelijk een gemeentelijke beschikking/toewijzing met eigen sleutelgegevens (iWmo/iJw 301-bericht) — meer structuur dan een document alleen (onderzoek-standaarden §7). Minimale variant nu; productcodes/volume volgen in de declaratie-ronde (besluitpunt 6).
| Attribuut | Type | Verplicht |
|---|---|---|
| aanmelding_id | ref AANMELDING | ja |
| gemeentecode | tekst (CBS-code) | ja |
| gemeente_naam | tekst | nee |
| toewijzingsnummer | tekst | ja |
| ingangsdatum | datum | ja |
| einddatum | datum | nee |
**Uniciteit:** toewijzingsnummer uniek per gemeentecode.
### 2.14 TOESTEMMING *(nieuw — besluitpunt 4)*
**Doel:** één generieke toestemmingsentiteit (WGBO/AVG). Toestemmingen duiken in de instroom al op drie plekken op: correspondentie huisarts/verwijzer (verwijstype 04!), DSM-hoofdgroep op factuur (opt-in sinds 2025), privacyverklaring zorgvraagtypering (onderzoek-standaarden §9.5; onderzoek-proces §2.8/§7). Cliëntakkoord op het behandelplan blijft een **apart feit bij het behandelplan** (deelgebied §5.5), geen TOESTEMMING-rij.
| Attribuut | Type | Verplicht |
|---|---|---|
| client_id | ref CLIENT | ja |
| toestemmingstype | waardelijst `toestemming_type` | ja |
| status | waardelijst `toestemming_status` | ja |
| datum | datum | ja |
| wijze | waardelijst `toestemming_wijze` | nee |
| vastgelegd_door | ref medewerker (rollenronde) | ja |
| geldig_tot | datum | nee |
| ingetrokken_op | datum | nee |
| scope_aanmelding_id / scope_episode_id | ref (optioneel) | nee *(default: cliëntbreed)* |
| toelichting | tekst | nee |
**Uniciteit:** max één actuele (niet-ingetrokken) rij per (client, toestemmingstype, scope). Intrekken = nieuw statusfeit, historie blijft (append-only audit).
### 2.15 ZORGEPISODE
**Doel:** de periode van zorg (discovery §5.1 besluit 9). Draagt intakes, diagnoses, behandelplannen, behandelwachttijd, zorgvraagtypering (latere ronde). Klinisch object, **niet** het ZPM-zorgtraject — verwant, gekoppeld, geen 1-op-1 (onderzoek-standaarden §6.1; onderzoek-leveranciers §2.3).
| Attribuut | Type | Verplicht |
|---|---|---|
| client_id | ref CLIENT | ja |
| aanmelding_id | ref AANMELDING (herkomst) | ja |
| startdatum | datum | ja |
| status | waardelijst `episode_status` | ja (default "lopend") |
| echelon_actueel | waardelijst `echelon` | nee *(kan wijzigen door op-/afschalen — besluitpunt 5)* |
| einddatum | datum | nee |
| einde_reden | waardelijst `episode_einde_reden` | nee (verplicht bij afsluiten; startlijst te bevestigen, sluit t.z.t. aan op iStd-redenen) |
| zorgtrajectnummer | tekst | nee *(gereserveerd; invulling declaratie-ronde)* |
**Uniciteit:** max één episode per aanmelding (een aanmelding met uitkomst "intake" leidt tot precies één episode; afgewezen/doorverwezen aanmeldingen hebben er nooit één — §5.1 besluit 9). Meerdere episodes per cliënt door de tijd. **Ontstaansmoment: bij uitkomst "intake", niet bij "wachtlijst"** — zie §5 en besluitpunt 1.
### 2.16 CLIENTPORTAAL_ACCOUNT
**Doel:** relatie-placeholder (discovery §5.1 besluit 8). Wettelijke basis: elektronische inzage Wabvpz (onderzoek-proces §8).
| Attribuut | Type | Verplicht |
|---|---|---|
| client_id | ref CLIENT | ja |
**Uniciteit:** max één account per CLIENT (1-op-0..1). Authenticatiedetails en statussen: auth/ADM-ronde. Portaaltoegang voor vertegenwoordigers (ouders, 12–16-regels) raakt CLIENTRELATIE — ook auth-ronde.
---
## 3. Relaties met cardinaliteit
| Van | Naar | Cardinaliteit | Toelichting |
|---|---|---|---|
| PERSOON | ADRES | 1 — 0..n | max 1 actueel per adrestype |
| PERSOON | CONTACTGEGEVEN | 1 — 0..n | |
| PERSOON | CLIENT | 1 — 0..1 | rol; één cliëntrol per persoon |
| CLIENT | CLIENTRELATIE | 1 — 0..n | contactpersonen/vertegenwoordigers |
| PERSOON | CLIENTRELATIE | 1 — 0..n | de relatie-persoon |
| VERWIJZER | PRAKTIJK_INSTELLING | 0..n — 0..1 | verwijzer kan zonder praktijk |
| CLIENT | CLIENT_HUISARTS | 1 — 0..n | max 1 actueel |
| CLIENT_HUISARTS | VERWIJZER / PRAKTIJK_INSTELLING | — 0..1 / 0..1 | minstens één gevuld |
| CLIENT | VERZEKERING | 1 — 0..n | max 1 actueel |
| CLIENT | AANMELDING | 1 — 0..n | episodisch (§5.0 besluit 2) |
| AANMELDING | VERWIJZING | 1 — 0..1 | zelfaanmelding: geen |
| VERWIJZING | VERWIJZER | 0..n — 1 | |
| AANMELDING | VERWIJSDOCUMENT | 1 — 0..n | |
| AANMELDING | TOEWIJZING | 1 — 0..n | alleen kader Jeugdwet/Wmo |
| AANMELDING | ZORGEPISODE | 1 — 0..1 | alleen bij uitkomst "intake" |
| CLIENT | ZORGEPISODE | 1 — 0..n | |
| CLIENT | TOESTEMMING | 1 — 0..n | |
| CLIENT | CLIENTPORTAAL_ACCOUNT | 1 — 0..1 | |
**Naar andere deelgebieden:**
| Van | Naar (deelgebied) | Cardinaliteit |
|---|---|---|
| AANMELDING | SCREENING (§5.2) | 1 — 0..1 |
| AANMELDING | WACHTLIJSTPLAATSING soort "aanmeld" (§5.3) | 1 — 0..n |
| ZORGEPISODE | INTAKE (§5.2) | 1 — 0..n (regulier + intern) |
| ZORGEPISODE | WACHTLIJSTPLAATSING soort "behandel" (§5.3) | 1 — 0..n |
| ZORGEPISODE | DIAGNOSE (§5.4) | 1 — 0..n |
| ZORGEPISODE | BEHANDELPLAN (§5.5) | 1 — 0..n (versies) |
| ZORGEPISODE | ZORGVRAAGTYPERING (latere ronde) | 1 — 0..n |
| ZORGEPISODE | regiebehandelaar-toewijzing (rollenronde) | 1 — 0..n |
| TOESTEMMING | correspondentie-verplichtingen (latere ronde: intakebrief, beloopsbrief) | grondslag per verstrekking |
---
## 4. Waardelijsten
Alle lijsten volgen het conventie-patroon (code, omschrijving, externe code, geldigheid). Startwaarden:
1. **geslacht** — man, vrouw, anders, onbekend *(externe code: HL7 AdministrativeGender)*
2. **genderidentiteit** — man, vrouw, non-binair, anders, zegt_het_niet *(zib Patient v4.3)*
3. **adrestype** — woonadres, postadres, tijdelijk_verblijf
4. **contactgegeven_type** — telefoon, email
5. **contactgegeven_soort** — mobiel_prive, vast_prive, werk, overig
6. **relatie** — partner, ouder, kind, broer_zus, familielid_overig, vriend_kennis, professional, overig
7. **relatierol** — eerste_contactpersoon, wettelijk_vertegenwoordiger, gezaghebbende_ouder, mantelzorger, naaste *(twee assen relatie × rol — zib Contactpersoon)*
8. **vertegenwoordigingsgrond** — curator, mentor, schriftelijk_gemachtigde, ouder_voogd, partner_familie *(WGBO-volgorde, onderzoek-proces §8)*
9. **huisarts_situatie** — bekend, geen_huisarts, geen_toestemming_correspondentie, onbekend *(voedt ZPM-verwijstype 04/05)*
10. **verwijzertype** — met attribuut `agb_verplicht` (ja/nee), §5.1 besluit 3. Startwaarden (discovery §5.0 besluit 3 + Verwijsafspraken GGZ, onderzoek-proces §2.2):
| code | agb_verplicht |
|---|---|
| huisarts | ja |
| medisch_specialist | ja |
| straatdokter | ja |
| bedrijfsarts | ja |
| regiebehandelaar | ja |
| ggz_instelling | ja |
| gemeente | nee |
| zelfaanmelding | nee |
| crisis | nee |
11. **praktijk_soort** — huisartsenpraktijk, ziekenhuis, ggz_instelling, gemeente, arbodienst, overig
12. **wettelijk_kader** — met attribuut `verwijsnudge_severity` (§5.1 besluit 7): zvw (blokkade), jeugdwet (signaal), wmo (signaal), wlz (waarschuwing), forensisch (waarschuwing) *(severity-startwaarden te bevestigen in de nudge-ronde; NB bij Zvw zonder spoed/Wvggz is ontbrekende verwijzing feitelijk declaratie-blokkerend — onderzoek-proces §10.3)*
13. **aanmeldkanaal** — zorgdomein, brief_post, e_mail, telefonisch, clientportaal, crisis, intern, overig
14. **aanmelding_status** — nieuw, in_screening, besloten *(§5.1 besluit 5)*
15. **aanmelding_uitkomst** — intake, afgewezen, doorverwezen, wachtlijst *(§5.1 besluit 5)*
16. **verwijsdocument_type** — verwijsbrief, beschikking, wlz_indicatiebesluit, huisartsmelding_60dagen, medische_verklaring_wvggz, overig *(§5.1 besluit 7, uitgebreid)*
17. **echelon** — gb_ggz, g_ggz, onbekend
18. **zpm_verwijstype** — 01 t/m 07 conform ZPM-veldafspraken (externe code = Vektis/ZPM-code; onderzoek-standaarden §6.3): 01 verwijzing_aanwezig, 02 doorverwijzing_regiebehandelaar, 03 geen_verwijzing_verlate_correspondentie, 04 geen_verwijzing_correspondentie_niet_toegestaan, 05 geen_verwijzing_niet_declarabel, 06 geen_verwijzing_andere_grond_fz, 07 verwijzing_zonder_agb
19. **doorverwijsroute** — justitieel_traject, einde_wlz_indicatie, overgang_jeugdwet, vervolg_acute_ggz, ggz_naar_ggz *(de vijf erkende routes; moet uit het dossier blijken — onderzoek-proces §2.7)*
20. **toestemming_type** — met attribuut `grondslag` (tekst): correspondentie_huisarts_verwijzer (WGBO/verwijsafspraken), dsm_hoofdgroep_op_factuur (Stcrt. 2025-11955, opt-in), privacyverklaring_zorgvraagtypering (NZa), gegevensdeling_derden (AVG), inzage_naasten (WGBO)
21. **toestemming_status** — verleend, geweigerd, ingetrokken
22. **toestemming_wijze** — mondeling, schriftelijk, portaal
23. **episode_status** — lopend, afgesloten
24. **episode_einde_reden** — behandeling_afgerond, doorverwezen, client_beeindigt, geen_contact, overleden, overig *(startlijst; mapping op iStandaarden-redenen in de declaratie-ronde)*
---
## 5. Statusmachine
### AANMELDING
Statussen: `nieuw` → `in_screening` → `besloten`. Flexibel, geen eenrichtingsflow (§5.1 besluit 5).
| Van | Naar | Voorwaarde |
|---|---|---|
| nieuw | in_screening | — |
| nieuw | besloten | direct besluit toegestaan (bijv. evidente doorverwijzing) |
| in_screening | besloten | uitkomst + uitkomst_datum verplicht |
| besloten | in_screening | heropening; uitkomst en uitkomst_datum worden gearchiveerd in de audit, velden leeg |
Regels in het model (spelregel 3.1 #7/#9): check-constraint "status = besloten ⇒ uitkomst en uitkomst_datum gevuld"; overgangen in een referentietabel `statusovergang` (entiteit, van, naar), niet in schermcode. Bij uitkomst `intake`: ZORGEPISODE wordt aangemaakt (zie hieronder). Bij uitkomst `wachtlijst`: WACHTLIJSTPLAATSING soort "aanmeld" aan de AANMELDING — **geen episode**.
**Wie mag zetten: rollenronde** (§5.1 besluit 6). Kandidaat-inperking om daar te toetsen: `besloten` alleen door een rol met indicatiebevoegdheid (LKS: indicerende rol regiebehandelaar).
### ZORGEPISODE
Statussen: `lopend` → `afgesloten`.
| Van | Naar | Voorwaarde |
|---|---|---|
| lopend | afgesloten | einddatum + einde_reden verplicht |
| afgesloten | lopend | heropening bij administratieve fout; terugval krijgt een **nieuwe episode** (besluitpunt 8) |
**Ontstaansregel (beantwoording open detail §5.1 besluit 9):** de episode ontstaat op het moment dat de aanmelding uitkomst **"intake"** krijgt; startdatum = uitkomst_datum. Bij uitkomst "wachtlijst" ontstaat géén episode. Onderbouwing: de NZa-behandelwachttijd loopt vanaf de intake en de verantwoordelijkheidsoverdracht van verwijzer naar aanbieder ligt ná de intake bij de regiebehandelaar (LKS 4.0; onderzoek-proces §1, §4.2, §10.3 — "episode pas bij intake, aanmeldwachttijd op de aanmelding"). De aanmeldwachtlijst hangt aan de AANMELDING (§5.3-besluit), dus er gaat niets verloren. Komt de cliënt van de aanmeldwachtlijst alsnog naar intake, dan wordt de uitkomst bijgewerkt naar "intake" (heropening → besloten) en ontstaat de episode alsnog. **Wie mag zetten: rollenronde.**
### Overige entiteiten
PERSOON, CLIENT, VERWIJZER, PRAKTIJK_INSTELLING, VERWIJZING, TOEWIJZING, CLIENT_HUISARTS, VERZEKERING: geen statusmachine — levenscyclus via geldigheidsperioden en soft delete. TOESTEMMING: `verleend`/`geweigerd` → `ingetrokken` (eenrichting; nieuwe toestemming = nieuwe rij). CLIENTPORTAAL_ACCOUNT: statusmachine in de auth/ADM-ronde.
---
## 6. ECD/TIP-eigenaarschap en events richting TIP
**Eigenaarschap:** alle entiteiten in dit deelgebied zijn **leidend in het ECD** (klinische/administratieve feiten — discovery §3.3). TIP houdt de proces-state: screeningstaken, termijnbewaking, wachtlijst-nudges, "max één actieve aanmelding"-bedrijfsregel.
**Events naar TIP** (mutatie-events, zelfde mechanisme als her-embedding — §3.3 koppelafspraak; payload bevat UUID + content-hash, **nooit BSN** — spelregel 3.1 #6):
| Event | Trigger | Waarvoor TIP het nodig heeft |
|---|---|---|
| `client_geregistreerd` | nieuwe CLIENT | workspace/dossiercontext aanmaken |
| `aanmelding_geregistreerd` | nieuwe AANMELDING | screeningstaak starten; Treeknorm-klok aanmeldwachttijd (4 wkn); 275-dagentoets als verwijzing volgt |
| `aanmelding_status_gewijzigd` | statusovergang | procesbewaking, heropening detecteren |
| `aanmelding_besloten` | status besloten (incl. uitkomst) | vervolgacties: intake plannen / wachtlijst / terugverwijsbrief |
| `verwijzing_geregistreerd` | nieuwe/gewijzigde VERWIJZING | 275-dagen-geldigheidsnudge; "verwijzing onvolledig"-inspanningsnudge |
| `verwijzing_ontbreekt` | aanmelding zonder VERWIJZING onder Zvw | nudge met severity per wettelijk kader (§5.1 besluit 7); 60-dagen-huisartsmelding-termijn |
| `toewijzing_geregistreerd` | nieuwe TOEWIJZING | iWmo/iJw-startberichten (305) t.z.t. |
| `zorgepisode_gestart` | nieuwe ZORGEPISODE | Treeknorm-klok behandelwachttijd (10 wkn); regiebehandelaar-toewijzing agenderen |
| `zorgepisode_afgesloten` | status afgesloten | afrondingsbrief-taak; terugval-venster 1 jaar (ZPM) bewaken |
| `toestemming_gewijzigd` | TOESTEMMING-mutatie | correspondentie-taken blokkeren/vrijgeven (intakebrief vereist toestemming) |
| `clientrelatie_gewijzigd` | CLIENTRELATIE-mutatie | vertegenwoordiger-afhankelijke rechten/portaal |
| `huisarts_gewijzigd` | CLIENT_HUISARTS / huisarts_situatie | correspondentie-adressering; verwijstype-afleiding |
TIP-snapshots van deze data zijn doelgebonden auditkopieën met herkomst (afstemming Joshua, discovery §3.3) — het ECD blijft bron.
---
## 7. Open besluitpunten voor Colin
1. **Ontstaansmoment ZORGEPISODE — ter bekrachtiging.** Voorstel: episode ontstaat bij uitkomst "intake", niet bij "wachtlijst" (onderbouwing §5). **Advies: bekrachtigen** — alle bronnen (LKS-verantwoordelijkheidsoverdracht, NZa-wachttijddefinities) wijzen dezelfde kant op, en de aanmeldwachtlijst hangt toch al aan de AANMELDING.
2. **VERWIJZING als eigen entiteit** tussen AANMELDING en VERWIJZER (verwijsdatum, echelon, DSM-vermoeden, heraanmelding). **Advies: ja** — de verwijsdatum is per 2026 verplicht op elke declaratie en de 275-dagentoets vereist verwijsdatum ≠ aanmelddatum; dat hoort niet als los veld op de aanmelding (zelfaanmelding heeft er geen) en niet op de verwijzer (die verwijst vaker).
3. **Vaste huisarts via hergebruik van VERWIJZER/PRAKTIJK_INSTELLING** (CLIENT_HUISARTS verwijst ernaar) of een aparte generalisatie EXTERNE_ZORGVERLENER. **Advies: hergebruik nu** — een huisarts is per definitie een potentiële verwijzer; generaliseren pas als er meer externe rollen bijkomen (ketenpartners, apotheek). Semantische scheefheid ("verwijzer die nooit verwees") accepteren als bekende schuld.
4. **TOESTEMMING nu al als generieke entiteit opnemen** (i.p.v. uitstellen naar een latere ronde zoals onderzoek-standaarden §9.5 suggereert). **Advies: nu opnemen met kleine startwaardelijst** — verwijstype 04 en de intakebrief maken toestemming al in de instroomflow nodig; uitstellen betekent losse vlaggen die later gemigreerd moeten worden.
5. **Echelon op twee plekken:** bron-echelon op VERWIJZING én actueel echelon op ZORGEPISODE (op-/afschalen binnen één aanbieder is geen doorverwijzing). **Advies: beide, episode-veld optioneel** — nodig voor wachttijd-uitsplitsing en factuurinhoud (g-ggz vs gb-ggz).
6. **TOEWIJZING minimaal nu** (gemeente, nummer, periode) en productcategorie/-code/volume in de declaratie-ronde. **Advies: akkoord met minimale variant** — het toewijzingsnummer is de sleutel die alle latere iWmo/iJw-berichten nodig hebben; de rest is declaratie-detail.
7. **Financieringsdetail Wlz/forensisch** (indicatiebesluit, strafrechtelijke titel) doorschuiven naar de declaratie-ronde; nu alleen VERZEKERING (Zvw) en TOEWIJZING (gemeentelijk). **Advies: doorschuiven** — het wettelijk kader zelf staat al op de aanmelding; de bronnen geven voor Wlz/fz nog te weinig structuurzekerheid.
8. **Terugval binnen 1 jaar:** nieuwe ZORGEPISODE met hergebruik van het ZPM-zorgtrajectnummer, of heropening van de oude episode? **Advies: nieuwe episode** — klinisch is het een nieuwe zorgperiode; het trajectnummer-hergebruik (NZa-regel) is een declaratie-koppeling, geen reden om episodes samen te smelten. Definitief te maken in de declaratie-ronde (episode ↔ zorgtraject niet 1-op-1).
9. **Huisarts-informeren als attribuut** (`huisarts_geinformeerd_op` op AANMELDING) of als onderdeel van een toekomstige CORRESPONDENTIE-entiteit (intakebrief, beloopsbrief, afrondingsbrief). **Advies: attribuut nu, CORRESPONDENTIE-entiteit in de rapportage-ronde** — de 60-dagentermijn is een hard wettelijk feit dat nu al een nudge nodig heeft; de brievenstroom is een groter onderwerp dat een eigen ronde verdient (onderzoek-proces §10.3 verrijking 9).
10. **Startwaarden `verwijsnudge_severity` per wettelijk kader** (waardelijst 12): bij Zvw is ontbrekende verwijzing zonder spoed/Wvggz-grond feitelijk declaratie-blokkerend — is `blokkade` daar de juiste severity, en welke voor Wlz/forensisch? **Advies: vaststellen in de nudge-/declaratie-ronde**, waardelijst-attribuut staat er klaar voor.
---
## 8. Bronverwijzingen
| Onderdeel | Bron |
|---|---|
| PERSOON/CLIENT-splitsing, BSN optioneel | discovery §5.1 besluit 1; spelregel 3.1 #6 |
| Gestructureerde naam, meerdere adressen, geslacht/genderidentiteit, overlijden | onderzoek-standaarden §2.2 (zib Patient v4.3), §8 |
| CLIENTRELATIE met twee assen relatie × rol | onderzoek-standaarden §2.2 (zib Contactpersoon v5.0); onderzoek-leveranciers §2.2 (Nedap ClientContactRelation + Type) |
| Vertegenwoordiging, leeftijdsgrenzen 12/16 | onderzoek-proces §8 (WGBO/KNMG) |
| Vaste huisarts als informatie-ontvanger, huisarts onbekend/geen toestemming | onderzoek-proces §2.8–§2.9 |
| VERWIJZING: verwijsdatum, 275 dagen, echelon, heraanmelding, DSM-vermoeden | onderzoek-proces §2.3–§2.5, §2.10 (Verwijsafspraken GGZ, NHG-richtlijn, NR/REG-2616a); onderzoek-standaarden §2.2, §8 |
| ZPM-verwijstypen 01–07, zorglabels | onderzoek-standaarden §6.3 (ZPM-veldafspraken jan 2022) |
| Doorverwijsroutes (5 erkende) | onderzoek-proces §2.7 |
| 60-dagen-huisartsmelding | onderzoek-proces §2.6 |
| Referral-decompositie marktconform | onderzoek-leveranciers §2.2 (Nedap Referral) |
| TOEWIJZING (iWmo/iJw 301, woonplaatsbeginsel) | onderzoek-standaarden §7 |
| VERZEKERING/COV | onderzoek-proces §10.1 stap 2; iStandaarden/Vecozo-praktijk |
| TOESTEMMING generiek (drie vindplaatsen) | onderzoek-standaarden §9.5; onderzoek-proces §2.8, §7 (opt-in DSM, privacyverklaring) |
| Episode-ontstaan bij intake | onderzoek-proces §1 (LKS-verantwoordelijkheidsoverdracht), §4.1–§4.2 (Treeknorm/NZa-definities), §10.3 |
| Episode ≠ ZPM-zorgtraject, trajectnummer-hergebruik | onderzoek-standaarden §6.1; onderzoek-leveranciers §2.3 |
| Statusmachine expliciet, regels in model | spelregels 3.1 #7/#9; discovery §5.1 besluiten 5–6 |
| Waardelijsten met geldigheidsperioden en externe codes | onderzoek-leveranciers §2.2/§7.1; onderzoek-standaarden §8 |
| TIP-grensvlak, events, snapshots | discovery §3.3 (afstemming Joshua 17-7-2026) |
| Wachtlijst aan aanmelding/episode | discovery §5.3-besluit; onderzoek-proces §4 |

279
docs/datamodel/deelmodellen/model-behandelplan.md Normal file
View File

@@ -0,0 +1,279 @@
# Datamodelvoorstel — Behandelplan (deelgebied §5.5)
**Status:** structurele herziening nodig — het snapshotbesluit in `../besluiten/besluitenlog-datamodel-2026-07-18.md` is leidend
**Datum:** 18 juli 2026
**Kader:** bouwt voort op `datamodel-discovery.md` (spelregels §3.1, TIP-grensvlak §3.3, besluiten §5). Geen enkel genomen besluit wordt teruggedraaid. Scope conform besluit §5.5: plan-kern — doelen, interventies, evaluatiemomenten, status, versiebeheer, cliëntakkoord. Sessieplanning → agenda-ronde; leefgebieden en veiligheidsplan → aparte beslissing later.
> **Let op:** de kernopzet hieronder — één volledig nieuw BEHANDELPLAN-record per versie — is vervangen door één logisch, levend behandelplan per zorgepisode met onveranderlijke formele snapshots. Ook MDO, evaluatie, behandelvisieconfiguratie, planakkoord en multidisciplinaire bijdragen zijn in het besluitenlog nader bepaald. Gebruik dit voorstel nog niet als basis voor SQL.
**Kernkeuzes in dit voorstel** (onderbouwing in §5.5-open-vragen → bronnen):
1. **Versiebeheer = nieuw record per versie.** Een vastgesteld plan is onveranderlijk; elke inhoudelijke wijziging is een nieuwe planversie die de vorige vervangt. Gedragen door LKS 4.0 ("substantiële aanpassing ⇒ nieuw behandelplan"), de Nedap-praktijk (DRAFT/ACTIVE/OLD, versie = nieuw plan) en spelregel §3.1 #3 (append-only denken). Muteren mag alleen in status `concept`.
2. **Cliëntakkoord = los feit, geen status.** Eigen entiteit BEHANDELPLAN_AKKOORD met datum, wijze van bespreken en wie akkoord gaf (cliënt of vertegenwoordiger, WGBO 12/16-grenzen). Gedragen door LKS 4.0 (toestemming is een gebeurtenis vóór vaststelling), WGBO informed consent, FHIR-patroon (CarePlan.status ≠ Consent) en Nedap (CarePlanAgreement + discussionType).
3. **Statusmachine minimaal:** `concept → vastgesteld → vervangen | afgesloten`, plus `vervallen` voor ingetrokken concepten. Proces-toestanden als "in evaluatie" zijn TIP-terrein, geen ECD-status.
4. **Kwaliteitsstatuut-eisen als vaststellings-voorwaarden:** regiebehandelaar, ≥1 doel, ≥1 evaluatiemoment, crisis- en waarnemingsafspraken zijn verplicht op het moment van vaststellen (niet al in concept).
---
## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.5)
Discovery-feitzinnen 1 t/m 9 blijven geldig; hieronder de uitgewerkte en nieuwe set. **[G]** = gewijzigd/verfijnd t.o.v. discovery, **[N]** = nieuw.
**Plan en versie**
1. [G] *Voor de zorgepisode van Jan de Vries is op 1 augustus 2026 behandelplan-versie 1 opgesteld door M. de Boer.* (versienummer expliciet vanaf versie 1)
2. *Het behandelplan heeft status "concept".*
3. [G] *Het behandelplan is gebaseerd op de intake van 20 juli 2026 (herkomst, optioneel) en adresseert diagnose F32.1 (verplicht bij vaststelling, meerdere mogelijk).*
4. [N] *In het behandelplan is vastgelegd dat psychiater A. Visser de rol van regiebehandelaar vervult in de behandelfase.* (LKS §3.6.2 onderdeel 5)
5. [N] *Het behandelplan bevat afspraken hoe te handelen bij crisis en wie waarneemt bij afwezigheid van de regiebehandelaar.* (LKS §3.6.2 onderdeel 4)
6. [N] *Behandelplan-versie 1 is op 6 augustus 2026 vastgesteld door regiebehandelaar A. Visser.*
7. [G] *Behandelplan-versie 2 vervangt versie 1; bij vaststelling van versie 2 op 15 september 2026 kreeg versie 1 status "vervangen".*
8. [N] *Behandelplan-versie 1 is als concept ingetrokken (status "vervallen") zonder ooit te zijn vastgesteld.*
9. [N] *Het behandelplan is bij afronding van de behandeling op 1 maart 2027 afgesloten.*
**Doelen**
10. [G] *Behandelplan-versie 1 bevat behandeldoel "weer drie nachten per week doorslapen" met prioriteit "hoog" en streefdatum 24 oktober 2026 (beoogde termijn 12 weken).* (LKS: doelen voor een bepaalde, te evalueren periode)
11. *Behandeldoel X heeft een cliëntversie in B1-taal.*
12. [N] *Behandeldoel X richt zich op diagnose F32.1.* (optionele verwijzing per doel, naast de plan-brede koppeling)
13. [N] *Behandeldoel X in versie 2 is de voortzetting van behandeldoel X' in versie 1.* (keten voor trendmeting over versies heen)
14. [N] *Behandeldoel X heeft status "behaald" sinds 15 september 2026.*
**Interventies**
15. [G] *Behandelplan-versie 1 bevat interventie van type "CGT", uitgevoerd door psycholoog M. de Boer.* (LKS §3.6.2 onderdeel 3: wie voert uit)
16. [G] *Interventie "CGT" is gekoppeld aan behandeldoel X en behandeldoel Y.* (m:n, minimaal één doel)
17. [N] *Interventie "eHealth-module slaaptraining" verwijst naar externe activiteit met systeem "Koppeltaal" en kenmerk "AD-1234".* (Koppeltaal-voorbereiding, onderzoek-standaarden §4)
**Evaluatiemomenten**
18. [G] *Behandelplan-versie 1 kent een gepland evaluatiemoment van type "tussenevaluatie" op 12 september 2026 (week 6).*
19. [N] *Het evaluatiemoment van 12 september 2026 is op 14 september 2026 uitgevoerd met uitkomst "bijstellen".* (LKS: op-/afschalen vast onderdeel van elke evaluatie; bijstelling leidt tot nieuwe planversie)
20. [N] *Het evaluatiemoment van type "jaarevaluatie" is uiterlijk 12 maanden na vaststelling gepland.* (LKS: evaluatie minimaal éénmaal per jaar — bewaking via nudge)
**Cliëntakkoord**
21. [G] *Cliënt Jan de Vries heeft op 5 augustus 2026 ingestemd met behandelplan-versie 1; het plan is met hem besproken.*
22. [N] *Voor behandelplan-versie 1 is vastgelegd dat het plan is besproken maar dat de cliënt (nog) geen akkoord heeft gegeven.* (WGBO-realiteit: besproken ≠ akkoord)
23. [N] *Wettelijk vertegenwoordiger P. de Vries heeft op 5 augustus 2026 namens de cliënt ingestemd met behandelplan-versie 1.* (WGBO <12 / 12–16 / wilsonbekwaam)
**Richting andere deelgebieden (context, hier niet gemodelleerd)**
24. [N] *Na vaststelling van het behandelplan is de verwijzer schriftelijk geïnformeerd (met toestemming van de cliënt).* → correspondentie-ronde; hier alleen het TIP-event (§6).
## 2. Entiteiten
Algemeen (spelregels §3.1, geldt voor alle entiteiten hieronder, niet herhaald per tabel): `id` UUID stabiel, `created_at`/`created_by`, provenance (mens/AI + model + bronnen + content-hash) op klinische records, `deleted_at` soft delete, audit append-only.
### 2.1 BEHANDELPLAN
**Doel:** één versie van het behandelplan van een zorgepisode. Een nieuwe versie is een nieuw record; de keten van versies vormt samen "het plan".
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| zorgepisode_id | UUID → ZORGEPISODE | ja | besluit §5.1 #9 / §5.5 |
| versienummer | integer ≥ 1 | ja | oplopend per episode |
| vervangt_plan_id | UUID → BEHANDELPLAN | nee | gevuld vanaf versie 2 |
| status | code → `behandelplan_status` | ja | zie §5 |
| opgesteld_door | UUID → MEDEWERKER | ja | rollenronde: entiteit MEDEWERKER volgt |
| opgesteld_op | datum | ja | |
| gebaseerd_op_intake_id | UUID → INTAKE | nee | herkomst, geen eigenaar (patroon §5.4 #2) |
| regiebehandelaar_id | UUID → MEDEWERKER | bij vaststelling | LKS §3.6.2 #5: regiebehandelaar behandelfase |
| aanpak_toelichting | tekst | nee | LKS #2 "wijze waarop" op hoofdlijnen; detail zit in interventies |
| crisisafspraken | tekst | bij vaststelling | LKS §3.6.2 #4 |
| waarnemingsafspraken | tekst | bij vaststelling | LKS §3.6.2 #4 |
| vastgesteld_op | datum | bij status ≥ vastgesteld | |
| vastgesteld_door | UUID → MEDEWERKER | bij status ≥ vastgesteld | LKS: regiebehandelaar (indicerende rol) stelt vast |
| einde_op / einde_status | datum + afleidbaar | bij vervangen/afgesloten/vervallen | |
**Uniciteit:**
- (`zorgepisode_id`, `versienummer`) uniek.
- **Max één plan met status `vastgesteld` per zorgepisode** (partial unique index) — spelregel §3.1 #7: regel in het model.
- `vervangt_plan_id` uniek waar gevuld (een versie wordt door hoogstens één opvolger vervangen).
"Verplicht bij vaststelling" = afgedwongen in de statusovergang `concept → vastgesteld` (check-constraint/trigger), niet bij aanmaken van het concept.
### 2.2 BEHANDELPLAN_DIAGNOSE (koppel)
**Doel:** welke diagnoses het plan adresseert (feitzin 3). M:n omdat een plan meerdere diagnoses kan adresseren en een diagnose door opeenvolgende planversies geadresseerd blijft.
| Attribuut | Type | Verplicht |
|---|---|---|
| behandelplan_id | UUID → BEHANDELPLAN | ja |
| diagnose_id | UUID → DIAGNOSE | ja |
**Uniciteit:** (`behandelplan_id`, `diagnose_id`) uniek. **Regel:** ≥ 1 rij verplicht bij vaststelling (zib Behandeldoel: relatie doel/plan → diagnose is een echte verwijzing, geen tekst).
### 2.3 BEHANDELDOEL
**Doel:** één doel binnen één planversie, met cliëntversie en evalueerbare termijn.
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| behandelplan_id | UUID → BEHANDELPLAN | ja | doel leeft binnen één versie |
| volgnummer | integer | ja | volgorde/weergave (prototype: 1–6, geen harde limiet in schema) |
| omschrijving | tekst | ja | professionele formulering (SMART) |
| clientversie | tekst | nee | B1-taal; nudge als hij ontbreekt, geen harde eis |
| prioriteit | code → `doel_prioriteit` | ja | |
| streefdatum | datum | nee | LKS: doelen voor een te evalueren periode; nudge als leeg |
| diagnose_id | UUID → DIAGNOSE | nee | doel-specifieke reden (zib Behandeldoel: RedenBehandeling) |
| status | code → `doel_status` | ja | default `actief` |
| status_gewijzigd_op | datum | nee | |
| overgenomen_van_doel_id | UUID → BEHANDELDOEL | nee | keten over versies heen (feitzin 13) — maakt trendmeting (TIP-longitudinale IE's, §3.3 #3) en "rapporteren op doel" over versies mogelijk |
**Uniciteit:** (`behandelplan_id`, `volgnummer`) uniek. **Regel:** ≥ 1 doel verplicht bij vaststelling (LKS §3.6.2 #1). `overgenomen_van_doel_id` moet naar een doel in de direct voorafgaande versie van dezelfde episode wijzen.
### 2.4 INTERVENTIE
**Doel:** één interventie binnen één planversie: wat wordt ingezet, door wie (LKS #3), en — bij eHealth — met welke externe referentie.
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| behandelplan_id | UUID → BEHANDELPLAN | ja | |
| interventietype | code → `interventietype` | ja | |
| omschrijving | tekst | nee | vrije specificatie ("anders"-patroon uit zibs) |
| uitvoerder_id | UUID → MEDEWERKER | bij vaststelling | LKS #3: wie voert uit; discipline/beroep via rollenronde |
| frequentie_toelichting | tekst | nee | "wekelijks", "2×/week" — echte planning is agenda-ronde |
| extern_systeem | tekst/code | nee | bijv. "koppeltaal" |
| extern_kenmerk | tekst | nee | ID van de eHealth-activiteit; samen met extern_systeem gevuld of samen leeg |
**Uniciteit:** geen natuurlijke sleutel buiten id; zelfde type mag vaker voorkomen (bijv. twee eHealth-modules).
### 2.5 INTERVENTIE_DOEL (koppel)
**Doel:** welke doelen een interventie dient (prototype: interventies gekoppeld aan doelen; m:n).
| Attribuut | Type | Verplicht |
|---|---|---|
| interventie_id | UUID → INTERVENTIE | ja |
| behandeldoel_id | UUID → BEHANDELDOEL | ja |
**Uniciteit:** (`interventie_id`, `behandeldoel_id`) uniek. **Regel:** ≥ 1 doelkoppeling per interventie bij vaststelling; interventie en doel moeten tot hetzelfde behandelplan behoren (constraint).
### 2.6 EVALUATIEMOMENT
**Doel:** gepland én uitgevoerd evaluatiemoment van een planversie (LKS #6: na hoeveel tijd wordt geëvalueerd; evaluatie minimaal jaarlijks).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| behandelplan_id | UUID → BEHANDELPLAN | ja | |
| evaluatietype | code → `evaluatietype` | ja | |
| gepland_op | datum | ja | feitzin "week 6" wordt bij vaststelling een concrete datum |
| status | code → `evaluatiemoment_status` | ja | default `gepland` |
| uitgevoerd_op | datum | bij status uitgevoerd | |
| uitgevoerd_door | UUID → MEDEWERKER | bij status uitgevoerd | LKS: regiebehandelaar zorgt voor evaluatiemomenten; MDT-toets → rollenronde |
| uitkomst | code → `evaluatie_uitkomst` | bij status uitgevoerd | op-/afschalen is vast onderdeel van elke evaluatie (LKS) |
| toelichting | tekst | nee | het inhoudelijke evaluatieverslag is een RAPPORTAGE (rapportage-ronde) die naar dit moment verwijst |
**Uniciteit:** geen buiten id. **Regel:** ≥ 1 evaluatiemoment met status `gepland` verplicht bij vaststelling van het plan.
### 2.7 BEHANDELPLAN_AKKOORD
**Doel:** het WGBO/informed-consent-feit, los van de planstatus. Legt vast óf en hoe het plan met de cliënt is besproken en wie instemde — ook het níet-akkoord is een registreerbaar feit (Nedap discussionType; LKS: vaststellen "nadat waar mogelijk toestemming is verkregen").
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| behandelplan_id | UUID → BEHANDELPLAN | ja | akkoord hoort bij één specifieke versie |
| datum | datum | ja | |
| wijze | code → `akkoord_wijze` | ja | besproken-en-akkoord / akkoord-volgt / niet-besproken / geen-akkoord |
| gegeven_door_type | code → `akkoord_partij` | ja | cliënt zelf / wettelijk vertegenwoordiger / gezaghebbende ouder |
| gegeven_door_persoon_id | UUID → PERSOON | nee | bij vertegenwoordiger: welke persoon (PERSOON-rollenmodel §5.1 #1) |
| vastgelegd_door | UUID → MEDEWERKER | ja | |
| toelichting | tekst | nee | bijv. reden geen akkoord |
**Uniciteit:** geen — meerdere akkoord-feiten per planversie zijn legitiem (kind én ouders bij 12–16 jaar; eerst "akkoord volgt", later het akkoord zelf). Het meest recente feit per partij telt functioneel.
## 3. Relaties met cardinaliteit
| Relatie | Cardinaliteit | Toelichting |
|---|---|---|
| ZORGEPISODE — BEHANDELPLAN | 1 — 0..n | alle versies hangen aan de episode (besluit §5.1 #9 / §5.5) |
| BEHANDELPLAN — BEHANDELPLAN (vervangt) | 0..1 — 0..1 | versieketen; opvolger uniek |
| BEHANDELPLAN — DIAGNOSE (via BEHANDELPLAN_DIAGNOSE) | m — n | ≥ 1 bij vaststelling; DIAGNOSE uit deelgebied §5.4 |
| BEHANDELPLAN — INTAKE (gebaseerd op) | 0..n — 0..1 | herkomstverwijzing, optioneel; INTAKE uit deelgebied §5.2 |
| BEHANDELPLAN — BEHANDELDOEL | 1 — 0..n (≥ 1 bij vaststelling) | doel leeft binnen één versie |
| BEHANDELDOEL — DIAGNOSE | 0..n — 0..1 | doel-specifieke reden, optioneel |
| BEHANDELDOEL — BEHANDELDOEL (overgenomen van) | 0..1 — 0..n theoretisch, praktisch 0..1 — 0..1 | keten over versies; splitsing van een doel in twee opvolgers is toegestaan |
| BEHANDELPLAN — INTERVENTIE | 1 — 0..n | |
| INTERVENTIE — BEHANDELDOEL (via INTERVENTIE_DOEL) | m — n (≥ 1 doel per interventie bij vaststelling) | binnen hetzelfde plan |
| BEHANDELPLAN — EVALUATIEMOMENT | 1 — 0..n (≥ 1 gepland bij vaststelling) | |
| BEHANDELPLAN — BEHANDELPLAN_AKKOORD | 1 — 0..n | los consent-feit per versie |
| MEDEWERKER — BEHANDELPLAN | 1 — 0..n | als opsteller, vaststeller, regiebehandelaar (drie aparte verwijzingen; MEDEWERKER/rollen → rollenronde) |
| PERSOON — BEHANDELPLAN_AKKOORD | 0..1 — 0..n | vertegenwoordiger als persoon-met-rol (besluit §5.1 #1) |
| RAPPORTAGE — EVALUATIEMOMENT / BEHANDELDOEL / BEHANDELPLAN | latere ronde | evaluatieverslag en "rapporteren op doel" verwijzen hierheen (onderzoek-rapportage §4, §9.1) |
## 4. Waardelijsten
Conform spelregel §3.1 #1 als referentietabellen; elke rij optioneel met externe code + codesysteem-URI + geldig-van/geldig-tot (patroon uit onderzoek-standaarden §8).
| Waardelijst | Startwaarden | Extra attributen |
|---|---|---|
| `behandelplan_status` | concept, vastgesteld, vervangen, afgesloten, vervallen | is_eindstatus (ja/nee) |
| `doel_prioriteit` | hoog, middel, laag | — |
| `doel_status` | actief, behaald, gestaakt, vervallen | is_eindstatus |
| `interventietype` | CGT, EMDR, schematherapie, systeemtherapie, farmacotherapie, vaktherapie, groepstherapie, eHealth-module, sociaal-psychiatrische begeleiding, overig | is_ehealth (ja/nee) — stuurt of extern_systeem/kenmerk relevant is; startlijst te bevestigen |
| `evaluatietype` | tussenevaluatie, jaarevaluatie, eindevaluatie | — |
| `evaluatiemoment_status` | gepland, uitgevoerd, vervallen | — |
| `evaluatie_uitkomst` | voortzetten, bijstellen, opschalen, afschalen, afronden | leidt_tot_nieuwe_versie (ja/nee — bijstellen/opschalen/afschalen → ja, als hint voor TIP, geen harde regel) |
| `akkoord_wijze` | besproken_en_akkoord, besproken_akkoord_volgt, niet_besproken, besproken_geen_akkoord | telt_als_consent (alleen besproken_en_akkoord → ja) |
| `akkoord_partij` | client, wettelijk_vertegenwoordiger, gezaghebbende_ouder | — |
## 5. Statusmachine BEHANDELPLAN
Expliciet per spelregel §3.1 #9, in een referentietabel `behandelplan_statusovergang` (van, naar, voorwaarde, rol).
| Van | Naar | Voorwaarden (afgedwongen in de overgang) | Wie mag zetten |
|---|---|---|---|
| — | concept | — | behandelaar (rollenronde) |
| concept | vastgesteld | regiebehandelaar_id, crisisafspraken, waarnemingsafspraken gevuld; ≥ 1 diagnose-koppeling; ≥ 1 doel; elke interventie ≥ 1 doel; ≥ 1 gepland evaluatiemoment; geen ander vastgesteld plan op de episode (of: die overgang zet de vorige tegelijk op `vervangen`) | regiebehandelaar, indicerende rol (LKS) — definitieve rolbinding in rollenronde |
| concept | vervallen | — | opsteller/regiebehandelaar → rollenronde |
| vastgesteld | vervangen | uitsluitend als effect van het vaststellen van de opvolgende versie (zelfde transactie); nooit handmatig | systeem, getriggerd door vaststelling opvolger |
| vastgesteld | afgesloten | einde behandeling/episode | regiebehandelaar → rollenronde |
| vervangen / afgesloten / vervallen | — | eindstatussen; heropening = nieuwe versie (concept) die op de laatste versie voortbouwt | — |
**Bewust géén statussen:** `in_evaluatie` (proces-toestand: het feit is een EVALUATIEMOMENT, de bewaking is TIP), `on-hold` (pauzering is een episode-/behandelingsfeit, geen planstatus), `gearchiveerd` (dat is `vervangen`/`afgesloten` + soft delete-regime). Cliëntakkoord is géén status (kernkeuze 2).
**Mutatieregels per status:** `concept` vrij muteerbaar (met audit). `vastgesteld` en eindstatussen: inhoud onveranderlijk — wijziging = nieuwe versie (zie open besluitpunt 3). Doel-status en evaluatiemoment-status mogen wél muteren op een vastgesteld plan (dat zijn feiten óver de uitvoering, niet het plan zelf), altijd met audit-event.
**Rollen:** alle "wie mag"-cellen zijn kandidaat-invullingen op basis van LKS 4.0; definitieve toewijzing in de rollenronde (consistent met discovery §5.1 besluit 6).
## 6. ECD/TIP-eigenaarschap en events richting TIP
**Eigenaarschap:** alle entiteiten in dit voorstel zijn **leidend in het ECD** (klinische feiten, bron van waarheid). TIP bezit: termijnbewaking, taken/reminders, nudge-evaluatie en de doelgebonden audit-snapshots (§3.3-afstemming Joshua). TIP houdt als longitudinale IE's hoogstens bij: doel-statusverloop en evaluatie-uitkomsten per episode (trend), via de `overgenomen_van`-keten — minimale, herleidbare kopie.
**Events ECD → TIP** (elk met record-UUID + content-hash, zelfde mechanisme als her-embedding, §3.2/§3.3 #4):
| Event | Payload-kern | Waarvoor TIP het gebruikt |
|---|---|---|
| `behandelplan.concept_aangemaakt` | plan-id, episode-id, versienr | taak "akkoord ophalen", "plan vaststellen" |
| `behandelplan.vastgesteld` | plan-id, versienr, vastgesteld_op, regiebehandelaar | nudge terugkoppelbrief verwijzer (LKS, met cliënt-toestemming — correspondentie-ronde); ZPM `behandelplan_check` vervalt; jaarevaluatie-termijn start |
| `behandelplan.vervangen` / `afgesloten` / `vervallen` | plan-id, opvolger-id | kopie-veroudering voorkomen; taken sluiten |
| `behandelplan.gemuteerd` (alleen concept) | plan-id, content-hash | snapshot-verversing, her-embedding |
| `akkoord.geregistreerd` | plan-id, wijze, partij | nudge bij `besproken_geen_akkoord` (LKS: geen overeenstemming → doorverwijzen bespreken) en bij vaststellen zonder consent-feit |
| `evaluatiemoment.gepland` / `uitgevoerd` / `vervallen` | moment-id, gepland_op, uitkomst | termijnbewaking (Treek-achtig: "evaluatie over 2 weken", "jaarevaluatie > 12 mnd → waarschuwing"); uitkomst `bijstellen` → taak "nieuwe planversie opstellen" |
| `doel.status_gewijzigd` | doel-id, keten-id, status | trend/voortgang (longitudinale IE) |
**Nudge-regels (TIP/Nudge Engine, geen schema-eisen):** behandeling gestart zonder vastgesteld plan (ZPM-trigger `behandelplan_check` — zie open besluitpunt 2); vastgesteld plan zonder consent-feit (`telt_als_consent`); jaarevaluatie-termijn (LKS: minimaal 1×/jaar); doel zonder cliëntversie of streefdatum; terugkoppeling verwijzer niet geregistreerd na vaststelling.
## 7. Open besluitpunten voor Colin
1. **Vaststellen zonder cliëntakkoord: toestaan met waarschuwing?** LKS zegt "nadat waar mogelijk toestemming is verkregen" — "waar mogelijk" impliceert dat vaststellen zonder akkoord soms legitiem is (crisis, wilsonbekwaam zonder bereikbare vertegenwoordiger). **Advies:** toestaan; ontbrekend of negatief consent-feit wordt een `waarschuwing`-nudge, geen blokkade. Het niet-akkoord zelf altijd registreerbaar houden (akkoord_wijze `besproken_geen_akkoord`).
2. **Behandelplan verplicht vóór start behandeling: nudge-severity.** Discovery §5.5 hield dit open. **Advies:** nudge, geen schema-eis (crisis en interne intakes maken een harde volgorde onhoudbaar — zelfde argument als screening-vóór-intake, §5.2 besluit 4); severity `waarschuwing` bij Zvw-regulier, `signaal` elders — configureerbaar per kader, zoals de verwijsbrief-regel (§5.1 #7).
3. **Strikte onveranderlijkheid na vaststelling — ook voor typo's?** **Advies:** strikt. Elke inhoudelijke wijziging = nieuwe versie; een pure verschrijving corrigeren mag niet stilzwijgend (WGBO-correctiesystematiek: geen stille edits in een dossier). Wie het te zwaar vindt: alternatief is een audit-gelogde "tekstuele correctie" op vastgestelde plannen — ik raad het af, twee regimes maken het model en de uitleg aan behandelaren complexer.
4. **Crisis- en waarnemingsafspraken hard verplicht bij vaststelling?** LKS noemt ze als verplicht onderdeel ("bevat in ieder geval"). **Advies:** ja, harde voorwaarde in de statusovergang — het zijn twee tekstvelden, de drempel is laag en de dekking is een Kwaliteitsstatuut-eis. Alternatief (nudge) alleen kiezen als de praktijk kort-durende trajecten kent waar dit knelt.
5. **Doel-keten (`overgenomen_van`) als mechanisme voor trend over versies — akkoord?** Nodig zodat "rapporteren op doel" en TIP-trendmeting versiewissels overleven. **Advies:** overnemen; kost één optionele kolom.
6. **Startlijst `interventietype` bevestigen** (CGT, EMDR, schematherapie, systeemtherapie, farmacotherapie, vaktherapie, groepstherapie, eHealth-module, sociaal-psychiatrische begeleiding, overig) en of de lijst per instelling uitbreidbaar is (zoals afdelingen, §5.2 besluit 2). **Advies:** instellingsconfigureerbaar met deze lijst als default.
7. **"Max één vastgesteld plan per episode" als DB-constraint — akkoord?** Nedap doet één ACTIVE per cliënt; hier per episode (consistent met §5.1 #9). **Advies:** ja, partial unique index; parallel lopende deelplannen (bijv. apart veiligheidsplan) komen in de latere veiligheidsplan-beslissing, niet als tweede vastgesteld behandelplan.
8. **Evaluatie-uitkomst `bijstellen`: automatisch een concept-opvolger klaarzetten (TIP-taak) of alleen signaleren?** **Advies:** alleen signaleren via event + taak; het ECD maakt nooit zelf records aan (human-in-the-loop hard constraint).
## 8. Bronverwijzingen
| Onderwerp | Bron |
|---|---|
| Scope, genomen besluiten, spelregels | `datamodel-discovery.md` §3.1, §3.3, §5.1 #9, §5.4 #2, §5.5 |
| Verplichte planonderdelen (doelen/periode, wie voert uit, crisis/waarneming, regiebehandelaar, evaluatietermijn), toestemming vóór vaststelling, terugkoppeling verwijzer, jaarlijkse evaluatie, substantiële aanpassing ⇒ nieuw plan | `onderzoek-proces.md` §5–6 (LKS 4.0 §3.6.2), §10.1 stap 10–12, §10.3 verrijking 8 |
| Statusmachine minimaal + versie=nieuw record + cliëntakkoord als los feit met besprekingsstatus (Nedap CarePlan/CarePlanAgreement) | `../onderzoek/onderzoek-leveranciers.md` §2.6, §7 punt 6 |
| Doel→diagnose als echte relatie, streefdatum, planstatus ≠ consent (FHIR CarePlan/Consent), interventie met externe eHealth-referentie (Koppeltaal), waardelijst-patroon (externe code + geldigheidsperiode, "anders"-optie) | `../onderzoek/onderzoek-standaarden.md` §2.2 (zib Behandeldoel), §3, §4, §8 |
| Evaluatieverslag en rapporteren-op-doel als rapportage-verwijzingen; geen stille edits (WGBO-correctie) | `../onderzoek/onderzoek-rapportage.md` §4, §1.1, §9.1 |
| WGBO informed consent, vertegenwoordiging 12/16/wilsonbekwaam | `onderzoek-proces.md` §8 |
| ZPM `behandelplan_check` als regeltrigger | discovery §5.5 open vraag; triqura-cortex regelset (CLAUDE.md) |

286
docs/datamodel/deelmodellen/model-diagnose.md Normal file
View File

@@ -0,0 +1,286 @@
# Datamodelvoorstel — deelgebied Diagnose
**Status:** voorstel ter review (bouwt voort op `datamodel-discovery.md` §5.4)
**Datum:** 18 juli 2026
**Modelleur:** Claude (deelgebied-agent "diagnose")
**Kader:** genomen besluiten uit de discovery zijn niet teruggedraaid. Uitgangspunten: DSM-5-TR primair met ICD-10-mapping als entiteit (besluit §5.4 #1), diagnose aan de ZORGEPISODE met intake als optionele herkomst (besluit §5.4 #2), spelregels §3.1 (waardelijsten als data, provenance, soft delete, statusmachines expliciet, regels in het model).
---
## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.4)
Gewijzigd betekent: de startlijst-feitzin is herschreven naar DSM-bronregistratie en de twee status-assen. Nieuw betekent: het feit ontbrak in de discovery.
1. **(gewijzigd, was §5.4 #1)** *Voor de zorgepisode van Jan de Vries is op 24 juli 2026 een diagnose geregistreerd met DSM-5-TR-classificatie "depressieve stoornis, eenmalige episode, matig" door psycholoog M. de Boer.*
2. **(gewijzigd, was deel van §5.4 #1)** *De diagnose is gesteld tijdens de intake van 22 juli 2026.* (herkomst, optioneel — een diagnose kan ook tijdens de behandeling worden geregistreerd)
3. **(nieuw)** *Uit de DSM-classificatie van de diagnose is via mappinglijstversie "WHO-FIC 2026-01" de ICD-10-code F32.1 afgeleid.*
4. **(ongewijzigd, §5.4 #3)** *De diagnose heeft ernst "matig".*
5. **(gewijzigd, was §5.4 #4)** *De diagnose heeft verificatiestatus "werkdiagnose".*
6. **(gewijzigd, was §5.4 #4)** *De diagnose is op 30 juli 2026 definitief vastgesteld door regiebehandelaar S. el Amrani.*
7. **(gewijzigd, was §5.4 #5/#6)** *De diagnose heeft klinische status "actief".* / *De diagnose is op 1 december 2026 in remissie verklaard door M. de Boer.*
8. **(gewijzigd, was §5.4 #2)** *De diagnose "depressieve stoornis, eenmalige episode, matig" is sinds 30 juli 2026 de hoofddiagnose van de zorgepisode van Jan de Vries.* (hoofddiagnose-zijn is een feit met een geldigheidsperiode, geen vaste eigenschap van het diagnoserecord)
9. **(nieuw)** *Per 15 oktober 2026 is de diagnose "bipolaire-I-stoornis" de hoofddiagnose van de zorgepisode; de eerdere hoofddiagnose-aanwijzing is per die datum beëindigd.*
10. **(nieuw, comorbiditeit)** *Voor de zorgepisode van Jan de Vries is daarnaast de diagnose "gegeneraliseerde-angststoornis" geregistreerd; deze is geen hoofddiagnose (nevendiagnose).*
11. **(nieuw)** *De diagnose X is op 2 september 2026 vervallen verklaard met reden "foutregistratie" en vervangen door diagnose Y.*
12. **(nieuw, zorgvraagtypering)** *Voor de zorgepisode van Jan de Vries is op 30 juli 2026 een HoNOS+-afname gedaan door M. de Boer; item 2 "opzettelijke zelfverwonding" heeft score 1.*
13. **(nieuw)** *Op basis van de HoNOS+-afname van 30 juli 2026 adviseerde de NZa-zorgvraagtyperingstool (algoritmeversie 3.2) zorgvraagtype 4; behandelaar M. de Boer heeft op 30 juli 2026 zorgvraagtype 4 gekozen.*
14. **(nieuw)** *De zorgvraagtypering van de zorgepisode is voor het laatst vastgesteld op 30 juli 2026.* (basis voor de nudge "hertypering minimaal jaarlijks")
15. **(nieuw, registratiefeit)** *Cliënt Jan de Vries heeft op 5 augustus 2026 een privacyverklaring afgegeven tegen aanlevering van zorgvraagtyperingsgegevens aan de NZa.* (structuur volgt in de toestemmings-ronde; zie open besluit 7)
## 2. Entiteiten
### 2.1 DIAGNOSE
**Doel:** één klinische diagnose van een cliënt binnen een zorgepisode, geregistreerd in DSM-5-TR-termen (bronregistratie), met afgeleide ICD-10-code en twee onafhankelijke status-assen (verificatie + klinisch).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| id | uuid | ja | stabiele identiteit (spelregel §3.1 #5) |
| zorgepisode_id | uuid → ZORGEPISODE | ja | eigenaar van de diagnose (besluit §5.4 #2) |
| dsm_classificatie_id | uuid → DSM_CLASSIFICATIE | ja | de DSM-5-TR-classificatie (bronregistratie) |
| afgeleide_icd10_code | tekst | nee | automatisch afgeleid via DSM_ICD10_MAPPING; leeg als de mapping (nog) geen resultaat geeft → nudge |
| mapping_lijstversie | tekst | nee | versie van de WHO-FIC-codelijst waarmee de afleiding is gedaan (reproduceerbaarheid bij controle/herdeclaratie) |
| ernst | waardelijst `diagnose_ernst` | nee | zie open besluit 5 (deels redundant met DSM-specificatie) |
| verificatiestatus | waardelijst `diagnose_verificatiestatus` | ja | default `werkdiagnose` |
| definitief_op | datum | nee | gezet bij overgang naar `definitief` |
| definitief_door | uuid → MEDEWERKER | nee | idem; rolvereiste volgt in de rollenronde |
| klinische_status | waardelijst `diagnose_klinische_status` | ja | default `actief` |
| klinische_status_sinds | datum | ja | ingangsdatum van de huidige klinische status |
| begindatum_aandoening | datum | nee | klinisch begin (onset), kan vóór de registratie liggen (zib Diagnose) |
| wijze_van_vaststellen | waardelijst `wijze_van_vaststellen` | nee | zib Diagnose-element |
| gesteld_tijdens_intake_id | uuid → INTAKE | nee | herkomst, geen eigenaar (besluit §5.4 #2) |
| geregistreerd_op | timestamp | ja | |
| geregistreerd_door | uuid → MEDEWERKER | ja | |
| toelichting | tekst | nee | vrije tekst (AI-voorbereiding §3.2: structuur + tekst in één record) |
| vervalreden | waardelijst `diagnose_vervalreden` | nee | verplicht zodra verificatiestatus `vervallen` is |
| vervangen_door_diagnose_id | uuid → DIAGNOSE | nee | correctieketen: vervallen record wijst naar zijn opvolger |
| auteur_type, ai_model, ai_bronnen, content_hash | provenance-velden | ja (patroon) | spelregel §3.1 #2; content_hash triggert her-embedding en het TIP-mutatie-event |
| deleted_at | timestamp | nee | soft delete (spelregel §3.1 #4) |
**Uniciteitsregels:**
- `id` uniek.
- Binnen één zorgepisode maximaal één **niet-vervallen, niet-verwijderde** diagnose per DSM-classificatie (partiële unieke index op `(zorgepisode_id, dsm_classificatie_id)` waar `verificatiestatus <> 'vervallen' and deleted_at is null`). Dezelfde classificatie mag wél terugkomen nadat een eerder record is vervallen.
- `vervalreden` is verplicht ⇔ `verificatiestatus = 'vervallen'` (check-constraint).
- Na `definitief`: `dsm_classificatie_id` is onveranderbaar (correctie = vervallen + nieuw record, zie statusmachine). Vergelijk Nedaps `immutable`-vlag.
### 2.2 DSM_CLASSIFICATIE (referentietabel, geïmporteerd)
**Doel:** de DSM-5-TR-classificaties als versioneerde referentiedata (import-patroon uit onderzoek-standaarden §8) — niet door behandelaars muteerbaar, nooit hardcoded.
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| id | uuid | ja | |
| dsm_code | tekst | ja | code volgens de gebruikte DSM-uitgave/codelijst |
| omschrijving | tekst | ja | let op licentie Boom/APA (open besluit 2) |
| dsm_hoofdgroep_id | uuid → DSM_HOOFDGROEP | ja | t.b.v. factuur (g-ggz) en NZa-wachttijduitsplitsing per hoofddiagnosegroep |
| selecteerbaar | boolean | ja | niet elke rij is een registreerbare einddiagnose (Nedap-patroon `selecteerbaar`) |
| lijstversie | tekst | ja | importversie |
| geldig_van / geldig_tot | datum | ja / nee | geldigheidsperiode per waarde (les uit Nedap-codetabellen) |
**Uniciteit:** `(dsm_code, lijstversie)` uniek.
### 2.3 DSM_HOOFDGROEP (referentietabel)
**Doel:** NZa-diagnosehoofdgroepen; afleidbaar gegeven voor factuur en wachttijdrapportage. Attributen: id, code, omschrijving, geldig_van/geldig_tot. Uniciteit: `(code)` uniek binnen geldigheidsperiode.
### 2.4 DSM_ICD10_MAPPING (referentietabel, geïmporteerd — de mappingtabel als entiteit)
**Doel:** de officiële "Codelijst DSM-5(-TR) met ICD-10 afleidingen" (WHO-FIC CC Nederland/RIVM) als versioneerde m:n-mappingtabel. Eén DSM-classificatie kan naar meerdere ICD-10-codes leiden en omgekeerd — daarom een eigen entiteit, geen kolom met uniciteitsaanname (onderzoek-standaarden §5, checklistpunt 3).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| id | uuid | ja | |
| dsm_classificatie_id | uuid → DSM_CLASSIFICATIE | ja | |
| icd10_code | tekst | ja | ICD-10 zoals in NL gebruikt |
| icd10_omschrijving | tekst | nee | |
| voorkeur | boolean | ja | bij meerdere afleidingen: welke is de standaard voor declaratie |
| lijstversie | tekst | ja | bijv. "publicatie 15-12-2023, geldig per 1-1-2024" |
| geldig_van / geldig_tot | datum | ja / nee | de lijst wisselt periodiek; op het diagnoserecord staat vastgelegd met welke versie is afgeleid |
**Uniciteit:** `(dsm_classificatie_id, icd10_code, lijstversie)` uniek; maximaal één `voorkeur = true` per `(dsm_classificatie_id, lijstversie)`.
### 2.5 HOOFDDIAGNOSE_AANWIJZING
**Doel:** het tijdgebonden feit "diagnose X is de hoofddiagnose van episode E van datum A tot datum B". Hiermee is "max één hoofddiagnose" een database-constraint (spelregel §3.1 #7) én blijft de historie behouden — nodig omdat de hoofddiagnose op de factuur en in de NZa-wachttijdrapportage per periode reproduceerbaar moet zijn. Alle overige actuele diagnoses van de episode zijn daarmee per definitie nevendiagnoses (comorbiditeit): geen apart type-veld nodig.
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| id | uuid | ja | |
| zorgepisode_id | uuid → ZORGEPISODE | ja | redundant met diagnose→episode, maar nodig voor de uniciteitsconstraint |
| diagnose_id | uuid → DIAGNOSE | ja | |
| geldig_van | datum | ja | |
| geldig_tot | datum | nee | leeg = actueel |
| aangewezen_door | uuid → MEDEWERKER | ja | |
| aangewezen_op | timestamp | ja | |
**Uniciteitsregels:**
- Geen overlappende geldigheidsperiodes binnen één zorgepisode (PostgreSQL exclusion-constraint op `(zorgepisode_id, daterange(geldig_van, geldig_tot))`) — dit ís het besluit "max één hoofddiagnose per moment in de tijd" (zie open besluit 1).
- `diagnose_id` moet bij dezelfde `zorgepisode_id` horen (constraint/trigger).
- Alleen een niet-vervallen diagnose kan als hoofddiagnose worden aangewezen; vervalt de diagnose, dan wordt de lopende aanwijzing beëindigd (`geldig_tot` gezet).
### 2.6 HONOS_AFNAME
**Doel:** één afname van de HoNOS+-vragenlijst (19 items, score 0–4) voor een zorgepisode. Generiek meetinstrument-patroon; HoNOS+ is de eerste invulling (onderzoek-standaarden §6.4).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| id | uuid | ja | |
| zorgepisode_id | uuid → ZORGEPISODE | ja | |
| instrument | tekst | ja | vast `HoNOS+` met versie, t.b.v. toekomstige instrumentwissel |
| afgenomen_op | datum | ja | |
| afgenomen_door | uuid → MEDEWERKER | ja | |
| toelichting | tekst | nee | |
| deleted_at | timestamp | nee | |
**Uniciteit:** geen beperking op aantal afnames per episode (herhaalde metingen zijn de bedoeling).
### 2.7 HONOS_ITEMSCORE
**Doel:** de score per HoNOS+-item van één afname, als gestructureerde data (geen JSON-blob — spelregel §3.1 #1 en AI-voorbereiding: scores moeten filterbaar/regelbaar zijn).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| id | uuid | ja | |
| honos_afname_id | uuid → HONOS_AFNAME | ja | |
| honos_item_id | uuid → waardelijst `honos_item` | ja | |
| score | geheel getal | ja | 0–4, of 9 = "onbekend/niet van toepassing" (HoNOS-conventie); check-constraint |
**Uniciteit:** `(honos_afname_id, honos_item_id)` uniek.
### 2.8 ZORGVRAAGTYPERING
**Doel:** het aanpalende record naast de diagnose (ZPM-verplichting g-ggz/fz): op basis van een HoNOS+-afname adviseert de NZa-tool een zorgvraagtype, de behandelaar kiest. Advies ≠ keuze: twee vastgelegde feiten met eigen herkomst — schoolvoorbeeld van het provenance-patroon (algoritme-advies vs. menselijke keuze, spelregel §3.1 #2).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| id | uuid | ja | |
| zorgepisode_id | uuid → ZORGEPISODE | ja | |
| honos_afname_id | uuid → HONOS_AFNAME | ja | de afname waarop advies en keuze rusten |
| soort | waardelijst `zorgvraagtypering_soort` | ja | `initieel` / `hertypering` |
| algoritmeversie | tekst | ja | versie van de NZa-zorgvraagtyperingstool (reproduceerbaarheid) |
| gekozen_zorgvraagtype_id | uuid → waardelijst `zorgvraagtype` | ja | de keuze van de behandelaar (komt op de factuur) |
| gekozen_door | uuid → MEDEWERKER | ja | |
| gekozen_op | datum | ja | basis voor de jaarlijkse-hertypering-nudge |
| afwijking_toelichting | tekst | nee | aanbevolen in te vullen als de keuze afwijkt van het advies |
| deleted_at | timestamp | nee | |
**Uniciteit:** maximaal één typering per HoNOS-afname (`honos_afname_id` uniek); meerdere typeringen per episode door de tijd (hertypering).
### 2.9 ZORGVRAAGTYPE_ADVIES
**Doel:** de door het algoritme geadviseerde zorgvraagtypes (de tool kan meerdere kandidaten met rangorde geven) — apart van de keuze vastgelegd.
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| id | uuid | ja | |
| zorgvraagtypering_id | uuid → ZORGVRAAGTYPERING | ja | |
| zorgvraagtype_id | uuid → waardelijst `zorgvraagtype` | ja | |
| rangorde | geheel getal | ja | 1 = eerste advies |
**Uniciteit:** `(zorgvraagtypering_id, zorgvraagtype_id)` uniek en `(zorgvraagtypering_id, rangorde)` uniek.
## 3. Relaties met cardinaliteit
| Relatie | Cardinaliteit | Toelichting |
|---|---|---|
| ZORGEPISODE — DIAGNOSE | 1 — 0..n | besluit §5.4 #2; een episode zonder diagnose kan (vroege fase) |
| INTAKE — DIAGNOSE | 0..1 — 0..n | herkomst, optioneel (besluit §5.4 #2); intake uit deelgebied §5.2 |
| DSM_CLASSIFICATIE — DIAGNOSE | 1 — 0..n | bronregistratie |
| DSM_CLASSIFICATIE — DSM_HOOFDGROEP | n — 1 | afleiding factuur/wachttijden |
| DSM_CLASSIFICATIE — ICD-10-code (via DSM_ICD10_MAPPING) | m — n, per lijstversie | mappingtabel als entiteit (besluit §5.4 #1) |
| ZORGEPISODE — HOOFDDIAGNOSE_AANWIJZING | 1 — 0..n | max 1 met overlappende geldigheid (constraint) |
| DIAGNOSE — HOOFDDIAGNOSE_AANWIJZING | 1 — 0..n | dezelfde diagnose kan meerdere periodes hoofddiagnose zijn |
| DIAGNOSE — DIAGNOSE (`vervangen_door`) | 0..1 — 0..1 | correctieketen na vervallen |
| ZORGEPISODE — HONOS_AFNAME | 1 — 0..n | |
| HONOS_AFNAME — HONOS_ITEMSCORE | 1 — 19 (bij volledige afname) | itemlijst uit waardelijst |
| HONOS_AFNAME — ZORGVRAAGTYPERING | 1 — 0..1 | niet elke afname leidt tot (her)typering |
| ZORGEPISODE — ZORGVRAAGTYPERING | 1 — 0..n | initieel + hertyperingen |
| ZORGVRAAGTYPERING — ZORGVRAAGTYPE_ADVIES | 1 — 0..n | algoritme-advies |
| MEDEWERKER — DIAGNOSE / HONOS_AFNAME / ZORGVRAAGTYPERING / HOOFDDIAGNOSE_AANWIJZING | 1 — 0..n | registrerende/kiezende medewerker; rolvereisten volgen in de rollenronde |
| BEHANDELPLAN — DIAGNOSE | m — n | "het plan adresseert diagnose X" (§5.5 feitzin 3); relatie wordt in deelgebied behandelplan uitgewerkt, hier alleen benoemd |
## 4. Waardelijsten
Conform spelregel §3.1 #1 als referentietabellen, met per rij optioneel `externe_code`, `codesysteem_uri` en `geldig_van`/`geldig_tot` (patroon uit onderzoek-standaarden §8).
| Waardelijst | Startwaarden | Extra attributen |
|---|---|---|
| `diagnose_verificatiestatus` | `werkdiagnose`, `definitief`, `vervallen` | — |
| `diagnose_klinische_status` | `actief`, `in_remissie`, `hersteld` | — (prototype-waarde `inactive` vervalt, zie open besluit 4) |
| `diagnose_ernst` | `licht`, `matig`, `ernstig` | — |
| `diagnose_vervalreden` | `foutregistratie`, `diagnose_herzien`, `ontkracht_na_onderzoek`, `overig` | `vervanger_verplicht` (ja/nee): bij `diagnose_herzien` is een vervangend record verplicht — zelfde patroon als `agb_verplicht` |
| `wijze_van_vaststellen` | `klinisch_onderzoek`, `gestructureerd_interview`, `psychodiagnostisch_onderzoek`, `heteroanamnese`, `overgenomen_van_verwijzer`, `overig` | — (zib Diagnose; "overig" met specificatieveld, zib-patroon "anders") |
| `honos_item` | de 19 HoNOS+-items: 1–12 (klassieke HoNOS), 13, A–E, Q | `volgnummer`, `omschrijving`; instrumentversie via geldigheidsperiode |
| `zorgvraagtype` | NZa-zorgvraagtypes ggz (import uit NZa-codetabel, versioneerd) | `externe_code` (NZa), `geldig_van`/`geldig_tot` |
| `zorgvraagtypering_soort` | `initieel`, `hertypering` | — |
`DSM_CLASSIFICATIE`, `DSM_HOOFDGROEP` en `DSM_ICD10_MAPPING` zijn geen waardelijsten maar **geïmporteerde, versioneerde referentiedata** (zelfde importmechanisme als NZa-prestatietabellen; onderzoek-standaarden §8, rij "Referentiedata-import").
## 5. Statusmachine
Twee onafhankelijke assen op DIAGNOSE (bevestigt de voorlopige modellering uit discovery §5.4 "nog open" — Nedap `certainty` + status en FHIR `verificationStatus` + `clinicalStatus` tonen dat dit staande praktijk is). Hoofddiagnose-zijn is bewust **geen** status maar een tijdgebonden aanwijzing (entiteit 2.5).
### 5.1 Verificatiestatus
| Van | Naar | Voorwaarde | Wie mag zetten |
|---|---|---|---|
| — | `werkdiagnose` | registratie | behandelaar (rollenronde) |
| `werkdiagnose` | `definitief` | — | regiebehandelaar, indicerende rol (LKS 4.0: verantwoordelijk voor het (doen) vaststellen van de diagnose) — precieze rolafdwinging in de **rollenronde**; tot die tijd wordt `definitief_door` wel vastgelegd |
| `werkdiagnose` | `vervallen` | vervalreden verplicht | behandelaar (rollenronde) |
| `definitief` | `vervallen` | vervalreden verplicht; bij reden `diagnose_herzien` ook `vervangen_door_diagnose_id` | regiebehandelaar (rollenronde) |
Geen overgang `definitief` → `werkdiagnose`: een definitieve diagnose wordt niet "teruggezet" maar vervalt en krijgt een opvolger (correctieketen). Na `definitief` is de DSM-classificatie onveranderbaar; de klinische status en toelichting blijven muteerbaar (met audit).
### 5.2 Klinische status
| Van | Naar | Wie mag zetten |
|---|---|---|
| `actief` | `in_remissie` | behandelaar (rollenronde) |
| `in_remissie` | `actief` | behandelaar (terugval) |
| `actief` / `in_remissie` | `hersteld` | behandelaar |
| `hersteld` | `actief` | behandelaar (heropleving binnen dezelfde episode); bij een nieuwe episode hoort een nieuw diagnoserecord |
De klinische status is alleen betekenisvol op niet-vervallen diagnoses; bij `vervallen` wordt de klinische as bevroren.
### 5.3 Toegestane overgangen als data
Conform spelregel §3.1 #9 worden de overgangen vastgelegd in een referentietabel `status_overgang` (entiteit, as, van, naar, rol-eis) — dezelfde structuur die de aanmelding-statussen (§5.1 besluit 5) gaan gebruiken. De rol-kolom blijft leeg tot de rollenronde.
## 6. ECD/TIP-eigenaarschap en events richting TIP
**Eigenaarschap:** alle entiteiten in dit deelgebied zijn **leidend in het ECD** (klinische feiten, bron van waarheid — §3.3). TIP houdt geen eigen diagnose-administratie; TIP maakt doelgebonden snapshots van de data waarop een intentie/nudge rust (afstemming Joshua §3.3 #2) en mag als longitudinaal informatie-element o.a. hoofddiagnose en zorgvraagtype door de tijd bijhouden (§3.3 #3).
**Events van ECD naar TIP** (zelfde mutatie-eventmechanisme als her-embedding, §3.2/§3.3 #4; payload met record-UUID + content-hash, nooit BSN):
| Event | Trigger | Waarvoor TIP het nodig heeft |
|---|---|---|
| `diagnose_geregistreerd` | nieuw DIAGNOSE-record | bestaat al als regeltrigger in de ZPM-regelengine (`diagnose_geregistreerd`); start nudges "zorgvraagtypering ontbreekt", "behandelplan ontbreekt" |
| `diagnose_definitief_vastgesteld` | verificatiestatus → `definitief` | HoNOS+ moet ná de DSM-diagnose worden ingevuld; factuur-/opt-in-checks |
| `diagnose_vervallen` | verificatiestatus → `vervallen` | koppelafspraak §3.3 #4: TIP-kopieën en lopende nudges op basis van dit record verouderen |
| `hoofddiagnose_gewijzigd` | nieuwe of beëindigde HOOFDDIAGNOSE_AANWIJZING | wachttijd-uitsplitsing per hoofddiagnosegroep; declaratiecontext |
| `diagnose_klinische_status_gewijzigd` | klinische status-overgang | trendbewaking, evaluatie-nudges |
| `honos_afname_geregistreerd` | nieuw HONOS_AFNAME-record | longitudinale IE's (trend itemscores) |
| `zorgvraagtypering_vastgesteld` | nieuw ZORGVRAAGTYPERING-record | reset van de jaarlijkse hertyperings-termijn |
| `diagnose_gewijzigd` (generiek mutatie-event) | content-hash wijzigt | her-embedding + verversen TIP-snapshots |
**Kandidaat-nudges (TIP/Nudge Engine, geen schema-eisen):** hertypering ouder dan 12 maanden (`waarschuwing`; NZa: minimaal jaarlijks); definitieve diagnose zonder zorgvraagtypering in g-ggz (`waarschuwing`); werkdiagnose ouder dan X weken zonder definitieve vaststelling (`signaal`); diagnose zonder afgeleide ICD-10-code doordat de mappingversie geen resultaat geeft (`signaal`); DSM-hoofdgroep op factuur zonder opt-in-toestemming (`blokkade` — declaratieronde).
## 7. Open besluitpunten voor Colin
1. **Hoofddiagnose: per episode of per moment in de tijd?** — *Advies: per moment in de tijd*, gemodelleerd als HOOFDDIAGNOSE_AANWIJZING met geldigheidsperiode en een exclusion-constraint (geen overlap per episode). Zo is spelregel §3.1 #7 een echte database-constraint, kan de hoofddiagnose tijdens de behandeling verschuiven (klinische realiteit; prototype ondersteunde dit niet) én blijft reproduceerbaar welke hoofddiagnose gold op elk declaratie-/rapportagemoment (NZa-wachttijden per hoofddiagnosegroep, DSM-hoofdgroep op factuur). "Max één per episode ooit" zou herziening onmogelijk maken zonder geschiedenis te wissen.
2. **DSM-licentie en actuele mappingversie.** Gebruik van DSM-5-TR-omschrijvingen in een commercieel ECD vereist vermoedelijk een licentie bij Boom/APA; de WHO-FIC-codelijst is alleen vrijgegeven voor NZa-doeleinden, en de versie van 15-12-2023 is per 1-1-2026 vervallen. — *Advies: vóór de bouw van de diagnosemodule uitzoeken (licentie + geldige opvolgerversie); het model is er niet van afhankelijk — referentietabellen blijven identiek, alleen de importbron/licentievorm verschilt.*
3. **Correctiepatroon na definitieve vaststelling.** — *Advies: vervallen + nieuw record met `vervangen_door`-keten* (geen mutatie van de DSM-code op een definitief record). Past bij de append-only-geest (§3.1 #3), het Nedap-`immutable`-patroon en de WGBO-correctiesystematiek; de keten houdt herleidbaar wat wanneer gold.
4. **Startlijst klinische status bevestigen: `actief` / `in_remissie` / `hersteld`.** — *Advies: prototype-waarde `inactive` laten vervallen* — hij overlapt semantisch met zowel remissie als hersteld en niemand kan uitleggen wanneer welke geldt (het labels-vs-codes-probleem in het klein). Terugval binnen de episode = `hersteld` → `actief`; een nieuwe zorgvraag na afsluiting = nieuwe episode met nieuw diagnoserecord.
5. **Ernst-veld behouden naast de DSM-classificatie?** DSM-5-TR codeert ernst bij sommige stoornissen ín de classificatie (de matige depressieve episode uit de feitzin), bij andere niet. — *Advies: behouden als optioneel veld*; waar de classificatie de ernst al draagt is het veld afleidbaar/redundant — eventueel later een consistentie-nudge ("ernst wijkt af van classificatie").
6. **Zorgvraagtypering ook voor gb-ggz?** De HoNOS+-verplichting geldt g-ggz/fz; de basis-ggz kent een eigen profiel op de factuur. — *Advies: de entiteiten generiek houden (afname + typering) en het gb-ggz-profiel pas in de declaratieronde toevoegen*; niets in dit model blokkeert dat.
7. **Privacyverklaring/opt-in als generieke TOESTEMMING-entiteit.** Toestemmingsfeiten duiken op drie plekken op (DSM-hoofdgroep op factuur, huisarts-correspondentie verwijstype 04, privacyverklaring zorgvraagtypering). — *Advies: één generieke TOESTEMMING-entiteit in een latere ronde (zoals onderzoek-standaarden §9.5 voorstelt); tot die tijd dit deelgebied niet belasten met een eigen toestemmingsveld — wel feitzin 15 als geregistreerd feit erkennen.*
8. **Wie mag een diagnose definitief vaststellen** blijft, conform discovery §5.4, expliciet voor de **rollenronde** (LKS: regiebehandelaar, indicerende rol; in settings 3–8 moet bovendien de bij diagnostiek betrokken discipline in het dossier worden vastgelegd — dat laatste veld toevoegen in de rollenronde). Geen besluit nodig nu; genoemd zodat het niet wegvalt.
## 8. Bronverwijzingen
- **Discovery:** `datamodel-discovery.md` §3.1 (spelregels #1, #2, #4, #5, #7, #9), §3.2 (structuur + tekst, content-hash), §3.3 (TIP-grensvlak, afstemming Joshua), §5.1 #9 (ZORGEPISODE), §5.4 (besluiten DSM-primair + episode-eigenaarschap; open vragen verificatiestatus, hoofddiagnose, rollen).
- **Onderzoek proces** (`scratchpad/onderzoek-proces.md`): §5 (regiebehandelaar indicerende rol, LKS 4.0), §6.2 (DSM-5-classificatie verplicht voor alle ggz; betrokken discipline als dossiereis), §7 (zorgvraagtypering HoNOS+ na DSM-diagnose, hertypering minimaal jaarlijks, privacyverklaring als registratiefeit), §10.1 rij 8–9.
- **Onderzoek leveranciers** (`../onderzoek/onderzoek-leveranciers.md`): §2.3 (DiagnoseToekenning met `primair`-boolean en NZa-codetabel met ICD-10-mapping als data), §2.4 (Nedap `certainty` + status = twee assen; `immutable` na vaststelling; waarschuwing GAF/DSM-IV-erfgoed), §7.5.
- **Onderzoek standaarden** (`../onderzoek/onderzoek-standaarden.md`): §2.2 (zib Diagnose v2.0: code-systeem-display-drieluik, steller, datum, wijze van vaststellen; DSM-5 erkend codesysteem), §3 (FHIR Condition `clinicalStatus`/`verificationStatus`), §5 (WHO-FIC-codelijst, m:n-mapping, lijstversie op het record, DSM-hoofdgroep, opt-in, licentierisico), §6.4 (HoNOS+ 19 items 0–4, zorgvraagtyperingstool met algoritmeversie, advies ≠ keuze), §8 (checklist DIAGNOSE-rij, referentiedata-importpatroon), §9 (open punten 1, 2, 5, 6).
- **Onderzoek rapportage** (`../onderzoek/onderzoek-rapportage.md`): §1.1 (WGBO-correctiesystematiek: feitelijke onjuistheden vs. klinische conclusies — onderbouwing correctieketen i.p.v. stille mutatie).
- **Standaarden/regelgeving:** LKS GGZ 4.0 (zorginzicht.nl); Codelijst DSM-5(-TR) met ICD-10-afleidingen (whofic.nl); NZa V&A zorgvraagtypering en Handleiding zorgvraagtypering (zorgprestatiemodel.nl); zib Diagnose v2.0 (zibs.nl); FHIR nl-core Condition (Nictiz R4 zib2020).

224
docs/datamodel/deelmodellen/model-intake.md Normal file
View File

@@ -0,0 +1,224 @@
# Datamodelvoorstel — Deelgebied Intake
**Status:** herziening nodig — deels achterhaald door `../besluiten/besluitenlog-datamodel-2026-07-18.md`
**Datum:** 18 juli 2026
**Modelleur:** Claude (deelgebied "Intake", discovery §5.2)
**Scope:** INTAKE, CONTACTMOMENT, KINDCHECK, intake-uitkomst, relatie intake–zorgepisode
**Kader:** bouwt voort op de besluiten in `datamodel-discovery.md` (§3.1 spelregels, §5.1 #9 ZORGEPISODE, §5.2 besluiten 1–4). Geen enkel besluit is teruggedraaid.
> **Let op:** de intake is nader besloten als één onderzoekstraject per samenhangende zorgvraag, met meerdere contacten, onderzoeken en disciplines. Interne overgangen vormen geen nieuwe intake. De precieze relatie met AANMELDINGSTRAJECT en ZORGEPISODE volgt uit de nog uit te werken formele acceptatie.
Standaardvelden op elk record (spelregels §3.1, hier niet per entiteit herhaald): `id` (UUID, stabiel), `created_at`/`created_by`, `updated_at`/`updated_by`, `deleted_at` (soft delete), append-only audit met hash-chaining.
---
## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.2)
Gewijzigde zinnen vervangen de genoemde discovery-zin; nieuwe zinnen komen erbij.
1. **(gewijzigd, §5.2 #4)** *Voor de zorgepisode van Jan de Vries is op 20 juli 2026 een intake gestart op afdeling Volwassenen, met aanleiding "regulier".* — De intake hangt aan de ZORGEPISODE (besluit §5.2 #1), niet meer "op basis van de aanmelding"; de aanmelding is via de episode bereikbaar.
2. **(nieuw)** *De intake voor de zorgepisode van Jan de Vries is op 18 juli 2026 aangemaakt met status "gepland".* — Er zit tijd tussen het besluit tot intake en het eerste gesprek (aanmeldwachttijd, NZa: wachttijd loopt tot het moment dat de cliënt voor de intake terecht kan).
3. **(gewijzigd, §5.2 #5)** *De intake heeft status "bezig" sinds 22 juli 2026.*
4. **(gewijzigd, §5.2 #6)** *Bij de intake is een contactmoment van type "intakegesprek" geregistreerd op 22 juli 2026, uitgevoerd door psycholoog M. de Boer, met toelichting "eerste gesprek, anamnese afgenomen".*
5. **(nieuw)** *Het contactmoment van 22 juli 2026 had een geplande duur van 60 minuten.* — Optioneel veld; voorbereiding op ZPM-consultregistratie ("planning = realisatie"), uitwerking in de agenda-/declaratieronde.
6. **(gewijzigd, §5.2 #7)** *De kindcheck voor de intake is op 22 juli 2026 uitgevoerd door M. de Boer: cliënt is verantwoordelijk voor minderjarige kinderen: nee.* — Uitvoerder en datum zijn verplicht; de vlag is verbreed van "thuiswonend" naar "verantwoordelijk voor" (kindcheck-norm KNMG-meldcode: ook co-ouderschap en andere zorgrelaties tellen).
7. **(nieuw)** *Bij de kindcheck van cliënt X is vastgelegd: verantwoordelijk voor 2 minderjarige kinderen (leeftijden "4 en 7"); zorgen over veiligheid: ja, met toelichting "moeder oververmoeid, geen netwerk"; actie ondernomen: ja, met toelichting "adviesvraag Veilig Thuis, 23 juli".* — Bij "ja" op een vlag is de bijbehorende toelichting verplicht.
8. **(gewijzigd, §5.2 #8)** *De intake is op 30 juli 2026 afgerond met uitkomst "in zorg", met geadviseerd zorgprogramma "Algemeen GGZ".* — Uitkomst is verplicht bij afronden; zorgprogramma-advies is optioneel en komt uit de waardelijst ZORGPROGRAMMA (besluit §5.2 #2).
9. **(nieuw)** *De intake van cliënt Y is op 30 juli 2026 afgerond met uitkomst "terugverwijzing", met toelichting "advies aan huisarts: begeleiding POH-GGZ".* — Terugverwijzing naar de verwijzer met advies is in het LKS een aparte uitkomst naast doorverwijzing naar een andere aanbieder.
10. **(nieuw)** *De intake van cliënt Z is op 25 juli 2026 afgebroken met reden "cliënt trekt zich terug".* — Afbreken is een status met reden, geen uitkomst.
11. **(nieuw)** *Binnen de lopende zorgepisode van Jan de Vries is op 1 oktober 2026 een tweede intake gestart met aanleiding "intern", op afdeling Ouderen.* — Meerdere intakes per episode (besluit §5.2 #1).
12. **(nieuw)** *Voor de zorgepisode van cliënt W is op 2 augustus 2026 een intake met aanleiding "crisis" gestart, zonder voorafgaande screening.* — Screening vóór intake is een nudge, geen harde eis (besluit §5.2 #4).
13. **(nieuw)** *De afgeronde intake van 30 juli 2026 is op 15 augustus 2026 heropend en heeft weer status "bezig".* — Zelfde flexibiliteitsprincipe als de aanmelding-status (besluit §5.1 #5); heropening laat een audit-event achter.
---
## 2. Entiteiten
### 2.1 INTAKE
**Doel:** de intake als afgebakend onderzoeks-/kennismakingstraject binnen een zorgepisode: van gepland eerste contact tot een uitkomstbesluit. Eén episode kan meerdere intakes hebben (regulier, intern, crisis).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `zorgepisode_id` | UUID → ZORGEPISODE | ja | eigenaar van de intake (besluit §5.2 #1) |
| `aanleiding_id` | ref → waardelijst `intake_aanleiding` | ja | regulier / intern / crisis |
| `afdeling_id` | ref → waardelijst `afdeling` | ja | organisatorische eenheid (besluit §5.2 #2) |
| `status` | ref → waardelijst `intake_status` | ja | zie statusmachine (§5); default `gepland` |
| `startdatum` | date | ja | datum waarop de intake start (gepland of feitelijk) |
| `einddatum` | date | nee* | *verplicht zodra status `afgerond` of `afgebroken` (check-constraint) |
| `uitkomst_id` | ref → waardelijst `intake_uitkomst` | nee* | *verplicht bij status `afgerond`, leeg bij elke andere status (check-constraint, spelregel §3.1 #7) |
| `uitkomst_toelichting` | text | nee | vrije toelichting bij de uitkomst (bijv. advies aan verwijzer) |
| `geadviseerd_zorgprogramma_id` | ref → waardelijst `zorgprogramma` | nee | inhoudelijk advies bij uitkomst `in_zorg` |
| `doorverwijzing_bestemming` | text | nee | bij uitkomst `doorverwijzing`/`terugverwijzing`: waarheen; in de correspondentieronde te vervangen door FK naar PRAKTIJK_INSTELLING |
| `afbreekreden_id` | ref → waardelijst `intake_afbreekreden` | nee* | *verplicht bij status `afgebroken`, anders leeg |
**Uniciteitsregels:**
- Geen natuurlijke sleutel; identiteit via UUID.
- "Max één lopende intake (status `gepland`/`bezig`) per episode" wordt een **aan/uit-zetbare bedrijfsregel**, geen schemabeperking — zelfde patroon als parallelle aanmeldingen (besluit §5.0 #5). Een crisis-intake kan naast een lopende reguliere intake nodig zijn.
- Check-constraints: (`status = afgerond` ⇔ `uitkomst_id` gevuld ∧ `einddatum` gevuld); (`status = afgebroken` ⇔ `afbreekreden_id` gevuld ∧ `einddatum` gevuld).
**Bewust nog niet gemodelleerd (rollenronde):** wie de intake verricht, wie indiceert, wie regiebehandelaar wordt, het centrale aanspreekpunt tussen intake en start behandeling en de crisis-/waarnemingsafspraken (LKS 4.0-dossiereisen). Deze landen in de REGIEBEHANDELAAR_TOEWIJZING-structuur van de rollenronde (onderzoek-proces §10.3, verrijking 7 en 11); het intakemodel hoeft daarvoor niet te wijzigen omdat die toewijzingen aan de episode/intake refereren, niet andersom.
### 2.2 CONTACTMOMENT
**Doel:** een feitelijk contact (gesprek, telefonisch contact, huisbezoek, onderzoek) dat in het kader van een intake heeft plaatsgevonden. Klinisch feit; de declarabele consultregistratie (ZPM) is een latere, aparte structuur die hiernaar kan verwijzen (onderzoek-rapportage §1.5: rapportage ≠ consultregistratie).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `intake_id` | UUID → INTAKE | ja | in deze ronde hangt elk contactmoment aan een intake; generalisatie (contactmoment bij behandeling/agenda) volgt in de agenda-ronde met een eigen besluit |
| `type_id` | ref → waardelijst `contactmoment_type` | ja | intakegesprek, telefonisch contact, ... |
| `datum_tijd` | timestamp | ja | wanneer het contact plaatsvond |
| `uitgevoerd_door` | UUID → MEDEWERKER | ja | uitvoerder; MEDEWERKER wordt in de rollenronde uitgewerkt, de FK ligt hier al vast |
| `toelichting` | text | nee | vrije tekst |
| `geplande_duur_minuten` | integer | nee | ZPM-voorbereiding (prestatiecode-as "duur"); type diagnostiek/behandeling, beroepscode en setting volgen in de agenda-/declaratieronde |
**Uniciteitsregels:** geen — meerdere contactmomenten van hetzelfde type op dezelfde dag zijn legitiem (twee telefonische contacten). Identiteit via UUID.
### 2.3 KINDCHECK
**Doel:** de wettelijk verankerde kindcheck (Wet verplichte meldcode huiselijk geweld en kindermishandeling; KNMG-meldcode) bij de intake van een volwassen cliënt: zijn er minderjarigen die van de cliënt afhankelijk zijn, zijn er zorgen over hun veiligheid, en is daarop actie ondernomen. De prototype-structuur (drie ja/nee-vlaggen + tekst) blijft de kern — bevestigd als goed patroon — met drie verbeteringen: (a) vlag 1 verbreed van "thuiswonend" naar "verantwoordelijk voor minderjarigen", (b) uitvoerder + datum verplicht (provenance), (c) toelichting verplicht zodra een vlag op "ja" staat (conditionele check-constraint, spelregel §3.1 #7 — regel in het model, niet alleen in de UI).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `intake_id` | UUID → INTAKE | ja | max één kindcheck per intake |
| `uitgevoerd_op` | date | ja | |
| `uitgevoerd_door` | UUID → MEDEWERKER | ja | |
| `verantwoordelijk_voor_minderjarigen` | boolean | ja | vlag 1 (was: "thuiswonende kinderen") |
| `aantal_kinderen` | integer | nee | alleen zinvol bij vlag 1 = ja |
| `leeftijden` | text | nee | vrije tekst ("4 en 7"); bewust géén kindrecords — dataminimalisatie, de kinderen zijn geen cliënt |
| `zorgen_over_veiligheid` | boolean | ja | vlag 2 |
| `zorgen_toelichting` | text | nee* | *verplicht indien vlag 2 = ja (check-constraint) |
| `actie_ondernomen` | boolean | ja | vlag 3 (bijv. adviesvraag Veilig Thuis, stap in de meldcode) |
| `actie_toelichting` | text | nee* | *verplicht indien vlag 3 = ja (check-constraint) |
| `notitie` | text | nee | algemene vrije tekst |
**Uniciteitsregels:** unieke constraint op `intake_id` (1-op-0..1). Herziening van een kindcheck = wijziging met audit-trail, geen tweede record; bij een nieuwe intake in dezelfde episode hoort een nieuwe kindcheck (situatie kan veranderd zijn).
**Wat bewust níet in het ECD-schema zit:** het meldcode-stappenplan (5 stappen, termijnen, Veilig Thuis-procesgang) is proces-state en beslislogica — TIP-terrein (§3.3). Het ECD legt de klinische feiten vast (de drie vlaggen + toelichtingen); TIP bewaakt het vervolg via nudges (zie §6).
---
## 3. Relaties met cardinaliteit
| Relatie | Cardinaliteit | Toelichting |
|---|---|---|
| ZORGEPISODE — INTAKE | 1 — 0..* | besluit §5.2 #1; een episode kan (nog) geen intake hebben (crisisinstroom in aanmeldfase) en meerdere intakes (regulier + intern + crisis) |
| AANMELDING — ZORGEPISODE | 1 — 0..1 | context uit §5.1 #9: episode ontstaat bij aanmelding-uitkomst `intake`; afgewezen aanmelding heeft nooit een episode |
| INTAKE — CONTACTMOMENT | 1 — 0..* | een geplande intake heeft nog geen contactmomenten |
| INTAKE — KINDCHECK | 1 — 0..1 | 0..1 in het schema; "verplicht vóór afronden" is een nudge (zie §6), geen schema-eis — bij een geplande of afgebroken intake kan hij ontbreken |
| INTAKE — waardelijst AFDELING | * — 1 | besluit §5.2 #2 |
| INTAKE — waardelijst ZORGPROGRAMMA | * — 0..1 | advies bij uitkomst `in_zorg` |
| CONTACTMOMENT — MEDEWERKER | * — 1 | MEDEWERKER volgt in de rollenronde; FK ligt vast |
| KINDCHECK — MEDEWERKER | * — 1 | idem |
| DIAGNOSE — INTAKE | * — 0..1 | uit deelgebied diagnose (besluit §5.4 #2): intake is optionele *herkomst* van een diagnose, geen eigenaar |
| BEHANDELPLAN — INTAKE | * — 0..1 | uit deelgebied behandelplan (feitzin §5.5 #3): "gebaseerd op de intake van ..." |
| WACHTLIJSTPLAATSING (soort `behandel`) — ZORGEPISODE | * — 1 | §5.3: behandelwachttijd start na de intake; beëindigingsreden "behandeling gestart" — raakt de intake alleen via de episode |
---
## 4. Waardelijsten
Alle waardelijsten volgen het referentietabel-patroon (spelregel §3.1 #1) met per rij: `code`, `omschrijving`, `actief`, optioneel `externe_code` + `codesysteem_uri`, en `geldig_van`/`geldig_tot` (les uit Nedaps NZa-tabellen, onderzoek-leveranciers §2.2/§7.1). Waar zinvol een `overig`-waarde met specificatie-vrij-veld (zib-patroon "anders + SpecificatieAnders", onderzoek-standaarden §2.2).
### 4.1 `intake_aanleiding`
Startwaarden (bevestiging van besluit §5.2 #1): `regulier`, `intern`, `crisis`.
Geen extra attribuut nodig. Mogelijk later attribuut `screening_verwacht` (ja/nee) als input voor de nudge "screening vóór eerste intake" — nu niet nodig, de nudge kan op aanleiding-code werken.
### 4.2 `intake_status`
Startwaarden: `gepland`, `bezig`, `afgerond`, `afgebroken`. Zie §5.
### 4.3 `intake_uitkomst`
Voorstel (verbetering t.o.v. prototype-drietal; open besluitpunt 1 en 2):
| Code | Omschrijving | Onderbouwing |
|---|---|---|
| `in_zorg` | cliënt komt in behandeling bij de instelling | prototype, bevestigd door LKS-fase indicatiestelling |
| `terugverwijzing` | terug naar de verwijzer/huisarts, met advies voor passend vervolg | **nieuw** — LKS 4.0 §6.1: bij geen passend aanbod terugverwijzen "met advies"; ander feit dan doorverwijzing (andere brief, andere ontvanger) |
| `doorverwijzing` | door naar een andere (beter passende) zorgaanbieder | prototype, verscherpt: alleen nog externe doorverwijzing; ZPM kent "doorverwijzing tussen GGZ-aanbieders" als erkende route zonder nieuwe verwijzing |
| `extra_diagnostiek` | intake afgerond, maar het indicatiebesluit vergt aanvullend (psychodiagnostisch/somatisch) onderzoek | prototype, behouden — praktijk kent dit als reële uitkomst (onderzoek-proces §3, stap 4) |
`afgewezen` is bewust géén intake-uitkomst: afwijzen gebeurt bij de aanmelding (uitkomst `afgewezen`, besluit §5.1 #5); wie een intake bereikt wordt niet meer "afgewezen" maar terug- of doorverwezen. Staken door de cliënt is geen uitkomst maar status `afgebroken` + reden.
### 4.4 `intake_afbreekreden`
Startwaarden: `client_trekt_terug`, `geen_contact_meer`, `overleden`, `overig` (+ specificatieveld). Consistent met de beëindigingsredenen-richting van §5.3 (wachtlijst).
### 4.5 `contactmoment_type`
Startwaarden (prototype-lijst bevestigd, één toevoeging): `intakegesprek`, `aanvullend_onderzoek`, `telefonisch_contact`, `huisbezoek`, `beeldcontact` (nieuw — beeldbellen is in de GGZ-praktijk een standaard contactvorm en ZPM-relevant via zorglabels digitale zorg), `overig` (+ specificatieveld).
### 4.6 Bestaande lijsten uit andere deelgebieden (hier alleen gebruikt)
`afdeling` (instellingsconfigureerbaar, besluit §5.2 #2), `zorgprogramma` (idem).
---
## 5. Statusmachine INTAKE
Statussen: `gepland` → `bezig` → `afgerond` / `afgebroken`.
| Van | Naar | Betekenis / voorwaarde |
|---|---|---|
| — | `gepland` | intake aangemaakt (besluit tot intake genomen, eerste gesprek nog niet gevoerd) |
| `gepland` | `bezig` | eerste contactmoment geregistreerd (systeemgedreven) of handmatig gezet |
| `gepland` | `afgebroken` | reden verplicht (bijv. cliënt trekt zich terug vóór het eerste gesprek) |
| `bezig` | `afgerond` | uitkomst + einddatum verplicht (check-constraint) |
| `bezig` | `afgebroken` | reden + einddatum verplicht |
| `afgerond` | `bezig` | heropening; uitkomst en einddatum worden geleegd, audit-event verplicht — zelfde flexibiliteit als aanmelding-status (besluit §5.1 #5) |
| `afgebroken` | `bezig` | heropening (cliënt meldt zich alsnog); reden wordt geleegd, audit-event verplicht |
Niet toegestaan: `gepland` → `afgerond` (afronden zonder enig geregistreerd contact is klinisch onzinnig; wil men toch, dan eerst een contactmoment registreren), `afgerond` ↔ `afgebroken` rechtstreeks.
**Wie mag welke overgang zetten: rollenronde.** Het prototype kent geen rollen; de discovery (§5.2 open vraag "wie mag een intake afronden") verwijst dit expliciet naar de rollenronde. De statusmachine zelf komt conform spelregel §3.1 #9 in een referentietabel (`status_overgang`: van, naar, actief), zodat de rol-kolom daar later aan toegevoegd wordt zonder schemawijziging van INTAKE.
De status van het prototype (`bezig`/`afgerond`) blijft een subset; `gepland` en `afgebroken` zijn toevoegingen (open besluitpunt 4).
---
## 6. ECD/TIP-eigenaarschap en events richting TIP
**Eigenaarschap:** INTAKE, CONTACTMOMENT en KINDCHECK zijn klinische feiten — **leidend in het ECD** (§3.3). TIP houdt geen kopie van deze entiteiten behalve doelgebonden snapshots bij intenties/nudges (afstemming Joshua, §3.3 #2) en eventuele longitudinale IE's (bijv. kindcheck-vlaggen voor trendbewaking, §3.3 #3). Mutatie-events (create/update/soft delete, met UUID + content-hash) zijn het koppelmechanisme (§3.3 #4). Het BSN komt nooit in events richting TIP (spelregel §3.1 #6).
**Events richting TIP:**
| Event | Payload (kern) | Waarom TIP dit nodig heeft |
|---|---|---|
| `intake.aangemaakt` | intake-id, episode-id, aanleiding, afdeling, startdatum | proces-start; nudge "screening ontbreekt bij eerste reguliere intake van de episode" (besluit §5.2 #4); behandelwachttijd-bewaking voorbereiden |
| `intake.status_gewijzigd` | intake-id, oude/nieuwe status, datum | procesbewaking; heropening detecteren |
| `intake.contactmoment_geregistreerd` | contactmoment-id, intake-id, type, datum | nudge "intake gepland maar al X dagen geen contact"; NZa-aanmeldwachttijd eindigt bij het eerste intakecontact |
| `intake.kindcheck_vastgelegd` | kindcheck-id, intake-id, drie vlaggen (géén vrije tekst met persoonsgegevens van derden) | nudges: "zorgen = ja, actie = nee" (meldcode-stap open, urgentie `waarschuwing`); trend/longitudinale IE |
| `intake.afgerond` | intake-id, uitkomst, einddatum, geadviseerd zorgprogramma | vervolg-nudges: bij `in_zorg` → "behandelplan opstellen", "behandelwachttijd gestart (Treeknorm 10 wkn)", "intakebrief aan verwijzer (toestemming cliënt)"; bij `extra_diagnostiek` → "vervolg binnen X dagen?"; bij `terugverwijzing`/`doorverwijzing` → "brief aan verwijzer/ontvanger" |
| `intake.afgebroken` | intake-id, reden, einddatum | proces afsluiten, eventueel aanmelding-heropening voorstellen |
**Nudges (protocolregels in TIP, geen schema-eisen):** kindcheck ontbreekt bij afronden intake (`waarschuwing`); zorgen zonder actie (`waarschuwing`, escalatie naar `blokkade` denkbaar bij crisiscontext); screening ontbreekt vóór eerste reguliere intake (`signaal`); geen contactmoment X dagen na plandatum (`signaal`); LKS-aanspreekpunt tussen intake en start behandeling niet vastgelegd (`signaal` — pas actief na de rollenronde).
---
## 7. Open besluitpunten voor Colin
1. **Uitkomst splitsen: `terugverwijzing` naast `doorverwijzing`?** Het prototype kent alleen `doorverwijzing`. Het LKS onderscheidt terugverwijzing naar de huisarts (met advies) van doorverwijzing naar een andere aanbieder — andere ontvanger, andere correspondentieplicht, ander ZPM-verwijstype bij de ontvangende partij. **Advies: splitsen** (twee waarden in de waardelijst; kost niets, voorkomt een vrije-tekst-onderscheid later).
2. **`extra_diagnostiek` behouden als einduitkomst?** Alternatief: de intake open laten tot alle diagnostiek klaar is. **Advies: behouden.** De praktijk sluit de intakefase administratief af terwijl aanvullend onderzoek loopt; het vervolg is dan óf een nieuw contactmoment binnen een nieuwe (interne) intake, óf de diagnostiekstructuur van een latere ronde. Heropening (`afgerond` → `bezig`) dekt de gevallen waarin het toch één traject blijkt.
3. **Kindcheck: vierde vlag "cliënt (of partner) zwanger"?** De KNMG-kindcheck rekent zwangerschap expliciet mee (het ongeboren kind telt). **Advies: toevoegen** als optionele boolean `zwangerschap` — kleine toevoeging, wettelijk gedekt gat. (Let op: KNMG-meldcode-detail is algemene kennis, niet uit de vier onderzoeksrapporten — bij twijfel kort verifiëren in de meldcode-tekst.)
4. **Statussen `gepland` en `afgebroken` toevoegen** naast prototype-`bezig`/`afgerond`. **Advies: ja.** Zonder `gepland` is de aanmeldwachttijd (aanmelding → eerste intakecontact) niet uit het model af te leiden; zonder `afgebroken` wordt staken door de cliënt een oneigenlijke "uitkomst".
5. **Kinderen als platte velden (`aantal_kinderen` + `leeftijden`-tekst) of als aparte kindrecords?** **Advies: plat houden.** De kinderen zijn geen cliënt; aparte persoonsrecords van derden in het dossier schuren met dataminimalisatie. Wordt een kind zelf cliënt, dan ontstaat een eigen PERSOON via de normale route.
6. **"Max één lopende intake per episode" als aan/uit-bedrijfsregel — standaard aan of uit?** **Advies: standaard uit** (crisis-intake naast lopende reguliere intake moet kunnen), met een `signaal`-nudge bij een tweede lopende intake.
7. **Episode-ontstaan bevestigen: pas bij aanmelding-uitkomst `intake`, niet bij `wachtlijst`** (open detail §5.1 #9). Onderzoek-proces §10.3 ondersteunt dit: aanmeldwachttijd hoort bij de AANMELDING, verantwoordelijkheidsoverdracht ligt ná de intake. **Advies: bevestigen zoals al voorgesorteerd** — geen wijziging, alleen het open detail sluiten.
8. **`beeldcontact` toevoegen aan `contactmoment_type`?** **Advies: ja** — gangbare contactvorm, en ZPM-zorglabels voor digitale zorg (S-labels) vragen er later om. De waardelijst is instellingsconfigureerbaar, dus dit is alleen een startwaarde-keuze.
9. **Contactmoment nu exclusief aan INTAKE hangen** (deze ronde) en generalisatie naar behandeling/agenda uitstellen tot de agenda-ronde. **Advies: akkoord gaan met deze scope-afbakening**; de agenda-ronde beslist of CONTACTMOMENT opgaat in een generieke consult-/afspraakstructuur of ernaast blijft bestaan (ZPM: planning ≠ geleverde prestatie, onderzoek-leveranciers §2.8).
---
## 8. Bronverwijzingen
| Onderwerp | Bron |
|---|---|
| Intake aan zorgepisode, meerdere intakes, aanleiding-waardelijst | discovery §5.2 besluit 1; §5.1 #9 |
| Afdeling/zorgprogramma gescheiden waardelijsten | discovery §5.2 besluit 2 |
| Screening-vóór-intake als nudge | discovery §5.2 besluit 4 |
| Prototype kindcheck (3 vlaggen + tekst), intake-afronding via behandeladvies-tab, statussen bezig/afgerond | discovery §5.2 bevindingen; prototype `app/epd/patients/[id]/intakes/[intakeId]/kindcheck/` en `actions.ts` (encounters) |
| LKS 4.0: intakefase, terugverwijzing met advies, doorverwijzing, aanspreekpunt intake→behandeling, verantwoordelijkheidsoverdracht ná intake | onderzoek-proces §1, §6.1, §10.1 (stappen 7–8) |
| NZa-wachttijddefinities (aanmeldwachttijd tot intake; behandelwachttijd vanaf intake), Treeknormen 4/10 weken | onderzoek-proces §4.1–4.2 |
| Episode pas bij intake, aanmeldwachttijd op aanmelding | onderzoek-proces §10.3 (open vragen) |
| ZPM-consult-assen (beroep, type, duur, setting) als voorbereiding op CONTACTMOMENT-velden | onderzoek-standaarden §6.2, §8 (checklist CONTACTMOMENT) |
| Waardelijst-rijen met geldigheidsperioden en externe codes; "anders + specificatie"-patroon | onderzoek-leveranciers §2.2, §7.1; onderzoek-standaarden §2.2 (zib BehandelAanwijzing2), §8 |
| Consultregistratie ≠ klinische rapportage (twee feiten) | onderzoek-rapportage §1.5 |
| Statusmachine in referentietabel, check-constraints, soft delete, provenance | discovery §3.1 spelregels #1, #3, #4, #7, #9 |
| ECD/TIP-grensvlak: snapshots, longitudinale IE's, mutatie-events, meldcode-proces als TIP-terrein | discovery §3.3 (afstemming Joshua); onderzoek-standaarden §4 checklist 3 (proces-state → TIP) |
| Kindcheck-grondslag (Wet verplichte meldcode, KNMG-kindcheck incl. zwangerschap) | algemene domeinkennis, niet in de vier rapporten — expliciet gemarkeerd bij open besluitpunt 3 |

366
docs/datamodel/deelmodellen/model-rapportage.md Normal file
View File

@@ -0,0 +1,366 @@
# Datamodelvoorstel — Deelgebied Voortgangsrapportage
**Status:** deels herzien — zie `../besluiten/besluitenlog-datamodel-2026-07-18.md` §§6 en 8
**Datum:** 18 juli 2026
**Modelleur:** Claude (deelgebied rapportage & overdracht)
**Kader:** bouwt voort op `datamodel-discovery.md` (spelregels §3.1, AI-voorbereiding §3.2, TIP-grensvlak §3.3, besluiten §5). Geen enkel genomen besluit wordt teruggedraaid. Onderbouwing uit `../onderzoek/onderzoek-rapportage.md`, `onderzoek-proces.md`, `../onderzoek/onderzoek-leveranciers.md`, `../onderzoek/onderzoek-standaarden.md`.
> **Let op:** een klinische rapportage heeft één primaire zorgepisode en kan naar andere context verwijzen zonder daarmee toegang te verlenen. Een MDO-verslag is alleen de verslagcomponent van een afzonderlijke MDO-workflow; hetzelfde geldt voor rapportage bij een formele evaluatie.
---
## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery)
Feitzin 9 uit discovery §5.2 ("Verslag X is geschreven door… / gegenereerd door AI-model Z…") wordt in deze ronde uitgewerkt; alle overige zinnen zijn nieuw. Nummering R1–R24.
**Kernrapportage**
1. *R1 — Voor de zorgepisode van Jan de Vries is op 2 augustus 2026 een rapportage van type "voortgang" vastgelegd door psycholoog M. de Boer.*
2. *R2 — De rapportage van 2 augustus gaat over een gebeurtenis van 2 augustus 2026, 16:30.*
3. *R3 — De rapportage van 2 augustus heeft als vrije tekst "…".*
4. *R4 — De rapportage van 2 augustus is geschreven volgens methodiek "SOEP" en heeft als sectie "Plan" de tekst "…".* (methodiek is optioneel; een rapportage zonder methodiek heeft alleen vrije tekst)
5. *R5 — De rapportage van 2 augustus hoort bij het contactmoment van 2 augustus 2026.* (optioneel)
6. *R6 — De rapportage van 2 augustus rapporteert op behandeldoel "weer drie nachten per week doorslapen" met voortgangsindicatie "lichte vooruitgang".* (0..n doelen per rapportage, indicatie optioneel per doelkoppeling)
7. *R7 — De rapportage van 2 augustus heeft status "definitief" sinds 2 augustus 2026, 17:04.*
8. *R8 — Rapportageversie 2 van 5 augustus 2026 vervangt rapportageversie 1 van 2 augustus 2026; versie 1 heeft sindsdien status "vervangen".* (correctie ná definitief = nieuwe versie, nooit stille edit)
**Provenance (spelregel 3.1 #2)**
9. *R9 — De rapportage van 2 augustus heeft herkomst "mens" en als auteur medewerker M. de Boer.*
10. *R10 — Rapportage Y is gegenereerd door AI-model Z (versie …) op basis van bronrecords A (content-hash h1) en B (content-hash h2).*
11. *R11 — Rapportage Y is op 3 augustus 2026 bevestigd door M. de Boer; pas daarna kreeg hij status "definitief".* (AI-record wordt nooit definitief zonder menselijke bevestiging)
12. *R12 — De rapportage van 2 augustus heeft content-hash h3.* (wijziging tekst ⇒ nieuwe hash ⇒ her-embedding + mutatie-event, discovery §3.2/§3.3.4)
**Dienst, dagdeel en overdracht**
13. *R13 — Verpleegkundige K. Jansen heeft op 3 augustus 2026 om 06:30 een rapportage van type "verpleegkundig" vastgelegd; deze telt bij dienstdag 2 augustus, dagdeel "nacht".* (grens ligt vast als instellingsconfiguratie, standaard 07:00 — niet hardcoded)
14. *R14 — De verpleegkundige rapportage van 3 augustus is gemarkeerd voor de overdracht.*
15. *R15 — Voor de zorgepisode van Jan de Vries is op 3 augustus 2026 een overdrachtssamenvatting over de periode 2–3 augustus gegenereerd door AI-model Z, op basis van de rapportages R13 en R14 (met content-hashes).*
16. *R16 — De overdrachtssamenvatting van 3 augustus is bevestigd door verpleegkundige K. Jansen.*
**Zichtbaarheid en cliëntrechten (WGBO/Wabvpz)**
17. *R17 — De rapportage van 2 augustus is zichtbaar voor de cliënt in het portaal.* (vlag stuurt portaalweergave; het wettelijk inzagerecht blijft altijd bestaan)
18. *R18 — Cliënt Jan de Vries heeft op 6 augustus 2026 een eigen verklaring aan zijn dossier laten toevoegen.* (rapportagetype "clientverklaring", auteurtype "cliënt"; opname is verplicht voor de instelling)
**Incident (Wkkgz art. 10 lid 3 — dossierspoor)**
19. *R19 — Op 5 augustus 2026 om 21:15 heeft zich rond cliënt Jan de Vries een incident van categorie "medicatie-incident" voorgedaan.*
20. *R20 — Van het incident van 5 augustus zijn aard, toedracht en tijdstip in het dossier aangetekend.*
21. *R21 — Bij het incident van 5 augustus was medewerker K. Jansen direct betrokken.* (0..n betrokkenen per incident)
**Episodeniveau en doelrelatie**
22. *R22 — Het MDO van 1 september 2026 over de zorgepisode van Jan de Vries is vastgelegd in een rapportage van type "MDO-verslag", met betrokken disciplines psychiatrie en verpleegkunde.*
23. *R23 — De evaluatierapportage van 15 september 2026 hoort bij behandelplan versie 1 (evaluatiemoment week 6).*
24. *R24 — De rapportage van 2 augustus is een verslag over de intake van 20 juli 2026.* (optionele verwijzing; vervangt de prototype-rapporttypen `intake`/`behandeladvies` — zie open besluitpunt 2)
---
## 2. Entiteiten
### 2.1 RAPPORTAGE (kern)
**Doel:** één klinisch verslag-record in het cliëntdossier: gestructureerde velden + vrije tekst in hetzelfde record (spelregel §3.2), met verplichte provenance (spelregel 3.1 #2). Vervangt de prototype-tabel `reports` inclusief de drie impliciete typologieën (onderzoek-rapportage §8.2).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| id | uuid | ja | stabiel (spelregel 3.1 #5) |
| zorgepisode_id | uuid → ZORGEPISODE | ja | eigenaar van het verslag; cliënt is afleidbaar via de episode (geen dubbele FK) |
| rapportagetype_code | code → waardelijst `rapportagetype` | ja | |
| gebeurtenis_datumtijd | timestamptz | ja | wanneer het gerapporteerde plaatsvond (≠ moment van vastleggen) |
| vrije_tekst | text | ja | embeddings-bron (§3.2); minimumlengte per type via typeconfiguratie |
| methodiek_code | code → waardelijst `rapportagemethodiek` | nee | SOEP/DAP/TIP; leeg = alleen vrije tekst. Methodiek is optie, geen dwang |
| dienst_datum | date | nee* | *verplicht als het type `dienstweergave = ja` heeft; berekend bij vastleggen (vóór dienstgrens ⇒ vorige dag) en daarna bevroren |
| dagdeel_code | code → waardelijst `dagdeel` | nee* | idem; afgeleid uit gebeurtenis_datumtijd + dagdeel-tijdvakken |
| overdracht_markering | boolean | ja (default per type) | "neem mee in overdracht" |
| client_zichtbaar | boolean | ja (default per type) | portaalweergave; heft Wabvpz-inzagerecht nooit op |
| herkomst | code → waardelijst `herkomst` (`mens`/`ai`) | ja | spelregel 3.1 #2 |
| auteur_type_code | code → waardelijst `auteur_type` | ja | medewerker / cliënt / naaste / extern / ai |
| auteur_medewerker_id | uuid → MEDEWERKER | ja indien herkomst=mens én auteur_type=medewerker | |
| auteur_persoon_id | uuid → PERSOON | ja indien auteur_type=cliënt/naaste | cliëntverklaring, naaste-notitie |
| ai_model | text | ja indien herkomst=ai | modelnaam + versie |
| bevestigd_door_medewerker_id | uuid → MEDEWERKER | ja vóór status definitief indien herkomst=ai | human-in-the-loop, harde platformregel |
| bevestigd_op | timestamptz | idem | |
| status_code | code → waardelijst `rapportagestatus` | ja | zie statusmachine (§5) |
| definitief_op | timestamptz | ja bij status ≥ definitief | |
| versienummer | integer | ja (default 1) | |
| vorige_versie_id | uuid → RAPPORTAGE | nee | versieketen; nieuw record per versie |
| intake_id | uuid → INTAKE | nee | "verslag over" een intake |
| contactmoment_id | uuid → CONTACTMOMENT | nee | koppeling aan consult; consultregistratie (ZPM) blijft een apart feit |
| behandelplan_id | uuid → BEHANDELPLAN | nee | voor evaluatie- en MDO-verslagen |
| content_hash | text (sha-256) | ja | trigger her-embedding + TIP-koppelafspraak (§3.3.4) |
| created_at / updated_at / deleted_at / created_by | — | ja/ja/nee/ja | soft delete (spelregel 3.1 #4) |
**Uniciteitsregels**
- `vorige_versie_id` is uniek indien gevuld (max. één opvolger per versie; de keten is een lijst, geen boom).
- Per versieketen is er hoogstens één record met status `concept` of `definitief`; alle voorgangers hebben status `vervangen`.
- Content-hash + updated_at maken elke tekstwijziging detecteerbaar (append-only audit, spelregel 3.1 #3, logt de rest).
### 2.2 RAPPORTAGESECTIE
**Doel:** optionele gestructureerde secties per methodiek (S/O/E/P, D/A/P, T/I/P) naast de vrije tekst — methodiekwissel is configuratie, geen migratie (onderzoek-rapportage §3, §9.1; Nedap `soapReportEntries`, onderzoek-leveranciers §2.5).
| Attribuut | Type | Verplicht |
|---|---|---|
| id | uuid | ja |
| rapportage_id | uuid → RAPPORTAGE | ja |
| sectietype_code | code → waardelijst `sectietype` | ja |
| tekst | text | ja |
**Uniciteit:** (rapportage_id, sectietype_code) uniek — één sectie "Plan" per rapportage. Secties zijn alleen toegestaan als hun sectietype bij de methodiek van de rapportage hoort (check-constraint via waardelijst, spelregel 3.1 #7).
### 2.3 RAPPORTAGE_DOELKOPPELING
**Doel:** rapporteren-op-doel (onderzoek-rapportage §4; Nedap/ZilliZ-praktijk). Een rapportage refereert 0..n behandeldoelen; per koppeling optioneel een voortgangsindicatie.
| Attribuut | Type | Verplicht |
|---|---|---|
| rapportage_id | uuid → RAPPORTAGE | ja |
| behandeldoel_id | uuid → BEHANDELDOEL | ja |
| voortgang_code | code → waardelijst `voortgang_indicatie` | nee |
**Uniciteit:** (rapportage_id, behandeldoel_id) uniek.
### 2.4 AI_BRONVERWIJZING
**Doel:** verplichte bronverwijzingen bij AI-gegenereerde records (spelregel 3.1 #2) — generiek bruikbaar voor RAPPORTAGE én OVERDRACHTSSAMENVATTING (en later andere AI-output). Legt vast waaróp de generatie rustte, inclusief content-hash van de bron op dat moment (zelfde mechanisme als TIP-snapshot, discovery §3.3.2).
| Attribuut | Type | Verplicht |
|---|---|---|
| id | uuid | ja |
| eigenaar_entiteit | code (`rapportage`/`overdrachtssamenvatting`) | ja |
| eigenaar_id | uuid | ja |
| bron_entiteit | code (bv. `rapportage`, `intake`, `diagnose`, `behandelplan`) | ja |
| bron_id | uuid | ja |
| bron_content_hash | text | ja | hash van de bron ten tijde van generatie |
| volgorde | integer | nee |
**Uniciteit:** (eigenaar_entiteit, eigenaar_id, bron_entiteit, bron_id) uniek.
**Regel:** een record met herkomst `ai` moet ≥ 1 bronverwijzing hebben vóór het definitief kan worden.
### 2.5 INCIDENTDETAIL
**Doel:** de Wkkgz art. 10 lid 3-dossieraantekening: bij een rapportage van type `incident` horen gestructureerde velden aard, toedracht, tijdstip en betrokkenen (onderzoek-rapportage §1.3, §6, §9.3). 1-op-1 op RAPPORTAGE; de vrije tekst van de rapportage blijft het verhalende deel (spelregel §3.2: structuur + tekst in hetzelfde record).
| Attribuut | Type | Verplicht |
|---|---|---|
| rapportage_id | uuid → RAPPORTAGE (PK) | ja |
| incidentcategorie_code | code → waardelijst `incidentcategorie` | ja |
| aard | text | ja |
| toedracht | text | ja |
| incident_datumtijd | timestamptz | ja |
| merkbare_gevolgen | boolean | ja | art. 10-criterium; ook "mogelijk in de toekomst" telt |
| client_geinformeerd_op | date | nee | meldplicht aan cliënt; nudge indien leeg |
**Uniciteit:** rapportage_id is PK (1-op-1). Verplicht aanwezig als rapportagetype = `incident` (check-constraint).
### 2.6 INCIDENT_BETROKKENE
**Doel:** namen van direct betrokkenen bij het incident (wettelijk vereist veld).
| Attribuut | Type | Verplicht |
|---|---|---|
| id | uuid | ja |
| incident_rapportage_id | uuid → INCIDENTDETAIL | ja |
| medewerker_id | uuid → MEDEWERKER | nee* |
| naam_vrij | text | nee* |
\* Precies één van beide gevuld: interne betrokkene via referentie, externe via vrije naam.
**Uniciteit:** (incident_rapportage_id, medewerker_id) uniek indien medewerker_id gevuld.
> **Bewust buiten deze entiteit:** de VIM-melding (Wkkgz art. 9) is een apart register buiten het cliëntdossier met eigen autorisatie en levenscyclus — zie open besluitpunt 4. De IGJ-calamiteitenmelding is proces-state (TIP-kandidaat).
### 2.7 OVERDRACHTSSAMENVATTING
**Doel:** de vastgelegde (AI-)overdracht per episode over een periode/dienst, mét provenance en bronverwijzingen naar de onderliggende rapportages (onderzoek-rapportage §9.2; discovery §3.3.2 — zonder snapshot is niet herleidbaar waarop de overdracht rustte).
| Attribuut | Type | Verplicht |
|---|---|---|
| id | uuid | ja |
| zorgepisode_id | uuid → ZORGEPISODE | ja |
| periode_van / periode_tot | timestamptz | ja |
| dagdeel_code | code → waardelijst `dagdeel` | nee | bij dienst-gebonden overdracht |
| samenvatting_tekst | text | ja |
| herkomst | code (`mens`/`ai`) | ja |
| ai_model | text | ja indien herkomst=ai |
| bevestigd_door_medewerker_id | uuid → MEDEWERKER | ja vóór status definitief indien herkomst=ai |
| bevestigd_op | timestamptz | idem |
| status_code | code → waardelijst `rapportagestatus` | ja | zelfde statusmachine als RAPPORTAGE |
| content_hash | text | ja |
| created_at / deleted_at / created_by | — | ja/nee/ja |
**Uniciteit:** geen harde uniciteit op (episode, periode) — hergenereren levert een nieuw record; het oude krijgt status `vervangen`. Bronnen via AI_BRONVERWIJZING (≥ 1 verplicht bij herkomst `ai`).
### 2.8 Configuratie (geen eigen entiteitenkaart-blok, wel vastgelegd)
- **INSTELLINGSCONFIG `dienstgrens`** — tijdstip (default 07:00) waarvóór een rapportage bij de vorige dienstdag telt. Data, niet hardcoded (lost prototype-gebrek §8.2.5 op).
- **Dagdeel-tijdvakken** — als attributen op de waardelijst `dagdeel` (van/tot), zelfde reden.
---
## 3. Relaties met cardinaliteit
| Relatie | Cardinaliteit | Toelichting |
|---|---|---|
| RAPPORTAGE → ZORGEPISODE | n : 1 (verplicht) | eigenaar; cliënt afleidbaar. Eén episode per rapportage (Nedap doet m:n — bewust niet gevolgd, zie open besluitpunt 3) |
| RAPPORTAGE → waardelijst `rapportagetype` | n : 1 (verplicht) | |
| RAPPORTAGE → MEDEWERKER (auteur) | n : 0..1 | verplicht bij herkomst mens/auteur medewerker |
| RAPPORTAGE → PERSOON (auteur) | n : 0..1 | cliëntverklaring / naaste |
| RAPPORTAGE → MEDEWERKER (bevestiger) | n : 0..1 | verplicht vóór definitief bij herkomst AI |
| RAPPORTAGE → RAPPORTAGE (vorige versie) | 1 : 0..1 | versieketen, opvolger uniek |
| RAPPORTAGE → CONTACTMOMENT | n : 0..1 | consult (ZPM-registratie) en verslag zijn twee feiten die verwijzen, geen één record (onderzoek-rapportage §1.5) |
| RAPPORTAGE → INTAKE | n : 0..1 | verslag-over |
| RAPPORTAGE → BEHANDELPLAN | n : 0..1 | evaluatie-/MDO-verslag |
| RAPPORTAGE ↔ BEHANDELDOEL | n : m via RAPPORTAGE_DOELKOPPELING | 0..n doelen per rapportage; voortgangsindicatie optioneel |
| RAPPORTAGESECTIE → RAPPORTAGE | n : 1 | max. één per sectietype |
| INCIDENTDETAIL → RAPPORTAGE | 1 : 1 | alleen bij type `incident` |
| INCIDENT_BETROKKENE → INCIDENTDETAIL | n : 1 | |
| AI_BRONVERWIJZING → (RAPPORTAGE \| OVERDRACHTSSAMENVATTING) | n : 1 (polymorf) | stabiele UUID's maken dit veilig (spelregel 3.1 #5) |
| OVERDRACHTSSAMENVATTING → ZORGEPISODE | n : 1 (verplicht) | |
| OVERDRACHTSSAMENVATTING → MEDEWERKER (bevestiger) | n : 0..1 | |
**Naar andere deelgebieden:** ZORGEPISODE (discovery §5.1 #9), INTAKE (§5.2), BEHANDELPLAN + BEHANDELDOEL (§5.5), CONTACTMOMENT (agenda-ronde; FK nu al gereserveerd), MEDEWERKER en PERSOON (rollenronde). Verslaglegging in de aanmeld-/screeningsfase loopt via SCREENINGSACTIVITEIT (bestaat al, §5.2 besluit 3) — een RAPPORTAGE zonder episode bestaat in dit voorstel niet (open besluitpunt 1).
---
## 4. Waardelijsten
Alle lijsten conform spelregel 3.1 #1: referentietabellen, UI en database delen één bron. Elke rij krijgt (patroon uit onderzoek-standaarden §8): `code`, `naam`, `actief`, optioneel `externe_code` + `codesysteem_uri`, `geldig_van`/`geldig_tot`.
### 4.1 `rapportagetype` — met typeconfiguratie als attributen
Attributen per waarde: `overdracht_default` (ja/nee), `client_zichtbaar_default` (ja/nee), `dienstweergave` (telt mee in dienst/dagdeel-overzicht), `standaard_methodiek` (0..1), `episode_niveau` (ja = niet per se één cliëntcontact, bv. MDO), `min_lengte`/`max_lengte`. Dit vervangt de drie hardcoded prototype-lijsten (`REPORT_TYPES`, `VERPLEEG_REPORT_TYPES`, `CATEGORY_CONFIG`) door één configuratiebron — het Nedap-patroon "rapporttypen zijn beheerconfiguratie", zonder de Nedap-fout van magic numbers in de docs.
| Code | Overdracht | Cliëntzichtbaar | Dienstweergave | Herkomst |
|---|---|---|---|---|
| `voortgang` | nee | ja | nee | prototype |
| `observatie` | ja | ja | ja | prototype |
| `incident` | ja | ja | ja | prototype (nu mét art. 10-structuur) |
| `medicatie` | ja | ja | ja | prototype |
| `contact` | nee | ja | nee | prototype |
| `crisis` | ja | ja | ja | prototype |
| `verpleegkundig` | ja | ja | ja | prototype |
| `vrije_notitie` | nee | ja | nee | prototype |
| `evaluatie` | nee | ja | nee | nieuw (LKS: evaluatie ≥ 1×/jaar aantoonbaar) |
| `mdo_verslag` | nee | ja | nee | nieuw (LKS/Verenso; episode_niveau = ja) |
| `clientverklaring` | nee | ja | nee | nieuw (WGBO-aanvullingsrecht; auteur_type cliënt) |
Prototype-typen `intake` en `behandeladvies` **vervallen als rapportagetype** (open besluitpunt 2): een verslag *over* een intake is een rapportage met `intake_id`; het behandeladvies is al een eigen entiteit in de intake-flow (discovery §5.2). De verpleegkundige subcategorie (medicatie/adl/gedrag/incident/observatie) vervalt als aparte JSON-dimensie: adl en gedrag kunnen desgewenst als extra rapportagetypen worden toegevoegd — dat is nu configuratie, geen code.
### 4.2 `rapportagemethodiek`
`vrij` (default), `soep`, `dap`, `tip`, `sbar`. Optionele structuur, geen dwang (onderzoek-rapportage §3: geen landelijk verplichte notitievorm; methodiek = configuratie).
### 4.3 `sectietype` — attribuut: `methodiek_code`, `volgorde`
| Methodiek | Secties |
|---|---|
| soep | `soep_s` Subjectief · `soep_o` Objectief · `soep_e` Evaluatie · `soep_p` Plan |
| dap | `dap_d` Data · `dap_a` Assessment · `dap_p` Plan |
| tip | `tip_t` Thema · `tip_i` Interventie · `tip_p` Plan |
| sbar | `sbar_s` Situation · `sbar_b` Background · `sbar_a` Assessment · `sbar_r` Recommendation |
### 4.4 `dagdeel` — attributen: `tijd_van`, `tijd_tot`
`nacht` (23:00–07:00), `ochtend` (07:00–15:00), `middag` (15:00–19:00), `avond` (19:00–23:00). Tijdvakken zijn data (per instelling aanpasbaar); startwaarden uit het prototype-timelinepatroon.
### 4.5 `voortgang_indicatie` (op doelkoppeling)
`achteruitgang`, `gelijk`, `lichte_vooruitgang`, `duidelijke_vooruitgang`, `behaald`. (Startlijst; Nedap gebruikt een vergelijkbare voortgangsmaat — te bevestigen, open besluitpunt 9.)
### 4.6 `incidentcategorie`
`agressie_geweld`, `medicatie_incident`, `val`, `suicide_poging_automutilatie`, `vermissing_onttrekking`, `seksueel_grensoverschrijdend`, `middelengebruik`, `overig` (met specificatieveld — zib-patroon "anders + specificatie"). Bron: IGJ-meldingscategorieën GGZ.
### 4.7 `auteur_type`
`medewerker`, `client`, `naaste`, `extern`, `ai`. (Nedap kent employee/caren/extern; AI is de Triqura-uitbreiding conform spelregel 3.1 #2.)
### 4.8 `herkomst`
`mens`, `ai`. Bewust een eigen as naast auteur_type: een AI-gegenereerd-en-bevestigd verslag blijft herkomst `ai` — de bevestiging maakt de mens verantwoordelijk, niet de auteur.
### 4.9 `rapportagestatus`
`concept`, `definitief`, `vervangen`. (Zib TekstUitslag kent pending/preliminary/final/corrected — ons `vervangen` + nieuwe versie dekt "corrected" semantisch; export-mapping is triviaal.)
---
## 5. Statusmachine
Statussen en overgangen in een referentietabel (spelregel 3.1 #9). Geldt voor RAPPORTAGE én OVERDRACHTSSAMENVATTING.
| Van | Naar | Trigger | Wie mag |
|---|---|---|---|
| — | `concept` | aanmaken | elke medewerker met dossiertoegang; AI (via pipeline) maakt altijd en alleen `concept` |
| `concept` | `concept` | bewerken | auteur (bij AI: de beoogd bevestiger); vrij bewerken toegestaan zolang concept |
| `concept` | `definitief` | accorderen | **alleen een mens** (nooit AI — human-in-the-loop is platform-hard). Bij herkomst `ai`: pas na `bevestigd_door` + `bevestigd_op` én ≥ 1 bronverwijzing. Welke rollen precies → **rollenronde** |
| `concept` | *(soft delete)* | verwijderen | auteur; `deleted_at`, nooit hard delete |
| `definitief` | `vervangen` | nieuwe versie wordt definitief | automatisch (systeem), atomair met de definitief-overgang van de opvolger |
| `definitief` | *(soft delete)* | WGBO-vernietigingsverzoek | **niet** via de normale flow; aparte, gelogde procedure (batchjob/verzoekafhandeling, spelregel 3.1 #4 + KNMG 2024: het vernietigingsverzoek zelf bewaren) |
**Expliciet verboden:** `definitief` → `concept` (geen stille heropening; correctie = nieuwe versie via `vorige_versie_id`), elke UPDATE van `vrije_tekst`/secties op een definitief record (append-only gedachte; DB-constraint), status zetten door een AI-component.
**Nudge-kansen (Nudge Engine, geen schema-eis):** "verslag nog concept na X dagen", "consult zonder verslag", "incident met merkbare gevolgen zonder cliënt-geïnformeerd-datum", "evaluatie langer dan een jaar geleden".
---
## 6. ECD/TIP-eigenaarschap en events richting TIP
**Eigenaarschap:** RAPPORTAGE, RAPPORTAGESECTIE, RAPPORTAGE_DOELKOPPELING, INCIDENTDETAIL(+BETROKKENE), OVERDRACHTSSAMENVATTING en AI_BRONVERWIJZING zijn **leidend in het ECD** (klinische feiten, discovery §3.3). TIP houdt geen kopie van verslagteksten; TIP mag doelgebonden snapshots maken op basis van uuid + content_hash (afspraak Joshua §3.3.2) en longitudinale IE's bijhouden (bv. voortgangsindicaties per doel, §3.3.3).
**Events ECD → TIP** (payload: record-uuid, entiteittype, rapportagetype, zorgepisode-uuid, content_hash, tijdstip — **geen vrije tekst, nooit BSN**, spelregel 3.1 #6):
| Event | Wanneer | TIP-gebruik |
|---|---|---|
| `rapportage.definitief` | concept → definitief | nudge-evaluatie na actie; trend op doelvoortgang |
| `rapportage.versie_vervangen` | nieuwe versie definitief | koppelafspraak §3.3.4: TIP-snapshot veroudert aantoonbaar; her-embedding trigger deelt dit mechanisme |
| `rapportage.verwijderd` | soft delete | idem — TIP-kopieën doelgebonden opruimen |
| `incident.aangetekend` | incidentrapportage definitief | termijn-nudges (cliënt informeren; evt. VIM/IGJ-spoor) |
| `overdracht.bevestigd` | overdrachtssamenvatting definitief | overdracht-workflow, taken |
| `rapportage.concept_aangemaakt` (optioneel) | AI-generatie klaar | TIP-taak "bevestigen" voor de behandelaar |
**Proces-state die bewust in TIP blijft (niet in het ECD):** overdrachts-workflow (wie moet nog lezen/bevestigen — Nedap's `reportActions`-patroon is bij ons TIP-terrein), VIM-analyse-workflow, IGJ-meldtermijnbewaking, "verslag vergeten"-signalering. Het ECD levert alleen de klinische feiten waaruit TIP die state afleidt.
---
## 7. Open besluitpunten voor Colin
1. **Rapportage zonder zorgepisode (screenings-/aanmeldfase)?** Voorstel: **nee** — RAPPORTAGE vereist een episode; verslaglegging vóór de episode loopt via SCREENINGSACTIVITEIT (type + toelichting, al besloten §5.2 #3). Houdt het model schoon en volgt het LKS (verwijzer is eerstverantwoordelijke tot de intake). *Advies: bevestigen.*
2. **`intake` en `behandeladvies` schrappen als rapportagetype?** Ze dupliceren eigen entiteiten (onderzoek-rapportage §8.2.3). Voorstel: schrappen; "verslag over een intake" = rapportage met `intake_id`. *Advies: schrappen; bij migratie van prototypedata krijgen oude records type `vrije_notitie` + intake-verwijzing.*
3. **Eén episode per rapportage, of meerdere (Nedap: `episodeIds[]` m:n)?** Voorstel: **één** — parallelle episodes zijn bij ons een aan/uit-bedrijfsregel (§5.0.5) en een verslag dat twee episodes raakt is zeldzaam; m:n compliceert autorisatie en TIP-events. *Advies: 1:n houden; heroverwegen als parallelle episodes aangezet worden.*
4. **VIM binnen of buiten het ECD?** De VIM-melding hoort wettelijk búiten het cliëntdossier (eigen register, eigen autorisatie). Voorstel: **buiten scope van het ECD-dossierdeel deze ronde**; alleen de dossieraantekening (INCIDENTDETAIL) modelleren; VIM als aparte module/ronde besluiten, met hooguit een optionele verwijzing VIM → rapportage-uuid. *Advies: buiten deze ronde plaatsen.*
5. **Overdrachtssamenvatting persisteren of vluchtig?** Voorstel: **persisteren** (entiteit §2.7) — zonder vastlegging is niet herleidbaar op welke bronnen een overdracht rustte (spelregel 3.1 #2 + §3.3.2), en de bevestiging door een mens is een klinisch relevant feit. *Advies: persisteren.*
6. **Dienstgrens en dagdeel-tijdvakken per instelling of per afdeling?** Voorstel: per **instelling** starten (één configwaarde), model zo dat een afdelings-override later een extra configrij is, geen migratie. *Advies: instelling nu, afdeling later.*
7. **Cliëntverklaring (WGBO-aanvulling) als rapportagetype of eigen entiteit?** Voorstel: **rapportagetype** `clientverklaring` met auteur_type `client` — de verklaring is inhoudelijk een dossierstuk met dezelfde levenscyclus; een eigen entiteit voegt nu niets toe. *Advies: rapportagetype.*
8. **Termijn-nudge "verslag nog concept"**: verplichte accordering binnen X dagen als protocolregel — welke X (config per instelling)? *Advies: nudge met default 3 werkdagen, severity `waarschuwing`; geen harde blokkade.*
9. **Waardelijst-startwaarden bevestigen:** voortgangsindicatie (§4.5), incidentcategorieën (§4.6), dagdeel-tijdvakken (§4.4), en de overdracht-/zichtbaarheids-defaults per rapportagetype (§4.1). *Advies: startwaarden overnemen en in de praktijk bijstellen — het zijn referentiedata, geen schema.*
10. **Vertrouwelijkheid per discipline** ("groen slotje", Nedap; vertrouwelijkheid zelfs per SOEP-sectie): voorstel **doorschuiven naar de rollenronde**, maar nu vastleggen dát autorisatie op rapportage-niveau (en mogelijk sectie-niveau) komt, zodat de entiteiten er geen schemawijziging voor nodig hebben. *Advies: doorschuiven, kolomreservering niet nodig (aparte autorisatietabel t.z.t.).*
11. **Persoonlijke werkaantekeningen**: NIP zegt géén dossier-entiteit. Voorstel: **niet faciliteren** in het ECD (simpelste, juridisch schoonste). *Advies: niet faciliteren; expliciet zo vastleggen in de discovery.*
---
## 8. Bronverwijzingen
| Onderwerp | Bron |
|---|---|
| Spelregels waardelijsten, provenance, audit, soft delete, UUID's, statusmachines | discovery §3.1 (#1–#5, #7, #9) |
| Tekst + structuur in één record; content-hash → her-embedding | discovery §3.2 |
| TIP-grensvlak, snapshot- en koppelafspraak (Joshua) | discovery §3.3 (#1–#4) |
| ZORGEPISODE als eigenaar van klinische records | discovery §5.1 besluit #9; §5.4 besluit #2 |
| Behandeldoel, evaluatiemoment, behandelplan-kern | discovery §5.5 |
| Verslag-feitzin + provenance-verwijzing naar deze ronde | discovery §5.2 feitzin 9 + open vragen |
| WGBO dossierplicht, 20 jaar, correctie/aanvulling/vernietiging | onderzoek-rapportage §1.1; onderzoek-proces §8 |
| Wabvpz elektronische inzage, NEN 7513-logging | onderzoek-rapportage §1.2 |
| Wkkgz art. 10 lid 3 (aard/toedracht/tijdstip/betrokkenen) en VIM-scheiding | onderzoek-rapportage §1.3, §6 |
| LKS 4.0: regiebehandelaar-verslaglegging, MDO, jaarlijkse evaluatie | onderzoek-rapportage §1.4; onderzoek-proces §1, §5, §10.1 (#12) |
| ZPM: consultregistratie ≠ inhoudelijke rapportage | onderzoek-rapportage §1.5; onderzoek-standaarden §6.2 |
| SOEP/DAP/TIP/SBAR als configuratie, niet als dwang | onderzoek-rapportage §3 |
| Rapporteren op doel + voortgangsmaat | onderzoek-rapportage §4 |
| Overdracht/dienst, eOverdracht als koppelvlak | onderzoek-rapportage §5, §9.2 |
| Prototype-analyse en gebreken (`app/api/reports`, `lib/types/report.ts`) | onderzoek-rapportage §8 |
| Nedap-patronen: ReportType-configuratie, SOEP-secties, auteurstype, verbergen-met-reden, cliëntakkoord als los feit | onderzoek-leveranciers §2.5, §2.6, §7 (#1, #7) |
| zib TekstUitslag (type/datum/status concept-definitief-gecorrigeerd) | onderzoek-standaarden §2.2 |
| Waardelijst-patroon: externe code + codesysteem + geldigheidsperiode | onderzoek-standaarden §8; onderzoek-leveranciers §7 #1 |
| NIP: werkaantekeningen geen dossier | onderzoek-rapportage §2.3 |

269
docs/datamodel/deelmodellen/model-screening.md Normal file
View File

@@ -0,0 +1,269 @@
# Datamodelvoorstel — deelgebied Screening / triage
**Status:** gerichte herziening nodig — zie `../besluiten/besluitenlog-datamodel-2026-07-18.md` §§2 en 3
**Datum:** 18 juli 2026
**Scope:** SCREENING, SCREENING_ACTIVITEIT, SCREENING_BESLUIT + wat triage in de praktijk nodig heeft: urgentiebepaling/crisissignalering, informatie-uitvraag, wie screent.
**Kader:** genomen besluiten uit `datamodel-discovery.md` zijn heilig; dit voorstel draait niets terug. De open vraag "screeningsbesluit ↔ aanmelding-uitkomst" wordt hier opgelost met een onderbouwd voorstel (§7 punt 1).
> **Let op:** SCREENING hoort voortaan bij het AANMELDINGSTRAJECT en kan informatie uit meerdere AANMELDSIGNALEN gebruiken. Het screeningsbesluit blijft een inhoudelijk advies en is niet hetzelfde als het formele acceptatiebesluit.
---
## 0. Kernkeuze vooraf: besluit ≠ uitkomst (twee feiten)
De open vraag uit discovery §5.2 ("is het screeningsbesluit hetzelfde feit als de aanmelding-uitkomst?") beantwoordt dit voorstel met: **twee aparte feiten**.
Onderbouwing:
- Het LKS 4.0 kent geen aparte screeningsfase; landelijk is alleen de intake/indicatiestelling normatief. Screening is een **interne processtap** van de instelling (onderzoek-proces §3, §10.3). Het screeningsbesluit is daarmee een *inhoudelijk advies* ("geschikt, afdeling Volwassenen, urgentie spoed"), de aanmelding-uitkomst is het *formele instellingsbesluit* ("intake" / "afgewezen" / "doorverwezen" / "wachtlijst" — discovery §5.1 #5).
- De twee vallen aantoonbaar niet samen: een screening kan "geschikt" adviseren terwijl de aanmelding op "wachtlijst" of (wegens aanmeldpauze/capaciteit) op "doorverwezen" uitkomt. Eén samengevouwen feit kan dat verschil niet uitdrukken.
- Samenvouwen zou bovendien besluit §5.1 #5 (aanmelding-uitkomstwaarden) impliciet wijzigen — dat doen we niet.
Gevolg: SCREENING_BESLUIT blijft een eigen entiteit onder SCREENING; de uitkomst op AANMELDING blijft eigendom van het deelgebied instroom. Discrepantie tussen beide is géén schemafout maar een **nudge** ("aanmelding-uitkomst wijkt af van screeningsadvies — motiveer"), zie §6.
---
## 1. Feitzinnen (nieuw en gewijzigd t.o.v. discovery §5.2)
Feitzinnen 1–3 van discovery §5.2 blijven gelden; S3 verfijnt discoveryzin 3. Nieuw/gewijzigd:
1. **(S1, gewijzigd)** *Voor de aanmelding van Jan de Vries is op 15 juli 2026 een screening gestart; screener is verpleegkundige K. Jansen.*
2. **(S2, gewijzigd)** *Bij de screening is op 16 juli 2026 een activiteit van type "telefonisch contact" geregistreerd door K. Jansen, met toelichting "huisarts gesproken over medicatiehistorie".*
3. **(S3, gewijzigd)** *Het screeningsbesluit voor de screening luidt "geschikt", met geadviseerde afdeling Volwassenen, geadviseerd zorgprogramma "Algemeen GGZ" en urgentie "regulier"; het is op 17 juli 2026 genomen door K. Jansen, met motivatie "past binnen reguliere volwassenenzorg".* — het besluit hangt aan de SCREENING (niet rechtstreeks aan de aanmelding) en draagt urgentie en optioneel zorgprogramma.
4. **(S4, nieuw)** *De screening heeft status "lopend".* / *De screening is op 17 juli 2026 afgerond.*
5. **(S5, nieuw)** *Bij de screening is op 16 juli 2026 urgentie "spoed" ingeschat door K. Jansen.* — tussentijdse urgentie-inschatting, vóór het besluit (onderzoek-proces §3: urgentie wordt vaak al bíj de screening bepaald, vóór er een wachtlijstplaatsing is).
6. **(S6, nieuw)** *Bij de activiteit van 16 juli 2026 is een crisissignaal afgegeven.* — elk contactmoment tijdens de screening kan een crisissignaal opleveren; dit gaat direct als event naar TIP.
7. **(S7, nieuw)** *Voor de screening is op 15 juli 2026 een informatie-uitvraag van type "medicatieoverzicht" gedaan bij verwijzer P. Pietersen, door K. Jansen.*
8. **(S8, nieuw)** *De informatie-uitvraag van 15 juli 2026 heeft status "uitstaand".* / *...is op 16 juli 2026 beantwoord met document document-813.*
9. **(S9, nieuw)** *De aanmelding van Jan de Vries heeft op 17 juli 2026 uitkomst "intake" gekregen; dit besluit verwijst naar het screeningsbesluit van 17 juli als onderbouwing.* — de uitkomst blijft een feit op AANMELDING (instroom-deelgebied); de verwijzing legt de relatie vast.
10. **(S10, nieuw)** *De screening is op 20 juli 2026 afgebroken met reden "cliënt trekt aanmelding in".*
11. **(S11, nieuw)** *Activiteittype "dossieronderzoek" telt niet als cliëntcontact; activiteittype "telefonisch contact" wel.* — eigenschap van de waardelijstwaarde, maakt de nudge "nog geen contact geweest bij deze screening" (discovery §5.2 besluit 3) berekenbaar.
---
## 2. Entiteiten
Alle entiteiten volgen de harde spelregels (discovery §3.1): stabiele UUID, soft delete (`deleted_at`), append-only audit, statussen/typen als referentiedata. Auditvelden (`created_at`, `created_by`, ...) worden hieronder niet herhaald.
### 2.1 SCREENING
**Doel:** de interne triagefase van één aanmelding — de periode waarin de instelling beoordeelt of, waar en hoe urgent de cliënt geholpen moet worden. Container voor activiteiten, informatie-uitvragen en het besluit.
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `id` | uuid | ja | |
| `aanmelding_id` | uuid → AANMELDING | ja | |
| `gestart_op` | date | ja | |
| `status` | ref → `screening_status` | ja | zie statusmachine §5 |
| `screener_id` | uuid → MEDEWERKER | nee | verantwoordelijk screener/triagist; invulling en verplichtheid → rollenronde |
| `urgentie_id` | ref → `urgentie` | nee | actuele tussentijdse inschatting (S5); definitieve urgentie staat op het besluit |
| `urgentie_ingeschat_op` | timestamp | nee | verplicht zodra `urgentie_id` gevuld |
| `afgerond_op` | date | nee | verplicht bij status `afgerond`/`afgebroken` |
| `afbreekreden` | ref → `screening_afbreekreden` | nee | verplicht bij status `afgebroken` |
**Uniciteit:** max **één screening met status `lopend` per aanmelding** (partial unique index op `aanmelding_id` where status = lopend en `deleted_at is null`). Meerdere afgeronde screenings per aanmelding zijn toegestaan: heropening van een besloten aanmelding (discovery §5.1 #5) start een **nieuwe** screening in plaats van een status-terugdraai — historie blijft intact.
### 2.2 SCREENING_ACTIVITEIT
**Doel:** één uitgevoerde triagehandeling (contact, dossieronderzoek, vragenlijst, ...), getypeerd conform discovery-besluit §5.2 #3. Maakt de aantoonbaarheid van de inspanningsverplichting bij onvolledige verwijzing concreet (onderzoek-proces §2.5: "aantoonbaar in het dossier").
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `id` | uuid | ja | |
| `screening_id` | uuid → SCREENING | ja | |
| `type_id` | ref → `screening_activiteit_type` | ja | |
| `uitgevoerd_op` | timestamp | ja | |
| `uitgevoerd_door` | uuid → MEDEWERKER | ja | feitzin S2; beroep/rol-detail → rollenronde |
| `toelichting` | text | nee | vrije tekst (embedbaar conform §3.2 discovery: structuur + tekst in één record) |
| `crisis_signaal` | boolean | ja (default nee) | S6; `true` triggert direct TIP-event, zie §6 |
**Uniciteit:** geen natuurlijke sleutel naast `id`; meerdere activiteiten van hetzelfde type per dag zijn legitiem (twee telefoontjes).
### 2.3 SCREENING_BESLUIT
**Doel:** het inhoudelijke triage-advies dat de screening afsluit: geschiktheid, geadviseerde plek en urgentie. Dit is het *advies*-feit; het *formele* besluit blijft de uitkomst op AANMELDING (§0).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `id` | uuid | ja | |
| `screening_id` | uuid → SCREENING | ja | |
| `uitkomst_id` | ref → `screening_uitkomst` | ja | vervangt prototype-veld `geschikt`/`niet_geschikt` |
| `geadviseerde_afdeling_id` | ref → `afdeling` | voorwaardelijk | verplicht als de uitkomstwaarde `vereist_afdeling = ja` heeft (waardelijst-attribuut, §4); geen vrije string meer (prototype-gebrek) |
| `geadviseerd_zorgprogramma_id` | ref → `zorgprogramma` | nee | afdeling ≠ zorgprogramma (discovery-besluit §5.2 #2) |
| `urgentie_id` | ref → `urgentie` | ja | definitieve urgentie; voedt straks `WACHTLIJSTPLAATSING.prioriteit` (aanmeld) en de intakeplanning |
| `genomen_op` | date | ja | |
| `genomen_door` | uuid → MEDEWERKER | ja | wie dit mág → rollenronde |
| `motivatie` | text | nee | verplicht maken bij `niet_geschikt`/`doorverwijzing_elders` is een kandidaat-protocolregel (nudge), geen schema-eis |
**Uniciteit:** max **één besluit per screening** (unique op `screening_id` where `deleted_at is null`). Correctie = soft delete + nieuw besluit (audit-hoofdstuk dekt de herleidbaarheid); geen stille updates op een genomen besluit.
### 2.4 INFORMATIE_UITVRAAG (nieuw)
**Doel:** vastleggen wat de instelling tijdens de triage aan aanvullende informatie heeft uitgevraagd, bij wie, en of het ontvangen is. Rechtstreekse eis uit de verwijsafspraken: bij onvolledige verwijzing geldt een **inspanningsverplichting die aantoonbaar moet zijn in het dossier** (onderzoek-proces §2.5, §10.1 stap 4). Ook de basis voor nudges ("uitvraag staat 14 dagen open").
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `id` | uuid | ja | |
| `screening_id` | uuid → SCREENING | ja | zie open punt §7.6 voor generiek gebruik buiten de screening |
| `type_id` | ref → `informatie_uitvraag_type` | ja | |
| `gericht_aan_verwijzer_id` | uuid → VERWIJZER | nee | gevuld als de uitvraag bij de verwijzer ligt |
| `gericht_aan_omschrijving` | text | nee | vrij veld voor andere partijen (cliënt, vorige zorgaanbieder, gemeente); verplicht als `gericht_aan_verwijzer_id` leeg is |
| `uitgevraagd_op` | date | ja | |
| `uitgevraagd_door` | uuid → MEDEWERKER | ja | |
| `status` | ref → `informatie_uitvraag_status` | ja | zie §5 |
| `ontvangen_op` | date | nee | verplicht bij status `ontvangen` |
| `ontvangen_document_id` | uuid → DOCUMENT | nee | koppeling naar het ontvangen stuk (zelfde documentmechanisme als verwijsdocument, discovery §5.1 #7) |
| `toelichting` | text | nee | |
**Uniciteit:** geen; meerdere uitvragen van hetzelfde type mogen (herinnering = nieuwe uitvraag of statusloos herinner-event — keuze bij de bouw).
---
## 3. Relaties met cardinaliteit
| Relatie | Cardinaliteit | Toelichting |
|---|---|---|
| AANMELDING — SCREENING | 1 : 0..n | max één `lopend` per aanmelding (§2.1); heropening = nieuwe screening |
| SCREENING — SCREENING_ACTIVITEIT | 1 : 0..n | |
| SCREENING — SCREENING_BESLUIT | 1 : 0..1 | besluit sluit de screening inhoudelijk af |
| SCREENING — INFORMATIE_UITVRAAG | 1 : 0..n | |
| SCREENING_BESLUIT — `afdeling` (waardelijst) | n : 0..1 | geadviseerde afdeling |
| SCREENING_BESLUIT — `zorgprogramma` (waardelijst) | n : 0..1 | geadviseerd programma |
| SCREENING / SCREENING_BESLUIT — `urgentie` (waardelijst) | n : 0..1 resp. n : 1 | tussentijds resp. definitief |
| SCREENING_ACTIVITEIT — MEDEWERKER | n : 1 | uitvoerder; MEDEWERKER wordt in de rollenronde uitgewerkt (rol op PERSOON, conform discovery §5.1 #1) |
| SCREENING — MEDEWERKER (screener) | n : 0..1 | |
| SCREENING_BESLUIT — MEDEWERKER (genomen_door) | n : 1 | |
| INFORMATIE_UITVRAAG — VERWIJZER | n : 0..1 | uitvraag bij de verwijzer (instroom-deelgebied) |
| INFORMATIE_UITVRAAG — DOCUMENT | n : 0..1 | ontvangen stuk |
| AANMELDING(uitkomst) — SCREENING_BESLUIT | 0..1 : 0..1 | **verwijzing als onderbouwing** (S9): op het aanmelding-uitkomstfeit een optionele `screening_besluit_id`. Eigenaar van dit veld is het instroom-deelgebied; hier alleen de relatie benoemd |
| SCREENING_BESLUIT ⇒ WACHTLIJSTPLAATSING | afleiding, geen FK | urgentie van het besluit is de voorgestelde prioriteit bij een aanmeld-wachtlijstplaatsing (discovery §5.3); overname is een handeling, geen automatisme |
| SCREENING ⇒ INTAKE | geen directe FK | screening vóór intake blijft een **nudge**, geen harde volgorde-eis (discovery-besluit §5.2 #4); de intake hangt aan de ZORGEPISODE, niet aan de screening |
---
## 4. Waardelijsten
Conform spelregel §3.1 #1 (één bron, referentietabellen) en de standaarden-les (onderzoek-standaarden §8): elke rij krijgt optioneel `externe_code` + `codesysteem_uri` en `geldig_van`/`geldig_tot`; waar zinvol een "overig/anders"-waarde met specificatie in het vrije-tekstveld.
### `screening_status`
| code | omschrijving |
|---|---|
| `lopend` | screening gestart, nog geen eindtoestand |
| `afgerond` | besluit genomen, screening klaar |
| `afgebroken` | gestopt zonder besluit |
### `screening_afbreekreden` (startwaarden)
`client_trekt_terug` · `aanmelding_ingetrokken` · `geen_contact_mogelijk` · `overleden` · `overig`
### `screening_activiteit_type` — met attribuut `is_clientcontact` (ja/nee)
Startlijst = discovery-besluit §5.2 #3, aangevuld vanuit de praktijk (onderzoek-proces §3: telefonische screening en generalistisch aanmeldgesprek):
| code | omschrijving | is_clientcontact |
|---|---|---|
| `telefonisch_contact` | telefonisch contact met cliënt of derden | ja |
| `aanmeldgesprek` | (generalistisch) aanmeld-/triagegesprek | ja |
| `dossieronderzoek` | beoordeling verwijsbrief/dossier | nee |
| `vragenlijst` | uitgezette/beoordeelde vragenlijst | nee |
| `mdo_bespreking` | bespreking in (aanmeld-)MDO | nee |
| `overig` | anders, zie toelichting | nee |
Het attribuut `is_clientcontact` volgt het `agb_verplicht`-patroon (discovery §5.1 #3): gedragsregels als data op de waardelijst, niet in applicatiecode. Nudge "nog geen contact geweest" telt activiteiten met `is_clientcontact = ja`.
### `screening_uitkomst` — met attribuut `vereist_afdeling` (ja/nee)
| code | omschrijving | vereist_afdeling |
|---|---|---|
| `geschikt` | geschikt voor intake bij deze instelling | ja |
| `niet_geschikt` | niet geschikt; terugverwijzing naar verwijzer/huisarts met advies (LKS §6.1) | nee |
| `doorverwijzing_elders` | beter passende aanbieder; doorverwijzen | nee |
Bewust **géén** waarde `wachtlijst`: wachtlijst is geen triage-oordeel maar een capaciteitsuitkomst op de AANMELDING (§0). Bevestigen → §7.2.
### `urgentie` — met attributen `volgorde` (int) en `reactietermijn_dagen` (int, optioneel, instellingsconfiguratie)
| code | omschrijving |
|---|---|
| `crisis` | acute keten; buiten reguliere flow (GMAP-triagewijzer kent eigen urgentiegraden — aparte module, §7.7) |
| `spoed` | versneld beoordelen/plaatsen |
| `regulier` | normale flow |
Sluit aan op het roadmap-idee prioriteit `spoed`/`normaal`/`laag` (discovery §5.3); de wachtlijst-prioriteitslijst kan dezelfde referentietabel gebruiken of ernaar mappen — afstemmen met de wachtlijst-modelleur.
### `informatie_uitvraag_type` (startwaarden)
`verwijsinformatie_aanvullen` · `medicatieoverzicht` · `medische_voorgeschiedenis` · `eerdere_behandelverslagen` · `vragenlijst_client` · `beschikking_gemeente` · `overig`
### `informatie_uitvraag_status`
`uitstaand` · `ontvangen` · `niet_ontvangen` (opgegeven na inspanning — het registreren hiervan ís de aantoonbare inspanning) · `vervallen` (niet meer nodig)
---
## 5. Statusmachine
### SCREENING
| Van | Naar | Voorwaarde |
|---|---|---|
| — | `lopend` | aanmaken; aanmelding bestaat en heeft geen andere lopende screening |
| `lopend` | `afgerond` | er bestaat een SCREENING_BESLUIT voor deze screening (database-constraint, spelregel §3.1 #7); `afgerond_op` gevuld |
| `lopend` | `afgebroken` | `afbreekreden` + `afgerond_op` gevuld |
| `afgerond`/`afgebroken` | — | eindtoestanden; heropening = nieuwe SCREENING (§2.1) |
**Wie mag zetten: → rollenronde** (expliciet open, conform discovery §5.1 #6). Werkhypothese voor die ronde: activiteiten en uitvragen registreren mag elke betrokken zorgmedewerker; het besluit nemen en de screening afronden is voorbehouden aan een daartoe aangewezen rol (triagist/regiebehandelaar-indicerend).
### SCREENING_BESLUIT
Geen statusmachine: een besluit is een gebeurtenisfeit. Correctie = soft delete + nieuw besluit (append-vriendelijk, audit §3.1 #3).
### INFORMATIE_UITVRAAG
`uitstaand` → `ontvangen` | `niet_ontvangen` | `vervallen`. Eindtoestanden; nieuwe behoefte = nieuwe uitvraag. Wie mag zetten: → rollenronde.
---
## 6. ECD/TIP-eigenaarschap en events richting TIP
**Eigenaarschap:** alle vier entiteiten zijn **klinische feiten, leidend in het ECD** (grensvlak §3.3). De *procesbewaking* — termijnen, volgordebewaking, prioriteitsstelling van werk — is TIP-terrein en wordt gevoed door onderstaande events. TIP maakt per intentie/nudge zijn eigen doelgebonden snapshot (afstemming Joshua §3.3); mutatie-doorval loopt via de standaard mutatie-events + content-hash.
| Event | Trigger | Payload-kern (nooit BSN, spelregel §3.1 #6) |
|---|---|---|
| `screening.gestart` | nieuwe SCREENING | screening_id, aanmelding_id, gestart_op |
| `screening.activiteit_geregistreerd` | nieuwe activiteit | activiteit_id, type, is_clientcontact, uitgevoerd_op |
| `screening.crisis_gesignaleerd` | activiteit met `crisis_signaal = true` óf urgentie op `crisis` | screening_id, bron (activiteit/urgentie), tijdstip — **hoogste prioriteit**, TIP escaleert richting acute keten |
| `screening.urgentie_gewijzigd` | (her)inschatting urgentie op SCREENING | oude/nieuwe urgentie, tijdstip |
| `screening.informatie_uitvraag_gestart` / `.afgesloten` | nieuwe uitvraag / eindstatus | uitvraag_id, type, status, uitgevraagd_op |
| `screening.besluit_genomen` | nieuw SCREENING_BESLUIT | besluit_id, uitkomst, afdeling, zorgprogramma, urgentie |
| `screening.afgerond` / `screening.afgebroken` | eindstatus SCREENING | screening_id, status, (afbreekreden) |
| `screening.record_gemuteerd` | correctie/soft delete op elk record | record_id, content_hash (koppelafspraak §3.3 #4) |
**Kandidaat-nudges (Protocol Rules Registry, ter illustratie — geen schema-eisen):**
- "Screening lopend, nog geen activiteit met cliëntcontact" (discovery-besluit §5.2 #3).
- "Informatie-uitvraag staat > N dagen op `uitstaand`" (inspanningsverplichting, onderzoek-proces §2.5).
- "Aanmelding nadert Treeknorm aanmeldwachttijd (4 weken) en screening is nog `lopend`" (onderzoek-proces §4.1).
- "Aanmelding-uitkomst wijkt af van screeningsadvies — motivatie vastleggen" (§0).
- "Screeningsbesluit `geschikt` maar nog geen intake of wachtlijstplaatsing na N dagen."
- "Crisissignaal afgegeven — acute-keten-route (GMAP) starten": severity `blokkade`-achtig qua urgentie, maar via TIP, niet via het schema.
---
## 7. Open besluitpunten voor Colin
1. **Besluit ≠ uitkomst bevestigen (kernkeuze §0).** Screeningsbesluit = inhoudelijk advies (eigen feit onder SCREENING); aanmelding-uitkomst = formeel besluit (blijft op AANMELDING), met optionele verwijzing `screening_besluit_id` als onderbouwing en een discrepantie-nudge. **Advies: akkoord** — gedragen door onderzoek-proces §10.3 (LKS kent geen normatieve screeningsfase) en het bestaan van uitkomsten (wachtlijst, aanmeldpauze) die geen triage-oordeel zijn.
2. **Startwaarden `screening_uitkomst`**: `geschikt` / `niet_geschikt` / `doorverwijzing_elders`, en bewust géén `wachtlijst`. **Advies: overnemen**; `niet_geschikt` impliceert terugverwijzing-met-advies (LKS §6.1) — als jullie "terugverwijzing" als aparte waarde naast "afwijzen" willen, splitsen we hem.
3. **Urgentie op twee plekken**: tussentijdse inschatting op SCREENING (muteerbaar, ge-audit) én definitieve urgentie verplicht op het BESLUIT. **Advies: beide** — de praktijk bepaalt urgentie vaak al vóór het besluit (onderzoek-proces §3/§10.3) en de wachtlijstprioriteit heeft een definitieve waarde nodig. Alternatief (alleen op besluit) is simpeler maar verliest de vroege crisis-/spoedsignalering.
4. **Startwaarden `urgentie`**: `crisis` / `spoed` / `regulier`, met `reactietermijn_dagen` als instellingsconfiguratie. **Advies: zo starten**; afstemmen met de wachtlijst-ronde of prioriteit dezelfde lijst hergebruikt (mijn voorkeur) of een eigen lijst met mapping krijgt.
5. **Heropening = nieuwe SCREENING** (max één lopende per aanmelding; afgeronde blijven staan). **Advies: akkoord** — past bij append-only/historiebehoud en bij discovery §5.1 #5 (besloten aanmelding kan terug naar "in screening") zonder status-terugdraai op een afgeronde screening.
6. **INFORMATIE_UITVRAAG: nu alleen onder SCREENING, of direct generiek?** Ook de intake vraagt aanvullende informatie op (onderzoek-proces §3 stap 4). **Advies: nu onder SCREENING houden** en in de intake-ronde besluiten of hij generiek wordt (bijv. polymorf aan aanmelding/episode); voortijdig generaliseren maakt het eigenaarschap vaag.
7. **Crisissignalering als vlag + TIP-event, geen eigen entiteit.** De acute keten (GMAP-triagewijzer met urgentiegraden en beoordelingstijden) is een eigen module/route buiten deze ronde. **Advies: akkoord**; als crisisscreening een echt werkproces wordt, verdient dat een eigen deelgebied.
8. **Startlijst `screening_activiteit_type` bevestigen**, incl. de toevoegingen `aanmeldgesprek` en `mdo_bespreking` en het attribuut `is_clientcontact`. **Advies: overnemen** — dekt de discovery-startlijst plus de praktijk (generalistisch aanmeldgesprek, aanmeld-MDO).
9. **Wie screent / wie besluit → rollenronde** (bevestiging dat dit daar landt, conform discovery §5.1 #6). Werkhypothese in §5 meenemen als input voor die ronde.
---
## 8. Bronverwijzingen
| Onderwerp | Bron |
|---|---|
| Uitgangspunten, spelregels, TIP-grensvlak | `datamodel-discovery.md` §3.1, §3.2, §3.3 |
| Bestaande besluiten screening (activiteittypen, afdeling/zorgprogramma, screening-als-nudge) | discovery §5.2 besluiten 1–4; §5.1 #5 (aanmelding-status), #9 (zorgepisode) |
| Open vraag besluit ↔ uitkomst | discovery §5.2 "Open vragen"; `onderzoek-proces.md` §10.3 (LKS kent geen aparte screeningsfase) |
| Triagepraktijk (telefonische screening, aanmeldgesprek, uitkomsten, urgentie vóór wachtlijst) | `onderzoek-proces.md` §3, §10.1 stap 5 |
| Inspanningsverplichting onvolledige verwijzing (basis INFORMATIE_UITVRAAG) | `onderzoek-proces.md` §2.5, §10.1 stap 4; Verwijsafspraken GGZ (VWS, dec 2024) |
| Treeknormen / aanmeldwachttijd (nudge-context) | `onderzoek-proces.md` §4.1 |
| Acute ggz / GMAP-triagewijzer (crisisroute) | `onderzoek-proces.md` §3; Generieke Module Acute Psychiatrie |
| Waardelijst-patronen (externe code, geldigheidsperioden, "anders"-optie) | `../onderzoek/onderzoek-standaarden.md` §8; `../onderzoek/onderzoek-leveranciers.md` §7.1 (Nedap: waardelijsten met begindatum/einddatum) |
| Instellingsconfigureerbare triage-/wachtwaardelijsten | `../onderzoek/onderzoek-leveranciers.md` §2.7 ("possible values are defined by the care organisation") |
| Prototype-gebreken (afdeling als vrije string, activiteiten zonder type) | discovery §5.2 "Bevindingen prototype" |

239
docs/datamodel/deelmodellen/model-wachtlijst.md Normal file
View File

@@ -0,0 +1,239 @@
# Datamodelvoorstel — Wachtlijstplaatsing
**Status:** voorlopig onderzoeksmodel — niet bouwrijp; zie `../besluiten/besluitenlog-datamodel-2026-07-18.md` §4
**Datum:** 18 juli 2026
**Bouwt voort op:** `datamodel-discovery.md` §5.3 (besluit sessie 17 juli: WACHTLIJSTPLAATSING als eigen entiteit, twee momenten aanmeld/behandel), §5.1 #9 (ZORGEPISODE), §5.1 #5 (aanmelding-uitkomst `wachtlijst`), spelregels §3.1
**Onderzoeksinput:** onderzoek-proces §4 (Treeknormen, NZa Transparantieregeling, praktijkfenomenen), onderzoek-leveranciers §2.7 (Nedap-wachtlijst), onderzoek-standaarden §8 (waardelijst-patroon met geldigheidsperioden)
> **Let op:** alleen de volledige, append-only tijdlijn en het zichtbaar houden van bruto wachttijd zijn als uitgangspunt bekrachtigd. Cardinaliteiten, dragers, teldatums, aftrekregels, redenlijsten en concrete NZa-/Treeknormberekeningen vragen nader GGZ-onderzoek. De voorstellen hieronder zijn op die punten niet definitief.
---
## 1. Feitzinnen
Genummerd; **(≈ §5.3 #n)** = herkomst uit de discovery-startlijst, **(nieuw)** = toegevoegd in deze ronde.
1. *De aanmelding van Jan de Vries is op 18 juli 2026 op de wachtlijst geplaatst met soort "aanmeld", voor afdeling Volwassenen.* (≈ §5.3 #1, gewijzigd: soort expliciet erbij)
2. *De wachtlijstplaatsing van 18 juli is gericht op zorgprogramma "Trauma".* (nieuw, optioneel feit)
3. *De wachtlijstplaatsing van 18 juli heeft prioriteit "normaal".* (= §5.3 #2)
4. *De wachttijd van de aanmeldplaatsing telt vanaf de aanmelddatum 14 juli 2026.* (= §5.3 #3, verduidelijkt: de teldatum is een eigen attribuut, standaard afgeleid van de aanmelddatum)
5. *De wachtlijstplaatsing van 18 juli is op 20 augustus 2026 beëindigd met reden "intake gestart".* (= §5.3 #4)
6. *Voor de zorgepisode van Jan de Vries is op 1 augustus 2026 een wachtlijstplaatsing van soort "behandel" aangemaakt voor afdeling Volwassenen; de wachttijd telt vanaf de datum van het eerste intakegesprek, 22 juli 2026.* (nieuw — de behandelwachttijd uit het §5.3-besluit als eigen feit)
7. *De behandelplaatsing van 1 augustus is op 15 oktober 2026 beëindigd met reden "behandeling gestart".* (nieuw)
8. *Bij de wachtlijstplaatsing is op 12 augustus 2026 een activiteit van type "cliënt geïnformeerd over Treeknorm-overschrijding" geregistreerd door medewerker K. Jansen, met toelichting "gewezen op zorgbemiddeling Zilveren Kruis".* (nieuw — LKS-plicht: cliënt informeren bij overschrijding en wijzen op zorgbemiddeling verzekeraar)
9. *Bij de wachtlijstplaatsing is op 20 augustus 2026 een activiteit van type "overbruggingszorg afgesproken" geregistreerd.* (nieuw — LKS: regiebehandelaar beoordeelt overbruggingszorg voor de wachtende cliënt)
10. *De wachtlijstplaatsing is van 1 t/m 14 september 2026 opgeschort met reden "op verzoek cliënt".* (nieuw — cliënt kiest zelf voor uitstel; apart geregistreerd zodat bruto- én netto-wachttijd berekenbaar blijven)
11. *De prioriteit van de wachtlijstplaatsing is op 5 augustus 2026 gewijzigd van "normaal" naar "spoed" na herbeoordeling.* (nieuw — mutatie, loopt via audit + activiteit "herbeoordeling prioriteit")
12. *(nudge) Bij (dreigende) overschrijding van de Treeknorm van de plaatsingssoort volgt een signaal.* (= §5.3 #5, gegeneraliseerd naar beide soorten: aanmeld 4 weken, behandel 10 weken)
13. *(afleiding) De aanmeldingswachttijd van de plaatsing bedraagt 5 weken (van teldatum tot beëindiging met reden "intake gestart", minus opschortingen indien netto gerekend).* (nieuw — geen opgeslagen feit maar een gedefinieerde afleiding, zie §6.1)
---
## 2. Entiteiten
### 2.1 WACHTLIJSTPLAATSING
**Doel:** vastleggen dat een cliënt op enig moment wacht — vóór de intake (aan de AANMELDING, aanmeldwachttijd) of na de intake wachtend op behandeling (aan de ZORGEPISODE, behandelwachttijd) — met de dimensies die de Treeknorm-bewaking en de NZa-wachttijdaanlevering nodig hebben.
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `id` | uuid | ja | stabiele identiteit (spelregel 3.1 #5) |
| `soort` | FK → waardelijst `wachtlijst_soort` | ja | `aanmeld` / `behandel` (besluit §5.3) |
| `aanmelding_id` | FK → AANMELDING | conditioneel | verplicht bij soort `aanmeld`, leeg bij `behandel` |
| `zorgepisode_id` | FK → ZORGEPISODE | conditioneel | verplicht bij soort `behandel`, leeg bij `aanmeld` |
| `afdeling_id` | FK → waardelijst AFDELING | ja | organisatorische eenheid waarvoor gewacht wordt (§5.2 besluit #2) |
| `zorgprogramma_id` | FK → waardelijst ZORGPROGRAMMA | nee | inhoudelijk aanbod waarvoor gewacht wordt; optioneel (zie §7 punt 1) |
| `prioriteit_id` | FK → waardelijst `wachtlijst_prioriteit` | ja | default `normaal` |
| `plaatsingsdatum` | date | ja | datum waarop de plaatsing is geregistreerd |
| `teldatum` | date | ja | datum waarop de wachttijd begint te tellen; default afgeleid (aanmeld → aanmelddatum AANMELDING; behandel → datum eerste intakegesprek van de episode), overschrijfbaar met auditspoor |
| `status` | FK → statusmachine (§5) | ja | `actief` / `opgeschort` / `beëindigd` |
| `einddatum` | date | conditioneel | verplicht bij status `beëindigd`, anders leeg |
| `beeindigingsreden_id` | FK → waardelijst `wachtlijst_beeindigingsreden` | conditioneel | verplicht bij status `beëindigd`, anders leeg |
| `toelichting` | text | nee | vrije tekst |
| `deleted_at` | timestamp | nee | soft delete (spelregel 3.1 #4) |
| audit-velden | — | ja | created_at/by, updated_at/by; mutaties append-only in audittrail (3.1 #3) |
**Uniciteitsregels:**
- Precies één van `aanmelding_id` / `zorgepisode_id` gevuld, consistent met `soort` (check-constraint — regel in het model, spelregel 3.1 #7).
- Maximaal één plaatsing met status ≠ `beëindigd` per (`aanmelding_id`, `soort`) resp. (`zorgepisode_id`, `soort`) — partial unique index. Historie (meerdere beëindigde plaatsingen na heropening) blijft mogelijk. Zie §7 punt 4 voor de vraag of parallel wachten op meerdere afdelingen ooit nodig wordt.
- `einddatum` ≥ `teldatum` (check-constraint).
### 2.2 WACHTLIJSTACTIVITEIT
**Doel:** gebeurtenissen tijdens het wachten vastleggen. Uit het procesonderzoek (§4.3–4.4): informeren van de cliënt bij Treeknorm-overschrijding, wijzen op zorgbemiddeling van de verzekeraar en overbruggingszorg-afspraken zijn LKS-plichten die aantoonbaar in het dossier horen. Zelfde patroon als SCREENINGSACTIVITEIT (discovery §5.2 besluit #3): type uit waardelijst + vrije toelichting, zodat nudges mogelijk zijn ("Treeknorm overschreden maar cliënt nog niet geïnformeerd").
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `id` | uuid | ja | |
| `wachtlijstplaatsing_id` | FK → WACHTLIJSTPLAATSING | ja | |
| `type_id` | FK → waardelijst `wachtlijst_activiteittype` | ja | |
| `datum` | date | ja | |
| `uitgevoerd_door` | FK → MEDEWERKER | ja | rollenronde bepaalt wie welk type mag registreren |
| `toelichting` | text | nee | |
| `deleted_at` / audit-velden | — | — | conform spelregels |
**Uniciteit:** geen natuurlijke uniciteit buiten `id`; hetzelfde activiteitstype mag vaker voorkomen (cliënt kan meermaals geïnformeerd worden).
### 2.3 WACHTLIJSTOPSCHORTING
**Doel:** perioden vastleggen waarin het wachten niet aan de aanbieder ligt (cliënt kiest bewust een latere datum, is tijdelijk niet beschikbaar). Door opschortingen apart te registreren blijven zowel bruto-wachttijd (NZa-definitie rekent in kale weken) als netto-wachttijd (interne sturing) afleidbaar — het model dwingt geen rekenkeuze af (zie §7 punt 5).
| Attribuut | Type | Verplicht | Toelichting |
|---|---|---|---|
| `id` | uuid | ja | |
| `wachtlijstplaatsing_id` | FK → WACHTLIJSTPLAATSING | ja | |
| `begindatum` | date | ja | |
| `einddatum` | date | nee | leeg zolang de opschorting loopt |
| `reden_id` | FK → waardelijst `wachtlijst_opschortingsreden` | ja | |
| `toelichting` | text | nee | |
| `deleted_at` / audit-velden | — | — | |
**Uniciteitsregels:** opschortingen van dezelfde plaatsing mogen niet overlappen (exclusion-constraint op de periode); maximaal één opschorting zonder `einddatum` per plaatsing.
---
## 3. Relaties met cardinaliteit
| Relatie | Cardinaliteit | Toelichting |
|---|---|---|
| AANMELDING — WACHTLIJSTPLAATSING (soort `aanmeld`) | 1 — 0..n | historie mogelijk; max 1 niet-beëindigd (§2.1). Aanmeldwachttijd hangt aan de AANMELDING (besluit §5.3 + §5.1 #9) |
| ZORGEPISODE — WACHTLIJSTPLAATSING (soort `behandel`) | 1 — 0..n | idem; behandelwachttijd hangt aan de ZORGEPISODE. Episode ontstaat bij uitkomst `intake` (open detail §5.1 #9; het procesonderzoek §10.3 ondersteunt precies deze verdeling: aanmeldwachttijd op de aanmelding, episode pas bij intake) |
| WACHTLIJSTPLAATSING — AFDELING | n — 1 | verplichte dimensie |
| WACHTLIJSTPLAATSING — ZORGPROGRAMMA | n — 0..1 | optionele dimensie |
| WACHTLIJSTPLAATSING — WACHTLIJSTACTIVITEIT | 1 — 0..n | |
| WACHTLIJSTPLAATSING — WACHTLIJSTOPSCHORTING | 1 — 0..n | niet-overlappend |
| WACHTLIJSTACTIVITEIT — MEDEWERKER | n — 1 | entiteit MEDEWERKER volgt in de rollenronde; hier alleen de referentie |
| AFDELING — VESTIGING | n — 0..1 | **voorgesteld nieuw attribuut** op de waardelijst AFDELING t.b.v. de NZa-uitsplitsing per vestigingslocatie (§6.2); zie §7 punt 2 |
**Samenhang met de aanmelding-uitkomst `wachtlijst` (besluit §5.1 #5):** uitkomst `wachtlijst` en het bestaan van een actieve aanmeldplaatsing zijn twee feiten die bij elkaar horen maar niet hetzelfde zijn. Consistentie wordt een nudge ("uitkomst wachtlijst zonder actieve wachtlijstplaatsing"), geen schema-koppeling — zelfde patroon als verwijsbrief (§5.1 #7) en screening-vóór-intake (§5.2 #4). Omgekeerd bij de behandelkant: intake-uitkomst `in_zorg` zonder direct gestarte behandeling → nudge "behandelwachttijd nog niet geregistreerd".
---
## 4. Waardelijsten
Alle lijsten volgen de spelregels: referentietabel, één bron voor UI en database (3.1 #1), en per rij optioneel `externe_code`, `codesysteem_uri`, `geldig_van`, `geldig_tot` (les uit onderzoek-leveranciers §7.1 en onderzoek-standaarden §8: NZa-achtige lijsten hebben geldigheidsperioden).
### 4.1 `wachtlijst_soort`
| Code | Omschrijving | `drager` | `telt_vanaf` | `treeknorm_weken` |
|---|---|---|---|---|
| `aanmeld` | Aanmeldwachttijd | AANMELDING | aanmelddatum | 4 |
| `behandel` | Behandelwachttijd | ZORGEPISODE | datum eerste intakegesprek | 10 |
De Treeknorm zit als **attribuut op de waardelijst**, niet in code — de totaalnorm (14 weken) is afleidbaar. Bron: Treeknormen (onderzoek-proces §4.1); NZa-definities aanmeldings-/behandelingswachttijd (§4.2) vallen samen met deze twee soorten.
### 4.2 `wachtlijst_prioriteit`
Startwaarden: `spoed`, `normaal`, `laag` (conform het roadmap-idee uit discovery §5.3; praktijk kent urgentie-inschatting al bij screening — onderzoek-proces §3). Attribuut `sorteervolgorde` (int). Instellingsconfigureerbaar (Nedap-les, onderzoek-leveranciers §2.7: prioriteit/urgentie als configureerbare lijst).
### 4.3 `wachtlijst_beeindigingsreden`
Lost de tweede open vraag uit §5.3 op. Startlijst uit de praktijk (onderzoek-proces §4.4) plus attributen:
| Code | Omschrijving | `geldig_voor_soort` | `zorg_gestart` |
|---|---|---|---|
| `intake_gestart` | Intake gestart | aanmeld | ja |
| `behandeling_gestart` | Behandeling gestart | behandel | ja |
| `intern_doorgeplaatst` | Doorgeplaatst naar andere afdeling/programma (nieuwe plaatsing volgt) | beide | nee |
| `doorverwezen_extern` | Doorverwezen naar andere aanbieder | beide | nee |
| `bemiddeld_verzekeraar` | Via zorgbemiddeling verzekeraar elders geplaatst | beide | nee |
| `client_trekt_terug` | Cliënt trekt zich terug | beide | nee |
| `geen_contact` | Geen contact meer te krijgen met cliënt | beide | nee |
| `overleden` | Cliënt overleden | beide | nee |
| `administratief_vervallen` | Plaatsing onterecht/dubbel aangemaakt | beide | nee |
| `overig` | Anders, zie toelichting | beide | nee |
- `geldig_voor_soort` (aanmeld/behandel/beide) voorkomt betekenisloze combinaties ("behandeling gestart" op een aanmeldplaatsing) als datagedreven regel, niet hardcoded.
- `zorg_gestart` (ja/nee) markeert de redenen die meetellen in de retrospectieve NZa-wachttijdberekening (gerealiseerde wachttijd van cliënten die daadwerkelijk zijn ingestroomd, §6.1).
- Patroon "overig + verplichte toelichting" volgt het zib-ontwerppatroon "anders-optie met specificatieveld" (onderzoek-standaarden §2.2).
### 4.4 `wachtlijst_activiteittype`
Startwaarden: `client_geinformeerd_treeknorm` (LKS-plicht), `gewezen_op_zorgbemiddeling` (LKS-plicht), `overbruggingszorg_afgesproken` (LKS: regiebehandelaar beoordeelt overbruggingszorg), `contactmoment` (tussentijds contact met wachtende), `herbeoordeling_prioriteit`, `overig`.
### 4.5 `wachtlijst_opschortingsreden`
Startwaarden: `verzoek_client` (cliënt kiest latere datum), `client_niet_beschikbaar` (vakantie, detentie, opname elders), `overig`.
---
## 5. Statusmachine WACHTLIJSTPLAATSING
Conform spelregel 3.1 #9: statussen en overgangen als data (referentietabel `wachtlijst_status` + overgangstabel), niet in schermcode.
| Van | Naar | Trigger/betekenis |
|---|---|---|
| — | `actief` | plaatsing aangemaakt (begintoestand) |
| `actief` | `opgeschort` | WACHTLIJSTOPSCHORTING zonder einddatum geopend |
| `opgeschort` | `actief` | lopende opschorting krijgt einddatum |
| `actief` | `beëindigd` | einddatum + beëindigingsreden gezet |
| `opgeschort` | `beëindigd` | idem; lopende opschorting wordt daarbij afgesloten |
| `beëindigd` | `actief` | heropening (correctie of cliënt meldt zich terug); consistent met de flexibele-statusfilosofie van §5.1 #5. Heropening wist einddatum/reden en logt append-only |
De status `opgeschort` is afleidbaar uit een open WACHTLIJSTOPSCHORTING; hij staat toch expliciet op de plaatsing zodat lijstweergaven en nudges niet hoeven te joinen en de statusmachine compleet is. Consistentie (status ↔ open opschorting) is een check-constraint/trigger.
**Wie mag welke overgang zetten: expliciet doorgeschoven naar de rollenronde** (zelfde lijn als discovery §5.1 #6). Kandidaat om daar te bespreken: beëindigen met reden `overleden` en heropenen als beperkte acties.
Prioriteitswijziging (feitzin 11) is géén statusovergang: het is een attribuutmutatie met auditspoor plus optioneel een activiteit `herbeoordeling_prioriteit`.
---
## 6. Treeknormen, NZa-aanlevering en ECD/TIP-eigenaarschap
### 6.1 Afleidbaarheid van de wachttijden (geen opgeslagen velden)
De verplichte cijfers zijn **afleidingen** uit het model, geen extra administratie:
- **Wachttijd per plaatsing (bruto)** = weken tussen `teldatum` en `einddatum` (lopend: peildatum). Dit volgt de NZa-definities: aanmeldingswachttijd = weken tussen eerste afspraak/aanmelding en het moment dat de cliënt terecht kan voor intake; behandelingswachttijd = weken tussen eerste intake en start behandeling (onderzoek-proces §4.2).
- **Netto-variant** = bruto minus de som van WACHTLIJSTOPSCHORTING-perioden (voor interne sturing; zie §7 punt 5).
- **Retrospectieve NZa-aanlevering** (berekeningswijze 1): gemiddelde bruto-wachttijd van plaatsingen die in de laatste twee maanden zijn beëindigd met een reden waar `zorg_gestart = ja`, uitgesplitst per **vestigingslocatie** (via AFDELING → VESTIGING) en per **hoofddiagnosegroep** (alleen g-ggz; via de hoofddiagnose van de gestarte ZORGEPISODE — voor aanmeldplaatsingen de episode die uit de aanmelding is voortgekomen). Maandelijks, uiterlijk de 10e, via het NZa Zorgbeeldportaal; eenlocatie-aanbieders zijn per 2026 vrijgesteld (afleiding uit declaratiedata).
- **Actuele berekeningswijze** (berekeningswijze 2: "derde beschikbare mogelijkheid in de agenda") komt niet uit de wachtlijst maar uit de agenda — agenda-ronde. Het model hoeft die keuze niet af te dwingen; de aanbieder kiest de methode.
- **Treeknorm-bewaking**: (peildatum − `teldatum`) > `treeknorm_weken` van de soort ⇒ overschrijding. Nudges: `signaal` bij dreigende overschrijding (bijv. 75% van de norm), `waarschuwing` bij overschrijding zonder activiteit `client_geinformeerd_treeknorm` (LKS-plicht), `signaal` voor overbruggingszorg-beoordeling bij lopende behandelplaatsing (regiebehandelaar eerstverantwoordelijk).
Benodigde dimensies die (nog) buiten dit deelgebied liggen: **vestiging** (§7 punt 2), **echelon gb-ggz/g-ggz** op de aanmelding (§7 punt 6; hoofddiagnosegroep-uitsplitsing geldt alleen g-ggz) en **zorgverzekeraar** (alleen bij omzetplafond-afhankelijke wachttijden; declaratie-ronde, §7 punt 7).
### 6.2 Eigenaarschap en events richting TIP (conform §3.3)
**Eigenaarschap: WACHTLIJSTPLAATSING, -ACTIVITEIT en -OPSCHORTING zijn leidend in het ECD.** Het zijn dossier-/registratiefeiten met wettelijke bewijsfunctie (LKS: aantoonbaar informeren; NZa: bron van de aanlevering). TIP houdt er geen kopie-administratie op na buiten de afgesproken snapshot-/IE-mechanismen (afstemming Joshua, §3.3).
**Events ECD → TIP** (zelfde mutatie-eventmechanisme als her-embedding, §3.2/§3.3 punt 4):
| Event | Payload (minimaal) | TIP-gebruik |
|---|---|---|
| `wachtlijstplaatsing.aangemaakt` | plaatsing-id, soort, drager-id, afdeling, zorgprogramma, prioriteit, teldatum | start Treeknorm-bewaking (timer/nudgeplanning) |
| `wachtlijstplaatsing.prioriteit_gewijzigd` | plaatsing-id, oud/nieuw | herprioritering werkvoorraad |
| `wachtlijstplaatsing.opgeschort` / `.hervat` | plaatsing-id, periode, reden | Treeknorm-timer pauzeren/hervatten (indien netto-bewaking gekozen) |
| `wachtlijstplaatsing.beeindigd` | plaatsing-id, einddatum, reden, zorg_gestart | bewaking stoppen; instroom-funnel-statistiek |
| `wachtlijstactiviteit.geregistreerd` | activiteit-id, plaatsing-id, type, datum | plicht-nudges afvinken (cliënt geïnformeerd, overbrugging geregeld) |
**Proces-state die bij TIP hoort, niet in het ECD:** de Treeknorm-timers zelf, de taak "NZa-aanlevering klaarzetten vóór de 10e" en de opvolging van nudges. Het ECD levert de feiten; TIP de bewaking en beslislogica. De maandelijkse aanleverset zelf is een afgeleide rapportage (view/export) uit het ECD — als het verzendmoment vastgelegd moet worden, is dat een auditfeit, geen nieuwe entiteit.
---
## 7. Open besluitpunten voor Colin
1. **Afdeling verplicht, zorgprogramma optioneel — bevestigen.** Advies: zo doen. De afdeling is de organisatorische eenheid waar capaciteit en wachtlijstbeheer leven (discovery §5.2 besluit #2); het zorgprogramma is een verfijning die niet altijd bekend is bij plaatsing. "Beide" als twee optionele velden zonder verplichting zou de NZa-afleiding en de nudges hun ankerdimensie ontnemen. Wat kan misgaan: instellingen die puur programma-gericht werken moeten dan een (rest)afdeling kiezen — acceptabel, afdelingen zijn per instelling configureerbaar.
2. **VESTIGING als waardelijst + optionele koppeling AFDELING → VESTIGING nu al opnemen?** De NZa-aanlevering splitst per vestigingslocatie (clustering binnen gemeente/10 km toegestaan). Advies: waardelijst VESTIGING nu aanmaken met optionele FK op AFDELING; verplicht maken zodra de aanleverexport gebouwd wordt. Alternatief (vestiging pas in de ADM-ronde) maakt de aanlevering tijdelijk niet afleidbaar.
3. **Startlijst beëindigingsredenen (§4.3) bevestigen**, inclusief de attributen `geldig_voor_soort` en `zorg_gestart`. Advies: overnemen; de lijst komt rechtstreeks uit praktijk + LKS/NZa (onderzoek-proces §4.4) en is instellingsuitbreidbaar (Nedap-les: configureerbare `closingReason`).
4. **Max één niet-beëindigde plaatsing per drager per soort: harde constraint of aan/uit-bedrijfsregel?** Advies: harde partial-unique constraint (spelregel 3.1 #7). Parallel wachten op twee afdelingen tegelijk is in de praktijk een keuze-/bemiddelingsvraagstuk, geen registratiefeit; mocht het ooit nodig zijn, dan is de constraint versoepelen goedkoper dan dubbelingen opruimen. (Bewust strakker dan het parallelle-aanmeldingen-patroon §5.0 #5 — dáár ging het om meerdere zorgvragen, hier om dezelfde wachtvraag.)
5. **Pauzeert een opschorting de Treeknorm-telling (netto) of niet (bruto)?** De NZa-definitie rekent in kale weken en kent geen expliciete pauzeregeling; het model registreert opschortingen apart zodat beide berekeningen mogelijk blijven. Advies: extern (NZa-aanlevering) bruto rapporteren, intern (nudges/sturing) netto bewaken — en dit als instellingsinstelling op de nudge-regel zetten, niet in het schema.
6. **Echelon (gb-ggz/g-ggz) op de AANMELDING toevoegen** (verrijking uit onderzoek-proces §10.3 punt 3). Nodig omdat de hoofddiagnosegroep-uitsplitsing van de wachttijden alleen voor g-ggz geldt en het echelon op de verwijsbrief hoort te staan. Advies: overnemen in het instroom-deelgebied (hoort daar, niet bij de wachtlijst); hier alleen gesignaleerd als afhankelijkheid.
7. **Zorgverzekeraar-dimensie** (alleen aanleveren als de wachttijd per verzekeraar verschilt, omzetplafonds). Advies: parkeren tot de declaratie-/financieringsronde; het model blokkeert niets omdat de verzekeraar t.z.t. via de financieringskant van de aanmelding afleidbaar wordt.
8. **Aanmeldpauze/patiëntenstop** (praktijkfenomeen, instellings-/afdelingsniveau — onderzoek-proces §4.4). Geen cliëntgebonden feit maar capaciteitsconfiguratie. Advies: niet in dit deelgebied; kandidaat voor de ADM-/capaciteitsronde, eventueel als periode-attribuut op AFDELING.
9. **Urgentie al bij de screening vastleggen** (vóór er een wachtlijstplaatsing is — onderzoek-proces §3/§10.3). Advies: screeningsbesluit uitbreiden met een optionele geadviseerde prioriteit uit dezelfde waardelijst `wachtlijst_prioriteit` (hergebruik, geen tweede lijst); besluit hoort formeel bij het screening-deelgebied.
---
## 8. Bronverwijzingen
| Onderwerp | Bron |
|---|---|
| Besluit WACHTLIJSTPLAATSING eigen entiteit, twee momenten, soort-waardelijst; open vragen | `datamodel-discovery.md` §5.3; drager-besluiten §5.1 #9 (ZORGEPISODE), §5.1 #5 (uitkomst `wachtlijst`) |
| Spelregels (waardelijsten, statusmachines, constraints, soft delete, audit) | `datamodel-discovery.md` §3.1 #1, #3, #4, #7, #9 |
| TIP-grensvlak en eventmechanisme | `datamodel-discovery.md` §3.3 |
| Treeknormen 4/10/14 weken; NZa-definities aanmeldings-/behandelingswachttijd; Transparantieregeling (uitsplitsing vestiging × hoofddiagnosegroep × evt. verzekeraar; maandelijks ≤ 10e; Zorgbeeldportaal; 2026: eenlocatie via declaratiedata); LKS-plichten (informeren, zorgbemiddeling, overbruggingszorg); beëindigingsredenen uit de praktijk | `onderzoek-proces.md` §4.1–4.4, §10.1 (rij 6 en 11), §10.3 |
| Verwijsdatum op declaratie 2026 (IZA-wachttijdinzicht, verklaart automatische afleiding eenlocatie) | `onderzoek-proces.md` §2.10 |
| Nedap-wachtlijst als "tijdelijke oplossing"; configureerbare waardelijsten voor prioriteit/wachtreden/beëindigingsreden | `../onderzoek/onderzoek-leveranciers.md` §2.7, §7.4 |
| Waardelijst-patroon: externe code + codesysteem + geldigheidsperiode; "anders"-optie met specificatieveld | `../onderzoek/onderzoek-standaarden.md` §2.2 (BehandelAanwijzing2-patroon), §8; `../onderzoek/onderzoek-leveranciers.md` §7.1 |
| Episode-ontstaan bij intake ondersteunt aanmeldwachttijd-op-aanmelding | `onderzoek-proces.md` §10.3 (open-vragensectie) |
| Standaarden extern: NZa Transparantieregeling (NR/REG-2024 e.v.), LKS GGZ 4.0, Treeknormen (veldnorm) | via bronnenlijsten van de onderzoeksrapporten |

818
docs/datamodel/entiteitenkaarten/ehr-referral-terminology.html Normal file
View File

@@ -0,0 +1,818 @@
<!doctype html>
<html lang="nl">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="color-scheme" content="light dark">
<title>Engelstalige EHR-termen voor GGZ-instroom</title>
<style>
:root {
--bg: #f5f7f6;
--surface: #ffffff;
--surface-subtle: #edf3f1;
--text: #172420;
--muted: #5b6d68;
--line: #dce3e0;
--accent: #0f766e;
--accent-strong: #0b5c56;
--accent-soft: #e1f0ee;
--success: #166534;
--success-soft: #e7f6eb;
--warning: #9a4d08;
--warning-soft: #fceedc;
--danger: #a12c2c;
--danger-soft: #fce8e8;
--code-bg: #e9efed;
}
@media (prefers-color-scheme: dark) {
:root {
--bg: #0d1512;
--surface: #12201c;
--surface-subtle: #172923;
--text: #e6eeeb;
--muted: #96a9a4;
--line: #2a3b36;
--accent: #35d6c4;
--accent-strong: #6ee7d9;
--accent-soft: #163430;
--success: #72d58a;
--success-soft: #173322;
--warning: #f0a94e;
--warning-soft: #2a1f10;
--danger: #f18a8a;
--danger-soft: #341a1a;
--code-bg: #1c2d28;
}
}
:root[data-theme="light"] {
--bg: #f5f7f6;
--surface: #ffffff;
--surface-subtle: #edf3f1;
--text: #172420;
--muted: #5b6d68;
--line: #dce3e0;
--accent: #0f766e;
--accent-strong: #0b5c56;
--accent-soft: #e1f0ee;
--success: #166534;
--success-soft: #e7f6eb;
--warning: #9a4d08;
--warning-soft: #fceedc;
--danger: #a12c2c;
--danger-soft: #fce8e8;
--code-bg: #e9efed;
}
:root[data-theme="dark"] {
--bg: #0d1512;
--surface: #12201c;
--surface-subtle: #172923;
--text: #e6eeeb;
--muted: #96a9a4;
--line: #2a3b36;
--accent: #35d6c4;
--accent-strong: #6ee7d9;
--accent-soft: #163430;
--success: #72d58a;
--success-soft: #173322;
--warning: #f0a94e;
--warning-soft: #2a1f10;
--danger: #f18a8a;
--danger-soft: #341a1a;
--code-bg: #1c2d28;
}
* {
box-sizing: border-box;
}
html {
background: var(--bg);
color: var(--text);
scroll-behavior: smooth;
}
body {
margin: 0;
background: var(--bg);
color: var(--text);
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
line-height: 1.55;
}
a {
color: var(--accent-strong);
text-underline-offset: 0.2em;
}
a:hover {
text-decoration-thickness: 2px;
}
code {
padding: 0.12em 0.38em;
border-radius: 5px;
background: var(--code-bg);
color: var(--accent-strong);
font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
font-size: 0.9em;
}
.page {
width: min(1180px, calc(100% - 2rem));
margin: 0 auto;
padding: 2rem 0 5rem;
}
.toolbar {
display: flex;
justify-content: space-between;
align-items: center;
gap: 1rem;
margin-bottom: 3rem;
color: var(--muted);
font-size: 0.82rem;
}
.toolbar-actions {
display: flex;
align-items: center;
gap: 0.75rem;
}
.button {
appearance: none;
border: 1px solid var(--line);
border-radius: 7px;
background: var(--surface);
color: var(--text);
padding: 0.45rem 0.75rem;
font: inherit;
cursor: pointer;
}
.button:hover {
border-color: var(--accent);
}
header {
margin-bottom: 2rem;
}
.eyebrow {
margin: 0 0 0.65rem;
color: var(--accent-strong);
font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
font-size: 0.72rem;
font-weight: 700;
letter-spacing: 0.08em;
text-transform: uppercase;
}
h1,
h2,
h3 {
color: var(--text);
line-height: 1.2;
text-wrap: balance;
}
h1 {
max-width: 22ch;
margin: 0 0 0.7rem;
font-family: "Iowan Old Style", "Palatino Linotype", "Book Antiqua", Georgia, serif;
font-size: clamp(2rem, 5vw, 3.7rem);
font-weight: 600;
letter-spacing: -0.025em;
}
h2 {
margin: 0 0 1rem;
font-family: "Iowan Old Style", "Palatino Linotype", "Book Antiqua", Georgia, serif;
font-size: clamp(1.4rem, 2.4vw, 2rem);
font-weight: 600;
}
h3 {
margin: 0;
font-size: 1rem;
}
.subtitle {
max-width: 68ch;
margin: 0;
color: var(--muted);
font-size: 1.05rem;
}
section {
margin-top: 3.5rem;
}
.callout {
margin-top: 2rem;
padding: 1.15rem 1.25rem;
border: 1px solid color-mix(in srgb, var(--success) 36%, var(--line));
border-radius: 10px;
background: var(--success-soft);
}
.callout.warning {
border-color: color-mix(in srgb, var(--warning) 36%, var(--line));
background: var(--warning-soft);
}
.callout h2,
.callout h3 {
margin-bottom: 0.45rem;
color: inherit;
}
.callout p {
max-width: 80ch;
margin: 0;
}
.concept-grid {
display: grid;
grid-template-columns: repeat(3, minmax(0, 1fr));
gap: 1rem;
}
.concept-card {
display: flex;
flex-direction: column;
min-height: 230px;
border: 1px solid var(--line);
border-radius: 10px;
background: var(--surface);
overflow: hidden;
}
.concept-header {
display: flex;
justify-content: space-between;
align-items: center;
gap: 0.75rem;
padding: 0.75rem 1rem;
border-bottom: 1px solid var(--line);
}
.concept-body {
display: flex;
flex: 1;
flex-direction: column;
gap: 0.9rem;
padding: 1rem;
}
.concept-body p {
margin: 0;
}
.concept-body .note {
margin-top: auto;
color: var(--muted);
font-size: 0.86rem;
}
.pill {
display: inline-flex;
align-items: center;
border-radius: 999px;
background: var(--surface-subtle);
color: var(--muted);
padding: 0.18rem 0.55rem;
font-size: 0.72rem;
white-space: nowrap;
}
.model-flow {
display: grid;
grid-template-columns: repeat(5, minmax(0, 1fr));
gap: 0.55rem;
margin-top: 1.2rem;
}
.flow-step {
position: relative;
padding: 0.75rem 0.8rem;
border-radius: 8px;
background: var(--accent-soft);
color: var(--accent-strong);
font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
font-size: 0.78rem;
text-align: center;
}
.flow-step:not(:last-child)::after {
position: absolute;
top: 50%;
right: -0.48rem;
z-index: 1;
content: "›";
transform: translateY(-52%);
color: var(--muted);
font-family: sans-serif;
font-size: 1.2rem;
}
.caption {
margin: 0.75rem 0 0;
color: var(--muted);
font-size: 0.82rem;
}
.table-shell {
overflow-x: auto;
border: 1px solid var(--line);
border-radius: 10px;
background: var(--surface);
}
table {
width: 100%;
min-width: 780px;
border-collapse: collapse;
font-size: 0.9rem;
}
th,
td {
padding: 0.8rem 0.9rem;
border-bottom: 1px solid var(--line);
text-align: left;
vertical-align: top;
}
th {
background: var(--surface-subtle);
color: var(--muted);
font-size: 0.74rem;
font-weight: 700;
letter-spacing: 0.045em;
text-transform: uppercase;
}
tbody tr:last-child td {
border-bottom: 0;
}
tbody tr:nth-child(even) {
background: color-mix(in srgb, var(--surface-subtle) 45%, transparent);
}
.rating {
display: inline-block;
min-width: 4.5rem;
border-radius: 999px;
padding: 0.15rem 0.5rem;
font-size: 0.75rem;
font-weight: 700;
text-align: center;
}
.rating.strong {
background: var(--success-soft);
color: var(--success);
}
.rating.moderate {
background: var(--accent-soft);
color: var(--accent-strong);
}
.rating.weak {
background: var(--warning-soft);
color: var(--warning);
}
.rating.reject {
background: var(--danger-soft);
color: var(--danger);
}
.two-column {
display: grid;
grid-template-columns: 1fr 1fr;
gap: 2rem;
align-items: start;
}
.avoid-list {
display: grid;
gap: 0.65rem;
margin: 0;
padding: 0;
list-style: none;
}
.avoid-list li {
padding-bottom: 0.65rem;
border-bottom: 1px solid var(--line);
}
.panel {
padding: 1.25rem;
border: 1px solid var(--line);
border-radius: 10px;
background: var(--surface);
}
.panel h3 {
margin-bottom: 0.65rem;
}
.panel p {
margin: 0 0 0.8rem;
}
.panel p:last-child {
margin-bottom: 0;
}
.source-grid {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
gap: 0.65rem 1.5rem;
padding: 0;
list-style: none;
}
.source-grid a {
display: block;
padding: 0.5rem 0;
border-bottom: 1px solid var(--line);
}
footer {
margin-top: 4rem;
padding-top: 1.25rem;
border-top: 1px solid var(--line);
color: var(--muted);
font-size: 0.8rem;
}
@media (max-width: 840px) {
.concept-grid,
.two-column {
grid-template-columns: 1fr;
}
.model-flow {
grid-template-columns: 1fr;
}
.flow-step:not(:last-child)::after {
top: auto;
right: 50%;
bottom: -0.72rem;
transform: translateX(50%) rotate(90deg);
}
}
@media (max-width: 620px) {
.page {
width: min(100% - 1.25rem, 1180px);
padding-top: 1rem;
}
.toolbar {
align-items: flex-start;
flex-direction: column;
margin-bottom: 2rem;
}
.source-grid {
grid-template-columns: 1fr;
}
}
@media print {
:root {
--bg: #ffffff;
--surface: #ffffff;
--surface-subtle: #f3f5f4;
--text: #111111;
--muted: #444444;
--line: #cccccc;
--accent: #0f766e;
--accent-strong: #0b5c56;
--accent-soft: #edf7f5;
--success: #166534;
--success-soft: #eef8f0;
--warning: #814005;
--warning-soft: #fff6e8;
--danger: #8a2424;
--danger-soft: #fff0f0;
--code-bg: #eeeeee;
}
.toolbar-actions {
display: none;
}
.page {
width: 100%;
padding: 0;
}
section,
.concept-card,
.panel,
.callout {
break-inside: avoid;
}
}
</style>
</head>
<body>
<main class="page">
<nav class="toolbar" aria-label="Documentacties">
<span>Lokaal onderzoeksartefact · 18 juli 2026</span>
<div class="toolbar-actions">
<a href="onderzoek-engelstalige-epd-terminologie.md">Onderzoeksrapport</a>
<button class="button" id="theme-toggle" type="button" aria-label="Wissel licht en donker thema">
Licht/donker
</button>
</div>
</nav>
<header>
<p class="eyebrow">EHR terminology review</p>
<h1>Engelstalige EHR-termen voor GGZ-instroom</h1>
<p class="subtitle">
Vergelijking van Epic, Oracle Health, athenahealth, Netsmart, NextGen,
HL7 FHIR, ONC/360X en NHS, aangescherpt voor een primair ambulante GGZ-context.
</p>
</header>
<aside class="callout">
<h2>Aanbevolen richting</h2>
<p>
Gebruik <code>referral</code> als eersteklas lifecycle-object voor het beheerde
aanmeldingstraject en <code>referral_submission</code> voor iedere afzonderlijke
ontvangst of aanvulling. Een mogelijk <code>referral_request</code> blijft een
apart te valideren concept voor het inhoudelijke verzoek of de formele verwijzing.
</p>
</aside>
<section aria-labelledby="core-model-title">
<h2 id="core-model-title">Voorgesteld kernmodel</h2>
<div class="concept-grid">
<article class="concept-card">
<div class="concept-header">
<h3>Referral Request</h3>
<span class="pill">verzoek · open</span>
</div>
<div class="concept-body">
<p><code>referral_request</code></p>
<p>
Het inhoudelijke verzoek om zorg of beoordeling, geïnitieerd door een
professional, organisatie, cliënt of vertegenwoordiger.
</p>
<p class="note">
Mogelijke Engelse tegenhanger van de formele VERWIJZING. Eerst bepalen
of dit een eigen identiteit nodig heeft.
</p>
</div>
</article>
<article class="concept-card">
<div class="concept-header">
<h3>Referral Submission</h3>
<span class="pill">ontvangst</span>
</div>
<div class="concept-body">
<p><code>referral_submission</code></p>
<p>
Eén ontvangen indiening of aanvulling, met eigen kanaal, bron, tijdstip,
documenten en oorspronkelijke inhoud.
</p>
<p class="note">
Voorkeursnaam voor AANMELDSIGNAAL. Een lokale technische term, geen
universele EHR-standaard.
</p>
</div>
</article>
<article class="concept-card">
<div class="concept-header">
<h3>Referral</h3>
<span class="pill">workflow</span>
</div>
<div class="concept-body">
<p><code>referral</code></p>
<p>
Het beheerde instroomobject dat submissions en eventuele requests
beoordeelt, aanvult, trieert en afsluit.
</p>
<p class="note">
Voorkeursnaam voor AANMELDINGSTRAJECT. Sluit aan op Epic, Oracle en
behavioral-healthleverancier Netsmart.
</p>
</div>
</article>
</div>
<div class="model-flow" aria-label="Voorgestelde instroomketen">
<div class="flow-step">referral_submission</div>
<div class="flow-step">referral</div>
<div class="flow-step">acceptance_decision</div>
<div class="flow-step">clinical_care_episode</div>
<div class="flow-step">clinical_intake</div>
</div>
<p class="caption">
De zorgsetting is een afzonderlijk tijdgebonden kenmerk. De keten heet dus
niet admission of pre-admission; de meeste GGZ-behandeling is ambulant.
</p>
</section>
<section aria-labelledby="options-title">
<h2 id="options-title">Beoordeling van naamparen</h2>
<div class="table-shell">
<table>
<thead>
<tr>
<th>Naamparen</th>
<th>Oordeel</th>
<th>Sterk punt</th>
<th>Belangrijk risico</th>
</tr>
</thead>
<tbody>
<tr>
<td>Referral Submission / Referral</td>
<td><span class="rating strong">Voorkeur</span></td>
<td>Idiomatic in referral management en behavioral health</td>
<td>Referral moet expliciet als ontvangende lifecycle worden gedefinieerd</td>
</tr>
<tr>
<td>Referral Submission / Referral Case</td>
<td><span class="rating moderate">Sterk</span></td>
<td>Scheidt ontvangst en workflow zeer expliciet</td>
<td>Case kan elders juridisch, financieel of klinisch iets anders betekenen</td>
</tr>
<tr>
<td>Care Access Submission / Care Access Case</td>
<td><span class="rating moderate">Redelijk</span></td>
<td>Inclusief voor zelfaanmelding en niet-formele bronnen</td>
<td>Access kan als dossier-, systeem- of autorisatietoegang worden gelezen</td>
</tr>
<tr>
<td>Referral Submission / Referral Intake Case</td>
<td><span class="rating weak">Zwak</span></td>
<td>Sluit aan op behavioral-healthtaal als referral intake</td>
<td>Botst met Triqura's afzonderlijke klinische intake</td>
</tr>
<tr>
<td>Inbound Care Submission / Access Assessment Case</td>
<td><span class="rating reject">Afwijzen</span></td>
<td>Domeinneutraal</td>
<td>Abstract en niet herkenbaar in onderzochte EHR-documentatie</td>
</tr>
</tbody>
</table>
</div>
</section>
<section aria-labelledby="evidence-title">
<h2 id="evidence-title">Wat markt en standaarden feitelijk gebruiken</h2>
<div class="table-shell">
<table>
<thead>
<tr>
<th>Bron</th>
<th>Gepubliceerde term</th>
<th>Betekenis</th>
<th>Gevolg voor Triqura</th>
</tr>
</thead>
<tbody>
<tr>
<td>Epic</td>
<td>Referral</td>
<td>Lifecycle-object met incoming/outgoing class, status, triage en historie</td>
<td>Ondersteunt <code>referral</code> als beheerd instroomobject</td>
</tr>
<tr>
<td>Oracle Health</td>
<td>Referral / Referral Order</td>
<td>Order is verzoek; Referral Management beheert status, bijlagen en tijdlijn</td>
<td>Scheidt request en beheerde referral</td>
</tr>
<tr>
<td>Netsmart</td>
<td>Incoming Referral / Referral Manager / Referral Packet</td>
<td>Behavioral-healthinstroom uit meerdere kanalen; acceptatie naar pre-admit</td>
<td>Referraltaal past bij de GGZ, maar pre-admit niet als generieke kernterm</td>
</tr>
<tr>
<td>HL7 FHIR</td>
<td>ServiceRequest / Task / EpisodeOfCare / Encounter</td>
<td>Verzoek, workflowtaak, verantwoordelijkheid en contact zijn aparte concepten</td>
<td>Lokale objecten niet naar één FHIR-resource forceren</td>
</tr>
<tr>
<td>ONC/360X</td>
<td>Referral Request / Referral Order / Referral Identifier</td>
<td>Closed-loop workflow met persistente identifier tot afsluiting</td>
<td>Request en workflow moeten herkenbaar maar niet samengevouwen zijn</td>
</tr>
<tr>
<td>NHS</td>
<td>Referral Request / Patient Pathway</td>
<td>Referral Request omvat self-referral; Patient Pathway is veel breder</td>
<td>Ondersteunt een apart request, maar niet Patient Pathway voor deze fase</td>
</tr>
</tbody>
</table>
</div>
</section>
<section class="two-column" aria-label="Terminologierisico's en modelcorrectie">
<div>
<h2>Termen om te vermijden</h2>
<ul class="avoid-list">
<li><code>signal</code> — klinkt als alert of klinisch vroegsignaal.</li>
<li><code>admission</code> — suggereert opname of reeds verleende toegang.</li>
<li><code>pre_admission</code> — is opnamegericht en niet passend als ambulante standaard.</li>
<li><code>encounter</code> — is een feitelijk contact, geen instroomworkflow.</li>
<li><code>episode_of_care</code> — impliceert organisatorische verantwoordelijkheid.</li>
<li><code>patient_pathway</code> — is breder en langduriger dan beoordeling vóór acceptatie.</li>
<li><code>referral_intake_case</code> — botst met de afzonderlijke klinische intake.</li>
</ul>
</div>
<article class="panel">
<h3>Belangrijkste modelcorrectie</h3>
<p>
Het huidige AANMELDSIGNAAL bevat zowel een transportfeit als inhoud van
een zorgverzoek. Engelstalige EHR-terminologie maakt zichtbaar dat dit
twee betekenissen kunnen zijn.
</p>
<p>
Een huisartsbrief, later ontvangen diagnostiek en een telefoontje kunnen
drie submissions binnen één referral zijn, zonder dat drie nieuwe
zorgverzoeken of trajecten ontstaan.
</p>
<p>
Of het inhoudelijke verzoek daarom een eigen <code>referral_request</code>
nodig heeft, wordt in de FCO-IM-feitenronde bepaald.
</p>
</article>
</section>
<section aria-labelledby="sources-title">
<h2 id="sources-title">Primaire bronnen</h2>
<ul class="source-grid">
<li><a href="https://open.epic.com/EHITables/GetTable/REFERRAL.htm">Epic REFERRAL</a></li>
<li><a href="https://open.epic.com/EHITables/GetTable/REFERRAL_2.htm">Epic referral triage</a></li>
<li><a href="https://docs.oracle.com/en/industries/health/oracle-health-ehr/ehrfg/referrals.html">Oracle Health Referrals</a></li>
<li><a href="https://www.ntst.com/carefabric/population-health-management/referral-management">Netsmart Referral Manager</a></li>
<li><a href="https://hl7.org/fhir/R5/servicerequest.html">HL7 FHIR ServiceRequest</a></li>
<li><a href="https://hl7.org/fhir/R5/episodeofcare.html">HL7 FHIR EpisodeOfCare</a></li>
<li><a href="https://oncprojectracking.healthit.gov/wiki/spaces/TechLab360X/pages/18776120/360X+Home">ONC 360X</a></li>
<li><a href="https://www.datadictionary.nhs.uk/classes/patient_pathway.html">NHS Patient Pathway</a></li>
</ul>
</section>
<aside class="callout warning">
<h2>Nog één open begrippenvraag</h2>
<p>
<code>referral_submission</code> en <code>referral</code> zijn de huidige
voorkeursrichting. De bestaande begrippenlijst is nog niet aangepast omdat
eerst moet worden vastgesteld of de Nederlandse VERWIJZING volledig
samenvalt met een zelfstandig <code>referral_request</code>.
</p>
</aside>
<footer>
Zelfstandig HTML-artefact. Geen externe scripts, fonts of stylesheets.
Bronlinks vereisen internet; alle onderzoeksinhoud is lokaal beschikbaar.
</footer>
</main>
<script>
(() => {
const root = document.documentElement;
const toggle = document.getElementById("theme-toggle");
const storedTheme = localStorage.getItem("ehr-referral-theme");
if (storedTheme === "light" || storedTheme === "dark") {
root.dataset.theme = storedTheme;
}
toggle.addEventListener("click", () => {
const systemDark = window.matchMedia("(prefers-color-scheme: dark)").matches;
const current = root.dataset.theme || (systemDark ? "dark" : "light");
const next = current === "dark" ? "light" : "dark";
root.dataset.theme = next;
localStorage.setItem("ehr-referral-theme", next);
});
})();
</script>
</body>
</html>

2
docs/datamodel/entiteitenkaart-instroom.html → docs/datamodel/entiteitenkaarten/entiteitenkaart-instroom.html
View File

@@ -1025,7 +1025,7 @@ erDiagram
</section>
<footer>
Bron: <code>docs/datamodel/datamodel-discovery.md</code> §5.1–5.5 · volgende stap (§6): statussen +
Bron: <code>docs/datamodel/deelmodellen/datamodel-discovery.md</code> §5.1–5.5 · volgende stap (§6): statussen +
eigenaarschap ECD/TIP per entiteit vastleggen, daarna de latere rondes (agenda, rapportage &amp;
overdracht, rollen/disciplines) en pas dan de schema-baseline.
</footer>

623
docs/datamodel/feitenmodellen/feitenmodel-instroom.md Normal file
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 3–5 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`.

319
docs/datamodel/onderzoek/onderzoek-engelstalige-epd-terminologie.md Normal file
View File

@@ -0,0 +1,319 @@
# Onderzoek Engelstalige EPD-terminologie — referral en instroom
**Status:** onderzoeksrapport, aanbeveling nog niet als begrippenbesluit verwerkt
**Datum:** 18 juli 2026
**Aanleiding:** de werktermen `Inbound Care Signal` en `Access Assessment Case` uit `../begrippenlijst-kernmodel.md` zijn onvoldoende vanzelfsprekend voor Engelstalige ontwikkelaars en zorgprofessionals
**Scope:** Amerikaanse EHR’s, behavioral-health EHR’s, HL7 FHIR, Amerikaanse closed-loop referral guidance en NHS-terminologie
## 1. Onderzoeksvraag
Welke Engelse technische termen passen het beste bij:
1. **AANMELDSIGNAAL** — iedere afzonderlijke binnenkomst met eigen bron, ontvangsttijd, documenten en oorspronkelijk geuite zorgvraag;
2. **AANMELDINGSTRAJECT** — de institutionele workflow waarin één samenhangende zorgvraag wordt beoordeeld, eventueel gevoed door meerdere binnenkomsten, vóór klinische intake en formele acceptatie?
## 2. Hoofdconclusie
De twijfel bij de huidige werktermen is terecht:
- **`Inbound Care Signal` afwijzen.** `signal` is geen gangbare EHR-term voor een ontvangen aanmelding. In zorg-IT klinkt het eerder als klinisch signaal, alert of vroegsignaal.
- **`Access Assessment Case` afwijzen als canonieke naam.** De woorden zijn begrijpelijk, maar deze combinatie komt niet herkenbaar terug in de onderzochte EHR’s of standaarden. `access assessment` beschrijft eerder een activiteit binnen een workflow dan de beheerde workflow zelf.
Amerikaanse EHR’s gebruiken vrijwel overal **referral** als overkoepelende term voor de beheerde instroomworkflow. Ze maken in publieke documentatie alleen niet altijd scherp onderscheid tussen:
- het zorgverzoek;
- de ontvangen verzending of documentenbundel;
- de interne workflow die het verzoek behandelt.
Dat onderscheid is voor Triqura wel nodig. Daarom is de sterkste oplossing geen simpele hernoeming, maar een model met drie begrippen:
1. **Referral Request — `referral_request`**
Het semantische verzoek om zorg of beoordeling, geïnitieerd door professional, organisatie, cliënt of vertegenwoordiger.
2. **Referral Submission — `referral_submission`**
Eén afzonderlijke ontvangst of indiening, via bijvoorbeeld portaal, telefoonregistratie, e-mail, eFax of koppeling, met eigen bron en documenten.
3. **Referral Case — `referral_case`**
De door de ontvangende instelling beheerde workflow waarin submissions en requests worden beoordeeld, aangevuld, getrieerd en afgesloten.
Voor de huidige Nederlandse begrippen betekent dit voorlopig:
- **AANMELDSIGNAAL → `Referral Submission`**
- **AANMELDINGSTRAJECT → `Referral Case`**
- **VERWIJZING → waarschijnlijk `Referral Request`**, voor zover het de formele zorgvraag/verwijzing representeert
De precieze grens tussen `Referral Request` en de bestaande Nederlandse entiteit VERWIJZING moet in de volgende feitenronde worden vastgesteld.
## 3. Wat de leveranciers laten zien
### 3.1 Epic
Epic publiceert een eersteklas `REFERRAL`-object:
- classificeert referrals als `Internal`, `Incoming` of `Outgoing`;
- kent statussen als `New Request`, `Open`, `Pending Review`, `Authorized`, `Denied`, `Closed` en `Incomplete`;
- bewaart bron, reden, prioriteit, ontvangstdatum en besluitdatum;
- kent triage-uitkomsten zoals `Accept`, `Reject`, `Redirect`, `Information Request`, `Respond` en `Convert`;
- heeft een afzonderlijke referralhistorie.
Dit lijkt sterk op het Nederlandse AANMELDINGSTRAJECT: één beheerd object met lifecycle en triage. Epic noemt dit eenvoudigweg een **Referral**.
Epic publiceert daarnaast `ServiceRequest (Referral)` als FHIR-projectie en een `Incoming Referral Notification` als uitwisselingsinterface. Dat bevestigt dat een bericht, verzoek en beheerd referralobject niet noodzakelijk hetzelfde zijn.
**Les voor Triqura:** `referral` is herkenbaar voor de workflow, maar zonder suffix te ambigu wanneer ook request en submission afzonderlijk worden gemodelleerd.
### 3.2 Oracle Health
Oracle Health gebruikt eveneens **Referral** voor het beheerde object:
- actieve en eerdere referrals;
- status;
- referring en referred providers;
- attachments;
- comments;
- activity timeline;
- gekoppelde afspraken;
- requested start date en service-by date.
Een nieuwe referral begint in de UI als **Referral Order**. De order is het verzoek; de Referral Management-functionaliteit beheert vervolgens de lifecycle.
**Les voor Triqura:** `Referral Order` is te smal voor zelfaanmelding en informele instroom. `Referral` past bij de ontvangende workflow.
### 3.3 athenahealth
athenahealth publiceert vooral:
- `Referral Order`;
- `Referral/Auth`;
- attachments gekoppeld aan een referral authorization order;
- generieke `Patient Cases`.
`Referral/Auth` vermengt verwijzing en verzekeringsautorisatie. `Patient Case` is te breed en in de publieke documentatie niet specifiek genoeg verbonden aan instroom.
**Les voor Triqura:** `order`, `authorization` en een ongekwalificeerde `patient_case` passen niet als generieke kernnamen.
### 3.4 Netsmart — behavioral health
Netsmart is voor de GGZ-context bijzonder relevant. Referral Manager:
- verzamelt **incoming referrals** uit onder andere eFax en PDF-upload;
- organiseert referral packets, tijdlijnen, notities, communicatie, taken en wachtrijen rond één referral;
- ondersteunt acceptatie en afwijzing;
- spreekt expliciet over het **referral intake process**;
- zet een geaccepteerde referral door naar een afzonderlijke **pre-admit workflow** in het EHR.
Netsmart gebruikt dus:
- `incoming referral` voor de ontvangen instroom;
- `referral record`/`referral` als beheerd lifecycle-object;
- `referral packet` voor de documentenbundel;
- `referral intake` voor het proces;
- `pre-admit` pas na acceptatie.
**Les voor Triqura:** referralterminologie past ook bij behavioral health. `intake` is daar echter breder en administratief gebruikt, terwijl Triqura `INTAKE` al reserveert voor het klinische onderzoekstraject. Daarom is `Referral Intake Case` voor Triqura onnodig verwarrend.
### 3.5 NextGen en Qualifacts
NextGen gebruikt vooral `Referral Order` binnen een encounter en een `Intake Template` voor gegevens binnen dat contact. `Case` heeft er een andere betekenis: het groepeert encounters voor juridische of verzekeringsdoeleinden.
Qualifacts gebruikt publiek vooral `intake`, `case management` en configureerbare workflows, maar publiceert onvoldoende technisch detail om een zelfstandig referralobject betrouwbaar af te leiden.
**Les voor Triqura:** `case` moet altijd worden gekwalificeerd als `referral_case`; een kaal `case` is te breed.
## 4. Wat de standaarden laten zien
### 4.1 HL7 FHIR
FHIR maakt nuttige conceptuele scheidingen:
- **`ServiceRequest`** — voorstel, plan of order om een dienst te laten uitvoeren;
- **`Task`** — administratieve coördinatie en voortgang van de uitvoering;
- **`EpisodeOfCare`** — periode waarin een organisatie verantwoordelijkheid draagt;
- **`Encounter`** — feitelijk contact of interactie.
FHIR beschrijft een intakevoorbeeld waarin:
1. een `ServiceRequest` wordt ontvangen;
2. eligibility en capaciteit worden beoordeeld;
3. een geplande `EpisodeOfCare` kan worden gemaakt;
4. verdere assessment volgt;
5. na acceptatie een plan ontstaat en de episode actief wordt.
Triqura heeft bewust een andere semantische grens: de ZORGEPISODE ontstaat pas bij formele acceptatie en acceptatie impliceert nog niet automatisch alle behandelverantwoordelijkheid. Daarom moet het pre-acceptatietraject niet rechtstreeks `EpisodeOfCare` worden genoemd.
Een Triqura Referral Submission kan bij uitwisseling bestaan uit meerdere FHIR-resources, bijvoorbeeld `ServiceRequest`, `DocumentReference`, `Communication` en provenance. Het lokale object hoeft dus geen FHIR-resourcenaam te dragen.
### 4.2 Amerikaanse ONC/360X
360X gebruikt:
- `referral request`;
- `referral order`;
- een persistente `Referral Identifier`;
- een closed-loop `referral workflow`;
- statussen en terugkoppelingen tot de referral is gesloten.
De Amerikaanse definitie van **Referral Order** is doorgaans provider-authored. Die term sluit zelfaanmelding en instroom vanuit niet-klinische bronnen onvoldoende in.
**Les voor Triqura:** gebruik `request` in plaats van `order` voor het inhoudelijke verzoek, en modelleer de ontvangende workflow afzonderlijk.
### 4.3 NHS
De NHS definieert:
- **Service Request** — verzoek om zorgdiensten;
- **Referral Request** — subtype voor een zorgdienst, inclusief expliciete zelfverwijzing;
- **Patient Pathway** — de bredere route vanaf het eerste ontvangen verzoek, mogelijk over langere tijd en meerdere behandelperioden.
De NHS vermeldt bovendien dat een mondeling en later schriftelijk bevestigd verzoek normaliter als één referral wordt verwerkt. Dit ondersteunt het onderscheid tussen:
- één semantisch request;
- meerdere ontvangsten of representaties van dat request.
`Patient Pathway` is voor Triqura te breed: het kan chronische of recidiverende zorg en meerdere referral-to-treatment periods omvatten.
## 5. Beoordeling van naamparen
### Optie A — Referral Submission / Referral Case
**Identifiers:** `referral_submission` / `referral_case`
**Advies:** voorkeur
Sterke punten:
- voor Amerikaanse developers direct herkenbaar als onderdeel van referral management;
- submission duidt één ontvangst aan;
- case duidt één beheerde workflow-instance aan;
- self-referral kan expliciet als referral request door de cliënt worden geïnitieerd;
- geen botsing met admission, encounter of EpisodeOfCare;
- laat ruimte voor een afzonderlijke Referral Request.
Risico’s:
- `Referral Submission` is een lokale technische term, geen universele EHR-standaardterm;
- `case` kan elders financieel of juridisch betekenen en moet daarom altijd als `referral_case` worden geschreven;
- de definitie moet expliciet maken dat referral ook self-referral en andere toegestane bronnen omvat.
### Optie B — Care Access Submission / Care Access Case
**Identifiers:** `care_access_submission` / `care_access_case`
**Advies:** inhoudelijk inclusief, maar minder idiomatisch
Sterke punten:
- neutraler voor zelfaanmelding en niet-formele bronnen;
- benadrukt toegang tot zorg in plaats van verwijzing door een professional.
Risico’s:
- veel minder herkenbaar in de onderzochte EHR-documentatie;
- `access` kan voor developers systeem-, dossier- of autorisatietoegang betekenen;
- het verband met referral management en closed-loop uitwisseling wordt minder zichtbaar.
### Optie C — Referral Submission / Referral Intake Case
**Identifiers:** `referral_submission` / `referral_intake_case`
**Advies:** niet kiezen voor Triqura
Sterke punten:
- zeer expliciet over de instroomfase;
- sluit aan bij behavioral-healthtaal als `referral intake process`.
Risico’s:
- Triqura kent al een afzonderlijke klinische INTAKE;
- Amerikaanse systemen gebruiken intake zowel administratief als klinisch;
- vergroot precies de begripsverwarring die het kernmodel probeert te voorkomen.
### Optie D — Inbound Care Submission / Access Assessment Case
**Identifiers:** `inbound_care_submission` / `access_assessment_case`
**Advies:** niet kiezen
Sterke punten:
- domeinneutraal;
- inhoudelijk te begrijpen met een definitie ernaast.
Risico’s:
- geen herkenbaar naamgebruik in de onderzochte EHR’s;
- te abstract en samengesteld;
- `assessment` klinkt als één activiteit;
- `inbound care` klinkt eerder als gegevenslogistiek dan als cliëntinstroom.
## 6. Aanbevolen conceptueel model
De terminologische onduidelijkheid komt mede doordat AANMELDSIGNAAL nu twee betekenissen bevat: de ontvangen verzending én het inhoudelijke zorgverzoek.
De aanbevolen scheiding is:
```text
Referral Request
het inhoudelijke verzoek om zorg of beoordeling
Referral Submission
één ontvangen representatie of aanvulling van een request
Referral Case
de ontvangende workflow die submissions en requests behandelt
```
Voorbeelden:
- Een huisarts stuurt een verwijzing met brief: één Referral Request, ontvangen via één Referral Submission, behandeld in één Referral Case.
- De huisarts stuurt later aanvullende diagnostiek: dezelfde Referral Request en Referral Case, tweede Referral Submission.
- De cliënt belt daarnaast zelf met aanvullende informatie: derde Referral Submission bij dezelfde Referral Case.
- Twee instanties melden onafhankelijk dezelfde zorgvraag: twee requests of submissions kunnen na menselijke beoordeling aan één Referral Case worden gekoppeld.
- Een gelijktijdige crisisvraag en reguliere hulpvraag kunnen ieder een eigen Referral Case krijgen.
De cardinaliteiten mogen nog niet uit deze voorbeelden worden afgeleid. Eerst moeten de elementaire feitzinnen worden gevalideerd.
## 7. Aanbeveling voor de begrippenlijst
Nog niet automatisch aanpassen; eerst inhoudelijk bevestigen:
1. vervang `Inbound Care Signal` door **Referral Submission**;
2. vervang `Access Assessment Case` door **Referral Case**;
3. voeg **Referral Request** toe als afzonderlijk begrip;
4. herbeoordeel of de huidige VERWIJZING volledig samenvalt met Referral Request of slechts één subtype/bron daarvan is;
5. behoud **Clinical Intake Assessment** als afzonderlijk klinisch proces na of rond acceptatie;
6. behoud **Clinical Care Episode** voor de geaccepteerde zorgperiode.
## 8. Betrouwbaarheid en beperkingen
- Epic EHI-exporttabellen geven sterke aanwijzingen voor het logische exportmodel, maar zijn niet automatisch het operationele interne databaseschema.
- Oracle, athenahealth, Netsmart, NextGen en Qualifacts publiceren vooral product-, UI- en API-termen.
- FHIR is een uitwisselingsmodel en geen verplicht lokaal domeinmodel.
- Marketingdocumentatie is gebruikt om gangbaar taalgebruik te beoordelen, niet om cardinaliteiten of juridische betekenis af te leiden.
- Er bestaat geen universele EHR-term voor “iedere afzonderlijke binnenkomst ongeacht kanaal”. `Referral Submission` is daarom een expliciet gekozen lokale technische term.
## 9. Bronnen
### Amerikaanse EHR’s
- Epic, `REFERRAL`: https://open.epic.com/EHITables/GetTable/REFERRAL.htm
- Epic, `REFERRAL_2` triage decision: https://open.epic.com/EHITables/GetTable/REFERRAL_2.htm
- Epic, `REFERRAL_HIST`: https://open.epic.com/EHITables/GetTable/REFERRAL_HIST.htm
- Epic, FHIR interfaces: https://open.epic.com/Interface/FHIR
- Oracle Health, Referrals: https://docs.oracle.com/en/industries/health/oracle-health-ehr/ehrfg/referrals.html
- Oracle Health, Create Referral: https://docs.oracle.com/en/industries/health/oracle-health-ehr/ehrfg/create-referral.html
- athenahealth, Referral Authorization: https://docs.athenahealth.com/api/api-ref/referral-authorization
- athenahealth, Patient Cases: https://docs.athenahealth.com/api/api-ref/document-type-patient-case
- Netsmart, Referral Management: https://www.ntst.com/carefabric/population-health-management/referral-management
- Netsmart, referral intake workflow: https://www.ntst.com/blog/2025/optimizing-human-services-intake-with-ai-and-automation
- NextGen, Referrals: https://docs.nextgen.com/en-US/nextgenc2ae-adaptive-content-engine-help-enterprise-8-3-1-3288208/add-referrals-251359
- NextGen, Cases: https://docs.nextgen.com/en-US/nextgenc2ae-enterprise-ehr-help-3270157/cases-in-nextgenc2ae-enterprise-ehr-324977
- Qualifacts, InSync EHR: https://www.qualifacts.com/about/insync-ehr-platform/
### Standaarden en guidance
- HL7 FHIR ServiceRequest: https://hl7.org/fhir/R5/servicerequest.html
- HL7 FHIR Task: https://hl7.org/fhir/R5/task.html
- HL7 FHIR EpisodeOfCare: https://hl7.org/fhir/R5/episodeofcare.html
- HL7 FHIR Encounter: https://hl7.org/fhir/R5/encounter.html
- HL7 US SDOH Referral Management Task: https://hl7.org/fhir/us/sdoh-clinicalcare/STU2.3/StructureDefinition-SDOHCC-TaskForReferralManagement.html
- ONC 360X: https://oncprojectracking.healthit.gov/wiki/spaces/TechLab360X/pages/18776120/360X+Home
- US Health IT Referral Order: https://isp.healthit.gov/uscdi-data/referral-order
- NHS Service Request: https://www.datadictionary.nhs.uk/classes/service_request.html
- NHS Referral Request: https://archive.datadictionary.nhs.uk/DD%20Release%20May%202024/classes/referral_request.html
- NHS Patient Pathway: https://www.datadictionary.nhs.uk/classes/patient_pathway.html

193
docs/datamodel/onderzoek/onderzoek-leveranciers.md Normal file
View File

@@ -0,0 +1,193 @@
# Onderzoek: datamodellen en publieke API's van Nederlandse ECD/EPD-leveranciers
**Status:** onderzoeksrapport t.b.v. datamodel-discovery (input, geen besluiten)
**Datum:** 18 juli 2026
**Onderzoeker:** research-agent "leveranciers"
**Relatie tot discovery:** dit rapport toetst nergens besluiten uit `../deelmodellen/datamodel-discovery.md` terug — het levert vergelijkingsmateriaal per deelgebied (§5-besluiten) en markeert hooguit open vragen.
---
## 1. Aanpak en betrouwbaarheid per bron
Onderzocht via webresearch (juli 2026): Nedap Ons, Medicore, PinkRoccade Zorg (mijnCaress), Adapcare (Pluriform Zorg), en kort SDB/USER, ZilliZ en Praktijkdata. Betrouwbaarheid verschilt sterk:
| Leverancier | Publieke API-docs | Diepgang van dit onderzoek |
|---|---|---|
| **Nedap Ons** | ✅ Volledig: [ons-api.nl](https://ons-api.nl/) + downloadbare OpenAPI-spec (2,8 MB, 772 paden) | Hoog — spec integraal geanalyseerd |
| **Medicore** | ❌ Alleen marketingpagina's over "Mint" API-platform | Laag — geen resource-niveau vindbaar |
| **PinkRoccade mijnCaress** | ❌ Geen publieke documentatie | Laag — alleen persberichten/partnerpagina's |
| **Adapcare Pluriform Zorg** | ❌ Geen publieke documentatie ("Care Connector") | Laag — alleen productpagina's |
| **SDB USER (ex-Avinty)** | ❌ Geen publieke documentatie ("Connect Service") | Laag |
| **ZilliZ / Praktijkdata** | ❌ Geen publieke documentatie | Zeer laag |
**Belangrijkste methodische bevinding:** van de onderzochte leveranciers publiceert alleen **Nedap** zijn API-model openbaar. Al het onderstaande over de anderen is afgeleid uit marketingmateriaal en derden (integratiepartners) — dat is expliciet gemarkeerd. De Nedap-analyse is daarentegen gebaseerd op de letterlijke OpenAPI-specificatie ([ons-api.nl/assets/openapi.json](https://ons-api.nl/assets/openapi.json), opgehaald 18-07-2026).
---
## 2. Nedap Ons — volledige OpenAPI-analyse
Nedap Ons is primair een VVT/GHZ/GGZ-suite. De API ([ons-api.nl](https://ons-api.nl/)) is REST, zonder versienummers in URL's (resources worden 6 maanden vóór verwijdering gedeprecate), met certificaat-authenticatie en rate limiting ("4 requests tegelijkertijd per certificaat") — bron: [API-eigenschappen](https://ons-api.nl/techniek/apis/API_eigenschappen.html). De huidige API's vervingen op 19-11-2025 de oude per-applicatie-API's ([API-overzicht](https://ons-api.nl/techniek/apis/APIS.html)).
### 2.1 Domeinindeling (tags in de spec)
De spec groepeert ~250 resource-typen in modules. Relevant voor het ECD:
| Module | Kern-resources |
|---|---|
| **administration** | Client, ClientAddress, Bsn, Agbcode, Referral, CareProvider, Practitioner (met AgbCode/BigCode/Profession), ClientContactRelation(+Type), ClientEmployeeRelation(+Type), Location, LocationAssignment (incl. **WaitingList**), Insurance, Document, Team, ExpertiseProfile/ExpertiseGroup |
| **dossier** | Report, ReportType, ReportEntry, SoapReportEntry, CarePlan, CarePlanEntry, CarePlanAgreement, CarePlanSignatureRequirement, Goal/GoalEntry, Demand/DemandEntry, Domain, Action/ActionEntry, ClientNote, MedicalNote, SystemNote, Alert, RestrictiveMeasureRegistration (dwang/vrijheidsbeperking) |
| **dossier.episodes** | Episode, SubGoal, Action |
| **dossier.medical** | Problem, MedicalSummary, PropensityToAdverseReaction (allergieën), advance_directives, involuntary_care (LegalStatus, Incompetence — Wzd/Wvggz), **dsm.Classification / dsm.ClassificationSeries** |
| **dossier.omaha** | Omaha-classificatie (VVT-verpleegkundig: Problem, InterventionCategory, InterventionTarget) |
| **agenda** | AgendaSeries, AgendaOccurrence, ClientAbsenceOccurrence, Label, Unavailability, Reservation |
| **carepath** | CarePath, Template, ModuleTemplate, IntentTemplate (zorgpaden als sjablonen) |
| **dbc.ggz** | Zorgtraject, Subtraject (DBC's — legacy), DiagnoseToekenning |
| **zpm** | CareOrderZpmDetails, ZpmGbggzProfiel, ZpmZorglabel, ZpmSetting (Zorgprestatiemodel) |
| **client_story** | Story, Category, Answer ("levensverhaal" van de cliënt) |
| **survey** | Survey, SurveyResult (vragenlijsten/ROM) |
| **finance** | CareOrder, Invoice, DeclarationRule, FinanceType, VecozoInvoiceRelation |
| **openehr** | ArchetypeWrapper, CompositionWrapper — Nedap gebruikt intern deels openEHR-composities |
| overig | medication, moves (roosteren), payroll, wlz/wmo/jw (Zorglegitimatie per wet!), groupcare, tasque (zorgtaken) |
**Observatie:** de wettelijke kaders zijn bij Nedap aparte modules met elk een eigen "Zorglegitimatie"-resource (`wlz.WlzZorglegitimatie`, `wmo.WmoZorglegitimatie`, `jw.JwZorglegitimatie`) plus `finance.FinanceType`. Het discovery-besluit "wettelijk kader hoort bij de aanmelding" (§5.0.4) is een schonere generalisatie van hetzelfde principe: financieringskader als expliciet gegeven, niet impliciet.
### 2.2 Cliënt, persoon en verwijzer
- **Client** is bij Nedap één platte entiteit (geen persoon/rol-splitsing zoals discovery-besluit §5.1 #1). BSN is een **aparte resource** (`/clients/{id}/bsn`, aparte autorisatie) — zelfde gedachte als spelregel 3.1 #6: BSN afgeschermd op need-to-know, los van het gewone cliëntrecord.
- Relaties zijn expliciet getypeerd: `ClientContactRelation` + `ClientContactRelationType` (waardelijst als resource!) en `ClientEmployeeRelation` + type. Contactpersonen hebben eigen adres-resources.
- **Referral** (verwijzing) heeft: `referrer`, `referrerType`, `referrerCategory`, `agbCode`, `institution`, `specialism`, `date`, `documentId`, `clientId`. Verwijzertype en -categorie zijn strings (waardelijsten), AGB-code en instelling zijn aparte velden, en het verwijs**document** is een losse gekoppelde entiteit. Dit spiegelt de discovery-besluiten §5.1 #2-#3 vrijwel één-op-één (verwijzer ≠ praktijk, AGB op beide, verwijsdocument getypeerd los).
- In de (legacy) DBC-flow zit `SoortVerwijzer` als NZa-waardelijst met `code`, `omschrijving`, `begindatum`, `einddatum` — waardelijst-items met **geldigheidsperioden**. Dat detail (waardelijstwaarden die in de tijd geldig zijn) zit nog niet in de discovery-spelregels en is een aandachtspunt voor de referentietabellen.
### 2.3 Zorgepisodes en trajecten: twee gescheiden werelden
Nedap kent **twee losstaande structuren** die beide "episode/traject" heten:
1. **`dossier.episodes.Episode`** — klinisch-inhoudelijk: `clientId`, `startDate`, `endDate`, `evaluationDate`, `title`, `goal`, `subGoals[]`, gekoppelde `problemIds[]` (medische problemen), `surveyResults[]`, `documents[]`. Plus opvallend: **autorisatie op episode-niveau** (`authorizedExpertiseProfileIds`, `authorizedExpertiseGroupIds`) — wie de episode mag inzien is een eigenschap van de episode.
2. **`dbc.ggz.Zorgtraject`** — financieel/declaratie: `identificatienummer`, `begindatum`, `einddatum` ("Set automatically based on the state of the DBCs... If null, open; if non-null, closed"), `zorgdomein` (NZa-codelijst), `primaireDiagnose`, `subtrajecten[]` (DBC's, met regiebehandelaar-AGB, directe/indirecte minuten, grouper-resultaat/prestatiecode). Voor ZPM is er een aparte module (`zpm.*`) die aan een `CareOrder` hangt.
**Relevantie voor discovery §5.1 #9 (ZORGEPISODE):** Nedap bevestigt de scheiding klinische episode ↔ declaratietraject als twee entiteiten die naar elkaar verwijzen, niet als één ding. Ook opvallend: rapportages verwijzen naar episodes via `episodeIds[]` — **many-to-many**, één verslag kan bij meerdere episodes horen. De discovery gaat nu impliciet uit van één episode per klinisch record; dit is een beargumenteerde open vraag voor de rapportage-ronde (geen bezwaar tegen genomen besluiten).
**Diagnose in de DBC-flow:** `DiagnoseToekenning` heeft `primair` (boolean), datum, en een `diagnoseCode` uit een NZa-tabel die per code o.a. `icd9cm`, `icd10`, prestatiecode-mappings en `selecteerbaar`/`sorteervolgorde` bevat. De mapping diagnose→declaratiecode is dus **data in een codetabel**, precies het patroon van discovery-besluit §5.4 #1 (DSM-registratie met ICD-10-mapping via tabel).
### 2.4 DSM-classificatie (GGZ-module)
`dossier.medical.dsm.Classification` (binnen een `ClassificationSeries`): `classificationDate`, `beginDate`/`endDate`, `status` ("status of the classification phase" — vrije string, geen enum in de spec), `diagnosisDescription`, `findings`, `evaluations`, GAF-scores (`gafStart/gafCurrent/gafEnd/gafMax`), `immutable` (vergrendeld na vaststelling), `axis3weight`. Het bredere `dossier.medical.Problem` kent `certainty` (≈ werkdiagnose vs. definitief), `severity`, `course`, `onsetApproximateDate`/`onsetPeriodOfLife`, `resolvedApproximateDate`, `snomedExpressionValue` en wederom episode-koppeling + autorisatievelden. De as "zekerheid" (certainty) naast klinische status bevestigt het discovery-patroon van twee status-assen (§5.4 open vraag: verificatiestatus + klinische status) als gangbaar.
### 2.5 Rapportagemodel
`dossier.Report` is het centrale verslag-record:
- **Typering:** `reportTypeId` verwijst naar `ReportType`, maar de spec documenteert een **hardcoded lijst**: 101 Rapportage, 102 Gewicht, 103 Bloeddruk, 104 Temperatuur, 105 Bloedsuiker, 106/107 Vocht in/uit, 108 Defecatie, 109 Medisch, 110 Voortgang, 111 Familie communicatie, 112 Keten communicatie, 309 Stemming, 310 Omaha, 311 Saturatie, 314 Pijnscore, 315 SOEP, 316 Bristol, 317 Klinimetrie. `ReportType` is wél een resource met `enabled`-vlag, maar de magic numbers staan letterlijk in de API-beschrijving — het anti-patroon dat spelregel 3.1 #1 (waardelijsten als data, één bron) wil voorkomen, hier zichtbaar bij een marktleider.
- **Metingen als rapportage:** gewicht, bloeddruk enz. zijn géén aparte observatie-entiteit maar rapportagetypen met `reportEntries[]` (naam/waarde/unit, bv. `systolicPressure, 120, mm[Hg]`). Genericiteit boven aparte tabellen per meetwaarde.
- **SOEP gestructureerd:** `soapReportEntries[]` met `soapPart` (Subjective/Objective/...), `content`, en **vertrouwelijkheid + autorisatie per SOEP-deel** (`confidential`, `expertiseProfileIds`). Een verslag is dus deels afschermbaar per discipline.
- **Koppelingen:** `carePlanEntryId` (rapporteren op zorgplan-regel/doel), `episodeIds[]`, `restrictiveMeasureId`, parent/child (reacties op rapportages), `reportActions[]` (leesbevestiging/actie door discipline X).
- **Auteurschap:** basisvelden uit `AuditedBase` (`createdAt/updatedAt/createdBy`) plus `ReportAuthorType`: `employee` / `caren` (mantelzorger via Caren-portaal!) / `external`. Familie kán rapporteren; het auteurstype is expliciet. Dit is een smallere variant van de provenance-spelregel 3.1 #2 (die met mens/AI verder gaat).
- **Status:** `ReportStatus` is minimaal: 0=OPENED / 1=CLOSED, alleen gebruikt voor communicatie-draden. Rapportages zelf kennen geen workflow-status — wel `flagged`, `confidential`, `hidden` + `hidingReason` (soft delete met reden).
### 2.6 Zorgplan (behandelplan-equivalent)
- `CarePlan`: `clientId`, `employeeId`, `beginDate`, `endDate`, `status` — enum **`DRAFT` / `ACTIVE` / `OLD`**. Versiebeheer werkt via nieuwe plannen (endpoints `by_client/active`, `by_client/draft`, `activate`, `archive`): het oude plan wordt `OLD`, er is er hooguit één `ACTIVE`. Dit is het "nieuw record per versie"-model uit de open vraag van discovery §5.5.
- Hiërarchie: `Domain` (leefgebied) → `Demand` (zorgvraag/probleem) → `Goal` → `Action`, elk met een "Entry"-variant (de concrete invulling in dít plan: `DemandEntry`, `GoalEntry`, `ActionEntry`) — sjabloon versus instantie gescheiden. `CarePlanEntry` bundelt demand+goal+acties en draagt `percentageTarget`/`percentageRealized`.
- **Cliëntakkoord is een eigen entiteit, geen status:** `CarePlanAgreement` (carePlanId, clientId, employeeId) plus `CarePlanSignatureRequirement` met `required` en `discussionType`: `discussed` / `discussed_later` / `no_discussion` / `no_agreement`. Dit beantwoordt de open discovery-vraag §5.5 ("is cliëntakkoord een status of los feit?") vanuit de praktijk: **los feit**, met aparte registratie of/hoe het besproken is.
- `carepath.CarePath` + `Template`: zorgpaden als sjablonen met modules, geïnstantieerd per cliënt (`activeModules`, start/einddatum) — vergelijkbaar met "zorgprogramma" als inhoudelijk aanbod (discovery §5.2 #2), maar dan geoperationaliseerd.
### 2.7 Wachtlijst
`LocationAssignmentWaitingList` is een subtype van `LocationAssignment` (type `WAITING_LIST`), letterlijk gedocumenteerd als: *"Developed as a (temporary) solution to enable (GGZ) customers to indicate a client is on a 'waiting list'"*. Velden: `waitingFor`, `status` ("Wachtstatus (urgentie)"), `description`, `classification` (alleen Wlz, ZN-classificatie zoals `DREIGENDE_CRISIS_THUIS`), `closingReason` ("Assumed use: BI tooling"). Bij álle waardevelden staat: **"Possible values are defined by the care organisation"** — volledig instellingsconfigureerbare waardelijsten, niets hardcoded. Voorbeeldwaarden: `waitingFor: BESCHIKBARE_PLEK`, `status: ACTIEF_PLAATSEN`, `closingReason: GEPLAATST`.
**Relevantie voor discovery §5.3:** zelfs de marktleider heeft wachtlijst als noodoplossing aan locatietoewijzing gehangen. Het discovery-besluit (WACHTLIJSTPLAATSING als eigen entiteit met soort aanmeld/behandel, prioriteit en beëindigingsreden) is structureel sterker dan wat Nedap publiek biedt; de Nedap-les die overblijft is: maak prioriteit, wachtreden én beëindigingsreden instellingsconfigureerbare waardelijsten.
### 2.8 Agenda
Klassiek series/occurrence-patroon: `AgendaSeries` (herhaalregels: recurrenceType, weekdagen, cycleInterval, validFrom/To) en `AgendaOccurrence` (concrete afspraak, met `clientPresent`, `registered`, `registrationComplete`, `hourTypeId` → koppeling naar tijdregistratie/declaratie, labels, uitnodigingen voor cliënt en medewerkers). Afwezigheid van cliënten (`ClientAbsenceOccurrence` + `ClientAbsenceReason` als waardelijst-resource) is een aparte structuur. `presence_logs` verbinden agenda met aanwezigheidsregistratie (klinisch/verblijf). Les: afspraak-realisatie ("registered") en de afspraak zelf zijn gescheiden assen — relevant voor de agenda-ronde i.c.m. ZPM (planning ≠ geleverde prestatie).
### 2.9 FHIR/zibs-positie van Nedap
De eigen API is **niet** FHIR — het is een proprietary REST-model. FHIR/zibs zit in een aparte documentatiesectie ([ZIBs en FHIR](https://ons-api.nl/techniek/FHIR%20en%20ZIBS.html)) als uitwisselingslaag ernaast (o.a. `harmony.ZorgdomeinFhirConnector` in de spec, `nuts.Consent` voor het Nuts-netwerk). Dit ondersteunt de discovery-koers (§4): eigen model als kern, FHIR als adapter aan de rand. Zelfde geldt voor Nedaps interne openEHR-gebruik: wrapper-resources, geen leidend API-model.
---
## 3. Medicore (ECD/EPD, veel gebruikt in GGZ/jeugdzorg)
**Niet publiek vindbaar:** resource-lijsten, entiteiten, statussen of een developer-portal. Wat wél uit publieke bronnen blijkt:
- Medicore heeft een API-/integratieplatform **"Mint" (Medicore Integrated)** met "35+ partners"; genoemde integratiedomeinen: medicatie, roosterplanning, speech-to-text, eigen apps. Standaarden: HL7, **FHIR**, OpenID Connect, Azure. Bron: [API-platform](https://medicore.nl/medicore-producten/api-platform/), [Mint-oplossingenpagina](https://medicore.nl/oplossingen/api-platform/).
- De EPD-pagina noemt als product-onderdelen: Mijn Medicore, Zorgapp, UP (AI-assistent), API-platform, Wellbee-cliëntportaal — geen module- of entiteitenlijst op datamodel-niveau. Bron: [EPD-pagina](https://medicore.nl/medicore-producten/epd/).
- Medicore werkt "al jaren met open standaarden zoals MedMij en HL7 FHIR" (bron: [kennisartikel Medicore UP](https://medicore.nl/kennis/de-virtuele-ecd-epd-assistent-die-je-tijd-en-inzichten-teruggeeft/)); dat maakt aannemelijk dat externe koppelingen FHIR-resources gebruiken (MedMij-gegevensdiensten zijn per definitie FHIR), maar **hoe het interne datamodel eruitziet is niet publiek**.
- Toegang tot documentatie loopt via contact/partnerschap; er is geen publieke Swagger/OpenAPI gevonden.
**Conclusie:** "Medicore = FHIR-based API" (aanname uit de opdracht) is publiek **niet verifieerbaar** op resource-niveau; verifieerbaar is alleen dat hun koppelplatform FHIR als standaard noemt.
## 4. PinkRoccade Zorg — mijnCaress
**Niet publiek vindbaar:** API-referentie, entiteiten, waardelijsten. Wat wél blijkt:
- mijnCaress (VVT/GHZ-ECD, geen GGZ-focus) positioneert zich als "API-based... één platform" en "steeds meer open"; werken met API's wordt genoemd als voorwaarde om data "gestandaardiseerd beschikbaar te stellen voor uitwisseling in de zorgketen". Bronnen: [mijnCaress VVT](https://www.mijncaress.nl/vvt/), zoekresultaat "mijnCaress wordt steeds meer Open" (pagina zelf inmiddels 404).
- Concrete koppelingen die publiek beschreven zijn: **ZorgDomein ↔ mijnCaress via HL7 FHIR** (verwijzingen ontvangen en verwerken in het ECD) — bron: [ICT&health](https://www.icthealth.nl/nieuws/koppeling-zorgdomein-mijncaress-beperkt-administratielast/), [FMT Gezondheidszorg](https://fmtgezondheidszorg.nl/koppeling-zorgdomein-en-mijncaress-verbetert-samenwerking-in-keten/); identity-koppelingen via Tools4ever; zorgapp-koppelingen via CareConnections.
- Het [mijnCaress Platform-overzicht](https://mijncaress.nl/oplossingen/mijncaress-platform/) noemt modules (Medewerkerportaal, Zorgapp, Cliëntportaal, Financieel, Stuurinformatie, Spraakgestuurd rapporteren) maar nul technische documentatie.
**Conclusie:** geen bruikbaar datamodel-vergelijkingsmateriaal; alleen het signaal dat verwijzingen-instroom via FHIR (ZorgDomein) sectorbreed de norm wordt — relevant voor de latere adapter/instroomkant van AANMELDING.
## 5. Adapcare — Pluriform Zorg
**Niet publiek vindbaar:** API-referentie of entiteitenmodel. Wat wél blijkt van de [GGZ-productpagina](https://www.adapcare.nl/pluriform-zorg/ggz/):
- Pluriform Zorg is een "workflowgestuurd ECD" voor het "complete GGZ-behandeltraject", met als genoemde processtappen: **intake en diagnostiek → behandeling → crisis → nazorg**, voor ambulante gesprekken én klinische opnames; "ondersteunt alle financieringsvormen binnen de GGZ" (incl. forensisch).
- Integratie via de **"Adapcare Care Connector"**: "integreer je op basis van open standaarden (zoals FHIR, ZIB's en openEHR)" plus CACAO-samenwerkingsplatform. Geen documentatie van wat er achter die connector zit.
**Conclusie:** het proces-vocabulaire (intake/diagnostiek/behandeling/crisis/nazorg als fasen van één traject) bevestigt de fasering die de discovery in AANMELDING → ZORGEPISODE modelleert, maar op datamodel-niveau valt niets te verifiëren.
## 6. Kort: USER (SDB), ZilliZ, Praktijkdata
- **USER** is het GGZ-EPD van **Avinty, sinds april 2023 onderdeel van SDB Groep** (níet van ZilliZ — de opdrachttekst suggereerde "Zilliz/USER", dat klopt niet). De [USER-productpagina](https://sdbzorgt.nl/user/) noemt: Agenda als "het centrale punt rondom plannen, rapporteren en registreren", multidisciplinair zorgplan waaraan de cliënt meeschrijft, rapportage-overzicht "Voortgang / Decursus" over alle disciplines, Metingen, Zorgviewer, en facturatiestromen "ZPM, WLZ, WMO en FZ". Koppelingen via een **"Connect Service"** ("fundamenteel open ecosysteem") — geen publieke API-docs. Interessant vocabulaire-detail: GGZ-rapportage heet hier **decursus**, en de agenda is expliciet de spil tussen plannen, rapporteren en (ZPM-)registreren.
- **ZilliZ** ([zilliz.nl](https://zilliz.nl/)) is een ECD voor kleinschalige zorg (rapportage, geleverde zorg boeken, facturatie, Vecozo/CAK-berichtenverkeer). API-koppelingen bestaan (REST/SOAP, via partners zoals [Brixxs](https://brixxs.com/faq/hoe-kan-ik-een-api-koppeling-maken-met-zilliz/)) maar zijn niet publiek gedocumenteerd.
- **Praktijkdata** (Telasoft) is een EPD voor GGZ-praktijken (psychologen/psychiaters/therapeuten) met koppelingen naar o.a. [SnelStart](https://www.snelstart.nl/koppelingen/praktijkdata), [BergOp](https://www.bergop.info/aanbod/functies/koppelingen-epd) (ROM) en [MyMindspace](https://www.mymindspace.nl/praktijkdata-epd-koppelt-met-mymindspace) (eHealth). Documentatie alleen op aanvraag.
- **Koppeltaal 2.0** (geen leverancier, wel hét GGZ-koppelvlak voor eHealth): FHIR R4 + zib2020, met verplichte profielen voor Patient, Practitioner, CareTeam, Organization, **Task**, **ActivityDefinition**, RelatedPerson — eHealth-modules worden als ActivityDefinition aangeboden en als Task aan een cliënt toegewezen. Bronnen: [Simplifier-package](https://simplifier.net/packages/koppeltaalv2.00/0.7.2), [Koppeltaal 2.0 Dev Guide](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide/technische-howto/resources-managen). Relevant zodra het ECD eHealth-interventies aan behandeldoelen koppelt (discovery §5.5, interventies).
---
## 7. Dwarsdoorsnede: wat dit betekent voor het Triqura-datamodel
Per discovery-deelgebied, zonder besluiten terug te draaien:
1. **Waardelijsten (spelregel 3.1 #1)** — Nedap laat beide uitersten zien: `ReportType` met magic numbers ín de API-docs (het anti-patroon) én wachtlijstvelden die volledig "defined by the care organisation" zijn (het gewenste patroon). Extra les: NZa-achtige waardelijsten (SoortVerwijzer, Zorgdomein, diagnosecodes) dragen bij Nedap **geldigheidsperioden** (`begindatum`/`einddatum` per waarde). Overweging voor de referentietabellen: geldig-van/geldig-tot per waarde opnemen.
2. **Episode ↔ declaratietraject (besluit §5.1 #9)** — bevestigd door Nedap: klinische episode en zorgtraject/DBC/ZPM zijn gescheiden structuren die naar elkaar verwijzen. Open vraag voor de rapportage-ronde: Nedap koppelt verslagen many-to-many aan episodes (`episodeIds[]`).
3. **Verwijzer (besluiten §5.1 #2-#3)** — Nedaps `Referral` (referrerType, referrerCategory, agbCode, institution, specialism, documentId) valideert de gekozen decompositie; niets gevonden dat ertegen pleit.
4. **Wachtlijst (besluit §5.3)** — geen leverancier heeft dit publiek beter opgelost dan het discovery-besluit; Nedap noemt zijn eigen oplossing letterlijk tijdelijk. Beëindigingsreden ("closingReason... assumed use: BI tooling") als configureerbare waardelijst wordt door de praktijk bevestigd.
5. **Diagnose (besluiten §5.4)** — twee status-assen (certainty + klinische status) en mappingtabellen met ICD-9/ICD-10-kolommen per diagnosecode zijn bij Nedap staande praktijk; `immutable` na vaststelling is het equivalent van "definitief vastgesteld". GAF-scores op de classificatie zijn DSM-IV-erfgoed — niet overnemen, wel een waarschuwing over hoe classificatie-historie in een model versteent.
6. **Behandelplan (§5.5, open vragen)** — Nedap beantwoordt twee open discovery-vragen vanuit de praktijk: statusmachine minimaal (`DRAFT`/`ACTIVE`/`OLD`, één actief plan, versie = nieuw record) en **cliëntakkoord als los feit** (`CarePlanAgreement`) met een aparte besprekingsstatus (`discussed`/`discussed_later`/`no_discussion`/`no_agreement`) — dat laatste dekt de WGBO-realiteit dat een plan besproken-maar-niet-akkoord kan zijn.
7. **Rapportage (latere ronde)** — Nedap-patronen om mee te nemen: metingen als generiek entry-mechanisme i.p.v. tabel-per-meetsoort; vertrouwelijkheid/autorisatie per verslag-onderdeel (SOEP-deel) en zelfs per episode; auteurstype als enum (medewerker/naaste/extern — bij Triqura komt daar AI bij, spelregel 3.1 #2 gaat verder); verbergen met reden i.p.v. verwijderen.
8. **FHIR-positie (§4 discovery)** — geen enkele onderzochte leverancier gebruikt FHIR als intern datamodel. Nedap: proprietary REST + FHIR/zibs als rand. Medicore/PinkRoccade/Adapcare: FHIR genoemd als koppelstandaard. De discovery-koers (eigen model, FHIR als adapter) is marktconform.
9. **Openheid als onderscheid** — alleen Nedap publiceert zijn API volledig. Een publiek gedocumenteerde, semantisch rijke API (uit FCO-IM-feitzinnen afleidbaar) zou voor Triqura een reëel concurrentievoordeel zijn in een markt waar documentatie achter partnercontracten zit.
## 8. Expliciet: wat NIET publiek vindbaar is
- Interne datamodellen/ERD's van álle leveranciers (ook Nedap publiceert alleen het API-vlak, niet het databaseschema).
- Medicore: elke resource-/entiteitenlijst, statussen, waardelijsten; het bestaan van een FHIR-API is aannemelijk maar niet op resource-niveau verifieerbaar.
- PinkRoccade mijnCaress: elke technische API-documentatie; de "steeds meer open"-pagina is inmiddels offline (404).
- Adapcare: alles achter de "Care Connector"; geen spec, geen resources.
- USER/SDB: alles achter de "Connect Service"; ook GGZ-instroomfunctionaliteit (aanmelding/wachtlijst) is publiek onbeschreven.
- Wachtlijst-/aanmeldstatussen en instroomworkflows: bij geen enkele leverancier publiek gedocumenteerd behalve Nedaps wachtlijst-resource.
- Dit onderzoek heeft geen toegang gehad tot partnerportalen, NDA-documentatie of demo-omgevingen; alles hierboven komt uit openbare bronnen d.d. 18-07-2026.
## 9. Bronnen
**Nedap Ons (primair, hoge betrouwbaarheid):**
- [ons-api.nl — Wat is Ons API?](https://ons-api.nl/) · [API-overzicht](https://ons-api.nl/techniek/apis/APIS.html) · [API-eigenschappen](https://ons-api.nl/techniek/apis/API_eigenschappen.html) · [ZIBs en FHIR](https://ons-api.nl/techniek/FHIR%20en%20ZIBS.html)
- [OpenAPI-specificatie (json, geanalyseerd 18-07-2026)](https://ons-api.nl/assets/openapi.json)
- [Nedap Ons support — What is Ons API?](https://support.nedap-ons.nl/support/solutions/articles/103000371509-what-is-ons-api-)
**Medicore:**
- [API-platform](https://medicore.nl/medicore-producten/api-platform/) · [Mint-oplossingen](https://medicore.nl/oplossingen/api-platform/) · [EPD](https://medicore.nl/medicore-producten/epd/) · [Medicore UP / standaarden](https://medicore.nl/kennis/de-virtuele-ecd-epd-assistent-die-je-tijd-en-inzichten-teruggeeft/)
**PinkRoccade mijnCaress:**
- [mijnCaress Platform](https://mijncaress.nl/oplossingen/mijncaress-platform/) · [mijnCaress VVT](https://www.mijncaress.nl/vvt/) · [ZorgDomein-koppeling via FHIR (ICT&health)](https://www.icthealth.nl/nieuws/koppeling-zorgdomein-mijncaress-beperkt-administratielast/) · [FMT Gezondheidszorg](https://fmtgezondheidszorg.nl/koppeling-zorgdomein-en-mijncaress-verbetert-samenwerking-in-keten/)
**Adapcare:**
- [Pluriform Zorg GGZ](https://www.adapcare.nl/pluriform-zorg/ggz/) · [Adapcare](https://www.adapcare.nl/)
**USER / ZilliZ / Praktijkdata:**
- [USER EPD (SDB Zorgt)](https://sdbzorgt.nl/user/) · [SDB EPD GGZ](https://sdbzorgt.nl/oplossingen/epd-geestelijke-gezondheidszorg/) · [ZilliZ](https://zilliz.nl/) · [Brixxs — API-koppeling ZilliZ](https://brixxs.com/faq/hoe-kan-ik-een-api-koppeling-maken-met-zilliz/) · [Praktijkdata ↔ SnelStart](https://www.snelstart.nl/koppelingen/praktijkdata) · [BergOp EPD-koppelingen](https://www.bergop.info/aanbod/functies/koppelingen-epd) · [MyMindspace ↔ Praktijkdata](https://www.mymindspace.nl/praktijkdata-epd-koppelt-met-mymindspace)
**Koppeltaal (context):**
- [Koppeltaal 2.0 package (Simplifier)](https://simplifier.net/packages/koppeltaalv2.00/0.7.2) · [Koppeltaal 2.0 Dev Guide](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide/technische-howto/resources-managen)

241
docs/datamodel/onderzoek/onderzoek-rapportage.md Normal file
View File

@@ -0,0 +1,241 @@
# Onderzoek: voortgangsrapportage & dossiervoering in de Nederlandse GGZ
**Status:** onderzoeksinput voor datamodel-deelgebied voortgangsrapportage (ronde "rapportage & overdracht")
**Datum:** 18 juli 2026
**Auteur:** onderzoeksagent "rapportage" (webresearch + prototype-analyse)
**Kader:** dit rapport draait geen besluiten uit `../deelmodellen/datamodel-discovery.md` terug; het levert feiten, bronnen en kandidaat-feitzinnen. Waar iets schuurt met een genomen besluit staat dat expliciet als open vraag gemarkeerd.
---
## 1. Wettelijk kader: wat móet er in het dossier
### 1.1 WGBO — dossierplicht (BW 7:454)
- De hulpverlener is verplicht een dossier in te richten en daarin aantekening te houden van "gegevens omtrent de gezondheid van de patiënt en de te diens aanzien uitgevoerde verrichtingen", voor zover dit voor een goede hulpverlening noodzakelijk is. Er is geen limitatieve wettelijke lijst; de norm is *noodzakelijk voor goede zorg* ([KNMG — richtlijn Omgaan met medische gegevens](https://www.knmg.nl/richtlijn-omgaan-met-medische-gegevens/), [Ondernemersplein — medisch dossier bijhouden](https://ondernemersplein.overheid.nl/wetten-en-regels/medisch-dossier-bijhouden-en-delen/)).
- **Bewaartermijn: 20 jaar**, gerekend vanaf de laatste wijziging in het dossier (WGBO-wijziging per 1-1-2020, was 15 jaar vanaf vastlegging) ([LVVP](https://lvvp.info/nieuwsbrief/wijziging-wgbo-waaronder-verlenging-bewaartermijn-15-naar-20-jaar/), [Rijksoverheid](https://www.rijksoverheid.nl/onderwerpen/rechten-van-patient-en-privacy/uw-medisch-dossier/bewaren-medisch-dossier), [KNMG — wijzigingen WGBO](https://www.knmg.nl/advies-richtlijnen/dossiers/behandelingsovereenkomst-wgbo/wijzigingen-wgbo.htm)). Langer bewaren kan (belang van derden, bijv. erfelijke gegevens); bij gedwongen opname geldt aanvullend minimaal 5 jaar na ontslag ([Autoriteit Persoonsgegevens](https://www.autoriteitpersoonsgegevens.nl/en/themes/health/health-data-in-a-file/retention-of-the-health-data-file)).
- **Patiëntrechten op het dossier** ([AP — rechten bij het dossier](https://www.autoriteitpersoonsgegevens.nl/en/themes/health/health-data-in-a-file/rights-regarding-the-health-data-file), [VvAA](https://www.vvaa.nl/nieuws-en-kennis/nieuws-en-artikelen/kopie-wijziging-of-vernietiging-van-medisch-dossier), [KNMG praktijkdilemma vernietiging](https://www.knmg.nl/ik-ben-arts/praktijkdilemmas-1/praktijkdilemma/heeft-mijn-patient-recht-op-vernietiging-van-zijn-medisch-dossier)):
- **Inzage en afschrift** — altijd.
- **Correctie** — alleen voor feitelijke, objectief vaststelbare onjuistheden; indrukken/conclusies van de behandelaar vallen er níet onder.
- **Aanvulling** — de cliënt mag altijd een eigen (afwijkende) verklaring aan het dossier laten toevoegen; de hulpverlener móet die opnemen, ook bij inhoudelijk oneens zijn.
- **Vernietiging** — op verzoek, tenzij een aanmerkelijk belang van een ander zich verzet of een wettelijke bepaling vernietiging verbiedt. (Sinds de herziening 2024 van de KNMG-richtlijn: het vernietigingsverzoek zelf bewaren ná vernietiging.)
### 1.2 Wabvpz — elektronische inzage en logging
Per 1 juli 2020 (art. 15d/15e Wabvpz): cliënt heeft recht op **kosteloze elektronische inzage en elektronisch afschrift** van het dossier, en recht op een afschrift van de **logging** (wie keek wanneer in het dossier); logging moet voldoen aan **NEN 7513** ([Eldermans & Geerts](https://www.eldermans-geerts.nl/per-1-juli-2020-het-recht-op-elektronische-inzage-in-en-afschrift-van-het-medisch-dossier/), [Dirkzwager](https://www.dirkzwager.nl/kennis/artikelen/per-1-juli-2020-nieuwe-rechten-en-verplichtingen-met-betrekking-tot-het-elektronisch-patientendossier), [VGN](https://www.vgn.nl/nieuws/elektronische-inzage-afschrift-en-logging-1-juli-2020)).
**Gevolg voor rapportage:** elke voortgangsrapportage is in beginsel cliënt-leesbaar. Dit is geen portaal-feature-keuze maar een wettelijk recht — een "vertrouwelijk"-vlag in het ECD kan zichtbaarheid in een portaal uitstellen, maar heft het inzagerecht niet op.
### 1.3 Wkkgz — incidenten in het dossier (art. 10 lid 3)
- Incidenten met **merkbare gevolgen voor de cliënt** (of die deze in de toekomst kunnen hebben) moeten aan de cliënt worden gemeld én in het **cliëntendossier** worden aangetekend: **aard, toedracht en tijdstip** van het incident plus de **namen van direct betrokkenen**. De cliënt kan hiervan afschrift vragen ([Holla — Wkkgz-meldingen](https://www.holla.nl/nieuws/wkkgz-meldingen), [Dirkzwager — mededeling van een incident](https://www.dirkzwager.nl/kennis/artikelen/inzage-in-het-medisch-dossier-van-een-overleden-pati%C3%ABnt-2-mededeling-van-een-incident)).
- Dit staat **los van** de interne VIM-melding (zie §6): VIM registreert élk incident in een apart register; het dossier krijgt alleen een aantekening bij merkbare gevolgen ([zzp-erindezorg — incident vs calamiteit](https://www.zzp-erindezorg.nl/blog/eisen-uit-de-wkkgz-verschil-tussen-incident-en-calamiteit/)).
### 1.4 Landelijk Kwaliteitsstatuut GGZ (v4.0, jan 2025)
- De **regiebehandelaar** (indicerend/coördinerend) is verantwoordelijk voor probleemanalyse, diagnose en behandelplan op hoofdlijnen, en voor **dossiervoering, verslaglegging en het eindverslag**; minimaal jaarlijks een planbespreking met alle betrokken disciplines, vastgelegd in het dossier ([Landelijk Kwaliteitsstatuut GGZ 4.0, Zorginzicht](https://www.zorginzicht.nl/binaries/content/assets/zorginzicht/kwaliteitsinstrumenten/landelijk-kwaliteitsstatuut-ggz-4.0.pdf), [Zorginstituut](https://www.zorginstituutnederland.nl/publicaties/publicatie/2020/12/15/landelijk-kwaliteitsstatuut-ggz)).
- MDO-conclusies en -afspraken horen direct in het dossier (multidisciplinair behandelplan) ([Verenso — handreiking MDO](https://www.verenso.nl/kwaliteit/richtlijnen-en-praktijkvoering/richtlijnendatabase/multidisciplinair-overleg-mdo), [normenkaderzorg — MDO-registratie-eis](https://www.normenkaderzorg.nl/index.php?title=DBC_zonder_geldig_MDO_%28N2220%29)).
### 1.5 Zorgprestatiemodel — registratie naast rapportage
Het ZPM registreert **consulten** (declaratie) via "planning = realisatie": afwijking > 15 minuten van de geplande tijd moet worden bijgesteld; tijdschrijven is afgeschaft; de agenda + periodieke controle is de verantwoordingsbron ([Spelregels correct registreren en declareren, zorgprestatiemodel.nl](https://www.zorgprestatiemodel.nl/content/uploads/2023/07/20230628-Spelregels-correct-registreren-en-declareren_definitief.pdf), [Dirkzwager — ZPM registratie](https://www.dirkzwager.nl/kennis/artikelen/het-zorgprestatiemodel-registratie), [NZa V&A](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/vraag-en-antwoord/vraag-en-antwoord-zorgprestatiemodel)).
**Gevolg voor het model:** *consultregistratie* (declarabel feit, agenda-gedreven) en *inhoudelijke rapportage* (klinisch feit) zijn twee verschillende feiten die naar elkaar kunnen verwijzen, maar niet één record zijn. Uitzonderingssituaties moeten wel "uit het dossier blijken".
---
## 2. Professionele richtlijnen dossiervoering
### 2.1 KNMG — Omgaan met medische gegevens (herzien jan 2024)
Hoofdstuk 2 behandelt dossierplicht, bewaartermijn en patiëntrechten; er is bewust géén uitputtende lijst wat per situatie in het dossier moet — de noodzakelijkheidsnorm geldt ([KNMG-richtlijn 2024, pdf](https://www.knmg.nl/download/knmg-richtlijn-omgaan-met-medische-gegevens-2), [overzichtspagina](https://www.knmg.nl/actueel/publicaties/publicaties-per-onderwerp/omgaan-met-medische-gegevens)).
### 2.2 V&VN — Richtlijn Verslaglegging (2022)
Richtlijn voor verpleegkundigen/verzorgenden, ook toepasbaar in de GGZ ([Kennisplatform V&VN — verslaglegging](https://kennisplatform.venvn.nl/onderwerp/verslaglegging/), [richtlijn-pdf](https://www.venvn.nl/media/w02buck0/v-vn-richtlijn-verslaglegging.pdf), [Nursing](https://www.nursing.nl/praktijk/organisatie-van-zorg/nieuwe-richtlijn-moet-verslaglegging-en-overdracht-verbeteren/)):
- Doel: continuïteit en kwaliteit van zorg, samenwerking tussen zorgverleners.
- Vastleggen in **alle fasen van het verpleegkundig proces**: gegevensverzameling, zorgproblemen/diagnoses, **gezamenlijk vastgestelde doelen**, uitgevoerde zorg, **voortgangsrapportage**, evaluatie, overdracht.
- **Eenduidige taal** die uitwisselbaar is tussen organisaties (eenheid van taal / zibs-terminologie).
- **Cliënt betrekken**: controleer of wat je rapporteert aansluit bij de wensen/behoeften van de zorgvrager.
- Bij overdracht tussen settingen: de informatiestandaard **eOverdracht** gebruiken.
### 2.3 NIP — dossier vs. persoonlijke werkaantekeningen
- Het cliëntdossier bevat alles wat relevant is voor kwaliteit en continuïteit van de professionele relatie: behandelplan, gespreksaantekeningen, observaties, testuitslagen, correspondentie ([NIP — dossiervorming](https://www.psynip.nl/uw-beroep/cotan/cotan-beoordelingssysteem-ast-en-beroepscode/algemene-standaard-testgebruik-nip-2017/2-2-onderzoeksprocedure/2-2-2-dossiervorming/)).
- **Persoonlijke werkaantekeningen** (indrukken, vermoedens, vragen als geheugensteun voor het eigen denkproces) horen **niet** in het dossier, zijn tijdelijk en moeten vernietigd worden zodra niet meer relevant. Let op: gespreksnotities en observaties over de cliënt zijn *géén* werkaantekeningen — die horen wél in het dossier ([NIP — persoonlijke werkaantekeningen](https://www.psynip.nl/uw-beroep/cotan/cotan-beoordelingssysteem-ast-en-beroepscode/algemene-standaard-testgebruik-nip-2017/2-2-onderzoeksprocedure/2-2-4-persoonlijke-werkaantekeningen/)).
- **Gevolg voor het model:** werkaantekeningen zijn geen dossier-entiteit. Als het ECD ze faciliteert, dan strikt gescheiden van de rapportage-entiteit, buiten inzage/afschrift, met een vernietigings-levenscyclus. Simpeler: niet faciliteren.
### 2.4 NVvP / psychiatrie
Geen aparte NVvP-dossierrichtlijn gevonden naast WGBO/KNMG; dossiervoering is onderdeel van de kwaliteitsvisitatie en elk diagnostisch verslag is een medisch document dat tuchtrechtelijk toetsbaar is ([NVvP — wet- en regelgeving](https://www.psychiatrie.nl/alle-themas/wet-en-regelgeving/), [Richtlijn psychiatrische diagnostiek — wettelijk kader](https://richtlijnendatabase.nl/richtlijn/psychiatrische_diagnostiek/wettelijke_kader_psychiatrische_diagnostiek.html), [NVvP normenkader kwaliteitsvisitatie](https://www.psychiatrie.nl/app/uploads/2024/10/Normenkader-NVvP-Kwaliteitsvisitatie.pdf)).
---
## 3. Rapportagemethodieken
| Methodiek | Structuur | Gebruik |
|---|---|---|
| **SOEP / SOAP** | Subjectief · Objectief · Evaluatie/Analyse · Plan | Breedst gebruikt; huisartsen (NHG-referentiemodel), verpleging, ook GGZ |
| **DAP** | Data · Assessment · Plan | Internationaal dé behandelnotitie-vorm in mental/behavioral health; S+O samengevoegd tot één Data-sectie |
| **TIP** | Thema · Interventie · Plan | GGZ-specifiek alternatief, cliëntvriendelijker |
| **SBAR(R)** | Situation · Background · Assessment · Recommendation (· Repeat) | Mondelinge/acute overdracht, niet primair dossiernotitie |
| **SMART** | doelformulering, geen notitievorm | doelen in behandelplan |
| **Vrije tekst / decursus** | chronologisch journaal | klassiek medisch EPD-patroon |
- **SOEP**: S = wat de cliënt zelf zegt/beleeft; O = observaties en meetbare vaststellingen incl. gedane interventie en reactie; E = interpretatie/conclusie uit S+O; P = vervolgplan ([Verslagleggen in de GGZ — SOEP-methode](https://www.verslagleggenindeggz.nl/blog/de-soep-methode-hoe-pas-je-die-toe-in-een-voortgangsrapportages/), [CME-Online — SOEP vs SOAP](https://www.cme-online.nl/blog/wat-is-soep-rapporteren/), [NHG HIS-referentiemodel — SOEP-verslag](https://referentiemodel.nhg.org/node/19)). Nedap Ons ondersteunt SOEP als gestructureerd rapportageformulier ([Nedap Ons — SOEP-rapportage](https://support.nedap-ons.nl/support/solutions/articles/103000267329-rapporteren-volgens-de-soep-methode-in-ons-dossier)).
- **DAP**: Data (uitspraken cliënt + observaties + interventies), Assessment (klinische indruk, voortgang op doelen, risico-overwegingen), Plan (vervolg, huiswerk, verwijzing). Typisch drie alinea's ([Headway — DAP notes](https://headway.co/resources/dap-note), [SimplePractice](https://www.simplepractice.com/resource/how-to-write-dap-notes/), [ICANotes](https://www.icanotes.com/2022/10/11/how-to-write-dap-notes/)).
- **TIP en kritiek op SOEP in de GGZ**: het E/A-veld verleidt tot het vastleggen van niet met de cliënt afgestemde aannames — pijnlijk nu cliënten hun dossier online meelezen (Wabvpz). TIP (Thema-Interventie-Plan) wordt in de GGZ aanbevolen als eenvoudiger en herkenbaarder voor de cliënt ([Verslagleggen in de GGZ — SOEP, SOAP of TIP](https://www.verslagleggenindeggz.nl/blog/soep-soap-of-tip-wat-is-een-handige-opbouw-voor-clientrapportages/)).
- **SBAR/I-PASS**: overdrachtscommunicatie; 66% van psychiatrisch verpleegkundigen is ontevreden over de overdracht en voor de klinische GGZ bestaan geen specifieke richtlijnen ([HBO Kennisbank — SBAR-onderzoeken](https://hbo-kennisbank.nl/details/sharekit_av:oai:surfsharekit.nl:270e77bd-1d30-4d7f-b42d-85d5cdd52b74), [eNurse — SBAR-methode](https://enurse.nl/2019/02/24/sbar-methode/), [Nursing — I-PASS](https://www.nursing.nl/student-corner-gebruik-de-i-pass-voor-een-goede-mondelinge-overdracht-2/)).
**Modelles:** er is geen landelijk verplichte notitievorm. Instellingen kiezen (en wisselen). De methodiek is dus **configuratie** (template per rapportagetype/sessietype), geen schema-hardcoding — exact spelregel 3.1 #1. De gestructureerde secties (S/O/E/P of D/A/P) zijn wel waardevolle *optionele* structuur naast de vrije tekst (past op AI-voorbereiding §3.2: structuur + tekst in hetzelfde record).
---
## 4. Relatie rapportage ↔ behandelplan (rapporteren op doelen)
- Het behandelplan is in de GGZ "het hart van het dossier"; elk sessieverslag is een bijdrage aan dat plan: ligt de behandeling op koers, vragen doelen bijstelling, werkt de aanpak ([Kuno — behandelverslag koppelen aan behandelplan](https://www.heykuno.com/nl/blog/ggz-behandelverslag/), [Carecheck — verslaglegging in de GGZ](https://carecheck.nl/verslaglegging-in-ggz/)).
- ECD-praktijk: **rapporteren op een doel** — bij het actuele zorgplan per doel een voortgangsrapportage met een *mate van voortgang* (schaal) plus een notitie ([Nedap Ons — rapporteren op doelen en voortgang](https://support.nedap-ons.nl/support/solutions/articles/103000266084-rapporteren-op-doelen-en-voortgang-in-het-zorgplan-in-ons-dossier), [ZilliZ — rapporteren op zorgdoelen](https://zilliz.nl/kennis/blog/rapportegen-op-zorgdoelen-met-zilliz/)).
- V&VN: evaluatie moet aantoonbaar plaatsvinden — verifieer dat doelen periodiek beoordeeld worden ([Kennisplatform V&VN](https://kennisplatform.venvn.nl/onderwerp/verslaglegging/)).
**Modelles:** een rapportage moet 0..n **behandeldoelen** kunnen refereren (niet verplicht: verpleegkundige dagrapportage of een incident staat vaak los van een doel). Optioneel per doelkoppeling een voortgangsindicatie uit een waardelijst. Evaluatieverslagen (het geplande evaluatiemoment uit §5.5 van de discovery) zijn een rapportagetype dat aan het behandelplan zelf refereert.
---
## 5. Overdracht tussen diensten en teams
- **Dienstoverdracht (klinisch/verpleegkundig):** rapportages worden per dienst/dagdeel gelezen; gestandaardiseerde mondelinge vormen zijn SBAR/I-PASS (§3). Het "include in handover"-patroon (rapportage markeren voor de overdracht) is gangbaar in ECD's en zit ook in het prototype.
- **eOverdracht (Nictiz):** landelijke informatiestandaard voor de verpleegkundige overdracht túsen instellingen, gebaseerd op zibs (publicatie 2017), uitwisseling via HL7 FHIR; kandidaat voor verplichting onder de Wegiz ([Nictiz — eOverdracht](https://www.nictiz.nl/informatiestandaarden/eoverdracht/), [functioneel ontwerp v3.1](https://informatiestandaarden.nictiz.nl/wiki/vpk:V3.1_Ontwerp_eOverdracht), [ICT&health — Wegiz](https://www.icthealth.nl/magazine/editie-01-2023/gegevensuitwisseling-vpo-bijna-klaar-voor-verplichting-onder-wegiz)). Conform discovery §4 is dit een **koppelvlak**, geen modelregel — maar de zib-begrippen zijn een gratis checklist voor wat een overdracht inhoudelijk draagt.
- **MDO:** gepland overleg van meerdere disciplines; conclusies en afspraken direct in het dossier vastleggen als (bijstelling van het) multidisciplinair behandelplan; de regiebehandelaar bewaakt voortgang én verslaglegging ([Verenso — handreiking MDO](https://www.verenso.nl/assets/Praktijkvoering_handreikingen/VER00331-HandrMultidoverl-DEF.pdf), [NZa — MDO-vergoeding ggz](https://www.nza.nl/vraag-en-antwoord/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/hoe-wordt-het-mdo-vergoed)). MDO-verslag = rapportagetype op episodeniveau (niet per se één cliëntcontact).
---
## 6. Incidentmelding: twee gescheiden sporen
Dit is de belangrijkste structurele bevinding voor het incident-rapportagetype:
| Spoor | Wat | Waar | Wie leest |
|---|---|---|---|
| **VIM-melding** (Wkkgz art. 9) | élk incident, ook zonder gevolgen; doel: leren/verbeteren | intern VIM-register, **buiten het cliëntdossier** | VIM-commissie; beschermd, in beginsel niet voor cliënt/IGJ |
| **Dossieraantekening** (Wkkgz art. 10 lid 3) | alleen incidenten met (mogelijk) merkbare gevolgen: aard, toedracht, tijdstip, namen betrokkenen | **cliëntendossier** | cliënt (inzagerecht, afschrift) |
| **IGJ-melding** | calamiteit (dood of ernstig schadelijk gevolg), geweld in de zorgrelatie; binnen 3 werkdagen | IGJ-portaal | IGJ |
- Elke zorgaanbieder moet een interne VIM-procedure hebben: signaleren, registreren, analyseren, maatregelen, terugkoppeling ([Erisietsmisgegaan — VIM](https://erisietsmisgegaan.nl/bijna-alles-dat-je-moet-weten-over-veilig-incidenten-melden/), [TPSC — VIM & Wkkgz](https://www.patientsafety.com/nl/blog/vim-wkkgz), [NHG — procedure VIM](https://www.nhg.org/praktijkvoering/patient/patientveiligheid/procedure-veilig-incident-melden/)).
- Calamiteit = onbedoelde/onverwachte gebeurtenis met dood of ernstig schadelijk gevolg; melden bij IGJ binnen 3 werkdagen; in de GGZ vallen daaronder ook suïcide(pogingen) bij tekortschietende zorg en geweld in de zorgrelatie ([IGJ — calamiteit melden](https://www.igj.nl/onderwerpen/klachten-en-melden/calamiteiten/melding-doen-van-een-calamiteit), [IGJ — suïcide(poging) melden ggz](https://www.igj.nl/onderwerpen/klachten-en-melden/suicidepoging)).
- Gangbare GGZ-incidentcategorieën: agressie/geweld, suïcide(poging)/automutilatie, medicatie-incident, vallen, vermissing/onttrekking, seksueel grensoverschrijdend gedrag ([IGJ — cijfers meldingen ggz](https://www.igj.nl/over-ons/igj-in-cijfers/cijfers-over-meldingen/cijfers-meldingen-geestelijke-gezondheidszorg)).
**Modelles:** het prototype-type `incident` vermengt beide sporen. In het nieuwe model: (a) de **dossieraantekening incident** is een rapportagetype in het cliëntdossier (met de art.-10-velden aard/toedracht/tijdstip/betrokkenen); (b) de **VIM-melding** is een *aparte entiteit buiten het cliëntdossier* met eigen autorisatie, eigen levenscyclus (gemeld → in analyse → afgerond) en eigen categorie-waardelijst, met optionele verwijzing naar cliënt en rapportage. VIM valt mogelijk buiten scope van het ECD-dossierdeel — maar het besluit "waar leeft VIM" moet expliciet genomen worden.
---
## 7. Hoe bestaande ECD's/EPD's rapportage structureren
### 7.1 Nedap Ons (referentie-ECD in care/GGZ)
([Cliëntrapportages toegelicht](https://support.nedap-ons.nl/support/solutions/articles/103000266173-cli%C3%ABntrapportages-in-ons-dossier-toegelicht), [rapportages configureren](https://support.nedap-ons.nl/support/solutions/articles/103000265596-rapportages-voor-ons-dossier-configureren), [autorisaties rondom rapportages](https://support.nedap-ons.nl/support/solutions/articles/103000265496-autorisaties-rondom-rapportages-in-ons-dossier))
- **Rapporttypen zijn beheer-configuratie**: Beheer → Dossierinstellingen → Rapporttypen; alleen geactiveerde typen zijn bruikbaar. Voorbeelden: *Rapportage* (vrije tekst), *Medische rapportage* (medisch kenmerk, andere autorisatie), *Familie-communicatie* (zichtbaar in cliëntportaal Caren), *Ketencommunicatie* (voor externen, bijv. huisarts/Zorgmail).
- Rapportagevormen: vrije tekst, voortgang op doel (met voortgangsmaat), meetwaarden, gestructureerde formulieren (o.a. SOEP).
- Rapportages koppelen aan zorgplan(doel), medische episode of maatregel.
- **Vertrouwelijkheid per rapportage**: alleen zichtbaar voor bepaalde deskundigheidsprofielen ("groen slotje"), en dan niet zichtbaar voor de cliënt in Caren.
- Moment van rapporteren (achteraf rapporteren toestaan of niet) is instelbaar.
### 7.2 GGZ-specifieke EPD's (Medicore, Carecheck e.a.)
- Rapportagetypen die een GGZ-EPD onderscheidt: intake-/behandelverslagen, voortgangsrapportages, evaluatieverslagen, diagnostische rapportages, MDO-verslagen, online sessierapporten, indirecte-tijdregistraties; per **sessietype** een rapportagetemplate en de keuze of het verslag met de cliënt wordt gedeeld via het portaal ([Carecheck — verslaglegging in de GGZ](https://carecheck.nl/verslaglegging-in-ggz/)).
- Signalering op **ontbrekende verslaglegging** (consult gehad, geen verslag) is een gangbare EPD-functie — bij Triqura is dat een natuurlijke Nudge-Engine-regel, geen schema-eis.
- Klassiek medisch patroon: het chronologische journaal heet **decursus** ("beloop") ([Studeersnel — EPD-opbouw en afkortingen](https://www.studeersnel.nl/nl/document/universiteit-twente/vcpg-2/20230719-opbouw-en-afkortingen-in-het-epd/109078787), [NHG — adequate dossiervorming met het EPD](https://www.nhg.org/praktijkvoering/informatisering/richtlijn-adequate-dossiervorming-epd/)).
- Zorgplannen kennen een concept → definitief-cyclus met ondertekening/akkoord van de cliënt ([Nedap Ons — conceptzorgplannen ondertekenen](https://support.nedap-ons.nl/support/solutions/articles/103000265569-conceptzorgplannen-ondertekenen-of-akkoord-laten-verklaren-in-ons-dossier)); voor losse rapportages is accorderen minder universeel, maar concept/definitief + naderhand alleen aanvullen (niet stilzwijgend herschrijven) volgt uit de correctie-systematiek van §1.1.
---
## 8. Prototype-analyse (`app/api/reports`, `lib/types/report.ts`)
### 8.1 Wat er nu is
- Eén `reports`-tabel voor **10 typen**: `voortgang`, `observatie`, `incident`, `medicatie`, `contact`, `crisis`, `intake`, `behandeladvies`, `vrije_notitie`, `verpleegkundig` — hardcoded als TypeScript-const, niet als waardelijst in de database.
- **Twee validatieschema's op één tabel**: standaardrapportage (20–5000 tekens, optioneel `encounter_id`/`intake_id`) vs. `verpleegkundig` (1–500 tekens, verplichte `category` in `structured_data`, `include_in_handover`). De subset `VERPLEEG_REPORT_TYPES` (verpleegkundig, observatie, incident, medicatie, crisis) bepaalt wat het verpleegkundig overzicht toont — een derde impliciete typologie in code.
- `structured_data.category` (medicatie/adl/gedrag/incident/observatie) is een **JSON-veld zonder constraint**; categorielabels, iconen en kleuren leven in de UI-code (`CATEGORY_CONFIG`).
- **Shift-logica**: `calculateShiftDate` — vóór 07:00 telt de rapportage bij de dienst van de vorige dag; `shift_date` wordt alleen gezet voor verpleegkundige notities, bij andere typen is hij leeg maar wordt er wél op gefilterd.
- AI-provenance beperkt: `ai_confidence` + `ai_reasoning` (van de classifier), geen model/bronverwijzingen/content-hash zoals spelregel 3.1 #2 eist.
- `created_by` verwijst naar practitioner maar mag `null` zijn; soft delete via `deleted_at` is aanwezig; geen concept/definitief-status, geen versies, updates overschrijven de tekst zonder zichtbaar spoor.
- Rapportage hangt alleen aan `patient_id` (plus losse optionele `intake_id`/`encounter_id`) — geen koppeling aan zorgepisode, behandelplan of doel.
### 8.2 Gebreken t.o.v. spelregels en wetgeving
1. Typen/categorieën hardcoded in code → schendt spelregel 3.1 #1 (waardelijsten op één plek).
2. Twee (eigenlijk drie) typologieën door elkaar: rapporttype, verpleegkundige categorie, "telt mee in verpleegoverzicht" — de dimensies *wie schreef het (discipline)*, *wat voor soort inhoud* en *in welke weergave hoort het* zijn niet gescheiden.
3. `intake` en `behandeladvies` als rapporttype dupliceren entiteiten die in de discovery al een eigen plek hebben (intake, screeningsbesluit/behandelplan) — een verslag *over* een intake is iets anders dan de intake zelf.
4. Geen mutatiehistorie: een gewijzigde rapportage is juridisch een gewijzigd dossier; WGBO-correctiesystematiek en de append-only-auditregel (3.1 #3) vragen om versies of een expliciet wijzigingsspoor.
5. `shift_date` half toegepast (alleen verpleegkundig) en de 07:00-grens is hardcoded.
6. Incident-type dekt noch de art.-10-velden (aard/toedracht/tijdstip/betrokkenen), noch het VIM-spoor.
7. Geen cliëntzichtbaarheids-dimensie, terwijl Wabvpz-inzage en portaaldeling per type gangbaar zijn.
---
## 9. Implicaties voor het datamodel (voorstel, geen besluit)
### 9.1 Kern-entiteit RAPPORTAGE
- Hangt aan **CLIENT** én (vrijwel altijd) aan **ZORGEPISODE** (consistent met besluiten §5.1 #9, §5.4 #2). Open: mag een rapportage zonder episode bestaan (bijv. tijdens screening/aanmeldfase)?
- **Rapportagetype uit een waardelijst** (referentietabel), met per type configuratie: structuurtemplate (vrij/SOEP/DAP/...), min/max-lengte, standaard-cliëntzichtbaarheid, telt-mee-in-overdracht, toegestane disciplines. Dit vervangt de drie hardcoded lijsten van het prototype en volgt het Nedap-patroon "rapporttypen zijn beheerconfiguratie".
- **Tekst + structuur in één record** (§3.2): verplichte vrije tekst; optionele gestructureerde secties per methodiek als aparte velden of een getypeerde sectietabel (sectiecode uit waardelijst: S/O/E/P, D/A/P, T/I/P) — zodat methodiekwissel configuratie is, geen migratie.
- **Auteur en accordering**: auteur verplicht (mens of AI met provenance conform 3.1 #2); status `concept → definitief`; na definitief geen stille edits — correctie = nieuwe versie of aanvulling, cliëntaanvulling (WGBO) als eigen record/vlag.
- **Referenties**: 0..1 contactmoment/consult (relatie met ZPM-registratie, §1.5), 0..n behandeldoelen (met optionele voortgangsindicatie per doel, §4), 0..1 behandelplan (voor evaluatieverslagen), 0..1 intake (verslag-over).
### 9.2 Overdracht en diensten
- `include_in_handover`-markering behouden als vlag óf afleiden via typeconfiguratie.
- **Dienst/dagdeel** (nacht/ochtend/middag/avond) als waardelijst; de shift-toewijzingsgrens (07:00) als instellingsconfiguratie, niet hardcoded. Shift-datum consequent voor alle rapportages die in dienstweergaven meedoen.
- De **overdracht zelf** (al dan niet AI-samengevat) is een afgeleid product; als hij wordt vastgelegd, dan met provenance en bronverwijzingen naar de onderliggende rapportages (spelregel 3.1 #2 + TIP-snapshotafspraak §3.3).
- MDO-verslag: rapportagetype op episodeniveau, meerdere betrokken disciplines vastlegbaar.
### 9.3 Incident
- Dossieraantekening incident = rapportagetype met gestructureerde art.-10-velden: aard, toedracht, tijdstip, betrokkenen; incidentcategorie uit waardelijst (agressie, medicatie, val, suïcide(poging), vermissing, seksueel grensoverschrijdend, overig).
- VIM-melding = aparte entiteit buiten het cliëntdossier (eigen autorisatie en levenscyclus), optioneel gelinkt aan de dossieraantekening. Calamiteit/IGJ-melding als status/escalatie op de VIM-melding. **Open besluit: hoort VIM in het ECD-domein of erbuiten?**
- Nudge-kansen: "incident met merkbare gevolgen zonder dossieraantekening", "calamiteit → IGJ-termijn 3 werkdagen".
### 9.4 Zichtbaarheid en rechten
- Per rapportage: zichtbaarheidsvlag voor cliëntportaal (default per type), wetende dat het Wabvpz-inzagerecht altijd blijft bestaan — de vlag stuurt portaalweergave, geen juridische afscherming.
- Vertrouwelijkheid per deskundigheid (Nedap-patroon "groen slotje") → rollenronde.
- Persoonlijke werkaantekeningen: **geen dossier-entiteit** (NIP); bewust buiten scope houden of als expliciet niet-dossier-domein modelleren.
- Bewaartermijn: 20 jaar vanaf laatste dossierwijziging → het batchjob-criterium van spelregel 3.1 #4 moet op *dossierniveau* rekenen, niet per record.
### 9.5 Kandidaat-feitzinnen (startlijst voor de rapportage-ronde)
1. *Voor de zorgepisode van Jan de Vries is op 2 augustus 2026 een rapportage van type "voortgang" vastgelegd door psycholoog M. de Boer.*
2. *De rapportage van 2 augustus is geschreven volgens structuur "SOEP".* / *...heeft als vrije tekst "..." en als sectie "Plan" de tekst "...".*
3. *De rapportage van 2 augustus hoort bij het contactmoment (consult) van 2 augustus 2026.*
4. *De rapportage van 2 augustus rapporteert op behandeldoel "weer drie nachten doorslapen" met voortgang "licht verbeterd".*
5. *De rapportage van 2 augustus heeft status "definitief" sinds 2 augustus 2026, 17:04.*
6. *Verpleegkundige K. Jansen heeft op 3 augustus 2026 om 06:30 een verpleegkundige notitie vastgelegd; deze telt bij de dienst van 2 augustus (nachtdienst).*
7. *De verpleegkundige notitie is gemarkeerd voor de overdracht.*
8. *De rapportage van 2 augustus is zichtbaar voor de cliënt in het portaal.*
9. *Rapportage Y is gegenereerd door AI-model Z op basis van bronnen A en B, en op 3 augustus bevestigd door M. de Boer.* (= feitzin 9 uit discovery §5.2)
10. *Op 5 augustus 2026 om 21:15 heeft zich een incident van categorie "medicatie-incident" voorgedaan rond cliënt Jan de Vries; aard, toedracht en betrokkenen zijn in het dossier aangetekend.*
11. *Voor het incident van 5 augustus is een VIM-melding gedaan; de VIM-melding heeft status "in analyse".*
12. *Cliënt Jan de Vries heeft op 6 augustus 2026 een eigen verklaring aan zijn dossier laten toevoegen.*
13. *Het MDO van 1 september 2026 over de zorgepisode van Jan de Vries is vastgelegd in een MDO-verslag, met betrokken disciplines psychiatrie en verpleegkunde.*
### 9.6 Open vragen voor de sessie met Colin
1. Rapportage zonder zorgepisode toestaan (screeningsfase)? Of hangt vroege verslaglegging aan de AANMELDING?
2. Welke rapportagetypen in de startwaardelijst — en vervallen `intake`/`behandeladvies` als rapporttype ten gunste van de eigen entiteiten?
3. Structuurmethodiek: alleen vrije tekst + optionele secties, of SOEP/DAP/TIP als eersteklas sectiemodel?
4. Versiebeheer rapportage: nieuw record per versie of muteren-met-audittrail (zelfde vraag als behandelplan §5.5)?
5. VIM binnen of buiten het ECD? Zo binnen: autorisatiemodel dat het uit het cliëntdossier houdt.
6. Is "definitief maken" (accorderen) een verplichte stap, en zit daar een termijn-nudge op ("verslag nog concept na X dagen")?
7. Dienstgrenzen (07:00 e.d.) per instelling of per afdeling configureerbaar?
---
## Bronnen (samengevat)
**Wet & toezicht:** [KNMG-richtlijn Omgaan met medische gegevens 2024](https://www.knmg.nl/download/knmg-richtlijn-omgaan-met-medische-gegevens-2) · [KNMG wijzigingen WGBO](https://www.knmg.nl/advies-richtlijnen/dossiers/behandelingsovereenkomst-wgbo/wijzigingen-wgbo.htm) · [Rijksoverheid bewaartermijn](https://www.rijksoverheid.nl/onderwerpen/rechten-van-patient-en-privacy/uw-medisch-dossier/bewaren-medisch-dossier) · [AP rechten dossier](https://www.autoriteitpersoonsgegevens.nl/en/themes/health/health-data-in-a-file/rights-regarding-the-health-data-file) · [Eldermans & Geerts Wabvpz](https://www.eldermans-geerts.nl/per-1-juli-2020-het-recht-op-elektronische-inzage-in-en-afschrift-van-het-medisch-dossier/) · [Holla Wkkgz-meldingen](https://www.holla.nl/nieuws/wkkgz-meldingen) · [IGJ calamiteiten](https://www.igj.nl/onderwerpen/klachten-en-melden/calamiteiten/melding-doen-van-een-calamiteit) · [IGJ suïcidemeldingen ggz](https://www.igj.nl/onderwerpen/klachten-en-melden/suicidepoging) · [Landelijk Kwaliteitsstatuut GGZ 4.0](https://www.zorginzicht.nl/binaries/content/assets/zorginzicht/kwaliteitsinstrumenten/landelijk-kwaliteitsstatuut-ggz-4.0.pdf) · [ZPM spelregels registreren/declareren](https://www.zorgprestatiemodel.nl/content/uploads/2023/07/20230628-Spelregels-correct-registreren-en-declareren_definitief.pdf)
**Beroepsgroepen:** [V&VN Richtlijn Verslaglegging](https://kennisplatform.venvn.nl/onderwerp/verslaglegging/) · [NIP dossiervorming](https://www.psynip.nl/uw-beroep/cotan/cotan-beoordelingssysteem-ast-en-beroepscode/algemene-standaard-testgebruik-nip-2017/2-2-onderzoeksprocedure/2-2-2-dossiervorming/) · [NIP persoonlijke werkaantekeningen](https://www.psynip.nl/uw-beroep/cotan/cotan-beoordelingssysteem-ast-en-beroepscode/algemene-standaard-testgebruik-nip-2017/2-2-onderzoeksprocedure/2-2-4-persoonlijke-werkaantekeningen/) · [NVvP wet- en regelgeving](https://www.psychiatrie.nl/alle-themas/wet-en-regelgeving/) · [Verenso handreiking MDO](https://www.verenso.nl/kwaliteit/richtlijnen-en-praktijkvoering/richtlijnendatabase/multidisciplinair-overleg-mdo)
**Methodieken:** [Verslagleggen in de GGZ — SOEP](https://www.verslagleggenindeggz.nl/blog/de-soep-methode-hoe-pas-je-die-toe-in-een-voortgangsrapportages/) · [Verslagleggen in de GGZ — SOEP/SOAP/TIP](https://www.verslagleggenindeggz.nl/blog/soep-soap-of-tip-wat-is-een-handige-opbouw-voor-clientrapportages/) · [NHG SOEP-verslag](https://referentiemodel.nhg.org/node/19) · [Headway DAP notes](https://headway.co/resources/dap-note) · [SimplePractice DAP](https://www.simplepractice.com/resource/how-to-write-dap-notes/) · [eNurse SBAR](https://enurse.nl/2019/02/24/sbar-methode/)
**ECD-praktijk:** [Nedap Ons cliëntrapportages](https://support.nedap-ons.nl/support/solutions/articles/103000266173-cli%C3%ABntrapportages-in-ons-dossier-toegelicht) · [Nedap Ons rapporttypen configureren](https://support.nedap-ons.nl/support/solutions/articles/103000265596-rapportages-voor-ons-dossier-configureren) · [Nedap Ons rapporteren op doelen](https://support.nedap-ons.nl/support/solutions/articles/103000266084-rapporteren-op-doelen-en-voortgang-in-het-zorgplan-in-ons-dossier) · [Carecheck verslaglegging GGZ](https://carecheck.nl/verslaglegging-in-ggz/) · [Kuno behandelverslag](https://www.heykuno.com/nl/blog/ggz-behandelverslag/) · [Nictiz eOverdracht](https://www.nictiz.nl/informatiestandaarden/eoverdracht/) · [Medicore ECD](https://medicore.nl/medicore-producten/ecd/)

214
docs/datamodel/onderzoek/onderzoek-standaarden.md Normal file
View File

@@ -0,0 +1,214 @@
# Onderzoek NL-zorgstandaarden als checklist voor het ECD-datamodel
**Status:** onderzoeksrapport (agent "standaarden")
**Datum:** 18 juli 2026
**Kader:** conform discovery §4 — standaarden zijn *koppelvlak- en uitwisselingszaken*, geen datamodel-regels. Doel per standaard: welke velden/structuren moet ons eigen model minimaal kunnen uitdrukken om later goedkoop te koppelen. Geen enkele standaard wordt als model overgenomen.
---
## 1. Leeswijzer en conclusie vooraf
Per standaard beantwoordt dit rapport drie vragen: (a) wat is het en wie beheert het, (b) welke structuren/velden zijn relevant voor ons domein, (c) wat betekent dat concreet als *checklist* voor het eigen model. Hoofdconclusies:
1. **zibs zijn de goedkoopste checklist** voor klinische entiteiten — maar let op: de zib-wereld is in beweging (publicatie 2024 verving o.a. de zib Probleem door Diagnose/Symptoom/AandoeningOfGesteldheid), terwijl de FHIR-implementatiewereld (nl-core) nog op zib-release **2020** zit. Semantisch aansluiten bij zibs ≈ automatisch goedkoop richting FHIR.
2. **Er bestaat géén zib "Verwijzing".** Verwijzing is in NL geregeld via NZa-regels + veldafspraken (verwijstypen 01–07) en de NHG-richtlijn informatie-uitwisseling huisarts-ggz. Onze VERWIJZER/AANMELDING-entiteiten moeten die administratieve werkelijkheid kunnen uitdrukken, niet een zib.
3. **Het Zorgprestatiemodel stelt de hardste eisen** aan wat het model straks moet kunnen: zorgtrajectnummer, prestatiecode-bepalende velden per consult (beroep, type, duur, setting), verwijstype, zorglabels en zorgvraagtypering (HoNOS+). Dit valideert het besluit ZORGEPISODE als eigen entiteit (§5.1 #9) — mits de episode later een ZPM-zorgtraject kan dragen.
4. **DSM-5-TR → ICD-10**: de officiële afleiding bestaat als beheerde codelijst (WHO-FIC Collaborating Centre NL / RIVM). Het discovery-besluit "DSM als bronregistratie, ICD-10 afgeleid via mappingtabel" (§5.4 #1) is exact hoe de keten het bedoeld heeft. Twee risico's: licentie (DSM is auteursrechtelijk van APA/Boom) en versiegeldigheid van de codelijst.
5. **Koppeltaal 2.0** raakt het ECD-model nauwelijks in de kern — het is een FHIR R4-berichtendomein voor eHealth-taken. Vereist wel: stabiele ID's voor cliënt/behandelaar en het kunnen uitdrukken van "toegewezen eHealth-activiteit" (raakt de behandelplan-interventies).
6. **iWmo/iJw** (gemeente-gefinancierde zorg, o.a. jeugd-GGZ) valideert het besluit "wettelijk kader hoort bij de aanmelding" (§5.0 #4): per kader gelden totaal andere administratieve objecten (beschikking/toewijzing/305-307-berichten i.p.v. verwijsbrief/zorgtraject).
---
## 2. Zibs / Nictiz
### 2.1 Wat en wie
Zorginformatiebouwstenen (zibs) zijn semantische definities van klinische begrippen (datamodel + waardelijsten + terminologiebindingen), beheerd door **Nictiz**. Vastgesteld als nationale standaard (Informatieberaad Zorg, 2018). Publicaties per jaar; de actuele grote release is **zib-publicatie 2024**; de meeste implementaties (FHIR nl-core, MedMij) zijn nog gebaseerd op **release 2020** (en Basisgegevens GGZ zelfs op 2017).
Bronnen: [Nictiz — wat is een zib](https://www.nictiz.nl/wat-we-doen/activiteiten/zibs/wat-is-een-zib/) · [zibs.nl publicatie 2024](https://www.zibs.nl/wiki/ZIB_Publicatie_2024(NL)) · [Registratie aan de bron](https://www.registratieaandebron.nl/zorginformatiebouwstenen)
**Belangrijke wijziging in publicatie 2024** ([bron](https://www.zibs.nl/wiki/ZIB_Publicatie_2024(NL))): de zib **Probleem is vervallen** en vervangen door drie nieuwe zibs: **AandoeningOfGesteldheid v1.1**, **Diagnose v2.0** en **Symptoom v2.0**. Ook AllergieIntolerantie en MedicatieContraIndicatie zijn vervangen. Relevante versies 2024: Patient v4.3, Contactpersoon v5.0, Behandeldoel v4.0, BehandelAanwijzing2 v2.1, TekstUitslag v4.4, Zorgverlener v4.0.1, Zorgaanbieder v3.6, Contact v7.0.
### 2.2 Relevante zibs per onderwerp (checklist)
**zib Patient v4.3** ([zibs.nl](https://zibs.nl/wiki/Patient-v4.3(2024NL))) — kernelementen: Identificatienummer 0..* (BSN via OID 2.16.840.1.113883.2.4.6.3), Naamgegevens 1 (achternaam, voorvoegsels, voornamen, initialen, roepnaam), Adresgegevens 0..*, Contactgegevens 0..1 (telefoon/e-mail), Geboortedatum 1, Geslacht 1 (codelijst), **Genderidentiteit 0..1** (nieuw t.o.v. oudere versies), MeerlingIndicator, OverlijdensIndicator + DatumOverlijden.
→ *Checklist PERSOON*: BSN als herhaalbaar identificatienummer-patroon (wij: één BSN, versleuteld — voldoende), gestructureerde naam (niet één naamveld!), meerdere adressen mogelijk, geslacht als code uit waardelijst, overlijden als expliciet feit. Genderidentiteit apart van geslacht is voor GGZ relevant — overwegen als optioneel veld.
**zib Contactpersoon v5.0** ([2024-publicatie](https://www.zibs.nl/wiki/ZIB_Publicatie_2024(NL)); v4.1-pagina: [zibs.nl](https://www.zibs.nl/wiki/Contactpersoon-v4.1(2024NL))) — kern: naam/adres/contactgegevens + **twee gescheiden assen**: *Relatie* (echtgenoot, ouder, kind, …) en *Rol* (eerste contactpersoon, wettelijk vertegenwoordiger, mantelzorger, …), beide uit waardelijsten.
→ *Checklist*: het discovery-besluit PERSOON/rollen (§5.1 #1) past hier perfect: contactpersoon wordt straks een rol op PERSOON met twee attributen (relatie + rol) uit waardelijsten — niet één "type"-veld. Wettelijk vertegenwoordiger is in de GGZ (Wvggz, WGBO, jeugd) een must-have rolwaarde.
**Verwijzing — géén zib.** In geen enkele zib-publicatie bestaat een bouwsteen "Verwijzing". De inhoudseisen aan een verwijzing komen uit de **NHG-richtlijn Informatie-uitwisseling huisarts-ggz** en de **verwijsafspraken ggz** (veldafspraak zorgprestatiemodel): AGB-code verwijzer, (vermoeden van) DSM-benoemde psychische stoornis, echelon (basis-ggz vs gespecialiseerde ggz), en of het een heraanmelding betreft; geldigheid **9 maanden (275 dagen) tot aanmelddatum** bij de GGZ-aanbieder. Bij onvolledige verwijzing: inspanningsverplichting om info op te halen, aantoonbaar in dossier, behandeling mag wel starten.
Bronnen: [LVVP — eisen verwijsbrief](https://lvvp.info/nieuws/welke-eisen-worden-gesteld-aan-de-verwijsbrief/) · [Verwijsafspraken GGZ (zorgprestatiemodel, nov 2021)](https://www.zorgprestatiemodel.nl/content/uploads/2021/11/Verwijsafspraken-GGZ_november-2021.pdf) · [Zilveren Kruis — verwijzing naar GGZ](https://www.zilverenkruis.nl/zorgaanbieders/zorgsoort/ggz/declareren/verwijzing-naar-ggz)
→ *Checklist AANMELDING/VERWIJZER*: verwijsdatum én aanmelddatum apart (geldigheidstoets), AGB verwijzer + AGB praktijk (besluit §5.1 #3 klopt), echelon-indicatie, heraanmelding-vlag, vermoeden-DSM-stoornis (vrije tekst of code), en het ZPM-**verwijstype** (zie §6.3) als af te leiden/registreerbaar gegeven.
**Probleem → Diagnose v2.0 (2024)** ([zibs.nl](https://www.zibs.nl/wiki/Diagnose-v2.0(2024NL))) — kern: DiagnoseNaam 1..* (codelijst: SNOMED CT, ICD-10-nl, DHD-thesaurus, ICF, ICPC-1, **DSM-IV/DSM-5** worden expliciet genoemd als toegestane codesystemen), DiagnoseStatus 1 (codelijst), DiagnoseDatum 1, DiagnoseSteller 1 (verwijzing Zorgverlener), WijzeVanVaststellen 1, Toelichting 0..1, Aanleiding 0..*, AandoeningOfGesteldheid 0..1 (verwijzing). De oude zib Probleem (2020, gebruikt in Basisgegevens GGZ) kende daarnaast ProbleemType, ProbleemStatus (actueel/niet-actueel) en verificatiestatus-achtige noties die in FHIR als `clinicalStatus`/`verificationStatus` terugkomen.
→ *Checklist DIAGNOSE*: code + codesysteem + weergavenaam als drieluik (nooit alleen een code-string), datum gesteld, steller, status als aparte as, toelichting. Het discovery-model (§5.4: verificatiestatus + klinische status als twee assen) is uitdrukbaar in zowel zib 2020 (Probleem) als FHIR Condition — houden zo. DSM-5 is een erkend codesysteem binnen de zib — DSM-bronregistratie botst dus niet met de standaardenwereld.
**zib Behandeldoel v4.0** ([zibs.nl](https://www.zibs.nl/wiki/Behandeldoel-v4.0(2024NL))) — kern: **GewenstZorgresultaat** (tekstuele weergave van het doel), GewensteGezondheidstoestand 0..1 (verwijzing FunctioneleOfMentaleStatus), en een RedenBehandeling-container die verwijst naar Diagnose / Symptoom / VerpleegkundigeDiagnose / OvergevoeligheidIntolerantie. Oudere versie (2020, in FHIR nl-core) kent ook streefdatum en evaluatie-relatie.
→ *Checklist BEHANDELDOEL*: doel als tekst + expliciete **relatie doel → diagnose/probleem** (discovery-feitzin §5.5 #3 "adresseert diagnose F32.1" — dit moet een echte FK-relatie worden, geen tekst), streefdatum/termijn, en evalueerbaarheid. Onze extra's (cliëntversie B1, prioriteit, leefgebied) zijn eigen verrijkingen bovenop het zib-minimum — prima, exporteerbaar als extensie.
**zib BehandelAanwijzing2 v2.1** ([zibs.nl](https://www.zibs.nl/wiki/BehandelAanwijzing2-v2.1(2024NL))) — kern: Behandeling (codelijst: reanimatie, beademing, opname, …), BehandelBesluit (wel uitvoeren / niet uitvoeren / anders + SpecificatieAnders), MeestRecenteBespreekdatum, DatumBeeindigd + RedenBeeindigd, AfspraakPartij (patiënt / vertegenwoordiger / zorgverlener). Hangt samen met zib Wilsverklaring.
→ *Checklist*: behandelaanwijzingen/wilsverklaringen zitten nog niet in discovery-ronde 1 — voor een GGZ-ECD (crisis, Wvggz-context) op de roadmap zetten. Minimum om te kunnen uitdrukken: welke behandeling, wel/niet-besluit, met wie afgesproken, laatst besproken, beëindigd + reden. Let op patroon: **"anders"-optie met specificatieveld** i.p.v. dichte enum — nuttig ontwerppatroon voor onze waardelijsten.
**zib TekstUitslag v4.4** ([zibs.nl](https://www.zibs.nl/wiki/TekstUitslag-v4.4(2024NL))) — kern: TekstResultaat 1 (het verslag), TekstUitslagType 1 (code), TekstUitslagDatumTijd 0..1, TekstUitslagStatus 0..1 (pending/preliminary/**final**/corrected), Verrichting 0..1, VisueelResultaat 0..*.
→ *Checklist VERSLAG/RAPPORTAGE* (latere ronde): elk verslag heeft type (code), datum, status met minimaal concept/definitief/gecorrigeerd, en gestructureerde koppeling aan de aanleiding. Sluit naadloos aan op discovery-spelregel 3.1 #2 (provenance) en de AI-voorbereiding (tekst + structuur in één record).
**GGZ-specifiek relevant, buiten de gevraagde lijst:** de **Basisgegevens GGZ** (MedMij/PGO-informatiestandaard, [functioneel ontwerp](https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpGGZ), [inhoud](https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_InhoudGGZ)) is een selectie van ~24 zibs (release 2017) die de sector zelf als kern voor GGZ-uitwisseling heeft aangemerkt: Patient, Burgerlijke Staat, Betaler, **BehandelAanwijzing, Wilsverklaring, JuridischeStatus** (Wvggz!), Contactpersoon, FunctioneleOfMentaleStatus, Probleem, **Drugsgebruik, Alcoholgebruik, Tabakgebruik**, Woonsituatie, Gezinssituatie(Kind), Taalvaardigheid, ParticipatieInMaatschappij, HulpVanAnderen, LaboratoriumUitslag, AlgemeneMeting, Verrichting, TekstUitslag, Zorgverlener, Zorgaanbieder. Dit is de facto de checklist "wat verwacht een PGO/keten van een GGZ-dossier".
→ Voor ons model: **JuridischeStatus** (rechterlijke machtiging/Wvggz-maatregel) en de leefstijl-/sociale-context-zibs zijn kandidaten voor latere rondes; nu alleen borgen dat het model ze als aparte entiteiten kán toevoegen (episodisch, met begin/eind en bron).
---
## 3. FHIR NL: zib-profielen en nl-core (R4)
**Wat en wie:** Nictiz publiceert twee R4-packagelijnen op basis van zib-release 2020, gevet door HL7 Nederland ([GitHub Nictiz-R4-zib2020](https://github.com/Nictiz/Nictiz-R4-zib2020)):
- `nictiz.fhir.nl.r4.zib2020` — 1-op-1 representatie van de zibs, **abstract**, niet voor implementatie ([Simplifier](https://simplifier.net/packages/nictiz.fhir.nl.r4.zib2020/0.11.0-beta.1)).
- `nictiz.fhir.nl.r4.nl-core` — de **implementatieprofielen** (afgeleid van de zib-profielen, verrijkt met o.a. expliciete Patient-referenties), dit is wat je in een adapter gebruikt ([Simplifier](https://simplifier.net/packages/nictiz.fhir.nl.r4.nl-core/) · voorbeeld [nl-core-Patient](https://hl7nl.github.io/Nictiz-R4-zib2020-IG/StructureDefinition-nl-core-Patient.html)).
Relevante mapping onderwerpen → FHIR-resources: Patient→`Patient` (nl-core-Patient), Contactpersoon→`Patient.contact`/`RelatedPerson`, Probleem/Diagnose→`Condition` (met `clinicalStatus` + `verificationStatus` — exact onze twee status-assen), Behandeldoel→`Goal`, BehandelAanwijzing→`Consent`/ACP-profielen, TekstUitslag→`DiagnosticReport`/`DocumentReference`, Verwijzing→`ServiceRequest` (geen zib, wel een FHIR-resource), Zorgepisode→`EpisodeOfCare`, Behandelplan→`CarePlan`.
→ *Checklist (adapter-goedkoopte, geen modeleis):*
- Overal **stabiele UUID's** (spelregel 3.1 #5) — FHIR-resources hebben een logical id nodig; onze UUID's kunnen 1-op-1 mee.
- Codes altijd als **(code, systeem, display)** opslaan, nooit alleen een label — FHIR `CodeableConcept` is dan een triviale projectie. Dit is dezelfde les als spelregel 3.1 #1 (waardelijsten als data): geef elke waardelijstrij optioneel een externe code + codesysteem-URI kolom.
- Status-assen gescheiden houden (klinisch vs verificatie op diagnose; plan-status vs cliëntakkoord op behandelplan — FHIR CarePlan kent `status` en separaat `Consent`).
- Versies: nl-core R4 is formeel nog beta (0.x); niets in beton gieten, alleen semantisch niet nodeloos afdrijven (discovery §4, aandachtspunt).
---
## 4. Koppeltaal 2.0 (GGZ-specifiek)
**Wat en wie:** Koppeltaal is de GGZ-standaard + infrastructuur (beheer: **VZVZ**, eigenaar: Stichting Koppeltaal) om **EPD/ECD, ROM-vragenlijsten en eHealth-modules** binnen een "domein" van een zorgaanbieder te verbinden. Koppeltaal 2.0 is **FHIR R4**-gebaseerd; profielen staan op Simplifier ([project koppeltaalv2.0](https://simplifier.net/koppeltaalv2.0)), documentatie in de [Koppeltaal 2.0 Dev Guide](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide) en op [koppeltaal.nl](https://www.koppeltaal.nl/koppeltaal/koppeltaal-20).
**Kernresources/-profielen** (KT2-profielen, o.a. KT2Patient, KT2Practitioner, KT2CareTeam, KT2Task, [KT2ActivityDefinition](https://simplifier.net/Koppeltaal/KoppeltaalActivityDefinition), Endpoint, Device, Subscription; de server dwingt profielconformiteit af, bijv. op [KT2Task](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide/hackathon-use-cases/crud-task/use-case-1-opvoeren-taak)):
- **ActivityDefinition** — een aanbieder publiceert een eHealth-activiteit (module, vragenlijst, game) domeinbreed.
- **Task** — toewijzing van zo'n activiteit aan een specifieke cliënt, altijd gebaseerd op een ActivityDefinition; aangemaakt vanuit het behandelaarportaal/ECD. Status-lifecycle: `completed|cancelled|failed|rejected`; resources worden **niet verwijderd** maar end-of-life gemarkeerd (ActivityDefinition `retired`) — zelfde filosofie als onze soft delete ([resources managen](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide/technische-howto/resources-managen)).
- **Patient/Practitioner/RelatedPerson/CareTeam** — identiteiten binnen het domein; **Endpoint/Device** — aangesloten applicaties; **Subscription** — notificaties bij wijzigingen; launch via **HTI** (Health Tools Interoperability, JWT-gebaseerd).
→ *Checklist ECD-model:*
1. CLIENT en BEHANDELAAR moeten met stabiele ID's naar buiten te refereren zijn (hebben we: UUID's) en Koppeltaal-traceerbaarheid vergt geen extra ECD-velden.
2. Het behandelplan-deel "interventies" (discovery §5.5) moet een interventie kunnen typeren als **eHealth-activiteit met externe referentie** (welke module, bij welke aanbieder, welke taak-status). Minimaal: een optioneel extern-referentieveld (systeem + id) op interventie/activiteit — dan is een Koppeltaal-adapter later een dunne laag.
3. Taak-/opdrachtstatus (toegewezen → gestart → afgerond/geannuleerd) is proces-state: kandidaat-**TIP-terrein** (grensvlak §3.3), niet per se ECD. De klinische uitkomst (bijv. ROM-uitslag) is wél ECD.
---
## 5. DSM-5-TR → ICD-10-mapping
**Hoe de officiële mapping werkt en wie hem beheert:**
- De **DSM-5-TR** zelf is van de American Psychiatric Association; de Nederlandse vertaling/uitgave ligt bij **Boom uitgevers** ([boom.nl](https://www.boom.nl/psychiatrie/101-4_DSM-5-TR)). Auteursrecht en licenties lopen via APA/Boom — de Nederlandse Staat had voor keten-gebruik een licentie ([whofic.nl](https://www.whofic.nl/dsm-5icd-10)).
- Het **WHO-FIC Collaborating Centre Nederland** (ondergebracht bij RIVM) beheert en publiceert de **"Codelijst DSM-5(-TR) met ICD-10 afleidingen"**: per DSM-classificatie de afgeleide ICD-10-code(s) ([whofic.nl — DSM-5/ICD-10](https://www.whofic.nl/dsm-5icd-10) · [codelijst-document](https://www.whofic.nl/documenten/codelijst-dsm-5-tr-met-icd-10-afleidingen)). De DSM-5-TR gebruikt in de VS ICD-10-CM-codes; de NL-codelijst leidt af naar ICD-10 zoals in NL gebruikt. De lijst is versioneerd met ingangs- en einddatum (bijv. publicatie 15-12-2023, geldig per 1-1-2024; die versie is niet meer geldig vanaf 1-1-2026 — er verschijnen dus periodiek opvolgers).
- Gebruiksbeperking: de codelijst mag **uitsluitend** worden gebruikt in "declaratie-, registratie- en informatiesystemen van de ggz en fz" ten behoeve van NZa-regelgeving; ander gebruik vereist afstemming met Boom ([whofic.nl](https://www.whofic.nl/documenten/codelijst-dsm-5-tr-met-icd-10-afleidingen)).
- Voor de relatie met NZa-diagnosehoofdgroepen bestaat aanvullend een afleiding DSM-hoofdgroep/ICD-10 → NZa-diagnosehoofdgroep ([beta.nl/ggzdiagnosen](https://beta.nl/ggzdiagnosen/)).
**Registratieplicht in beweging (2024–2028):** de NZa-verplichting om DSM-gegevens op de factuur te zetten kreeg per 1-1-2025 een juridisch probleem (grondslag); sindsdien geldt: aanlevering DSM-hoofdgroep aan verzekeraars alleen met **getekende toestemmingsverklaring (opt-in)** van de patiënt, en VWS heeft per aparte ministeriële regeling ([Stcrt. 2025-11955](https://zoek.officielebekendmakingen.nl/stcrt-2025-11955.html)) de registratie-/aanleverplicht van DSM-hoofdgroep of basis-ggz-profiel op de factuur richting 2027/2028 geborgd. In het risicoverevenings-/bekostigingsdenken vervangt **zorgvraagtypering** op termijn de DSM-rol ([zorgprestatiemodel.nl — opt-in](https://www.zorgprestatiemodel.nl/nieuws/tijdelijke-toestemmingsverklaring-opt-in-voor-vermelden-van-gegevens-over-de-dsm-hoofdgroepdiagnose-of-het-basis-ggz-profiel-op-factuur/) · [zorgictzorgen.nl](https://zorgictzorgen.nl/grondslag-ggz-declaraties-per-2025-durft-nza-niet-te-wijzigen/)).
→ *Checklist DIAGNOSE (bevestigt discovery-besluit §5.4 #1, met verscherping):*
1. **Bronregistratie in DSM-5-TR-termen; ICD-10 afgeleid via de WHO-FIC-codelijst** — als geïmporteerde, **versioneerde referentietabel** (kolommen minimaal: DSM-code, DSM-omschrijving, afgeleide ICD-10-code(s), ingangsdatum, einddatum, lijstversie). Nooit hardcoden.
2. Op het diagnoserecord vastleggen **met welke lijstversie** de afleiding is gedaan (reproduceerbaarheid bij herdeclaratie/controle).
3. Eén DSM-code kan naar **meerdere ICD-10-codes** leiden (en vice versa) — de mappingrelatie is m:n; het model moet dat aankunnen (aparte mappingtabel, geen kolom "icd10_code" met uniciteitsaanname).
4. **DSM-hoofdgroep** als afleidbaar gegeven (voor factuur/verzekeraar) + een plek voor de **opt-in-toestemmingsverklaring** van de cliënt (raakt privacy/toestemmings-entiteit — latere ronde, wel als open punt noteren).
5. **Open punt licentie (nieuw, geen teruggedraaid besluit):** commercieel gebruik van DSM-omschrijvingen in een ECD-product vereist vermoedelijk een licentie bij Boom/APA; de WHO-FIC-codelijst is alleen vrij voor NZa-doeleinden. Uitzoeken vóór de bouw van de diagnosemodule.
---
## 6. Zorgprestatiemodel (ZPM)
**Wat en wie:** bekostigingsmodel ggz/fz sinds 2022 (NZa + veldpartijen; programma [zorgprestatiemodel.nl](https://www.zorgprestatiemodel.nl)). Regelgeving: jaarlijkse NZa-regeling — voor 2026 is dat **NR-REG-2616b** met tariefbeschikking TB/REG-26628-05 en "Codetabel prestaties en tarieven v20260401" ([NZa — regels 2026](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz/welke-regels-gelden-voor-de-ggz-en-fz-in-2026) · [Registreren en declareren ggz/fz](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz) · [Veldafspraken 2025](https://www.zorgprestatiemodel.nl/content/uploads/2025/01/20250131-Veldafspraken-2025-.pdf)).
### 6.1 Zorgtraject
Het zorgtraject start zodra een patiënt zich met een psychische zorgvraag meldt; de aanbieder kent een **zorgtrajectnummer** toe en koppelt dat aan **alle** ggz-prestaties voor die patiënt tot einde behandeling. Bij terugval/recidive **binnen een jaar** na de laatste prestatie moet **hetzelfde zorgtrajectnummer** hergebruikt worden ([NZa](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz)). Prestaties zijn dag-gebonden (losse consulten/verblijfsdagen), niet 365-dagen-trajecten zoals de oude DBC's ([Informatiekaart ZPM](https://puc.overheid.nl/nza/doc/PUC_646523_22/)).
→ *Checklist ZORGEPISODE*: de episode moet een **zorgtrajectnummer** kunnen dragen (uniek per cliënt-aanbieder-zorgvraag), en de "terugval binnen 1 jaar → zelfde nummer"-regel betekent: episode-einde is geen harde afsluiting van het trajectnummer. Modelmatig: zorgtraject (ZPM/declaratie-object) en zorgepisode (klinisch object) zijn **verwant maar niet identiek** — discovery §5.1 #9 zegt al "sluit straks aan op het ZPM-zorgtraject (declaratie-ronde)"; dit onderzoek bevestigt: maak het t.z.t. een aparte, gekoppelde entiteit, forceer geen 1-op-1.
### 6.2 Prestatiecodes
De prestatiecode + het tarief van een consult wordt bepaald door **vier assen**: (1) **beroepscategorie** van de uitvoerder (NZa-beroepenlijst), (2) **type consult** (diagnostiek of behandeling), (3) **duur** (tijdsklassen "vanaf x minuten"; registratie op basis van *geplande* tijd, "planning = realisatie"-principe), (4) **setting** (o.a. ambulant kwaliteitsstatuut sectie II/III, outreachend, klinisch — met varianten hoog/laag). Daarnaast bestaan aparte prestaties voor verblijfsdagen, toeslagen (o.a. tolk) e.d. Codetabellen worden door de NZa gepubliceerd ([Toelichting tabellen ggz/fz](https://www.zorgprestatiemodel.nl/shared/content/uploads/2021/09/20210927-Toelichting-tabellen.pdf) · [Codetabel prestaties en tarieven](https://puc.overheid.nl/nza/doc/PUC_641029_22/4/) · [beroepenlijst-wijzigingen](https://www.zorgprestatiemodel.nl/nieuws/aanpassingen-in-beroepenlijst/)).
→ *Checklist* (grotendeels agenda/declaratie-rondes, maar het fundament ligt nu):
- Elk contactmoment/consult moet kunnen vastleggen: **uitvoerder + diens beroep** (referentie naar NZa-beroepenlijst als geïmporteerde tabel), **type** (diagnostiek/behandeling), **geplande duur**, **setting** (waardelijst per instelling-locatie). Discovery-contactmomenten (§5.2) hebben al type+uitvoerder; beroep-van-uitvoerder komt via de rollenronde — borgen dat MEDEWERKER straks een beroepscode uit een NZa-lijst kan dragen.
- Prestatie- en tariefcodetabellen zijn **jaarlijks wisselende referentiedata** met geldigheidsperioden → zelfde import-patroon als de DSM-codelijst (versie + ingangs-/einddatum). Nooit hardcoden (spelregel 3.1 #1).
### 6.3 Verwijstypen en zorglabels
De ZPM-veldafspraken definiëren **verwijstypen** (registratie naast de AGB-code van de verwijzer) ([Verwijstypen en zorglabels, jan 2022](https://www.zorgprestatiemodel.nl/content/uploads/2022/01/20220111-Verwijstypen-en-zorglabels.pdf)):
| Nr | Verwijstype |
|---|---|
| 01 | Verwijzing aanwezig (AGB initiële verwijzer) |
| 02 | Doorverwijzing (AGB verwijzende regiebehandelaar) |
| 03 | Geen verwijzing — uitzondering, verlate correspondentie (huisarts binnen 60 dagen informeren) |
| 04 | Geen verwijzing — patiënt staat correspondentie met huisarts niet toe |
| 05 | Geen verwijzing (factuur mag niet naar zorgverzekeraar) |
| 06 | Geen verwijzing, andere rechtmatigheidsgrond (alleen fz) |
| 07 | Verwijzing aanwezig, maar verwijzer heeft geen AGB-code (bijv. buitenlands) |
Daarnaast **zorglabels** op prestaties voor uitzonderingssituaties: publiek (N01–N04, NZa-regelgeving: o.a. overgang jeugd-ggz → Zvw, tolk-toeslag), generiek privaat (G01–G04, veldafspraken: o.a. uitzonderingen "minimale betrokkenheid regiebehandelaar", Ketenveldnorm levensloopfunctie, acute ggz buiten budget) en specifiek privaat (S01–S03, contractueel: o.a. digitale zorg).
→ *Checklist*: het discovery-verwijzertype (huisarts/specialist/gemeente/zelfaanmelding/… §5.0 #3) is een **ander begrip** dan het ZPM-verwijstype (01–07, een declaratiestatus van de verwijzing). Beide nodig: ons verwijzertype beschrijft *wie* verwijst; het ZPM-verwijstype is afleidbaar uit (aanwezigheid verwijzing × AGB × toestemmingsvlaggen) maar moet ook overschrijfbaar geregistreerd kunnen worden. Verwijstype 03/04 tonen bovendien twee feiten die het model moet kennen: "huisarts geïnformeerd op datum X" en "cliënt staat correspondentie met huisarts niet toe" (toestemmingsfeit!). Zorglabels: prestatie-niveau, declaratie-ronde — alleen borgen dat prestaties later 0..n labels uit een NZa-tabel kunnen dragen.
### 6.4 Zorgvraagtypering (HoNOS+)
Bij de start van een behandeling (en bij herijking) wordt een **HoNOS+**-vragenlijst afgenomen: **19 items, score 0–4** (items 1–12 = klassieke HoNOS, plus 13, A–E en Q). De NZa-**zorgvraagtyperingstool** (een door de NZa gepubliceerd algoritme) adviseert op basis daarvan zorgvraagtypes; de **behandelaar kiest** uiteindelijk zelf het zorgvraagtype (advies is niet bindend). Het zorgvraagtype staat verplicht op de factuur; sinds **1 juli 2023** worden zorgvraagtyperingsgegevens ook verplicht aan de NZa aangeleverd volgens de "Standaard voor gegevensaanlevering zorgvraagtypering" (na een AP-discussie over de rechtmatigheid, met privacyverklaring-optie voor de patiënt) ([Embloom — FAQ HoNOS+](https://www.embloom.nl/veelgestelde-vragen-over-de-honos/) · [NZa zorgvraagtyperingstool](https://www.zorgprestatiemodel.nl/nieuws/zorgvraagtyperingstool-nza-online/) · [algoritmeregister — zorgvraagtypering](https://algoritmes.overheid.nl/nl/algoritme/zb000158/97912239/zorgvraagtypering) · [NZa Q&A aanlevering](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/vraag-en-antwoord/vraag-en-antwoord-zorgvraagtypering) · [Standaard gegevensaanlevering (PUC_705646_22)](https://puc.overheid.nl/PUC/Handlers/DownloadDocument.ashx?identifier=PUC_705646_22&versienummer=2&type=pdf&ValChk=89nf2n26dv_DAuBfeXxRzVtQuS-8DOi3kmeb1fKvw5g1))
→ *Checklist* (nieuwe entiteit voor een latere ronde, hangt aan ZORGEPISODE):
- **Meetinstrument-afname** als generiek patroon: instrument (HoNOS+), afnamedatum, afnemer, 19 itemscores (0–4) als gestructureerde data.
- **Zorgvraagtypering** als apart record: geadviseerd(e) type(s) door algoritme (+ tool-/algoritmeversie!), gekozen type door behandelaar, datum, relatie naar de afname. Advies ≠ keuze — twee velden, en dit is een mooi voorbeeld van het provenance-patroon (spelregel 3.1 #2: algoritme-advies = AI/algoritme-herkomst, keuze = mens).
- Aanlevering NZa + privacyverklaring: raakt dezelfde toestemmings-/opt-outstructuur als §5.4 — één toekomstige toestemmingsentiteit kan beide dragen.
---
## 7. iStandaarden: iWmo en iJw (gemeente-gefinancierde zorg)
**Wat en wie:** de **iStandaarden** worden beheerd door **Zorginstituut Nederland**; iWmo (Wmo 2015) en iJw (Jeugdwet) regelen het berichtenverkeer tussen zorgaanbieders en gemeenten. Actuele release: **iWmo 3.2 / iJw 3.2** (in productie sinds 3 april 2023, big bang; geen nieuwe major release in 2025) ([istandaarden.nl](https://www.istandaarden.nl/) · [release iWmo 3.2](https://www.istandaarden.nl/iwmo/releases/release-iwmo-3.2) · [informatiemodel iJw 3.2](https://informatiemodel.istandaarden.nl/informatiemodel/ijw/3.2/processen/start-melden/)).
**Berichtenstructuur** (identiek patroon iWmo/iJw, verschil zit in wet, productcodes en enkele velden; [Heldy — iWmo uitgelegd](https://www.heldy.nl/kennisbank/wmo/iwmo-uitgelegd) · [iJw uitgelegd](https://www.heldy.nl/kennisbank/jeugdzorg/ijw-uitgelegd)):
- **301/302 Toewijzing**: gemeente wijst zorg toe (toewijzingsnummer, productcategorie/productcode, volume/frequentie, begindatum, ev. einddatum).
- **305/306 Start zorg**: aanbieder meldt werkelijke startdatum. **307/308 Stop zorg**: melding einde + reden.
- **303/304 Declaratie**: periodiek, per toewijzing; regels met productcode, volume, tarief; gemeente keurt per regel goed/af.
- Daarnaast verzoek om toewijzing (315/316) en regieberichten ([analyse regieberichten](https://www.istandaarden.nl/binaries/content/assets/istandaarden/iwmo/iwmo-3.1.0/analyse-08---regieberichten.pdf)).
- **Uitvoeringsvarianten**: inspanningsgericht (p×q), outputgericht, taakgericht — bepalen welke berichten gebruikt worden ([handreiking uitvoeringsvarianten](https://www.istandaarden.nl/binaries/content/assets/istandaarden/iwmo/handreiking-uitvoeringsvarianten-iwmo-en-ijw.pdf)).
→ *Checklist* (valideert discovery §5.0 #4: wettelijk kader op de aanmelding):
1. Bij kader **Jeugdwet/Wmo** is de "verwijzing" feitelijk een **beschikking/toewijzing van de gemeente** met eigen sleutelgegevens: gemeente(code), toewijzingsnummer, productcategorie + productcode, toegewezen volume/frequentie, begin-/einddatum. Discovery-besluit §5.1 #7 ("beschikking telt ook als verwijzing", waardelijst `verwijsdocument_type`) klopt — maar de toewijzing heeft méér structuur dan een document: op termijn een eigen entiteit TOEWIJZING onder de aanmelding/episode bij gemeentelijk kader.
2. Start-/stopdatum van zorg moeten als harde feiten uit het model af te leiden zijn (305/307 zijn direct te genereren uit episode-start en -einde + reden — beëindigingsredenen-waardelijst van de episode moet t.z.t. mappen op de iStandaarden-redenenlijst).
3. Productcodes zijn (net als ZPM-tabellen en DSM-codelijst) **externe, versioneerde referentiedata** per gemeente/regio — zelfde importpatroon.
4. Woonplaatsbeginsel (jeugd): de verantwoordelijke gemeente is een gegeven aan de aanmelding-/financieringskant, niet aan de persoon.
---
## 8. Geconsolideerde checklist per discovery-entiteit
| Entiteit (discovery) | Moet minimaal kunnen uitdrukken (uit standaarden) | Bron |
|---|---|---|
| PERSOON | gestructureerde naamdelen; meerdere adressen; geslacht (code) + evt. genderidentiteit; overlijden(sdatum); BSN als geïdentificeerd nummer | zib Patient |
| Rol CONTACTPERSOON (later) | relatie én rol als twee aparte waardelijsten; wettelijk vertegenwoordiger | zib Contactpersoon |
| VERWIJZER / PRAKTIJK | AGB persoonlijk + AGB praktijk (besloten); verwijzertype; "verwijzer zonder AGB" mogelijk | ZPM-verwijsafspraken |
| AANMELDING | verwijsdatum ≠ aanmelddatum (275-dagen-toets); echelon; heraanmelding-vlag; ZPM-verwijstype 01–07 (afleidbaar/overschrijfbaar); huisarts-geïnformeerd-feit + correspondentie-toestemming; bij Wmo/Jw: toewijzingsgegevens (gemeente, nummer, productcode, volume, periode) | ZPM, NHG, iWmo/iJw |
| ZORGEPISODE | koppelbaar aan ZPM-zorgtrajectnummer (hergebruik bij terugval <1 jaar → geen 1-op-1); start/stop + reden (iStd 305/307); draagt zorgvraagtypering | NZa-regeling, iStandaarden |
| DIAGNOSE | (code, systeem, display)-drieluik; DSM-bron + versioneerde m:n-mapping naar ICD-10 incl. lijstversie op het record; DSM-hoofdgroep afleidbaar; steller + datum + wijze van vaststellen; twee status-assen | zib Diagnose, WHO-FIC-codelijst, NZa |
| BEHANDELPLAN / DOEL | doel-tekst + FK naar diagnose; streefdatum/termijn; planstatus ≠ cliëntakkoord (apart feit); interventie met optionele externe eHealth-referentie (systeem+id) | zib Behandeldoel, FHIR CarePlan/Consent, Koppeltaal |
| CONTACTMOMENT (agenda-ronde) | uitvoerder + beroepscode (NZa-lijst); type diagnostiek/behandeling; geplande duur; setting; 0..n zorglabels | ZPM-codetabellen |
| Waardelijsten algemeen | elke rij optioneel externe code + codesysteem-URI + geldigheidsperiode; "anders"-optie met specificatieveld waar zinvol | zibs/FHIR-patroon |
| Referentiedata-import (nieuw patroon) | één generiek mechanisme voor versioneerde externe tabellen: DSM/ICD-10-codelijst, NZa-prestatie-/beroepen-/zorglabeltabellen, iStd-productcodes, AGB (al geparkeerd) — met versie, ingangs- en einddatum | alle |
## 9. Open vragen en risico's (geen teruggedraaide besluiten)
1. **DSM-licentie**: gebruik van DSM-5-TR-omschrijvingen in een commercieel ECD vereist vermoedelijk afspraken met Boom/APA; de WHO-FIC-codelijst is alleen vrijgegeven voor NZa-doeleinden. Uitzoeken vóór de diagnosemodule-bouw.
2. **Geldigheid codelijst DSM→ICD-10 in 2026**: de versie van 15-12-2023 is per 1-1-2026 vervallen; bevestigen welke opvolgerversie nu geldt (whofic.nl) en dat abonneren op updates onderdeel wordt van het referentiedata-importpatroon.
3. **zib 2020 vs 2024**: nl-core (FHIR) volgt zib 2020 (Probleem), de zib-wereld is naar 2024 (Diagnose). Ons model volgt geen van beide letterlijk; bij adapterbouw de dan geldende nl-core-versie kiezen.
4. **Zorgtraject ↔ zorgepisode**: hergebruikregel trajectnummer (<1 jaar terugval) botst mogelijk met een strikte episode-afsluiting — ontwerpbeslissing voor de declaratie-ronde, nu alleen niet-1-op-1 aannemen.
5. **Toestemmingen** duiken op drie plekken op (DSM-hoofdgroep op factuur/opt-in, huisarts-correspondentie bij verwijstype 04, privacyverklaring zorgvraagtypering): pleit voor één generieke TOESTEMMING-entiteit in een latere ronde.
6. **DSM-registratieplicht is politiek in beweging** (grondslag-discussie 2025, zorgvraagtypering als opvolger richting 2028): declaratie-gerelateerde DSM-velden flexibel houden, niets aan de factuurketen hardcoden.
## 10. Bronnen (hoofdlijst)
- Nictiz zibs: https://www.nictiz.nl/wat-we-doen/activiteiten/zibs/ · https://www.zibs.nl/wiki/ZIB_Publicatie_2024(NL) · https://zibs.nl/wiki/Patient-v4.3(2024NL) · https://www.zibs.nl/wiki/Diagnose-v2.0(2024NL) · https://www.zibs.nl/wiki/Behandeldoel-v4.0(2024NL) · https://www.zibs.nl/wiki/BehandelAanwijzing2-v2.1(2024NL) · https://www.zibs.nl/wiki/TekstUitslag-v4.4(2024NL)
- FHIR NL: https://github.com/Nictiz/Nictiz-R4-zib2020 · https://simplifier.net/packages/nictiz.fhir.nl.r4.nl-core/ · https://hl7nl.github.io/Nictiz-R4-zib2020-IG/StructureDefinition-nl-core-Patient.html
- Basisgegevens GGZ: https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpGGZ · https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_InhoudGGZ
- Koppeltaal 2.0: https://www.koppeltaal.nl/koppeltaal/koppeltaal-20 · https://simplifier.net/koppeltaalv2.0 · https://simplifier.net/Koppeltaal/KoppeltaalActivityDefinition · https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide
- DSM/ICD-10: https://www.whofic.nl/dsm-5icd-10 · https://www.whofic.nl/documenten/codelijst-dsm-5-tr-met-icd-10-afleidingen · https://beta.nl/ggzdiagnosen/ · https://zoek.officielebekendmakingen.nl/stcrt-2025-11955.html · https://www.zorgprestatiemodel.nl/nieuws/tijdelijke-toestemmingsverklaring-opt-in-voor-vermelden-van-gegevens-over-de-dsm-hoofdgroepdiagnose-of-het-basis-ggz-profiel-op-factuur/
- Zorgprestatiemodel/NZa: https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz · https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz/welke-regels-gelden-voor-de-ggz-en-fz-in-2026 · https://www.zorgprestatiemodel.nl/content/uploads/2022/01/20220111-Verwijstypen-en-zorglabels.pdf · https://www.zorgprestatiemodel.nl/content/uploads/2021/11/Verwijsafspraken-GGZ_november-2021.pdf · https://www.zorgprestatiemodel.nl/shared/content/uploads/2021/09/20210927-Toelichting-tabellen.pdf · https://puc.overheid.nl/nza/doc/PUC_641029_22/4/
- Zorgvraagtypering: https://www.embloom.nl/veelgestelde-vragen-over-de-honos/ · https://algoritmes.overheid.nl/nl/algoritme/zb000158/97912239/zorgvraagtypering · https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/vraag-en-antwoord/vraag-en-antwoord-zorgvraagtypering
- iStandaarden: https://www.istandaarden.nl/ · https://www.istandaarden.nl/iwmo/releases/release-iwmo-3.2 · https://www.heldy.nl/kennisbank/wmo/iwmo-uitgelegd · https://www.heldy.nl/kennisbank/jeugdzorg/ijw-uitgelegd · https://www.istandaarden.nl/binaries/content/assets/istandaarden/iwmo/handreiking-uitvoeringsvarianten-iwmo-en-ijw.pdf

432
docs/datamodel/sessielogs/sessielog-2026-07-18.md Normal file
View File

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

306
docs/datamodel/sessielogs/sessielog-2026-07-19.md Normal file
View File

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

8
docs/sessions/2026-07-17-sessielog.md
View File

@@ -8,8 +8,8 @@
## 1. Wat er ligt
- **`docs/datamodel/datamodel-discovery.md`** — feitzinnen, besluiten en open vragen per flow (§5.1 t/m §5.5), FCO-IM-werkwijze
- **`docs/datamodel/entiteitenkaart-instroom.html`** — samenhang-diagram + drie ER-diagrammen + waardelijsten, gepubliceerd als artifact ter review
- **`docs/datamodel/deelmodellen/datamodel-discovery.md`** — feitzinnen, besluiten en open vragen per flow (§5.1 t/m §5.5), FCO-IM-werkwijze
- **`docs/datamodel/entiteitenkaarten/entiteitenkaart-instroom.html`** — samenhang-diagram + drie ER-diagrammen + waardelijsten, gepubliceerd als artifact ter review
De scope van ronde 1 is deze sessie verbreed: van alleen instroom naar **aanmelding t/m behandelplan** (incl. wachtlijstbeheer, diagnose, behandelplan-kern). Agenda en rapportage & overdracht blijven latere rondes.
@@ -59,6 +59,6 @@ De scope van ronde 1 is deze sessie verbreed: van alleen instroom naar **aanmeld
## Referenties
- Discovery: `docs/datamodel/datamodel-discovery.md`
- Entiteitenkaart: `docs/datamodel/entiteitenkaart-instroom.html` (artifact: claude.ai/code/artifact/e2340972-f677-4f0d-af95-b40e8dcac241)
- Discovery: `docs/datamodel/deelmodellen/datamodel-discovery.md`
- Entiteitenkaart: `docs/datamodel/entiteitenkaarten/entiteitenkaart-instroom.html` (artifact: claude.ai/code/artifact/e2340972-f677-4f0d-af95-b40e8dcac241)
- Vorige sessie: `docs/sessions/2026-07-14-sessielog.md`