How Does the FDA Regulate DHTs
The FDA regulates DHTs as medical devices pursuant to authority granted under the Federal Food, Drug, and Cosmetic Act (FDCA), which gives it the authority to regulate devices that enter interstate commerce in the United States. The FDCA, in relevant part, defines a “device” as an article “intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals… and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes.”
In December 2016, Congress modified the definition of a device to specifically exclude certain software functions, including those intended to be used for:
- Administrative support;
- Maintaining or encouraging a healthy lifestyle, unrelated to diagnosis, cure, or treatment of a disease or condition (i.e., general wellness);
- Electronic patient records so long as, among other things, the function is not intended to interpret or analyze patient records for the purpose of diagnosis, cure, or treatment;
- Transferring, storing, converting formats, and displaying clinical laboratory test or other device data and results (i.e., Medical Device Data Systems or MDDS); or
- Certain clinical decision support (CDS).
FDA’s guidance “Multiple Function Device Products: Policy and Considerations” describes FDA’s evolving approach to the regulation of “multiple function” devices—products with at least one regulated device function and at least one “other function,” which may include not only non-device functions, but also device functions that are exempt from premarket review and those that fall within FDA’s enforcement discretion.
FDA defines the term “function” as a distinct purpose of the product, which could be the intended use or a subset of it. When a software function is intended for use in the diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease, or is intended to affect the structure or any function of the human body, the software function is a device under section 201(h) of the FDCA if it is not a software function excluded from the device definition pursuant to section 520(o) of the FDCA.
Software can be embedded in the hardware of another device (Software in a Medical Device or SiMD) or can function as a standalone product (Software as a Medical Device or SaMD). The FDA has a tiered approach to the regulation of DHTs, whereby, depending on its intended use and risk level, a software function is either a (i) device, subject to regulation; (ii) device over which the FDA does not intend to focus its regulatory oversight; or (iii) not a device and not subject to regulation.
As described above, the statutory definition of a device is quite broad. Read literally, the definition could potentially encompass software that helps automate the analysis of data generally conducted by healthcare professionals. While physicians have long used tools to assess multiple variables to help make diagnoses, new software has enabled healthcare professionals to receive analyses of complex data that could not be evaluated efficiently—or at all—by any single physician. Thus, while the output is not necessarily novel, the calculation speed and complexity certainly are.
The Evolution of DHT Regulation
The Medical Device Amendments of 1976 provided the FDA with comprehensive authority to regulate devices. Devices have been using software for decades. In fact, in 1987, the FDA issued a draft guidance, “Draft Policy Guidance for Regulation of Computer Products,” intended to provide software developers and manufacturers of devices with guidance about which DHTs were regulated as devices and which might be exempt from certain regulatory requirements. In a subsequent update, the FDA stated that medical software devices would not be the focus of the FDA’s oversight if they were “intended to involve competent human intervention before any impact on human health occurs (e.g., where clinical judgment and experience can be used to check and interpret a system’s output).”
The FDA’s guidance on the “General Principles of Software Validation” was drafted in 1997 and finalized in 2002, and it described how certain provisions of the Quality System Regulation under 21 C.F.R. Part 820 apply to software. For instance, it recommended an integration of software lifecycle management and risk management activities. This recommendation has largely been carried forward to today as the FDA contemplates a similar regulatory approach for many DHTs. However, with the recent finalization of the Quality Management System Regulation rule to harmonize the FDA’s quality management system requirements for devices with requirements in ISO 13485, it is yet to be seen when and how the FDA will update its policy for DHTs.
The late 1990s also marked the introduction of guidance documents for software premarket submissions contained in devices and for submissions for blood establishment computer software. A 2005 version of an update software premarket guidance superseded both documents, which the FDA again later updated in 2023.
In the last decade, there has been a surge in DHTs. Underscoring the breadth of this field, each type of DHT presents distinct regulatory considerations. Many of these technologies would not have been technologically or commercially viable in the recent past. Since enactment of the Cures Act, which amended the definition of a device to exclude certain software functions, the FDA issued additional guidances discussing the types of DHTs that would be subject to FDA oversight.
The FDA has been trying to be creative in its approach. In 2017, the FDA announced the launch of the Software Precertification Pilot Program in an attempt to explore innovative approaches to regulatory oversight of device software developed by entities who have demonstrated a robust culture of quality, organizational excellence, and commitment to monitoring real-world performance of their products postmarket. However, in September 2023, the FDA issued a report concluding that a new regulatory paradigm, requiring a legislative change, would be needed to implement the program.
In the area of AI/ML-based devices, to ensure there is an adequate regulatory framework to evaluate these fast-evolving technologies, the FDA issued a discussion paper in 2019 and an Action Plan in 2021 focused on AI-enabled devices by outlining the FDA’s next steps towards oversight for AI/ML-based devices. In February 2024, AdvaMed published a document describing foundational principles for AI in medical technology to help guide further innovations, policymaking, and regulations of these technologies.
With the explosion of health‑related DHTs and questions surrounding applicable regulatory oversight, the FDA developed the Digital Health Policy Navigator on September 28, 2022, as an interactive tool to help developers in determining whether a product’s software functions are subject to or the focus of the FDA’s oversight as a device.
In December 2023, the FDA announced the establishment of a new advisory committee on DHTs to help the FDA explore the complex scientific and technical issues related to DHTs. This effort is intended to bring together external experts across different disciplines to address cross-cutting issues and help improve the FDA’s understanding of the benefits, risks, and clinical outcomes associated with use of DHTs. Also in December 2023, the FDA issued a guidance on the use of DHTs to acquire data remotely for clinical investigations that evaluate medical products. It is intended to help improve the efficiency of clinical trials for stakeholders and increase the opportunities for individuals to participate in research. The DHT Advisory Committee is also expected to provide feedback. The next section delves deeper into the nuanced landscape of these technologies and the challenges they pose.
Current Regulatory Landscape of DHTs
Device Software Functions and Mobile Medical Applications
As discussed above, the FDA characterizes software that functions as a device as “device software functions.” This term is used to emphasize that a product could have multiple functions. Further, the definition of a device can encompass all types of software applications, which then run on a desktop, laptop, remotely on a website or cloud, or on a mobile device. The platform on which the software runs plays no role in whether it is subject to regulation as a “device.” Instead, the functionality of the software is the key determining factor.
Recognizing the dynamic characteristics of DHTs, regulators from around the world saw the need to develop a shared framework to promote innovation and protect public health. In 2013, the International Medical Device Regulators Forum (IMDRF) formed the Software as a Medical Device Working Group (WG), chaired by the FDA, to develop guidance supporting innovation and timely access to safe and effective SaMD. The WG defined SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” The FDA has used these principles in developing its own regulatory paradigm for DHTs. However, as discussed in the section above, many device-related software functions are not regulated by the FDA due to the FDA’s tiered approach.
General Wellness Products
Historically, products merely intended for general wellness indications (e.g., relaxation, stress management) have not been subject to FDA regulation unless they are intended for medical purposes. This is one of the categories that Congress explicitly excluded from the statutory device definition. The FDA issued a guidance in 2019, interpreting this exemption stating that the agency does not intend to regulate products, whether or not they meet the technical device definition, if they (1) are intended for only general wellness use, and (2) present a low risk to the safety of users and other persons.
This guidance defines a general wellness use as (1) “relates to maintaining or encouraging a general state of health or a healthy activity” or (2) “relates the role of healthy lifestyle with helping to reduce the risk or impact of certain chronic diseases or conditions and where it is well understood and accepted that healthy lifestyle choices may play an important role in health outcomes for the disease or condition.”
Products in the first category involve claims about “sustaining or offering general improvement to functions associated with a general state of health that do not make any reference to diseases or conditions” (e.g., it merely promotes a healthy weight or encourages healthy eating). In contrast, those in the second category make claims related to maintaining or promoting health or wellness, but only in the context of promoting, tracking, or encouraging choices which, as part of a healthy lifestyle, may help reduce the risk of or may help living well with certain chronic diseases or conditions. An example includes a product that promotes physical activity, which, as part of a healthy lifestyle may help reduce the risk of high blood pressure.
To be considered “low risk,” the product must not (a) be invasive (e.g., penetrate or pierce the skin), (b) be implanted, or (c) involve an intervention or technology that may pose a risk to the safety of users or other persons if specific regulatory controls are not applied, such as risks from lasers or radiation exposure.
Clinical Decision Support Software
Section 520(o)(1)(E) of the FDCA excludes from the definition of a device CDS software functions that meet the following four criteria (which the FDA refers to these products as “Non-Device CDS”):
- Not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system;
- Intended for displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);
- Intended for supporting or providing recommendations to a healthcare professional about prevention, diagnosis, or treatment of a disease or condition; and
- Intended for enabling such healthcare professional to independently review the basis for such recommendations that such software presents so that such healthcare professional does not rely primarily on any of such recommendations to make a clinical decision regarding an individual patient.
The boundaries between non-device CDS—unregulated by the FDA—and software that is a device remain fluid. Despite the statutory attempt at clarifying which CDS software are excluded from the definition of a device, understanding what constitutes CDS can be challenging. The FDA had issued multiple draft guidances interpreting the above criteria. Unsurprisingly, the FDA’s revised draft guidances elicited some criticisms due to scope and clarity. The FDA finalized the guidance in 2022 based on the feedback received.
Artificial Intelligence and Machine Learning
Some DHTs can be easily accommodated by the FDA’s traditional device regulatory scheme. Others cannot. AI/ML are examples of the latter.
AI has been considered the science of making intelligent machines. It employs different methods, such as models incorporating statistical analyses, use of “if-then” statements, and, sometimes, machine learning. ML is a subset of AI that can design and inform software algorithms so that they learn from new data. Algorithms can be “locked” so their function remains unchanged, or they can be “adaptive,” allowing their behavior to change over time, even after undergoing FDA review to gain access to the market.
To date, the FDA has reviewed and authorized about 700 devices with AI/ML (e.g., a software that identifies patients at risk for having sepsis and a software that screens for the presence of irregular heart rhythms). To date, these appear to have been for locked algorithms.
Currently, devices that rely on AI/ML are expected to follow the Clinical Evaluation Guidance by the IMDRF. There, AI/ML-based SaMD manufacturers are offered the option to submit a plan for post-approval modifications as part of the premarket review. The FDA’s premarket review would examine “the SaMD’s performance, the manufacturer’s plan for modifications, and the ability of the manufacturer to manage and control resultant risks of the modifications.” This framework relies on what the FDA is calling a “predetermined change control plan” discussed below.
Central to the FDA’s approach for AI/ML-based DHT, as with its regulation of all devices, is assuring the safety and effectiveness of products. Implementing mechanisms that provide transparency and allow for the monitoring of real-world performance are critical. For instance, the FDA maintains it is essential that modifications be communicated to stakeholders (e.g., by software notifications, e-mails, and letters) so they know about the change. Companies will need to decide whether these communications constitute reportable corrections or removals.
Real-word performance monitoring will require developers to gather data in a manner that device companies have not traditionally done. Given that these products differ from conventional devices by evolving through design, it is not surprising that the FDA will expect more in the way of monitoring real-world performance than for traditional devices.
Special Considerations for DHT Premarket Submissions
In addition to typical contents for a device premarket submission, DHT sponsors should also address specific topics, including specific documentation needs, DHT modifications, cybersecurity, and interoperability. Below is a highlight of key considerations for these topics.
Level of Documentation
The FDA’s guidance “Content of Premarket Submissions for Device Software Functions” notes the emergence of consensus standards regarding software has provided greater consistency and quality of software development and documentation. The guidance identifies information the FDA considers to be generally necessary to evaluate safety and effectiveness of DHTs in a premarket submission. This guidance notably includes increased alignment with the ISO device software standards.
The guidance applies to all types of premarket submissions that include one or more device software function(s). The guidance takes a risk-based approach, evaluating whether the software needs “basic” or “enhanced” documentation based on the risk level. Under this framework, the FDA recommends companies submit enhanced documentation for a premarket submission that includes device software functions when the device presents greater risk to a patient, a user of a device, or others in the environment of use. For example, the FDA recommends enhanced documentation level for a continuous ventilator for use in professional healthcare facilities due to the level of risk from the failure or latent flaw of the device software functions that could directly or indirectly result in death or serious injury.
Predetermined Change Control Plans
In the Food and Drug Omnibus Reform Act of 2022 (FDORA), Congress provided the FDA with express authority for predetermined change control plans (PCCPs) under section 515C. In March 2023, the FDA issued draft guidance “Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions” to outline a path to foster modification of AI/ML-enabled devices. This document is the first of several guidances that the FDA plans to issue related to PCCPs. Although prior to the enactment of FDORA, the FDA had already considered a mechanism to allow manufacturers to prespecify modifications for AI/ML-based software (see e.g., DEN190040 authorization requiring as a special control a “detailed protocol that describes, in the event of a future change, the level of change in the device technical specifications or indications for use”).
This guidance, when finalized, intends to reduce the need for prior FDA authorization of modifications to AI/ML-enabled device software functions. This includes modifications to the ML model that are implemented automatically (i.e., implemented automatically by software) and modifications to the ML model that are implemented manually (i.e., involving steps that require human input, action, review, or decision-making that are not implemented automatically).
The guidance states that proposed modifications should be consistent with the device’s intended use and indications for use and be “intended to maintain or improve the safety and effectiveness of the device.” Although the statutory language in section 515C appears broad, the draft guidance states that the FDA does not believe changes to indications for use could be allowed, as such modifications included in a PCCP would not allow the device to remain safe and effective.
Cybersecurity
Cybersecurity is a widespread issue that affects devices connected to the internet, networks, and other devices. The FDA defines cybersecurity as “the process of preventing unauthorized access, modification, misuse or denial of use, or the unauthorized use of information that is stored, accessed, or transferred from a medical device to an external recipient.” In recent years, numerous hospitals have demonstrated that they possess vulnerable devices susceptible to hacking. This stems from increasing connectivity of medical equipment to the internet and a lack of serious attention to cybersecurity, unlike in financial sectors, which has left thousands of devices vulnerable.
As cyberattacks in healthcare and life sciences sectors increased, the FDA has taken several steps to enhance cybersecurity for devices. The FDA acknowledges that “[c]ybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities in the U.S. and globally.” In recent years, the FDA issued multiple safety alerts to warn the public of certain cyber risks. In January 2020, the FDA issued a safety communication warning that attackers could “remotely take control of the medical device to silence alarms, generate false alarms and interfere with alarms of patient monitors connected to these devices.” In September 2022, the FDA alerted device users about Medtronic’s MiniMed insulin pump system. The alert concerned potential for “unauthorized access” to the pump system, which could be used to deliver too much or too little insulin.
In 2023, the FDA issued guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,” which replaced a 2014 guidance, by providing updated recommendations regarding cybersecurity safety measures for devices, including detailed recommendations on conducting cybersecurity risk assessments, interoperability considerations, and documentation to help manufacturers improve cybersecurity measures, both pre- and postmarket.
Historically, the FDA has argued that cybersecurity is a fundamental aspect of device safety, thus justifying requiring it as part of a device risk assessment to ensure the safety and effectiveness of a device (21 CFR 820.30). However, it was not until recently that Congress granted explicit authority to the FDA. Section 3305 of FDORA added section 524B to FDCA, which requires applicants to provide cybersecurity information in their device submissions for “cyber devices” to demonstrate their products meet cybersecurity requirements. Section 524B(c) of FDCA defines “cyber device” as a device that “(1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.” If a device uses software that connects to the internet, it is most likely a cyber device. In March 2024, the FDA issued a draft guidance “Select Updates for the Premarket Cybersecurity Guidance: Section 524B of the FD&C Act,” (Premarket Cybersecurity Guidance) proposing updated recommendations on cybersecurity considerations for cyber devices, consistent with this recent statutory amendment. When finalized, the FDA plans to incorporate this guidance into the Premarket Cybersecurity Guidance.
The FDA’s electronic Submission Template And Resource (eSTAR) Form, an interactive form that guides applicants through the process of preparing a comprehensive device submission, includes a guide that follows the recommendations noted in the 2023 Premarket Cybersecurity Guidance. Practically, this means that manufacturers will be prevented from submitting a 510(k) without the FDA-prescribed cybersecurity information, if applicable.
The FDA’s guidance “Postmarket Management of Cybersecurity in Medical Devices” from December 2016 provides recommendations on how to assess whether the risk of patient harm is sufficiently controlled or uncontrolled. According to the FDA, this assessment is based on “an evaluation of the likelihood of exploit, the impact of exploitation on the device’s safety and essential performance, and the severity of patient harm if exploited.”
Vulnerabilities, such as viruses or worms, may jeopardize the operation of networked devices. As a result, constant maintenance is required to safeguard against unauthorized access to the network or device. The FDA’s guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” outlines principles that the FDA considers to be applicable to software maintenance actions required to address cybersecurity vulnerabilities for networked devices—specifically, those that incorporate off-the-shelf software. This guidance makes it clear that such device manufacturers are expected to be vigilant and responsive to cybersecurity vulnerabilities under 21 C.F.R. § 820.100. Thus, each manufacturer is expected to regularly analyze sources of data and implement necessary corrective and preventive actions relating to cybersecurity.
Interoperability
Interoperable devices are those “that have the ability to exchange and use information through an electronic interface with another medical/non-medical product, system, or device.” In September 2017, the FDA released the guidance “Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices.” The guidance is not limited to the addressing unidirectional sending of patient data; it includes complex interactions, including the control of devices. It addresses three principal areas: (1) design considerations for interoperable devices, including testing and risk management of interoperable devices; (2) the content of premarket submissions for interoperable devices; and (3) labeling considerations for interoperable devices. The guidance elaborates in detail on each of these elements.
The FDA further states that to ensure the safe performance of the interoperable devices, manufacturers are expected to establish “appropriate functional, performance, and interface requirements.” According to the FDA, failure to do so may lead to device malfunction, patient injury, and possibly death. To illustrate, the FDA gives a simple example: the transmitting of patient weight in kilograms when the receiving device assumes the weight is in pounds.
Conclusion
The FDA’s regulation of devices is dynamic, having shifted dramatically since enactment of the Medical Device Amendments of 1976. However, the devices themselves have changed even more than the law. DHTs, by taking so many different forms at such a rapid pace, present significant challenges to the existing regulatory paradigm. Devices that exist now would have seemed fantastical fifteen years ago, and it is hard to envision the capabilities of new products.
The FDA is aware of those challenges. How the FDA addresses the explosion of DHTs will have a major impact on the agency, manufacturers, the healthcare industry, patients and consumers, and the growth of the digital health industry.