Skip to content

Handling Medical Data in the Netherlands: A Practical Guide for Developers

Working on an app or system that touches medical data in the Netherlands? Then you're not just building features, you're operating in one of the most tightly regulated data domains out there. This post breaks down what you actually need to know (and care about) as a developer: what the law expects, where the real constraints are, and how standards like NEN 7510 fit into your system design.

Info

For a more in-depth explanation, read the repository

ISO 27001 compliance

NEN 7510 is pretty much an expanded version of ISO 27001. If you comply with NEN 7510, you're most likely also ISO 27001 compliant.

Why this matters

If your application processes medical data under Dutch jurisdiction, you're dealing with:

  • Strict privacy laws (AVG / GDPR)
  • Additional rules for medical data
  • Mandatory security standards (like NEN 7510)

And importantly: these rules apply even if you're "just building the backend."

Step 1: Everything starts with the AVG (GDPR)

Before you even touch medical data, you need to understand the baseline: the AVG (the Dutch implementation of GDPR).

The short version developers care about

  • If you store or process data from people on EU territory, you must comply
  • Collect as little data as possible.

  • Be explicit about:

    • what you store
    • why you store it
    • how long you store it

  • Make sure there is a lawful ground for storing or processing data (explained in step 2)

  • People can:

    • request access to their data
    • request to correct data
    • request deletion of their data

  • Data breaches must be reported within 72 hours to the https://www.autoriteitpersoonsgegevens.nl/datalek-melden

What counts as "personal data"?

Anything traceable to a person. That includes:

  • Names, emails, etc.
  • Pseudonymized data (if reversible)
  • Device-related data (if it can identify someone)
  • Location related data (IP-addresses, geo-location, etc)

"Sensitive" data (aka: don't touch unless you really have to)

This includes:

  • Health data (obviously)
  • Biometric/genetic data
  • Religion, politics, sexuality
  • Ethnicity
  • Union membership

Rule of thumb: if you don't absolutely need it → don't store or process it.

You can't just collect data because your app needs it. You need a legal basis. The common ones in practice:

  • Contract → required to deliver your service
  • Legal obligation
  • Vital interest → life-or-death scenarios
  • Public task
  • Legitimate interest → tricky, requires balancing
  • Consent → user explicitly agrees

If you can't clearly explain your legal basis, you shouldn't be storing or processing the data.

Step 3: Core data protection principles (design implications)

These aren't just legal theory, they directly affect your architecture:

  • Data minimization → don't over-engineer schemas
  • Purpose limitation → no "we'll use it later"
  • Storage limitation → build deletion/retention logic
  • Accuracy → allow updates
  • Security → encryption, access control
  • Accountability → logging + documentation

If you're designing systems, these should show up in your requirements—not as an afterthought.

Step 4: Medical data = extra restrictions

Warning

Handling medical data is forbidden by default.

When is it allowed?

Only when:

  • It's part of a treatment context, AND
  • You have a valid legal basis, AND
  • The patient gave explicit consent

Also:

  • All medical data tied to a patient = patient dossier
  • You must clearly define why you store it (your "grondslag")

Step 5: Sharing medical data

Inside your organization

  • Allowed (but only with personnel related to the treatment of the patient)
  • No extra consent required

Outside your organization (other providers, research, third parties)

  • Requires explicit patient consent
  • You must clearly communicate:
    • what data is shared
    • with whom
    • why

There are legal exceptions, but don't rely on those unless you know exactly what you're doing.

Step 6: Compliance isn't optional — enter NEN 7510

Unlike many guidelines, NEN 7510 is mandatory in the Netherlands for healthcare systems. Think of it as your security and design baseline.

What it means in practice

You're expected to implement:

  • RBAC (Role-Based Access Control) with Zero-trust mindset: no one gets access by default.
  • 2FA: Required for systems handling patient data.
  • Encryption: Data must be encrypted both in transit and at rest. For web-applications this means that HTTPS is mandatory.
  • Monitoring & logging: You need visibility into system behavior.
  • Backups: Backups must be encrypted at rest and tested regularly to ensure that they can be restored.
  • Session management: Auto-logout on inactivity.
  • Brute-force protection: Rate limiting, CAPTCHA, etc.
  • Secure coding practices: OWASP-level hygiene is expected.
  • No anonymous access: Everything must be authenticated.
  • Data cleanup: Don't keep data longer than needed, in compliance with the data retention policy.
  • Deduplication: Patients must have only one dossier. If multiple occur, they should be merged together.
  • Unique identifier: Screens and prints must contain clear identification of the patient, such as name, birthdate, etc.

Also: you're expected to perform a risk assessment. There's no prescribed method, just that you must do it.

Step 7: Logging (NEN 7513)

Logging is absolutely not optional, it is required. NEN 7513 defines how to log medical system activity.

Key requirements

You must log:

  • Who did something
  • What they did
  • When they did it
  • Which patient data was involved
  • Why (if applicable)

Examples of events to log

  • Logins (success + failure)
  • Authorization attempts
  • Data access (including reads!)
  • Data changes (CRUD)
  • Role/permission changes
  • System config changes
  • External data exchanges

Important constraints

  • Logs must be immutable
  • Actions from admins are logged
  • Patients have the right to see:
    • their data
    • who accessed it

Also: logs themselves are sensitive data → protect them just like medical data.

Step 8: Messaging (NTA 7516)

If your system sends medical data via email or chat, this standard applies.

Key requirements

  • TLS encryption (TLS 1.2+)
  • Message integrity (verify sender + content)
  • Clear sender identity
  • Authorization checks
  • Logging (again)
  • Minimal metadata
  • EU data boundaries

UX constraint (often overlooked)

Users must be able to:

  • Read messages without creating an account
  • Save them easily

Yes, this has real architectural implications.

So what does this mean for your architecture?

If you boil it down:

  • Treat medical data as data that must be protected as best as possible
  • Design for:
    • minimal data collection
    • strict access control
    • full traceability (logging)
  • Assume:
    • audits will happen
    • breaches must be reported
  • Build:
    • consent flows
    • deletion workflows
    • monitoring systems

Final takeaway

If you want a mental model:

AVG defines whether you can process data NEN 7510/7513/7516 define how you must secure and handle it

And the biggest practical rule:

Do I need the data? If no, don't touch it.

Used sources