FDA Issues Draft Guidances to Scale Back Regulation of Digital Health Software

On December 8, 2017, the U.S. Food and Drug Administration (“FDA”) issued two draft guidance documents that describe types of software functions that FDA will not regulate, including FDA’s long-awaited policy on clinical decision support software. FDA published these documents in response to the 21st Century Cures Act, in which Congress removed certain low risk digital health software from FDA’s jurisdiction. In addition, as part of its broader Digital Health Innovation Action Plan, FDA announced that it was adopting as final guidance a document developed by the International Medical Device Regulators Forum (“IMDRF”) on clinical evaluation of software as a medical device. FDA also announced a January 30, 2018, public workshop on the progress of the Software Precertification (“Pre-Cert”) Pilot Program.

These developments continue to build on the policies FDA has been developing in recent years to clarify the applicability of FDA regulatory requirements to digital health technologies. While FDA’s policy structure in this area remains a work in progress, these documents continue the general trend towards relatively limited, risk-based FDA regulation of digital health software.

Draft Guidance on Clinical and Patient Decision Support Software

As discussed in several previous Ropes & Gray Alerts (summarizing the 21st Century Cures Act, the General Wellness guidance, and the Digital Health Innovation Action Plan), device manufacturers have long anticipated FDA guidance on clinical decision support (“CDS”) software. FDA’s new draft guidance, “Clinical and Patient Decision Support Software,” describes FDA’s proposed views on the regulation of CDS as well as a related category of software that FDA defines as patient decision support (“PDS”) software.

Section 3060 of the 21st Century Cures Act (section 520(o) of the FDCA) removes certain software functions from the definition of “device.” One category under this provision is a software function that:

1. Is 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;
2. Is intended to display, analyze, or print medical information about a patient or other medical information, like clinical practice guidelines;
3. Is intended to support or provide recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and
4. Is intended to enable health care professionals to independently review the basis for the software’s recommendations so professionals do not primarily rely on the recommendations when making a clinical diagnosis or treatment decision.

In the draft guidance, FDA proposes to define CDS as software functions that meet the first, second, and third criteria listed above. FDA states that such a CDS function, in order not to be considered a “device,” would also have to meet the fourth criterion. FDA also states that it would continue to regulate as devices software that is Class III (i.e., software that is intended for a use in supporting or sustaining human life or for a use which is of substantial importance in preventing impairment of human health, or that presents a potential unreasonable risk of illness or injury).

FDA provides examples of CDS that meet, and do not meet, all four of the agency’s proposed criteria. Software functions that FDA would consider to be excluded from FDA regulation are:

1. Software that makes recommendations by matching patient information with reference information that is commonly used in clinical practice. Within this category, FDA includes (i) software that identifies drug-drug interaction alerts based on FDA-approved drug labeling and patient-specific information and (ii) software that uses a patient’s diagnosis to provide a health care provider with current practice treatment guidelines for common diseases and provides the source of those guidelines;
2. Software that suggests an intervention or test using clinical guidelines in response to a physician’s order, such as suggesting that a health care professional order liver function tests before prescribing a statin; and
3. Software that uses rule-based tools that compare patient-specific signs, symptoms or results with available practice guidelines to recommend condition-specific diagnostic tests, investigations, or therapy.

In contrast, FDA intends to focus its regulatory oversight on two types of CDS-related software.

First, FDA will regulate software intended to generate treatment and diagnostic recommendations on which the health care professional will rely primarily in making clinical decisions or determining therapy plans. To be excluded from the definition of “device,” the CDS function must be intended to enable the health care professional to independently review the basis for the recommendations presented by the software. In the draft guidance, FDA states that, to meet this criterion, such software must clearly explain (i) the purpose or intended use of the software function, (ii) the intended user, (iii) the inputs used to generate the recommendation, and (iv) the rationale or support for the recommendation. FDA believes that a health care professional would be unable to evaluate the basis of a software recommendation independently if it were based on non-public or proprietary information. Thus, under the draft guidance, a software function would fail to qualify as non-device CDS if it operates via a non-transparent algorithm. This aspect of the draft guidance is likely to generate public comment, because it does not take into account the degree of risk posed by the product. However, it is possible that FDA might choose to exercise enforcement discretion with respect to such software if it falls within another low-risk category set forth in the second draft guidance, described below.

Second, FDA intends to regulate software designed to acquire, process, or analyze a medical image, a signal from an in vitro diagnostic (“IVD”) device that can detect diseases, or a pattern or signal from a signal acquisition system (a machine that receives, as inputs, signals from sensors on the body). FDA has historically regulated technologies that analyze the information from signal acquisition systems, such as IVD tests and technologies that measure and assess electrical activity in the body (e.g., electrocardiograph and electroencephalograph machines) as well as medical imaging technologies. Also included within this category are algorithms that process physiologic data to generate new data points or that analyze and interpret genomic data to determine a patient’s risk for a particular disease.

The following are examples of software functions that FDA intends to regulate:

1. Software that customizes the patient-specific surgical plan and instrumentation based on analysis of imaging and device characteristics for orthopedic implant procedures;
2. Software that analyzes multiple physiological signals (e.g., sweat, heart rate, breathing) to monitor whether a person is having a heart attack;
3. Software that analyzes near-infrared camera signals of a patient intended for use in determining and/or diagnosing brain hematoma; and
4. Software that analyzes multiple physiological signals, such as heart rate and eye movement, to monitor whether an individual is having a heart attack or narcolepsy episode, and software that analyzes images of body fluid preparations or digital slides to perform cell counts and morphology reviews.

Moreover, the draft guidance addresses the agency’s enforcement discretion policy for low-risk PDS software that is intended for patients or caregivers who are not health care professionals. Specifically, FDA will exercise enforcement discretion and not enforce compliance with applicable regulatory requirements if the PDS meets the same four criteria that CDS must meet as outlined in Section 520(o)(1)(E) of the FDCA, thus generally mirroring the policy FDA is adopting for CDS, except that the fourth criterion would be modified in the PDS context to require transparency of the basis for the software recommendations to laypersons (patients) rather than health care professionals.

Other Changes to FDA’s Existing Software Policies

The 21st Century Cures Act also excludes from the definition of “device” four other categories of low-risk software functions. These statutory changes affect several existing FDA policies and guidance documents. As a consequence, the draft guidance on “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act,” describes the changes FDA intends to make to several previously published guidance documents, including FDA’s guidances on “Mobile Medical Applications,” “General Wellness: Policy for Low Risk Devices,” and “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices.” As an overarching concept, FDA notes that section 3060 of the 21st Century Cures Act creates a function-specific standard of software functions that do not meet the definition of “device,” independent of the platform on which the software runs.

The draft guidance describes the four types of software functions that FDA is excluding from the scope of its regulation:

1. Software functions intended for administrative support of a health care facility. FDA has historically not regulated most of these software functions as devices. The draft guidance clarifies, however, that Laboratory Information Management Systems, which is software intended for administrative support of laboratories and/or for transferring, storing, converting formats, or displaying clinical laboratory test data and results, no longer falls under the definition of “device.”
2. Software functions intended for maintaining or encouraging a healthy lifestyle. We have previously described FDA’s policy of exercising enforcement discretion with respect to software devices intended for certain “wellness” purposes. In the draft guidance, FDA identifies the following examples from the General Wellness Guidance of mobile applications that no longer meet the definition of “device” due to the 21st Century Cures Act amendments: (i) an application that plays music to soothe and relax an individual to manage stress; and (ii) an application that solely monitors and records daily energy expenditure and cardiovascular workout activities to allow awareness to improve or maintain good cardiovascular health. In addition, although the statutory amendment does not apply to wellness claims that relate to the role of a healthy lifestyle in helping reduce the risk or impact of particular chronic diseases or conditions, FDA states that it will continue to exercise enforcement discretion over this category of products as long as they present a low risk to the safety of users and other persons.
3. Software functions intended to serve as electronic patient records. Under the 21st Century Cures Act, a software function intended to transfer, store, convert formats, or display electronic patient records that are the equivalent of a paper medical chart would not be a “device” if: (i) the records were created, stored, transferred, or reviewed by health care professionals; (ii) the records are part of information technology certified by the Office of the National Coordinator for Health Information Technology (“ONC”); and (iii) the software function is not intended for interpretation or analysis of patient records. In the draft guidance, FDA states that as long as criteria (i) and (iii) are met, it does not intend to enforce the statutory requirement that the software function be certified by ONC. Additionally, the draft guidance clarifies that personal health records, which include software functions that enable a patient or non-health care provider to create, store, or transfer health records for their own record-keeping, are not devices.
4. Software functions that are intended for transferring, storing, converting formats, and displaying data and results. In the draft guidance, the agency explains that software functions that solely transfer, store, covert formats, and display medical device data would no longer fall within the definition of a “device,” but that this exclusion does not apply to software that analyzes or interprets medical device data. Accordingly, software functions that generate alarms or alerts or prioritize patients based on their clinical status are not excluded from the definition of “device.” FDA explains, however, that it intends to exercise enforcement discretion not to regulate “low risk” software functions of this type, such as analysis of data to provide a notification for which immediate clinical action is not needed. 

However, FDA notes that a software function described above will not be excluded from the definition of “device” if FDA makes a finding that the software function would be reasonably likely to have serious adverse health consequences and certain substantive and procedural criteria are met, or if the device is Class III.

Software Precertification Program Workshop

FDA also announced an upcoming public workshop that will be held on January 30 and 31, 2018, which aims to discuss the current development of its Software Pre-Cert Pilot Program, which Ropes & Gray summarized here. This voluntary pilot program—which began in September 2017 and currently includes nine participants — will assess a new approach for regulating digital health software that focuses on evaluating the software developer or digital health technology developer, rather than focusing primarily on the product. The public workshop will discuss various topics relating to precertification, such as the criteria and measures to evaluate whether a company is conducting high-quality software design, testing, and ongoing maintenance of its software products and the types of digital health products that should be marketed without FDA review based on precertification.

IMDRF Guidance on Clinical Evaluation of Software as a Medical Device

The IMDRF is a voluntary group of medical device regulators from around the world that focuses on international medical device regulatory harmonization and convergence. This group has published several documents relating to regulation of Software as a Medical Device (“SaMD”), defined as software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device. The guidance document FDA has recently adopted and published in final form addresses the “clinical evaluation” of SaMD, which includes the activities needed to assess the clinical safety, performance, and effectiveness of SaMD for its intended use. When FDA initially proposed adopting this guidance document in October 2016, the draft was criticized by the medical device industry for its heavy use of terminology and concepts from foreign regulatory systems (particularly European), and its unclear relevance to the FDA regulatory framework. The final document eliminates some of the most concerning uses of such terminology and concepts that commenters identified, but may continue to be of uncertain application for entities that design and develop SaMD for the U.S. market.

Implications for the Digital Health Software Industry

FDA’s release of the two draft guidance documents, and continuing efforts to facilitate the Software Pre-Cert program, represent the agency’s efforts to oversee digital health products under a risk-based framework and to prioritize innovation in this field. Whether the IMDRF Guidance on clinical evaluation of SaMD will have any real-world impact for U.S. software developers remains to be seen, but the document represents yet another step in FDA’s efforts to build out a more complete and internationally consistent regulatory framework for digital health software. FDA also has indicated that it will publish separate guidance on the regulation of a product with multiple functions, including at least one device function and at least one software function that is not a device.

Interested persons have until February 6, 2018, to submit comments on the two draft guidance documents. Ropes & Gray will continue to monitor developments in the digital health space. If you have any questions, please contact any member of Ropes & Gray’s FDA regulatory practice or your usual Ropes & Gray advisor.