National Center for Health Research; December 23, 2019
National Center for Health Research Public Comments on
FDA’s Clinical Decision Support Software; Draft Guidance for Industry and
Food and Drug Administration Staff; Availability
[FDA-2017-D-6569]
The National Center for Health Research (NCHR) is a nonprofit think tank that conducts, analyzes, and scrutinizes research, policies, and programs on a range of issues related to health and safety. We do not accept funding from companies that make products that are the subject of our work.
Clinical Decision Support (CDS) Software is a growing set of medical software with the potential for helping make better clinical decisions but also the potential for harming patients. We appreciate FDA clarifying plans for regulating this software; however, we have concerns regarding the draft guidance.
The guidance should be edited to clarify the types of information required to accurately categorize CDS software. The guidance defines Non-Device CDS according to four criteria, with the fourth criterion requiring that software is “intended for the purpose of enabling an HCP to independently review the basis for recommendations…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”. The guidance also indicates (page 12, lines 248-253) that the FDA would consider this criterion satisfied by a “plain language” description of: 1) “the purpose or intended use of the software function”, 2) “the intended user”, 3) “the inputs used to generate the recommendation (e.g. patient age and sex)”, and 4) “the basis for rendering a recommendation”. While a plain language description of these factors will provide valuable context for the CDS product, a greater level of detail is needed to assess whether an HCP would or would not be overly dependent on such CDS software. CDS with AI functionality, for example, would require not just a simple listing of data inputs, but a detailed description of key components used to build machine learning (ML) models, including sources of structured and unstructured data, degree of interoperability, data models used, informatics pipelines built, etc. We strongly recommend that the fourth criterion of Non-Device CDS require both plain language and detailed information about the underlying functionality, algorithms, and other core components.
The guidance should address potential software-related inconsistencies between product risk and patient safety risk. The FDA is making risk stratification a key part of the regulatory process for digital health technologies, tying the level of regulation to the type of clinical condition addressed (e.g. non-serious, serious, critical). Prior research has demonstrated that unexpected software flaws can cause even low-risk devices to become the source of high-risk safety recalls.1 For example, the FDA database described a Total Parenteral Nutrition (TPN) software product that was previously exempt from FDA review and yet became a high-risk Class III product recall.1 Despite this, the guidance document lists TPN software as representative of a Non-Device CDS function that would be excluded from regulation. We strongly recommend that the FDA clearly explain how the existing risk stratification approach will handle situations where CDS software flaws amplify patient safety risks.
The guidance should explain how patient populations will be protected from the growing volume of CDS software. Digital health software is beginning to reach a level of scale, scope, and complexity similar to that of any “blockbuster” drug. Just as millions of patients must be protected from the flawed manufacture, labeling, or surveillance of drugs; adequate safeguards are similarly required to prevent the design, development, and distribution of flawed or inaccurate CDS software that could harm millions of patients. Given the FDA’s initiatives involve software in its many forms, from the Digital Health Precertification Pilot, to frameworks for leveraging Real-World Evidence or AI/ML-based Software as a Medical Device, a robust regulatory approach for software that addresses patient safety at scale will be essential:
- Given the critical nature and rapid development lifecycle of CDS software, how will software flaws that pose a risk to patient safety be effectively monitored, detected, and addressed in a timely manner?
- How would a typical “recall” be practically implemented for CDS software found to be a serious risk to patients?
Thank you for the opportunity to comment on this draft guidance concerning regulation of CDS software.
National Center for Health Research can be reached at info@center4research.org or at (202) 223-4000.
Reference
- Ronquillo JG, Zuckerman DM. Software-Related Recalls of Health Information Technology and Other Medical Devices: Implications for FDA Regulation of Digital Health. Milbank Quarterly 2017;95:535–553. https://www.ncbi.nlm.nih.gov/pmc/articles/pmid/28895231/