Software that can hold patient data

Healthcare software fails in a particular way. It is not usually that the software does not work. It is that it works, and then somebody asks where the data is stored, or who can see the audit log, or what happens when the model is wrong, and there is no good answer. At that point the choice is a rebuild or a shelved project.

We build it the other way round. The compliance questions get answered in the first week, in the architecture, while changing them is still cheap.

Who this is for

• Clinics and practices that need something their practice management system does not do, and cannot wait for a vendor roadmap.
• MedTech and digital health startups building a first product and needing the regulatory path designed in rather than discovered.
• Health and lifestyle professionals whose work is genuinely clinical in character but whose software is currently a spreadsheet.

What we build

Patient portals and practice platforms. Intake, records, appointments, secure messaging, invoicing, and the administrative machinery that turns a practice into something that scales past one person's memory.

Clinical tooling. Structured data capture, reporting, and the audit trail that makes it defensible. Usually the difference between data you have and data you can act on.

Health and lifestyle applications. Patient- or client-facing apps, including installable web apps that work offline and lock behind biometrics.

AI decision support, carefully. Drafting, summarising, triage suggestions and document extraction, with a human review step designed in, not offered as a setting.

Integration. HL7 v2, FHIR and vendor APIs, so what you build talks to what you already run.

What compliance-first actually means here

It is a set of concrete engineering decisions, not a statement of intent:

• Data minimisation as an architecture, so you are not storing things you never needed and cannot now justify.
• Encryption in transit and at rest, with key handling that survives a question about it.
• Role-based access that reflects clinical reality, including the emergency case where someone needs access they do not normally have: granted, logged, and reviewable.
• A tamper-evident audit trail: who accessed which record, and when.
• EEA data residency as a configuration you control.
• Data subject rights built as features (export, deletion, consent) rather than as a manual job for whoever is on support that week.
• Lifecycle documentation aligned with IEC 62304 where the software is or may become a device, so evidence accumulates as you build instead of being reconstructed later.

A word on wording: we design to these standards and produce the evidence for them. We are not a certification body and we do not hold certifications on your behalf. Where a claim needs a notified body, it needs a notified body.

What shapes the cost

We do not publish a price for medical work, and you should be wary of anyone who does. The range between a practice tool and a CE-marked device is enormous. What moves it:

• Whether it is a medical device. The single biggest factor. Device classification brings a quality management system, clinical evaluation, technical documentation and a notified body, a different order of project entirely.
• Whose data, and how much of it. Health data raises the bar on nearly every technical decision you will make.
• What it has to integrate with. A clean FHIR endpoint is a very different proposition from a legacy HL7 v2 feed, or from no interface at all.
• Whether AI sits in the clinical path or beside it, which changes both the engineering and the regulatory position.
• How many languages, since clinical copy has to be right in every one.

Tell us what you want to build and whether patient data is involved. We will come back with a written scope, a fixed price and a date, and if what you are describing is a device and you have not budgeted for that, we will say so before you spend anything.

Further reading

• Software as a Medical Device under the EU MDR
• The EU AI Act for medical device software
• NEN 7510 and GDPR for healthcare software
• The European Health Data Space, explained
• What custom medical software costs

Working specifically in the Dutch market? See medical software development in the Netherlands.

Frequently asked questions

Is what we want to build a medical device? It depends on what it claims to do. Software with a medical purpose of its own (diagnosis, monitoring, prediction, prognosis or treatment) is generally a device under the EU MDR, and under Rule 11 most clinical software lands in Class IIa or above, which means a notified body. Software that stores, communicates or supports without interpreting usually is not. The boundary is a design decision as much as a legal one, and it is worth deciding deliberately at the start rather than discovering it later.

Are you a notified body, or can you certify us? No. We are an engineering partner. We build the software, produce the technical documentation and evidence a conformity assessment needs, and work alongside your quality and regulatory people. The assessment itself is done by your notified body. Anyone telling you they can certify you is telling you something untrue.

What does NEN 7510 actually require of a supplier? NEN 7510 is the Dutch information security standard for healthcare. It is not a law in itself, but Dutch legislation and regulatory oversight make it effectively mandatory for organisations handling medical personal data, and it applies to suppliers and processors as well as care providers. In practice it means encryption in transit and at rest, role-based access, tamper-evident logging, an information security management system rather than a checklist, and processor agreements down your supply chain.

Where will the data be stored? In the EEA, unless there is a compelling reason otherwise that you have agreed to in writing. For health data we default to European regions and design so that data residency is a configuration you control rather than an assumption buried somewhere in the stack.

How do you handle AI in clinical software? Human in the loop, by default. The model drafts; the clinician reviews and signs. That is partly good engineering and partly a deliberate way of keeping accountability where it belongs. It also affects classification: a system that hands a clinician a draft they must approve is a different regulatory proposition from one that decides. We design that boundary explicitly and document why it sits where it does.

Can you work with our existing EHR or practice system? Usually, via whatever APIs and standards it exposes: HL7 v2, FHIR, or a vendor-specific interface. Where a system offers nothing we look at supported import and export routes before suggesting you replace it. Replacing a working clinical system is expensive, disruptive and rarely the cheapest way to solve the actual problem.