患者真正需要的是什么
很多患者端产品的失败，不是因为功能少，而是因为做成了医院信息系统的查询窗口。
患者打开 App 想解决的是三个问题：
- 「我这个指标是什么意思？」——报告解读
- 「上次和这次比，是变好还是变坏了？」——趋势对比
- 「我爸妈的情况我能不能一起看？」——家庭成员代管
如果只是把 HIS 里的数据原样搬出来，患者看不懂，第二次就不会打开了。
报告解读是核心功能，不是装饰
体检报告和检验单的问题在于：指标名称专业、参考区间单位不一、异常值只标一个箭头。
我们的处理方式是结构化：
- 指标按类别分组（血常规、肝肾功能、血脂等）
- 每项指标显示当前值、参考区间、偏离程度
- 异常项自动高亮并给出分级提示
- 同指标的历史趋势用折线图呈现
关键在于不给出诊断结论。系统只做数据呈现和趋势说明，医学判断留给医生。这既是合规要求，也是产品边界。
设备数据怎么接
智能穿戴设备的接入比想象中麻烦，主要卡在三点：
- 授权链路 —— 各家平台的授权流程不同，需要逐一适配
- 数据口径 —— 同一指标在不同设备上的采样频率和算法不同，直接对比会失真
- 数据连续性 —— 用户摘下手表的那段时间就是空的，趋势图不能当成异常
我们的做法是按指标建立统一的中间模型，原始数据保留，展示层做归一化。这样换设备或者增加设备类型时，不需要重构数据层。
一套代码，两端输出
采用 uni-app 技术栈，App 与 H5 共用业务逻辑和组件，只在小部分能力（如设备蓝牙、本地存储）上做平台分支。
这样做的实际收益：
- 维护成本减半，改一个功能两端同时生效
- H5 版本可以直接用于微信分享和投放，不需要单独开发
- 后续如果要出小程序，迁移成本也低
代价是部分平台特有能力需要额外封装，且性能上限不如原生。对于健康管理这类以数据展示和表单为主的场景，这个取舍是划算的。
合规不能等到最后做
医疗健康类应用涉及的合规事项，在功能开发前就要对齐：
- 隐私政策与服务协议（明确数据采集范围与用途）
- 用户授权与撤回机制
- 账号注销与数据删除（要真删，不是标记删除）
- 敏感信息的传输与存储加密
- 第三方 SDK 的数据流向说明
这些如果等到上线前才补，往往会推翻已有的交互设计。项目里我们的做法是先出合规清单，再定页面流程。
交付情况
本项目已交付上线版本，覆盖 20+ 页面，App 与 H5 双端同步，接入智能穿戴设备 8 项体征指标。