Step 6: Is the Software Function Intended to Provide Clinical Decision Support?
Clinical decision support (CDS) is a software function that provides health care professionals and patients with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care. Certain CDS software functions are not devices under section 520(o)(1)(E) of the FD&C Act.
Step 6 will help determine if your CDS software function is a device.
6.A: Is the software function 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?
Your product may be a device. Go to Step 7.
Consider the following as you answer this question for your software function:
- The FDA generally considers the term signal to include those signals that typically require use of either:
- An IVD, which can include an electrochemical or photometric response generated by an assay and instrument that may be further processed by software to generate a clinical test result, or
- A signal acquisition system that measures a parameter from within, attached to, or external to the body for a medical purpose.
- The FDA generally considers the term medical image to include those images generated by use of medical imaging systems (for example, computed tomography (CT), x-ray, ultrasound, magnetic resonance imaging (MRI)) to view any part(s) of the body or images acquired for a medical purpose (for example, pathology, dermatology). Images that were not originally acquired for a medical purpose but are being processed or analyzed for a medical purpose are also considered medical images.
- The FDA interprets the term pattern in this provision to refer to multiple, sequential, or repeated, measurements of a signal or from a signal acquisition system.
- The FDA considers software functions that assess or interpret the clinical implications or clinical relevance of a signal, pattern, or medical image to be software functions that acquire, process, or analyze.
WHY: Software functions intended to acquire, process, or analyze a medical image or a signal from an IVD or a pattern or signal from a signal acquisition system do not meet the criteria in section 520(o)(1)(E) of the FD&C Act. Answering "No" to Question 6.A suggests the software function is not excluded from the device definition by section 520(o)(1)(E) of the FD&C Act. The software function may be the focus of the FDA's regulatory oversight as a device.
LEARN: Clinical Decision Support Software
ASK: If you have questions or would like feedback, go to Resources to learn about engaging with the FDA or email the Digital Health inbox.
Continue to Question 6.B.
Consider the following as you answer this question for your software function:
- The FDA generally considers the term signal to include those signals that typically require use of either:
- An IVD, which can include an electrochemical or photometric response generated by an assay and instrument that may be further processed by software to generate a clinical test result, or
- A signal acquisition system that measures a parameter from within, attached to, or external to the body for a medical purpose.
- The FDA generally considers the term medical image to include those images generated by use of medical imaging systems (for example, computed tomography (CT), x-ray, ultrasound, magnetic resonance imaging (MRI)) to view any part(s) of the body or images acquired for a medical purpose (for example, pathology, dermatology). Images that were not originally acquired for a medical purpose but are being processed or analyzed for a medical purpose are also considered medical images.
- The FDA interprets the term pattern in this provision to refer to multiple, sequential, or repeated, measurements of a signal or from a signal acquisition system.
- The FDA considers software functions that assess or interpret the clinical implications or clinical relevance of a signal, pattern, or medical image to be software functions that acquire, process, or analyze.
6.B: Does the software function display, analyze, or print medical information normally communicated between health care professionals?
Continue to Question 6.C.
Consider the following as you answer this question for your software function:
- The FDA interprets medical information about a patient to be the type of information that normally is, and generally can be, communicated between health care professionals in a clinical conversation or between health care professionals and patients in the context of a clinical decision, meaning that the relevance of the information to the clinical decision being made is well understood and accepted.
- Examples of medical information include but are not limited to: demographic information, symptoms, certain test results, patient discharge summaries, and other medical information (such as clinical practice guidelines, peer-reviewed clinical studies, textbooks, approved drug or medical device labeling, and government agency recommendations).
- FDA interprets other medical information to include information such as peer-reviewed clinical studies, clinical practice guidelines, and information that is similarly independently verified and validated as accurate, reliable, not omitting material information, and supported by evidence.
Your product may be a device. Go to Step 7,
Consider the following as you answer this question for your software function:
- The FDA interprets medical information about a patient to be the type of information that normally is, and generally can be, communicated between health care professionals in a clinical conversation or between health care professionals and patients in the context of a clinical decision, meaning that the relevance of the information to the clinical decision being made is well understood and accepted.
- Examples of medical information include but are not limited to: demographic information, symptoms, certain test results, patient discharge summaries, and medical information (such as clinical practice guidelines, peer-reviewed clinical studies, textbooks, approved drug or medical device labeling, and government agency recommendations).
- FDA interprets other medical information to include information such as peer-reviewed clinical studies, clinical practice guidelines, and information that is similarly independently verified and validated as accurate, reliable, not omitting material information, and supported by evidence.
WHY: Software functions not intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information do not meet the criteria in section 520(o)(1)(E)(i) of the FD&C Act. Answering "No" to Question 6.B suggests the software function is not excluded from the device definition by section 520(o)(1)(E) of the FD&C Act. The software function may be the focus of the FDA's regulatory oversight as a device.
LEARN: Clinical Decision Support Software
ASK: If you have questions or would like feedback, go to Resources to learn about engaging with the FDA or email the Digital Health inbox.
6.C: Does the software function provide recommendations (information/options) to a health care professional rather than provide a specific output or directive for preventing, diagnosing, or treating a disease or condition?
Continue to Question 6.D.
Consider the following as you answer this question for your software function:
- Software functions that are intended for patients or caregivers do not meet the criteria in section 520(o)(1)(E) of the FD&C Act since the software function is not limited to supporting or providing recommendations to health care professionals.
- The FDA generally considers criteria in section 520(o)(1)(E)(ii) of the FD&C Act to refer to software that:
- Provides condition-, disease-, and/or patient-specific information and options to a health care professional to enhance, inform, and/or influence a health care decision;
- Does not provide a specific preventative, diagnostic, or treatment output or directive;
- Is not intended to support time-critical decision making; and
- Is not intended to replace or direct the health care professional's judgment.
The following are examples of software functions that meet Criterion 3 (section 520(o)(1)(E)(ii) of the FD&C Act):
- Evidence-based clinician order sets for an HCP to choose from, tailored for a particular condition, disease, or clinician preference;
- Matching patient-specific medical information from records or reports to reference information (e.g., clinical guidelines);
- Contextually relevant reference information about a disease or condition;
- Drug-drug interaction and drug-allergy contraindication notifications to avert adverse drug events;
- Drug formulary guidelines;
- Duplicate testing or prescription product prevention notifications (e.g., medication reconciliations and test reconciliations);
- Reminders for preventive care or clinician’s orders; and
- Patient data reports and summaries (e.g., discharge papers).
Your product may be a device. Go to Step 7.
Consider the following as you answer this question for your software function:
- Software functions that are intended for patients or caregivers do not meet the criteria in section 520(o)(1)(E) of the FD&C Act since the software function is not limited to supporting or providing recommendations to health care professionals.
- The FDA generally considers criteria in section 520(o)(1)(E)(ii) of the FD&C Act to refer to software that:
- Provides condition-, disease-, and/or patient-specific information and options to a health care professional to enhance, inform, and/or influence a health care decision;
- Does not provide a specific preventative, diagnostic, or treatment output or directive;
- Is not intended to support time-critical decision making; and
- Is not intended to replace or direct the health care professional's judgment.
Software that provides a specific preventive, diagnostic, or treatment output or directive or that addresses a time-critical decision would not satisfy Criterion 3 (section 520(o)(1)(E)(ii) of the FD&C Act), including software that:
- Provides a specific preventative, diagnostic, or treatment course;
- Provides a specific follow-up directive;
- Provides time-critical alarms or alerts intended to trigger potential clinical intervention to assure patient safety;
- Provides a treatment plan for a specific patient’s disease or condition; or
- Provides a risk probability or risk score for a specific disease or condition.
WHY: Software functions not intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition do not meet the criteria in section 520(o)(1)(E)(ii) of the FD&C Act. Answering "No" to Question 6.C suggests the software function is not excluded from the device definition by section 520(o)(1)(E) of the FD&C Act. The software function may be the focus of the FDA's regulatory oversight as a device.
LEARN: Clinical Decision Support Software
ASK: If you have questions or would like feedback, go to Resources to learn about engaging with the FDA or email the Digital Health inbox.
6.D: Does the software function provide the basis of the recommendations so that the health care professional DOES NOT RELY primarily on any recommendations to make a decision regarding an individual patient?
LIKELY NOT A DEVICE
Consider the following as you answer this question for your software function:
To enable a health care professional to independently review the basis for recommendation, the FDA recommends that the software or labeling:
- Include the purpose or intended use of the product, including the intended health care professional user and intended patient population. (To enable independent review, the purpose or intended use cannot be time-sensitive.)
- Identify the required input medical information, with plain language instructions on how the inputs should be obtained, their relevance, and data quality requirements.
- Provide a plain language description of the underlying algorithm development and validation that forms the basis for the CDS implementation:
- Summary of the logic or methods (for example, artificial intelligence/machine learning techniques)
- Description of the data relied upon
- Description of results from clinical validation studies
- Provide relevant patient-specific information and other knowns/unknowns for consideration.
WHY: Software functions intended to enable health care professionals to independently review the basis for the recommendations presented by the software so that they do not rely primarily on such recommendations, but rather on their own judgment, to make clinical decisions for individual patients meet the criteria in section 520(o)(1)(E)(iii) of the FD&C Act. All four criteria of section 520(o)(1)(E) of the FD&C Act must be met for a CDS software function to be not a device:
- 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 (section 520(o)(1)(E) of the FD&C Act);
- 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) (section 520(o)(1)(E)(i) of the FD&C Act);
- Intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition (section 520(o)(1)(E)(ii) of the FD&C Act); and
- 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)(iii) of the FD&C Act).
Considering your answers to the previous questions, answering "Yes" to Question 6.D suggests the software function may not meet the device definition.
If you are unsure, go to Step 7 to learn about other device criteria and considerations that may apply to your software function.
LEARN: Clinical Decision Support Software
ASK: If you have questions or would like feedback, go to Resources to learn about engaging with the FDA or email the Digital Health inbox.
Your product may be a device. Go to Step 7.
Consider the following as you answer this question for your software function:
To enable a health care professional to independently review the basis for recommendation, the FDA recommends that the software or labeling:
- Include the purpose or intended use of the product, including the intended health care professional user and intended patient population. (To enable independent review, the purpose or intended use cannot be time-sensitive.)
- Identify the required input medical information, with plain language instructions on how the inputs should be obtained, their relevance, and data quality requirements.
- Provide a plain language description of the underlying algorithm development and validation that forms the basis for the CDS implementation:
- Summary of the logic or methods (for example, artificial intelligence/machine learning techniques)
- Description of the data relied upon
- Description of results from clinical validation studies
- Provide relevant patient-specific information and other knowns/unknowns for consideration
WHY: Software functions that are not intended to enable health care professionals to independently review the basis for the recommendations presented by the software so that they do not rely primarily on such recommendations, but rather on their own judgment, to make clinical decisions for individual patients do not meet the criteria in section 520(o)(1)(E)(iii) of the FD&C Act. Answering "No" to Question 6.D suggests the software function is not excluded from the device definition by section 520(o)(1)(E) of the FD&C Act. The software function may be the focus of the FDA's regulatory oversight as a device.
LEARN: Clinical Decision Support Software
ASK: If you have questions or would like feedback, go to Resources to learn about engaging with the FDA or email the Digital Health inbox.
Feedback: Was the Digital Health Policy Navigator useful? Let us know what you think