Article
Whether a piece of software is a medical device is not decided by how sophisticated it is, how much it costs, or whether it uses machine learning. It is decided by what the manufacturer says it is for. Intended purpose, as stated in the labelling, the instructions, the marketing and the way the product actually behaves, is the hinge on which the whole regulatory regime turns. Clinical directors who understand that one point are equipped to ask the right questions of every vendor who walks through the door.
The definition, and where the line falls
Under the UK Medical Devices Regulations, software is a medical device if the manufacturer intends it to be used for a medical purpose: diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease or injury. Software that merely stores, communicates, searches or displays information without interpreting it for a medical purpose is not a device. Software that takes patient data and produces an output intended to inform a clinical decision generally is.
The MHRA's guidance on crafting an intended purpose makes the consequence explicit. A tool described as an aid to documentation is one thing. The same tool, once it starts to suggest a diagnosis, flag a risk score or recommend a referral, has acquired a medical purpose, and with it the obligations of a medical device: registration with the MHRA, a quality management system, technical documentation, clinical evaluation, post-market surveillance and conformity marking. The code may not have changed much. The regulatory status has changed completely.
The regulatory status of software is set by its claims, not by its code.
Why the classification is about to matter more
At the time of writing, most standalone software falls into Class I under the UK rules, which the manufacturer can self-declare without an Approved Body. The MHRA has signalled through its software and AI change programme that reform will move UK classification closer to the international approach, under which software that informs diagnosis or treatment decisions is at least Class IIa and subject to independent assessment. A product that is lawfully self-declared today may face a different bar after reform, and its manufacturer may or may not be ready for it.
For a clinical director this is not an abstract point. A deploying organisation that has built a workflow around a Class I self-declared tool may find that the tool's status is contested, that a vendor cannot produce the evidence a higher class requires, or that a competitor has already done the work.
Three ways organisations cross the line without noticing
Use drifts beyond the stated purpose
A documentation assistant is procured for its stated purpose. Six months later clinicians are using its summaries as a triage aid. The manufacturer's intended purpose has not changed. The organisation's use has. The MHRA regime places the obligation on the manufacturer, but the clinical risk, and the governance question under DCB0160, now sits with the deploying organisation.
Features are added by update
Vendors ship. An administrative tool gains a “clinical insights” panel in a release nobody in the organisation reviewed. The tool that was assessed at procurement is not the tool now in use. Without a process for reviewing releases against intended purpose, the organisation has no way of knowing when the line was crossed.
Marketing outruns the label
The intended purpose in the technical file is cautious. The sales deck is not. The regulator reads both. So should the buyer.
Two regimes, not one
Medical device status and clinical safety under DCB0129 and DCB0160 are separate obligations. DCB0129 applies to health IT systems deployed in the NHS whether or not they are medical devices; a manufacturer needs a signed clinical safety case regardless of MHRA class, and a deploying organisation needs its own case under DCB0160. Neither replaces the other. A vendor who answers a question about device status with a clinical safety case, or the reverse, has not answered the question.
What to ask, and what to keep
- The vendor's written statement of intended purpose, and confirmation that the marketing matches it.
- Regulatory status: whether the product is a medical device, its class, and the conformity marking it carries.
- The DCB0129 clinical safety case and the name of the Clinical Safety Officer who signed it.
- A release process that notifies you of changes affecting purpose or function before they reach your users.
- Your own record of how the tool is used in your organisation, and evidence that the use matches the stated purpose.
None of this requires a clinical director to become a regulatory specialist. It requires them to know that the question exists, to ask it before signing, and to keep asking it each time the software changes.
This article sets out Novatib's advisory position. It is not legal or regulatory advice.