NA

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.

NA

Findings
The goal of sDHT design is to create tools that are functional, intuitive, accessible, and enjoyable to use, moving beyond merely minimizing use-errors. Human-centered design (HCD) is the preferred term over user-centered design, emphasizing the impact on many user groups beyond just the end-users. "Users" encompass end-users (patients/participants), carepartners, clinicians, investigators, and administrators.

Recommendations
Developers of sDHTs should adhere to the following HCD principles:
Empathetic: Take time to deeply understand users' needs, behaviors, and emotions, capturing this in the use specification.
Holistic: Consider the entire end-to-end user journey, including hardware, software, accessories, packaging, instructions for use, and training.
Iterative: Employ an iterative approach to designing, prototyping, testing, and refining, using formative evaluations to identify use-errors and gather usability data, capturing this in the use-related risk analysis.
User-centric: Improve usability by capturing user feedback in real-world settings, gradually recruiting larger, more diverse samples that represent the intended use population.
Inclusive: Collaborate with individuals representing all user groups by hiring them as consultants or creating user advisory panels to influence design decisions (co-design).
Multidisciplinary: Ensure the development team includes colleagues from various disciplines to bring diverse perspectives and innovative solutions.

Regulatory Considerations
The document ties the HCD process to risk management and eventual validation by recommending that findings from formative evaluations (used to identify use-errors) be captured in a use-related risk analysis. The approach aligns with the principles of the overarching V3+ framework.

Findings
Usability is a multi-domain concept that requires a combination of methods for evaluation. Evaluations fall into two types: formative (for design modification of prototypes) and summative (for demonstrating usability of the final product to a representative user sample). The user experience metrics fall into several domains, including: Satisfaction, Usefulness, Ease of use, Learnability, Efficiency, Memorability, Understandability, Actionability, Readability, and Use-errors. Metrics related to Satisfaction and Usefulness are always subjectively reported by users.

Recommendations
Developers should select metrics based on the specific usability-related domain being evaluated.
Subjective Data (e.g., Satisfaction, Usefulness): Capture through qualitative surveys, quantitative surveys (scales), interviews, focus groups, and think-aloud evaluations .
Objective Data (e.g., Ease of use, Use-errors): Capture through direct or indirect observation (e.g., counting steps/attempts, timing task completion), or by using data generated by the sDHT (e.g., error reports, timestamps, page load times).
Time-based Metrics: Evaluate Learnability (ease of first use), Efficiency (ease with experience), and Memorability (ease after non-use) by measuring ease of use at different points in time .
Information Presentation: If the sDHT presents clinical data or written information (instructions, warnings), evaluate Understandability, Actionability, and Readability .
Use-errors: Objectively capture the number, type, and recoverability of use-errors (actions, or lack thereof, that may result in harm) via observation and sDHT data, noting that "use-error" is preferred to "user-error".

Regulatory Considerations
While this guide does not reference regulatory bodies like the FDA, it is part of the V3+ framework and recommends that researchers prioritize essential documents like the use specification and use-related risk analysis before designing a usability study. Summative evaluations demonstrating usability against a representative user sample under intended use conditions are the standard for demonstrating product fitness.

Findings
For an sDHT to be considered fit-for-purpose, a researcher or healthcare provider must understand the alignment between the sDHT's intended use (What it does, who uses it, where/when/how) and their own context of use . Key information for this assessment comes from the developer's Use Specification (detailing hardware, software, accessories, training) and Use-Related Risk Analysis (detailing warnings, harms from use-errors, and risk avoidance) . Usability validation evidence should cover study objectives, protocols, participant characteristics, metrics, and collection methods.

Recommendations
Researchers/providers should use the checklist to:
The Basics: Compare the sDHT's intended use to their context of use; if there is substantial overlap, existing evidence may be sufficient.
Use Specification/Risk Analysis: Gather detailed descriptions of the sDHT's hardware, software, accessories, written materials, training, cautions, warnings, and potential harms from use-errors to update their own Use Specification and Use-Related Risk Analysis .
Existing Evidence: Access existing usability validation study results (objectives, methods, participant characteristics, metrics, etc.) to determine its applicability and generalizability to their context of use .
Collaboration: Consider establishing a collaborative relationship with the developer to provide feedback for next-generation sDHTs, ensure version control, and potentially collaborate on future usability validation studies .

Regulatory Considerations
The document notes that if the sDHT is a regulated medical device, the intended use statement should already capture the answers to the basic questions. The entire checklist is framed around the V3+ framework, which is designed to ensure the rigor necessary for a product to be considered fit-for-purpose by all stakeholders.

Findings
FDA considers electronic records and signatures to be equivalent to paper records and handwritten signatures when they meet the requirements of 21 CFR part 11. Advances in technology, including Digital Health Technologies (DHTs) and cloud computing, necessitate updated guidance on ensuring the authenticity, integrity, and confidentiality of electronic data in clinical investigations. Records submitted to the FDA under predicate rules (e.g., marketing applications) are subject to part 11. FDA does not intend to assess the compliance of external Real-World Data (RWD) sources like Electronic Health Record (EHR) systems with part 11, but the sponsor remains responsible for the quality and integrity of all submitted data.

Recommendations
Risk-Based Validation: Regulated entities should use a risk-based approach to validation for all electronic systems deployed, proportionate to the risks to participant safety and reliability of trial results. Validation must cover system functionality, trial-specific configurations, customizations, and interoperability.
Data Retention & Audit Trails: Electronic records must be retained for the applicable period in a secure and traceable manner. Audit trails must capture all changes (old/new value, user ID, date/time) and should be protected from modification.
Security & Access Controls: Logical and physical access controls (e.g., strong login credentials, multi-factor authentication) must limit system access to authorized users based on a documented risk assessment. Security safeguards (e.g., encryption, antivirus) must be in place to protect data at rest and in transit.
DHT Use: DHTs should be selected and validated to be fit for purpose. The data originator (person, system, or DHT itself) must be associated with every data element as part of the audit trail. The final location of source data for inspection is the durable electronic data repository, not the individual DHT.
Outsourcing: Regulated entities must have a written agreement with IT service providers (including for cloud computing) detailing roles, responsibilities, and the service provider's ability to provide data integrity and security safeguards. The sponsor must maintain oversight.

Regulatory Considerations
FDA does not certify electronic systems or signature methods; they are evaluated during inspection. Users of electronic signatures must submit a letter of non-repudiation to the FDA certifying that the electronic signature is the legally binding equivalent of a handwritten signature. Security breaches impacting participant safety or privacy should be reported to the IRB and FDA in a timely manner.

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
A Use-Related Risk Analysis (URRA) is essential for identifying potential use-errors (actions or lack of action that may result in harm) and their associated use-related hazards (source of potential harm) when using an sDHT. The analysis must focus on user interactions with the sDHT, including all user groups (end-users, clinicians, carepartners, researchers, and administrators). Critical tasks are defined as those use-errors that may result in serious harm.

Recommendations
Developers should follow these five steps for the Use-Related Risk Analysis:
Describe all user tasks: Identify the sequence of actions a user performs to achieve a goal, which can be derived from sources like a task analysis or formative evaluations.
Describe potential use-errors: Identify and document potential actions or lack of actions that may result in harm for each task, noting that "use-error" is preferable to "user-error".
Describe potential use-related hazards: Determine the source of potential harm resulting from each identified use-error.
Develop a plan to minimize or eliminate known risks: The preferred approach is inherent safety by design (eliminating the error). If not feasible, use protective measures (e.g., warnings) or, as a last resort, provide instructions to users. Identify methods to evaluate the effectiveness of the chosen mitigation strategy.
Keep it up to date: The URRA is a living document requiring ongoing updates throughout the sDHT development and usability validation process.

Regulatory Considerations
The URRA is presented as a fundamental step within the V3+ framework for ensuring device usability and minimizing risk, implicitly setting the groundwork for regulatory compliance related to device safety. The minimization of use-errors, particularly for critical tasks, is a central tenet of device development best practices.

Findings
The DTRA Best Practice Evaluation Rubric uses five dimensions to determine if a DCT practice should be considered a "best practice":
Evidence of Success: Requires measurable and demonstrable success using KPIs and tangible outcomes.
Improving Patient Experience: Must address the needs of patients, caregivers, and therapeutic experts, demonstrating improved experience and engagement.
Site Impact: Must consider the implications of adoption and the practical impact on site burden and working practices.
Operational and Technical Feasibility: Ensures operational and technical aspects (including ongoing support, security, integrity, scaling, and reuse) have been fully considered when deploying new technologies.
Regulatory & Ethical Compliance: Requires appropriate consideration of global and local regulations and guidance (e.g., ICH E6/E8, GDPR, HIPAA), including adherence to privacy, consent, and ethical safeguards.

Recommendations
A practice should demonstrate several key factors across the dimensions:
Patient-Centricity: Reduce patient burden by offering the option to reduce physical visits and enable greater patient empowerment and access to information. It should strive to increase the diversity of recruited patients while mitigating bias toward technologically literate patients.
Site Support: Achieve a net reduction in burden for sites, utilizing simple, intuitive technology with minimal, on-demand training. It must provide clarity of fiduciary responsibility and use technology to increase risk-based monitoring without sacrificing data integrity.
Technical Rigor: Have a clear problem statement and a thoroughly defined strategy to mitigate operational and technical risks. It should take a holistic approach and ensure the solution is fit for use for the specific patient population, aligning with data privacy and security standards.

Regulatory Considerations
Practices must ensure compliance with both global and local regulations and Health Authority guidance. Explicit attention must be given to aligning with ICH E6 (Good Clinical Practice) and privacy laws like GDPR and HIPAA. The design must protect stakeholders providing sensitive or personal data with safeguards to ensure ethical safety.

Findings
There are various formal and informal engagement pathways available for developers of Digital Health Products and Combination Products to communicate with the FDA to seek advice regarding product classification, regulatory status, and submission strategies. Informal pathways include the Digital Health Inquiry (via the Digital Health Inbox), the DICE Mailbox Inquiry, and the Pre-RFD Process, which provide non-binding feedback. Formal pathways include the 513(g) Program for classification, and the Q-Submission Program (encompassing Pre-Submissions for pre-application feedback and SRD for risk determination).

Recommendations
Manufacturers should use the provided map to determine the appropriate pathway based on their product type (standalone digital health or combination product) and the type of advice they are seeking (informal or formal). The Pre-Submission (Pre-Sub) program is recommended as an opportunity to obtain formal feedback "prior" to submitting an application, particularly if a new product's regulatory pathway is unclear or if planning a study to support a future application. Combination Product manufacturers can use CPAMs to clarify marketing authorization standards or post-market modification requirements.

Regulatory Considerations
The 513(g) Request provides information on a product's classification and applicable regulatory requirements but does not determine substantial equivalence or make final marketing authorization decisions. Programs like the CDRH-Payor Connection and Parallel Review with CMS are voluntary and designed to expedite patient access by aligning clinical evidence for both regulatory clearance/approval and coverage decisions. Participation in these programs, however, does not alter the FDA’s existing, separate standards for regulatory review.