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 ruim 160 beveiligings- en toegangsgebeurtenissen, onderverdeeld in de volgende categorieen. Conform NEN 7513:2024 hoofdstuk 6 worden drie soorten gebeurtenissen op persoonlijke gezondheidsinformatie gelogd: toegangsgebeurtenissen, zoekgebeurtenissen en uitwisselingsgebeurtenissen (exports).
Granulariteit (beleidskeuze): een toegangsgebeurtenis wordt gelogd bij het openen van een patientdossier (detailweergave, gesprek, export) en bij elke mutatie. Lijstweergaven die uitsluitend naam en status als index tonen, gelden niet als dossierinzage en worden niet afzonderlijk gelogd. Zoeken op patientnaam geldt wel als zoekgebeurtenis en wordt gelogd.
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_SEARCHED | MEDIUM | Zoekgebeurtenis: zoeken op patientnaam of geboortedatum (globale zoek, profielenlijst en fuzzy-zoeken) |
| 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",
"action_code": "C | R | U | D | E",
"audit_source": "remedice-backend",
"actor": {
"user_id": "int",
"email": "string",
"role": "rolnaam binnen de tenant op het moment van de gebeurtenis"
},
"purpose_of_use": "doelcode (NEN 7513 tabel 9), leeg voor niet-patientgebeurtenissen",
"authorization_basis": "RBAC-permissiecode die toegang verleende",
"control_results": "T | F (resultaat geautomatiseerde autorisatiecontrole)",
"consent_profile": "geen-bijzonderheden (alleen bij clientgebonden gebeurtenissen)",
"tenant": "schema_name",
"ip_address": "string",
"resource": {
"type": "string",
"id": "string"
},
"metadata": {}
}
Gevoelige metadata: velden die zelf persoonsgegevens bevatten (zoals de letterlijke zoekvraag van een zoekgebeurtenis, vereist door NEN 7513 tabel 2) gaan uitsluitend naar het beschermde CloudWatch-auditplane. De DB-mirror voor de in-app viewer krijgt in plaats daarvan een niet-omkeerbare correlatiehash (zoekvraag_corr).
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.
Zoekgebeurtenissen staan in een eigen loggroep en blijven op de live-tier van 365 dagen. Een zoekvraag raakt patientgegevens, maar is geen dossierinhoud en valt niet onder de dossierbewaarplicht. Ze gaan daarom niet naar het onveranderlijke archief, zodat een naamfragment niet twintig jaar onwisbaar vastligt.
6. Toegang tot logs
| Rol | Toegangsniveau |
|---|---|
| Remedice systeembeheerder | Volledige leestoegang voor incidentonderzoek (logbeheerder, NEN 7513 8.1.2) |
| Apotheek-beheerder | In-app auditlogviewer voor de eigen tenant (permissie settings.view_audit_log plus step-up, 90 dagen terug) |
| Medewerker met dossiertoegang | Per-patient toegangslograpport (permissie review.view plus step-up), zie paragraaf 6.1 |
| Reguliere medewerkers | Geen directe logtoegang |
| Externe auditor | Op verzoek, conform auditrecht in verwerkersovereenkomst |
Elke raadpleging van de logging wordt zelf gelogd (AUDIT_LOG_VIEWED), conform NEN 7513 8.7.2. Uitschakelen van deze meta-logging is niet mogelijk via de applicatie.
6.1 Inzage door de patient (NEN 7513 5.2.2 en 9.2)
De patient heeft het recht te weten wie toegang heeft gehad tot zijn dossier. De apotheek (verwerkingsverantwoordelijke) beantwoordt zo'n verzoek via het per-patient toegangslograpport op het scherm Patientrechten (AVG):
- Inhoud: chronologisch overzicht per gebeurtenis met tijdstip, gebeurtenistype, actiecode, rol van de medewerker, gebruiksdoel en de permissiecode waarop toegang berustte.
- Clientweergave: conform NEN 7513 8.5.1 en tabel 19 toont de clientweergave in eerste instantie niet de naam van de medewerker, wel diens rol en de organisatie. Alleen bij een specifiek, met redenen omkleed verzoek weegt de apotheek de belangen af en toont zo nodig de naam (zorgaanbiederweergave).
- Periode: het rapport is filterbaar op periode en dekt de afgelopen 90 dagen (DB-mirror). Voor oudere periodes vraagt de apotheek een uittreksel op bij Remedice; de logbeheerder haalt dit uit CloudWatch (365 dagen) of het S3-archief (20 jaar) en levert het beveiligd aan.
- Noodprocedure: Remedice kent geen noodknop-toegang ("break the glass"); elk dossier is alleen via reguliere RBAC-autorisatie bereikbaar. De controleposities behandelrelatie, clienttoestemming en noodprocedure zijn daarom niet geautomatiseerd en blijven leeg in de logregel.
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:2024 conformiteitsmatrix
De tabel hieronder mapt de logregel-velden van Remedice op de veldeisen van NEN 7513:2024, tabel 1 (toegangsgebeurtenissen) en tabel 2 (zoekgebeurtenissen). Optionaliteit: M = verplicht, MC = conditioneel verplicht, U = optioneel (de keuze is per de norm aan de zorgaanbieder en wordt hier vastgelegd).
| NEN 7513-veld | Clausule | Optionaliteit | Remedice-veld |
|---|---|---|---|
| Gebeurteniscode (EventID) | 7.2.2 | M | event_type (uniek binnen audit_source) |
| Actiecode (EventActionCode) | 7.2.3 | M | action_code (C/R/U/D/E conform tabel 5; toepassingsfuncties en zoekvragen zijn E) |
| Datum en tijd (EventDateTime) | 7.2.4 | M | timestamp (ISO-8601, UTC; kloksynchronisatie via AWS-tijdbasis) |
| Resultaat (EventOutcomeIndicator) | 7.2.5 | U | Afleidbaar uit event_type (aparte success/failed-gebeurtenissen) |
| GebruikersID (UserID) | 7.3.2 | M | actor.user_id (stabiele PK uit het authenticatiesysteem) |
| Gebruikersnaam (UserName) | 7.3.4 | U | actor.email |
| Gebruikersrol (RoleIDCode) | 7.3.6 | U (vastgelegd: ja) | actor.role (rolnaam binnen de tenant op het moment van de gebeurtenis) |
| Gebruiksdoel (PurposeOfUse) | 7.3.7 | U (vastgelegd: ja) | purpose_of_use (doelcodes conform tabel 9: 1 = zorgverlening, 5 = kwaliteitsborging, 13 = nut voor de client) |
| Toegangspunt (NetworkAccessPointID) | 7.4.2 | U | ip_address |
| Bronsysteem (AuditSourceID) | 7.5.4 | M | audit_source plus de CloudWatch log group |
| Betrokken object: klasse/categorie/identificatietype | 7.6.3, 7.6.4, 7.6.6 | M | resource.type (vastgelegde typecodering, bijv. review_patient, patient_profiel) |
| Betrokken object: identificatie (ParticipantObjectID) | 7.6.9 | M | resource.id (UUID; nooit inhoudelijke gezondheidsinformatie) |
| Zoekvraag (ParticipantObjectQuery, tabel 2) | 7.6.11 | M bij zoekgebeurtenis | metadata.zoekvraag (alleen CloudWatch-plane; DB-mirror krijgt correlatiehash) |
| Autorisatieprotocol | 7.7.2 | U (vastgelegd: ja) | authorization_basis (RBAC-permissiecode, bijv. review.view) |
| Behandelrelatieprotocol | 7.7.3 | U | Niet geautomatiseerd; behandelrelatie wordt organisatorisch door de apotheek geborgd |
| Toestemmingsprofiel | 7.7.4 | MC | consent_profile = "geen-bijzonderheden" bij clientgebonden gebeurtenissen |
| Controles | 7.7.5 | MC | control_results: positie 1 (autorisatiecontrole, geautomatiseerd) als T/F; behandelrelatie, toestemming en noodknop zijn niet geautomatiseerd en blijven leeg |
Aanvullende conformiteit:
- Drie gebeurtenissoorten (hoofdstuk 6): toegangsgebeurtenissen (inzien, muteren, exporteren), zoekgebeurtenissen (
REVIEW_PATIENT_SEARCHEDmet zoekvraag) en uitwisselingsgebeurtenissen (exports en DSAR) worden gelogd. - Bewaartermijn (8.3): het bewaarbeleid in paragraaf 5 dekt de wettelijke ondergrens van 5 jaar uit het Besluit elektronische gegevensverwerking door zorgaanbieders (Begz).
- Logbeheerder (8.1.2): de verantwoordelijke informatiebeveiliging van Remedice is aangewezen als logbeheerder.
- Beschikbaarheid (8.2): dual-write naar CloudWatch en DB-mirror; een mislukte write naar het ene kanaal blokkeert het andere niet en wordt in de applicatielog gemeld.
- Vertrouwelijkheid en integriteit (8.4): zie paragraaf 7 (append-only, IAM write-only, Object Lock, CloudTrail).
- Toegang tot logging en weergaven (8.5, 9.2, 9.3): zie paragraaf 6 en 6.1, inclusief clientweergave zonder medewerkersnaam en meta-logging van elke raadpleging (8.7.2).