FDA Calls for Comment on Non-Device Software Functions

Background of the Medical Software Functions Exclusion

Most of those in the industry do not question whether the FDA has the authority to regulate software that qualifies as a device. However, there are many intricacies in the definitions of the 21st Century Cures Act – which, in 2016, amended the definition of medical devices in the FD&C Act. Importantly, the Cures Act excluded these medical software functions from the definition of device: software functions 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,
  4. for transferring, storing, converting formats, or displaying data, or
  5. to provide limited clinical decision support.

Now, as required by the Cures Act, the FDA has put out a call for comment asking for input on the risks and benefits to health of the software functions excluded from the device definition under the Act. See the FDA’s announcement here: Development of 21st Century Cures Act Section 3060 Required Report: Request for Input. Stakeholders are invited to share ideas for “best practices to promote safety, education, and competency” for these non-device software functions. Comments are due by July 13, 2020.


Implications of Excluding Medical Software from the Device Definition

The current call for comment on the Cures Act only deals with the five aforementioned non-device software functions, but whenever a particular category is “exempted” from regulations it may be tempting to use less rigor in developing that software. However, whether or not software is formally considered a device, best practice is to continue to follow relevant standards. For example, even if a company is not bound by ISO 14971, it would only be beneficial for them to consider reasonably foreseeable use and misuse when designing their product.

Maintaining compliance even when the law does not require it has two readily apparent benefits. First, if the device definition changes (something that is always possible, especially after a change in administration or a call for comment), and a previously un-regulated product becomes regulated, the compliant company will be in the best position possible. Secondly, it demonstrates integrity by the company (something that the FDA looks for in its Excellence Appraisals in the Pre-Cert Program, and that a court may take into consideration when evaluating the risk mitigation a company took in designing their product).

It is always good to remember that software developers are free to exceed the bare minimum of safety! A change in the device definition does not necessarily mean there should be a change in the way a company guards against risk in that device.


For more general information about the 21st Century Cures Act, see some of our previous posts: Medical Device Section 21st Century Cures Act21st Century Cures Act – SCPR SW Impact Analysis21st Century Cures Act – Medical Device Summary.

About the author

Amy enjoys researching and writing about developments in medical technology and how that intersects with US law. She received her J.D. from the University of Florida Levin College of Law in 2020 and now works as a Regulatory Associate for SoftwareCPR®, a general-purpose regulatory consulting firm that is recognized globally for their expertise with standards and national regulations pertaining to medical device, mobile medical app, and HealthIT software.

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:




Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: March 7 & 28, 2024

Virtual via Zoom

Registration Link:

Register Now



Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
Partners located in the US (CA, FL, MA, MN, TX) and Canada.