FDA Device Software Functions — Premarket Submissions

The guidance explains what FDA needs to review device software

The guidance applies to the documentation recommended for premarket submissions involving device software functions. It covers software that meets the device definition, whether it operates within a hardware medical device or is itself a device software function.

It replaced FDA's 2005 guidance for software contained in medical devices and retired the former “level of concern” approach. It does not replace software lifecycle engineering, design controls, risk management, cybersecurity evidence or device-specific requirements. Those activities create the evidence from which the submission is assembled.

Use MTL-107 — Software Lifecycle and MTL-303 — IEC 62304 Software Lifecycle for the underlying development framework.

FDA uses Basic and Enhanced documentation levels

The documentation level is based on the possible consequences of a software failure or flaw, not simply device classification or the development team's view of software complexity. Enhanced documentation is appropriate where a failure or flaw could create a hazardous situation with a probable risk of death or serious injury, or where the software implements a risk control whose failure could lead to that consequence.

Document the decision early and revisit it when intended use, architecture, risk controls or available safety information changes. The selected level affects the detail expected for certain documents; it does not change the obligation to develop safe, effective and adequately verified software.

• Identify the software functions and their contribution to device behaviour.
• Consider direct failures, delayed or incorrect output and loss of a software risk control.
• Use the risk analysis and system architecture to support the rationale.
• Apply the highest relevant level to the submission documentation as FDA recommends.
• Keep the determination controlled and consistent with the submitted configuration.

Describe the software in its medical-device context

The software description should explain what the software does, its significant features, operating environment, hardware platform, interfaces, inputs, outputs and role in the device. Reviewers should be able to understand the software boundary and how the functions support the intended use.

Include diagrams where they communicate structure or behaviour more clearly than prose. Identify software items supplied by third parties, externally hosted functions, mobile or cloud elements and configurable or optional features. The description should agree with labelling, architecture, risk analysis and testing.

Software risk evidence connects failures to controls

The submission should explain reasonably foreseeable software hazards, causes, hazardous situations, possible harms and the controls implemented. Software can initiate a hazard, fail to detect one, provide incorrect information, delay a response or defeat a control implemented elsewhere.

Show how risk-control measures became requirements and how their effectiveness was verified. Where a control depends on users, external systems or hardware, make the dependency and interface explicit. Use MTL-105 — Medical-device Risk Management for the practical chain from hazards to evidence.

Requirements must be complete enough to support objective testing

The software requirements specification should define the software's functional, performance, interface, data, alarm, security, safety, configuration and environmental behaviour. Requirements should be unambiguous, verifiable and consistent with system requirements and risk controls.

Do not reduce the submission to an exported issue list without context. Explain identifiers, status, baselines and how requirements relate to the released version. For Enhanced documentation, provide the additional detail expected by the guidance.

MTL-103 — User Needs and Design Inputs explains how higher-level needs become controlled, testable inputs.

Architecture and design reveal how the software works

Architecture documentation should identify software items, responsibilities, interfaces, data and control flow, external dependencies and allocation of safety or security functions. It should make important separation, redundancy, monitoring and fault-handling strategies visible.

Detailed design information should be proportionate to the selected documentation level and the parts of the software that require reviewer understanding. Avoid diagrams that use unexplained blocks or conflict with requirements and tests.

Traceability demonstrates completeness

Traceability should connect system and software requirements, hazards and controls, architecture or design elements, and verification results. Its purpose is to reveal omissions and support review, not merely populate a matrix.

Use stable identifiers and controlled baselines. A reviewer should be able to select a safety-significant requirement and find its source, implementation allocation, test evidence, result and unresolved issues without relying on tribal knowledge.

Verification evidence should support the submitted claims

Provide a software testing summary and sufficient supporting evidence to explain strategy, levels, environments, acceptance criteria, results and conclusions. Testing should cover normal operation, boundaries, faults, interfaces, safety functions, security controls and relevant regression.

For Enhanced documentation, the guidance recommends more detailed evidence. In every case, explain deviations, failures and retesting rather than reporting only a pass percentage. Test configuration must be traceable to the software version in the submission.

MTL-106 — Verification and Validation describes evidence planning and the distinction between verification and validation.

Unresolved anomalies require transparent evaluation

List unresolved software anomalies relevant to the released configuration and explain their impact, detection, workarounds, risk evaluation and rationale for release. An anomaly should not disappear from the submission because it has a low internal priority or is difficult to reproduce.

Reconcile anomaly records with risk management, testing, labelling and post-market plans. If an anomaly affects a claimed function or risk control, the release rationale must be particularly clear.

Lifecycle and configuration records establish control

Summarise development, maintenance, configuration and change-control practices relevant to the submitted software. Provide a revision-level history that explains significant changes and identifies the current version.

For software of unknown provenance, legacy components or third-party software, identify the available evidence, gaps, compensating controls and product-specific verification. Software component information may also need to support the cybersecurity submission addressed in MTL-308 — FDA Cybersecurity in Medical Devices Guidance.

Assemble the submission as a navigable evidence package

Create a controlled index that maps each guidance element to the submitted document and location. Use consistent names, versions and identifiers. Remove contradictions between summaries and source evidence, and confirm that all records describe the same intended use and device configuration.

• State the documentation-level determination and rationale.
• Describe every device software function in scope.
• Include risk, requirements, architecture and design evidence at the expected depth.
• Provide traceability and software-testing evidence.
• Identify unresolved anomalies and release rationale.
• Provide revision history and lifecycle information.
• Cross-reference cybersecurity evidence where applicable.
• Perform an independent submission-consistency review.

Common misconceptions

Practical submission checklist

• Does the software description match the device, labelling and architecture?
• Is the Basic or Enhanced documentation-level rationale current and risk-based?
• Are software requirements controlled, testable and complete?
• Does architecture show all important interfaces and dependencies?
• Can safety and cybersecurity controls be traced to verification?
• Do test summaries identify configuration, failures and conclusions?
• Are unresolved anomalies reconciled with risk and release decisions?
• Does the revision history identify significant changes?
• Are third-party and unknown-provenance elements addressed?
• Can a reviewer navigate the package without relying on the development team?