医疗器械软件的检测边界在哪

结论：先确定软件在产品中的角色，边界就清楚了

「医疗器械软件要测什么」这个问题，答案取决于软件在产品中扮演什么角色。角色不同，边界完全不同。

嵌入在硬件设备中的软件。 它是设备的一部分，检测随设备一起进行，边界是设备的边界。

独立的软件产品。 它本身就是器械，边界是软件本身加上它声称支持的运行环境。

配套的辅助软件。 比如手机应用、配置工具，要判断它是否影响产品的安全或有效性——影响的要纳入，不影响的可以说明后排除。

边界划不清的后果是两头都可能出问题： 漏掉了影响安全的部分，或者把不相关的部分也纳入测试而增加成本。

边界判断的依据

软件的功能是否影响安全或有效性。 这是核心判据。

软件是否参与器械的预期用途。 实现诊断、治疗、监测功能的软件必然在边界内。

软件失效的后果。 后果严重的必须纳入。

软件与硬件的耦合程度。 紧密耦合的通常一起考虑。

软件的更新方式。 独立更新的软件，边界的划定影响后续变更管理。

建议把判断写下来。 哪些软件组件在边界内、哪些在外、理由是什么。这份说明在送检和审查时都要用到。

各类软件的处理

「第三方组件」是容易被忽略的部分。 产品中使用的操作系统、库、框架都是第三方组件，它们的版本、已知漏洞、维护状态都影响产品的安全性。边界划定时要把它们纳入考虑，而不是当成「不是我们写的代码」就不管。

运行环境的界定

独立软件产品的一个特殊问题是：它运行在什么环境上？

硬件要求。 处理器、内存、存储、显示的最低要求。

操作系统。 支持的系统及版本范围。

依赖的其他软件。 运行库、数据库、浏览器。

网络要求。 带宽、延迟、是否需要联网。

外设。 打印机、读卡器等。

运行环境的声称要与验证对应。 声称支持某个系统版本，就应当在该版本上验证过；声称的硬件最低配置，应当在该配置下验证过性能。

「最低配置下的性能」常被忽略。 开发和测试都在高配机器上做，而实际用户可能用最低配置，性能表现完全不同。建议在声称的最低配置上做一遍验证。

检测的内容

软件相关的检测通常包括：

功能测试。 各项功能是否按设计实现。

性能测试。 响应时间、处理能力、并发。

接口测试。 与硬件、与其他软件的接口。

异常处理。 输入异常、资源不足、通信中断时的表现。

数据完整性。 数据的存储、传输、显示是否准确。

用户界面。 显示的正确性、操作的合理性、警示的有效性。

兼容性。 在声称支持的环境上的表现。

网络安全。 相关的安全措施与验证。

「异常处理」是实际中问题较多的部分。 正常路径的功能通常做得没问题，出问题的是异常路径——输入了超出范围的数值、存储空间满了、网络断了、用户做了非预期的操作。这些场景应当在测试中覆盖。

与硬件测试的关系

对于含软件的硬件设备，软件与硬件的测试要协调：

功能测试需要软硬件配合。 单独测软件或单独测硬件都不完整。

EMC 测试中软件是被测对象的一部分。 软件版本变化可能影响 EMC 表现。

单一故障测试涉及软件保护。 软件实现的保护功能要在故障状态下验证。

安全相关功能的验证。 软件参与的安全功能要实测。

建议在测试计划中明确软件版本，并在报告中记录。软件版本不明确的测试报告，在变更评估时无法作为基线。

送检准备

提供软件版本信息。 版本号、构建日期、变更记录。

提供功能说明。 各项功能及其实现方式。

提供架构说明。 软件的组成、模块划分、第三方组件清单。

提供运行环境要求。 独立软件产品适用。

提供操作方法。 测试人员需要能操作软件。

提供监测手段。 如何观察软件的内部状态。

提供测试账号或数据。 需要登录或特定数据才能运行的软件。

「监测手段」准备不足会影响测试效率。 实验室需要判断软件是否正常工作，如果只能从界面观察，某些内部异常可能被漏掉。

软件版本的管理

测试报告与软件版本是绑定的，版本管理不清楚会带来后续麻烦：

版本标识不能重复。 每个可发布的版本有明确的版本号。

版本要可追溯。 版本号对应到具体的代码状态。

报告中记录版本。 测试时用的是哪个版本。

变更记录要保留。 版本之间改了什么。

发布控制。 哪些版本是发布版本、哪些是内部版本。

「报告中没写软件版本」是实务中的常见问题。 将来软件更新后要判断是否需要重测，没有基线版本就无从比较。

与风险管理的衔接

软件相关的内容应当在风险文件中有对应：

软件失效的危害识别。 哪些软件功能失效会造成危害。

风险控制措施。 软件内的和软件外的。

验证的对应。 每项控制措施对应的验证活动。

剩余风险。 控制后仍存在的风险。

建议软件的验证计划直接引用风险文件中的控制措施清单，这样两边的一致性有保障，审查时也容易说明。

我们的做法

承接含软件产品的委托时，我们会先与委托方确认软件的边界——哪些组件在测试范围内、哪些不在、理由是什么。 这一点明确之后，测试项目才能定下来。

对于独立软件产品，我们会确认声称的运行环境范围，并建议在声称的最低配置上做一遍验证，因为这是实际用户可能遇到的最不利情况。

如果你有含软件的产品需要安排检测，想先理清范围，可以把软件架构和功能说明发过来一起讨论，或者直接联系：132 4819 8029。能力范围见服务介绍，送检要求见送检要求，流程见检测流程。

English version

Conclusion. What must be tested in medical device software depends on the role the software plays in the product, and different roles give entirely different boundaries. Software embedded in hardware forms part of the device, is tested with it, and takes the device's boundary. A standalone software product is itself the device, with a boundary of the software plus the operating environment it claims to support. Accompanying auxiliary software such as phone applications and configuration tools requires a judgement on whether it affects safety or effectiveness: where it does, it comes within the boundary, and where it does not, it can be excluded with an explanation. An unclear boundary causes trouble both ways: parts affecting safety are missed, or unrelated parts are tested at unnecessary cost.

Basis for the boundary. Whether the software's function affects safety or effectiveness is the central criterion. Whether the software participates in the intended use matters, since software performing diagnosis, treatment or monitoring necessarily falls inside. The consequence of software failure matters, since serious consequences require inclusion. The degree of coupling with hardware matters, since tightly coupled software is usually considered together. And the update mechanism matters, since for independently updated software the boundary affects later change management. Write the judgement down: which components fall inside, which outside and why. That statement is needed both at submission and during review.

Handling each type. Embedded firmware travels with the device and focuses on function, safety, single fault behaviour and electromagnetic compatibility. A standalone software product covers software plus operating environment and focuses on function, performance, compatibility and cybersecurity. An accompanying mobile application depends on its function and focuses on data integrity, communication and display. Configuration and maintenance tools depend on their effect and focus on correctness of parameter setting and protection against error. And third-party components need separate description covering provenance, version and known issues. Third-party components are the part most often overlooked: operating systems, libraries and frameworks used in the product are all third-party, and their versions, known vulnerabilities and maintenance status all affect product safety. Bring them within the boundary rather than disregarding them as code someone else wrote.

Defining the operating environment. For standalone software a particular question arises: what does it run on? Hardware requirements cover minimum processor, memory, storage and display. Operating systems cover which systems and version ranges are supported. Software dependencies cover runtimes, databases and browsers. Network requirements cover bandwidth, latency and whether connectivity is needed. And peripherals cover printers, card readers and similar. Environmental claims must correspond to verification: claiming support for a system version means having verified on it, and claiming a minimum hardware configuration means having verified performance on that configuration. Performance at minimum configuration is commonly overlooked, since development and testing happen on well-specified machines while real users may run the minimum, where behaviour differs entirely. Verify once on the claimed minimum.

What is tested. Functional testing confirms that each function works as designed. Performance testing covers response time, throughput and concurrency. Interface testing covers interfaces to hardware and to other software. Exception handling covers behaviour under invalid input, resource exhaustion and communication loss. Data integrity covers accuracy in storage, transmission and display. User interface covers correctness of display, reasonableness of operation and effectiveness of warnings. Compatibility covers behaviour in the claimed environments. And cybersecurity covers the relevant measures and their verification. Exception handling is where problems concentrate in practice: functions on the normal path usually work, while trouble appears on exception paths where values out of range are entered, storage fills, the network drops or users do something unexpected. Cover those scenarios in testing.

Relationship to hardware testing. For hardware containing software, the two must be coordinated. Functional testing needs both together, since testing either alone is incomplete. Electromagnetic compatibility testing treats software as part of the item under test, and a software version change may alter behaviour. Single fault testing involves software protection, since protective functions implemented in software must be verified under fault. And safety-related functions in which software participates must be measured. State the software version in the test plan and record it in the report; a report without a clear software version cannot serve as a baseline for change assessment.

Preparing for submission. Provide software version information covering version number, build date and change records. Provide a functional description covering each function and how it is implemented. Provide an architecture description covering composition, module structure and a third-party component list. Provide operating environment requirements for standalone products. Provide operating instructions, since testers must be able to drive the software. Provide monitoring means for observing internal state. And provide test accounts or data where the software requires login or particular data to run. Inadequate monitoring provision reduces test efficiency: the laboratory must judge whether the software is working correctly, and where only the interface can be observed, internal abnormalities may be missed.

How we handle it. For products containing software we agree the boundary with the client first, covering which components fall within the test scope, which do not and why. Only then can test items be fixed. For standalone software products we confirm the claimed operating environment range and suggest verifying on the claimed minimum configuration, since that is the least favourable case real users may encounter.

Send us the software architecture and functional description and we will work through the scope. Phone or WeChat: +86 132 4819 8029.