Findings
The FDA classifies CDS software as Non-Device CDS only if it meets four specific criteria related to data inputs, information display, HCP support, and independent reviewability. Software functions that analyze medical images, signals from IVDs, or patterns from signal acquisition systems remain regulated as medical devices. Non-Device CDS must be intended for health care professionals and not for patients or caregivers. Automation bias and the time-critical nature of decision-making are key factors in determining whether an HCP can truly review the basis of a recommendation independently. If software provides a specific diagnostic or treatment directive rather than a list of options, it generally fails to meet the exclusion criteria.

Recommendations
Developers should ensure that software intended as Non-Device CDS provides a plain language description of the underlying algorithm and the data used for validation. The software or labeling must clearly identify the intended HCP user, the patient population, and the required input medical information. To support independent review, the software should highlight the source of its clinical recommendations, such as specific clinical practice guidelines or peer-reviewed studies. Developers are encouraged to use usability testing to verify that HCPs can understand the basis of recommendations without relying primarily on the software’s output. For multiple function products, developers should follow the FDA’s policy for assessing products that contain both device and non-device functions.

Regulatory Considerations
The FDA applies a risk-based approach to software oversight, focusing on functions that acquire or analyze complex medical data like ECG waveforms or genomic sequences. Software intended for time-sensitive or critical medical decisions is typically regulated as a device because the user lacks the time to independently verify the recommendation. The agency intends to exercise enforcement discretion for certain software functions that provide only one clinically appropriate recommendation if all other non-device criteria are met. Sponsors may use the Q-Submission process to discuss alternative approaches or clarify the regulatory status of specific software functions. Existing digital health policies continue to apply to software functions that meet the device definition, including mobile medical applications.

Findings
Enhanced documentation is required for high-risk device software where flaws could result in serious injury or death.
Risk management plans should include robust risk assessments, including residual risk evaluations.
Verification and validation activities are critical to confirm software functionality and mitigate risks.
The lack of traceability between software design and requirements can undermine device safety and effectiveness.
Unresolved software anomalies must be carefully documented and justified based on a risk assessment.

Recommendations
Use a risk-based approach to determine whether basic or enhanced documentation levels are required for premarket submissions.
Include comprehensive risk management documentation, detailing hazard identification, risk control measures, and residual risk evaluations.
Provide detailed system and software architecture diagrams, highlighting relationships between modules and external systems.
Document unresolved software anomalies and justify their impact on safety and effectiveness using a risk-based rationale.
Align software development, configuration management, and maintenance practices with FDA-recognized standards like ANSI/AAMI/IEC 62304.

Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System regulations, emphasizing design controls and risk management.
Submission of risk management files and unresolved software anomalies as part of premarket documentation.
Use of system and software architecture diagrams to demonstrate software functionality and risk mitigation.
Implementation of cybersecurity measures as part of software validation and risk management processes.
Documentation of premarket changes and interactions between device functions and external systems, particularly in multi-function devices.

Findings
Not all CDS software is regulated as a medical device; the FDA applies specific criteria to determine its classification.
CDS software functions are excluded from the device definition if they meet all four criteria in section 520(o)(1)(E) of the FD&C Act.
Automation bias in decision-making poses a risk, particularly in time-critical scenarios, and influences regulatory considerations.
Clear labeling and transparency about the basis for recommendations are essential for enabling HCPs to make independent decisions.
Software functions that provide specific diagnostic outputs or time-critical directives typically fail to meet the criteria for Non-Device CDS.

Recommendations
Clearly define the intended use, user population, and input medical information for CDS software in labeling.
Ensure that software provides transparent and plain language descriptions of algorithms, data sources, and validation results.
Avoid presenting specific treatment or diagnostic directives to ensure the software supports rather than replaces HCP judgment.
Include sufficient information to allow HCPs to independently review and understand the basis for software recommendations.
Engage with the FDA early in the development process for software functions with potential regulatory oversight.

Regulatory Considerations
CDS software functions that meet all four criteria under section 520(o)(1)(E) of the FD&C Act are excluded from FDA’s definition of a device.
Software intended for time-critical decision-making or replacing HCP judgment is generally considered a device.
Developers must ensure that software labeling and functionality align with the criteria for Non-Device CDS.
Transparency in data sources, algorithm logic, and validation methods is required to enable independent HCP decision-making.
The FDA may request additional information or oversight for software that poses significant risks to patient safety.

Findings
Non-Device-MDDS functions are excluded from FDA regulation, provided they do not interpret or analyze medical data.
Device-MDDS hardware functions are still considered devices but are subject to enforcement discretion.
FDA clarified that functions involving analysis, alarms, or active patient monitoring fall under regulatory oversight due to higher risk.
The guidance addresses scenarios involving multiple function device products with both device and non-device functions.
General-purpose IT infrastructure used for data transfer, storage, or display is not regulated as a medical device.

Recommendations
Clearly delineate whether software functions qualify as Non-Device-MDDS or Device-MDDS under section 520(o)(1)(D) of the FD&C Act.
Avoid adding analysis, interpretation, or real-time monitoring capabilities to Non-Device-MDDS to maintain exemption from regulatory oversight.
For Device-MDDS, adhere to existing classification regulations but note FDA’s intent not to enforce regulatory controls for most low-risk use cases.
Developers of multiple function devices should assess how non-device functions impact the safety and effectiveness of device functions.
Consult FDA guidance on "Multiple Function Device Products" for more details on managing products with both device and non-device functions.

Regulatory Considerations
Non-Device-MDDS functions are not subject to FDA oversight under section 520(o)(1)(D) of the FD&C Act.
FDA does not enforce premarket notification, registration, or quality system requirements for Device-MDDS hardware functions.
Active patient monitoring and alarm systems remain within the scope of FDA regulation due to their higher risk profiles.
The regulatory status of multiple function devices depends on how non-device and device functions interact.
Developers must avoid modifying data or controlling other medical devices unless explicitly regulated as such.

Findings
A “multiple function device product” contains at least one device function and one “other function” that may or may not be subject to FDA oversight.
FDA assesses "other functions" only to the extent they impact the safety or effectiveness of the device function under review or are claimed to provide a positive labeled impact.
Manufacturers must conduct and document risk assessments for all functions within the product to ensure safety and performance.
Functions not directly subject to FDA premarket review are still considered during inspections if they influence the device function under review.
Design separation between device and non-device functions can mitigate risks and simplify regulatory assessment.

Recommendations
Conduct thorough risk assessments for “other functions” and document the impacts, whether negative, positive, or neutral, on the device function under review.
Use design separation to minimize interdependencies between device and non-device functions where feasible.
Include only the relevant "other function" documentation in premarket submissions if it impacts the device function under review or is represented as a labeled positive impact.
For modifications to “other functions,” determine if they significantly affect the safety or effectiveness of the device function, and, if so, submit a new premarket notification as required.
Follow applicable labeling, quality system, and postmarket requirements for both device and non-device functions, ensuring clarity in what has been evaluated by the FDA.

Regulatory Considerations
Non-device functions are not regulated unless they impact the safety or effectiveness of a device function under review.
For device functions under review, manufacturers must comply with FDA's design validation and risk analysis requirements under 21 CFR 820.30(g).
Changes to non-device functions must be assessed for potential impacts on the device function under review to determine whether additional regulatory submissions are necessary.
FDA evaluates the premarket safety and effectiveness of device functions within the context of interactions with non-device functions but does not directly regulate the non-device functions themselves.
Postmarket requirements, such as adverse event reporting, apply to device functions, including when the event involves an interaction with a non-device function.

Findings
Software functions for administrative support of healthcare facilities, general wellness, and maintaining electronic patient records are excluded from FDA regulation if they meet specific criteria under section 520(o)(1) of the FD&C Act.
MDDS software functions for transferring, storing, converting formats, and displaying data are not devices unless they include interpretive or analytical features.
Wellness-related software functions that are unrelated to disease diagnosis or treatment (e.g., tracking fitness or sleep) are no longer regulated as devices.
Software functions associated with certified health IT under ONC Health IT Certification are not considered devices, provided they are not intended for interpretation or diagnosis.
Software involving clinical alerts, prioritization of patient information, or medical decision support remains subject to FDA oversight under section 520(o)(1)(E).

Recommendations
Clearly define software functions to assess whether they fall under the excluded categories outlined in section 520(o)(1) of the FD&C Act.
For software functions that combine device and non-device functionalities, ensure that only device-related functionalities are included in FDA regulatory submissions.
Maintain compliance with general FDA requirements for software that still meets the definition of a device, particularly those with interpretive or decision-support capabilities.
Align product labeling and marketing claims with the revised guidance to accurately reflect whether software functions meet the exclusion criteria.
Use the latest FDA-recognized consensus standards to assess compliance for any software functions still considered devices.

Regulatory Considerations
Non-device software functions under section 520(o)(1) are excluded from FDA regulation, but any interpretive or analytical capabilities must still comply with device requirements.
Software functions certified under ONC Health IT Certification are not devices unless intended for analysis or diagnosis.
Hardware associated with MDDS functions remains subject to FDA regulation, but non-device MDDS software functions are excluded from oversight.
FDA continues to regulate functions that prioritize patient-related information or trigger clinical alerts under section 520(o)(1)(E).
Software combining device and non-device functions must clearly delineate each functionality’s regulatory status to avoid unnecessary oversight of non-device components.