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 DHCoE works to strategically advance science and evidence for digital health technologies (DHTs).
Key areas of focus include Artificial Intelligence / Machine Learning (AI/ML) in Software as a Medical Device (SaMD), Cybersecurity, Augmented Reality (AR) and Virtual Reality (VR), and Wireless Medical Devices.
The DHCoE develops and publishes Guidances with Digital Health Content and maintains a Digital Health Policy Navigator to provide clarity on regulatory policies.
Digital health technologies are acknowledged as having the potential to facilitate decentralized clinical trial activities and allow for continuous or frequent measurements of clinical features remotely.
Programs and initiatives include the Software Precertification (Pre-Cert) Pilot Program, the Regulatory Accelerator, and the Diagnostic Data Program.
The center is also involved in international harmonization on device regulatory policy and standards.

Recommendations
The DHCoE recommends that stakeholders, including sponsors and DHT manufacturers, engage with the agency early to discuss the use of DHTs in drug development or for decentralized clinical trials (DCTs).
Stakeholders are encouraged to use the Digital Health Policy Navigator tool to assess whether a particular software function meets the device definition and is the focus of FDA oversight.
The DHCoE emphasizes the need for a patient-centered approach for AI/ML-enabled devices that considers issues like usability, equity, trust, and accountability, and promotes transparency.

Regulatory Considerations
The DHCoE's work includes innovating the regulatory paradigm for digital health, moving towards models that may include shifting scrutiny from the pre-market to the post-market phase and focusing on the capability of firms (Software Pre-Cert Pilot Program).
The FDA has committed, as part of PDUFA VII, to activities such as publishing a Framework for the Use of DHTs in Drug and Biological Product Development and establishing a DHT Steering Committee.
The center provides information to help determine the regulatory status of various digital health products, such as Software as a medical device (SaMD), mobile medical applications (MMA), and General Wellness products.
Submissions for products with device software functions must include recommended documentation for the FDA's evaluation of safety and effectiveness.
For questions regarding upcoming premarket submissions, stakeholders are directed to contact the appropriate review division through a Q-submission.

Findings
Sites must establish effective data privacy and security plans, especially considering regional and global regulations like GDPR.
Risk mitigation is critical, including plans to address unanticipated issues and potential patient disengagement due to technology challenges.
Budgeting and contracting often involve additional considerations, such as storage, training, and technical support requirements for connected devices.
Sites require adequate training to ensure staff and patients are prepared to use connected devices efficiently.
Companion applications or services often play an essential role in device functionality and data transmission.

Recommendations
Develop a clear plan for data pathways, including storage, security, and regulatory compliance.
Establish detailed risk mitigation and management strategies to handle unexpected challenges.
Ensure comprehensive training programs for site staff and patients to enhance device usability.
Incorporate device storage and resource allocation into budgeting and contracting processes.
Facilitate effective communication with sponsors and vendors to resolve operational and technical issues promptly.

Regulatory Considerations
Ensure connected devices comply with CFR 21, Part 11, and other relevant data collection and transmission regulations.
Understand and adhere to local and regional data privacy laws, such as GDPR, when managing patient data.
Verify that appropriate licenses and regulatory approvals are in place for device data transmission and storage.
Assess and address shipping and handling regulations for devices, ensuring safe and compliant transportation.

Findings
The field lacks a centralized, standardized database of validated digital health technologies, making it difficult for researchers and clinicians to select appropriate tools.
Non-wearable sensors and software applications are the most common types of DHTs, with 83% of ambient technologies categorized as software or applications.
Most DHTs focus on mild cognitive impairment (MCI) and early Alzheimer’s disease, with fewer technologies validated for moderate or severe dementia stages.
Uneven Distribution of Dementia Subtypes – The review identified a gap in DHT validation for frontotemporal dementia (FTD) and Lewy Body dementia, with Alzheimer’s disease being the predominant focus.

Recommendations
Expand and maintain an open-access database of validated DHTs to improve accessibility and standardization.
Increase research on digital measures applicable to moderate and severe stages of dementia, as well as non-Alzheimer’s dementias.
Promote integration of wearable, ambient, and cognitive assessment tools to generate comprehensive digital phenotypes of patients.
Follow clear guidelines for analytical and clinical validation of DHTs to improve regulatory acceptance and research applicability.
Conduct more usability and feasibility assessments, especially for populations with cognitive decline, to ensure DHTs are accessible and effective in real-world settings.

Findings
Product development firms are hesitant to increase DHT use despite regulatory support.
Conventional hardware-based technologies are preferred over newer digital tools.
Operational barriers contribute to the low adoption of DHTs in product development trials.

Recommendations
Reduce operational barriers to facilitate DHT adoption.
Provide additional regulatory clarity to encourage DHT use.
Encourage the incorporation of more DHTs and patient-centric endpoints in clinical trials.

Regulatory Considerations
The FDA's guidance on DHT use is evolving and not yet fully formalized.
There is a need for harmonization between US and non-US regulatory agencies.
The impact of recent regulatory support may take years to be fully realized.

Findings
Decentralized Clinical Trials (DCTs), which shift activities away from sites, rely heavily on technology to reduce participant burden and improve access to trials. Digital platforms are essential for this shift, providing centralized data capture, remote monitoring, and streamlined workflows. Benefits include allowing participants to be monitored remotely, which can improve self-management and clinical outcomes, and giving researchers better insight into the real-world variability of disease activity. Currently, commercial platforms are often limited in functionality and face major challenges due to a lack of interoperability and specific data standardization protocols for clinical trial platforms, making it difficult to integrate third-party modules.

Recommendations
The paper strongly recommends the adoption of unified, integrated, and DCT-specific digital platforms to fully realize the benefits of decentralization. Platform developers should adopt international standards for health data exchange, such as HL7 FHIR and CDISC standards (PRM, CDASH, ADaM), to address the lack of data standardization and improve interoperability and modularity. Platforms should incorporate features that enhance participant engagement and adherence, such as customization options, simple user interfaces (UIs), push notifications, gamification, and allowing access to participant data . Security and governance teams are paramount to manage risks associated with malware, lost devices, and ensuring compliance with local legislation and data security protocols.

Regulatory Considerations
Digital platform design must maintain digital security and compliance with local legislation and data standards. The paper notes that a fully integrated, unified digital platform in a best-case scenario would use pre-existing standards (like CDISC and HL7) to guarantee interoperability. Adopting these standards and recommendations for data sharing, privacy, and security, as recommended by organizations like the Healthcare Information and Management Systems Society, is critical for future digital components used in DCTs. Improved data integrity and accountability in platforms could be further explored using technologies like blockchain to create an immutable ledger.

Findings
There is a need for more rigorous research beyond technology validation to ensure reliable real-world data capture and improved patient outcomes.
Limited translation of AI tools into medical practice despite their success in retrospective studies.
Insufficient application of social factors in clinical decision-making and DHT research.
Need for more rigorous and reproducible research designs with larger sample sizes and longer follow-up times.

Recommendations
Use the study's repository to inform future research by healthcare providers, policymakers, and the life sciences industry.
Consider how data collection methods (active or passive) complement primary study outcomes.
Conduct targeted systematic reviews to assess factors contributing to the digital divide.
Ensure greater consistency in metrics used across DHT research.

Regulatory Considerations
Manufacturers need to demonstrate the ongoing value of their products using real-world evidence.
Regulatory approvals for AI-based products are increasing, particularly for machine learning applications.

Findings
The need for rigorous verification and validation of DHT-generated measurements before they can be relied upon for safety, efficacy, or effectiveness.
The risk of widening health inequities due to disparities in access to healthcare and technology.
Challenges in ensuring data quality, privacy, and security.
The necessity for improved interoperability to facilitate data sharing.
The requirement for developing AI and machine learning algorithms for real-time data evaluation.

Recommendations
Improve the reach and effectiveness of DHTs, particularly among marginalized groups.
Develop and validate AI and machine learning algorithms for real-time evaluation of DHT data.
Ensure systematic protections for data privacy and security.
Enhance interoperability to unlock the full potential of DHTs.
Engage with stakeholders, including patients, to create efficient pathways for DHT adoption.

Regulatory Considerations
Compliance with rapidly changing digital health policies.
Utilization of FDA guidance documents and tools for understanding digital health regulations.
Consideration of regulatory oversight as DHTs become more integral to clinical trial design.

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
There is a need for appropriate training and infrastructure support to address challenges in implementing digital health technologies.
User acceptance is hindered by discomfort with technology among some participants.
Physicians face time constraints and question the utility of digital health technologies over current practices.
Concerns about data confidentiality among participants need to be addressed.
The complexity of digital health technology affects patient acceptance.

Recommendations
Provide appropriate training to staff and patients.
Ensure availability of appropriate infrastructure support.
Conduct pilot studies before scaling up to larger trials.
Address data confidentiality concerns.
Select devices with FDA clearance to minimize regulatory hurdles.

Regulatory Considerations
The FDA's Digital Health program provides regulatory advice for digital health technology applications.
Choosing devices with FDA 501(k) clearance can minimize regulatory hurdles.

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.