Logbeleid (NEN 7513)
Versie 1.0.0 - maart 2026
Dit document beschrijft het logbeleid van Remedice conform NEN 7513 (Logging van toegang tot patientgegevens in elektronische patientdossiers).
1. Doel
Het logbeleid waarborgt de traceerbaarheid en controleerbaarheid van alle toegang tot en handelingen met patientgegevens en beveiligingsrelevante acties binnen Remedice.
2. Wat wordt gelogd
Remedice logt 60+ beveiligings- en toegangsgebeurtenissen, onderverdeeld in de volgende categorieen:
2.1 Patientgegevens-toegang
| Gebeurtenis | Severity | Beschrijving |
|---|---|---|
| REVIEW_CREATED | HIGH | Nieuwe medicatiebeoordeling aangemaakt |
| REVIEW_DELETED | HIGH | Medicatiebeoordeling verwijderd |
| REVIEW_CONSENT_RECORDED | MEDIUM | Toestemming van de patient vastgelegd |
| REVIEW_PATIENT_VIEWED | MEDIUM | Inzage in patientgegevens binnen medicatiebeoordeling |
| REVIEW_PATIENT_UPDATED | MEDIUM | Wijziging van patientgegevens |
| REVIEW_PATIENT_STATUS_CHANGED | MEDIUM | Statuswijziging van een patientbeoordeling |
| REVIEW_PATIENT_EXPORTED | HIGH | Export van patientgegevens (PDF/download) |
| REVIEW_AFDELING_EXPORTED | HIGH | Export van een afdelingsbeoordeling |
| DSAR_PATIENT_EXPORTED | HIGH | Inzageverzoek (DSAR): export van patientgegevens |
| MEDICATION_UPDATED | MEDIUM | Wijziging van medicatie in een patientprofiel |
| LABWAARDE_CREATED / LABWAARDE_UPDATED / LABWAARDE_DELETED | MEDIUM | Toevoegen, wijzigen of verwijderen van labwaarden |
| ALLERGIE_CREATED / ALLERGIE_DELETED | MEDIUM | Toevoegen of verwijderen van allergieen |
| CONTRA_INDICATIE_CREATED / CONTRA_INDICATIE_DELETED | MEDIUM | Toevoegen of verwijderen van contra-indicaties |
2.2 Authenticatie en autorisatie
Toegang berust op wachtwoord plus verplichte TOTP, met step-up (een verse tweede factor) voor gevoelige acties. ZORG-ID, Google en Apple zijn optionele OIDC-koppelingen; er is geen aparte UZI-patientdatagate.
| Gebeurtenis | Severity | Beschrijving |
|---|---|---|
| AUTH_LOGIN_SUCCESS | MEDIUM | Succesvolle login |
| AUTH_LOGIN_FAILED | HIGH | Mislukte loginpoging (wachtwoord of TOTP) |
| AUTH_LOGIN_LOCKED | HIGH | Account vergrendeld na te veel mislukte pogingen |
| AUTH_PASSWORD_CHANGED | HIGH | Wachtwoord gewijzigd |
| AUTH_PASSWORD_RESET_REQUESTED | MEDIUM | Wachtwoordreset aangevraagd |
| AUTH_PASSWORD_RESET_COMPLETED | HIGH | Wachtwoordreset voltooid |
| AUTH_TOTP_RESET | HIGH | TOTP-device gereset |
| USER_TOTP_RESET_INITIATED | HIGH | TOTP-reset geinitieerd door beheerder |
| AUTH_STEP_UP_SUCCESS | MEDIUM | Step-up (verse tweede factor) geslaagd voor een gevoelige actie |
| AUTH_STEP_UP_FAILED | HIGH | Step-up-verificatie mislukt |
| AUTH_TENANT_SWITCHED | MEDIUM | Gebruiker wisselde van actieve apotheek (multi-tenant) |
| AUTH_OAUTH_LOGIN | MEDIUM | Login via gekoppelde OIDC-provider (ZORG-ID, Google of Apple) |
| AUTH_OAUTH_LINKED | MEDIUM | OIDC-provider gekoppeld aan account |
| AUTH_OAUTH_UNLINKED | HIGH | OIDC-provider losgekoppeld |
| AUTH_OAUTH_LINK_FAILED | HIGH | Koppelen van OIDC-provider mislukt |
| AUTH_DEVICE_REGISTERED | MEDIUM | Vertrouwd device geregistreerd |
| AUTH_DEVICE_REVOKED | HIGH | Vertrouwd device ingetrokken |
| AUTHORIZATION_DENIED | HIGH | Toegang geweigerd (onvoldoende rechten) |
2.3 Gebruikersbeheer
| Gebeurtenis | Severity | Beschrijving |
|---|---|---|
| USER_INVITED | MEDIUM | Nieuwe gebruiker uitgenodigd |
| USER_DEACTIVATED | HIGH | Gebruikersaccount gedeactiveerd |
| USER_UPDATED | MEDIUM | Gebruikersgegevens gewijzigd |
| USER_EMAIL_CHANGED | HIGH | E-mailadres gewijzigd |
2.4 Facturatie (superuser)
| Gebeurtenis | Severity | Beschrijving |
|---|---|---|
| BILLING_EXEMPT_TOGGLED | HIGH | Facturatie-uitzondering gewijzigd |
| BILLING_COUNT_ADJUSTED | HIGH | Verbruiksteller aangepast |
3. Logstructuur
Elke logregel bevat de volgende velden:
{
"event_id": "UUID",
"timestamp": "ISO-8601",
"event_type": "string",
"severity": "LOW | MEDIUM | HIGH",
"actor": {
"user_id": "int",
"email": "string"
},
"tenant": "schema_name",
"ip_address": "string",
"resource": {
"type": "string",
"id": "string"
},
"metadata": {}
}
4. Waar worden logs opgeslagen
| Opslag | Technologie | Locatie |
|---|---|---|
| Primair (live) | AWS CloudWatch Logs | eu-central-1 (Frankfurt), 365 dagen |
| Partitionering | Per tenant, per datum | Logstream: {schema_name}/{YYYY-MM-DD} |
| Langetermijnarchief | S3 Object Lock (governance) via dagelijkse CloudWatch-export | eu-central-1, org-account, SSE-S3, tot 20 jaar |
| AWS-API-auditspoor | CloudTrail organisatietrail (multi-region, log-file-validation) | eu-central-1, zelfde Object Lock-archief |
5. Bewaartermijn
Remedice hanteert een tweetraps bewaarmodel.
| Tier | Opslag | Bewaartermijn |
|---|---|---|
| Live | CloudWatch Logs | 365 dagen |
| Archief | S3 Object Lock (governance) | 20 jaar |
De live-tier in CloudWatch is direct doorzoekbaar voor incidentonderzoek en dekt de NEN 7510-vloer. Een dagelijkse export verplaatst elke afgesloten dag naar het S3 Object Lock-archief. Het archief legt op elk object een uniforme bewaartermijn van 20 jaar (7300 dagen) vast. Die termijn dekt in een keer alle wettelijke ondergrenzen: 5 jaar voor patienttoegangs-logs uit NEN 7513, 2 jaar voor beveiligingslogs en de 20 jaar dossierbewaarplicht uit WGBO art. 7:454 lid 3 BW.
6. Toegang tot logs
| Rol | Toegangsniveau |
|---|---|
| Remedice systeembeheerder | Volledige leestoegang voor incidentonderzoek |
| Apotheek-beheerder | Inzage in eigen tenant-logs (indien geimplementeerd in UI) |
| Reguliere medewerkers | Geen directe logtoegang |
| Externe auditor | Op verzoek, conform auditrecht in verwerkersovereenkomst |
7. Integriteit en tamperbeveiliging
- Append-only: CloudWatch Logs zijn niet te wijzigen of verwijderen via de applicatie
- Sequence tokens: Elke logwrite gebruikt een sequence token dat de volgorde waarborgt
- IAM-restricties: Applicatie heeft alleen write-toegang, delete-rechten zijn niet toegekend
- S3 Object Lock-archief: Het langetermijnarchief gebruikt Object Lock in governance-mode (20 jaar). De applicatie en reguliere beheerders kunnen archieflogs niet wijzigen of verwijderen. Verwijderen voor het einde van de termijn vereist een expliciete, geaudite override door een daartoe gerechtigde principal, bedoeld voor een wettelijke correctieplicht
- CloudTrail org-trail: Een multi-region CloudTrail-organisatietrail met log-file-validation legt elke AWS-API-actie op de log-infrastructuur vast in hetzelfde Object Lock-archief, zodat ook beheer van de logs zelf controleerbaar is
8. Reviewprocedure
| Frequentie | Actie |
|---|---|
| Dagelijks (automatisch) | Monitoring op drempelwaarden (meerdere mislukte logins, ongebruikelijke exports) |
| Maandelijks | Steekproefsgewijze controle van HIGH-severity events |
| Jaarlijks | Volledige audit van logbeleid en bewaartermijnen |
| Bij incident | Ad-hoc onderzoek van relevante logregels |
9. Scraper monitoring logging (MDR PMS / IEC 62304 / ISO 14971)
Naast de NEN 7513 patienttoegangs-logging wordt ook de dagelijkse scraper-pipeline gemonitord via CloudWatch Logs. Dit is vereist vanuit:
- MDR PMS (Art. 83-86): Monitoring van databronnen en trendanalyse van technische fouten
- IEC 62304 sectie 6: Traceerbaarheid van software-onderhoud (databron-updates)
- ISO 14971 FMEA (M11): "Scrape-fout" is een geidentificeerd risico; monitoring is een beheersmaatregel
9.1 Wat wordt gelogd
| Gebeurtenis | Beschrijving |
|---|---|
scraper.run.started |
Scraper-run gestart: naam, batch-grootte, aantal ontdekte URLs |
scraper.run.completed |
Scraper-run voltooid: duur, verwerkt, geuploaded, ongewijzigd, fouten, afgebroken |
scraper.run.failed |
Scraper-run gecrasht: fouttype, foutmelding, verwerkte aantallen |
9.2 Logstructuur
{
"event_id": "UUID",
"timestamp": "ISO-8601",
"event_type": "scraper.run.completed",
"actor": "system",
"scraper_slug": "kompas",
"scraper_name": "Kompas",
"run_id": "UUID (koppelt started aan completed/failed)",
"duration_seconds": 3421.5,
"analyzed": 208,
"uploaded": 15,
"unchanged": 190,
"errors": 3,
"aborted": false
}
9.3 Opslag
| Opslag | Technologie | Locatie |
|---|---|---|
| Primair | AWS CloudWatch Logs | eu-central-1 |
| Partitionering | Per scraper, per datum | Logstream: {scraper_slug}/{YYYY-MM-DD} |
| Log group | /remedice-<env>/scraper (dev: /remedice/scraper/runs) |
Gescheiden van de audit log groups |
| Bewaartermijn | 30 dagen | Operationele systeemlogging, geen patient-auditspoor |
9.4 Verschil met NEN 7513 audit logging
De scraper monitoring logging is geen patienttoegangs-logging (NEN 7513) maar operationele systeemlogging. Er is geen actor (gebruiker), geen tenant, en geen patientdata betrokken. De logs dienen uitsluitend voor:
- Vroegtijdige detectie van databronproblemen (PMS-vereiste)
- Trendanalyse van scrape-fouten (FMEA-beheersmaatregel)
- Traceerbaarheid van databron-updates (IEC 62304)
10. NEN 7513 conformiteit
Dit logbeleid voldoet aan de vereisten van NEN 7513 (sectie 2-8, patienttoegang):
- Wie: Gebruiker (user_id, email) wordt altijd gelogd
- Wat: Actie (event_type) en resource (type, id) worden vastgelegd
- Wanneer: Tijdstempel in ISO-8601
- Waarom: Afleidbaar uit event_type en metadata
- Resultaat: Succes/falen afleidbaar uit event_type (bijv. AUTH_LOGIN_FAILED vs. AUTH_LOGIN_SUCCESS)