- T40 UI 审计计划和结果文档(docs/qa/) - wiki 更新:miniprogram 设计系统合规审计记录 + index 关键数字更新 - 审计 V2 完整报告(docs/audits/v2/) - 讨论记录文档(docs/discussions/) - 设计规格和实施计划(docs/superpowers/) - 角色测试计划和结果(docs/qa/role-test-*) - Docker 生产部署配置
107 lines
4.8 KiB
Markdown
107 lines
4.8 KiB
Markdown
# 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 设备选型与合作** — 面向老年患者的家庭设备方案
|