The FDA & EU IVDR Regulatory Frameworks For IVD SaMD

By Marcelo Trevino, independent expert

Software that is qualified as an in vitro diagnostic medical device (known as SaMD IVD) is affected by the same requirements as other medical devices, which are governed by various FDA regulations and EU In Vitro Diagnostic (IVD) Regulation EU 2017/746. Therefore, SaMD IVD's intended use, classification, clinical/performance requirements, and the content of the technical documentation must comply with these regulations. In my last article, I described how to know if FDA and EU regulators qualify your software as an IVD SaMD. This article builds on that foundation and summarizes the regulatory framework required for IVD SaMD in the U.S. and European markets.

Defining Software’s Intended Use And Regulatory Classification In The U.S.

In the U.S., IVD SaMD is classified according to risk-based criteria based on the intended use, then software is categorized by level of concern to establish the evidence required. There are four steps involved in the classification:

1. Select the appropriate device type regulation: There are three sections of regulations that cover IVD devices: 21 CFR Part 862 Clinical Chemistry and Clinical Toxicology, 21 CFR Part 864 Hematology and Pathology, and 21 CFR Part 866 Immunology and Microbiology.

2. Determine the appropriate device risk classification: There are three levels: Class I (low to moderate risk, general controls required), Class II (moderate to high risk, general controls and special controls required), or Class III (highest risk, general controls and premarket approval required).

3. Review device classification exceptions: Depending on the applicable regulations associated with the device, some devices might be exempt from premarket notification requirements.

4. Determine the associated product codes: Based on the applicable regulation number, FDA’s product classification database shall be used to review available product codes to identify predicate devices and the substantial equivalence information.

The “level of concern” refers to an estimate of the severity of injury that a device could permit or inflict, either directly or indirectly, on a patient or operator as a result of device failures, design flaws, or simply by virtue of employing the device for its intended use. There are three levels of concern for device software in the U.S.: major, moderate, and minor. To establish the level of concern, manufacturers should answer questions provided in FDA’s Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices and establish a rationale. This will determine the amount of documentation required in the premarket submission. FDA considers IVD software to be at least a moderate level of concern because software flaws could indirectly affect a patient and could potentially result in injury.

Determining Software’s Intended Use And Regulatory Classification In The EU

After the software is qualified as an IVD, the manufacturer shall define its intended use, since the intended use determines the regulatory classification of the software. The intended use shall capture the software’s core functionality and the effect of the information provided for healthcare decisions.

Once the software is qualified as an in vitro diagnostic medical device, the next step is to determine its risk class based on Annex VIII of Regulation (EU) 2017/746.

Rule 1.4 of Annex VIII indicates: “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.”

Rule 1.8 of Annex VIII indicates: “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.” Rule 1.9. of Annex VIII indicates: “If several classification rules apply to the same device, the rule resulting in the higher classification shall apply.”

MDCG 2019-11 provides examples of classification. However, it is important to note that these examples should not be considered confirmation of the final device’s classification, as manufacturers shall consider all the rules under Annex VIII for the in vitro diagnostic medical device software according to its intended purpose, and the justification should be documented in the device’s technical documentation.

General Safety And Performance Requirements (GSPR) For In Vitro Diagnostic Medical Device Software In The EU

In the EU, once a software qualifies as an in vitro diagnostic medical device, the manufacturer must demonstrate compliance with the 20 general safety and performance requirements detailed in Annex I of Regulation (EU) 2017/746. If some of these are not applicable, a justification must be provided. Software compliance can be supported through the use of different harmonized standards such as EN ISO 14971:2019 for medical device risk management.

Below are the relevant GSPRs affecting software:

GSPR 13.2(d) requires devices to be designed and manufactured in such a way as to remove or reduce as far as possible the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts.

GSPR 16 focuses on software and includes four points:

1. Software design must ensure repeatability, reliability, and performance in line with its intended use;
2. Software must be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management, including information security, verification, and validation;
3. Software running on mobile platforms shall be designed and manufactured taking into account the specific features of the mobile platform (e.g., size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards level of light or noise); and
4. Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics, and IT security measures, including protection against unauthorized access necessary to run the software as intended.

GSPR 20.4.1 (ah) addresses information required in the instructions for use and requires that the instructions for use for devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, shall contain minimum requirements concerning hardware, IT network characteristics, and IT security measures, including protection against unauthorized access, necessary to run the software as intended.

Software performance must also be demonstrated. MDCG 2020-1: Guidance on Clinical Evaluation (MDR)/Performance Evaluation (IVDR) of Medical Device Software provides guidance on the level of evidence required according to the EU 2017/746 IVD Regulation.

Clinical Evidence Through Performance Evaluation: FDA And EU Requirements

FDA and EU IVDR regulators require clinical evidence through performance evaluation. FDA and EU recognize IMDRF/SaMD/WG/N41 Final: 2017 for demonstrating clinical evaluation of SaMD in general. In the EU, there is an additional guidance provided for IVD SaMD: MDCG-2020-1 Guidance on Clinical Evaluation (MDR)/Performance Evaluation (IVDR) of Medical Device Software.

To demonstrate that the IVD SaMD performs as intended, manufacturers shall demonstrate that the software is designed using recognized standards and also that it can achieve its medical purpose safely and effectively. If the IVD SaMD uses an algorithm that must be trained to perform as intended, manufacturers shall provide a conclusion that the algorithm works for its medical purpose as part of the analytical and clinical performance evidence. Regulatory agencies in the U.S. and the EU will expect to see a description of the data sets used to evaluate the software, including inclusion or exclusion criteria, clinical site descriptions, number of subjects, algorithm development processes, statistical models used, and performance measures for verification and validation. Any claimed benefits must be supported with clinical evidence based on performance evaluation.

A valid clinical association shall be established between the IVD SaMD output and the target clinical condition and clinical studies to evaluate analytical and clinical performance. Effective performance of the SaMD’s intended use shall be demonstrated through analytical performance (demonstration that the software processes input data to generate accurate output data, which may include analytical sensitivity, analytical specificity, bias, precision, accuracy, limits of detection, and method comparison) and clinical performance (the analytical use of the software applied to the target population in a clinical care setting achieving its stated intended purpose or claimed benefit, which can be demonstrated referencing existing data from studies performed for the same intended use or by generating new clinical data for the specific software’s intended use).

EU IVDR And FDA Technical Documentation Requirements For Regulatory Review

For the EU, Annexes II and III of 2017/746 IVD Regulation provide details on the technical documentation that must be gathered for the software. EN 62304 provides good guidance to ensure most requirements are adequately addressed and the documentation generated according to EN 62304 standard allows a large part of the regulatory requirements to be met. The information to be provided includes, among others: an overview of the entire system and a description of the data interpretation methodology, a summary of the results of all verification, validation, and testing applicable in a real-world usage environment, labeling information, configurations, and operating systems required.

Similarly, FDA’s draft guidance Content of Premarket Submissions for Device Software Functions and Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices provide details on the recommended documentation that software manufacturers should include in premarket submissions. This includes, for example, software description, system and software architecture diagrams, risk management file, device hazard analysis for software devices, software design specifications, software level of concern classification, and verification and validation activities, among others.

FDA’s MDUFA Digital Health Commitments

As part of the Medical Device User Fee Amendment V (MDUFA V) passed by the U.S. Congress on Sept. 30, 2022, FDA established several Digital Health Commitments to be accomplished between fiscal year 2023 and fiscal year 2027 that will continue to build its digital health expertise and work to streamline and align their review processes with software life cycles for digital health products. The following are the six Digital Health Commitments:

1. Continue to develop software and digital health technical expertise to provide assistance for premarket submissions that include digital health.
2. Strengthen efforts to expand staff understanding of digital health topics and enhance consistent evaluation submissions.
3. Continue to participate in international harmonization efforts related to digital health.
4. Finalize the draft guidance Content of Pre-market submissions for device software functions by 18 months from close of the comment period.
5. Publish draft guidance describing a process to evaluate a predetermined change control plan for digital health devices.
6. Engage with stakeholders including patients, users, and industry through roundtables, informal meetings, and teleconferences to explore regulatory approaches to digital health technologies.

Conclusion

As SaMD becomes more predominant in the medical device world, it is important for manufacturers and developers to understand how to qualify an IVD SaMD and then to establish the analytical and clinical claims for the software to define its intended use, since this is how performance will be assessed by regulators to comply with regulatory requirements. IMDRF/SaMD WG/41 Final: 2017 is a thorough guidance document on how to approach performance evaluation for IVD SaMD, which is crucial to demonstrate that the IVD SaMD is safe and effective. There are many guidance documents and tools available to aid manufacturers through the IVD SaMD regulatory process, particularly driven by FDA’s CDRH Digital Health Center of Excellence, which provides digital health expertise and policy direction that manufacturers and developers should take advantage of. This is particularly important as many embark in IVD SaMD development activities that continue to evolve rapidly as artificial intelligence and machine learning applications continue growing in the medical device world.

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.