On September 27, 2019,the U.S. Food and Drug Administration (FDA) issued several guidances that will impact innovation in the digital health space, the draft guidance, Clinical Decision Support Software and the final guidances: Policy for Device Software Functions and Mobile Medical Applications, General Wellness: Policy for Low Risk Devices, Off-The-Shelf Software Use in Medical Devices, and Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices. Taken together, these guidances define FDA’s position on regulatory oversight and enforcement of devices commonly developed and used in digital health. This paper will explore FDA’s framework for regulatory oversight and discretion as well as what does not constitute a device in accordance with the recently released guidances
Clinical Decision Support (CDS) software has become an integral tool used By Healthcare Professionals (HCPs) when treating patients and by patients and caregivers when trying to understand the contours of a given ailment.CDS provides healthcare professionals and patients with knowledge and personspecific information, intelligently filtered or presented at appropriate times, to enhance health and healthcare. Examples of CDS include: computerised alerts and reminders for providers and patients, conditionspecific order sets, focused patient data reports and summaries, diagnostic support, and contextually relevant reference information.
On December 8, 2017, the U.S. Food & Drug Administration (FDA) published a draft guidance titled “Clinical and Patient Decision Support Software” that aimed to provide clarity on the scope of the FDA’s oversight of clinical decision support software intended for healthcare professionals, and patient decision support software intended for patients and caregivers who are not healthcare professionals. On October 27, 2019, FDA issued an updated guidance document applicable to clinical decision support software that takes a risk-based approach to regulation of CDS. Recognising that digital health is playing an ever-increasing role in healthcare, FDA’s stated position is to encourage innovation. By taking a riskbased approach to its oversight of CDS, FDA hopes to strike a balance between encouraging developers to create, adapt and expand the functionalities of their software to support providers in diagnosing and treating diseases, while also ensuring the software doesn’t introduce unacceptable risk to the patient. The CDS guidance was issued alongside a suite of final guidance documents that, taken together, illustrates FDA’s commitment to providing clarity to developers operating in the digital health space.
CDS software, inter alia, provides HCPs and patients with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and healthcare. CDS includes technologies such as computerised alerts and reminders for providers and patients; clinical guidelines; conditionspecific order sets; focused patient data reports and summaries; documentation templates; diagnostic support; and contextually relevant reference information. In its guidance, FDA attempted to clarify which types of CDS software are not devices, which types of CDS software may be devices but, based on FDA’s current understanding of the risks posed by the devices, FDA intends to exercise enforcement discretion, and CDS software that are devices and on which FDA intends to focus its regulatory oversight.
When determining whether CDS software is a device or a non-device, FDA intends to evaluate who the intended user of the CDS software is and whether the user can independently review the basis for the recommendation made by the software. The user’s ability to independently review the basis for the software’s recommendation asks whether the function is intended for the purpose of enabling the user to independently review the basis for the recommendations so that it is not the intent that user rely primarily on any such recommendation. If the CDS software is intended for use by an HCP, whether the CDS software is a device hinges upon whether the HCP can independently review the basis for the recommendation made by the software. If so, the software is non-device CDS. If not, the software is device CDS.
Whether FDA exercises enforcement discretion or exercises oversight focus depends upon the risk associated with the situation or condition at issue. Drawing from the International Medical Device Regulators Forum, Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations (IMDRF Framework), In the guidance, FDA categorises risk associated with patient conditions as non-serious, serious, and critical. In general, non-serious situations or conditions are situations or conditions where an accurate diagnosis and treatment is important but not critical for interventions to mitigate longterm irreversible consequences on an individual patient's health condition or public health. In general, serious situations or conditions means situations or conditions where accurate diagnosis or treatment is of vital importance to avoid unnecessary interventions or timely interventions are important to mitigate long-term irreversible consequences on an individual patient’s health condition or public health. In general, critical situations or conditions means situations or conditions where accurate and/or timely diagnosis or treatment action is vital to avoid death, long-term disability or other serious deterioration of health of an individual patient or to mitigating impact to public health.
In addition to a risk assessment based on the impact of the software output on a patient’s situation or condition, FDA assesses the risk associated with a device CDS function in terms of whether the information provided by the software will be used to inform clinical management, drive clinical management, or treat or diagnose. Informing clinical management means that the information provided by the software will not trigger an immediate or near-term action and will inform the intended user of options for treating, diagnosing, preventing, or mitigating a disease or will provide clinical information by aggregating relevant information (e.g., disease, condition, drugs, medical devices, population, etc.). Driving clinical management means that the information provided by the software will be used by the end user (to aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or condition) will be used to guide next diagnostics or next treatment interventions: to aid in treatment by providing enhanced support to safe and effective use of medicinal products or a medical device; to aid in diagnosis by analysing relevant information to help predict risk of a disease or condition or as an aid to making a definitive diagnosis; or to triage or identify early signs of a disease or condition. Treating and diagnosing means that the information provided by the software will be used to take an immediate or near-term action: to treat/prevent or mitigate by connecting to other medical devices, medicinal products, general purpose actuators or other means of providing therapy to a human body; or to diagnose/screen/detect a disease or condition (i.e., using sensors, data, or other information from other hardware or software devices, pertaining to a disease or condition.
Software that drives clinical management and treats or diagnoses patient conditions are not CDS; such software goes beyond supporting or providing recommendations to an HCP, patient, or caregiver. Whereas CDS software provides support by offering recommendations and informing clinical management, software that drives clinical management goes beyond simply supporting or providing a recommendation about prevention, diagnosis, or treatment of a disease or condition. Drive functions are relied on to guide next diagnostics or treatment interventions, and therefore are not CDS. Similarly, software that treats or diagnoses prompt an immediate or nearterm action, which are functions that are well beyond the scope of supporting or providing recommendations. FDA’s focus in the instant guidance is on CDS solely.
Whether FDA will engage in oversight focus of software that informs clinical management depends on the seriousness of the patient’s condition, the intended end user, and whether the end user can independently review the basis for the recommendation being made by the software. The table below summarises FDA’s approach to oversight focus and enforcement discretion.
Software developers should take notice that FDA oversight focus is applicable to almost every form of CDS software except when an HCP can independently review the basis for the recommendation being made by the software. If an HCP cannot independently review the basis for the recommendation being made by the software, the condition at issue must be non-serious for FDA to exercise enforcement discretion. In contrast, where the end user is a patient or a caregiver, FDA will engage in oversight focus unless the condition at issue is non-serious and the end use patient or caregiver can independently review the basis for the recommendation being made by the software.
Although FDA’s risk-based approach to regulation of CDS software is a practical and flexible approach to regulatory oversight, developers will still find themselves seeking FDA clearance for their software innovations. The complexity of many digital health innovations do not lend themselves to HCPs independently reviewing the basis for the recommendation being made by the software. Developers targeting patients and caregivers will almost certainly need a regulatory clearance in advance of commercialisation unless the software is coupled with a way for users to independently review the basis for the recommendation being made by the software.
