21st Century Cures Act Provides (Some) Clarity on FDA’s Regulation of Software

by Suzan Onel and Jacqueline J. Chan

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 provisions intended to increase medical research funding and improve the 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. With the passage of these provisions, industry now has regulatory clarity across multiple categories of software products as to which ones are subject to FDA regulation. However, questions remain regarding how FDA will 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.

Software Excluded from the Device Definition

Prior to the passage of the Act, FDA actively regulated software that met the “device” definition pursuant to the applicable device statutory and regulatory provisions.¹ Historically, some medical or “health-related” software products have been exempted from FDA’s device authority by policy or regulation, while other 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.²

The Act provides some useful clarity as to what devices fall outside of FDA’s regulatory authority. Section 3060(a) of the Act amends FDCA § 520 by adding a new subsection (FDCA § 520(o))³ 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.

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)),⁴ 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)).⁵

The fourth category of software excluded from the device definition corresponds with software previously regulated as medical devices, specifically medical device data systems (MDDS),⁶ medical image storage devices,⁷ medical image communications devices,⁸ and laboratory information systems (LIS⁹):

• 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)).

The regulation of three of these software products—medical image storage devices, medical image communications devices, and MDDS—was previously the subject of conflicting regulatory provisions. These products were simultaneously subject to (1) FDA classification regulations and the medical device general controls and (2) an FDA guidance document that stated that FDA intends to use its enforcement discretion to not enforce compliance with the regulatory controls.¹⁰ Through the new provisions, Congress has provided industry with much needed clarification on the regulation of these software products 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, the fifth category of software excluded from the device definition is a 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.¹¹

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, questions 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.¹²

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.¹³ The scope of this provision is particularly unclear since the text uses “analyzes” to both exclude and include this category of software from the device definition. This provision also 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.

Notably, the Act also includes other broadly worded language that allows FDA to regulate otherwise 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;¹⁴
• Use of the software function would be reasonably likely to have a serious adverse health consequence;¹⁵
• 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).¹⁶

It likely 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 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 that appear to give FDA the authority to bring back under its jurisdiction some excluded categories of software.

We encourage companies to review these software provisions closely and consider the potential impact of the new law on their medical software products while continuing to monitor FDA activity related to its implementation and interpretation of the new FDCA Section 520(o).

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 U.S.C. § 360j(o).
4. Under FDA’s final guidance, “General Wellness: Policy for Low Risk Devices,” 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.
5. See FDCA § 520(o)(1)(C) for additional requirements.
6. 21 C.F.R. § 880.6310.
7. 21 C.F.R. § 892.2010.
8. 21 C.F.R. § 892.2020.
9. 21 C.F.R. § 862.2100.
10. FDA Guidance, “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices” (Feb. 9, 2015).
11. FDCA § 520(o)(1)(E) (emphasis added).
12. See FDCA § 520(o)(1)(D).
13. See FDCA § 520(o)(1)(E).
14. FDCA § 520(o)(2).
15. 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).
16. See FDCA § 520(o)(2)-(4).