--- name: meddev-fda-premarket description: 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. Use when working on fda premarket in medical device software. license: MIT metadata: skill_id: REG-FDA-PREMARKET version: 1.0.0 last_updated: '2026-01-04' applies_to: Class A, Class B, Class C jurisdiction: FDA prerequisites: REG-IEC62304, REG-ISO14971 category: regulatory --- # 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): ```markdown 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: ```yaml 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): ```markdown 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