Clinical safety, MHRA & ISO: your questions answered

What is DCB0129?

DCB0129 is the clinical risk management information standard for the manufacture of health IT systems. It sets out how manufacturers identify hazards, assess risks to patients, implement controls and demonstrate that clinical risks have been managed during design, development and maintenance.

NHS England states that compliance with DCB0129 and DCB0160 is mandatory within their applicable scope under the Health and Social Care Act 2012. These are England's information standards: assess applicability to the system and service rather than describing them as blanket UK-wide requirements.

For a digital health innovator or supplier, this means an ongoing safety process supported by evidence, not simply a document produced before a tender. Its scope depends on the system and intended use; do not assume that being a small company or using an existing platform removes the need to assess clinical risk.

What is the difference between DCB0129 and DCB0160?

DCB0129 addresses the manufacturer's clinical risk management. DCB0160 addresses the deploying organisation's clinical risk management when it implements, uses, maintains or decommissions a health IT system.

The supplier considers the product's design and intended use; the deployer considers local workflows, configuration, integrations, staff and patients. Both sides need to exchange safety evidence. A supplier's DCB0129 safety case does not replace the deployer's DCB0160 assessment.

What documentation and evidence does DCB0129 require?

Core evidence includes a clinical risk management plan, a hazard log and a clinical safety case report, supported by the organisation's clinical risk management arrangements. The plan defines responsibilities and activities; the hazard log records hazards, risks, controls and residual risk; the safety case explains why the system is acceptably safe for its intended use.

Evidence should connect each important control to its implementation and verification. Relevant assumptions, limitations, outstanding risks and information the deployer needs must be clear. The documents should be controlled and reviewed as the product changes.

Do we need a named Clinical Safety Officer, and is training enough?

The standards require an appropriately qualified Clinical Safety Officer (CSO) to oversee clinical risk management. The CSO must have suitable clinical experience and clinical risk management competence; a course certificate alone does not establish that every person is suitable for every product or deployment.

A retained or fractional CSO can provide specialist support, but the organisation must still maintain its own governance and responsibilities. DigiSafe provides named CSO support and our sister company, CSO Training Academy, provides training; the right combination depends on your team's experience and the system's risks.

Is there a DCB0129 certificate or central product approval?

DCB0129 is not a centrally issued product certification scheme. Suppliers demonstrate compliance through their clinical risk management process and safety evidence, which buyers and deploying organisations can review.

A consultant's completion letter or a training certificate should not be confused with NHS approval of a product. Ask for the actual safety case, hazard log, scope, version and named responsibilities rather than relying on a claim that software is 'DCB0129 certified'.

Do AI products and ambient scribes need DCB0129 work?

AI is not an exemption from clinical risk management. Where an AI product or ambient voice technology (AVT) system falls within the health IT standard's scope, the manufacturer needs to assess its clinical hazards and the deployer needs to assess local use.

Depending on the product, hazards may include inaccurate output, omitted information, automation bias, inappropriate reliance, population bias and failures in human review. Clinical safety and medical device qualification are separate questions: a product can need clinical safety assessment without being a medical device.

When should we start, and when must the safety evidence be updated?

Start during product design, while you can still change workflows and implement controls. Retrospective paperwork is less useful than evidence built alongside requirements, development and testing.

Review clinical risk when changes may affect safety, including new functionality, integrations, intended users, AI models or intended use, and when incidents or monitoring reveal new information. The amount of work depends on the change and its risk; do not treat the first safety case as permanent approval for every future version.

What is DCB0160?

DCB0160 is the clinical risk management information standard for the deployment and use of health IT systems. It addresses how deploying organisations manage patient safety risks arising from implementation, use, maintenance and decommissioning.

For a PCN, GP practice, ICB or NHS trust, the key question is whether the system is acceptably safe in the actual local environment, with your configuration, staff, patients and connected systems. Governance should establish which organisation owns the deployment and safety decisions, especially where several organisations share a service.

Our supplier has DCB0129 evidence. Do we still need DCB0160?

Yes, where DCB0160 applies to your deployment. The manufacturer's evidence is an input to your assessment, not a substitute for it. Local configuration, data migration, integrations, access permissions, training and downtime arrangements can introduce risks that the manufacturer cannot fully assess.

Review the supplier's clinical safety case and relevant hazards, confirm its assumptions match your use, and document local controls and remaining risks. Any gaps or unclear responsibilities should be resolved before the relevant deployment decision.

What should PCNs and GP practices do before deploying new software?

Define the intended use, affected patients and workflows, accountable organisation and CSO arrangements. Request supplier safety evidence early, involve clinical and operational users, assess local hazards and plan the controls needed for safe implementation.

Record the deployment's clinical risk management plan, hazard log and clinical safety case report. Confirm testing, staff training, escalation and business continuity arrangements, and ensure residual risks go through the appropriate local acceptance process. A shared PCN rollout still needs to account for differences between practices.

Can an ICB or trust use one safety case across several sites?

A common assessment and evidence set can support a coordinated rollout, but it must accurately describe the scope and local differences. A shared document does not remove hazards introduced by different configurations, workflows, integrations or training arrangements.

Identify what can be assessed centrally and what each site must confirm. Set clear ownership, record site-specific risks and controls where necessary, and ensure the responsible organisation accepts the risks for its own deployment.

Does a DTAC assessment replace DCB0129 or DCB0160?

No. The Digital Technology Assessment Criteria (DTAC) bring together baseline areas including clinical safety, data protection, technical security, interoperability, and usability and accessibility. Clinical safety evidence is part of that assessment rather than an alternative to the clinical risk management standards.

A completed DTAC form is not blanket NHS approval and does not transfer the deployer's clinical safety responsibilities to the supplier. Procurement, information governance, device regulation where applicable, and local clinical safety decisions still need appropriate evidence.

What happens after go-live, or when we retire a system?

Clinical risk management continues during use. Monitor incidents and new hazards, check that controls remain effective, and reassess changes to configuration, integrations, workflows or the supplier's product. Keep the relevant safety evidence current.

Decommissioning can also introduce risks, such as inaccessible records, incomplete migration or loss of a clinical workflow. Include safe transition, data access and continuity arrangements in the assessment instead of treating retirement as purely an IT task.

How do we know whether our software is a medical device?

Medical device qualification depends on the manufacturer's intended purpose and the product's functions and claims. Software with a medical purpose, such as supporting diagnosis, monitoring or treatment, may be a medical device. Software used only for general administration or communication is not automatically a medical device just because clinicians use it.

Document an intended-purpose statement and assess the functions against the rules for your target market. Marketing claims, instructions and actual functionality need to be consistent. AI alone does not determine qualification or risk class.

Are all AI tools and ambient scribes Class I medical devices?

No. There is no universal rule that every AI tool or ambient scribe is a Class I medical device. Qualification depends on intended purpose and functionality; classification then follows the applicable regulatory rules.

A tool that records or transcribes information needs a different assessment from one that interprets findings, recommends treatment or influences clinical decisions. Assess each product and target market rather than assuming 'Class I minimum'. Even where device regulation does not apply, clinical safety, privacy and security obligations may still be relevant.

What is MHRA medical device registration, and is it approval?

MHRA registration records the manufacturer, responsible person where relevant, and device information required for market oversight. Medical devices must meet the applicable regulatory requirements and registration rules before being placed on the Great Britain market.

Registration is not MHRA approval, accreditation or certification of the device, and is not permission to describe a product as 'MHRA approved'. It does not replace conformity assessment, the required declaration of conformity, technical documentation or the applicable marking.

Does a Class I device still need evidence and registration?

Yes. A low-risk classification does not remove the manufacturer's obligations. Under the applicable Great Britain route, many Class I devices can be self-declared, but some require third-party involvement, such as devices supplied sterile or with a measuring function. The precise route depends on the device and regulatory framework.

Manufacturers still need evidence of conformity, appropriate technical documentation, risk management, clinical evaluation, labelling and post-market arrangements, as applicable, plus the required registration. Self-declaration is a responsibility to substantiate conformity, not a shortcut around it.

What should we prepare before registering a medical device?

Establish the intended purpose, qualification and classification, target market, legal manufacturer and conformity assessment route. Prepare the required technical and clinical evidence, risk management, labelling, declaration of conformity and certificates where applicable.

Gather the manufacturer and device details needed for the MHRA registration system, and establish a UK Responsible Person if required. Registration should follow a properly evidenced regulatory route rather than being the first step used to decide whether the product is compliant.

Do overseas manufacturers need a UK Responsible Person?

A manufacturer based outside the UK that places a medical device on the Great Britain market must appoint a UK Responsible Person to perform specified regulatory tasks, including registration responsibilities. This role is distinct from a consultant, distributor or Clinical Safety Officer unless that party has also formally taken on the role.

The manufacturer's obligations remain important: appointing a UK Responsible Person does not transfer all product compliance responsibility. Confirm the mandate, responsibilities and access to documentation before market entry.

Are Great Britain and Northern Ireland rules the same, and is UKCA always needed?

No. Great Britain and Northern Ireland have different medical device market-access arrangements. Northern Ireland follows the relevant EU medical device framework, while Great Britain operates under its own framework, including transitional recognition of certain CE-marked devices.

UKCA is therefore not the only possible route for every device supplied in Great Britain, and it is not the market-access marking for Northern Ireland. The applicable route depends on the device, certificates, marking and current transitional rules. Check current MHRA guidance before committing to a launch date; there is no single deadline that safely describes every product.

What happens after MHRA registration?

The manufacturer must continue to meet the applicable requirements, including post-market surveillance, vigilance and keeping relevant records and registration information up to date. Registration does not make compliance a one-time task.

Monitor real-world performance, complaints and safety signals, investigate problems and take appropriate corrective action. Changes to intended purpose, functionality or risk may require a fresh regulatory assessment as well as an updated clinical safety assessment.

Which ISO standards are relevant to digital health suppliers?

ISO 13485 covers quality management systems for medical devices. ISO/IEC 27001 covers information security management systems. ISO 9001 covers general quality management systems. ISO/IEC 42001 covers AI management systems for organisations providing or using AI.

You do not automatically need all four. Choose a scope based on your intended purpose, regulatory route, information risks, use of AI, customer requirements and growth plans. A gap analysis can distinguish what is mandatory, what buyers request and what would improve your operations.

What is ISO 13485, and does every Class I device need certification?

ISO 13485 specifies medical device quality management system requirements, including controlled processes and evidence relevant to regulatory compliance across the device lifecycle. It is more specific to medical devices than ISO 9001.

ISO 13485 certification is not a universal prerequisite for every Class I device registration route. The manufacturer must meet the applicable legal and quality requirements; whether certification is required depends on the conformity assessment route, market and contractual expectations. Building a suitable QMS and obtaining independent certification are related but distinct activities.

What does ISO/IEC 27001 demonstrate, and does it cover all NHS requirements?

ISO/IEC 27001 sets requirements for an information security management system (ISMS): a risk-based approach to protecting information, choosing controls, managing incidents and improving over time. A certificate applies to a defined scope, not automatically to every product or activity in a business.

Certification does not by itself prove compliance with every DTAC, data protection or NHS buyer requirement. Check the scope, risk treatment, relevant controls and the actual evidence requested. An ISMS supports assurance, but does not replace product-specific testing or legal obligations.

How is ISO 9001 different from ISO 13485?

ISO 9001 is a general quality management standard applicable across sectors, focusing on consistent delivery, customer requirements and improvement. ISO 13485 is tailored to medical device quality management and associated regulatory requirements.

ISO 9001 is not a substitute for medical device regulatory evidence or for ISO 13485 where that standard is required by your route or buyer. An organisation may use one or both, with a scope that matches its services and products.

What is ISO/IEC 42001, and does it certify that an AI product is safe?

ISO/IEC 42001 specifies requirements for an AI management system (AIMS), helping organisations govern the responsible development, provision or use of AI. It addresses organisational processes and risk management rather than issuing clinical approval for an individual model.

Certification does not replace medical device conformity assessment, DCB0129 or DCB0160 evidence, data protection duties or applicable AI law. Product-level validation and monitoring remain necessary where relevant. AI governance should connect to your existing quality, security and clinical safety processes.

Can DigiSafe issue ISO certificates?

DigiSafe supports gap analysis, management system development, internal audit and readiness for certification. Independent certification bodies perform certification audits and issue certificates; ISO itself does not certify organisations.

Choose a suitable certification body and check its accreditation and scope where accredited certification is required. Consultancy support, audit readiness and an independent certification decision should not be presented as the same service or as a guaranteed outcome.

Can we combine ISO, clinical safety and medical device work?

Yes. You can coordinate document control, competence, supplier management, change control, risk review, incident handling and improvement across an integrated management system. This can reduce duplication while keeping each standard's requirements visible.

Integration does not make the standards interchangeable. Preserve the clinical hazard evidence required for DCB0129 and DCB0160, device-specific regulatory evidence, and the distinct quality, information security and AI governance requirements relevant to your scope.

How long does ISO readiness take, and where should we start?

There is no reliable universal timescale or cost: readiness depends on the chosen standard, scope, existing processes, staff capacity and evidence already available. Certification audit scheduling is also separate from implementing the system.

Start with a gap analysis and an agreed scope. Build a prioritised plan, assign owners, put the processes into use and gather evidence before internal audit and management review. DigiSafe can shape this around an early-stage innovator, established supplier or deploying organisation rather than imposing a one-size-fits-all pack.