triqura-ecd/docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md

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:

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.