The FDA recently released six guidance documents as part of the agency’s continued focus on updating the regulatory stance on software as a medical device and other digital health products. The updated guidance documents reflect the need for a more flexible, risk-based approach to regulation that accommodates a rapidly evolving technological landscape. This On the Subject summarizes the key provisions and changes presented in the guidance, and discusses next steps for stakeholders impacted by FDA’s evolving approach to digital health regulation.
The 21st Century Cures Act, enacted in December 2016, amended the definition of “medical device” in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FDCA) to exclude five distinct categories of software or digital health products. In response, the US Food and Drug Administration (FDA) issued new digital health guidance and revised several pre-existing medical device guidance documents. FDA also stated that it would continue to assess how to update and revise these guidance documents as its thinking evolved.
Late last week, FDA issued five final guidance documents and re-issued a draft guidance document to better reflect FDA’s current thinking on software as a medical device (SaMD) and other digital health products:
Most of the guidance documents reflect modest changes to prior draft guidance documents that describe categories of low-risk health and wellness devices that FDA does not intend to regulate. FDA’s new draft Clinical Decision Support (CDS) Software guidance, however, provides a new and more detailed analysis of risk factors that FDA will apply to determine whether a CDS tool is a medical device. FDA updated its previously issued draft CDS guidance without finalizing it. Although the new guidance does not explain why FDA is reissuing the CDS guidance in draft, the new draft guidance seems to reflect the agency’s attempt to better align its definition of non-device software with the often misunderstood and misinterpreted statutory definition of CDS in section 520(o)(1)(E) of the Cures Act. The chart below summarizes the key provisions and changes to these guidance documents.
Digital health products can present a particular challenge for developers and regulators in assessing the appropriate regulatory pathways for a new product. The updated guidance documents reflect the need for a more flexible, risk-based approach to regulation that accommodates a rapidly evolving technological landscape. These documents also reflect what appears to be the new normal for digital health regulation—the need for iterative thinking and ongoing revisions to interpretive guidance documents to keep pace with a constantly changing marketplace.
FDA finalized its draft guidance, which provides FDA’s current thinking regarding the amended definition of a “device” and the resulting impact it has on FDA guidance documents related to medical device software that predate the Cures Act. The guidance describes changes to the following four guidance documents at a high level:
FDA clarified that hardware with general wellness intended uses that relate to maintaining or encouraging a general state of health or healthy activity that otherwise meet the definition of a “device” under section 201 of the FDCA will continue to be regulated as devices.
FDA also withdrew its Guidance for the Submission of Premarket Notifications for Medical Image Management Devices, because some software functions described therein no longer meet the definition of a “device.” For the Medical Image Management Devices that continue to meet the definition of “device,” FDA acknowledged that the guidance was out-of-date and encouraged medical device manufacturers to reference the FDA-recognized versions of voluntary consensus standards instead.
Overview FDA previously finalized its draft guidance on General Wellness Products in 2016 (previously discussed here).
FDA clarified that software functions that are intended for maintaining or encouraging a healthy lifestyle and are unrelated to the diagnosis, cure, mitigation, prevention or treatment of a disease or condition are excluded from the definition of “device.”
The title of Section V has been changed to “Examples of General Wellness Products that Are Not Medical Devices and Examples of General Wellness Products that Are Medical Devices for which FDA Does Not Intend to Enforce Requirements” to more accurately reflect the fact that some examples provided in this section do not meet the definition of a “device.”
Overview This guidance supersedes the February 9, 2015, “Mobile Medical Applications” guidance. While FDA broadened the scope of the guidance to include device software that includes mobile applications, FDA reiterated that it intends to apply regulatory oversight to only those software functions that:
Are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or analyzing medical device data
Transform the mobile platform into a regulated medical device by using attachments, display screens or sensors, or by including functionalities similar to those of currently regulated medical devices
Become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis or treatment recommendations.
FDA intends to continue exercising enforcement discretion (i.e., based on FDA’s current understanding of risks, it does not intend to enforce compliance with applicable device requirements) over the following software functions:
Helping patients (i.e., users) self-manage their disease or conditions without providing specific treatment or treatment suggestions
Automating simple tasks for healthcare providers (HCPs)
Providing or facilitating supplemental care by coaching to help patients manage their health in their daily environment
Facilitating access to information related to the patients’ health conditions or treatments (beyond providing an electronic “copy” of a medical reference)
Allowing patients to communicate with their HCPs by supplementing or augmenting data or information by capturing a image for patients to send to their HCPs about potential medical conditions
Performing simple calculations otherwise normally used in a clinical practice.
FDA also moved a number of examples from Appendix B (examples of mobile apps for which FDA intends to exercise enforcement discretion) or Section V.B (examples of mobile apps for which FDA intends to exercise enforcement discretion, such as functions that enable patients or HCPs to interact with electronic health record (EHR) systems or those intended to transfer, store, convert, format and display medical device data in its original form) to Appendix A (examples of mobile apps that are NOT medical devices) because they no longer meet the definition of a “device.”
Overview Since the Cures Act excludes software that is intended for “transferring, storing, covering formats, or displaying clinical laboratory test or other device data and results unless such function is intended to interpret or analyze clinical laboratory test or other device data, results, and findings” (emphasis added), Medical Device Data Systems (MDDS), medical image storage devices and medical image communications devices no longer meet the definition of a “device.”
The guidance defines “Non-Device-MDDS” as software functions that are solely intended to transfer, store or convert formats and display medical device data or results. However, software functions that “analyze or interpret” medical device data and results, such as medical images, waveforms, signals or other clinical information, remain devices. Additionally, software functions intended to generate alarms or alerts or prioritize patient-related information on multi-patient displays are not excluded from the definition of a “device,” because they involve analysis or interpretation of laboratory tests or other device data and results.
The guidance also defines “Device-MDDS” as hardware functions that are solely intended to transfer, store or convert formats and display medical device data or results. Hardware that is intended to transfer, store, convert formats and display medical device data and results remains a device unless it is used solely for transfer, storage or conversion of formats and to display medical device data or results.
FDA intends to provide recommendations on Non-Device-MDDS and Device-MDDS functions with respect to how they affect the safety and effectiveness of device function(s) in multiple function device products in a separate guidance.
Overview In the revised guidance, which updates the September 1999 guidance, FDA removed the section on “Exemption of Laboratory Information Management Systems,” for Laboratory Information Systems and Laboratory Information Management Systems functions, which includes calculator/data processing modules for clinical use under 21 CFR section 862.2100, intended for administrative support. FDA made this change because FDA no longer regulates software that simply transfers, stores, converts formats or displays clinical laboratory test data and results as a “device.”
Overview FDA clarified that the term “clinical decision support” (CDS) is used broadly. CDS provides HCPs and patients with information, “intelligently filtered or presented at appropriate times” to enhance healthcare. Under section 520(o)(1)(E) of the FDCA, software that meets all of the following criteria are excluded from the definition of a “device,” (further discussed here):
Not intended to acquire, process or analyze a medical image or a signal from an in vitro diagnostic device or pattern or signal from a signal acquisition system
Intended for the purpose of displaying, analyzing or printing medical information about a patient or other medical information (e.g., peer-reviewed clinical studies and clinical practice guidelines)
Intended for the purpose of supporting or providing recommendations to an HCP about prevention, diagnosis or treatment of a disease or condition
Intended for the purpose of enabling an HCP to independently review the basis for such recommendations that the software presents so that it is not the intent that a HCP rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.
The most significant element is whether the HCP can independently review the basis for information or recommendations the software presents, so that the HCP is not required to rely primarily on any of such recommendations to make a decision regarding a patient.
In the previous version of the draft guidance, FDA stated that it also intended to exercise enforcement discretion over products intended for patients or caregivers if the software generally paralleled CDS for HCPs and met all four criteria above. The revised guidance removes the concept of “patient decision support” or “PDS” software. FDA now considers all CDS software that is intended for a patient or caregiver, regardless of whether the user can independently review the basis for information or recommendations presented by the software, to be “Device CDS,” although some Device CDS software intended for patient or caregiver use remains subject to enforcement discretion. For example, software that provides information to a patient about the use of a prescription drug that is consistent with both FDA-approved labeling and the patient’s prescription, such as software that reminds a patient how or when to take a prescribed drug, remains under enforcement discretion.
If the software is intended for an HCP and the HCP can independently review the basis for information or recommendations, the software is “Non-Device CDS.” The revised guidance clarifies that “Non-Device CDS” includes software functions that meet all criteria in the basic framework and only includes software intended for HCPs.
For Device CDS, FDA has adopted the International Medical Device Regulators Forum (IMDRF) risk-based framework for categorizing products, which evaluates (1) the significance of the information provided by the product to a healthcare decision (to treat or diagnose, to drive clinical management or to inform clinical management) against (2) the state of the healthcare condition (critical, serious, non-serious). See IMDRF “‘Software as a Medical Device’: Possible Framework for Risk Categorization and Corresponding Considerations.” Based on this, FDA has established a summary of its current regulatory policy and added examples for each of the following categories:
Device CDS functions for which FDA intends to exercise enforcement discretion
Device CDS functions on which FDA intends to focus regulatory oversight
Non-Device CDS functions on which FDA intends to focus regulatory oversight (e.g., software that manipulates or analyzes images to create models intended to be used in planning surgical treatments).
Intended User Is HCP
Intended User Is Patient or Caregiver
IMDRF Risk Categorization
Can User Independently Review Basis of Recommendation?