Most devices are now computers with a sensor and an actuator attached. When one fails, the question is often not whether a part broke but what the software did, in which version, and whether the manufacturer knew it could.
This guide explains the software life cycle the standards require, the records it leaves for every release, and how to request and read those records when a failure may have been in the code. It is written for readers who will not read the code, and do not need to.
Who this guide is for
- Legal counsel who must establish what version was running, what it was known to do, and what was tested.
- Manufacturers — software, quality, and regulatory teams who maintain the software file and decide what a problem report means.
- Hospitals — clinical engineering and IT staff who manage versions, updates, and the devices on the network.
This guide is general technical information. It is not legal advice. Terms follow IEC 62304:2006 with Amendment 1:2015 and FDA's 2023 guidance on premarket software documentation; a manufacturer's own procedures may name the same records differently.
01Software has a life cycle
IEC 62304 is the standard FDA recognises for the life cycle of medical device software. It does not say how to write software. It says what activities must happen, what each must produce, and how much of it is required by the harm the software could cause.
Each software system is classed by the worst harm a failure could contribute to after other risk controls are taken into account: A, no injury; B, non-serious injury; C, death or serious injury. The class sets how much design, verification, and documentation is required. The classification is itself a recorded decision.
Planning, requirements, architecture, detailed design, implementation and unit verification, integration and testing, system testing, and release. Then maintenance, which repeats the cycle for every change.
Software of unknown provenance: operating systems, libraries, and components the manufacturer did not develop under the standard. Each must be listed with its version, its known anomalies reviewed, and its failure modes considered in the risk analysis.
A problem resolution process: every reported problem recorded, investigated, classed for safety, and either fixed or closed with a reason. The problem report file is the software equivalent of the complaint file (guide 13).
Every item under version control; every release identified, with the exact contents, build, and tools that made it. A version number on a label should lead to one and only one set of files.
The safety class and the documentation level (next pages) decide how much of this record exists. Ask for the classification decision and its reasoning first.
Each box is a document the standard requires, to a depth set by the software class, with a version. A failure is traced from the right side of the V to the left: which test should have caught it, which requirement it violates, which hazard it belongs to.
02What FDA saw
A premarket submission contains part of the software record, at a depth FDA's guidance calls the documentation level.
Basic and enhanced
FDA's 2023 guidance replaced three levels of concern with two documentation levels. Enhanced applies where a failure or latent flaw could, before risk controls, present a probable risk of death or serious injury, and to Class III devices, combination products, and blood-establishment software. Enhanced submissions include the detailed design and unit and integration test evidence; basic ones summarise them.
What is in every submission
A software description; the risk management file; the requirements; the architecture; the development and maintenance process; verification and validation evidence; the revision history; and the unresolved anomalies, each with its effect and the reason it was left.
What is not
The code, the full test records, the problem reports, and everything after the submission: later versions, patches, and the letters to file that decided a change needed no new submission (guide 09).
03Requesting the record
These are the items to name in a request, in the terms of IEC 62304, for the version that was running and every version since. The form of the request is in guide 05.
Classification and plan
The software safety classification with its rationale; the software development plan and the maintenance plan.
Requirements, architecture, design
The software requirements specification, the architecture, and the detailed design for the items involved in the failure mode.
SOUP list
Every SOUP item with version, the review of its published anomalies, and the risk analysis of its failure.
Verification records
Unit, integration, and system test protocols and reports for the release in question, and the regression testing for each change since.
Traceability
The matrix linking hazards, requirements, design, and tests. A missing link is a finding on its own.
Configuration and release
Release records with version, build, and contents; release notes and the residual anomalies list for each version; the record of which units received which version, and when.
Problems and changes
All problem reports and change requests for the software, with their safety assessment and closure, from first release to the present.
Request each item for the version that was running and for every version since. A file that covers only the current release answers a different question.
04Reading the record
Software records are read from the version backwards.
Fix the version
From the device log, the label, and the service record (guide 07). Version, build, and configuration. If they disagree, that is the first finding.
Read the anomaly lists
The residual anomalies for that version, and the release notes for every later version. "Fixed" entries in later notes describe what the earlier version did.
Find the requirement
The requirement the failure violates, and the hazard it was meant to control. No requirement means the hazard was not analysed, or the control was not specified.
Find the test
The test that verifies the requirement: its protocol, its result, the version it ran on, and whether it was repeated after later changes.
Read the problem reports
Every report with similar symptoms, before and after the event: how it was classed, what was found, and how it was closed. "Could not reproduce" is a closure, not a finding.
Check the SOUP
Operating system, drivers, and libraries: their versions, their published defects, and whether any match the failure.
05What software failures look like
Software fails differently from hardware. It does not wear, and it does not fail at random; it fails every time the same conditions recur, and the conditions may be rare. Field reports describe the symptoms; these are the common ones.
A fault that appears under a sequence of actions, a timing coincidence, or a particular load, and not on the bench. Timing and concurrency faults are software faults until shown otherwise.
The device restarts on its own. A watchdog has caught the software not responding. The log shows the reset; the problem reports may show why.
The display, the alarm, and the actual output disagree: a value shown that was not delivered, an alarm limit that did not act, a setting that reverted.
A dose, a rate, a volume, or a time calculated wrongly for a particular unit, range, or rounding. Reproducible exactly, once the inputs are known.
Time-outs, lost messages, and stale data between the device and a network, a pump module, or a sensor. Each side logs its own view.
"No fault found" on a returned device is the expected result of a software fault tested under the wrong conditions. It closes nothing. The conditions in the log and the clinical record are the test.
06Where the record is weak
These are the findings an engineering reviewer looks for first in a software file.
The fielded version was not the tested version
System testing ran on one build; a later build shipped, with changes and no full regression.
A known anomaly, deferred
The failure mode is in the residual anomalies list of the release, with a rationale that rests on probability rather than on a control.
A hazard with no requirement
The risk file lists the hazard; nothing in the requirements controls it; nothing in the tests checks it.
A test that was never repeated
The requirement was verified once, before several changes to the items that implement it.
SOUP without a review
An operating system or library listed with no version, or with no review of its defects.
Problem reports closed without analysis
Similar reports closed as "cannot reproduce" or "user error" with no record of what was tried.
A patch outside the process
A change made quickly in the field with a shortened record: no requirement change, no risk review, limited testing.
Each finding is a comparison between what the standard requires and what the file contains. The standard is the measure; the file is the evidence.
✓Device software at a glance
- Version, build, and configuration established from log, label, and service record
- Software safety classification and rationale obtained
- Documentation level and the submission's software section read (guide 09)
- Residual anomalies list for the version, and release notes for every later version
- Requirement and hazard for the failure mode located; traceability checked
- Test protocol and report for that requirement; version it ran on; regression since
- Problem reports with similar symptoms, with classification and closure
- SOUP list with versions and anomaly reviews
- Changes since release: change requests, letters to file, regression records
- Which units received which version, and when
- Conditions from the log and clinical record written as a reproduction test
§Sources and further reading
- IEC 62304:2006 + A1:2015 — Medical device software, software life cycle processesiec.ch
- FDA — Content of Premarket Submissions for Device Software Functions (June 2023)fda.gov
- FDA — General Principles of Software Validation (2002)fda.gov
- eCFR — 21 CFR Part 820, Quality Management System Regulation; design and development under ISO 13485 clause 7.3ecfr.gov
A–ZTerms used in this guide
- Software system
- The software of a device, or a part of it, considered as one item for classification and documentation.
- Software safety class
- A, B, or C: the class assigned to a software system by the worst harm a failure could contribute to, after other risk controls.
- SOUP
- Software of unknown provenance: components the manufacturer did not develop under the standard, such as an operating system or a library.
- Software requirements
- The statements of what the software must do, including the risk controls it implements, each one verifiable.
- Verification
- Confirmation by examination and objective evidence that specified requirements have been fulfilled: unit, integration, and system testing.
- Residual anomaly
- A known defect left in a release, listed with its effect and the reason it was accepted.
- Problem report
- The record of a reported problem with the software: its investigation, its safety classification, and its closure.
- Documentation level
- FDA's basic or enhanced level, which sets how much of the software record a premarket submission must contain.