Research assistant Nicole Gebert contributed to this article.
Part 1 of this article discussed the background and purpose of the EU In Vitro Diagnostic Regulation (EU) 2017/746 (IVDR), the definition of in vitro diagnostic medical devices (IVDs), the risk-based classification system, conformity assessments, and the role of notified bodies. This was followed by part 2, where we discussed clinical evidence, post-market surveillance, and transition periods. We will now focus specifically on requirements for medical device software (MDSW) as an IVD (IVD-MDSW) and the delimitation between the application of the EU Medical Device Regulation (EU) 2017/745 (MDR) and application of the IVDR to a software device.
Qualification as IVD-MDSW
As already mentioned in part 1 of this article, the expanded IVDR definition of “in vitro diagnostic medical devices” in Article 2 (2) now explicitly includes software.
IVD-MDSW usually occurs in the following forms:
- Software itself as an IVD
- Software as an accessory for an IVD
- Software driving or influencing the use of an IVD
The first stage in determining whether the software is an IVD-MDSW subject to the IVDR is to confirm that the software is a medical device (MDSW).
- The Medical Device Coordination Group (MDCG) guideline MDCG 2019-11 clarifies that MDSW is software intended to be used alone, or in combination, for a purpose as specified in the definition of “medical device” in the MDR or IVDR (for more information on the intended purpose of MDSW under the MDR, see part 2 our MDR blog series). In general, software that processes, analyses, creates, or modifies medical information will qualify as MDSW if it is intended to have a medical purpose. Software for non-medical purposes, or for general purposes, even when used in a healthcare setting, or software intended for well-being purposes, is not covered by the MDR and IVDR. Software that merely used to store, archive, or performs simple searches on medical data does not qualify as MDSW.
Second, the software must meet the following criteria to qualify as IVD-MDSW:
- The MDSW provides information within the scope of the definition of IVDs;
- MDSW creates information based on data obtained by an IVD only; or
- The intended purpose of the MDSW is substantially driven by data sources coming from IVDs.
In accordance with the second step, an MDSW that analyses maternal parameters such as age, concentration of serum markers, and information obtained through various IVD assays, as well as fetal ultrasound examination to evaluate the risk of trisomy 21, may be considered an IVD-MDSW as the intended purpose is substantially driven by IVD data.
MDSW that does not fulfill this second step is covered exclusively by the MDR. This includes, for example, MDSW that assesses the level of risk to initiate care processes that help reduce intensive care unit (ICU) transfers, readmissions, adverse events, and the duration of stay, by considering risk assessment parameters like respiratory rate, heart rate, blood pressure, and SpO2, by default, and can be configured by the user to include other parameters as well, including results from in vitro medical diagnostic devices. This MDSW would fall under the MDR as (i) the data is obtained from both IVDs and medical devices, and (ii) the data obtained from the IVD is not critical to the output, so the information derived from the medical device is more relevant to the intended purpose.
Risk Classification of IVD-MDSW According to the IVDR
In part 1 of this article, we discussed the adoption of a new classification system. We also pointed out that the IVDR does not contain software-specific classification rules, like Rule 11 of Annex VIII to the MDR. Therefore, the classification of MDSW under the IVDR requires consideration of all classification and implementation rules of Annex VIII to the IVDR.
The classification system of the IVDR considers the intended purpose of the device and the inherent risks, and groups devices into four different risk classes (classes A to D) in ascending order of their risk intensity. For example, software for the interpretation of automated readings of line immunoassay for the confirmation and determination of antibodies to HIV-1, HIV-1 group O, and HIV-2 in human serum and plasma, may be a device intended to be used for determining the infectious load of a life-threatening disease where monitoring is critical in the process of patient management under rule 1 of Annex VIII to the IVDR and would thus be classified in class D. At the same time, the IVD-MDSW referred to above, which uses maternal parameters and information obtained through fetal ultrasound examination to evaluate the risk of trisomy 21, may be considered a device that is intended for screening for congenital disorders in the embryo or fetus under Rule 3 (l) of Annex VIII to the IVDR and should thus be in class C.
However, given the close nature of the MDR and the IVDR, there are of course similarities in the regulation of MDSW. Very similar to the risk assessment under the software-specific rule 11 of Annex VIII to the MDR (i.e., which effectively provides for class IIa ranking as a default result and therefore requires notified body review of most MDSW), the risk assessment of MDSW under the IVDR will in most cases result in a class B ranking (or higher) and therefore also require the IVD-MDSW to undergo an conformity assessment by a notified body. This is because IVDs, including IVD-MDSW, which are not covered by any specific classification rule, fall under class B by default (Rule 6 of Annex VIII of the IVDR).
Technical Documentation for IVD-MDSW
Before placing IVDs on the market, most manufacturers will need to get their technical documentation assessed by a notified body (see part 1 of this article for IVDR conformity assessment routes). The IVDR stipulates several software-specific requirements for the technical documentation in Annex II:
- The device description and specification should include a description of any software that drives the device or influences use of the device (Annex II 1.1.k).
- For IVDs that incorporate software, the design information should include a description of any software to be used with the device, as well as an overview of the entire system. If the IVD uses software for objective data interpretation, or if the software is independent of any other device, a description of the data interpretation methodology, namely the algorithm, should be included (Annex II 3.1).
- The documentation should further contain evidence of software validation as used in the finished device, as well as address all hardware configurations and, where applicable, operating systems identified in the labeling (Annex II 6.4, EN ISO/IEC 62304 is considered the state of the art approach).
Several guidelines for IVDR technical documentation submissions have been issued by notified bodies and should be taken into consideration when dealing with the respective notified body (e.g., TÜV Rheinland, BSI).
Introduction of a Unique Device Identification Requirement for IVD-MDSW
The IVDR, like the MDR, introduces the Unique Device Identification (UDI) system. Annex VI Part C 6.2 of the IVDR addresses the UDI assignment for software specifically. In accordance with the IVDR, software that is commercially available on its own (i.e., standalone IVD-MDSW), as well as software that constitutes an IVD device, shall be subject to UDI requirements. These requirements are identical for MDSW under the MDR and for IVD-MDSW under the IVDR. More details on how to identify software devices can be found in part 5 of our blog series on the MDR.
IT Security
Among the many novelties introduced, the IVDR and the MDR aim to ensure that devices placed on the EU market are suitable for the new technological challenges associated with cybersecurity risks.
IVDs must thus be designed and manufactured in a way that removes or reduces risks associated with the possible negative interaction between software and the IT environment in which it operates and interacts (Annex I Chapter II 13.2.d). Manufacturers must establish, implement, document, and maintain a risk management system. Particularly with the complexity of software development, software configuration, and interdependencies between software components, IVD-MDSW is afflicted with security vulnerabilities. It is therefore considered more reasonable that software as such is subject to foreseeable misuse. Manufacturers should foresee or evaluate the potential exploitation of those vulnerabilities.
Manufacturers must also develop and manufacture IVD-MDSW in accordance with the state of the art, while taking into account the principles of development lifecycle and risk management, including information security, verification, and validation. Manufacturers also need to set out minimum requirements concerning IT network characteristics and IT security measures, including protection against unauthorized access (Annex I Chapter II (16) IVDR).
Further information can be found in the MDCG Guidance on Cybersecurity for medical devices (MDCG 2019-16).
Performance Evaluation of IVD-MDSW
Although the IVDD already required a performance assessment, it was only implied, not explicitly stated, and primarily concerned with the analytical performance of the device. Under the IVDR, any software that qualifies as an IVD must meet all clinical evidence and performance evaluation principles explicitly outlined in Article 56 (1) and Annex XIII of the IVDR. The MDCGs Guidance on Clinical Evaluation (MDR) / Performance Evaluation (IVDR) of Medical Device Software (MDCG 2020-1) aims to provide the framework for the determination of the appropriate level of clinical evidence required for MDSW to fulfill the requirements set out in the IVDR (and MDR).
Although the definition of clinical evaluation in the MDR and performance evaluation in the IVDR are not identical, sufficient clinical evidence is expected in both cases to demonstrate compliance with the relevant general safety and performance requirements.
When collecting clinical evidence for IVD-MDSW, three key elements should be taken into account:
- Scientific validity;
- Analytical performance; and
- Clinical performance.
Part A of Annex XIII applies primarily to the pre-market phase and defines performance evaluation as a three-step process: (i) drafting a performance evaluation plan, (ii) collecting data to demonstrate scientific validity and analytical and clinical performance, and (iii) evaluating and documenting the data in a performance evaluation report.
Part B of Annex XIII concerns the post-market phase and outlines the requirements for post-market performance follow-up. This concept was not included in the IVDD, but is in line with the practice of many manufacturers to conduct a periodic “state of the art” review.
Concluding Remarks
Under the IVDR, IVD-MDSW is subject to several software specific requirements. As most IVD-MDSW will likely end up in class B or higher, manufacturers will also need to undergo notified body review in order to be able to place IVD-MDSW on the market. Therefore, it can be expected that a number of manufacturers will make use of the transition periods discussed in part 2 of this blog series. However, as discussed in more detail in part 4 of our blog series on MDSW under the MDR, in particular MDSW manufacturers should be aware of the implications that come along with the use of transition periods as the IVD-MDSW may not undergo any significant changes to its design or intended purpose in order to benefit from such transition periods.