In the rapidly advancing world of healthcare technology, clinical decision-making has become smarter, more efficient, and patient-centric thanks to the revolutionary Clinical Decision Support (CDS) software.
CDS software is a type of health information technology (HIT) that provides healthcare professionals with patient-specific information and treatment recommendations to support clinical decision-making. CDS software can come in many different forms, including standalone software applications, mobile apps, and cloud-based platforms. Many everyday devices utilize CDS, such as medical imaging devices, diagnostic testing devices, telemedicine platforms, and wearable devices like smartwatches.
In fact, CDS software can be integrated into a wide range of medical devices and technologies to help support clinical decision-making and improve patient outcomes. But how do you decide if your CDS is a medical device?
Well, determining whether clinical decision support (CDS) software is a medical device can depend on several factors, including the intended use and functionality of the software. Here are some considerations:
- Intended use: If the CDS software is intended to provide information to healthcare professionals to aid in clinical decision-making, it may be considered a medical device.
- Functionality: If the CDS software analyzes patient-specific data and provides recommendations or advice to healthcare professionals, it may be more likely to be considered a medical device.
- Impact on patient care: If the CDS software is used to diagnose, treat, prevent, or cure a disease or condition, it is more likely to be considered a medical device.
- Level of risk: If the CDS software poses potential risks to the patient, such as incorrect recommendations or advice, it may be classified as a medical device and subject to regulatory requirements.
In short, if your CDS software or app is designed to provide recommendations to healthcare professionals that are intended to inform clinical decision-making, it likely meets the definition of a medical device. But hold on, there are still some ambiguities around this decision.
To make it easier for you to decide whether your CDS software is a medical device or not, we're going to review the 4 criteria a device or app must meet to be considered a non-device CDS. However, consulting with a contract research organization (CRO) and the FDA is strongly encouraged before classifying your device and embarking on a regulatory pathway you never had to pursue in the first place.
Table of Contents:
- The origin story of a device CDS determination.
- The 4 criteria's your device or app must meet to be considered a non-device CDS.
- A device CDS example.
- How might consulting with a CRO or the FDA help with device determination and costs?
The origin story of a device CDS determination.
To understand why this subject is so ambiguous with so many loopholes, we thought it was important to discuss the history of how a CDS device has been regulated. We'll try to keep this as brief as possible.
Since the first set of consumer protection regulations were passed in 1906, Congress has increased the FDA's responsibility in safeguarding and supporting the development of human pharmaceuticals, biological goods, medical devices, and radiation-emitting equipment (FDA: History of Medical Device Regulation).
In response to the public's ongoing demand for increased monitoring and regulations for medical devices, Congress passed the 21st Century Cures Act. It was enacted into law on December 13, 2016, with the aim of accelerating the development of medical products and bringing new discoveries and advancements to patients more quickly and effectively. The statute balances the speed to which FDA may make such decisions while providing more efficient pathways to market (FDA: 21st Century Cures Act).
Since then, the FDA has expressed concern about the potential for CDS software to be used in ways that were not intended or tested.
The FDA is also concerned about the possibility of software errors or malfunctions that could result in patient harm. For example, if CDS software provides inaccurate or incomplete information to healthcare professionals, it could result in incorrect diagnoses or treatments, which could be harmful to patients.
Additionally, physicians and other health care providers (HCPs) may become overly reliant on CDS software, even though it is not intended to be the major source of decision-making. The FDA is worried that such "automation bias" could result in medical mistakes where doctors may accidentally follow inaccurate advice leading to inaccurate or inappropriate care.
To address this concern, the agency said it will regulate certain software that provides information that a specific patient may exhibit signs of a disease, or condition, identify the risk probability or risk score for disease or condition, and that is intended to support time-critical decision-making.
It's critical to understand that all these regulations are required to protect the public, even though some might argue that FDA's extensive involvement violates the 21st Century Cures Act's statutory language (FDA’s CDS the Guidance).
Again, because there is a lot of ambiguity in this process and the FDA review approach, your device determination, whether a device CDS or non-device CDS, is mostly based on intended use, the risk level of each device and, of course, the four CDS criteria's. Having said that, it is always more advantageous to consult with a CRO and/or the FDA before embarking on any regulatory pathway.
The big 4 criteria.
To be exempt from the device definition and not be regulated as a medical device, your software function or app must meet all four criteria:
Criterion 1 and Criterion 2: Data inputs
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.
2) Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information.
Criterion 3 and Criterion 4: Data outputs
3) Intended for the purpose of supporting or providing recommendations to an HCP about prevention, diagnosis, or treatment of a disease or condition.
4) Intended for the purpose of enabling an HCP to independently review the basis for the recommendations that such software presents so that it is not the intent that the HCP rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.
Now, let’s talk about how these criteria should be interpreted. Even if your medical device satisfies criteria 1, 2, and 3 but not 4, it will still be regarded as a device CDS. The next step would be to determine your device class based on risks and choose an appropriate regulatory pathway such as a 510(k), De Novo, or PMA.
However, keep in mind there may be subtle ways to change how your product is labeled to ensure your device meets all four criteria. Remember the intended use, functionality, potential impact on patient care, and level of risk are all factors that contribute to whether a CDS is considered a medical device.
The risk level contributes to some of the ambiguity in determining whether your device or software is a medical device. If your device is generally of higher risk, such as involving pediatric, cancer, or HIV patients, the FDA tends to be more conservative in how they interpret the listed standards and criteria. In these cases, the potential for patient harm should the device provide inaccurate information is much greater.
We will go into more detail about how collaborating with a CRO and communicating with the FDA beforehand can be beneficial. Additionally, we provide a customer example of how we identified an app as a device CDS to help your intended outcome.
A real-life example of a technology discovering they were a device CDS.
We collaborated with a team on their technology; let's see how their app was identified as a device CDS and how we arrived at that conclusion. This team focused on developing a mobile medical application that gives parents or caregivers accurate over-the-counter medication dosage information for children based on age and weight inputs, as well as reminders to promote the frequency of dosage.
The team was unsure about how they would be regulated and whether their app qualified as a medical device.
We analyzed the CDS guidance to see which criteria they met. They met criteria 1 and 3, but not 2 and 4. As a result, they were regarded as device CDS subject to regulatory requirements. After determining that they were a medical device, we conducted regulatory research to determine their class and the least burdensome pathway.
The application is 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 and, therefore, met criteria 1. The application provided recommendations to parents and not an HCP to support or provide recommendations about prevention, diagnosis, or treatment of a disease or condition, satisfying criteria 3.
The application is not intended to display, analyze, or print medical information about a patient and, therefore, did not meet criteria 2. Additionally, the device's primary user is not an HCP and, therefore, did not meet criteria 4 (See Figure 1).
Figure 1: CDS Software Function Device Decision Table, reproduced from FDA guidance document on Clinical Decision Support Software
How might consulting with a CRO or the FDA help with device determination and costs?
Seeking guidance from an experienced contract research organization during your device designation process will make your journey that much smoother. A partner like Proxima can assist you in identifying the criteria your device doesn't satisfy to then offer guidance so you may avoid taking the regulatory pathway for medical devices.
Additionally, if you decide to seek clarification from the FDA regarding your device's classification, you may submit a 513(g) request. This formal request for designation or classification enables you to receive a definitive response from the FDA, clarifying whether your software falls under the category of a device CDS and outlining the regulatory requirements accordingly.
Notably, a 513(g) request serves as a legally binding agreement between you and the FDA, providing critical certainty regarding your product's classification. In the event of an audit or inquiry, having the 513(g) determination can prove instrumental in demonstrating compliance.
If you are a startup, it is also beneficial to take part in a pre-submission meeting with the FDA to clarify regulatory requirements and identify potential issues leading to more productive communication throughout the review process. As a startup, it can be even more challenging when your device or app gets classified as a medical device due to the lengthy and costly regulatory pathway, such as the De Novo pathway. In this pre-submission meeting, you maybe advised to bring your device description and testing plans. Overall, this is an opportunity to foresee your next steps if you find it difficult to pursue a demanding and costly regulatory pathway.
Main takeaway: It is okay to be a device CDS and not have all the answers right away, you can figure it out as you go. Remember that you can always rely on consultants and the FDA for assistance in determining whether you are a device or non-device CDS and in finding the best solutions for your individual needs and the demands of your device or app. Just remember to embrace the process of learning and adapting as you work towards providing cutting-edge solutions that will impact patient care for the better.
