Short, plain-language perspectives from the ClinAssure team on the standards, decisions and delivery patterns that shape safer digital health programmes.
The two standards are often confused, but they cover different accountability. DCB0129 sits with whoever manufactures or configures the health IT system; DCB0160 sits with the organisation deploying and using it. In practice, most digital health programmes need both applied together — and clarity on who owns which is often the first gap worth closing.
Clinical safety work is rarely skipped entirely — it usually just arrives after the decisions it should have shaped have already been made. Service model, workflow and system design choices carry clinical risk implications long before a formal safety case is written. Moving assurance activity earlier, even informally, changes what the paperwork ends up defending.
Suppliers often treat DTAC as a form to complete before submission. The organisations that move through procurement fastest treat it as a readiness state instead — clinical safety, data protection, technical security, interoperability and accessibility genuinely built in, so the assessment reflects reality rather than describing intent.
As more clinical workflow moves into software — including AI-enabled decision support — it's tempting to treat clinical risk as an engineering or data problem. It remains a clinical problem first. The tools for managing it change; the underlying question of patient safety impact does not.
Share your programme context and we'll come back with a focused view of where clinical assurance should start.