Tackling Medical Device Software Under the New IVDR Requirements (Part 1)
The definition of an IVD in Article 2 of the IVDR 2017/746 states:
‘in vitro diagnostic medical device’ means any medical device which is a reagent, reagent product, calibrator, control material, kit, instrument, apparatus, piece of equipment, software or system, whether used alone or in combination, intended by the manufacturer to be used in vitro for the examination of specimens….
The text underlined, is an example of what differentiates from the IVD Directive 98/79/EC.
Revision to The Medical Device Regulatory Framework in the EU
One of the reasons for the revision to the EU framework is because of technological changes since the 1990s. This has resulted in many software packages and systems going under the radar.
The EU wasn’t alone in being behind in this area. This was a global issue and one the International Medical Device Regulators Forum (IMDRF) got to grips with in 2013. They formed the Software as a Medical Device Working Group (WG) to develop guidance supporting innovation and timely access to safe and effective Software as a Medical Device (SaMD) globally. The FDA published a set of definitions during 2013 to include in the scope of IVD devices.
Winding the clock forward to the present day, SaMD now appears as MDSW in the EU texts.
There should be no complaints about this inclusion into IVDR 2017/746 as it is long overdue. Within the last twelve months, the Medical Device Coordination Group (MDCG) have issued guidance documents. I will summarise some key points from this that are extremely helpful.
Qualification & Classification of Software
MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR was published in October 2019. The purpose of this document was primarily supporting manufacturers of MDSW. Defining the criteria for qualification of software, is discussed classification rules, as set out in Annex VIII of both regulations.
The guidance provided is really useful. There are decision step diagrams which walk you through the software qualification process:
- Decision Step 1: Does the Medical Device Software (MDSW) provide information within the scope of the in vitro diagnostic medical device definition?
- Does the MDSW create information based on data obtained by in vitro diagnostic
medical devices only?
- Decision Step 3: Is the intended purpose substantially driven by data sources coming from in vitro diagnostic medical devices? If yes, then the applicable legislation is Regulation (EU) 2017/746. If the intended purpose is substantially driven by data sources coming from medical devices, then the applicable legislation is Regulation (EU) 2017/745.
This latter step is only applicable if data analysed is a combination of in vitro diagnostic medical devices and medical devices.
Section 5 of the guidance document is concerning the implementing & classification rules of Annex VIII. Providing examples for:
Application of implementing rule 1.4 – First sentence (Software, which drives a device or influences the use of a device, shall fall within the same class as the device).
- Software that is intended to operate (driving) a C-reactive protein (CRP) measuring analyser from a remote location is classified in the same class as the analyser. i.e. if the analyser is a classified as class A then the software operating the analyser falls into Class A.
Second sentence (if the software is independent of any other device, it shall be classified in its own right):
- MDSW that integrates genotype of multiple genes to predict risk a disease or medical condition developing or recurring. This is an independent IVD MDSW and is classified on its own.
We await more guidance from the MDCG on implementing rule 1.9. However, in general (if several classification rules apply to the same device based on the intended purpose, the rule resulting in higher classification will apply).
By Implementing Rule 1.1 of Annex VIII of Regulation (EU) 2017/746, the application of the classification rules shall be governed by the intended purpose of the MDSW.
Examples for the classification of MDSW under the IVDR:
- Software intended to be installed on a fully automated enzyme-linked immunosorbent assay (ELISA) analyser, and intended to determine the Human HbA1c concentration in serum from the results obtained with a Human HbA1c ELISA, intended to screen for and diagnose diabetes and monitor diabetic patients, should be in class C per Rule 3(k).
- The software within a PAP stain automated cervical cytology screening system, intended to classify the PAP cervical smear as either normal or suspicious, should be in class C per Rule 3(h).
- 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, should be in class D per Rule 1.
- The software that uses maternal parameters such as age, concentration of serum markers and information obtained through foetal ultrasound examination for evaluating the risk of trisomy 21, should be in class C per Rule 3(l).
Section 10 (Annex II) of the guidance document presents some useful examples of how to use the decision steps (described above) for the qualification of MDSW:
- MDSW intended to generate a risk score in order to trigger care processes, reduce ICU transfers, readmissions, adverse events and length of stay. The risk score by default includes respiratory rate, heart rate, blood pressure and SpO2. However, a user can configure it to include other parameters, including in vitro diagnostic medical device results.
In decision Step 1, the MDSW can be understood to meet criteria (a), (f) and (h). It is therefore answered “yes”. Step 2 is answered with a “no”. The in vitro diagnostic medical device result may be included in the calculation. Step 3 directs the significance of the medical device derived information as driving the intended purpose. This results in the qualification of the software as an MD MDSW (as the data received from the in vitro diagnostic medical device is not deemed decisive for the overall calculation result (output) achieved by the MDSW)
- A bioinformatics MDSW intended to analyse digital Next Generation Sequencing (NGS) raw data coming from sequenced patient’s cancer genomes. It allows the detection and visualisation of somatic genome alterations (such as substitutions, small insertions and deletions (indels), copy number alterations, and genomic rearrangements) across a selected number of genes. Additionally, it is also capable of determining genomic signatures* (such as microsatellite instability [MSI] and/or tumour mutational burden [TMB]). The types of somatic genome alterations and genomic signatures detected depend on the test chosen. The MDSW assists the user in identifying and visualising genomic alterations and is intended to identify somatic genome alterations to support diagnosis and treatment decisions.
Decision step 1 is concluded with a “yes”. The MDSW is intended for analysing congenital data to provide information on the predisposition to a medical condition or disease. Thus meeting criteria (b) and (c) laid out in the decision step. As the MDSW processes data coming only from in vitro diagnostic medical devices into the calculation, then the software is qualified as an IVD MDSW according to Step 2.
Classification of your MDSW is just one part of many required to achieve conformity to the new regulation. It’s an important step and shouldn’t be underestimated, as it sets out the regulatory pathway of your device. The relationship between the software and other devices can often be confusing. But with guidance documents, referenced in this blog, it should be easier considering MDSW classification in-line with the intended purpose.
Beyond this step, there are other aspects of the IVDR which concern MDSW. These include meeting the requirements of Annex I (GSPR) and device Performance Evaluation. Please keep in touch with this series of blogs for further discussion on MDSW and the IVDR. You may also be interested in other IVDR blogs such as How Should We Classify Our IVD Device under IVDR?
For any questions on this blog topic or for any other IVD related queries, please get in touch. Call us now on 01295 724286 or email us at firstname.lastname@example.org.
IMed QA & IVDR Consultant