Correctly classifying IVD software

The term IVD software has not been clearly defined, even though software is being used as in vitro diagnostic medical device (IVD medical device) or as an accessory for IVD medical devices more and more frequently.

This article describes when software should be classified as an IVD medical device, the list or class the software should be included in, and what you should take into account for the safety classification according to IEC 62304.

0. Classification of IVD software

We have to differentiate between three IVD software classifications:

  1. Classification of software as IVD medical device, as a medical device or as an accessory
  2. Risk classification according to IVD Directive or the IVDR
  3. Software safety classification according to IEC 62304

1. Classification of software as an IVD medical device

a) Possible cases

We have to differentiate between several types of “IVD software”:

  1. An in vitro diagnostic medical devices, i.e. the software itself is an IVD according to IVDD or IVDR
  2. Software as an accessory for an IVD
  3. Software that is used in an IVD context but which falls within the scope of the MDD/MDR
  4. Embedded software, i.e. software that is part of an IVD
  5. And lastly, software that is not a medical device

b) MEDDEV 2.1/6 rules on IVD software

The EU's MEDDEV 2.1/6 guideline regulates how IVD software has to be classified based on the characteristics described above. However, this guideline applies to the IVD Directive (IVDD). This article will look at the extent to which the guideline can also be applied for the IVD Regulation (IVDR).

Fig .1: Flowchart for EU guideline MEDDEV 2.1/6 on IVD software (click to enlarge)

Decision step 1: Does the IVD software fall within the scope of an EU directive?

This decision step should stay the same once the IVDR enters into force. Here, we differentiate between software that falls within the scope of a directive (future EU regulation) and software that does not. MEDDEV refers to another diagram for this step.

Decision step 2: Expert fuction?

The second step concerns whether

  1. there is an expert function involved that provides information that
  2. falls within the scope of the term in vitro diagnostic medical device.

The planned guidance document from the MDGC no longer defines the term “expert fuction”, which is why we are considering taking only the second part into account in this decision step. This would lead to us retreating back to the definition of the term in vitro diagnostic medical device.

In other words, the question in this 2nd step of whether the software falls within the scope of the IVDR would be answered in the affirmative in the following cases:

The software is intended, alone or in combination, to be used for/in in vitro tests to examine body fluids or tissues outside the body and to provide information:

  1. Concerning a physiological or pathological process or state
  2. Concerning congenital physical or mental impairments
  3. Concerning the predisposition to a medical condition or a disease
  4. To determine the safety and compatibility with potential recipients
  5. To predict treatment response or reactions
  6. To define or monitoring therapeutic measures.

Obviously, software never actually directly analyses body fluids or tissue samples, it analyses data. When making a decision here, what matters is the objective of this analysis.

This software can be divided into two types:

  1. Software that interacts with the samples via the hardware for the purpose of analysis, as would be the case for, for example, drivers or for raw data acquisition.
  2. Software that processes and analyzes raw data or other data with one of the objectives described above.

Decision steps 3 and 4: Where did the data come from?

For steps three and four, MEDDEV differentiates between data sources:

Data source

Relevant directive / regulation

Exclusively IVD(s) - according to IVDD / IVDR


Exclusively MD(s) - according to MDD / MDR


From IVDs and from MD(s)


Classifying the software according to MEDDEV using data sources may, in fact, be easier. However, it is not always selective and so not always helpful. Why should devices used for exactly the same diagnosis be treated differently depending on the source of the data? Why does the law require a clinical evaluation in one case and a performance evaluation in the other?

While in vitro diagnostic medical devices, as the name implies, are used for diagnosis, for therapeutic objectives the MDR should apply irrespective of the source of the data. The differentiation according to the data source appears to be more sensible for diagnostic objectives.

Decision steps 5 and 6: Accessories?

Unfortunately, MEDDEV does not provide any guidance for decision steps 5 and 6.

Standalone software can also be an accessory for IVD medical device. The IVDR regulation defines the term accessory as follows:

Definition: In vitro diagnostic accessory

“An article which, whilst not being itself an in vitro diagnostic medical device, is intended by its manufacturer to be used together with one or several particular in vitro diagnostic medical device(s) to specifically enable the in vitro diagnostic medical device(s) to be used in accordance with its/their intended purpose(s) or to specifically and directly assist the medical functionality of the in vitro diagnostic medical device(s) in terms of its/their intended purpose(s)”

Source: IVDR

Wish list

A future guideline should also include examples to answer questions such as:

  • How should out-of-range value warnings be evaluated? Does this assessment change if complex interdependencies between values are taken into account?
  • Which calculations and conversions of and between values are still not critical?
  • How many degrees of freedom are there in the representation of, e.g., trend lines and correlations?
  • What do manufacturers have to pay attention to if they allow users to parameterize and even, if necessary, to script? 


There is additional information in the EU's Borderline Manual.

An expert who does not want to be named was involved in the creation of this section. Thanks to him nonetheless.

2. Risk classification of IVD software according to the IVDR and IVDD

a) Risk classification according to the IVDD

The IVD Directive (IVDD) defines several classes of in vitro diagnostic:

  • List A includes the devices with the highest risk, such as blood group tests
  • List B includes high-risk devices, such as devices for determining tumor markers
  • There are also devices for self-testing and
  • other IVDs

b) Risk classification according to the IVDR

The IVDR differentiates between classes A to D, where class A includes the non-critical devices and class D the most critical devices.

In the same way as the IVDD, the IVDR has the following classification rules:

Classification Rules:

1.1. Application of the classification rules shall be governed by the intended purpose of the devices.

1.2. If the device in question is intended to be used in combination with another device, the classification rules shall apply separately to each of the devices.

1.3. Accessories for an in vitro diagnostic medical device shall be classified in their own right separately from the device with which they are used.

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.8. Where a manufacturer states multiple intended purposes for a device, and as a result the device falls into more than one class, it shall be classified in the higher class.

1.9. If several classification rules apply to the same device, the rule resulting in the higher classification shall apply.

Source: IVDR, Annex VIII

c) The importance of the risk classification

The classification does not affect the safety and performance requirements that IVD medical devices must meet. Even class A software (not to be confused with safety class A according to IEC 62304) must meet all requirements such as:

However, the classification determines the possible conformity assessment procedures. For class A IVD medical devices, manufacturers do not need to involve a notified body. In other words, a review of the documentation by a notified body is not required. The manufacturers do not need a certified QM system either.

d) Types of IVD software

With regard to IVD software we have already distinguished between the following forms of standalone software:

  1. Independent in vitro diagnostic medical device, i.e. itself an IVD medical device according to IVDD and IVDR
  2. Accessories for an IVD medical device
  3. Software that is used in an IVD context but which falls under the scope of the MDD/MDR
  4. Software that is not a medical device

There is also embedded software, i.e. software that is part of an in-vitro diagnostic medical device. However, this software is not classified independently, so the following sections are able focus on the classification of standalone software. They are also limited to the case that the software falls within the scope of the IVD/IVDR.

e) Application of the classification rules

The IVDR looks at software in more detail (compared to the IVD Directive 98/79/EC). It emphasizes that the intended purpose is decisive for the classification and thus the question of whether it is the software that enables the clinical information to be provided. In other words, the decisive factor is whether the specificity and, if applicable, the sensitivity of the analyte is first generated by the software.

An example of such software would be bioinformatic software that compares general genetic data from a patient sample from a high-throughput sequencing of DNA samples with reference data, with the objective of determining, for example, whether

  • the patient has a disease or
  • of diagnosing or analyzing a physiological condition or
  • classifying stages of a cancer.

In other words, such software devices fall into class B, C or D depending on the classification rule.

IVD software in risk class A?

The claim from some auditors that IVD software always falls into class A because software can never harm patients directly or because the software itself cannot do anything has to be challenged.

If the standalone software evaluates data from a specific instrument and does not do anything analyte-specific, i.e. analyzes completely independently of the IVD assay data (e.g. with no assay-specific set limit or quality values), it can be assigned to the same class as the instrument (according to implementing rule 1.4). This would one of the few cases in which IVD software could be put into class A.

Risk classes B, C and D

However, if the IVD software performs assay-specific analyses, it must be assigned to the same class as the assay. After all, it influences the result and thus the application.

If several assays can be analyzed with the software, implementing rules 1.8 and 1.9 in particular must be followed (classification into the highest class for the assays involved!)

Therefore, it is a strategic decision whether you separate software into controlling elements and analyzing elements in order to be able to classify them differently.

Dr. Sebastian Grömminger, IVD expert at the Johner Institute helped with the drafting of this section.

3. IVD: Software safety classification according to IEC 62304

a) Question: A, B or C?

A point-of-care device measures “standard” parameters, such as pH, pCO2, glucose, potassium, etc. There are now arguments about how to classify the software. A, B or C?

One team argues for safety class B, because no serious injury is possible. After all, the IVD equipment's measurement result is only one of many parameters for a therapy - whether it is the right one or the wrong one or the right one but delayed. In addition, calibration and control cycles are carried out regularly with the laboratory device.

Another team argues for safety class C because it could actually lead to a patient injury, even if such a case is unlikely. Doctors are not considered a “risk-minimizing action” here.

How should this IVD software be classified according to IEC 62304?

b) Preliminary considerations: Special features of IVD medical devices

As with all IVD devices, or more precisely measured values, and in contrast to other devices, there is no direct possibility of harm. No pinching, no radiation, not electric shocks, etc. Measured values can “only” lead to patients being treated incorrectly or late, or even not being treated at all - which can be fatal in certain circumstances.

This “external cause chain”, i.e. the chain of events triggered by an incorrect or missing measured value, is very difficult to estimate. The probabilities are particularly difficult to estimate. For example, the probability that a doctor will actually treat a patient incorrectly due to an incorrect or missing measured value.

Unfortunately, IEC 62304:2006 does not consider these probabilities at all. In the most unlikely case, something bad can happen to “sufficiently critical” patients. And this means safety class C. IEC 62366:2006 + A1:2015 offers more options here.


Further information

Read more on safety classes here.

The calibration and control cycles probably do not change this, they only reduce the probability that a measured value is not displayed incorrectly or is not displayed at all. Probabilities, however, are irrelevant for the safety classification - at least with the “old" IEC 62304.

d) Answer: The intended purpose is decisive

The safety class of an IVD medical device depends above all on the intended purpose, which itself determines the patients, their state of health and the illness the medical device is used for. This determines the maximum severity of the damage that can be caused by a software error - largely independently of the probability - and thus the safety class of the software according to IEC 62304.

Further information

Read more on software as medical device (SaMD) here.


Dr. Tina Priewasser

Find out what Johner Institute can do for you

A quick overview: Our


Learn More Pfeil_weiß

Always up to date: Our


Learn More Pfeil_grau

Privacy settings

We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.