Clinical safety, software and medical devices

A legally required digital exchange still needs safe software and deployment. Some software functions also engage medical-device regulation. Assess the intended purpose, the organisation's role and the relevant national regime to identify those additional responsibilities.

This is a deeper regulatory branch of the wiki's digital sending/availability question, with a 3 November 2026 research baseline. Start with clinical responsibilities and safe sharing for the care-service implications. Use this page when product classification, manufacturer/deployer roles or the Great Britain/Northern Ireland device boundary affects the exchange being implemented.

For board oversight, the useful distinction is between the supplier's evidence for its product and the organisation's assurance of its own configuration and workflow. The worked examples and national comparison establish the service context first.

Developer and deploying organisation

The two clinical-risk information standards below address different roles: developing a system and deploying it in a care service. A provider that develops its own system should assess both roles.

DCB0129 addresses clinical risk management by organisations developing and maintaining health IT systems. Its published materials explain manufacturer assurance and the associated information-standard notice. “Manufacturer” in this context includes a development role; it does not establish that every health IT product is a regulated medical device. ¹⁰¹

DCB0160 addresses deployment, use, maintenance and decommissioning by health and care organisations. Supplier assurance informs local assessment, but the provider still needs assurance for its particular configuration and workflow. ¹⁰²

As a practical synthesis, local assurance should consider patient matching, missing or delayed messages, coding and unit conversion, access failures and downtime. Assign an owner to each control. Record residual risks, acceptance decisions and review triggers. These examples are recommended assessment prompts, rather than additional statutory requirements.

Current DCB status and territorial limits

NHS England's June 2026 review identifies the current versions as DCB0129 version 4.2 and DCB0160 version 3.2, published in 2018. It distinguishes those existing standards from strengthened statutory powers. Its account says relevant bodies must continue to have regard to the existing standards; future revisions are likely to use enhanced compliance powers. ¹⁰³

The same source records commencement of the Health and Care Act 2022 changes on 7 July 2025 and the Data (Use and Access) Act 2025 supplier-related changes on 5 February 2026. A stronger enabling power does not prove that every existing standard has become a universal duty. ¹⁰³

For each deployment, record the actual notice, applicable body and services, contractual terms and onboarding conditions. Do not present NHS England's standard-setting framework as a blanket UK-wide statutory mandate. Other nations can adopt a standard through policy, procurement or contracts. Verify that adoption instead of assuming it from the DCB number.

Is the software a medical device?

Medicines and Healthcare products Regulatory Agency (MHRA) guidance explains when software falls within medical-device regulation. Classification depends on the intended purpose and relevant functions. An electronic system used in healthcare is not automatically a medical device. Equally, software that performs a qualifying medical function can be a device without physical hardware. Record the assessment and the functionality covered. ¹⁰⁴

For artificial intelligence (AI), describe the actual intended use, clinical claims and product boundaries. Classification follows those functions and claims. Reassess material changes in function or intended purpose. A local clinical safety case and device conformity evidence should remain distinct records.

Great Britain and Northern Ireland

MHRA's UK guidance distinguishes the two frameworks. UKCA alone does not establish permission for the Northern Ireland market. CE acceptance in Great Britain has category-specific transitional conditions; use the actual device and certificate rather than one assumed deadline. ¹⁰⁵

The Northern Ireland guidance also identifies separate clinical investigation and performance-study requirements. A pilot label does not itself exempt a device investigation. The appropriate sponsor and regulatory pathway depend on the study and territories involved. ¹⁰⁷

Health institution exemption

Health-institution arrangements depend on the device type, territory and conditions. Public ownership alone does not establish eligibility, and the GB and NI routes differ.

For Great Britain, MHRA's January 2026 guidance makes a significant distinction. Regulation 33 contains a conditional exemption for in vitro diagnostic devices. The regulations do not currently contain an equivalent general-device exemption. MHRA nevertheless describes its longstanding guidance approach for general devices, including software, subject to conditions and leading practice. Preserve that difference between legislation and regulatory guidance. ¹⁰⁶

The guidance considers the institution's purpose, the same legal entity, premises or immediate vicinity, transfer and manufacture or modification. It can cover qualifying private hospitals as well as public institutions. A transfer between legal entities or home use needs particular scrutiny; public ownership does not settle eligibility. ¹⁰⁶

Northern Ireland has the distinct Article 5(5) route under MDR/IVDR. MHRA identifies safety and performance, quality management, justification and documentation requirements, and directs institutions to the full conditions. Do not transplant Great Britain's guidance approach into that regime. ¹⁰⁷

Monitoring after deployment

Great Britain's strengthened manufacturer post-market surveillance requirements took effect on 16 June 2025. MHRA describes incident notification, trend monitoring and corrective action within the amended framework. Establish who owns device monitoring and how the provider supplies relevant incident information. Check the product's applicable transitional position. ¹⁰⁸

Separately, DCB0160 covers the deployment lifecycle. Changes to interfaces, configuration or workflows can require renewed local risk assessment. A purchase or initial approval should not close the safety file. ¹⁰²

Procurement, professional accountability and liability

The Digital Technology Assessment Criteria (DTAC) form NHS England's assessment framework across clinical safety, data protection, security, interoperability, usability and accessibility. It brings together requirements and good practice. It does not replace device approvals or other necessary assurance. The official page records a revised approach and form in 2026; the previous form should not be used from 6 April 2026. ¹⁰⁹

Identify whether DTAC or another assurance process applies through the buyer's rules and contract. Private suppliers and providers can face procurement requirements when supplying public services, while retaining their own regulatory roles.

General Medical Council (GMC) guidance keeps professionals responsible for decisions made using AI and other technologies. It also addresses competence, patient discussions, reporting adverse incidents and raising safety concerns. Developers and employers remain responsible for the aspects they create, test and update. These professional expectations apply across the UK; they do not replace a court's liability assessment. ¹¹⁰

Before deployment, record supplier and provider responsibilities, indemnity and insurance, incident escalation and evidence retention. Treat that allocation as a review of the actual arrangements. Neither a contract, a conformity mark nor an assurance form should be treated as deciding every negligence or product-liability issue. Case-specific liability research remains in the validation queue.

Return to clinical responsibilities and safe sharing for the service account, or the requirements table for the underlying digital obligation.