Non-binding Guidance: Key Takeaways from FDA’s Final Guidance on Clinical Decision Support Software

This episode of Ropes & Gray’s podcast series Non-binding Guidance examines FDA’s final guidance on Clinical Decision Support (“CDS”) software, released in September, and its implications for the life sciences and health care industries. The final guidance represents a substantial change in FDA’s approach to CDS software regulation from the agency’s 2019 draft guidance and may prompt many software developers to reassess their CDS products in light of the new guidance. Join Ropes & Gray FDA regulatory partners Greg Levine and Kellie Combs and counsel Sarah Blankstein as they discuss FDA’s new CDS guidance and provide an overview of key changes, practical implications, and some of the challenges posed by the guidance.

---

Transcript:

Kellie Combs: Hi, everyone. I’m Kellie Combs, a partner in the life sciences regulatory compliance practice at Ropes & Gray, and co-lead of our Ropes & Gray Digital Health Initiative. Welcome to Non-binding Guidance, a podcast series focused on current trends in FDA regulatory law, as well as other important developments affecting the life sciences industry. I'm here today with my partner Greg Levine from the life sciences regulatory and compliance practice, also based in Washington, D.C., and Sarah Blankstein, a counsel in our practice who’s based in Boston. On today’s podcast, we’ll discuss FDA’s final guidance on Clinical Decision Support Software, or CDS, which FDA released on September 28.

For those who need a brief refresh—CDS software was exempted under the 21^st Century Cures Act from the statutory definition of medical device, and therefore, from FDA regulation so long as it meets four criteria:

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

To be sure, the practical implications of being exempt from the “medical device” definition are significant, as it effectively takes the software out of FDA’s jurisdiction—that means that FDA requirements like premarket approval or clearance, registration or listing, and other regulatory obligations would not apply.

Even though the statute lays out the four criteria that have to be considered when determining the regulatory status of CDS, this has really been an area rife with complexity. FDA released two draft versions of the CDS guidance in 2017 and 2019, and both of those were met with extensive commentary from industry prior to finalizing the guidance last month. Each iteration of the guidance has represented a substantial shift from the prior version, and this final guidance is no exception. We expect a number of changes in the guidance will be controversial and may prompt many software developers to reassess software in light of the new guidance.

Sarah, let’s start with you: Can you speak to some of the key changes from the 2019 final guidance that the industry should be aware of?

Sarah Blankstein: Happy to, Kellie. So, as you noted, the final guidance really is a major shift from the prior draft. FDA has substantially changed its interpretation of three of the four criteria that you mentioned to qualify as non-device CDS. Among other things, they abandoned the draft guidance’s proposed adoption of the risk-based categorization scheme for software as a medical device that was put out by the International Medical Device Regulators Forum (or IMDRF), and that IMDRF criteria had been a source of significant confusion in the 2019 draft.

The final guidance also shrinks the scope of the guidance by removing discussion of CDS software intended for patients or caregivers, and it also takes out the discussion of provider-directed CDS that don’t meet all four of the statutory criteria but may nonetheless qualify for FDA enforcement discretion. FDA now refers industry to other FDA guidance documents for analysis of patient-directed decision support tools.

Looking at the changes to FDA’s interpretation of the criteria for CDS to qualify as a non-device, the most notable shifts for industry are in the second, third and fourth criteria. And, taken on the whole, I would say these changes seem to broaden the scope of software FDA considers subject to its regulation as medical device software.

Kellie Combs: Great—thanks, Sarah, for that helpful overview. Can you give a little more detail on those changes?

Sarah Blankstein: Of course. To briefly touch on those changes: The second criterion—that’s the criterion that requires software be intended to display, analyze, or print medical information about a patient or other medical information—FDA has newly and narrowly interpreted that criterion to restrict it to information that is “well-understood and accepted,” such as information typically communicated in conversation between providers, peer-reviewed clinical studies, and clinical practice guidelines.

The third criterion—that’s the criterion that software is intended to support or provide recommendations to a health care provider about prevention, diagnosis, or treatment of disease—this criterion is one that FDA had previously interpreted relying on the IMDRF risk framework, that I had mentioned, and that analysis had rested in significant part on an unhelpful distinction between “informing” and “driving” a clinical decision. So, FDA has abandoned that approach in the final guidance, adopting a new interpretation, asserting, most notably, that software has to satisfy four conditions, including that it (1) not provide a specific preventive, diagnostic, or treatment output or directive, and that it (2) not be intended to support time-critical decision-making. So those two requirements are new in this final guidance.

FDA’s rationale for adopting those two exclusions turns on the concept of “automation bias.” Automation bias is the tendency to over-rely on an automated system. And according to FDA, this type of bias is more likely to occur if the software provides a single, specific output as opposed to a list of options or complete information for the HCP’s consideration. Similarly, FDA asserts that time-critical decision-making is going to result in more automation bias because the user doesn’t have sufficient time to adequately consider other information.

These two new exclusions for specific and time-critical recommendations seemingly could narrow the scope of CDS that FDA doesn’t consider to be a medical device, so this is an important change in the final guidance. And as an example of how it might narrow what qualifies as non-device CDS, based on the principle that software providing a “specific” output doesn’t satisfy Criterion 3, FDA asserts in the guidance that software that provides information that a specific patient “may exhibit signs” of a disease or condition, or identifies a risk probability or risk score for a specific disease or condition, would fail under the third criterion. Under the draft guidance, that type of software could have qualified as non-device CDS, at least under some circumstances.

And finally, just to touch on the fourth criterion, which FDA also revised substantially—that’s the criterion that requires the software to enable health care providers to independently review the basis for the software’s recommendations—here FDA responded to criticism of the draft guidance that had pointed out that the recommendations in the draft guidance for this criterion were vague and difficult to apply. So, in the final guidance, FDA does provide several more tangible recommendations—if burdensome—on satisfying this criterion.

Finally, like many of FDA’s software guidances, the CDS Guidance does contain a number of examples intended to illustrate FDA’s thinking, and some of these underscore the more controversial or problematic aspects of the final guidance.

Kellie, can you speak to some of the examples in the CDS Guidance that you think are particularly noteworthy?

Kellie Combs: Sure—thanks, Sarah. And I will state at the outset that there are lots and lots of examples in the guidance which I think are really helpful to consider as you’re thinking through whether your client’s software or other software you may be analyzing is subject to FDA regulation. But, Sarah, as you suggested, the examples do tee up some of the complexities, and in some cases, even some inconsistencies, in FDA’s line of thinking here. So, one of the more interesting examples from my perspective is one that really brings home the notion that FDA is narrowing the software that qualifies as non-device CDS, and that’s due to the reinterpretation of Criterion 3, which we talked about—and this relates to FDA’s interpretation to exclude algorithms that provide a single recommendation.

In one example, in the guidance, FDA describes software that identifies patients with a possible diagnosis of opioid addiction based on a variety of factors like medical information, family history, prescription patterns, and geographical data. According to FDA, this example does not meet Criterion 3 because it provides a specific diagnostic or treatment output or directive—therefore, this would be a regulated medical device.

Note, interestingly, FDA included the same exact example in its 2019 draft guidance with the added context that the algorithm inputs are not explained. And there, in 2019, FDA categorized it as device CDS only because it failed on the transparency criterion, Criterion 4. Now, this is an issue back then that could have been cured by providing the user with additional information, and the software would then have been considered non-device CDS.

Some of the other examples also underscore FDA issues with line drawing, when it interprets Criterion 3 to exclude software that provides a “specific output.” For example, the Agency describes software that recommends a prioritized list of FDA chemotherapy agents to an HCP based on the patient’s diagnosis and demographics from the medical record as non-device CDS. On the other hand, though, software that identifies a specific FDA-approved chemotherapy agent based on the patient’s medical record is categorized by FDA as a device, because it provides a specific treatment output or directive.

Now, practically speaking, it’s not clear how a prioritized list that identifies the best option is any different from an algorithm that provides only the best option, particularly if the algorithm meets Criterion 4 and explains clearly to the HCP the basis for the recommendation. Moreover, as a practical challenge, what if we have a case where there’s only one approved agent for a particular type of cancer or line of treatment. In that case, would FDA think that the software would run afoul of that criteria just by providing that single specific output?

Sarah Blankstein: Thanks, Kellie. You’ve given some interesting examples regarding Criterion 3, but what about Criterion 4? This is an area where I know many of our clients were really eager for more guidance from FDA.

Kellie Combs: Yes, and here, I think while we’re happy to have more clarity on this criterion, the examples do show how prescriptive and difficult the criterion may be to satisfy in practice.

So, looking at one example, FDA describes a software function that provides a prioritized list of FDA-authorized depression treatment options to an HCP. The intended use, HCP user, and patient population are clearly identified. The medical information from the patient’s record is clearly identified to the HCP to be able to understand what information is being considered. However, according to FDA, this software remains a device function because (1) it does not provide the user with the full report of the clinical studies being relied on, and (2) it doesn’t identify the studies that most closely matched the patient-specific diagnosis and demographics as well as other considerations, such as the warning/contraindications from the label.

This is a lot of information that has to be provided to satisfy Criterion 4 under FDA’s guidance. And problematically, much if not most CDS software currently on the market and analyzed under the previously-applicable 2019 draft guidance likely would not meet the high bar set in the final guidance.

Greg, I’d like to get some of your thoughts on the final guidance—and what are some of the key takeaways for you?

Greg Levine: Thanks, Kellie. First of all, you and Sarah have done a terrific job highlighting some of the key issues with this guidance. And I will say, this guidance is kind of a big deal. We’ve been waiting for this guidance for a long time—we’ve had several drafts, as you noted, and each time that there’s been a draft it’s changed in fairly significant ways. FDA first promised they were going to come out with this guidance in 2014, so I think we have a litany of Ropes & Gray client alerts over the years saying, “This guidance is coming.” And so, now we have this guidance in final form.

I think the consequences can be fairly significant, in that we have lots of software that has been developed and put on the market over the years, either before we had any guidance (in the total absence of guidance from FDA on CDS), or where we were looking at drafts or really trying to read the tea leaves on a lot of things about where the lines are, about what's regulated as a device and what's not regulated as a device as far as this kind of software.

Now, FDA has done a really good job in recent years in trying to bring some order to the chaos of software regulation in general—software as a medical device—and defining and setting out actual policies in writing about what's regulated and what's not regulated. And, of course, Congress stepped in with the Cures Act for certain types of software functions. The trend, in general, both from Congress and from the FDA, has been sort of de-regulatory. In other words, trying not to over-regulate; trying not to have FDA regulate software where the failure of the software or poor design of the software won't be really important or critical as a public health matter; and to try not to over-regulate to where you are inhibiting innovation unnecessarily.

Here, with this guidance, I do have some real concerns. A lot of it will be non-controversial, but many of the aspects that you two have pointed out, I think, are potentially problematic and might bring some relatively low-risk algorithms into the area of FDA oversight. It may be that FDA is reacting to Congress trying to narrow its legal authority. The FDA would always rather have broader authority, and then pick and choose when it uses that authority, versus admitting or conceding that its authority doesn't exist in certain respects—so, there might be some of that going on here.

But I do think there are some questions about whether some of this interpretation squares with the statute. For example, the criteria where it says that the "software should be intended to display, analyze, or print medical information," and FDA says that medical information has to be “well-understood and accepted." It’s really not clear that that's entirely consistent with the statute. The statute says "medical information”—it doesn't say "well-understood and accepted medical information.” Or the point that you were just talking about, Kellie, where the software provides a specific recommendation—if the basis for that recommendation is very clear and understandable to the health care provider, who can then assess it in support of making a health care decision, why is it that that should not be exempt from the statute? And is that really what Congress intended?

The other thing is that, because this is a guidance, the FDA doesn't really have to explain its reasoning in a lot of detail. They do give some of their thinking, but it's not like in the preamble to a regulation, where they would have to go through each comment and respond in sufficient detail. And so I think we have series of pronouncements here without a whole lot of analysis or justification behind it.

So, I think there is going to be some controversy on some of this. I think this leaves a number of software developers in a difficult position if they already have software on the market. They may need to reassess it, they may need to determine whether they're going to change their software, or whether they are going to keep it on the market as is. They could make a judgment that, "We actually think it meets the statutory criteria, and if FDA challenges us, we will fight them or dispute that at that point." But that's a risk, and not every software developer would want to take that risk.

For those who have products that they are developing that are not on the market yet, it would be a similar kind of analysis. "Do I now have to change it, or do I go to FDA? Do I submit a 513(g) request to FDA and ask FDA how they would choose to regulate my device, or not?" And that could be a make-or-break determination in some cases, because being an FDA-regulated device manufacturer is a big deal. It's not just the FDA has to review your software before it gets on the market, but it's all of the obligations, duties and requirements that you have to fulfill on an ongoing basis as a medical device manufacturer regulated by the FDA. So, these kinds of decisions and these kinds of differences can be very important. So, we'll see what happens from here.

I was hopeful that FDA had stated in its guidance agenda for 2022 that it was planning a draft guidance called "Risk Categorization for Software as a Medical Device: FDA Interpretation, Policy, and Considerations." And I was thinking that was a place where FDA might be able to show a little flexibility in some of these things. In other words, say that, just because something isn't excluded from the definition of a device by statute, that doesn't mean they will regulate it. They could still exercise enforcement discretion—they have some policies where they do that now, but maybe there's more room to do some of that.

Unfortunately, the FDA has now released their 2023 guidance agenda, and they pulled that draft guidance off, so that's not going to be forthcoming. And, instead, they said they're going to pursue further refinement of the framework through the IMDRF (the International Medical Device Regulators Forum), which in the past, their pronouncements have been at best confusing when you try to align them with the U.S. FDA regulatory regime. So, it seems to me like that was a missed opportunity, unfortunately, and I do think there’s going to be some difficult issues that software developers have to face, and possibly some challenges to the FDA's interpretation, as well.

Kellie Combs: Great—thanks, Greg. This is certainly an area to watch, and we will continue to monitor all of these developments. But for today, unfortunately, I think we're out of time. Thanks very much everyone for tuning in to our podcast, Non-binding Guidance, which is brought to you by attorneys in the life sciences regulatory and compliance practice at Ropes & Gray. For more information about our practice or other topics of interest to life sciences companies, please visit our FDA regulatory and www.ropesgray.com. You can also subscribe to this podcast, Non-binding Guidance, and other RopesTalk podcasts at Ropes & Gray's podcast newsroom on our website, or by searching for Ropes & Gray podcasts in Apple or Spotify. Thanks again for listening.