Findings
General wellness products are defined by two factors: they are intended only for general wellness use and present a low risk to user safety. The FDA categorizes wellness uses into those relating to a general state of health (e.g., weight management, physical fitness, sleep) and those relating to chronic diseases where lifestyle choices are well-accepted to play a role in health outcomes. Products are not considered low risk if they are invasive, implanted, or involve technologies like lasers or radiation that require specific regulatory controls. Software functions intended for maintaining a healthy lifestyle that are unrelated to the diagnosis or treatment of a disease are explicitly excluded from the statutory definition of a medical device.

Recommendations
Manufacturers should ensure that claims for general wellness products are limited to sustaining or improving general health functions or encouraging healthy lifestyle choices for living well with chronic conditions. Disease-related claims must be supported by peer-reviewed scientific publications or official statements from healthcare professional organizations. Labeling and marketing communications must be consistent with and not exceed the product's stated intended use. For products using non-invasive sensing to estimate physiologic parameters, manufacturers should validate these outputs if they mimic values used clinically. If a product includes notifications to see a doctor, these should not name specific diseases or characterize outputs as pathological.

Regulatory Considerations
For products meeting the low-risk general wellness criteria, the FDA does not intend to enforce requirements such as registration and listing, premarket notification, or Quality Management System regulations. The FDA may coordinate with the Consumer Product Safety Commission to determine jurisdiction over specific products. If a product targets the diagnosis, screening, or management of a disease through alerts or clinical thresholds, it is generally not considered a general wellness product and is subject to standard medical device regulations. Industry members may contact the Digital Health Center of Excellence or use the Q-Submission process to discuss alternative approaches or clarify the regulatory status of a specific product.

Findings
AI-enabled medical devices require robust risk assessment to address data drift, bias, and transparency challenges.
The total product lifecycle (TPLC) approach is essential for managing AI-enabled devices, ensuring continuous oversight and updates.
There is a need for improved standardization in AI model validation and performance monitoring to ensure consistency in regulatory submissions.
Effective data management practices, including dataset representativeness and bias control, are critical for AI model development.
Cybersecurity vulnerabilities in AI-enabled medical devices must be proactively addressed to prevent risks to patient safety and data integrity.

Recommendations
AI-enabled device manufacturers should integrate Good Machine Learning Practice (GMLP) principles throughout the device lifecycle.
Marketing submissions should include comprehensive documentation of AI model development, validation, and performance monitoring.
Developers should implement transparency measures, such as model interpretability and explainability, to enhance user trust and understanding.
AI models must undergo rigorous bias evaluation to ensure equitable performance across diverse patient populations.
A predetermined change control plan (PCCP) should be established to allow safe and effective AI model updates post-market without additional FDA submissions.

Regulatory Considerations
FDA encourages early engagement through the Q-Submission Program for AI-enabled device manufacturers.
Compliance with FDA-recognized consensus standards, such as ANSI/AAMI/ISO 14971 for risk management, is recommended.
AI-enabled devices must meet labeling requirements, ensuring that users clearly understand model inputs, outputs, and performance metrics.
Post-market surveillance and continuous monitoring of AI model performance are necessary to ensure ongoing safety and effectiveness.
Cybersecurity measures must be included in regulatory submissions, detailing safeguards against data breaches and unauthorized model modifications.

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
OTS software introduces unique risks due to its general-purpose design and lack of lifecycle control by medical device manufacturers.
Comprehensive testing and risk management are essential to mitigate safety hazards associated with OTS software in medical devices.
Regular updates and maintenance are critical for managing obsolescence and ensuring long-term safety and effectiveness of OTS components.
Networking and interoperability of OTS software pose additional risks related to data integrity, cybersecurity, and scalability.
Enhanced documentation is required for high-risk devices incorporating OTS software, especially those involving AI or ML functionalities.

Recommendations
Provide comprehensive descriptions of OTS software, including version details and system specifications.
Conduct thorough risk assessments and include mitigation plans in premarket submissions.
Perform rigorous testing, including integration and regression testing, for OTS software components.
Establish mechanisms for continued maintenance, support, and version control of OTS software.
Ensure that device labeling includes warnings and specifications related to OTS software compatibility and restrictions.

Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System regulations, including design controls and purchasing controls for OTS software.
Submission of a risk management file and traceability documentation linking risks, design requirements, and testing outcomes.
Compliance with premarket submission requirements, including 510(k), IDE, and PMA applications, as applicable.
Use of device labeling to communicate hardware and software compatibility and restrictions to users.
Development of beta testing and investigational plans for clinical studies involving OTS software.

Findings
High rates of missing data in DHTs compared to traditional measures due to technical and software difficulties.
Practical issues such as unfamiliarity with platforms, connectivity difficulties, and lack of data visibility.
Specific technical issues like blocking of websites by firewalls and failed software updates leading to data loss.

Recommendations
Ensure appropriate workforce training for those involved in DHT deployment.
Conduct pilot evaluations in study sites to identify potential issues early.
Improve data visibility at both site and central coordinating team levels.
Implement robust feasibility testing before full-scale deployment.
Co-design DHTs with study staff and patients to enhance usability.

Regulatory Considerations
The FDA requires adequate training, education, and experience for those responsible for data capture using mobile technologies.
Ensure data integrity through oversight responsibilities as recommended by the Clinical Trials Transformation Initiative.

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
CADe devices must meet classification requirements under 21 CFR 892.2050, including general and special controls, and require FDA clearance through 510(k) submissions.
Each new CADe device or significant modification must demonstrate substantial equivalence to a predicate device in terms of safety and effectiveness.
Robust testing and validation are necessary, including standalone and clinical performance assessments, to evaluate detection accuracy and false positive rates.
Devices with substantive technological differences or new intended uses may require clinical performance assessments.
Enrichment strategies for study populations (e.g., including challenging cases) are encouraged but should not bias performance evaluations.

Recommendations
Clearly describe the CADe algorithm, training datasets, scoring methodologies, and intended use in premarket submissions.
Conduct standalone performance assessments to measure detection accuracy and generalizability.
Compare new devices to predicate devices whenever possible, using consistent datasets and methodologies.
Develop and submit user training materials that address expected device performance, limitations, and appropriate usage scenarios.
Provide comprehensive labeling, including indications for use, directions, warnings, precautions, and performance metrics, to ensure clinician understanding and appropriate application.

Regulatory Considerations
All CADe devices under 21 CFR 892.2050 must comply with 510(k) premarket notification requirements, including general and special controls.
Changes to CADe algorithms or device characteristics must be evaluated for significant impact on safety and effectiveness, potentially requiring new submissions.
Devices with altered indications for use or significant technological differences may need additional clinical performance studies to demonstrate substantial equivalence.
Labeling must comply with 21 CFR Part 801 and provide sufficient information to describe the device, its intended use, and directions for use.
Manufacturers should consult FDA for guidance on substantial modifications or unique device characteristics.

Findings
The review includes 275 studies, with neurology, musculoskeletal disorders, and cardiology as the most common therapeutic areas.
The studies focused on sensor performance (48%), algorithm development (86%), operational feasibility (46%), and software development (9%).
Gaps in reporting included insufficient details on software used (27%), comparator measures (17%), and participant demographics (e.g., age and gender were missing in 9% and 15% of studies, respectively).
Sixty-seven percent of the studies used wearable sensors, while others incorporated smartphones, tablets, cameras, and implantable devices.
The lack of methodological and reporting standards across studies hinders reproducibility and broader applicability.

Recommendations
Develop methodological and reporting standards to improve consistency across feasibility studies.
Include comprehensive participant demographic data, including sociodemographics and health indicators, to ensure inclusivity and generalizability.
Conduct small feasibility studies to validate sensors, optimize algorithms, and identify operational challenges before launching full-scale trials. Use the database created from this review to inform trial design and technology selection, ensuring alignment with specific research goals.
Encourage collaboration among investigators, sponsors, and regulators to standardize methods and share insights to avoid redundant studies.

Regulatory Considerations
Align sensor verification and algorithm validation processes with regulatory requirements for reliable clinical endpoints.
Ensure secure and ethical data transfer, storage, and sharing practices for compliance with privacy regulations.
Address barriers to participation for underrepresented populations by assessing and reporting equity-related data during feasibility studies.

Findings
Verification involves testing the accelerometer's technical specifications (e.g., accuracy and precision) through peer-reviewed studies.
Validation of the algorithm relies on "ground truth" data, gathered through infrared video recordings and manual scoring of movements.
Cross-validation was used to assess the algorithm's performance, with additional validation in independent samples planned.
The separation of verification and validation allows greater flexibility, enabling the algorithm's use with multiple accelerometer devices that meet minimum standards.

Recommendations
Conduct separate verification and validation processes to ensure the reliability of both the device and the algorithm.
Use peer-reviewed publications to document the performance of DHTs and their limitations.
Ensure validation includes testing with representative populations to confirm the algorithm’s utility across diverse contexts.
Promote industry-wide standards to facilitate scalability and regulatory acceptance of DHTs in clinical trials.

Regulatory Considerations
Ensure DHTs undergo rigorous verification to meet accuracy and precision standards documented in peer-reviewed studies.
Validate algorithms using empirical "ground truth" data to demonstrate their ability to measure clinically meaningful outcomes.
Align the design and validation of DHTs with regulatory expectations for reliable and transferable performance across devices.

Findings
Lack of security and confidence in digital health technologies hampers adoption.
Absence of suitable guidance for selecting BioMeTs based on clinical requirements.
BioMeTs (DHTs) and algorithms are often created without expert guidance and transparency.
No standardized evaluation resources for testing, verifying, and validating BioMeTs.
Inconsistencies in algorithm application across different cohorts.

Recommendations
Develop a standardized BioMeT and algorithm evaluation framework.
Create professionally tailored standardized guidelines for BioMeT use.
Implement a framework with unique identifiers for BioMeTs and algorithms.
Establish mechanisms for dynamic updates of hardware or software.
Use systematic reviews and Delphi processes to inform framework development.

Regulatory Considerations
Assign unique identifier numbers to BioMeTs and algorithms.
Provide mechanisms for dynamic hardware or software updates.
Ensure robust deployment through standardized evaluation protocols.

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.

Findings
Software changes must be assessed for potential impacts on the safety and effectiveness of the device, even if they are routine updates.
A risk-based assessment is required to determine whether changes introduce new risks, modify existing risks, or necessitate new risk controls.
Cybersecurity updates, routine maintenance changes, and minor clarifications may not require a new 510(k) if they do not affect performance specifications or safety.
Substantial modifications, such as adding new algorithms, introducing new functionalities, or modifying clinical performance, generally require a new 510(k).
Manufacturers must document all changes, even those not requiring a new 510(k), in compliance with QS regulations.

Recommendations
Use the provided flowchart and guiding principles to evaluate whether software changes exceed the regulatory threshold for submission of a new 510(k).
Conduct a risk-based assessment for all changes, focusing on new or modified risks and the adequacy of existing risk controls.
Verify and validate changes to ensure they meet device specifications and do not introduce unintended consequences.
Submit a new 510(k) for changes that significantly affect clinical functionality, performance specifications, or introduce new risks that are not mitigated.
Maintain detailed documentation of all decisions regarding software changes, including rationale for whether submission of a new 510(k) was required.

Regulatory Considerations
Submission of a new 510(k) is required for changes that could significantly impact the safety or effectiveness of a device or constitute a major modification to its intended use.
Cybersecurity updates generally do not require a new 510(k) if they solely strengthen security without affecting device performance.
Manufacturers must evaluate cumulative changes and submit a new 510(k) if the combined impact exceeds the regulatory threshold.
Device software changes involving substantial algorithm modifications or system architecture updates are likely to require a new 510(k).
Changes that address compliance during a recall or correction must be evaluated under FDA's guidance for recalls and device enhancements.