New Draft Policy on Clinical Decision Support Software Highlights FDA’s Release of Six New Digital Health Guidance Documents

Key Points:

• The FDA recently issued six guidance documents that further clarify the agency’s interpretation of the 21^stCentury Cures Act’s software exemptions.
• The revised draft guidance on CDS further elaborates on how to make CDS tools appropriately transparent for health care professionals such that they are not regulated as medical devices.
• The revised CDS draft guidance also introduces a risk-based framework for regulating CDS software that is a medical device, based on criteria adopted by the IMDRF.

  ---

Background

FDA recently released six software-related guidances, advancing the agency’s Digital Health Innovation Action Plan:¹ “Clinical Decision Support Software”² (revised Draft Guidance issued for comments); “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act”³ (Final Guidance); “Policy for Device Software Functions and Mobile Medical Applications”⁴ (Updated Final Guidance); “General Wellness: Policy for Low Risk Devices”⁵ (Updated Final Guidance); “Off-The-Shelf Software Use in Medical Devices”⁶ (Updated Final Guidance); and “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices”⁷ (Updated Final Guidance).

Together, the six guidances provide a variety of technical changes and clarifications to FDA’s interpretation of the 21^stCentury Cures Act (Cures) exemptions for certain software functions.  The revised draft guidance on clinical decision support (CDS) software offers significant clarifications on meeting the statutory CDS exemption and previews a risk-based framework for regulation of the full range of CDS-related software tools. Cures 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: administrative software; software to support a healthy lifestyle; electronic patient records; Medical Device Data Systems (MDDS) and Clinical Decision Support (CDS). Post-Cures, FDA issued several draft guidances to provide the agency’s interpretation of the scope of its regulatory authority and clarity on several aspects of the Cures exemptions. These five finalized guidances and the revised draft provide stakeholders with additional clarity on which software-based applications and features are within the scope of the Cures exemptions or will otherwise be subject to FDA enforcement discretion.

FDA plans to host a webinar on November 4, 2019 regarding the CDS draft guidance, and another webinar on November 14, 2019 on the other guidance documents. The revised CDS draft guidance will be open for comment until December 26, 2019. ⁸

Below, we analyze the CDS guidance in depth, and provide a brief summary of the noteworthy changes in the five additional guidance documents in the package.

Clinical Decision Support (Revised Draft Guidance Issued for Comments)

The CDS guidance is a revised draft guidance; the original draft was published in 2017. As we noted at that time,⁹ CDS has been a complicated category for FDA to address, and the statutory language for the CDS exemption¹⁰ is fairly complex.

Meeting the CDS Exemption Criteria

Under the Cures 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). The function cannot be “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 . . . ” to qualify as CDS. Additionally, an exempt CDS must have the following intended purposes:

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.”

The original draft guidance provided relatively limited discussion of what is required to satisfy the third, “independent review” prong. In this revised draft, FDA explains that the inquiry into whether the user can independently review the basis “asks whether the function is independent for the purpose of enabling the user to independently review the basis for the recommendation so that it is not the intent that [sic] user rely primarily on any such recommendation ….”¹¹ The developer should use “plain language … to describe the basis for a recommendation, regardless of the complexity of the software,” including for “descriptions of the logic or rationale used by an algorithm to render a recommendation.”¹² Furthermore, “[t]he sources supporting the recommendation or the sources underlying the basis for the recommendation should be identified and available to the intended user (e.g., clinical practice guidelines with the date or version, published literature, or information that has been communicated by the CDS developer to the intended user) and understandable by the intended user ….”¹³

This further elaboration on the “independent review” criterion could potentially pose challenges to some CDS tools. The concept of treating a health care professional’s (HCP’s) ability independently to review the basis for recommendation decision as a proxy for a developer’s intent that the HCP not “rely primarily” on the recommendation of the CDS tool is not new; it is reflected in the 2017 draft guidance. Moreover, the direction to use “plain language” to describe complex software algorithms seems appropriate; a complex explanation of software coding would presumably be of little value to an HCP. However, the expectation that the CDS—through the tool itself or adjunct to the CDS tool—identify and make “available” the sources for the recommendation seems to envision CDS tools that rely solely or primarily on public, widely available material such as published literature and clinical guidelines. More advanced CDS tools can also rely on more specialized case studies and patient data that are not readily available. This revised draft guidance raises questions about how FDA will evaluate those types of tools.

CDS That Does Not Satisfy the Cures Exemption: Introduction of IMDRF Framework

In the original draft guidance, FDA focused specifically on the Cures exemption and did not explicitly address its plans for a risk-based approach to regulating CDS more broadly. At that time, the agency also did not address the applicability of the framework adopted by the International Medical Device Regulators Forum (IMDRF) for software as a medical device (SAMD), which the FDA had endorsed but which has not been formally promulgated within U.S. regulations.¹⁴ In particular, the original draft guidance did not indicate whether there were any types of CDS tools that fell outside of the Cures exemption for which the agency would continue to exercise enforcement discretion, (with the exception of the proposed enforcement discretion for what the agency referred to as “patient decision support” (PDS) tools).

The revised draft addresses these topics directly, explaining that FDA plans to focus its regulatory oversight “on CDS functions that are intended to help health care professionals and patients inform their clinical management for serious or critical conditions and that are not intended for health care professionals to independently evaluate the basis of the software’s recommendations.”¹⁵ Thus, the proposed policy of enforcement discretion is retained for certain PDS tools, and is extended to certain low-risk CDS tools based on application of the IMDRF framework.

The revised draft guidance uses the four criteria of the Cures CDS exemption to determine if a software function is “Device CDS” or “Non-Device CDS.” “CDS” is used as a catch-all for functions that are either Device CDS or Non-Device CDS. In accordance with IMDRF, FDA explains that the risk of a Device CDS Function is based partly on the significance of information the software function provides. A software function can: (1) “inform” clinical management; (2) “drive clinical management” or (3) be used for “treating/diagnosing.”

The risk of a Device CDS function is also based on the state of the health care situation or condition: (1) non-serious; (2) serious or (3) critical.

• Non-serious situations or conditions are those in which “accurate diagnosis and treatment is important but not critical for interventions to mitigate long term irreversible consequences on an individual patient’s health condition or public health.” These may include short-lived disease processes, or temporary injury or impairment not requiring professional medical intervention (such as mild to moderate seasonal allergy symptoms).
• Serious situations or conditions are those in which “accurate diagnosis or treatment is of vital importance to avoid unnecessary interventions (e.g., biopsy) or timely interventions are important to mitigate long term irreversible consequences on an individual patient’s health condition or public health.” These may include recurrent disease processes that have a substantial impact on day-to-day functioning, or disease processes that have potential to be substantially disabling, for example.
• Critical situations or conditions are those in which “accurate and/or timely diagnosis or treatment action is vital to avoid death, long-term disability or other serious deterioration of health of an individual patient or to mitigating impact to public health.” These may include circumstances such as paralysis, or impact to public health like the Ebola virus, or fragile intended target populations like pediatrics or high-risk populations for a particular disease or condition.¹⁶

Pursuant to the risk categorizations above, FDA does not intend to enforce device requirements applicable to two types of low-risk Device CDS:

1. Inform x Non-Serious for Patients/Caregivers: CDS software functions intended for the purpose of supporting or providing recommendations to patients or caregivers—not HCPs—to prevent, diagnose, or treat a disease or condition, when the CDS function is intended for the patient or caregiver to be able to independently review the basis for its information. Examples of such software provided by FDA include:
   1. Software that provides information about the use of a prescription drug that is consistent with the FDA-required labeling and the patient’s prescription, which that does not recommend changes in dose or discontinuation that the HCP does not oversee.
   2. Software that assists a patient in identifying over-the-counter cold or allergy medications to consider purchasing based on the patient’s symptoms (e.g., a prioritized list based on symptoms).
2. Inform x Non-Serious for HCPs: Functions intended for HCPs that do not meet criterion (4) of the Cures exemption because they are not intended for the HCP to be able to independently review the basis for its recommendation, and therefore the HCP would rely primarily on it. Examples of such software provided by FDA include:
   1. Machine-learning algorithm (with unexplained logic and inputs) that trends and classifies patient-specific data such as blood test results and weight to alert HCPs to potential triggers that may be indicative of cholesterol management issues.
   2. Software that provides recommendations of potential allergens and common cold symptoms based on location-specific electronic health records (EHRs), environmental conditions, and patient-reported outcomes, intended to provide the HCP with diagnosis options (such as seasonal allergic rhinitis, as opposed to the common cold).

The higher-risk functions on which FDA intends to focus its regulatory oversight are “Device CDS functions intended for patients, caregivers, or HCPs that inform clinical management for serious and critical health care situations or conditions.”¹⁷ This table summarizes FDA’s proposed regulatory policy.¹⁸

As an example of high-risk Device CDS function subject to oversight, FDA points out a CDS tool that identifies hospitalized, type 1 diabetic patients at heightened risk for postoperative cardiovascular events, and which does not explain why that software made that identification to the HCP. Here, if the CDS provides inaccurate information (such as failing to identify a high risk patient), this could lead to inappropriate treatment and significant patient harm. Other examples include:

• Inform HCP x Serious: Machine-learning algorithm, for which the logic and inputs are not explained, that categorizes likely symptoms of seasonal influenza and for each flu season based on location and current EHRs of patients diagnosed or suspected to have influenza to assist HCPs in differentiating between common flu symptoms and other illnesses (such as the common cold) in a particular season.
• Inform HCP x Critical: Software, for which the inputs are not explained, that identifies who may identify signs of opioid addiction (based on patient-specific data, family history, EHR data, prescription patterns and geographical data).
• Inform Patient x Serious: Patient-facing software that aggregates data from continuous glucose monitoring, activity trackers and food logs to help insulin-dependent type 2 diabetic patients identify potential lifestyle triggers for hypoglycemic events and recommends corrective treatment options, such as insulin dosage timing.
• Inform Patient x Non-Serious: Patient-facing software with a questionnaire to assess stress and anxiety (prior to diagnosis of general anxiety disorder) that recommends treatment options based on assessment output.

The introduction of the IMDRF risk framework for SAMD into this revised draft guidance extends the reach of this policy beyond Cures-exempt CDS to a broader framework for evaluating decision support tools for HCPs and patients/caregivers across the full spectrum of risk. This introduces important new terminology and criteria for evaluating risk that are not found in the FDCA and are novel in U.S. medical device software policy. FDA will likely need to provide more clarity than this guidance as to how these criteria will be applied. Another important consideration for the proposed adoption of the IMDRF framework for CDS-related SAMD is that, while FDA has acceded to requests to identify a band of enforcement discretion for software functions that do not fit within the contours of the Cures CDS exemption, the proposed band of such enforcement discretion appears to be rather narrow. For example, the types of CDS tools that may not meet the “independent review” criterion may provide the types of more sophisticated analyses that would support recommendations for serious or critical health care conditions. If this is the case, then CDS developers have even more incentive to continue to track FDA’s efforts to develop its pre-certification program for SAMD and its exploration of the appropriate regulatory oversight for artificial intelligence/machine learning tools.

The Revised CDS draft guidance will be open for comment until December 26, 2019.

Other Software Guidance Documents

FDA issued also updated five other software-related guidance documents, either as final versions or updated final versions. These guidances are largely consistent with their predecessor versions, with some notable clarifications and technical changes. We summarize these guidances below.

Mobile Medical Applications (Updated Final Guidance)

In updating previously issued final guidance on mobile medical applications (apps), FDA retains its approach to mobile medical apps but expands the official reach of the guidance. Specifically, the previous version of the guidance only purported to apply to mobile apps, and this version applies to software apps intended for use on mobile platforms or on general-purpose computing platforms. FDA explains that the policy applies to the software function, regardless of the platform, which is consistent with FDA’s overall approach to digital health tools.¹⁹ This is essentially a change in nomenclature; the agency had already acknowledged that it treats software functions the same whether they run on an app or another platform.

 FDA explains that it will continue to focus its regulatory oversight on the subset of software functions that are medical devices and whose functionality could pose a risk to a patient’s safety if the device were to not function as intended.²⁰ Consistent with the previous version of the guidance, FDA identifies the following software functions that are the focus of FDA’s regulatory oversight:

• Software functions that are an extension of one or more medical devices by connecting such device(s) for purposes of controlling the device or analyzing medical device data.
• Software functions (typically, mobile apps) that 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.
• Software functions that become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis or treatment recommendations.

The updated guidance continues to provide examples of software functions for which FDA intends to exercise enforcement discretion, those that do not meet the definition of a medical device, and those for which it intends to focus its regulatory oversight.²¹ To reflect changes that Section 3060 of Cures made to the device definition, FDA moved certain examples of software functions from the enforcement discretion category to the non-device category. For example, FDA previously categorized mobile apps that are intended for individuals to log, record, track, evaluate or make decisions or behavioral suggestions related to developing or maintaining general fitness, health or wellness (e.g., tools that promote healthy eating) as medical devices that would be subject to FDA’s enforcement discretion. In this version, FDA lists software functions with the same intended use as examples that are not medical devices.²²

Medical Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices (“MDDS”) (Updated Final Guidance)

In the updated final guidance on MDDS, FDA acknowledges that the existing definition of MDDS under 21 C.F.R. § 880.6310 is inconsistent with the exemption in Cures for software functions that overlap substantially with the MDDS concept (i.e., the transfer, storage, display, or conversion of medical device data).²³ Under the current version of the regulation, MDDS includes both software and hardware, and Cures exempted qualifying MDDS software functions from the definition of “device.” FDA explains that MDDS hardware are still devices under the FDCA, but that it will continue to exercise enforcement discretion for these devices, as it has since initially announcing the policy in 2015.²⁴ In particular, this updated final guidance attempts to reconcile the regulatory definition of MDDS, which does not allow for “active patient monitoring,” and the Cures exemption, which does not contain the same limitation explicitly. FDA indicates that while exempt MDDS software may potentially be used for active patient monitoring, software to “generate alarms or alerts or prioritize patient-related information on multi-patient displays, which are typically used for active patient monitoring, are considered device software functions because these functions involve analysis or interpretation of” lab data or device data.

FDA also introduces new terminology. The new guidance terms MDDS software as “non-device-MDDS” and MDDS hardware as “device-MDDS,”²⁵ similar to the nomenclature in the CDS guidance. Consistent with Cures, FDA notes that if a product that contains both non-device-MDDS and device-MDDS (“a multiple function device product”), FDA does not intend to enforce FDCA requirements for either part at this time. However, FDA intends to provide recommendations on the regulation of multiple function device products in a separate guidance document.²⁶

General Wellness: Policy for Low Risk Devices (Updated Final Guidance)

FDA originally finalized a policy of enforcement discretion for “general wellness” products in 2016. Cures then exempted from the definition of “device” those software functions intended “for maintaining or encouraging a healthy lifestyle” and that are “unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease on condition.”²⁷ However, the Cures exemption only applies to software, not hardware. Under the updated version of the guidance, FDA would continue to exercise enforcement discretion with respect to hardware devices that meet FDA’s definition of a general wellness product.²⁸ Unfortunately, the agency does not take the opportunity to clarify which wellness functions performed by hardware are low-risk device functions covered by enforcement discretion, and which wellness functions performed by hardware simply do not meet the device definition. Furthermore, it stands to reason that hardware with an intended use solely to support an exempt software wellness function would not constitute a device, given that its only intended use is to support a non-device intended use.

Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act (Final Guidance)

In this updated version of the guidance, FDA provided further legal rationale for its decision not to enforce the requirement imposed by Cures that certain electronic health records be certified by the Office of the National Coordinator (ONC) for Health Information Technology to qualify for the exemption from the definition of a “device.”²⁹ Whereas the draft guidance simply asserted the agency’s intention not to enforce the ONC certification requirement, the final guidance explains that the types of software functions described by the Cures exemption for electronic health records do not meet the existing FDCA definition of “device” in any event. FDA reiterated that it plans to issue a separate guidance document to explain its approach to health IT systems that contain both non-device functions and device functions.³⁰

Off-the-Shelf Software Use in Medical Devices (Updated Final Guidance)

FDA merely updates its final guidance from 1999 to include the medical device definition exemption in Cures, and does not introduce new policy with respect to off-the-shelf software.

Contact Information

If you have any questions concerning this alert, please contact:

¹ U.S. Food and Drug Administration, Digital Health Action Plan (2017), available at https://www.fda.gov/media/106331/download.

² Draft Guidance, Clinical Decision Support Software (Sept. 2019), https://www.fda.gov/media/109618/download.

³ Final Guidance, Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act (Sept. 2019), https://www.fda.gov/media/109622/download [hereinafter “Revised Cures Changes Guidance”].

⁴ Final Guidance, Policy for Device Software Functions and Mobile Medical Applications (Sept. 2019), https://www.fda.gov/media/80958/download [hereinafter “Revised Mobile Medical Apps Guidance”].

⁵ Final Guidance, General Wellness: Policy for Low Risk Devices (Sept. 2019), https://www.fda.gov/media/90652/download [hereinafter “Revised General Wellness Guidance”].

⁶ Final Guidance, Off-The-Shelf Software Use in Medical Devices (Sept. 2019), https://www.fda.gov/media/71794/download [hereinafter “Revised Off-The-Shelf Software Guidance”].

⁷ Final Guidance, Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices (Sept. 2019), https://www.fda.gov/media/88572/download [hereinafter “Revised MDDS Guidance”].

⁸ Stakeholders may submit comments any time on any guidance, even if they are final. See 21 C.F.R. § 10.115(g)(5).

⁹ https://www.akingump.com/en/news-insights/new-fda-guidance-clarifies-exemptions-for-digital-health.html.

¹⁰ Federal Food, Drug, and Cosmetic Act (FDCA) section 520(o)(1)(E) (as added by Cures).

¹¹ Revised CDS Guidance at 8.

¹² Id. at 12.

₁₃ Id.

₁₄ IMDRF, “Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations (Sept. 2014), http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf.

₁₅ Statement from Principal Deputy Commissioner Amy Abernethy, MD, PhD., Statement on new steps to advance digital health policies that encourage innovation and enable efficient and modern regulatory oversight (Sept. 26, 2019).

₁₆ Revised CDS Guidance at 14-16.

₁₇Id. at 17

₁₈Id. at tbl. 3.

₁₉ Revised Mobile Medical Apps Guidance at 1.

₂₀ Id. at 10.

₂₁ Appendix A lists examples of software functions that are not medical devices; Appendix B lists examples of software functions for which FDA intends to exercise enforcement discretion; and Appendix C lists examples of software functions for which FDA intends to focus its regulatory oversight.

₂₂ Id. at 18.

₂₃ Revised MDDS Guidance at 2.

₂₄ Id.

₂₅ Id.

₂₆ Id. at 6.

₂₇ FDCA section 520(o)(1)(B) (as added by Cures).

₂₈ Revised General Wellness Guidance at 3-5.

₂₉ Revised Cures Changes Guidance at 8.

₃₀ Id.