Skip to main content
Back to articles

Protect Clinical Insights

AVT Registry and PARD: A Buyer's Verification Workflow for GP Practices

How a GP practice verifies an AI scribe or clinical software vendor's MHRA and AVT claims before buying: walkthroughs of the AVT registry and PARD, a reusable buyer's checklist, and how the result feeds your DCB0160 work.

Published · 11 May 2026Topics: clinical-safety, dcb0160, mhra, medical-devices, procurement, ai-technology
Practice manager checking the AVT registry and PARD database to verify a software vendor's regulatory claims

Why This Article Exists

If a software vendor tells your practice their product is "MHRA-registered" or "on the AVT registry", you should be able to verify both claims in under fifteen minutes before signing anything. The Ambient Voice Technology (AVT) Self-Certified Supplier Registry and the Public Access Registration Database (PARD) are the two primary-source lookups that let you do it. This article walks through both, how to interpret a Global Medical Device Nomenclature (GMDN) code, and a reusable ten-step checklist you can hand to your Clinical Safety Officer (CSO).

This is the practical companion to DCB0160 and MHRA Medical Devices: How the Two Regimes Apply to Software in GP Practices — the pillar explains the two-regime model and the module-level rule, this one shows the lookup workflow that follows. For the AI-scribe-specific deep dive, see Deploying Ambient Voice Scribes with DCB0160 Compliance.

Why You Should Verify the Vendor's Claim

A vendor that says "we are MHRA-registered" or "we are on the AVT registry" has made a verifiable claim. Verifying it is cheap; failing to verify it can leave the practice committed to a product whose paperwork does not cover what you are deploying.

MHRA registration is not endorsement. PARD records that the manufacturer has declared an intended purpose, classified the device under UK MDR 2002 and registered it with the MHRA. The MHRA has not assessed the product for clinical safety or efficacy (GOV.UK, how to comply with the legal requirements, last updated 15 January 2025). AVT self-certification is not assurance. Suppliers attest to NHS England's expectations on data protection, clinical safety, MHRA registration, hosting and information governance; NHS England Digital lists them, it does not vouch for them (AVT Self-Certified Supplier Registry, last updated 17 April 2026).

The deployer's obligations sit with the practice regardless. NHS England Digital is explicit that practices must "understand the manufacturer's DCB0129 then form your own DCB0160 risk assessment" (applicability — background, last updated 27 May 2022). A clean AVT listing and a current PARD record are inputs to that work; they do not replace it.

AVT Registry Walkthrough

The AVT registry is published by NHS England Digital and lists 23 suppliers as of 17 April 2026 (AVT Self-Certified Supplier Registry).

What to do on the page:

  • Note the last-updated date at the top. The registry refreshes regularly; a claim made against a stale version may already be out of date.
  • Search by supplier name. Suppliers self-list, so the trading name on the registry should match the entity that will sign the contract. If they differ, ask the vendor to reconcile.
  • Read the listed product name. Suppliers list specific named products, not whole portfolios. If the product you are buying is not the one named — a newer line, a different module configuration, a white-labelled version — the listing may not cover what you are deploying.
  • Check what the supplier has self-certified against. The registry sets out expectations around clinical safety, data protection, MHRA registration, hosting and information governance. A listing attests to meeting those; it is not an independent audit.

NHS England's AI ambient scribing guidance (published 27 April 2025, last updated 24 April 2026) sets the expectation that NHS organisations procure ambient scribes from registered suppliers. A supplier not on the registry is therefore a hard signal — ask why, and ask whether registration is in progress.

PARD Lookup Walkthrough

PARD is at pard.mhra.gov.uk — the canonical record of medical devices registered for the Great Britain market and the primary source MHRA itself points to (GOV.UK, how to comply with the legal requirements, last updated 15 January 2025).

A four-step lookup:

  1. Search by manufacturer name first. Use the exact contractual entity, not the trading or marketing name. Many vendors trade under one name and register under another — a parent company, a regulated subsidiary or an Authorised Representative. If you cannot find the manufacturer at all, clarify that with the vendor first.
  2. Search by device name. Match the product to a listed device. If the names do not match, ask the vendor to point you at the correct record. Watch for cases where the registered device is an older version, a different module configuration, or a different intended purpose than the one being marketed.
  3. Read the GMDN code and classification. Each record carries a Global Medical Device Nomenclature code indicating intended purpose, plus a class (I, IIa, IIb or III) reflecting risk. The next H2 walks through how to read these.
  4. Confirm the registration is current. A lapsed registration is not the same as a current one. A vendor claiming "MHRA-registered" against a lapsed record is a problem.

Two corner cases. A vendor may legitimately not need to be on PARD — admin software (appointment booking, prescription request, virtual consultation) is not a medical device and does not require registration (MHRA stand-alone software flowchart v1.10f, p.10, last updated 1 July 2023). And a vendor may be registered for one module but not another — Class I registration for transcription-and-summarisation may not cover a separate decision-support module.

Reading a GMDN Code

The Global Medical Device Nomenclature code is a standardised identifier for the device's intended purpose. Two GMDN-related checks matter at procurement.

Does the GMDN match what the vendor is selling? Codes are intended-purpose-specific. A code for "speech-to-text software for clinical documentation" reflects a different intended purpose from one for "clinical decision support software for primary care". If the vendor is marketing the product for a use case that does not match the GMDN, the registration may not cover what you are deploying.

Does the class match the clinical involvement? The four UK MDR 2002 classes are Class I (generally low risk), Class IIa and IIb (generally medium risk) and Class III (generally high risk) (MHRA flowchart p.26). Software that "allows direct diagnosis" sits at Class IIa (flowchart p.39); a vendor marketing diagnostic or decision-support functionality at Class I may be misclassified — worth raising in writing.

You do not need to be a regulatory specialist to spot obvious mismatches. Two questions: does the registered intended purpose match the product, and does the class match the clinical involvement?

Cross-Checking Against Your DCB0160 Hazard Log

A "registered" answer from PARD does not end the work; it feeds your DCB0160 process as one input among several. NHS England Digital's applicability background page is explicit that the practice must understand the manufacturer's DCB0129 risk assessment and then form its own DCB0160 risk assessment for the deployed configuration (applicability — background, last updated 27 May 2022). The operating principle is module-by-module: each module that influences real-time direct care needs its own hazard analysis in the practice's hazard log, with controls and residual-risk decisions recorded.

Practical hand-off to the CSO at procurement should include:

  • the PARD record reference and date you accessed it;
  • the AVT registry entry (where applicable), with the date checked;
  • the vendor's DCB0129 Clinical Safety Case Report and Hazard Log;
  • a written statement from the vendor on which modules are covered by the MHRA registration and which are not;
  • a confirmed list of vendor-side change triggers — model updates, scope changes — that will require re-assessment.

For the full DCB0160 assessment process, see How to Conduct a DCB0160 Clinical Safety Assessment and A Plain English Guide to DCB0160.

What "Not Registered" Actually Means

"Not registered" is not automatically a deal-breaker, and it is not automatically fine. Three sub-cases:

Case A: it does not need to be registered. Admin software does not meet the medical-device definition. The MHRA flowchart (p.10) lists administrative functions — appointment booking, prescription request, virtual consultation — and paper-replacement EPRs as non-device categories. A patient-messaging app that only handles reminders and signposting is admin software; you should not expect to find it on PARD.

Case B: it should be registered but is not. A vendor marketing generative AI summarisation, clinical-decision-support functionality or diagnostic features without a registration covering those modules is shipping a product that NHS England expects to be registered (AI ambient scribing guidance, last updated 24 April 2026, on the Class I expectation). Do not buy until they have addressed it.

Case C: it is registered under a different entity or module. A parent company may hold the registration; a Class I registration may cover the transcription module but not a decision-support module added later. Ask the vendor to identify the record that covers what you are deploying — registration reference, classification, GMDN, and a clear statement of which modules are covered. If they cannot, the registration does not cover what you are buying.

In all three cases, the right next step is a written question to the vendor, with the answer logged in the procurement file.

A Buyer's Verification Checklist

A ten-step workflow to run before signing. Steps 1–3 are the practice's own work; 4–7 are the lookup workflow; 8–10 are the hand-off into DCB0160.

  1. Confirm the product line. Name the specific product, version and module configuration. Regulatory paperwork is keyed to a specific one.
  2. Map the modules. List the discrete functions the product will perform — transcription, summarisation, coding, letter generation, decision support, EPR write-back, admin features. Each is assessed separately.
  3. Decide which modules are likely medical devices. Use the pillar's two-regime test — does the manufacturer's intended purpose for the module meet the four-limb test under regulation 2 of UK MDR 2002? If yes, expect a registration.
  4. For AI ambient scribes, check the AVT registry. Open the AVT registry, note the last-updated date, confirm the supplier is listed and the listed product matches what you are buying.
  5. Look up the manufacturer in PARD. Use the exact contractual entity at pard.mhra.gov.uk. If the manufacturer is not found, ask the vendor to identify the registering entity.
  6. Find the device record. Match the registered device name to the product. Note the registration reference and the date you accessed the record.
  7. Read the GMDN and classification. Confirm the registered intended purpose matches the product as marketed, and the class is consistent with the clinical functionality. Flag mismatches in writing.
  8. Request the vendor's DCB0129 paperwork. Ask for the Clinical Safety Case Report and Hazard Log. For the matching questions to ask in the same conversation, see the seventeen-question vendor checklist in Deploying Ambient Voice Scribes with DCB0160 Compliance.
  9. Record re-assessment triggers. Get written confirmation of how the vendor will notify you on material change — model update, module addition, scope expansion, registration update. This goes into your CSO's diary against your DCB0160 hazard log.
  10. File the evidence. PARD reference, AVT entry, last-updated dates, vendor DCB0129 paperwork, written answers on module coverage and re-assessment triggers — all into the supplier file with access dates. Re-check at least annually and on any vendor-notified material change.

Frequently Asked Questions

How do I check if an AI scribe vendor is MHRA-registered?

Use PARD at pard.mhra.gov.uk. Search by manufacturer name (the contractual entity, not the trading name), then by device name. Confirm the GMDN matches the product as marketed, the classification matches the clinical functionality, and the registration is current (GOV.UK, how to comply with the legal requirements, last updated 15 January 2025). For ambient scribes, also check the AVT registry.

Is the AVT registry the same as MHRA registration?

No. The AVT registry is NHS England Digital's list of ambient-voice-technology suppliers that have self-certified against NHS England's ambient scribing expectations. MHRA registration is a separate statutory requirement under UK MDR 2002 for any product that meets the medical-device definition. An AVT listing implies the supplier has attested to holding MHRA registration where applicable — verify that separately on PARD.

What if the vendor is not on the AVT registry?

For an AI ambient scribe, treat it as a hard signal. NHS England's AI ambient scribing guidance (last updated 24 April 2026) expects NHS organisations to procure from registered suppliers. Ask the vendor whether registration is in progress. For products that are not ambient scribes, the AVT registry does not apply.

What does Class I MHRA registration mean for the practice?

Class I is the lowest-risk medical-device class under UK MDR 2002. It confirms the manufacturer has declared an intended purpose, classified the device and registered it — not that the MHRA has reviewed it for safety or efficacy (MHRA flowchart p.26, last updated 1 July 2023). NHS England's stated expectation for ambient scribes is at least Class I; higher classes involve more conformity-assessment evidence.

How often does the AVT registry update?

It refreshes regularly; the page carries a last-updated date at the top. As of 17 April 2026 it lists 23 suppliers. Note the access date in your procurement file each time you check.

A vendor says they are "DCB0129 compliant" — does that cover MHRA?

No. DCB0129 is the NHS clinical-risk-management standard for the manufacture of Health IT Systems; it does not replace UK MDR 2002. The DCB0129 specification itself states that 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 done DCB0129 has met one obligation; if any module meets the medical-device definition, they have a separate UK MDR registration obligation on top. See Why DCB0129 is Not a Substitute for DCB0160.

What if the registered intended purpose does not match what the vendor is selling me?

Raise it in writing. MHRA registration is intended-purpose-specific — a GMDN code keyed to a transcription product does not cover generative summarisation or decision-support functionality. Ask the vendor to identify the registration record (or pending application) that covers the functionality you are buying. If they cannot, do not sign until they can.

Can I rely on the vendor's website or PDF instead of PARD?

No. Vendor self-statements are not regulatory primary sources. A claim on a vendor website that does not match the PARD record is a contradiction worth resolving before procurement, not after.

If you want a CSO-led module-level review of a system you are about to buy — verifying the registration record against the modules being deployed and producing a DCB0160 hazard-log starter — contact us.

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

Primary Sources Cited in This Article

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