Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

Is my software in class IIa, IIb, or III, Dark Fate

Here we are! White smoke over the European Parliament! The MDCG 2019-11 guidance on qualification and classification of medical device software (MDSW) was published the 11th of October 2019.

This guidance could compete with a FDA guidance, if there were an international contest of MD guidances. Similar structure, with definitions and reminders on the regulatory context, with plenty of examples, a bit verbose ... like a FDA guidance.

No surprise on qualification

The MDCG 2019-11 reuses the successful receipt of the MEDDEV 2.1/6: decision trees to qualify software as a medical device: one for MDSW and one for IVD SW. The decisions trees were adapted to the changes of the MDR/IVDR, compared to the MDD/IVDD. But there is no fundamental change: a software qualified as a SAMD for the MDD, remains qualified as a SAMD. Conversely, it's highly probable that software not qualified as SAMD with regard to the MDD will remain outside the scope of the MDR.
For this reason, and without any surprise, we retrieve almost the verbatim of the examples found in the MEDDEV 2.1/6.

The guidance also brings clarification on how to qualify SAMD using IVD data, either of SAMD, or of IVD SW, depending on the relevance of input data. A grey zone remains on software using both MD data and IVD data as input data. MD or IVD? We'll see in a couple of years if new examples are added to the guidance or the Manual on Borderline Classification.

Annex XVI software

The guidance also covers the case of software falling in devices listed in Annex XVI or their accessories. My two cents: don't try to place on the market such software right now. Wait for common specifications or guidances on Annex XVI.

No surprise on classification

Bid you farewell class I SAMD. The guidance doesn't resuscitate class I software and goes to a strict interpretation of the rogue, the villainous rule 11.
In a last symbolic gesture, the MDCG even added at the very end of the guidance an example of class I SAMD. But it is not convincing at all. If I were the vendor of this poor software, I would claim its use for wellness only, outside the scope of the MDR, with the help of a cryptic disclaimer written by my lawyer.

IMDRF SAMD categorization

Probably knowing how many SAMD would be sentenced to class III with a too strict reading of rule 11, the MDCG called the IMDRF cavalry to assist them in their quest for mercy.
The IMDRF SAMD categorization framework proposes a classification system, which is summed up in a table of the IMDRF document. This table was borrowed and amended by the MDCG, to map the MDR regulatory classes to the IMDRF classification table.
IMDRF SAMD table and MDCG SAMD table comparison.png
The IMDRF cagetorization scheme looks like a risk assessment policy, to establish the SAMD class:

  • Significance of SAMD information: likelihood that wrong data from software can lead to a damage,
  • State of healthcare: severity of the damage.

Thanks to this table inserted into the MDCG, it's now possible to introduce a dose of likelihood in the determination of SAMD regulatory class. E.g.: risk of death places your software in class III if we disregard the likelihood, with a strict reading of rule 11. Risk of death (critical situation) with software driving clinical management (medium significance) places your software in class IIb. Phew...

"Drives or influences", "in combination"

The implementing rule "drives or influence" was already a classification propeller in the MDD. It retains its characteristics in the MDR and IVDR similar implementing rules. But for SAMD, there's a risk that SAMD class is going to be boosted by rule 11.
If rule 11 classes SAMD higher than the implementing rule, rule 11 wins.

This is also applicable to embedded software (de facto a combination of software and medical device, see section 6.2 of MDCG 2019-11). If embedded software provides functions only inside the scope of the intended use of the hardware host, the device result of the HW+SW combination is in the class of the hardware. But if software has some more functions extending the intended use, rule 11 has to be invoked to give its judgement.
Thus, a device combination of a hardware host and an embedded software, can be placed in a higher class than hardware alone, per rule 11.


A few words on IVD SAMD classification. The guidance doesn't bring any interpretation of IVDR classification rules. A new guidance is in preparation for IVDR classification. This makes the title of the MDCG 2019-11 a kind of misleading advertising.
But we shouldn't place too high expectations on this future guidance. IVD SAMD will be placed in IVDR regulatory class B or higher, like the other IVD devices.


Class I SAMD is dead. But SAMD will rarely be in class III, with the benevolent assistance of the IMDRF categorization. Almost 100% of SAMD will require the CE certificate of a notified body, to be placed on the market. A wave of SAMD certification requests is already growing.

But where are the notified bodies able to certify SAMD? Where are the regiments of technical file reviewers, qualified at the same time on MDR/IVDR and SAMD, with a real understanding of software design processes and software risk management? In the MDR limbo.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed