Fda Premarket

FDA Premarket Submission Software Documentation

Purpose

Guide preparation of FDA premarket submission software documentation (510(k), De Novo, PMA), including documentation depth determination, required documents, cybersecurity, SBOM, interoperability, and post-market commitments.

Important Note: The 2023 FDA guidance "Content of Premarket Submissions for Device Software Functions" replaces the previous "Level of Concern" (Minor/Moderate/Major) framework. The new guidance uses a risk-based approach with documentation depth tailored to the device's risk profile rather than discrete LoC categories.

When to Apply

• Preparing or updating FDA submissions involving software.
• Significant software changes that may alter LoC or documentation set.
• Adding networked features, cybersecurity controls, or interoperability.
• Introducing SOUP/third-party components impacting safety or cybersecurity.

Requirements (testable)

1. Documentation Level Determination: Determine documentation depth based on device risk profile per FDA 2023 software guidance; document rationale linking to intended use, hazards, and risk controls. Rationale: risk-based documentation scope. [Note: The previous "Level of Concern" (Minor/Moderate/Major) terminology has been superseded.]
2. Documentation Set: Provide required items (Software Description, architecture/design, requirements, risk analysis, V&V summary, unresolved anomalies, revision history) appropriate to risk level. Rationale: completeness and risk-proportionate evidence.
3. Cybersecurity Documentation: Include threat modeling summary, security controls, patch/update strategy, access control, logging, and penetration/DAST results per FDA cybersecurity guidance (Oct 2023). Rationale: security assurance.
4. SBOM: Provide SBOM covering SOUP/third-party components with versions, licenses, known vulnerabilities, and update plan. Rationale: transparency and vulnerability management.
5. Predicate/Comparison (510(k)): Compare software features, architecture, risks, and controls to predicate device; justify equivalence or differences. Rationale: substantial equivalence.
6. De Novo Specifics: Provide benefit-risk summary, special controls proposals (if any), and rationale for risk mitigations. Rationale: classification basis.
7. Interoperability: Describe external systems, standards used (e.g., HL7, BLE, WiFi), interface specifications, and error handling per FDA interoperability guidance. Rationale: safe data exchange.
8. Traceability: Provide matrix linking requirements ↔ risks ↔ design ↔ code ↔ tests ↔ anomalies. Rationale: verification completeness.
9. Anomaly/Problem Resolution: Include known anomalies with impact, mitigations, and justification for acceptability; track to post-market plan if deferred. Rationale: risk transparency.
10. Post-Market Commitments: Document update/patch policy, vulnerability handling, and monitoring plan. Rationale: lifecycle assurance.

Recommended Practices

• Maintain a submission bundle script to collect required artifacts for a given LoC.
• Keep an “FDA delta” note per release summarizing changes since last submission.
• Align cybersecurity content with FDA’s 2023 guidance: include SBOM, threat model, architecture, and software release integrity controls.
• Use standardized traceability exports (CSV/HTML) from your ALM and attach to submission.

Patterns

Documentation level determination (excerpt):

Risk Profile Assessment:
Basis:
- Device function: therapy delivery (infusion pump)
- Failure impact: could result in non-serious injury (infusion interruption < 10 min)
- Controls: alarms, safe state clamp, manual override
- Autonomy: clinician-initiated, no closed-loop control
Documentation Approach: Full software documentation per FDA 2023 guidance Section V

SBOM snippet:

components:
  - name: mbedtls
    version: 2.28.4
    license: Apache-2.0
    role: TLS for OTA and BLE transport
    known_vulns: []
    update_plan: track LTS patches quarterly; CVE feed monitored
  - name: tiny-rtos
    version: 1.4.2
    license: BSD-3
    role: scheduler for comms tasks
    known_vulns:
      - CVE-2025-1234 (mutex PI bug)
    mitigation: nesting disabled; wrapper enforces single-level; TEST-RTOS-12

Interoperability description (excerpt):

Interfaces:
- BLE GATT service (GLP profile) -> see spec BLE-GLP-IF-01; handles PHI.
- WiFi WPA3-Enterprise to hospital network; HL7 v2 over TLS 1.3 to HIS.
Error handling:
- Interface errors generate alarm code AL-IO-04; safe state: suspend upload, retain buffered data, retry policy exponential backoff.

Traceability matrix example (tabular excerpt):

REQ-210 | HZ-07 | RISK-CTRL-19 | DES-ARCH-PUMP-1 | pump_stop_on_door_open() | TEST-410, TEST-411 | Pass

Anti-Patterns (risks)

• Underestimating documentation depth when hazards include potential serious injury -> risk: FDA deficiency.
• Missing SBOM or vague “commercial library” entries -> risk: cybersecurity deficiency.
• No linkage between threat model and implemented controls -> risk: unverifiable security posture.
• Predicate comparison limited to high-level features only -> risk: insufficient substantial equivalence rationale.
• Known anomalies listed without mitigation or justification -> risk: approvability risk.

Verification Checklist

• Documentation level determined with rationale aligned to device risk profile and hazards/harms.
• Required documents collected appropriate to risk: Software Description, architecture, requirements, risk analysis, V&V, unresolved anomalies, revision history.
• Cybersecurity package includes threat model, controls, SBOM, update/patch plan, test results.
• SBOM complete with versions, licenses, vulnerabilities, and handling plan.
• Predicate/De Novo specifics addressed (as applicable).
• Interoperability described with standards, interfaces, and error handling.
• Traceability matrix generated and current.
• Known anomalies documented with mitigation/justification.
• Post-market plan (updates, vulnerability response) included.

Traceability

• Maintain submission bundle manifests listing file hashes and versions.
• Link SBOM components to code modules and controls; reference CVE tracking.
• Keep mapping of threat model elements to controls and verification.

References

• FDA "Content of Premarket Submissions for Device Software Functions" (2023) - replaces 2005 software guidance and "Level of Concern" framework.
• FDA "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (September 2023).
• FDA "Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices" (2017).
• FDA "Computer Software Assurance for Production and Quality System Software" (2022).
• 21 CFR 820 (QMS expectations; not a submission doc but informs processes).

Changelog

• 1.0.1 (2026-01-04): Audit corrections - replaced outdated "Level of Concern" (LoC) terminology with 2023 guidance framework, corrected FDA guidance titles to current versions.
• 1.0.0 (2026-01-04): Initial skill covering documentation sets, cybersecurity, SBOM, predicate/De Novo specifics, and traceability.

Audit History

• 2026-01-04: Regulatory audit performed. Critical corrections applied:
  • "Level of Concern" (Minor/Moderate/Major) terminology replaced - this was from the 2005 FDA guidance and is superseded by the 2023 guidance "Content of Premarket Submissions for Device Software Functions" which uses a risk-based documentation approach
  • FDA guidance title "Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices" (2005) replaced with current 2023 guidance title
  • Added reference to "Computer Software Assurance" (2022) guidance
  • Clarified interoperability guidance title and date