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
The quality of evidence for the analytical validation of sensor-based digital health technologies (sDHTs), which is the evaluation of algorithms converting sensor data into a clinically interpretable measure, is often inconsistent and insufficient. The existing V3+ framework codifies the overall evaluation process, which includes verification, usability validation, analytical validation, and clinical validation. To improve the scientific rigor of analytical validation, a hierarchical framework for selecting reference measures is needed because not all potential reference measures are of equal quality. The framework classifies reference measures based on attributes that contribute to reduced measurement variability, with defining and principal measures being the most rigorous due to objective data acquisition and the ability to retain source data.

Recommendations
The proposed framework sequentially moves the investigator through four steps: (1) Compile preliminary information, including the digital clinical measure, context of use (COU), algorithm requirements, and sensor verification evidence . (2) Select an existing reference measure, develop a novel comparator, or identify a set of anchor measures, prioritizing measures with the highest scientific rigor (defining → principal → manual → reported) . (3) Consider the impact of the data collection environment to determine if the analytical validation study can be conducted in the intended use environment with the highest-order measure, or if in-lab validation is necessary, ensuring the results are generalizable . (4) Describe the rationale for key study design decisions to encourage transparency for evaluators, regulators, and payers . Investigators must justify passing over a higher-ranked reference measure, generally only acceptable if the higher-ranked measure poses unacceptable risk or is not applicable to the context of use.

Regulatory Considerations
The principles of the framework for analytical validation apply regardless of the regulatory status of the sDHT (regulated medical device, low-risk general wellness apps, or research product) or its intended use (clinical care or clinical research). The framework is intended to help investigators support the most rigorous claims regarding sDHT performance, which is important for acceptance by evaluators, peer-reviewers, regulators, and payers. The categorization of the digital clinical measure as a digital biomarker or an electronic clinical outcome assessment also does not change the framework's applicability.

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
FDA oversight focuses on software functions that meet the definition of a medical device under section 201(h) of the FD&C Act and pose risks to patient safety.
Many software functions are exempt from regulation if they do not meet the medical device definition or pose minimal risk.
Mobile medical apps that transform general-purpose platforms into regulated devices (e.g., by using sensors or attachments) fall under FDA’s regulatory scope.
Certain apps, like those for general wellness or simple medical calculations, are subject to enforcement discretion due to their low risk.
Manufacturers are encouraged to adopt quality systems to ensure software safety and effectiveness throughout the product lifecycle.

Recommendations
Clearly identify the intended use of software functions and ensure they align with definitions for medical devices under the FD&C Act.
Adopt a robust Quality System (QS) to ensure software safety and mitigate risks.
For mobile medical apps that transform general-purpose platforms into devices, ensure compliance with FDA classification and regulatory requirements.
Distinguish between software functions for general wellness and those with patient-specific analysis to assess regulatory oversight needs.
Engage with FDA early in the development process to clarify requirements for new or novel device software functions.

Regulatory Considerations
Device software functions that meet FDA’s medical device definition and pose safety risks are subject to classification (Class I, II, or III) and regulatory requirements.
FDA exercises enforcement discretion for low-risk software functions, such as apps for medication reminders or wellness tracking.
Mobile apps used solely for administrative purposes or patient education generally do not meet the definition of a medical device.
Developers of regulated software must comply with labeling, quality system, and premarket submission requirements, depending on classification.
Apps that collect, transfer, or display medical device data without modifying it may fall under MDDS guidance and are typically exempt from rigorous regulation.

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.