Clarity of Intended Use a Key Point in IVDR Device Classification

The first part of this two-part examination of risk delved into risk classification for conventional medical devices, a highly complex picture for developers with customers in multiple markets. The picture is no less complicated for makers of IVD test kits, partly because many regulatory schemes employ a four-tier risk classification framework. In contrast, the FDA may end up with a two-tier risk system if Congress passes a wide-reaching legislative proposal, the Verifying Leading-edge IVCT Development (VALID) Act of 2021, which we previously discussed.

The EU’s Medical Device Coordination Group (MDCG) published a guidance for classification for IVDs in November 2020, stating that the risk is determined by the intended purpose, or intended use. The intended use is determined by the data regarding device performance as supplied in product labels, along with the instructions for use, promotional and sales material, and “statements.”

The MDCG stated that a clear limitation of use should be spelled out in the instructions for use and in any technical documentation if the test developer wants to avoid an inadvertent up-classification. A problem may arise when more than one classification rule or sub-rule applies to the test, and MDCG advises that the intended purpose and any associated claims should be “sufficiently specified to enable a clear attribution of the [risk] class.” Otherwise, the guidance states, “ambiguous claims may lead to a higher classification” of risk.

For reference, section 1.9 of Annex VIII of the IVDR states, “if several classification rules apply to the same device, the rule resulting in the higher classification shall apply.” We would also note that for a test with more than one intended purpose, the higher risk classification is applied to all distributed tests without exception.

Software a Complicating Factor in Risk Determinations

As we noted in our previous blog on risk classification, the combination of software and device hardware can drive either component into a higher risk category, which may hold true for the IVDR guidance as well. Section 3.2.3 of the MDCG guidance states explicitly that software that drives or influences the use of the device will be accorded the same risk classification as that device. The guidance includes several annexes that provide different risk classifications of a diagnostic system, depending on the use.

‍

One example is a blood gas analyzer and associated software, which could fall into class C when used without a reagent or disposable sensor cassette, assuming the outcome would change the physician’s decisions regarding patient management. This intended use produced a class A designation when the analyzer and software analyze the sample only after the sample has been processed with reagents or a replaceable sensor cassette.

This could all prove especially complicated when the software is an artificial intelligence (AI) application used with the IVD, however. This is because a draft EU legislative proposal for AI seems to suggest that AI software would be a high-risk product when it affects the safety profile of any product with which it is used, a consideration we described in a previous blog. The MDCG IVD risk guidance makes no mention of AI, leaving open the possibility that AI software used with IVDs could elevate the test’s risk classification.

The MDCG guidance states that the highest risk category, class D, includes tests used to detect transmissible, potentially lethal pathogens with a high rate of propagation. This holds as well for tests of transmissible pathogens in blood and other donated tissues. The list of class C tests is lengthier, and includes tests that:

• Serve as companion diagnostics;
• Are used to detect sexually transmitted diseases; and
• Are used for disease staging, assuming an erroneous test result would endanger the life of the patient.

Class C tests also include those used to screen, diagnose and stage cancer, but screening tests for pre-cancerous conditions also fall into class C. While test developers are likely to see a one-year delay in the implementation date for the IVDR per a recent proposal by the European Commission, we advise developers to continue to update their compliance systems and their premarket dossiers, particularly given the shortage of notified bodies that are certified for the IVDR.

SaMD Risk Categorization in a State of Flux

Developers of software as a medical device (SaMD) occupy a highly unpredictable space where risk classification is concerned for several reasons, including the pending status of several draft regulatory frameworks for AI and ML. The International Medical Device Regulators Forum had previously assembled a risk framework for SaMD, and as the saying goes, there’s good news and bad news.

The good news for developers marketing products outside the U.S. is that the IMDRF uses a four-tier system, which may be bad news for products distributed in the U.S. when paired with IVDs. The previously discussed VALID Act would impose a two-class system on these tests, and there is no indication how the FDA would navigate this difference. This uncertainty will prevail regardless of whether the agency maintains its three-tier approach to risk for software rather than the four-tier approach in the IMDRF guidance, but one thing is clear: The solution is difficult to predict and may be exceptionally complicated.

Another consideration is that the IMDRF guidance is seven years old and may be in need of a refresh, given the ongoing regulatory churn, particularly in the realm of AI and machine learning (ML). As written, the guidance features a matrix that categorizes the significance of the information provided by the SaMD, such as when used to:

• Inform clinical management;
• Drive clinical management; or
• Treat or diagnose the patient’s condition.

These three elements would be combined with non-serious, serious, and critical patient conditions to yield a total of nine risk determinations. The highest risk category, category IV, is applied to software that is used to treat or diagnose a patient who is in a critical condition. However, software used to inform clinical management of patients in critical condition will be deemed a class II product.

More to the point of the utility of the IMDRF guidance is that it includes several total product life cycle (TPLC) considerations, including the now-notorious question of change control. Section 8.2 of the guidance recommends that developers institute “an appropriate level of control to manage changes” to the software, and to conduct a risk-based assessment of any modifications to an algorithm. The obvious problem for any software distributed in the U.S. is that the FDA is intent on publishing a draft guidance for change control for AI, which is certain to be much more specific than the provisions found in the IMDRF guidance.

That greater degree of specificity in any FDA guidance is not necessarily a problem for the IMDRF guidance, as IMDRF documents serve primarily as statements of regulatory principle and are anything but compulsory. On the other hand, the EU’s discussion paper on AI is another potential source of regulatory disharmony, and we might point out that the U.K. Medicines and Health Care Products Regulatory Agency recently declared its intent to overhaul its regulatory regime, a proposal that includes software regulation. SaMD developers are thus ensured that they will inhabit a world of uncertainty regarding risk for several years to come, which itself is a source of significant risk to developers.