The Latest FDA Move To Limit Digital Health Software Regs

This article by partner Greg Levine and associate Rebecca Williams and was published by Law360 on December 21, 2017.

On Dec. 8, 2017, the U.S. Food and Drug Administration issued two draft guidance documents that describe types of software functions that the FDA will not regulate, including the FDA’s long-awaited policy on clinical decision support software. The FDA published these documents in response to the 21st Century Cures Act, in which Congress removed certain low-risk digital health software from the FDA’s jurisdiction. In addition, as part of its broader Digital Health Innovation Action Plan, the 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. The FDA also announced a Jan. 30, 2018, public workshop on the progress of the Software Precertification (Pre-Cert) Pilot Program.

These developments continue to build on the policies the FDA has been developing in recent years to clarify the applicability of FDA regulatory requirements to digital health technologies. While the FDA’s policy structure in this area remains a work in progress, these documents continue the general trend toward 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 articles (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. The FDA’s new draft guidance, “Clinical and Patient Decision Support Software,” describes the FDA’s proposed views on the regulation of CDS as well as a related category of software that the FDA defines as patient decision support (PDS) software.

Section 3060 of the 21st Century Cures Act (Section 520(o) of the Federal Food, Drug, and Cosmetic Act) 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, the FDA proposes to define CDS as software functions that meet the first, second and third criteria listed above. The FDA states that such a CDS function, in order not to be considered a “device,” would also have to meet the fourth criterion. The 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).

The FDA provides examples of CDS that meet, and do not meet, all four of the agency’s proposed criteria. Software functions that the 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, the FDA includes (1) software that identifies drug-drug interaction alerts based on FDA-approved drug labeling and patient-specific information, and (2) 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, the FDA intends to focus its regulatory oversight on two types of CDS-related software.

First, the 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, the FDA states that, to meet this criterion, such software must clearly explain (1) the purpose or intended use of the software function; (2) the intended user; (3) the inputs used to generate the recommendation; and (4) the rationale or support for the recommendation. The FDA believes that a health care professional would be unable to evaluate the basis of a software recommendation independently if it were based on nonpublic or proprietary information. Thus, under the draft guidance, a software function would fail to qualify as nondevice CDS if it operates via a nontransparent 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 the 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, the 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). The 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 physiological 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 the 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, the 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 the 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 the FDA intends to make to several previously published guidance documents, including the 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, the 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 the FDA is excluding from the scope of its regulation:

1. Software functions intended for administrative support of a health care facility: The 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 the FDA’s policy of exercising enforcement discretion with respect to software devices intended for certain “wellness” purposes. In the draft guidance, the 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: (1) an application that plays music to soothe and relax an individual to manage stress; and (2) 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, the 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: (1) the records were created, stored, transferred or reviewed by health care professionals; (2) the records are part of information technology certified by the Office of the National Coordinator for Health Information Technology (ONC); and (3) the software function is not intended for interpretation or analysis of patient records. In the draft guidance, the FDA states that as long as criteria (1) and (3) 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.” The 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, the FDA notes that a software function described above will not be excluded from the definition of “device” if the 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

The FDA also announced an upcoming public workshop that will be held on Jan. 30 and 31, 2018, which aims to discuss the current development of its Software Pre-Cert Pilot Program, which we 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 the 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 the 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

The 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 the FDA’s efforts to build out a more complete and internationally consistent regulatory framework for digital health software. The 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 Feb. 6, 2018, to submit comments on the two draft guidance documents.