DCB0160 and MHRA Medical Devices: How the Two Regimes Apply to Software in GP Practices

Why This Article Exists

DCB0129/DCB0160 and MHRA medical-device regulation are two independent regimes. Either, both or neither can apply to a given product, and the question is decided module-by-module rather than product-by-product. For a practice manager buying clinical software, the test starts with the manufacturer's intended purpose (which decides MHRA), then layers on whether the product supports real-time direct care (which decides DCB applicability). A generative artificial intelligence (AI) scribe usually triggers both; an electronic patient record (EPR) that only replaces paper triggers DCB0160 alone; a QRisk3 calculator embedded in a primary-care application triggers both; a population-analytics dashboard usually triggers neither.

This guide is for GP practice managers, clinical leads and Clinical Safety Officers who already know the basics of DCB0160 and now have to deal with the medical-device side of the same products. It walks through both regimes at a buyer's level, the module-level rule that ties them together, the AVT and PARD registries you use to verify a vendor claim, a worked-examples matrix, and the borderline cases (clinical decision support, EPR modules, AI scribe scope creep) where the line is hardest to draw. For the AI-scribe-specific deep dive, see Deploying Ambient Voice Scribes with DCB0160 Compliance; for the verification workflow end-to-end, the AVT registry and PARD buyer's verification workflow.

Why Most Clinical Software Triggers Both Regimes, Not One

The most common buyer mistake is to treat DCB0160 as the full compliance answer for any digital product used in the practice, or to assume that "the vendor is not MHRA-registered" means there is nothing to do on the medical-device side. Both come from the same root cause: the two regimes are independent.

The DCB0129 specification states it directly. The standard "applies to all Health IT Systems including those that are also controlled by medical device regulations" (DCB0129 Specification v4.2, NHS England Digital, p.9, version dated 2 May 2018). The MHRA's stand-alone software flowchart adds the other half: in complex systems, only the modules that meet the device definition carry medical-device obligations, not the whole product (MHRA stand-alone software flowchart v1.10f, p.9, last updated 1 July 2023).

Put together, that gives four possible cases:

• DCB only. Health IT System with no medical-device function (e.g. EPR that replaces paper).
• MHRA only. Software with a medical purpose but no role in NHS real-time direct care (e.g. a stand-alone diagnostic app sold direct to patients).
• Both. A Health IT System that contains, or is, a medical device (e.g. a generative AI ambient scribe).
• Neither. Population-level products with no medical purpose and no real-time-care role (e.g. a board-reporting dashboard).

NHS England's long-read on digital clinical safety assurance covers the principle but stops short of working through the categories GP practices buy in volume — AI scribes, EPR modules and clinical decision support — and that is the gap this article fills. The buyer's question is not "is this software a medical device or a Health IT System?". It is "for each module of this software, which regimes apply, and what evidence does the vendor have?".

Regime 1: NHS Clinical Safety Standards at a Buyer's Level

DCB0129 (manufacturer) and DCB0160 (adopter) are published under section 250 of the Health and Social Care Act 2012 (page last updated 7 July 2025), which gives the Secretary of State or NHS England the power to publish information standards that apply to specified persons. The duty attaching to both today is to have regard to them. Section 95 of the Health and Care Act 2022 changed that to "must comply" from 7 July 2025, but regulation 3 of S.I. 2025/807 preserves the old position for every standard already in force, and both DCB standards are. Having regard to a standard is a real obligation to engage with it and to justify departures, not an invitation to skip it — and a revised standard would not be covered by the saving.

Two gating questions in NHS England Digital's step-by-step applicability guidance (last updated 4 August 2022) decide whether the standards apply at all:

1. Does the digital product support health or adult social care services in England?
2. Is the digital product used to influence, support or manage the real-time or near-real-time direct care of patients/service users?

If both answers are yes, the standards apply. Population-level products are explicitly out of scope: the same guidance states that "population health 'Digital products', for example those that are used for statistical reporting purposes, fall out of scope of DCB 0129 and DCB 0160". The "Health IT System" the standards talk about is defined in the DCB0129 specification glossary as "Product used to provide electronic information for health or social care purposes. The product may be hardware, software or a combination" (DCB0129 Specification v4.2, p.6).

Two consequences for a GP practice as a buyer:

The DCB0160 obligation sits on the practice regardless of MHRA status. The Health IT System being deployed might also be a medical device, but that does not relieve the practice of any DCB0160 work. There is just a separate manufacturer-side regime running alongside, with its own evidence and obligations on the supplier.

DCB0129 is the manufacturer's homework. A vendor that has done DCB0129 properly will share their clinical safety case report and hazard log on request. The practice uses that evidence as input into its own DCB0160 process; it does not replace it. NHS England Digital's background page on applicability is explicit that practices must "understand the manufacturer's DCB0129 then form your own DCB0160 risk assessment" (applicability — background, last updated 27 May 2022).

For more on the split, see Why DCB0129 is Not a Substitute for DCB0160, What is DCB0129? and A Plain English Guide to DCB0160. If your DCB0160 work also has to satisfy the Digital Technology Assessment Criteria (DTAC), the medical-device crossover is the same: DTAC's clinical safety pillar maps to DCB0160 and does not displace any MHRA obligation on the supplier.

NHS England's v2 review of both standards has reached public consultation, and it closes on 11 September 2026 (NHS England Digital, Review of digital clinical safety standards DCB0129 and DCB0160, last edited 30 June 2026). The current standards remain the live obligation until a revised version is published — but a revised standard would be published under the amended section 250, so the "have regard to" saving would not carry across to it. Date-stamp your safety case and re-check the standards page annually.

Regime 2: MHRA Medical-Device Regulation at a Buyer's Level

The Medical Devices Regulations 2002 (S.I. 2002/618), as amended, are the legal framework for medical devices in Great Britain. Regulation 2 of the in-force version (revision incorporating amendments to 17 June 2025) defines a medical device by reference to the manufacturer's intended purpose. A medical device is "any instrument, apparatus, appliance, software, material or other article" intended by the manufacturer to be used for human beings for the purpose of one or more of:

1. diagnosis, prevention, monitoring, treatment or alleviation of disease;
2. diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or handicap;
3. investigation, replacement or modification of the anatomy or of a physiological process; or
4. control of conception,

and which "does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means" (S.I. 2002/618, regulation 2). MHRA's how to comply with the legal requirements guidance reproduces this definition (last updated 15 January 2025).

A product is therefore not a medical device just because it is used in healthcare; it is a medical device because the manufacturer has declared an intended medical purpose that meets the four-limb test. The MHRA's stand-alone software flowchart lists non-device categories at p.10:

• Admin software ("book an appointment, request a prescription or have a virtual consultation… if it only has an administrative function").
• "An electronic patient record that simply replaces a patient's paper file".
• Software that "provides reference information to help a Healthcare Professional to use their knowledge to make a clinical decision".
• Software that "stores or transmits medical data without change".

(MHRA stand-alone software flowchart v1.10f, p.10, last updated 1 July 2023.)

Two misconceptions to correct straight away. "If it's used in healthcare, it's a medical device" — no; the MHRA flowchart explicitly lists admin, paper-replacement EPR and reference-only software as non-device categories. "There are just Class 1 and Class 2" — no; the UK Medical Devices Regulations (UK MDR) use Class I, IIa, IIb and III. The flowchart (p.26) confirms verbatim: "There are four classes as follows: Class I — generally regarded as low risk. Class IIa — generally regarded as medium risk. Class IIb — generally regarded as medium risk. Class III — generally regarded as high risk".

For software, the most-applicable classification rules are Implementing Rule 2.3 (software that drives or influences another device takes its classification), Rule 10 (active diagnostic devices, generally Class IIa with Class IIb / Class I carve-outs) and Rule 12 (other active devices, generally Class I). MHRA flowchart pp.26-27.

Manufacturers must register their devices with the MHRA before placing them on the Great Britain market, operate a post-market surveillance system, and report adverse incidents through the medical-devices vigilance system (MHRA flowchart p.30; GOV.UK, Post-market surveillance obligations by medical device type, last updated 5 September 2025). The buyer's job is to verify those arrangements are in place, not carry them out.

UK MDR reform is incremental. Post-market surveillance amendments came into force in 2025. A further statutory instrument introducing new pre-market requirements is expected in 2026, and a separate consultation on indefinite recognition of CE-marked devices closed in March 2026 (GOV.UK, Implementation of the future regulations, last updated 12 March 2026). UK MDR 2002 remains the in-force framework.

Module-Level Reasoning: Why a Product Can Be Partly Health IT, Partly Medical Device

The single most useful concept for a practice buyer is module-level reasoning. The MHRA flowchart spells it out:

"In complex systems it may be appropriate to UKCA mark only those functions/modules that meet the definition of a device rather than UKCA marking the whole product."

Source: MHRA stand-alone software flowchart v1.10f, p.9, last updated 1 July 2023.

A primary-care application is often a bundle: appointment booking, prescription request, structured EPR notes, plus (say) a QRisk3 cardiovascular calculator embedded in the consultation flow. Each module is assessed on its own:

• Appointment booking, prescription request — admin functions; not medical devices (flowchart p.10).
• Structured EPR notes that replace paper — not a medical device: the flowchart says "An electronic patient record that simply replaces a patient's paper file does not meet the definition of a medical device" (p.10).
• QRisk3 calculator embedded in the consultation flow — a medical device. NHS England Digital's applicability guidance names this exact case in Step 5: "the implementation of a QRisk3 calculator in a primary care desktop application" is an example where DCB0129/DCB0160 apply alongside medical-device requirements (applicability step-by-step, last updated 4 August 2022).

The buyer's question is not "is this application a medical device?". It is "which modules are medical devices, and what evidence does the vendor have for each one?". A vendor that says "the whole thing is registered" without naming modules has not done the work; a vendor that says "none of it is a medical device" while shipping a QRisk3 calculator is contradicting the flowchart. The same logic applies to AI ambient scribes, EPRs with added clinical decision support modules and symptom checkers built on reference content. List the modules, decide each against the four-limb test, then layer DCB0160 across whichever modules are used in real-time direct care.

How to Verify a Vendor's Claim: the AVT Registry and PARD Lookup

Once you know which modules matter, two primary-source registries verify what the vendor claims.

The Ambient Voice Technology (AVT) Self-Certified Supplier Registry is the canonical primary-source list for AI ambient scribes used in NHS settings, currently listing 27 suppliers (NHS England Digital, AVT Self-Certified Supplier Registry, last edited 21 August 2026). Suppliers self-certify that they meet NHS England's expectations on data protection, clinical safety, MHRA registration, hosting and information governance. To use it: open the registry, check the last-updated date, search by supplier name, and check the listed product (suppliers list specific products, not whole portfolios — if the product you are buying is not the listed one, the listing may not cover it). If a supplier is not on the registry, treat that as a hard signal: NHS England tells adopters not to enter commercial agreements without confirming the supplier meets national and local requirements (NHS England, Guidance on the use of AI-enabled ambient scribing products in health and care settings, version 3, published 27 April 2025, last updated 29 July 2026). It is equally explicit that it does not endorse listed suppliers, and that the registry is not a commercial framework.

The Public Access Registration Database (PARD), at pard.mhra.gov.uk, is the canonical primary-source database for any device claiming MHRA registration (GOV.UK, Medical devices: how to comply with the legal requirements, last updated 15 January 2025). To use it: search by manufacturer name first (match the contractual entity — many vendors trade as one entity and register under another), then by device name. The Global Medical Device Nomenclature (GMDN) code indicates intended purpose, the classification gives Class I, IIa, IIb or III, and the registration date confirms currency. Check the record matches the product — a Class I registration for a transcription product does not cover a generative summarisation product, because registration is intended-purpose-specific. "Not registered" is legitimate for admin software, and for an ambient scribe whose intended purpose is documentation only. What it is not legitimate for is a product marketed on clinical benefit.

Two things to remember. Registration is not endorsement — PARD records that the manufacturer has declared an intended purpose, classified the device under the rules and registered it; the MHRA has not reviewed it for safety or efficacy. AVT self-certification is not assurance — it does not replace your DCB0160 assessment, data protection review or information-governance work. The full verification workflow, with GMDN reading and a reusable buyer's checklist, is in the AVT registry and PARD buyer's verification workflow.

Worked Examples: a Buyer's Matrix

The matrix below works through scenarios that come up in GP-practice procurement, with the DCB and MHRA call for each and the primary-source citation behind it. Use it as a starter guide; every product needs its own module-level review.

Two patterns from the matrix. The same product can sit in different rows depending on what its modules do: a messaging app that is purely admin sits in "neither regime"; the same vendor's line plus a triage module would have to be reassessed, module-by-module. For AI scribes, the answer turns on intent rather than on the technology. The MHRA's ambient voice technology guidance (29 July 2026) gives transcription, summarisation for clinician review, structured-data capture, code suggestion and letter drafting as examples of products that are not medical devices, and reserves device status for products intended to suggest diagnoses or treatments, marketed on clinical benefit, or acting without clinician review. An earlier and widely repeated reading treated generative summarisation itself as the trigger; NHS England withdrew that wording when it aligned its own guidance with the MHRA on 29 July 2026. The longer treatment is in Deploying Ambient Voice Scribes with DCB0160 Compliance.

When This Gets Harder: Clinical Decision Support (CDS) Modules, EPR Modules, AI Scribe Scope Creep

Three borderline patterns have no bright line; the answer comes down to intended-purpose reasoning. Each has its own dedicated article; the summary below tells you which case you are in.

Reference Information vs Clinical Decision Support

The MHRA flowchart lists reference information as a non-device category (flowchart p.10) but provides no single bright-line test for the moment a reference product crosses into decision support. The closest primary-source test is the Software as a Medical Device (SaMD) intended-purpose guidance, which requires the manufacturer to specify how the SaMD output influences clinical decision-making (GOV.UK, Crafting an Intended Purpose in the Context of Software as a Medical Device, published 22 March 2023).

Practical buyer test: ask whether the module provides information for the clinician to use, or recommendations the clinician acts on. A drug-interaction database surfaced as look-up reference is one thing; an active prompt that says "do not prescribe X" is another. A static clinical-pathway library is one thing; an interactive pathway tool that asks for patient inputs and returns "next step" recommendations is another. Deeper treatment in Reference Information vs Clinical Decision Support: Where the Medical-Device Line Falls.

EPR Modules

A paper-replacement EPR is not a medical device (flowchart p.10). It gets harder when the EPR has accreted modules — coding suggestion, embedded risk calculator, AI summarisation that writes back to the record. Each module needs its own intended-purpose assessment; the EPR's overall non-device status does not protect them. No single primary source enumerates the threshold; the flowchart's module-level rule (p.9) is the operating principle. Deeper treatment in EPR Modules and the Medical-Device Line.

AI Scribe Scope Creep

A scribe procured as documentation support, then updated to offer suggested diagnoses, follow-up recommendations or autonomous actions, has crossed a regulatory line. The MHRA is explicit that where a product's intended purpose has changed it "may require assessment or reassessment as a medical device", and NHS England tells adopters to "ensure processes are in place to review any changes in functionality to determine whether they alter the product's regulatory status" (NHS England AI ambient scribing guidance, version 3, last updated 29 July 2026). The vendor's MHRA position may not have been revisited; the DCB0129 hazard analysis at procurement probably was not. The DCB0160 obligation is a re-assessment trigger every time the vendor materially changes the model, the modules or the deployed scope. Deeper treatment in Deploying Ambient Voice Scribes with DCB0160 Compliance.

In all three cases the operating principle is the same: work module-by-module, against intended purpose, then form a DCB0160 view across whichever modules are used in real-time direct care.

What This Means for Your DCB0160 Work and Your Clinical Safety Officer (CSO)

The medical-device side of a Health IT System does not change the shape of the DCB0160 work; it changes some of the inputs. NHS England Digital's background page on applicability is explicit: practices "understand the manufacturer's DCB0129 then form your own DCB0160 risk assessment" (applicability — background, last updated 27 May 2022). Where MHRA layers on, the practice has additional vendor evidence to gather (registration record, classification, post-market surveillance arrangements) and additional triggers for re-assessment when the vendor changes a registered module.

The Clinical Safety Officer is the right person to make the module-level call: a registered healthcare professional with appropriate training, translating manufacturer evidence into deployment-specific risk assessment. Practices without a permanent CSO can still satisfy the standard — see Setting Up a Clinical Safety Officer Role Without Extra Headcount and What is a Clinical Safety Officer?.

Post-market surveillance under UK MDR sits on the manufacturer (GOV.UK, Post-market surveillance obligations by medical device type, last updated 5 September 2025). The practice's ongoing obligations come through DCB0160: review and re-assessment when the system, configuration or use changes.

Three practical handovers should be in your CSO's diary for any product where both regimes apply:

• At procurement. Module list, intended-purpose statement per module, AVT registry check (if applicable), PARD record per registered module, DCB0129 safety case and hazard log from the manufacturer.
• At deployment. DCB0160 hazard log written for the deployed configuration. Controls that survive the realities of the consultation. Sign-off recorded.
• On material change. Re-assessment when the vendor changes a registered module, when the deployed scope changes (e.g. expansion to telephone consultations or home visits), or when NHS England changes the underlying guidance. See How to Conduct a DCB0160 Clinical Safety Assessment.

If you want a CSO-led module-level review of a system you are about to buy, contact us. The scope is verification of regulatory claims at the module level, a DCB0160 hazard-log starter, and a written record you can hand to the vendor and the deployment team.

What's Changing in 2026 and How to Date-Stamp Your Decisions

Three regulatory shifts matter for any buyer-side document signed in 2026.

MHRA medical-device reform is incremental. UK MDR 2002 (S.I. 2002/618), as amended, remains the in-force legal framework. Post-market surveillance amendments came into force in 2025. A further statutory instrument is expected in 2026 to introduce new pre-market requirements, including an international reliance scheme, and a separate consultation on indefinite recognition of CE-marked devices closed in March 2026 (GOV.UK, Implementation of the future regulations, last updated 12 March 2026).

Software and AI as a medical device guidance is consolidating. GOV.UK's Software and AI as a medical device page (last updated 3 February 2025) is the single reference point for AI/SaMD MHRA work, linking onward to the SaMD intended-purpose guidance.

DCB0129/DCB0160 v2 review is in flight. NHS England Digital's review page (last edited 30 June 2026) confirms the review has reached public consultation, closing 11 September 2026. The current standards remain the live obligation until a revised version is published.

For any decision you make under either regime, date-stamp the underlying source. Dates on this page reflect the position at 7 May 2026.

Common Misconceptions to Correct

1. "DCB0160 covers everything digital we use in the practice." No. DCB0160 applies to Health IT Systems used in real-time or near-real-time direct care; population-level analytics, policy-writing software and admin tools fall outside (NHS England Digital applicability tool, last updated 4 August 2022).

2. "If it's used in healthcare, it's a medical device." No. The MHRA flowchart explicitly lists admin software, paper-replacement EPRs and reference-information software as non-device categories (flowchart p.10, last updated 1 July 2023). The test is the manufacturer's intended purpose under regulation 2 of UK MDR 2002, not the use setting.

3. "If it's a medical device, DCB0160 doesn't apply." Wrong direction. When the medical device is also a Health IT System used in real-time direct care (or contains such a module), both regimes apply. DCB0129 v4.2 p.9 says so directly: the standard "applies to all Health IT Systems including those that are also controlled by medical device regulations".

4. "There are just Class 1 and Class 2 medical devices." No. UK MDR uses Class I, IIa, IIb and III (MHRA flowchart p.26). Misnaming the classes in a procurement document tends to indicate the buyer has not engaged with the rules.

5. "An AI scribe is a transcriber, so it's not a medical device." Nearly right, for the wrong reason. Under the MHRA's ambient voice technology guidance (29 July 2026), transcription, summarisation, structured-data capture, code suggestion and letter drafting for clinician review are all non-device examples — but the test is the manufacturer's intended purpose, not the feature list. The same scribe becomes a device if it offers suggested diagnoses, or if the marketing claims it guides diagnosis or improves outcomes. Read the sales material, not just the specification.

6. "Our symptom checker isn't a medical device because a clinician reviews the output later." Real-time clinician review affects the safety case and the DCB0160 risk assessment, but it is not the legal classification test. The MHRA flowchart's symptom-checker section says symptom checkers are Class I unless they "allow direct diagnosis", in which case they are Class IIa (flowchart p.39).

7. "DCB0129 supersedes the Medical Device Regulations for software." No. The two regimes run in parallel; neither replaces the other. A vendor that has done DCB0129 has met one obligation; they may or may not have met UK MDR registration obligations on top. See Why DCB0129 is Not a Substitute for DCB0160.

Key Takeaways and Next Steps

The central principle is that DCB and MHRA are two independent regimes, decided module-by-module against the manufacturer's intended purpose and whether the module supports real-time direct care.

Key takeaways:

• The buyer's question is "which modules?", not "is this a device?". A primary-care application can carry device modules alongside admin modules that are not.
• Verify vendor claims against the AVT registry (for ambient scribes) and PARD (for any MHRA registration claim). Registration is not endorsement, and self-certification is not assurance.
• The DCB0160 obligation sits on the practice regardless of the manufacturer's MHRA status. The two regimes run in parallel and neither replaces the other.
• Date-stamp every regulatory decision against the source you relied on. UK MDR reform and the DCB0129/DCB0160 v2 review are incremental but live; revisit annually and on material vendor change.

Next steps for practice managers:

• List the modules in every clinical software product you use, including ones bundled inside a single application.
• For each module, decide DCB and MHRA applicability against its intended purpose; gather the vendor's DCB0129 evidence and PARD record where applicable.
• Diary a re-assessment trigger on vendor model updates, scope changes (e.g. moving an AI scribe from face-to-face into telephone consultations) and material guidance changes from NHS England or MHRA.

If you would like a CSO-led module-level review of a system you are about to buy or have already deployed, book a demo. The scope is verifying regulatory claims at the module level and producing a DCB0160 hazard-log starter you can hand to the vendor and the deployment team.

Frequently Asked Questions

Do I need both DCB0160 and MHRA registration for clinical software?

It depends on what the software does. DCB0160 applies to your practice as the deployer of any Health IT System used in real-time direct care. MHRA registration is the manufacturer's obligation for any software (or module) that meets the medical-device definition under regulation 2 of UK MDR 2002. Many products trigger both regimes — AI scribes that summarise consultations, primary-care applications that embed risk calculators. The two obligations sit on different parties (you, and the manufacturer) and neither replaces the other (DCB0129 Specification v4.2, p.9). For help with a specific product, contact us for a CSO-led module-level review.

Is an EPR a medical device under MHRA regulation?

A paper-replacement EPR is not a medical device. The MHRA stand-alone software flowchart (p.10) is explicit: "An electronic patient record that simply replaces a patient's paper file does not meet the definition of a medical device". The harder question is what happens when the EPR has added modules — embedded risk calculators, coding suggestion, AI summarisation, decision support — over time. Each module is assessed on its own intended purpose; the flowchart's module-level rule (p.9) is the operating principle. Detailed walk-through in EPR Modules and the Medical-Device Line.

Is clinical decision support software a medical device?

It depends on whether it is reference information or actively influences a clinical decision. The MHRA flowchart lists reference-only software as non-device (p.10). The intended-purpose test in Crafting an Intended Purpose for SaMD (published 22 March 2023) requires the manufacturer to specify how the output influences clinical decision-making. No single bright-line test exists, so the safest approach is module-level reasoning against intended purpose. Detailed walk-through in Reference Information vs Clinical Decision Support.

How do I check if a vendor's software is MHRA-registered?

Use the Public Access Registration Database (PARD) at pard.mhra.gov.uk. Search by manufacturer name, then by device name. Confirm the GMDN code matches the product, the classification matches what the vendor has claimed, and the registration is current. PARD is the lookup MHRA itself points buyers to (GOV.UK, Medical devices: how to comply with the legal requirements, last updated 15 January 2025). For ambient AI scribes, also check the AVT Self-Certified Supplier Registry (last edited 21 August 2026). Step-by-step in the AVT registry and PARD buyer's verification workflow.

What is the AVT registry and what does it tell me?

The Ambient Voice Technology Self-Certified Supplier Registry is the canonical primary-source list of AI ambient scribe suppliers that have self-certified against NHS England's ambient scribing guidance. NHS England Digital maintains it; it currently lists 27 suppliers (last edited 21 August 2026). Suppliers attest to meeting NHS England's expectations on data protection, clinical safety, MHRA registration, hosting and information governance. Listing is not endorsement, and self-certification is not assurance. Procurement assurance still sits with you.

Is the DCB0160 standard changing?

Yes. NHS England's review page (last edited 30 June 2026) confirms the review has reached public consultation, which closes on 11 September 2026. The current DCB0129 v4.2 specification and DCB0160 are the live obligation until a revised version is published — and a revised standard would sit on the "must comply" footing rather than "have regard to". Date-stamp your safety case so revisions can be incorporated promptly.

What happens if my vendor changes the AI scribe model after we've deployed?

Material model changes can change the safety profile and are a re-assessment trigger under DCB0160. Your safety case should specify a trigger on vendor model updates; the vendor's DCB0129 process should generate notification when they make material changes. Practically, the CSO re-runs the parts of the hazard analysis the change touches, confirms controls still work, and updates the safety case. If the vendor adds modules that change the device classification (e.g. adding generative summarisation to a previously transcription-only product), MHRA registration may also need updating.

What does Class I MHRA registration mean for my practice?

Class I is the lowest-risk medical-device class under UK MDR 2002. Note that many ambient scribes will not be devices at all under the MHRA's ambient voice technology guidance (29 July 2026), so the first question is whether the product has a medical intended purpose, not what class it is. Where it does, Class I registration confirms the manufacturer has declared an intended purpose, classified the device under the rules and registered it with the MHRA — it does not mean the MHRA has reviewed the device for safety or efficacy. Higher classes (IIa, IIb, III) involve more conformity-assessment evidence; classification rules are in the MHRA flowchart, pp.26-27.

My software vendor says they're "DCB0129 compliant" — does that cover MHRA?

No. DCB0129 is a clinical-risk-management standard for the manufacture of Health IT Systems, published under section 250 of the Health and Social Care Act 2012. It does not replace UK MDR 2002. The DCB0129 specification itself states the standard "applies to all Health IT Systems including those that are also controlled by medical device regulations" (DCB0129 Specification v4.2, p.9). A vendor that has produced DCB0129 documentation has met one obligation; if any module of their product meets the medical-device definition, they have a separate UK MDR obligation on top. See Why DCB0129 is Not a Substitute for DCB0160.

Can a single product be partly a medical device and partly not?

Yes. The MHRA flowchart is explicit: "In complex systems it may be appropriate to UKCA mark only those functions/modules that meet the definition of a device rather than UKCA marking the whole product" (flowchart p.9). A primary-care application can have admin modules that are not devices alongside a QRisk3 calculator module that is. Ask the vendor which modules are covered by their MHRA registration, not just whether the company is registered.

Disclaimer. This article is for informational purposes only and reflects the regulatory position at 7 May 2026. It does not constitute legal advice. Practices should consult their Clinical Safety Officer, Data Protection Officer or legal counsel for advice on specific products and circumstances, and should refer to the latest NHS England, NHS England Digital, MHRA and GOV.UK guidance before making procurement or deployment decisions.

Primary Sources Cited in This Article

The list below is the verified primary-source set used throughout this article. Last-updated dates reflect the position at 7 May 2026; re-check before relying on any specific date.

• Health and Social Care Act 2012, section 250 (legislation.gov.uk). Page last updated 7 July 2025.
• DCB0129 Specification v4.2 (NHS England Digital). Version dated 2 May 2018, published 7 June 2018.
• DCB0160 publication record (NHS England Digital). Last updated 15 June 2023.
• Applicability of DCB0129 and DCB0160, step-by-step (NHS England Digital). Last updated 4 August 2022.
• Applicability of DCB0129 and DCB0160 — background (NHS England Digital). Last updated 27 May 2022.
• Review of digital clinical safety standards DCB0129 and DCB0160 (NHS England Digital). Last edited 30 June 2026.
• Medical Devices Regulations 2002, regulation 2 (legislation.gov.uk). Current in-force version (revision incorporating amendments to 17 June 2025).
• Medical devices: how to comply with the legal requirements (GOV.UK). Last updated 15 January 2025.
• Medical device stand-alone software including apps, v1.10f (MHRA). Last updated 1 July 2023.
• Crafting an Intended Purpose in the Context of Software as a Medical Device (GOV.UK). Published 22 March 2023.
• Software and AI as a medical device (GOV.UK). Last updated 3 February 2025.
• Implementation of the future regulations (GOV.UK). Last updated 12 March 2026.
• Post-market surveillance obligations by medical device type (GOV.UK). Last updated 5 September 2025.
• Ambient voice technology-enabled products (MHRA). Published 29 July 2026.
• Guidance on the use of AI-enabled ambient scribing products in health and care settings (NHS England). Version 3, published 27 April 2025, last updated 29 July 2026.
• Ambient Voice Technology Self-Certified Supplier Registry (NHS England Digital). Last edited 21 August 2026.
• Regulation 3, Health and Care Act 2022 (Commencement No. 10 and Transitional and Saving Provision) Regulations 2025 (legislation.gov.uk). In force 7 July 2025.