As the Covid-19 pandemic pummels healthcare institutions around the world, some doctors are turning to innovation to diagnose patients: artificial intelligence (AI).
Despite herculean efforts to do so, governments are still straining to scale up lab-based methods like nucleic acid and antibody testing, but these new in silico tools offer a way to save on both money and time. That means some regions are betting big on AI: the European Commission, for example, is investing money into a tool that analyzes computerized tomography scans to accelerate patient diagnosis.[i]
Software diagnostic tools like these have exploded over the past decade, covering conditions that range from melanoma to spinal fracture to, of course, Covid-19. But as the use of those tools has grown, so have the associated regulatory challenges.
Most digital diagnostic tools fall under the umbrella of software as a medical device (SaMD), a larger umbrella that includes not just software used for diagnosis, but also for prevention, treatment, and so on.
According to the International Medical Device Regulators Forum (IMDRF), SaMD is software intended for a medical purpose achievable through operation of the software itself. Software that only supports a larger piece of hardware (e.g., pacemaker software), in other words, is not SaMD.[ii] And software used in a medical context that doesn’t have a specific medical purpose (e.g., image capture software that doesn’t perform analysis) also isn’t SaMD.
But outside of those caveats, SaMD as a category is quite broad. It runs the gamut from diagnosis to prevention to treatment, addresses all kinds of medical conditions, can be run on specialized medical equipment or general-purpose devices (e.g. phones), and can operate independently or in conjunction with other hardware. Plus, different countries might have different goalposts for what counts as SaMD.
As you would expect, that creates quite the headache for regulators—and for software manufacturers too.
Diagnostically speaking, SaMD comes in several flavors. Some tools are intended to support doctors, particularly radiologists, in a clinical setting, helping to capture what even the trained human eye might miss, and these naturally receive close scrutiny. According to one article in Diagnostic Imaging, the US Food and Drug Administration (FDA) had approved 28 algorithms in this vein as of October 2019.[iii]
But on the flip side, there is also an increasing trend of direct-to-consumer tools, which sometimes receive tens of millions of downloads.[iv] Some such apps do their best to fly under the regulatory radar, arguing that they are relatively low-risk and are meant to complement—not substitute for—professional medical advice.
Whether intended for clinical or consumer use, these diagnostic tools carry their own suite of regulatory challenges. There’s an enormous number of them, for one: 318,000 mobile health apps by one count (although this includes apps that aren’t used for diagnosis, or don’t count as medical devices). Those that are AI-based may continue to change during use, leading them to defy the usual premarket pathways for approval. Also, they blur the lines of liability: if a diagnostic tool goes wrong, who’s to blame—doctor, hospital, or software creator?[v]
And as a review by Australia’s Therapeutic Goods Administration (TGA) notes, there is far too little research available on how the use of these tools impacts patient safety.[vi] Because journals tend to publish positive results over negative ones, studies that indicate performance failures don’t always see the light, creating the risk that regulators see an all-too-rosy picture. For regulators, this hence implies the importance of post-market surveillance data.
Direct-to-consumer diagnostic tools also face challenges, as seemingly innocuous as they are. Some of these apps work poorly and may give consumers false assurance—for example, incorrectly telling them that their melanoma is harmless and leading them to delay treatment.[vii]
Regulators hence must be discerning when assigning risk levels to diagnostic SaMD.
As is common elsewhere, many regulators have adopted a risk-based approach to classifying diagnostic SaMD. The IMDRF’s proposed categories run from I to IV, with IV being the most serious.[viii] A device’s category is decided based on two variables: the healthcare condition in question, and the nature of the information provided by the SaMD.
|Significance of information provided by SaMD to health care decision|
|State of healthcare situation or condition||Treat or diagnose||Drive clinical management||Inform clinical management|
This framework allows for a relatively flexible approach to SaMD management. According to examples the IMDRF provides, SaMD used to self-assess hearing loss would be Category I, and SaMD that analyzed heart rate data to help clinicians diagnose arrhythmia would be Category II. Malignant skin lesions are “critical” conditions, so if SaMD provides data (e.g. monitoring growth) that supplements other information to diagnose malignancy, it would be Category III, but if used as the sole tool to build a structural map and calculate dimensions of a lesion, it would be Category IV.
Of course, countries and regions manage and designate these risk categories in varying ways. For example, both the US and EU take high-risk SaMD quite seriously—an FDA guidance document recommends “independent review” for higher-risk SaMD.[ix] But when it comes to lower-risk SaMD, the two regions diverge in their regulatory approach.
Under the Trump administration, the US FDA takes a “hands off” approach to regulating lower-risk SaMD, stating that it will “exercise enforcement discretion” even though software may meet the definition of a medical device. Former Trump-appointed FDA commissioner Scott Gottlieb has argued that over-regulation of mobile health could stifle innovation, though not all his colleagues may agree.[x] Particularly worth watching is FDA’s new PreCert program, which will allow SaMD developers to roll out products by getting FDA approval of the company’s development process—rather than the product itself.[xi]
This move toward SaMD liberalization in the US contrasts with the increasingly strict EU approach. For example, the EU’s new Medical Device Regulation (MDR) will strictly limit the number of SaMD designated as minimal-risk.[xii] The EU recognizes SaMD as Class I, IIa, IIb, or III, but the MDR, scheduled to go into effect in May 2021 after a Covid-19-related delay, has a “Rule 11” that will push the majority of Class I devices into Class IIa at a minimum.
Some commentators have criticized this as an undue focus on severity, rather than risk, which will increase the costs of regulatory compliance—in other words, limiting innovation in just the way that ex-commissioner Gottlieb pushed back against.[xiii]
Regulators have their work cut out for them, as they struggle to balance the need to protect patient safety battling with the drive to foster life-saving innovation. New trends like the increasing adoption of AI will only make it more difficult to design appropriate regulatory frameworks, although they also create opportunities for regulatory advancements. Many countries are trying to evaluate the US PreCert program, for example, to see if they can pilot similar programs in their local markets.
For now, SaMD for diagnostic will need both technical innovation as well as clear-thinking regulatory innovation.
[v] https://www.mobius.md/blog/2019/03/11-mobile-health-statistics; https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-software-medical-device; https://hbr.org/2018/03/ai-will-change-radiology-but-it-wont-replace-radiologists
[viii] https://www.fda.gov/medical-devices/software-medical-device-samd/global-approach-software-medical-device-software-medical-device; http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf
[xii] https://www.med-technews.com/features/how-european-guidance-affects-classification-of-software-und/; https://blog.cm-dm.com/post/2019/05/24/MDR%3A-one-year-left-and-too-late-for-class-I-software