Does The FDA Or EU IVDR Consider IVD Software An IVD Medical Device?
By Marcelo Trevino, independent expert
In recent years, software has been playing an increasingly critical role in the medical device world. Software with a medical intended use can be embedded as part of a medical device (and regulated as part of the device) or it can also be considered a medical device by itself and regulated as an independent device, which is called Software as a Medical Device (SaMD). In vitro diagnostic devices are known as IVD SaMD. This article summarizes the regulatory requirements in the EU, which are governed by the In Vitro Diagnostics Regulation (IVDR), and the requirements in the U.S., which are governed by the FDA under different parts of the Code of Federal Regulations and guidance documents, to allow manufacturers and developers understand the steps they must undertake to be able to commercialize these types of devices.
EN 62304:2006/A1:2016 is the standard on the life cycle processes for medical device software and it is considered the state of the art in medical device software development. It is recognized by FDA and IVD regulators as a consensus standard. The standard sets out requirements for the software life cycle, from development to maintenance of medical device software when software is itself a medical device and when software is an embedded or integral part of the final medical device. It also provides a framework of processes, activities, and tasks necessary in the software life cycle: a) software development process, b) software maintenance process, c) software risk management process, d) software configuration management process, and e) software problem resolution process.
The standard classifies software into three classes:
- A: No injury or damage to health is possible (requirements for software system shall be established during design and development);
- B: Non-serious injury is possible (requirements for software system shall be established during design and development and architecture of software shall be described); and
- C: Death or serious injury is possible (requirements for software system shall be established during design and development, architecture of software shall be described, and a description of the detailed design is required).
Once the initial safety classification has been carried out for the system, it is possible to break the system down into software items and software units that shall also be aligned with the design requirements.
A summary of the effects of the software classification on documentation and processes according to 62304 is provided below:
U.S. FDA Guidance
The FDA has published multiple guidance documents regarding the regulation of software, including SaMD. Some types of software are regulated as medical devices, whereas other types of software are not regulated.
There have been many digital health guidance documents published by FDA in recent years. Below are a few examples that can significantly aid manufacturers and software developers:
- Multiple Function Device Products: Policy and Considerations
- Content of Premarket Submissions for Device Software Functions (Draft)
- Digital Health Technologies for Remote Data Acquisition in Clinical Investigations (Draft)
- Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (Draft)
- Changes to Existing Medical Software Policies resulting from Section 3060 of the 21st Century Cures Act
- Policy for Device Software Functions and Mobile Medical Applications
- Off the shelf software use in Medical Devices
- Clinical Decision Support Software
- Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
- Medical Device Data Systems, Medical Image Storage Devices and Medical Image Communications Devices
- General Wellness: Policy for Low-Risk Devices
- Software as a Medical Device (SaMD): Clinical Evaluation
- Medical Device Accessories – Describing Accessories and Classification Pathways
- Deciding When to Submit a 510(k) for a Software Change to an Existing Device
- Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices
FDA has developed an interactive tool, called Digital Health Policy Navigator, to introduce digital health policies to stakeholders in an interactive format with simplified questions and yes and no answers. Manufacturers can assess if a particular software function meets the device definition and if it is likely it will be regulated by FDA as a device. The tool introduces policy considerations in plain language to allow manufacturers to easily understand policies and pathways.
As an additional resource, FDA recently published a list of currently marketed Artificial Intelligence (AI)/ Machine Learning (ML) Enabled Medical Devices. This list is a non-exhaustive list based on publicly available information that is meant to be a public resource on these devices and FDA’s work in this area and to show how AI/ML is being used across medical disciplines.
IVD SaMD Software Qualification in the U.S.
Software that meets the definition of a medical device under section 201(h) of the FD&C Act is deemed a medical device. IVD medical devices are regulated under 21 CFR 809. 21. CFR 809.3 (a) states:
“In vitro diagnostic products are those reagents, instruments, and systems intended for use in the diagnosis or disease or other conditions, including a determination of the state of health, in order to cure, mitigate, treat or prevent disease or its sequelae. Such products are intended for use in the collection, preparation, and examination of specimens taken from the human body. These products are devices defined in section 201(h) of the Federal Food, Drug, and Cosmetic Act (the act), and may also be biological products subject to section 351 of the Public Health Service Act.”
Since there are many software applications and different categories, different regulatory approaches could be applicable depending on the nature of the software. This is particularly relevant when it comes to clinical decision support. Software used to inform clinical management is not regulated as a medical device if it is intended for a healthcare professional to independently review and understand the basis of the software’s recommendation and the software does not perform signal or image acquisition, processing, or analysis.
In September 2022, FDA finalized guidance on Clinical Decision Support that focuses on explaining four criteria necessary for clinical decision support software to be considered non-device clinical decision support. If software meets all four of the following criteria, it would be considered non-device clinical decision support software and would not be regulated as a device:
- The software function does NOT acquire, process, or analyze medical images, signals, or patterns.
- The software function displays, analyzes, or prints medical information normally communicated between healthcare providers.
- The software function provides information and/or options to a healthcare provider rather than a specific output or directive.
- The software function provides the basis of the recommendations so that the healthcare provider does not rely on any recommendations in order to make a decision.
EU IVDR
Regulation (EU) 2017/746 on in vitro diagnostic medical devices came into force on May 26, 2022. The regulation includes several types of software used in in vitro diagnostics and provides safety- and performance-specific performance requirements that manufacturers must comply with. The EU does not use the term Software as a Medical device (SaMD). Instead, the term medical device software (MDSW) is used for classification purposes.
IVDR SaMD Software Qualification And Defining Software Intended Use
The first step to qualify a software as an in vitro diagnostic medical device is to verify that the software is intended for in vitro diagnosis. According to Article 2 of Regulation (EU) 2017/746 on in vitro diagnostic medical devices,
"in vitro diagnostic medical device" means any medical device which is a reagent, [...] software or system, whether used alone or in combination, intended by the manufacturer to be used in vitro for the examination of specimens from the human body […] for the purpose of providing information on one or more of the following:
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 disease;
4. To determine the safety and compatibility with potential recipients;
5. To predict treatment response or reactions;
6. To define or monitor therapeutic measures.“
Software intended to be an accessory to in vitro diagnostic medical devices also falls under this definition and is subject to the same rules for demonstration of compliance. Manufacturers should then determine if the software creates information based on data obtained by IVD medical devices only. If it does, then the software is an IVD medical device, but if the data analyzed is obtained from an IVD and another medical device, then manufacturers must assess if the intended purpose is substantially driven by data sources coming from that other medical device since the EU MDR regulation could also be applicable.
MDCG 2019-11 provides examples of software qualified as in vitro diagnostic medical devices or that are excluded from the IVDR definition.
Software could be used in a healthcare environment but not considered an in vitro diagnostic medical device, such as, for example, software intended solely for communication, storage, or performing a simple search or software that supports the process from patient sample to patient result (such as laboratory information systems).
Software that combines and processes multiple in vitro diagnostic results (possibly combined with data from medical or non-medical devices) qualifies as an in vitro diagnostic medical device. For example, this category includes software that integrates genotype of multiple genes to predict risk of a disease or medical condition developing/recurring or software that uses an algorithm to characterize viral responses to different drugs based on genotyping assays.
There is also software that combines different modules, some intended for medical use and others that are not intended for medical use. According to the MDCG 2019-11, only modules intended for medical use are subject to the requirements of the regulation. It is the obligation of the manufacturer to identify the boundaries and the interfaces of the different modules based on the intended use. This will ensure that the combination of modules or systems is assessed for safety and does not impact performance of the modules subject to the medical device regulation as required per Annex I of the EU 2017/746 IVD Regulation.
In the EU, there are two categories of software that qualify as in vitro diagnostic medical devices: a) software that is independent of any other device (stand-alone software) and b) software that drives or influences the use of a device. Regardless of whether the software is stand-alone or embedded, its qualification depends on the intended medical purpose of the software. For example, software needed to make raw data from an in vitro diagnostic medical device readable to enable the use of the device for its intended purpose is considered software that drives or influences the use of the device.
With all of this information, you should now know if the FDA and EU are regulating your IVD software as a medical device. This is the foundation you’ll need before navigating those regulatory frameworks, which I’ll cover in my next article.
About The Author:
Marcelo Trevino is the global vice president, regulatory affairs and quality assurance at Agendia, a molecular diagnostics company focused on breast cancer genomic testing. He has more than 20 years of experience in global regulatory affairs, quality, and compliance, serving in senior leadership roles with different medical device organizations. He has an extensive knowledge of medical device management systems and medical device regulations worldwide. Trevino holds a BS in industrial and systems engineering and an MBA in supply chain management from the W.P. Carey School of Business at ASU. He is also a certified Medical Device Master Auditor and QMS Master Auditor by Exemplar Global. He can be reached at marcelotrevino@outlook.com or on LinkedIn.