Short answer: a digital health product may need MHRA medical device work, a DCB 0129 clinical safety case, both, or neither. UKCA or CE marking does not replace DCB 0129, and DCB 0129 does not decide whether software is a medical device.
Two different questions
Medical device regulation asks what the software is intended to do. If the intended purpose is diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, injury or disability, the product may fall within medical device regulation. The details matter, including whether the software is only storing, transferring or displaying data, or whether it performs an action on information for a medical purpose.
DCB 0129 asks a different question: if this is health IT used in England's health and care environment, has the manufacturer applied clinical risk management and produced evidence that the clinical risk is acceptable for the defined use?
The medical-device side
In the UK, the MHRA is the regulator for medical devices. For software and AI, classification starts with intended purpose. A tool that simply stores notes is usually different from a tool that interprets findings, predicts deterioration, prioritises patients or recommends treatment. The same technical product can land differently if the claims, users and use context change.
If the product is a medical device, the manufacturer needs the appropriate medical-device route: classification, technical documentation, clinical evaluation, risk management, post-market surveillance, registration and conformity marking or applicable transitional arrangements. That work is not replaced by an NHS procurement form or a clinical safety case.
The DCB 0129 side
DCB 0129 is the NHS clinical risk management standard for manufacturers of health IT systems. It expects a named Clinical Safety Officer, hazard analysis, a clinical risk management file, a hazard log and a clinical safety case report. DCB 0160 is the companion standard for the health or care organisation deploying and using the system.
The key point is that clinical safety depends on workflow. A device can be technically conformant and still create clinical risk if it is configured, surfaced, integrated or acted on in an unsafe way. That is why NHS clinical safety evidence remains relevant even when a product is also a regulated medical device.
Which bucket are you in?
Medical device and DCB 0129
Common for clinical decision support, AI triage, risk prediction, diagnostic support, remote monitoring with clinical interpretation, and software that influences an individual patient's management in the NHS. You need the medical-device work and the NHS clinical safety file.
Medical device, but not an NHS health IT deployment
Possible if the product has a medical purpose but is not being used by, supplied into or deployed in the NHS setting you are assessing. DCB 0129 may not be the immediate route, but medical-device duties still apply.
DCB 0129, but not a medical device
Possible for health IT that affects care workflows without itself having a regulated medical purpose, such as some referral, communication, scheduling, prescribing support, pathway or record systems. The product can still create clinical hazards even if it is not a medical device.
Neither
Possible for genuinely administrative, wellness or general-purpose tools outside clinical care. Be careful: changing the claim from "wellness dashboard" to "detects deterioration" can change the answer.
What founders usually get wrong
"We have UKCA or CE, so we do not need DCB 0129."
Wrong. Conformity marking may be necessary for a medical device, but it does not by itself produce the NHS clinical safety case for a specific health IT workflow.
"We are doing DCB 0129, so we are not a medical device."
Also wrong. DCB 0129 does not classify the product under medical device law. Intended purpose, claims and functionality still need separate assessment.
"It is only AI, not software as a medical device."
AI is not an exemption. If an AI system has a medical purpose, it can be Software as a Medical Device or AI as a Medical Device. The clinical-safety case then needs to handle AI-specific hazards such as automation bias, dataset shift, confidence display, explainability limits and unsafe use outside intended scope. For route-mapping intent, use the AI medical device and SaMD consultant page; for the safety case stream, use the AI clinical safety and SaMD DCB 0129 page.
Practical sequence
- Write the intended purpose in one plain paragraph.
- List the users, patient group, clinical setting, decisions affected and claims you make in sales material.
- Classify medical-device status with regulatory advice where needed.
- Decide whether the product is health IT used in the NHS and whether DCB 0129 applies.
- Build one evidence map so medical-device risk management, DCB 0129 hazards, DTAC evidence and post-market surveillance do not contradict each other.
- For AI or SaMD products, explicitly map model failure modes, workflow controls, change control and clinical escalation in the safety case.