Regulatory Considerations
The Premarket Notification (510(k)) database is a critical component of the FDA's regulatory framework for medical devices. Its primary function is to house information on devices that have been cleared through the 510(k) pathway, which is the most common route to market for medical devices in the U.S.

A 510(k) submission's central requirement is to demonstrate "substantial equivalence" to a legally marketed predicate device. This means the new device is as safe and effective as a device already on the market. Clearance of a 510(k) does not denote "approval" in the same way as a Premarket Approval (PMA) application but rather confirms that the device meets the necessary criteria for marketing.

The database provides transparency and serves as an essential resource for manufacturers to identify potential predicate devices for their own submissions. For healthcare providers, patients, and researchers, it offers a way to verify the regulatory status and clearance basis for a specific device.

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
Collaborative Communities are sustained, multi-stakeholder forums (including patients, industry, academia, and the FDA) dedicated to solving shared challenges in the medical device ecosystem. These communities are not intended to replace formal regulatory mechanisms. They are equipped to perform activities such as:
Developing best practices and strategies.
Generating and evaluating evidence to support novel approaches.
Clarifying ill-defined challenges and generating consensus on definitions.
Addressing issues related to product quality and safety.

Recommendations
The FDA/CDRH does not establish or fund these communities. Instead, the FDA recommends that interested stakeholders convene and lead these groups. The FDA reviews opportunities on a case-by-case basis for participation, considering:
The community's potential public health impact.
Alignment with the CDRH mission, priorities, and resources.
The existence of a formal governance structure, a convener, a plan to measure success, and a mechanism for sustained engagement.

Regulatory Considerations
The FDA's participation in these communities is a strategic priority for advancing regulatory science and fostering responsible medical device innovation. Examples of digital health-related collaborations include those focused on AI/ML, Digital Biomarkers, Digital Health Technologies (DHTs), and Real-World Data (RWD). The outcomes developed by these groups can inform and accelerate the development of science-based solutions to policy and scientific challenges.

Findings
Cybersecurity is an integral part of medical device safety and effectiveness, and manufacturers are responsible for addressing it throughout the entire device lifecycle. The FDA considers a device's cybersecurity as part of its benefit-risk assessment for both premarket and postmarket activities. A lack of robust cybersecurity controls can lead to patient harm, compromised device functionality, and breaches of data privacy. The dynamic nature of cybersecurity threats requires ongoing monitoring, risk management, and timely implementation of mitigation strategies.

Recommendations
Manufacturers should build cybersecurity into devices from the design phase ("secure by design") and conduct a thorough risk analysis to identify and mitigate potential vulnerabilities. Premarket submissions should include comprehensive documentation of the device's cybersecurity controls, a risk management plan, and a plan for postmarket surveillance and response. Manufacturers should establish a robust postmarket surveillance program to monitor for, identify, and address new cybersecurity threats in a timely manner. Clear and informative labeling is essential to help users understand and manage cybersecurity risks.

Regulatory Considerations
The FDA has the authority to take action against devices with inadequate cybersecurity that pose a risk to public health. The agency recommends that manufacturers use the Q-submission process to discuss specific cybersecurity questions related to their device submissions. Compliance with recognized standards and best practices for cybersecurity is strongly encouraged. Manufacturers must report certain cybersecurity incidents to the FDA as part of their postmarket reporting requirements. The FDA collaborates with other government agencies and stakeholders to promote a coordinated approach to medical device cybersecurity.

Key Principles (Findings)
This guidance establishes that the eSTAR platform will become the mandatory format for the electronic submission of medical device Pre-Submissions to the FDA. A key principle is that a properly completed eSTAR submission is considered a 'complete' submission, which allows it to bypass the traditional Refuse-to-Accept (RTA) process and instead undergo a more focused technical screening within 15 days. The structure of the eSTAR template is designed to align with the FDA's internal review memo, creating a more efficient and consistent review process. The guidance also makes it clear that while eSTAR use is currently voluntary, it will become required for Pre-Subs at least one year after this guidance is finalized.

Recommendations for Industry
The primary recommendation for industry is to familiarize themselves with and begin voluntarily using the eSTAR platform for Pre-Submissions in advance of the mandatory deadline. The guidance recommends that submitters use the structured, dynamic PDF to ensure all necessary elements of a complete submission are included, thereby facilitating a smoother and more efficient review. For certain types of follow-up communications, such as submitting meeting minutes or presentation slides, the guidance recommends they continue to be submitted as an eCopy rather than through the eSTAR template.

Regulatory Considerations
This guidance is issued under the authority of the Federal Food, Drug, and Cosmetic (FD&C) Act, which mandates the transition to electronic-only submissions. Upon finalization, the requirement to use the eSTAR template for Pre-Subs will be a binding regulatory requirement. The guidance outlines a specific technical screening process for eSTAR submissions that will replace the RTA process. If a submission fails this screening, it will be placed on hold, and the review clock will restart upon receipt of the corrected information. The document also specifies certain types of submissions, such as appeals and withdrawal requests, that will be exempt from the mandatory eSTAR requirement.

Findings
Clinically Acceptable Performance: A clinical study demonstrated that the weekly AFib burden estimates from the Apple AFib History Feature were in close agreement with a reference ECG patch, with an average difference of just 0.67%. The vast majority of measurements had paired differences within ±10% of the reference device.
Generalizable Across Subgroups: The device's accuracy was similar across various subgroups, including different sexes, races, ages, and skin tones.
Performance Post-Ablation is Uncertain: In a small subgroup of patients with a prior cardiac ablation, the device's performance, while still strong, showed slightly more variability and exceeded a pre-specified acceptance criterion. The study was not designed or powered to demonstrate equivalent performance in this specific group.
Technical Limitations Exist: The feature only provides a retrospective weekly estimate and does not give specific timestamps or durations of AFib episodes. It also does not detect other atrial tachyarrhythmias, like atrial flutter.

Recommendations
Appropriate Use: The document implicitly recommends using the tool precisely within its qualified context of use—as a secondary, not primary, endpoint for comparing AFib burden between study arms in cardiac ablation device trials.
Supplemental Data Collection: For studies involving patients who have had a prior ablation, it would be beneficial to assess the tool alongside other methods of determining AFib burden to better characterize its performance in this population.
Define Study-Specific Endpoints: Investigators using the tool are responsible for defining and justifying their specific study designs and what constitutes a clinically significant reduction in AFib burden.

Regulatory Considerations
MDDT Qualification: The Apple AFib History Feature is officially qualified by the FDA as a Medical Device Development Tool (MDDT), which reduces the burden on device developers, as they no longer need to independently justify its methodology for collecting weekly AFib burden estimates in their clinical studies.
Secondary Endpoint Only: A key limitation for its regulatory use is its qualification only as a secondary endpoint. It cannot, by itself, be used to evaluate the primary safety and effectiveness of cardiac ablation devices. This is partly because FDA typically requires the inclusion of any atrial tachyarrhythmia (not just AFib) for defining ablation success in pivotal studies.
Not a Replacement for Primary Endpoints: The tool's utility is intended to provide supplemental data and help better understand post-treatment AFib burden; it is not meant to replace more clinically well-defined primary endpoints.

Findings
The development and evaluation of medical devices require scientifically plausible and reliable tools for collecting data to support regulatory submissions. A lack of standardized, pre-vetted tools can lead to inefficiencies and unpredictability in the device development and review process. The qualification of development tools can be applied across a wide range of device areas, including cardiovascular, neurology, imaging, and cybersecurity. The evidence required for tool qualification must be robust enough to support its intended context of use.

Recommendations
Tool developers, medical device sponsors, research organizations, and academic institutions are encouraged to voluntarily submit proposals to the MDDT program to qualify their tools. Submissions should include a detailed description of the tool, a clearly defined context of use (COU), specific performance criteria, and a comprehensive plan for collecting evidence to validate the tool's performance and scientific plausibility. Collaboration in developing tools and supporting evidence is recommended to pool resources and increase the acceptance of qualified tools.

Regulatory Considerations
The MDDT program is a formal regulatory mechanism for the FDA to qualify tools that can be used to support assessments of medical device safety, effectiveness, or performance. Once a tool is qualified for a specific context of use, the FDA accepts assessments from that tool in support of regulatory submissions without needing to re-evaluate the tool's suitability. The program recognizes four main categories of tools: Non-clinical Assessment Models (NAM), Biomarker Tests (BT), Clinical Outcome Assessments (COA), and an "Other" category for tools that do not fit the primary classifications.

Findings
Diverse Pathways to Market Exist: The case studies demonstrate there is no single "right" way to approach the FDA; successful strategies are highly varied and include De Novo requests, 510(k) clearances, and leveraging established pathways for new indications.
Early FDA Engagement is Crucial: A consistent theme across the successful case studies is the value of engaging with the FDA early and often. This collaborative approach helps de-risk the development process, clarify evidentiary requirements, and build trust.
"Drug-like" Evidence Can Be a Differentiator: For novel software-based interventions, particularly digital therapeutics, generating a robust body of evidence similar to that of a pharmaceutical (i.e., randomized controlled trials) is a key strategy for gaining regulatory and commercial success.
Platform-Based Approaches are Emerging: Companies are finding success by moving from single-product solutions to integrated platforms that can monitor multiple health aspects, which requires a more holistic regulatory strategy.

Recommendations
Leverage Pre-Submission (Pre-Sub) Meetings: Sponsors are strongly encouraged to use the Q-Submission program to gain valuable, early feedback from the FDA on their validation plans and overall regulatory strategy.
Build a Multi-faceted Commercialization Plan: Regulatory clearance is only one step. The case studies recommend developing a comprehensive strategy that considers market access, reimbursement, and payer engagement from the outset.
Address Underserved Markets: The examples highlight opportunities for innovation in underserved areas, such as pediatrics and behavioral health, where DHTs can fill significant gaps in care.
Innovate on Evidence Generation: Sponsors should be prepared to innovate not just in their technology, but also in their approach to clinical evidence, tailoring their trial designs to best demonstrate the unique value of their digital product.

Regulatory Considerations
Understand the Risk Classification: The regulatory pathway for a DHT is determined by its intended use and associated risk level. Sponsors must correctly classify their device to determine if a 510(k), De Novo, or other pathway is appropriate.
AI/ML Devices Have Unique Needs: For products incorporating artificial intelligence or machine learning, sponsors must address specific regulatory considerations, such as predetermined change control plans (PCCPs), to manage algorithm updates post-market.
Interoperability is a Key Factor: For devices intended to be part of a connected health ecosystem (e.g., automated insulin dosing systems), demonstrating interoperability and cybersecurity is a critical component of the regulatory submission.

Findings
The Library of Human Factors Resources compiles external documents related to human factors, human-centered design, and usability in the context of Digital Health Technologies (DHTs), especially sensor-based DHTs (sDHTs). The resources in the library are categorized by usability validation activity:
Use-related risk assessment (topics include user tasks, use-errors, use-related hazards, and risk mitigation).
Design considerations (topics relate to product design).
Formative evaluation (topics related to usability evaluation of a prototype product).
Summative evaluation (topics related to usability evaluation of a final-version or marketed product).

Recommendations
The page recommends that users, developers, and evaluators utilize the library's interactive index to find relevant documents to their DHT:
Use the Search by Activity tab to filter by one of the usability validation activities listed above.
Use the human factors topic column to further narrow the search.
Review the document name, issuing body, and product of focus columns to identify the most relevant document.
Click the hyperlink to access the selected document, then use the information in the relevant sections column to locate the specific topics of interest.

Regulatory Considerations
The library is a collection of resources for accelerating sDHT adoption, and it specifically includes documents like regulatory guidance and industry standards. This emphasizes the importance of understanding and applying human factors principles for validation and achieving regulatory acceptance for sDHTs.

Findings
The V3+ Use Specification must contain a detailed description of the user groups, use environments, and the sDHT user interface. The user groups include end-users (individuals from whom data is captured) as well as carepartners, clinicians, researchers, and administrators. Characteristics of users (e.g., demographics, literacy, physical/cognitive capabilities, disease characteristics) and use environments (e.g., temperature, network availability, clutter) must be considered for risk management .

Recommendations
Developers must follow these four steps to create the Use Specification:
Identify all user groups: Create a list of users, including sub-categories (e.g., different types of researchers), and describe the characteristics of each group (e.g., health literacy, physical capabilities) to create detailed descriptions of representative users.
Identify all likely use environments: Create a list of typical environments (e.g., Home, Hospitals) and describe their characteristics (e.g., temperature, noise, network availability), also considering "edge cases" (e.g., extreme weather).
Describe the sDHT user interface: Detail all aspects of the hardware and software (visual, auditory, tactile cues), accessories (e.g., packaging, chargers), and all written materials and training (e.g., instructions for use, helpdesk troubleshooting).
Keep it up to date: The Use Specification is a living document that requires ongoing updates and maintenance throughout the sDHT development and usability validation process.

Regulatory Considerations
The development of the Use Specification is presented as the foundational step for the usability validation component of the V3+ framework. This document directly informs the subsequent Use-Related Risk Analysis.

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
There is widespread confusion among digital health developers regarding the complex and evolving regulatory landscape, with many uncertain about whether their products require regulation or which pathway to pursue. This lack of a clear regulatory strategy acts as a significant barrier to market access, investor confidence, and user trust. The heterogeneity of the digital health sector, coupled with varying international requirements, further complicates the path to market for innovators, hindering the scalability of effective solutions.

Recommendations
Digital health innovators should proactively integrate a tailored regulatory strategy into their core business plan, viewing it as a commercial differentiator rather than a hurdle. Developers are encouraged to utilize resources like DiMe’s regulatory pathway tools to navigate the U.S. and global landscapes effectively. Early and continuous engagement with regulators and collaborative efforts across the industry are essential to ensure products are developed to meet both market needs and regulatory standards, ultimately accelerating the delivery of high-quality digital health solutions to patients.

Regulatory Considerations
A comprehensive policy framework is necessary for the successful integration of digital health technologies, encompassing regulatory authorization, value assessment, and reimbursement. Developers must understand the nuances of different regulatory classifications, such as Software as a Medical Device (SaMD), and their specific evidentiary requirements. Greater international harmonization of regulatory standards is crucial for enabling global scalability. Regulatory bodies should continue to develop agile frameworks that can accommodate the rapid pace of innovation in digital health while ensuring patient safety and product effectiveness.