William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
Read other articles by this author
The current version of the 21st Century Cures Act, which has been around in various forms since 2014, passed the House on November 25th and passage in the Senate is expected (12/7/16 – 2pm ET). Among the 996-page grab bag of material in this act is action taken to define certain types of medical software and to restrict FDA’s regulation thereof. This is relevant to a variety of health-related software including Clinical Decision Support (CDS).
In Subtitle F- Medical Device Innovations, Section 3060, Clarifying Medical Software Regulation, begins with a 5-part definition of the types of software which will not be regulated under the FDA’s medical device authority, a feat accomplished by excluding them from the definition of “medical device”. These include administrative software (which wasn’t regulated anyway), and certified electronic medical records that do not interpret or analyze patient records (which the FDA has already chosen not to regulate). The not analyze and interpret rule sounds like such an EMR cannot have CDS functionality even though certification of some EHRs includes CDS. Perhaps some coordination will be required here. Also excluded is lifestyle software that is “unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition”, and thus isn’t a medical device by the existing definition. In addition, software is excluded from regulation which moves data around without fundamentally altering it. Such software may provide general background information but cannot interpret or analyze clinical laboratory or other device data, results, and findings. This is similar to the FDA’s Medical Device Data Systems (MDDS) definition which the FDA has already chosen not to regulate.
CDS also comes up in a provision that imaging or signal processing software that includes supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition is also excluded from the definition of a medical device if the health care professional can independently review the basis for such recommendations and it is not the intent that the professional rely primarily on the recommendations to make a clinical diagnosis or treatment decision regarding an individual patient. A CDS that is based on patient data other than from imaging or signal acquisition does not seem to be covered by this exclusion, perhaps leaving such a CDS in medical device limbo.
The “not rely on” provision is of interest since it assumes that the provider can and will make independent judgements that might be contrary to the software’s recommendations. Although how realistic this is may be an issue this also presents some litigation traps. If the provider follows software recommendations that turn out to be wrong the software creator will remind the provider (and the court) that they weren’t supposed to rely on it. But if the medical provider acts differently from the software recommendations and that turns out to be wrong, the injured party might be able to point to the recommendation that they ignored and argue that had they just followed the recommendation the patient would have been fine.
There is an exception to the rule that software that is not a medical device by these new definitions will not be FDA regulated in that “the Secretary” can find, with public notice, that there should be regulation if a software function could be reasonably likely to have serious adverse health consequences. It is not clear if such a finding would be for a specific product or a generic category. Thus, the regulatory discretion that the FDA currently uses to include or exclude things could be used to draw an otherwise exempt software product back into its domain. Factors that the Secretary “shall consider” in reaching a conclusion to regulate are (in brief) the likelihood and severity of potential harm, the extent to which the software is intended to support clinical judgment, whether there is a reasonable opportunity for the provider to second guess recommendations, and the intended user and user environment. Or to put it another way, software that is important might still be regulated while unimportant software won’t be.
A further provision of the act is that the Secretary is to issue a biannual report that summarizes findings regarding the impact of such excluded software on patient safety, including best practices to promote related safety, education, and competency. This seems to require the FDA to study and make recommendations about software it does not regulate.
As with all legislation that manipulates regulatory requirements, the actual impact of all of this will only emerge over time as manufacturers of some products that are now regulated, or which might be regulated, are excluded from regulation, with or without any resultant adverse impact.