FDA regulation of clinical decision support software

INTRODUCTION

As the dust clears from the Food and Drug Administration's (FDA) release of its long-anticipated Final Guidance on Mobile Medical Applications in September 2013 (MMA Final Guidance),¹ the attention of industry and regulatory actors may turn to a significant health technology area explicitly excluded from the MMA Final Guidance—clinical decision support (CDS) software. The FDA plans to release a separate guidance document on CDS software,² but until then, manufacturers of CDS software remain in a gray area without clear marketing pathways. However, recent recommendations by the working group established under the Food and Drug Administration Safety and Innovation Act of 2012 (FDASIA) propose a risk-based regulatory framework that the FDA must take into consideration in its CDS software guidance.³

CLINICAL DECISION SUPPORT SOFTWARE: REGULATION MUST BALANCE SAFETY AND INNOVATION

Clinical decision support (CDS) software is loosely defined as any application that analyzes data to help health care providers make clinical decisions.⁴ CDS software is meant to enhance health outcomes by providing clinicians and patients with individualized application of medical knowledge, provided by an intelligently organized and filtering data processor.⁵ Examples include computerized alerts (drug–drug interactions and allergy warnings), patient data reports, documentation forms, diagnosis advice from integrated reference information, and other workflow/administrative tools to enhance accurate and timely diagnoses.⁶ Current uses of CDS software are reactive (to possible adverse events), but future versions of software may involve analyses of cost and clinical appropriateness. The advantages of CDS software are numerous: increased quality of care among geographically separated members of a single health care team,⁷ avoidance of medical errors,⁸ increased efficiency (eg, using electronic prescriptions and computerized physician order entry or CPOE),⁹ improved drug compliance,¹⁰ and utilization of proper preventive services.¹¹

However, medical and legal practitioners agree that finely crafted regulation is necessary, as evidence of the risks has emerged from some health information technology (HIT) vendors (ie, those who have voluntarily registered their products as devices and reported adverse events).¹² As a result, the FDA has received 260 reports of HIT-related malfunctions with the potential for patient harm (including 44 injuries and 6 deaths).¹³ The reported adverse events fall into four categories: (1) errors of commission such as accessing the incorrect record or overwriting information; (2) errors of omission or transmission in which patient data may be lost; (3) errors in data analysis, including medication dosing errors; and (4) incompatibility between systems, which lead to any of the first three types of errors.¹⁴ Alert fatigue may create a nuisance for medical practitioners, leading to under-reliance on systems.¹⁵ Transparency of the processes underlying data output is also key; physicians must be able to identify an error in the system by cross-checking outputs with their personal knowledge. And of course, physicians themselves are prone to human error. The Food and Drug Administration Safety and Innovation Act of 2012 (FDASIA) workgroup acknowledged that when ‘even serious safety-related issues with software occur, [there is] no central place to report them to, and they do not generally get aggregated at a national level’.¹⁶

However, regulating the industry too strictly would be problematic, as inflexible regulations could stifle innovation and decrease the local applicability of CDS software.¹⁷ These software systems must often be integrated individually with each health care organization (individual hospitals or clinics), creating a comprehensive electronic health record system.¹⁸ Given the vast diversity of systems, and the lack of interoperability among them, a single risk framework is unlikely to be applied consistently across health care organizations. The lack of a standard set of functionalities that each health care setting is required to maintain is a source of variability among different software systems. Variability, in turn, has served as a barrier to regulation.¹⁹ How should the FDA regulate such a diverse array of software implementation, given that it has had little success regulating other types of software in the medical field?²⁰

FDA CONSIDERING PROPOSED FRAMEWORKS FOR REGULATING HIT

Last year, the Bipartisan Policy Center (BPC) conducted research to assist federal agencies in developing an appropriate oversight framework for HIT, including CDS software.²¹ The FDA has referenced the BPC report in its HIT working group presentations, and was ‘reportedly receptive to the center's framework’.²² The BPC divided HIT into three categories based on risk of potential harm and corresponding recommended level of oversight: traditionally regulated medical device software, clinical software (including CDS), and administrative or non-clinical software.²³ The BPC recommended that clinical software, given its lower risk profile, be subject to a new oversight framework that would take into account factors such as the level of risk of potential harm, the degree of direct clinical action on patients, the opportunity for clinician intervention, and the nature and pace of development.²⁴ The BPC proposed a four-element oversight framework for CDS software that involves adherence to standards for assuring patient safety; support for implementation of such standards; developer, implementer, and user participation in patient safety monitoring; and aggregation and analysis of data to identify trends and mitigate future risk.²⁵ Industry groups such as the mHealth Regulatory Coalition and software companies have expressed approval of this approach, emphasizing the importance of interoperability of software systems, the indirect involvement of HIT with patient care, and the unique shared responsibility for these priorities spread among manufacturers, providers, and end-users.²⁶

FDASIA calls for the Secretary of the Department of Health and Human Services, acting through the Commissioner of Food and Drugs [in consultation with the Office of the National Coordinator (ONC) for HIT and the Chairman of the Federal Communications Commission (FCC)], to report on a risk-based regulatory pathway relating to HIT by January 2014.²⁷ The FDASIA HIT Policy Workgroup, established under the ONC's HIT Policy Committee (HITPC), published their recommendations for a regulatory framework in September 2013, the culmination of a series of meetings among industry and government experts. The Taxonomy subgroup suggested that HIT be divided into two categories: those ‘Subject’ and ‘Not Subject’ to a risk-based regulatory framework.²⁸ Categorization would be based on a decision tree functionality question: ‘Is use intended to inform or change decision-making about initiating, discontinuing, modifying, or avoiding care interventions or personal health management?’²⁹ Examples of out-of-scope product types include claims processing software, health benefit eligibility software, general purpose communication applications (eg, email and paging) used by clinicians, cost-effectiveness software, and disease registries. These products would fall under the existing regulatory framework.³⁰

According to the workgroup's descriptions, the risk framework for in-scope products may be determined by the purpose and intended use of software, severity and likelihood of possible injury, transparency of software operation and sources of content, the use as part of a comprehensive system, the possibility of clinician mitigation, and network connectivity.³¹ These factors suggest that even within the category of CDS software, all products will not be regulated under a single standard. In fact, the workgroup suggested that the FDA explain ‘which forms of clinical decision support software it regulates’.³² The workgroup was clearer in some of its recommendations regarding how to regulate low-risk categories, though the definitions of low-risk products are left to the agencies.³³ The group recommended that FDA do not use its premarket approval/clearance requirements for lower risk categories and only low-level regulations for low-risk HIT products; for example, lower risk HIT could also be exempted from good manufacturing practice requirements.³⁴ Finally, consistent with the FDA's ramp-up of post-market surveillance in other areas, the FDA is encouraged to create a ‘new approach that reflects shared responsibility across users, producers, and across regulatory agencies’.³⁵ Such post-market surveillance would include standard formatting of adverse event reports, post-implementation testing, and a system that would facilitate aggregation of safety issues at a national level.³⁶

A starting premise for future policy decisions is that the lines between the various agencies’ responsibilities must be clearly drawn. The same device could be configured in such a way that both ONC and FDA would have responsibility for the interface. Coordination between the FCC and FDA would also be necessary for medical devices brought separately before each agency. The workgroup recommended that coordination be transparent and consistent, and that public and/or private sector effort could develop a public process for customer rating of HIT to enhance transparency.³⁷

RECENTLY INTRODUCED SOFTWARE ACT AND PROTECT ACT THREATEN THE DEVELOPMENT OF A COHERENT AND COMPREHENSIVE POLICY

A possible wrench in the development of HIT policy by the FDA is the October 2013 Sensible Oversight for Technology Which Advances Regulatory Efficiency Act of 2013 (‘SOFTWARE Act’), which was introduced in the House of Representatives.³⁸ The bill would amend the Food Drug and Cosmetic Act (FDCA) and seeks to ‘provide regulatory clarity regarding mobile medical applications, clinical decision support, electronic health records and other healthcare related software’.³⁹ The bill creates three categories of software: clinical software, health software, and medical software.⁴⁰ Under this proposed regime, neither clinical nor health software would be subject to regulation.⁴¹ Clinical software, which would include clinical decision support software, is any

software intended for human or animal use that captures, analyzes, changes, or presents patient or population clinical data or information and may recommend courses of clinical action, but does not directly change the structure or any function of the body of man or other animals and is intended to be marketed for use only by a health care provider in a health care setting.⁴²

Proponents of the bipartisan legislation claim that it would walk the line between promoting safety while permitting for innovation.⁴³ However, other legislators and industry representatives are concerned that the Act is both incomplete and too far-reaching.⁴⁴

Critics of the SOFTWARE Act point out the infeasibility of this three-category system, given the interoperability of systems and wide variability within these categories.⁴⁵ The categorization of software contradicts the trend of integration of health technology into efficient, streamlined systems. More importantly, certain products that could be classified under clinical or health software should be regulated due to their high risk in certain contexts; for example, a programmed diagnostic tool that recommends certain treatment approaches to a particular patient could be of high risk depending on the patient's medical condition. At the same time, the legislation is purportedly incomplete.⁴⁶ The drafters of the legislation give no reason for dividing software into three categories but only regulating one of them. Thus, ‘[t]he legislation as it is currently constructed creates new categories of health information technology but then does not answer the question of how those categories should be regulated’.⁴⁷ Moreover, the legislation would likely take regulatory power away from the FDA.⁴⁸

From the perspective of patient safety, the Preventing Regulatory Overreach to Enhance Care Technology (‘PROTECT Act’), a companion to the SOFTWARE Act that was introduced on 10 February 2014 by Senators Deb Fischer (R-Neb.) and Angus King (I-Maine), is more alarming.⁴⁹ The Senate bill would completely remove some high-risk CDS software (including software used to make complex medical decisions) from the FDA's regulatory jurisdiction.⁵⁰ Instead, the National Institute of Standards and Technology would have oversight responsibility for clinical software. While the PROTECT Act implies that FDA overreach is stifling innovation in the industry, critics of the legislation point out that the FDA has much more experience in creating technical standards, and is well positioned with industry experts to obtain input in order to do so.⁵¹

As long as the FDA delays releasing the draft guidance with respect to CDS software, the regulatory pathway to marketing CDS software, and HIT generally, remains unclear. The FDA has been reluctant to define its policy with respect to determining which software programs will be considered a device, or as to whether a device will then be subject to premarket clearance and review.⁵² Manufacturers and legal consultants will have to continue to exercise judgment in determining the likelihood that the FDA will require premarket clearance or review for their particular products.⁵³ In the meantime, practitioners and industry experts should be on the lookout for public comment solicitations once the FDA releases its draft guidance on CDS software.