By: Suzan Onel[*]
On December 13, 2016, President Obama signed the 21st Century Cures Act (Public Law No. 114-255) (“the Act”) into law. This sweeping healthcare legislation includes many provisions intended to increase medical research funding and improve the U.S. Food and Drug Administration’s (“FDA”) review and approval of drugs and medical devices. Among its medical device provisions, the Act amends the “device” definition under the Federal Food, Drug, and Cosmetic Act (“FDCA”), to exclude specific kinds of medical and decision support software from FDA’s jurisdiction.
This legislative exclusion is important because it effectively resolves the compliance conundrum facing companies selling certain low risk software products into the healthcare industry. Prior to the passage of the Act, the choice for companies that sell hardware or software products that transfer, store, convert or display medical device data or images was either to follow, at their own risk, FDA’s guidance documents which state that the Agency does not intend to actively enforce the device requirements against these products, or to follow the applicable medical device regulations, which impose specific requirements on the manufacturer and may be unevenly implemented across industry. With the passage of the Act, companies now have clarity across multiple categories of software products. However, questions still remain, including how will FDA apply these provisions, the scope and interpretation of the exclusions, and the interplay of the exclusions with separate provisions that grant FDA authorization to bring the excluded software back under its jurisdiction in certain circumstances.
Clarification of FDA’s Regulation of Software
Prior to the Act, FDA actively regulated software that met the “device” definition pursuant to the applicable device statutory and regulatory provisions.[1] “Software” covers a wide spectrum of products and could include stand-alone software that is intended to receive medically related data as input and to relay the results through a general purpose computer to a health care professional or other user. Historically, some software products have been exempted from FDA’s device authority by policy or regulation, while other software products were classified under their own FDA regulations or considered “components” or “accessories” to other devices and regulated under the same controls as the underlying “parent” device.[2]
Three stand-alone software products have been the subject of particular confusion: medical image storage devices, medical image communications devices, and medical device data systems (“MDDS”). These products are the subject of FDA classification regulations and, pursuant to the medical device general controls, require establishment registration, device listing, postmarket reporting, and compliance with the Quality System Regulation (QSR).[3] Notwithstanding these regulations, in February 2015, FDA issued a final guidance stating that it intends to use its enforcement discretion not to enforce compliance with the device regulatory controls for these three types of software due to the low risk they posed to patients and the importance they played in advancing digital health notwithstanding the existing regulations.[4] While well intentioned, this guidance created uncertainty in the industry because the final guidance, by its terms, is not enforceable or legally binding; in contrast, the device regulations are legally binding and enforceable.
Software Excluded from the Device Definition
The Act provides some useful clarity. Section 3060(a) of the Act amends FDCA § 520 by adding a new subsection (“FDCA § 520(o)”)[5] that outlines five categories of software that are excluded from the device definition and therefore are exempt from FDA’s regulation. We provide below a brief summary of each category and encourage industry to review section 3060 of the Act closely to understand the nuances of each category.
The first three categories described under the new FDCA § 520(o) represent software categories that FDA has not been actively regulating as medical devices:
- Software intended for administrative support of a health care facility (FDCA § 520(o)(1)(A)),
- Software intended for maintaining or encouraging a healthy lifestyle and unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition (FDCA § 520(o)(1)(B)),[6] and
- Software intended to serve as electronic patient records to the extent that such records are intended to transfer, store, convert formats, or display the equivalent of a paper medical chart (FDCA § 520(o)(1)(C)).[7]
The fourth category of software excluded from the device definition corresponds with software previously regulated as medical devices, specifically MDDS, medical image storage devices, medical image communications devices, and laboratory information systems (“LIS”[8]):
- Software intended for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or other device, unless such function is intended to interpret or analyze clinical laboratory test or other device data, results, and findings (FDCA § 520(o)(1)(D)).
Through these provisions, Congress has provided industry with much needed clarification on the regulation of MDDS, medical image storage devices, medical image communications devices, and other similar software products intended to transfer, store, convert or display medical information by effectively codifying FDA’s intention to exercise its enforcement discretion over these products.
Interestingly, Congress also chose to exclude from the device definition a software category commonly known as “clinical decision support software” (“CDSS”):
- Software intended for the purpose of—
(i) displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);
(ii) supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and
(iii) enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient (FDCA § 520(o)(1)(E)) (emphasis added).
The level of regulation appropriate for this category of software is one that has been the subject of a tremendous amount of discussion between industry, FDA, the Office of the National Coordinator for Health Information Technology, and the Federal Communications Commission. While the Act has clearly helped elucidate the issue, vagaries remain, particularly as to the scope of the CDSS provision and how it will be applied.
Caveats and Conditions to the Software Exclusion from the Device Definition
As noted above, the Act includes several caveats and conditions to the device exclusionary language. For example, the fourth category of software excluded from the device definition relates to software intended to transfer, store, convert, or display medical information; however, this exclusion does not apply if the software function is intended to interpret or analyze clinical laboratory test or other device data, results or findings. See FDCA § 520(o)(1)(D).
The fifth category of software excluded from the device definition explicitly states that if the CDSS software is 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, it would not be exempt from the device definition. See FDCA § 520(o)(1)(E). Furthermore, this provision includes other language that is sufficiently vague that it could allow FDA to conclude that certain CDSS is not excluded from the device definition. For example, it is unclear how FDA will decide when software is used to “support or provide recommendations” to a health care professional versus directing a result. It is also unclear what standard will be used to assess whether the health care professional can “independently review the basis for such recommendations” or ensure that the health care professional does not “rely primarily” on the recommendations provided by the software to make a clinical diagnosis or treatment decision.
It is also notable that the Act includes other more broadly worded language that allows FDA to reach excluded software products when:
- Assessing the safety and effectiveness of a device with multiple functions, where at least one software function is an excluded category and at least one software function meets the device definition (FDCA § 520(o)(2));
- Use of the software function would be reasonably likely to have a serious adverse health consequence[9];
- The software is used in the manufacture and transfusion of blood and blood components to assist in the prevention of disease; or
- The software meets the definition of a Class III device under FDCA § 513(a)(1)(C).
See FDCA § 520(o)(2)-(4).
It will be some years before FDA promulgates regulations implementing the Act and, under the current administration, it may be some time before FDA issues a draft guidance to provide industry with its current thinking on how it will implement these provisions. In the meantime, industry will need to remain vigilant as to how FDA interprets these exclusions, particularly vague terms such as the intended software “function” used throughout FDCA § 520(o)(1), “interpret or analyze” under § 520(o)(1)(D), “acquire, process, or analyze” under § 520(o)(1)(E), and “independently review” and “rely primarily” under § 520(o)(1)(E)(iii).
Conclusion
For years, the medical device and software communities have had to try to reconcile FDA’s guidance documents and public statements with FDA’s statutes and regulations when evaluating whether FDA would regulate their software products as medical devices and, if so, which medical device requirements would apply. The 21st Century Cures Act helps to provide some welcome clarity by explicitly excluding certain categories of software from the statutory device definition and, therefore, FDA’s jurisdiction. However, questions remain, particularly as to certain provisions which appear to give the FDA authority to bring back under its jurisdiction some excluded categories of software.
We will continue to monitor FDA activity related to its implementation and interpretation of the new FDCA Section 520(o). In the meantime, we encourage companies to review these software provisions closely and consider the potential impact of the new law on their medical software products. We would be pleased to assist in this regard.
[*] Ms. Onel thanks Jacqueline Chan for her assistance on this Alert.
[1] The FDCA defines “device” as “an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is—(1) recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them, (2) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or (3) intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes.” FDCA § 201(h); 21 U.S.C. § 321(h).
[2] The Act also modifies FDCA § 513(b) to require FDA to classify an accessory “based on the intended use of the accessory, notwithstanding the classification of any other device with which such accessory is intended to be used.” See section 3060(c) of the Act. FDA issued a final guidance to this effect on December 30, 2016.
[3] 21 C.F.R. §§ 892.2010, 892.2020, and 880.6310
[4] See FDA Guidance, “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices” (Feb. 9, 2015).
[5] 21 U.S.C. § 360j(o)
[6] Under FDA’s final guidance, “General Wellness: Policy for Low Risk Devices” (July 29, 2016), FDA stated that it does not intend to apply its limited resources to examining products that meet the “low risk” “general wellness” definition to determine whether they are devices and whether they comply with premarket review and postmarket regulatory requirements.
[7] Software under FDCA § 520(o)(1)(C) must also meet the following requirements: (1) such records were created, stored, transferred, or reviewed by health care professionals, or by individuals working under supervision of such professionals, (2) such records are part of health information technology that is certified under section 3001(c)(5) of the Public Health Service Act; and (3) such function is not intended to interpret or analyze patient records, including medical image data, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.
[8] 21 C.F.R. § 862.2100
[9] FDA must issue a notice and proposed order to support a determination that software excluded from the device definition should be regulated due to reasonably likely serious adverse health consequences. See § 520(o)(3)(B)-(C).
Note: This post is intended to provide general background information and should not be considered legal advice.