In December 2016, Congress enacted the 21st Century Cures Act that included section 3060 addressing FDA regulation of software.?Among other things, that section exempted from FDA regulation clinical decision support software so long as the healthcare professional user can “independently review the basis for the recommendations that the software presents so that it is not the intent that the healthcare professional rely primarily on any such recommendation to make a clinical diagnosis or treatment decision regarding an individual patient.”?In a final guidance document FDA issued September 27, 2022 on Clinical Decision Support Software, FDA wants to override that congressional statute and reclaim jurisdiction over software that Congress declared is unregulated.
FDA seems to be under the mistaken impression that it can add to the language of the statute in ways that constrain the exemptions that Congress intended.?Here are some examples:
- The statute says that CDS developers can produce unregulated software that analyzes “medical information about a patient.” ?FDA interprets those five words to mean “the type of information that normally is, and generally can be, communicated between HCPs in a clinical conversation or between HCPs and patients in the context of a clinical decision, meaning that the relevance of the information to the clinical decision being made is well understood and accepted.”?Where on earth in those five statutory words does FDA glean that interpretation??Congress did not so limit this exemption as to include only information that is commonly discussed.?To interpret it this way is to severely tie the hands of algorithm developers.?Machine learning developers routinely include other information adjacent to classical diagnostic information to improve accuracy.?The statute in no way says that the information must be limited to that which we already know is relevant.
- Following that language, the statute says that CDS developers can develop software that analyzes “other medical information.”?In normal English language, that is open-ended, and even expands the idea of what kind of information can be used as the basis for algorithm development.?Yet FDA takes it in the complete opposite direction, declaring that those are words somehow word of limitation, words that mean the information must be from peer-reviewed clinical studies, clinical practice guidelines or “similarly independent and verified and validated as accurate, reliable, not omitting material information and supported by evidence.”?Where in the heck did that come from in the statutory language??
- The statute says that software is exempt if, among other things it is “intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis, or treatment of a disease or condition.”?FDA interprets those words as meaning that the software output cannot be intended to “direct” healthcare professionals what to do.?Apparently, FDA thinks that mere software can “direct” doctors what to do, as if the doctor then has no choice.?FDA amplifies on this to say that in determining whether the software directs a healthcare professional what to do, the agency will look at the level of software automation and the time critical nature of the healthcare professional’s decision-making. ?The agency argues that automation bias, or the propensity of humans to over-rely on a suggestion from an automated system, will lead unthinking doctors to do whatever the software says. ?As an example, FDA says that it will regulate software that provides “information that a specific patient ‘may exhibit signs’ of a disease or condition or identify the risk probability or risk score for particular disease or condition.” ?Really, that necessarily means that the doctor will unthinkingly reach the same conclusion??None of this has any basis whatsoever in the statutory language.?This is FDA rebelling against Congress to limit what Congress has done.??According to the statutory language, if the software produces a “recommendation,” the software will be exempt if it meets the other elements of the statutory provision.?The statute does not include any words of limitation that the recommendation must somehow be mealymouthed or it will not be exempt. ?FDA is adding words not found in the statute.?
- As already explained, FDA interprets that same statutory language from paragraph three to also exclude software “intended to support time-critical decision-making.”?Again, that language is nowhere found in the statute.?It’s revealing to me that FDA raises it in connection with the definition of a “recommendation.”?Frankly, I could understand if the timing aspect were raised in the language from criterion 4 regarding whether a person can independently review the basis for the recommendation.?But FDA didn’t want to deal with the issue there, because with that criterion there would be a question of fact as to whether there was, in a given instance, enough time to review the basis for the recommendation.?Instead, FDA wanted to raise this issue in connection with the definition of a “recommendation” to categorically exclude software used in time-critical decision-making, regardless of whether the user in fact has adequate time to understand what the software is doing.?FDA is without statutory basis in saying that somehow the time critical element is part of the definition of what constitutes a “recommendation” and thus an absolute bar to exempting the software.
FDA does not get to add words to a statute.?This is particular true with statutory language that exempts activity from agency oversight.?Congress specified the conditions for exemption, and the agency frankly cannot add to or subtract from those conditions.?If a word is legitimately ambiguous, the agency can define the word in harmony with its typical meaning.?But that’s not what the agency has done here.?The agency has sought to add new concepts to the statutory language and thereby restrict what devices can be exempt.
FDA did all this in response to comments on the 2019 draft that the agency’s imposition of a risk-based framework for deciding what software was to be regulated violated the law.?Having realized that the agency couldn’t defend its interpretation in that regard, the agency shifted approaches and came up with this entirely new attack on the statute.?And then the agency went right to final guidance with it.?As a reminder, the 2019 draft was itself a reproposal from a 2017 draft that did not include any of these new features or even the risk framework that FDA added in 2019.?The agency has spent six years trying to figure out a way to add what is not in the statute to reduce the number of exempt products.
In 35 years of practicing food and drug law, never have I seen a guidance document so radically changed from proposed to final as this one without involving a reproposal.?As one small data point, what the agency covered on pages 11-12 in the 2019 draft guidance, is now pages 10 through 15 and entirely different. FDA is desperately trying to draw a distinction between software that is too self-confident in its recommendations (Dr., the diagnosis is X), versus software that is more tentative in its recommendation, (Dr., the diagnosis is probably X, but might also be something else.)?But that whole line of argument is a new addition to the draft guidance.?It replaces the discussion about risk in the proposed guidance previously imported from the International Medical Device Regulators Forum, that has now been deleted from the document.
The purpose of this CDS guidance document is to define the parameters of what software is exempt from FDA regulation.?Consequently, it’s a guidance aimed at supporting FDA enforcement in the form of warning letters and other enforcement letters.?Unfortunately, a guidance document and even warning letters are not viewed typically as a final agency action, and therefore cannot be challenged in court.?To press against this interpretation, a company would have to wait until it’s in the throes of an enforcement action requiring compliance before objecting in court to the agency’s interpretation.
I wish I could tell you that you could just ignore the FDA guidance because it violates the law.?But you would ignore FDA at your own peril.?It really doesn’t matter what some private lawyer thinks.?FDA will likely start acting consistent with this final guidance, and so ignoring it would bring substantial regulatory enforcement risk.?
Further, considering that FDA has been pondering this for six years and has proceeded with the final draft, there’s no evidence that FDA leadership is open-minded to hearing about the ways in which this document falls short and violates the law.
Thus, in practical terms, the industry is relegated to raising concerns with members of Congress, as it is a congressional statute that FDA is ignoring.?It would be my hope that industry could encourage members of Congress to investigate what FDA is doing here to override the statute, perhaps through a congressional hearing.
We live in interesting times.?Having waited six years since the statute was enacted, this final guidance is truly a disaster for the clinical decision support industry, and the healthcare professionals and ultimately the patients who would benefit from expanded use of these CDS software programs.
Experienced Medical Device Global Regulations and Standards Consultant, Strategist and Change Leader - Principal and Founder, Elisabeth George Consulting LLC
2 年Great analysis - looking forward to digesting it in more depth and understanding the FDA's perception and Industry's perception on how to implement.
Linkedin Top Voice| Life Science Lawyer | Emily Whitehead Foundation Board Member | Entrepreneur | Drexel Univ. Adjunct Prof. | DarshanTalks podcast host | Author, and Speaker
2 年Any interest in discussing this on a podcast?
Engineer | Radiologist | Healthcare AI Deployment and Evaluation | Builder
2 年This seems like a very narrow interpretation of the Act and the Final Guidance. The Act provides leeway for the Secretary to post Final Guidances based on its own rationale / evidence. While arguments may be technically correct (not my expertise), the intent of the Act and Guidance must be to keep patients safe (with the minimum required oversight). As a clinician actively working on safe and equitable deployment of AI tools, the guidance seems like a very reasonable approach to regulation to keep patients safe.
Population Health and Data Science Lead; Physician; Intrapreneur at DukeHealth
2 年Bradley, one more question (after many more readings). What's your take on how this guidance will treat NLP and unstructured text? Is text a signal/pattern or not? The guidance seems very clear on imaging and continuous vital sign and blood value monitoring, but doesn't say much (if anything) about text.
??CMO Medical Device Advisor ??Commercialization GTM Expert ??Future Proof Market Adoption Workshop ??Message Engineer for Medtech Host ??Speaker, Writer, Researcher
2 年Thank you Brad for dissecting this and connecting the dots to previous proposed guidances, as well as advising that the path forward is to engage Congress, while noting caution in the short-term: "Consequently, it’s a guidance aimed at supporting FDA enforcement in the form of warning letters and other enforcement letters. Unfortunately, a guidance document and even warning letters are not viewed typically as a final agency action, and therefore cannot be challenged in court. To press against this interpretation, a company would have to wait until it’s in the throes of an enforcement action requiring compliance before objecting in court to the agency’s interpretation."