FDA Guidance on Software and Medical Devices

Almost nothing that is made anymore doesn’t have some software in it.  That includes a lot of medical devices and equipment.  In addition, information technology is pervasive in all aspects of health care.  The Food & Drug Administration is charged with regulating compounds and devices intended for use in rendering health care.  The question has arisen for many years about the extent to which software might be considered a medical device and the extent to which, if it is a device, it is regulated.  Recent guidances shed more light on this topic.  The first is a general final guidance on how to do a clinical evaluation when software falls in the definition of a device.  (Software is often a device because it is either embedded in something, a pacemaker, e.g., that is a device or because it meets the definition of being designed to diagnose, prevent or treat a health condition.)  This guidance actually is an adoption by the FDA of a policy developed by an international group of regulators, the International Medical Device Regulators Forum.   (Software Guidance)   The primary thrust of this guidance is that the software needs to be evaluated to determine that there is a valid clinical association between the output of the software and the targeted clinical condition and that the software produces the expected output data.  The general quality systems required by the FDA throughout a product’s life cycle apply to software when it is a device and implementation of those quality systems by software developers should ensure that these two criteria are met.  The guidance further gives some specific examples of how to document that there a valid clinical association, how to generate evidence of that validity and how to ensure that the software is accurately taking inputs and creating outputs.

The second guidance relates to clinical decision software; when it is a device and how it will be regulated.  (CDS Guidance)   Clinical decision support software is already fairly ubiquitous and with the spread of artificial intelligence will likely become more significant in diagnostic and treatment decisions.  The guidance divides this kind of software into two types:  that intended for use by health professionals and that for use by patients and caregivers.  The FDA attempts in the guidance to categorize CDS as not meeting the definition of a device; meeting the definition but not needing regulation; or needing regulatory focus.  Software is not a device if it meets all of the following four criteria:  it doesn’t process  or analyze a medical image or signal from an in vitro diagnostic device,  it is intended to display or analyze information about a patient or general medical information, it is intended to provide recommendations about disease diagnosis, prevention or treatment, and it helps clinicians make decisions but is not intended to have the clinician primarily rely on any recommendation coming from the CDS.  That last criteria is clearly the important one.  FDA will ignore CDS that just provides inputs and isn’t relied on to supplant clinician judgment.  Although CDS that is aimed at patients or caregivers is not exempt from the device definition, FDA said it won’t regulate it as long as it meets similar criteria.  The guidance then goes on to give examples of CDS functionality that would not be considered a device as well as functionality that still would be considered a device, but some of these FDA does not intend to regulate.  If CDS is a device, it still generally falls into the lower categories of regulatory scrutiny.  In my experience, health care software developers are often unaware of the potential for FDA regulation, and they should read these guidances carefully.