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