Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act
October 4, 2019Nearly three years after Section 3060(a) of the 21st Century Cures Act amended section 520 of the Federal Food, Drug, and Cosmetic Act (FD&C Act) by removing certain software functions from the device definition in section 201(h) of the FD&C Act, FDA has released Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act (“guidance’”). The scope of this September 27, 2019 guidance document covers the 2016 amended medical device definition and its effects on four related medical device software guidance documents, which were also updated and released on September 27, 2019: 1.) General Wellness: Policy for Low Risk Devices, 2.) Mobile Medical Applications, 3.) Off-The-Shelf Software Use in Medical Devices, and 4.) Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices.
Software functions that were removed from the definition of a device include those intended 1.) for administrative support of a health care facility, 2.) for maintaining or encouraging a healthy lifestyle, 3.) to serve as electronic patient records, and 4.) for transferring, storing, converting formats, displaying data and results.
Administrative Support of a Health Care Facility
FDA has not historically considered software functions such as processing and maintenance of financial records, appointment schedules, and analysis to predict utilization to be software functions of devices.
Additionally, Laboratory Information Systems (LIS) and Laboratory Information Management Systems (LIMS) functions intended for administrative support are not considered device functions. Transferring, storing, or displaying clinical laboratory test data and results are also not considered to be within the definition of a device. As a result, section 3.2.2. of the Off-The-Shelf Software Use in Medical Devices titled “Exemption of Laboratory Information Management Systems” has been removed.
On the other hand, software functions that also analyze or interpret medical data remain medical devices under FDA’s oversight. FDA does not intend to enforce regulatory requirements for software functions that generate alarms or alerts if they do not prompt immediate clinical action because the function would be considered low-risk. An example would be a notification that a parameter is out of range but is not intended to alert a caregiver to intervene. However, software functions that analyze medical device data in order to provide a notification or flag will continue to be regulated as a device.
Maintaining or Encouraging a Healthy Lifestyle
The General Wellness: Policy for Low Risk Devices guidance document has been updated from the July 29, 2016 version (which we have previously blogged on here) to ensure consistent policy in the regulation of digital health products. One such update is the replacement of “mobile application” with “software function” in the examples listed in Section V of the guidance document. FDA also changed this section’s title to “Examples of General Wellness Products that Are Not Medical Devices and Examples of General Wellness Products that Are Medical Devices for which FDA Does Not Intend to Enforce Requirements” to show that some examples (such as a software function that plays music to “soothe and relax”) are not medical devices under 201(h) of the FD&C Act. Beyond these updates, the guidance remains largely unchanged.
Similar changes were made to the Mobile Medical Applications guidance document, which we last blogged on here. Where appropriate, “mobile application” has been changed to “software function” and the full title of the guidance, “Policy for Device Software Functions and Mobile Medical Applications,” has been modified to reflect the delineation. Some examples of mobile apps for which FDA intends to exercise enforcement discretion have been moved to examples of mobile apps that are NOT medical devices. For example, apps that track and trend exercise activity or track the quantity or quality of healthy people’s sleep patterns do not meet the amended medical device definition.
Serve as Electronic Patient Records
Software functions that are intended to transfer, store, convert formats, or display electronic patient records that are the equivalent of a paper medical chart are not devices if all the following criteria are met:
- Such records were created, stored, transferred, or reviewed by health care professionals (HCPs), or by individuals working under supervision of such professionals, (section 520(o)(1)(C)(i) of the FD&C Act);
- Such records are part of information technology certified under a program of voluntary certification kept or recognized by the Office of the National Coordinator for Health Information Technology (ONC) under section 3001(c)(5) of the Public Health Service Act (“ONC Health IT Certification Program”)12 (section 520(o)(1)(C)(ii) of the FD&C Act); and
- Such software functions are not intended for interpretation or analysis of patient records, including medical image data, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition (section 520(o)(1)(C)(iii) of the FD&C Act).
Some examples of mobile apps that were considered to be under FDA enforcement discretion have been moved to examples of mobile apps that are NOT medical devices in the Mobile Medical Applications guidance document. For example, EHR software functions certified under the ONC Health IT Certification Program are not considered to be devices. While this seems straightforward on the surface, this does not represent a least burdensome approach. To not be considered a device, EHR vendors would need to understand the requirements of and obtain ONC certification. At least for the time being, FDA does not intend to enforce compliance to the FD&C Act requirements for software functions that are not certified under the ONC Health IT Certification Program if they meet other criteria in section 520(o)(1)(C)(i) and (iii) of the FD&C Act.
On the other hand, functions that extend beyond those intended to transfer, store, convert formats, or display the equivalent of a paper medical chart, such as using a mobile device’s built-in camera to document or transfer images to supplement what would otherwise be an in person consultation between a patient and his/her healthcare provider, would be instances when FDA intends to exercise enforcement discretion.
As part of its update to the Mobile Medical Applications guidance document, FDA increases the number of examples it does not consider medical devices from five to twenty-one. It also changes an example from “assessing the need for immunization” to “documenting the need” so that the example is that of an electronic patient record and not clinical decision support software.
Transferring, Storing, Converting Formats, Displaying Data and Results
Over time, FDA’s thinking on MDDS products has evolved and we have shared our thoughts on Medical Device Data Systems (MDDS) here, here, and here during the evolution. From exercising enforcement discretion to full out declaring that software functions that meet the definitions of MDDS are no longer devices, we are hopeful FDA will better utilize its resources and focus on higher risk products.
However, what is unclear is how FDA intends to focus on a MDDS multiple function product. That is a product that may have a software function that is not considered a device and another function that is a device. For the time being, FDA stated it would not regulate the MDDS software functions in a MDDS multiple function product and has stated it intends to enforce the requirements under the FD&C Act based on its understanding of risks in these devices.
Therefore, the Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices guidance document has been modified to clarify that software functions that are solely intended to transfer, sore, convert formats, and display medical device data and results, are not devices and therefore not subject to FDA regulatory requirements, whether or not the use is for immediate clinical action. These are considered Non-Device-MDDS and is different from Device DDS, which encompasses hardware that transfers, stores, converts formats, and displays medical device data.
Overall, we appreciate FDA’s efforts to harmonize four related medical device software guidance documents. However, we look forward to seeing more clarifications such as FDA’s amended regulations to clearly identify the hardware functions that remain device functions and a list of product codes that are no longer devices subject to enforcement discretion. We also expect to see greater clarity around any risk-based criteria FDA will employ in their assessment of exercising enforcement discretion.