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