hms/docs/discussions/2026-05-04-product-vision-brainstorming.md

HMS 产品愿景与方向发散式讨论

日期: 2026-05-04 | 参与者: 产品负责人 + AI 协作

背景

系统已完成主体功能开发（18 crate / 59 小程序页面 / ~210 API 路由 / 48 health 实体），审计完成度 83%，P0/P1 大部分已修复。在准备交付第一个客户（血液透析中心）之前，进行产品方向和愿景的发散式讨论。

讨论要点

1. 产品定位演进

初始定位（CLAUDE.md）: 面向体检中心/医疗机构的综合健康管理平台

讨论后明确:

• 以自有体检中心为流量入口，体检报告作为健康管理的起点
• 体检后根据客户情况分流到：健康管理（亚健康）、慢病管理、综合医院、专科医院（眼科、牙科、月子中心等）
• 形成完整的健康管理闭环（体检 → 分流 → 管理 → 复查 → 回到体检）
• HMS 作为患者端门户（小程序为主），是患者与医疗机构之间的枢纽

核心定位: HMS 是AI 驱动的主动关怀引擎，不是传统的医疗管理系统。

2. 商业模型

收入来源（已确认）:

• 管理服务订阅费: 患者为长期健康管理服务付费（月费/年费）
• 转介佣金: 向合作专科机构导流，按成交或人次收取佣金
• 自有医疗机构收入: 自有专科机构（如透析中心）的医疗服务收入

商业飞轮:

体检中心（自有，流量入口）
  → 体检报告 + 风险评估
  → HMS 患者端小程序（转化 + 留存）
    ├── 自有专科机构 → 医疗服务收入
    ├── 合作专科机构 → 转介佣金
    └── 患者管理服务订阅 → 订阅收入
  → 定期复查 → 回到体检中心（闭环）

3. 第一个客户：血液透析中心枢纽系统

3.1 核心价值主张

"增进已有以及潜在患者的羁绊，提高他们对血透机构的信任度"

不是让患者自己管自己，而是:

1. 系统被动采集健康数据（BLE + 透析时采集 + 外部系统）
2. AI 持续分析所有患者数据
3. 自动生成"今日关怀清单"给护士
4. 护士根据 AI 建议主动关怀患者
5. 患者感受到"时时刻刻有人在关心我" → 信任

3.2 用户群体

四端全覆盖:

• 老年患者本人（60+）: 极简界面，关怀推送，健康科普
• 患者子女: 监控父母健康数据，异常告警，与医护沟通
• 医护端: 每日关怀工作台，患者管理，数据录入
• 机构管理端: 统计看板，内容管理，运营管理

3.3 数据策略

被动采集为主，不依赖患者手动录入:

• BLE 设备自动采集（血压计、血糖仪、体重秤等）
• 透析时机构采集（体重、血压、超滤量、化验指标等）
• 外部系统对接（HIS/LIS，通过已实现的 FHIR R4 + OAuth）

4. 部署模式

私有化部署产品，卖给不同机构:

• 每个企业客户一套独立部署
• 企业下属多个机构（如 A 企业有 B/C/D 血透中心）
• 系统内多租户隔离（tenant_id），企业一套系统多机构使用
• 与现有架构设计一致

5. 对现有系统的影响

已有能力	需要演进的方向
告警系统（阈值触发）	AI 趋势分析（连续变化识别，不只是阈值）
Action Inbox（工作流收件箱）	每日关怀清单（护士专用工作台）
随访任务（手动创建）	AI 自动生成的关怀建议 + 话术推荐
AI 分析（被动触发 SSE）	AI 每日批处理（主动关怀引擎）
微信订阅消息（业务提醒）	"护士今天关注了您的健康"关怀类通知
BLE 设备适配（3 类）	更丰富的家庭设备生态（体重秤等）
FHIR R4 + OAuth（已实现）	HIS/LIS 数据对接管道

结论 / 待定

达成共识

1. HMS 的灵魂是"AI 驱动的主动关怀引擎" — 护士从"凭经验记忆关心谁"变成"AI 告诉我今天该关心谁"
2. 第一个客户的核心场景是透析中心的信任建设 — 不是功能堆砌，而是让患者感受到被关注
3. 数据采集走被动路线 — BLE + 机构采集 + 外部对接，不依赖老年患者手动录入
4. 私有化部署 + 多租户 — 与现有架构一致，每个企业一套系统
5. 商业飞轮以体检中心为入口 — 自有流量 + 分流转化 + 持续管理

待后续探索

1. AI 关怀引擎的具体分析模型 — 透析患者的关键风险指标和分析逻辑
2. 护士每日关怀工作台的 UX 设计 — 什么信息、怎么展示、怎么操作
3. 体检→管理转化路径设计 — 体检后如何引导患者进入健康管理
4. 定价策略 — 私有化部署的定价模式
5. 竞争格局 — 透析管理领域的主要竞品和差异化策略
6. BLE 设备选型与合作 — 面向老年患者的家庭设备方案