FDA's approach to clinical decision support software: A brief summary
By Bradley Merrill Thompson and M. Jason Brooke
We wrote this paper for those who have little experience with U.S. Food and Drug Administration regulation of clinical decision support (CDS) software. Our goal is to provide background for those who want to participate in FDA's ongoing efforts to clarify its regulatory approach to CDS. In 2011, FDA announced plans to publish a new guidance document that will define which types of CDS it will regulate. To gather the information needed to write the guidance, the agency held a hearing in September 2011, and we anticipate FDA will propose its guidance document perhaps early in 2012.
While the topic is very complicated, in this paper we try to distill it down to the fundamentals, and probably risk oversimplifying in the process. In particular, we address four questions:
- To what extent has FDA historically regulated CDS?
- What do we know about FDA's planned changes to its CDS regulatory program?
- What specific types of software are likely to be impacted?
- What are the open policy and regulatory issues that need to be addressed by the FDA's guidance document?
So let's get started.
FDA already regulates CDS. While the agency has never published a guidance document outlining the contours of that regulatory program, over the last 20 years FDA has regulated many different types of CDS. We will start by identifying at a high level the two different categories of CDS.
CDS Categories: CDS can be divided broadly into two categories: (1) standalone and (2) accessory. Standalone includes that software intended to be run on a computing platform that is not attached to a medical device but that will directly provide a diagnostic or treatment recommendation. Accessory software, on the other hand, specifically is marketed to support the functionality of a medical device like a blood glucose meter. Accessory software may or may not be sold by the manufacturer of the medical device it supports, but what distinguishes such software is the clear linkage through the promotional materials to a medical device.
Understanding that framework is important because it determines the regulatory requirements that apply. If the software is designed, for example, to analyze data downloaded from a blood glucose meter, the software is an accessory and will be regulated in the same manner as the blood glucose meter. The classification and most of the FDA regulatory requirements will be dictated by how the parent medical device is regulated. Standalone CDS, in contrast, is regulated or not on its own merits, without regard to another medical device.
Regulatory Status: Once you properly figure out which of the two roles the software plays, you can figure out its regulatory status. Typically that's one of the following three choices:
- Software that does NOT meet the legal definition of a device and is not FDA regulated;
- Software that DOES meet the legal definition of a device but FDA does not expect these products to undergo premarket review; and
- Software that DOES meet the definition of a device and FDA is actively regulating and would require a premarket review.
Except for a few specific exempt device types identified in the classification regulations like medical device data systems (or MDDS devices), that middle category isn't today a regulatory classification you'll find defined in any FDA records. Fortunately or unfortunately, depending on your perspective, FDA has been very reluctant over the last 20 years to define with any real precision its policy on which types of software must undergo premarket review and clearance, or even approval. The agency has held open public meetings and floated concept papers, but by and large has not with any certainty clarified its policy on when software trips the premarket requirement.
So the following is just our personal observations about how FDA regulates software in practice, gleaned from watching FDA enforcement actions, podium policy, and the informal statements FDA has made in concept papers.
Unregulated Software: One of the more recent articulations of the types of software FDA does not regulate was included in FDA's proposed MDDS classification, published in 2008. In that notice, FDA explained:
"It is FDA's long-standing practice to not regulate those manual office functions that are simply automated for the ease of the user (e.g., office automation).... For example, the report-writing functions of a computer system that allow for the manual (typewriter like) input of data by practitioners would not be... [regulated] because these systems are not directly connected to a medical device. In addition, software that merely performs library functions, such as storing, indexing, and retrieving information not specific to an individual patient, is not considered to be a medical device. Examples include medical texts or the Physician's Desk Reference on CD-ROM that are indexed and cross-referenced for ease of use."
FDA went to say that it won't regulate "software that allows a doctor to enter or store a patient's health history in a computer file", presumably referring generally to electronic health records.
On its face, that description of unregulated software is somewhat narrowly written. That's not surprising since FDA usually takes an expansive view of its jurisdiction, and is not likely to concede much ground in that regard, at least not in a formal writing.