.png){kind=logo}
In September 2022, the FDA issued a final guidance on clinical decision support software [1]. With this guidance, the FDA communicated their final thinking around the criteria that a clinical decision support software must meet in order to be excluded from the definition of a medical device.
To provide a brief historical recap on how this guidance came to be: in 2016, the 21st Century Cures Act [2] amended section 520(o) of the Federal Food, Drug, & Cosmetic (FD&C) Act to exclude certain software functions from the definition of a medical device. Shortly after, in 2017, the FDA issued its first draft guidance interpreting this provision. Based on comments received on the 2017 draft guidance, the FDA issued another revised, but still draft, guidance in 2019. Finally, in 2022, the FDA released this final guidance on clinical decision support software. Note that this guidance is not intended to discuss regulatory strategies for software functions considered as a medical device; it only serves to help interested parties understand whether their software function would fall under the definition of a device.
The guidance elaborates on the following four criteria, all of which must be met, in order for clinical decision support software to be excluded from the definition of a device.
Criterion (1)
Not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system
Software functions that assess or interpret the clinical implications or relevance of a signal, pattern, or medical image do not meet Criterion 1. A medical image includes images generated by use of a medical imaging system (such as a CT image, x-ray, or ultrasound). Signals include those that typically require the use of an in vitro diagnostic device or a signal acquisition system (such as signal generation from an ECG). A pattern includes multiple, sequential, or repeated measurements of a signal. For example, a measurement of blood glucose over time is considered a pattern.
A few examples of software functions that would not meet this particular criterion include those that:
- process or analyze a medical image to make enhancements, manipulations, measurements, or identify normal/abnormal structures
- process or analyze an ECG waveform or QRS complex (measures repeated complexes, measures variation from baseline, heart rate detection, or arrhythmias); and
- process or analyze an electrochemical or photometric response generated by an assay and instrument to generate a clinical test result.
This particular criterion does not introduce any new concepts. Software functions that do not meet this criterion have in fact been regulated by the FDA for several years.
Criterion (2)
Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information
This criterion is interpreted as software functions that display, analyze, or print patient-specific medical information. That includes information such as patient demographics, symptoms, test results, discharge summaries, or other medical information like clinical practice guidelines or peer-reviewed clinical studies. The FDA interprets medical information as information whose relevance to a clinical decision is well understood and accepted in the practice of medicine. Some examples include:
- A radiology study report
- An ECG report annotated by a healthcare provider describing it as an abnormal heart rhythm
- A blood pressure result from a legally marketed device
- A lab test result in an electronic health record
If a software function displays the type of medical information summarized above, it meets Criterion 2.
Criterion (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
One important consideration regarding meeting this criterion is that the software function must be intended to support or provide recommendations to a health care professional (HCP), and not a patient or caregiver.
The FDA interprets Criterion 3 to refer to software that:
- Provides condition-, disease-, and/or patient-specific information and options to a healthcare provider 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 or direct the healthcare provider’s judgment.
To provide an example, if a software function is intended to provide an output that lists different treatment options for a healthcare provider to consider for a patient it would meet Criterion 3. In contrast, if the same software function provided only one specific treatment course for the HCP, it would fail to meet Criterion 3.
Criterion (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
This criterion really highlights the concept of independent review by an HCP. A non-device should enable an HCP to independently review the basis of the recommendation(s) provided by a software function.
In order to satisfy Criterion 4, the FDA recommends that:
- The software or labeling include the purpose or intended use of the product, including the intended HCP user (can’t be time-critical)
- The software or labeling identify the required input medical information
- The software or labeling provide a plain language description of the underlying algorithm development and validation that forms the basis for the clinical decision support implementation; and
- The software output provide relevant patient-specific information and other knowns/unknowns for consideration by the HCP
This particular criterion really places an emphasis on providing as much information as possible to the HCP such that they can consider this information while using their own judgment to make a clinical decision for a patient.
Helpful Tools
The information presented in this guidance is dense and there is a lot to consider when figuring out whether a software qualifies as a medical device. The FDA recognizes that, and they have provided some useful tools to help interested parties understand if their software is subject to the FDA’s regulatory oversight.
The following graphic, available on the FDA website [3], illustrates the main points of the 2022 final guidance on clinical decision support software:
The FDA has also created a digital interactive tool to introduce digital health policy to stakeholders [4]. This tool incrementally introduces policy considerations by asking accessible questions that can be answered in Yes/No format. It is a good starting point to understanding what type of questions a stakeholder should be asking when trying to determine the regulatory status of their software.
Conclusion
With this guidance, the FDA outlines their statutory criteria for exclusion of software functions from the medical device definition. It does not go into enforcement policy on certain software functions. Rather, it serves to help stakeholders determine whether the software or software function they are developing falls under the device definition. In order for a software function to be excluded from the definition of a medical device, it must meet all four criteria described within this guidance document.
REFERENCES
[1] https://www.fda.gov/media/109618/download
[2] https://www.congress.gov/114/plaws/publ255/PLAW-114publ255.pdf
[3] https://www.fda.gov/media/161775/download
Disclaimer - This post intended for informational purposes and does not constitute legal information or advice. The materials are provided in consultation with US federal law and may not encompass state or local law.
