Building for the NHS: what DTAC and clinical safety add to a health product

The alphabet soup, briefly

DTAC: the front door

DTAC assesses five areas: clinical safety, data protection, technical security, interoperability, and usability and accessibility. It is not a certification you pass once. It's a structured set of evidence an NHS organisation reviews before they let your product near patients or staff, and crucially it's required before pilots as well as full procurement. Teams are routinely caught out by planning a “quick pilot” and discovering it needs the same evidence pack as a contract.

The February 2026 update, widely called DTAC 2.0, trimmed roughly a quarter of the questions by removing overlap with the DSPT and the pre-acquisition questionnaire. It's less repetitive than it was, but the underlying bar has not dropped.

DCB0129: clinical risk management

This is the one that shapes the product rather than just documenting it. DCB0129 requires you to systematically identify, assess, and mitigate the clinical risks that could arise from someone using your software: a wrong dose shown, a missed alert, an ambiguous label, a screen that reads differently under pressure.

In practice it means:

• A Clinical Safety Officer. A named, registered clinician who has completed the NHS clinical safety training. They own the clinical risk process and sign the safety case. You cannot appoint a non-clinician to this role.
• A hazard log. A living register of every clinical hazard, its severity and likelihood, and what you've done to reduce it.
• A clinical safety case report. The argument, backed by the hazard log, that the product is safe to use as intended.
• Ongoing maintenance. The safety case is updated every release. It is not a document you write once and file.

DSPT: data security

The Data Security and Protection Toolkit is an annual self-assessment against a set of data security standards, with evidence attached. If you process NHS patient data you complete it yearly, and your DTAC submission references it. Start it early: gathering the evidence (policies, training records, access controls, penetration test results) takes longer than filling in the form.

What this adds to a build

How to sequence it so it doesn't derail the build

The teams that struggle treat compliance as a phase at the end. The teams that don't fold it in from the start:

1. Start the hazard log in discovery. As you map the core flow, you're already identifying where a user could be misled or a step could fail. That's the raw material for the hazard log.
2. Bring the Clinical Safety Officer into design reviews. Clinical hazards are cheapest to remove on a wireframe.
3. Open the DSPT early. It's mostly evidence collection, and that runs in parallel with everything else.
4. Write the safety case as you build, not after. Each release updates it. Retro-fitting one across a finished product is slow and painful.

Done this way, the compliance work adds weeks, not months, and it genuinely improves the product: the hazard analysis forces you to design the unhappy paths properly, which is where health software usually fails.

Common misconceptions

• “DTAC is a certification.” It isn't. There's no badge. It's an evidence pack an NHS organisation assesses, and different trusts can weight it differently.
• “We'll do the clinical safety work after the build.” The safety case has to reflect the product as built and is updated every release. Starting late means reverse-engineering hazards from finished screens.
• “Our CTO can be the Clinical Safety Officer.” Only if your CTO is also a registered clinician with the NHS training. Otherwise it has to be someone who is.
• “A pilot is informal, so it's exempt.” DTAC is expected before pilots. A pilot that touches patient care needs the evidence.
• “CE or UKCA marking covers it.” Medical device regulation and NHS digital assurance are separate tracks. You may need both, and one does not satisfy the other.

What good looks like

A health product that clears assurance smoothly usually shares a few traits: a Clinical Safety Officer who was in the room from the first design review, a hazard log that started as a spreadsheet in discovery week one, a deliberately narrow first release so the safety case is small and defensible, and a DPIA and DSPT that were opened months before they were needed. The teams that treat it as a design input rather than a launch gate are the ones that don't slip.

Common questions

Do I need DTAC for a small NHS pilot?

Yes. DTAC is required before pilots, not only before full procurement. Plan for the same evidence pack whether it is a six-week trial or a three-year contract.

Who can be a Clinical Safety Officer?

A registered clinician (for example a doctor, nurse, or pharmacist) who has completed the recognised NHS clinical safety training. It cannot be a non-clinical product or engineering lead.

What is the difference between DCB0129 and DCB0160?

DCB0129 applies to you as the manufacturer of the software. DCB0160 applies to the NHS organisation that deploys it. You produce a clinical safety case under 0129; your customer runs their own process under 0160.

How much time does NHS compliance add to a build?

Typically four to eight weeks of additional elapsed time, most of which can overlap with design and development if you start the hazard log and DSPT early rather than treating them as a final phase.

What changed with DTAC 2.0 in 2026?

The February 2026 version removed roughly 25 percent of the questions by cutting duplication with the DSPT and the pre-acquisition questionnaire. The form is shorter; the clinical safety and data security expectations behind it are unchanged.

If you're building something the NHS will use, talk to us early, ideally before design. Folding clinical safety in from the start is far cheaper than bolting it on. You can see the kind of work we mean on our healthcare projects page.