NHS-Ready Software Development: What NHS Buyers Require

Quick Answer: What Is NHS-Ready Software Development?

NHS-ready software development means building digital health technology that meets the NHS’s mandatory clinical safety, data protection, information governance, and interoperability standards — including DCB0129, DCB0160, and DTAC. Without this, your software cannot be legally procured or deployed by any NHS organisation in England, no matter how good the technology is.

Getting NHS compliance wrong is not a paperwork problem. It is a patient safety problem — and the NHS treats it that way.

A landmark 2025 study found that more than 10,000 digital health technologies in use across NHS trusts in England had never been formally assessed against the mandatory clinical safety standards DCB0129 and DCB0160. These are not optional guidelines. Under the Health and Social Care Act 2012, NHS organisations cannot legally procure a digital health technology without DCB0129 assurance, nor deploy one without DCB0160 assurance.

If you are building software for the NHS — or planning to — understanding what NHS-ready software development actually requires is the difference between a product that gets through procurement and one that gets shelved.

NHS Software Compliance: By the Numbers

10,000+ — NHS digital health tools never assessed against DCB0129 or DCB0160 (2025 study)

£10B+ — Cost of the NPfIT failure that created today’s compliance framework

25% — DTAC question set reduction after the February 2026 update

6–18 months — Compliance timeline when built correctly from day one

6 Apr 2026 — Date updated DTAC became mandatory 

What Does “NHS-Ready” Actually Mean?

The term gets used loosely. Vendors claim their software is “NHS-ready” on the basis of having an NHS logo on their website or having sold one licence to one trust. That is not what it means.

Genuine NHS-ready software development means your product has:

• • Met the clinical safety requirements of DCB0129 (for manufacturers) and is ready to support deploying trusts through DCB0160
  • Completed — or is ready to complete — the Digital Technology Assessment Criteria (DTAC) covering clinical safety, data protection, technical security, interoperability, and usability
  • Demonstrated compliance with the Data Security and Protection Toolkit (DSPT) and UK GDPR / Data Protection Act 2018
  • Implemented recognised interoperability standards such as HL7 FHIR, where data exchange with NHS systems is required
  • Achieved or is actively working towards Cyber Essentials Plus certification
  • Appointed a qualified Clinical Safety Officer (CSO) — a registered clinician with formal training in clinical risk management

None of these are ticked off at the end of a project. They need to be designed in from the very first line of code.

Why Did the NHS’s Last Big IT Programme Fail — and What Does That Mean for You?

It is worth knowing the history, because it shapes how the NHS approaches digital procurement today.

The National Programme for IT (NPfIT), launched in 2002 with an initial budget of around £6.2 billion, was meant to deliver a unified electronic patient record system across the NHS. It was described as the world’s largest civilian IT project. It was shelved in 2011 after costs reportedly exceeded £10 billion with core objectives undelivered.

The reasons it failed are instructive:

• • Top-down design with almost no involvement from the clinicians and staff who would actually use the systems
  • Contracts awarded before the scope was clear, leaving critical parameters undefined
  • Underestimated scale and complexity, particularly around integrating new systems with existing NHS infrastructure
  • Vendor dependence — a handful of large contractors who struggled to deliver, with limited accountability
  • No effective clinical safety framework to catch problems before deployment

The NHS learned from this — painfully. The result is the rigorous, multi-layered compliance framework that exists today. DCB0129, DCB0160, DTAC, and the DSPT all exist partly because of what went wrong with NPfIT.

The lesson for any software team working with the NHS: compliance is not bureaucracy for its own sake. It is the NHS’s defence against repeating a catastrophically expensive and patient-harmful mistake.

DCB0129 Explained: What Manufacturers Must Do

Definition: DCB0129 is the clinical risk management standard for manufacturers of health IT systems. Published by NHS England under the Health and Social Care Act 2012, it requires manufacturers to identify, assess, and mitigate clinical risks throughout the development lifecycle of a health IT product. Compliance is mandatory for any software being supplied to the NHS.

DCB0129 requires manufacturers to:

• • Establish a Clinical Risk Management System — documented processes for identifying and controlling clinical risk at every stage of development
  • Appoint a Clinical Safety Officer (CSO) — a clinician registered with a professional body (such as the GMC or NMC) who has completed clinical risk management training
  • Produce a Hazard Log — a formal record of every identified hazard, its potential clinical impact, the controls applied, and the residual risk
  • Compile a Clinical Safety Case Report (CSCR) — the structured argument that your system has been rendered safe for its intended clinical use

Crucially, DCB0129 is not a one-time exercise. Compliance must be maintained through product changes, updates, and in response to any clinical incidents reported after deployment.

If your software cannot meet DCB0129, it cannot legally enter the NHS market. That is not a grey area.

DCB0160 Explained: What Deploying Organisations Must Do

Definition: DCB0160 is the clinical risk management standard for NHS organisations that deploy health IT systems. It requires each deploying trust or organisation to assess the specific clinical risks of implementing a given technology in their own environment — even if the manufacturer already holds DCB0129 assurance.

This is a critical distinction. One product, one DCB0129 clinical safety case. But every trust that deploys that product must conduct its own DCB0160 assessment. The risks of running a piece of software in a busy A&E department are different from running the same software in a community mental health service.

DCB0160 assessments consider:

• • • The specific risks arising from implementation in that organisation’s clinical environment
    • Risks during use, updates, and eventual decommissioning
    • Additional hazards created by the interaction between the new system and existing legacy systems

As a software manufacturer, you cannot do DCB0160 for an NHS trust. But you can make it significantly easier by producing thorough DCB0129 documentation that gives deploying trusts a clear foundation to build from.

DCB0129 vs DCB0160 at a Glance

What Is the DTAC — and Why Did It Change in 2026?

Definition: The Digital Technology Assessment Criteria (DTAC) is NHS England’s national baseline framework for assessing digital health technologies before NHS procurement. Introduced in 2021, it consolidates requirements across five areas: clinical safety, data protection, technical security, interoperability, and usability and accessibility.

Think of the DTAC as the full compliance passport your product needs to be seriously considered in any NHS procurement. NHS England revised the DTAC in February 2026, cutting the question set by 25% and removing duplication with other frameworks. The updated form became mandatory from 6 April 2026.

The five pillars of the DTAC are:

1. Clinical Safety Demonstrate DCB0129 compliance. A new decision tree in the 2026 update helps manufacturers determine whether their product qualifies as a medical device — an area that had previously caused significant confusion during procurement.
2. Data Protection Evidence of ICO registration, a completed Data Protection Impact Assessment (DPIA), and compliance with UK GDPR and the Data Protection Act 2018. Patient data governance is non-negotiable.
3. Technical Security Cyber Essentials Plus is typically required. Following the June 2024 Synnovis ransomware attack — which disrupted over 10,000 hospital appointments — NHS England has significantly intensified cybersecurity scrutiny across procurement. If your security posture is not demonstrably robust, procurement conversations will be short.
4. Interoperability Your APIs must use recognised standards such as HL7 FHIR. The 2026 DTAC update now requires manufacturers to explain why their chosen technical interfaces are appropriate — not just list them. Where your product uses NHS Number, NHS Login integration is expected unless there is a justified alternative.
5. Usability and Accessibility Products must meet the NHS Service Standard and WCAG 2.1 accessibility guidelines. This is about real-world usability for NHS staff and patients — not just ticking a box.

NHS Information Governance: The Foundation Everything Else Sits On

Information Governance (IG) is not a separate compliance stream. It runs through every other requirement.

The Data Security and Protection Toolkit (DSPT) is the NHS’s annual self-assessment for organisations handling NHS patient data. Suppliers working with NHS data are typically expected to have completed and published a DSPT assessment. Completion of the DSPT is integrated into the DTAC data protection requirements.

From a practical development standpoint, NHS IG requirements mean:

• • Patient data must be processed lawfully under UK GDPR, with appropriate legal bases documented
  • Data must not leave approved jurisdictions without explicit controls
  • Access controls, audit logging, and data minimisation principles must be built into the product architecture — not added after the fact
  • Any breach or incident response process must be documented and tested

Teams that treat IG as a final-stage exercise almost always find themselves going back to rearchitect fundamental components of their product. It is far cheaper to design for it from day one.

How to Achieve NHS Software Compliance: A Practical Roadmap

The compliance journey looks complex from the outside. In practice, it follows a logical sequence — as long as you start early.

Step 1: Determine whether your product is a medical device The MHRA’s guidance on Software as a Medical Device (SaMD) determines whether your product needs UKCA marking in addition to DTAC compliance. The 2026 DTAC update includes a step-by-step decision tree to help with this assessment. Get this wrong and you will face significant delays in procurement.

– If your product uses AI, this step is more complex than it looks.

An AI-based triage tool, clinical decision-support feature, or diagnostic algorithm is likely to be classified as a Software as a Medical Device — triggering UKCA marking requirements on top of DCB0129. The 2026 DTAC update added a decision tree specifically because this classification was causing procurement delays. Do this assessment early. 

Step 2: Appoint a Clinical Safety Officer Your CSO must be a registered clinician. If you do not have one in-house, this can be provided by a specialist third party. The CSO is not a figurehead — they are actively responsible for overseeing clinical risk management activities and signing off documentation.

Step 3: Begin clinical risk management from the earliest development stage This is the most common mistake made by teams new to NHS-ready software development. DCB0129 requires risk management to start at the beginning of the development lifecycle, not be retrofitted at the end. The Hazard Log should be a living document updated throughout.

Step 4: Complete the DTAC self-assessment Work through all five DTAC pillars with supporting evidence. Each version of your product requires its own assessment. Budget time for this — it is detailed.

Step 5: Ensure your NHS data security posture is demonstrable Cyber Essentials Plus and DSPT completion are expected. If you are working with NHS patient data, ICO registration and a completed DPIA are mandatory.

Step 6: Build for interoperability from the start If your product will integrate with NHS systems — electronic health records, NHS login, the Personal Demographics Service (PDS), or EMIS Web / SystmOne — the architecture decisions you make early will determine how smoothly those integrations go. HL7 FHIR is the standard. SNOMED CT is the required clinical terminology. These are not plug-ins you add later.

Step 7: Prepare your documentation package By the time you reach a formal procurement, you should be able to produce a complete DTAC form, a Clinical Safety Case Report, your Hazard Log, DSPT evidence, Cyber Essentials Plus certification, and your DPIA. NHS procurement teams will ask for all of these.

Selecting a development partner with direct experience of this process makes a material difference to how quickly and cleanly you move through it. Teams evaluating their options would do well to ask specific technical and governance questions of any development partner before they commit.

What This Looks Like in Practice: A Healthcare Platform Built to Standard

Understanding the compliance framework is one thing. Delivering it across a complex, long-running healthcare product is another.

Since 2019, Emvigo has worked with a UK-based genomics and epigenetics healthcare platform delivering personalised DNA health insights to individuals and practitioners worldwide. The engagement has run for over six years and covers a multilingual mobile application, a practitioner portal, an AI health coach, and white-label delivery infrastructure — all built to meet patient data security requirements and healthcare interoperability standards throughout the product lifecycle. (Client name withheld under NDA. Details shared with client approval.)

What that engagement demonstrates is the importance of compliance being embedded in delivery from the outset — not treated as a final audit. Data governance, clinical risk considerations, and interoperability architecture were factored into every major product decision across more than half a decade of development.

That kind of sustained, standards-aware engagement is also why Emvigo’s ISO 9001:2015 certification matters in a healthcare context. Quality management processes that consistently meet international standards are not peripheral to NHS readiness — they underpin it.

Teams building healthcare apps often face the same set of infrastructure decisions at the outset. The considerations that shape healthcare app development partnerships — compliance capability, data architecture, integration experience — are exactly the ones that determine whether a product can realistically reach NHS procurement.

AI in NHS Software: What It Means for Your Compliance Timeline

If you are reading this because you are building a product with AI features — a triage assistant, a diagnostic support tool, a risk-scoring algorithm — your compliance path is more complex than the standard roadmap above, and your procurement timeline needs to reflect that.

Here is what changes:

Classification risk is higher. The MHRA applies its Software as a Medical Device framework to AI tools that influence clinical decisions. If your AI feature affects diagnosis, triage, or treatment — even indirectly — UKCA marking is likely required. That adds regulatory process on top of DCB0129, not instead of it.

DCB0129 hazard identification gets harder. Standard hazard logs cover known failure modes. AI introduces probabilistic failure — the system behaves correctly most of the time, but fails in ways that are difficult to predict or reproduce. Your Clinical Safety Officer needs experience with this type of risk, not just traditional IT hazard analysis.

NHS buyers will ask questions you need answers to. Bias, explainability, training data provenance, and model drift are now procurement-stage conversations in NHS digital. “The model performs well in testing” is not a sufficient answer. Expect to demonstrate how your AI was validated, on what population, and how performance is monitored post-deployment.

The 2024 NHS England review of DCB0129 and DCB0160 — still ongoing — is explicitly focused on keeping those standards current with AI. Build as if the updated standards are already in force, because by the time you reach procurement, they may well be.

The Real Cost of Getting NHS Compliance Wrong

It is worth being direct about the risk profile here.

Commercial risk: A product that fails DTAC or cannot demonstrate DCB0129 compliance simply does not get procured. There is no workaround. Every month spent rectifying compliance gaps after a product is built is a month of delayed revenue — usually far more expensive than building compliantly from the start.

Patient safety risk: The research is unambiguous. Unassessed digital health technologies in NHS settings pose genuine, documented risks to patient safety. The 2025 study identified historical cases where digital failures caused significant harm, including deaths, discovered years after deployment.

Reputational risk: An NHS trust that procures non-compliant software faces its own regulatory exposure. Trusts know this. They will not take the risk on a supplier who cannot demonstrate rigorous compliance.

The hidden costs of software projects in healthcare often stem precisely from compliance gaps that were not visible at the start. Teams that understand how to choose a software development partner with genuine healthcare compliance experience avoid the most expensive of these lessons.

FAQs About NHS-Ready Software Development 

1. What is NHS-ready software development?

NHS-ready software development means building digital health technology that meets all mandatory NHS clinical safety, data protection, security, and interoperability requirements — including DCB0129 for manufacturers, DCB0160 for deploying organisations, and the Digital Technology Assessment Criteria (DTAC). Without meeting these standards, software cannot be legally procured or deployed within the NHS in England.

2. What is DCB0129 and who does it apply to?

DCB0129 is a mandatory clinical risk management standard issued by NHS England. It applies to all manufacturers and developers of health IT systems intended for use in the NHS. It requires manufacturers to operate a documented Clinical Risk Management System, maintain a Hazard Log, and produce a Clinical Safety Case Report — overseen throughout by an appointed Clinical Safety Officer.

3. What is DCB0160 and how is it different from DCB0129?

DCB0160 applies to NHS organisations deploying health IT systems, rather than manufacturers. Where DCB0129 is the supplier’s assurance, DCB0160 is the deploying trust’s own clinical risk assessment for a specific implementation. Every organisation deploying a product must complete its own DCB0160 assessment — even if the manufacturer already holds DCB0129 certification.

4. What does a Clinical Safety Officer (CSO) do in NHS software development?

A Clinical Safety Officer is a registered clinician responsible for overseeing all clinical risk management activities throughout a product’s lifecycle. In the context of DCB0129, the CSO leads hazard identification, reviews and signs off the Hazard Log and Clinical Safety Case Report, and ensures clinical risk management remains active after deployment. The CSO role can be provided by an outsourced specialist.

5. What is the Digital Technology Assessment Criteria (DTAC)?

The DTAC is NHS England’s national baseline framework for assessing digital health technologies before procurement. Updated in February 2026, it covers five core areas: clinical safety, data protection, technical security, interoperability, and usability and accessibility. All digital health technology suppliers to the NHS are expected to complete a DTAC assessment. Without a satisfactory DTAC, procurement is effectively impossible.

6. What is the Data Security and Protection Toolkit (DSPT)?

The DSPT is the NHS’s annual self-assessment framework for data security standards. Organisations that access, store, or process NHS patient data are expected to complete the DSPT and publish their results. It demonstrates compliance with the National Data Guardian’s ten data security standards and forms part of the data protection evidence required in a DTAC assessment.

7. How does HL7 FHIR support NHS integration?

HL7 FHIR (Fast Healthcare Interoperability Resources) is the international standard for exchanging healthcare data electronically. It is the interoperability standard expected by NHS England for systems that need to exchange data with NHS infrastructure, including electronic health records and NHS APIs. The DTAC requires suppliers to explain and justify their chosen interoperability approach, with FHIR being the expected baseline for most NHS integrations.

8. What compliance is required for Software as a Medical Device (SaMD)?

Software classified as a medical device by the MHRA requires UKCA marking in addition to standard NHS compliance requirements. AI-based clinical decision-support tools are particularly likely to be classified as SaMD. If your software qualifies, you must follow both the Medical Device Regulations and DCB0129. The 2026 DTAC update includes a step-by-step decision tree to help manufacturers assess whether their product falls within the medical device boundary.

9. How long does it take to achieve NHS software compliance?

There is no fixed timeline — it depends heavily on your product’s clinical risk profile, whether it qualifies as a medical device, and how early compliance work began in the development cycle. For a new product built with compliance embedded from the start, a realistic timeline from development to completed DTAC documentation is typically six to eighteen months. Products that attempt to retrofit compliance after development is complete often take significantly longer.

10. What are the most common reasons NHS software projects fail compliance?

The most common failure points are: starting clinical risk management too late in the development process; appointing a CSO without proper clinical registration or training; incomplete or superficial Hazard Logs; failing to account for interoperability with existing NHS systems from the architecture stage; and underestimating the data protection requirements — particularly around DPIAs and DSPT completion. Most of these problems are avoidable with the right partner and the right process from the outset.