The CDS Coalition has filed a citizen petition to have the FDA withdraw its final guidance for clinical decision support (CDS) software, a development that could prove essential to unlocking the market for these products. One of the key questions in this petition is whether the FDA has violated the law by introducing concepts in the final guidance that were absent from the draft, but the immediate question is whether the FDA is already enforcing the terms of this guidance.
In our blog on the final guidance, we advised our clients that the FDA had departed drastically from the 2019 draft, such as in the definition of the term “medical information about a patient.” That is just one of several elements of the guidance that the CDS Coalition lists as potential deviations from the statute, but it is important to recognize that these petitions do not have a high success rate (see here, here and here), and on average may take nearly 3 years to process.
Assuming the FDA is already enforcing the terms of the guidance, developers should remain mindful of the four criteria that qualify the software for a non-device status. Bear in mind that each of these criteria must be met to escape regulation as a medical device. These criteria are that the software function:
- Does not acquire, process, or analyze medical images, signals, or patterns;
- Displays, analyzes, or prints only medical information that is normally communicated between healthcare professionals (HCPs);
- Provides recommendations (information and options) to the HCP rather than a directive or specific output; and
- Provides the HCP with the basis of any recommendations, thus reducing any possibility that the HCP relied primarily on those recommendations to make a clinical decision.
Final Guidance May Offer Greater Harmonization with MDR
One of the interesting aspects of the final CDS guidance is that it may be more harmonized than the 2019 draft with the European Union’s Medical Device Regulation (MDR). Rule 11 of Annex VIII of the MDR states that any software that is intended to provide information used to make a decision on diagnosis or on a therapeutic decision falls into class IIa, the category for low-to-medium risk devices.
The risk classification changes to class III, however, if the decision could have an impact that would result in death or irreversible deterioration of the patient’s health. The CDS software would be classified as a class IIb product if the impact could include serious deterioration of health or require surgery to correct the mistaken diagnosis or selected course of action.
The Medical Device Coordination Group’s guidance on regulatory classification, MDCG 2019-11, lends more insight, describing the types of software that are governed by the MDR and the risk status of those products. MDCG describes CDS software as computer-based tools that combine general medical information and algorithms with patient-specific data. One of the examples offered is the drug planning system, which would calculate the dosage of a drug to be administered to a specific patient. This function would qualify such software as a medical device subject to regulation, which also applies to a radiotherapy planning system and software used to analyze X-ray images or interpret electrocardiograms.
The risk of automation bias is greater when the software offers a single specific output rather than a list of options.
The FDA seems most concerned about the prospect that an HCP will become dependent on the CDS to make clinical decisions, a concern that is perhaps best captured by the notion of automation bias. The transcript from the FDA’s October 2022 webinar for the CDS final guidance states that the risk of automation bias is greater when the software offers a single specific output rather than a list of options.
The problem is seen as more acute when urgent clinical intervention is indicated, which complicates the task of developing a CDS that can be used in urgent and emergency care settings. Overcoming this problem of a single recommendation is likely to be difficult at times even in non-urgent/non-emergency settings, for instance when the patient suffers from a rare disease or condition for which there are few treatments.
This is not to say that the picture is necessarily less ambiguous for more common disorders. For more prevalent diseases and conditions, clinical practice guidelines are a key source of information, and these guidelines can be very specific for a disease sub-type and a particular patient sub-population. An example of this is the guideline issued by cardiology societies for atrial fibrillation, which states that novel oral anticoagulants (NOACs) are recommended rather than warfarin.
There are exceptions to this recommendation, however. Warfarin would be recommended over NOACs when the patient suffers from moderate or worse mitral valve stenosis (and implicitly some degree of mitral valve regurgitation) or has been implanted with a prosthetic heart valve. The question for a CDS developer is how to avoid a single recommendation for a well-identified population when the medical science underlying the diagnosis is this robust.
Coalition Argues the Final Guidance Impinges on State Law
The CDS Coalition’s petition lines up several instances in which the final guidance departs from the statute on procedural and/or substantive grounds, such as:
- The fact that the final guidance contains provisions not seen in the draft, is potentially a violation of the Administrative Procedures Act;
- The failure of the final guidance to conform to the principle that any changes be a logical outgrowth of the draft; and
- The final guidance’s limitation of the term “medical information about a patient” to information that is routinely discussed between HCPs or between an HCP and a patient, is a limitation not found in the 21st Century Cures Act.
Among the specific problems cited by the petition is the absence of any mention of automation bias in the 2019 draft, but the coalition also argued that the final guidance strays into the practice of medicine, which is regulated by state law. The petitioners argued that a failure of a physician to adequately think through a diagnostic or treatment decision is a matter for a state board of medicine to consider, not the FDA. Assuming the developer of the CDS has properly labeled the software, the physician is aware of the limitations of the software and is presumed to act accordingly.
The petitioners argued that the FDA itself has found no evidence that existing CDS products have a poor safety record suggestive of a need for regulation, and that the guidance would force a massive volume of applications that the agency would find unmanageable. These are all credible arguments, but there is no plausible way to forecast how this process will play out. Unfortunately, our best recommendation to our clients is to stay tuned and try to weave some degree of flexibility into any developmental CDS projects.
