Software in Medical Devices, by MD101 Consulting

Qualification

Crafting a well-defined and clear intended purpose is paramount for the regulatory compliance and safe use of MDSW says the guidance. This is what lots of software editors strive to do. Not for regulatory compliance, but to keep their software outside the regulatory hassle of MDR/IVDR.

Simple search

Some restrictions about what is considered a simple search were added. On purpose, this is consistent with a rigorous approach to consider that using NLP isn't simple search. Searching for patterns in medical images isn't simple search either.

New examples

Some new examples of MDSW were added. This is useful, if you look for some MDSW similar to your case. E.g.: Some VR applications, or SW module integrated in a EHR platform and outputting diagnosis results are actually MDSW.

As long as the definition of medical device in MDR article 2 is what it is, the content of this guidance won't be alleviated. On the contrary, it will be loaded with new examples of MDSW.

We are in a situation opposite to the FDA's law enforcement discretion policy, for example with CDSS.

Classification: Rogue rule 11

Rule 11 is still there, still harmful and merciless for all medical device manufacturers having MDSW in their products:

• Extensive interpretation of sub-rule 11a) Software intended to provide information which is used to take decisions with diagnostic or therapeutic purposes makes almost any kind of SaMD class IIa,
• No change to table 1 Classification Guidance on Rule 11 either. Bloated by class IIa cells and inconsistent with IMDRF table.

But the definition of medical device in MDR isn't limited to diagnosis and treatment. Other modes of actions are present.
If my software is intended to prevent a disease, in which class is it?

Crossing the MD definition and rule 11

In the MD definition, we find the following modes of action:

• diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
• diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability,
• investigation, replacement or modification of the anatomy or of a physiological or pathological process or state,
• providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations,
• devices for the control or support of conception;
• products specifically intended for the cleaning, disinfection or sterilisation of devices (...).

In rule 11, we find the following modes of action:

• 11a: (3 first paragraphs of Rule 11) intended to provide information which is used to take decisions with diagnostic or therapeutic purposes;
• 11b: (Paragraph 4 of Rule 11) intended to monitor physiological processes or parameters;
• 11c: (Paragraph 5 of Rule 11) all other uses.

Some definitions

The definition of medical device uses, several terms, which require a definition.

The definition of diagnosis can be found in MDCG 2022-5:

• Diagnosis is the process of investigation of the anatomy, morphology, the condition or the functions of the human body irrespective if these are physiological or pathological, and subsequent interpretation of this information with a view to determining possible abnormalities. In this context, investigation can include visualisation, detection or measurement.
  

There is no definition of therapy, therapeutic or treatment or prognosis in MDR or MDCG or MEDDEV documents. Nothing either in 21 CFR or FDA guidance.
Here are definitions from Merriam-Webster dictionary:

• Prognosis: the prospect of recovery as anticipated from the usual course of disease or peculiarities of the case
• Therapeutic: of or relating to the treatment of disease or disorders by remedial agents or methods
• Treatment: the action or way of treating a patient or a condition medically or surgically : management and care to prevent, cure, ameliorate, or slow progression of a medical condition.

The table below takes each word found in the definition of medical device in MDR article 2, and crosses it with the wording of sub-rule 11a: Software intended to provide information which is used to take decisions with XXX purposes.
This exercise was made to envision a maximum of modes of action of a MDSW.

Interpretation of sub-rules vs definition of medical device

Class IIa, class IIb, and class III dominate the results of this table. This is not surprising. As soon as software answers to the definition of medical device (diagnosis, treatment, prognosis and so on), it falls into the case of sub-rule 11a. Sub-rule 11a is so broad that almost any type of software delivers information for diagnosis or therapeutic purposes. In a direct or indirect manner, like a 3-cushion billiard shot.

This is why lots of medical device manufacturers strive to craft an intended use, trying to keep their software in class I.
Unsuccessfully, when you read this guidance and interpret sub-rule 11.a in a rigorous way.

Some people greet the addition of an example in class I. One example. Versus lots of cases in higher classes. Nothing to get excited about.

Wishful thinking solution

As already mentioned in a previous post, a little word could be a game changer.

In the good old times of the MDD, we had the rule 10a for active devices where direct diagnosis was covered. Placing MDSW in class IIa. All other software providing information in an indirect way was in class I by rule 12.

Borrowing the spirit of MDD rule 10a, the word direct would make lots of software in class I:
In sub-rule 11.a, replace:
Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes
By:
Software intended to provide information which is used to take decisions with direct diagnosis or therapeutic purposes.

This little word would change the world of MDSW! Lots of software are used early in the care pathway. Conversely, medical imaging software would stay in class IIa. Their output is actually used for direct diagnosis.

Modular approach

This MDCG guide also contain a welcomed and interesting update of section 7 on the modular approach.
It will be useful for editors of heath-software with modules qualified as MDSW. Thanks to the provided examples.

It also contains a discussion on the combination of MDSW and non-MDSW. This combination shall remain safe and effective.
Evidence of safety and effectiveness shall be brought by:

• Architectural representation of MDSW and non-MDSW, clearly delineating the MDSW boundaries,
• Risk assessment, taking into account software failures coming from non-MDSW, and consequences on MDSW
• Risk assessment, taking into account usability on non-MDSW displaying MDSW output.

Effective segregation

The guide doesn't mention how effective the architectural segregation should be. The words modules, delineate, clarity are present in the guide. We can rely on common practice and estimate that a module running in a micro-service will be better segregated than a library loaded by an executable.
Talking IEC 62304 langage: the MDSW manufacturer shall identify segregation necessary for risk control.

Usability on non-MDSW

This is a new recommendation. And this is consistent with the need of evidence of safety and effectiveness of MDSW and non-MDSW combination.
A result displayed by non-MDSW may be interpreted in a wrong manner by a user. This may be a hazardous situation leading to an unacceptable risk.

Accessory?

The guide is somewhat nice with health software editors. It doesn't re-qualify the non-MDSW displaying results as an accessory to the MDSW!

We can try to see why:
According to MDR definition of accessory: it specifically enable the medical device(s) to be used in accordance with its/their intended purpose(s). We can say that the non-MDSW, by displaying the MDSW result, enables the MDSW to be used in accordance with its intended purpose.

However, the word specifically is present twice in the definition of accessory.
It saves the health-software editors from seeing their existing non-MDSW re-qualified as accessory to the MDSW. An existing non-MDSW displaying electronic health records won't be qualified as accessory, if it displays health records containing the output of some MDSW.

However, a non-MDSW developed specifically to be used in combination with the MDSW will be qualified as accessory to the MDSW.

FDA multiple function device products

As usual, the FDA dealt with this problem long before the MDCG. The guidance on multiple function device products treats this case in a more thorough manner than the MDCG guide!
If you want to find how to document the safety and effectiveness of MDSW combined with non-MDSW, it's worth reading this FDA guidance! In other words, the content of your 510k can be reused in your CE tech file.

European Health Data Space (EHDS)

There is a long paragraph about EHDS in this MDCG guide. EHDS was published in March 2025. It's applicable to health software having electronic health records (EHR). Thus, applicable to the vast majority of health software, called EHR systems in this regulation. Editors will have to implement interoperability according to some common specifications. These specifications should be published by March 2027. The EHDS regulation will be fully applicable by March 2031 for EHR systems.

Fortunately, EHDS regulation requires "self-certification" only. No need to promise your Notified Body you will be compliant.
This paragraph is here to inform health software editors having EHR systems that this regulation will be applicable to them. Given the application dates, we have some time to implement it. However, it will collide with the dates of application of MDR, AI Act, and Cyber Resilience Act. By order of appearance on stage:

• AI Act: August 2027 for MDSW with high-risk AI system (the majority, in fact, per rule 11a),
• CR Act: December 2027 for the non-MDSW part of the health software,
• MDR: December 2028 or December 2027 (if AIMD or Class III implantable, that's very few MDSW) ,
• EHDS: March 2031 for MDSW with an EHR system,
• And the NIS2 directive? That's set by every national transposition.

Lucky you, health software editors with MD, AI systems and EHR systems. You will have the feeling to be transitioning to some EU regulation forever!

Conclusion

The MDCG 2019-11 rev1 doesn't change anything to the MDSW landscape. In lots of cases, sub-rule 11.a will trap you and your MDSW in the class IIa hell. It won't deliver you until you decommission it.