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

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:

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:

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.