Is my software in IVDR class A, B, C, or D: A new hope
After the MDCG guide 2019-11 for the MDR, the MDCG 2020-16 gives the regulatory oversight on In-Vitro Diagnostic medical devices (IVD MD) classification; including software qualified as IVD MD. Let's see the consequences for software.
Drives or influences
The MDCG 2020-16 guide focuses deservedly on reagents, and other non-active IVD devices, which are the core of the IVD technology. For software, the keyword is "drives or influences". If a software drives or influences one of these IVD non-active devices, as well as instruments, then it takes the class of the main device.
E.g.: if a software drives or influences the use of a reagent, then it takes the class of the reagent, according to the intended purpose of this reagent.
We find a similar example in annex 2 of the guide: A software driving or influencing an instrument (a blood gaz analyser), takes the class of this device.
Nothing new compared to the MDCG 2019-11, after all.
Annex 1 - ELISA test
The truly interesting part of this guide is the annex 1, at the end of the document.
There, we have the ELISA analyser (the instrument), and its software: either internal firmware or installed on a PC connected to the instrument. The MDCG 2020-11 tells us that the ELISA instrument and its software are in class A.
Hurray! We have very common device and software in the lowest class under the IVDR regime! In self-certification!
ELISA software intended purpose
Just to remind you what this kind of software does:
- It pilots the instrument: moving plates, filling wells, rincing, in brief, automating the IVD test,
- It takes the Optical Density (OD) measurement from the optical photometer,
- It converts the OD to an IVD result, like a quantitative value (concentration of substance to be detected), or a qualitative value (Positive / Negative).
This result is obtained by the use of a fitting curve (linear, quadratic, log...) between the OD and the result. This fitting curve is determined during IVD reagent design and development.
Thus, the ELISA software contributes without doubt in a major way to giving the result according to the intended purpose of the reagent. Wrong fitting curve algorithm, wrong result, wrong or delayed diagnosis.
Note: by "wrong fitting curve", I don't think about the fitting curve itself, but the translation of the fitting curve into software code with some unknown bugs remaining after design transfer.
Does ELISA software drive or influence the use of the reagent?
Given the position in class A of ELISA instruments, we can conclude that, despite its major contribution to the final result according to the intended purpose of the reagent, the MDCG IVD working group considers that it doesn't drive or influence the use of the reagent.
Remark: a fitting curve is a math function, which can be complex. thus, we can't invoke the "simple search" argument to place the software in the lowest regulatory class.
Class A? So much the better!
The manufacturers can say "Thanks" to the MDCG IVD WG. The Notified Bodies can also say "Thanks" to the MDCG IVD WG, they reduced a bit the uncontrollable bottleneck with this decision on ELISA instruments.
Comparison with MDR rule 11
So, we have an ELISA instrument with its software, which contributes in a major way to the final result, with some algorithm using a pre-defined fitting curve. This software has the color and smell of aid to diagnosis. We can even say that the software drives clinical management.
This IVDR class A self-certified ELISA software would definitely be in the scope of the MDR ill-formed rule 11, thus in class IIa under the MDR regime, with certification by a Notified Body and the whole regulatory shebang #!.
Class A under the IVDR regime,
Class IIa or above under the MDR regime, if we had to classify this software with the MDR rules.
I let you chew and swallow this cookie with real discrepancy chunks.
PS: MDCG or CAMD members, if by any chance you read this and know I'm wrong, please contact me. I'm sure I wouldn't be the only one interested by your answer.