How to Document Risk Analysis Evidence for a Digital Therapeutics FDA 510(k) Review Packet

Conduct Risk Analysis Following ISO 14971

Build your risk management file around ISO 14971 risk management. For digital therapeutics (DTx), connect each claimed clinical benefit to identified hazards, risk controls, and verification evidence. Keep the narrative concise, but make the chain of logic auditable from user need to residual risk acceptability.

Define scope and user context

• State the intended use, indications, and target population, including comorbidities and contraindications.
• Describe use environments (home, clinic), connectivity assumptions, and dependencies (mobile OS versions, sensors, cloud services).
• Clarify clinical workflow touchpoints and when to defer to a healthcare professional.

Identify hazards and hazardous situations specific to DTx

• Algorithmic errors, inaccurate inputs, data loss/corruption, latency, and downtime impacting therapy timing or dosing guidance.
• Behavior-change content risks (e.g., triggering adverse mental health events), misleading feedback, and over-reliance on app advice.
• Privacy breaches, misidentification, localization/time-zone errors, and interoperability failures with connected devices.

Estimate, control, and evaluate residual risk

• Apply severity/probability scoring, document risk controls (inherent, protective, and information for safety), then re-score residual risk.
• Show verification of each control and justify acceptability using your company’s criteria and clinical benefit rationale.
• Integrate with IEC 62304 software processes so safety classifications drive design and testing depth.

If you plan a Special 510(k), ensure the analysis demonstrates that modifications do not introduce new or increased risks; this groundwork will streamline your special 510(k) hazard analysis.

Provide Enhanced Software Documentation

For enhanced level devices, present a cohesive software narrative that proves you engineered the product to be safe, effective, and maintainable. Tie every artifact to risk controls and objective evidence rather than submitting standalone documents.

Core artifacts to include

• Software description and architecture: system context, data flows, states, interfaces, error handling, and assumptions/constraints.
• Requirements: user needs, system and software requirements with uniquely identified items linked to hazards and controls.
• IEC 62304 software testing deliverables: verification plans, unit/integration/system tests, acceptance criteria, results, and coverage summaries.
• SOUP/OTS assessments: component inventory, known anomalies, cybersecurity posture, and update policy impacts.
• Configuration management: build provenance, release notes, unresolved anomalies with clinical justification, and versioning strategy.
• Usability/human factors evidence mapping UI risks (e.g., mis-taps, readability) to mitigations and validation outcomes.

Make the relationships obvious: each safety-relevant requirement points to the test case(s), test report(s), and the risk it mitigates. This linkage is central to enhanced documentation.

Include Cybersecurity Risk Analysis

Use AAMI TIR57 cybersecurity methods to perform a structured threat model and link findings to your ISO 14971 file. For DTx, cybersecurity is inseparable from safety because loss of integrity, availability, or confidentiality can directly impact clinical outcomes.

Threat modeling and controls

• Identify assets (PHI, models, keys), attack surfaces (mobile app, APIs, BLE, cloud), threats, and vulnerabilities; rate exploitability and impact.
• Select controls proportionate to risk: authentication and authorization, least privilege, secure data-at-rest/in-transit cryptography, secure session management, and tamper resistance.
• Document security architecture, key management, secure update mechanisms, logging, and time synchronization for audit trails.

Security testing and maintenance

• Provide SAST/DAST/SCA results, penetration testing summaries, API fuzzing outcomes, and remediation evidence.
• Include an SBOM, vulnerability monitoring and triage process (e.g., CVSS-based), patch timelines, and coordinated vulnerability disclosure approach.
• Show how cybersecurity risk controls are verified and how residual cyber risk is deemed acceptable in the clinical context.

Submit Performance Testing Data

Align performance evidence with claimed indications and risk controls. For algorithm-driven DTx, describe datasets, ground truth methods, and generalizability. Present metrics meaningful to clinical outcomes (e.g., accuracy, sensitivity/specificity, AUC, adherence/engagement measures, latency) alongside predefined acceptance criteria.

Bench, simulated-use, and clinical support

• Bench/algorithm validation across representative devices, OS versions, locales, and connectivity conditions; include failure injection.
• Simulated-use and usability validation showing users can perform critical tasks safely under realistic conditions.
• Clinical or real-world evidence when needed to support substantial equivalence, with clear statistical plans and risk-focused endpoints.
• FDA 510(k) predicate device comparison summarizing similarities/differences, demonstrating equal or better performance in risk-relevant scenarios.

Tie each performance result to specific risks and controls so reviewers can see how evidence reduces residual risk to acceptable levels.

Use eSTAR Submission Format

Use the eSTAR submission format to organize content consistently and reduce administrative deficiencies. Complete all required modules, justify non-applicable sections, and attach evidence where prompted so your packet is structured for efficient review.

Practical tips

• Mirror eSTAR sectioning in your document filenames and IDs to simplify cross-references.
• Answer data fields directly in the template, then attach full reports; keep summaries aligned with the detailed attachments.
• Run automated validations, resolve flags, and confirm that cross-references to risk, testing, and labeling are intact.
• Maintain consistency between the submission text, figures, and attached PDFs to avoid contradictory statements.

Prepare Traceability Matrix

A robust traceability matrix for software makes your logic transparent. Use it to connect intended use, user needs, requirements, design elements, tests, defects, and risk controls, so any reviewer can start at a hazard and quickly find the proving evidence.

What to trace

• User needs → system requirements → software requirements → design units/components.
• Requirements and design items → verification/validation tests → objective evidence (report IDs, page/section).
• Hazards and controls → specific requirements and tests → residual risk results and acceptance rationale.

How to maintain the matrix

• Use stable, unique IDs; manage revisions under configuration control.
• Record unresolved anomalies and mitigations with clinical justifications.
• Export a submission-ready snapshot referenced throughout eSTAR to ensure reviewers see a consistent single source of truth.

Present Hazard Analysis Summary

Provide a concise, decision-focused summary that highlights the most consequential hazards and how your controls and evidence reduce risk. Emphasize safety-critical scenarios unique to DTx, such as incorrect therapeutic recommendations, failure to alert, or content that could trigger harm.

What reviewers expect to see

• Top hazards with initiating causes, harms, and pre- vs. post-mitigation risk levels.
• Mapped controls (design, protective, information for safety) with verification references and outcomes.
• Residual risk acceptability and overall benefit-risk, including human factors and real-world use considerations.

Linkage to predicate comparison and device changes

• For Special 510(k), show how each modification was analyzed and why no new questions of safety/effectiveness arise.
• Summarize FDA 510(k) predicate device comparison findings that support equivalence in risk-relevant performance.

Conclusion

To document risk analysis evidence effectively, anchor your file to ISO 14971, deliver enhanced software documentation with IEC 62304 software testing results, present a rigorous AAMI TIR57 cybersecurity assessment, provide performance data tied to claims, structure everything in the eSTAR submission format, maintain a living traceability matrix, and end with a clear hazard analysis summary that proves residual risk is acceptable.

FAQs

What is the role of ISO 14971 in risk analysis for digital therapeutics?

ISO 14971 provides the lifecycle framework to identify hazards, estimate and control risks, verify controls, and judge residual risk acceptability. For digital therapeutics, it ensures algorithm behavior, content delivery, connectivity, and user interactions are systematically analyzed, controlled, and verified, with outputs feeding your hazard analysis summary and aligning with IEC 62304 development and testing activities.

How should cybersecurity risks be documented for FDA 510(k) submissions?

Develop an AAMI TIR57 cybersecurity threat model linked to your ISO 14971 file, list assets and attack surfaces, rate exploitability and impact, and map each risk to specific controls. Provide SBOM, SAST/DAST/SCA and penetration test results, vulnerability monitoring and patch processes, secure update design, logging/audit plans, and evidence that cybersecurity controls were verified and that residual cyber risk is clinically acceptable.

What software documentation is required for enhanced level devices?

Enhanced level devices typically include a comprehensive software description and architecture, complete requirements with risk linkages, IEC 62304 software testing plans and results (unit, integration, system), SOUP/OTS evaluations, configuration management and release history, unresolved anomaly justifications, usability validation summaries, and a traceability matrix that ties hazards, requirements, controls, and tests to objective evidence.

How does the eSTAR format impact 510(k) submission preparation?

The eSTAR submission format structures your packet, prompts for justifications, and reduces administrative deficiencies. It guides placement of software, cybersecurity, and performance evidence, enforces consistency through required fields and validations, and makes cross-references to your traceability matrix and hazard analysis easier for reviewers to follow, which can accelerate interactive review.