FDA Seeks Comments on Certain Non-Device Software Functions

FDA Seeks Comments on Certain Non-Device Software Functions

Date: July 14, 2026

The U.S. Food and Drug Administration (FDA) is seeking comments on the impact on patient safety of certain software functions excluded from the definition of a medical device under the 21st Century Cures Act, including best practices, education, and competency related to patient safety.

The comments will inform the development of the 2026 Non-Device Software Functions Health Risk and Benefit Report. The report covers software functions intended for: administrative support of healthcare facilities; encouraging healthy lifestyles; use as electronic medical records; transmitting, storing, converting format, or displaying data; and providing limited clinical decision support.

Companies should assess how this request may affect product classification, registration strategy, and compliance documentation, particularly manufacturers of software intended for non-medical purposes. Comments are due by August 13, 2026.

Scope of the Request

• Administrative support for healthcare facilities;
• Encouraging healthy lifestyles;
• Use as electronic medical records;
• Transmitting, storing, converting format, or displaying data;
• Providing limited clinical decision support.

Submission Details

Comments must be submitted by August 13, 2026, at www.regulations.gov under Docket No. FDA-2018-N-1910.

These reports are published every two years. They review information on health risks and benefits associated with non-device software functions described in section 520(o)(1)(A)-(E) of the Federal Food, Drug, and Cosmetic Act and provide findings on their impact on patient safety, including best practices.

Historical Reports

• 2024 Non-Device Software Functions Report (PDF - 1.72 MB)
• 2022 Non-Device Software Functions Report (PDF - 1 MB)
• 2020 Non-Device Software Functions Report (PDF - 6.7 MB)
• 2018 Non-Device Software Functions Report (PDF - 278 KB)

Additional report: FDASIA Health IT Report: Proposed Strategy and Recommendations for a Risk-Based Framework (2014).

Source and Applicability

Source organization: FDA CDRH News & Updates. Original release date: July 13, 2026. Page update date: July 14, 2026.

This article is based on public information from FDA CDRH News & Updates: https://www.fda.gov/about-fda/cdrh-reports/reports-non-device-software-functions. Specific requirements are subject to the latest official publication of the regulatory authority.

AIMEILI Regulatory Interpretation and Business Impact

For software as a medical device (SaMD) and software-enabled medical devices, overseas registration reviews usually focus not only on product function descriptions but also on the intended use of algorithms, risk controls, data sources, performance validation, cybersecurity, software lifecycle, clinical evaluation, and post-market continuous learning or version-change management.

Different countries do not fully align on classification, evidence requirements, and change management for software medical devices. Companies cannot rely solely on documentation frameworks developed for traditional hardware devices.

Key Documents to Check

Companies should prioritize preparation of the software description, algorithm intended use, inputs and outputs, target population, training and validation data descriptions, performance validation reports, risk management, software lifecycle documents, cybersecurity materials, clinical evaluation materials, labels and instructions for use, version control records, and post-market surveillance plans.

If a product involves diagnosis, treatment recommendations, life support, automated decision-making, or high-risk scenarios, companies should more carefully assess the depth of evidence and clinical validation requirements.

Common Risks

Common issues include overly broad descriptions of algorithm intended use, unclear boundaries between training and validation data, lack of a control strategy for software version changes, insufficient cybersecurity documentation, mismatch between clinical evidence and claims, and inconsistent classification conclusions across countries.

AIMEILI View

The FDA request for comments on non-device software functions has several compliance implications for Chinese medical device companies.

First, registration pathway. Companies need to re-evaluate the classification boundary for software products. The 21st Century Cures Act expressly excludes five categories of software, including administrative support, healthy lifestyle, and electronic medical records, from the definition of a medical device. However, the FDA emphasizes that patient safety still requires attention. Chinese companies exporting such products to the United States cannot simply rely on the non-device exemption. They must proactively assess whether the functions fully meet the exclusion criteria; otherwise, the product may be reclassified as a medical device and require a new registration application. For example, if software providing limited clinical decision support has logic that exceeds the limited scope, such as combining patient-specific data to recommend treatment, the FDA may view it as a medical device requiring the 510(k) or PMA pathway.

Second, technical documentation and clinical evaluation. The request asks for comments on best practices, education, and competency for patient safety, which directly relates to pre-market and post-market document preparation. Companies should consider adding software function safety analysis to technical documentation, particularly patient-impact assessments for non-device functions. Even if a product is excluded from the device definition, the FDA may still require clinical evidence or indirect data to demonstrate safety. Chinese manufacturers need stricter risk management processes, with reference to ISO 14971, to control risks of misdiagnosis or data errors that may arise from non-device software functions.

Third, labeling and quality systems. The FDA request emphasizes patient safety education and competency, which means product labels may need to state limitations on use, target population, and potential risks. At the same time, the quality system should cover software change management. Non-device software may be updated, for example through algorithm adjustments, and failure to assess the patient-safety impact in a timely manner may create regulatory risk. When preparing U.S. market documentation, Chinese companies should coordinate with their U.S. agent in advance to ensure labels align with final FDA guidance.

Fourth, post-market maintenance. The FDA publishes non-device software function reports every two years, and companies should continue to monitor patient-safety findings in these reports. If a report identifies risks in a certain type of software function, the FDA may issue safety communications or require recalls. Chinese companies should establish post-market surveillance mechanisms, proactively collect user feedback and adverse events, and prepare to cooperate with follow-up FDA actions. In addition, companies are encouraged to submit comments by August 13, 2026, through Docket FDA-2018-N-1910 to influence future policy, including issues related to China-specific clinical practice and data protection regulations.

FAQ

What is usually the most challenging part of international registration for software as a medical device?

Answer: The main challenges are usually risk classification, algorithm evidence, clinical evaluation, software lifecycle, and post-market change management, rather than simply completing an application form.

Can software as a medical device be filed first using ordinary software documentation?

Answer: No. Ordinary software documentation should not be applied without analysis. Companies should first confirm whether the product is SaMD, whether it has decision-support attributes, and whether it affects diagnosis or treatment, and then design the registration dossier.

Content Review and Applicability

Content author: AIMEILI Regulatory Editorial Team. Professional review: AIMEILI Medical Device International Registration Project Team.

Source principles: Priority is given to official regulatory authorities, international organizations, standards bodies, and public regulatory materials; industry media and project experience are used only as supporting judgment.

Applicability: This article is intended for preliminary understanding, document preparation, and project planning. It does not replace the official requirements of the target country regulator, testing conclusions, or legal advice.

Need to Assess the Registration Pathway?

Please provide the product name, intended use, target country, and existing documentation basis. AIMEILI can assist in assessing the registration pathway, documentation gaps, and compliance risks.