Content of Premarket Submissions for Device Software Functions: 2023 FDA Guidance, Basic vs. Enhanced Documentation, and Deliverable Checklist

The FDA final guidance Content of Premarket Submissions for Device Software Functions—issued on June 14, 2023 by the Center for Devices and Radiological Health (CDRH) and the Center for Biologics Evaluation and Research (CBER)—defines the mandatory software lifecycle documentation, architecture diagrams, risk management artifacts, and verification/validation test reports required in FDA 510(k) premarket notifications, De Novo classification requests, Premarket Approval (PMA) applications, Investigational Device Exemptions (IDEs), and Humanitarian Device Exemptions (HDEs). The guidance applies to all device software functions under Section 201(h) and Section 520(o) of the Federal Food, Drug, and Cosmetic Act—encompassing both Software in a Medical Device (SiMD) (embedded firmware/controllers) and standalone Software as a Medical Device (SaMD).

For regulatory affairs engineers and R&D quality teams preparing an FDA eSTAR submission, the June 2023 guidance superseded the legacy May 11, 2005 software guidance, retiring the three-tier Minor, Moderate, and Major Level of Concern (LoC) framework in favor of a two-tier risk-based system aligned with ANSI/AAMI/IEC 62304 and ISO 14971: Basic Documentation and Enhanced Documentation.

How Did the 2023 FDA Premarket Software Guidance Replace the Old Minor, Moderate, and Major Level of Concern?

Under the superseded 2005 FDA guidance, sponsors answered a sequence of 11 preset questions to classify their software as having a Minor, Moderate, or Major Level of Concern. Because practically all modern networked or clinical medical devices triggered at least a “Moderate” Level of Concern—and because the 2005 questions did not align cleanly with ISO 14971 hazardous-situation risk analysis or IEC 62304 Software Safety Classes (Class A, B, and C)—the June 2023 guidance collapsed the framework into two Documentation Levels:

• Enhanced Documentation Level: Required for any premarket submission that includes device software function(s) where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury to a patient, user of the device, or others in the environment of use—evaluated prior to the implementation of risk control measures. Enhanced Documentation is also required for: (1) devices intended to test blood donations for transfusion-transmitted infections or determine donor/recipient compatibility (Blood Establishment Computer Software), (2) device constituent parts of a combination product where a software failure could lead to death or serious injury as a result of the drug/biologic constituent, and (3) any Class III device (PMA) unless FDA agrees otherwise in a Pre-Submission (Q-Sub).
• Basic Documentation Level: Required for any premarket submission that includes device software function(s) where Enhanced Documentation is not required (i.e., where a software failure or flaw prior to risk controls would not present a probable risk of death or serious injury).

Critical Regulatory Distinction — Evaluating Risk Prior to Risk Controls: Sponsors must evaluate whether a software failure could lead to death or serious injury before taking credit for software or hardware risk controls. Furthermore, while the FDA Basic vs. Enhanced boundary parallels IEC 62304 Class B vs. Class C concepts, FDA evaluates “probable risk” (excluding purely theoretical, negligible-probability sequences of events) within the context of the whole medical device’s intended use.

What Is the Difference Between Basic and Enhanced Documentation Levels in FDA Software Submissions?

Both Basic and Enhanced Documentation submissions require a structured set of 10 core software lifecycle categories in the Design History File (DHF), but they differ substantially in **what must be submitted to FDA in the premarket package** across three specific deliverables—the Software Design Specification (SDS), Unit/Integration Testing Protocols & Reports, and Development/Maintenance Practice Details:

Submission Element (2023 FDA Guidance)	Basic Documentation Level	Enhanced Documentation Level
1. Documentation Level Evaluation	Statement specifying “Basic Documentation” and a risk-based rationale explaining why software failure does not pose a probable risk of death or serious injury.	Statement specifying “Enhanced Documentation” and rationale based on intended use and risk profile.
2. Software Description	Comprehensive overview of software features, programming languages, hardware platforms, OS/middleware, Off-The-Shelf (OTS/SOUP) components, interoperability interfaces, and AI/ML model summary.	Same comprehensive Software Description as Basic Level.
3. Risk Management File (ISO 14971)	Risk Management Plan, Risk Assessment (mapping hazardous situations, software causes, severity/probability, risk control measures, and verification links), and Risk Management Report.	Same complete Risk Management File as Basic Level.
4. Software Requirements Specification (SRS)	Complete SRS detailing functional, performance, interface, safety, cybersecurity, inputs/outputs, and alarm requirements (with requirement IDs for traceability).	Complete SRS (same requirement as Basic Level).
5. System and Software Architecture Design Chart	Detailed visual block/data-flow architecture diagrams showing modules, layers, external interfaces, OTS/SOUP modules, and data stores.	Detailed visual architecture diagrams mapping down to modular/unit components linked to the SDS.
6. Software Design Specification (SDS)	NOT required in the FDA submission (must still be documented and maintained internally in the manufacturer’s DHF).	REQUIRED in the FDA submission: Complete prospective SDS explaining how each SRS requirement is implemented in software modules, data structures, and algorithms.
7. Software Development, Configuration Management, & Maintenance Practices	Declaration of Conformity to IEC 62304 (Subclause 5.1, Clause 6, Clause 8) OR a high-level summary of life cycle, coding standards, configuration management, and maintenance processes.	Declaration of Conformity to IEC 62304 OR complete documentation of all Basic elements plus complete Configuration Management and Maintenance Plans/Procedures.
8. Software Testing (Verification & Validation)	Summary description of unit, integration, and system-level testing PLUS complete System-Level Test Protocols and Test Reports (pass/fail results, test configurations, and traceability to SRS).	Everything required for Basic Level PLUS complete Unit-Level and Integration-Level Test Protocols and Test Reports.
9. Software Version / Revision Level History	Log of software version numbers, dates, and differences tested during development up to the release version under review.	Same Revision Level History log as Basic Level.
10. Unresolved Anomalies (Known Bugs)	List of all remaining unresolved software anomalies/defects at release, including problem description, impact on safety/performance, root-cause/workaround, and risk-acceptability rationale.	Same Unresolved Anomalies list and risk rationale as Basic Level.

What Deliverables Are Required in a 510(k) or De Novo Submission for Device Software Functions?

To prevent FDA Refuse-to-Accept (RTA) holds or Additional Information (AI) deficiency letters during a 510(k) or De Novo review, regulatory engineering teams structure four core technical artifacts around bidirectional traceability:

1. End-to-End Traceability Analysis (Embedded in the Risk File, SRS, SDS, & Test Reports): Note that unlike the 2005 guidance—which listed “Traceability Analysis” as a standalone 11th row—the 2023 FDA guidance requires traceability to be woven directly throughout the submission artifacts, linking every Requirement ID (SRS) ↔ Architecture / Design Module ID (SDS) ↔ Hazard / Risk Control ID (Risk Assessment) ↔ Verification Test Case ID (V&V Report).
2. Clear Separation Between SRS (“What”) and SDS (“How”): A frequent FDA deficiency occurs when sponsors submit a combined “SRS/SDS” document or auto-generate a Doxygen code dump after coding is finished. The SRS must specify testable black-box functional and safety requirements (e.g., “SRS-042: The infusion controller shall trigger a high-priority audible and visual occlusion alarm within ≤ 3.0 seconds when downstream line pressure exceeds 600 mmHg”), whereas the SDS (submitted for Enhanced level) specifies the internal software state machines, interrupt handlers, sliding-window filter equations, and class interfaces implementing SRS-042.

Mapping IEC 62304 Declarations of Conformity and Section 524B Cyber Device Rules

• Using an IEC 62304 Declaration of Conformity to Streamline Section 7: Under Section VI.G of the 2023 guidance, manufacturers who have implemented an FDA-recognized version of ANSI/AAMI/IEC 62304 can submit a formal Declaration of Conformity (citing Subclause 5.1 for Software Development Planning, Clause 6 for Software Maintenance Process, and Clause 8 for Software Configuration Management Process) in lieu of uploading voluminous internal Standard Operating Procedures (SOPs).
• Alignment With FDA Premarket Cybersecurity Guidance (Section 524B “Cyber Devices”): The 2023 Device Software Functions guidance covers software functional verification and safety; for any device that includes software and can connect to the internet or network interfaces (a “cyber device” under FD&C Act § 524B), the premarket submission must also include a separate Cybersecurity section containing a Software Bill of Materials (SBOM), threat model, security architecture views, and penetration/fuzz testing reports per FDA’s September 2023 Premarket Cybersecurity Guidance.