Drawing the Device Line: FDA Seeks Public Input on Patient Safety and Non-Device Health Software

Firm Publication

Key Takeaways

  • The FDA is requesting public comments by August 13, 2026, on the patient safety impacts of software functions excluded from the medical device definition under the 21st Century Cures Act, including clinical decision support and data transfer and display software.
  • Companies developing remote patient monitoring, CDS and other health software should evaluate whether their products qualify for statutory exclusions under FD&C Act Section 520(o)(1), as small functionality differences can determine whether a product is an unregulated software function or a regulated medical device.
  • Stakeholders are encouraged to submit real-world experience and best practices to help the FDA understand how non-device software functions affect patient safety, user training, alert fatigue, and clinical decision making.

On July 14, the U.S. Food and Drug Administration (FDA) announced it is seeking public input regarding the patient safety impacts of certain medical software functions excluded from the definition of a medical device under the 21st Century Cures Act. In particular, the FDA is requesting input on best practices to promote patient safety, education, and competency associated with these non-device software functions. Comments are due August 13, 2026.

Sometimes Software Is a Medical Device Under the FD&C Act

The statutory definition of a medical device under the Federal Food, Drug, and Cosmetic Act (FD&C Act) is broad, bringing medically-related software functions under the FDA’s medical device authority alongside physical products like pacemakers and tongue depressors. To curtail this jurisdictional reach, the 21st Century Cures Act amended the FD&C Act to exclude certain software functions from the statutory definition of a medical device, and thus from the FDA’s medical device authority. (Even where a product may otherwise fall outside the statutory definition of a device, the FDA may assert jurisdiction based on intended use as evidenced by labeling, advertising, or promotional claims.)

21st Century Cures Act Software Exclusions

Subject to specific conditions that vary by category, these exclusions, codified in FD&C Act Section 520(o)(1), apply to software functions intended for:

  • Administrative support of healthcare facilities.
  • Maintaining or encouraging a healthy lifestyle.
  • Serving as electronic patient records.
  • Transferring, storing, converting formats, or displaying certain diagnostic tests or other device data.
  • Providing certain limited clinical decision support (CDS) to healthcare professionals.

These exclusions help clarify that simply operating in a healthcare setting does not necessarily make software a medical device. Rather, whether a software function constitutes a medical device depends on the software function’s intended use and operation. FDA has issued several guidance documents interpreting these exclusions, including its January 2026 CDS guidance addressing when certain CDS functions intended for healthcare professionals qualify as non-device software under Section 520(o)(1)(E). In that guidance, the FDA further clarified the dividing line between (1) a “pattern or signal” that makes a function a medical device and (2) “medical information” that a non-device CDS function may use, explaining that continuous or streaming measurements generally constitute a pattern while discrete, intermittent measurements are generally treated as medical information. Additionally, this CDS guidance announced a new enforcement discretion policy for software products that provide only one output, when only one output is clinically appropriate and all other criteria of Section 520(o)(1)(E) are met.

Software products may contain both non-device and device functions, resulting in certain multi-function products remaining subject to FDA’s medical device authority, even when many functions satisfy a statutory exclusion.

FDA Is Requesting Public Comments on Non-Device Software Functions

The 21st Century Cures Act also requires the FDA to publish a report every two years on the risks and benefits of these non-device software functions. To fulfill this statutory mandate, FDA is requesting input to inform its 2026 report, which examines available information regarding the health risks and benefits associated with these non-device software functions and summarizes their impact on patient safety, including best practices to promote safety, education, and competency.

The current request for input provides an opportunity for software developers, healthcare providers, health systems, technology companies, and other stakeholders to proffer relevant information regarding both the benefits and potential risks of these increasingly prevalent technologies. Stakeholders may also wish to provide suggestions regarding practices that can mitigate patient safety risks while preserving the efficiencies and clinical benefits offered by non-device software. FDA has identified topics of interest, including user training, escalation pathways, change-management procedures, oversight of software recommendations, transparency of software outputs, and monitoring for alert fatigue or overreliance.

How Do Device Functionality Challenges Affect Remote Patient Monitoring and Clinical Decision Support Software?

Certain remote patient monitoring (RPM) software products that connect to home devices such as blood pressure cuffs, glucometers, and pulse oximeters to send patients’ readings to their care teams, illustrate why stakeholder input is important. As technologies develop and reimbursement guidelines change, companies currently offering facially similar tools may disagree about whether their software products are regulated devices.

For example, companies that offer nearly identical software products that gather a patient’s information for review by a clinician, without analyzing the data or generating alerts, may reach different conclusions as to whether the product is a data-transfer-and-display software product excluded from the statutory definition of a medical device under Section 520(o)(1)(D) or a medical device subject to FDA’s applicable medical device authorities. Such inconsistent determinations create an uneven competitive landscape, expose companies to heightened enforcement risk if FDA later disagrees with their classification, and undermine the regulatory predictability that market participants need to make informed compliance and investment decisions.

What Determines Whether Clinical Decision Support Software Is FDA-Regulated?

CDS software functions offer similar examples. FDA interprets the CDS statutory exclusion under Section 520(o)(1)(E) as requiring, among other things, the software product to enable the clinician to independently review the basis for the recommendation so that the clinician can determine whether he or she agrees with the conclusions. Accordingly, some companies design their software to show the underlying data, sources, and logic, and take the position that the software product is non-device CDS. Other companies with similar software products may choose not to provide the same underlying, often proprietary, information and thus effectively direct clinical decision making (rather than just support it), resulting in the software product offering a medical device function. In practice, small changes to the functionality and process of similar clinician recommendation features can push the product from an excluded product to a regulated one. How companies classify their products thus has significant FDA and even payor reimbursement consequences.

Adding complexity, a software product’s intended functionality often shifts as the product evolves. A product may initially not be a device and later become one after the addition of features and updates to analyze data, predict risk, or suggest a diagnosis. These developments may unintentionally bring a once-unregulated product under the FDA’s medical device authority. These divergent positions and development processes are exactly the kind of real-world experience FDA is inviting stakeholders to share.

What Should Stakeholders Do Before the August 13, 2026 Deadline?

Comments from the industry are important in helping the FDA to understand how its current regulatory regime functions in practice. In light of the short comment window, stakeholders who develop, manufacture, license, deploy, purchase, or rely on non-device software functions should promptly consider whether to submit information and real-world experience that could inform the FDA’s 2026 report. Feel free to reach out to us if you would like assistance with evaluating whether to comment and how best to draft your comments. Comments may be submitted through Regulations.gov under Docket No. FDA-2018-N-1910 through August 13, 2026.

Related Professionals
Related Services
Firm Publication

Key Takeaways

  • The FDA is requesting public comments by August 13, 2026, on the patient safety impacts of software functions excluded from the medical device definition under the 21st Century Cures Act, including clinical decision support and data transfer and display software.
  • Companies developing remote patient monitoring, CDS and other health software should evaluate whether their products qualify for statutory exclusions under FD&C Act Section 520(o)(1), as small functionality differences can determine whether a product is an unregulated software function or a regulated medical device.
  • Stakeholders are encouraged to submit real-world experience and best practices to help the FDA understand how non-device software functions affect patient safety, user training, alert fatigue, and clinical decision making.

On July 14, the U.S. Food and Drug Administration (FDA) announced it is seeking public input regarding the patient safety impacts of certain medical software functions excluded from the definition of a medical device under the 21st Century Cures Act. In particular, the FDA is requesting input on best practices to promote patient safety, education, and competency associated with these non-device software functions. Comments are due August 13, 2026.

Sometimes Software Is a Medical Device Under the FD&C Act

The statutory definition of a medical device under the Federal Food, Drug, and Cosmetic Act (FD&C Act) is broad, bringing medically-related software functions under the FDA’s medical device authority alongside physical products like pacemakers and tongue depressors. To curtail this jurisdictional reach, the 21st Century Cures Act amended the FD&C Act to exclude certain software functions from the statutory definition of a medical device, and thus from the FDA’s medical device authority. (Even where a product may otherwise fall outside the statutory definition of a device, the FDA may assert jurisdiction based on intended use as evidenced by labeling, advertising, or promotional claims.)

21st Century Cures Act Software Exclusions

Subject to specific conditions that vary by category, these exclusions, codified in FD&C Act Section 520(o)(1), apply to software functions intended for:

  • Administrative support of healthcare facilities.
  • Maintaining or encouraging a healthy lifestyle.
  • Serving as electronic patient records.
  • Transferring, storing, converting formats, or displaying certain diagnostic tests or other device data.
  • Providing certain limited clinical decision support (CDS) to healthcare professionals.

These exclusions help clarify that simply operating in a healthcare setting does not necessarily make software a medical device. Rather, whether a software function constitutes a medical device depends on the software function’s intended use and operation. FDA has issued several guidance documents interpreting these exclusions, including its January 2026 CDS guidance addressing when certain CDS functions intended for healthcare professionals qualify as non-device software under Section 520(o)(1)(E). In that guidance, the FDA further clarified the dividing line between (1) a “pattern or signal” that makes a function a medical device and (2) “medical information” that a non-device CDS function may use, explaining that continuous or streaming measurements generally constitute a pattern while discrete, intermittent measurements are generally treated as medical information. Additionally, this CDS guidance announced a new enforcement discretion policy for software products that provide only one output, when only one output is clinically appropriate and all other criteria of Section 520(o)(1)(E) are met.

Software products may contain both non-device and device functions, resulting in certain multi-function products remaining subject to FDA’s medical device authority, even when many functions satisfy a statutory exclusion.

FDA Is Requesting Public Comments on Non-Device Software Functions

The 21st Century Cures Act also requires the FDA to publish a report every two years on the risks and benefits of these non-device software functions. To fulfill this statutory mandate, FDA is requesting input to inform its 2026 report, which examines available information regarding the health risks and benefits associated with these non-device software functions and summarizes their impact on patient safety, including best practices to promote safety, education, and competency.

The current request for input provides an opportunity for software developers, healthcare providers, health systems, technology companies, and other stakeholders to proffer relevant information regarding both the benefits and potential risks of these increasingly prevalent technologies. Stakeholders may also wish to provide suggestions regarding practices that can mitigate patient safety risks while preserving the efficiencies and clinical benefits offered by non-device software. FDA has identified topics of interest, including user training, escalation pathways, change-management procedures, oversight of software recommendations, transparency of software outputs, and monitoring for alert fatigue or overreliance.

How Do Device Functionality Challenges Affect Remote Patient Monitoring and Clinical Decision Support Software?

Certain remote patient monitoring (RPM) software products that connect to home devices such as blood pressure cuffs, glucometers, and pulse oximeters to send patients’ readings to their care teams, illustrate why stakeholder input is important. As technologies develop and reimbursement guidelines change, companies currently offering facially similar tools may disagree about whether their software products are regulated devices.

For example, companies that offer nearly identical software products that gather a patient’s information for review by a clinician, without analyzing the data or generating alerts, may reach different conclusions as to whether the product is a data-transfer-and-display software product excluded from the statutory definition of a medical device under Section 520(o)(1)(D) or a medical device subject to FDA’s applicable medical device authorities. Such inconsistent determinations create an uneven competitive landscape, expose companies to heightened enforcement risk if FDA later disagrees with their classification, and undermine the regulatory predictability that market participants need to make informed compliance and investment decisions.

What Determines Whether Clinical Decision Support Software Is FDA-Regulated?

CDS software functions offer similar examples. FDA interprets the CDS statutory exclusion under Section 520(o)(1)(E) as requiring, among other things, the software product to enable the clinician to independently review the basis for the recommendation so that the clinician can determine whether he or she agrees with the conclusions. Accordingly, some companies design their software to show the underlying data, sources, and logic, and take the position that the software product is non-device CDS. Other companies with similar software products may choose not to provide the same underlying, often proprietary, information and thus effectively direct clinical decision making (rather than just support it), resulting in the software product offering a medical device function. In practice, small changes to the functionality and process of similar clinician recommendation features can push the product from an excluded product to a regulated one. How companies classify their products thus has significant FDA and even payor reimbursement consequences.

Adding complexity, a software product’s intended functionality often shifts as the product evolves. A product may initially not be a device and later become one after the addition of features and updates to analyze data, predict risk, or suggest a diagnosis. These developments may unintentionally bring a once-unregulated product under the FDA’s medical device authority. These divergent positions and development processes are exactly the kind of real-world experience FDA is inviting stakeholders to share.

What Should Stakeholders Do Before the August 13, 2026 Deadline?

Comments from the industry are important in helping the FDA to understand how its current regulatory regime functions in practice. In light of the short comment window, stakeholders who develop, manufacture, license, deploy, purchase, or rely on non-device software functions should promptly consider whether to submit information and real-world experience that could inform the FDA’s 2026 report. Feel free to reach out to us if you would like assistance with evaluating whether to comment and how best to draft your comments. Comments may be submitted through Regulations.gov under Docket No. FDA-2018-N-1910 through August 13, 2026.

In Case You Missed It: