指南检测资料2026.10.01

IEC 62304软件文件：从需求追踪到实际发布版本

软件证据的关键是让需求、风险控制、测试、未解决异常和发布记录指向同一功能与版本。先建立这些关联，再考虑增加文件数量。

列文件清单前，先画清软件边界

只把应用界面算作软件，可能遗漏服务器计算、固件及通信模块的证据。应画明输入、输出和外部系统间的信息交换。即使某功能不属于医疗用途，也要评估其是否影响器械功能。

IEC 62304涵盖医疗器械软件开发与维护的生命周期过程，并不意味着一套文件即可完成整机确认和最终放行。韩国路径可参阅软件医疗器械注册指南，具体适用版本与证据范围应逐产品确定。

软件安全级别与韩国器械品目风险等级应区分。说明故障如何促成危险情境、有哪些软件外部控制、凭什么信赖这些控制。不能仅凭开发人员认为“出错概率低”，就减少文档范围。

若将功能分开评价，还需说明结构分离及其维持方式。仅列判断结果不如关联风险条目、设计结构与验证资料。使用与ISO 14971风险管理一致的产品定义。

以下为实务追溯表，并非指定申报格式。保留稳定标识，即使文件或工具不同也能找到关联。功能变化时，应追踪到表格末端确认影响。

“具备输入校验功能”不足以复现测试。应结合产品具体定义单位、缺失值、错误格式、通信延迟等挑战条件，这并不表示每件产品都要采用相同测试组合。

列明操作系统、库、商业模块及云依赖，记录实际版本和作用。供应商做过测试，不代表可以省略产品层面影响评估。明确谁跟踪已知问题、停止支持与变更通知，以及按什么标准采取措施。

代码提交历史有帮助，但不等于全部审查与批准记录。应串联变更请求、原因、影响范围、追加测试和部署版本。安全更新需与功能测试一起评估，并与网络安全资料指南保持版本一致。

与关闭工单数相比，剩余问题在什么条件下发生、造成什么影响更重要。记录复现步骤、受影响功能、风险评价、临时措施和修复计划。保留接受理由与批准人，并检查用户信息或培训是否需调整。

报告除合格结论外，还应提供测试环境、工具及版本、原始数据位置和失败后的措施。部分复测后，应说明哪些旧结果仍可使用。通过复测本身，并不能解释先前失败的原因。

核对申请中的版本、截图、风险资料、测试报告，以及安装包或部署基线。服务器和应用独立更新的产品，应确定版本组合和支持条件。发生咨询或故障时，还需能够识别现场版本。

本文追溯表是工作建议，FDA文件是美国提交资料参考，不替代韩国义务。通过软件证据审查咨询共同检查需求清单、测试结果与部署信息，可以在增加文件前找到缺失的关联。

资料核查日期：2026-09-28。文中的表格和准备流程为实务建议，具体产品的法定提交范围及适用标准须另行确认。

Q. 采用IEC 62304后，整机确认是否全部完成？: 不是。IEC公开范围说明不包括医疗器械本身的确认及最终放行，产品层面的性能、可用性等证据仍须衔接。
Q. 软件安全级别等于器械风险等级吗？: 两者不同。应按适用标准评估软件故障对危险情境的贡献，不应直接复制韩国器械等级。
Q. 开源组件也要记录吗？: 应识别并评估产品中影响功能或安全的外部组件，管理版本、用途、已知问题及变更影响，同时确认适用标准要求。