Industry insiders can all agree that the U.S. Food & Drug Administration (FDA) regulates the use of medical devices. Most insiders agree that a medical device is any instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part that is intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, intended to affect the structure or any function of the human body, and that does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes. 21 U.S.C. §321(h). It is, therefore, clear to most that a pacemaker would be a medical device subject to FDA regulation and enforcement. 

Such clarity is not so easily obtained (even for the most experienced) when assessing software that functions as a medical device. Developers looking to commercialize their products want and need to understand if their product is a regulated device subject to the FDA’s 510(k) clearance process. If a product is a regulated medical device and a developer fails to obtain FDA clearance, a developer could find themselves on the wrong side of FDA enforcement because the product will be considered misbranded upon commercialization into interstate commerce. 

The Current State of FDA Medical Device Software Regulations

Attempting to foster innovation, Congress excluded from the definition of device, software functions intended for: administrative support of a health care facility; maintaining or encouraging a healthy lifestyle without reference to any disease or condition; electronic patient records; transferring, storing, converting formats, or displaying data and results; and Clinical Decision Support Software (CDS).

The FDA has undertaken a risk-based approach to regulating software that may be considered a medical device and has attempted to clarify what is and what is not a device in several guidance documents. Of unique interest to developers are software programs that run on smartphones and other mobile communication devices, including accessories that attach to a smartphone or other mobile communication devices, or a combination of accessories and software. Often, these are known as mobile medical applications (MMAs). When making regulatory determinations, the FDA considers the functionality of the software. That is, if the intended use of an MMA is for the diagnosis of diseases or other conditions; the cure, mitigation, treatment, or prevention of disease; or is intended to affect the structure or any function of the body of man, the MMA is a device. The FDA applies regulatory oversight to those software functions that are medical devices and whose functionality could pose a risk to a patient’s safety if the device did not function as intended.

The FDA has articulated that any software intended for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition is not considered a medical device. A general wellness product is a low-risk product that has: an intended use that relates to maintaining or encouraging a general state of health or a healthy activity, or an intended use that relates the role of a healthy lifestyle with helping to reduce the risk or impact of certain chronic diseases or conditions and where it is well understood and accepted that healthy lifestyle choices may play an important role in health outcomes for the disease or condition.

The Rise of Clinical Decision Support Software

In recent years, an area of explosive growth is CDS. CDS is described as a variety of tools including, but not limited to: computerized alerts and reminders for providers and patients; clinical guidelines; condition-specific order sets; focused patient data reports and summaries; documentation templates; diagnostic support; and contextually relevant reference information. If the software functions meet all of the following four criteria, it’s not a regulated device:

(1) not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device (IVD) or a pattern or signal from a signal acquisition system;

(2) intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);

(3) intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and

(4) intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient (section 520(o)(1)(E) of the FD&C Act).

The fourth criteria is the stickiest for industry. FDA has noted that non-Device CDS software functions are intended to support or provide recommendations to a health care professional (HCP)(not a patient) about prevention, diagnosis, or treatment of a disease or condition.

• Software functions that support or provide such recommendations to patients or caregivers –not HCPs –remain in the definition of device.

• Non-Device CDS assist HCPs in making patient-specific care decisions. 

• Such software:

  • provides condition-, disease-, and/or patient-specific information and options to an HCP to enhance, inform, and/or influence a health care decision;

  • does not provide a specific preventive, diagnostic or treatment output or directive;

  • is not intended to support time-critical decision-making; and

  • is not intended to replace the HCP’s judgment.

Non-Device CDS software is intended to enable HCPs to independently review the basis for the recommendations presented by the software. This way they do not rely primarily on such recommendations, but rather on their own judgment, to make clinical decisions for individual patients. FDA has provided a visual overview of its guidance to help sponsors determine whether their software will be non-device CDS or if the software will be regulated as a device.

FDA does offer a formal process, 513(g) Request, whereby developers can have FDA provide a determination regarding whether a product is or is not regulated by FDA.