The handoff: where clinical safety falls through the gap.

Every piece of health IT that touches patient care in England carries two safety obligations. The manufacturer has to manage clinical risk under DCB 0129. The organisation deploying it has to do the same under DCB 0160. On paper, the two connect neatly. The supplier identifies hazards and controls what it can. The provider inherits that work, adds what only it can know about its own patients, pathways and people, and keeps watch once the system is live.

In reality, the connection is usually limited to an email attachment.

A supplier finishes its hazard log and safety case, exports them, and sends them over. A Clinical Safety Officer at the trust, ICB or practice opens them, often months later, often alongside a dozen other products, and starts again. They read, interpret, re-key and re-score. Some hazards are carried across. Some are missed. Some controls are assumed to sit with the other side, and nobody checks whether they do.

Why the handoff matters more now

The legal ground is shifting too. Since 7 July 2025, section 95 of the Health and Care Act 2022 has allowed standards such as DCB 0129 and DCB 0160 to carry a duty to comply, rather than only a duty to have regard to them. Since 5 February 2026, the Data (Use and Access) Act 2025 has allowed that duty to extend to IT providers. NHS England says the current standards still require bodies to have regard to them, and that future revisions are likely to use these stronger powers. Clinical safety is becoming a legal duty on both sides of the handoff.

At the same time, the standards themselves are under review. NHS England’s consultation ran from June to September 2026, and the themes behind it are telling: how risk is managed across interconnected systems and organisations, less duplication between the two standards, stronger monitoring after go-live, and how to handle AI. The focus groups that preceded it were clear: keep the standards mandatory, reduce duplication, and take post-implementation monitoring seriously.

The National Commission into the Regulation of AI in Healthcare went further. Its recommendations, all 44 of which the government accepted in October 2026, call for contracts that explicitly allocate responsibility for every required risk control between manufacturer and provider. In the Commission’s words, “no risk controls should be unaccounted for”. That describes the handoff problem exactly.

Most safety gaps are not hidden in either organisation. They sit in the space between them.

What goes wrong

In our work with suppliers and providers, the same patterns come up again and again.

• Hazards are described in the supplier’s language, not the clinical setting’s, so the provider cannot easily tell which ones apply locally.
• Controls are written as assumptions (“users will be trained”, “results will be reviewed”) with no owner on the provider side.
• Residual risk is scored once, at the supplier, and never rescored for a particular pathway or population.
• Updates break the chain. A new release changes a function, the supplier updates its log, and the provider’s safety case quietly goes out of date.
• Nobody owns the seam. Each side believes the other is watching.

None of this comes from carelessness. It comes from two organisations doing their part well, in separate documents, with no shared thread between them.

What good looks like

The best handoffs we see share a few things. The supplier writes hazards so a deployer can understand them: what could happen, to whom, at which step of care. Every control has a named owner, and where a control depends on the provider, it says so plainly. The provider starts its DCB 0160 work from the supplier’s hazards rather than from a blank page, then adds the local hazards only it can see. And both sides agree how changes will be communicated and how the system will be monitored once it is live.

That is what DCB 0129 and DCB 0160 always intended. It is also very close to what the Commission is now asking for.

How Qyro approaches it

We built Qyro Hazard Studio around the handoff because we have stood on both sides of it. A hazard in Qyro is a structured record: the hazard, its cause, the control, the evidence and the owner, placed on the care pathway where it could occur. When a supplier shares its record with a provider, those hazards carry across as data. The provider sees which controls it has inherited and which it now owns, adds its own local controls, and keeps one connected view as both sides change over time.

Qualified people still make the decisions. Your Clinical Safety Officer signs the safety case. What changes is that nobody has to rebuild the same hazard log twice, and nothing falls through the space in between.

Three questions to ask this week

• Suppliers: could a provider’s Clinical Safety Officer tell, from your hazard log alone, which controls they are expected to own?
• Providers: for your highest-risk systems, when did you last check that the supplier’s safety case matches the version you are running?
• Both: if a hazard changed tomorrow, how would the other side find out?

If any of those answers is “we’d have to look”, the handoff is where to start.