Bradley Merrill Thompson Quoted in “Software to Predict Risk of Sepsis, Stroke Should Be Regulated as a Medical Device, Says FDA”

The guidance applies to clinical decision support software, a broad category of software tools that can help physicians and other healthcare providers detect illnesses and generate alerts when a patient’s condition changes. For example, software that uses electrocardiogram (ECG) data to detect arrhythmias, like that used by Apple’s and Fitbit’s smartwatches, is regulated as a medical device. The same goes for software that analyzes images to differentiate between ischemic and hemorrhagic stroke, or that is used by radiologists to “triage” patients and review potential cases of pulmonary embolism. …

The biggest policy change, the FDA noted in the guidance, is that some types of predictive tools, which previously fell into a gray area, should now be regulated as medical devices. The agency gave an example of software that analyzes patient information to detect stroke or sepsis, and generates an alarm to notify a healthcare provider. 

Sepsis Detection

Several such risk-scoring tools are already in use: Electronic health record companies Epic Systems and Cerner have both made sepsis surveillance tools to detect the deadly condition before patients deteriorate. Neither are FDA cleared, and a study last year by Michigan Medicine found that Epic’s tool performed worse than advertised. …

Bradley Merrill Thompson, an attorney with Epstein Becker Green in Washington, D.C., who advises clients on FDA regulations, wrote that part of the FDA’s argument is around automation bias, or the concern that healthcare providers might rely too much on an automated suggestion. 

“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 from the draft guidance,” he wrote in an email. “Apparently, FDA has a very low view of healthcare professionals if the agency thinks that mere software can ‘direct’ doctors what to do, as if the doctor then has no choice.” …

Enforcement

There are still plenty of details to be hammered out, including how the changes would be enforced for software tools that are now considered a device. …

An FDA spokesperson wrote in an email that the agency has “discretion on when to take appropriate risk-based actions, as facilitated by the publicly-available guidance. Guidances describe the agency’s current thinking on a topic and should be viewed as recommendations, unless specific regulatory or statutory requirements are cited.”

The agency added that developers are encouraged to work with the FDA as early as possible in the process to get answers to their questions, through the Center for Devices and Radiological Health’s pre-submission program. 

“I absolutely believe that we should take [the FDA] literally, and that they would apply this guidance to regulate a lot of software which is presently in the marketplace but for which the developers have not sought to comply with FDA requirements,” Thompson wrote.

Whether the agency would allow risk-scoring tools developed and used by hospitals internally wasn’t addressed in the guidance, but the FDA has a long-standing policy of allowing for the practice of medicine, Thompson added. Vendors that develop products for sale to multiple institutions would need to comply, he said.