New FDA Guidance Clarifies Exemptions for Digital Health Software

Key Points

• Two new draft guidances aim to conform FDA’s existing digital health-related policies to the software exemptions from the device definition added by Cures, and are largely faithful to those legislative provisions.
• The CDS draft guidance does not pinpoint the precise line between CDS that is not a medical device and other clinical decision analytical software that could, or would, be subject to device regulation; this ambiguity is also consistent with the Cures legislation, which sets out criteria that are not self-executing.
• The CDS draft guidance, which also addresses patient decision support software, is co-authored by CDER, as well as the two centers that review devices (CDRH and CBER); this reflects the increasing intersection between digital health and drug development and regulation.

  ---

Last year at this time, we analyzed the provisions in the newly minted 21st Century Cures Act (“Cures”) that exempt certain software functions from regulation by the U.S. Food and Drug Administration (FDA) as a medical device.¹ The Cures provisions largely aligned with FDA’s practices and policies toward health-related software, although certain aspects of the exemptions are potentially broader than those under current agency policies. During 2017, FDA initiated a number of changes to its regulatory approach to health-related software, often referred to under the general rubric of “digital health.” These initiatives have included the “pre-certification” pilot program and investment in digital health expertise through the MDUFA IV user fee reauthorization. On December 7, FDA took another major step toward advancing the regulatory framework in this space, issuing two draft guidances indicating how it will implement the digital health-related provisions of Cures.²

Background

Cures Section 3060 amended the federal Food, Drug, and Cosmetic Act (FDCA) by adding a new subsection to Section 520 that defines five categories of software functions to which the statutory definition of “device” in section 201(h) does not apply. “Functions” that fall within one or more of the following five categories are not medical devices subject to FDA oversight: administrative software, software to support a healthy lifestyle, electronic patient records, Medical Device Data Systems (MDDS) and Clinical Decision Support (CDS). The two draft guidances, “Clinical and Patient Decision Support Software” and “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act,” provide FDA’s interpretation of the scope of its regulatory authority and long-awaited clarity on several aspects of the Cures exemptions. Although much of the draft guidance is unsurprising, given the language of the Cures provision and FDA’s existing regulatory approaches, some of FDA’s proposed approaches are noteworthy, and many questions remain unanswered. 

CDS Guidance

Industry has anxiously awaited the draft guidance “Clinical and Patient Decision Support Software”³ since FDA announced a plan to develop guidance addressing what is commonly captured under the catch-all phrase “clinical decision support” in 2011. Notably, this guidance has been issued by Center for Devices and Radiological Health (CDRH) and the Center for Biologics Evaluation and Research (CBER)—the two centers that review medical devices—as well as the Center for Drug Evaluation and Research (CDER). This reflects the increasing relevance of CDS in drug applications and the on- and off-label use of drugs in practice. It also suggests that the policies in the draft guidance reflect the active consideration of CDER and provide the draft guidance with the imprimatur of the broader agency. In addition to addressing CDS specifically for the first time, this draft guidance also addresses “patient decision support” (PDS), which is not explicitly referenced in Cures.

CDS

One of the five exemptions to the definition of “device” added by Cures covers certain aspects of CDS. Just as this has been a complicated category for FDA to address, the statutory language of the exemption is also quite complex. Under the exemption, a CDS-related software function is not a device if (1) it is not intended for certain uses and (2) it is intended for each of three uses (all three must be met).

First, a function potentially qualifies for this exemption, unless it “is 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 . . . .” As we noted in our original Cures analysis, Congress did not define “signal acquisition system,” leaving significant ambiguity as to the ultimate scope of the CDS exemption. FDA does offer clarity in the draft guidance: “A signal acquisition system is the electronic circuitry and control processor that receives, as inputs, signals from sensors that are within, attached to (e.g., EEG, ECG), or external to (e.g., CT, MRI) the human body or sample from the human body (e.g., digital pathology).”⁴ Technologies that “analyze physiological signs and provide diagnostic, prognostic and predictive functionalities are devices.” 

We surmised in our original analysis that the CDS exemption might not extend to software that analyzes data derived directly from the body via an in vitro diagnostic (IVD), sensor or other instrument, or to software that analyzes data derived directly from a medical device. FDA seemingly confirms this point, noting that such technologies falling outside of the CDS exemption “include, but are not limited to, in vitro diagnostic tests, technologies that measure and assess electrical activity in the body (e.g., electrocardiograph (ECG) machines and electroencephalograph (EEG) machines), and medical imaging technologies. Additional examples include algorithms that process physiologic data to generate new data points (such as ST-segment measurements from ECG signals), analyze information within the original data (such as feature identification in image analysis), or analyze and interpret genomic data (such as genetic variations to determine a patient’s risk for a particular disease).”

In addition to the exclusion, the three mandatory purposes that an exempt CDS function must have are also relatively restrictive. To qualify, an exempt CDS must have the purpose of:

1. “displaying, analyzing, or printing medical information about a patient or other medical information ...;”
2. “supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition;”
3. “enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.”

As described in our earlier analysis of the Cures exemptions, these criteria suggest that the characterization of the output of a CDS tool is less significant than the transparency of the tool itself. In its draft guidance, FDA clarifies that the “independent review” prong will be met if the software function explains:

1. “The purpose or intended use of the software function;
2. The intended user (e.g., ultrasound technicians, vascular surgeons);
3. The inputs used to generate the recommendation (e.g., patient age and gender); and
4. The rationale or support for the recommendation.”

We have advised in the past that this concept would remain challenging and subjective; although the guidance proposes more specific criteria than FDA has previously, it remains somewhat unclear what constitutes a sufficiently transparent software function under these criteria. One seemingly clear-cut factor has been that CDS software that identifies sources supporting a recommendation is less likely to be subjected to active regulation. FDA confirms this point in the guidance: “In order for the software function to be excluded from the definition of device, the intended user should be able to reach the same recommendation on his or her own without relying primarily on the software function. The sources supporting the recommendation or underlying the rationale for the recommendation should be identified and easily accessible to the intended user, understandable by the intended user (e.g., data points whose meaning is well understood by the intended user), and publicly available (e.g., clinical practice guidelines, published literature).” FDA provides several examples of CDS functions that are not devices, including:

• 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
• software that makes chemotherapeutic suggestions to a health care professional based on patient history, tests results and patient characteristics, including software suggesting a platinum-based chemotherapy for BRCA-positive individuals that is consistent with drug labeling
• software that presents and prioritizes alternatives to orders, drugs or therapies using practice guidelines or other generally accepted practices (e.g., software providing ventilator guideline suggestion, based on patient-specific blood gas readings and current condition).

Illustrative examples of CDS and other software functions on which FDA intends to focus its regulatory oversight are:

• software that analyzes multiple physiological signals (e.g., sweat, heart rate, eye movement, breathing) from FDA-regulated devices to monitor whether a person is having a heart attack or narcolepsy episode
• software intended for health care professionals that uses an algorithm undisclosed to the user to analyze patient information to determine which antihypertensive drug class is likely to be most effective in lowering the patient’s blood pressure
• software that analyzes a patient’s laboratory results using a proprietary algorithm to recommend a specific radiation treatment for which the basis of the recommendation is unavailable for the health care provider to review.

PDS

Finally, the draft guidance addresses the status of PDS software, which is not addressed in Cures. FDA proposes to adopt an enforcement discretion policy for PDS that generally parallels the CDS functions excluded from the “device” definition. To qualify for enforcement discretion, PDS would need to be low-risk and meet the same four factors as CDS, with special accommodations for the difference between a patient and health care professional as the intended user. To qualify for enforcement discretion, PDS software must (1) not acquire, process, or analyze a medical image or a signal from an IVD or a pattern or signal from a signal acquisition system; (2) display, analyze or print medical information about a patient or other medical information; (3) support or provide recommendations to patients or non-health care professional caregivers about prevention, diagnosis, or treatment of a disease or condition; and (4) enable the patient or non-health care professional caregiver to independently review the basis for the recommendation so that it is not the intent that such patient or non-health care professional rely primarily on any of such recommendations to make a decision regarding the patient. This proposed treatment of PDS appears to complement FDA’s ongoing policy of enforcement discretion toward low-risk “wellness”-related functions that mention a specific disease or condition, but might be potentially broader in certain respects (see discussion of “Healthy Lifestyle” software, infra).

Cures Changes Guidance

The second guidance, “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act,”⁵ includes FDA’s proposals to make the agency’s existing digital health guidances (“General Wellness”⁶; “Mobile Medical Applications”⁷; “Off-the-Shelf Software Use in Medical Devices”⁸; and “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices”⁹) conform to the software exemptions to the device definition as amended by Cures. In it, FDA addresses the four remaining Cures exemptions, for software functions intended (1) for administrative support of a health care facility; (2) for maintaining or encouraging a healthy lifestyle; (3) to serve as electronic patient records; and (4) for transferring, storing, converting formats, and displaying data and results. We analyze each in turn below.

Administrative Support Software

Section 520(o)(1)(A) of the FDCA exempts from the definition of “device” a software function that is intended “for administrative support of a health care facility . . . ,” such as billing, claims and scheduling. As we noted in our Cures analysis (and FDA confirms in the guidance), this category had been generally understood to fall outside the existing definition of “device” in Section 201(h) of the FDCA. To clarify further, FDA proposes to modify its “Off-the-Shelf Software Use in Medical Devices” guidance to remove the section titled “Exemption of Laboratory Information Management Systems,” which are not within the definition of “device,” as amended by Cures.

Software to Support a Healthy Lifestyle

Pursuant to Section 520(o)(1)(B), the term “device” does not include a software function intended “for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.” 

In FDA’s “General Wellness” guidance, the agency declared its intent not to examine “low-risk general wellness products” to determine whether they are devices or, if they are devices, whether they comply with premarket and postmarket device requirements. In that guidance, CDRH defines a “general wellness product” as a product that meets two factors:

1. intended for only general wellness use
2. presents a low risk to the safety of users and other persons.

The “General Wellness” guidance elaborated on what FDA then considered to be general wellness intended uses:

1. “An intended use that relates to maintaining or encouraging a general state of health or a healthy activity” or
2. “An intended use that relates to 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.”

In the “General Wellness” guidance, FDA remained noncommittal regarding what was not a device, and what was a device subject to enforcement discretion. In the “Cures Changes” guidance, FDA proposes that software functions in the second category above—the “living well with disease” category—are not exempt from the statutory “device” definition because they “relate to the mitigation or prevention of a disease or condition.” However, FDA intends to continue to apply enforcement discretion for this type of wellness software function as long as it is low-risk. Thus, FDA concludes that a “software function with a healthy lifestyle claim (e.g., products that fall within the first category of general wellness intended uses as defined by the General Wellness Guidance) is not a device as long as its claims are unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.”

For example, FDA lists the following healthy lifestyle software functions that are not devices:

• a mobile app that monitors and records food consumption to “manage dietary activity for weight management and alert the user, healthcare provider, or family member of unhealthy dietary activity”¹⁰
• mobile apps that track a normal baby’s sleeping and eating habits
• mobile apps that help healthy people track the quantity or quality of their normal sleep patterns
• mobile apps that use social gaming to encourage healthy lifestyle habits.

It may be inappropriate to equate the mention of a disease or condition (in the context of a well-understood healthy lifestyle choice to help people live well with that condition) with a disease claim.¹¹ Further, although FDA currently does not intend to enforce the applicable device requirements to this category of software, FDA is not bound by this decision and may begin enforcement against these software functions at any time. 

Electronic Patient Records

The Cures software provision also exempts certain electronic patient records. Functions intended “to serve as electronic patient records, including patient-provided information, to the extent that such records are intended to transfer, store, convert formats or display the equivalent of a paper medical chart” are not devices if three conditions are met:

1. “such records were created, stored, transferred, or reviewed by health care professionals, or by individuals working under supervision of such professionals”
2. “such records are part of health information technology that is certified” by the Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program;
3. “such function is not intended to interpret or analyze patient records, including medical image data, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.”¹²

One particular aspect of the draft guidance as it relates to electronic patient records is particularly noteworthy. FDCA Section 520(o)(1)(C)(ii), added by Cures, specified that electronic patient records would not be exempt from device regulation unless, among other things, “certified by the [ONC] Health IT Certification Program.” FDA backs away from this requirement in the draft guidance, instead stating that the agency will not enforce the requirement. Presumably, FDA coordinated this proposed approach with the Department of Health and Human Services. Nevertheless, we expect that this aspect of the draft guidance will garner significant attention, since FDA’s limited explanation for its approach highlights the tension between the agency’s wide latitude to set its own enforcement priorities and the constitutional requirement that FDA enforce the laws enacted by Congress.¹³

FDA also notes that software functions that do meet the definition of “device” may be contained in a system with software functions that do not meet the definition. The agency intends to address this situation (products with multiple functions) in a separate guidance document.

MDDS

Finally, Cures exempts software functions known as MDDS from the device definition. After classifying MDDS in 2011,¹⁴ FDA ultimately finalized a policy of enforcement discretion toward MDDS in 2015. In keeping with FDA’s MDDS definition, the Cures exemption covers software “for transferring, storing, converting formats, or displaying clinical laboratory test or other device data . . . unless such function is intended to interpret or analyze” such data. Much like the exemption for software supporting a healthy lifestyle, this exemption had the effect of making MDDS functionality, which, until the passage of Cures, had been a medical device but granted enforcement discretion, not a device at all. FDA identifies in the draft guidance the criteria that would render a software function not MDDS (and subject it to FDA oversight) as “analyz[ing] or interpret[ing] medical device data in addition to transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results.”¹⁵

One question raised by the Cures language was whether the MDDS exemption would include the transfer and display of medical device data for “active patient monitoring.”  FDA policy, pre-Cures, was that MDDS could not be intended for active patient monitoring.¹⁶ FDA’s draft guidance does not articulate this precise limitation.  Rather, FDA distinguishes between patient monitoring that requires immediate clinical action and monitoring for which immediate clinical action is not needed.  FDA proposes not to enforce regulatory requirements for low-risk software functions that potentially include active patient monitoring (e.g., “the analysis of data to provide a notification, for which clinical action is not needed”). Instead, “FDA intends to focus its regulatory oversight on software functions intended to generate alarms or alerts or prioritize multi-patient displays if they are intended to alert a caregiver to take an immediate clinical action.” 

Contact Information

If you have any questions regarding this alert, please contact the Akin Gump Strauss Hauer & Feld LLP lawyer with whom you usually work or:

¹ “The 21st Century Cures Medical Software Provisions: Additional Clarity for Digital Health, but Also More Questions,” available at https://www.akingump.com/en/news-insights/the-21stst-century-cures-medical-software-provisions-additional.html#_edn16.

² FDA  issued a third guidance as well: “Software as a Medical Device: Clinical Evaluation,” available at https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM524904.pdf, which is not the focus of this analysis.  This final guidance furthers FDA’s commitment to advancing international harmonization of software policies, but, unlike a traditional guidance document, it does not provide actual recommendations to FDA staff regarding application of current regulatory requirements. 

³ FDA Draft Guidance for Industry, “Clinical and Patient Decision Support Software” (Dec. 2017), available at https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM587819.pdf

⁴ Id. at 6 n.1.

⁵ FDA Draft Guidance for Industry, “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act” (Dec. 2017), available at https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM587820.pdf (hereinafter, “Cures Changes Guidance”).

⁶ FDA Guidance, “General Wellness: Policy for Low Risk Devices” (July 2016), available at https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm429674.pdf.

⁷ FDA Guidance, “Mobile Medical Applications,” (Feb. 2015), available at https://www.fda.gov/downloads/MedicalDevices/.../UCM263366.pdf.

⁸ FDA Guidance, “Off-the-Shelf Software Use in Medical Devices” (Sept. 1999), available at https://www.fda.gov/downloads/MedicalDevices/.../ucm073779.pdf.

⁹ FDA Guidance, “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices” (Feb. 2015), available at https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm401996.pdf.

¹⁰ FDA notes, that for this example, the app would not be a device as long as its claims are “unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.”  Id. at 8.

¹¹ FDA’s recent rulemaking on intended use is relevant to this inquiry.  FDA issued a final rule in January 2017 revising its standard for “intended use,” using a “totality of the evidence” test (if the totality of the evidence shows that a manufacturer objectively intended to use a device for an off-label use), which includes circumstances surrounding product distribution, known effects on the product and/or the context in which the product is sold.  82 Fed. Reg. 2,193.

¹² Id. at 9-10.

¹³ See Const., Art. II, sec. 3 (The president must “take care that the laws be faithfully executed,” a requirement that extends to executive branch agencies, which includes FDA). FDA might have proposed this approach because the agency believes that electronic patient record functions that otherwise qualify for this exemption would not be medical devices under the FDCA, even if they lack ONC certification.

¹⁴ 76 Fed. Reg. 8637 (Feb. 15, 2011).

¹⁵ Cures Changes Guidance, supra, at 13.

¹⁶ FDA Guidance, Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices 6 (Feb. 2015), available at https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm401996.pdf.