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.