What does the law count as a medical device?
Anything, including software, that its manufacturer intends for a medical purpose. Regulation 2 of the Medical Devices Regulations 2002 (SI 2002/618) defines a medical device as "any instrument, apparatus, appliance, software, material or other article" with a listed purpose. The purposes include "diagnosis, prevention, monitoring, treatment or alleviation of disease". They also cover the diagnosis, monitoring or treatment of an injury or handicap. Software has been in the definition since the regulations were made, so a questionnaire engine gets no special treatment.
Everything turns on intended purpose. Regulation 2 defines it by the data the manufacturer supplies: the labelling, the instructions and the promotional materials. The MHRA's guidance on crafting an intended purpose, published 22 March 2023, says the statement is construed objectively and that marketing forms part of it. A vendor that promotes "automated clinical screening" has described a medical device, whatever its contract says. The MHRA's guidance on stand-alone software including apps, last updated 1 July 2023, applies that test step by step and carries appendices on symptom checkers and clinical calculators.
Where is the line for a consultation questionnaire?
Between collecting information and acting on it. A questionnaire that records a patient's answers and presents them to a prescriber is a data-capture tool. The clinician makes every judgement, so the software has no medical purpose of its own. The moment the software starts making or shaping the judgement, the analysis changes. The MHRA's February 2025 guidance on digital mental health technology, which covers chatbots and AI algorithms, puts it the same way. Software with "a medical purpose" and complex functionality is a device; software limited to wellbeing, or to recording and communicating data, is not.
The table applies that reasoning to the features found in online pharmacy consultation flows. It is a reading of regulation 2 and the MHRA guidance above, not a ruling on any product. Only the manufacturer's intended purpose statement, and ultimately the MHRA, can settle a specific case.
| Feature | Likely status | Reason |
|---|---|---|
| Form that records answers and shows them to the prescriber | Not a device. | Stores and communicates data. No medical purpose of its own. |
| Branching questions that skip irrelevant sections | Not a device. | Form logic. It changes what is asked, not what is decided. |
| Hard stop that declines a patient on age or postcode | Not a device. | An administrative or commercial rule, not a clinical judgement. |
| Automatic decline on a clinical answer, such as a condition or a medicine | Device. | Software decides the patient is unsuitable for treatment. That is a medical purpose. |
| Risk score or eligibility score shown to the prescriber | Device. | Information intended to inform a treatment decision. |
| BMI or dose calculation from patient inputs | Device. | The MHRA treats clinical calculators as candidates for device status. |
| Recommended product or dose presented to the prescriber | Device. | A treatment recommendation is a medical purpose. |
| Fraud checks: duplicate accounts, repeat orders, shared payment details | Not a device. | Administrative screening the GPhC expects, with no clinical judgement. |
Two rows deserve care. A hard stop on age is an eligibility rule. A hard stop because the patient ticked "history of pancreatitis" is a clinical exclusion, and software that applies it has taken the decision a prescriber would otherwise take. Vendors often describe both as "rules". The second is a device function. Likewise a BMI calculator sounds trivial, but a BMI threshold that gates a weight-loss supply is a clinical calculation with a treatment consequence. Our guide to designing an online consultation flow shows how to keep the human decision points visible in the flow itself.
What does device status require of the vendor?
A conformity mark, a registration, technical documentation and post-market surveillance. The MHRA's page on regulating medical devices in the UK, updated 20 February 2026, sets out the Great Britain route. The manufacturer affixes a UKCA mark to attest conformity with the UK MDR 2002. CE marked devices remain acceptable for a period. Devices certified under the EU directives are accepted until the sooner of certificate expiry or 30 June 2028. Devices compliant with the EU Medical Device Regulation are accepted until 30 June 2030. Non-sterile, non-measuring Class I devices can be self-certified. Higher classes need a UK Approved Body.
Registration is separate from marking. The MHRA's registration guidance says all medical devices "must be registered with the MHRA before they can be placed on the market in Great Britain". That includes custom-made devices and procedure packs. A manufacturer outside the UK "must appoint a single UK Responsible Person to take responsibility for all of their medical devices". The registration fee is charged by device category. From 1 April 2026 it is £300 a year for each GMDN category registered. The table summarises the obligations from those two MHRA pages.
| Obligation | Who | Detail |
|---|---|---|
| Intended purpose statement | Manufacturer. | Defines the device and every requirement that follows. Marketing must match it. |
| Classification | Manufacturer. | Class I, IIa, IIb or III under the UK MDR 2002 rules. Class I non-sterile, non-measuring devices are self-declared. |
| Conformity assessment | Manufacturer, plus a UK Approved Body above Class I. | Technical file, clinical evaluation, risk management and a declaration of conformity. |
| UKCA or accepted CE mark | Manufacturer. | CE accepted until 30 June 2028 (directive devices) or 30 June 2030 (EU MDR devices). |
| MHRA registration | Manufacturer or UK Responsible Person. | Before placing on the Great Britain market. £300 a year per GMDN category from 1 April 2026. |
| Post-market surveillance | Manufacturer. | Strengthened duties in force since 16 June 2025, including vigilance reports to the MHRA. |
The post-market surveillance regulations that took effect on 16 June 2025 matter to a pharmacy buyer more than they look. They oblige the manufacturer to gather and act on incident data from real use. If your vendor has no route for you to report a wrong output, it is not meeting a legal duty. The software is then unlikely to be the compliant device its brochure describes. Our guide to what to ask suppliers about DCB0129 covers the clinical safety file that should sit alongside.
What does it require of the pharmacy?
Due diligence, safe deployment and a record of both. The pharmacy is not the manufacturer, so it does not mark or register anything. It does carry the GPhC's standards. Standard 5.2 of the 2018 standards for registered pharmacies requires equipment and facilities to be "safe to use and fit for purpose". Standard 1.1 requires the risks of providing services to be identified and managed, and standard 4.2 requires services to be "managed and delivered safely and effectively". The GPhC's February 2025 guidance for pharmacies providing services at a distance goes further. It says the systems a pharmacy uses should be UKCA or CE marked, regularly backed up and maintained to the manufacturer's specification. It expects a business continuity plan for IT failure.
The GPhC's April 2026 position statement on AI adds the diligence step in terms. Pharmacy owners must "carry out due diligence to make sure AI tools are safe, appropriate and used in line with their intended purpose". They must also provide "suitable training, so staff understand the system and its limitations". The same statement confirms the division of labour: the GPhC "does not have a role in regulating AI tools/products or in assessing their clinical safety or technical performance". The MHRA judges the product. The GPhC judges your decision to use it.
On top of that sits the NHS clinical safety standard for deploying organisations. DCB0160 asks the organisation putting a health IT system into use to run its own clinical risk management under a named clinical safety officer. The manufacturer's DCB0129 file is the input. Our guide to what DCB0160 requires of pharmacies sets out the documents. Together the three layers answer the inspector's question: you knew what the software was, you checked it, and you trained people to use it within its limits.
Who is liable if unregistered software harms a patient?
The manufacturer for the product, the pharmacy for the decision to use it, and the professional for the decision made with it. Under regulation 61 of the UK MDR 2002 the Secretary of State, acting through the MHRA, has a duty to enforce the regulations. Regulation 60 provides that a UK Responsible Person "may be proceeded against as a person placing the device on the market". An unmarked, unregistered device is the manufacturer's breach first.
That breach does not shelter the pharmacy. The GPhC's standards for pharmacy professionals date from May 2017. They say pharmacy professionals "are personally accountable for meeting the standards and must be able to justify the decisions they make". Its April 2026 AI statement repeats that professionals remain "personally accountable for their professional practice, even when AI is being used". A superintendent who let unclassified software decline or approve patients will be asked why the pharmacy did not check. Our companion article on whether AI can triage patients safely works through the accountability chain in more detail.
The practical lesson is documentary. Keep the vendor's classification statement, the certificate or the written reasoning for non-device status, your DCB0160 assessment and the training record together. If a patient is harmed, that file is the difference between a vendor problem and a fitness-to-practise problem.
How do you check whether your software is registered?
Search the register, then ask for the documents the register cannot show. The MHRA's Public Access Registration Database lists registered manufacturers by name, address and GMDN device type. It does not list product names or model numbers. So it confirms that a company has registered a category of device, not that the tool on your screen is covered. Registration is also not approval: the MHRA does not assess or endorse products at registration. Any vendor calling itself "MHRA approved" has misdescribed the process. The checklist below covers the full check.
- Ask for the manufacturer's statement of intended purpose and compare it with the website copy and the sales deck.
- Ask whether the product, or any module of it, is classified as a medical device, and in which class.
- For a device, ask for the UKCA or CE certificate, the declaration of conformity and the name of any UK Approved Body.
- Search the MHRA's Public Access Registration Database for the manufacturer and the GMDN device type.
- For a "not a device" answer, ask for the reasoning in writing, referenced to the UK MDR 2002 definition and the MHRA software guidance.
- Ask for the DCB0129 clinical safety case and hazard log, and confirm the manufacturer has a route for you to report incidents.
- Check whether changes to scoring rules or models are covered by a change control process, and how you will be told.
- File everything with your DCB0160 assessment and your risk register.
Send every software supplier one email asking three things. Which functions are classified as a medical device? Which are not, and why? Where is the certificate or registration? A serious vendor answers within days with documents. A vendor that answers with adjectives has told you what you need to know. Keep the replies in the procurement file, because an inspector or a solicitor will ask the same question later.
Are decision-support rules in a PMR a medical device?
Often, yes, and the same test applies. A PMR that displays formulary text, records what was dispensed and prints labels is handling data. A PMR module that applies interaction rules or dose-range checks to a named patient's record and produces a warning is different. It is intended to inform a treatment decision, which is a medical purpose. The MHRA's stand-alone software guidance treats decision support and clinical calculators as candidates for device status, judged on the manufacturer's intended purpose. Under the UK MDR 2002 classification rules much of that software sits in Class I and is self-declared, which is why you may never have seen a certificate.
That does not mean nobody checked. It means the manufacturer signed its own declaration, and the only way to see it is to ask. The MHRA's AI Airlock illustrates how fine the line can be. TORTUS, a clinical documentation tool, joined the second cohort in October 2025 so that the regulator could examine when documentation support becomes decision support that needs classifying. If the MHRA is testing that boundary with a sandbox, your PMR vendor should be able to state where its own modules sit. Our guide to how AI is actually used in pharmacy software lists the questions to put to any vendor.
What is changing in 2026?
The framework, not the definition. The MHRA launched the National Commission into the Regulation of AI in Healthcare on 26 September 2025. Professor Alastair Denniston chairs it, with the Patient Safety Commissioner, Professor Henrietta Hughes, as deputy chair. It took evidence from December 2025 to February 2026 and is due to publish recommendations for a new regulatory framework during 2026. The MHRA's regulation page also records that the government will consult on indefinite recognition of CE marked devices. That would remove the 2028 and 2030 cliff edges for vendors relying on EU certification.
Classification is the other moving part. The UK MDR 2002 still follows the classification rules of the older EU directives, under which much stand-alone software falls into Class I. The EU's Medical Device Regulation, in force since 2021, places software that informs diagnostic or therapeutic decisions in Class IIa or higher under its rule 11. A vendor selling into both markets may therefore hold a self-declared Class I UKCA position and a Class IIa CE certificate for the same product. Ask which one your contract relies on. Whatever the Commission recommends, the regulation 2 test and the pharmacist's accountability will still be there when it lands.
Key takeaways
- Software is named in the UK MDR 2002 definition of a medical device, and the test is the manufacturer's intended purpose, read from labelling, instructions and marketing.
- A questionnaire that collects and displays answers is not a device. Software that scores answers, declines patients on clinical grounds, calculates doses or recommends treatment is.
- A device needs a UKCA mark or an accepted CE mark (to 30 June 2028 or 30 June 2030) and MHRA registration before sale. Registration costs £300 a year per device category from 1 April 2026.
- Post-market surveillance duties in force since 16 June 2025 mean your vendor must have a route for you to report wrong outputs.
- The pharmacy does not mark or register anything, but GPhC standards 1.1, 4.2 and 5.2 and the April 2026 AI statement require due diligence, training and fit-for-purpose systems.
- The MHRA's public database confirms manufacturers and device types, not products, and registration is not approval; ask for the certificate and intended purpose statement.
- The National Commission launched on 26 September 2025 is due to recommend a new framework in 2026, but the regulation 2 test stays.
Sources and further reading
- Medical Devices Regulations 2002, regulation 2: definitions (legislation.gov.uk)
- Medical device stand-alone software including apps (MHRA, updated 1 July 2023)
- Regulating medical devices in the UK (MHRA, updated 20 February 2026)
- Register medical devices to place on the market (MHRA)
- Software and artificial intelligence (AI) as a medical device (MHRA)
- Guidance for registered pharmacies providing services at a distance (GPhC, February 2025)
- Standards for registered pharmacies (GPhC, June 2018)
FAQs
Know which of your tools is a device.
Dataforge PMR publishes what each module does and which parts are clinical, so you can file the classification with your DCB0160 assessment. Whatever software you run, ask for the same clarity in writing.
See Dataforge PMR