FDA Overhauls its Draft Guidance on Clinical Decision Support (“CDS”) Software

On September 27, 2019, the U.S. Food and Drug Administration (“FDA”) issued a revised draft guidance entitled “Clinical Decision Support Software” (the “CDS Draft Guidance”), describing the agency’s proposed approach to regulating CDS software. The CDS Draft Guidance revises a previously issued draft guidance on the same subject released by FDA on December 8, 2017.

In its public statement upon release of the CDS Draft Guidance, FDA explained that the revisions to the guidance are intended to address the many stakeholder comments it received on the original draft, particularly relating to the draft’s failure to consider the potential risk of patient harm if a CDS software product were to malfunction. Consequently, the most notable change from the 2017 draft guidance was to incorporate key elements of the software risk categorization framework FDA had helped develop through the International Medical Device Regulatory Forum in 2014 (“IMDRF Framework”). FDA asserts that the approach set forth in the CDS Draft Guidance will strike the right balance between ensuring patient safety and promoting innovation. We expect that some, however, will criticize the draft guidance as missing the mark: providing additional regulatory clarity and latitude for certain low-risk CDS software products, but creating additional ambiguity and uncertainty for others.

21^st Century Cures Act and FDA’s Initial CDS Draft Guidance

As outlined in a previous Ropes & Gray Alert summarizing the 2017 CDS draft guidance, Section 3060 of the 21^st Century Cures Act (Section 520(o) of the Federal Food, Drug, and Cosmetic Act (“FDCA”)) removed certain software functions from the definition of “device.” One category of software no longer considered a device under FDCA § 520(o)(1)(E) is software 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 an HCP about prevention, diagnosis, or treatment of a disease or condition; and
4. Is intended to enable HCPs to independently review the basis for the software’s recommendations so HCPs do not primarily rely on the recommendations when making a clinical diagnosis or treatment decision.

In the 2017 draft guidance, FDA proposed to interpret these provisions such that a software function meeting the first three criteria would be considered CDS, but would only be exempt from FDA regulatory oversight if it also met the fourth criterion. It was FDA’s emphasis on this fourth criterion that elicited the bulk of industry criticism. In particular, FDA made the transparency of a software function the key determinant in whether a CDS product would be considered a regulated medical device, regardless of the product’s specific risk profile. Under its previous proposed framework, for example, regardless of whether a software function was intended to provide clinical recommendations for a self-limiting disease like the common cold or a life-threatening disease like cancer, FDA would have decided whether to regulate the software based entirely on whether the software’s inputs and rationale were sufficiently transparent to the user. The risk to the user or patient of the software providing unreliable information would not have been the determining factor.

Partial Incorporation of the IMDRF Risk Categories

In response to comments submitted on the 2017 draft guidance, FDA agreed to incorporate risk-based principles outlined in the IMDRF Framework, a document established to promote international harmonization of regulation of Software as a Medical Device (“SaMD”). The IMDRF Framework describes two major factors for the risk categorization of a SaMD (CDS is one type of SaMD):

1. The significance of information provided by a SaMD to the health care decision (i.e., whether the information is intended to “inform” clinical management, “drive” clinical management, or “treat or diagnose” a disease or condition), and
2. The state of the health care situation or condition (i.e., whether the situation or condition is non-serious, serious, or critical). 

These two factors are combined to create a matrix of risk profiles for SaMD from “low impact” (I) to “very high impact” (IV). 

State of Healthcare situation or condition	Significance of information provided by SaMD to healthcare decision
	Treat or Diagnose	Drive clinical management	Inform clinical management
Critical	IV	III	II
Serious	III	II	I
Non-serious	II	I	I

 
FDA has proposed to incorporate this framework into the newly released CDS Draft Guidance in two ways. First, FDA has evaluated the third statutory criterion from the 21^st Century Cures Act (requiring that the software be intended to “support or provide recommendations to” an HCP about prevention, diagnosis, or treatment of a disease or condition) by reference to the “significance of information” factor from the IMDRF Framework. Specifically, FDA states that only SaMD functions that “inform clinical management” meet the definition of a CDS, but functions that either “drive clinical management” or “treat or diagnose” go beyond the statutory criterion that a CDS “support or provide recommendations to an HCP.” This proposed interpretation is significant because it would mean that SaMD functions that do more than “inform” clinical management, at least some of which might have been wholly exempt from the definition of a device under the 2017 draft guidance if sufficiently transparent, would no longer be exempt from the definition of device nor eligible for enforcement discretion. This interpretation is likely to elicit negative comment, as it is far from clear that devices that “aid” or “guide” clinical decision-making (which is how the IMDRF Framework defines the term “drive clinical management”) can be viewed as categorically distinct from devices that “support or provide recommendations” for clinical decision-making (the statutory language). In other words, whereas some software products that “aid” or “guide” clinical decision-making conceivably might do more than “support or provide recommendations” for clinical decision-making, it is not clear how FDA has concluded that all such software products must go beyond what Congress intended by the phrase “support or provide recommendations.” It is also not clear how, if at all, FDA is taking into consideration that software functions that “drive” clinical management presumably are not intended to “trigger an immediate or near-term action,” according to the IMDRF Framework’s criteria.

The second way in which FDA incorporated the IMDRF Framework into its revised draft guidance was to address some commenters’ requests for enforcement discretion for “low impact” CDS functions that are not statutorily exempt from the definition of device because they do not meet the fourth prong of the statutory test, dealing with transparency. As depicted in the table included above, this would include CDS functions that:

1. Provide information to drive clinical management of a disease in a non-serious situation or condition;
2. Provide information to inform clinical management for a disease or condition in a serious situation or condition; and
3. Provide information to inform clinical management for a disease or condition in a non-serious situation or condition.

Although FDA declined to extend enforcement discretion to cover all of these categories, the draft guidance proposes to do so for category 3. As noted above, the CDS Draft Guidance considers software in category 1 not to qualify as CDS, because it is used to drive clinical management. The CDS Draft Guidance does not mention software in category 2 at all or explain its rationale for considering such CDS to be of “higher risk” than the other devices categorized by the IMDRF Framework as “low impact.”

The CDS Draft Guidance provides the following examples of CDS for which FDA will now exercise enforcement discretion because, although they are not sufficiently transparent to be exempt from the definition of device, they are intended to “inform clinical management” for “non-serious situations or conditions”:

1. Software that provides recommendations of potential allergens and common cold symptoms based on location-specific electronic health records, environmental conditions, and patient-reported outcomes to provide the HCP with options for different diagnoses (e.g., seasonal allergic rhinitis vs. common cold).
2. Machine-learning algorithm, for which the logic and inputs are not explained, that trends and classifies patient-specific data (e.g., blood test results, weight) to alert HCPs to potential triggers that may be indicative of cholesterol management issues.
3. Software intended for HCPs, where the basis for the recommendation is not disclosed to the user, to analyze patient information to determine which over-the-counter (OTC) allergy drug class is likely to be most effective in alleviating the patient’s seasonal allergies.

The CDS Draft Guidance also provides examples of software functions that FDA intends to regulate because, although they meet the first three criteria of the statutory CDS definition, they do not meet the fourth criterion and they are intended to “inform clinical management” for “serious or critical situations or conditions.” These examples include machine learning algorithms, for which the logic and inputs are not explained, (i) that identify hospitalized, type I diabetes patients at increased risk for postoperative cardiovascular events or (ii) that categorize likely symptoms of seasonal influenza for each season based on location and current electronic health records of patients diagnosed or suspected to have influenza to assist HCPs in differentiating between common flu symptoms and other illnesses. Likewise, FDA says that it intends to regulate software, for which the inputs are not explained, that identifies patients who may exhibit signs of opioid addiction based on patient-specific data, family history, electronic health records data, prescription patterns, and geographical data.

Other Changes

While the most significant change to the CDS Draft Guidance is the incorporation of the risk-based framework described above, FDA did make some additional changes of note to the draft guidance.

Transparency Criterion. FDA appears to have softened its interpretation of the fourth statutory criterion regarding the “transparency” of a CDS to be exempt from the definition of “device.” In the 2017 draft guidance, FDA interpreted the requirement that HCPs be able to “independently review the basis of” and “not primarily rely” on recommendations from a CDS as a requirement that an HCP be able to “reach the same recommendation . . . without relying primarily on the software function.” This interpretation was viewed by some as limiting exemption of a CDS to those software functions that perform simple calculations that could be perfectly replicated by HCPs. In contrast, the revised CDS Draft Guidance focuses on whether an HCP could theoretically “understand” or “evaluate” the basis for a recommendation (i.e., whether an algorithm’s logic and inputs are adequately described and available to the HCP). This shift hews more closely to the statutory language and has potentially powerful implications for complex software like machine learning algorithms.

Patient Decision Support Software. Another notable change to the draft guidance is that FDA collapsed its discussion of “Patient Decision Support” software—which it had previously considered separately from CDS in the 2017 draft guidance—into its more general CDS analysis. Under the 2017 draft guidance, FDA created a separate category of software that operated like a CDS (i.e., met the first three statutory criteria), but provided recommendations directly to patients or caregivers rather than HCPs. Because the third criterion in the statute explicitly refers to HCPs, FDA stated that patient/caregiver-directed software operating in this manner could never be exempt from the definition of “device.” Instead, FDA explained that it would exercise enforcement discretion over software products that otherwise met all four statutory criteria, but were directed toward patients or caregivers. The CDS Draft Guidance continues to preserve this distinction in effect, but now refers to such software as one subset of “device CDS.”

Like HCP-directed CDS, the revised CDS Draft Guidance also applies the principles of the IMDRF Framework to patient/caregiver-directed CDS. However, the effect for patient/caregiver-directed CDS is to narrow the enforcement discretion that was available under the 2017 draft guidance. The CDS Draft Guidance maintains the requirement from the 2017 guidance that patient/caregiver-directed CDS meet the fourth criterion of transparency (i.e., be intended to permit the patient to independently evaluate the basis for the software’s recommendations) to receive enforcement discretion. The CDS Draft Guidance proposes to further narrow the types of software functions that would have been eligible for enforcement discretion, though, by adding the requirements that the software be intended to “inform clinical management” for “non-serious health care situations or conditions.” Thus, for example, the following devices described in the CDS Draft Guidance would previously have been eligible for enforcement discretion if sufficiently transparent but now would be subject to FDA oversight because they focus on a serious condition:

• 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 (e.g., timing of insulin dosing).
• A software function that provides recommendations to caregivers of pediatric patients with cystic fibrosis by aggregating information on when they should bring such children to the emergency room, based on patient-specific symptoms and care guidelines.

Conclusion

The CDS Draft Guidance marks a significant change in FDA’s thinking about how to regulate CDS software products. That FDA saw the need to re-issue the original draft guidance as yet another draft for public comment reflects FDA’s recognition that it has substantially altered its thinking. In particular, the inclusion of a risk-based enforcement framework for CDS is a major shift in thinking that arguably aligns better both with Congressional intent and the regulatory principles FDA itself has espoused in the past. On the other hand, the CDS Draft Guidance may be viewed by some as a “half-loaf” compromise under which FDA would continue to regulate a wide variety of CDS functions that, under the IMDRF Framework criteria, would appear to be “low impact.”

Industry stakeholders have the opportunity to submit public comments to the revised draft guidance by December 26, 2019. FDA is also hosting a webinar on November 4, 2019 to discuss and answer questions about the CDS Draft Guidance. 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.