Medical Software Development: The UK Standards Guide.

Medical software development is the practice of building software for clinical use under a documented safety, risk and traceability regime, so the product can be certified, procured and deployed in a healthcare setting. The engineering is rarely the hard part. The evidence you produce alongside it usually is. Arch works on both sides of that line, from general healthcare software development through to devices carrying a regulatory claim.

Software that can hurt someone is a different trade.

Key Takeaways

• Medical software development is governed by intended purpose, not technology. A rules engine and a neural network making the same clinical claim carry the same classification.
• The UK layer is the one most guides miss: DTAC, DCB0129 and DCB0160, UKCA marking and the MHRA's reform programme sit on top of the international standards.
• Assurance is patchier than the paperwork suggests. Across 178 NHS organisations, only 17.3% of deployed digital health technologies were fully assured against both DCB0129 and DCB0160.
• Security is a live engineering constraint, not a policy annexe. UK healthcare logged roughly 264,000 cyber-attack events between January and May 2026, against 27,000 across all of 2025.
• Classification drives cost. Decide it before you design: retrofitting a safety case costs more than writing one.

What is Medical Software Development?

Medical software development covers any software written for a clinical purpose, from patient administration to diagnosis, monitoring and treatment. Only some of it is a medical device, and that distinction sets everything else.

Software as a Medical Device, or SaMD, performs a medical function on its own, without being part of a physical device. A triage algorithm is SaMD. A booking system for the same clinic is not, though both may sit in one product.

The commercial pull is real. The global SaMD market is forecast to grow from USD 38.02 billion in 2025 to USD 47.26 billion in 2026, a compound annual growth rate of 24.3%, according to The Business Research Company's 2026 report. The same pressure sits behind pharmaceutical software development, where the compliance burden is a close cousin of SaMD.

What separates medical software development from ordinary product engineering is that the regulator does not inspect your software. It inspects your evidence about your software. Requirements, hazards, design decisions, tests and releases all have to link to each other, and stay linked. The same discipline applies whether you are building a clinical product or a healthcare app development company would recognise as a companion tool.

Class A, B or C. The answer sets everything after it.

When Software Becomes a Medical Device

Intended purpose is the trigger. If you claim your software diagnoses, prevents, monitors, predicts, treats or alleviates disease or injury, it is very likely a device under the UK Medical Devices Regulations 2002. If you claim it schedules appointments, it is not.

Your marketing claim is part of the evidence: teams get caught out by ambitious copy long before their code.

Under EU MDR 2017/745 Rule 11, software intended to provide information used to take decisions for diagnostic or therapeutic purposes falls into Class IIa as a minimum. It rises to Class III where such decisions may cause death or irreversible deterioration in health, and to Class IIb where they may cause serious deterioration or require surgical intervention. Software intended to monitor physiological processes is Class IIa, or Class IIb where it monitors vital parameters and variation could pose immediate danger.

Rule 11 is broad by design. Most clinical decision support falls inside it.

The UK direction of travel is the same, and steeper. Under the incoming framework, most SaMD products move away from self-certifiable Class I towards higher risk classes, with recognition of CE-marked devices running until 30 June 2030. If your product self-certified as Class I, that assumption may not survive the transition.

The technical file is the product, as far as the regulator is concerned.

Which UK Standards Govern Healthcare Software?

Four layers stack, and most international guides cover only the first.

IEC 62304 sets the software lifecycle. It assigns each software item a safety class based on what happens if it fails and the failure is not mitigated: Class A where no injury is possible, Class B where non-serious injury is possible, Class C where death or serious injury is possible. The class sets how much architecture, unit verification and traceability you owe.

ISO 14971 governs risk management, and ISO 13485 the quality management system it all lives inside. For a device these are not extras; they are the container.

DCB0129 and DCB0160 are the NHS clinical risk standards. DCB0129 applies to you as manufacturer, DCB0160 to the organisation deploying your software. Both require a named Clinical Safety Officer, a hazard log and a clinical safety case report.

DTAC is the NHS assessment gate covering clinical safety, data protection, technical security, interoperability and usability. Not a certification, but you rarely sell into the NHS without passing it.

The gap between having these standards and meeting them is wide. A national study of 178 NHS organisations, published in the Journal of Medical Internet Research in October 2025, found only 17.3% of deployed digital health technologies were fully assured against both DCB0129 and DCB0160, leaving over 70% without documented safety assurance.

Most software already running in the NHS could not evidence its own clinical safety.

DCB0129 builds it. DCB0160 is whoever switches it on.

What is Changing in UK Regulation in 2026?

Three things, all of which touch your build plan.

NHS England updated the Digital Technology Assessment Criteria on 24 February 2026, cutting the form by around 25%, with the previous version withdrawn after 6 April 2026. A shorter form is not a softer one.

The MHRA published draft Medical Devices (Amendment) Regulations in June 2026, introducing Predetermined Change Control Plans for software and AI, and tighter vigilance timelines including 2-day reporting for serious public-health threats. A Predetermined Change Control Plan lets you specify in advance how a model may change and how you will verify it, so routine retraining does not mean a fresh submission.

There is a new route in, too. UK international reliance lets manufacturers leverage FDA, TGA and Health Canada approvals. Temper the expectation: comparable schemes drew around 14% of applications in their first two years.

Alongside this sits the MHRA's AI-as-a-medical-device framework, with an international reliance element expected by autumn 2026, raising cybersecurity assurance and controlled model updates into your safety and performance claims rather than leaving them in an IT annexe.

The model learns. The lifecycle still applies.

Compliance by Design: A Medical Software Development Workflow

Compliance-by-design means the regulatory artefacts are outputs of the work, not a project that starts after it. In practice, medical software development follows a loop. It also has to fit into how the build itself is run, not sit beside it as a separate workstream.

Fix intended purpose first. One paragraph, written down, agreed by clinical and commercial. It determines classification, and classification determines everything downstream.

Classify before you architect. Establish the device class and IEC 62304 safety class per software item. Doing this late is what makes rework expensive: you cannot bolt traceability onto a codebase never partitioned for it.

Partition to contain the class. Isolate the clinical function behind a documented interface so the surrounding platform does not inherit its safety class. Third-party libraries are Software of Unknown Provenance and need their own justification.

Run the hazard log as a live artefact. Hazards, causes, controls, and the requirement or test each control maps to. Update it in the sprint, not at submission.

Verify against requirements. Every requirement traces to a test, every result retained. Automate evidence generation in your pipeline or it will not survive contact with a deadline.

Build post-market surveillance in. Logging, incident triage and reporting timelines are engineering requirements, not support policy. This is the same territory covered by the work we do across the health sector more broadly.

Traceability separates a specialist from a general agency, and it is where Arch aligns engineering with clinical-safety requirements on UK health tech app development projects.

Someone else's code, your hazard log.

Architecture and Cross-Platform Frameworks

Can you use Flutter or React Native for regulated medical software development? Yes, with conditions.

Nothing in IEC 62304 names a language or framework. It requires that you can trace a requirement to the code implementing it and the test proving it, and that you justify every third-party component you did not write. A cross-platform framework is a large SOUP item. That is a documentation cost, not a prohibition.

Where cross-platform gets harder is at the edges: real-time telemetry, Bluetooth from a sensor, background execution, precise thread control. If the clinical function depends on deterministic timing at the hardware boundary, native gives you fewer things to argue about.

For Class A and much of Class B, cross-platform is usually the pragmatic call. For Class C, the hours spent evidencing the runtime tend to erase the savings.

Architectural rework nearly always traces to one of two causes. The team classified late and found the regulated function entangled with everything else. Or interoperability was treated as an integration task rather than a design constraint, and HL7 FHIR solved the syntax while leaving semantic mapping across EHR systems wide open.

Compliance by design, or compliance by archaeology.

Data Security and Avoiding Breaches

Health data is special category data under UK GDPR, and the threat picture has changed sharply. UK healthcare recorded roughly 264,000 cyber-attack events from January to May 2026, against 27,000 in all of 2025, a tenfold rise, with 41% of those events targeting the Log4Shell vulnerability.

Log4Shell was disclosed in December 2021. The dominant attack against UK healthcare in 2026 is a known, patchable flaw over four years old.

That tells you where the effort belongs. Dependency inventory and patching cadence, enforced in the pipeline. Encryption in transit and at rest, with keys you can rotate. Role-based access at the service boundary, not just the interface. Audit logging a clinical safety investigation can read. Data residency decided deliberately, because hosting is a regulatory choice in UK healthcare.

None of it is exotic. It is unglamorous work that competes badly with features until it does not.

Cost, Timeline and Team for a Compliant Build

Arch does not publish fixed price bands for regulated work, because the number is set by classification rather than feature count. The drivers are knowable even when the figure is not.

What moves the cost: the device class and IEC 62304 safety class, whether an ISO 13485 quality management system exists or must be stood up, the number of EHR integrations and how open those vendors are, whether AI components need a change control plan, and whether an Approved Body assessment is in scope.

Plan for this pattern: the regulated portion carries documentation and verification overhead scaling with safety class, not lines of code. A Class C component in a small product can cost more to evidence than the rest of the application costs to write.

Team shape matters as much as budget. Medical software development needs a Clinical Safety Officer, quality management ownership, and engineers who have produced a technical file before. Buying those late, under submission pressure, breaks budgets.

Choosing a Medical Software Development Partner

Ask for artefacts, not credentials. Four questions separate real experience from a case study deck.

Can they show a hazard log and clinical safety case report from delivered work, redacted as needed? Who is their Clinical Safety Officer, and are they named on projects or borrowed for pitches? How do they generate traceability evidence, and is any automated? What have they integrated with in UK primary or secondary care, and what went wrong?

A partner who answers those crisply has done regulated work. One who redirects to their tech stack has not. NHS Trailblazers is one example of that kind of delivered, evidenced work.

Medical software development rewards teams that treat the regulator as a design input from day one. The standards are knowable, the UK layer learnable, and the evidence burden survivable if built in rather than reconstructed.

Frequently Asked Questions

What standards govern the development of software used in healthcare?

Four layers apply to UK medical software development. IEC 62304 sets the software lifecycle and assigns safety Class A, B or C. ISO 14971 governs risk management, ISO 13485 the quality management system. DCB0129 and DCB0160 are the NHS clinical risk standards. DTAC is the NHS assessment gate covering safety, data protection, security, interoperability and usability. Device software also needs UKCA marking or, until 30 June 2030, a recognised CE mark.

When does software count as a medical device?

Intended purpose decides it, not technology. Software that diagnoses, prevents, monitors, predicts, treats or alleviates disease is very likely a device. Under EU MDR Rule 11, software providing information used for diagnostic or therapeutic decisions is Class IIa at minimum, rising to Class III where a decision could cause death or irreversible deterioration. Administrative and wellness functions usually fall outside scope, though marketing claims can pull them back in.

Can I use cross-platform frameworks for regulated medical software?

Yes. IEC 62304 mandates no language or framework. It requires traceability from requirement to code to test, and justification of third-party components, which a cross-platform framework becomes as Software of Unknown Provenance. That is a documentation cost, not a bar. For Class A and much of Class B, cross-platform is pragmatic. For Class C, or where the clinical function needs deterministic timing at the hardware boundary, native is usually cheaper once evidence work counts.

What is changing in UK medical device software regulation in 2026?

Three shifts. NHS England updated DTAC on 24 February 2026, cutting the form by around 25% and withdrawing the previous version after 6 April 2026. The MHRA published draft Medical Devices (Amendment) Regulations in June 2026, introducing Predetermined Change Control Plans for software and AI plus 2-day reporting for serious public-health threats. New international reliance routes allow leverage of FDA, TGA and Health Canada approvals, though comparable schemes drew about 14% of applications early.

How long does a compliant medical software build take?

Medical software development timelines depend on classification more than scope. The regulated portion carries overhead scaling with IEC 62304 safety class, so a small Class C component can take longer to evidence than a larger Class A application takes to build. An ISO 13485 quality management system, and any Approved Body assessment, add materially. Teams that classify before architecting hit predictable timelines. Teams that classify late rebuild.

Why do regulated healthcare builds so often need architectural rework?

Two causes dominate. The team classified late, so the regulated function ended up entangled with unregulated features and the platform inherited the highest safety class. Or interoperability was treated as integration rather than architecture: HL7 FHIR resolves the syntax, but semantic differences between EHR systems still need mapping nobody budgeted for. Both are avoidable by fixing intended purpose and classification before design.

About the Author

Hamish Kerry is the Marketing Manager at Arch, where he's spent the past six years shaping how digital products are positioned, launched, and understood. With over eight years in the tech industry, Hamish brings a deep understanding of accessible design and user-centred development, always with a focus on delivering real impact to end users. His interests span AI, app and web development, and the transformative potential of emerging technologies. When he's not strategising the next big campaign, he's keeping a close eye on how tech can drive meaningful change.

You can catch up with Hamish on LinkedIn

Sources

1. The Business Research Company, Software As A Medical Device (SaMD) Market Report 2026, 1 July 2026. https://www.thebusinessresearchcompany.com/report/samd-software-as-a-medical-device-global-market-report
2. Journal of Medical Internet Research, Digital Health Technology Compliance With Clinical Safety Standards in the NHS in England: National Cross-Sectional Study, 31 October 2025. https://pmc.ncbi.nlm.nih.gov/articles/PMC12619009/
3. Assuric, DTAC 2.0: Key Changes and What Healthtech Teams Need to Know, 26 February 2026. https://www.assuric.com/blog/dtac-2.0-explained
4. TrustedTraceMed, UKCA marking for medical software: new UK framework explained, 22 March 2026. https://trustedtracemed.com/resources/ukca-medical-software-2026.html
5. PatientGuard, The MHRA 2026 Regulatory Roadmap Explained, 2 June 2026. https://patientguard.com/the-mhra-2026-regulatory-roadmap-explained/
6. Med-Tech Insights, A Pivotal Year for Regulatory Reform and Innovation, 21 April 2026. https://med-techinsights.com/2026/04/21/a-pivotal-year-for-regulatory-reform-and-innovation/
7. Periculo, MHRA's AI Medical Device Framework: What NHS Suppliers Need to Know About Cybersecurity and Compliance, 7 January 2026. https://www.periculo.co.uk/cyber-security-blog/mhras-ai-medical-device-framework-what-nhs-suppliers-need-to-know-about-cybersecurity-and-compliance
8. Infosecurity Magazine, UK Healthcare Sector Records Tenfold Increase in Cyber-Attacks, 30 June 2026. https://www.infosecurity-magazine.com/news/uk-healthcare-tenfold-increase/
9. Arch, Health Tech App Development UK, 14 July 2026. https://wearearch.com/blog/health-tech-app-development-uk