Software in Medical Devices, by MD101 Consulting

What is its regulatory class?

Thanks to the rogue, the villainous rule 11 of the 2017/745/EU MDR, we know that our software is in class IIa. At least.
Such software is used to detect contraindications, drug interactions and excessive doses (see the last paragraph at the bottom of the page through the link to the European Court of Justice above). Contraindications, drug interactions and excessive doses are hazardous situations for the patient. What if we have a software failure leading to a false negative on one of these hazardous situations?
The bets are opened:

1. In some cases, death of the patient, for instance if the medical personnel using the software doesn't detect the problem on a critical interaction, or
2. More potentially, severe consequences to the patient leading to additional medical intervention, or
3. If we are lucky, non-severe consequences to the patient.

Thus, thanks to the rogue, the villainous rule 11, our software is, depending on the context:

1. In class III, or
2. In class IIb, or
3. In class IIa.

So, if we don't restrict by the intended use the type of drugs managed by our software, or the personnel using it, our software is potentially in Class III. I repeat C.L.A.S.S. T.H.R.E.E.

Lucky us, class I 93/42/CE MDD -> class III 2017/745/EU MDR.

What is its IEC 62304 safety class?

Same player shoot again.
Our software can lead to, depending on the context:

1. Death or permanent injury, or injury requiring medical intervention: In class C, or
2. Non-serious injury: In class B,
3. Forget class A, unless you're able to demonstrate that you have a mitigation action outside software (e.g. a mandatory clinical protocol) leading to an acceptable risk of false negative.

Conclusion on classification

Once again, if we don't restrict the intended use, in other words, if we allow any kind of drug prescription in our software, we have the perfect combo:
2017/745/EU Class III and IEC 62304:2006+Amd1:2015 Class C.

CE marking

Preclinical data

Here, the path is well known, we have to apply the standards for software: IEC 82304-1, ISO 14971, IEC 62304 and IEC 62366-1. Plus standards on IFU, the future ISO 20417, and labelling ISO 15223-1.
No need to say that we have to polish our design control process, and the associated documents. No need to say that it will cost an arm and a leg.

Clinical data

Ah ah, article 61 of the MDR, here we are!
What does it say for Class III devices? Article 61.4, a clinical investigation is mandatory.
I'm absolutely not a specialist of clinical investigations, but I'm sure we have a little problem. If my software isn't restricted by its intended use, my software addresses any patient with any pathology. Defining the cohort of patients in the clinical investigation protocol is going to be tricky!

But, thinking out loud, my software doesn't have a clinical performance. It only displays information on drugs. It's the drugs, which support the clinical performance.

Non-clinical validation?

My software doesn't have any clinical performance, but only a technical performance:

• Displaying data coming from a thesaurus on drugs, and/or
• Computing drug doses from weight or body mass index, namely a rule of three, and/or
• Displaying some alerts based on thresholds found in the same thesaurus.

So I don't need a clinical investigation. Performance bench testing should be enough, that's what allows the article 61.10. But this article 61.10 begins with the legal jargon: without prejudice to 61.4.

Clinical investigation or not clinical investigation, that is the question.
Pliz, European Commission, we need a guidance, a common specification, whatever.

Conclusion

If you have a Drug Prescription Assistance Software to CE mark, craft very carefully the intended use. Or the probability of regulatory failure will be set to 1.

Edit 2019/10/21 after the publication of MDCG 2019-11

From what we have in the new MDCG 2019-11 guidance on qualification and classification of software, we should be able to release the lash on Drug Prescription Assistance Software. The guidance makes use of the IMDRF SaMD possible risk categorization guidance, especially the table in section 7.2. This table is copied and interpreted in table 1 of the MDCG guidance.
Using this table 1 in the MDCG guidance we should be able to assert that we are in a case where our software:

• Drives clinical management, and not the highest level treat or diagnose (the drug treats the patient),
• May be used in Critical situation or condition, here we take the highest level since we don't know.

In this case, we fall in the cell III.i, which places our software in class IIb.
This is a better situation than class III. But it doesn't wipe out the issue on letting a notified body swallow the article 61.10 for a class IIb device. Bon appétit Notified Body.