Authors:

Miriam Schulze CEO of BAYOOMED

Julia Schliesch Marketing Generalist at BAYOOMED

Hardly any rule in the European Medical Device Regulation (MDR) has changed the software industry as much as Rule 11. It determines how medical device software is classified – and therefore also how quickly a product can actually be brought to market. As soon as software falls into Class IIa, a Notified Body is required. For manufacturers, this primarily means additional costs, longer certification processes and often a delay of at least 3-6 months before market entry. For the first product in particular, onboarding with a notified body alone, including Stage 1 and Stage 2 audits, can quickly take twelve months or longer.

This is precisely why the currently discussed revision of Rule 11 is attracting so much attention. But what is actually being revised? Why was the previous regulation criticized? And why do many manufacturers try to avoid being classified in Class IIa as much as possible?

Rule 11 can be found in Annex VIII of the MDR and regulates the classification of medical device software. The current Rule 11 of the MDR reads:

The problem: Under the current MDR, many software products are relatively quickly assigned to at least Class IIa – especially if they support diagnostic or therapeutic decisions or provide medically relevant information.

Modern software solutions such as clinical decision support, AI-based evaluations, digital health applications and monitoring tools are particularly affected by this.

Criticism from the industry has therefore been voiced for years: As soon as software becomes medically relevant, it very quickly ends up in at least Class IIa in regulatory terms. Their proposal is therefore:

First of all, it is important to note that nothing has been finalized yet. The EU Commission has currently only published a proposal to revise the MDR and IVDR. This is currently being discussed politically and professionally.

The background to this is the criticism that the existing classification logic for software has become too general. The explanatory document on the EU Commission’s revision proposal states that certain classification rules should be adapted in order to align the risk classification of products – particularly software – more closely with the actual risk.

A key point here is that software should in future be classified more frequently as Class I – with subsequent higher classification depending on the clinical risk.

The new structure is based more closely on the international IMDRF model. This evaluates software on the basis of two factors:

• how strongly software influences clinical decisions,
• and how critical the respective clinical situation is.

This is intended to make the classification more risk-based overall.

In future, the current proposal explicitly distinguishes between “critical”, “serious” and “non-serious situations” and between software that merely informs or actively controls clinical management (“drive clinical management”).

Depending on the combination of these, software is to be classified as Class IIa, IIb or III in future. For example, the proposal envisages Class III for software if it could cause a risk of death or irreversible damage to health in a critical situation. Class IIb would apply, for example, if software actively controls clinical decisions in critical situations.

The actual discussion is less about the number “IIa” itself – but about the consequences associated with it.

The actual discussion is less about additional regulatory requirements – because basic requirements for documentation, risk management or software development also apply to Class I products. The key difference is that Class IIa also requires the involvement of a notified body. This results in considerable additional costs, longer certification times and a significantly higher internal resource requirement.

This is particularly critical when it comes to software. Modern development processes are based on rapid iterations, regular updates and agile development. The regulatory requirements and procedures of traditional medical devices are difficult to adapt for low-risk digital products.

This is particularly challenging for smaller manufacturers, start-ups and digital health companies. While large medtech companies usually already have established regulatory and quality management structures in place and have long since completed onboarding with the Notofied Body, Class IIa can quickly become a considerable economic burden for smaller companies.

This is why Rule 11 is often discussed as a brake on innovation – especially in comparison to the USA. There, the FDA takes a much more risk-based approach to digital medical devices in several areas:

• Enforcement discretion for low-risk software:
  For certain low-risk software functions, the FDA deliberately refrains from actively enforcing regulatory requirements – even if the software could formally fall under the device definition.
• Exceptions due to the 21st Century Cures Act:
  Certain clinical decision support and health IT functions are no longer considered medical devices in the USA and therefore do not fall under traditional FDA regulation.
• General wellness exceptions:
  Apps and digital applications with a general focus on wellness or prevention are classified significantly lower under certain regulatory conditions or are not considered medical devices at all.
• More flexible regulation of AI software:
  With so-called Predetermined Change Control Plans (PCCP), the FDA is increasingly creating opportunities to cover certain changes to AI-based medical devices in advance from a regulatory perspective without requiring a new approval for each adaptation
• Stronger focus on actual risk:
  Overall, the FDA approach to software is often considered to be more pragmatic and more focused on the actual patient risk. This makes the US market increasingly attractive for many digital health companies, despite other challenges.

Although the revision is welcomed in principle, many questions remain unanswered.

The main reason: Numerous terms in the current proposal are still open to interpretation. And it is precisely these terms that ultimately determine whether software is classified as Class I, IIa, IIb or even III.

The wording relating to non-serious situations is currently the subject of particularly critical debate. This is precisely where many stakeholders see the danger that even more software products could be automatically classified as Class IIa in future – even if the actual risk is comparatively low.

The discussion is therefore now less about individual classes – and more about the question of how predictably and consistently software can be classified at all.

The EU Commission’s current proposal is not yet final. The next step will be consultations in the European Parliament, discussions in the Council as well as further expert opinions and possible adjustments.

Many experts believe that the definition of key terms in particular needs to be further clarified. In addition, future guidance documents are likely to play a decisive role in practical application. Numerous industry players and specialist organizations have therefore already submitted comments and proposed amendments to the current draft.

Numerous associations such as BVMED together with Spectaris and VDGH, as well as the SVDGV, have submitted their feedback and suggestions. One thing is already clear:
The discussion about Rule 11 shows how difficult it has become to strike a balance between patient safety, promoting innovation and regulatory practicability in modern medical device software.

The planned revision of MDR Rule 11 is a clear signal that the current software classification is considered too unrealistic in many areas.

It is true that the new regulation is intended to be more risk-based in future and allow Class I to be used more frequently again. At the same time, however, the current discussion also shows that many questions of definition and interpretation remain unanswered.

So why does hardly any manufacturer want to end up in Class IIa?

Not because of the name itself – but because of the economic consequences for low-risk digital medical devices: higher costs and longer development times later remuneration options

For modern software products in particular, the leap to Class IIa can therefore mean far more than just a different classification. For many companies, it changes the entire regulatory and economic environment of their product.

This makes an early regulatory strategy all the more important – from the right intended purpose to the appropriate classification and approval strategy. This is precisely where we support manufacturers of digital medical devices with practical regulatory advice and individual solutions – even if products already fall under Class IIa.