Custom healthcare software that complies with NEN 7510, the Dutch standard for information security in healthcare. Audit logging, role management, encryption and data residency are built in from the first design, not bolted on afterwards.
NEN 7510 is the Dutch standard for information security in the healthcare sector: a healthcare-specific supplement to ISO 27001, mandatory for any organisation processing personal health data. The standard consists of three parts: NEN 7510-1 describes the management system, NEN 7510-2 the concrete control measures, and NEN 7510-3 sets requirements for audit logging.
In practice, we often see software that is "made compliant later" retain structural shortcomings: audit logs the owner can switch off themselves, role models patched after the fact, or cloud choices that wouldn't pass a Schrems II assessment. We build the other way round: the compliance architecture first, then the features around it.
We work with healthcare organisations (hospitals, mental health and long-term care), GP cooperatives, dentists and physiotherapists going digital, pharmacists, EHR vendors, health insurers, healthcare IT suppliers and health-tech start-ups bringing their first medical product to market. For research institutions, including university medical centres, RIVM and ZonMW consortia, we build platforms with pseudonymisation, purpose limitation and strict sub-processor control. We don't build EHR replacements for ChipSoft, Epic, CGM, HiX or Topicus, but we do build the modules and portals that run alongside those systems and exchange data via HL7 FHIR or MedMij.
The standard is the same, but the scope of software in healthcare varies greatly. In the first conversation we advise which approach suits your situation. A patient portal calls for something different than a telemedicine platform or a research environment with pseudonymisation.
A secure environment where patients can view record items, book appointments, complete questionnaires or communicate securely with their care provider. Log in with DigiD or MedMij, role-based access, an immutable audit trail and a patient-rights flow for access, correction and data portability.
A dedicated healthcare module alongside the EHR: a referral integration, a telemedicine consultation, questionnaires with clinical scoring, or a module for specific conditions. Includes HL7 FHIR integrations, encryption at rest and in transit, sub-processor management and a DPIA process with your DPO or CISO.
A research platform with pseudonymisation and purpose limitation, or an AI tool that falls under the MDR and the AI Act alongside NEN 7510. A mission-critical setup with IaC, security scans (Checkov, Trivy), an external pen test before go-live and a mapping document that demonstrably covers the standard for your organisation.
A working platform plus the documentation you need to demonstrate NEN 7510 requirements, to your own quality function, an external auditor or the Dutch Data Protection Authority.
Four patterns in which we support healthcare organisations. Standard EHR replacement is not among them. For ChipSoft, Epic, CGM or HiX, we build modules around the system, not alternatives to it.
The EHR handles the core, but for a referral portal, questionnaires with scoring or a patient journey app, you run into its limits. You want something that connects via HL7 FHIR but sits under your own brand and compliance.
You are building a digital therapeutic, a telemonitoring app or an AI diagnostic tool. NEN 7510 is unavoidable for sales to hospitals, and investors and buyers explicitly ask for it.
An academic medical centre, research institute or consortium that needs to analyse data from multiple care providers. Pseudonymisation, purpose limitation and watertight access control are not optional.
An existing healthcare application still runs on-premise or in a setup that no longer passes the standard assessment. You want to move to a modern EU cloud architecture without losing your compliance footing.
A conversation in which we understand the healthcare context: which data, which target group, which EHR, which partners. We identify early on whether, alongside NEN 7510, MDR, the AI Act or the WGBO also play a role.
Together with your DPO or CISO we map the architecture against NEN 7510-2 and NEN 7510-3. Data flows, sub-processors, encryption strategy, key management and the audit log design are settled before we write any code.
Two-weekly sprints with working builds. Secure-by-default frameworks, automated security scans (Checkov, Trivy, dependency checks) in the pipeline, and a DPIA update for every feature that touches personal health data.
Before go-live we have an external security firm pen test the system. Findings go back into a sprint, followed by a retest. In parallel we finalise the NEN 7510 mapping document so your audit process starts with the evidence in place.
Phased rollout, training for functional administrators and end users and, if you wish, ongoing management including an annual pen test, patch management and quarterly DPIA reviews for new features.
NEN 7510-2 describes control measures at a high level. These are the concrete implementations we build into every healthcare application, regardless of scope. The tailoring lies in how they come together, not in whether they are there.
A role model based on the principle of least privilege, MFA mandatory for all users with access to patient data, session management with automatic logout and device binding where needed. Login via DigiD, MedMij or the care organisation's identity provider.
AES-256 or stronger for data at rest, TLS 1.2+ for data in transit, client-side encryption for the most sensitive fields, and a key management strategy in which keys are separated from the encrypted data, often with KMS or HSM integration.
An audit log compliant with NEN 7510-3: write-only storage, a separate domain, not switchable off by functional administrators, with configurable retention and alerting rules for suspicious patterns (bulk queries, access outside office hours, access to one's own record).
Self-service or guided flows for access, correction, restriction, erasure and data portability. In a care context, erasure often means restricting access while retaining data for the statutory retention period, and we build that nuance in carefully.
An inventory of all cloud and SaaS providers in the chain, data processing agreements in order, a Schrems II assessment for each provider with US ownership, and periodic review of the sub-processor register.
Incident response runbook with escalation matrix, pre-drafted notification templates for the Dutch Data Protection Authority (Autoriteit Persoonsgegevens), and rehearsed restore procedures, so that you can act within the stipulated deadlines in practice.
NEN 7510 rarely stands alone. Depending on what the software does, additional frameworks come into play. A telemonitoring app that raises alarms is a medical device (MDR). An AI tool that predicts risk falls under the AI Act. A platform that exchanges patient data must comply with MedMij, and interoperability almost always runs via HL7 FHIR, or for legacy integrations via HL7v3 or EDIFACT.
We map out these overlays before we begin, so that the design supports them rather than conflicts with them. An MDR classification of class IIa affects the development process (technical file, post-market surveillance), not just a box to tick. For enterprise healthcare contexts, we see this layering frequently in our enterprise software projects, and for research platforms in our broader healthcare software approach.
What we explicitly don't do: tick off NEN 7510 as a checklist and then resume feature work without any connection to it. The standard is an attitude, and we build that attitude structurally into the architecture, the development process and the team's governance.
What healthcare clients usually want to know before we begin.
A no-obligation introductory call of half an hour. We listen to your healthcare context (which data, which EHR, which partners) and give you direction on where the compliance risks and solutions lie. No sales pitch, just concrete advice. We also carry out similar compliance projects for KYC/AML compliance in other regulated sectors.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
