So You’ve Just Found Out Your Low-Risk Device is Actually Class IIb
Article Summary
Designing a medical device requires aligning with regulatory expectations from the very beginning. By clearly defining intended use, understanding risk classification, and building your technical file early, you can avoid costly redesigns and accelerate your path to market.Article Contents
Introduction
The initial stages of designing a medical device can be the most exciting for many innovators: you’ve identified a problem, ideas are fast flowing, you’ve gathered a talented team, and you’ve realised that the solution is feasible and within reach. The only thing you need now is to design an initial functional prototype which you can use for grant fund applications and pitch decks.
Although oversimplified, this is, in fact, the correct approach. The only issue is that it’s oversimplified. Identifying a problem comprehensively requires data, getting a talented team together is no simple task, and designing your initial prototype will have you dodging pitfalls like a contestant in Takeshi’s Castle. Afterall, medical devices is one of the most heavily regulated sectors in the world.
This article will focus on that last point – how to align your medical device design with regulatory expectations from day one, and not something added as an afterthought. To keep things concise, references will be made to the EU regulatory framework, though many of the principles discussed here are equally applicable to the UK and US markets, as well as other international regulatory frameworks.
Below I present three key aspects of regulatory thinking that can be easily incorporated into the initial stages of medical device development. Let’s begin.

Medical Device’s Intended Use
In Article 2 of Regulation (EU) 2017/745, the definition of a medical device contains the following: ” medical device means any instrument, apparatus, […] or other article intended by the manufacturer to be used […]”.
The phrase “intended by the manufacturer” is doing a remarkable amount of heavy lifting.
It does not say “used in practice”, nor “capable of being used”, nor “likely to be used”. It refers specifically to how the manufacturer intends the device to be used. In regulatory terms, this is distinct from misuse, off-label use, or creative interpretation by an enthusiastic clinician. You are not regulated based on what someone could do with your device; you are regulated based on what you say it is for.
This brings us to the intended use statement, one of the most powerful sentences you will write during development.
An intended use statement must unambiguously define:
- The clinical purpose of the device
- The target patient population
- The intended user (layperson, healthcare professional, specialist)
- The use environment (home, ambulance, ward, operating theatre)
- Any relevant limitations
At first glance, it may seem obvious whether a medical device is destined for the home or a clinical environment. You are unlikely to encounter an MRI machine in the living room any time soon. But consider something more plausible: a novel blood pressure monitor that incorporates a diagnostic function. Technically, it could be used at home by a patient monitoring their own condition, or in a clinic by a trained healthcare professional.
Those two environments look deceptively similar from a hardware perspective. Yet the regulatory and design implications are very different.
If intended for use by a layperson at home:
- The user interface must compensate for lack of medical training.
- Instructions for use must be exceptionally clear and accessible.
- Usability engineering must address foreseeable misuse.
- The design must tolerate user error, incorrect cuff placement, and inconsistent technique.
If intended for use in a hospital:
- More complex functionality may be acceptable.
- Operator training can be assumed and documented.
- Device labelling can rely on clinical terminology.
- Integration into wider care pathways may be expected.
Same concept. Same core technology. Different intended use, and therefore different design requirements.

Medical Device’s Risk Classification
Once intended use is defined, the next question follows naturally: what is the risk classification of the device?
Under Annex VIII of Regulation (EU) 2017/745, medical devices are assigned to one of four risk classes: Class I, Class IIa, Class IIb, or Class III.
Classification is determined by applying a series of rules based on factors such as invasiveness, duration of contact, anatomical site, whether the device is active, whether it administers or exchanges energy, and so on. The higher the class, the greater the regulatory scrutiny, which also means access to market is longer and more costly.
It is not unusual for classification to become one of the single biggest drivers of commercial viability.
Imagine you are developing a means to treat insomnia with a soft, comforting cushion designed to help synchronise a user’s breathing to promote sleep. Perhaps it gently expands and contracts in rhythm, encouraging paced breathing. A relatively benign concept. Depending on the claims, you might initially consider it low risk – Class I.
Then a new study suggests that sleep quality improves further when body temperature is regulated within a specific range. You add a modest heating element to the cushion to maintain optimal warmth.
From an engineering standpoint, this feels incremental. From a regulatory standpoint, it may not be. You have now introduced active energy delivery and thermal risk in the form of potential for burns or overheating.
What was previously Class I may now fall into Class IIa, or potentially IIb, depending on the specifics of intended use and physiological interaction.
The feature addition is small. The regulatory consequences are large.
A word of caution: Risk classification is nuanced and highly context dependent. It requires careful interpretation of Annex VIII and its associated guidance. Do not rely solely on AI tools to make this determination.
At the time of writing, when prompted to list examples of Class I medical devices, one large language model confidently stated that a “basic medical record storage software” is considered a Class I medical device. This is incorrect, not because the classification is wrong, but because this isn’t even a medical device.

Medical Device’s Technical File
All of this (intended use, classification, risk analysis, design decisions), ultimately converges into one central artefact: the technical documentation, often referred to as the technical file.
The technical file is not a single document. It is a structured body of evidence demonstrating that your device complies with the MDR’s General Safety and Performance Requirements (GSPRs).
At a high level, it will include:
- Device description and specification
- Intended use and classification rationale
- Design and manufacturing information
- Risk management documentation
- Verification and validation data
- Clinical evaluation
- Labelling and instructions for use
- Post-market surveillance planning
If you think this sounds substantial, then you are 100% correct.
However, the technical file should not be viewed as something compiled at the end of development in a frantic pre-certification rush. When approached correctly, it is simply a reflection of a well-structured development process.
If you define intended use and the risk classification early, you mitigate the risk of costly re-design later. Designing with regulations in mind does not mean designing fearfully or conservatively. It means designing deliberately and recognising that every design choice, such as material, feature, claim, user interface, and environment, has regulatory implications.
By baking this understanding into the design pipeline early, you will encounter fewer unpleasant surprises on the way to market.
Disclaimer. The views and opinions expressed in this article are solely those of the author and do not necessarily reflect the official policy or position of Test Labs Limited. The content provided is for informational purposes only and is not intended to constitute legal or professional advice. Test Labs assumes no responsibility for any errors or omissions in the content of this article, nor for any actions taken in reliance thereon.
Get It Done, With Certainty.
Contact us about your testing requirements, we aim to respond the same day.
Get resources & industry updates direct to your inbox
We’ll email you 1-2 times a week at the maximum and never share your information