On Tuesday, December 13, President Obama signed into law the 21st Century Cures Act. That Act previously passed both houses of Congress with tremendous bipartisan support. Widely touted as streamlining how the Food and Drug Administration (FDA or the Agency) reviews and approves drugs and medical devices, this law contains several provisions specifically addressing FDA regulation of medical software.1 Historically, FDA has viewed nearly all medical software that is used in patient care as falling within the jurisdiction of medical device regulation. However, the Agency refrained from actively regulating certain types of software. Those policies have been conveyed primarily by non-binding Agency guidance and case-by-case assessments. While consistent with FDA’s existing policies, the new law makes them much more concrete and not subject to easy modification.
The 21st Century Cures Act amends the Federal Food, Drug and Cosmetic Act (FDC Act) to explicitly exclude software functions with certain intended uses from the definition of a medical device.2
- Software intended for administrative support of a health care facility, such as processing bills and claims, scheduling, inventory management, analysis of historical data to predict utilization, and determination of benefit eligibility. Historically, these types of software have not been viewed by FDA as meeting the definition of a medical device, but the law codifies that interpretation.
- Software intended for general health and wellness that is not related to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition. Such software also likely does not fall within the historic definition of a medical device (which requires a relationship to diagnosis, cure, mitigation, prevention or treatment). At the same time, this aligns with FDA’s General Wellness guidance3, pursuant to which such software would not be examined to determine whether it constitutes a regulated medical device. Of note, the statute does not address a second category of general wellness products that are specifically associated with a particular disease or condition. Such products would, presumably, still fall under enforcement discretion under FDA’s existing guidance document. In addition, the statute, which is focused on the software function, remains silent on the overall product’s risk level, which the Generall Wellness guidance requires to be low risk in order to be eligible for enforcement discretion. Companies may thus still need to evaluate whether their general wellness products fall squarely under the statutory exemption or require the more nuanced approach offered by the guidance.
- Software intended to serve as electronic patient records, if such records are created and used by health care providers and constitute health information technology as certified under Public Health Service Act § 3001(c)(5), and they do not interpret or analyze patient records for the purpose of diagnosis or treatment. As FDA has largely refrained from regulating electronic health records in the past, despite statements that the Agency considered these to meet the definition of a medical device, the principal effect of this provision is to turn the Agency’s current approach into a statutory requirement.
- Software intended to transfer, store, convert formats, or display laboratory and device data, results, associated findings by a health care professional, and general background information about a test or device. This provision essentially describes medical device data systems (MDDS) as defined in 21 C.F.R. § 880.6310 and elaborated upon by FDA in its 2015 guidance, which considered such software to meet the definition of a medical device.4 The statute now specifically excludes MDDS from regulation as a medical device, and also defines MDDS slightly more broadly than the existing definition, which focuses solely on medical device data itself without the findings or background that might accompany it. In line with current policy, though, software intended to independently analyze laboratory or device data, results, and findings would not be part of the carve-out, which is limited to software that handles (i.e., stores, transfers, displays) data and physician opinions without contributing to the interpretive process.
- Clinical decision support (CDS) software that displays/analyzes medical information (e.g., peer-reviewed clinical studies and clinical practice guidelines) and makes recommendations for health care professionals regarding prevention, diagnosis, or treatment of a disease/condition. However, the statute places limitations on the CDS carve-out, as such software:
a. Cannot be processing or analyzing medical images (e.g., CT scans, MRIs, X-rays), data from in vitro diagnostic devices, or “a pattern or signal from a signal acquisition system” (we expect FDA will interpret this last part as referring to sensor data); and
b. Must be transparent and its recommendations reviewable, such that it does not serve as the sole basis for a health care professional’s determination regarding a particular patient. In other words, CDS that takes the place of a professional in making treatment decisions remains subject to stricter scrutiny.
This exclusion of certain CDS software from the definition of a medical device is likely the most impactful of the software provisions, as industry and stakeholders have long been waiting for clearer rules on the regulation of CDS. Further guidance will still be needed, but the guidelines established in the law provide a solid starting point.
In addition to identifying the above categories of software to be generally excluded from the definition of a medical device, the statute also addresses the not-uncommon situation of software that performs multiple functions. Where a software product has multiple functions, at least one of which does not meet the definition of a medical device, the statute instructs FDA not to regulate the function(s) subject to exemption, although specifically allows for an assessment of the impact of the non-regulated function(s) on the regulated function(s).
Importantly, the law also includes a “catch-all” provision reserving FDA authority, under certain conditions, to regulate software functions that would otherwise be excluded from the definition of medical device, if FDA finds them “reasonably likely to have serious adverse health consequences” and they have been identified as such in a final order after an opportunity for public comment.
Factors to be considered in this assessment include the likelihood and severity of patient harm from a malfunction; the extent to which the software is intended to support clinical judgment; the transparency/reviewability of any recommendation provided by the software; and the intended user and use environment. In addition, the Secretary of Health and Human Services is required, with FDA’s input, to review information on any risks and benefits to health associated with the software functions covered by the law, and to publish regular reports addressing their impact on patient safety, including best practices with respect to their use.
Finally, the 21st Century Cures Act amends the FDC Act such that accessories are to be classified based on their intended use, notwithstanding the classification of any other device with which they are meant to be used. This is in line with a 2015 draft guidance5, which updated a previous practice of always regulating an accessory in the same class as its parent device.
It is important to note that while these statutory provisions effectively exempt certain categories of software from regulation as medical devices, there remain a host of medical software products that will continue to be subject to regulation as devices, whether actively regulated or falling under enforcement direction per existing FDA guidance and policy. In addition, this statutory carve-out does not wholly void the role of the existing guidance documents, as many medical software products that fall outside the new statutory carve-out could still be considered subject to enforcement discretion. For instance, a number of mobile apps that do not fall within the types of software functions statutorily exempted from regulation under the language of the Act would likely still be subject to enforcement discretion per the mobile medical applications6 guidance.
While the language in the statute is very helpful in providing clearer guidance on what software should and should not be regulated by FDA as a medical device, it is expected that FDA will need to issue new regulations implementing some of the features of these provisions, and guidance interpreting some of the descriptions. During this process, prior Agency guidance – such as that on mobile medical applications and others referenced above – remains relevant in assessing the level of regulation likely to apply to health-related software, and the appropriate pathways for bringing these applications to the U.S. market.