Industries
Software quality in Healthcare
In healthcare software the test record is part of the product. A reviewer does not want assurance that something was tested — they want to see what was tested, when, by whom, and what happened to the defects that were found.
What shapes Healthcare software
What tends to go wrong
Testing has to be evidence, not activity: an auditor wants the record of what was tested and when, not an assurance that it was.
Access control spans clinicians, administrators, patients and integrations, and the damaging bugs are in the combinations nobody enumerated.
Integration surfaces — scheduling, records, lab and device feeds — fail at the seams between systems, where neither vendor owns the test.
Data handling has to hold up under scrutiny across retention, export and deletion, long after the feature that created the record shipped.
What binds you
GDPR — Article 9
Health data is a special category, which raises the bar on lawful basis, access control and minimisation. The practical consequence for a delivery team is that a production restore into staging is not a shortcut, it is processing special-category data, and it needs the same controls the production system has.
EU MDR / IVDR
Software can itself be a medical device. Rule 11 of the MDR sweeps in software intended to provide information used for diagnostic or therapeutic decisions, and MDCG 2019-11 is the guidance on qualification and classification. If you are in scope, verification and validation stop being engineering hygiene and become regulatory evidence.
NIS2
Health is an Annex I sector, so providers above the size threshold are essential entities: risk-management measures, supply-chain security, and incident notification on a clock. Transposition dates vary by member state — check where your entity actually sits rather than where your customers do.
Engineering practice, not legal advice.
How we work on it
What that means in practice
We work in a way that leaves a trail: documented test cases, recorded execution, and defect reports that read as evidence rather than as chat messages. Security assessment focuses on the paths where patient data actually moves — authentication, authorisation between roles, and every integration boundary — and the report is written to be handed to a reviewer, not just to your engineers.
Related reading
- Application security
OWASP assessment vs penetration test: which one your requirement names
Suppliers use the two terms interchangeably. Contracts, insurers and regulators do not. How to read the clause you have been given before you buy the wrong thing.
- Application security
Broken object level authorisation: the API risk no scanner will find for you
The top entry on the OWASP API Security Top 10 returns a perfectly normal 200 to the wrong person. Why tooling cannot see it, and how the testing actually runs.
- Application security
Triaging dependency vulnerabilities: what to do with 400 open alerts
A scanner dashboard nobody opens is worse than no scanner. How to sort advisories by whether they can actually be triggered, and how to record the ones you defer.
FAQ
Healthcare questions we hear often
What does “documented testing” actually mean in a deliverable?
Written test cases with expected results, a record of each execution against a build, and defect reports that carry reproduction steps, severity reasoning and a resolution trail. The distinguishing feature is that a reader who was not there can reconstruct what was covered and what was not. That is what makes it usable as evidence rather than as reassurance.
Can you test our product without access to real patient data?
Yes, and it is the preferred arrangement. Realistic data can be synthesised or derived, and the cases that matter — role boundaries, integration seams, retention and deletion — are about structure and permissions rather than about the content of any particular record. Where production-like data is genuinely necessary, that becomes a scoped conversation with a processing agreement behind it, not an ad-hoc export.
Do you certify our software as compliant?
No. We are not a notified body and an assessment is not a conformity assessment. What we produce is engineering evidence — test records, security findings, remediation verification — that supports your own compliance work. Anyone offering to make you “MDR compliant” with a test cycle is selling you the wrong document.
Which access-control failures do you look for first?
The combinations nobody enumerated. A product spanning clinicians, administrators, patients and machine integrations has far more role pairs than anyone wrote acceptance criteria for, and the damaging findings live in the pairs that were never considered — a patient reaching another patient’s record through an integration endpoint, an administrator scope that quietly includes clinical data.
Contact
Building for healthcare?
Tell us what you are shipping and where it worries you. You will get a considered reply from an engineer, not an autoresponder.