FHIR Datamodel

Overview

• MedMIJ - Nederlandse patiëntportalen
• Koppeltaal - eHealth apps en interventies
• Landelijk Schakelpunt (LSP) - Medicatie-uitwisseling
• Andere zorginstellingen - Via standaard FHIR API's

Standaard Compliance

MedMIJ Basisgegevens GGZ 2.0

• ✅ Cliënten kunnen later hun eigen dossier inzien via een PGO-app
• ✅ Gegevens kunnen veilig gedeeld worden met andere zorgaanbieders
• ✅ Automatische uitwisseling met huisartsen en andere verwijzers
• ✅ Geen vendor lock-in - data is altijd exporteerbaar

FHIR R4 Resources

• Veldnamen volgen FHIR naming conventions
• Data types komen overeen met FHIR specificaties
• Relaties tussen resources volgen FHIR reference structuur
• API endpoints kunnen direct FHIR JSON genereren

Geïmplementeerde Resources

1. Practitioners - Behandelaren

• BIG-nummer (indien van toepassing)
• AGB-code voor facturatie
• Naam en kwalificaties
• Contactgegevens
• Actieve status

• Toewijzen van behandelverantwoordelijkheid
• Autorisatie en toegangscontrole
• Facturatie en declaratie
• Handtekeningen op documenten

2. Organizations - Instellingen

• AGB-code instelling
• KVK-nummer
• Naam en nevenvestigingen
• Adres en contactgegevens

• Juridische verantwoordelijkheid
• Facturatie en contracten
• Verwijzingen naar andere instellingen
• Netwerkzorg registratie

3. Patients - Patiënten/Cliënten

• BSN (versleuteld opgeslagen)
• Naam, geboortedatum, geslacht
• Adres en contactgegevens
• Verzekeringsgegevens
• Huisarts (naam + AGB)
• Noodcontactpersoon

• BSN wordt versleuteld opgeslagen
• Toegang via Row Level Security (RLS)
• AVG-compliant logging van alle toegang

• Basis voor alle andere dossiergegevens
• Identificatie bij contact
• Facturatie naar verzekering
• Communicatie met cliënt

4. Encounters - Contactmomenten

• Type contact (intake, diagnostiek, behandeling, crisis)
• Status (gepland, lopend, afgerond)
• Datum en tijd
• Behandelaar en cliënt
• Locatie (polikliniek, online, kliniek)
• Aanmeldingsreden

• Timeline van alle contacten per cliënt
• Facturatie per contactmoment
• Koppeling van diagnoses aan intake
• Planning en agenda-beheer

5. Conditions - Diagnoses

• DSM-5/ICD-10 code (bijv. "F32.2")
• Omschrijving (bijv. "Depressieve episode, ernstig")
• Klinische status (actief, in remissie, opgelost)
• Ernst (mild, matig, ernstig)
• Verificatie status (voorlopig, bevestigd)
• Vastgesteld door welke behandelaar
• Bij welk contactmoment

• Problemlijst per cliënt
• Basis voor behandelplan
• DBC registratie en facturatie
• Rapportage en statistiek

1. Intake: voorlopige diagnose "F32.2 - Depressieve episode, ernstig"
2. Na diagnostiek: bevestiging van diagnose
3. Na behandeling: status wijzigt naar "in remissie"
4. Bij herstel: status wordt "opgelost"

6. Observations - Metingen en Observaties

• Type observatie (ROM-score, risico-inschatting, vitaliteit)
• Uitkomst/waarde
• Interpretatie (normaal, afwijkend)
• Datum en tijd
• Uitgevoerd door welke behandelaar
• Gekoppeld aan welk contactmoment

• ROM-metingen: PHQ-9, GAD-7, OQ-45 (routine outcome monitoring)
• Risico-inschattingen: Suïcidaliteit, agressie, verwaarlozing
• Middelengebruik: Alcohol, drugs, medicatie-compliance
• Vitale functies: Bloeddruk, hartslag (indien relevant)

• Voortgang monitoren met ROM-scores
• Veiligheidsbewaking (risico's)
• Wetenschappelijk onderzoek
• Kwaliteitsindicatoren

• PHQ-9 vragenlijst ingevuld: score 18 → interpretatie: "Matig-ernstige depressie"
• Risico-inschatting: "Suïcidale gedachten, geen plannen" → interpretatie: "Matig risico"

7. CarePlans - Behandelplannen

• Titel en beschrijving
• Status (concept, actief, afgerond, gestopt)
• Looptijd (start- en einddatum)
• Behandeldoelen (SMART geformuleerd)
• Behandelactiviteiten (interventies, frequentie)
• Welke diagnoses worden behandeld
• Regiebehandelaar

• Multidisciplinair behandelplan opstellen
• Voortgang monitoren
• Communicatie met cliënt
• Evaluatie en bijstelling

Behandelplan: "Behandeling depressie"
├─ Diagnose: F32.2 (Depressieve episode, ernstig)
├─ Doel 1: "PHQ-9 score < 10 binnen 12 weken"
├─ Doel 2: "Herstel dagelijks functioneren (werk/sociaal)"
├─ Activiteit 1: Individuele CGT - 1x/week, 12 sessies
├─ Activiteit 2: ROM-meting PHQ-9 - elke 4 weken
└─ Activiteit 3: Medicatie - Sertraline 50mg dagelijks

Relaties tussen Resources

Patient (Patiënt)
  │
  └─── Encounters (Contactmomenten)
         │
         ├─── Conditions (Diagnoses)
         │      └─── ondersteund door Observations (ROM-scores)
         │
         ├─── Observations (Metingen/Risico's)
         │
         └─── CarePlans (Behandelplannen)
                ├─── Doelen (Goals)
                └─── Activiteiten (Interventies)

Uitgevoerd door: Practitioner (Behandelaar)
Binnen: Organization (Instelling)

1. Aanmelding → Encounter (intake) wordt aangemaakt
2. Diagnostiek → Conditions (diagnoses) gekoppeld aan Encounter
3. ROM-meting → Observations gekoppeld aan Encounter
4. Behandelplan → CarePlan gekoppeld aan Patient + Conditions
5. Behandeling → Nieuwe Encounters voor sessies
6. Evaluatie → Nieuwe Observations (ROM) om voortgang te meten

Data-uitwisselbaarheid

FHIR API Endpoints

GET    /api/fhir/Patient              → Lijst van patiënten
GET    /api/fhir/Patient/{id}         → Specifieke patiënt
POST   /api/fhir/Patient              → Nieuwe patiënt aanmaken
PUT    /api/fhir/Patient/{id}         → Patiënt bijwerken

GET    /api/fhir/Practitioner         → Lijst van behandelaren
GET    /api/fhir/CarePlan/{id}        → Behandelplan ophalen
POST   /api/fhir/CarePlan             → Behandelplan importeren

• Content-Type: application/fhir+json
• Volledig FHIR R4 compliant JSON
• Ondersteunt FHIR search parameters
• Error responses via FHIR OperationOutcome

Export/Import Scenario

1. Behandelaar maakt behandelplan in Mini-EPD
2. Export via API: GET /api/fhir/CarePlan/abc-123
3. FHIR JSON response bevat volledig behandelplan
4. Andere instelling importeert: POST /api/fhir/CarePlan
5. ✅ Behandelplan is succesvol gedeeld tussen systemen

1. Cliënt opent PGO-app (Persoonlijke Gezondheidsomgeving)
2. App vraagt toestemming voor toegang tot dossier
3. Mini-EPD API deelt FHIR resources met app
4. Cliënt ziet eigen behandelplan, diagnoses en ROM-scores
5. ✅ Data-uitwisselbaarheid volgens MedMIJ standaard

Privacy & Beveiliging

Toegangscontrole (Row Level Security)

• Behandelaren zien alleen hun eigen patiënten
• Patiënten kunnen later hun eigen data inzien (via patiëntenportaal)
• Administrators hebben beperkte toegang (geen medische data)

Encryptie

• BSN wordt versleuteld opgeslagen (pgcrypto)
• Communicatie via HTTPS/TLS
• Database backups zijn versleuteld

AVG-compliance

• Recht op inzage - Cliënt kan eigen data opvragen via API
• Recht op correctie - Data kan bijgewerkt worden
• Recht op vergetelheid - Data kan verwijderd worden (na wettelijke bewaartermijn)
• Logging - Alle toegang wordt gelogd in audit trail
• Toestemming - Consent management via Consents resource (toekomstig)

Roadmap

✅ Fase 1: Foundation (Voltooid)

• Database schema met 6 FHIR resources
• TypeScript type definitions
• Data migratie van legacy tabellen
• Seed data voor demo

✅ Fase 2: API & UI (Voltooid)

• FHIR transform library (DB ↔ FHIR JSON)
• Patient API endpoints (GET/POST/PUT)
• Practitioner API endpoints (GET/POST)
• Patient UI (lijst, detail, formulieren)

⏳ Fase 3: Encounters & Conditions (In planning)

• Encounter API endpoints
• Condition API endpoints
• Observation API endpoints
• UI voor contactmomenten en diagnoses

🎯 Fase 4: CarePlans (Hoofddoel)

• CarePlan API endpoints
• Wizard UI voor behandelplan opstellen
• Doelen en activiteiten beheer
• Voortgang monitoring

🔮 Fase 5: Integraties (Toekomst)

• MedMIJ aansluiting (patiëntportaal)
• Koppeltaal aansluiting (eHealth apps)
• Landelijk Schakelpunt (medicatie)
• Swagger/OpenAPI documentatie

Technische Details

Database: PostgreSQL (Supabase)

• Type-safe ENUMs voor statussen (draft, active, completed, etc.)
• Automatische timestamps (created_at, updated_at)
• Foreign keys voor relaties tussen resources
• Indexes op veel-gebruikte velden voor performance
• JSONB fields voor flexibele embedded data (goals, activities)

Veldnamen volgen FHIR

• name_family → Patient.name.family
• identifier_bsn → Patient.identifier[system=bsn].value
• status → CarePlan.status

Transform Pattern

// Database → FHIR
const fhirPatient = dbPatientToFHIR(dbRow);

// FHIR → Database
const dbInsert = fhirPatientToDB(fhirResource);

Voor Functioneel Beheerders

Wat betekent dit voor dagelijks gebruik?

• Intuïtieve UI, geen FHIR kennis nodig
• Alle data logisch gestructureerd
• Diagnoses gekoppeld aan intake-moment
• Behandelplan volgt automatisch uit diagnose

• Export naar andere systemen is mogelijk
• Backups bevatten FHIR-compliant data
• Audits en rapportages zijn eenvoudig
• Geen vendor lock-in

• Database schema volgt internationale standaard
• API endpoints zijn FHIR-compliant
• Integraties zijn goed gedocumenteerd
• Migratie naar andere systemen is eenvoudig

Veelgestelde Vragen

Referenties

• FHIR R4: https://hl7.org/fhir/R4/
• FHIR Patient: https://hl7.org/fhir/R4/patient.html
• FHIR CarePlan: https://hl7.org/fhir/R4/careplan.html

• MedMIJ GGZ: https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpGGZ
• ZIBs: https://zibs.nl/

• Technisch schema: docs/archive/schemas/20241121_fhir_ggz_schema.sql (archived)
• Bouwplan: docs/bouwplan-pragmatisch-fhir.md
• Datamodel details: docs/datamodel-documentatie.md