Healthcare AI: Navigating the Regulatory Challenges
Healthcare AI: Navigating the Regulatory Challenges
Failing fast is often used as a mantra in technology startups. It embraces the entrepreneurial drive to develop a solution to a problem quickly, validate the solution under realistic scenarios, and leverage the feedback to update and repeat the process. The core idea is that with each iteration the solution moves closer to solving the problem as deficiencies are gradually removed. Companies that offer Software as a Service (SaaS) embrace this model since decisions to add new features are driven by hard metrics of customer acquisition and retention rates. Commercial implementations of Artificial Intelligence (AI) were likewise rolled out against this backdrop. A prime example is the Netflix recommendation engine that uses prior customer data to customize a “best” list of movies related to a current movie selection. The company employed customers’ responses to sophisticated A/B testing to adapt the algorithms that personalize recommendations. Data considerations for AI development for medical device manufacturers were detailed in my previous blog, Healthcare AI: Does the data tell a compelling story? In this current blog, the regulatory pathway for AI medical devices will be discussed.
Failing fast is not a concept that resonates well within regulated environments, especially healthcare. A medical error can have significant ramifications for the health and well-being of a patient. Manufacturers of medical devices have systematic design processes built on thorough failure mode risk analysis, limiting both the number and negative effects of failures. In the early 1990s, it could be argued that medical device regulation was rigorously hardware-centric, burdensome from a documentation standpoint, and fairly risk-averse. For example, it was not until the De Novo program was established under the Food and Drug Administration Modernization Act (1997) that devices with low-to-moderate risk could be introduced as Class I or II instead of automatically starting as Class III. Shortly thereafter, the FDA released a series of guidance documents addressing direct regulation of software in medical devices, including Off-the-shelf Software (1999), General Principles of Software Validation (2002), and Premarket Submission for Software (2005). These documents tackled important topics such as leveraging industry software platforms and tools, planning for the entire software life cycle, and managing patient risks associated with the hardware device.
AI and Software as a Medical Device (SaMD) Risk Framework
In 2012, the FDA shifted to a global software regulatory approach by joining a consortium of medical device regulators, the International Medical Device Regulators Forum (IMDRF). The IMDRF introduced a new paradigm: Software as a Medical Device (SaMD), defined as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” This regulatory framework broadly encompasses software (including AI) that runs on general-purpose hardware and provides information directly related to clinical management. It is particularly important for computationally intensive AI algorithms that leverage hardware agnostic cloud platforms. The IMDRF formed a working group that developed a series of guidance documents supporting innovation and timely access to effective SaMD. One key FDA guidance is the SaMD Risk Categorization Framework consisting of four levels (I, II, III, IV) in increasing order of patient risk. According to Table 1, the risk categories are determined by a combination of a patient’s health condition (critical, serious, non-serious) and the impact of SaMD information on healthcare decision-making (treat or diagnose, drive clinical management, or inform clinical management). Naturally, the necessary systematic engineering controls for risk and quality management become more rigorous with the higher classification of risk level.
Table 1. MD Risk Categorization Framework
|Impact of SaMD Information on Healthcare Decision Making|
|Patient's Health Condition or Situation||Treat or Diagnose||Drive Clinical Management||Inform Clinical Management|
AI and SaMD Quality Management System
The IMDRF SaMD Quality Management System (QMS) Framework includes best practices for software life-cycle management from initial design through retirement. AI is heavily dependent on having the right data to design robust products that will realize regulatory approval. Medical devices capture large quantities of data for individual patients, for example, a 24-hour EEG study consisting of 26 leads of electrode measurements. However, a fundamental challenge is obtaining medical data for a large enough number (N) of patients with the appropriate medical conditions. In many cases, the number is less than ideal and thus is commonly referenced as the “small N” problem by the AI community. There are two strategies for dealing with this limitation during algorithm development. First, the training set is augmented by linearly modifying existing samples or creating new synthetic ones through AI approaches such as Generative Adversarial Networks. Second, the dimensionality of the feature space is reduced systematically using techniques such as principal component analysis. This will sustain the desired signal while suppressing the undesired noise. As a rule of thumb, the best approach to solve any given problem is to apply the simplest algorithm that meets the minimum performance criteria. Less complex techniques tend to be less susceptible to subtle variations in the data, and are therefore most likely to maintain performance for new input data.
AI and SaMD Clinical Evaluation
The IMDRF guidance Software as a Medical Device (SaMD): Clinical Evaluation details validation approaches for medical devices with AI. There are three components to clinical evaluations that need to be demonstrated:
- Valid clinical association between the SaMD inputs/outputs and targeted clinical condition. This involves producing supporting evidence from literature searches or secondary data analysis of prior clinical trials. It is important that the AI algorithm is not a “black box” and has a level of clinical justification for how it achieves results.
- Analytical validation that the SaMD output is as expected for a given input. The AI algorithm should be designed in a way to produce robust results consistently during training, as illustrated by the supervised learning example in my prior AI blog.
- Clinical validation showing the SaMD has been tested for intended use on the target populations, and users can achieve clinically meaningful outcomes given reliable and predictable use. Example measures of clinical validation include sensitivity, specificity, clinical usability, confidence intervals, and others.
The clinical evaluations are subject to independent review depending on the risk-based classification. This verification by an outside party is less critical for risk categories I and II than risk categories III and IV.
AI and SaMD Post-Market Monitoring
Figure 1 taken from the SaMD Clinical Evaluation Guidance outlines the cycle of post-market monitoring. The three levels of clinical evaluation are applied to real-world data which is collected, analyzed, and appraised. This may result in New Clinical Evidence which may be used to justify the enablement of new AI functionality or disablement of existing AI functionality, subsequently impacting the SaMD definition statement. For example, the risk classification may be increased if enough evidence is shown to support diagnosis instead of just driving clinical management. As an intentional strategy, AI medical device manufacturers may file an initial FDA submission with lower risk labeling claims and refile with higher risk claims after capturing the supporting real-world data. In 2017, the FDA released two recommendations that outline the process of making subsequent FDA submissions:
Figure 1. Pathway for Continuous Learning – Using Real World Performance Data from Ongoing Clinical Evaluation.
Proposed AI Regulatory Framework
In April 2019, the FDA released a document outlining a “Proposed Regulatory Framework for Modification to AI/ML based SaMD.” Essentially, the purpose of the discussion paper is to shorten the SaMD regulatory process surrounding iterative improvements of AI/ML algorithms. The proposed regulatory framework suggests that the SaMD manufacturer provides a predetermined change control plan as part of the FDA submission. This includes any of the following broad changes to the SaMD specification:
- Clinical and analytical performance;
- Inputs used by algorithm and clinical association to the SaMD output;
- Intended use of SaMD as outlined in the IMDRF risk categorization framework.
It also includes an algorithm change protocol necessary to support the changes to the SaMD specification. As shown in Figure 1, Post-Market Monitoring uses real-world data to determine whether the new clinical evidence supports changing the SaMD specification. If the modifications stay within the predetermined change control plan, the subsequent review process by the FDA should be streamlined.
AI and SaMD Recap
While the term failing fast does not resonate well in the MedTech community, the underlying concept of iterative software improvement certainly does. Over the last 20 years, the FDA and other regulatory bodies have moved the regulatory focus of medical device software from slowly evolving hardware devices to rapidly improving AI platforms. The FDA provides a regulatory pathway for medical devices with AI through a series of SaMD documents:
To have the right balance of AI and regulatory resources in order to realize your product vision, it is important to find a partner with both the necessary expertise and the real-world experience to back it up. Syncro Medical is ISO 13485 and ISO 9001 certified and has been building medical devices that incorporate sophisticated data analytics for over 30 years. Let Syncro Medical help you navigate the regulatory challenges in the path of bringing your AI medical device to market.