In this article, we’ll walk you through the basic IVDR classification concepts for software as an IVD and look at some examples. The Regulation (EU) 2017/746 on in-vitro diagnostic medical devices (IVDR), describes the certification process and obligations of IVD manufacturers. By the way, this is separate from medical devices under the MDR – we have a separate article for medical device classification examples under the MDR instead.
The IVDR begins with some basic definitions of what an IVD is and what devices may classify as an IVD. Read Article 2 of the IVDR to verify if your software falls into the definition of an in-vitro diagnostic medical device, and continue with Annex VIII, Classification Rules. There are 10 Implementing Rules, but only 7 classification rules. Additionally, take a look into the MDCG 2019-11, Guidance on Qualification and Classification of SW in the IVDR. It provides a valuable decision tree. MDCG 2020-16 provides guidance on the classification rules for IVDs and it includes a couple of great examples.
The concept is simple: the more dangerous the disease or condition to be diagnosed is for the patient, the higher the risk class of the IVD. Each device falls into one of four risk classes: A, B, C, & D, with Class D being associated with the highest risk class. Let’s walk through the jungle and look at some IVDR classification examples…
Step 1 – Is your software an in-vitro diagnostic?
Take your intended use statement and read Article 2 of the IVDR. If it is a match, congratulations, continue the IVDR classification with step 2. If not, try the MDR.
Step 2 – Where is the input data coming from?
Does your software create output information based on data obtained by another IVD? Yes? Congratulations, the software is an IVD according to the IVDR. No? If the data analysed is obtained from a combination of both in vitro diagnostic medical devices and medical devices, proceed to step 3.
Step 3 – What was your intended purpose again?
The third step of the IVDR classification examines whether the software utilises data from “IVD sources” as well as from other sources (e.g., medical devices). The aim is to determine if the intended purpose of the software is substantially achieved through IVD data sources. Yes? The software falls under the IVDR. No? The software falls under the MDR (and we are done here).
Is your software used alone or in combination?
There are only two of the implementing rules important for software: 1.4. Software, which drives a device or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right. 1.9. If several classification rules apply to the same device, the rule resulting in the higher classification shall apply.
That means that the IVDR classification distinguishes between stand-alone software and embedded software. Let’s look at some examples:
- A software that is intended to operate (driving) a C-reactive protein (CRP) measuring analyzer from a remote location is classified in the same class as the analyzer, i.e., if the analyzer is classified as Class A then the software operating the analyzer falls into the same risk class. Also known as embedded software.
- MDSW that integrates the genotype of multiple genes to predict the risk of a disease or medical condition developing or recurring; this is an independent IVD MDSW and is classified on its own (probably Class C, see Rule 3 (i)). Also known as stand-alone software.
Side note: A stand-alone software will undergo the appropriate conformity assessment. It will have its documentation. An embedded software, that is part of a hardware device will undergo the conformity assessment applicable to the whole device. This is interesting and we will walk through it in a final example by the end of the article.
Classification – A waterfall approach
In the next step, you basically walk through Annex VIII from top to bottom and stop at the point where the description matches your intended purpose best.
Determination of the infectious load of e.g., HIV or Hepatitis – Class D.
Genetic testing or cancer diagnosis – Class C.
Class C Fertility and pregnancy tests – Class B.
General laboratory equipment (buffer, pipette) – Class A.
What does the IVDR classification mean for me as a manufacturer?
After classifying the IVD software, you will need to draw up a quality management system (QMS) according to the ISO 13485 and create the technical documentation (TD) based on the IVDR, Annex I, and Annex III. Manufacturers of Class B and higher need to involve a Notified Body into the certification process that will assess your QMS, the TD, and your software. Class A manufacturers are exempt from the NB involvement.
Let’s summarize with one final example!
Imagine a company manufacturing laboratory equipment: plastic stuff, electric devices, reagents, analysis software, the complete workflow. All devices are intended to be IVDs, are intended to be used together, and some specific reagents are intended to diagnose infectious diseases (e.g., HIV, Hepatitis C Virus). Let’s take a look into the individual steps of a PCR test, from patient to diagnosis, and classify the individual products.
Specimen receptacles.
You somehow need to ensure the safe transport of body fluids or samples of the patient to the laboratory. These plastic tubes and containers are called specimen receptacles. Following Annex VIII, Rule 5 c, specimen receptacles are classified as class A.
Reagents used for the PCR.
This product consists of reagents to prepare the PCR mix or to isolate the DNA that are used in combination with the sample are classified as Class A (see Rule 5 a). Reagents for a specific infectious agent (HI Virus or E.Coli) are classified separately. Here probably Class C or Class B.
The PCR thermocycler.
This son of a gun can do two marvelous things. Heat up samples and cool them down again. Following Annex VIII, Rule 5 a, products for general laboratory use are classified as class A. Wait, the PCR thermocycler includes software! No problem, claim that the SW runs the hardware device and has no diagnostic purpose on its own. Both the SW & HW can be considered to be one device. Still Class A. Phew.
Software used to analyze results.
Finally, there is software analyzing the raw data. And now it gets tricky. The risk class depends on the initial infectious agent to be diagnosed in your sample. You determine the infectious load of B. anthracis? Probably Class D under the IVDR classification. You determine the infectious load of E. coli? Probably Class B.
Remembering implementing rule 1.9? If several classification rules apply to the same device, the rule resulting in the higher classification shall apply. Therefore, the analysis software is based on the biological beast you want to find in the sample. In this example, Class D.
To summarise, the diagnostic workflow typically entails sample collection, processing, and analysis using an in vitro diagnostic (IVD) device. The primary purpose of the IVD is to accurately detect and identify specific conditions or pathogens present in the sample, providing crucial information for clinical decision-making.
The final diagnostic statement consolidates the results of the IVD analysis, offering a clear indication of the presence or absence of the targeted condition or pathogen in the sample. For instance, the statement might confirm the presence of a particular virus or bacteria in a patient’s blood sample.
Subsequently, by navigating through Annex VIII, we determine the risk classification of the IVD. This IVDR classification takes into account the specific use context of the IVD and the characteristics of the conditions or pathogens being diagnosed. Factors such as the severity of the condition, the intended use environment, and the potential consequences of false results all contribute to determining the appropriate risk classification for the IVD.
