A patient portal sounds simple: a website where people book appointments and read their results. In the Netherlands it's rarely that simple, because the moment you touch health data you inherit DigiD login, NEN 7510 security, GDPR, and MedMij data exchange. Get the foundations right and a portal genuinely improves care and cuts admin. Get them wrong and you're rebuilding under pressure. Here's what building a Dutch patient portal actually involves.

Note: this is practical guidance, not legal or regulatory advice. Your obligations depend on your organisation, the data you handle and the portal's function. Confirm your specific requirements with a qualified professional before you build.

What a patient portal is for

Strip away the features and a portal exists to do two things: give patients safe access to their own information, and take repetitive work off your staff. Every good feature serves one of those goals. When both are met, patients stop phoning for results and staff stop rekeying forms: the portal pays for itself in time saved, not just in patient satisfaction. That framing matters before you write a single feature: a portal justified by "patients expect one" tends to sprawl, while one justified by specific saved hours stays focused and measurable.

The features that actually matter

Portals drift into feature bloat quickly. The core set that earns its place:

Start with the handful that remove the most manual work, and add the rest once the foundation is solid.

Compliance is the foundation, not a feature

In Dutch healthcare, security and privacy aren't a phase you add at the end. They shape the architecture from day one. The baseline you should expect:

The expensive mistake: treating compliance as a bolt-on after the demo looks good. Retrofitting NEN 7510 controls, proper access logging and DigiD-grade authentication into a portal that wasn't designed for them is slow, costly and risky. Security architecture belongs in the first design conversation, not the last.

Integration is where the real work lives

A portal is only as useful as the systems behind it. If it can't read from your EHR/EPD, patients see stale data and staff key things twice. The heavy lifting (and much of the budget) is in connecting to source systems and exchanging data along Dutch interoperability lines. The MedMij framework and national standards define how patient data moves between providers; building to them is what makes a portal part of the ecosystem rather than an island. Our overview of MedMij and Nictiz explains how that exchange fits together.

What drives the cost

Portal cost scales with integrations and compliance, not with the number of screens. The main levers:

DriverEffect on cost
DigiD integrationAdds authentication and assurance work
EHR/EPD integrationOften the largest single item
MedMij data exchangeStandards conformance and testing
Secure messagingExtra security and storage handling
NEN 7510 securityOngoing overhead across the build

Because integrations dominate, price them separately and honestly rather than folding them into a round number. For the full picture, see our breakdown of custom medical software cost. The same logic applies: compliance and integration are the budget, screens are the easy part.

How to approach the build

  1. Define the two or three workflows that remove the most manual work. Start there, not with a feature wishlist.
  2. Design for compliance from day one, with NEN 7510 and GDPR shaping the architecture.
  3. Scope integrations early (DigiD, your EHR/EPD and MedMij) because they set the timeline.
  4. Launch a compliant minimum, then extend once it's proven in real use.

A phased approach also keeps risk contained: each release is small enough to secure, test and validate properly before the next one adds scope. A patient portal is a healthcare system, not a brochure with a login. Build it that way (compliant foundations first, integrations scoped honestly, features earned by real use) and it becomes an asset your patients and staff rely on every day rather than a project that stalls in review.

Planning a patient portal? Neurova AI builds custom medical software for the Dutch market, with DigiD, NEN 7510 and MedMij designed in from the start. Book a call and we'll scope it honestly.

Frequently asked questions

What features does a patient portal need in the Netherlands? Core features include secure login (typically via DigiD), access to medical records, appointment scheduling, secure messaging with providers, prescription requests, and viewing results. Dutch portals also commonly need MedMij-based data exchange so patients can collect their data from different providers in one place.

What compliance applies to a Dutch patient portal? At minimum, GDPR for personal and health data and NEN 7510 for information security in Dutch healthcare. Patient authentication usually relies on DigiD, and data exchange often follows the MedMij framework and Dutch interoperability standards. Depending on function, medical device rules may also apply.

How much does a patient portal cost to build? Cost depends on scope and integrations rather than screen count. A focused portal is far cheaper than one with deep EHR integration, DigiD, MedMij and messaging. Integrations and security are the main drivers, so price those separately and expect compliance to add to a comparable non-regulated build.

Written by Andreas Chitos, founder of Neurova AI. He builds AI systems and medical software from Eindhoven, the Netherlands. Get in touch.