Merge pull request 'swift-cortex: technisch datamodel instroom/intake + ER-diagrammen' (#1) from swift-cortex into main

Reviewed-on: #1

docs/datamodel/begrippenlijst-kernmodel.md

@@ -0,0 +1,597 @@
+# Begrippenlijst kernmodel — Nederlands/Engels
+
+**Status:** versie 0.3 — §3 (instroom) en §4 (intake/behandeladvies) bijgewerkt na hun FCO-IM-feitenrondes en entiteitenmodellen  
+**Datum:** 18 juli 2026, §3 en §4 bijgewerkt 19 juli 2026  
+**Bron:** `besluiten/besluitenlog-datamodel-2026-07-18.md` (B1–B30)  
+**Terminologieonderzoek:** de driedeling Referral Request/Referral Submission/Referral Case uit `onderzoek/onderzoek-engelstalige-epd-terminologie.md` is verwerkt en bevestigd in `feitenmodellen/feitenmodel-instroom.md` en `deelmodellen/model-instroom.md`  
+**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
+
+Bijgewerkt 19 juli 2026 na de FCO-IM-feitenronde (`feitenmodellen/feitenmodel-instroom.md`) en de entiteiten-/cardinaliteitenafleiding (`deelmodellen/model-instroom.md`, B21–B30). Vervangt de eerdere werktermen `Inbound Care Signal`, `Access Assessment Case`, `Presenting Care Need` en `Screening Recommendation` (zie toelichting per begrip hieronder).
+
+### Referral Request — `referral_request`
+
+**Nederlandse domeinterm:** zorgverzoek  
+**Status Engelse naam:** aanbevolen
+
+Het inhoudelijke verzoek om zorg of beoordeling voor één of meer samenhangende geuite zorgvragen, met een eigen identiteit los van de submission die het aanleverde en los van een eventuele formele verwijzing. Kan afkomstig zijn van een professional, organisatie, cliënt of vertegenwoordiger.
+
+**Is niet:** de technische ontvangst van het verzoek (dat is `Referral Submission`), het interne beoordelingstraject (`Referral Case`), of een bewijs dat de zorg is geaccepteerd. Bevat geen aparte `Presenting Care Need`-entiteit — de geuite zorgvraag is een attribuut (`presenting_need_text`) op dit object; die eerdere kandidaat-entiteit is niet doorgezet.
+
+**Terminologienotitie:** dit is de derde term uit de driedeling die `Inbound Care Signal`/`Access Assessment Case` verving (zie hieronder). Kan bij crisisaanmeldingen zonder bekende persoon bestaan (B26).
+
+### Referral Submission — `referral_submission`
+
+**Nederlandse domeinterm:** afzonderlijke binnenkomst  
+**Status Engelse naam:** aanbevolen
+
+Eén afzonderlijke binnenkomst bij de instelling, via één kanaal en op één ontvangstmoment, met eigen bron, tijdstip en documenten.
+
+**Is niet:** automatisch een nieuw zorgverzoek of aanmeldingstraject; een overschrijfbare actuele versie van eerder ontvangen informatie.
+
+**Terminologienotitie:** vervangt `Inbound Care Signal` (`inbound_care_signal`, aanmeldsignaal) — dezelfde betekenis, definitieve naam bevestigd na de feitenronde. `Referral` bleek te smal voor deze rol (een zelfaanmelding is ook een submission); `Signal` is internationaal minder gangbaar dan `Submission`.
+
+### Referral Case — `referral_case`
+
+**Nederlandse domeinterm:** aanmeldingstraject  
+**Status Engelse naam:** aanbevolen
+
+Het institutionele beoordelingsproces voor één samenhangende zorgvraag, gevoed door één of meer submissions en requests. Heeft geen vaste, eenrichtings-statusmachine — de actuele stand wordt afgeleid uit een tijdlijn van gebeurtenissen (B25).
+
+**Is niet:** een opname, verwijzing, klinische intake, zorgepisode of financieel traject.
+
+**Terminologienotitie:** vervangt `Access Assessment Case` (`access_assessment_case`) — dezelfde betekenis, definitieve naam bevestigd. `Case` duidt hier een behandelbare workflowcase aan, nog geen klinische casus of zorgepisode.
+
+### Professional Referral — `professional_referral`
+
+**Nederlandse domeinterm:** formele verwijzing  
+**Status Engelse naam:** aanbevolen
+
+De formele Nederlandse VERWIJZING: een door een toegestane verwijzer uitgegeven object met verwijzer, verwijsdatum, geldigheid en verwijsspecifieke gegevens, gekoppeld aan een `Referral Request`. Kan een eerdere `Professional Referral` op hetzelfde request vervangen bij correctie of aanvulling (B23).
+
+**Is niet:** ieder zorgverzoek. Een zelfaanmelding heeft geen `Professional Referral`. Bewijst niet dat zorg al is geaccepteerd.
+
+**Terminologienotitie:** verfijnt de eerdere bredere term `Referral` (`referral`) — die naam bleek dubbelzinnig zodra `Referral Request`/`Referral Submission`/`Referral Case` als aparte objecten bestonden. `Professional` maakt expliciet dat dit de formele, door een verwijzer uitgegeven verwijzing is, niet het bredere zorgverzoek.
+
+### Municipal Care Assignment — `municipal_care_assignment`
+
+**Nederlandse domeinterm:** gemeentelijke toewijzing  
+**Status:** bevestigen (juridisch nog niet door een jurist bevestigd, zie B27)
+
+De gemeentelijke beschikking/toewijzing (Wmo/Jeugdwet, iWmo/iJw 301-bericht) als toegangsticket náást — niet in plaats van — een eventuele `Professional Referral`.
+
+**Is niet:** een vervanging van de professionele verwijsroute (die bestaat bij Jeugdwet zelfstandig ernaast); bij Wmo het enige toegangsdocument, omdat daar geen professionele verwijsroute bestaat.
+
+### Legal Mandate — `legal_mandate`
+
+**Nederlandse domeinterm:** wettelijk mandaat (Wvggz)  
+**Status:** bevestigen (juridisch nog niet door een jurist bevestigd, zie B27)
+
+Het wettelijke mandaat bij gedwongen zorg: crisismaatregel of zorgmachtiging. Werkt zelf als bindend besluit; de instelling heeft geen institutionele acceptatiediscretie.
+
+**Is niet:** een `Care Acceptance Decision` of een vervanging daarvan — een ander soort feit (wettelijke plicht, geen discretionaire beoordeling). Een zorgepisode kan rechtstreeks uit een geldig mandaat ontstaan.
+
+### Submission-to-Case Assignment — `submission_case_assignment`
+
+**Nederlandse domeinterm:** toewijzing van submission aan aanmeldingstraject  
+**Status Engelse naam:** aanbevolen
+
+De historiseerbare koppeling waarmee een submission aan een `Referral Case` wordt toegewezen.
+
+**Is niet:** destructieve verplaatsing. De oorspronkelijke submission en eerdere toewijzingen blijven bestaan.
+
+**Terminologienotitie:** hernoemd van `Signal-to-Case Assignment` (`signal_case_assignment`) — het "signal_"-voorvoegsel kwam nergens anders terug en week af van het "submission_"-patroon; technische correctie bij de tweede reviewronde (19 juli 2026), geen betekenisverandering.
+
+### Case Consolidation — `case_consolidation`
+
+**Nederlandse domeinterm:** logische samenvoeging van aanmeldingstrajecten  
+**Status Engelse naam:** aanbevolen
+
+Een niet-destructieve relatie waarbij één aanmeldingstraject als leidend wordt aangewezen ten opzichte van een ander, overlappend traject; beide behouden hun identiteit en historie.
+
+**Is niet:** database-merge, verwijderen, overschrijven of stil hernummeren. Vereist geen speciale beslisbevoegdheid — een administratieve correctie, geen inhoudelijk zorgbesluit.
+
+**Terminologienotitie:** hernoemd van `Access Case Consolidation` (`access_case_consolidation`) — het "access_"-voorvoegsel was ongemotiveerd en suggereerde ten onrechte een besluit over zorgtoegang; technische correctie bij de tweede reviewronde (19 juli 2026), geen betekenisverandering.
+
+### Screening — `screening`
+
+**Nederlandse domeinterm:** screening  
+**Status Engelse naam:** aanbevolen
+
+De verzameling activiteiten (contact, onderzoek, informatie-uitvraag) binnen een `Referral Case` waarmee de beoordeling voor het acceptatiebesluit tot stand komt.
+
+**Is niet:** een zelfstandig besluitobject. Screening levert geen apart advies op — het screeningsbesluit **is** het acceptatiebesluit (B21).
+
+### Care Acceptance Decision — `care_acceptance_decision`
+
+**Nederlandse domeinterm:** acceptatiebesluit  
+**Status Engelse naam:** aanbevolen
+
+Het formele besluit dat de beoordeling van een `Referral Case` afrondt: draagt zelf de onderliggende beoordelingen (inhoudelijke match, plek, capaciteit), de besluituitkomst (`geaccepteerd`/`afgewezen`), de vervolgroute en, bij afwijzing, de onderbouwing. Kan een eerder besluit van dezelfde case vervangen bij heroverweging of institutionele correctie (B23).
+
+**Is niet:** behandelovereenkomst, behandeltoestemming, opnamebesluit, zorgplicht of toewijzing van verantwoordelijkheid. Geen apart, voorafgaand screeningsadvies ernaast (B21) — dat eerdere kandidaat-begrip `Screening Recommendation` (`screening_recommendation`) is niet doorgezet.
+
+### Case Information Request — `case_information_request`
+
+**Nederlandse domeinterm:** informatieverzoek  
+**Status Engelse naam:** aanbevolen
+
+Een gedateerd, toegeschreven gebeurtenisfeit: wie heeft wanneer welke aanvullende informatie gevraagd bij een `Referral Case`.
+
+**Is niet:** een besluituitkomst of statusfase — er bestaat op dat moment nog geen `Care Acceptance Decision` (B25). Kan zich op elk moment voordoen, ook ná een eerder besluit tijdens een heroverweging.
+
+### Case Withdrawal — `case_withdrawal`
+
+**Nederlandse domeinterm:** cliënt-intrekking  
+**Status Engelse naam:** aanbevolen
+
+De registratie dat een cliënt een `Referral Case` intrekt.
+
+**Is niet:** een `Care Acceptance Decision` — vereist geen beslisbevoegdheid en kan op elk moment plaatsvinden, ook ná een positief besluit (B24).
+
+### Crisis Encounter Note — `crisis_encounter_note`
+
+**Nederlandse domeinterm:** crisisnotitie vóór identificatie  
+**Status:** bevestigen (grotendeels optionele velden, geen wettelijke structuurplicht gevonden, zie B28)
+
+Gestructureerde vastlegging van crisisgerelateerd handelen (bijvoorbeeld medicatie, risico-inschatting, dwangmaatregel) bij een `Referral Case`, ook vóórdat identificatie of volledige dossiervorming heeft plaatsgevonden.
+
+**Is niet:** de screening zelf (`Screening` gaat over het beoordelingsproces, niet over klinisch handelen) of een vervanging van de formele Wvggz-dwangregistratie.
+
+### Case Urgency Assessment — `case_urgency_assessment`
+
+**Nederlandse domeinterm:** urgentiebeoordeling  
+**Status Engelse naam:** aanbevolen
+
+Een herhaalbare beoordeling van de urgentie van een `Referral Case`, vastgesteld tijdens screening/triage en later aan te passen door het intake-team of in een MDO (B29).
+
+**Is niet:** een vast statusveld — de meest recente beoordeling geldt, zonder vervangt-relatie (lagere inzet dan een acceptatiebesluit).
+
+## 4. Intake en behandeladvies
+
+Bijgewerkt 19 juli 2026 na de FCO-IM-feitenronde voor intake en
+behandeladvies (`feitenmodellen/feitenmodel-intake-behandeladvies.md`,
+`deelmodellen/model-intake-behandeladvies.md`).
+
+### Clinical Intake Assessment — `clinical_intake_assessment`
+
+**Nederlandse domeinterm:** intake / intaketraject  
+**Status Engelse naam:** aanbevolen
+
+Een dynamisch klinisch onderzoekstraject voor één samenhangende zorgvraag,
+met meerdere contacten, onderzoeken, disciplines en bevindingen. Hangt aan
+de Clinical Care Episode; start op enig moment ná het acceptatiebesluit dat
+de episode liet ontstaan, mogelijk na een periode op de intakewachtlijst.
+
+**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.
+
+**Terminologienotitie:** `Intake Assessment Activity` (`intake_assessment_activity`)
+is niet als aparte entiteit doorgezet — onderzoeksactiviteiten (aanvullend
+onderzoek, telefonisch contact, huisbezoek, beeldcontact) zijn getypeerde
+waarden van `intake_contact.contact_type`, geen zelfstandig object.
+
+### Child Safety Check — `child_safety_check`
+
+**Nederlandse domeinterm:** kindcheck  
+**Status Engelse naam:** aanbevolen
+
+De wettelijk verankerde kindcheck (Wet verplichte meldcode huiselijk geweld
+en kindermishandeling; KNMG-meldcode) bij de intake van een volwassen
+cliënt: is de cliënt verantwoordelijk voor minderjarigen, zijn er zorgen
+over hun veiligheid, en is daarop actie ondernomen.
+
+**Is niet:** het volledige meldcode-stappenplan — dat is proces-state,
+TIP-terrein. Alleen de klinische feiten horen in het ECD.
+
+### Treatment Advice — `treatment_advice`
+
+**Nederlandse domeinterm:** behandeladvies  
+**Status Engelse naam:** aanbevolen
+
+Het object dat een Clinical Intake Assessment afrondt: draagt de uitkomst
+(in zorg, terug- of doorverwijzing, aanvullende diagnostiek nodig), het
+geadviseerde zorgprogramma en de toelichting. Kan een eerder advies van
+dezelfde intake vervangen bij heroverweging.
+
+**Is niet:** een apart, voorafgaand advies naast een later formeel besluit —
+het advies zelf ís de vervolgrichting, net als bij Care Acceptance
+Decision. Geen behandelplan — het advies wijst een richting, het
+behandelplan werkt die uit.
+
+**Terminologienotitie:** `doorverwijzing` en `terugverwijzing` zijn volgens
+LKS 4.0 een volgtijdelijk paar (eerst doorverwijzen proberen, dan pas
+terugverwijzen), geen onafhankelijke alternatieven — gedekt door de
+vervangt-relatie, niet door een aparte sequentie-regel. `extra_diagnostiek`
+is een praktijkgefundeerde uitkomst, niet LKS-genormeerd.
+
+## 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
+
+Dit volledige begrippenkader wacht nog op een eigen feitenronde (besluitenlog §10 punt 3). Vooruitlopend daarop bestaat sinds 19 juli 2026 een bewust minimale, voorlopige hook — `episode_team_involvement` (`deelmodellen/model-instroom.md` §2.20) — die alleen vastlegt dát een team bij een episode betrokken is, zonder rollen, bevoegdheid of individueel lidmaatschap. Deze hook wordt door onderstaand begrippenkader vervangen of geabsorbeerd zodra die ronde plaatsvindt; hij krijgt hier bewust geen eigen kernbegrip-entry om verwarring met `Episode Team Assignment` te voorkomen (B30).
+
+### 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
+
+**Opgelost bij de instroom-feitenronde (19 juli 2026), zie §3:**
+
+- `inbound_care_signal` → vervangen door `referral_submission`;
+- `access_assessment_case` → vervangen door `referral_case`;
+- `presenting_care_need` → geen aparte entiteit doorgezet, nu attribuut op `referral_request`;
+- `access_case_consolidation` → hernoemd naar `case_consolidation`, naam bevestigd;
+- `screening_recommendation` → vervallen, geen apart besluitobject naast `care_acceptance_decision` (B21).
+
+**Opgelost bij de intake-/behandeladvies-feitenronde (19 juli 2026), zie §4:**
+
+- `clinical_intake_assessment` — naam bevestigd (was: te bevestigen);
+- `intake_assessment_activity` → niet als aparte entiteit doorgezet, nu waarde van `intake_contact.contact_type`;
+- `treatment_advice` — nieuw, bevestigd (loste `feitenmodellen/feitenmodel-instroom.md` §7 vraag 2 op).
+
+De betekenis van onderstaande begrippen staat vast, maar de Engelse naam moet nog expliciet worden bevestigd:
+
+1. `funding_case` — financieel traject;
+2. `lead_clinician_role` — regiebehandelaar;
+3. `care_goal` — behandel-/zorgdoel;
+4. `care_planning_profile` — behandelvisieprofiel;
+5. `cross_episode_clinical_concept` — voorlopige naam voor de longitudinale architectuurlaag.
+
+Daarnaast, uit de instroom-ronde, nog juridisch te bevestigen (niet een naamskwestie maar een inhoudelijke aanname, zie B27 en `deelmodellen/model-instroom.md` §7 punt 3):
+
+6. `municipal_care_assignment` — gemeentelijke toewijzing;
+7. `legal_mandate` — wettelijk mandaat (Wvggz).
+
+En uit de intake-/behandeladvies-ronde, eveneens een inhoudelijke aanname
+i.p.v. een naamskwestie (zie `deelmodellen/model-intake-behandeladvies.md`
+§6 punt 3):
+
+8. `child_safety_check` — de vierde vlag (zwangerschap) is toegevoegd op
+   basis van algemene domeinkennis, niet uit de eerder verzamelde
+   onderzoeksrapporten.
+
+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.

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

@@ -0,0 +1,494 @@
+# Besluitenlog datamodel — sessie 18 juli 2026 (bijgewerkt 19 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` en `../sessielogs/sessielog-2026-07-19.md` (§2 uitgebreid met B21–B30, instroom feitenronde en entiteitenmodel)  
+**Vervolg:** structurele besluiten verwerken in de deelmodellen voordat SQL of migrations worden gemaakt — voor instroom inmiddels gedaan in `../feitenmodellen/feitenmodel-instroom.md` en `../deelmodellen/model-instroom.md`; begrippenlijst- en `../deelmodellen/model-aanmelding.md`-synchronisatie volgt als eerstvolgende stap
+
+## 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.
+
+### B21 — Screeningsbesluit is het acceptatiebesluit
+
+**Besluit**
+
+- Er is geen apart, voorafgaand screeningsadvies naast het acceptatiebesluit; **Care Acceptance Decision** draagt zelf de onderliggende beoordelingen (inhoudelijke match, plek, capaciteit), de besluituitkomst, de vervolgroute en, bij afwijzing, de onderbouwing.
+- Dit vervangt de eerder in `../deelmodellen/datamodel-discovery.md` §5.2 en `../deelmodellen/model-screening.md` veronderstelde scheiding tussen screeningsbesluit/-advies en een apart acceptatiebesluit.
+- Screening blijft bestaan als de verzameling activiteiten (contact, onderzoek) die de beoordeling voeden, niet als eigen besluitobject.
+
+### B22 — Besluituitkomst, vervolgroute en onderbouwing zijn losse feiten
+
+**Besluit**
+
+- Besluituitkomst is beperkt tot `geaccepteerd`/`afgewezen`; doorverwijzen en case afsluiten zijn vervolgroutes, geen besluituitkomsten.
+- Capaciteit is invoer voor het besluit maar bepaalt de uitkomst niet automatisch: bij ontbrekende capaciteit zijn zowel "geaccepteerd + intakewachtlijst" als "afgewezen + capaciteitsonderbouwing" geldige uitkomsten.
+- Bij afwijzing is een concrete onderbouwing verplicht; het herhalen van de uitkomst is geen geldige onderbouwing.
+- Elk positief besluit laat een zorgepisode ontstaan, ook wanneer de vervolgroute intakewachtlijst is — niet pas bij de feitelijke start van de intake. Dit corrigeert het eerdere voorstel in `../deelmodellen/model-aanmelding.md` §2.15 waarin de episode pas bij uitkomst "intake" ontstond.
+
+### B23 — Herziening via expliciete vervangt-relatie
+
+**Besluit**
+
+- Een acceptatiebesluit of professionele verwijzing kan optioneel precies één eerder exemplaar vervangen, met een verplichte reden. Het vervangen exemplaar blijft ongewijzigd bewaard; er is geen impliciete "laatste is geldig"-regel op basis van datum.
+- Dit geldt zowel bij heroverweging na afwijzing als bij institutionele correctie van een eerder positief besluit, met dezelfde bevoegdheidseis als het oorspronkelijke besluit.
+- De vervangt-relatie is uniek per vervangen exemplaar (voorkomt vertakking) en kan onbeperkt diep zijn.
+
+**Ontwerpuitwerking**
+
+Of dit patroon ook voor andere herzienbare objecten in latere deelgebieden geldt, wordt per deelgebied opnieuw beoordeeld.
+
+### B24 — Cliënt-intrekking is geen besluit
+
+**Besluit**
+
+- Cliënt-intrekking van een aanmeldingstraject vereist geen beslisbevoegdheid en kan op elk moment plaatsvinden, ook ná een positief besluit.
+- Een reeds ontstane zorgepisode wordt bij intrekking of institutionele correctie altijd afgesloten met een reden, nooit verwijderd of ongedaan gemaakt.
+
+### B25 — Geen statusmachine, actuele stand afgeleid uit een gebeurtenistijdlijn
+
+**Besluit**
+
+- Het aanmeldingstraject heeft geen vaste, eenrichtings-statusmachine. De actuele stand (in beoordeling, wacht op informatie, besloten, ingetrokken) wordt afgeleid uit een tijdlijn van gebeurtenissen (toewijzing, informatieverzoek, besluit, intrekking, consolidatie), niet uit één overschrijfbaar statusveld.
+- Dit sluit aan bij B7 (wachtlijst: volledige tijdlijn is de bron) en de non-lineaire aanmelding-status uit `../deelmodellen/datamodel-discovery.md` §5.1 #5.
+- Een informatieverzoek is een eigen gebeurtenisfeit, geen besluituitkomst en geen statusfase — er bestaat op dat moment nog geen besluit.
+
+**Ontwerpuitwerking**
+
+De afleidingsregel wordt in de applicatielaag als één centrale, herbruikbare projectie geïmplementeerd, niet los per scherm.
+
+### B26 — Zorgverzoek kan zonder bekende persoon bestaan
+
+**Besluit**
+
+- Bij crisisaanmeldingen kan de identiteit nog onbekend zijn op het moment dat het zorgverzoek al geregistreerd moet worden. Een placeholder- of "John Doe"-persoon die later wordt vervangen is bewust geen oplossing, omdat dat vereist alle gekoppelde feiten achteraf naar de echte persoon te verplaatsen.
+- De koppeling aan een persoon wordt in plaats daarvan een eigen, gedateerd en toegeschreven feit, vastgelegd zodra de identiteit bekend wordt.
+
+### B27 — Wmo/Jeugdwet-toewijzing en Wvggz-mandaat zijn eigen instroomroutes
+
+**Besluit**
+
+- Een gemeentelijke toewijzing (Wmo/Jeugdwet) bestaat náást, niet in plaats van een professionele verwijzing — bij Jeugdwet bestaat een zelfstandige professionele verwijsroute naast de gemeentelijke toegang; bij Wmo bestaat geen professionele verwijsroute.
+- Een Wvggz-mandaat (crisismaatregel/zorgmachtiging) kent geen institutionele acceptatiediscretie en vervangt het acceptatiebesluit niet: het besluit tot gedwongen zorg is al genomen door burgemeester of rechter. Een zorgepisode kan daarom ook rechtstreeks uit een geldig mandaat ontstaan, niet uitsluitend uit een acceptatiebesluit.
+
+**Onderzoek**
+
+De juridische aannames achter dit besluit — met name of de zorgmachtiging-route (officier van justitie/rechter) hetzelfde patroon volgt als de crisismaatregel, en of de Jeugdwet-verwijsroute specifiek voor jeugd-ggz identiek is aan jeugdhulp in het algemeen — zijn nog niet door een jurist bevestigd.
+
+### B28 — Gestructureerde crisisdocumentatie vóór identificatie
+
+**Ontwerpuitwerking**
+
+Crisisgerelateerd handelen (medicatie, risico-inschatting, dwangmaatregelen) kan vóór identificatie of dossiervorming al gestructureerd worden vastgelegd, los van het beoordelingsproces (screening). Geen expliciet wetsartikel gevonden dat dit tijdens de interventie zelf verplicht; de algemene WGBO-dossierplicht ondersteunt het wel. Concrete velden blijven daarom grotendeels optioneel.
+
+### B29 — Urgentie is een herhaalbare beoordeling
+
+**Besluit**
+
+- Urgentie van een aanmeldingstraject is geen vast veld maar een herhaalbare beoordeling: vastgesteld tijdens screening/triage door de rol screener/triagist, en later aan te passen door het intake-team of in een MDO.
+- De waarde zelf is een eenvoudige waardelijst zonder verplichte onderbouwing.
+
+### B30 — Minimale hook voor teambetrokkenheid, volledig zorgteam-model blijft aparte ronde
+
+**Besluit**
+
+- Een team kan bij een zorgepisode betrokken zijn vóórdat een individuele behandelaar is toegewezen (bijvoorbeeld tijdens een intakewachtlijst).
+- Zorgteam (het team van betrokken behandelaren, met regie-/hoofdbehandelaarschap) is een zelfstandig begrip, los van zorgprogramma (inhoudelijk aanbod) en organisatorische eenheid — die laatste twee kunnen aan elkaar gekoppeld worden (een organisatorische eenheid kan één of meer zorgprogramma's verzorgen).
+- Voor nu wordt alleen een minimale, voorlopige hook voor teambetrokkenheid vastgelegd, zonder rollen, bevoegdheid of individueel lidmaatschap. Dit bevestigt en verscherpt B16 en §10 punt 3: het volledige zorgteam-model (leden, rollen, regiebehandelaarschap, bevoegdheid, mogelijk toekomstige cliëntautorisatie) blijft een aparte, nog te plannen ronde.
+
+---
+
+B21–B30 zijn de uitkomst van de FCO-IM-feitenronde en de daaropvolgende entiteiten-/cardinaliteitenafleiding voor instroom (sessie 19 juli 2026). Volledige feitzinnen, scenariotoetsen, het uitgewerkte entiteitenmodel (20 entiteiten) en de reviewgeschiedenis staan in `../feitenmodellen/feitenmodel-instroom.md` en `../deelmodellen/model-instroom.md`; dit besluitenlog vat de richting samen en dupliceert niet de volledige attribuuttabellen.
+
+## 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.
+
+### B31 — Intake hangt aan de zorgepisode, start ná het acceptatiebesluit
+
+**Besluit**
+
+Sluit de ontwerpuitwerking van B6 af, nu het acceptatieproces is uitgewerkt (B21-B27). De intake hangt aan de zorgepisode, niet aan het aanmeldingstraject. Zij start op enig moment ná het acceptatiebesluit dat de episode liet ontstaan — mogelijk pas na een periode op de intakewachtlijst (vervolgroute `intakewachtlijst`, B22). De eerdere aanname dat de episode zelf pas bij aanmelding-uitkomst "intake" ontstaat (`../deelmodellen/model-intake.md`, open besluitpunt 7) is met B22 al herzien; dit besluit trekt de consequentie daarvan door voor de intake zelf.
+
+### B32 — Behandeladvies is een eigen object dat de intake afrondt, geen apart voorafgaand advies
+
+**Besluit**
+
+- Net als bij het acceptatiebesluit (B21) bestaat er geen apart, voorafgaand behandeladvies naast een later formeel besluit — het behandeladvies zelf draagt de uitkomst en de vervolgrichting.
+- Het behandeladvies krijgt wel een eigen identiteit, los van de intake zelf (Treatment Advice), naar het patroon van Care Acceptance Decision — niet als platte velden op de intake-entiteit.
+- Een behandeladvies kan een eerder advies van dezelfde intake vervangen bij heroverweging, met dezelfde vervangt-constructie als bij herziening van het acceptatiebesluit (B23): verplichte reden, uniek per vervangen exemplaar, onbeperkte kettingdiepte.
+
+Dit sluit `../feitenmodellen/feitenmodel-instroom.md` §7 vraag 2 af, die sinds sessielog 19 juli 2026 geparkeerd stond.
+
+### B33 — Vier behandeladvies-uitkomsten, deels LKS-genormeerd
+
+**Besluit**
+
+- Vier uitkomsten: `in_zorg`, `terugverwijzing`, `doorverwijzing`, `extra_diagnostiek`.
+- `Doorverwijzing` en `terugverwijzing` zijn volgens LKS 4.0 (patient journey fase 2-3, §3.6.2) een volgtijdelijk paar — eerst een inspanningsverplichting tot doorverwijzing naar een beter passende aanbieder, pas daarna terugverwijzing als dat niets oplevert — geen twee gelijkwaardige, onafhankelijke uitkomsten. De volgorde wordt gedekt door het vervangt-mechanisme uit B32, niet door een aparte sequentie-regel.
+- `Extra_diagnostiek` is een praktijkgefundeerde uitkomst, nergens in LKS 4.0 als zodanig benoemd — bewust behouden, maar expliciet gemarkeerd als praktijkkeuze, niet als landelijke norm.
+- Gedeeld/onduidelijk advies bij twijfel tussen behandelaren krijgt geen eigen uitkomstwaarde: LKS 4.0 §3.6.2 lost dit institutioneel op (de zorgaanbieder bepaalt wie de doorslaggevende stem heeft, vaak in het professioneel statuut).
+- Een cliënt die afziet van het geadviseerde vervolg is een later, apart feit, geen behandeladvies-uitkomst — analoog aan hoe planakkoord al los van het behandelplan wordt vastgelegd (B13).
+- Wachtlijst voor behandelcapaciteit is geen aparte uitkomst maar een vervolgroute na `in_zorg`, zelfde precedent als bij het acceptatiebesluit (Route 2A/2B).
+
+**Onderzoek**
+
+De exacte bevoegdheidsmatrix is deels wél een landelijke norm: LKS 4.0 Tabel 2 schrijft voor settings 3–8 (multidisciplinair ambulant, outreachend, klinisch, forensisch, hoogspecialistisch) dwingend MDT-bespreking voor; voor setting 2 is dat optioneel; voor vrijgevestigden niet van toepassing. Het model biedt hiervoor een minimale hook (`intake_mdt_review`); de precieze verplichtingsregel per setting hoort bij de bevoegdheidsronde (B16) en vereist een setting-registratie die nu nog niet bestaat.
+
+### B34 — Kindcheck-structuur bevestigd, vierde vlag toegevoegd
+
+**Besluit**
+
+- De bestaande prototypestructuur (drie ja/nee-vlaggen met verplichte toelichting bij "ja") blijft de kern, met vlag 1 verbreed van "thuiswonende kinderen" naar "verantwoordelijk voor minderjarigen" (KNMG-meldcode: ook co-ouderschap en andere zorgrelaties tellen).
+- Een vierde vlag ("zwangerschap van cliënt of partner") wordt toegevoegd — de KNMG-kindcheck rekent het ongeboren kind expliciet mee.
+
+**Onderzoek**
+
+De vierde vlag is toegevoegd op basis van algemene domeinkennis (KNMG-meldcode), niet uit de eerder verzamelde onderzoeksrapporten — te verifiëren tegen de actuele meldcode-tekst.
+
+## 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.~~ **Gedaan** (19 juli 2026) — als Referral Submission/Referral Case/Signal-to-Case Assignment/Access Case Consolidation, zie B21–B25 en `../deelmodellen/model-instroom.md`.
+2. ~~ACCEPTATIEBESLUIT en de relatie met intake en ZORGEPISODE.~~ **Gedaan** (19 juli 2026), zie B21–B27 en `../deelmodellen/model-instroom.md`. ~~De relatie met het behandeladvies ná de intake blijft apart onderzoek.~~ **Ook gedaan** (19 juli 2026) — zie B31–B33 en `../deelmodellen/model-intake-behandeladvies.md`.
+3. Tijdgebonden programma-, organisatie- en zorgteambetrokkenheid. **Deels gestart:** een minimale, voorlopige hook voor teambetrokkenheid bestaat nu in het instroomdeelgebied (B30, `episode_team_involvement`); het volledige zorgteam-model (leden, rollen, regiebehandelaarschap, bevoegdheid) staat hierdoor als eerstvolgende ronde met concrete urgentie.
+4. Eén levend BEHANDELPLAN met immutable snapshots.
+5. MDO- en evaluatieworkflows. **Deels gestart:** een minimale, voorlopige hook voor MDT-bespreking bij het behandeladvies bestaat nu (B33, `intake_mdt_review`); de volledige MDO-workflow (B14-B15) blijft een aparte ronde.
+6. Bevoegdheidsmatrix per besluittype en teamrol. **Aangescherpt** (19 juli 2026): LKS 4.0 vereist voor settings 3–8 dwingend MDT-bespreking bij het behandeladvies, voor setting 2 optioneel — een concrete, setting-afhankelijke eis die de matrix straks moet dekken (zie B33-onderzoek).
+7. Versiegebonden BEHANDELVISIEPROFIEL in ADM.
+8. Engelse werktermen in `../begrippenlijst-kernmodel.md` reviewen en vóór het logische model definitief bevestigen — voor instroom en intake/behandeladvies is dit gedaan (§3, §4 aldaar); overige secties nog open.
+
+### 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.
+7. Juridische verificatie van de Wvggz/Wmo-Jeugdwet-aannames in B27 — met name de zorgmachtiging-route en de jeugd-ggz-specifieke Jeugdwet-relatie (zie `../deelmodellen/model-instroom.md` §7 punt 3). Nog open.
+8. ~~Mogelijke uitkomsten van het behandeladvies na de intake en de bijbehorende bevoegdheid.~~ **Gedaan** (19 juli 2026) — zie B32–B33, op basis van volledige LKS 4.0-teksttoetsing. Setting-afhankelijke bevoegdheidsdetails blijven bij de bevoegdheidsronde (punt 6 hierboven).
+9. **Nieuw (19 juli 2026):** KNMG-kindcheck-vierde-vlag (zwangerschap) verifiëren tegen de actuele meldcode-tekst — nu op basis van algemene domeinkennis toegevoegd (B34).
+
+### 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`~~ — **gesynchroniseerd** (19 juli 2026): het AANMELDING/VERWIJZING/ZORGEPISODE-deel is niet-destructief gemarkeerd als vervallen met verwijzing naar `../deelmodellen/model-instroom.md`; PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING/TOESTEMMING blijven ongewijzigd geldig.
+- `../deelmodellen/model-screening.md` — nog niet gesynchroniseerd; inhoudelijk grotendeels opgegaan in `../deelmodellen/model-instroom.md` (screening = onderdeel van Referral Case, geen apart besluitobject, B21).
+- ~~`../deelmodellen/model-intake.md`~~ — **gesynchroniseerd** (19 juli 2026): vervangen door `../deelmodellen/model-intake-behandeladvies.md`, niet-destructief gemarkeerd.
+- `../deelmodellen/model-wachtlijst.md`
+- `../deelmodellen/model-behandelplan.md`
+- `../deelmodellen/model-rapportage.md`
+- `../entiteitenkaarten/entiteitenkaart-instroom.html` — nog niet geregenereerd; bron is nu `../deelmodellen/model-instroom.md` en `../deelmodellen/model-intake-behandeladvies.md`.
+
+De entiteitenkaart wordt pas opnieuw gegenereerd nadat de Markdown-deelmodellen zijn herzien — voor instroom is de bron nu `../deelmodellen/model-instroom.md`.

docs/datamodel/deelmodellen/datamodel-discovery.md

@@ -0,0 +1,214 @@
+# Datamodel Discovery — ECD
+
+**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
+
+---
+
+## 1. Waarom deze discovery
+
+Het prototype-datamodel is de bron van vrijwel alle gevonden gebreken: labels vs. codes, twee modules op één tabel, schema niet reproduceerbaar, regels die alleen in de UI leven. We bouwen het ECD opnieuw op een eigen model. Dit document verkent de uitgangspunten en de werkvorm — er wordt nog niets gebouwd.
+
+## 2. Methode: feiten eerst (FCO-IM)
+
+We modelleren niet met tabellen als startpunt, maar met **feitzinnen in natuurlijke taal**, uitgesproken door de domeinexpert (Colin). Uit die zinnen leiden we elementaire feiten af, en dááruit het model. Dit is de kern van FCO-IM: het model legt de *communicatie* over het domein vast, en daarmee blijft de betekenis (semantiek) bewaard — leesbaar voor behandelaar én ontwikkelaar. Vanuit een elementair feitenmodel zijn ER-diagrammen, relationele schema's en zelfs graph-modellen af te leiden.
+
+**Werkvorm per flow:**
+1. Claude stelt een startlijst feitzinnen op vanuit de bestaande schermen en use-cases
+2. Colin corrigeert, schrapt en vult aan ("zo zeggen wij dat niet", "dit feit ontbreekt")
+3. Samen benoemen we per feit: uniciteit (kan dit feit maar één keer waar zijn?), verplichtheid, wie het feit mag vastleggen/wijzigen
+4. Claude leidt er de entiteitenkaart uit af (HTML-visualisatie) → review → pas daarna SQL
+
+## 3. Uitgangspunten voor het datamodel
+
+### 3.1 Harde spelregels
+1. **Waardelijsten op één plek** — types, statussen, afdelingen als data (referentietabellen), UI en database delen dezelfde bron. Directe les uit de kapotte intake-tabs.
+2. **Herkomst (provenance) op elk klinisch record** — auteur (mens/AI), bij AI: model + bronverwijzingen; content-hash zodat gewijzigde tekst automatisch her-embedding triggert.
+3. **Append-only audit** — geen UPDATE/DELETE op audit; hash-chaining (elk event hasht het vorige) maakt manipulatie detecteerbaar; NEN 7510: 5 jaar bewaren.
+4. **Soft delete overal** — `deleted_at`, nooit hard delete; definitieve verwijdering na wettelijke termijn via batchjob.
+5. **Stabiele UUID's** — één identiteit per record; vector-hits en (later) graph-nodes wijzen altijd terug naar hetzelfde PostgreSQL-record.
+6. **BSN: opslaan, maar afgeschermd** — zorgaanbieders zijn wettelijk verplicht het BSN te gebruiken (Wabvpz: declaraties, Vecozo, verwijzingen), dus het ECD slaat het op — versleuteld in de database, toegang op need-to-know, elke inzage gelogd. De echte regel: het BSN komt **nooit** in AI-prompts, embeddings, logs of events richting TIP. (Wijkt bewust af van het architectuurdocument v0.1 — "alleen bsn_hash" past bij een AI-laag boven een bestaand EPD, niet bij een zelfstandig ECD; correctie meenemen in v0.2.)
+7. **Regels in het model, niet alleen in de UI** — "max één hoofddiagnose per traject" is een database-constraint.
+8. **Reproduceerbaar schema** — alles in migrations vanaf een verse baseline; de `conditions`-tabel-zonder-migration mag nooit meer gebeuren.
+9. **Statusmachines expliciet** — per entiteit: welke statussen, welke overgangen, wie mag ze zetten. In een referentietabel of check-constraint, niet impliciet in schermcode.
+
+### 3.2 AI-voorbereiding (vector + graph)
+- **Tekst en structuur in hetzelfde record** — elk verslag heeft gestructureerde velden (voor regels/filters) én vrije tekst (voor embeddings).
+- **pgvector vanaf dag één** — extensie in dezelfde PostgreSQL; embeddings in een aparte tabel (`record_id`, `chunk_index`, `embedding`, `model`, `content_hash`) zodat her-embedden en modelwissel geen schemawijziging zijn. Productie-les uit het veld: event-driven her-embedding (trigger bij mutatie) boven periodieke batch.
+- **Neo4j: ontwerpen, niet aanzetten** — de graph-vragen (ZPM: diagnose → prestatiecode → bevoegdheid) komen uit dezelfde bron-records; zolang ID's stabiel zijn kan de graaf later zonder migratie worden opgebouwd.
+
+### 3.3 Grensvlak met TIP
+- ECD = klinische feiten (bron van waarheid voor het dossier). TIP = proces-state en beslislogica.
+- Per entiteit leggen we in de discovery een kolom **eigenaarschap** vast: leidend in ECD, en welke gebeurtenissen als event naar TIP gaan.
+
+**Afstemming Joshua (17 juli 2026):**
+1. **TIP-eigen beslis-state** (workspaces, intents, taken) heeft geen ECD-tegenhanger — per definitie geen dubbeling. Brondata hoort bij de bron; het ECD is leidend.
+2. **Auditkopie**: TIP maakt een snapshot van de data waarop een intentie/nudge/actie is gebaseerd — doelgebonden, met herkomst erop. Zonder snapshot is niet herleidbaar waarop een besluit rustte; dit is juist het onderscheidend vermogen.
+3. **Longitudinale IE's**: voor trendmeting houdt TIP relevante informatie-elementen door de tijd vast. Bewuste, minimale dubbeling — TIP slaat alleen de IE's op die nodig zijn om tot intenties/nudges/acties te komen.
+4. **Koppelafspraak nodig**: hoe valt een wijziging in het ECD (correctie, soft delete) door naar TIP zodat de kopie niet veroudert? Het ECD-model levert hiervoor de bouwstenen die er al in zitten: stabiele UUID's, content-hash per record en mutatie-events (zelfde mechanisme als event-driven her-embedding, §3.2).
+
+Kortom: wel een bewuste, minimale, herleidbare kopie waar nodig; geen schaduwadministratie.
+
+## 4. Context: standaarden en koppelvlakken (geen datamodel-regels)
+
+Het datamodel ontwerpen we volledig op eigen termen, vanuit de feitzinnen. FHIR, zibs en openEHR zijn koppelvlak- en uitwisselingszaken; uitwisseling loopt via onze eigen API's. Deze learnings zijn relevant als achtergrond, maar stellen geen eisen aan het model:
+
+- **FHIR**: puur uitwisselformaat. Komt alleen ooit terug in een adapter of export (deployment model B richting bestaande EPD's).
+- **zibs (Nictiz)**: semantische definities van klinische begrippen. Bruikbaar als gratis checklist per entiteit ("welke velden hoort een verwijzing te hebben?", Wvggz-registratie-eisen) — het model blijft van ons.
+- **openEHR**: nemen we niet over; alleen de ontwerples "stabiele kern als schema, veranderlijke inhoud als data" — die al in het Triqura-architectuurdocument stond (ADR-03).
+- **Aandachtspunt** (geen regel): drijf semantisch niet nodeloos af van wat de Nederlandse zorg onder een begrip verstaat — dat houdt een eventuele adapter later goedkoop.
+
+## 5. Scope ronde 1: instroom t/m behandelplan
+
+**Scopeverbreding (sessie 17 juli 2026):** ronde 1 loopt van aanmelding t/m het opstellen van het behandelplan — dus inclusief wachtlijstbeheer (§5.3), diagnose stellen (§5.4) en behandelplan opstellen (§5.5). Agenda en rapportage & overdracht blijven latere rondes.
+
+### 5.0 Besluiten basis (sessie 16 juli, Colin)
+
+1. **Terminologie: "cliënt"** — overal, ook in tabelnamen. (Prototype mixte patients/cliënten.)
+2. **Persoon ≠ patiënt-zijn**: één CLIËNT-record per persoon; zorg is episodisch via AANMELDING (1 cliënt → meerdere aanmeldingen door de tijd).
+3. **Verwijzer is een eigen begrip** met type uit een waardelijst: huisarts, medisch specialist, GGZ-instelling, bedrijfsarts, gemeente, zelfaanmelding, crisis. Routes niet hardcoden.
+4. **Wettelijk kader hoort bij de aanmelding** (Zvw, Jeugdwet, Wmo, Wlz, forensisch) — bepaalt ook de financierings-/declaratiekant. Jeugd loopt onder de huidige wetgeving indirect via de gemeente.
+5. **Parallelle aanmeldingen**: nog geen besluit. Structuur ondersteunt meerdere; "max één actief" wordt een aan/uit-zetbare bedrijfsregel, geen schemabeperking.
+
+### 5.1 Feitzinnen basis (herzien na besluiten)
+
+1. *Persoon Jan de Vries is geboren op 12-03-1988.*
+2. *Jan de Vries is sinds 14 juli 2026 cliënt bij de instelling, onder cliëntnummer 427.*
+3. *Jan de Vries heeft zich op 14 juli 2026 aangemeld bij de instelling.*
+4. *Verwijzer P. Pietersen is van het type huisarts.*
+5. *Verwijzer P. Pietersen is verbonden aan praktijk/instelling "Huisartsenpraktijk De Vries & Pietersen".*
+6. *Praktijk/instelling "Huisartsenpraktijk De Vries & Pietersen" heeft AGB-code 12345678.*
+7. *Verwijzer P. Pietersen heeft zelf ook AGB-code 87654321 (persoonlijk, naast de praktijk-AGB).*
+8. *De aanmelding van 14 juli 2026 is ontvangen via verwijzer P. Pietersen.*
+9. *De aanmelding van 14 juli 2026 valt onder wettelijk kader Zvw.*
+10. *De aanmelding van 14 juli 2026 heeft als hulpvraag "somberheidsklachten, slaapproblemen".*
+11. *De aanmelding van 14 juli 2026 heeft status "nieuw".*
+12. *Bij de aanmelding van 14 juli 2026 is verwijsdocument document-812 (type: verwijsbrief) ontvangen.*
+13. *Cliënt Jan de Vries heeft toegang tot het cliëntportaal.*
+
+**Besluiten (sessie 17 juli 2026, Colin):**
+1. **PERSOON en CLIENT gesplitst.** PERSOON draagt de identiteit (naam, geboortedatum, BSN) en blijft bestaan onafhankelijk van zorg. CLIENT is een rol/koppeltabel op PERSOON (cliëntnummer, cliënt-sinds-datum), niet meer één platte entiteit. Reden: dezelfde persoon kan later ook een andere rol hebben (contactpersoon, wettelijk vertegenwoordiger van iemand anders' dossier, medewerker) zonder een dubbel persoonsrecord. Dit verfijnt besluit 5.0.2 ("persoon ≠ patiënt-zijn") — die tekst benoemde het onderscheid al, maar modelleerde nog één CLIENT-record; nu krijgt PERSOON zijn eigen entiteit.
+   - **BSN is optioneel op PERSOON.** Niet elke persoon heeft een BSN nodig in het systeem — een medewerker is ook een persoon. De verplichting hoort bij de rol: voor de cliëntrol is het BSN nodig (Wabvpz: declaraties, Vecozo, verwijzingen — zie spelregel 3.1 #6), voor andere rollen niet. Of dat een nudge wordt ("cliënt zonder BSN") of een rolgebonden eis, bepalen we bij de rollenronde.
+2. **VERWIJZER en PRAKTIJK_INSTELLING zijn twee losse entiteiten** — een verwijzer kan zonder praktijk bestaan (bijv. gemeente-ambtenaar), een praktijk kan meerdere verwijzers hebben.
+3. **AGB-verplichting hangt aan verwijzertype**, niet hardcoded per type in de applicatie: waardelijst `verwijzertype` krijgt attribuut `agb_verplicht (ja/nee)`. Huisarts/medisch specialist → ja, gemeente → nee. Zowel verwijzer als praktijk/instelling kunnen een eigen AGB-code hebben.
+4. **Geen AGB-validatie tegen Vecozo nu** — vrije invoer, validatie tegen een echte AGB-tabel parkeren we tot de declaratie-ronde.
+5. **Aanmelding-status is flexibel** — geen eenrichtingsflow, een besloten aanmelding kan terug naar "in screening" bij heropening. Basisstatussen: `nieuw → in screening → besloten`. Uitkomst bij `besloten`: `intake` / `afgewezen` / `doorverwezen` / `wachtlijst`.
+6. **Wie de status mag zetten blijft open** — rollen/disciplines zijn nog niet gemodelleerd; komt terug in die ronde.
+7. **Verwijsbrief blijft een nudge, geen harde schema-eis.** Ontbrekende verwijzing wordt een protocolregel (Nudge Engine), met severity die kan verschillen per financieringtype/regelgeving (bijv. `blokkade` bij Zvw-huisartsroute, `signaal` bij Wmo/Jeugdwet). Een beschikking telt ook als verwijzing: waardelijst `verwijsdocument_type` (verwijsbrief, beschikking, ...) i.p.v. één vast veld.
+8. **Cliëntportaaltoegang als losse entiteit `CLIENTPORTAAL_ACCOUNT`**, 1-op-0..1 op CLIENT (niet elke cliënt heeft portaaltoegang; een persoon zonder cliëntrol kan sowieso geen portaalaccount hebben). Authenticatiedetails (e-mail, provider-koppeling, status uitgenodigd/actief/geblokkeerd) werken we pas uit in de auth/ADM-ronde — hier alleen de relatie vastgelegd zodat de entiteitenkaart klopt.
+9. **ZORGEPISODE is een eigen entiteit** tussen aanmelding en de klinische records. De AANMELDING is de binnenkomst-*gebeurtenis* (verwijzer, hulpvraag, besluit); de ZORGEPISODE is de *periode van zorg* die bij uitkomst "intake" start. Aan de episode hangen: intakes (regulier én intern), diagnoses, behandelplannen en de behandelwachttijd. Bij de aanmelding blijven: screening en aanmeldwachttijd. Een afgewezen aanmelding heeft nooit een episode. Sluit straks aan op het ZPM-zorgtraject (declaratie-ronde). Open detail: ontstaat de episode al bij uitkomst "wachtlijst", of pas bij "intake"?
+
+**Open idee, nog geen besluit:** mogelijk krijgt ook een verwijzer toegang tot de status van zijn verwijzingen (verwijzersportaal, analoog aan `CLIENTPORTAAL_ACCOUNT` maar dan op VERWIJZER). Nog niet uitgewerkt en niet in de entiteitenkaart opgenomen — apart onderwerp voor een volgende ronde als dit een echte behoefte blijkt.
+
+Aanmelding → screening → intake. Dit is de eerste rebuild-module én de TIP-proefflow. Latere rondes: diagnose & behandeltraject, agenda, rapportage & overdracht.
+
+### 5.2 Feitzinnen screening & intake (herzien na sessie 17 juli)
+
+1. *Voor de aanmelding van Jan de Vries is op 15 juli 2026 een screening gestart.*
+2. *Bij de screening is op 16 juli 2026 een activiteit van type "telefonisch contact" geregistreerd door verpleegkundige K. Jansen, met toelichting "huisarts gesproken over medicatiehistorie".*
+3. *Het screeningsbesluit voor de aanmelding luidt "geschikt", met geadviseerde afdeling Volwassenen, genomen op 17 juli 2026.*
+4. *Op basis van de aanmelding van Jan de Vries is op 20 juli 2026 een intake gestart op afdeling Volwassenen, met aanleiding "regulier".*
+5. *De intake heeft status "bezig".*
+6. *Contactmoment van type "intakegesprek" op 22 juli 2026 is gevoerd door psycholoog M. de Boer.*
+7. *De kindcheck voor de intake is op 22 juli 2026 uitgevoerd: thuiswonende kinderen: nee.*
+8. *De intake is op 30 juli 2026 afgerond met uitkomst "in zorg".*
+9. *Verslag X is op 22 juli 2026 geschreven door M. de Boer.* / *Verslag Y is gegenereerd door AI-model Z op basis van bronnen A en B, en bevestigd door M. de Boer.*
+
+**Bevindingen prototype (verkenning 17 juli 2026):**
+- Afdelingen: drie onderling inconsistente hardcoded lijsten — screening biedt er 6 (incl. FACT, Verslaving), intake accepteert er 3 (andere labels: "Jeugd" vs "Jeugd (< 18 jaar)"), behandeladvies heeft een vierde lijst plus 4 "zorgprogramma's" (Algemeen GGZ, FACT, Verslaving, Trauma). FACT is op de ene plek afdeling, op de andere zorgprogramma.
+- Screeningsactiviteiten zijn nu vrije tekst zonder typering; contactmomenten in de intake hebben wél een typed lijst (Intakegesprek, Aanvullend onderzoek, Telefonisch contact, Huisbezoek, Overig).
+- Screeningsbesluit: `geschikt`/`niet_geschikt` + afdeling als vrije string.
+- Kindcheck is geen enkele uitkomstwaarde maar drie ja/nee-vlaggen + tekst (thuiswonende kinderen?, zorgen over veiligheid?, actie ondernomen?).
+- Intake afronden loopt via de behandeladvies-tab: checkbox + verplichte vervolgkeuze `in_zorg`/`doorverwijzing`/`extra_diagnostiek`, zet status `afgerond` + einddatum. Statussen: alleen `bezig`/`afgerond`.
+
+**Besluiten (sessie 17 juli 2026, Colin):**
+1. **Intake hangt aan de ZORGEPISODE** (aanvankelijk aan de aanmelding gemodelleerd; herzien met besluit §5.1 #9), niet direct aan de cliënt. Eén episode kan **meerdere intakes** hebben: naast de reguliere intake bestaan er interne intakes binnen een lopende episode (bijv. overgang naar een andere afdeling). De intake krijgt een **aanleiding** uit een waardelijst (regulier / intern / crisis — lijst te bevestigen).
+2. **AFDELING en ZORGPROGRAMMA zijn twee aparte waardelijsten.** Afdeling = organisatorische eenheid (Volwassenen, Jeugd, Ouderen, Forensisch, ...), zorgprogramma = inhoudelijk aanbod (FACT, Verslaving, Trauma, ...). FACT is een programma, geen afdeling. Welke afdelingen echt bestaan is per instelling configureerbaar — waardelijst, geen hardcoded lijst.
+3. **Screeningsactiviteiten krijgen een type uit een waardelijst + vrije toelichting** (telefonisch contact, dossieronderzoek, vragenlijst, overig — startlijst te bevestigen). Maakt nudges mogelijk ("nog geen contact geweest bij deze screening").
+4. **Screening vóór intake is een nudge, geen harde eis** — zelfde patroon als de verwijsbrief. Interne intakes en crisis maken een harde volgorde-eis onhoudbaar; hooguit een protocolregel bij de eerste intake van een episode.
+
+**Open vragen voor een volgende ronde:**
+- Verhouding screeningsbesluit ↔ aanmelding-uitkomst: "geschikt" (screening) en uitkomst "intake" (aanmelding) overlappen — is het besluit hetzelfde feit als de uitkomst, of twee aparte feiten?
+- Intake-uitkomstwaarden bevestigen: `in_zorg` / `doorverwijzing` / `extra_diagnostiek` (nu uit het prototype overgenomen).
+- Kindcheck: gestructureerde velden zoals het prototype (drie ja/nee-vlaggen + tekst) aanhouden, of anders?
+- Wie mag een intake afronden → rollenronde.
+- Verslagen (feitzin 9, provenance) → rapportage-ronde; de provenance-spelregel (3.1 #2) ligt al vast.
+
+### 5.3 Feitzinnen wachtlijstbeheer (startlijst — te corrigeren)
+
+Wachtlijst bestaat niet in het prototype (geen tabel, geen scherm) — alleen als roadmap-idee (prioriteit `spoed`/`normaal`/`laag`, wachtdagen, Treeknorm-nudges). We ontwerpen dit vanaf nul. Aanmelding-uitkomst `wachtlijst` bestaat al (§5.1 besluit 5); de vraag is wat daarachter zit.
+
+1. *De aanmelding van Jan de Vries is op 18 juli 2026 op de wachtlijst geplaatst voor afdeling Volwassenen.*
+2. *De wachtlijstplaatsing heeft prioriteit "normaal".*
+3. *De wachttijd van de plaatsing telt vanaf de aanmelddatum 14 juli 2026.*
+4. *De wachtlijstplaatsing is op 20 augustus 2026 beëindigd met reden "intake gestart".*
+5. *(nudge) Bij overschrijding van de Treeknorm voor aanmeldwachttijd volgt een signaal.*
+
+**Besluit (sessie 17 juli 2026, Colin):** WACHTLIJSTPLAATSING wordt een **eigen entiteit** (afdeling, prioriteit, begin/eind, beëindigingsreden), inzetbaar op **twee momenten**: vóór de intake (aanmeldwachttijd) én na de intake wachtend op behandeling (behandelwachttijd) — sluit aan op de Treeknormen die beide kennen. Soort plaatsing als waardelijst (`aanmeld`/`behandel`). Met besluit §5.1 #9: de aanmeldwachttijd hangt aan de AANMELDING, de behandelwachttijd aan de ZORGEPISODE.
+
+**Nog open:**
+- Wachtlijst per afdeling, per zorgprogramma, of beide?
+- Welke beëindigingsredenen: intake gestart / behandeling gestart / doorverwezen / cliënt trekt zich terug / ...?
+
+### 5.4 Feitzinnen diagnose stellen (startlijst — te corrigeren)
+
+Bevinding prototype: de module heet DSM-5 maar registreert feitelijk **ICD-10 F-codes** (`code_system: 'ICD-10'`, regex `F##.#`); "DSM-5" is een optioneel vrijetekstveld. Werkdiagnose-vs-definitief (FHIR `verification_status`) zit in de tabel maar de UI gebruikt het niet. Velden nu: ernst `licht`/`matig`/`ernstig`, type hoofd-/nevendiagnose, status `active`/`remission`/`resolved`/`inactive`. Diagnose hangt in het prototype aan de intake.
+
+1. *Voor de zorgepisode van Jan de Vries is op 24 juli 2026 diagnose F32.1 "matige depressieve episode" geregistreerd door psycholoog M. de Boer, gesteld tijdens de intake van 22 juli.*
+2. *Diagnose F32.1 is de hoofddiagnose.*
+3. *Diagnose F32.1 heeft ernst "matig".*
+4. *Diagnose F32.1 is een werkdiagnose.* / *Diagnose F32.1 is op 30 juli 2026 definitief vastgesteld.*
+5. *Diagnose F32.1 heeft status "actief".*
+6. *Diagnose F32.1 is op 1 december 2026 in remissie verklaard.*
+
+**Besluiten (sessie 17 juli 2026, Colin):**
+1. **DSM-5-TR is de primaire classificatie, met ICD-10-mapping** voor declaratie/uitwisseling. Behandelaren registreren in DSM-termen (bronregistratie), de ICD-10-code wordt afgeleid via een mappingtabel — geen dubbele handmatige invoer. (Het prototype deed het omgekeerd: ICD-10 als registratie, DSM als vrije tekst.)
+2. **De diagnose hangt aan de ZORGEPISODE** (besluit §5.1 #9), niet aan de intake. De diagnose overleeft de intake en wordt tijdens de behandeling bijgesteld; de intake waarin hij gesteld is wordt als herkomst vastgelegd (optionele verwijzing), niet als eigenaar.
+
+**Nog open:**
+- Werkdiagnose vs. definitief: aparte status-as naast klinische status (actief/remissie/opgelost) — voorlopig zo gemodelleerd (verificatiestatus + klinische status), bevestigen.
+- "Max één hoofddiagnose" (spelregel §3.1 #7): per wat — per episode, per moment in de tijd?
+- Wie mag een diagnose (definitief) stellen → rollenronde (regiebehandelaar).
+
+### 5.5 Feitzinnen behandelplan opstellen (startlijst — te corrigeren)
+
+Bevinding prototype: module gestript (AI-generatie negeerde diagnose/ernst), maar het typemodel is bekend: behandelstructuur (duur, frequentie, vorm), SMART-doelen (1-6, met cliëntversie in B1-taal, leefgebied, prioriteit), interventies (1-5, gekoppeld aan doelen), sessieplanning, evaluatiemomenten, veiligheidsplan (bij ernstige diagnose), leefgebieden-scores (7 domeinen, 0-10). Statussen waren inconsistent per laag (TS: `concept/actief/in_evaluatie/afgerond/gearchiveerd`; DB: `draft/active/on-hold/revoked/completed`).
+
+1. *Voor de zorgepisode van Jan de Vries is op 1 augustus 2026 een behandelplan opgesteld door M. de Boer.*
+2. *Het behandelplan heeft status "concept".*
+3. *Het behandelplan is gebaseerd op de intake van 20 juli 2026 en adresseert diagnose F32.1.*
+4. *Het behandelplan bevat behandeldoel "weer drie nachten per week doorslapen" met prioriteit hoog en beoogde termijn 12 weken.*
+5. *Behandeldoel X heeft een cliëntversie in B1-taal.*
+6. *Aan behandeldoel X is interventie "CGT" gekoppeld.*
+7. *Het behandelplan kent een evaluatiemoment in week 6.*
+8. *Cliënt Jan de Vries heeft op 5 augustus 2026 ingestemd met het behandelplan.*
+9. *Behandelplanversie 2 vervangt versie 1 per 15 september 2026.*
+
+**Besluit (sessie 17 juli 2026, Colin):** deze ronde modelleert de **plan-kern**: doelen, interventies, evaluatiemomenten, status, versiebeheer en cliëntakkoord. Sessieplanning → agenda-ronde; leefgebieden en veiligheidsplan → aparte beslissing later.
+
+**Nog open:**
+- Statusmachine: welke statussen echt (prototype-lagen waren inconsistent), en is cliëntakkoord een status of een los feit (WGBO)?
+- Versiebeheer: nieuw record per versie (zoals `care_plans.version` deed) of muteren met audit?
+- ~~Waar hangt het plan aan~~ — besloten: aan de ZORGEPISODE (besluit §5.1 #9), consistent met de diagnose.
+- Is een behandelplan verplicht vóór start behandeling — harde eis of nudge (ZPM kent `behandelplan_check` als regeltrigger)?
+
+## 6. Vervolg
+
+| Stap | Wat | Wie |
+|---|---|---|
+| 1 | Feitzinnen instroom corrigeren en aanvullen | Colin |
+| 2 | Entiteitenkaart instroom (HTML-visualisatie) | Claude |
+| 3 | Statussen + eigenaarschap (ECD/TIP) per entiteit | samen |
+| 4 | Zelfde cyclus voor diagnose/traject, agenda, rapportage | samen |
+| 5 | Pas daarna: schema-baseline (migrations) + `lib/dat/` | Claude |
+
+## Bronnen
+
+- [FCO-IM (Wikipedia)](https://en.wikipedia.org/wiki/FCO-IM) · [CaseTalk — About FCO-IM](https://www.casetalk.com/articles/introduction) · [Zwart e.a., Fact Oriented Modeling with FCO-IM](https://www.goodreads.com/book/show/27818248-fact-oriented-modeling-with-fco-im)
+- [Nictiz — Zorginformatiebouwstenen (zibs)](https://www.nictiz.nl/wat-we-doen/activiteiten/zibs/) · [Registratie aan de bron — zibs](https://www.registratieaandebron.nl/zorginformatiebouwstenen)
+- [openEHR — Design Principles](https://specifications.openehr.org/releases/1.0.1/html/architecture/overview/Output/design_principles.html) · [Archetype relational mapping (PMC)](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4636072/)
+- [dbi services — Embedding versioning met pgvector / event-driven her-embedding](https://www.dbi-services.com/blog/rag-series-embedding-versioning-with-pgvector-why-event-driven-architecture-is-a-precondition-to-ai-data-workflows/) · [pgvector RAG op managed PostgreSQL (2026)](https://danubedata.ro/blog/pgvector-rag-managed-postgres-2026)
+- [Append-only audit trails — designgurus](https://www.designgurus.io/answers/detail/how-do-you-enforce-immutability-and-appendonly-audit-trails) · [EHR audit trail — compliance & best practices](https://www.accountablehq.com/post/ehr-audit-trail-explained-what-it-is-compliance-requirements-and-best-practices)

docs/datamodel/deelmodellen/model-aanmelding.md

@@ -0,0 +1,547 @@
+# Datamodelvoorstel — Aanmelding & instroombasis
+
+**Status:** gesynchroniseerd 19 juli 2026 — AANMELDING/VERWIJZING/VERWIJSDOCUMENT/TOEWIJZING/ZORGEPISODE (§2.10–§2.13, §2.15) zijn vervangen door `model-instroom.md`; PERSOON/CLIENT/CLIENTRELATIE/VERWIJZER/PRAKTIJK_INSTELLING/CLIENT_HUISARTS/VERZEKERING/TOESTEMMING/CLIENTPORTAAL_ACCOUNT (§2.1–§2.9, §2.14, §2.16) blijven ongewijzigd geldig en worden door `model-instroom.md` hergebruikt, niet gedupliceerd  
+**Datum:** 18 juli 2026, gesynchroniseerd 19 juli 2026
+**Deelgebied (na sync):** PERSOON, CLIENT, CLIENTRELATIE, VERWIJZER, PRAKTIJK_INSTELLING, CLIENT_HUISARTS, VERZEKERING, TOESTEMMING, CLIENTPORTAAL_ACCOUNT
+**Bronnen:** `datamodel-discovery.md`, onderzoek-proces, onderzoek-leveranciers, onderzoek-standaarden, onderzoek-rapportage (details in §8)
+
+> **Let op:** dit document behandelde oorspronkelijk ook de instroomflow (AANMELDING, VERWIJZING, ZORGEPISODE). Die deelgebieden zijn na de FCO-IM-feitenronde van 19 juli 2026 volledig herzien en staan nu in `model-instroom.md` (feitzinnen: `../feitenmodellen/feitenmodel-instroom.md`; besluiten: B21–B30 in `../besluiten/besluitenlog-datamodel-2026-07-18.md`). De secties hieronder die nog AANMELDING/VERWIJZING/ZORGEPISODE beschrijven zijn behouden als historisch werkdocument, niet als actuele bron — gebruik ze 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) — **vervallen, zie `model-instroom.md`**
+
+*(Feitzinnen 17–25 hieronder zijn vervangen door `../feitenmodellen/feitenmodel-instroom.md` en de entiteiten in `model-instroom.md` — Professional Referral, Municipal Care Assignment, Referral Case. Behouden als historisch werkdocument.)*
+
+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) — **vervallen, zie `model-instroom.md`**
+
+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 — **vervallen, zie `model-instroom.md`**
+
+*(Feitzinnen 29–30 zijn achterhaald: de episode ontstaat sinds B22/B23 bij het acceptatiebesluit zelf, niet bij uitkomst "intake" — zie `model-instroom.md` §2.18 `clinical_care_episode`.)*
+
+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 — **vervallen, zie `model-instroom.md`**
+
+*(Vervangen door `referral_request` en `referral_case` in `model-instroom.md` §2.1, §2.6 — inclusief de daar herstelde velden `zpm_verwijstype`, `huisarts_geinformeerd_op` en `wettelijk_kader`. Behouden als historisch werkdocument; de waardelijsten `aanmeldkanaal`, `echelon`, `zpm_verwijstype` en `wettelijk_kader` in §4 hieronder blijven wel in gebruik.)*
+
+**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)* — **vervallen, zie `model-instroom.md`**
+
+*(Vervangen door `professional_referral` in `model-instroom.md` §2.14, inclusief het herstelde `heraanmelding`-veld en de vervangt-relatie voor correctie/aanvulling — zie B23.)*
+
+**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 — **vervallen, zie `model-instroom.md`**
+
+*(Vervangen door `submission_document` in `model-instroom.md` §2.3 — nu gekoppeld aan de submission die het document aanleverde, niet aan de aanmelding.)*
+
+**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)* — **vervallen, zie `model-instroom.md`**
+
+*(Vervangen door `municipal_care_assignment` in `model-instroom.md` §2.15 — zelfde minimale opzet, nu expliciet náást in plaats van in plaats van `professional_referral` gemodelleerd, met een vervangt-relatie voor herziene 301-berichten. Juridisch nog niet door een jurist bevestigd, zie B27.)*
+
+**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 — **vervallen, zie `model-instroom.md`**
+
+*(Vervangen door `clinical_care_episode` in `model-instroom.md` §2.18 — belangrijkste wijziging: ontstaat bij het acceptatiebesluit zelf (of een Wvggz-mandaat), niet meer bij uitkomst "intake". Alleen ontstaan/einde zijn daar uitgewerkt; het volledige episodemodel — programma-/organisatiebetrokkenheid, zorgteam — blijft een apart deelgebied.)*
+
+**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
+
+**Geldig (PERSOON/CLIENT-laag):**
+
+| 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 | TOESTEMMING | 1 — 0..n | |
+| CLIENT | CLIENTPORTAAL_ACCOUNT | 1 — 0..1 | |
+
+**Vervallen (AANMELDING/VERWIJZING/VERWIJSDOCUMENT/TOEWIJZING/ZORGEPISODE) —
+zie `model-instroom.md` §3 voor de actuele cardinaliteitentabel
+van `referral_request`/`referral_submission`/`referral_case`/
+`professional_referral`/`municipal_care_assignment`/`clinical_care_episode`:**
+
+| Van | Naar | Cardinaliteit | Toelichting |
+|---|---|---|---|
+| 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 | |
+
+**Naar andere deelgebieden** *(AANMELDING/ZORGEPISODE hieronder zijn de oude
+ankers; lees deze als `referral_case`/`clinical_care_episode` totdat
+screening/wachtlijst/intake/diagnose/behandelplan zelf zijn gesynchroniseerd)*:
+
+| 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:
+
+*(Nummering ongewijzigd gelaten — `model-instroom.md` §4 verwijst naar 12, 17 en 18 hieronder. Items 13–16, 19, 23 zijn vervallen ten gunste van waardelijsten in `model-instroom.md`; zie annotaties per item.)*
+
+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 *(vervallen — komt terug als `submission_channel` in `model-instroom.md` §4, met vergelijkbare waarden)*
+14. **aanmelding_status** — nieuw, in_screening, besloten *(vervallen — `referral_case` heeft geen statusveld meer, zie B25 en `model-instroom.md` §5)*
+15. **aanmelding_uitkomst** — intake, afgewezen, doorverwezen, wachtlijst *(vervallen — vervangen door de gesplitste `decision_outcome`/`follow_up_route` in `model-instroom.md` §4, zie B22)*
+16. **verwijsdocument_type** — verwijsbrief, beschikking, wlz_indicatiebesluit, huisartsmelding_60dagen, medische_verklaring_wvggz, overig *(vervallen — komt terug als `document_type` in `model-instroom.md` §4; de Wvggz-waarde hoort inmiddels bij `legal_mandate.medical_statement_reference`)*
+17. **echelon** — gb_ggz, g_ggz, onbekend *(blijft in gebruik — hergebruikt door `professional_referral` in `model-instroom.md`)*
+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 *(blijft in gebruik — hergebruikt door `referral_case.zpm_verwijstype` in `model-instroom.md`)*
+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)* **— nog niet geïntegreerd in `model-instroom.md`.** Dit is reële, niet-gedekte inhoud: `model-instroom.md` heeft alleen de grovere `follow_up_route`-waarde `doorverwijzen`, niet welke van de vijf erkende routes. Op te pakken bij de volgende instroom-ronde, niet stilzwijgend laten vervallen.
+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 *(vervallen — `clinical_care_episode` heeft geen statusveld, status volgt uit `ended_at`/`end_reason`, zie `model-instroom.md` §2.18)*
+24. **episode_einde_reden** — behandeling_afgerond, doorverwezen, client_beeindigt, geen_contact, overleden, overig *(startlijst; mapping op iStandaarden-redenen in de declaratie-ronde)* *(komt terug als `episode_end_reason` in `model-instroom.md` §4, aangevuld met `ingetrokken_door_client`/`acceptatiebesluit_herzien`, zie B24)*
+
+---
+
+## 5. Statusmachine
+
+### AANMELDING — **vervallen, zie `model-instroom.md`**
+
+*(`referral_case` heeft bewust geen statusveld meer — de actuele stand wordt afgeleid uit een gebeurtenistijdlijn, zie B25 en `model-instroom.md` §1/§5. Behouden als historisch werkdocument.)*
+
+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 — **vervallen, zie `model-instroom.md`**
+
+*(`clinical_care_episode` ontstaat bij het acceptatiebesluit zelf — ook tijdens de intakewachtlijst — niet meer bij uitkomst "intake"; zie B22 en `model-instroom.md` §2.18. Behouden als historisch werkdocument.)*
+
+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, 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
+
+> **Vervallen voor het instroomdeel, nog niet opnieuw uitgewerkt.** De events hieronder (`aanmelding_*`, `verwijzing_*`, `toewijzing_*`, `zorgepisode_*`) verwijzen naar entiteiten die niet meer bestaan. `model-instroom.md` bevat nog geen TIP-event-ontwerp — dat vereist een eigen ontwerpstap (welke gebeurtenis uit de nieuwe tijdlijn-aanpak een TIP-event triggert), niet alleen een naamsvervanging. Behouden als historisch werkdocument en als checklist van wat opnieuw moet worden doordacht. De rijen voor CLIENT/CLIENTRELATIE/CLIENT_HUISARTS/TOESTEMMING blijven wel geldig.
+
+**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
+
+**Status per punt na de instroom-sync (19 juli 2026):**
+
+1. **Ontstaansmoment ZORGEPISODE.** **Herzien, niet bekrachtigd zoals hier geadviseerd.** De uiteindelijke beslissing (B22) is dat de episode ontstaat bij het acceptatiebesluit zelf, óók bij vervolgroute intakewachtlijst — niet pas bij uitkomst "intake" zoals hier geadviseerd. Zie `model-instroom.md` §2.18.
+2. **VERWIJZING als eigen entiteit.** **Bevestigd zoals geadviseerd**, nu `professional_referral` (`model-instroom.md` §2.14), met als aanvulling een vervangt-relatie voor correctie/aanvulling (B23) die hier nog niet was voorzien.
+3. **Vaste huisarts via hergebruik van VERWIJZER/PRAKTIJK_INSTELLING.** **Al verwerkt** — CLIENT_HUISARTS (§2.8) gebruikt deze opzet al, geen open vraag meer. Blijft ongewijzigd bij de sync.
+4. **TOESTEMMING nu al als generieke entiteit.** **Al verwerkt** — TOESTEMMING (§2.14) bestaat al met deze opzet, geen open vraag meer. Blijft ongewijzigd bij de sync; `model-instroom.md` hergebruikt deze entiteit voor correspondentietoestemming.
+5. **Echelon op twee plekken.** **Deels opgelost.** Bron-echelon staat op `professional_referral.echelon`. Een "actueel echelon" op de episode zelf (voor op-/afschalen na de instroom) is niet meegenomen — `clinical_care_episode` in `model-instroom.md` is bewust beperkt tot ontstaan/einde; dit hoort bij het bredere, nog te ontwerpen episodemodel.
+6. **TOEWIJZING minimaal nu.** **Verder uitgewerkt dan hier geadviseerd.** `municipal_care_assignment` (`model-instroom.md` §2.15) bevat, op basis van juridisch onderzoek naar het WMO301/iJw301-bericht, al productcategorie/-code/volume/eenheid — verder dan de hier voorgestelde minimale variant.
+7. **Financieringsdetail Wlz/forensisch.** **Nog steeds open** — niet opgepakt in de instroom-ronde. `wettelijk_kader` kent de waarden wlz/forensisch al (waardelijst 12), maar een indicatiebesluit- of titel-registratie ontbreekt nog.
+8. **Terugval binnen 1 jaar.** **Bevestigd (nieuwe episode), met een aanvulling.** `possible_continuation_of_episode_id` (`model-instroom.md` §2.18) legt optioneel een zorginhoudelijke continuïteitsrelatie tussen de oude en nieuwe episode, expliciet **geen** autoritatieve trajectnummer-toets — die blijft, zoals hier al voorzien, bij de declaratie-ronde.
+9. **Huisarts-informeren als attribuut.** **Bevestigd zoals geadviseerd**, nu op `referral_case.huisarts_geinformeerd_op` (`model-instroom.md` §2.6) in plaats van op AANMELDING.
+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? **Nog steeds open** — niet opgepakt in de instroom-ronde; **advies blijft: 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 |

docs/datamodel/deelmodellen/model-behandelplan.md

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

docs/datamodel/deelmodellen/model-diagnose.md

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

docs/datamodel/deelmodellen/model-instroom.md

@@ -0,0 +1,849 @@
+# Datamodelvoorstel — Instroom (Referral Request/Submission/Case, acceptatiebesluit)
+
+**Status:** voorstel ter review — eerste entiteiten- en cardinaliteitenafleiding,
+op 19 juli 2026 drie reviewrondes doorlopen (technisch, GGZ-domein, UX, en
+GGZ-wetgeving — zie §9)
+**Datum:** 19 juli 2026
+**Scope:** Referral Request, Referral Submission, Referral Case, Professional
+Referral, Care Acceptance Decision, de gebeurtenissen rond een case
+(screening, informatieverzoek, intrekking, consolidatie), Wmo/Jeugdwet-
+toewijzing en Wvggz-mandaat als alternatieve instroomroutes, crisis­
+documentatie vóór identificatie, en het ontstaan/einde van Clinical Care
+Episode. Behandeladvies/intake-uitkomst blijft buiten scope (nog open
+onderzoek, zie feitenmodel §7 vraag 2).
+**Kader:** bouwt rechtstreeks op de bevestigde feitzinnen in
+`../feitenmodellen/feitenmodel-instroom.md`. Alle vragen uit diens §7 zijn
+beantwoord, behalve vraag 2. Dit is de stap "afleiding van entiteiten en
+cardinaliteiten" uit die §7.
+**Naamgeving:** entiteiten en attributen zijn Engelstalig, conform besluit
+B20. Dit wijkt af van het oudere, Nederlandstalige `model-aanmelding.md` —
+die synchronisatie (AANMELDING/VERWIJZING/ZORGEPISODE vervangen door dit
+voorstel) is een aparte, latere stap, niet in dit document.
+**Autoriteit:** `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft
+leidend.
+
+---
+
+## 1. Ontwerpprincipe: tijdlijn in plaats van statusmachine
+
+`Referral Case` heeft geen vaste, eenrichtings-statusmachine (feitenmodel §4,
+domeinreview 19 juli 2026). In plaats daarvan zijn dit de gebeurtenis-
+entiteiten die aan een case kunnen hangen, in willekeurige volgorde en
+herhaalbaar:
+
+- `submission_case_assignment` — een submission wordt aan de case toegewezen;
+- `screening_activity` — een screeningscontact of -onderzoek;
+- `case_information_request` — een informatieverzoek;
+- `care_acceptance_decision` — een (vervangend) acceptatiebesluit;
+- `case_withdrawal` — een cliënt-intrekking;
+- `case_consolidation` — een leidend-aanwijzing tussen twee cases.
+
+§7 werkt uit hoe de actuele stand van een case uit deze gebeurtenissen wordt
+afgeleid.
+
+## 2. Entiteiten
+
+### 2.1 referral_request
+
+**Doel:** het inhoudelijke verzoek om zorg of beoordeling. Eigen identiteit,
+los van de submission die het aanleverde en los van een eventuele formele
+verwijzing (feitenmodel §2, §6).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| person_id | ref PERSOON | nee *(zie hieronder — crisisaanmelding met onbekende identiteit)* |
+| person_identified_at | tijdstip | verplicht zodra `person_id` gevuld is |
+| person_identified_by | ref medewerker | verplicht zodra `person_id` gevuld is |
+| initiated_at | tijdstip | ja |
+| initiator_type | waardelijst `initiator_type` (professional/organisatie/cliënt/vertegenwoordiger) | ja |
+| initiator_reference | tekst of ref VERWIJZER | nee |
+| requested_scope | tekst (bv. “gespecialiseerde GGZ”) | ja |
+| presenting_need_text | tekst (de geuite zorgvraag) | ja |
+
+**Uniciteit:** één stabiele identiteit; zodra bekend precies één
+persoon/cliënt; minstens één initiator; bevat één of meer samenhangende
+geuite zorgvragen (geen los attribuut — volgt uit de scope van het request
+zelf, splitsing gebeurt door een nieuw request aan te maken).
+
+**Waarom `person_id` optioneel is:** bij crisisaanmeldingen kan de
+identiteit nog onbekend zijn op het moment dat het request al geregistreerd
+moet worden. Een placeholder- of "John Doe"-persoon die later wordt
+vervangen is bewust geen oplossing — dat vereist achteraf alle gekoppelde
+feiten naar de echte persoon te verplaatsen, wat tegen append-only ingaat.
+`person_identified_at`/`_by` maken de koppeling zelf een gedateerd,
+toegeschreven feit in plaats van een stille invulling (domeinreview 19 juli
+2026, was open punt 1).
+
+### 2.2 referral_submission
+
+**Doel:** één afzonderlijke binnenkomst, via één kanaal en op één
+ontvangstmoment (feitenmodel §2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| received_at | tijdstip | ja |
+| channel | waardelijst `submission_channel` (ZorgDomein/e-mail/telefoon/portaal/…) | ja |
+| source_reference | tekst of ref VERWIJZER | nee *(“onbekend” toegestaan)* |
+| recorded_by | ref medewerker | nee *(verplicht bij telefonische/handmatige registratie)* |
+| raw_note | tekst | nee |
+
+**Uniciteit:** één ontvangstmoment en kanaal; minstens één bron (evt.
+onbekend); nul of meer documenten; nooit overschreven door een latere
+aanvulling — een aanvulling is een nieuwe submission.
+
+### 2.3 submission_document
+
+**Doel:** een document dat bij een submission is ontvangen (S4, S8).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| submission_id | ref referral_submission | ja |
+| document_type | waardelijst `document_type` (verwijsbrief/diagnostische aanvulling/…) | ja |
+| document_reference | ref documentopslag (UUID) | ja |
+
+**Uniciteit:** geen — meerdere documenten per submission toegestaan.
+
+### 2.4 submission_request_link
+
+**Doel:** de expliciete koppeling van een submission aan één of meer
+requests (S5, S9, S12) — de submission zelf wordt nooit gekopieerd of
+gesplitst (feitenmodel §3.2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| submission_id | ref referral_submission | ja |
+| referral_request_id | ref referral_request | ja |
+| established_at | tijdstip | ja |
+
+**Uniciteit:** een submission kan 0..n requests representeren of aanvullen;
+elke bekende relatie is een eigen rij.
+
+**`link_type` vervalt (voorstel, ter evaluatie):** “representeert” versus
+“vult_aan” bleek bij toetsing geen zelfstandig feit met eigen gedrag of
+regels — geen enkele uniciteits- of optionaliteitsregel behandelt ze
+verschillend. Het onderscheid is puur chronologisch: de vroegste
+`submission_request_link` voor een request is per definitie degene die het
+representeerde, latere zijn per definitie aanvullingen. Dat volgt al uit
+`established_at` in combinatie met de al bestaande volgorde van submissions;
+een apart, door een mens te zetten waardelijst-veld zou dezelfde informatie
+dubbel opslaan. `established_at` wordt daarom verplicht (was optioneel) om
+deze afleiding altijd mogelijk te maken.
+
+### 2.5 submission_duplicate_assessment
+
+**Doel:** vastleggen dat een submission als duplicaat van een andere is
+beoordeeld (S13, S14).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| submission_id | ref referral_submission (het duplicaat) | ja |
+| duplicate_of_submission_id | ref referral_submission (het origineel) | ja |
+| assessed_by | ref medewerker | ja |
+| assessed_at | tijdstip | ja |
+| reason | tekst | ja |
+
+**Uniciteit:** geen destructieve werking — beide submissions blijven bestaan.
+
+### 2.6 referral_case
+
+**Doel:** het institutionele aanmeldingstraject voor één samenhangend
+beoordeelde zorgvraag (feitenmodel §2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| person_id | ref PERSOON | nee *(zelfde reden als bij referral_request — crisisaanmelding)* |
+| person_identified_at | tijdstip | verplicht zodra `person_id` gevuld is |
+| person_identified_by | ref medewerker | verplicht zodra `person_id` gevuld is |
+| opened_at | tijdstip | ja |
+| presenting_need_summary | tekst | ja |
+| wettelijk_kader | waardelijst `wettelijk_kader` (zvw/wmo/jeugdwet/wvggz) | ja *(overgenomen van AANMELDING in `model-aanmelding.md` §2.10 / discovery §5.0 besluit 4, was in dit voorstel per abuis niet meegenomen; bepaalt welke instroomroute — `professional_referral`, `municipal_care_assignment`, `legal_mandate` — van toepassing is, reviewronde 19 juli 2026)* |
+| zpm_verwijstype | waardelijst `zpm_verwijstype` | nee *(afleidbaar uit professional_referral/initiator_type, overschrijfbaar; verplicht richting declaratie bij Zvw — overgenomen van AANMELDING in `model-aanmelding.md` §2.10, was in dit voorstel per abuis niet meegenomen)* |
+| huisarts_geinformeerd_op | datum | nee *(instroom zonder verwijzing; nudge harde termijn 60 dagen — overgenomen van AANMELDING in `model-aanmelding.md` §2.10)* |
+
+**Uniciteit:** één stabiele identiteit; één institutioneel als samenhangend
+beoordeelde zorgvraag; gevoed door 1..n submissions (via
+`submission_case_assignment`) en 1..n requests (via `request_case_link`); geen
+vast statusveld (zie §1 en §7).
+
+**AGB-code en correspondentietoestemming:** geen nieuwe velden nodig — AGB
+van de verwijzer/praktijk loopt via `professional_referral.referrer_id` →
+VERWIJZER/PRAKTIJK_INSTELLING (al aanwezig, `model-aanmelding.md` §2.6–§2.7);
+correspondentietoestemming (verwijstype 04) valt onder de al bestaande
+generieke TOESTEMMING-entiteit (`model-aanmelding.md` §2.14), met
+`scope_aanmelding_id` wijzend naar deze case.
+
+### 2.7 submission_case_assignment
+
+**Doel:** de historiseerbare toewijzing van een submission aan een case
+(C3–C7).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| submission_id | ref referral_submission | ja |
+| referral_case_id | ref referral_case | ja |
+| assigned_at | tijdstip | ja |
+| assigned_by | ref medewerker | ja |
+| reason | tekst | nee |
+
+**Uniciteit:** een submission kan aan meerdere cases worden toegewezen
+(uitzondering, feitenmodel §3.3); toewijzing is een gebeurtenis, geen
+overschrijfbaar veld.
+
+### 2.8 request_case_link
+
+**Doel:** welke requests binnen een case worden behandeld, en sinds wanneer
+(C8, C9).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_request_id | ref referral_request | ja |
+| referral_case_id | ref referral_case | ja |
+| since | datum | ja |
+| reason | tekst | nee *(verplicht zodra een request aan meer dan één case gekoppeld is — uitzondering, feitenmodel §4)* |
+
+**Uniciteit:** een request hoort normaliter bij precies één case; koppeling
+aan meer dan één case is een expliciete uitzondering met reden en
+tijdgebonden historie.
+
+### 2.9 case_consolidation
+
+**Doel:** niet-destructieve leidend-aanwijzing tussen twee overlappende cases
+(C10–C13).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| primary_case_id | ref referral_case (leidend) | ja |
+| related_case_id | ref referral_case (niet-leidend, blijft bestaan) | ja |
+| overlap_assessed_at | tijdstip | nee |
+| designated_at | tijdstip | ja |
+| designated_by | ref medewerker | ja |
+| reason | tekst | ja |
+
+**Bevoegdheid (voorstel, ter evaluatie):** geen speciale `decision_authority`
+vereist — elke medewerker die de case behandelt kan consolideren, net als bij
+`submission_case_assignment` en `submission_duplicate_assessment`. Consolidatie
+is een administratieve correctie (welke case leidend is voor rapportage),
+geen inhoudelijk besluit over zorgtoegang; zij creëert of beëindigt geen
+zorgconsequentie zoals `care_acceptance_decision` dat wel doet. Alleen een
+mens mag dit vaststellen — AI mag hooguit een match voorstellen (B1) — maar
+dat is een ander soort eis dan beslisbevoegdheid.
+
+**Uniciteit:** beide cases behouden hun eigen identiteit en historie na
+aanwijzing; geen merge, geen verwijdering. `related_case_id` is uniek: een
+case kan in hoogstens één consolidatie de niet-leidende rol vervullen
+(`UNIQUE(related_case_id)`); `primary_case_id` blijft vrij herhaalbaar. Een
+case mag zichzelf niet consolideren (`CHECK(primary_case_id <>
+related_case_id)`). Transitieve cykels (A leidend over B, B leidend over A)
+worden hierdoor niet uitgesloten en blijven een proces-/applicatie­
+verantwoordelijkheid (reviewronde 19 juli 2026, zie §9).
+
+### 2.10 screening_activity
+
+**Doel:** een concrete screeningsactiviteit binnen een case (G1–G4). Levert
+zelf geen apart advies op (feitenmodel §3.4). *(De aparte, lege
+`screening`-groeperingsentiteit uit de eerste versie is vervallen — geen
+enkel eigen attribuut, geen onderscheidend kenmerk tussen meerdere
+groeperingen; als een echte, benoembare screeningsronde ooit nodig blijkt,
+komt die terug als event-entiteit met eigen attributen. Reviewronde 19 juli
+2026, zie §9.)*
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| performed_at | tijdstip | ja |
+| activity_type | waardelijst `screening_activity_type` (telefonisch contact/dossieronderzoek/vragenlijst/…) | ja |
+| performed_by | ref medewerker | ja |
+| notes | tekst | nee |
+| funded | ja/nee | nee *(default nee — screeningscontact is meestal niet gefinancierd, feitenmodel §3.4)* |
+
+**Uniciteit:** geen — 0..n activiteiten per screening.
+
+### 2.11 case_information_request
+
+**Doel:** een informatieverzoek als eigen gebeurtenisfeit, niet als
+besluituitkomst of statusveld (feitenmodel §7 vraag 5, A28–A29).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| requested_at | tijdstip | ja |
+| requested_by | ref medewerker | ja |
+| requested_information | tekst | ja |
+| resolved_by_submission_id | ref referral_submission | nee |
+
+**Uniciteit:** geen — een case kan meerdere informatieverzoeken hebben, ook
+ná een eerder acceptatiebesluit tijdens een heroverweging.
+
+### 2.12 care_acceptance_decision
+
+**Doel:** het formele besluit dat de beoordeling van een case afrondt: draagt
+zelf de onderliggende beoordelingen, de besluituitkomst, de vervolgroute en,
+bij afwijzing, de onderbouwing (feitenmodel §2, §3.5, §4).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| decided_at | tijdstip | ja |
+| decided_by | ref medewerker | ja |
+| decision_authority_id | ref decision_authority | ja |
+| content_match | ja/nee | ja |
+| capacity_available | ja/nee | nee |
+| program_context | ref care_program of tekst | nee |
+| decision_outcome | waardelijst `decision_outcome` (`geaccepteerd`/`afgewezen`) | ja |
+| follow_up_route | waardelijst `follow_up_route` (intake_direct/intakewachtlijst/spoedroute/doorverwijzen/case_afsluiten) | ja |
+| rationale | tekst | verplicht bij `afgewezen`, anders optioneel |
+| replaces_decision_id | ref care_acceptance_decision (zelfreferentie) | nee |
+| replacement_reason | tekst | verplicht als `replaces_decision_id` gevuld is |
+
+**Uniciteit:** precies één case, beslisser, besluitdatum, besluituitkomst en
+vervolgroute per besluit. Optioneel precies één eerder besluit van dezelfde
+case vervangen — het vervangen besluit blijft ongewijzigd bewaard (feitenmodel
+§4, §7 vraag 3). Capaciteit bepaalt de uitkomst niet automatisch (Route 2A/2B).
+`replaces_decision_id` is uniek indien gevuld (partial unique index): een
+besluit kan door hoogstens één ander besluit worden vervangen, zodat de
+vervangt-keten nooit vertakt. Zonder die garantie zouden twee besluiten
+tegelijk "niet vervangen" kunnen zijn en zou de afleidingsregel in §5 geen
+eenduidig geldig besluit meer opleveren. Het geldige besluit van een case is
+het laatste, niet-vervangen besluit in de keten. *(Concurrency bij
+gelijktijdige heroverwegingen — bijvoorbeeld via `SELECT ... FOR UPDATE` op
+de keten-tail — is een implementatiedetail voor de migratie-/API-laag, niet
+voor dit document.)*
+
+**Kettingdiepte (voorstel, ter evaluatie):** onbeperkt toegestaan, geen aparte
+constraint. De afleidingsregel in §5 ("volg de vervangt-keten naar het
+laatste, niet-vervangen besluit") werkt voor elke kettinglengte zonder extra
+modellering. Een harde grens van één niveau zou een legitieme
+correctie-op-een-correctie blokkeren zonder dat daar een aantoonbare
+praktijkreden voor is — de feitzinnen tonen alleen één niveau omdat dat het
+scenario was, niet omdat een tweede niveau problematisch zou zijn.
+
+### 2.13 case_withdrawal
+
+**Doel:** cliënt-intrekking van een case, geen besluit en geen
+bevoegdheidseis (feitenmodel §3.5 Route 4, §7 vraag 4).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| withdrawn_at | tijdstip | ja |
+| recorded_by | ref medewerker | ja |
+| note | tekst | nee |
+
+**Uniciteit:** geen — kan op elk moment plaatsvinden, ook ná een positief
+besluit.
+
+### 2.14 professional_referral
+
+**Doel:** de formele Nederlandse VERWIJZING, zelfstandig object gekoppeld aan
+een request (R6–R10, feitenmodel §2, §6).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_request_id | ref referral_request | ja |
+| referrer_id | ref VERWIJZER | ja |
+| referral_date | datum | ja |
+| echelon | waardelijst `echelon` | nee |
+| suspected_condition | tekst | nee |
+| heraanmelding | ja/nee | ja (default nee) *(overgenomen van VERWIJZING in `model-aanmelding.md` §2.11, was in dit voorstel per abuis niet meegenomen)* |
+| replaces_referral_id | ref professional_referral (zelfreferentie) | nee |
+| replacement_reason | tekst | verplicht als `replaces_referral_id` gevuld is |
+
+**Uniciteit:** eigen identiteit, gekoppeld aan precies één request. Een
+request kan 0..n professional referrals hebben: een correctie of aanvulling
+op een eerdere verwijzing is geen nieuw request maar een nieuwe
+`professional_referral` die de vorige vervangt — dezelfde
+vervangt-constructie als bij `care_acceptance_decision` (domeinreview 19 juli
+2026, was open punt 1). De vervangen verwijzing blijft ongewijzigd bewaard;
+het geldige exemplaar is het laatste, niet-vervangen record in de keten.
+`replaces_referral_id` is, net als bij `care_acceptance_decision`, uniek
+indien gevuld — zelfde reden: voorkomt vertakking van de keten.
+
+**AGB-code:** geen apart veld — loopt via `referrer_id` → VERWIJZER, dat al
+een `agb_code` draagt (`model-aanmelding.md` §2.6).
+
+### 2.15 municipal_care_assignment *(voorstel, gebaseerd op juridisch onderzoek 19 juli 2026 — zie §9)*
+
+**Doel:** de gemeentelijke beschikking/toewijzing (Wmo/Jeugdwet, iWmo/iJw
+301-bericht) als toegangsticket naast — niet in plaats van — een eventuele
+`professional_referral`. Bij Jeugdwet bestaat een zelfstandige professionele
+verwijsroute náást de gemeentelijke toewijzing (een cliënt kan dus beide
+hebben); bij Wmo bestaat geen professionele verwijsroute, alleen de
+gemeentelijke toegang.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_request_id | ref referral_request | ja |
+| legal_framework | waardelijst `municipal_legal_framework` (wmo/jeugdwet) | ja |
+| municipality_code | tekst (CBS-gemeentecode) | ja |
+| assignment_number | tekst (toewijzings-/beschikkingsnummer) | ja |
+| product_category | waardelijst `municipal_product_category` | ja |
+| product_code | tekst | ja |
+| volume | getal | ja |
+| unit | waardelijst `municipal_product_unit` | ja |
+| frequency | tekst | ja |
+| start_date | datum | ja |
+| end_date | datum | nee |
+| issued_at | tijdstip | ja |
+| replaces_assignment_id | ref municipal_care_assignment (zelfreferentie) | nee |
+| replacement_reason | tekst | verplicht als `replaces_assignment_id` gevuld is |
+
+BSN, geboortedatum, geslacht en adres van de cliënt komen niet terug als
+eigen velden — die lopen via PERSOON (al bestaand, niet dubbel modelleren).
+AGB-code van de aanbieder loopt via de bestaande PRAKTIJK_INSTELLING-entiteit.
+
+**Uniciteit:** `assignment_number` uniek per `municipality_code`. Zelfde
+vervangt-mechaniek als `professional_referral`/`care_acceptance_decision`
+(gemeenten sturen herziene 301-berichten) — `replaces_assignment_id` uniek
+indien gevuld, onbeperkte kettingdiepte.
+
+### 2.16 legal_mandate *(voorstel, gebaseerd op juridisch onderzoek 19 juli 2026 — zie §9)*
+
+**Doel:** het wettelijke mandaat bij gedwongen zorg (Wvggz): crisismaatregel
+of zorgmachtiging. Bij een crisismaatregel heeft de instelling geen
+discretionaire ruimte — het burgemeesterlijk besluit (op basis van een
+medische verklaring) is zelf bindend; er bestaat geen apart institutioneel
+acceptatiebesluit ernaast. Dit vervangt dus geen `care_acceptance_decision`,
+het is een eigen soort feit met een andere aard (wettelijke plicht, geen
+discretionaire beoordeling).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| mandate_type | waardelijst `mandate_type` (crisismaatregel/zorgmachtiging) | ja |
+| decision_reference | tekst (besluit-/beschikkingsnummer) | ja |
+| decided_by_role | waardelijst `mandate_decider_role` (burgemeester/rechter) | ja |
+| decided_at | tijdstip | ja |
+| medical_statement_reference | ref document (medische verklaring psychiater) | verplicht bij `crisismaatregel` |
+| effectuated_at | tijdstip (tenuitvoerlegging) | ja |
+| valid_from | tijdstip | ja |
+| valid_until | tijdstip | nee |
+
+*(Aanname, te bevestigen door een jurist: geen apart institutioneel
+acceptatiebesluit náást een mandaat, ook niet bij zorgmachtiging — het
+juridisch onderzoek noemt dit "aannemelijk", niet met een wetsartikel
+bevestigd. De 24-uurstermijn voor tenuitvoerlegging bij een crisismaatregel
+is een nudge-regel, geen opgeslagen constraint.)*
+
+**Uniciteit:** geen vervangt-mechaniek voorgesteld — een crisismaatregel kan
+overgaan in een machtiging tot voortzetting/zorgmachtiging, maar dat is een
+nieuw mandaat met eigen `decision_reference`, geen correctie van het vorige.
+
+### 2.17 crisis_encounter_note *(voorstel, gebaseerd op juridisch onderzoek 19 juli 2026 — zie §9)*
+
+**Doel:** gestructureerde vastlegging van crisisgerelateerd handelen vóórdat
+identificatie of volledige dossiervorming heeft plaatsgevonden (gesignaleerd
+thema, zie §6-geschiedenis in §9). Losstaand van `screening_activity`, dat
+over het beoordelingsproces gaat, niet over klinisch handelen.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| occurred_at | tijdstip | ja |
+| recorded_by | ref medewerker | ja |
+| fact_type | waardelijst `crisis_fact_type` (medicatie_toegediend/risico_inschatting/vitale_functie/dwangmaatregel/overig) | ja |
+| description | tekst | ja |
+| structured_value | tekst/JSON | nee |
+
+**Onderbouwing:** geen expliciet wetsartikel gevonden dat gestructureerde
+vastlegging tíjdens de crisisinterventie zelf verplicht (juridisch onderzoek
+19 juli 2026) — de algemene WGBO-dossierplicht ondersteunt dit wel in
+algemene zin. Alle gestructureerde velden blijven daarom optioneel op
+`description` na. `fact_type = dwangmaatregel` verwijst waar mogelijk naar de
+formele Wvggz-dwangregistratie in plaats van die te dupliceren.
+
+**Nudge, geen constraint:** een generieke termijn van 14 dagen na de
+behandeling waarbinnen een cliënt zich alsnog moet identificeren is
+gevonden (juridisch onderzoek 19 juli 2026, bron niet met artikelnummer
+bevestigd). Dit wordt een signaal-nudge gekoppeld aan
+`referral_request.person_identified_at IS NULL`, geen blokkerende regel en
+geen attribuut op deze entiteit — de termijn hangt aan identificatie, niet
+aan de crisisnotitie.
+
+### 2.18 clinical_care_episode *(alleen ontstaan/einde — volledig episodemodel is een ander deelgebied)*
+
+**Doel:** de geaccepteerde zorgperiode die ontstaat uit een positief
+acceptatiebesluit óf een geldig wettelijk mandaat, ook vóór de feitelijke
+start van de intake (feitenmodel §3.5, §4; mandaat-route: juridisch
+onderzoek 19 juli 2026).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| originating_decision_id | ref care_acceptance_decision | nee *(zie XOR-regel hieronder)* |
+| originating_mandate_id | ref legal_mandate | nee *(zie XOR-regel hieronder)* |
+| started_at | tijdstip | ja |
+| ended_at | tijdstip | nee |
+| end_reason | waardelijst `episode_end_reason` | verplicht zodra `ended_at` gevuld is |
+| possible_continuation_of_episode_id | ref clinical_care_episode (zelfreferentie) | nee |
+
+**Uniciteit:** `CHECK` dat precies één van `originating_decision_id` /
+`originating_mandate_id` gevuld is — een episode ontstaat óf uit een
+acceptatiebesluit óf uit een mandaat, nooit uit beide of geen van beide.
+Maximaal één episode per geldig positief acceptatiebesluit of geldig
+mandaat. Een episode wordt nooit verwijderd; intrekking of correctie sluit
+haar af met een reden (`ingetrokken_door_client`, `acceptatiebesluit_herzien`,
+…) in plaats van haar te laten vervallen. Overige einde-redenen (bijvoorbeeld
+“behandeling afgerond”) horen bij een later deelgebied.
+
+**`possible_continuation_of_episode_id` (voorstel, tussenoplossing — zie
+§9):** systeem-gesuggereerd op basis van een gap ≤ 365 dagen tussen
+`ended_at` van de vorige episode (zelfde `person_id`) en `started_at` van
+deze episode; een mens bevestigt. **Expliciete disclaimer:** dit is een
+zorginhoudelijke continuïteitsaanwijzing voor het behandelteam, **geen**
+autoritatieve NZa-toets voor zorgtrajectnummer-hergebruik — die toets hangt
+aan de datum van de laatst geleverde prestatie bij dezelfde zorgaanbieder
+(niet aan de episode-einddatum) en hoort bij een nog niet bestaand
+declaratie-/prestatieregistratie-deelgebied. Bewust niet "heraanmelding"
+genoemd om verwarring met `professional_referral.heraanmelding` (een
+ZPM-verwijstype-vlag, ander begrip) te voorkomen.
+
+### 2.19 case_urgency_assessment *(voorstel, domeinreview 19 juli 2026 — zie §9)*
+
+**Doel:** urgentie als herhaalbare beoordeling, geen vast veld. Vastgesteld
+tijdens screening/triage door de rol screener of triagist, en kan later
+worden aangepast door het intake-team of in een MDO. Consistent met het
+tijdlijn-principe van dit document (§1): geen vervangt-relatie nodig zoals
+bij `care_acceptance_decision` — de laatste beoordeling geldt, de inzet is
+lager dan bij een acceptatiebesluit.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| referral_case_id | ref referral_case | ja |
+| assessed_at | tijdstip | ja |
+| assessed_by | ref medewerker | ja |
+| assessed_in_role | waardelijst `urgency_assessor_role` (screener/triagist/intake_team/mdo) | ja |
+| urgency_level | waardelijst `urgency_level` | ja |
+
+**Uniciteit:** geen — 0..n beoordelingen per case; de meest recente bepaalt
+de actuele urgentie (zelfde afleidingspatroon als §5). Geen verplichte
+onderbouwing bij de urgentiewaarde zelf (bevestigd door Colin — eenvoudige
+waardelijst volstaat).
+
+### 2.20 episode_team_involvement *(minimale, voorlopige hook — zie §9)*
+
+**Doel:** vastleggen dat een team bij een episode betrokken is, ook wanneer
+er nog geen individuele behandelaar is toegewezen (bijvoorbeeld: geaccepteerd
+met vervolgroute intakewachtlijst, Route 2A). Dit is **niet** het volledige
+zorgteam-concept — zorgteam (het team van betrokken behandelaren, met
+regie-/hoofdbehandelaarschap en rollen, en later mogelijk cliëntautorisatie)
+is een zelfstandig begrip, los van zorgprogramma en organisatorische eenheid,
+en krijgt een eigen feitenronde (besluitenlog §10 punt 3; begrippenlijst
+`Episode Clinical Team`). Deze entiteit is een minimale, voorlopige hook die
+door die toekomstige ronde wordt vervangen of geabsorbeerd — geen rollen,
+geen bevoegdheid, geen individueel lidmaatschap.
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| clinical_care_episode_id | ref clinical_care_episode | ja |
+| team_reference | tekst *(voorlopig vrije tekst — geen Team-entiteit vóór de zorgteam-ronde)* | ja |
+| involved_since | tijdstip | ja |
+| recorded_by | ref medewerker | ja |
+
+**Uniciteit:** geen — een episode kan door de tijd heen bij meerdere teams
+betrokken zijn (bijvoorbeeld bij op-/afschalen); geen statusveld, zelfde
+tijdlijn-principe.
+
+## 3. Relaties met cardinaliteit
+
+**Legenda:** `Van | Naar | A..B..C` — A is de multipliciteit van *Van* per
+één rij *Naar* (meestal `1` bij een verplichte FK op *Naar*; is die FK
+optioneel, dan wordt A zelf `0..1` en vervalt het derde token, dus `A..B`).
+`B..C` is de multipliciteit van *Naar* per één rij *Van*, als min..max
+(`n` = onbegrensd). Rijen met `(self)` beschrijven alleen het
+zelfreferentie-FK-veld, geen relatie tussen twee tabellen (reviewronde 19
+juli 2026, zie §9).
+
+| Van | Naar | Cardinaliteit | Toelichting |
+|---|---|---|---|
+| referral_request | PERSOON | n..0..1 | optioneel — zie person_identified_at |
+| referral_case | PERSOON | n..0..1 | optioneel — zie person_identified_at |
+| referral_request | professional_referral | 1..0..n | correctie/aanvulling is een vervangend record, geen nieuw request |
+| referral_submission | submission_document | 1..0..n | een submission kan zonder documenten bestaan |
+| referral_submission | submission_request_link | 1..0..n | een submission kan nul, één of meerdere requests representeren/aanvullen |
+| referral_request | submission_request_link | 1..1..n | elk request is via minstens één submission binnengekomen |
+| referral_submission | submission_duplicate_assessment | 1..0..n | een submission kan als duplicaat van meerdere andere zijn beoordeeld (zeldzaam, toegestaan) |
+| referral_case | submission_case_assignment | 1..1..n | een case wordt door minstens één submission gevoed |
+| referral_submission | submission_case_assignment | 1..0..n | een submission kan (uitzonderlijk) aan meerdere cases zijn toegewezen |
+| referral_case | request_case_link | 1..1..n | een case behandelt minstens één request |
+| referral_request | request_case_link | 1..1..n(uitzondering) | normaliter 1 case, bij uitzondering meer (feitenmodel §4) |
+| referral_case | case_consolidation | 1..0..n | een case kan leidend zijn over meerdere andere, of zelf niet-leidend zijn in precies één consolidatie (UNIQUE(related_case_id)) |
+| referral_case | screening_activity | 1..0..n | direct aan de case, geen aparte groeperingsentiteit meer |
+| referral_case | case_information_request | 1..0..n | |
+| referral_submission | case_information_request | 0..1 | een submission kan een reactie zijn op hoogstens één informatieverzoek (beide kanten optioneel-enkelvoudig, vandaar geen derde token) |
+| referral_case | care_acceptance_decision | 1..0..n | 0 zolang nog geen besluit; n bij heroverweging/correctie |
+| care_acceptance_decision | care_acceptance_decision | 0..1 (self) | `replaces_decision_id`, optioneel en uniek indien gevuld — voorkomt vertakking; onbeperkte kettingdiepte (voorstel) |
+| professional_referral | professional_referral | 0..1 (self) | `replaces_referral_id`, optioneel en uniek indien gevuld — voorkomt vertakking; onbeperkte kettingdiepte (voorstel) |
+| referral_case | case_withdrawal | 1..0..n | doorgaans 0 of 1, technisch meerdere niet uitgesloten |
+| referral_request | municipal_care_assignment | 1..0..n | naast, niet in plaats van `professional_referral` (voorstel) |
+| municipal_care_assignment | municipal_care_assignment | 0..1 (self) | `replaces_assignment_id`, optioneel en uniek indien gevuld (voorstel) |
+| referral_case | legal_mandate | 1..0..n | crisismaatregel kan overgaan in zorgmachtiging: nieuw mandaat, geen vervangt-relatie (voorstel) |
+| referral_case | crisis_encounter_note | 1..0..n | werkt al zonder `person_id` (voorstel) |
+| care_acceptance_decision | clinical_care_episode | 1..0..1 | XOR met `legal_mandate`; alleen bij uitkomst `geaccepteerd` |
+| legal_mandate | clinical_care_episode | 1..0..1 | XOR met `care_acceptance_decision` (voorstel) |
+| clinical_care_episode | clinical_care_episode | 0..1 (self) | `possible_continuation_of_episode_id`, optioneel, tussenoplossing (voorstel) |
+| referral_case | case_urgency_assessment | 1..0..n | herhaalbaar, laatste geldt (voorstel) |
+| clinical_care_episode | episode_team_involvement | 1..0..n | minimale hook, geen individueel lidmaatschap (voorstel) |
+
+## 4. Waardelijsten (startlijsten, te bevestigen)
+
+| Waardelijst | Voorlopige waarden |
+|---|---|
+| `initiator_type` | professional, organisatie, cliënt, vertegenwoordiger |
+| `submission_channel` | ZorgDomein, e-mail, telefoon, portaal, post, overig |
+| `document_type` | verwijsbrief, diagnostische aanvulling, beschikking, overig |
+| `screening_activity_type` | telefonisch contact, dossieronderzoek, vragenlijst, overig |
+| `decision_outcome` | geaccepteerd, afgewezen |
+| `follow_up_route` | intake_direct, intakewachtlijst, spoedroute, doorverwijzen, case_afsluiten |
+| `episode_end_reason` | ingetrokken_door_client, acceptatiebesluit_herzien, *(overige waarden: later deelgebied)* |
+| `echelon` | over te nemen uit `model-aanmelding.md` §4 waardelijst 17 (bestaande waardelijst) |
+| `zpm_verwijstype` | over te nemen uit `model-aanmelding.md` §4 waardelijst 18 (bestaande waardelijst, ZPM-verwijstypen 01–07) |
+| `wettelijk_kader` | over te nemen uit `model-aanmelding.md` §4 waardelijst 12 (bestaande waardelijst: zvw, wmo, jeugdwet, *(wvggz toe te voegen)*) |
+| `municipal_legal_framework` | wmo, jeugdwet *(voorstel)* |
+| `municipal_product_category` / `municipal_product_unit` | over te nemen uit iWmo/iJw-standaard (voorstel, nog niet uitgezocht) |
+| `mandate_type` | crisismaatregel, zorgmachtiging *(voorstel)* |
+| `mandate_decider_role` | burgemeester, rechter *(voorstel)* |
+| `crisis_fact_type` | medicatie_toegediend, risico_inschatting, vitale_functie, dwangmaatregel, overig *(voorstel)* |
+| `urgency_assessor_role` | screener, triagist, intake_team, mdo *(voorstel)* |
+| `urgency_level` | laag, normaal, hoog, spoed *(voorstel)* |
+
+Alle waardelijsten volgen het bestaande patroon (referentietabel met
+`code`, `omschrijving`, `geldig_van`/`geldig_tot`, `actief` — spelregel 3.1
+#1) en zijn hier nog geen definitieve besluiten.
+
+## 5. Waardelijst-vervanging: geen klassieke statusmachine
+
+`referral_case` heeft bewust geen `status`-kolom met vaste overgangen. De
+actuele stand wordt afgeleid door de gebeurtenissen in tijdsvolgorde te
+lezen:
+
+1. Is er een `case_withdrawal` zonder latere `care_acceptance_decision`? →
+   case is ingetrokken.
+2. Is er een `care_acceptance_decision` die niet door een ander besluit is
+   vervangen (`replaces_decision_id` wijst niet naar dit besluit)? → dat is
+   het geldige besluit; de case is besloten met die uitkomst.
+3. Is er een openstaand `case_information_request` zonder latere
+   `care_acceptance_decision` of `case_withdrawal`? → case wacht op
+   aanvullende informatie.
+4. Geen van bovenstaande? → case is in beoordeling (screening loopt of moet
+   nog beginnen).
+
+Dit is een leesregel voor de applicatielaag, geen opgeslagen veld — zo blijft
+de volledige tijdlijn de bron (consistent met B7 wachtlijst).
+
+**Implementatie-eis (UX-review 19 juli 2026, zie §9):** deze afleidingsregel
+wordt precies één keer geïmplementeerd, in één centrale, herbruikbare
+projectie (bijvoorbeeld een view of materialized read-model), niet los per
+scherm. Werklijst, dashboard en detailpagina lezen allemaal diezelfde
+projectie, nooit de losse events elk apart opnieuw. Zonder die eis ontstaat
+het risico dat schermen subtiel verschillende interpretaties van "de actuele
+stand" tonen — precies de drift die het tijdlijn-principe moest voorkomen.
+
+## 6. Buiten scope van dit document
+
+- Het volledige `clinical_care_episode`-model (programma-/organisatie-
+  betrokkenheid, zorgteam) — apart deelgebied, alleen ontstaan/einde hier.
+- `clinical_intake_assessment` en het behandeladvies — vraag 2 uit het
+  feitenmodel is nog open onderzoek.
+- PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING — al uitgewerkt in
+  `model-aanmelding.md` §2.1–§2.9; dit voorstel refereert ernaar zonder te
+  dupliceren.
+- Waardelijst-governance (wie mag waarden toevoegen) — ADM-ronde.
+- Declaratie-/prestatieregistratie-deelgebied — nodig voor de autoritatieve
+  NZa-365-dagentoets voor zorgtrajectnummer-hergebruik (zie
+  `possible_continuation_of_episode_id`, §2.18); dit voorstel modelleert
+  alleen een zorginhoudelijke benadering, geen declaratie-waarheid.
+- Productcodes/volumes bij `municipal_care_assignment` — minimale variant nu
+  (§2.15), net als bij TOEWIJZING in `model-aanmelding.md` §2.13; verdere
+  detaillering in de declaratie-ronde.
+- ~~Gestructureerde crisisdocumentatie vóór identificatie~~ — geadresseerd
+  met `crisis_encounter_note` (§2.17), gebaseerd op juridisch onderzoek 19
+  juli 2026 (zie §9).
+
+## 7. Open punten voor Colin
+
+**Beantwoord:**
+
+- ~~`person_id` verplicht op referral_request/referral_case?~~ Nee, optioneel
+  — komt voor bij crisisaanmeldingen met nog onbekende identiteit. Geen
+  placeholder-persoon; de koppeling wordt een eigen gedateerd feit
+  (`person_identified_at`/`_by`) zodra de identiteit vaststaat (domeinreview
+  19 juli 2026).
+- ~~Kan een request meerdere professional referrals hebben?~~ Ja — een
+  correctie of aanvulling is een wijziging, geen nieuwe verwijzing. Dezelfde
+  vervangt-constructie als bij `care_acceptance_decision`
+  (`replaces_referral_id` + verplichte reden); de oude verwijzing blijft
+  bewaard (domeinreview 19 juli 2026).
+
+**Voorstel op basis van precedent (ter evaluatie — nog niet door jou
+bevestigd):**
+
+- **Bevoegdheid bij case_consolidation.** Geen speciale
+  `decision_authority` vereist, zoals bij `submission_case_assignment` en
+  `submission_duplicate_assessment` — een administratieve correctie, geen
+  inhoudelijk zorgbesluit. Verwerkt in §2.9.
+- **Diepte van de vervangt-keten.** Onbeperkt, geen aparte constraint — de
+  afleidingsregel in §5 werkt voor elke lengte en een harde grens zou een
+  legitieme correctie-op-een-correctie zonder aantoonbare reden blokkeren.
+  Verwerkt in §2.12, §2.14, §3.
+- **`submission_link_type` vervalt.** Representeert/vult_aan is geen
+  zelfstandig feit met eigen regels, puur chronologisch afleidbaar uit
+  `established_at` (nu verplicht). Verwerkt in §2.4, §4.
+- **`request_case_link.reason`:** bevestigd zoals al voorgesteld — verplicht
+  alleen bij de uitzondering (meer dan één case per request), optioneel bij
+  de normale, enkelvoudige koppeling. Consistent met `submission_case_assignment`,
+  waar de reden ook alleen bij de eerste/bijzondere toewijzing werd genoemd.
+
+**Nog echt open:**
+
+1. **Startwaarden van de waardelijsten in §4** — met name `submission_channel`,
+   `document_type` en `screening_activity_type` zijn nu overgenomen uit de
+   voorbeeldfeiten, niet uit een volledige inventarisatie.
+2. **Volledig zorgteam-model.** `episode_team_involvement` (§2.20) is bewust
+   een minimale hook, geen individueel lidmaatschap, geen rollen, geen
+   regie-/hoofdbehandelaarschap, geen bevoegdheid, geen toekomstige
+   cliëntautorisatie. Het volledige zorgteam-concept — los van zorgprogramma
+   en organisatorische eenheid, die op hun beurt gekoppeld kunnen worden
+   (een organisatorische eenheid kan één of meer zorgprogramma's verzorgen)
+   — krijgt een eigen feitenronde (besluitenlog §10 punt 3; begrippenlijst
+   `Episode Clinical Team`/`Episode Team Assignment`/`Episode Team Role`/
+   `Lead Clinician Role`/`Decision Authority`). Deze hook wordt daardoor
+   vervangen of geabsorbeerd, niet doorontwikkeld binnen dit document.
+3. **Juridische aannames in §2.15–§2.17 die een jurist moet bevestigen**
+   (uit het onderzoek van 19 juli 2026, zie §9): geen apart institutioneel
+   acceptatiebesluit náást een Wvggz-mandaat (ook niet bij zorgmachtiging);
+   de 24-uurstermijn voor tenuitvoerlegging als nudge, niet als constraint;
+   de 14-dagentermijn voor identificatie als signaal-nudge; en of de
+   Jeugdwet-verwijsroute specifiek voor jeugd-ggz hetzelfde "naast elkaar,
+   geen vervanging"-patroon volgt als voor jeugdhulp in het algemeen. Deze
+   aannames blokkeren de modellering niet, maar moeten vóór productie
+   geverifieerd worden.
+
+## 8. Bronverwijzingen
+
+| Onderdeel | Bron |
+|---|---|
+| Alle feitzinnen, besloten regels en scenario's | `../feitenmodellen/feitenmodel-instroom.md` |
+| Screening=acceptatie, capaciteitsroutes, episodevorming | `../sessielogs/sessielog-2026-07-19.md` §5–§9 |
+| Tijdlijn i.p.v. statusmachine-principe | `../sessielogs/sessielog-2026-07-18.md` §5 (B7 wachtlijst), discovery §5.1 #5 |
+| PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING (hergebruikt, niet gedupliceerd) | `model-aanmelding.md` §2.1–§2.9 |
+| Engelstalig technisch model | besluit B20, `../besluiten/besluitenlog-datamodel-2026-07-18.md` §9 |
+
+## 9. Reviewronde 19 juli 2026
+
+Twee onafhankelijke reviews (technisch datamodel-perspectief, GGZ-domein-
+perspectief) op de eerste versie van dit document leverden 9 bevindingen op.
+Direct verwerkt in dit document, zonder verdere domeinvraag omdat het
+technische correcties of het herstellen van een omissie betrof:
+
+1. **Vervangt-keten kon vertakken.** `replaces_decision_id`/
+   `replaces_referral_id` zijn nu uniek indien gevuld — anders zou §5's
+   afleidingsregel geen eenduidig geldig besluit meer opleveren. Verwerkt in
+   §2.12, §2.14, §3.
+2. **Timestamp-precisie ondermijnde de tijdlijn-aanpak.** Event-velden die
+   ten onrechte op `datum` (dagprecisie) stonden zijn naar `tijdstip`
+   gebracht, consistent met `referral_submission.received_at` — anders zijn
+   gebeurtenissen op dezelfde kalenderdag niet eenduidig te ordenen. Verwerkt
+   op alle event-attributen behalve `professional_referral.referral_date`
+   (een extern documentdatum, geen systeemgebeurtenis) en
+   `request_case_link.since`.
+3. **ZPM-verplichte velden ontbraken.** `professional_referral.heraanmelding`
+   en `referral_case.zpm_verwijstype`/`huisarts_geinformeerd_op` stonden al
+   in het oudere `model-aanmelding.md` (AANMELDING/VERWIJZING) en zijn bij
+   het opnieuw opbouwen van dit deelgebied per abuis niet meegenomen — dit is
+   hersteld, geen nieuwe ontwerpvraag. AGB-code en correspondentietoestemming
+   bleken al gedekt via bestaande entiteiten (VERWIJZER, TOESTEMMING) en
+   kregen alleen een verduidelijkende notitie.
+
+Vervolgens is een tweede reviewronde uitgevoerd door drie onafhankelijke
+expert-agents: een datamodel-expert op de resterende technische punten, een
+GGZ-domein-expert op de domeinvragen, en een UX-expert op bruikbaarheid voor
+de uiteindelijke gebruikersinterface.
+
+**Technische punten (datamodel-expert) — direct verwerkt, mechanische
+correcties zonder domeinvraag:**
+
+- de lege, inconsistent gecardinaliseerde `screening`-entiteit is vervallen;
+  `screening_activity` hangt nu direct aan `referral_case` (§2.10);
+- naamgeving gecorrigeerd: `signal_case_assignment` → `submission_case_
+  assignment`, `access_case_consolidation` → `case_consolidation`,
+  `decision_authority_id`/`program_context` kregen Engelse ref-namen
+  conform B20 (§2.6, §2.7, §2.9, §2.12);
+- cardinaliteitsfout `referral_submission → case_information_request`
+  gecorrigeerd naar `0..1`; notatie-legenda toegevoegd aan §3;
+- unique constraint + check toegevoegd op `case_consolidation` (§2.9).
+
+**UX-punt (UX-expert) — direct verwerkt, implementatie-eis zonder
+domeinvraag:**
+
+- de afleidingsregel in §5 moet als één centrale projectie/read-model
+  geïmplementeerd worden, niet los per scherm — toegevoegd als expliciete
+  eis in §5.
+
+**Derde ronde — GGZ-wetgeving-expert (juridisch onderzoek) gevolgd door
+datamodel-expert (schema-integratie), verwerkt in dit document:**
+
+Een jurist-georiënteerd onderzoek naar Wvggz, Wmo/Jeugdwet, ZPM-regels en
+WGBO onderbouwde de vijf GGZ-scope-vragen uit de tweede ronde. De datamodel-
+expert vertaalde de bevindingen naar concreet schema. Verwerkt:
+
+- **Aanmelddatum.** Bevestigd als leesregel (geen nieuw veld): de vroegste
+  `referral_submission.received_at` die via `submission_request_link` aan het
+  request hangt, is het regelgevend juiste aanmelddatum-moment voor de
+  275-dagentoets. Redelijk zekere juridische basis (NZa-veldafspraken; exact
+  artikelnummer niet geverifieerd).
+- **Wmo/Jeugdwet.** `municipal_care_assignment` toegevoegd (§2.15) —
+  bestaat náást, niet in plaats van `professional_referral` (Jeugdwet kent
+  een zelfstandige professionele verwijsroute; Wmo niet). `referral_case.
+  wettelijk_kader` hersteld (§2.6). *Juridisch minder zeker: of dit patroon
+  specifiek voor jeugd-ggz identiek is aan jeugdhulp in het algemeen — zie §7
+  punt 3.*
+- **Wvggz.** `legal_mandate` toegevoegd (§2.16) — geen vervangt-relatie met
+  `care_acceptance_decision`, want geen institutionele discretie bij een
+  crisismaatregel (bindend burgemeesterlijk besluit). `clinical_care_episode`
+  aangepast: `originating_decision_id` optioneel, nieuw `originating_
+  mandate_id`, met een XOR-regel — een episode ontstaat óf uit een
+  acceptatiebesluit óf uit een mandaat (§2.18). *Juridisch minder zeker: of
+  dit ook voor de zorgmachtiging-route (rechter/officier van justitie) klopt
+  — zie §7 punt 3.*
+- **Heraanmelding/zorgtrajectnummer.** Herzien ten opzichte van het eerdere
+  voorstel: de NZa-365-dagenregel hangt aan de datum van de laatst geleverde
+  prestatie bij dezelfde aanbieder, niet aan de episode-einddatum, en is een
+  ander begrip dan `professional_referral.heraanmelding`. Omdat
+  prestatieregistratie nog geen deelgebied is, is `possible_continuation_
+  of_episode_id` toegevoegd (§2.18) als zorginhoudelijke
+  continuïteitsaanwijzing (episode-einddatum als benadering), expliciet
+  gemarkeerd als **geen** autoritatieve declaratietoets.
+- **Crisisdocumentatie vóór identificatie.** `crisis_encounter_note`
+  toegevoegd (§2.17), alle gestructureerde velden optioneel — geen expliciet
+  wetsartikel gevonden dat gestructureerde vastlegging tíjdens de
+  interventie verplicht, wel de algemene WGBO-dossierplicht. De gevonden
+  14-dagen-identificatietermijn is een signaal-nudge, geen constraint.
+
+Daarna is het eigenaarschap/urgentie-punt met Colin doorgesproken
+(domeinreview 19 juli 2026), met een scherpere uitkomst dan het
+UX-voorstel:
+
+- **Urgentie** is geen vast veld maar een herhaalbare beoordeling —
+  vastgesteld tijdens screening/triage door de rol screener/triagist, later
+  aan te passen door het intake-team of in een MDO. `case_urgency_assessment`
+  toegevoegd (§2.19): herhaalbaar, laatste geldt, geen vervangt-relatie nodig
+  (lagere inzet dan een acceptatiebesluit), geen verplichte onderbouwing
+  (bevestigd: eenvoudige waardelijst volstaat).
+- **Eigenaarschap** bleek eigenlijk een onderdeel van een groter, apart
+  begrip: **zorgteam** — het team van betrokken behandelaren (soms 1 persoon,
+  soms multidisciplinair, kan een organisatorische eenheid overstijgen), met
+  regie-/hoofdbehandelaarschap en later mogelijk cliëntautorisatie. Dat is
+  zelfstandig ten opzichte van zorgprogramma (inhoudelijk aanbod) en
+  organisatorische eenheid (die aan elkaar gekoppeld kunnen worden — een OE
+  kan één of meer zorgprogramma's verzorgen), en hoort bij een cliënt/case
+  kunnen staan zonder dat er al een individuele behandelaar is toegewezen
+  (bijvoorbeeld: geaccepteerd, intakewachtlijst — Route 2A). Op uitdrukkelijk
+  verzoek van Colin blijft dit nu beperkt tot een minimale, voorlopige hook
+  — `episode_team_involvement` (§2.20), geen rollen, geen bevoegdheid, geen
+  individueel lidmaatschap. Het volledige zorgteam-model krijgt een eigen
+  feitenronde (zie §7 punt 2).
+
+**Nog open:**
+
+- De juridische aannames uit de derde ronde (§7 punt 3) zijn in het schema
+  verwerkt maar nog niet door een jurist bevestigd.
+- Het volledige zorgteam-model (§7 punt 2).

docs/datamodel/deelmodellen/model-intake-behandeladvies.md

@@ -0,0 +1,234 @@
+# Datamodelvoorstel — Intake en behandeladvies
+
+**Status:** voorstel ter review — eerste entiteiten- en cardinaliteitenafleiding
+**Datum:** 19 juli 2026
+**Scope:** Clinical Intake Assessment, Intake Contact, Child Safety Check,
+Treatment Advice, en een minimale hook voor MDT-bespreking bij het
+behandeladvies. Contactmoment-generalisatie naar een bredere
+consult-/afspraakstructuur blijft buiten scope (agenda-ronde).
+**Kader:** bouwt rechtstreeks op de bevestigde feitzinnen in
+`../feitenmodellen/feitenmodel-intake-behandeladvies.md`, inclusief het
+gerichte LKS 4.0-onderzoek naar behandeladvies-uitkomsten en bevoegdheid.
+Dit is de stap "afleiding van entiteiten en cardinaliteiten" uit diens §7.
+**Naamgeving:** entiteiten en attributen zijn Engelstalig, conform besluit
+B20 — vervangt het oudere, Nederlandstalige `model-intake.md`, dat als
+historisch werkdocument blijft staan met verwijzingen hierheen.
+**Autoriteit:** `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft
+leidend.
+
+---
+
+## 1. Entiteiten
+
+### 1.1 clinical_intake_assessment
+
+**Doel:** het onderzoekstraject voor één samenhangende zorgvraag binnen een
+zorgepisode, van gepland eerste contact tot behandeladvies (feitenmodel §2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| clinical_care_episode_id | ref clinical_care_episode | ja |
+| initiation_reason | waardelijst `intake_initiation_reason` (regulier/intern/crisis) | ja |
+| department | waardelijst `department` (afdeling) | ja |
+| status | waardelijst `intake_status` (gepland/bezig/afgerond/afgebroken) | ja (default `gepland`) |
+| planned_at | tijdstip | ja |
+| started_at | tijdstip | verplicht zodra status `bezig` of later |
+| ended_at | tijdstip | verplicht zodra status `afgerond` of `afgebroken` |
+| abort_reason | waardelijst `intake_abort_reason` | verplicht bij status `afgebroken` |
+
+**Uniciteit:** één stabiele identiteit; hangt aan precies één
+`clinical_care_episode`. Een episode kan nul, één of meerdere intakes
+hebben. "Maximaal één lopende intake per episode" is een aan/uit-zetbare
+bedrijfsregel, geen schemabeperking (een crisisintake kan naast een lopende
+reguliere intake nodig zijn). Statusovergangen: zie §4.
+
+**Relatie met instroom:** `clinical_care_episode_id` vervangt de oudere,
+inmiddels onjuiste relatie met AANMELDING. De intake start op enig moment
+ná het acceptatiebesluit dat de episode liet ontstaan — mogelijk na een
+periode op de intakewachtlijst (`referral_case.follow_up_route =
+intakewachtlijst`, `model-instroom.md` §2.12). `planned_at` dekt precies
+dat interval.
+
+### 1.2 intake_contact
+
+**Doel:** een feitelijk contact binnen een `clinical_intake_assessment`
+(feitenmodel §3.2).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| clinical_intake_assessment_id | ref clinical_intake_assessment | ja |
+| occurred_at | tijdstip | ja |
+| contact_type | waardelijst `intake_contact_type` (intakegesprek/aanvullend_onderzoek/telefonisch_contact/huisbezoek/beeldcontact/overig) | ja |
+| performed_by | ref medewerker | ja |
+| notes | tekst | nee |
+| planned_duration_minutes | geheel getal | nee |
+
+**Uniciteit:** geen — meerdere contacten van hetzelfde type op dezelfde dag
+zijn legitiem.
+
+### 1.3 child_safety_check
+
+**Doel:** de wettelijk verankerde kindcheck bij de intake (feitenmodel
+§3.3).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| clinical_intake_assessment_id | ref clinical_intake_assessment | ja |
+| performed_at | tijdstip | ja |
+| performed_by | ref medewerker | ja |
+| responsible_for_minors | ja/nee | ja |
+| minor_count | geheel getal | nee *(alleen zinvol bij responsible_for_minors = ja)* |
+| minor_ages | tekst | nee *(vrije tekst, bewust geen kindrecords — dataminimalisatie)* |
+| safety_concern | ja/nee | ja |
+| safety_concern_notes | tekst | verplicht bij safety_concern = ja |
+| action_taken | ja/nee | ja |
+| action_taken_notes | tekst | verplicht bij action_taken = ja |
+| pregnancy | ja/nee | ja *(vierde vlag, KNMG-kindcheck — feitenmodel §3.3, te verifiëren tegen de meldcode-tekst)* |
+| notes | tekst | nee |
+
+**Uniciteit:** maximaal één `child_safety_check` per
+`clinical_intake_assessment` (uniek op `clinical_intake_assessment_id`). Een
+nieuwe intake binnen dezelfde episode krijgt een eigen, nieuwe kindcheck.
+
+### 1.4 intake_mdt_review *(minimale, voorlopige hook — zie §6)*
+
+**Doel:** vastleggen dát een behandeladvies in een multidisciplinair team is
+besproken, zonder de volledige MDO-workflow (B14-B15, nog een aparte ronde)
+hier te herhalen. Voor settings 3–8 is dit volgens LKS 4.0 een dwingende
+norm, voor setting 2 optioneel, voor vrijgevestigden niet van toepassing
+(feitenmodel §3.4).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| occurred_at | tijdstip | ja |
+| participants | tekst | ja *(vrije tekst voorlopig; structurering wacht op de MDO-ronde)* |
+| notes | tekst | nee |
+
+**Uniciteit:** geen eigen FK naar `clinical_intake_assessment` — wordt
+gekoppeld via `treatment_advice.mdt_review_id` (zie 1.5), zodat een
+MDT-bespreking pas telt zodra zij daadwerkelijk aan een vastgesteld advies
+hangt.
+
+### 1.5 treatment_advice
+
+**Doel:** het object dat een `clinical_intake_assessment` afrondt: draagt
+de uitkomst, het geadviseerde zorgprogramma en de toelichting (feitenmodel
+§2, §3.4).
+
+| Attribuut | Type | Verplicht |
+|---|---|---|
+| clinical_intake_assessment_id | ref clinical_intake_assessment | ja |
+| decided_at | tijdstip | ja |
+| decided_by | ref medewerker (indicerende regiebehandelaar) | ja |
+| outcome | waardelijst `treatment_advice_outcome` (in_zorg/terugverwijzing/doorverwijzing/extra_diagnostiek) | ja |
+| recommended_care_program | ref care_program | verplicht bij outcome `in_zorg`, anders optioneel |
+| rationale | tekst | verplicht bij `terugverwijzing`/`doorverwijzing`/`extra_diagnostiek`, optioneel bij `in_zorg` |
+| mdt_review_id | ref intake_mdt_review | nee *(settingafhankelijk — zie §6, punt 1)* |
+| replaces_advice_id | ref treatment_advice (zelfreferentie) | nee |
+| replacement_reason | tekst | verplicht als `replaces_advice_id` gevuld is |
+
+**Uniciteit:** precies één intake, beslisser, besluitdatum en uitkomst per
+advies. `replaces_advice_id` is uniek indien gevuld (voorkomt vertakking),
+onbeperkte kettingdiepte — zelfde constructie als
+`care_acceptance_decision`/`professional_referral` in `model-instroom.md`.
+Het geldige advies van een intake is het laatste, niet-vervangen advies in
+de keten.
+
+**`doorverwijzing`/`terugverwijzing` als volgtijdelijk paar:** LKS 4.0
+normeert eerst een inspanningsverplichting tot doorverwijzing, pas daarna
+terugverwijzing als dat niets oplevert. Dit wordt niet als aparte
+sequentie-constraint gemodelleerd, maar volgt vanzelf uit het
+vervangt-mechanisme: een `terugverwijzing`-advies dat een eerder
+`doorverwijzing`-advies vervangt, met de mislukte doorverwijzing als
+`replacement_reason` (feitenmodel §3.4, Route 2).
+
+## 2. Relaties met cardinaliteit
+
+| Van | Naar | Cardinaliteit | Toelichting |
+|---|---|---|---|
+| clinical_care_episode | clinical_intake_assessment | 1..0..n | een episode kan nog geen intake hebben (net ontstaan, wacht op intakewachtlijst) |
+| clinical_intake_assessment | intake_contact | 1..0..n | een geplande intake heeft nog geen contacten |
+| clinical_intake_assessment | child_safety_check | 1..0..1 | "verplicht vóór afronden" is een nudge, geen schema-eis |
+| clinical_intake_assessment | treatment_advice | 1..0..n | 0 zolang nog niet afgerond; n bij heroverweging (Route 4) |
+| treatment_advice | treatment_advice | 0..1 (self) | `replaces_advice_id`, optioneel en uniek indien gevuld — voorkomt vertakking |
+| treatment_advice | intake_mdt_review | 0..1..1 | een MDT-bespreking hoort bij precies één advies zodra gekoppeld |
+| treatment_advice | care_program | 0..1 | verplicht bij outcome `in_zorg` |
+
+## 3. Waardelijsten (startlijsten, te bevestigen)
+
+| Waardelijst | Voorlopige waarden |
+|---|---|
+| `intake_initiation_reason` | regulier, intern, crisis |
+| `intake_status` | gepland, bezig, afgerond, afgebroken |
+| `intake_abort_reason` | client_trekt_terug, geen_contact_meer, overleden, overig |
+| `intake_contact_type` | intakegesprek, aanvullend_onderzoek, telefonisch_contact, huisbezoek, beeldcontact, overig |
+| `treatment_advice_outcome` | in_zorg, terugverwijzing, doorverwijzing, extra_diagnostiek |
+| `department` | over te nemen uit `model-aanmelding.md`/instellingsconfiguratie (afdeling, instellingsconfigureerbaar) |
+| `care_program` | over te nemen uit bestaande zorgprogramma-waardelijst (`model-instroom.md` `program_context`) |
+
+Alle waardelijsten volgen het bestaande patroon (referentietabel met
+`code`, `omschrijving`, `geldig_van`/`geldig_tot`, `actief` — spelregel 3.1
+#1) en zijn hier nog geen definitieve besluiten.
+
+## 4. Statusmachine clinical_intake_assessment
+
+Statussen: `gepland` → `bezig` → `afgerond`/`afgebroken`, met heropening.
+
+| Van | Naar | Voorwaarde |
+|---|---|---|
+| — | gepland | intake aangemaakt |
+| gepland | bezig | eerste `intake_contact` geregistreerd |
+| gepland | afgebroken | `abort_reason` verplicht |
+| bezig | afgerond | een niet-vervangen `treatment_advice` verplicht |
+| bezig | afgebroken | `abort_reason` verplicht |
+| afgerond | bezig | heropening, audit-event verplicht |
+| afgebroken | bezig | heropening (cliënt meldt zich alsnog), audit-event verplicht |
+
+Niet toegestaan: `gepland` → `afgerond` rechtstreeks (afronden zonder
+geregistreerd contact); `afgerond` ↔ `afgebroken` rechtstreeks. Regels in
+het model als check-constraints en een referentietabel voor overgangen,
+consistent met spelregel 3.1 #7/#9.
+
+## 5. Buiten scope van dit document
+
+- Het volledige MDO-workflowmodel (casusinbreng, triage, agendering,
+  formele uitkomsttypen) — `intake_mdt_review` is een minimale hook, geen
+  vervanging van B14-B15.
+- Contactmoment-generalisatie naar een bredere consult-/afspraakstructuur —
+  agenda-ronde.
+- De volledige bevoegdheidsmatrix per setting (welke settings exact
+  MDT-bespreking vereisen, en de rolinvulling) — bevoegdheidsronde (B16).
+- ZPM-consultregistratie (planning versus geleverde prestatie) — hangt aan
+  `intake_contact` maar wordt in de declaratie-ronde uitgewerkt.
+
+## 6. Open punten voor Colin
+
+1. **`intake_mdt_review` als verplicht of optioneel veld op
+   `treatment_advice`?** Voorstel hierboven: optioneel op schemaniveau
+   (`mdt_review_id` nee), met een nudge/constraint die per setting bepaalt
+   of afronden zonder MDT-koppeling is toegestaan — settings 3–8 volgens
+   LKS 4.0 in principe niet. Dit vereist een settingregistratie die nu nog
+   niet bestaat in het model (welke setting geldt voor deze episode/case);
+   zonder die registratie kan de regel niet worden afgedwongen, alleen als
+   nudge worden voorgesteld.
+2. **Is `extra_diagnostiek` altijd een nieuw, vervangend `treatment_advice`
+   zodra het vervolgonderzoek is afgerond, of kan de intake ook gewoon
+   "bezig" blijven zonder tussentijdse afronding?** Beide zijn nu
+   schema-technisch mogelijk (heropening bestaat); welke de praktijk
+   prefereert is niet getoetst.
+3. **`pregnancy`-vlag op `child_safety_check`** is toegevoegd op basis van
+   algemene domeinkennis (KNMG-meldcode), niet uit de eerder verzamelde
+   onderzoeksrapporten — te verifiëren.
+4. **Startwaarden van de waardelijsten** — met name `intake_contact_type`
+   en `intake_abort_reason` zijn overgenomen uit het oudere
+   `model-intake.md` zonder nieuwe validatie.
+
+## 7. Bronverwijzingen
+
+| Onderdeel | Bron |
+|---|---|
+| Alle feitzinnen, besloten regels, scenario's | `../feitenmodellen/feitenmodel-intake-behandeladvies.md` |
+| LKS 4.0-onderzoek behandeladvies-uitkomsten en bevoegdheid | zie onderzoeksresultaat verwerkt in feitenmodel §3.4 |
+| Intake aan zorgepisode, meerdere intakes, aanleiding-waardelijst (basis) | `model-intake.md` §1/§2 (ouder, Nederlandstalig, episode-timing gecorrigeerd) |
+| Instroom-precedenten (vervangt-mechanisme, tijdlijn-principe) | `model-instroom.md` |
+| Engelstalig technisch model | besluit B20, `../besluiten/besluitenlog-datamodel-2026-07-18.md` §9 |

docs/datamodel/deelmodellen/model-intake.md

@@ -0,0 +1,230 @@
+# Datamodelvoorstel — Deelgebied Intake
+
+**Status:** **vervangen door `model-intake-behandeladvies.md`** (19 juli
+2026) — Engelstalige entiteiten, gecorrigeerde episode-timing (intake start
+ná het acceptatiebesluit, niet bij aanmelding-uitkomst "intake"), en het
+behandeladvies uitgewerkt als eigen `treatment_advice`-object in plaats van
+platte velden op INTAKE. Deze tekst blijft als historisch werkdocument
+staan — de kindcheck-/contactmoment-inhoud is grotendeels 1-op-1 hergebruikt
+(niet-destructief), gebruik dit document zelf niet als basis voor SQL.
+**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 | **vervallen** — context uit §5.1 #9: episode ontstaat bij aanmelding-uitkomst `intake`; afgewezen aanmelding heeft nooit een episode. Overruled door B22: de episode ontstaat al bij het acceptatiebesluit zelf, zie `model-instroom.md` §2.18. |
+| 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. **Niet gevolgd — herzien door B22 (19 juli 2026):** de episode ontstaat al bij het acceptatiebesluit zelf, óók bij vervolgroute intakewachtlijst, niet pas bij aanmelding-uitkomst "intake". Zie `model-intake-behandeladvies.md` §1.1.
+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 |

docs/datamodel/deelmodellen/model-rapportage.md

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

docs/datamodel/deelmodellen/model-screening.md

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

docs/datamodel/deelmodellen/model-wachtlijst.md

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

docs/datamodel/diagrammen/model-aanmelding-erd.html

@@ -0,0 +1,332 @@
+<!doctype html>
+<html lang="nl">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Aanmelding — entiteit-relatiediagram</title>
+<style>
+  :root {
+    --bg: #F5FAF9;
+    --surface: #FFFFFF;
+    --surface-2: #EAF3F1;
+    --border: #CFE1DE;
+    --text: #12211F;
+    --text-muted: #4C6B66;
+    --accent: #0F766E;
+    --font-sans: -apple-system, "Segoe UI", "Helvetica Neue", Arial, sans-serif;
+    --font-mono: ui-monospace, "SFMono-Regular", "Cascadia Code", "Roboto Mono", Consolas, monospace;
+  }
+
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #0A1615;
+      --surface: #10201E;
+      --surface-2: #15302C;
+      --border: #1F3A36;
+      --text: #E6F5F2;
+      --text-muted: #8FB6B0;
+      --accent: #34D6C4;
+    }
+  }
+
+  * { box-sizing: border-box; }
+
+  html, body {
+    margin: 0;
+    height: 100%;
+    overscroll-behavior: none;
+  }
+
+  body {
+    background: var(--bg);
+    color: var(--text);
+    font-family: var(--font-sans);
+  }
+
+  .app {
+    display: flex;
+    flex-direction: column;
+    height: 100vh;
+  }
+
+  /* Toolbar */
+  .toolbar {
+    flex: 0 0 auto;
+    display: flex;
+    align-items: center;
+    justify-content: space-between;
+    gap: 16px;
+    padding: 10px 16px;
+    background: var(--surface);
+    border-bottom: 1px solid var(--border);
+  }
+
+  .title-group {
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+    min-width: 0;
+  }
+
+  .title-group h1 {
+    font-size: 0.95rem;
+    margin: 0;
+    font-weight: 700;
+    white-space: nowrap;
+  }
+
+  .title-group .source {
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: var(--text-muted);
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+  }
+
+  .controls {
+    display: flex;
+    gap: 6px;
+    flex: 0 0 auto;
+  }
+
+  .controls button {
+    width: 32px;
+    height: 32px;
+    border-radius: 6px;
+    border: 1px solid var(--border);
+    background: var(--surface-2);
+    color: var(--text);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    padding: 0;
+  }
+
+  .controls button:hover { border-color: var(--accent); color: var(--accent); }
+  .controls button:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
+
+  @media (prefers-reduced-motion: no-preference) {
+    .controls button { transition: border-color 120ms, color 120ms; }
+  }
+
+  /* Diagram canvas */
+  .canvas-wrap {
+    flex: 1 1 auto;
+    position: relative;
+    overflow: hidden;
+    background:
+      repeating-linear-gradient(0deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      repeating-linear-gradient(90deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      #08211D;
+  }
+
+  .canvas-wrap .hint {
+    position: absolute;
+    left: 16px;
+    bottom: 14px;
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: #6FBFB2;
+    z-index: 2;
+    pointer-events: none;
+  }
+
+  #diagram {
+    width: 100%;
+    height: 100%;
+  }
+
+  #diagram svg {
+    width: 100%;
+    height: 100%;
+    display: block;
+  }
+
+  .loading {
+    position: absolute;
+    inset: 0;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    color: #6FBFB2;
+    font-family: var(--font-mono);
+    font-size: 13px;
+  }
+</style>
+</head>
+<body>
+
+<div class="app">
+  <div class="toolbar">
+    <div class="title-group">
+      <h1>Aanmelding — entiteit-relatiediagram</h1>
+      <span class="source">model-aanmelding.md §2 · 11 entiteiten · 12 relaties · AANMELDING/VERWIJZING/ZORGEPISODE vervangen door model-instroom.md (niet getoond)</span>
+    </div>
+    <div class="controls">
+      <button id="zoom-out" title="Uitzoomen" aria-label="Uitzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-in" title="Inzoomen" aria-label="Inzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="8" y1="3" x2="8" y2="13" stroke="currentColor" stroke-width="2"/><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-fit" title="Passend maken" aria-label="Passend maken">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M2 6V2h4M14 6V2h-4M2 10v4h4M14 10v4h-4" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+      <button id="zoom-reset" title="Reset (100%)" aria-label="Reset naar 100%">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M8 2a6 6 0 1 1-4.24 1.76" stroke="currentColor" stroke-width="1.8" stroke-linecap="round"/>
+          <path d="M2 2v3h3" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+    </div>
+  </div>
+
+  <div class="canvas-wrap">
+    <div class="loading" id="loading">Diagram wordt geladen…</div>
+    <div id="diagram" class="mermaid">
+erDiagram
+    PERSOON {
+        uuid id PK
+        string achternaam
+        date geboortedatum
+        string bsn
+    }
+    ADRES {
+        uuid id PK
+        uuid persoon_id FK
+        string adrestype
+        string postcode
+        date geldig_tot
+    }
+    CONTACTGEGEVEN {
+        uuid id PK
+        uuid persoon_id FK
+        string contacttype
+        string waarde
+        boolean voorkeur
+    }
+    CLIENT {
+        uuid id PK
+        uuid persoon_id FK
+        string clientnummer
+        date client_sinds
+        string huisarts_situatie
+    }
+    CLIENTRELATIE {
+        uuid id PK
+        uuid client_id FK
+        uuid persoon_id FK
+        string relatie
+        string rol
+        date geldig_van
+    }
+    VERWIJZER {
+        uuid id PK
+        uuid praktijk_instelling_id FK
+        string naam
+        string verwijzertype
+        string agb_code
+    }
+    PRAKTIJK_INSTELLING {
+        uuid id PK
+        string naam
+        string soort
+        string agb_code
+    }
+    CLIENT_HUISARTS {
+        uuid id PK
+        uuid client_id FK
+        uuid verwijzer_id FK
+        uuid praktijk_instelling_id FK
+        date geldig_van
+    }
+    VERZEKERING {
+        uuid id PK
+        uuid client_id FK
+        string uzovi_code
+        string polisnummer
+        date geldig_van
+    }
+    TOESTEMMING {
+        uuid id PK
+        uuid client_id FK
+        string toestemmingstype
+        string status
+        date datum
+    }
+    CLIENTPORTAAL_ACCOUNT {
+        uuid id PK
+        uuid client_id FK
+    }
+
+    PERSOON ||--o{ ADRES : "persoon_id"
+    PERSOON ||--o{ CONTACTGEGEVEN : "persoon_id"
+    PERSOON ||--o| CLIENT : "persoon_id"
+    CLIENT ||--o{ CLIENTRELATIE : "client_id"
+    PERSOON ||--o{ CLIENTRELATIE : "persoon_id"
+    PRAKTIJK_INSTELLING |o--o{ VERWIJZER : "praktijk_instelling_id"
+    CLIENT ||--o{ CLIENT_HUISARTS : "client_id"
+    VERWIJZER |o--o{ CLIENT_HUISARTS : "verwijzer_id"
+    PRAKTIJK_INSTELLING |o--o{ CLIENT_HUISARTS : "praktijk_instelling_id"
+    CLIENT ||--o{ VERZEKERING : "client_id"
+    CLIENT ||--o{ TOESTEMMING : "client_id"
+    CLIENT ||--o| CLIENTPORTAAL_ACCOUNT : "client_id"
+    </div>
+    <div class="hint">sleep om te pannen · scroll om te zoomen</div>
+  </div>
+</div>
+
+<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
+<script src="https://cdn.jsdelivr.net/npm/svg-pan-zoom@3.6.1/dist/svg-pan-zoom.min.js"></script>
+<script>
+  mermaid.initialize({
+    startOnLoad: false,
+    theme: "base",
+    themeVariables: {
+      background: "#08211D",
+      primaryColor: "#0E2E29",
+      primaryBorderColor: "#57D8C6",
+      primaryTextColor: "#EAFBF7",
+      lineColor: "#57D8C6",
+      textColor: "#EAFBF7",
+      tertiaryColor: "#123B35",
+      attributeBackgroundColorOdd: "#0E2E29",
+      attributeBackgroundColorEven: "#123B35",
+      fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace",
+      fontSize: "13px"
+    }
+  });
+
+  (async () => {
+    await mermaid.run({ querySelector: "#diagram" });
+    document.getElementById("loading").remove();
+
+    const svgEl = document.querySelector("#diagram svg");
+    svgEl.removeAttribute("style");
+
+    const panZoom = svgPanZoom(svgEl, {
+      panEnabled: true,
+      zoomEnabled: true,
+      controlIconsEnabled: false,
+      fit: true,
+      center: true,
+      minZoom: 0.15,
+      maxZoom: 8,
+      zoomScaleSensitivity: 0.35
+    });
+
+    document.getElementById("zoom-in").addEventListener("click", () => panZoom.zoomIn());
+    document.getElementById("zoom-out").addEventListener("click", () => panZoom.zoomOut());
+    document.getElementById("zoom-fit").addEventListener("click", () => { panZoom.fit(); panZoom.center(); });
+    document.getElementById("zoom-reset").addEventListener("click", () => { panZoom.reset(); });
+
+    window.addEventListener("resize", () => { panZoom.resize(); panZoom.fit(); panZoom.center(); });
+  })();
+</script>
+
+</body>
+</html>

docs/datamodel/diagrammen/model-behandelplan-erd.html

@@ -0,0 +1,336 @@
+<!doctype html>
+<html lang="nl">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Behandelplan — entiteit-relatiediagram</title>
+<style>
+  :root {
+    --bg: #F5FAF9;
+    --surface: #FFFFFF;
+    --surface-2: #EAF3F1;
+    --border: #CFE1DE;
+    --text: #12211F;
+    --text-muted: #4C6B66;
+    --accent: #0F766E;
+    --font-sans: -apple-system, "Segoe UI", "Helvetica Neue", Arial, sans-serif;
+    --font-mono: ui-monospace, "SFMono-Regular", "Cascadia Code", "Roboto Mono", Consolas, monospace;
+  }
+
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #0A1615;
+      --surface: #10201E;
+      --surface-2: #15302C;
+      --border: #1F3A36;
+      --text: #E6F5F2;
+      --text-muted: #8FB6B0;
+      --accent: #34D6C4;
+    }
+  }
+
+  * { box-sizing: border-box; }
+
+  html, body {
+    margin: 0;
+    height: 100%;
+    overscroll-behavior: none;
+  }
+
+  body {
+    background: var(--bg);
+    color: var(--text);
+    font-family: var(--font-sans);
+  }
+
+  .app {
+    display: flex;
+    flex-direction: column;
+    height: 100vh;
+  }
+
+  /* Toolbar */
+  .toolbar {
+    flex: 0 0 auto;
+    display: flex;
+    align-items: center;
+    justify-content: space-between;
+    gap: 16px;
+    padding: 10px 16px;
+    background: var(--surface);
+    border-bottom: 1px solid var(--border);
+  }
+
+  .title-group {
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+    min-width: 0;
+  }
+
+  .title-group h1 {
+    font-size: 0.95rem;
+    margin: 0;
+    font-weight: 700;
+    white-space: nowrap;
+  }
+
+  .title-group .source {
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: var(--text-muted);
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+  }
+
+  .controls {
+    display: flex;
+    gap: 6px;
+    flex: 0 0 auto;
+  }
+
+  .controls button {
+    width: 32px;
+    height: 32px;
+    border-radius: 6px;
+    border: 1px solid var(--border);
+    background: var(--surface-2);
+    color: var(--text);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    padding: 0;
+  }
+
+  .controls button:hover { border-color: var(--accent); color: var(--accent); }
+  .controls button:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
+
+  @media (prefers-reduced-motion: no-preference) {
+    .controls button { transition: border-color 120ms, color 120ms; }
+  }
+
+  /* Diagram canvas */
+  .canvas-wrap {
+    flex: 1 1 auto;
+    position: relative;
+    overflow: hidden;
+    background:
+      repeating-linear-gradient(0deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      repeating-linear-gradient(90deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      #08211D;
+  }
+
+  .canvas-wrap .hint {
+    position: absolute;
+    left: 16px;
+    bottom: 14px;
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: #6FBFB2;
+    z-index: 2;
+    pointer-events: none;
+  }
+
+  #diagram {
+    width: 100%;
+    height: 100%;
+  }
+
+  #diagram svg {
+    width: 100%;
+    height: 100%;
+    display: block;
+  }
+
+  .loading {
+    position: absolute;
+    inset: 0;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    color: #6FBFB2;
+    font-family: var(--font-mono);
+    font-size: 13px;
+  }
+</style>
+</head>
+<body>
+
+<div class="app">
+  <div class="toolbar">
+    <div class="title-group">
+      <h1>Behandelplan — entiteit-relatiediagram</h1>
+      <span class="source">model-behandelplan.md §2 · 12 entiteiten · 20 relaties · in structurele herziening — zie besluitenlog §5 B11 (één levend behandelplan met formele snapshots i.p.v. losse versie-records)</span>
+    </div>
+    <div class="controls">
+      <button id="zoom-out" title="Uitzoomen" aria-label="Uitzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-in" title="Inzoomen" aria-label="Inzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="8" y1="3" x2="8" y2="13" stroke="currentColor" stroke-width="2"/><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-fit" title="Passend maken" aria-label="Passend maken">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M2 6V2h4M14 6V2h-4M2 10v4h4M14 10v4h-4" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+      <button id="zoom-reset" title="Reset (100%)" aria-label="Reset naar 100%">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M8 2a6 6 0 1 1-4.24 1.76" stroke="currentColor" stroke-width="1.8" stroke-linecap="round"/>
+          <path d="M2 2v3h3" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+    </div>
+  </div>
+
+  <div class="canvas-wrap">
+    <div class="loading" id="loading">Diagram wordt geladen…</div>
+    <div id="diagram" class="mermaid">
+erDiagram
+    ZORGEPISODE {
+        uuid id PK
+    }
+    DIAGNOSE {
+        uuid id PK
+    }
+    INTAKE {
+        uuid id PK
+    }
+    MEDEWERKER {
+        uuid id PK
+    }
+    PERSOON {
+        uuid id PK
+    }
+    BEHANDELPLAN {
+        uuid id PK
+        uuid zorgepisode_id FK
+        uuid vervangt_plan_id FK
+        uuid gebaseerd_op_intake_id FK
+        uuid opgesteld_door FK
+        uuid regiebehandelaar_id FK
+        uuid vastgesteld_door FK
+        integer versienummer
+        string status
+        date vastgesteld_op
+    }
+    BEHANDELPLAN_DIAGNOSE {
+        uuid behandelplan_id FK
+        uuid diagnose_id FK
+    }
+    BEHANDELDOEL {
+        uuid id PK
+        uuid behandelplan_id FK
+        uuid diagnose_id FK
+        uuid overgenomen_van_doel_id FK
+        string omschrijving
+        string prioriteit
+        string status
+    }
+    INTERVENTIE {
+        uuid id PK
+        uuid behandelplan_id FK
+        uuid uitvoerder_id FK
+        string interventietype
+        string extern_systeem
+        string extern_kenmerk
+    }
+    INTERVENTIE_DOEL {
+        uuid interventie_id FK
+        uuid behandeldoel_id FK
+    }
+    EVALUATIEMOMENT {
+        uuid id PK
+        uuid behandelplan_id FK
+        uuid uitgevoerd_door FK
+        string evaluatietype
+        date gepland_op
+        string uitkomst
+    }
+    BEHANDELPLAN_AKKOORD {
+        uuid id PK
+        uuid behandelplan_id FK
+        uuid gegeven_door_persoon_id FK
+        uuid vastgelegd_door FK
+        date datum
+        string wijze
+        string gegeven_door_type
+    }
+
+    ZORGEPISODE ||--o{ BEHANDELPLAN : "zorgepisode_id"
+    BEHANDELPLAN |o--o| BEHANDELPLAN : "vervangt_plan_id (self)"
+    INTAKE |o--o{ BEHANDELPLAN : "gebaseerd_op_intake_id (0..1)"
+    BEHANDELPLAN ||--o{ BEHANDELPLAN_DIAGNOSE : "diagnoses"
+    DIAGNOSE ||--o{ BEHANDELPLAN_DIAGNOSE : "plannen"
+    BEHANDELPLAN ||--o{ BEHANDELDOEL : "doelen"
+    DIAGNOSE |o--o{ BEHANDELDOEL : "diagnose_id (optioneel)"
+    BEHANDELDOEL |o--o{ BEHANDELDOEL : "overgenomen_van_doel_id (self)"
+    BEHANDELPLAN ||--o{ INTERVENTIE : "interventies"
+    INTERVENTIE ||--o{ INTERVENTIE_DOEL : "doelkoppelingen"
+    BEHANDELDOEL ||--o{ INTERVENTIE_DOEL : "interventiekoppelingen"
+    BEHANDELPLAN ||--o{ EVALUATIEMOMENT : "evaluatiemomenten"
+    BEHANDELPLAN ||--o{ BEHANDELPLAN_AKKOORD : "akkoorden"
+    MEDEWERKER ||--o{ BEHANDELPLAN : "opgesteld_door"
+    MEDEWERKER |o--o{ BEHANDELPLAN : "regiebehandelaar_id"
+    MEDEWERKER |o--o{ BEHANDELPLAN : "vastgesteld_door"
+    MEDEWERKER |o--o{ INTERVENTIE : "uitvoerder_id"
+    MEDEWERKER |o--o{ EVALUATIEMOMENT : "uitgevoerd_door"
+    MEDEWERKER ||--o{ BEHANDELPLAN_AKKOORD : "vastgelegd_door"
+    PERSOON |o--o{ BEHANDELPLAN_AKKOORD : "gegeven_door_persoon_id"
+    </div>
+    <div class="hint">sleep om te pannen · scroll om te zoomen</div>
+  </div>
+</div>
+
+<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
+<script src="https://cdn.jsdelivr.net/npm/svg-pan-zoom@3.6.1/dist/svg-pan-zoom.min.js"></script>
+<script>
+  mermaid.initialize({
+    startOnLoad: false,
+    theme: "base",
+    themeVariables: {
+      background: "#08211D",
+      primaryColor: "#0E2E29",
+      primaryBorderColor: "#57D8C6",
+      primaryTextColor: "#EAFBF7",
+      lineColor: "#57D8C6",
+      textColor: "#EAFBF7",
+      tertiaryColor: "#123B35",
+      attributeBackgroundColorOdd: "#0E2E29",
+      attributeBackgroundColorEven: "#123B35",
+      fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace",
+      fontSize: "13px"
+    }
+  });
+
+  (async () => {
+    await mermaid.run({ querySelector: "#diagram" });
+    document.getElementById("loading").remove();
+
+    const svgEl = document.querySelector("#diagram svg");
+    svgEl.removeAttribute("style");
+
+    const panZoom = svgPanZoom(svgEl, {
+      panEnabled: true,
+      zoomEnabled: true,
+      controlIconsEnabled: false,
+      fit: true,
+      center: true,
+      minZoom: 0.15,
+      maxZoom: 8,
+      zoomScaleSensitivity: 0.35
+    });
+
+    document.getElementById("zoom-in").addEventListener("click", () => panZoom.zoomIn());
+    document.getElementById("zoom-out").addEventListener("click", () => panZoom.zoomOut());
+    document.getElementById("zoom-fit").addEventListener("click", () => { panZoom.fit(); panZoom.center(); });
+    document.getElementById("zoom-reset").addEventListener("click", () => { panZoom.reset(); });
+
+    window.addEventListener("resize", () => { panZoom.resize(); panZoom.fit(); panZoom.center(); });
+  })();
+</script>
+
+</body>
+</html>

docs/datamodel/diagrammen/model-diagnose-erd.html

@@ -0,0 +1,345 @@
+<!doctype html>
+<html lang="nl">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Diagnose — entiteit-relatiediagram</title>
+<style>
+  :root {
+    --bg: #F5FAF9;
+    --surface: #FFFFFF;
+    --surface-2: #EAF3F1;
+    --border: #CFE1DE;
+    --text: #12211F;
+    --text-muted: #4C6B66;
+    --accent: #0F766E;
+    --font-sans: -apple-system, "Segoe UI", "Helvetica Neue", Arial, sans-serif;
+    --font-mono: ui-monospace, "SFMono-Regular", "Cascadia Code", "Roboto Mono", Consolas, monospace;
+  }
+
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #0A1615;
+      --surface: #10201E;
+      --surface-2: #15302C;
+      --border: #1F3A36;
+      --text: #E6F5F2;
+      --text-muted: #8FB6B0;
+      --accent: #34D6C4;
+    }
+  }
+
+  * { box-sizing: border-box; }
+
+  html, body {
+    margin: 0;
+    height: 100%;
+    overscroll-behavior: none;
+  }
+
+  body {
+    background: var(--bg);
+    color: var(--text);
+    font-family: var(--font-sans);
+  }
+
+  .app {
+    display: flex;
+    flex-direction: column;
+    height: 100vh;
+  }
+
+  /* Toolbar */
+  .toolbar {
+    flex: 0 0 auto;
+    display: flex;
+    align-items: center;
+    justify-content: space-between;
+    gap: 16px;
+    padding: 10px 16px;
+    background: var(--surface);
+    border-bottom: 1px solid var(--border);
+  }
+
+  .title-group {
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+    min-width: 0;
+  }
+
+  .title-group h1 {
+    font-size: 0.95rem;
+    margin: 0;
+    font-weight: 700;
+    white-space: nowrap;
+  }
+
+  .title-group .source {
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: var(--text-muted);
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+  }
+
+  .controls {
+    display: flex;
+    gap: 6px;
+    flex: 0 0 auto;
+  }
+
+  .controls button {
+    width: 32px;
+    height: 32px;
+    border-radius: 6px;
+    border: 1px solid var(--border);
+    background: var(--surface-2);
+    color: var(--text);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    padding: 0;
+  }
+
+  .controls button:hover { border-color: var(--accent); color: var(--accent); }
+  .controls button:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
+
+  @media (prefers-reduced-motion: no-preference) {
+    .controls button { transition: border-color 120ms, color 120ms; }
+  }
+
+  /* Diagram canvas */
+  .canvas-wrap {
+    flex: 1 1 auto;
+    position: relative;
+    overflow: hidden;
+    background:
+      repeating-linear-gradient(0deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      repeating-linear-gradient(90deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      #08211D;
+  }
+
+  .canvas-wrap .hint {
+    position: absolute;
+    left: 16px;
+    bottom: 14px;
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: #6FBFB2;
+    z-index: 2;
+    pointer-events: none;
+  }
+
+  #diagram {
+    width: 100%;
+    height: 100%;
+  }
+
+  #diagram svg {
+    width: 100%;
+    height: 100%;
+    display: block;
+  }
+
+  .loading {
+    position: absolute;
+    inset: 0;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    color: #6FBFB2;
+    font-family: var(--font-mono);
+    font-size: 13px;
+  }
+</style>
+</head>
+<body>
+
+<div class="app">
+  <div class="toolbar">
+    <div class="title-group">
+      <h1>Diagnose — entiteit-relatiediagram</h1>
+      <span class="source">model-diagnose.md §2–§3 · 13 entiteiten · 19 relaties</span>
+    </div>
+    <div class="controls">
+      <button id="zoom-out" title="Uitzoomen" aria-label="Uitzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-in" title="Inzoomen" aria-label="Inzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="8" y1="3" x2="8" y2="13" stroke="currentColor" stroke-width="2"/><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-fit" title="Passend maken" aria-label="Passend maken">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M2 6V2h4M14 6V2h-4M2 10v4h4M14 10v4h-4" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+      <button id="zoom-reset" title="Reset (100%)" aria-label="Reset naar 100%">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M8 2a6 6 0 1 1-4.24 1.76" stroke="currentColor" stroke-width="1.8" stroke-linecap="round"/>
+          <path d="M2 2v3h3" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+    </div>
+  </div>
+
+  <div class="canvas-wrap">
+    <div class="loading" id="loading">Diagram wordt geladen…</div>
+    <div id="diagram" class="mermaid">
+erDiagram
+    ZORGEPISODE {
+        uuid id PK
+    }
+    INTAKE {
+        uuid id PK
+    }
+    MEDEWERKER {
+        uuid id PK
+    }
+    BEHANDELPLAN {
+        uuid id PK
+    }
+    DIAGNOSE {
+        uuid id PK
+        uuid zorgepisode_id FK
+        uuid dsm_classificatie_id FK
+        uuid gesteld_tijdens_intake_id FK
+        uuid definitief_door FK
+        uuid geregistreerd_door FK
+        uuid vervangen_door_diagnose_id FK
+        string verificatiestatus
+        string klinische_status
+        string afgeleide_icd10_code
+    }
+    DSM_CLASSIFICATIE {
+        uuid id PK
+        uuid dsm_hoofdgroep_id FK
+        string dsm_code
+        string omschrijving
+        boolean selecteerbaar
+    }
+    DSM_HOOFDGROEP {
+        uuid id PK
+        string code
+        string omschrijving
+    }
+    DSM_ICD10_MAPPING {
+        uuid id PK
+        uuid dsm_classificatie_id FK
+        string icd10_code
+        boolean voorkeur
+        string lijstversie
+    }
+    HOOFDDIAGNOSE_AANWIJZING {
+        uuid id PK
+        uuid zorgepisode_id FK
+        uuid diagnose_id FK
+        uuid aangewezen_door FK
+        date geldig_van
+        date geldig_tot
+    }
+    HONOS_AFNAME {
+        uuid id PK
+        uuid zorgepisode_id FK
+        uuid afgenomen_door FK
+        string instrument
+        date afgenomen_op
+    }
+    HONOS_ITEMSCORE {
+        uuid id PK
+        uuid honos_afname_id FK
+        string honos_item
+        int score
+    }
+    ZORGVRAAGTYPERING {
+        uuid id PK
+        uuid zorgepisode_id FK
+        uuid honos_afname_id FK
+        uuid gekozen_door FK
+        string soort
+        string gekozen_zorgvraagtype
+        date gekozen_op
+    }
+    ZORGVRAAGTYPE_ADVIES {
+        uuid id PK
+        uuid zorgvraagtypering_id FK
+        string zorgvraagtype
+        int rangorde
+    }
+
+    ZORGEPISODE ||--o{ DIAGNOSE : "zorgepisode_id (extern, module zorgepisode)"
+    INTAKE |o--o{ DIAGNOSE : "gesteld_tijdens_intake_id (extern, module intake)"
+    DSM_CLASSIFICATIE ||--o{ DIAGNOSE : "dsm_classificatie_id"
+    DSM_HOOFDGROEP ||--o{ DSM_CLASSIFICATIE : "dsm_hoofdgroep_id"
+    DSM_CLASSIFICATIE ||--o{ DSM_ICD10_MAPPING : "dsm_classificatie_id (mapping naar ICD-10)"
+    ZORGEPISODE ||--o{ HOOFDDIAGNOSE_AANWIJZING : "zorgepisode_id (extern)"
+    DIAGNOSE ||--o{ HOOFDDIAGNOSE_AANWIJZING : "diagnose_id"
+    DIAGNOSE |o--o| DIAGNOSE : "vervangen_door_diagnose_id (self)"
+    ZORGEPISODE ||--o{ HONOS_AFNAME : "zorgepisode_id (extern)"
+    HONOS_AFNAME ||--o{ HONOS_ITEMSCORE : "honos_afname_id (max 19 items)"
+    HONOS_AFNAME ||--o| ZORGVRAAGTYPERING : "honos_afname_id (uniek)"
+    ZORGEPISODE ||--o{ ZORGVRAAGTYPERING : "zorgepisode_id (extern)"
+    ZORGVRAAGTYPERING ||--o{ ZORGVRAAGTYPE_ADVIES : "zorgvraagtypering_id"
+    MEDEWERKER ||--o{ DIAGNOSE : "geregistreerd_door (extern, module medewerker)"
+    MEDEWERKER |o--o{ DIAGNOSE : "definitief_door (optioneel, extern)"
+    MEDEWERKER ||--o{ HONOS_AFNAME : "afgenomen_door (extern)"
+    MEDEWERKER ||--o{ ZORGVRAAGTYPERING : "gekozen_door (extern)"
+    MEDEWERKER ||--o{ HOOFDDIAGNOSE_AANWIJZING : "aangewezen_door (extern)"
+    BEHANDELPLAN }o--o{ DIAGNOSE : "adresseert diagnose (extern, module behandelplan)"
+    </div>
+    <div class="hint">sleep om te pannen · scroll om te zoomen</div>
+  </div>
+</div>
+
+<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
+<script src="https://cdn.jsdelivr.net/npm/svg-pan-zoom@3.6.1/dist/svg-pan-zoom.min.js"></script>
+<script>
+  mermaid.initialize({
+    startOnLoad: false,
+    theme: "base",
+    themeVariables: {
+      background: "#08211D",
+      primaryColor: "#0E2E29",
+      primaryBorderColor: "#57D8C6",
+      primaryTextColor: "#EAFBF7",
+      lineColor: "#57D8C6",
+      textColor: "#EAFBF7",
+      tertiaryColor: "#123B35",
+      attributeBackgroundColorOdd: "#0E2E29",
+      attributeBackgroundColorEven: "#123B35",
+      fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace",
+      fontSize: "13px"
+    }
+  });
+
+  (async () => {
+    await mermaid.run({ querySelector: "#diagram" });
+    document.getElementById("loading").remove();
+
+    const svgEl = document.querySelector("#diagram svg");
+    svgEl.removeAttribute("style");
+
+    const panZoom = svgPanZoom(svgEl, {
+      panEnabled: true,
+      zoomEnabled: true,
+      controlIconsEnabled: false,
+      fit: true,
+      center: true,
+      minZoom: 0.15,
+      maxZoom: 8,
+      zoomScaleSensitivity: 0.35
+    });
+
+    document.getElementById("zoom-in").addEventListener("click", () => panZoom.zoomIn());
+    document.getElementById("zoom-out").addEventListener("click", () => panZoom.zoomOut());
+    document.getElementById("zoom-fit").addEventListener("click", () => { panZoom.fit(); panZoom.center(); });
+    document.getElementById("zoom-reset").addEventListener("click", () => { panZoom.reset(); });
+
+    window.addEventListener("resize", () => { panZoom.resize(); panZoom.fit(); panZoom.center(); });
+  })();
+</script>
+
+</body>
+</html>

docs/datamodel/diagrammen/model-instroom-erd.html

@@ -0,0 +1,390 @@
+<!doctype html>
+<html lang="nl">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Instroom — entiteit-relatiediagram</title>
+<style>
+  :root {
+    --bg: #F5FAF9;
+    --surface: #FFFFFF;
+    --surface-2: #EAF3F1;
+    --border: #CFE1DE;
+    --text: #12211F;
+    --text-muted: #4C6B66;
+    --accent: #0F766E;
+    --font-sans: -apple-system, "Segoe UI", "Helvetica Neue", Arial, sans-serif;
+    --font-mono: ui-monospace, "SFMono-Regular", "Cascadia Code", "Roboto Mono", Consolas, monospace;
+  }
+
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #0A1615;
+      --surface: #10201E;
+      --surface-2: #15302C;
+      --border: #1F3A36;
+      --text: #E6F5F2;
+      --text-muted: #8FB6B0;
+      --accent: #34D6C4;
+    }
+  }
+
+  * { box-sizing: border-box; }
+
+  html, body {
+    margin: 0;
+    height: 100%;
+    overscroll-behavior: none;
+  }
+
+  body {
+    background: var(--bg);
+    color: var(--text);
+    font-family: var(--font-sans);
+  }
+
+  .app {
+    display: flex;
+    flex-direction: column;
+    height: 100vh;
+  }
+
+  /* Toolbar */
+  .toolbar {
+    flex: 0 0 auto;
+    display: flex;
+    align-items: center;
+    justify-content: space-between;
+    gap: 16px;
+    padding: 10px 16px;
+    background: var(--surface);
+    border-bottom: 1px solid var(--border);
+  }
+
+  .title-group {
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+    min-width: 0;
+  }
+
+  .title-group h1 {
+    font-size: 0.95rem;
+    margin: 0;
+    font-weight: 700;
+    white-space: nowrap;
+  }
+
+  .title-group .source {
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: var(--text-muted);
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+  }
+
+  .controls {
+    display: flex;
+    gap: 6px;
+    flex: 0 0 auto;
+  }
+
+  .controls button {
+    width: 32px;
+    height: 32px;
+    border-radius: 6px;
+    border: 1px solid var(--border);
+    background: var(--surface-2);
+    color: var(--text);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    padding: 0;
+  }
+
+  .controls button:hover { border-color: var(--accent); color: var(--accent); }
+  .controls button:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
+
+  @media (prefers-reduced-motion: no-preference) {
+    .controls button { transition: border-color 120ms, color 120ms; }
+  }
+
+  /* Diagram canvas */
+  .canvas-wrap {
+    flex: 1 1 auto;
+    position: relative;
+    overflow: hidden;
+    background:
+      repeating-linear-gradient(0deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      repeating-linear-gradient(90deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      #08211D;
+  }
+
+  .canvas-wrap .hint {
+    position: absolute;
+    left: 16px;
+    bottom: 14px;
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: #6FBFB2;
+    z-index: 2;
+    pointer-events: none;
+  }
+
+  #diagram {
+    width: 100%;
+    height: 100%;
+  }
+
+  #diagram svg {
+    width: 100%;
+    height: 100%;
+    display: block;
+  }
+
+  .loading {
+    position: absolute;
+    inset: 0;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    color: #6FBFB2;
+    font-family: var(--font-mono);
+    font-size: 13px;
+  }
+</style>
+</head>
+<body>
+
+<div class="app">
+  <div class="toolbar">
+    <div class="title-group">
+      <h1>Instroom — entiteit-relatiediagram</h1>
+      <span class="source">model-instroom.md §2–§3 · 20 entiteiten · 29 relaties</span>
+    </div>
+    <div class="controls">
+      <button id="zoom-out" title="Uitzoomen" aria-label="Uitzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-in" title="Inzoomen" aria-label="Inzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="8" y1="3" x2="8" y2="13" stroke="currentColor" stroke-width="2"/><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-fit" title="Passend maken" aria-label="Passend maken">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M2 6V2h4M14 6V2h-4M2 10v4h4M14 10v4h-4" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+      <button id="zoom-reset" title="Reset (100%)" aria-label="Reset naar 100%">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M8 2a6 6 0 1 1-4.24 1.76" stroke="currentColor" stroke-width="1.8" stroke-linecap="round"/>
+          <path d="M2 2v3h3" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+    </div>
+  </div>
+
+  <div class="canvas-wrap">
+    <div class="loading" id="loading">Diagram wordt geladen…</div>
+    <div id="diagram" class="mermaid">
+erDiagram
+    PERSOON {
+        uuid id PK
+    }
+    referral_request {
+        uuid id PK
+        uuid person_id FK
+        timestamp initiated_at
+        string initiator_type
+        text presenting_need_text
+    }
+    referral_submission {
+        uuid id PK
+        timestamp received_at
+        string channel
+    }
+    submission_document {
+        uuid id PK
+        uuid submission_id FK
+        string document_type
+    }
+    submission_request_link {
+        uuid submission_id FK
+        uuid referral_request_id FK
+        timestamp established_at
+    }
+    submission_duplicate_assessment {
+        uuid submission_id FK
+        uuid duplicate_of_submission_id FK
+        timestamp assessed_at
+    }
+    referral_case {
+        uuid id PK
+        uuid person_id FK
+        timestamp opened_at
+        string wettelijk_kader
+    }
+    submission_case_assignment {
+        uuid submission_id FK
+        uuid referral_case_id FK
+        timestamp assigned_at
+    }
+    request_case_link {
+        uuid referral_request_id FK
+        uuid referral_case_id FK
+        date since
+    }
+    case_consolidation {
+        uuid primary_case_id FK
+        uuid related_case_id FK
+        timestamp designated_at
+    }
+    screening_activity {
+        uuid id PK
+        uuid referral_case_id FK
+        string activity_type
+    }
+    case_information_request {
+        uuid id PK
+        uuid referral_case_id FK
+        uuid resolved_by_submission_id FK
+        timestamp requested_at
+    }
+    care_acceptance_decision {
+        uuid id PK
+        uuid referral_case_id FK
+        uuid replaces_decision_id FK
+        string decision_outcome
+        string follow_up_route
+    }
+    case_withdrawal {
+        uuid id PK
+        uuid referral_case_id FK
+        timestamp withdrawn_at
+    }
+    professional_referral {
+        uuid id PK
+        uuid referral_request_id FK
+        uuid replaces_referral_id FK
+        date referral_date
+    }
+    municipal_care_assignment {
+        uuid id PK
+        uuid referral_request_id FK
+        uuid replaces_assignment_id FK
+        string legal_framework
+    }
+    legal_mandate {
+        uuid id PK
+        uuid referral_case_id FK
+        string mandate_type
+    }
+    crisis_encounter_note {
+        uuid id PK
+        uuid referral_case_id FK
+        string fact_type
+    }
+    clinical_care_episode {
+        uuid id PK
+        uuid originating_decision_id FK
+        uuid originating_mandate_id FK
+        uuid possible_continuation_of_episode_id FK
+        timestamp started_at
+    }
+    case_urgency_assessment {
+        uuid id PK
+        uuid referral_case_id FK
+        string urgency_level
+    }
+    episode_team_involvement {
+        uuid id PK
+        uuid clinical_care_episode_id FK
+        string team_reference
+    }
+
+    PERSOON |o--o{ referral_request : "person_id"
+    PERSOON |o--o{ referral_case : "person_id"
+    referral_submission ||--o{ submission_document : "documenten"
+    referral_submission ||--o{ submission_request_link : "koppelingen"
+    referral_request ||--|{ submission_request_link : "min 1 submission"
+    referral_submission ||--o{ submission_duplicate_assessment : "als duplicaat"
+    referral_submission ||--o{ submission_duplicate_assessment : "als origineel"
+    referral_case ||--|{ submission_case_assignment : "min 1 toewijzing"
+    referral_submission ||--o{ submission_case_assignment : "toewijzingen"
+    referral_case ||--|{ request_case_link : "min 1 request"
+    referral_request ||--|{ request_case_link : "normaliter 1 case"
+    referral_case ||--o{ case_consolidation : "primary (leidend)"
+    referral_case ||--o| case_consolidation : "related (uniek)"
+    referral_case ||--o{ screening_activity : "activiteiten"
+    referral_case ||--o{ case_information_request : "informatieverzoeken"
+    referral_submission |o--o| case_information_request : "resolved_by (0..1)"
+    referral_case ||--o{ care_acceptance_decision : "besluiten"
+    care_acceptance_decision |o--o| care_acceptance_decision : "vervangt (self)"
+    referral_case ||--o{ case_withdrawal : "intrekkingen"
+    referral_request ||--o{ professional_referral : "verwijzingen"
+    professional_referral |o--o| professional_referral : "vervangt (self)"
+    referral_request ||--o{ municipal_care_assignment : "toewijzingen"
+    municipal_care_assignment |o--o| municipal_care_assignment : "vervangt (self)"
+    referral_case ||--o{ legal_mandate : "mandaten"
+    referral_case ||--o{ crisis_encounter_note : "notities"
+    care_acceptance_decision ||--o| clinical_care_episode : "XOR met mandaat"
+    legal_mandate ||--o| clinical_care_episode : "XOR met besluit"
+    clinical_care_episode |o--o| clinical_care_episode : "mogelijke vervolg (self)"
+    referral_case ||--o{ case_urgency_assessment : "beoordelingen"
+    clinical_care_episode ||--o{ episode_team_involvement : "team-betrokkenheid"
+    </div>
+    <div class="hint">sleep om te pannen · scroll om te zoomen</div>
+  </div>
+</div>
+
+<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
+<script src="https://cdn.jsdelivr.net/npm/svg-pan-zoom@3.6.1/dist/svg-pan-zoom.min.js"></script>
+<script>
+  mermaid.initialize({
+    startOnLoad: false,
+    theme: "base",
+    themeVariables: {
+      background: "#08211D",
+      primaryColor: "#0E2E29",
+      primaryBorderColor: "#57D8C6",
+      primaryTextColor: "#EAFBF7",
+      lineColor: "#57D8C6",
+      textColor: "#EAFBF7",
+      tertiaryColor: "#123B35",
+      attributeBackgroundColorOdd: "#0E2E29",
+      attributeBackgroundColorEven: "#123B35",
+      fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace",
+      fontSize: "13px"
+    }
+  });
+
+  (async () => {
+    await mermaid.run({ querySelector: "#diagram" });
+    document.getElementById("loading").remove();
+
+    const svgEl = document.querySelector("#diagram svg");
+    svgEl.removeAttribute("style");
+
+    const panZoom = svgPanZoom(svgEl, {
+      panEnabled: true,
+      zoomEnabled: true,
+      controlIconsEnabled: false,
+      fit: true,
+      center: true,
+      minZoom: 0.15,
+      maxZoom: 8,
+      zoomScaleSensitivity: 0.35
+    });
+
+    document.getElementById("zoom-in").addEventListener("click", () => panZoom.zoomIn());
+    document.getElementById("zoom-out").addEventListener("click", () => panZoom.zoomOut());
+    document.getElementById("zoom-fit").addEventListener("click", () => { panZoom.fit(); panZoom.center(); });
+    document.getElementById("zoom-reset").addEventListener("click", () => { panZoom.reset(); });
+
+    window.addEventListener("resize", () => { panZoom.resize(); panZoom.fit(); panZoom.center(); });
+  })();
+</script>
+
+</body>
+</html>

docs/datamodel/diagrammen/model-intake-behandeladvies-erd.html

@@ -0,0 +1,295 @@
+<!doctype html>
+<html lang="nl">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Intake en behandeladvies — entiteit-relatiediagram</title>
+<style>
+  :root {
+    --bg: #F5FAF9;
+    --surface: #FFFFFF;
+    --surface-2: #EAF3F1;
+    --border: #CFE1DE;
+    --text: #12211F;
+    --text-muted: #4C6B66;
+    --accent: #0F766E;
+    --font-sans: -apple-system, "Segoe UI", "Helvetica Neue", Arial, sans-serif;
+    --font-mono: ui-monospace, "SFMono-Regular", "Cascadia Code", "Roboto Mono", Consolas, monospace;
+  }
+
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #0A1615;
+      --surface: #10201E;
+      --surface-2: #15302C;
+      --border: #1F3A36;
+      --text: #E6F5F2;
+      --text-muted: #8FB6B0;
+      --accent: #34D6C4;
+    }
+  }
+
+  * { box-sizing: border-box; }
+
+  html, body {
+    margin: 0;
+    height: 100%;
+    overscroll-behavior: none;
+  }
+
+  body {
+    background: var(--bg);
+    color: var(--text);
+    font-family: var(--font-sans);
+  }
+
+  .app {
+    display: flex;
+    flex-direction: column;
+    height: 100vh;
+  }
+
+  /* Toolbar */
+  .toolbar {
+    flex: 0 0 auto;
+    display: flex;
+    align-items: center;
+    justify-content: space-between;
+    gap: 16px;
+    padding: 10px 16px;
+    background: var(--surface);
+    border-bottom: 1px solid var(--border);
+  }
+
+  .title-group {
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+    min-width: 0;
+  }
+
+  .title-group h1 {
+    font-size: 0.95rem;
+    margin: 0;
+    font-weight: 700;
+    white-space: nowrap;
+  }
+
+  .title-group .source {
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: var(--text-muted);
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+  }
+
+  .controls {
+    display: flex;
+    gap: 6px;
+    flex: 0 0 auto;
+  }
+
+  .controls button {
+    width: 32px;
+    height: 32px;
+    border-radius: 6px;
+    border: 1px solid var(--border);
+    background: var(--surface-2);
+    color: var(--text);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    padding: 0;
+  }
+
+  .controls button:hover { border-color: var(--accent); color: var(--accent); }
+  .controls button:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
+
+  @media (prefers-reduced-motion: no-preference) {
+    .controls button { transition: border-color 120ms, color 120ms; }
+  }
+
+  /* Diagram canvas */
+  .canvas-wrap {
+    flex: 1 1 auto;
+    position: relative;
+    overflow: hidden;
+    background:
+      repeating-linear-gradient(0deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      repeating-linear-gradient(90deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      #08211D;
+  }
+
+  .canvas-wrap .hint {
+    position: absolute;
+    left: 16px;
+    bottom: 14px;
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: #6FBFB2;
+    z-index: 2;
+    pointer-events: none;
+  }
+
+  #diagram {
+    width: 100%;
+    height: 100%;
+  }
+
+  #diagram svg {
+    width: 100%;
+    height: 100%;
+    display: block;
+  }
+
+  .loading {
+    position: absolute;
+    inset: 0;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    color: #6FBFB2;
+    font-family: var(--font-mono);
+    font-size: 13px;
+  }
+</style>
+</head>
+<body>
+
+<div class="app">
+  <div class="toolbar">
+    <div class="title-group">
+      <h1>Intake en behandeladvies — entiteit-relatiediagram</h1>
+      <span class="source">model-intake-behandeladvies.md §1–§2 · 7 entiteiten · 7 relaties</span>
+    </div>
+    <div class="controls">
+      <button id="zoom-out" title="Uitzoomen" aria-label="Uitzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-in" title="Inzoomen" aria-label="Inzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="8" y1="3" x2="8" y2="13" stroke="currentColor" stroke-width="2"/><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-fit" title="Passend maken" aria-label="Passend maken">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M2 6V2h4M14 6V2h-4M2 10v4h4M14 10v4h-4" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+      <button id="zoom-reset" title="Reset (100%)" aria-label="Reset naar 100%">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M8 2a6 6 0 1 1-4.24 1.76" stroke="currentColor" stroke-width="1.8" stroke-linecap="round"/>
+          <path d="M2 2v3h3" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+    </div>
+  </div>
+
+  <div class="canvas-wrap">
+    <div class="loading" id="loading">Diagram wordt geladen…</div>
+    <div id="diagram" class="mermaid">
+erDiagram
+    clinical_care_episode {
+        uuid id PK
+    }
+    care_program {
+        uuid id PK
+    }
+    clinical_intake_assessment {
+        uuid id PK
+        uuid clinical_care_episode_id FK
+        string initiation_reason
+        string status
+        timestamp planned_at
+    }
+    intake_contact {
+        uuid id PK
+        uuid clinical_intake_assessment_id FK
+        timestamp occurred_at
+        string contact_type
+        int planned_duration_minutes
+    }
+    child_safety_check {
+        uuid id PK
+        uuid clinical_intake_assessment_id FK
+        boolean responsible_for_minors
+        boolean safety_concern
+        boolean action_taken
+    }
+    intake_mdt_review {
+        uuid id PK
+        timestamp occurred_at
+        text participants
+    }
+    treatment_advice {
+        uuid id PK
+        uuid clinical_intake_assessment_id FK
+        uuid mdt_review_id FK
+        uuid replaces_advice_id FK
+        uuid recommended_care_program FK
+        string outcome
+        timestamp decided_at
+    }
+
+    clinical_care_episode ||--o{ clinical_intake_assessment : "clinical_care_episode_id"
+    clinical_intake_assessment ||--o{ intake_contact : "clinical_intake_assessment_id"
+    clinical_intake_assessment ||--o| child_safety_check : "clinical_intake_assessment_id"
+    clinical_intake_assessment ||--o{ treatment_advice : "clinical_intake_assessment_id"
+    treatment_advice |o--o| treatment_advice : "vervangt (self)"
+    intake_mdt_review |o--o| treatment_advice : "mdt_review_id"
+    care_program |o--o{ treatment_advice : "recommended_care_program"
+    </div>
+    <div class="hint">sleep om te pannen · scroll om te zoomen</div>
+  </div>
+</div>
+
+<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
+<script src="https://cdn.jsdelivr.net/npm/svg-pan-zoom@3.6.1/dist/svg-pan-zoom.min.js"></script>
+<script>
+  mermaid.initialize({
+    startOnLoad: false,
+    theme: "base",
+    themeVariables: {
+      background: "#08211D",
+      primaryColor: "#0E2E29",
+      primaryBorderColor: "#57D8C6",
+      primaryTextColor: "#EAFBF7",
+      lineColor: "#57D8C6",
+      textColor: "#EAFBF7",
+      tertiaryColor: "#123B35",
+      attributeBackgroundColorOdd: "#0E2E29",
+      attributeBackgroundColorEven: "#123B35",
+      fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace",
+      fontSize: "13px"
+    }
+  });
+
+  (async () => {
+    await mermaid.run({ querySelector: "#diagram" });
+    document.getElementById("loading").remove();
+
+    const svgEl = document.querySelector("#diagram svg");
+    svgEl.removeAttribute("style");
+
+    const panZoom = svgPanZoom(svgEl, {
+      panEnabled: true,
+      zoomEnabled: true,
+      controlIconsEnabled: false,
+      fit: true,
+      center: true,
+      minZoom: 0.15,
+      maxZoom: 8,
+      zoomScaleSensitivity: 0.35
+    });
+
+    document.getElementById("zoom-in").addEventListener("click", () => panZoom.zoomIn());
+    document.getElementById("zoom-out").addEventListener("click", () => panZoom.zoomOut());
+    document.getElementById("zoom-fit").addEventListener("click", () => { panZoom.fit(); panZoom.center(); });
+    document.getElementById("zoom-reset").addEventListener("click", () => { panZoom.reset(); });
+
+    window.addEventListener("resize", () => { panZoom.resize(); panZoom.fit(); panZoom.center(); });
+  })();
+</script>
+
+</body>
+</html>

docs/datamodel/diagrammen/model-rapportage-erd.html

@@ -0,0 +1,339 @@
+<!doctype html>
+<html lang="nl">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Rapportage — entiteit-relatiediagram</title>
+<style>
+  :root {
+    --bg: #F5FAF9;
+    --surface: #FFFFFF;
+    --surface-2: #EAF3F1;
+    --border: #CFE1DE;
+    --text: #12211F;
+    --text-muted: #4C6B66;
+    --accent: #0F766E;
+    --font-sans: -apple-system, "Segoe UI", "Helvetica Neue", Arial, sans-serif;
+    --font-mono: ui-monospace, "SFMono-Regular", "Cascadia Code", "Roboto Mono", Consolas, monospace;
+  }
+
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #0A1615;
+      --surface: #10201E;
+      --surface-2: #15302C;
+      --border: #1F3A36;
+      --text: #E6F5F2;
+      --text-muted: #8FB6B0;
+      --accent: #34D6C4;
+    }
+  }
+
+  * { box-sizing: border-box; }
+
+  html, body {
+    margin: 0;
+    height: 100%;
+    overscroll-behavior: none;
+  }
+
+  body {
+    background: var(--bg);
+    color: var(--text);
+    font-family: var(--font-sans);
+  }
+
+  .app {
+    display: flex;
+    flex-direction: column;
+    height: 100vh;
+  }
+
+  /* Toolbar */
+  .toolbar {
+    flex: 0 0 auto;
+    display: flex;
+    align-items: center;
+    justify-content: space-between;
+    gap: 16px;
+    padding: 10px 16px;
+    background: var(--surface);
+    border-bottom: 1px solid var(--border);
+  }
+
+  .title-group {
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+    min-width: 0;
+  }
+
+  .title-group h1 {
+    font-size: 0.95rem;
+    margin: 0;
+    font-weight: 700;
+    white-space: nowrap;
+  }
+
+  .title-group .source {
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: var(--text-muted);
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+  }
+
+  .controls {
+    display: flex;
+    gap: 6px;
+    flex: 0 0 auto;
+  }
+
+  .controls button {
+    width: 32px;
+    height: 32px;
+    border-radius: 6px;
+    border: 1px solid var(--border);
+    background: var(--surface-2);
+    color: var(--text);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    padding: 0;
+  }
+
+  .controls button:hover { border-color: var(--accent); color: var(--accent); }
+  .controls button:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
+
+  @media (prefers-reduced-motion: no-preference) {
+    .controls button { transition: border-color 120ms, color 120ms; }
+  }
+
+  /* Diagram canvas */
+  .canvas-wrap {
+    flex: 1 1 auto;
+    position: relative;
+    overflow: hidden;
+    background:
+      repeating-linear-gradient(0deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      repeating-linear-gradient(90deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      #08211D;
+  }
+
+  .canvas-wrap .hint {
+    position: absolute;
+    left: 16px;
+    bottom: 14px;
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: #6FBFB2;
+    z-index: 2;
+    pointer-events: none;
+  }
+
+  #diagram {
+    width: 100%;
+    height: 100%;
+  }
+
+  #diagram svg {
+    width: 100%;
+    height: 100%;
+    display: block;
+  }
+
+  .loading {
+    position: absolute;
+    inset: 0;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    color: #6FBFB2;
+    font-family: var(--font-mono);
+    font-size: 13px;
+  }
+</style>
+</head>
+<body>
+
+<div class="app">
+  <div class="toolbar">
+    <div class="title-group">
+      <h1>Rapportage — entiteit-relatiediagram</h1>
+      <span class="source">model-rapportage.md §2 · 14 entiteiten · 18 relaties · deels herzien — zie besluitenlog-datamodel-2026-07-18.md §§6, 8</span>
+    </div>
+    <div class="controls">
+      <button id="zoom-out" title="Uitzoomen" aria-label="Uitzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-in" title="Inzoomen" aria-label="Inzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="8" y1="3" x2="8" y2="13" stroke="currentColor" stroke-width="2"/><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-fit" title="Passend maken" aria-label="Passend maken">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M2 6V2h4M14 6V2h-4M2 10v4h4M14 10v4h-4" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+      <button id="zoom-reset" title="Reset (100%)" aria-label="Reset naar 100%">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M8 2a6 6 0 1 1-4.24 1.76" stroke="currentColor" stroke-width="1.8" stroke-linecap="round"/>
+          <path d="M2 2v3h3" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+    </div>
+  </div>
+
+  <div class="canvas-wrap">
+    <div class="loading" id="loading">Diagram wordt geladen…</div>
+    <div id="diagram" class="mermaid">
+erDiagram
+    ZORGEPISODE {
+        uuid id PK
+    }
+    MEDEWERKER {
+        uuid id PK
+    }
+    PERSOON {
+        uuid id PK
+    }
+    INTAKE {
+        uuid id PK
+    }
+    CONTACTMOMENT {
+        uuid id PK
+    }
+    BEHANDELPLAN {
+        uuid id PK
+    }
+    BEHANDELDOEL {
+        uuid id PK
+    }
+    RAPPORTAGE {
+        uuid id PK
+        uuid zorgepisode_id FK
+        uuid auteur_medewerker_id FK
+        uuid auteur_persoon_id FK
+        uuid bevestigd_door_medewerker_id FK
+        uuid vorige_versie_id FK
+        uuid intake_id FK
+        uuid contactmoment_id FK
+        uuid behandelplan_id FK
+        string rapportagetype_code
+        text vrije_tekst
+        string status_code
+    }
+    RAPPORTAGESECTIE {
+        uuid id PK
+        uuid rapportage_id FK
+        string sectietype_code
+        text tekst
+    }
+    RAPPORTAGE_DOELKOPPELING {
+        uuid rapportage_id FK
+        uuid behandeldoel_id FK
+        string voortgang_code
+    }
+    AI_BRONVERWIJZING {
+        uuid id PK
+        string eigenaar_entiteit
+        uuid eigenaar_id
+        string bron_entiteit
+        uuid bron_id
+        text bron_content_hash
+    }
+    INCIDENTDETAIL {
+        uuid rapportage_id PK, FK
+        string incidentcategorie_code
+        text aard
+        boolean merkbare_gevolgen
+    }
+    INCIDENT_BETROKKENE {
+        uuid id PK
+        uuid incident_rapportage_id FK
+        uuid medewerker_id FK
+        string naam_vrij
+    }
+    OVERDRACHTSSAMENVATTING {
+        uuid id PK
+        uuid zorgepisode_id FK
+        uuid bevestigd_door_medewerker_id FK
+        text samenvatting_tekst
+        timestamp periode_van
+        string status_code
+    }
+
+    ZORGEPISODE ||--o{ RAPPORTAGE : "zorgepisode_id"
+    MEDEWERKER |o--o{ RAPPORTAGE : "auteur_medewerker_id"
+    PERSOON |o--o{ RAPPORTAGE : "auteur_persoon_id"
+    MEDEWERKER |o--o{ RAPPORTAGE : "bevestigd_door_medewerker_id"
+    RAPPORTAGE |o--o| RAPPORTAGE : "vorige_versie_id (self)"
+    CONTACTMOMENT |o--o{ RAPPORTAGE : "contactmoment_id"
+    INTAKE |o--o{ RAPPORTAGE : "intake_id"
+    BEHANDELPLAN |o--o{ RAPPORTAGE : "behandelplan_id"
+    RAPPORTAGE ||--o{ RAPPORTAGE_DOELKOPPELING : "rapportage_id"
+    BEHANDELDOEL ||--o{ RAPPORTAGE_DOELKOPPELING : "behandeldoel_id"
+    RAPPORTAGE ||--o{ RAPPORTAGESECTIE : "secties (max 1 per sectietype)"
+    RAPPORTAGE ||--o| INCIDENTDETAIL : "1-op-1 (alleen bij type incident)"
+    INCIDENTDETAIL ||--o{ INCIDENT_BETROKKENE : "betrokkenen"
+    MEDEWERKER |o--o{ INCIDENT_BETROKKENE : "medewerker_id (optioneel, xor naam_vrij)"
+    RAPPORTAGE |o--o{ AI_BRONVERWIJZING : "eigenaar (polymorf, indien eigenaar_entiteit=rapportage)"
+    OVERDRACHTSSAMENVATTING |o--o{ AI_BRONVERWIJZING : "eigenaar (polymorf, indien eigenaar_entiteit=overdrachtssamenvatting)"
+    ZORGEPISODE ||--o{ OVERDRACHTSSAMENVATTING : "zorgepisode_id"
+    MEDEWERKER |o--o{ OVERDRACHTSSAMENVATTING : "bevestigd_door_medewerker_id"
+    </div>
+    <div class="hint">sleep om te pannen · scroll om te zoomen</div>
+  </div>
+</div>
+
+<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
+<script src="https://cdn.jsdelivr.net/npm/svg-pan-zoom@3.6.1/dist/svg-pan-zoom.min.js"></script>
+<script>
+  mermaid.initialize({
+    startOnLoad: false,
+    theme: "base",
+    themeVariables: {
+      background: "#08211D",
+      primaryColor: "#0E2E29",
+      primaryBorderColor: "#57D8C6",
+      primaryTextColor: "#EAFBF7",
+      lineColor: "#57D8C6",
+      textColor: "#EAFBF7",
+      tertiaryColor: "#123B35",
+      attributeBackgroundColorOdd: "#0E2E29",
+      attributeBackgroundColorEven: "#123B35",
+      fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace",
+      fontSize: "13px"
+    }
+  });
+
+  (async () => {
+    await mermaid.run({ querySelector: "#diagram" });
+    document.getElementById("loading").remove();
+
+    const svgEl = document.querySelector("#diagram svg");
+    svgEl.removeAttribute("style");
+
+    const panZoom = svgPanZoom(svgEl, {
+      panEnabled: true,
+      zoomEnabled: true,
+      controlIconsEnabled: false,
+      fit: true,
+      center: true,
+      minZoom: 0.15,
+      maxZoom: 8,
+      zoomScaleSensitivity: 0.35
+    });
+
+    document.getElementById("zoom-in").addEventListener("click", () => panZoom.zoomIn());
+    document.getElementById("zoom-out").addEventListener("click", () => panZoom.zoomOut());
+    document.getElementById("zoom-fit").addEventListener("click", () => { panZoom.fit(); panZoom.center(); });
+    document.getElementById("zoom-reset").addEventListener("click", () => { panZoom.reset(); });
+
+    window.addEventListener("resize", () => { panZoom.resize(); panZoom.fit(); panZoom.center(); });
+  })();
+</script>
+
+</body>
+</html>

docs/datamodel/diagrammen/model-screening-erd.html

@@ -0,0 +1,303 @@
+<!doctype html>
+<html lang="nl">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Screening — entiteit-relatiediagram (achterhaald)</title>
+<style>
+  :root {
+    --bg: #F5FAF9;
+    --surface: #FFFFFF;
+    --surface-2: #EAF3F1;
+    --border: #CFE1DE;
+    --text: #12211F;
+    --text-muted: #4C6B66;
+    --accent: #0F766E;
+    --font-sans: -apple-system, "Segoe UI", "Helvetica Neue", Arial, sans-serif;
+    --font-mono: ui-monospace, "SFMono-Regular", "Cascadia Code", "Roboto Mono", Consolas, monospace;
+  }
+
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #0A1615;
+      --surface: #10201E;
+      --surface-2: #15302C;
+      --border: #1F3A36;
+      --text: #E6F5F2;
+      --text-muted: #8FB6B0;
+      --accent: #34D6C4;
+    }
+  }
+
+  * { box-sizing: border-box; }
+
+  html, body {
+    margin: 0;
+    height: 100%;
+    overscroll-behavior: none;
+  }
+
+  body {
+    background: var(--bg);
+    color: var(--text);
+    font-family: var(--font-sans);
+  }
+
+  .app {
+    display: flex;
+    flex-direction: column;
+    height: 100vh;
+  }
+
+  /* Toolbar */
+  .toolbar {
+    flex: 0 0 auto;
+    display: flex;
+    align-items: center;
+    justify-content: space-between;
+    gap: 16px;
+    padding: 10px 16px;
+    background: var(--surface);
+    border-bottom: 1px solid var(--border);
+  }
+
+  .title-group {
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+    min-width: 0;
+  }
+
+  .title-group h1 {
+    font-size: 0.95rem;
+    margin: 0;
+    font-weight: 700;
+    white-space: nowrap;
+  }
+
+  .title-group .source {
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: var(--text-muted);
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+  }
+
+  .controls {
+    display: flex;
+    gap: 6px;
+    flex: 0 0 auto;
+  }
+
+  .controls button {
+    width: 32px;
+    height: 32px;
+    border-radius: 6px;
+    border: 1px solid var(--border);
+    background: var(--surface-2);
+    color: var(--text);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    padding: 0;
+  }
+
+  .controls button:hover { border-color: var(--accent); color: var(--accent); }
+  .controls button:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
+
+  @media (prefers-reduced-motion: no-preference) {
+    .controls button { transition: border-color 120ms, color 120ms; }
+  }
+
+  /* Diagram canvas */
+  .canvas-wrap {
+    flex: 1 1 auto;
+    position: relative;
+    overflow: hidden;
+    background:
+      repeating-linear-gradient(0deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      repeating-linear-gradient(90deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      #08211D;
+  }
+
+  .canvas-wrap .hint {
+    position: absolute;
+    left: 16px;
+    bottom: 14px;
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: #6FBFB2;
+    z-index: 2;
+    pointer-events: none;
+  }
+
+  #diagram {
+    width: 100%;
+    height: 100%;
+  }
+
+  #diagram svg {
+    width: 100%;
+    height: 100%;
+    display: block;
+  }
+
+  .loading {
+    position: absolute;
+    inset: 0;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    color: #6FBFB2;
+    font-family: var(--font-mono);
+    font-size: 13px;
+  }
+</style>
+</head>
+<body>
+
+<div class="app">
+  <div class="toolbar">
+    <div class="title-group">
+      <h1>Screening — entiteit-relatiediagram (achterhaald)</h1>
+      <span class="source">model-screening.md §2 · 8 entiteiten · 11 relaties · ACHTERHAALD door B21 (screeningsbesluit = acceptatiebesluit, geen apart voorafgaand besluit meer) — zie model-instroom.md (care_acceptance_decision)</span>
+    </div>
+    <div class="controls">
+      <button id="zoom-out" title="Uitzoomen" aria-label="Uitzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-in" title="Inzoomen" aria-label="Inzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="8" y1="3" x2="8" y2="13" stroke="currentColor" stroke-width="2"/><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-fit" title="Passend maken" aria-label="Passend maken">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M2 6V2h4M14 6V2h-4M2 10v4h4M14 10v4h-4" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+      <button id="zoom-reset" title="Reset (100%)" aria-label="Reset naar 100%">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M8 2a6 6 0 1 1-4.24 1.76" stroke="currentColor" stroke-width="1.8" stroke-linecap="round"/>
+          <path d="M2 2v3h3" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+    </div>
+  </div>
+
+  <div class="canvas-wrap">
+    <div class="loading" id="loading">Diagram wordt geladen…</div>
+    <div id="diagram" class="mermaid">
+erDiagram
+    AANMELDING {
+        uuid id PK
+    }
+    MEDEWERKER {
+        uuid id PK
+    }
+    VERWIJZER {
+        uuid id PK
+    }
+    DOCUMENT {
+        uuid id PK
+    }
+    SCREENING {
+        uuid id PK
+        uuid aanmelding_id FK
+        uuid screener_id FK
+        date gestart_op
+        string status
+        string urgentie_id
+    }
+    SCREENING_ACTIVITEIT {
+        uuid id PK
+        uuid screening_id FK
+        uuid uitgevoerd_door FK
+        string type_id
+        timestamp uitgevoerd_op
+        boolean crisis_signaal
+    }
+    SCREENING_BESLUIT {
+        uuid id PK
+        uuid screening_id FK
+        uuid genomen_door FK
+        string uitkomst_id
+        string urgentie_id
+        text motivatie
+    }
+    INFORMATIE_UITVRAAG {
+        uuid id PK
+        uuid screening_id FK
+        uuid gericht_aan_verwijzer_id FK
+        uuid uitgevraagd_door FK
+        uuid ontvangen_document_id FK
+        string type_id
+        string status
+    }
+
+    AANMELDING ||--o{ SCREENING : "aanmelding_id"
+    SCREENING ||--o{ SCREENING_ACTIVITEIT : "activiteiten"
+    SCREENING ||--o| SCREENING_BESLUIT : "besluit (max 1)"
+    SCREENING ||--o{ INFORMATIE_UITVRAAG : "uitvragen"
+    MEDEWERKER ||--o{ SCREENING_ACTIVITEIT : "uitgevoerd_door"
+    MEDEWERKER |o--o{ SCREENING : "screener_id"
+    MEDEWERKER ||--o{ SCREENING_BESLUIT : "genomen_door"
+    MEDEWERKER ||--o{ INFORMATIE_UITVRAAG : "uitgevraagd_door"
+    VERWIJZER |o--o{ INFORMATIE_UITVRAAG : "gericht_aan_verwijzer_id"
+    DOCUMENT |o--o{ INFORMATIE_UITVRAAG : "ontvangen_document_id"
+    SCREENING_BESLUIT |o--o| AANMELDING : "onderbouwing uitkomst (0..1)"
+    </div>
+    <div class="hint">sleep om te pannen · scroll om te zoomen</div>
+  </div>
+</div>
+
+<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
+<script src="https://cdn.jsdelivr.net/npm/svg-pan-zoom@3.6.1/dist/svg-pan-zoom.min.js"></script>
+<script>
+  mermaid.initialize({
+    startOnLoad: false,
+    theme: "base",
+    themeVariables: {
+      background: "#08211D",
+      primaryColor: "#0E2E29",
+      primaryBorderColor: "#57D8C6",
+      primaryTextColor: "#EAFBF7",
+      lineColor: "#57D8C6",
+      textColor: "#EAFBF7",
+      tertiaryColor: "#123B35",
+      attributeBackgroundColorOdd: "#0E2E29",
+      attributeBackgroundColorEven: "#123B35",
+      fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace",
+      fontSize: "13px"
+    }
+  });
+
+  (async () => {
+    await mermaid.run({ querySelector: "#diagram" });
+    document.getElementById("loading").remove();
+
+    const svgEl = document.querySelector("#diagram svg");
+    svgEl.removeAttribute("style");
+
+    const panZoom = svgPanZoom(svgEl, {
+      panEnabled: true,
+      zoomEnabled: true,
+      controlIconsEnabled: false,
+      fit: true,
+      center: true,
+      minZoom: 0.15,
+      maxZoom: 8,
+      zoomScaleSensitivity: 0.35
+    });
+
+    document.getElementById("zoom-in").addEventListener("click", () => panZoom.zoomIn());
+    document.getElementById("zoom-out").addEventListener("click", () => panZoom.zoomOut());
+    document.getElementById("zoom-fit").addEventListener("click", () => { panZoom.fit(); panZoom.center(); });
+    document.getElementById("zoom-reset").addEventListener("click", () => { panZoom.reset(); });
+
+    window.addEventListener("resize", () => { panZoom.resize(); panZoom.fit(); panZoom.center(); });
+  })();
+</script>
+
+</body>
+</html>

docs/datamodel/diagrammen/model-wachtlijst-erd.html

@@ -0,0 +1,297 @@
+<!doctype html>
+<html lang="nl">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Wachtlijst — entiteit-relatiediagram</title>
+<style>
+  :root {
+    --bg: #F5FAF9;
+    --surface: #FFFFFF;
+    --surface-2: #EAF3F1;
+    --border: #CFE1DE;
+    --text: #12211F;
+    --text-muted: #4C6B66;
+    --accent: #0F766E;
+    --font-sans: -apple-system, "Segoe UI", "Helvetica Neue", Arial, sans-serif;
+    --font-mono: ui-monospace, "SFMono-Regular", "Cascadia Code", "Roboto Mono", Consolas, monospace;
+  }
+
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #0A1615;
+      --surface: #10201E;
+      --surface-2: #15302C;
+      --border: #1F3A36;
+      --text: #E6F5F2;
+      --text-muted: #8FB6B0;
+      --accent: #34D6C4;
+    }
+  }
+
+  * { box-sizing: border-box; }
+
+  html, body {
+    margin: 0;
+    height: 100%;
+    overscroll-behavior: none;
+  }
+
+  body {
+    background: var(--bg);
+    color: var(--text);
+    font-family: var(--font-sans);
+  }
+
+  .app {
+    display: flex;
+    flex-direction: column;
+    height: 100vh;
+  }
+
+  /* Toolbar */
+  .toolbar {
+    flex: 0 0 auto;
+    display: flex;
+    align-items: center;
+    justify-content: space-between;
+    gap: 16px;
+    padding: 10px 16px;
+    background: var(--surface);
+    border-bottom: 1px solid var(--border);
+  }
+
+  .title-group {
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+    min-width: 0;
+  }
+
+  .title-group h1 {
+    font-size: 0.95rem;
+    margin: 0;
+    font-weight: 700;
+    white-space: nowrap;
+  }
+
+  .title-group .source {
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: var(--text-muted);
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+  }
+
+  .controls {
+    display: flex;
+    gap: 6px;
+    flex: 0 0 auto;
+  }
+
+  .controls button {
+    width: 32px;
+    height: 32px;
+    border-radius: 6px;
+    border: 1px solid var(--border);
+    background: var(--surface-2);
+    color: var(--text);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    cursor: pointer;
+    padding: 0;
+  }
+
+  .controls button:hover { border-color: var(--accent); color: var(--accent); }
+  .controls button:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
+
+  @media (prefers-reduced-motion: no-preference) {
+    .controls button { transition: border-color 120ms, color 120ms; }
+  }
+
+  /* Diagram canvas */
+  .canvas-wrap {
+    flex: 1 1 auto;
+    position: relative;
+    overflow: hidden;
+    background:
+      repeating-linear-gradient(0deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      repeating-linear-gradient(90deg, rgba(87,216,198,0.07) 0 1px, transparent 1px 28px),
+      #08211D;
+  }
+
+  .canvas-wrap .hint {
+    position: absolute;
+    left: 16px;
+    bottom: 14px;
+    font-family: var(--font-mono);
+    font-size: 11px;
+    color: #6FBFB2;
+    z-index: 2;
+    pointer-events: none;
+  }
+
+  #diagram {
+    width: 100%;
+    height: 100%;
+  }
+
+  #diagram svg {
+    width: 100%;
+    height: 100%;
+    display: block;
+  }
+
+  .loading {
+    position: absolute;
+    inset: 0;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    color: #6FBFB2;
+    font-family: var(--font-mono);
+    font-size: 13px;
+  }
+</style>
+</head>
+<body>
+
+<div class="app">
+  <div class="toolbar">
+    <div class="title-group">
+      <h1>Wachtlijst — entiteit-relatiediagram</h1>
+      <span class="source">model-wachtlijst.md §2–§3 · 9 entiteiten · 8 relaties · voorlopig onderzoeksmodel, niet bouwrijp</span>
+    </div>
+    <div class="controls">
+      <button id="zoom-out" title="Uitzoomen" aria-label="Uitzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-in" title="Inzoomen" aria-label="Inzoomen">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none"><line x1="8" y1="3" x2="8" y2="13" stroke="currentColor" stroke-width="2"/><line x1="3" y1="8" x2="13" y2="8" stroke="currentColor" stroke-width="2"/></svg>
+      </button>
+      <button id="zoom-fit" title="Passend maken" aria-label="Passend maken">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M2 6V2h4M14 6V2h-4M2 10v4h4M14 10v4h-4" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+      <button id="zoom-reset" title="Reset (100%)" aria-label="Reset naar 100%">
+        <svg width="16" height="16" viewBox="0 0 16 16" fill="none">
+          <path d="M8 2a6 6 0 1 1-4.24 1.76" stroke="currentColor" stroke-width="1.8" stroke-linecap="round"/>
+          <path d="M2 2v3h3" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"/>
+        </svg>
+      </button>
+    </div>
+  </div>
+
+  <div class="canvas-wrap">
+    <div class="loading" id="loading">Diagram wordt geladen…</div>
+    <div id="diagram" class="mermaid">
+erDiagram
+    WACHTLIJSTPLAATSING {
+        uuid id PK
+        string soort
+        uuid aanmelding_id FK
+        uuid zorgepisode_id FK
+        uuid afdeling_id FK
+        uuid zorgprogramma_id FK
+        date teldatum
+        string status
+    }
+    WACHTLIJSTACTIVITEIT {
+        uuid id PK
+        uuid wachtlijstplaatsing_id FK
+        uuid uitgevoerd_door FK
+        string type
+        date datum
+    }
+    WACHTLIJSTOPSCHORTING {
+        uuid id PK
+        uuid wachtlijstplaatsing_id FK
+        date begindatum
+        date einddatum
+        string reden
+    }
+    referral_case {
+        uuid id PK
+    }
+    clinical_care_episode {
+        uuid id PK
+    }
+    AFDELING {
+        uuid id PK
+    }
+    ZORGPROGRAMMA {
+        uuid id PK
+    }
+    MEDEWERKER {
+        uuid id PK
+    }
+    VESTIGING {
+        uuid id PK
+    }
+
+    referral_case ||--o{ WACHTLIJSTPLAATSING : "aanmelding_id (soort aanmeld)"
+    clinical_care_episode ||--o{ WACHTLIJSTPLAATSING : "zorgepisode_id (soort behandel)"
+    AFDELING ||--o{ WACHTLIJSTPLAATSING : "afdeling_id"
+    ZORGPROGRAMMA |o--o{ WACHTLIJSTPLAATSING : "zorgprogramma_id (optioneel)"
+    WACHTLIJSTPLAATSING ||--o{ WACHTLIJSTACTIVITEIT : "wachtlijstplaatsing_id"
+    WACHTLIJSTPLAATSING ||--o{ WACHTLIJSTOPSCHORTING : "wachtlijstplaatsing_id"
+    MEDEWERKER ||--o{ WACHTLIJSTACTIVITEIT : "uitgevoerd_door"
+    VESTIGING |o--o{ AFDELING : "vestiging_id (voorgesteld, open §7.2)"
+    </div>
+    <div class="hint">sleep om te pannen · scroll om te zoomen</div>
+  </div>
+</div>
+
+<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
+<script src="https://cdn.jsdelivr.net/npm/svg-pan-zoom@3.6.1/dist/svg-pan-zoom.min.js"></script>
+<script>
+  mermaid.initialize({
+    startOnLoad: false,
+    theme: "base",
+    themeVariables: {
+      background: "#08211D",
+      primaryColor: "#0E2E29",
+      primaryBorderColor: "#57D8C6",
+      primaryTextColor: "#EAFBF7",
+      lineColor: "#57D8C6",
+      textColor: "#EAFBF7",
+      tertiaryColor: "#123B35",
+      attributeBackgroundColorOdd: "#0E2E29",
+      attributeBackgroundColorEven: "#123B35",
+      fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace",
+      fontSize: "13px"
+    }
+  });
+
+  (async () => {
+    await mermaid.run({ querySelector: "#diagram" });
+    document.getElementById("loading").remove();
+
+    const svgEl = document.querySelector("#diagram svg");
+    svgEl.removeAttribute("style");
+
+    const panZoom = svgPanZoom(svgEl, {
+      panEnabled: true,
+      zoomEnabled: true,
+      controlIconsEnabled: false,
+      fit: true,
+      center: true,
+      minZoom: 0.15,
+      maxZoom: 8,
+      zoomScaleSensitivity: 0.35
+    });
+
+    document.getElementById("zoom-in").addEventListener("click", () => panZoom.zoomIn());
+    document.getElementById("zoom-out").addEventListener("click", () => panZoom.zoomOut());
+    document.getElementById("zoom-fit").addEventListener("click", () => { panZoom.fit(); panZoom.center(); });
+    document.getElementById("zoom-reset").addEventListener("click", () => { panZoom.reset(); });
+
+    window.addEventListener("resize", () => { panZoom.resize(); panZoom.fit(); panZoom.center(); });
+  })();
+</script>
+
+</body>
+</html>

docs/datamodel/entiteitenkaarten/ehr-referral-terminology.html

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

docs/datamodel/feitenmodellen/feitenmodel-instroom.md

@@ -0,0 +1,765 @@
+# 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.
+
+**Beantwoord in domeinreview (19 juli 2026):**
+
+- Een request kan zonder bekende persoon bestaan. Dit komt voor bij
+  crisisaanmeldingen waarbij de identiteit nog niet vaststaat. Een
+  placeholder- of "John Doe"-persoon die later moet worden om-gehangen is
+  bewust geen oplossing — dat vereist het achteraf verplaatsen van alle
+  gekoppelde feiten naar de echte persoon, wat tegen append-only ingaat. In
+  plaats daarvan is `person_id` optioneel en wordt de koppeling vastgelegd
+  als een eigen, gedateerd en toegeschreven feit zodra de identiteit bekend
+  wordt.
+
+**Te toetsen:**
+
+- Is “dezelfde geuite zorgvraag” een expliciete relatie tussen verzoeken, of
+  wordt samenhang uitsluitend binnen de Referral Case beoordeeld?
+
+### 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.
+
+**Route 3 — heroverweging na afwijzing**
+
+A24. *Beoordeling van Referral Case C-405 constateert op 17 juli 2026 geen
+inhoudelijke match met de geuite zorgvraag.*
+
+A25. *Acceptatiebesluit A-731 betreft Referral Case C-405.*
+
+A26. *Acceptatiebesluit A-731 heeft besluituitkomst “afgewezen”, motivering
+“onvoldoende inhoudelijke match”.*
+
+A27. *Referral Case C-405 is na acceptatiebesluit A-731 afgesloten met
+uitkomst “afgewezen”.*
+
+A28. *Bij Referral Case C-405 is op 24 juli 2026 een informatieverzoek
+vastgelegd door medewerker K. Jansen, met gevraagde informatie “aanvullende
+diagnostische onderbouwing”.*
+
+A29. *Submission S-210 is op 26 juli 2026 ontvangen als reactie op het
+informatieverzoek van 24 juli 2026 en representeert het zorgverzoek van
+Referral Case C-405.*
+
+A30. *Beoordeling van de heroverweging van Referral Case C-405 bevestigt op
+27 juli 2026 alsnog een inhoudelijke match, op basis van submission S-210.*
+
+A31. *Acceptatiebesluit A-751 betreft Referral Case C-405, heeft
+besluituitkomst “geaccepteerd” en vervangt acceptatiebesluit A-731.*
+
+A32. *De reden voor vervanging van acceptatiebesluit A-731 door A-751 is
+“aanvullende diagnostiek toont alsnog inhoudelijke match aan”.*
+
+A33. *Zorgepisode E-905 is ontstaan uit acceptatiebesluit A-751.*
+
+Acceptatiebesluit A-731 blijft ongewijzigd bewaard; A-751 draagt de
+expliciete vervangt-relatie en de reden. Wie het geldige besluit van
+Referral Case C-405 wil weten, volgt de vervangt-keten naar het laatste,
+niet-vervangen besluit — dat hoeft niet impliciet uit datums te worden
+afgeleid (domeinreview 19 juli 2026, vraag 3).
+
+**Route 4 — cliënt trekt in vóór start intake**
+
+A34. *Referral Case C-406 is op 10 augustus 2026 afgesloten met
+acceptatiebesluit A-760, uitkomst “geaccepteerd”, vervolgroute
+“intakewachtlijst”.*
+
+A35. *Zorgepisode E-910 is ontstaan uit acceptatiebesluit A-760.*
+
+A36. *Referral Case C-406 is op 15 augustus 2026, vóór start van de intake,
+door de cliënt ingetrokken; vastgelegd door medewerker K. Jansen.*
+
+A37. *Zorgepisode E-910 is op 15 augustus 2026 afgesloten met reden
+“ingetrokken door cliënt vóór start intake”.*
+
+Cliënt-intrekking is geen Care Acceptance Decision en vereist geen
+beslisbevoegdheid — het is een registratie van de cliëntkeuze, niet een
+inhoudelijke herbeoordeling. Een cliënt kan een case op elk moment intrekken,
+niet uitsluitend ná een positief besluit.
+
+**Route 5 — institutionele correctie vóór start intake**
+
+A38. *Referral Case C-407 is op 12 augustus 2026 afgesloten met
+acceptatiebesluit A-762, uitkomst “geaccepteerd”, vervolgroute
+“intakewachtlijst”.*
+
+A39. *Zorgepisode E-911 is ontstaan uit acceptatiebesluit A-762.*
+
+A40. *Acceptatiebesluit A-763 betreft Referral Case C-407, heeft
+besluituitkomst “afgewezen” en vervangt acceptatiebesluit A-762, met reden
+“capaciteitsinschatting bleek bij nader inzien onjuist”.*
+
+A41. *Medewerker M. de Boer handelde bij acceptatiebesluit A-763 op grond van
+dezelfde beslisbevoegdheid als bij een regulier acceptatiebesluit.*
+
+A42. *Zorgepisode E-911 is op 16 augustus 2026 afgesloten met reden
+“acceptatiebesluit herzien vóór start intake”.*
+
+Een institutionele correctie is wél een Care Acceptance Decision — hetzelfde
+vervangt-mechanisme als Route 3, nu in omgekeerde richting — en vereist
+dezelfde bevoegdheid als het oorspronkelijke besluit. In beide routes 4 en 5
+verdwijnt de al ontstane zorgepisode niet: zij wordt afgesloten met een
+passende reden, net als iedere andere episode-afsluiting (B3).
+
+**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.
+- Een request kan zonder bekende persoon bestaan (crisisaanmelding met nog
+  onbekende identiteit). Zodra de persoon bekend is, betreft het request
+  precies één persoon of cliënt; de koppeling zelf is een gedateerd,
+  toegeschreven feit, geen stille invulling van een placeholder (domeinreview
+  19 juli 2026).
+- 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 case heeft geen vaste, eenrichtings-statusmachine. De actuele stand
+  wordt afgeleid uit een tijdlijn van gebeurtenissen (toewijzingen,
+  informatieverzoeken, acceptatiebesluiten), niet uit één overschrijfbaar
+  statusveld (domeinreview 19 juli 2026 — zie ook B7 bij wachtlijst en de
+  non-lineaire aanmelding-status uit discovery §5.1 #5).
+- Een informatieverzoek is een gebeurtenis: wie heeft wanneer welke
+  aanvullende informatie gevraagd. Deze gebeurtenis kan zich op elk moment
+  voordoen, ook ná een eerder acceptatiebesluit tijdens een heroverweging —
+  niet uitsluitend vóór het eerste besluit.
+- Een afgesloten case kan bij heroverweging een nieuw acceptatiebesluit
+  krijgen; hoe het eerdere besluit dan gehistoriseerd wordt (vervangen versus
+  aanvullend) is nog niet vastgesteld (zie §7 vraag 3).
+
+### 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 besluit kan optioneel precies één eerder besluit van dezelfde case
+  vervangen, met een verplichte reden voor vervanging (heroverweging,
+  domeinreview 19 juli 2026, vraag 3). Het vervangen besluit blijft
+  ongewijzigd bewaard; vervanging is een expliciete relatie, geen mutatie.
+- Het geldige besluit van een case is het laatste besluit in de
+  vervangt-keten; eerdere besluiten blijven raadpleegbaar maar zijn niet meer
+  bepalend voor de actuele stand.
+- Cliënt-intrekking van een Referral Case is geen Care Acceptance Decision:
+  het vereist geen beslisbevoegdheid en kan op elk moment plaatsvinden,
+  inclusief ná een positief besluit (domeinreview 19 juli 2026, vraag 4).
+- Een institutionele correctie van een eerder positief besluit ná ontstaan
+  van de zorgepisode volgt hetzelfde vervangt-mechanisme als heroverweging
+  (Route 3) en vereist dezelfde beslisbevoegdheid als het oorspronkelijke
+  besluit.
+- Een reeds ontstane zorgepisode wordt bij intrekking of correctie nooit
+  verwijderd of ongedaan gemaakt; zij wordt afgesloten met een passende
+  reden, net als elke andere episode-afsluiting.
+- 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):**
+
+- **Vraag 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.
+- **Vraag 5.** `aanvullende_informatie_nodig` is geen besluituitkomst en geen
+  fase in een vaste statusmachine. Er bestaat op dat moment nog geen Care
+  Acceptance Decision — een besluit vereist een bevoegde beslisser die de
+  zaak daadwerkelijk afrondt, en dat is hier per definitie nog niet gebeurd.
+  In plaats daarvan is een informatieverzoek een eigen, gedateerd en
+  toegeschreven gebeurtenisfeit (vergelijkbaar met een screeningsactiviteit),
+  en wordt de actuele stand van een Referral Case afgeleid uit de tijdlijn
+  van gebeurtenissen in plaats van uit één overschrijfbaar statusveld. Dit
+  sluit aan bij eerdere keuzes om de GGZ-praktijk niet in een te lineair
+  proces te dwingen (B7 wachtlijst, non-lineaire aanmelding-status discovery
+  §5.1 #5) en is verwerkt in §4 hierboven.
+- **Vraag 3.** Bij heroverweging krijgt een afgesloten case een nieuw
+  acceptatiebesluit. Het eerdere besluit blijft ongewijzigd bewaard en het
+  nieuwe besluit krijgt een expliciete "vervangt"-relatie met verplichte
+  reden — geen impliciete "laatste besluit is geldig"-regel op basis van
+  datum. Dit komt vaak genoeg voor in de praktijk om de extra structuur te
+  rechtvaardigen. Verwerkt in §3.5 (Route 3) en §4 hierboven.
+- **Vraag 4.** Een geaccepteerde case kan vóór start van de intake worden
+  teruggedraaid, op twee manieren: cliënt-intrekking (geen besluit, geen
+  bevoegdheidseis, kan op elk moment) of institutionele correctie (een
+  vervangend Care Acceptance Decision, zelfde bevoegdheid als het
+  oorspronkelijke besluit). De al ontstane zorgepisode wordt in beide
+  gevallen afgesloten met een passende reden, nooit verwijderd. Verwerkt in
+  §3.5 (Route 4 en 5) en §4 hierboven.
+
+**Nog open, nader onderzoek nodig:**
+
+- **Vraag 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), en raakt dit feitenmodel niet meer — die uitkomst hangt aan
+  de intake, niet aan de Referral Case.
+
+Vraag 2 vergt apart onderzoek (zie besluitenlog §10) en blokkeert de
+volgende stappen niet langer. Nu volgen:
+
+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`.

docs/datamodel/feitenmodellen/feitenmodel-intake-behandeladvies.md

@@ -0,0 +1,486 @@
+# Feitenmodel intake en behandeladvies — FCO-IM-ronde
+
+**Status:** concept voor domeinreview, geen logisch model
+**Datum:** 19 juli 2026
+**Scope:** zorginhoudelijke intake, intakecontact, kindcheck, en het behandeladvies waarmee de intake wordt afgerond
+**Autoriteit:** `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft leidend
+**Aanleiding:** sessiedoel "ronde de feitenronde van intake en behandeladvies af"; vervolg op de instroom-feitenronde (`feitenmodel-instroom.md`) en op `feitenmodel-instroom.md` §7 vraag 2 (behandeladvies-uitkomsten, tot nu toe geparkeerd)
+**Bronmateriaal:** het oudere `../deelmodellen/model-intake.md` bevat al een grondig doordachte, LKS-onderbouwde intake-uitkomst-structuur — deze ronde herbruikt die inhoud, corrigeert de inmiddels achterhaalde episode-timing-aanname, hernoemt naar het Engelstalige werkbegrippenkader (B20) en lost de opengebleven vraag over het behandeladvies op
+
+## 1. Doel van deze ronde
+
+Deze ronde formuleert elementaire feiten voor het vervolg ná een positief
+acceptatiebesluit: de zorginhoudelijke intake, de contacten en onderzoeken
+daarbinnen, de kindcheck, en de afronding van de intake met een
+behandeladvies. Net als bij instroom komen eerst de feiten, dan pas
+entiteiten en cardinaliteiten.
+
+**Centrale correctie ten opzichte van het oudere `../deelmodellen/model-intake.md`:** dat
+document ging nog uit van "episode ontstaat bij aanmelding-uitkomst
+`intake`". Dat is met B22 (19 juli 2026) achterhaald — de zorgepisode
+ontstaat al bij het acceptatiebesluit zelf, óók bij vervolgroute
+intakewachtlijst. De intake start dus niet gelijktijdig met het ontstaan van
+de episode, maar op enig moment daarna, mogelijk na een periode op de
+intakewachtlijst.
+
+**Centrale ontwerpkeuze deze ronde:** het behandeladvies wordt, net als het
+eerdere acceptatiebesluit (B21), **geen apart, voorafgaand advies-object**
+zonder eigen gewicht — maar wél een eigen entiteit los van de intake zelf,
+naar het patroon van Care Acceptance Decision. De intake is het
+onderzoekstraject (proces-container); het behandeladvies is het object dat
+de intake afrondt en de vervolgrichting draagt, met dezelfde
+vervangt-mogelijkheid bij heroverweging die bij het acceptatiebesluit al is
+vastgesteld (B23). Dit vervangt het oudere voorstel waarin uitkomst en
+advies platte velden op INTAKE zelf waren.
+
+## 2. Werkbegrippen
+
+De Engelse namen zijn werktermen en worden pas na domeinreview in de
+begrippenlijst vastgesteld. Waar een werkterm al in
+`../begrippenlijst-kernmodel.md` §4 staat, wordt die hergebruikt.
+
+### Clinical Intake Assessment — `clinical_intake_assessment`
+
+Een dynamisch klinisch onderzoekstraject voor één samenhangende zorgvraag,
+met meerdere contacten, onderzoeken, disciplines en bevindingen. Hangt aan
+de Clinical Care Episode, niet direct aan de Referral Case.
+
+Een Clinical Intake Assessment is niet:
+- één gesprek of contact;
+- de screening (die hoort bij instroom, vóór acceptatie);
+- FHIR `Encounter`;
+- automatisch gestart op het moment dat de episode ontstaat — er kan tijd
+  tussen zitten (intakewachtlijst).
+
+### Intake Contact — `intake_contact`
+
+Eén feitelijk contact (gesprek, telefonisch contact, huisbezoek, aanvullend
+onderzoek, beeldcontact) binnen een Clinical Intake Assessment.
+
+Een Intake Contact is niet: de intake zelf, of automatisch een declarabel
+consult — dat is een latere, aparte ZPM-consultregistratie die hiernaar kan
+verwijzen.
+
+### Child Safety Check — `child_safety_check`
+
+De wettelijk verankerde kindcheck (Wet verplichte meldcode huiselijk geweld
+en kindermishandeling; KNMG-meldcode) bij de intake van een volwassen
+cliënt: is de cliënt verantwoordelijk voor minderjarigen, zijn er zorgen
+over hun veiligheid, en is daarop actie ondernomen.
+
+Een Child Safety Check is niet: het volledige meldcode-stappenplan (dat is
+proces-state, TIP-terrein) — alleen de klinische feiten (de vlaggen en
+toelichtingen) horen in het ECD.
+
+### Treatment Advice — `treatment_advice`
+
+Het object dat een Clinical Intake Assessment afrondt: draagt de uitkomst
+(bijvoorbeeld in zorg, terug- of doorverwijzing, aanvullende diagnostiek
+nodig), het geadviseerde zorgprogramma, en de inhoudelijke toelichting. Kan
+een eerder behandeladvies van dezelfde intake vervangen bij heroverweging,
+met dezelfde vervangt-constructie als Care Acceptance Decision (B23).
+
+Een Treatment Advice is niet:
+- een apart, voorafgaand advies naast een later formeel besluit — het
+  advies zelf ís de vervolgrichting, net als bij het acceptatiebesluit
+  (B21-patroon toegepast);
+- het acceptatiebesluit (dat gaat over toegang tot het zorgproces, dit gaat
+  over de inhoudelijke richting na onderzoek);
+- een behandelplan — het advies wijst een richting, het behandelplan werkt
+  die vervolgens uit.
+
+## 3. Elementaire feitzinnen
+
+### 3.1 Intake start en verloop
+
+N1. *Clinical Intake Assessment N-1201 is op 18 juli 2026 aangemaakt voor
+Zorgepisode E-901, met aanleiding "regulier".*
+
+N2. *Clinical Intake Assessment N-1201 heeft status "gepland" sinds 18 juli
+2026.*
+
+N3. *Clinical Intake Assessment N-1201 heeft status "bezig" sinds 22 juli
+2026.*
+
+N4. *Clinical Intake Assessment N-1201 is toegewezen aan afdeling
+"Volwassenen".*
+
+N5. *Binnen dezelfde Zorgepisode E-901 is op 1 oktober 2026 een tweede
+Clinical Intake Assessment N-1205 gestart met aanleiding "intern", op
+afdeling "Ouderen".*
+
+N6. *Voor Zorgepisode E-903 is op 2 augustus 2026 een Clinical Intake
+Assessment N-1210 gestart met aanleiding "crisis", zonder voorafgaande
+screening.*
+
+N7. *Clinical Intake Assessment N-1201 is op 15 augustus 2026 heropend en
+heeft weer status "bezig", nadat zij eerder was afgerond.*
+
+N8. *Clinical Intake Assessment N-1215 is op 25 juli 2026 afgebroken met
+reden "cliënt trekt zich terug".*
+
+**Besloten in domeinreview (hergebruikt van `../deelmodellen/model-intake.md`, tijdlijn
+gecorrigeerd):**
+
+- Eén Clinical Intake Assessment per samenhangend onderzoekstraject; een
+  interne overgang (afdelingswissel) vormt geen nieuwe intake.
+- Een episode kan meerdere intakes hebben: regulier, intern (bijvoorbeeld
+  overgang naar een andere afdeling binnen dezelfde episode), en crisis.
+- Screening vóór intake blijft een nudge, geen harde eis — ook niet nu de
+  intake pas na het acceptatiebesluit start; crisis-instroom kan intake en
+  screening (bijna) gelijktijdig laten plaatsvinden.
+- Heropening (afgerond/afgebroken → bezig) is toegestaan, zelfde
+  flexibiliteitsprincipe als bij de Referral Case (B25) — geen
+  eenrichtingsstatus.
+
+**Gecorrigeerd ten opzichte van `../deelmodellen/model-intake.md`:**
+
+- De intake start niet "op basis van de aanmelding-uitkomst intake", maar
+  ergens ná het acceptatiebesluit, aan de Clinical Care Episode. Tussen het
+  ontstaan van de episode en de feitelijke start van de intake kan een
+  intakewachtlijst-periode zitten (Route 2A, `feitenmodel-instroom.md`).
+  Status "gepland" dekt precies dat interval.
+
+### 3.2 Intakecontact
+
+N9. *Intake Contact N-1301 is op 22 juli 2026 uitgevoerd binnen Clinical
+Intake Assessment N-1201, van type "intakegesprek", door psycholoog
+M. de Boer, met toelichting "eerste gesprek, anamnese afgenomen".*
+
+N10. *Intake Contact N-1301 had een geplande duur van 60 minuten.*
+
+N11. *Intake Contact N-1302 is op 24 juli 2026 uitgevoerd binnen Clinical
+Intake Assessment N-1201, van type "aanvullend onderzoek".*
+
+N12. *Intake Contact N-1303 is op 26 juli 2026 uitgevoerd binnen Clinical
+Intake Assessment N-1201, van type "beeldcontact".*
+
+**Besloten in domeinreview:**
+
+- Meerdere contacten van hetzelfde type op dezelfde dag zijn legitiem (geen
+  uniciteitsbeperking).
+- Contacttype-waardelijst bevat in elk geval: intakegesprek, aanvullend
+  onderzoek, telefonisch contact, huisbezoek, beeldcontact, overig.
+  Beeldcontact is toegevoegd ten opzichte van het oorspronkelijke
+  prototype — gangbare GGZ-contactvorm en ZPM-relevant.
+- Een Intake Contact hangt in deze ronde exclusief aan één Clinical Intake
+  Assessment. Generalisatie naar een bredere consult-/afspraakstructuur
+  (agenda, behandelcontacten) is uitdrukkelijk een latere ronde.
+
+### 3.3 Kindcheck
+
+N13. *Child Safety Check N-1401 is op 22 juli 2026 uitgevoerd door
+M. de Boer binnen Clinical Intake Assessment N-1201: cliënt is
+verantwoordelijk voor minderjarige kinderen: nee.*
+
+N14. *Child Safety Check N-1402 is op 3 augustus 2026 uitgevoerd binnen
+Clinical Intake Assessment N-1205: 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, 3 augustus".*
+
+N15. *Child Safety Check N-1402 registreert daarnaast: zwangerschap van de
+cliënt of partner: nee.*
+
+**Besloten in domeinreview (hergebruikt van `../deelmodellen/model-intake.md`):**
+
+- Drie ja/nee-vlaggen plus verplichte toelichting bij "ja" blijft de kern —
+  bevestigd prototypepatroon.
+- Vlag 1 is verbreed van "thuiswonende kinderen" naar "verantwoordelijk voor
+  minderjarigen" (KNMG-meldcode: ook co-ouderschap en andere zorgrelaties
+  tellen).
+- Een vierde vlag "zwangerschap van cliënt of partner" wordt toegevoegd —
+  de KNMG-kindcheck rekent het ongeboren kind expliciet mee. *(Algemene
+  domeinkennis, niet uit de eerdere onderzoeksrapporten — bij twijfel apart
+  te verifiëren tegen de meldcode-tekst.)*
+- Uitvoerder en datum zijn verplicht (provenance); de namen van eventuele
+  kinderen worden bewust niet als aparte persoonsrecords vastgelegd
+  (dataminimalisatie) — alleen aantal en leeftijden als vrije tekst.
+- Maximaal één Child Safety Check per Clinical Intake Assessment; een nieuwe
+  intake binnen dezelfde episode krijgt een eigen, nieuwe kindcheck (de
+  situatie kan gewijzigd zijn).
+
+### 3.4 Behandeladvies (afronding van de intake)
+
+**Route 1 — in zorg**
+
+N16. *Clinical Intake Assessment N-1201 heeft op 30 juli 2026 geleid tot
+Treatment Advice N-1501.*
+
+N17. *Treatment Advice N-1501 heeft uitkomst "in_zorg", geadviseerd
+zorgprogramma "Algemeen GGZ".*
+
+N18. *Treatment Advice N-1501 is vastgesteld door M. de Boer, handelend als
+regiebehandelaar van Zorgepisode E-901.*
+
+N19. *Clinical Intake Assessment N-1201 is op 30 juli 2026 afgerond met
+Treatment Advice N-1501.*
+
+**Route 2 — doorverwijzing, gevolgd door terugverwijzing (LKS-volgorde)**
+
+N20. *Treatment Advice N-1503 heeft uitkomst "doorverwijzing", met
+toelichting "beter passend bij aanbieder X, specialisatie trauma".*
+
+N20a. *Aanbieder X laat op 10 augustus 2026 weten geen plek te hebben.*
+
+N20b. *Treatment Advice N-1502 heeft uitkomst "terugverwijzing", met
+toelichting "geen doorverwijzing gelukt; advies aan huisarts: begeleiding
+POH-GGZ", en vervangt Treatment Advice N-1503.*
+
+Dit toont de LKS-volgorde (§3.6.2/patient journey fase 2-3): eerst een
+inspanningsverplichting tot doorverwijzing naar een beter passende
+aanbieder; pas als dat niets oplevert, of de cliënt komt niet in aanmerking
+voor GGZ, terugverwijzing naar de verwijzer met advies. Dit zijn dus geen
+twee gelijkwaardige, onafhankelijke uitkomsten maar een volgtijdelijk paar —
+het vervangt-mechanisme (Route 5 hieronder) dekt deze opvolging al.
+
+**Route 3 — aanvullende diagnostiek**
+
+N22. *Treatment Advice N-1504 heeft uitkomst "extra_diagnostiek", met
+toelichting "vermoeden persoonlijkheidsproblematiek, aanvullend
+psychodiagnostisch onderzoek nodig".*
+
+**Route 4 — heroverweging van het behandeladvies**
+
+N23. *Treatment Advice N-1505 betreft Clinical Intake Assessment N-1210,
+heeft uitkomst "extra_diagnostiek".*
+
+N24. *Op 20 augustus 2026 blijkt, na afronding van de aanvullende
+diagnostiek, dat Treatment Advice N-1506 nodig is: uitkomst "in_zorg",
+geadviseerd zorgprogramma "Trauma", en vervangt Treatment Advice N-1505.*
+
+N25. *De reden voor vervanging van Treatment Advice N-1505 door N-1506 is
+"aanvullende diagnostiek afgerond, duidelijk beeld voor zorgprogramma
+Trauma".*
+
+**Besloten in domeinreview, verscherpt door gericht LKS 4.0-onderzoek (19
+juli 2026 — volledige teksttoetsing, niet alleen samenvattingen):**
+
+- Behandeladvies is geen apart, voorafgaand advies naast een later
+  besluit — het draagt zelf de uitkomst, het richting-advies
+  (zorgprogramma) en de toelichting, analoog aan Care Acceptance Decision
+  (B21-patroon).
+- Vier uitkomstwaarden blijven het startpunt: `in_zorg`, `terugverwijzing`,
+  `doorverwijzing`, `extra_diagnostiek` — maar niet als vier gelijkwaardige
+  alternatieven.
+  - **`doorverwijzing` en `terugverwijzing` zijn LKS-genormeerd en
+    volgtijdelijk, geen onafhankelijke keuzes** (patient journey fase 2-3,
+    §3.6.2): eerst een inspanningsverplichting tot doorverwijzing naar een
+    beter passende aanbieder; pas als dat niets oplevert (of de cliënt komt
+    niet in aanmerking voor GGZ), volgt terugverwijzing naar de verwijzer
+    met advies. Als waardelijst-codes blijven het twee losse waarden; de
+    volgorde wordt gedekt door het vervangt-mechanisme (zie Route 2
+    hierboven), niet door een aparte sequentie-regel.
+  - **`extra_diagnostiek` is een praktijkgefundeerde toevoeging, geen
+    LKS-genormeerde uitkomst** — nergens in LKS 4.0 als zodanig benoemd.
+    Blijft behouden (de praktijk kent dit als reële afrondingsuitkomst),
+    maar expliciet gemarkeerd als zodanig, niet als landelijke norm
+    voorgesteld.
+- `Afgewezen` is bewust geen behandeladvies-uitkomst — afwijzen gebeurt al
+  bij het acceptatiebesluit (instroom); wie de intake bereikt, wordt niet
+  meer "afgewezen".
+- **Gedeeld/onduidelijk advies bij twijfel tussen behandelaren krijgt geen
+  eigen uitkomstwaarde.** LKS 4.0 §3.6.2 lost dit institutioneel op: bij
+  verschil van inzicht bepaalt de zorgaanbieder wie de doorslaggevende stem
+  heeft (vaak vastgelegd in het professioneel statuut) — een
+  escalatiemechanisme vóór afronding, geen apart feit in dit model.
+- **Cliënt die afziet van het geadviseerde vervolg is een later, apart
+  feit, geen intake-uitkomstwaarde** — analoog aan hoe planakkoord al los
+  van het behandelplan wordt vastgelegd (B13). LKS 4.0 gaat uit van
+  overeenstemming tussen regiebehandelaar en cliënt als vertrekpunt van de
+  uitkomst zelf; een latere weigering hoort dus bij een vervolgfeit, niet
+  bij `Treatment Advice`.
+- Vervolgroute bij wachtlijst voor behandelcapaciteit is geen aparte
+  uitkomst: uitkomst `in_zorg` kan gevolgd worden door plaatsing op een
+  behandelwachtlijst (apart wachtlijst-deelgebied), net zoals capaciteit bij
+  het acceptatiebesluit invoer is maar de besluituitkomst niet automatisch
+  bepaalt (Route 2A/2B-precedent). LKS 4.0 biedt hier geen aanknopingspunt,
+  dus dit blijft consistentie-redenering, geen LKS-citaat.
+
+**Bevoegdheid — LKS 4.0 maakt dit onderscheid expliciet zelf, verscherpt
+ten opzichte van de eerdere aanname van een simpele FK-placeholder:**
+
+- LKS 4.0 onderscheidt uitdrukkelijk "wie de intake verricht" van wie
+  bevoegd is de uitkomst vast te stellen (§2, fase 2) — dat kán dezelfde
+  persoon zijn, hoeft niet. De **regiebehandelaar in de indicerende rol**
+  is verantwoordelijk voor het (doen) vaststellen van de uitkomst
+  (§3.6.2). Bij vrijgevestigden (sectie II, §4.3) is dit altijd dezelfde
+  persoon als de intakebehandelaar; bij instellingen (sectie III) kan dat
+  uiteenlopen.
+- **MDT-bespreking is voor een deel van de settings een dwingende
+  landelijke norm, geen instellingsbeleid.** Voor settings 3 t/m 8
+  (multidisciplinair ambulant, outreachend, klinisch, forensisch,
+  hoogspecialistisch) schrijft LKS 4.0 Tabel 2 dwingend voor dat een
+  art. 14 BIG-beroep betrokken is bij diagnostiek/indicatiestelling **en**
+  bespreking plaatsvindt in het multidisciplinair team (MDT), met de
+  betrokken discipline als lid. Voor setting 2 (monodisciplinair ambulant)
+  is een MDT niet verplicht — direct contact, een MDT, of bilaterale
+  afstemming volstaan. Bij sectie II (vrijgevestigd) bestaat geen MDT,
+  alleen een professioneel netwerk voor advies/consultatie.
+- **Modelconsequentie:** bevoegdheid is niet één simpele FK naar een
+  persoon, maar minimaal een rol-attribuut (indicerende regiebehandelaar,
+  eventueel afwijkend van de intakebehandelaar) plus een optioneel,
+  settingafhankelijk MDT-feit — vergelijkbaar met hoe bij het
+  acceptatiebesluit beslisbevoegdheid al los van het besluit zelf is
+  gehouden (`decision_authority`). De exacte bevoegdheidsmatrix per setting
+  blijft een detail voor de rollenronde/bevoegdheidsmatrix (B16); wat hier
+  al vaststaat is dát het model ruimte moet bieden voor een optioneel
+  MDT-feit naast de indicerende regiebehandelaar, niet uitsluitend een
+  enkele beslisser.
+
+## 4. Voorlopige uniqueness- en optionaliteitsregels
+
+Deze regels zijn hypotheses voor domeinreview, geen definitieve
+cardinaliteiten.
+
+### Clinical Intake Assessment
+
+- Elke intake heeft één stabiele identiteit en hangt aan precies één
+  Clinical Care Episode.
+- Een episode kan nul, één of meerdere intakes hebben (regulier, intern,
+  crisis); "maximaal één lopende intake per episode" is een aan/uit-zetbare
+  bedrijfsregel, geen schemabeperking — een crisisintake kan naast een
+  lopende reguliere intake nodig zijn.
+- Elke intake heeft een aanleiding (regulier/intern/crisis) en een
+  afdeling.
+- Statussen: gepland → bezig → afgerond/afgebroken, met heropening
+  toegestaan vanuit afgerond of afgebroken. Niet toegestaan: rechtstreeks
+  gepland → afgerond (afronden zonder geregistreerd contact), of
+  afgerond ↔ afgebroken rechtstreeks.
+- Bij status afgerond hoort precies één (het laatst geldige, niet-vervangen)
+  Treatment Advice; bij status afgebroken hoort een afbreekreden, geen
+  Treatment Advice.
+
+### Intake Contact
+
+- Elk contact hoort bij precies één Clinical Intake Assessment.
+- Geen uniciteitsbeperking op type/datum-combinaties.
+
+### Child Safety Check
+
+- Maximaal één per Clinical Intake Assessment.
+- Uitvoerder en uitvoeringsdatum verplicht; per vlag is de toelichting
+  verplicht zodra die vlag "ja" is.
+
+### Treatment Advice
+
+- Elk advies hoort bij precies één Clinical Intake Assessment.
+- Elk advies heeft precies één uitkomst, één vaststeller en één
+  vaststellingsdatum.
+- Optioneel precies één eerder advies van dezelfde intake vervangen, met
+  verplichte reden — zelfde constructie als Care Acceptance Decision
+  (uniek per vervangen exemplaar, voorkomt vertakking, onbeperkte
+  kettingdiepte).
+- Geadviseerd zorgprogramma is verplicht bij uitkomst `in_zorg`, optioneel
+  anders.
+- Toelichting is verplicht bij `terugverwijzing`, `doorverwijzing` en
+  `extra_diagnostiek` (een ontvangende partij of vervolgstap moet
+  navolgbaar zijn); optioneel bij `in_zorg`.
+- Elk advies heeft precies één indicerende regiebehandelaar (kan dezelfde
+  persoon zijn als de intakebehandelaar, hoeft niet — LKS 4.0 §2/§3.6.2).
+  Optioneel, settingafhankelijk, een MDT-bespreking als apart feit
+  (deelnemers, datum) — voor settings 3 t/m 8 een verplicht feit, voor
+  setting 2 optioneel, voor sectie II (vrijgevestigd) niet van toepassing.
+  De exacte verplichtingsregel per setting is een detail voor de
+  bevoegdheidsronde (B16), niet voor deze feitenronde.
+
+## 5. Scenariotoets
+
+### Scenario 1 — reguliere intake, in zorg
+
+Benodigde objecten: één Clinical Intake Assessment (aanleiding regulier),
+minstens één Intake Contact, één Child Safety Check, één Treatment Advice
+met uitkomst `in_zorg`.
+
+Dit scenario toont de hoofdroute: acceptatie → (eventueel intakewachtlijst)
+→ intake → behandeladvies.
+
+### Scenario 2 — crisisintake zonder voorafgaande screening
+
+Benodigde objecten: één Clinical Intake Assessment met aanleiding `crisis`,
+gekoppeld aan een episode die is ontstaan uit een acceptatiebesluit of een
+Wvggz-mandaat (`feitenmodel-instroom.md` §3.5 Route 5/B27), zonder dat
+daaraan een screeningsactiviteit voorafging.
+
+Dit scenario toont dat screening vóór intake een nudge blijft, ook nu de
+volgorde acceptatie-vóór-intake vaststaat.
+
+### Scenario 3 — aanvullende diagnostiek en heroverweging
+
+Benodigde objecten: één Clinical Intake Assessment, een eerste Treatment
+Advice met uitkomst `extra_diagnostiek`, aanvullende Intake Contacten, en
+een tweede Treatment Advice dat het eerste vervangt met uitkomst `in_zorg`.
+
+Dit scenario toont dat het vervangt-patroon uit de instroomronde (B23)
+identiek toepasbaar is op het behandeladvies.
+
+### Scenario 4 — interne intake binnen een lopende episode
+
+Benodigde objecten: dezelfde Clinical Care Episode, een tweede Clinical
+Intake Assessment met aanleiding `intern` op een andere afdeling, eigen
+Intake Contacten en een eigen Treatment Advice.
+
+Dit scenario toont dat een episode meerdere, onafhankelijke intakes met elk
+hun eigen behandeladvies kan hebben.
+
+### Scenario 5 — kindcheck met positieve vlaggen
+
+Benodigde objecten: één Clinical Intake Assessment, één Child Safety Check
+met vlag "verantwoordelijk voor minderjarigen" = ja, verplichte toelichting,
+vlag "zorgen over veiligheid" = ja met verplichte toelichting, vlag "actie
+ondernomen" = ja met verplichte toelichting.
+
+Dit scenario toetst de conditionele verplichting van de toelichtingsvelden.
+
+## 6. Domeinreview
+
+**Beantwoord (domeinreview + gericht LKS 4.0-onderzoek, 19 juli 2026):**
+
+- Episode-timing gecorrigeerd: intake start ná het acceptatiebesluit, niet
+  gelijktijdig met een aanmelding-uitkomst die niet meer bestaat.
+- Behandeladvies-uitkomsten (`feitenmodel-instroom.md` §7 vraag 2, tot nu
+  toe geparkeerd): vier uitkomsten bevestigd (`in_zorg`, `terugverwijzing`,
+  `doorverwijzing`, `extra_diagnostiek`), hergebruikt uit het al bestaande
+  voorstel in `../deelmodellen/model-intake.md`, met een correctie na
+  volledige LKS 4.0-teksttoetsing: `doorverwijzing`/`terugverwijzing` zijn
+  LKS-genormeerd maar volgtijdelijk (eerst doorverwijzen proberen), niet
+  onafhankelijk; `extra_diagnostiek` is praktijkgefundeerd, niet
+  LKS-genormeerd — beide nuances zijn nu expliciet in §3.4 vastgelegd.
+- Behandeladvies is, net als het acceptatiebesluit, geen apart voorafgaand
+  advies — het object zelf geeft de vervolgrichting, met een vervangt-
+  mechanisme voor heroverweging.
+- Bevoegdheid: LKS 4.0 maakt zelf onderscheid tussen wie de intake verricht
+  en wie de uitkomst vaststelt (regiebehandelaar, indicerende rol). Voor
+  settings 3–8 is MDT-bespreking een dwingende landelijke norm, niet
+  instellingsbeleid; voor setting 2 optioneel; voor vrijgevestigden niet
+  van toepassing. Verwerkt als rol-attribuut plus optioneel MDT-feit in §4.
+
+**Nog open:**
+
+1. Exacte bevoegdheidsmatrix per setting (welke settings precies wanneer
+   MDT-bespreking vereisen, en de rolinvulling daarvan) — deel van de
+   bredere bevoegdheidsronde (B16); het principe (rol + optioneel MDT-feit)
+   staat al vast, de detailinvulling niet.
+2. Is `extra_diagnostiek` altijd een volledig nieuw, vervangend Treatment
+   Advice, of kan de bestaande intake simpelweg langer "bezig" blijven
+   zonder tussentijdse afronding? Beide patronen zijn nu toegestaan (zie
+   §3.1 N7 heropening); welke de praktijk het vaakst gebruikt is nog niet
+   getoetst.
+3. Vierde kindcheck-vlag (zwangerschap) is toegevoegd op basis van
+   algemene domeinkennis, niet uit de eerder verzamelde onderzoeksrapporten
+   — te verifiëren tegen de actuele meldcode-tekst.
+4. Contactmoment-generalisatie naar een bredere consult-/afspraakstructuur
+   blijft uitdrukkelijk een latere (agenda-)ronde.
+
+## 7. Volgende stap
+
+Na bevestiging van bovenstaande volgen:
+
+1. definitieve uniqueness- en optionaliteitsconstraints;
+2. afleiding van entiteiten en cardinaliteiten (`../deelmodellen/model-intake.md` her­zien
+   naar Engelse namen en de gecorrigeerde episode-relatie, analoog aan hoe
+   `../deelmodellen/model-instroom.md` uit `feitenmodel-instroom.md` is afgeleid);
+3. verwerking in `../besluiten/besluitenlog-datamodel-2026-07-18.md`;
+4. synchronisatie van `../begrippenlijst-kernmodel.md` (Treatment Advice,
+   Child Safety Check zijn nieuw; Clinical Intake Assessment/Intake Contact
+   bestonden al als werkterm) en `../deelmodellen/model-intake.md`.

docs/datamodel/onderzoek/onderzoek-engelstalige-epd-terminologie.md

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

docs/datamodel/onderzoek/onderzoek-leveranciers.md

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

docs/datamodel/onderzoek/onderzoek-rapportage.md

@@ -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/)

docs/datamodel/onderzoek/onderzoek-standaarden.md

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

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

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

docs/datamodel/sessielogs/sessielog-2026-07-19.md

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

docs/datamodel/sessielogs/sessielog-2026-07-19b.md

@@ -0,0 +1,266 @@
+# Sessielog datamodel — 19 juli 2026 (middag/avond)
+
+**Status:** chronologisch werkverslag
+**Doel:** context, redenering, correcties en voortgang van de sessie bewaren
+**Autoriteit:** dit sessielog is niet normatief; bevestigde besluiten staan al
+verwerkt in `../besluiten/besluitenlog-datamodel-2026-07-18.md` (B21-B34)
+**Vervolg:** bevoegdheidsronde (B16), statusmachines, definitieve
+uniqueness-/optionaliteitsconstraints
+
+## 1. Aanleiding
+
+Vervolg op `sessielog-2026-07-19.md` (ochtendronde). Deze sessie bestaat uit
+twee delen:
+
+1. afronding van de instroom-feitenronde: entiteiten/cardinaliteiten
+   afleiden, formaliseren in het besluitenlog, en de begrippenlijst en
+   `model-aanmelding.md` synchroniseren;
+2. een nieuwe, aparte feitenronde voor zorginhoudelijke intake en
+   behandeladvies, die ook vraag 2 uit `feitenmodel-instroom.md` §7
+   (behandeladvies-uitkomsten, sinds de ochtendronde geparkeerd) afsluit.
+
+Kort na de ochtendronde zijn eerst nog de resterende open vragen 3, 4 en 5
+uit `feitenmodel-instroom.md` §7 afgehandeld (zie §2). Daarna volgde een
+langere pauze; het werk aan entiteiten en de nieuwe feitenronde is
+'s middags/'s avonds gedaan.
+
+## 2. Afronding resterende instroomvragen (vraag 3, 4, 5)
+
+Direct aansluitend op de ochtendronde zijn drie openstaande punten uit
+`feitenmodel-instroom.md` §7 beantwoord:
+
+- **Aanvullende informatie nodig** wordt een gebeurtenisfeit, geen
+  besluituitkomst en geen statusfase — er bestaat op dat moment nog geen
+  besluit.
+- **Heroverweging na afwijzing** krijgt een expliciete "vervangt"-relatie
+  tussen acceptatiebesluiten, met verplichte reden en dezelfde
+  bevoegdheidseis als het origineel.
+- **Intrekking vóór start intake** krijgt twee routes: cliënt-intrekking
+  zonder bevoegdheidseis, en institutionele correctie met dezelfde
+  bevoegdheid als het origineel. In beide gevallen wordt een al ontstane
+  zorgepisode altijd afgesloten, nooit verwijderd.
+
+Referral Case krijgt daarmee een tijdlijn-gebaseerde stand in plaats van een
+vaste lineaire statusmachine. Alleen vraag 2 (behandeladvies-uitkomsten)
+bleef op dit moment nog open.
+
+## 3. Entiteiten en cardinaliteiten instroom
+
+`../deelmodellen/model-instroom.md` is toegevoegd: de eerste
+entiteiten-/cardinaliteitenafleiding uit `feitenmodel-instroom.md`. 20
+entiteiten, Engelstalig conform B20, met een vervangt-patroon voor
+herzieningen en een tijdlijn in plaats van een statusmachine voor Referral
+Case.
+
+Vier reviewrondes zijn verwerkt vóór het model als afgerond werd beschouwd:
+
+1. **Technische en GGZ-domeinreview** — vertakkende vervangt-keten gefixed
+   (uniek per vervangen exemplaar, geen boomstructuur), timestamp-precisie
+   gecorrigeerd, ontbrekende ZPM-velden hersteld.
+2. **Tweede ronde met datamodel-, GGZ-domein- en UX-expert-agents** — lege
+   screening-entiteit vervallen verklaard (screening is activiteit, geen
+   besluitobject — consistent met B21), naamgeving aangescherpt,
+   cardinaliteitsfout gecorrigeerd, een read-model-eis toegevoegd.
+3. **GGZ-wetgeving-onderzoek** (Wvggz, Wmo/Jeugdwet, 275-dagentoets,
+   365-dagenregel, crisisdocumentatie) vertaald naar nieuwe entiteiten:
+   `municipal_care_assignment`, `legal_mandate`, `crisis_encounter_note`.
+4. **Domeinreview eigenaarschap/urgentie met Colin** — een herhaalbare
+   urgentiebeoordeling (`case_urgency_assessment`, geen vast veld) en een
+   bewust minimale hook voor teambetrokkenheid
+   (`episode_team_involvement`); het volledige zorgteam-model blijft een
+   aparte, nog te plannen ronde (bevestigt B16).
+
+Ook is in `feitenmodel-instroom.md` de vraag "verzoek zonder bekende
+persoon" (crisisaanmelding) beantwoord: geen placeholder-persoon, de
+koppeling aan een persoon wordt een eigen, gedateerd feit dat pas ontstaat
+zodra de identiteit bekend is.
+
+## 4. Formalisering in het besluitenlog: B21-B30
+
+De uitkomst van de instroom-feitenronde en het entiteitenmodel is
+vastgelegd als B21-B30 in
+`../besluiten/besluitenlog-datamodel-2026-07-18.md`:
+
+| # | Kern |
+|---|------|
+| B21 | Screeningsbesluit = acceptatiebesluit, geen apart voorafgaand advies |
+| B22 | Besluituitkomst (`geaccepteerd`/`afgewezen`), vervolgroute en onderbouwing zijn losse feiten; elk positief besluit laat een episode ontstaan, ook bij vervolgroute intakewachtlijst |
+| B23 | Herziening via expliciete, unieke vervangt-relatie met verplichte reden en gelijke bevoegdheidseis |
+| B24 | Cliënt-intrekking vereist geen beslisbevoegdheid; een ontstane episode wordt altijd afgesloten, nooit verwijderd |
+| B25 | Geen statusmachine — actuele stand afgeleid uit een gebeurtenistijdlijn (aansluitend bij B7) |
+| B26 | Zorgverzoek kan zonder bekende persoon bestaan; koppeling is een eigen, gedateerd feit |
+| B27 | Wmo/Jeugdwet-toewijzing en Wvggz-mandaat zijn eigen instroomroutes naast de professionele verwijzing |
+| B28 | Gestructureerde crisisdocumentatie kan vóór identificatie al vastgelegd worden |
+| B29 | Urgentie is een herhaalbare beoordeling, geen vast veld |
+| B30 | Minimale hook voor teambetrokkenheid; het volledige zorgteam-model blijft een aparte ronde |
+
+Ook §10 van het besluitenlog is bijgewerkt: afgeronde punten gemarkeerd,
+de juridische verificatie- en behandeladvies-onderzoekspunten toegevoegd,
+en genoteerd dat het AANMELDING/VERWIJZING/ZORGEPISODE-deel van
+`model-aanmelding.md` is vervangen door `model-instroom.md`
+(synchronisatie als eerstvolgende stap).
+
+## 5. Synchronisatie begrippenlijst en model-aanmelding
+
+`../begrippenlijst-kernmodel.md` §3 vervangt de voorlopige werktermen
+(Inbound Care Signal, Access Assessment Case, Presenting Care Need,
+Screening Recommendation) door de bevestigde instroom-begrippen: Referral
+Request/Submission/Case, Professional/Municipal Referral, Legal Mandate,
+Case Information Request/Withdrawal, Crisis Encounter Note, Case Urgency
+Assessment. §10 bijgewerkt: opgeloste terminologievragen gemarkeerd,
+Wvggz/Wmo-Jeugdwet-aannames toegevoegd als nieuw juridisch te bevestigen
+punt.
+
+`../deelmodellen/model-aanmelding.md`: AANMELDING/VERWIJZING/
+VERWIJSDOCUMENT/TOEWIJZING/ZORGEPISODE (§2.10-§2.13, §2.15)
+niet-destructief gemarkeerd als vervallen met verwijzing naar de
+vervangende entiteit in `model-instroom.md` — de tekst blijft als
+historisch werkdocument staan, consistent met het niet-destructieve
+patroon dat elders in het datamodel wordt toegepast.
+PERSOON/CLIENT/CLIENTRELATIE/VERWIJZER/PRAKTIJK_INSTELLING/
+CLIENT_HUISARTS/VERZEKERING/TOESTEMMING/CLIENTPORTAAL_ACCOUNT
+(§2.1-§2.9, §2.14, §2.16) blijven ongewijzigd en behouden hun
+sectienummers, waar `model-instroom.md` extern naar verwijst.
+
+Ook zijn twee foutieve padverwijzingen in `model-instroom.md` §4
+gecorrigeerd (waardelijsten verwezen naar de verkeerde sectie in
+`model-aanmelding.md`).
+
+## 6. Nieuwe feitenronde: intake en behandeladvies
+
+Na afronding van de instroomronde is direct doorgewerkt aan een nieuwe
+FCO-IM-feitenronde voor de zorginhoudelijke intake. Als werkdocument is
+`../feitenmodellen/feitenmodel-intake-behandeladvies.md` opgesteld, met
+feitzinnen, scenariotoetsen en domeinreview voor Clinical Intake
+Assessment, Intake Contact, Child Safety Check en Treatment Advice.
+
+### 6.1 Episode-timing gecorrigeerd
+
+De intake hangt aan de zorgepisode, niet aan het aanmeldingstraject, en
+start op enig moment ná het acceptatiebesluit dat de episode liet
+ontstaan — mogelijk pas na een periode op de intakewachtlijst. Dit trekt
+de consequentie door van B22 (episode ontstaat al bij acceptatie, niet bij
+een aanmelding-uitkomst "intake" die niet meer bestaat) voor de intake
+zelf.
+
+### 6.2 Behandeladvies als eigen object
+
+Net als bij het acceptatiebesluit (B21) bestaat er geen apart, voorafgaand
+behandeladvies naast een later formeel besluit: het behandeladvies zelf
+draagt de uitkomst en de vervolgrichting. Het krijgt wel een eigen
+identiteit los van de intake (Treatment Advice), naar het patroon van Care
+Acceptance Decision. Een behandeladvies kan een eerder advies van dezelfde
+intake vervangen bij heroverweging, met dezelfde vervangt-constructie als
+bij herziening van het acceptatiebesluit (B23).
+
+Dit sluit `feitenmodel-instroom.md` §7 vraag 2 af, die sinds de
+ochtendronde geparkeerd stond.
+
+### 6.3 Vier behandeladvies-uitkomsten
+
+Op basis van volledige LKS 4.0-teksttoetsing (niet alleen samenvattingen):
+
+- Vier uitkomsten: `in_zorg`, `terugverwijzing`, `doorverwijzing`,
+  `extra_diagnostiek`.
+- `Doorverwijzing` en `terugverwijzing` zijn volgens LKS 4.0 (patient
+  journey fase 2-3, §3.6.2) een **volgtijdelijk paar** — eerst een
+  inspanningsverplichting tot doorverwijzing, pas daarna terugverwijzing —
+  geen twee gelijkwaardige, onafhankelijke uitkomsten. De volgorde wordt
+  gedekt door het vervangt-mechanisme uit §6.2, niet door een aparte
+  sequentie-regel.
+- `Extra_diagnostiek` is praktijkgefundeerd, nergens in LKS 4.0 als
+  zodanig benoemd — bewust behouden, maar expliciet gemarkeerd als
+  praktijkkeuze, geen landelijke norm.
+- Gedeeld/onduidelijk advies bij twijfel tussen behandelaren krijgt geen
+  eigen uitkomstwaarde: LKS 4.0 §3.6.2 lost dit institutioneel op.
+- Een cliënt die afziet van het geadviseerde vervolg is een later, apart
+  feit, geen behandeladvies-uitkomst (analoog aan planakkoord, B13).
+- Wachtlijst voor behandelcapaciteit is een vervolgroute na `in_zorg`,
+  zelfde precedent als bij het acceptatiebesluit.
+
+### 6.4 Bevoegdheid en MDT-bespreking
+
+LKS 4.0 maakt onderscheid tussen wie de intake verricht en wie de uitkomst
+vaststelt (regiebehandelaar, indicerende rol). Voor settings 3-8 is
+MDT-bespreking een **dwingende landelijke norm** (LKS 4.0 Tabel 2), niet
+instellingsbeleid; voor setting 2 optioneel; voor vrijgevestigden niet van
+toepassing. Verwerkt als rol-attribuut plus een optionele MDT-hook
+(`intake_mdt_review`) — de precieze verplichtingsregel per setting hoort
+bij de bredere bevoegdheidsronde (B16) en vereist een setting-registratie
+die nu nog niet bestaat.
+
+### 6.5 Kindcheck-structuur
+
+De bestaande prototypestructuur (drie ja/nee-vlaggen met verplichte
+toelichting bij "ja") blijft de kern, met vlag 1 verbreed van
+"thuiswonende kinderen" naar "verantwoordelijk voor minderjarigen"
+(KNMG-meldcode: ook co-ouderschap en andere zorgrelaties tellen). Een
+vierde vlag ("zwangerschap van cliënt of partner") is toegevoegd — de
+KNMG-kindcheck rekent het ongeboren kind expliciet mee. Deze vierde vlag
+is op basis van algemene domeinkennis toegevoegd, niet uit eerder
+verzamelde onderzoeksrapporten, en moet nog tegen de actuele
+meldcode-tekst geverifieerd worden.
+
+## 7. Nieuwe entiteiten en besluiten B31-B34
+
+`../deelmodellen/model-intake-behandeladvies.md` is toegevoegd:
+entiteiten-/cardinaliteitenafleiding voor Clinical Intake Assessment,
+Intake Contact, Child Safety Check en Treatment Advice.
+
+In het besluitenlog vastgelegd:
+
+- **B31** — Intake hangt aan de zorgepisode, start ná het
+  acceptatiebesluit (§6.1).
+- **B32** — Behandeladvies is een eigen object dat de intake afrondt, geen
+  apart voorafgaand advies (§6.2).
+- **B33** — Vier behandeladvies-uitkomsten, deels LKS-genormeerd (§6.3),
+  met de bevoegdheidsmatrix-vraag doorverwezen naar B16 (§6.4).
+- **B34** — Kindcheck-structuur bevestigd, vierde vlag toegevoegd (§6.5).
+
+`../begrippenlijst-kernmodel.md` §4 is gesynchroniseerd (Treatment Advice
+en Child Safety Check zijn nieuwe begrippen; Clinical Intake Assessment en
+Intake Contact bestonden al als werkterm). Het oudere
+`../deelmodellen/model-intake.md` is niet-destructief gemarkeerd als
+vervangen, consistent met hoe `model-aanmelding.md` eerder is behandeld.
+
+## 8. Open punten
+
+### Instroom
+
+Vrijwel volledig afgerond via B21-B30; het enige resterende punt is de
+bevoegdheidsmatrix (zie hieronder, gedeeld met intake/behandeladvies).
+
+### Intake en behandeladvies
+
+1. Exacte bevoegdheidsmatrix per setting (welke settings precies wanneer
+   MDT-bespreking vereisen, en de rolinvulling daarvan) — deel van de
+   bredere bevoegdheidsronde (B16); het principe (rol + optioneel
+   MDT-feit) staat al vast, de detailinvulling niet.
+2. Is `extra_diagnostiek` altijd een volledig nieuw, vervangend Treatment
+   Advice, of kan de bestaande intake simpelweg langer "bezig" blijven
+   zonder tussentijdse afronding? Beide patronen zijn nu toegestaan, welke
+   de praktijk het vaakst gebruikt is nog niet getoetst.
+3. Vierde kindcheck-vlag (zwangerschap) nog te verifiëren tegen de actuele
+   meldcode-tekst.
+4. Contactmoment-generalisatie naar een bredere consult-/afspraakstructuur
+   blijft uitdrukkelijk een latere (agenda-)ronde.
+
+### Nog niet opgepakt (aansluitend, uit eerdere sessies)
+
+- Het volledige zorgteam-model (leden, rollen, regiebehandelaarschap,
+  bevoegdheid, mogelijk toekomstige cliëntautorisatie) — bevestigd als
+  aparte ronde in B30.
+- Definitieve statusmachines waar die nog ontbreken.
+
+## 9. Afgesproken volgende stap
+
+1. Definitieve uniqueness- en optionaliteitsconstraints voor zowel
+   instroom als intake/behandeladvies.
+2. Bevoegdheidsronde (B16): setting-registratie en de volledige
+   bevoegdheidsmatrix (MDT-bespreking, regiebehandelaarschap, indicerende
+   rol).
+3. Verificatie van de vierde kindcheck-vlag tegen de actuele
+   meldcode-tekst.
+4. Beslissen of `extra_diagnostiek` altijd een vervangend Treatment Advice
+   vereist, op basis van praktijktoetsing.
+5. Zorgteam-model als aparte ronde plannen (B30).

docs/sessions/2026-07-17-sessielog.md

@@ -0,0 +1,64 @@
+# 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)
+
+1. Wanneer ontstaat de ZORGEPISODE precies — bij uitkomst "intake" of al bij "wachtlijst"?
+2. Verhouding screeningsbesluit ↔ aanmelding-uitkomst: één feit of twee?
+3. Behandelplan: statusmachine (cliëntakkoord als status of feit, WGBO), versiebeheer-vorm, verplicht-vóór-behandeling als nudge of eis.
+4. "Max één hoofddiagnose" — per episode of per moment in de tijd?
+5. DSM-ICD-mappingtabel: bron en onderhoud (APA-licentie) — vóór de schema-baseline.
+6. Startlijsten bevestigen: afdelingen, zorgprogramma's, AGB-verplichting per verwijzertype, beëindigingsredenen wachtlijst, intake-uitkomsten.
+7. Wie mag statussen zetten / diagnose stellen / intake afronden → rollen- en disciplinesronde.
+
+## 5. Vervolgstappen
+
+1. Entiteitenkaart reviewen (Colin) — met name kardinaliteiten en de aannames in de "Openstaand"-blokken.
+2. Statussen + eigenaarschap ECD/TIP per entiteit vastleggen (§6 stap 3).
+3. Latere rondes: agenda, rapportage & overdracht, rollen/disciplines, declaratie.
+4. 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`

supabase/migrations/20260720000001_create_reference_data.sql

@@ -0,0 +1,293 @@
+-- ============================================================================
+-- REFERENCE DATA (WAARDELIJSTEN) — instroom / intake / behandeladvies
+-- ============================================================================
+-- Created: 2026-07-20
+-- Purpose: shared reference-list table for the redesigned instroom/intake/
+--   behandeladvies domain (docs/datamodel/deelmodellen/model-instroom.md,
+--   model-intake-behandeladvies.md, model-aanmelding.md §4).
+--
+-- Design note: spelregel 3.1 #1 ("elke waardelijst is een referentietabel")
+-- is honoured with ONE shared, generic table (list_name-discriminated)
+-- instead of ~30 near-identical single-purpose tables. Each row still
+-- carries code/label/external_code/code_system/geldig_van/geldig_tot/actief.
+-- List-specific extra attributes (agb_verplicht, verwijsnudge_severity, ...)
+-- live in `extra` (JSONB) rather than one-off columns.
+--
+-- Scope note: this migration and the ones that follow (create_person_client_
+-- domain, create_referral_domain, create_intake_treatment_advice_domain)
+-- implement the REDESIGNED target schema from the 19-20 juli 2026 FCO-IM
+-- rounds. They are new, additive tables — the existing prototype tables
+-- (patients, screenings, intakes, patients.is_john_doe, intakes.kindcheck_data)
+-- are intentionally left untouched. Wiring the live app to this schema, and
+-- migrating prototype data into it, is a separate follow-up decision.
+-- ============================================================================
+
+CREATE TABLE value_list_item (
+  list_name     TEXT NOT NULL,
+  code          TEXT NOT NULL,
+  label         TEXT NOT NULL,
+  external_code TEXT,
+  code_system   TEXT,
+  extra         JSONB NOT NULL DEFAULT '{}'::jsonb,
+  valid_from    DATE,
+  valid_to      DATE,
+  active        BOOLEAN NOT NULL DEFAULT true,
+  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
+
+  PRIMARY KEY (list_name, code)
+);
+
+CREATE INDEX idx_value_list_item_list_active ON value_list_item(list_name, active);
+
+COMMENT ON TABLE value_list_item IS 'Generieke waardelijst-tabel (spelregel 3.1 #1): één rij per (list_name, code). Startlijsten, geen definitieve besluiten (zie modeldocumenten).';
+COMMENT ON COLUMN value_list_item.extra IS 'List-specifieke attributen, bv. agb_verplicht (verwijzertype), verwijsnudge_severity (wettelijk_kader).';
+
+ALTER TABLE value_list_item ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY "Enable read for authenticated users" ON value_list_item
+  FOR SELECT USING (auth.role() = 'authenticated');
+
+CREATE TRIGGER update_value_list_item_updated_at
+  BEFORE UPDATE ON value_list_item
+  FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- Seed data — startlijsten uit de modeldocumenten, geen definitieve besluiten
+-- ============================================================================
+
+INSERT INTO value_list_item (list_name, code, label, extra) VALUES
+-- geslacht (model-aanmelding.md §4.1) — externe code: HL7 AdministrativeGender
+('geslacht', 'man', 'Man', '{}'),
+('geslacht', 'vrouw', 'Vrouw', '{}'),
+('geslacht', 'anders', 'Anders', '{}'),
+('geslacht', 'onbekend', 'Onbekend', '{}'),
+
+-- genderidentiteit (zib Patient v4.3)
+('genderidentiteit', 'man', 'Man', '{}'),
+('genderidentiteit', 'vrouw', 'Vrouw', '{}'),
+('genderidentiteit', 'non_binair', 'Non-binair', '{}'),
+('genderidentiteit', 'anders', 'Anders', '{}'),
+('genderidentiteit', 'zegt_het_niet', 'Zegt het niet', '{}'),
+
+-- adrestype
+('adrestype', 'woonadres', 'Woonadres', '{}'),
+('adrestype', 'postadres', 'Postadres', '{}'),
+('adrestype', 'tijdelijk_verblijf', 'Tijdelijk verblijf', '{}'),
+
+-- contactgegeven_type
+('contactgegeven_type', 'telefoon', 'Telefoon', '{}'),
+('contactgegeven_type', 'email', 'E-mail', '{}'),
+
+-- contactgegeven_soort
+('contactgegeven_soort', 'mobiel_prive', 'Mobiel privé', '{}'),
+('contactgegeven_soort', 'vast_prive', 'Vast privé', '{}'),
+('contactgegeven_soort', 'werk', 'Werk', '{}'),
+('contactgegeven_soort', 'overig', 'Overig', '{}'),
+
+-- relatie
+('relatie', 'partner', 'Partner', '{}'),
+('relatie', 'ouder', 'Ouder', '{}'),
+('relatie', 'kind', 'Kind', '{}'),
+('relatie', 'broer_zus', 'Broer/zus', '{}'),
+('relatie', 'familielid_overig', 'Familielid overig', '{}'),
+('relatie', 'vriend_kennis', 'Vriend/kennis', '{}'),
+('relatie', 'professional', 'Professional', '{}'),
+('relatie', 'overig', 'Overig', '{}'),
+
+-- relatierol (twee assen relatie x rol — zib Contactpersoon)
+('relatierol', 'eerste_contactpersoon', 'Eerste contactpersoon', '{}'),
+('relatierol', 'wettelijk_vertegenwoordiger', 'Wettelijk vertegenwoordiger', '{}'),
+('relatierol', 'gezaghebbende_ouder', 'Gezaghebbende ouder', '{}'),
+('relatierol', 'mantelzorger', 'Mantelzorger', '{}'),
+('relatierol', 'naaste', 'Naaste', '{}'),
+
+-- vertegenwoordigingsgrond (WGBO-volgorde)
+('vertegenwoordigingsgrond', 'curator', 'Curator', '{}'),
+('vertegenwoordigingsgrond', 'mentor', 'Mentor', '{}'),
+('vertegenwoordigingsgrond', 'schriftelijk_gemachtigde', 'Schriftelijk gemachtigde', '{}'),
+('vertegenwoordigingsgrond', 'ouder_voogd', 'Ouder/voogd', '{}'),
+('vertegenwoordigingsgrond', 'partner_familie', 'Partner/familie', '{}'),
+
+-- huisarts_situatie (voedt zpm_verwijstype 04/05)
+('huisarts_situatie', 'bekend', 'Bekend', '{}'),
+('huisarts_situatie', 'geen_huisarts', 'Geen huisarts', '{}'),
+('huisarts_situatie', 'geen_toestemming_correspondentie', 'Geen toestemming correspondentie', '{}'),
+('huisarts_situatie', 'onbekend', 'Onbekend', '{}'),
+
+-- verwijzertype (extra.agb_verplicht — discovery §5.0 besluit 3)
+('verwijzertype', 'huisarts', 'Huisarts', '{"agb_verplicht": true}'),
+('verwijzertype', 'medisch_specialist', 'Medisch specialist', '{"agb_verplicht": true}'),
+('verwijzertype', 'straatdokter', 'Straatdokter', '{"agb_verplicht": true}'),
+('verwijzertype', 'bedrijfsarts', 'Bedrijfsarts', '{"agb_verplicht": true}'),
+('verwijzertype', 'regiebehandelaar', 'Regiebehandelaar', '{"agb_verplicht": true}'),
+('verwijzertype', 'ggz_instelling', 'GGZ-instelling', '{"agb_verplicht": true}'),
+('verwijzertype', 'gemeente', 'Gemeente', '{"agb_verplicht": false}'),
+('verwijzertype', 'zelfaanmelding', 'Zelfaanmelding', '{"agb_verplicht": false}'),
+('verwijzertype', 'crisis', 'Crisis', '{"agb_verplicht": false}'),
+
+-- praktijk_soort
+('praktijk_soort', 'huisartsenpraktijk', 'Huisartsenpraktijk', '{}'),
+('praktijk_soort', 'ziekenhuis', 'Ziekenhuis', '{}'),
+('praktijk_soort', 'ggz_instelling', 'GGZ-instelling', '{}'),
+('praktijk_soort', 'gemeente', 'Gemeente', '{}'),
+('praktijk_soort', 'arbodienst', 'Arbodienst', '{}'),
+('praktijk_soort', 'overig', 'Overig', '{}'),
+
+-- wettelijk_kader (extra.verwijsnudge_severity — te bevestigen in de nudge-/declaratieronde; wvggz toegevoegd bij B27)
+('wettelijk_kader', 'zvw', 'Zorgverzekeringswet', '{"verwijsnudge_severity": "blokkade"}'),
+('wettelijk_kader', 'jeugdwet', 'Jeugdwet', '{"verwijsnudge_severity": "signaal"}'),
+('wettelijk_kader', 'wmo', 'Wmo', '{"verwijsnudge_severity": "signaal"}'),
+('wettelijk_kader', 'wlz', 'Wlz', '{"verwijsnudge_severity": "waarschuwing"}'),
+('wettelijk_kader', 'forensisch', 'Forensisch', '{"verwijsnudge_severity": "waarschuwing"}'),
+('wettelijk_kader', 'wvggz', 'Wvggz', '{"verwijsnudge_severity": null}'),
+
+-- submission_channel (was aanmeldkanaal — model-instroom.md §4)
+('submission_channel', 'zorgdomein', 'ZorgDomein', '{}'),
+('submission_channel', 'e_mail', 'E-mail', '{}'),
+('submission_channel', 'telefoon', 'Telefoon', '{}'),
+('submission_channel', 'portaal', 'Cliëntportaal', '{}'),
+('submission_channel', 'post', 'Post', '{}'),
+('submission_channel', 'overig', 'Overig', '{}'),
+
+-- document_type (model-instroom.md §4)
+('document_type', 'verwijsbrief', 'Verwijsbrief', '{}'),
+('document_type', 'diagnostische_aanvulling', 'Diagnostische aanvulling', '{}'),
+('document_type', 'beschikking', 'Beschikking', '{}'),
+('document_type', 'overig', 'Overig', '{}'),
+
+-- screening_activity_type
+('screening_activity_type', 'telefonisch_contact', 'Telefonisch contact', '{}'),
+('screening_activity_type', 'dossieronderzoek', 'Dossieronderzoek', '{}'),
+('screening_activity_type', 'vragenlijst', 'Vragenlijst', '{}'),
+('screening_activity_type', 'overig', 'Overig', '{}'),
+
+-- decision_outcome (B22)
+('decision_outcome', 'geaccepteerd', 'Geaccepteerd', '{}'),
+('decision_outcome', 'afgewezen', 'Afgewezen', '{}'),
+
+-- follow_up_route
+('follow_up_route', 'intake_direct', 'Intake direct plannen', '{}'),
+('follow_up_route', 'intakewachtlijst', 'Intakewachtlijst', '{}'),
+('follow_up_route', 'spoedroute', 'Spoedroute', '{}'),
+('follow_up_route', 'doorverwijzen', 'Doorverwijzen', '{}'),
+('follow_up_route', 'case_afsluiten', 'Case afsluiten', '{}'),
+
+-- episode_end_reason (model-aanmelding.md §4.24 + B24-aanvullingen)
+('episode_end_reason', 'ingetrokken_door_client', 'Ingetrokken door cliënt', '{}'),
+('episode_end_reason', 'acceptatiebesluit_herzien', 'Acceptatiebesluit herzien', '{}'),
+('episode_end_reason', 'behandeling_afgerond', 'Behandeling afgerond', '{}'),
+('episode_end_reason', 'doorverwezen', 'Doorverwezen', '{}'),
+('episode_end_reason', 'client_beeindigt', 'Cliënt beëindigt', '{}'),
+('episode_end_reason', 'geen_contact', 'Geen contact meer', '{}'),
+('episode_end_reason', 'overleden', 'Overleden', '{}'),
+('episode_end_reason', 'overig', 'Overig', '{}'),
+
+-- echelon
+('echelon', 'gb_ggz', 'Generalistische basis-ggz', '{}'),
+('echelon', 'g_ggz', 'Gespecialiseerde ggz', '{}'),
+('echelon', 'onbekend', 'Onbekend', '{}'),
+
+-- zpm_verwijstype (Vektis/ZPM-code als external_code)
+('zpm_verwijstype', '01', 'Verwijzing aanwezig', '{}'),
+('zpm_verwijstype', '02', 'Doorverwijzing regiebehandelaar', '{}'),
+('zpm_verwijstype', '03', 'Geen verwijzing, verlate correspondentie', '{}'),
+('zpm_verwijstype', '04', 'Geen verwijzing, correspondentie niet toegestaan', '{}'),
+('zpm_verwijstype', '05', 'Geen verwijzing, niet declarabel', '{}'),
+('zpm_verwijstype', '06', 'Geen verwijzing, andere grond fz', '{}'),
+('zpm_verwijstype', '07', 'Verwijzing zonder AGB', '{}'),
+
+-- municipal_legal_framework (B27)
+('municipal_legal_framework', 'wmo', 'Wmo', '{}'),
+('municipal_legal_framework', 'jeugdwet', 'Jeugdwet', '{}'),
+
+-- municipal_product_category / municipal_product_unit — minimale startwaarden (declaratie-ronde volgt)
+('municipal_product_category', 'overig', 'Overig (nader te bepalen)', '{}'),
+('municipal_product_unit', 'overig', 'Overig (nader te bepalen)', '{}'),
+
+-- mandate_type / mandate_decider_role (B27, Wvggz)
+('mandate_type', 'crisismaatregel', 'Crisismaatregel', '{}'),
+('mandate_type', 'zorgmachtiging', 'Zorgmachtiging', '{}'),
+('mandate_decider_role', 'burgemeester', 'Burgemeester', '{}'),
+('mandate_decider_role', 'rechter', 'Rechter', '{}'),
+
+-- crisis_fact_type
+('crisis_fact_type', 'medicatie_toegediend', 'Medicatie toegediend', '{}'),
+('crisis_fact_type', 'risico_inschatting', 'Risico-inschatting', '{}'),
+('crisis_fact_type', 'vitale_functie', 'Vitale functie', '{}'),
+('crisis_fact_type', 'dwangmaatregel', 'Dwangmaatregel', '{}'),
+('crisis_fact_type', 'overig', 'Overig', '{}'),
+
+-- urgency_assessor_role / urgency_level
+('urgency_assessor_role', 'screener', 'Screener', '{}'),
+('urgency_assessor_role', 'triagist', 'Triagist', '{}'),
+('urgency_assessor_role', 'intake_team', 'Intake-team', '{}'),
+('urgency_assessor_role', 'mdo', 'MDO', '{}'),
+('urgency_level', 'laag', 'Laag', '{}'),
+('urgency_level', 'normaal', 'Normaal', '{}'),
+('urgency_level', 'hoog', 'Hoog', '{}'),
+('urgency_level', 'spoed', 'Spoed', '{}'),
+
+-- initiator_type
+('initiator_type', 'professional', 'Professional', '{}'),
+('initiator_type', 'organisatie', 'Organisatie', '{}'),
+('initiator_type', 'client', 'Cliënt', '{}'),
+('initiator_type', 'vertegenwoordiger', 'Vertegenwoordiger', '{}'),
+
+-- intake_initiation_reason
+('intake_initiation_reason', 'regulier', 'Regulier', '{}'),
+('intake_initiation_reason', 'intern', 'Intern', '{}'),
+('intake_initiation_reason', 'crisis', 'Crisis', '{}'),
+
+-- intake_status
+('intake_status', 'gepland', 'Gepland', '{}'),
+('intake_status', 'bezig', 'Bezig', '{}'),
+('intake_status', 'afgerond', 'Afgerond', '{}'),
+('intake_status', 'afgebroken', 'Afgebroken', '{}'),
+
+-- intake_abort_reason
+('intake_abort_reason', 'client_trekt_terug', 'Cliënt trekt zich terug', '{}'),
+('intake_abort_reason', 'geen_contact_meer', 'Geen contact meer', '{}'),
+('intake_abort_reason', 'overleden', 'Overleden', '{}'),
+('intake_abort_reason', 'overig', 'Overig', '{}'),
+
+-- intake_contact_type
+('intake_contact_type', 'intakegesprek', 'Intakegesprek', '{}'),
+('intake_contact_type', 'aanvullend_onderzoek', 'Aanvullend onderzoek', '{}'),
+('intake_contact_type', 'telefonisch_contact', 'Telefonisch contact', '{}'),
+('intake_contact_type', 'huisbezoek', 'Huisbezoek', '{}'),
+('intake_contact_type', 'beeldcontact', 'Beeldcontact', '{}'),
+('intake_contact_type', 'overig', 'Overig', '{}'),
+
+-- treatment_advice_outcome (B33 — doorverwijzing/terugverwijzing volgtijdelijk, extra_diagnostiek praktijkgefundeerd)
+('treatment_advice_outcome', 'in_zorg', 'In zorg', '{}'),
+('treatment_advice_outcome', 'terugverwijzing', 'Terugverwijzing', '{"lks_genormeerd": true, "volgt_op": "doorverwijzing"}'),
+('treatment_advice_outcome', 'doorverwijzing', 'Doorverwijzing', '{"lks_genormeerd": true}'),
+('treatment_advice_outcome', 'extra_diagnostiek', 'Extra diagnostiek', '{"lks_genormeerd": false}'),
+
+-- department / care_program — instellingsconfigureerbaar, minimale startwaarden
+('department', 'volwassenen', 'Volwassenen', '{}'),
+('department', 'jeugd', 'Jeugd', '{}'),
+('department', 'ouderen', 'Ouderen', '{}'),
+('department', 'forensisch', 'Forensisch', '{}'),
+('department', 'overig', 'Overig', '{}'),
+('care_program', 'algemeen_ggz', 'Algemeen GGZ', '{}'),
+('care_program', 'stemming', 'Stemming', '{}'),
+('care_program', 'trauma', 'Trauma', '{}'),
+('care_program', 'verslaving', 'Verslaving', '{}'),
+('care_program', 'overig', 'Overig', '{}'),
+
+-- toestemming_type (extra.grondslag)
+('toestemming_type', 'correspondentie_huisarts_verwijzer', 'Correspondentie huisarts/verwijzer', '{"grondslag": "WGBO/verwijsafspraken"}'),
+('toestemming_type', 'dsm_hoofdgroep_op_factuur', 'DSM-hoofdgroep op factuur', '{"grondslag": "Stcrt. 2025-11955, opt-in"}'),
+('toestemming_type', 'privacyverklaring_zorgvraagtypering', 'Privacyverklaring zorgvraagtypering', '{"grondslag": "NZa"}'),
+('toestemming_type', 'gegevensdeling_derden', 'Gegevensdeling derden', '{"grondslag": "AVG"}'),
+('toestemming_type', 'inzage_naasten', 'Inzage naasten', '{"grondslag": "WGBO"}'),
+
+-- toestemming_status / toestemming_wijze
+('toestemming_status', 'verleend', 'Verleend', '{}'),
+('toestemming_status', 'geweigerd', 'Geweigerd', '{}'),
+('toestemming_status', 'ingetrokken', 'Ingetrokken', '{}'),
+('toestemming_wijze', 'mondeling', 'Mondeling', '{}'),
+('toestemming_wijze', 'schriftelijk', 'Schriftelijk', '{}'),
+('toestemming_wijze', 'portaal', 'Portaal', '{}');

supabase/migrations/20260720000002_create_person_client_domain.sql

@@ -0,0 +1,349 @@
+-- ============================================================================
+-- PERSON / CLIENT DOMAIN
+-- ============================================================================
+-- Created: 2026-07-20
+-- Source: docs/datamodel/deelmodellen/model-aanmelding.md §2.1-2.9, §2.14, §2.16
+--   (PERSOON, ADRES, CONTACTGEGEVEN, CLIENT, CLIENTRELATIE, VERWIJZER,
+--    PRAKTIJK_INSTELLING, CLIENT_HUISARTS, VERZEKERING, TOESTEMMING,
+--    CLIENTPORTAAL_ACCOUNT) — the AANMELDING/VERWIJZING/ZORGEPISODE part of
+--    that document is superseded by the referral/intake domains that follow
+--    this migration, not translated here.
+--
+-- Naming: English identifiers per besluit B20. Dutch field names in the
+-- source document are translated 1:1 in meaning; nothing renamed to a
+-- different concept.
+--
+-- Privacy: raw BSN is never stored, only a SHA-256 hash (bsn_hash) — this
+-- follows the platform-wide privacy rule (root CLAUDE.md), which is a
+-- stricter requirement than the source document's "versleuteld (pgcrypto)"
+-- wording. Reversible BSN storage for declaratie/Vecozo purposes, if ever
+-- needed, is a separate, explicitly-scoped decision — not implemented here.
+-- ============================================================================
+
+CREATE EXTENSION IF NOT EXISTS pgcrypto;
+
+-- ============================================================================
+-- person
+-- ============================================================================
+CREATE TABLE person (
+  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  family_name       TEXT NOT NULL,
+  name_prefix       TEXT,
+  given_names       TEXT,
+  initials          TEXT,
+  preferred_name    TEXT,
+  birth_date        DATE NOT NULL,
+  gender            TEXT NOT NULL,           -- waardelijst geslacht
+  gender_identity   TEXT,                    -- waardelijst genderidentiteit
+  bsn_hash          TEXT,                    -- SHA-256, optioneel op PERSOON (rolgebonden eis via nudge)
+  deceased          BOOLEAN NOT NULL DEFAULT false,
+  deceased_at       DATE,
+
+  created_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at        TIMESTAMPTZ,
+
+  CONSTRAINT person_family_name_not_empty CHECK (length(trim(family_name)) > 0),
+  CONSTRAINT person_deceased_at_requires_flag CHECK (deceased_at IS NULL OR deceased)
+);
+
+CREATE UNIQUE INDEX idx_person_bsn_hash ON person(bsn_hash) WHERE bsn_hash IS NOT NULL AND deleted_at IS NULL;
+CREATE INDEX idx_person_name ON person(family_name, given_names) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE person IS 'Natuurlijke persoon, onafhankelijk van rollen (cliënt, contactpersoon, vertegenwoordiger, medewerker). model-aanmelding.md §2.1.';
+COMMENT ON COLUMN person.bsn_hash IS 'SHA-256 hash van het BSN; geen raw BSN opgeslagen (platform-privacyregel). Naam+geboortedatum-duplicaten zijn een nudge, geen constraint.';
+
+ALTER TABLE person ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON person FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_person_updated_at BEFORE UPDATE ON person FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- address
+-- ============================================================================
+CREATE TABLE address (
+  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  person_id     UUID NOT NULL REFERENCES person(id) ON DELETE CASCADE,
+  address_type  TEXT NOT NULL,               -- waardelijst adrestype
+  street        TEXT NOT NULL,
+  house_number  TEXT NOT NULL,
+  house_number_addition TEXT,
+  postal_code   TEXT NOT NULL,
+  city          TEXT NOT NULL,
+  country       TEXT NOT NULL DEFAULT 'NL',
+  valid_from    DATE,
+  valid_to      DATE,
+
+  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at    TIMESTAMPTZ
+);
+
+-- max één actueel (valid_to leeg) adres per persoon per adrestype
+CREATE UNIQUE INDEX idx_address_current_per_type ON address(person_id, address_type)
+  WHERE valid_to IS NULL AND deleted_at IS NULL;
+CREATE INDEX idx_address_person ON address(person_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE address IS 'model-aanmelding.md §2.2 — 0..n adressen per persoon (zib Patient).';
+
+ALTER TABLE address ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON address FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_address_updated_at BEFORE UPDATE ON address FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- contact_detail
+-- ============================================================================
+CREATE TABLE contact_detail (
+  id               UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  person_id        UUID NOT NULL REFERENCES person(id) ON DELETE CASCADE,
+  contact_type     TEXT NOT NULL,            -- waardelijst contactgegeven_type (telefoon/e-mail)
+  contact_subtype  TEXT,                     -- waardelijst contactgegeven_soort
+  value            TEXT NOT NULL,
+  is_preferred     BOOLEAN NOT NULL DEFAULT false,
+
+  created_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at       TIMESTAMPTZ
+);
+
+-- max één voorkeursgegeven per persoon per contacttype
+CREATE UNIQUE INDEX idx_contact_detail_preferred ON contact_detail(person_id, contact_type)
+  WHERE is_preferred AND deleted_at IS NULL;
+CREATE INDEX idx_contact_detail_person ON contact_detail(person_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE contact_detail IS 'model-aanmelding.md §2.3 — telefoonnummers en e-mailadressen per persoon.';
+
+ALTER TABLE contact_detail ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON contact_detail FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_contact_detail_updated_at BEFORE UPDATE ON contact_detail FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- client (rol op person)
+-- ============================================================================
+CREATE TABLE client (
+  id                 UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  person_id          UUID NOT NULL REFERENCES person(id) ON DELETE RESTRICT,
+  client_number      BIGINT NOT NULL,
+  client_since       DATE NOT NULL,
+  gp_situation       TEXT NOT NULL DEFAULT 'onbekend', -- waardelijst huisarts_situatie
+
+  created_at         TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at         TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at         TIMESTAMPTZ
+);
+
+-- max één CLIENT-rol per PERSOON
+CREATE UNIQUE INDEX idx_client_person ON client(person_id) WHERE deleted_at IS NULL;
+CREATE UNIQUE INDEX idx_client_number ON client(client_number) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE client IS 'model-aanmelding.md §2.4 — instellingsgebonden rol op PERSOON. Nudge (geen constraint): cliënt zonder bsn_hash (Wabvpz).';
+
+ALTER TABLE client ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON client FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_client_updated_at BEFORE UPDATE ON client FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- client_relation (contactpersoon / wettelijk vertegenwoordiger)
+-- ============================================================================
+CREATE TABLE client_relation (
+  id                        UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  client_id                 UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE,
+  person_id                 UUID NOT NULL REFERENCES person(id) ON DELETE RESTRICT,
+  relation_type              TEXT,            -- waardelijst relatie (partner, ouder, kind, ...)
+  relation_role              TEXT NOT NULL,   -- waardelijst relatierol
+  representation_basis       TEXT,            -- waardelijst vertegenwoordigingsgrond (alleen bij rol wettelijk_vertegenwoordiger)
+  valid_from                 DATE NOT NULL,
+  valid_to                   DATE,
+  notes                      TEXT,
+
+  created_at                 TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                 TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                 TIMESTAMPTZ
+);
+
+-- max één actuele rij per (client, persoon, rol)
+CREATE UNIQUE INDEX idx_client_relation_current ON client_relation(client_id, person_id, relation_role)
+  WHERE valid_to IS NULL AND deleted_at IS NULL;
+CREATE INDEX idx_client_relation_client ON client_relation(client_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE client_relation IS 'model-aanmelding.md §2.5 — contactpersonen/vertegenwoordigers, twee assen relatie x rol (zib Contactpersoon). Leeftijdsafhankelijke rechten (12/16 WGBO) zijn autorisatie, geen schema.';
+
+ALTER TABLE client_relation ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON client_relation FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_client_relation_updated_at BEFORE UPDATE ON client_relation FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- Zelfrelatie (persoon = cliënt-persoon) niet toegestaan. CHECK-constraints
+-- kunnen geen subquery bevatten in Postgres, dus dit is een trigger i.p.v.
+-- een CHECK — functioneel identiek aan wat model-aanmelding.md §2.5 vraagt.
+CREATE OR REPLACE FUNCTION prevent_client_relation_self_reference()
+RETURNS TRIGGER AS $$
+BEGIN
+  IF NEW.person_id = (SELECT person_id FROM client WHERE client.id = NEW.client_id) THEN
+    RAISE EXCEPTION 'client_relation: person_id mag niet gelijk zijn aan de cliënt-persoon zelf';
+  END IF;
+  RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER client_relation_no_self_reference
+  BEFORE INSERT OR UPDATE ON client_relation
+  FOR EACH ROW EXECUTE FUNCTION prevent_client_relation_self_reference();
+
+-- ============================================================================
+-- practice_organization (moet vóór referrer bestaan i.v.m. FK)
+-- ============================================================================
+CREATE TABLE practice_organization (
+  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  name          TEXT NOT NULL,
+  practice_type TEXT,                        -- waardelijst praktijk_soort
+  agb_code      TEXT,
+  address_text  TEXT,
+  phone         TEXT,
+
+  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at    TIMESTAMPTZ
+);
+
+CREATE UNIQUE INDEX idx_practice_organization_agb ON practice_organization(agb_code) WHERE agb_code IS NOT NULL AND deleted_at IS NULL;
+
+COMMENT ON TABLE practice_organization IS 'model-aanmelding.md §2.7 — organisatie waaraan verwijzers/huisartsen verbonden zijn.';
+
+ALTER TABLE practice_organization ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON practice_organization FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_practice_organization_updated_at BEFORE UPDATE ON practice_organization FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- referrer
+-- ============================================================================
+CREATE TABLE referrer (
+  id                      UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  name                    TEXT NOT NULL,
+  referrer_type           TEXT NOT NULL,     -- waardelijst verwijzertype (extra.agb_verplicht bepaalt nudge)
+  agb_code                TEXT,
+  practice_organization_id UUID REFERENCES practice_organization(id) ON DELETE SET NULL,
+  phone                   TEXT,
+  email                   TEXT,
+
+  created_at              TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at              TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at              TIMESTAMPTZ
+);
+
+CREATE UNIQUE INDEX idx_referrer_agb ON referrer(agb_code) WHERE agb_code IS NOT NULL AND deleted_at IS NULL;
+CREATE INDEX idx_referrer_practice ON referrer(practice_organization_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE referrer IS 'model-aanmelding.md §2.6 — persoon/functionaris die verwijst, los van practice_organization. Kan zonder praktijk bestaan (gemeente-ambtenaar). Ook referent voor de vaste huisarts.';
+
+ALTER TABLE referrer ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON referrer FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_referrer_updated_at BEFORE UPDATE ON referrer FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- client_general_practitioner (vaste huisarts)
+-- ============================================================================
+CREATE TABLE client_general_practitioner (
+  id                        UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  client_id                 UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE,
+  referrer_id                UUID REFERENCES referrer(id) ON DELETE SET NULL,
+  practice_organization_id   UUID REFERENCES practice_organization(id) ON DELETE SET NULL,
+  valid_from                 DATE NOT NULL,
+  valid_to                   DATE,
+
+  created_at                 TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                 TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                 TIMESTAMPTZ,
+
+  CONSTRAINT client_gp_at_least_one_ref CHECK (referrer_id IS NOT NULL OR practice_organization_id IS NOT NULL)
+);
+
+-- max één actuele registratie per cliënt
+CREATE UNIQUE INDEX idx_client_gp_current ON client_general_practitioner(client_id)
+  WHERE valid_to IS NULL AND deleted_at IS NULL;
+
+COMMENT ON TABLE client_general_practitioner IS 'model-aanmelding.md §2.8 — vaste huisarts, los van de incidentele verwijzer. "Geen huisarts"/"geen toestemming" staat op client.gp_situation, niet hier.';
+
+ALTER TABLE client_general_practitioner ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON client_general_practitioner FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_client_gp_updated_at BEFORE UPDATE ON client_general_practitioner FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- insurance
+-- ============================================================================
+CREATE TABLE insurance (
+  id                    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  client_id             UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE,
+  uzovi_code            TEXT NOT NULL,
+  insurer_name          TEXT,
+  policy_number         TEXT,
+  valid_from            DATE NOT NULL,
+  valid_to              DATE,
+  cov_checked_at        DATE,
+
+  created_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at            TIMESTAMPTZ
+);
+
+-- max één actuele verzekering per cliënt
+CREATE UNIQUE INDEX idx_insurance_current ON insurance(client_id) WHERE valid_to IS NULL AND deleted_at IS NULL;
+
+COMMENT ON TABLE insurance IS 'model-aanmelding.md §2.9 — Zvw-verzekeringsgegevens. Nudge: Zvw-aanmelding zonder actuele COV-controle. Wlz/forensisch: declaratie-ronde.';
+
+ALTER TABLE insurance ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON insurance FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_insurance_updated_at BEFORE UPDATE ON insurance FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- consent
+-- ============================================================================
+-- referral_case_id/clinical_care_episode_id FKs are added by later migrations
+-- (create_referral_domain, create_intake_treatment_advice_domain) once those
+-- tables exist — see ALTER TABLE at the bottom of create_referral_domain.
+CREATE TABLE consent (
+  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  client_id         UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE,
+  consent_type      TEXT NOT NULL,           -- waardelijst toestemming_type (extra.grondslag)
+  status            TEXT NOT NULL,           -- waardelijst toestemming_status
+  consent_date      DATE NOT NULL,
+  method            TEXT,                    -- waardelijst toestemming_wijze
+  recorded_by       UUID REFERENCES practitioners(id),
+  valid_to          DATE,
+  revoked_at        DATE,
+  scope_referral_case_id UUID,               -- optioneel; default cliëntbreed
+  notes             TEXT,
+
+  created_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at        TIMESTAMPTZ
+);
+
+-- max één actuele (niet-ingetrokken) rij per (client, type, scope)
+CREATE UNIQUE INDEX idx_consent_current ON consent(client_id, consent_type, COALESCE(scope_referral_case_id, '00000000-0000-0000-0000-000000000000'))
+  WHERE status <> 'ingetrokken' AND deleted_at IS NULL;
+CREATE INDEX idx_consent_client ON consent(client_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE consent IS 'model-aanmelding.md §2.14 — generieke WGBO/AVG-toestemming. Cliëntakkoord op het behandelplan is een apart feit bij het behandelplan, geen consent-rij. scope_referral_case_id FK volgt in create_referral_domain.sql.';
+
+ALTER TABLE consent ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON consent FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_consent_updated_at BEFORE UPDATE ON consent FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- client_portal_account
+-- ============================================================================
+CREATE TABLE client_portal_account (
+  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  client_id   UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE,
+
+  created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at  TIMESTAMPTZ
+);
+
+CREATE UNIQUE INDEX idx_client_portal_account_client ON client_portal_account(client_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE client_portal_account IS 'model-aanmelding.md §2.16 — relatie-placeholder (Wabvpz elektronische inzage). Authenticatiedetails: auth/ADM-ronde.';
+
+ALTER TABLE client_portal_account ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON client_portal_account FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_client_portal_account_updated_at BEFORE UPDATE ON client_portal_account FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();

supabase/migrations/20260720000003_create_referral_domain.sql

@@ -0,0 +1,567 @@
+-- ============================================================================
+-- REFERRAL / INSTROOM DOMAIN
+-- ============================================================================
+-- Created: 2026-07-20
+-- Source: docs/datamodel/deelmodellen/model-instroom.md (20 entiteiten),
+--   docs/datamodel/feitenmodellen/feitenmodel-instroom.md, besluiten B21-B30.
+--
+-- Design principles carried over from the model documents:
+-- - referral_case has NO status column — the current state is derived from
+--   the event timeline (signal_case_assignment/screening_activity/
+--   case_information_request/care_acceptance_decision/case_withdrawal/
+--   case_consolidation). See model-instroom.md §5. Application code (or a
+--   read-model view, per the UX review) computes "actuele stand", not this
+--   schema.
+-- - "vervangt"-relations (care_acceptance_decision, professional_referral,
+--   municipal_care_assignment) are enforced unique-if-set (partial unique
+--   index) so the chain can never fork.
+-- - `medewerker`/beslisser references point at the existing `practitioners`
+--   table (already used by the prototype screening/intake schema).
+-- - `decision_authority_id` on care_acceptance_decision is left nullable
+--   for now: the target table for decision authority does not exist yet
+--   (bevoegdheidsronde, B16/B33). The model calls it "verplicht"; enforcing
+--   NOT NULL today would make every insert impossible. Tighten once that
+--   ronde delivers a real authority table.
+-- ============================================================================
+
+-- ============================================================================
+-- referral_request
+-- ============================================================================
+CREATE TABLE referral_request (
+  id                    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  person_id             UUID REFERENCES person(id) ON DELETE RESTRICT,
+  person_identified_at  TIMESTAMPTZ,
+  person_identified_by  UUID REFERENCES practitioners(id),
+  initiated_at          TIMESTAMPTZ NOT NULL,
+  initiator_type        TEXT NOT NULL,             -- waardelijst initiator_type
+  referrer_id           UUID REFERENCES referrer(id),
+  requested_scope       TEXT NOT NULL,
+  presenting_need_text  TEXT NOT NULL,
+
+  created_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at            TIMESTAMPTZ,
+
+  CONSTRAINT referral_request_person_identification CHECK (
+    (person_id IS NULL AND person_identified_at IS NULL AND person_identified_by IS NULL)
+    OR (person_id IS NOT NULL AND person_identified_at IS NOT NULL AND person_identified_by IS NOT NULL)
+  )
+);
+
+COMMENT ON TABLE referral_request IS 'model-instroom.md §2.1. person_id optioneel: crisisaanmelding met onbekende identiteit (B26) — geen placeholder-persoon, de koppeling is een eigen feit.';
+
+ALTER TABLE referral_request ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON referral_request FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_referral_request_updated_at BEFORE UPDATE ON referral_request FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- referral_submission
+-- ============================================================================
+CREATE TABLE referral_submission (
+  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  received_at       TIMESTAMPTZ NOT NULL,
+  channel           TEXT NOT NULL,                 -- waardelijst submission_channel
+  source_reference  TEXT,                          -- vrije tekst of naam verwijzer; "onbekend" toegestaan
+  recorded_by       UUID REFERENCES practitioners(id),
+  raw_note          TEXT,
+
+  created_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at        TIMESTAMPTZ
+);
+
+COMMENT ON TABLE referral_submission IS 'model-instroom.md §2.2. Nooit overschreven door een latere aanvulling — een aanvulling is een nieuwe submission.';
+
+ALTER TABLE referral_submission ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON referral_submission FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_referral_submission_updated_at BEFORE UPDATE ON referral_submission FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- submission_document
+-- ============================================================================
+CREATE TABLE submission_document (
+  id                  UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  submission_id       UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE,
+  document_type       TEXT NOT NULL,                -- waardelijst document_type
+  document_reference  UUID NOT NULL,                -- documentopslag
+
+  created_at          TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at          TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at          TIMESTAMPTZ
+);
+
+CREATE INDEX idx_submission_document_submission ON submission_document(submission_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE submission_document IS 'model-instroom.md §2.3.';
+
+ALTER TABLE submission_document ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON submission_document FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_submission_document_updated_at BEFORE UPDATE ON submission_document FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- submission_request_link
+-- ============================================================================
+CREATE TABLE submission_request_link (
+  id                  UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  submission_id       UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE,
+  referral_request_id UUID NOT NULL REFERENCES referral_request(id) ON DELETE CASCADE,
+  established_at      TIMESTAMPTZ NOT NULL,
+
+  created_at          TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at          TIMESTAMPTZ,
+
+  UNIQUE (submission_id, referral_request_id)
+);
+
+CREATE INDEX idx_submission_request_link_request ON submission_request_link(referral_request_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE submission_request_link IS 'model-instroom.md §2.4. "representeert" vs "vult_aan" is niet opgeslagen — af te leiden als vroegste established_at per referral_request_id.';
+
+ALTER TABLE submission_request_link ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON submission_request_link FOR ALL USING (auth.role() = 'authenticated');
+
+-- ============================================================================
+-- submission_duplicate_assessment
+-- ============================================================================
+CREATE TABLE submission_duplicate_assessment (
+  id                          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  submission_id               UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE,
+  duplicate_of_submission_id  UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE,
+  assessed_by                 UUID NOT NULL REFERENCES practitioners(id),
+  assessed_at                 TIMESTAMPTZ NOT NULL,
+  reason                      TEXT NOT NULL,
+
+  created_at                  TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                  TIMESTAMPTZ,
+
+  CONSTRAINT submission_duplicate_not_self CHECK (submission_id <> duplicate_of_submission_id)
+);
+
+COMMENT ON TABLE submission_duplicate_assessment IS 'model-instroom.md §2.5. Niet-destructief: beide submissions blijven bestaan.';
+
+ALTER TABLE submission_duplicate_assessment ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON submission_duplicate_assessment FOR ALL USING (auth.role() = 'authenticated');
+
+-- ============================================================================
+-- referral_case
+-- ============================================================================
+CREATE TABLE referral_case (
+  id                        UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  person_id                 UUID REFERENCES person(id) ON DELETE RESTRICT,
+  person_identified_at      TIMESTAMPTZ,
+  person_identified_by      UUID REFERENCES practitioners(id),
+  opened_at                 TIMESTAMPTZ NOT NULL,
+  presenting_need_summary   TEXT NOT NULL,
+  legal_framework           TEXT NOT NULL,          -- waardelijst wettelijk_kader
+  zpm_referral_type         TEXT,                   -- waardelijst zpm_verwijstype
+  gp_informed_at            DATE,
+
+  created_at                TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                TIMESTAMPTZ,
+
+  CONSTRAINT referral_case_person_identification CHECK (
+    (person_id IS NULL AND person_identified_at IS NULL AND person_identified_by IS NULL)
+    OR (person_id IS NOT NULL AND person_identified_at IS NOT NULL AND person_identified_by IS NOT NULL)
+  )
+);
+
+COMMENT ON TABLE referral_case IS 'model-instroom.md §2.6. Geen statusveld — zie §5 aldaar en de opmerking bovenaan dit bestand. legal_framework/zpm_referral_type/gp_informed_at hersteld van het oudere AANMELDING (B21-B27).';
+
+ALTER TABLE referral_case ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON referral_case FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_referral_case_updated_at BEFORE UPDATE ON referral_case FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- Now that referral_case exists: wire the consent scope FK from the person/client migration
+ALTER TABLE consent
+  ADD CONSTRAINT consent_scope_referral_case_fk FOREIGN KEY (scope_referral_case_id) REFERENCES referral_case(id) ON DELETE SET NULL;
+
+-- ============================================================================
+-- submission_case_assignment
+-- ============================================================================
+CREATE TABLE submission_case_assignment (
+  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  submission_id     UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE,
+  referral_case_id  UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE,
+  assigned_at       TIMESTAMPTZ NOT NULL,
+  assigned_by       UUID NOT NULL REFERENCES practitioners(id),
+  reason            TEXT,
+
+  created_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at        TIMESTAMPTZ,
+
+  UNIQUE (submission_id, referral_case_id)
+);
+
+CREATE INDEX idx_submission_case_assignment_case ON submission_case_assignment(referral_case_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE submission_case_assignment IS 'model-instroom.md §2.7 (hernoemd van signal_case_assignment). Toewijzing is een gebeurtenis, geen overschrijfbaar veld.';
+
+ALTER TABLE submission_case_assignment ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON submission_case_assignment FOR ALL USING (auth.role() = 'authenticated');
+
+-- ============================================================================
+-- request_case_link
+-- ============================================================================
+CREATE TABLE request_case_link (
+  id                    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_request_id   UUID NOT NULL REFERENCES referral_request(id) ON DELETE CASCADE,
+  referral_case_id      UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE,
+  since_date            DATE NOT NULL,
+  reason                TEXT,
+
+  created_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at            TIMESTAMPTZ,
+
+  UNIQUE (referral_request_id, referral_case_id)
+);
+
+COMMENT ON TABLE request_case_link IS 'model-instroom.md §2.8. reason verplicht (applicatieniveau) zodra een request aan >1 case gekoppeld is.';
+
+ALTER TABLE request_case_link ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON request_case_link FOR ALL USING (auth.role() = 'authenticated');
+
+-- ============================================================================
+-- case_consolidation
+-- ============================================================================
+CREATE TABLE case_consolidation (
+  id                    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  primary_case_id       UUID NOT NULL REFERENCES referral_case(id) ON DELETE RESTRICT,
+  related_case_id       UUID NOT NULL REFERENCES referral_case(id) ON DELETE RESTRICT,
+  overlap_assessed_at   TIMESTAMPTZ,
+  designated_at         TIMESTAMPTZ NOT NULL,
+  designated_by         UUID NOT NULL REFERENCES practitioners(id),
+  reason                TEXT NOT NULL,
+
+  created_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at            TIMESTAMPTZ,
+
+  CONSTRAINT case_consolidation_no_self CHECK (primary_case_id <> related_case_id)
+);
+
+-- een case kan hoogstens één keer de niet-leidende rol vervullen
+CREATE UNIQUE INDEX idx_case_consolidation_related_unique ON case_consolidation(related_case_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE case_consolidation IS 'model-instroom.md §2.9 (hernoemd van access_case_consolidation). Geen speciale decision_authority vereist (administratieve correctie). Transitieve cykels niet uitgesloten op schemaniveau — applicatieverantwoordelijkheid.';
+
+ALTER TABLE case_consolidation ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON case_consolidation FOR ALL USING (auth.role() = 'authenticated');
+
+-- ============================================================================
+-- screening_activity
+-- ============================================================================
+CREATE TABLE screening_activity (
+  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_case_id  UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE,
+  performed_at      TIMESTAMPTZ NOT NULL,
+  activity_type     TEXT NOT NULL,          -- waardelijst screening_activity_type
+  performed_by      UUID NOT NULL REFERENCES practitioners(id),
+  notes             TEXT,
+  funded            BOOLEAN NOT NULL DEFAULT false,
+
+  created_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at        TIMESTAMPTZ
+);
+
+CREATE INDEX idx_screening_activity_case ON screening_activity(referral_case_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE screening_activity IS 'model-instroom.md §2.10. Directe koppeling aan referral_case — de aparte "screening"-groeperingsentiteit is vervallen (reviewronde 19 juli).';
+
+ALTER TABLE screening_activity ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON screening_activity FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_screening_activity_updated_at BEFORE UPDATE ON screening_activity FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- case_information_request
+-- ============================================================================
+CREATE TABLE case_information_request (
+  id                          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_case_id            UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE,
+  requested_at                TIMESTAMPTZ NOT NULL,
+  requested_by                UUID NOT NULL REFERENCES practitioners(id),
+  requested_information       TEXT NOT NULL,
+  resolved_by_submission_id   UUID REFERENCES referral_submission(id),
+
+  created_at                  TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                  TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                  TIMESTAMPTZ
+);
+
+CREATE UNIQUE INDEX idx_case_information_request_resolved_submission ON case_information_request(resolved_by_submission_id) WHERE resolved_by_submission_id IS NOT NULL AND deleted_at IS NULL;
+CREATE INDEX idx_case_information_request_case ON case_information_request(referral_case_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE case_information_request IS 'model-instroom.md §2.11. Geen besluituitkomst en geen statusfase (B21/vraag 5) — een gedateerd gebeurtenisfeit; kan zich ook ná een eerder besluit voordoen tijdens heroverweging.';
+
+ALTER TABLE case_information_request ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON case_information_request FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_case_information_request_updated_at BEFORE UPDATE ON case_information_request FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- care_acceptance_decision
+-- ============================================================================
+CREATE TABLE care_acceptance_decision (
+  id                     UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_case_id       UUID NOT NULL REFERENCES referral_case(id) ON DELETE RESTRICT,
+  decided_at             TIMESTAMPTZ NOT NULL,
+  decided_by             UUID NOT NULL REFERENCES practitioners(id),
+  decision_authority_id  UUID,                    -- ref decision_authority — tabel volgt uit bevoegdheidsronde (B16); tijdelijk geen FK/NOT NULL
+  content_match          BOOLEAN NOT NULL,
+  capacity_available     BOOLEAN,
+  program_context        TEXT,                    -- waardelijst care_program of vrije tekst
+  decision_outcome       TEXT NOT NULL,            -- waardelijst decision_outcome
+  follow_up_route        TEXT NOT NULL,            -- waardelijst follow_up_route
+  rationale              TEXT,
+  replaces_decision_id   UUID REFERENCES care_acceptance_decision(id),
+  replacement_reason     TEXT,
+
+  created_at             TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at             TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at             TIMESTAMPTZ,
+
+  CONSTRAINT care_acceptance_decision_outcome_check CHECK (decision_outcome IN ('geaccepteerd', 'afgewezen')),
+  CONSTRAINT care_acceptance_decision_rationale_required CHECK (
+    decision_outcome <> 'afgewezen' OR (rationale IS NOT NULL AND length(trim(rationale)) > 0)
+  ),
+  CONSTRAINT care_acceptance_decision_replacement_reason_required CHECK (
+    replaces_decision_id IS NULL OR (replacement_reason IS NOT NULL AND length(trim(replacement_reason)) > 0)
+  ),
+  CONSTRAINT care_acceptance_decision_no_self_replace CHECK (replaces_decision_id <> id)
+);
+
+-- vervangt-keten kan nooit vertakken (B23 / reviewronde 19 juli, kritieke bevinding)
+CREATE UNIQUE INDEX idx_care_acceptance_decision_replaces_unique ON care_acceptance_decision(replaces_decision_id) WHERE replaces_decision_id IS NOT NULL AND deleted_at IS NULL;
+CREATE INDEX idx_care_acceptance_decision_case ON care_acceptance_decision(referral_case_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE care_acceptance_decision IS 'model-instroom.md §2.12. Geen apart voorafgaand screeningsadvies (B21). Concurrency bij gelijktijdige heroverwegingen (SELECT ... FOR UPDATE op de keten-tail) is applicatieverantwoordelijkheid.';
+
+ALTER TABLE care_acceptance_decision ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON care_acceptance_decision FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_care_acceptance_decision_updated_at BEFORE UPDATE ON care_acceptance_decision FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- case_withdrawal
+-- ============================================================================
+CREATE TABLE case_withdrawal (
+  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_case_id  UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE,
+  withdrawn_at      TIMESTAMPTZ NOT NULL,
+  recorded_by       UUID NOT NULL REFERENCES practitioners(id),
+  note              TEXT,
+
+  created_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at        TIMESTAMPTZ
+);
+
+CREATE INDEX idx_case_withdrawal_case ON case_withdrawal(referral_case_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE case_withdrawal IS 'model-instroom.md §2.13. Geen beslisbevoegdheid vereist; kan op elk moment, ook ná een positief besluit (B24).';
+
+ALTER TABLE case_withdrawal ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON case_withdrawal FOR ALL USING (auth.role() = 'authenticated');
+
+-- ============================================================================
+-- professional_referral
+-- ============================================================================
+CREATE TABLE professional_referral (
+  id                    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_request_id   UUID NOT NULL REFERENCES referral_request(id) ON DELETE RESTRICT,
+  referrer_id           UUID NOT NULL REFERENCES referrer(id),
+  referral_date         DATE NOT NULL,
+  echelon               TEXT,                      -- waardelijst echelon
+  suspected_condition   TEXT,
+  is_readmission        BOOLEAN NOT NULL DEFAULT false,
+  replaces_referral_id  UUID REFERENCES professional_referral(id),
+  replacement_reason    TEXT,
+
+  created_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at            TIMESTAMPTZ,
+
+  CONSTRAINT professional_referral_replacement_reason_required CHECK (
+    replaces_referral_id IS NULL OR (replacement_reason IS NOT NULL AND length(trim(replacement_reason)) > 0)
+  ),
+  CONSTRAINT professional_referral_no_self_replace CHECK (replaces_referral_id <> id)
+);
+
+CREATE UNIQUE INDEX idx_professional_referral_replaces_unique ON professional_referral(replaces_referral_id) WHERE replaces_referral_id IS NOT NULL AND deleted_at IS NULL;
+CREATE INDEX idx_professional_referral_request ON professional_referral(referral_request_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE professional_referral IS 'model-instroom.md §2.14. Correctie/aanvulling = nieuw, vervangend record, geen nieuw request (was open punt 1, opgelost).';
+
+ALTER TABLE professional_referral ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON professional_referral FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_professional_referral_updated_at BEFORE UPDATE ON professional_referral FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- municipal_care_assignment
+-- ============================================================================
+CREATE TABLE municipal_care_assignment (
+  id                    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_request_id   UUID NOT NULL REFERENCES referral_request(id) ON DELETE RESTRICT,
+  legal_framework       TEXT NOT NULL,            -- waardelijst municipal_legal_framework
+  municipality_code     TEXT NOT NULL,
+  assignment_number     TEXT NOT NULL,
+  product_category      TEXT NOT NULL,            -- waardelijst municipal_product_category
+  product_code          TEXT NOT NULL,
+  volume                NUMERIC NOT NULL,
+  unit                  TEXT NOT NULL,            -- waardelijst municipal_product_unit
+  frequency             TEXT NOT NULL,
+  start_date            DATE NOT NULL,
+  end_date              DATE,
+  issued_at             TIMESTAMPTZ NOT NULL,
+  replaces_assignment_id UUID REFERENCES municipal_care_assignment(id),
+  replacement_reason    TEXT,
+
+  created_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at            TIMESTAMPTZ,
+
+  CONSTRAINT municipal_care_assignment_replacement_reason_required CHECK (
+    replaces_assignment_id IS NULL OR (replacement_reason IS NOT NULL AND length(trim(replacement_reason)) > 0)
+  ),
+  CONSTRAINT municipal_care_assignment_no_self_replace CHECK (replaces_assignment_id <> id)
+);
+
+CREATE UNIQUE INDEX idx_municipal_care_assignment_replaces_unique ON municipal_care_assignment(replaces_assignment_id) WHERE replaces_assignment_id IS NOT NULL AND deleted_at IS NULL;
+CREATE UNIQUE INDEX idx_municipal_care_assignment_number ON municipal_care_assignment(municipality_code, assignment_number) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE municipal_care_assignment IS 'model-instroom.md §2.15 (voorstel, juridisch onderzoek 19 juli). Naast, niet in plaats van professional_referral (Jeugdwet kent een eigen professionele verwijsroute).';
+
+ALTER TABLE municipal_care_assignment ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON municipal_care_assignment FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_municipal_care_assignment_updated_at BEFORE UPDATE ON municipal_care_assignment FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- legal_mandate
+-- ============================================================================
+CREATE TABLE legal_mandate (
+  id                            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_case_id              UUID NOT NULL REFERENCES referral_case(id) ON DELETE RESTRICT,
+  mandate_type                  TEXT NOT NULL,      -- waardelijst mandate_type
+  decision_reference            TEXT NOT NULL,
+  decided_by_role               TEXT NOT NULL,      -- waardelijst mandate_decider_role
+  decided_at                    TIMESTAMPTZ NOT NULL,
+  medical_statement_reference   UUID,               -- documentopslag
+  effectuated_at                TIMESTAMPTZ NOT NULL,
+  valid_from                    TIMESTAMPTZ NOT NULL,
+  valid_until                   TIMESTAMPTZ,
+
+  created_at                    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                    TIMESTAMPTZ,
+
+  CONSTRAINT legal_mandate_type_check CHECK (mandate_type IN ('crisismaatregel', 'zorgmachtiging')),
+  CONSTRAINT legal_mandate_medical_statement_required CHECK (
+    mandate_type <> 'crisismaatregel' OR medical_statement_reference IS NOT NULL
+  )
+);
+
+CREATE INDEX idx_legal_mandate_case ON legal_mandate(referral_case_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE legal_mandate IS 'model-instroom.md §2.16 (voorstel, juridisch onderzoek 19 juli). Geen vervangt-relatie: een crisismaatregel die overgaat in een zorgmachtiging is een nieuw mandaat.';
+
+ALTER TABLE legal_mandate ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON legal_mandate FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_legal_mandate_updated_at BEFORE UPDATE ON legal_mandate FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- crisis_encounter_note
+-- ============================================================================
+CREATE TABLE crisis_encounter_note (
+  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_case_id  UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE,
+  occurred_at       TIMESTAMPTZ NOT NULL,
+  recorded_by       UUID NOT NULL REFERENCES practitioners(id),
+  fact_type         TEXT NOT NULL,          -- waardelijst crisis_fact_type
+  description       TEXT NOT NULL,
+  structured_value  JSONB,
+
+  created_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at        TIMESTAMPTZ
+);
+
+CREATE INDEX idx_crisis_encounter_note_case ON crisis_encounter_note(referral_case_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE crisis_encounter_note IS 'model-instroom.md §2.17 (voorstel). Werkt al zonder geïdentificeerde persoon. 14-dagen-identificatienudge hangt aan referral_request.person_identified_at IS NULL, geen constraint hier.';
+
+ALTER TABLE crisis_encounter_note ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON crisis_encounter_note FOR ALL USING (auth.role() = 'authenticated');
+
+-- ============================================================================
+-- clinical_care_episode
+-- ============================================================================
+CREATE TABLE clinical_care_episode (
+  id                                    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  originating_decision_id               UUID REFERENCES care_acceptance_decision(id) ON DELETE RESTRICT,
+  originating_mandate_id                UUID REFERENCES legal_mandate(id) ON DELETE RESTRICT,
+  started_at                            TIMESTAMPTZ NOT NULL,
+  ended_at                              TIMESTAMPTZ,
+  end_reason                            TEXT,                -- waardelijst episode_end_reason
+  possible_continuation_of_episode_id   UUID REFERENCES clinical_care_episode(id),
+
+  created_at                            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                            TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                            TIMESTAMPTZ,
+
+  CONSTRAINT clinical_care_episode_origin_xor CHECK (
+    (originating_decision_id IS NOT NULL AND originating_mandate_id IS NULL)
+    OR (originating_decision_id IS NULL AND originating_mandate_id IS NOT NULL)
+  ),
+  CONSTRAINT clinical_care_episode_end_reason_required CHECK (
+    ended_at IS NULL OR end_reason IS NOT NULL
+  ),
+  CONSTRAINT clinical_care_episode_no_self_continuation CHECK (possible_continuation_of_episode_id <> id)
+);
+
+CREATE UNIQUE INDEX idx_clinical_care_episode_decision ON clinical_care_episode(originating_decision_id) WHERE originating_decision_id IS NOT NULL AND deleted_at IS NULL;
+CREATE UNIQUE INDEX idx_clinical_care_episode_mandate ON clinical_care_episode(originating_mandate_id) WHERE originating_mandate_id IS NOT NULL AND deleted_at IS NULL;
+
+COMMENT ON TABLE clinical_care_episode IS 'model-instroom.md §2.18 (alleen ontstaan/einde — volledig episodemodel is een ander deelgebied). XOR: ontstaat óf uit een acceptatiebesluit óf uit een mandaat. possible_continuation_of_episode_id is een zorginhoudelijke aanwijzing, GEEN NZa-trajectnummertoets.';
+
+ALTER TABLE clinical_care_episode ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON clinical_care_episode FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_clinical_care_episode_updated_at BEFORE UPDATE ON clinical_care_episode FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- case_urgency_assessment
+-- ============================================================================
+CREATE TABLE case_urgency_assessment (
+  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  referral_case_id  UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE,
+  assessed_at       TIMESTAMPTZ NOT NULL,
+  assessed_by       UUID NOT NULL REFERENCES practitioners(id),
+  assessed_in_role  TEXT NOT NULL,          -- waardelijst urgency_assessor_role
+  urgency_level     TEXT NOT NULL,          -- waardelijst urgency_level
+
+  created_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at        TIMESTAMPTZ
+);
+
+CREATE INDEX idx_case_urgency_assessment_case ON case_urgency_assessment(referral_case_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE case_urgency_assessment IS 'model-instroom.md §2.19. Herhaalbaar, laatste assessed_at geldt; geen vervangt-relatie (lagere inzet dan een acceptatiebesluit).';
+
+ALTER TABLE case_urgency_assessment ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON case_urgency_assessment FOR ALL USING (auth.role() = 'authenticated');
+
+-- ============================================================================
+-- episode_team_involvement (minimale, voorlopige hook — zie besluitenlog §10 punt 3)
+-- ============================================================================
+CREATE TABLE episode_team_involvement (
+  id                          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  clinical_care_episode_id    UUID NOT NULL REFERENCES clinical_care_episode(id) ON DELETE CASCADE,
+  team_reference              TEXT NOT NULL,     -- vrije tekst; geen Team-entiteit vóór de zorgteam-ronde
+  involved_since               TIMESTAMPTZ NOT NULL,
+  recorded_by                  UUID NOT NULL REFERENCES practitioners(id),
+
+  created_at                   TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                   TIMESTAMPTZ
+);
+
+CREATE INDEX idx_episode_team_involvement_episode ON episode_team_involvement(clinical_care_episode_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE episode_team_involvement IS 'model-instroom.md §2.20. Bewust minimaal — geen rollen, geen bevoegdheid, geen individueel lidmaatschap. Wordt vervangen/geabsorbeerd door het volledige zorgteam-model (besluitenlog §10 punt 3).';
+
+ALTER TABLE episode_team_involvement ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON episode_team_involvement FOR ALL USING (auth.role() = 'authenticated');

supabase/migrations/20260720000004_create_intake_treatment_advice_domain.sql

@@ -0,0 +1,178 @@
+-- ============================================================================
+-- INTAKE / TREATMENT ADVICE DOMAIN
+-- ============================================================================
+-- Created: 2026-07-20
+-- Source: docs/datamodel/deelmodellen/model-intake-behandeladvies.md (5
+--   entiteiten), docs/datamodel/feitenmodellen/feitenmodel-intake-behandeladvies.md,
+--   besluiten B31-B34.
+--
+-- clinical_intake_assessment hangs off clinical_care_episode (not off
+-- referral_case) — it starts at some point after the acceptance decision,
+-- possibly after a wait-list period (status = 'gepland' covers that).
+-- ============================================================================
+
+-- ============================================================================
+-- clinical_intake_assessment
+-- ============================================================================
+CREATE TABLE clinical_intake_assessment (
+  id                         UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  clinical_care_episode_id   UUID NOT NULL REFERENCES clinical_care_episode(id) ON DELETE RESTRICT,
+  initiation_reason          TEXT NOT NULL,        -- waardelijst intake_initiation_reason
+  department                 TEXT NOT NULL,        -- waardelijst department
+  status                     TEXT NOT NULL DEFAULT 'gepland', -- waardelijst intake_status
+  planned_at                 TIMESTAMPTZ NOT NULL,
+  started_at                 TIMESTAMPTZ,
+  ended_at                   TIMESTAMPTZ,
+  abort_reason               TEXT,                 -- waardelijst intake_abort_reason
+
+  created_at                 TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                 TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                 TIMESTAMPTZ,
+
+  CONSTRAINT clinical_intake_assessment_status_check CHECK (status IN ('gepland', 'bezig', 'afgerond', 'afgebroken')),
+  CONSTRAINT clinical_intake_assessment_started_required CHECK (
+    status NOT IN ('bezig', 'afgerond', 'afgebroken') OR started_at IS NOT NULL
+  ),
+  CONSTRAINT clinical_intake_assessment_ended_required CHECK (
+    status NOT IN ('afgerond', 'afgebroken') OR ended_at IS NOT NULL
+  ),
+  CONSTRAINT clinical_intake_assessment_abort_reason_required CHECK (
+    status <> 'afgebroken' OR abort_reason IS NOT NULL
+  )
+);
+
+CREATE INDEX idx_clinical_intake_assessment_episode ON clinical_intake_assessment(clinical_care_episode_id) WHERE deleted_at IS NULL;
+CREATE INDEX idx_clinical_intake_assessment_status ON clinical_intake_assessment(status) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE clinical_intake_assessment IS 'model-intake-behandeladvies.md §1.1. Start ná het acceptatiebesluit (B31), niet gelijktijdig met episode-ontstaan — planned_at dekt een eventuele intakewachtlijst-periode. "Maximaal één lopende intake per episode" is een aan/uit-zetbare bedrijfsregel, geen schemabeperking.';
+
+ALTER TABLE clinical_intake_assessment ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON clinical_intake_assessment FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_clinical_intake_assessment_updated_at BEFORE UPDATE ON clinical_intake_assessment FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- intake_contact
+-- ============================================================================
+CREATE TABLE intake_contact (
+  id                            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  clinical_intake_assessment_id UUID NOT NULL REFERENCES clinical_intake_assessment(id) ON DELETE CASCADE,
+  occurred_at                   TIMESTAMPTZ NOT NULL,
+  contact_type                  TEXT NOT NULL,      -- waardelijst intake_contact_type
+  performed_by                  UUID NOT NULL REFERENCES practitioners(id),
+  notes                         TEXT,
+  planned_duration_minutes      INTEGER,
+
+  created_at                    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                    TIMESTAMPTZ,
+
+  CONSTRAINT intake_contact_duration_non_negative CHECK (planned_duration_minutes IS NULL OR planned_duration_minutes >= 0)
+);
+
+CREATE INDEX idx_intake_contact_assessment ON intake_contact(clinical_intake_assessment_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE intake_contact IS 'model-intake-behandeladvies.md §1.2. Exclusief aan één clinical_intake_assessment; generalisatie naar een bredere consult-/afspraakstructuur is de agenda-ronde.';
+
+ALTER TABLE intake_contact ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON intake_contact FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_intake_contact_updated_at BEFORE UPDATE ON intake_contact FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- child_safety_check
+-- ============================================================================
+CREATE TABLE child_safety_check (
+  id                             UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  clinical_intake_assessment_id  UUID NOT NULL REFERENCES clinical_intake_assessment(id) ON DELETE CASCADE,
+  performed_at                   TIMESTAMPTZ NOT NULL,
+  performed_by                   UUID NOT NULL REFERENCES practitioners(id),
+  responsible_for_minors         BOOLEAN NOT NULL,
+  minor_count                    INTEGER,
+  minor_ages                     TEXT,             -- vrije tekst, bewust geen kindrecords (dataminimalisatie)
+  safety_concern                 BOOLEAN NOT NULL,
+  safety_concern_notes           TEXT,
+  action_taken                   BOOLEAN NOT NULL,
+  action_taken_notes             TEXT,
+  pregnancy                      BOOLEAN NOT NULL,  -- vierde vlag, te verifiëren tegen KNMG-meldcode (B34)
+  notes                          TEXT,
+
+  created_at                     TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                     TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                     TIMESTAMPTZ,
+
+  CONSTRAINT child_safety_check_safety_notes_required CHECK (NOT safety_concern OR safety_concern_notes IS NOT NULL),
+  CONSTRAINT child_safety_check_action_notes_required CHECK (NOT action_taken OR action_taken_notes IS NOT NULL)
+);
+
+-- maximaal één per intake
+CREATE UNIQUE INDEX idx_child_safety_check_assessment ON child_safety_check(clinical_intake_assessment_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE child_safety_check IS 'model-intake-behandeladvies.md §1.3 (B34). Wet verplichte meldcode / KNMG-kindcheck.';
+
+ALTER TABLE child_safety_check ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON child_safety_check FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_child_safety_check_updated_at BEFORE UPDATE ON child_safety_check FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- ============================================================================
+-- intake_mdt_review (minimale, voorlopige hook — zie §6 aldaar)
+-- ============================================================================
+CREATE TABLE intake_mdt_review (
+  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  occurred_at   TIMESTAMPTZ NOT NULL,
+  participants  TEXT NOT NULL,           -- vrije tekst; structurering wacht op de MDO-ronde (B14-B15)
+  notes         TEXT,
+
+  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at    TIMESTAMPTZ
+);
+
+COMMENT ON TABLE intake_mdt_review IS 'model-intake-behandeladvies.md §1.4. Geen eigen FK naar clinical_intake_assessment — gekoppeld via treatment_advice.mdt_review_id, telt pas zodra hij aan een vastgesteld advies hangt. LKS 4.0: dwingend voor settings 3-8, optioneel setting 2, n.v.t. vrijgevestigden.';
+
+ALTER TABLE intake_mdt_review ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON intake_mdt_review FOR ALL USING (auth.role() = 'authenticated');
+
+-- ============================================================================
+-- treatment_advice
+-- ============================================================================
+CREATE TABLE treatment_advice (
+  id                             UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  clinical_intake_assessment_id  UUID NOT NULL REFERENCES clinical_intake_assessment(id) ON DELETE RESTRICT,
+  decided_at                     TIMESTAMPTZ NOT NULL,
+  decided_by                     UUID NOT NULL REFERENCES practitioners(id), -- indicerende regiebehandelaar
+  outcome                        TEXT NOT NULL,       -- waardelijst treatment_advice_outcome
+  recommended_care_program       TEXT,                -- waardelijst care_program
+  rationale                      TEXT,
+  mdt_review_id                  UUID REFERENCES intake_mdt_review(id),
+  replaces_advice_id             UUID REFERENCES treatment_advice(id),
+  replacement_reason             TEXT,
+
+  created_at                     TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                     TIMESTAMPTZ NOT NULL DEFAULT now(),
+  deleted_at                     TIMESTAMPTZ,
+
+  CONSTRAINT treatment_advice_outcome_check CHECK (outcome IN ('in_zorg', 'terugverwijzing', 'doorverwijzing', 'extra_diagnostiek')),
+  CONSTRAINT treatment_advice_care_program_required CHECK (
+    outcome <> 'in_zorg' OR recommended_care_program IS NOT NULL
+  ),
+  CONSTRAINT treatment_advice_rationale_required CHECK (
+    outcome = 'in_zorg' OR (rationale IS NOT NULL AND length(trim(rationale)) > 0)
+  ),
+  CONSTRAINT treatment_advice_replacement_reason_required CHECK (
+    replaces_advice_id IS NULL OR (replacement_reason IS NOT NULL AND length(trim(replacement_reason)) > 0)
+  ),
+  CONSTRAINT treatment_advice_no_self_replace CHECK (replaces_advice_id <> id)
+);
+
+-- vervangt-keten kan nooit vertakken, zelfde patroon als care_acceptance_decision
+CREATE UNIQUE INDEX idx_treatment_advice_replaces_unique ON treatment_advice(replaces_advice_id) WHERE replaces_advice_id IS NOT NULL AND deleted_at IS NULL;
+CREATE INDEX idx_treatment_advice_assessment ON treatment_advice(clinical_intake_assessment_id) WHERE deleted_at IS NULL;
+
+COMMENT ON TABLE treatment_advice IS 'model-intake-behandeladvies.md §1.5 (B32-B33). Geen apart voorafgaand advies — dit object zelf geeft de vervolgrichting. doorverwijzing/terugverwijzing zijn LKS-genormeerd volgtijdelijk (via replaces_advice_id); extra_diagnostiek is praktijkgefundeerd, niet LKS-genormeerd.';
+
+ALTER TABLE treatment_advice ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "Enable all for authenticated users" ON treatment_advice FOR ALL USING (auth.role() = 'authenticated');
+CREATE TRIGGER update_treatment_advice_updated_at BEFORE UPDATE ON treatment_advice FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- Een afgeronde intake vereist minimaal één (niet noodzakelijk het laatst
+-- vervangen) treatment_advice — afgedwongen op applicatieniveau, niet als
+-- schema-constraint (zou een circulaire FK-afhankelijkheid vereisen).
+COMMENT ON COLUMN clinical_intake_assessment.status IS 'gepland/bezig/afgerond/afgebroken. Bij afgerond hoort minimaal één treatment_advice (applicatieniveau, geen FK-constraint i.v.m. circulaire afhankelijkheid).';