triqura-ecd/docs/datamodel/deelmodellen/datamodel-discovery.md

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) · CaseTalk — About FCO-IM · Zwart e.a., Fact Oriented Modeling with FCO-IM
• Nictiz — Zorginformatiebouwstenen (zibs) · Registratie aan de bron — zibs
• openEHR — Design Principles · Archetype relational mapping (PMC)
• dbi services — Embedding versioning met pgvector / event-driven her-embedding · pgvector RAG op managed PostgreSQL (2026)
• Append-only audit trails — designgurus · EHR audit trail — compliance & best practices