云端处理对器械检测边界的影响

结论：功能在云端，风险却在使用者那一端

越来越多的器械把部分处理放到云端——数据存储、复杂计算、模型推理、多设备协同。这样做有技术和商业上的理由，但它改变了检测的边界。

传统器械的边界是设备本身。 设备交付给使用者之后，它的行为是确定的，不会因为外部因素而改变。

含云端处理的器械不同： 器械的一部分功能不在使用者手上，而且这部分可能在使用者不知情的情况下被更新、被中断、被改变。

关键问题是：云端的变化会影响使用者手上产品的行为，而使用者对此没有控制。 这是检测和风险管理需要专门处理的。

边界的重新界定

本地部分。 使用者手上的设备或应用。

通信链路。 本地与云端之间的连接。

云端部分。 服务端的处理逻辑、数据存储、模型。

云端的基础设施。 服务器、网络、第三方服务。

判断哪些在检测边界内的依据仍然是： 该部分是否影响产品的安全或有效性。

云端处理如果参与了器械的预期用途（比如计算结果、生成报告、做出判断），它就在边界内，不能因为「在服务器上」就排除。

通信环节的考察

通信是本地与云端之间的桥梁，它的可靠性直接影响功能：

「重复与丢失」是实际中容易出问题的地方。 网络中断后重连，可能导致同一份数据被提交两次，或者中断期间的数据丢失。对于监测类产品，数据丢失意味着监测的空白。

云端不可用时的行为

这是含云端处理的产品必须验证的场景：

功能降级还是完全不可用。 云端不可用时，本地还能做什么。

降级时的提示。 使用者是否知道当前处于降级状态。

关键功能的本地保障。 安全相关的功能是否依赖云端。

数据的本地保存。 离线期间的数据能否保存并在恢复后上传。

恢复后的处理。 恢复时的数据同步、状态恢复。

「关键功能不应依赖云端」是设计上的基本原则。 如果报警、停止、安全保护这类功能需要云端响应，那么网络中断就等于失去保护。这类功能应当在本地实现。

「降级时的提示」同样重要。 使用者不知道处于降级状态，可能继续按完整功能的预期使用，风险反而更大。

服务变更的管理

云端服务的更新与本地软件的更新有一个重要差别：云端更新是制造商单方面进行的，使用者手上的产品行为随之改变，而使用者可能完全不知情。

这带来几个管理要求：

变更控制。 云端的变更同样要走变更管理流程。

影响评估。 评估变更对产品安全和有效性的影响。

验证。 变更后的验证，含与各版本本地端的兼容性。

申报义务。 影响安全有效性的变更可能需要申报。

版本兼容。 云端更新后，旧版本的本地端能否继续工作。

通知。 重要变更是否需要通知使用者。

「与各版本本地端的兼容性」是实际的复杂点。 使用者手上的应用版本各不相同，云端更新后要确保各版本都能正常工作，或者明确不再支持某些版本并通知。

数据方面的考察

数据的准确传输。 本地采集的数据准确上传到云端。

处理结果的准确返回。 云端的处理结果准确返回并显示。

数据的存储安全。 云端存储的保护措施。

数据的访问控制。 谁能访问什么数据。

数据的留存与删除。 保存多久、如何删除。

跨境传输。 涉及跨境时的合规要求。

「跨境传输」对面向多个市场的产品是实际问题，不同地区对健康数据的跨境流动有不同的规定，服务架构的设计要考虑这一点。

服务持续性

云端服务的持续性直接关系到产品的可用性：

服务中断的应对。 计划内维护和非计划中断。

服务终止的处理。 如果决定停止某项云服务，使用者手上的产品怎么办。

数据的迁移或导出。 服务终止时使用者的数据如何处理。

通知义务。 提前多久通知使用者。

「服务终止」是需要在产品资料中说明的内容。 使用者购买的产品依赖一个可能被终止的服务，这一点应当在购买前知情，且应当有明确的处理安排。

资料中应当说明的

用户资料中建议包含：需要的网络条件；云端不可用时的功能状态；数据的处理与存储说明；隐私相关的说明；服务的可用性承诺；以及服务变更或终止时的通知方式。

责任的划分

云端服务可能涉及多方，责任划分要清楚：

制造商。 对产品整体的安全有效性负责，包括云端部分。

云服务提供商。 基础设施的可用性和安全性。

第三方服务。 如果调用了第三方的服务或接口。

使用者。 网络环境、设备维护。

关键点是：制造商不能因为使用了第三方的云服务就转移责任。 从器械的角度，产品的安全有效性仍由制造商负责，第三方服务的可靠性是制造商需要管理的供方问题。

建议在与云服务商的协议中明确可用性、安全性、数据处理、以及变更通知方面的要求，并把这些纳入供方管理。

与检测的配合

检测时涉及云端的产品，准备工作包括：提供可用的测试环境（测试账号、测试服务端）；说明云端参与了哪些功能；提供模拟云端异常的方法；以及说明版本对应关系。

「模拟云端异常的方法」对验证很有用 ——能主动制造超时、错误响应、服务不可用，才能验证本地端的处理是否正确。

我们的做法

承接含云端处理产品的委托时，我们会先确认哪些功能依赖云端、哪些在本地，并把「云端不可用时的行为」作为独立的验证内容。 这一项对应的是实际使用中必然会遇到的场景。

验证时我们会实际断开网络连接，观察产品的行为——是否安全停止、是否有明确提示、数据是否保存、恢复后是否正常。 这比查看设计文档中的描述更可靠。

如果你的产品含云端处理，需要理清检测边界和验证范围，可以把系统架构发过来一起讨论，或者直接联系：132 4819 8029。能力范围见服务介绍，流程见检测流程，更多内容见知识库。

English version

Conclusion. More devices now place part of their processing in the cloud: data storage, complex computation, model inference and multi-device coordination. There are technical and commercial reasons for this, and it changes the testing boundary. A conventional device's boundary is the device itself: once delivered, its behaviour is determinate and does not change because of external factors. A device with cloud processing is different, since part of its functionality sits outside the user's hands and may be updated, interrupted or altered without the user knowing. The key point is that changes in the cloud affect the behaviour of the product in the user's hands while the user has no control over them, and testing and risk management must address that specifically.

Redefining the boundary. The local part is the device or application the user holds. The communication link connects local to cloud. The cloud part comprises server-side processing logic, data storage and models. And the cloud infrastructure comprises servers, network and third-party services. The test for inclusion remains whether the part affects the product's safety or effectiveness. Where cloud processing participates in the intended use, by computing results, generating reports or making determinations, it lies within the boundary and cannot be excluded merely because it runs on a server.

Examining communication. Communication bridges local and cloud, and its reliability affects function directly. Connection establishment covers whether connections form reliably. Data integrity covers whether data are corrupted in transit. Transmission security covers encryption and authentication. Timeout handling covers behaviour when responses are slow or absent. Reconnection covers recovery after interruption. Data caching covers handling during offline periods. And duplication and loss cover whether data are submitted twice or lost after recovery. Duplication and loss cause frequent trouble: reconnecting after an interruption may submit the same data twice or lose what was collected during the gap. For monitoring products, lost data means a gap in monitoring.

Behaviour when the cloud is unavailable. This scenario must be verified for any product with cloud processing. Establish whether function degrades or ceases entirely, meaning what the local part can still do. Establish whether degradation is indicated, meaning whether the user knows the current state. Establish whether critical functions are locally assured, meaning whether safety-related functions depend on the cloud. Establish whether data are stored locally during the offline period and uploaded afterwards. And establish recovery behaviour, covering synchronisation and state restoration. Critical functions should not depend on the cloud, which is a basic design principle: where alarms, stopping or safety protection require a cloud response, a network interruption means the protection is gone, and such functions belong locally. Indicating degradation matters equally: a user unaware of degraded operation may continue using the product as though it were fully functional, which increases risk.

Managing service changes. Cloud updates differ from local software updates in an important respect: the manufacturer makes them unilaterally, the behaviour of products in users' hands changes accordingly, and users may not know at all. Several management requirements follow. Change control must cover cloud changes as well. Impact assessment must evaluate the effect on safety and effectiveness. Verification must follow changes, including compatibility with each version of the local part. Notification obligations may apply where safety or effectiveness is affected. Version compatibility must be maintained, with old local versions continuing to work after a cloud update. And important changes may require notifying users. Compatibility with each local version is the practical complication: users run assorted application versions, and after a cloud update each must either continue working or be explicitly deprecated with notification.

Data considerations. Accurate transmission covers locally acquired data reaching the cloud correctly. Accurate return covers processing results being returned and displayed correctly. Storage security covers protection of data held in the cloud. Access control covers who may access what. Retention and deletion cover how long data are kept and how they are removed. And cross-border transfer covers compliance where data cross borders. Cross-border transfer is a real issue for products serving several markets, since regions differ in their rules on health data movement and the service architecture must reflect that.

Service continuity. Continuity of the cloud service bears directly on product usability. Plan for service interruption, both scheduled maintenance and unplanned outage. Plan for service termination, addressing what happens to products in users' hands if a cloud service is discontinued. Plan for data migration or export on termination. And define notification obligations, including how far in advance users are told. Service termination belongs in the product documentation: a user buying a product that depends on a service which may be discontinued should know that before purchase, and clear arrangements should exist.

What the documentation should state. User documentation should cover the network conditions required; the functional state when the cloud is unavailable; how data are processed and stored; privacy matters; service availability commitments; and how service changes or termination will be notified.

How we handle it. For products with cloud processing we establish first which functions depend on the cloud and which are local, and treat behaviour when the cloud is unavailable as a separate verification item, since that scenario will certainly occur in use. In verification we actually disconnect the network and observe what the product does: whether it stops safely, whether it indicates the state clearly, whether data are retained and whether it resumes correctly. That is more reliable than reading a description in a design document.

Send us the system architecture and we will work through the boundary and verification scope. Phone or WeChat: +86 132 4819 8029.