Software is now considered a medical device if that is its intended purpose according to the European Union’s definition of in vitro diagnostic (IVD) devices in the new In Vitro Diagnostic Regulation (IVDR) 2017/746.
Here we look at the scope of how this change in definition impacts software developers within the IVD space, and we use this as an example of the magnitude of the new IVDR regulation for all IVDs.
Software is a medical device according to the definition of IVD if that is its intended purpose; thus, software as part of an instrument, software as a medical device, and apps are included in the definition of IVDs and fall under IVDR regulation. This included genetic testing, companion diagnostics, as well as stand-alone software.
At the Top of IVDR 2017/746, number 17 introduces software that falls under this regulation:
(17) It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of an in vitro diagnostic medical device, qualifies as an in vitro diagnostic medical device, while software for general purposes, even when used in a healthcare setting, or software intended for well-being purposes is not an in vitro diagnostic medical device. The qualification of software, either as a device or an accessory, is independent of the software’s location or the type of interconnection between the software and a device.
To help medical software developers better understand the criteria “for the qualification of software falling within the scope of the new medical devices regulations,” the EU provided a guidance document on the application of the classification criteria for software. Follow the link below for The European Commission’s Medical Device Coordination Group (MDCG) 28-page guidance document released on October 11, 2019.
This guidance document clearly states in section 5.2 Classification Rules that the proper classification of medical device software requires the manufacturer to consider all classifications and implement the rules of Annex VIII of the IVDR.
Here are the examples provided for the classification of medical device software:
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).
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.
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). Classification examples in Annex IV are provided for guidance purposes and aim to illustrate how
To fully see the magnitude of the inclusion of software as an IVD from a regulatory perspective we have created a table to highlights the regulations for software and provides a reference to the IVDR 2017/746 document. The list of requirements is extensive and includes general safety and performance requirements, technical documentation, registration of devices and economic operation, classification rules, and performance evaluation, performance studies and post-market performance follow-up.
General Safety and Performance Requirements
Chapter 2 13.2 (d)
Construction of devices and interaction with their environment
Electronic programmable systems — devices that incorporate electronic programmable systems and software that are devices in themselves
Information in the instructions for use
Device description and specification
Software verification and validation
Registration of Devices and Economic Operations
PART C, 3.5
UDI assignment criteria
Minor software revisions
UDI placement criteria for software
Performance Evaluation Performance Studies and Post-Market Performance Follow-Up
Part A, 1.1
Performance evaluation plan
In summary, the regulation for all IVD devices changes with IVDR. The example above for software is just the tip of the iceberg. And, compliance with the new IVDR starts May 26, 2022. For more specific information on the time-line to transition to IVDR, classification of IVDs under IVDR, or analytical and clinical technical documentation aspects of IVDR conformity, check out our previous blog post.
Feel free to contact Criterion Edge for more details on how we can help you successfully transition your in vitro device to the IVDR.
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Tag Manager and Pardot's tracking features to collect information such as the number of visitors to the site, and the most popular pages. Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!