The 21st Century Cures Medical Software Provisions: Additional Clarity for Digital Health, but Also More Questions
Key Points 
- Although the Cures medical software provisions largely align with FDA's current policies, certain of the Cures exemptions may be broader than those under current agency policy.
- Many clinical decision support functions remain vulnerable for FDA regulation as medical devices.
- FDA retains several avenues for applying medical device requirements to exempted medical software functions.
On December 13, the President signed into law the 21st Century Cures Act (“Cures”), which reforms many aspects of Food and Drug Administration’s (FDA) oversight of medical products and authorizes funding to support the Cancer Moonshot, the Precision Medicine Initiative, efforts to combat opioid addiction, and initiatives to improve mental health. It is a major accomplishment to pass such wide-ranging FDA legislation outside the five-year cycle of user fee reauthorizations.1 Section 3060 of Cures, “Clarifying Medical Software Regulation,” was one of the numerous FDA-related provisions relating to medical device regulation, and it is the focus of this alert. This provision identifies software functions that will not be considered medical devices for purposes of the Federal Food, Drug, and Cosmetic Act (FDCA), and specifies situations in which FDA may nevertheless exercise authority over these types of software.
Section 3060 affirms much of FDA’s current approach to digital health, as articulated in FDA guidances and applied by the agency in the context of individual product submissions, presubmission meetings and informal inquiries.2 Nevertheless, Section 3060 appears to depart from FDA’s current policy in a number of significant respects. In particular:
- Certain software functions that seemingly were medical devices under the FDCA, or that were potentially devices based on FDA guidances, appear to fall outside of Section 3060; examples include certain health and wellness functions and certain data transfer and monitoring functions.
- At the same time, Section 3060 appears not to exempt other software functions that stakeholders might have expected would be exempt from regulation as a medical device; in particular, certain clinical decision support (CDS) functions appear not to be exempted in Cures, although FDA could nevertheless determine that some of these functions either are not devices under the FDCA or should be subjected to enforcement discretion.
More broadly, it remains to be seen whether the detailed distinctions in Section 3060 will translate into clear and predictable lines of regulatory oversight, given the growing diversity of digital health solutions.
Background
The discussions that ultimately resulted in the enactment of Cures began approximately three years ago, and FDA regulation of digital health software was a key early focus for stakeholders. The SOFTWARE Act was introduced in the House in October 2013,3 and the MEDTECH Act was introduced in the Senate in April 2015.4 These followed the inclusion in the Food and Drug Administration Safety and Innovation Act of 2012 (FDASIA) of a requirement for the issuance of a federal framework for oversight of health IT. The common theme among these efforts was a desire to provide greater clarity and certainty to developers of digital health solutions with regard to FDA regulatory requirements and to avoid unnecessary regulation of lower-risk, health-related software.
Between the initial introduction of the SOFTWARE Act and the MEDTECH Act, and last week’s enactment of Cures, FDA released or updated several foundational policies addressing core aspects of digital health products. In April 2014, FDA, along with the Federal Communications Commission and the Office of the National Coordinator for Health Information Technology (ONC), finalized the FDASIA Health IT Report.5 FDA issued its final guidance on mobile medical applications in September 2013, and then updated it in February of 2015.6 That month, FDA also issued guidance announcing a policy of enforcement discretion towards medical device data systems (MDDS), medical image storage devices, and medical image communications devices.7 Finally, in 2016, FDA issued final guidance addressing general wellness applications.8 Section 3060 of Cures, “Clarifying Medical Software Regulation,” addresses each of the specific topics of the aforementioned FDA guidances—mobile apps, general wellness functions, and MDDS—but also addresses electronic health records CDS. CDS is probably the most significant aspect of digital health still awaiting guidance or other formal policy clarification from the agency.
Section 3060 amends the FDCA by adding a new subsection to Section 520 that provides for five categories of software to which the statutory definition of a device in Section 201(h) does not apply. Under Section 201(h), a device is defined 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.9
As a result, functions that fall within one or more of those five categories would not be a medical device subject to FDA oversight. A product with multiple functions would potentially be subject to categorization as a device based on its other, nonexempt function(s).10
Section 3060 also provides other general standards and clarifications for FDA’s regulation of such software, including a reservation of authority for FDA and a process for FDA to “claw back” certain software functions into the device definition. Each of the five software exemptions from the device definition is analyzed below, as are the treatment of multifunction products, the “claw back” provision and the reservation of FDA authority.
Analysis of Exempt Software Functions
Administrative Software
The first exemption is for software functions intended “for administrative support of a health care facility . . . ,” such as billing, claims, and scheduling. This exemption appears to be consistent with FDA’s current approach, as expressed in the Draft Health IT Framework and in the Mobile Medical Apps Guidance.11 Moreover, the description of this category is generally understood to fall outside of the existing definition of device in Section 201(h).
Software to Support a “Healthy Lifestyle”
The second exemption addresses software for “maintaining or encouraging a healthy lifestyle.” According to the exemption, software intended to assist with “maintaining or encouraging a healthy lifestyle” is not a device, so long as it “is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.” FDA’s General Wellness Guidance (“Guidance”) describes products that will not be subject to device regulation as those having an intended use for “maintaining or encouraging a general state of health or a health activity,” or “that relates the role of healthy lifestyle with helping to reduce the risk or impact of certain chronic diseases or conditions and where it is well understood and accepted that healthy lifestyle choices may play an important role in health outcomes for the disease or condition.” By and large, this exemption appears to track FDA’s existing policy. Moreover, the caveat in the exemption—that the function may not be related to diagnosis, cure, mitigation, prevention or treatment—aligns with the applicable criterion for a device under the existing statutory definition in Section 201(h). In at least two respects, however, the “healthy lifestyle” exemption in Section 3060 potentially excludes software products that would otherwise be subject to regulation under the Guidance and the FDCA.
First, the Guidance applies only to general wellness products that are “low risk.” Thus, under the Guidance, a general wellness product might still be subject to device regulation if, despite being intended for general wellness, the product is invasive, implanted, or involves “an intervention or technology that may pose a risk to the safety of users . . . if specific regulatory controls are not applied ….”12 The Cures provision does not include the low-risk caveat. It is unclear, however, whether in practice any software intended only for maintaining a healthy lifestyle would present more than a low risk.13 (Furthermore, as discussed below, FDA does have authority under Section 3060 to regulate exempted functions if they present the level of risks associated with Class III devices).
Second, software could be developed that is intended for maintaining or encouraging a healthy lifestyle, and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition, but that is “intended to affect the structure or any function of the body.” A structure/function product that does not achieve its primary intended purposes through chemical action is a device under section 201(h). Although it may be difficult to identify an example at this time, “structure/function” software for general wellness could conceivably fall within Section 3060, whether or not it would be exempted under the Guidance. The Guidance indicates that certain “Claims that address a specific body structure or function” are subject to enforcement discretion, while claims relating to restoring a structure or function are not. It is not clear whether the Guidance’s reference to “addressing” structure/function is intended to be synonymous with “affect[ing]” structure/function (other than by restoring structure or function), but, in any event, Section 3060 seemingly extends to any structure/function claim relating to a healthy lifestyle that is unrelated to the diagnosis, cure, prevention, mitigation or treatment of disease.
The more immediate and definitive effect of this statutory exemption is to confirm that many functions falling within the Guidance are not devices, as opposed to being subject to enforcement discretion. In the Guidance, FDA explained that it “does not intend to examine low risk general wellness products to determine whether they are devices within the meaning of the [FDCA] or if they are devices, whether they comply with the premarket and post-market regulatory requirements for devices ….”14 In other words, FDA clarified that its policy was not to subject qualifying wellness products to device requirements, but it did not opine as to whether these products were not devices, or were devices but were being granted enforcement discretion. Cures answers that question: many, if not most, of these wellness functions are not devices—so long as their intended use is within the parameters of the exemption (and subject to the “claw back” and reserve provisions analyzed below).
Electronic Patient Records
The Cures software provision also exempts certain electronic patient records. The provision includes three criteria. The criteria appear to exempt certain functions generally considered to be devices up to now, but they also leave many types of patient record software subject to device regulation (i.e., they might or might not constitute devices based on the pre-existing Section 201(h) definition).15 Functions intended “to serve as electronic patient records, including patient-provided information, to the extent that such records are intended to transfer, store, convert formats or display the equivalent of a paper medical chart” are not devices if three conditions are met:
- “such records were created, stored, transferred, or reviewed by health care professionals, or by individuals working under supervision of such professionals;”
- “such records are part of health information technology that is certified” by the ONC; and
- “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.”
Despite some potential ambiguity, the various capabilities described in the lead-in of the exemption all appear intended to relate to “the equivalent of a paper medical chart.” In other words, a qualifying function may be intended to transfer, store, convert formats of or display information, but, in each case, the function must be performed on “the equivalent of a paper medical chart.” The provision could be read to include functions that “transfer, store, [or] convert formats” more generally, or “display the equivalent of a paper medical chart.” In other words, the paper medical chart reference could be interpreted as relating to only “displaying,” which would potentially allow for the transfer, storage or conversion of medical device data. That does not appear to be the intent, however, given the existence of a separate exemption that relates to MDDS and indicates that the electronic patient record exemption applies solely to digitizing paper medical charts.
MDDS
The penultimate exemption appears designed to track the device classification known as MDDS. MDDS electronically transfer, store, convert from one format to another or display medical device data. After classifying MDDS in 2011,16 FDA ultimately finalized a policy of enforcement discretion toward MDDS in 2015.
In keeping with FDA’s MDDS definition, the Cures exemption covers software “for transferring, storing, converting formats, or displaying clinical laboratory test or other device data . . . unless such function is intended to interpret or analyze” such data. Much like the exemption for software supporting a healthy lifestyle, this exemption has the effect of making MDDS functionality, which, up to now, has been a medical device but granted enforcement discretion, not a device at all. Moreover, the exemption appears to be broader than FDA’s MDDS definition, meaning that certain functions relating to device data transfer, storage and conversion that are currently subject to active regulation (i.e., they do not fall within the scope of MDDS enforcement discretion) would no longer be devices either.
In particular, FDA precludes an MDDS from being used for “active patient monitoring.”17 Whether the Cures exemption would include active patient monitoring is unclear, because each of the exempted capabilities themselves could be used in the context of active patient monitoring, or not. The issue of “real-time” or “active” patient monitoring has been particularly challenging in the aftermath of FDA’s MDDS classification and subsequent exercise of enforcement discretion. FDA has cleared numerous types of monitoring software, but other monitoring software is marketed without FDA clearance—sometimes specifically for active monitoring. FDA has concerns about software that will be relied upon for monitoring patients with acute conditions and for whom the timely and accurate transmission of data may be critical to their well-being and to ensuring appropriate and timely treatment. If Section 3060 is interpreted to exempt MDDS-like functionality, but is intended to support “active” monitoring of the type that FDA believes should be subject to regulatory oversight (including premarket review), FDA would then need to invoke the “claw back” process in the legislation or its “reserve” authority, both of which are analyzed below.
CDS
The final exemption is designed to address some aspects of what is commonly captured under the catch-all phrase “clinical decision support”. It is probably not a coincidence that, just as this has been a complicated category for FDA to address, the language of this exemption is the most complex of the five. Under the exemption, a software function is not a device if (1) it is not intended for certain uses, and (2) it is intended for each of three uses (all three must be met).
First, a function potentially qualifies for this CDS exemption, unless it “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 . . . .” Although a signal acquisition system is not defined, in this context, it apparently refers to a wearable sensor or other instrument that obtains data from the human body. Thus, the CDS exemption might not extend to software that analyzes data derived directly from the body via an in vitro diagnostic (IVD), sensor or other instrument; more generally, this could suggest that the exemption does not apply to software that analyzes data derived directly from a medical device. Furthermore, as will become apparent from the discussion of the three mandatory criteria immediately below, the exemption appears to contemplate “back-end” analytics performed on data or other information after the data has been incorporated into a patient record or into a provider’s databases. Software that analyzes data directly from an IVD or sensor would potentially remain subject to device regulation, to the extent that such software met the definition in Section 201(h) and FDA opted to exercise active regulation of it.
The three mandatory purposes that a qualifying function must have are also relatively restrictive. To qualify, an exempt CDS must have the purpose of:
(1) “displaying, analyzing, or printing medical information about a patient or other medical information ...;”
(2) “supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition;” and
(3) “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 third criterion is particularly notable, because it epitomizes the challenge in attempting to differentiate between a clinician making a treatment decision that resides sufficiently within the practice of medicine and software performing relatively definitive analyses to constitute “use in the diagnosis or cure, mitigation, treatment, or prevention of disease . . . .” CDS tools currently in use or in development provide varying levels of transparency into the tool’s algorithms, weights and inputs. Their outputs are couched in different levels of confidence and with a range of disclaimers about how the outputs are to be used.
At the risk of parsing the language too finely, this provision suggests that the characterization of the output of a CDS tool is less significant than the transparency of the tool itself and its intended use within a particular treatment environment. First, the provision refers to “recommendations” multiple times; this implies that a nondevice CDS tool may indeed characterize its output as a “recommendation,” rather than resort to a less definitive term, such as a “suggestion” or “consideration.” On the other hand, the tool must “enabl[e] such health care professional to independently review the basis” for the recommendation. With the ever-increasing complexity of clinical software algorithms and the growing trove of data inputs, it is unclear what degree of expertise and training will be required of a clinician, and what amount of transparency will be necessary with respect to a CDS tool, to “enabl[e]” the clinician to “independently” review the output’s rationale. An even more subjective element of the provision is that the features enabling clinician independent review need to be sufficiently robust so “that it is not the intent that” the clinician “rely primarily” on the recommendations to make a diagnosis or treatment decision.
Analysis of Generally Applicable Provisions
Three other aspects of Section 3060 that are generally applicable merit separate discussion, because all three will fundamentally impact the scope of the five specific exemptions and how they are applied in practice.
Multi-Function Products
For products with multiple functions, including one software function exempted under the provision and one function that is not exempted under the provision that meets the definition of a device, Section 3060 provides that FDA “shall not regulate the software function” that is exempt, but, when assessing the safety and effectiveness of the product’s non-exempt device function, FDA “may assess the impact that the software function or functions . . . have on such device function or functions.”18 This is consistent with FDA’s general approach, since FDA would consider the impact that any accessory or component intended to be used with the device would have on the proper and safe functioning of such device.
What this provision does not address is how to assess the contours or boundaries of a “product” that is not a physical device. A digital platform or system may run any number of applications, some of which may be used as a medical device. However one chooses to define the “product” for this purpose, the ongoing challenge for FDA and the regulated industry is to determine an appropriately dynamic method of assessing potential impact on the proper functioning of medical device software, and to identify and address threats posed by other applications on a shared system, which might not be anticipated by, or under the control of, the maker of the medical device software. To ensure safety and effectiveness in this context, there is a need for a functional and practical approach that might not be conducive to a bright line standard.19
FDA “Claw Back” and Reservation of Authority
The Cures provision grants FDA the discretion to “claw back” into the device definition certain of the exempted software functions if the agency finds that “use of such software function would be reasonably likely to have serious adverse health consequences,” after issuance of notification with rationale and a proposed order, followed by a comment period and issuance of a final order. This authority applies only to functions exempted as electronic patient records, MDDS or CDS; it is not available for exempted administrative functions or “healthy lifestyle” functions. Notably, this claw back provision is premised on safety concerns—“serious adverse health consequences”—and not effectiveness concerns. Although the ineffectiveness of any product, including a software product, could have adverse health consequences, it may be difficult for FDA to make a case that ineffectiveness is reasonably likely to have “serious” adverse health consequences. More broadly, the process for exercising this authority is fairly cumbersome and might not allow for a timely agency response to particular concerns.
Section 3060 also clarifies that FDA maintains certain authorities, notwithstanding the exemptions provided. Perhaps most noteworthy among these provisions is the reservation of authority for FDA to “regulate software as a device … if such software meets the criteria under section 513(a)(1)(C).” That is a reference to the FDCA criteria for classification of devices under Class III, subject to premarket approval. Conceivably, FDA could determine that an otherwise exempt software function falls under this reserve authority more readily than the agency could satisfy the substantive and procedural requirements of the “claw back” clause. For example, FDA could determine that a particular software function presents a “potential unreasonable risk of illness or injury”20 under Section 513(a)(1)(C), even if the agency is unable to demonstrate that the function is “reasonably likely to have serious adverse health consequences.”
Alternatively, if FDA had a concern that an exempt software function should be subject to regulation, under Section 513(a)(1)(C), FDA could determine that the function cannot be classified as a Class I device or a Class II device, because “insufficient information exists to determine that” application of general controls or application of special controls, respectively, would “provide reasonable assurance of safety and effectiveness of the device.”21 Under the FDCA, a device that cannot provide a reasonable assurance of safety and effectiveness under one of those two circumstances falls within Class III. In other words, absent an examination of how general or special controls could provide a reasonable assurance of safety and effectiveness—through classification as a Class I or Class II device and compliance with the designated general and/or special controls—“insufficient information” would exist for a function to fall outside of Class III. Conceivably, FDA could take the position that the sponsor of such a product would need to demonstrate that general or special controls would provide reasonable assurance of safety and effectiveness in order to avoid regulation as a device. Although this would be a potentially aggressive reading of Section 3060, it may be a more plausible way for FDA to address a safety or efficacy concern than invoking the “claw back” provision.
Contact Information
If you have any questions regarding this alert, please contact the Akin Gump Strauss Hauer & Feld lawyer with whom you usually work or:
|
Nathan A. Brown |
Marlee P. Gallant |
1 It is not uncommon for Congress to pass FDA-related legislation. Outside of the user fee reauthorization packages, however, these “off-cycle” laws have generally focused on discrete issues, frequently motivated by particular public health concerns. See, e.g., The Drug Quality and Security Act of 2013, Pub. L. No. 113-54 (passed in response to a meningitis outbreak associated with medications prepared by a compounding pharmacy). This year, Congress will take up reauthorization of most of the prescription drug, medical device, generic drug and biosimilar user fee programs, which otherwise expire on September 30, 2017.
2 For example, FDA maintains an email address for informal inquiries concerning the classification of mobile medical applications.
3 H.R. 3303, introduced Oct. 22, 2013.
4 S. 1101, introduced Apr. 27, 2015.
5 FDASIA Health IT Report: Proposed Strategy and Recommendations for a Risk-Based Framework (Apr. 2014).
6 FDA, Mobile Medical Applications: Guidance for Industry and FDA Staff (Feb. 9, 2015).
7 FDA, Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices: Guidance for Industry and FDA Staff (Feb. 9, 2015).
8 FDA, General Wellness: Policy for Low Risk Devices: Guidance for Industry and FDA Staff (July 29, 2016).
9 FDCA § 201(h).
10 See Cures Section 3060(a), adding Section 520(o)(2) to the FDCA. Note that Section 3060 also clarifies that accessories are to be classified based on their own intended use, notwithstanding the classification of any devices with which the accessory is intended for use. See Cures Section 3060(c), adding Section 513(b)(9) to the FDCA.
11 Mobile Medical Apps Guidance at 21 providing as an example of a mobile app that is not a medical device, “mobile apps that automate general office operations in a health care setting and are not intended for use in the diagnosis of disease or other conditions….).
12 General Wellness Guidance at 5.
13 The General Wellness Guidance is not restricted to software, and the prototypical examples of a general wellness product that are not low risk are likely to be physical sensors or other wearables that physically interact with the body, thereby posing potential risk. Such a sensor might be regulated as a device, even if the software that uses the sensor’s data to support general wellness is not considered a device. Unlike the Guidance, the Cures exemption is specific to software. As a practical matter, it is unclear whether the maker of a wellness product comprising some type of physical sensor and software functionality would receive any additional advantage from Section 3060: the software function could take advantage of the general wellness exemption, but the physical component likely could not and thus could still be assessed by FDA under the General Wellness Guidance for a determination of whether it is low-risk.
14 General Wellness Guidance at 2 (footnote omitted).
15 Nevertheless, many electronic patient record functions would not appear to meet the definition of Section 201(h), and FDA has not indicated that it believes electronic patient record functions constitute medical devices.
16 76 Fed. Reg. 8637 (Feb. 15, 2011).
17 See 21 C.F.R. § 880.6310(a)(2) (“This identification does not include devices intended to be used in connection with active patient monitoring.”).
18 Cures § 3060(a).
19 This source of confusion might or might not be compounded by the introduction in Section 3060 of the concept of a “function.” Section 3060 exempts certain “functions” that are “intended” for specified uses. The FDCA’s device definition in Section 201(h) refers to an “instrument … or other similar or related article” that is “intended for use” as specified. The word “function” was probably used in Cures to avoid adopting one of the words used in the device definition (such as instrument, contrivance, or article), which might have implied that the exempt functions indeed met the definition of device notwithstanding the Cures provision. Ultimately, the introduction of the new concept of a “function” risks blurring the distinction between product claims as the primary measure of intended use, and functionality of the product, which is generally not the proper measure of intended use.
20 FDCA § 513(a)(1)(C)(ii)(II).
21 Id. § 513(a)(1)(C)(i)(I) & (II).
Authors
