Developing software for healthcare — requirements, costs and pitfalls

Having custom software built for the healthcare sector is fundamentally different from building a webshop or an internal dashboard. It's not just about the technology — it's about the complex web of requirements, responsibilities, and oversight that surrounds healthcare. Underestimate this and you'll pay the price later: in delays, rework, or worse, a product that cannot be put into use.

This article is intended for healthcare organizations, healthcare entrepreneurs, and decision-makers considering building a digital product — from a patient portal to a reporting system or a custom electronic care record (ECD). It gives an honest picture of what this process involves, what it costs, and what the most common mistakes are.

The regulations you cannot ignore

NEN 7510 — information security in healthcare

NEN 7510 is the Dutch standard for information security in the healthcare sector. Similar to ISO 27001, but specifically focused on the protection of medical data. For many healthcare organizations, NEN 7510 certification is mandatory or contractually required by health insurers and umbrella organizations.

What this means in practice for a software project: the supplier must be able to demonstrate that the system meets the security requirements of the standard. This requires role-based access control, logging of who viewed which data and when, encryption of data in transit and at rest, and a documented incident response process. These are not options you add afterwards — they must be built into the design from day one.

GDPR and medical data

Medical data falls under special categories of personal data under the GDPR. Processing it is in principle prohibited unless there is an explicit legal basis. In healthcare, this basis is often the treatment relationship (Article 9(2)(h) GDPR), but this does not exempt you from other obligations.

A software agency that builds healthcare software acts legally as a processor. This means a data processing agreement is mandatory, data minimization must be incorporated into the design, and data breaches must be able to be reported to the supervisory authority within 72 hours. Healthcare organizations that delegate this to an agency without a processing agreement are themselves liable.

UZI cards and authentication

For systems that provide access to the National Switch Point (LSP) or that work with the BIG register, authentication via UZI cards (Unique Healthcare Provider Identification) is required. These are chip cards that record the identity of a healthcare provider. Not every agency has experience with UZI integrations — and it's not a trivial technical task.

Systems that don't require a direct LSP connection can also work with DigiD (for patients) or other certified authentication means, depending on the risk level.

SMART on FHIR and interoperability

One of the most underestimated requirements in healthcare software is interoperability: the requirement that systems can communicate with each other. In the Netherlands, FHIR (Fast Healthcare Interoperability Resources) is the standard for exchanging medical data. SMART on FHIR is an authorization framework that sits on top of this and enables secure connections with external systems.

If your new system needs to communicate at all with an EHR (Electronic Health Record), a GP system, or the LSP, then FHIR support is not a luxury — it's a prerequisite. Much standard software does not support this, or does so incompletely. Custom software can build this in, but it increases complexity and costs.

Always ask explicitly in agency conversations: have you built FHIR integrations before? Do you have references in healthcare? An agency that is vague about this has probably not done it.

Common applications

Not all healthcare software is equally complex. A few common use cases, ranked by complexity:

Patient portal — A secure environment where patients can view appointments, fill in questionnaires, or send messages. Relatively manageable in scope, but requires GDPR compliance, DigiD integration, and good UX for a diverse user group.

Planning system for healthcare professionals — Schedules, appointments, availability. The challenge lies in complex planning logic (part-time contracts, specializations, locations) and integration with existing HR or ECD systems.

Care record or ECD — The most complex type. Structured recording of care plans, treatment data, medication. Requires standardization via FHIR, robust auditing, and often integration with external systems such as pharmacy software or the LSP.

Reporting to healthcare authorities — Many healthcare organizations must periodically report to the Dutch Healthcare Authority (NZa) or health insurers. Software that automates this must align exactly with the required DBC codes and declaration formats.

Why healthcare software costs more

The price difference between a regular web application and healthcare software has three causes.

Compliance overhead — Documentation, security audit, penetration testing, and demonstrably meeting NEN 7510 requirements cost extra time. This is work that is not visible in the end-user interface, but is necessary to put the system into use.

Integration complexity — Connections with EHR systems, UZI infrastructure, LSP, or FHIR endpoints are technically demanding. They are not standard API connections — they require certificates, specific protocols, and extensive testing.

Testing requirements — In healthcare, errors can have direct consequences for patient safety. This requires a more extensive testing strategy, including functional acceptance tests with end users (healthcare professionals), and sometimes certification as a medical device under the MDR (Medical Device Regulation).

Realistic budget indications

Different budget standards apply to healthcare software than to regular custom work:

• Patient portal (basic): €40,000 – €70,000. Including DigiD, secure messaging, appointment overview, and GDPR compliance. Without EHR integration.
• Patient portal with EHR connection: €80,000 – €140,000. Depending on the EHR and the interfaces available.
• Planning system: €60,000 – €120,000. Heavily dependent on planning complexity and number of integrations.
• Full ECD or EHR: €150,000 – €400,000+. This is custom work in the heaviest category. Expect a trajectory of 9 to 18 months with a multidisciplinary team.

On top of the build costs come ongoing costs: hosting (preferably in the Netherlands or the EU, on certified infrastructure), maintenance, annual security reviews, and any recertification.

The pitfalls that affect healthcare organizations most

Choosing an agency without healthcare references. Technically, many agencies can build an application. But an agency that has never worked in the healthcare sector doesn't know the compliance requirements from the inside. The result: you pay for a learning process that the supplier charges to your account.

Postponing compliance until after the build. Security and GDPR compliance are not a coat of paint you apply afterwards. Whoever builds this in after the first release is effectively rebuilding the system. Plan compliance as a first-class requirement, not an afterthought.

Not accounting for changes in legislation. The healthcare sector is digitalizing rapidly, and legislation is evolving with it. Systems that comply today may need to be adjusted in two years. Ensure there is a maintenance contract and that the agency is available for the long term.

Forgetting the user. Healthcare professionals are busy. A system that doesn't work intuitively won't be used — regardless of how much it cost. Invest in user research and test early with real healthcare providers and patients.

Finding the right agency

Ask agencies in conversations for concrete references in the healthcare sector. Not just "we've done something in healthcare before," but: which system, for which organization, with which integrations, and what were the compliance requirements? Also ask about the data processing agreement — an agency that can't talk about this directly has little experience with GDPR in healthcare.

Check whether the agency is familiar with NEN 7510, FHIR, and the Dutch healthcare infrastructure. These are not bonus points — they are basic qualifications for this type of work.

Building healthcare software is complex, but it's manageable if you know what you're buying. The organizations that successfully digitalize are not the organizations with the largest budget — they are the organizations that find the right partner and ask the right questions.