docs(datamodel): FCO-IM feitenronde instroom, besluitenlog + herstructurering
Voegt de discovery- en besluitvormingsronde van 18-19 juli toe (besluitenlog, begrippenlijst, feitenmodel-instroom met scenariotoetsen, terminologie- en leveranciersonderzoek) en synchroniseert feitenmodel-instroom.md met de screening=acceptatie-beslissing (§5). Herstructureert docs/datamodel/ naar submappen per documentsoort (besluiten/sessielogs/feitenmodellen/deelmodellen/ onderzoek/entiteitenkaarten) zodat toekomstige besluitenlogs en feitenrondes per deelgebied een vaste plek krijgen.
This commit is contained in:
colinislit
@@ -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
|
||||
193
docs/datamodel/onderzoek/onderzoek-leveranciers.md
Normal file
193
docs/datamodel/onderzoek/onderzoek-leveranciers.md
Normal file
@@ -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)
|
||||
241
docs/datamodel/onderzoek/onderzoek-rapportage.md
Normal file
241
docs/datamodel/onderzoek/onderzoek-rapportage.md
Normal file
@@ -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/)
|
||||
214
docs/datamodel/onderzoek/onderzoek-standaarden.md
Normal file
214
docs/datamodel/onderzoek/onderzoek-standaarden.md
Normal file
@@ -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
|
||||
Reference in New Issue
Block a user