Free
Editorial Views  |   February 2018
Regulatory Landscape for Clinical Decision Support Technology
Author Notes
  • From Epstein Becker & Green, P.C., Washington, D.C.; and Berman Institute of Bioethics, Johns Hopkins University, Baltimore, Maryland.
  • This article has been selected for the Anesthesiology CME Program. Learning objectives and disclosure and ordering information can be found in the CME section at the front of this issue.
    This article has been selected for the Anesthesiology CME Program. Learning objectives and disclosure and ordering information can be found in the CME section at the front of this issue.×
  • Corresponding articles on pages 241, 244, 272, and 283.
    Corresponding articles on pages 241, 244, 272, and 283.×
  • Accepted for publication September 25, 2017.
    Accepted for publication September 25, 2017.×
  • Address correspondence to Ms. Javitt: gjavitt@ebglaw.com
Article Information
Editorial Views / Technology / Equipment / Monitoring
Editorial Views   |   February 2018
Regulatory Landscape for Clinical Decision Support Technology
Anesthesiology 2 2018, Vol.128, 247-249. doi:10.1097/ALN.0000000000002022
Anesthesiology 2 2018, Vol.128, 247-249. doi:10.1097/ALN.0000000000002022

“The current U.S. Food and Drug Administration (FDA) regulatory requirements for clinical decision support systems are still under development.”

Image: © ThinkStock.
Image: © ThinkStock.
Image: © ThinkStock.
×
THE articles by Kheterpal et al.1  and Liu et al.2  in this month’s issue of Anesthesiology highlight the challenges and opportunities in harnessing patient data to aid clinicians in patient management through the use of clinical decision support technologies. Although their articles focus on the use of clinical decision support in the intraoperative context, these technologies encompass a wide range of clinical settings and in the foreseeable future may extend to virtually every facet of clinical care. Indeed, by 2021, the U.S. clinical decision support market is projected to reach almost $5 billion.
In addition, editorials by Sessler3  and by Glance et al.4  rightly call for rigorous validation and transparency of clinical decision support to ensure accuracy and reliability. The current U.S. Food and Drug Administration (FDA) regulatory requirements for clinical decision support systems are still under development. The regulatory framework that will achieve the right balance between promoting innovation and protecting patients is not obvious, particularly given that clinical decision support will comprise products across of a broad spectrum of complexity and indications.
This commentary therefore seeks to provide an overview of the regulatory landscape for clinical decision support, with particular focus on the current and potential future role of the FDA, to foster discussion and encourage stakeholder input into the development of a rational and beneficial regulatory framework for clinical decision support.
The federal Food, Drug, and Cosmetics Act authorizes FDA to regulate medical “devices,” which include “articles” (including instruments, machines, implants, and diagnostic reagents) that are intended to affect the structure or function of the body or intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease. Unlike drugs, medical devices do not achieve their intended effect through chemical action in or on the body and are not dependent on being metabolized to achieve their primary intended purposes.
FDA historically has taken the position that software meeting the definition of a medical device is subject to FDA regulation, whereas in practice the agency’s regulatory attention primarily has focused on software embedded in or intended to be used in conjunction with another medical device. Although diverse in many respects, clinical decision support technologies invariably include software, either in “standalone” form (i.e., a program that is intended to be run on a general purpose computer) or as a component of or accessory to a medical device.
FDA has not developed a specific regulatory framework for clinical decision support but has discussed its future regulatory approach for clinical decision support within the broader context of health information technology (“health IT”). In response to a Congressional directive, FDA issued a report in 2014 outlining a “risk-based” approach to the regulation of health IT generally and of clinical decision support products specifically.5  In the report, the agency described clinical decision support as technology that “provides healthcare providers and patients with knowledge and person-specific information, intelligently filtered or presented at appropriate times to enhance health or health care.” Further, FDA stated that because the risks of clinical decision support are “generally low compared to the potential benefits, FDA does not intend to focus its oversight on most clinical decision support”—even if it met the statutory device definition—and instead “intends to focus its oversight on a limited set of software functionalities that provide clinical decision support and pose higher risks to patients.” Examples of clinical decision support in this latter category include computer-aided detection/diagnostic software, remote display or notification of real-time alarms (physiologic, technical, advisory) from bedside monitors, radiation treatment planning, robotic surgical planning, and control and electrocardiography analytical software.
The 21st Century “Cures Act,”†01  enacted in 2016, formalized the FDA’s risk-based approach by redefining the statutory term “device” to exclude low-risk clinical decision support technologies. Specifically, the revised definition categorically excludes certain software functions from the statutory definition of a medical device. Software functions that are not medical devices include those intended for (1) administrative support of a health facility, such as financial, billing, and claims-related software; (2) maintaining or encouraging a healthy lifestyle, such as calorie and exercise tracking apps; and (3) allowing basic storage, retrieval, and display of patient medical records.
In contrast, software functions that are intended to interpret and analyze patient records, medical images, laboratory test data, or other medical device data and/or that are intended to assist a healthcare provider in making diagnostic or treatment decisions are medical devices.†01  Depending on the level of risk posed by the software, these requirements may include prior FDA marketing authorization (either a “510(k) clearance” or “premarket approval”). The level of risk posed by a device depends on its intended use, which in turn is determined based on the manufacturer’s labeling claims for the device. Thus, in cases where a device may have multiple potential uses, the risk classification of the device is in most circumstances determined by the manufacturer’s claims and not on how a clinician uses the device in practice.
This distinction is particularly relevant in the case of medical software such as clinical decision support, where the risks of the product arise not from any physical interaction with the body but rather from how the information is used by the clinician. Thus, in evaluating the risk level of clinical decision support products, FDA is concerned about both the accuracy of the data provided and the impact the manufacturer intends for the device to have on a physician’s clinical decision-making. FDA generally considers clinical decision support products that are intended to provide adjunctive information and that do not direct a specific clinical decision to pose less risk than those that will be used as the sole basis for decision making or that provide directive clinical recommendations. For example, in the case of computer-aided detection (CAD) devices used in conjunction with breast imaging, FDA distinguishes between those that are intended solely to direct the clinician’s attention to portions of an image or aspects of radiology device data (CADe) and those that also are intended to assess disease risk, specify disease type, severity, or stage and/or recommend an intervention (CADx). Whereas CADe devices generally are class II (moderate risk), CADx devices are class III (high risk). The different risk classification in turn affects the regulatory standards for marketing authorization. Class II devices generally require 510(k) clearance. To obtain clearance, the manufacturer typically must show “substantial equivalence” to a previously marketed, or “predicate,” device. Demonstrating substantial equivalence typically does not require the submission of data from adequate and well controlled clinical investigations. In contrast, class III devices require approval of an application for premarket approval, which typically must include data from randomized controlled clinical trials demonstrating that it is safe and effective for its intended use.
Like CADe devices, the AlertWatch:OR device discussed by Kheterpal et al.1  was determined to be a class II device. The device received its first 510(k) clearance from FDA in early 2014, and an updated version received clearance in 2016. According to the device’s cleared indications for use, it is “intended for use by clinicians for secondary monitoring of patients within operating rooms and by supervising anesthesiologists outside of operating rooms.” Once alerted, “a clinician must refer to the primary monitor or device before making a clinical decision.” In the case of a supervising anesthesiologist, he or she must contact the clinician inside the operating room or must return to the operating room before making a clinical decision.
Of particular relevance to the article by Kheterpal et al.1  and commentary by Sessler,3  the cleared indications for use for the AlertWatch:OR do not include improvement of patient outcomes. Consequently the 510(k) clearance was not required to include data demonstrating that use of the device resulted in improved patient outcomes. This is a common scenario with clinical decision support products—and indeed, with more traditional diagnostics as well. Although the limited availability of patient outcomes data may be frustrating to the clinician or healthcare system seeking to determine whether or not to adopt the technology, the generation of such data is expensive and time-consuming, and requiring manufacturers to generate outcome data as a condition of initial marketing could deter, and certainly would delay, the availability of such products.
The limited number of clinical decision support devices that have gone through FDA review make it challenging to know how FDA will approach future clinical decision support devices. The 21st Century Cures Act was helpful in clarifying the types of clinical decision support products that do not constitute medical devices, but FDA guidance would provide clarity to stakeholders regarding how FDA will classify those clinical decision support devices and what design and validation requirements will be needed as part of the FDA review process. In July 2017, FDA published the Digital Health Innovation Action Plan, which lays out the agency’s “vision for fostering digital health innovation while continuing to protect and promote the public health.” The Action Plan†01  describes a voluntary pilot “precertification” program through which software developers meeting certain quality standards could launch new products with less premarket data, subject to postmarket data collection requirements and†01  commits to hiring additional FDA personnel with digital health expertise.
The Action Plan also promised new draft guidance in early 2018. Slightly ahead of schedule, on December 8, 2017, FDA issued guidance aimed at updating and clarifying the agency’s approach to CDS products in light of the Cures Act.6,7  Of particular relevance to CDS used in the perioperative setting, the guidance proposes to reduce oversight of software functions that analyze patient data and provide notification to a healthcare provider, such as through alarms or alerts. The guidance states that, although these software functions continue to meet the statutory definition of a medical device, the agency does not intend to enforce device requirements, provided that the notification does not trigger the need for immediate clinical action. In announcing the new guidance, Commissioner Gottlieb reiterated the agency’s commitment to encouraging innovation in digital health by focusing regulatory regulatory efforts on the highest risk products.†01 
The FDA’s recent initiatives will, it is hoped, provide much needed clarity to clinical decision support developers regarding the pathway to market new products. As these products enter the marketplace in ever greater numbers, it will be increasingly important for clinicians, as the users of these devices, to appreciate the limitations of FDA oversight†01  and to take these limitations into account in their use of the products. Depending on the intended use of the CDS software, it may not be subject to FDA regulation. Devices that continue to require premarket authorization may not need evidence of improved process measures or clinical outcomes depending on the manufacturer’s claims for the product.†01  Collecting data on improved measures and outcomes is expensive and time-consuming and will likely come out only after clinical decision support devices are on the market. So clinicians will need to understand what the devices are or are not intended to do and may wish to consider what role they can play in the postmarket data generation process to establish clinical utility.
Competing Interests
The author and her law firm represent medical device manufacturers, including those with an interest in developing CDS technologies, but do not, as of the publication date, represent any manufacturer referenced herein. The views expressed herein are those of the author and do not represent those of Epstein Becker & Green, P.C., Washington, D.C., or the Berman Institute of Bioethics, Baltimore, Maryland. The author is not supported by, nor maintains any financial interest in, any commercial activity that may be associated with the topic of this article.
Content added in proof.
Content added in proof.×
References
Kheterpal, S, Shanks, S, Tremper, KK . Impact of a novel multiparameter decision support system on intraoperative processes of care and postoperative outcomes. Anesthesiology 2018; 128:272–82
Liu, JB, Liu, Y, Cohen, ME, Ko, CY, Sweitzer, BJ . Defining the intrinsic cardiac risks of operations to improve preoperative cardiac risk assessments. Anesthesiology 2018; 128:283–92
Sessler, DI . Decision support alerts: Importance of validation. Anesthesiology 2018; 128:241–3
Glance, LG, Dick AW, Osler TM . Risk prediction tools: The need for greater transparency. Anesthesiology 2018; 128:244–6
FDA, FDASIA Health IT Report: Proposed Strategy and Recommendations for Risk-Based Framework, April 2014. Available at: https://www.fda.gov/downloads/AboutFDA/CentersOffices/OfficeofMedicalProductsandTobacco/CDRH/CDRHReports/UCM391521.pdf. Accessed November 15, 2017
Food and Drug Administration: Changes to existing software policies resulting from section 3060 of the 21st Century Cures Act (draft), December 2017. Available at: https://www.federalregister.gov/documents/2017/12/08/2017-26442/changes-to-existing-medical-software-policies-resulting-from-section-3060-of-the-21st-century-cures. Accessed December 11, 2017†
Food and Drug Administration: Clinical and patient decision support software (draft), December 2017. Available at: https://www.fda.gov/downloads/MedicalDevices/.../UCM587819.pdf. Accessed December 11, 2017†
Image: © ThinkStock.
Image: © ThinkStock.
Image: © ThinkStock.
×