Files

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

Voegt de discovery- en besluitvormingsronde van 18-19 juli toe (besluitenlog,
begrippenlijst, feitenmodel-instroom met scenariotoetsen, terminologie- en
leveranciersonderzoek) en synchroniseert feitenmodel-instroom.md met de
screening=acceptatie-beslissing (§5). Herstructureert docs/datamodel/ naar
submappen per documentsoort (besluiten/sessielogs/feitenmodellen/deelmodellen/
onderzoek/entiteitenkaarten) zodat toekomstige besluitenlogs en feitenrondes
per deelgebied een vaste plek krijgen.

2026-07-19 11:07:21 +02:00

5.5 KiB

Raw Blame History

Sessielog — 17 juli 2026

Deelnemers: Colin (PO) + Claude Code Onderwerp: Datamodel-discovery ronde 1 — feitzinnen en entiteitenkaart van aanmelding t/m behandelplan Branch: swift-cortex

1. Wat er ligt

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.

2. Besluiten

#	Besluit	Toelichting
1	PERSOON en CLIENT gesplitst	PERSOON draagt identiteit (naam, geboortedatum, BSN); CLIENT is een rol erop (cliëntnummer, sinds-datum). Zelfde persoon kan later ook contactpersoon, vertegenwoordiger of medewerker zijn. BSN optioneel op PERSOON — de verplichting hoort bij de rol (cliënt: Wabvpz), niet bij de persoon.
2	ZORGEPISODE als eigen entiteit	Aanmelding = binnenkomst-gebeurtenis (verwijzer, screening, besluit, aanmeldwachttijd); zorgepisode = periode van zorg die bij uitkomst "intake" start (intakes, diagnoses, behandelplan, behandelwachttijd). Sluit straks aan op het ZPM-zorgtraject.
3	VERWIJZER + PRAKTIJK_INSTELLING als losse entiteiten	AGB-verplichting hangt als attribuut aan de waardelijst `verwijzertype` (huisarts ja, gemeente nee). Geen AGB-validatie tegen Vecozo nu — declaratie-ronde.
4	Aanmelding-status flexibel	`nieuw → in screening → besloten`, vrij terug te bewegen. Uitkomst bij besloten: `intake` / `afgewezen` / `doorverwezen` / `wachtlijst`.
5	Verwijsbrief is een nudge, geen harde eis	Protocolregel met severity per financieringtype; beschikking telt ook als verwijzing (waardelijst `verwijsdocument_type`). Zelfde patroon voor screening-vóór-intake.
6	Intake hangt aan de zorgepisode, meerdere per episode	Interne intakes (bijv. afdelingsovergang) bestaan; `aanleiding`-waardelijst (regulier/intern/crisis).
7	AFDELING en ZORGPROGRAMMA gescheiden waardelijsten	FACT is een programma, geen afdeling. Lost de drie inconsistente hardcoded lijsten uit het prototype op.
8	Screeningsactiviteiten getypeerd	Type uit waardelijst + vrije toelichting (prototype had alleen vrije tekst).
9	WACHTLIJSTPLAATSING als entiteit, twee momenten	Aanmeldwachttijd (aan aanmelding) én behandelwachttijd (aan episode) — volgt de Treeknormen. Prioriteit, telt-vanaf, beëindigingsreden.
10	DSM-5-TR primair, ICD-10 via mapping	Behandelaren registreren DSM; ICD-10 afgeleid via mappingtabel. Prototype deed het omgekeerd (ICD-10 + DSM als vrije tekst).
11	Diagnose aan de episode, intake als herkomst	Diagnose overleeft de intake; twee status-assen (klinisch + verificatie werkdiagnose/definitief).
12	Behandelplan: kern eerst	Doelen (B1-cliëntversie), interventies, evaluatiemomenten, versies, cliëntakkoord. Sessieplanning → agenda-ronde; leefgebieden en veiligheidsplan → later.
13	CLIENTPORTAAL_ACCOUNT als entiteit (0..1 op CLIENT)	Alleen de relatie; auth-details in de auth/ADM-ronde. Verwijzersportaal genoteerd als idee, geen besluit.

3. Bevindingen prototype (verkenningen)

Afdelingen: drie onderling inconsistente hardcoded lijsten (screening 6, intake 3 met andere labels, behandeladvies 4 + 4 zorgprogramma's).
Diagnose-module: heet DSM-5 maar registreert feitelijk ICD-10 F-codes; verification_status zit in de tabel maar de UI gebruikt het niet.
Kindcheck: geen enkele uitkomstwaarde maar drie ja/nee-vlaggen + tekst — zo overgenomen in het model.
Wachtlijst: bestaat nergens in code/DB, alleen als roadmap-idee — vanaf nul ontworpen.
Behandelplan: gestript maar typemodel teruggehaald uit git-historie; statussen waren inconsistent tussen TS- en DB-laag.
Intake afronden: liep via behandeladvies-tab met uitkomst in_zorg/doorverwijzing/extra_diagnostiek — als startlijst overgenomen.

4. Open vragen (belangrijkste)

Wanneer ontstaat de ZORGEPISODE precies — bij uitkomst "intake" of al bij "wachtlijst"?
Verhouding screeningsbesluit ↔ aanmelding-uitkomst: één feit of twee?
Behandelplan: statusmachine (cliëntakkoord als status of feit, WGBO), versiebeheer-vorm, verplicht-vóór-behandeling als nudge of eis.
"Max één hoofddiagnose" — per episode of per moment in de tijd?
DSM-ICD-mappingtabel: bron en onderhoud (APA-licentie) — vóór de schema-baseline.
Startlijsten bevestigen: afdelingen, zorgprogramma's, AGB-verplichting per verwijzertype, beëindigingsredenen wachtlijst, intake-uitkomsten.
Wie mag statussen zetten / diagnose stellen / intake afronden → rollen- en disciplinesronde.

5. Vervolgstappen

Entiteitenkaart reviewen (Colin) — met name kardinaliteiten en de aannames in de "Openstaand"-blokken.
Statussen + eigenaarschap ECD/TIP per entiteit vastleggen (§6 stap 3).
Latere rondes: agenda, rapportage & overdracht, rollen/disciplines, declaratie.
Pas daarna: verse schema-baseline (migrations) + lib/dat/.

Referenties

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

5.5 KiB Raw Blame History