Four Beliefs That Make NHS Clinical Safety Harder Than It Is

• Myth: the safety case is a document you write at the end
• Myth: someone in the build team can own clinical risk
• Myth: the data flow diagram you drew for investors will satisfy governance
• Myth: DTAC is five separate answers
• What good looks like

Most teams arrive at clinical safety work already holding a set of beliefs about what it is. They are reasonable beliefs, picked up from other regulated industries or from the way procurement talks. The problem is that each one changes what the team builds, and by the time a reviewer sees the product, the belief has hardened into a gap nobody can close cheaply.

§Myth: the safety case is a document you write at the end

The clinical safety case is a claim about how the software behaves. A named clinician signs it, and that signature carries their professional registration. So the document is only as good as what the product can demonstrate.

Teams that treat it as a deliverable tend to schedule it like one: an assessment near the submission date, a hazard log assembled from memory, a narrative written backwards from features that already exist. It reads fine, and it is nearly always wrong in the details. The hazard log describes a version of the product that no longer exists, because releases kept shipping while the assessment sat still. A reviewer opening it eleven versions later can’t tell what was mitigated and what drifted.

The belief underneath is that compliance is paperwork layered onto an unchanged product. In practice the product has to keep showing its working, release after release, or the signature is vouching for a description rather than a system.

§Myth: someone in the build team can own clinical risk

Engineering teams are used to owning risk. Performance risk, security risk, availability risk — all fair game for the people writing the code. Clinical risk feels like the same category, so it gets absorbed into the delivery lead’s remit or, worse, gets handled by a contractor who offers to “cover the clinical side.”

It doesn’t transfer. Under DCB0129 the clinical safety officer has to be a suitably qualified, currently registered clinician, and the judgement they make is theirs. A studio can’t make it for them, and shouldn’t want to. What a build team can do is make the product legible enough that the officer’s judgement is quick and well-founded.

When no clinician holds the role yet, that absence is the first problem, not a detail to resolve near submission. It changes who decides what a hazard even is.

§Myth: the data flow diagram you drew for investors will satisfy governance

A diagram built to explain the product to a buyer shows the shape of the system: services, integrations, the flow of value. A governance reviewer asks a narrower and more physical set of questions. Where does the record actually sit? Who can read it? How long does it stay? What happens when someone asks for it back?

Those are schema and infrastructure decisions, not illustration choices. Residency, access control and retention get settled by how the database and hosting are configured. Teams that defer them end up migrating live patient data later, which is slow, visible, and never popular.

§Myth: DTAC is five separate answers

The submission covers clinical safety, data protection, technical security, interoperability, and usability and accessibility. Five topics, five owners, five documents — so it’s tempting to let each owner answer independently and stitch the results together at the end.

The assessment expects the answers to agree with each other. Where they contradict, the reviewer finds it, and the contradiction reads as risk regardless of how safe the product is. Most of the real work is discovering those disagreements internally, before someone else does.

§What good looks like

A product that holds together under this scrutiny tends to share a few traits. The hazard log still matches the running code. Every mitigation can be pointed at in a feature and traced to the release that shipped it. The data position is settled at the schema, not drawn afterwards. And the clinical safety officer has evidence they can check rather than a narrative they have to trust.

That is a different kind of build from the one most teams plan. Foundry 5’s guide on NHS DTAC and clinical safety software development sets out the evidence pack a trust asks for, how a hazard log is kept traceable across releases, and what a safety officer needs in front of them before they sign.