GuidelinesTesting data2026.10.01
IEC 62304 Documentation: Trace Requirements Through to the Released Build
Software evidence works when requirements, risk controls, tests, unresolved anomalies and release records identify the same functions and versions. Build those links before expanding the document set.
Define the software boundary before listing documents
Treating only the app screens as software can omit server calculations, firmware and communication modules. Map inputs, outputs and information exchanges with external systems. Assess whether functions outside the medical purpose can affect the device functions.
IEC 62304 addresses development and maintenance life-cycle processes for medical-device software. It does not complete validation or final release of the entire device. Use the software-device approval guide for the Korean route, and establish the applicable edition and evidence scope for the product.
Align safety-class reasoning with risk management
Distinguish the software safety class from the Korean product risk class. Describe how failures contribute to hazardous situations, which controls exist outside the software and why those controls can be relied on. A developer’s belief that an error is unlikely does not by itself justify reduced documentation.
If functions are assessed separately, explain their architectural separation and how it is maintained. Link the class decision to risk entries, architecture and verification evidence rather than recording only the result. Use the same product definition as the ISO 14971 risk-management file.
Follow one requirement to its test result
This is a practical traceability example, not a prescribed submission form. Stable identifiers preserve the links across separate documents and tools. When a function changes, follow the impact to the end.
| Linked item | Example entry |
|---|---|
| Requirement SW-012 | Conditions for detecting out-of-range input and preventing calculation |
| Risk control RC-004 | Control inaccurate results caused by invalid input |
| Design | Input-validation module, boundaries and error response |
| Test TC-021 | Expected and actual results for normal, boundary and out-of-range input |
| Release evidence | Tested build, anomaly disposition and approval record |
“Input validation is provided” is not enough to reproduce a test. Specify units, missing values, invalid formats and communication delays where relevant. These are examples of challenging conditions, not a universal test combination.
Control external components and changes
Inventory operating systems, libraries, commercial modules and cloud dependencies with the versions and roles used in the product. Supplier testing does not eliminate the need to assess product-level impact. Assign responsibility for reviewing known problems, end of support and change notices, with criteria for action.
Commit history helps but is not the entire review and approval record. Connect the change request, reason, impact, additional testing and deployed version. Consider security changes alongside functional testing, and align versions with the cybersecurity evidence guide.
Include unresolved anomalies in the release decision
The conditions and consequences of remaining problems matter more than a closed-ticket count. Document reproduction steps, affected functions, risk assessment, interim measures and correction plans. Identify the approver and acceptance rationale, including any implications for user information or training.
A report should enable review through test environment, tools and versions, raw-data location and actions after failures, alongside the outcome summary. Explain which earlier results remain usable after partial retesting. Passing a retest alone does not explain the original failure.
Reconcile the submission with the deployed product
Match software versions, screenshots, risk documentation, reports and the installation package or deployment baseline. Products with independently updated servers and apps need identified version combinations and support conditions. Establish how the version in the field can be determined when an incident or inquiry arrives.
The traceability table here is a working template; the FDA source concerns US submissions and does not replace Korean obligations. Bring requirements, test results and deployment information to a software evidence review to find broken links before creating more documents.
Sources checked: 2026-09-28. The tables and preparation steps are practical suggestions; confirm the legal submission scope and applicable standards for the particular product.
Frequently asked questions
- Q. Does applying IEC 62304 complete device validation?
- No. IEC’s public scope excludes validation and final release of the medical device itself. Device-level performance, usability and other evidence still need to be connected.
- Q. Is software safety class the same as the device risk class?
- No. Assess software contribution to hazardous situations under the applicable standard; do not copy the Korean device class number.
- Q. Should open-source components be documented?
- Identify and evaluate external components that form part of the product and affect its functions or safety. Manage versions, purpose, known issues and change impact, and determine the applicable standard requirements.