移动医疗应用的检测关注点

结论：运行环境不可控，是移动应用与其他软件的根本差别

运行在专用硬件上的软件，环境是确定的——处理器、内存、系统版本都由制造商决定。移动应用不同：它运行在用户自己的手机上，而手机的型号、系统版本、硬件性能、已安装的其他应用、系统设置，全都不由你控制。

这带来一组特有的问题：

设备差异导致的表现不一致；系统更新可能改变应用的行为；其他应用可能干扰（抢占资源、后台限制）；系统的省电策略可能中断后台任务；以及用户的设置可能关闭必要的权限。

这些问题在专用设备上不存在，但在移动应用上是常态，必须在验证中覆盖。

兼容性验证

设备范围。 声称支持哪些设备或哪个档次的设备。

系统版本范围。 支持的系统版本区间。

屏幕适配。 不同尺寸和分辨率下的显示是否正常、关键信息是否被遮挡。

性能表现。 在较低配置设备上的响应速度。

系统差异。 不同厂商对系统的定制可能改变行为。

建议明确声称支持的范围，并在范围的边界上验证 ——支持的最低系统版本、最低配置设备，这些是实际用户可能遇到的最不利情况。

「不同厂商的系统定制」是实务中问题较多的地方。 同样的系统版本，不同厂商的后台管理策略、通知策略、权限管理可能差别明显，导致应用在某些设备上工作不正常。

后台运行与通知

对于需要持续监测或定时提醒的应用，这一项是关键：

如果应用承担提醒用药、监测数据、报警这类功能，通知送达的可靠性就是安全相关的问题。 通知没收到的后果，可能与设备本身失效相当。

验证时应当覆盖： 在各种省电设置下的表现；应用被清理后能否恢复；通知权限被关闭时是否有提示；以及在免打扰模式下重要通知的处理。

建议在应用中加入权限和设置的检查与引导，在必要权限缺失时明确提示用户，而不是静默地失去功能。

数据与通信

数据准确性。 显示的数值与来源数据是否一致，单位换算是否正确。

数据完整性。 传输和存储过程中数据是否被破坏。

同步机制。 多设备或云端同步时的一致性、冲突处理。

离线处理。 无网络时的行为，数据缓存与后续同步。

通信安全。 传输加密、服务端认证。

本地存储安全。 敏感数据在设备上的保护。

「离线处理」值得专门验证。 网络不稳定是移动场景的常态，应用应当能在离线时继续工作并在恢复后正确同步，而不是数据丢失或重复。

与配套硬件的配合

很多医疗应用配套硬件设备使用，这部分的验证包括：

配对与连接。 连接的建立、断开后的重连。

数据接收的完整性。 传输中断时的处理。

指令下发。 从应用控制硬件时的可靠性和确认机制。

版本匹配。 应用版本与硬件固件版本的兼容关系。

连接中断时的行为。 硬件在失去连接时的安全状态。

「版本匹配」是实务中容易出问题的地方。 应用更新后与旧固件不兼容，或者固件更新后需要新版应用。建议有版本检查和提示机制，而不是让用户自己发现不兼容。

用户界面的考虑

医疗应用的界面不只是美观问题：

关键信息的可读性。 字号、对比度，考虑使用者可能视力不佳。

警示的醒目程度。 异常值、报警信息是否足够醒目。

误操作的防护。 关键操作是否需要确认。

数值输入的校验。 超出合理范围的输入是否被拦截。

单位的明确。 显示的数值带不带单位、单位是否可能被误读。

操作的可撤销性。 误操作后能否纠正。

「数值输入的校验」是数据安全的第一道防线。 用户可能输错小数点、输错单位，应用应当能识别明显不合理的输入并提示。

更新与版本

更新机制。 通过应用商店还是自有渠道。

强制更新。 涉及安全问题时能否强制用户更新。

旧版本的处理。 不再支持的版本如何处理。

版本追踪。 现场用户在用哪些版本。

「强制更新的能力」对安全相关的应用有价值，因为发现严重问题时需要确保用户停止使用旧版本。

权限与隐私

移动应用涉及的权限和数据，需要专门考虑：

权限的必要性。 申请的权限是否都是功能必需的。申请过多权限既有隐私风险也影响用户信任。

权限的说明。 向用户说明为什么需要某项权限。

权限被拒绝时的处理。 功能降级还是无法使用，要有明确处理。

数据的收集范围。 收集哪些数据、用于什么目的。

数据的存储与传输。 本地存储的保护、传输的加密。

数据的删除。 用户要求删除数据时的处理。

「权限被拒绝时的处理」要明确。 用户拒绝了某项权限，应用应当明确告知哪些功能不可用，而不是表现异常让用户困惑。

与说明书的关系

移动应用的使用说明应当包含：支持的设备与系统范围；安装与配置步骤；必要权限及其用途；与硬件的配对方法；常见问题处理；数据的备份与恢复；以及技术支持的联系方式。

「必要权限及其用途」建议写清楚，因为权限设置不当是应用无法正常工作的常见原因。

我们的做法

承接移动应用相关的委托时，我们会先确认声称支持的设备和系统版本范围，并建议在范围边界上做验证 ——最低系统版本、较低配置设备，这些是实际使用中容易出问题的组合。

对于承担提醒或监测功能的应用，我们建议把「后台运行与通知送达」作为独立的验证内容，在各种省电和权限设置下实测 ——这一项在常规的功能测试中通常不覆盖，但它直接关系到功能能否真正实现。

如果你有移动医疗应用需要安排验证，想先理清范围，可以把应用的功能和配套硬件情况发过来一起讨论，或者直接联系：132 4819 8029。能力范围见服务介绍，送检要求见送检要求，其他问题见常见问题。

English version

Conclusion. Software running on dedicated hardware has a determinate environment: processor, memory and system version are all fixed by the manufacturer. A mobile application is different, running on the user's own phone, where model, system version, hardware performance, other installed applications and system settings all lie outside your control. That creates a distinct set of problems: inconsistent behaviour across devices; system updates changing application behaviour; interference from other applications competing for resources or imposing background restrictions; power-saving policies terminating background tasks; and user settings revoking necessary permissions. None of these exists on dedicated hardware while all are normal for mobile applications, and verification must cover them.

Compatibility verification. Define the device range, meaning which devices or which tier is claimed. Define the system version range. Verify screen adaptation across sizes and resolutions, confirming that display is correct and key information is not obscured. Verify performance on lower-specification devices, particularly response time. And consider system variation, since manufacturer customisation can change behaviour. State the supported range explicitly and verify at its boundaries: the lowest supported system version and the lowest specification device are the least favourable combinations real users may encounter. Manufacturer customisation causes considerable trouble in practice: at the same system version, different manufacturers' background management, notification and permission policies can differ markedly, leaving an application malfunctioning on certain devices.

Background operation and notifications. For applications performing continuous monitoring or scheduled reminders, this is critical. System power-saving limits terminate background tasks. Applications cleared by the system interrupt monitoring. Revoked notification permissions prevent reminders arriving. Do-not-disturb mode silences reminders. Notification channel settings can downgrade important notifications. And battery optimisation policies restrict background activity. Where an application handles medication reminders, data monitoring or alarms, the reliability of notification delivery is a safety matter: a notification not received may have consequences comparable to device failure. Verification should cover behaviour under various power-saving settings; recovery after the application is cleared; whether the user is warned when notification permissions are revoked; and how important notifications are handled in do-not-disturb mode. Build permission and settings checks into the application, warning the user explicitly when necessary permissions are missing rather than silently losing function.

Data and communication. Data accuracy covers whether displayed values match source data and whether unit conversion is correct. Data integrity covers whether data are corrupted in transmission or storage. Synchronisation covers consistency and conflict handling across devices or with a cloud service. Offline handling covers behaviour without connectivity, including caching and later synchronisation. Communication security covers encryption in transit and server authentication. And local storage security covers protection of sensitive data on the device. Offline handling deserves specific verification: unstable connectivity is normal in mobile use, and the application should continue working offline and synchronise correctly afterwards rather than losing or duplicating data.

Working with companion hardware. Many medical applications accompany a hardware device, and verification covers pairing and connection, including establishment and reconnection after loss. Completeness of received data, including handling of interrupted transmission. Command transmission, covering reliability and confirmation when the application controls the hardware. Version matching between application and device firmware. And behaviour on loss of connection, including the hardware's safe state. Version matching causes frequent trouble: an updated application may be incompatible with old firmware, or updated firmware may require a new application. Provide version checking and clear messaging rather than leaving users to discover incompatibility.

User interface considerations. A medical application's interface is not merely a matter of appearance. Key information must be legible in type size and contrast, allowing for users with poor eyesight. Warnings must be sufficiently prominent for abnormal values and alarms. Erroneous operation must be guarded against, with confirmation for critical actions. Numeric input must be validated, intercepting values outside reasonable ranges. Units must be explicit, with displayed values carrying units that cannot be misread. And operations should be reversible where possible. Input validation is the first line of data safety: users may misplace a decimal point or mistake a unit, and the application should recognise clearly unreasonable input and say so.

Updates and versions. Consider the update mechanism, whether through an application store or your own channel. Consider forced updates, meaning whether users can be compelled to update when a security issue arises. Consider handling of unsupported old versions. And consider version tracking of what users are running. The ability to force updates has value for safety-related applications, since a serious problem requires ensuring that users stop running the old version.

How we handle it. For mobile application work we confirm the claimed device and system version range and suggest verifying at its boundaries: the lowest system version and lower-specification devices, the combinations where problems arise in real use. For applications performing reminders or monitoring we suggest treating background operation and notification delivery as a separate verification item, measured under various power-saving and permission settings; routine functional testing does not cover it, while it determines directly whether the function can be delivered at all.

Send us the application's functions and companion hardware details and we will work through the scope. Phone or WeChat: +86 132 4819 8029.