Building Software for the NHS in 2026: DTAC, Clinical Safety and What Actually Gets You Through Procurement

Two things changed this year that anyone selling digital health technology into the NHS needs to know about.

The DTAC form was replaced on 6 April 2026. The previous version should not be used from that date. The refreshed form carries roughly 25 percent fewer questions, strips out duplication with the Data Security and Protection Toolkit and the Pre-Acquisition Questionnaire, and adds a step-by-step decision tree for working out whether your product is a medical device.

The clinical safety standards are under review right now. NHS England opened a public consultation on DCB0129 and DCB0160 on 29 June 2026. It closes on 11 September 2026. If you build health IT and have an opinion about how those standards apply in practice, you have roughly a month to put it on record.

Both of these matter more than the average regulatory update, because NHS procurement failures are rarely about the product. They are about assurance documentation that was assembled after the build rather than produced by it — and by the time a buyer asks, retrofitting is expensive and slow.

This guide covers the compliance stack, what each part means in engineering terms, where the medical device boundary sits, and the failure modes that stall health tech procurements.

This is an engineering guide, not clinical, regulatory or legal advice. Clinical safety is patient safety. Every position here should be confirmed with a qualified Clinical Safety Officer and appropriate regulatory counsel before it drives a build or a submission.

What changed on 6 April 2026

DTAC is NHS England's assessment framework for software-based digital health technologies — apps, websites, platforms and other tools handling health and care data. Its purpose is consolidation: before DTAC, individual NHS organisations ran their own evaluations with varying expectations, and suppliers assembled a different evidence pack for every trust.

The refreshed form replaced the previous version on 6 April 2026. NHS guidance also indicates a new DTAC website and updated framework arrangements from that date.

What actually changed:

The decision tree is the most consequential addition. The medical device boundary has caused persistent confusion and incorrect self-assessments, and getting it wrong surfaces late — usually when an NHS buyer queries incomplete documentation and the procurement stalls.

If you have a DTAC submission in draft against the old form, rebuild it. The previous form should not be used from 6 April 2026.

The consultation closing in September

Worth acting on rather than just noting.

NHS England has opened a review of DCB0129 and DCB0160 to ensure they remain current, practical and aligned with advances in healthcare technology and clinical practice. The public consultation launched on 29 June 2026 and closes on 11 September 2026. NHS England is explicitly seeking input from IT manufacturers alongside NHS professionals and digital risk assessment specialists.

Two reasons this is worth your time:

The standards predate current practice. DCB0129 and DCB0160 were written for a world of deployed clinical systems rather than continuously delivered software with machine learning components. If you have found the standards awkward to apply to modern delivery — continuous deployment, model retraining, feature flags — this is the mechanism for saying so.

Consultation responses are public record. A substantive response is a citable artefact, and for a supplier selling into health it demonstrates engagement with the standards rather than mere compliance with them.

The compliance stack

Four frameworks, frequently confused, each doing something different.

The relationships matter. DCB0129 and DCB0160 are complementary rather than alternatives — clinical safety evidence produced by the manufacturer under DCB0129 becomes an input into the deploying organisation's DCB0160 work. That same evidence underpins the clinical safety section of DTAC.

Which is the practical point: these are not four separate exercises. They share evidence. A build that produces DCB0129 artefacts naturally populates DTAC section C and hands the deploying trust what it needs for DCB0160. A build that treats them as three documentation tasks does the work three times and produces inconsistencies between them.

Note also that compliance with DCB0129 and DCB0160 is required under the Health and Social Care Act 2012 — these fall under section 250 and are legal requirements for digital systems used in health and adult social care in England, not best-practice guidance. NHS organisations must not procure a digital health technology without DCB0129 assurance, and must not deploy one without DCB0160 assurance.

That last sentence is the commercial reality. Without DCB0129 assurance you are not in the procurement.

The medical device boundary

The single most expensive thing to get wrong.

Software becomes Software as a Medical Device when its intended purpose meets the medical device definition in UK medical device legislation. Intended purpose is the operative concept — it turns on what you claim the product does, not on the technology inside it. A symptom checker that suggests possible conditions is likely a device. A symptom diary that records what the patient reports is likely not. The gap between those two is a sentence of marketing copy.

The new DTAC decision tree exists specifically to reduce incorrect self-assessment here. Use it early — during conceptualisation, not at submission.

What this means for engineering:

Intended purpose is an architectural constraint, not a marketing decision. If your product is a device, you need a conformity assessment, a UKCA mark or recognised equivalent, and a risk management system. That is a different build, a different timeline and a different cost base. Deciding this in month nine is how projects die.

Scope creep can change your classification. A feature that adds interpretation, diagnosis or treatment recommendation to a product previously outside the definition can bring it into scope. Build a classification review into your feature approval process, not just your release process.

Device status now automatically triggers the PAQ under the refreshed DTAC. Plan for it rather than discovering it.

DCB0129 and DCB0160

Frequently mentioned together, applied to different parties.

DCB0129 defines clinical risk management requirements for manufacturers of health IT systems. It is your obligation as a supplier.

DCB0160 defines the equivalent requirements for organisations deploying those systems — the NHS trust or provider. It focuses on safe implementation in the local clinical environment rather than repeating the manufacturer's work.

What DCB0129 requires you to produce, in engineering terms:

A hazard log that is maintained, not written. Hazards identified, risks assessed, mitigations defined, residual risk accepted by a named individual. Maintained across the product lifecycle means updated as the product changes — which for continuously delivered software means it is a living artefact tied to your release process, not a document produced once for submission.

Traceability from hazard to mitigation to test. When a hazard is mitigated by a control, that control needs to be identifiable in the system and verifiable by a test. Auditors follow that chain. Teams that cannot follow it themselves are in trouble before anyone external looks.

Clinical risk management integrated with change management. A change that touches a mitigated hazard needs clinical safety review before release. This is the requirement most incompatible with unmodified continuous deployment, and working out how to satisfy it without abandoning your delivery model is a genuine engineering design problem worth solving deliberately.

Evidence packaged for the deploying organisation. Your DCB0129 output feeds their DCB0160 work. Suppliers who hand over a coherent package close deployments faster than those who send a PDF and wait for questions.

Research published in 2025 examined assurance status across NHS organisations in England via freedom of information requests, and found no public data existed on how many digital health technologies are in use or how many are assured against these mandatory standards. Draw your own conclusion about the state of the field — but note that a supplier arriving with a clean, complete assurance package stands out in a way that has direct commercial value.

The Clinical Safety Officer

DTAC requires a nominated Clinical Safety Officer. The requirements: the CSO must be a clinician, hold current registration with a professional body, and be trained in clinical risk management.

Two things worth knowing.

The previous NHS-specific CSO training requirement has been removed under the refreshed DTAC. That is a real reduction in burden for suppliers who previously struggled to find or fund a CSO through that specific route.

The CSO role can be undertaken by an outsourced third party. For a startup or a non-health software company entering the market, this is usually the right answer. You are not going to hire a registered clinician onto a six-person engineering team, and you do not need to.

The failure mode is treating the CSO as a signature rather than a participant. A CSO who reviews a hazard log at submission is providing very little assurance. A CSO engaged during design, who challenges intended purpose and hazard identification while changes are still cheap, is providing the thing the standard exists for.

DTAC's five areas in engineering terms

The five assessment areas remain unchanged under the refresh, with modernised requirements within each.

Clinical safety. DCB0129 compliance, hazard log, nominated CSO, medical device determination via the decision tree. Covered above.

Data protection. UK GDPR and Data Protection Act 2018 compliance, Caldicott Principles, DPIA for high-risk processing. Health data is special category data, so the stricter regime applies throughout. Note that UK data protection law changed materially in 2026 — the automated decision-making reforms in particular have direct consequences for any clinical decision support built on models. We cover the engineering implications in our UK data protection guide.

Technical security. Penetration testing, vulnerability management, secure development practices, and evidence of all three. The DSPT overlaps here, and the refreshed DTAC removes duplication between them.

Interoperability. Covered below.

Usability and accessibility. Commissioned services are expected to meet the NHS service standard, which aligns with the GOV.UK service standard, and may be assessed against it alongside the DTAC usability and accessibility criteria. Accessibility here means WCAG conformance evidenced by testing, not asserted in a form.

Interoperability

The area where teams from outside health most consistently underestimate the work.

FHIR R4 for data exchange. SNOMED CT for clinical terminology. HL7 where legacy interfaces demand it. The Internet First policy shapes how services are exposed.

Three things that catch people out:

SNOMED CT is not a lookup table. It is a hierarchical ontology with post-coordination, relationships and versioning. Products that store clinical concepts as free text or as a local enum will fail interoperability review and will need a data migration to fix.

FHIR profiles matter more than FHIR itself. UK Core profiles constrain the base specification. Building to vanilla FHIR and discovering the profile requirements later means rework in your resource models.

Build to the standard from day one. Retrofitting terminology and exchange standards into a system that modelled clinical data its own way is among the most expensive remediations in health tech. This is the single strongest argument for engaging health-experienced engineering early rather than building generically and adapting.

Data protection in a health context

Health data is special category data, which raises the bar across the board.

DPIA is effectively mandatory for the processing most health products perform. Do it early — it constrains architecture, and discovering that late is expensive.

Caldicott Principles apply alongside UK GDPR. They govern the use of confidential patient information and are not satisfied simply by GDPR compliance.

The DUAA changes apply here too, with a caveat. The 2026 reforms to automated decision-making flipped the default from prohibition to permission-with-safeguards — but special category data remains more protected, and health data is special category data. Do not assume the liberalisation applies to your clinical decision support. This is exactly the kind of question to put to counsel rather than infer.

Data residency needs to be deliberate. Confirm where your logging, observability and backup destinations actually sit. Error tracking tools routinely ship data to regions nobody assessed, and in a health context that is a serious problem rather than a housekeeping one.

Timeline, cost and team shape

Indicative planning bands. Health tech carries an assurance overhead that generic software does not.

The assurance overhead typically adds 20 to 35 percent to an equivalent non-regulated build. Teams that plan for it deliver on schedule; teams that discover it mid-build do not.

Team additions specific to health:

For how these roles map to UK rates and staffing models, see our UK developer day rate index and our 2026 IR35 guide.

The regional point worth noting: health data and health tech capability is not concentrated solely in London. Leeds hosts significant NHS digital infrastructure, and Greater Manchester's cross-sector convergence spans health alongside finance and advanced manufacturing — which we cover in our Manchester software development guide.

Five ways health tech procurements stall

1. Medical device status determined late. Discovered at DTAC submission rather than at concept. Adds months and sometimes changes the product. Use the new decision tree at conceptualisation.

2. The hazard log was written for submission. An artefact produced in a fortnight to satisfy a form, disconnected from how the product actually changes. Reviewers can tell. So can deploying trusts.

3. Clinical terminology modelled locally. Free text or local enums where SNOMED CT belongs. Fails interoperability review and requires data migration to remediate.

4. The CSO was a signature. Engaged at the end, with no involvement in design decisions that created the hazards. Provides no real assurance and frequently produces a log that does not match the system.

5. Assurance treated as a phase rather than a property. The recurring theme across UK regulated software: frameworks increasingly require you to demonstrate outcomes continuously, not to produce documents periodically. Products designed to generate their own evidence pass; products that assemble evidence retrospectively stall. The same pattern holds in financial services, which we cover in our London fintech development guide.

Frequently asked questions

What changed in the NHS DTAC in 2026? The updated DTAC form replaced the previous version from 6 April 2026, and the previous form should not be used from that date. It carries roughly 25 percent fewer questions, removes duplication with the DSPT and the Pre-Acquisition Questionnaire, adds a step-by-step decision tree for medical device classification, automatically triggers the PAQ where software qualifies as a medical device, and removes the previous requirement for NHS-specific Clinical Safety Officer training. The five assessment areas remain the same.

What is the difference between DCB0129 and DCB0160? DCB0129 defines clinical risk management requirements for manufacturers and developers of health IT systems. DCB0160 defines equivalent requirements for the NHS organisations deploying those systems. They are complementary — manufacturer evidence produced under DCB0129 becomes an input to the deploying organisation's DCB0160 activities.

Are DCB0129 and DCB0160 legally required? Yes. Compliance is required under the Health and Social Care Act 2012, falling under section 250. NHS organisations must not procure a digital health technology without DCB0129 assurance and must not deploy one without DCB0160 assurance.

When does the NHS clinical safety standards consultation close? NHS England's public consultation on DCB0129 and DCB0160 launched on 29 June 2026 and closes on 11 September 2026. NHS England is seeking input from IT manufacturers alongside NHS professionals and digital risk assessment specialists.

Does my product count as a medical device? It depends on intended purpose rather than technology. Software becomes Software as a Medical Device when its intended purpose meets the definition in UK medical device legislation. The refreshed DTAC includes a decision tree to help determine this. Use it during concept development, and confirm with regulatory counsel — incorrect self-assessment is the most common cause of late-stage procurement delay.

Do I need to employ a Clinical Safety Officer? You need a nominated CSO who is a clinician with current professional body registration and training in clinical risk management. The role can be undertaken by an outsourced third party, which is usually the practical answer for smaller suppliers. The previous NHS-specific CSO training requirement has been removed under the refreshed DTAC.

How much does it cost to build NHS-compliant software? A non-device digital health product built DTAC-ready typically runs £200k to £500k over six to ten months. Class I Software as a Medical Device runs £400k to £1m over ten to eighteen months. Retrofitting assurance into an existing product typically costs £120k to £400k. Assurance overhead usually adds 20 to 35 percent against an equivalent non-regulated build.

What interoperability standards does the NHS require? FHIR R4 for data exchange, SNOMED CT for clinical terminology, HL7 where legacy interfaces require it, and adherence to the Internet First policy. UK Core FHIR profiles constrain the base specification, so building to vanilla FHIR and adapting later creates rework.

The short version

Three things to do this quarter.

Rebuild any DTAC draft against the new form. The previous version is invalid from 6 April 2026.

Run the medical device decision tree now, even if you are confident of the answer. Confirming it costs an hour; discovering it at submission costs months.

Respond to the consultation before 11 September if you build health IT. It is a rare opportunity to shape standards you have to work under, and the response is a public record of engagement.

And the structural point underneath all of it: NHS assurance is increasingly a property of how you build rather than a document you produce at the end. Products that generate their own evidence pass procurement. Products that assemble it retrospectively stall — and stalling in NHS procurement is measured in quarters.

About Akoode Technologies

Akoode Technologies is an AI and software development company headquartered in Gurugram, India, with a US office in Oklahoma, working with clients across the UK, USA and India. We build custom software, AI and machine learning systems, mobile applications and eCommerce platforms for startups, SMEs and enterprises across 15+ industries, with 180+ projects delivered globally and clients across the UK, including London and Manchester.

Verified ratings: 4.9 out of 5 on Google across 110 client reviews, and 5.0 out of 5 on GoodFirms.

If you are planning a health tech build or assessing an existing product against the refreshed DTAC, book a call. We will be straight with you about where you need a specialist regulatory partner rather than a development one.

This article is an engineering guide, not clinical, regulatory or legal advice. Framework references reflect published NHS England and industry guidance as of August 2026; DCB0129 and DCB0160 are under active review with consultation closing 11 September 2026, and outcomes may change requirements. Medical device classification and clinical safety decisions must be confirmed with a qualified Clinical Safety Officer and appropriate regulatory counsel.