William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
Read other articles by this author
It has long been clear that the FDA can regulate software that falls under the definition of a medical device. Such software might be part of and integral to a more physical chunk of technology in which case it is regulated as part of that technology, and no special jurisdictional questions arise. However, device cybersecurity is a hot topic despite the fact that there do not seem to be any real-world examples of devices being hacked for nefarious purposes. Such real-world examples would be distinct from lab demonstrations, and the “discovery” and publication of vulnerabilities has an element of self-serving business promotion, ie you have a big problem and if you hire me I can tell you how to solve it.
Software can also be a medical device itself, now often designated as SaMD – Software as Medical Device, and thus is subject to regulation, unless the FDA decides, within its “regulatory discretion” to not regulate a particular item or type of item. In the past some people argued that software could not be a medical device, in part because it wasn’t “an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article” as stipulated in the FDA definition. But “other similar” can cover a good deal of ground, and in any case the FDA has said that if you think software is generally excluded, you are wrong. The EU has made this more explicit with the current definition of a medical device including “any instrument, apparatus, appliance, software, material or other article used alone or in combination”.
The 21st Century Cures Act (which probably didn’t cure anything) addressed certain categories of medically related software and removed some from FDA regulation by limiting the definition of a medical device via specific exclusions. The excluded categories are software functions that are intended (1) for administrative support of a health care facility, (2) for maintaining or encouraging a healthy lifestyle, (3) to serve as electronic patient records, (4) for transferring, storing, converting formats, or displaying data, or (5) to provide limited clinical decision support. These are mostly things that the FDA wasn’t regulating, or was minimally regulating, anyway.
Having legislated that certain software isn’t a medical device, the law then directed the FDA to undertake a study of the now not medical device software to determine if there are any risks and benefits to health associated with these non-device software functions. Presumably if there are risks to health some further action would be warranted such as reinstating FDA regulation or creating another regulatory scheme. Accordingly, the FDA has now issued a call for comments on this subject. The resulting report is to include a summary of the impact of such software on patient safety, including best practices to promote safety, education, and competency. We will have to wait and see who it is that needs this education and competency.
FDA’s interest in digital health also includes the ongoing pilot program to study the pre-certification of the developers of SaMD which could result in reducing the extent of regulation for some types of SaMD. These excluded types would be one where the medical conditions they address aren’t serious and the interventions they might influence are relatively unimportant. This creates a new category of medical software which is “ doesn’t matter very much”. The FDA also has a draft guidance document, dated December 2017, on the regulation of Clinical Decision Support software. This draft, which might ultimately become a full guidance, is also based on an “is it important” threshold, along with can it be effectively second guessed in a timely manner.