MDR Classes IIa and IIb are not rungs on a ladder

More and more healthcare software companies are announcing certification as a Class IIa medical device. That is a real achievement and should be taken seriously.

At the same time, MDR classes are often discussed as if they were successive levels on a compliance ladder: Class IIa is good, Class IIb is better and Class III is best.

That is not how the Medical Device Regulation works.

A Class IIb device is not necessarily more compliant, more advanced or more effective than a Class IIa device. Both must comply fully with the requirements that apply to their classification. The difference is primarily about the device's intended purpose and the risks associated with the clinical decisions it informs.

First: is the software a medical device?

Before assigning a class, there is a more fundamental question: does the software qualify as a medical device at all?

Not every piece of software used in healthcare falls under the MDR. Software used only for administration, communication, storage or simple search will often not qualify as medical device software. The same may apply to general wellness products without an intended medical purpose.

This is an important distinction. Such software is not automatically Class I; it may sit outside the medical-device framework altogether.

Software becomes medical device software when its manufacturer gives it an intended medical purpose that falls within the MDR definition. Once that has been established, the relevant classification rules determine whether it belongs in Class I, IIa, IIb or III.

Classification is not a compliance score

For medical device software, Rule 11 of the MDR is often central. It classifies software according to the significance of the information it provides, the clinical context in which it is used and the potential consequences of the decisions it informs.

In simplified terms:

• Class I. The remaining category for medical device software that is not covered by the higher-risk parts of Rule 11 or another applicable rule. European guidance gives examples such as software that helps people with communication disorders convert selected symbols into spoken language. Class I software can generally be self-declared by the manufacturer.
• Class IIa. The starting classification for software that provides information used to make diagnostic or therapeutic decisions, unless the possible impact of those decisions meets the threshold for IIb or III. It also covers certain software used to monitor physiological processes.
• Class IIb. Software is classified as IIb when the decisions it informs could lead to a serious deterioration in a person's health or to a surgical intervention. It can also include software continuously monitoring vital physiological parameters when changes could place the patient in immediate danger.
• Class III. Software is classified as III when the decisions it informs could lead to death or an irreversible deterioration in a person's health.

These summaries are useful, but they are not enough to classify a real product. European guidance explicitly says that examples are illustrative and that classification can change when the intended purpose, patient population or context of use changes.

The same apparent functionality can therefore fall into a different class when used for a different population, condition or clinical decision.

The real difference between IIa and IIb

Class IIa and Class IIb are not simply two distances along the same product roadmap. They reflect different risk profiles.

Class IIa is the default under Rule 11 for software that provides information used in diagnosis or therapy. Class IIb applies when the potential consequences of the decisions informed by that software cross a specific threshold: serious deterioration of health or surgical intervention.

That does not mean Class IIa software is limited to administrative or trivial work. The official European guidance includes meaningful clinical functions among its IIa examples. Nor does involving a healthcare professional automatically make software Class IIa. Human review is important, but classification still depends on the intended purpose, clinical context and potential impact of the decision.

Similarly, a Class IIb conformity assessment does not give a manufacturer general permission to make any clinical claim. A device is assessed and CE-marked for a specifically defined intended purpose. New functionality or claims may change its risk profile and require a new assessment.

Why Ask Aletta is pursuing Class IIb

Our ambition is to develop Ask Aletta from a reactive clinical knowledge platform into a proactive assistant embedded in the clinical workflow.

We want it to understand the context of the patient, help healthcare professionals prepare consultations and provide information that supports medical decisions at the moment it matters. Some of those decisions may concern serious conditions where incorrect information could contribute to a serious deterioration in a patient's health or to a surgical intervention.

It is that intended purpose and associated risk profile—not a desire to obtain a higher number—that lead us to the Class IIb pathway.

We could define a narrower intended purpose and build a more limited product. But that would not be the Ask Aletta we are working towards. At the same time, pursuing Class IIb does not mean we can make unlimited claims. It means we must define precisely what the product is intended to do and produce the technical, clinical and quality evidence required to support that purpose.

The classification follows the product, not the other way around.

Sources

• Regulation (EU) 2017/745 on medical devices, including Rule 11
• MDCG 2019-11 rev.1: Qualification and classification of software
• MDCG 2021-24 rev.1: Guidance on classification of medical devices