194 lines
8.6 KiB
Markdown
194 lines
8.6 KiB
Markdown
# HMS 健康管理平台 — 后续演化路线图
|
||
|
||
> 版本: v1.0 | 日期: 2026-04-29 | 面向: 客户产品规划
|
||
|
||
---
|
||
|
||
## 1. 当前状态 — 已交付能力
|
||
|
||
### 1.1 交付总览
|
||
|
||
| 指标 | 数据 |
|
||
|------|------|
|
||
| 后端模块 | 9 个 Rust crate（5 基础 + 3 业务 + 1 组装） |
|
||
| 业务实体 | 47 个（44 健康 + 3 AI） |
|
||
| 数据库迁移 | 76 个，全部可回滚 |
|
||
| 管理后台 | 29 个页面（25+ 健康路由 + 4 系统） |
|
||
| 患者端小程序 | 31 个页面，5 个 TabBar |
|
||
| 医护端小程序 | 9 个页面 |
|
||
| 后端测试 | 225 单元 + 159 集成 |
|
||
| API 文档 | OpenAPI 自动生成，Swagger UI 可交互 |
|
||
|
||
### 1.2 已实现的核心能力
|
||
|
||
| 能力域 | 状态 | 说明 |
|
||
|--------|------|------|
|
||
| 患者管理（建档/标签/家属/医患关系） | ✅ 已完成 | 含 PII 加密和脱敏 |
|
||
| 健康数据（体征/化验/日常监测/设备同步） | ✅ 已完成 | 趋势图、小时聚合 |
|
||
| 预约排班（透析预约/医生排班） | ✅ 已完成 | 原子 CAS 并发控制 |
|
||
| 随访管理（任务/记录/模板） | ✅ 已完成 | 可自定义字段模板 |
|
||
| 咨询管理（会话/消息） | ✅ 已完成 | 图文/语音消息 |
|
||
| 告警系统（规则/危急值） | ✅ 已完成 | 阈值可配置，分级告警 |
|
||
| 内容管理（文章/分类/标签/公告） | ✅ 已完成 | 富文本编辑，审核流程 |
|
||
| 积分商城（账户/规则/商品/订单） | ✅ 已完成 | 积分兑换，签到 |
|
||
| AI 分析（化验解读/趋势/报告） | 🔄 Phase 1 MVP | SSE 流式输出 |
|
||
| 透析管理（透析记录/透析处方） | 🔄 基础完成 | 已独立拆分为 erp-dialysis |
|
||
| 微信小程序（患者端 + 医护端） | ✅ 已完成 | 微信登录，蓝牙设备同步 |
|
||
|
||
---
|
||
|
||
## 2. Phase 1：加固期（2-3 周）— 上线前必修
|
||
|
||
> **目标：** 补齐临床安全和合规短板，确保系统具备上线条件。
|
||
|
||
### 2.1 危急值告警闭环
|
||
|
||
| 项目 | 说明 | 工期 |
|
||
|------|------|------|
|
||
| 危急值阈值可配置化 | 硬编码阈值改为数据库配置，支持按科室/年龄段差异化设置 | 2 天 |
|
||
| 告警通知闭环 | 异常体征 → 自动通知责任医护 → 医护确认处理 → 超时升级 | 1 天 |
|
||
| 日常监测告警验证 | 确保所有体征数据（含设备上报）都经过告警检测 | 1 天 |
|
||
|
||
**为什么是 P0：** 危急体征值无人响应可能导致患者安全事故，这是医疗系统的底线。
|
||
|
||
### 2.2 合规补全
|
||
|
||
| 项目 | 说明 | 工期 |
|
||
|------|------|------|
|
||
| 知情同意记录 | 患者数据处理前获取明确同意，记录同意版本和时间，支持撤回 | 3 天 |
|
||
| 审计日志补全 | 临床数据变更记录前后值，读操作（查看患者详情/化验报告）纳入审计 | 3 天 |
|
||
| 隐私政策 & 用户协议 | 小程序端展示可阅读的隐私政策和用户协议 | 1 天 |
|
||
|
||
**法规依据：** PIPL（个人信息保护法）第 29 条要求处理敏感个人信息须取得单独同意。医疗数据属于敏感个人信息。
|
||
|
||
### 2.3 事件可靠性
|
||
|
||
| 项目 | 说明 | 工期 |
|
||
|------|------|------|
|
||
| 事件重放机制 | 服务重启后从 Outbox 恢复未处理事件，不丢失 | 2 天 |
|
||
| 随访逾期通知 | 逾期未完成随访自动催办 + 幂等保护（不重复通知） | 1 天 |
|
||
|
||
---
|
||
|
||
## 3. Phase 2：治理期（2-4 周）— 架构治理与质量提升
|
||
|
||
> **目标：** 提升代码质量和系统稳定性，为规模化运营打基础。
|
||
|
||
### 3.1 架构治理
|
||
|
||
| 项目 | 说明 | 工期 |
|
||
|------|------|------|
|
||
| 积分系统独立拆分 | 从 erp-health 拆分为独立 crate，降低健康模块复杂度和合规风险 | 5 天 |
|
||
| 事件订阅优化 | 消息模块改用过滤订阅，减少无效事件传递 | 1 天 |
|
||
| 统一事件消费模式 | 消除双路径问题，所有事件消费走统一入口 | 2 天 |
|
||
|
||
### 3.2 质量提升
|
||
|
||
| 项目 | 说明 | 工期 |
|
||
|------|------|------|
|
||
| 关键路径测试补全 | 多租户隔离验证、患者安全路径、预约并发测试（50-80 用例） | 4 天 |
|
||
| 过敏史变更追溯 | 更新过敏史时保留历史记录，支持变更回溯 | 1 天 |
|
||
| PII 加密范围扩展 | 从仅身份证/手机号扩展到姓名、过敏史、诊断、咨询内容 | 3 天 |
|
||
|
||
### 3.3 前端工程化
|
||
|
||
| 项目 | 说明 | 工期 |
|
||
|------|------|------|
|
||
| 前端测试覆盖 | 管理后台核心页面单元测试 + E2E 测试 | 3 天 |
|
||
| 前端性能优化 | 大列表虚拟滚动、图表懒加载、路由代码分割 | 2 天 |
|
||
| 小程序体验优化 | 页面加载性能、离线缓存、弱网降级 | 2 天 |
|
||
|
||
---
|
||
|
||
## 4. Phase 3：深化期（4-6 周）— 专科能力与智能增强
|
||
|
||
> **目标：** 从通用健康管理深化为肾病/血透专科能力，增强 AI 智能分析。
|
||
|
||
### 4.1 血透专科能力
|
||
|
||
| 项目 | 说明 | 前置条件 |
|
||
|------|------|---------|
|
||
| 透析方案管理 | 透析处方模板、透析器选择、抗凝方案 | 客户需求确认 |
|
||
| 透析并发症追踪 | 低血压、失衡综合征等并发症记录与分析 | 透析方案完成 |
|
||
| 干体重管理 | 干体重目标设定、变化趋势、达标提醒 | 客户需求确认 |
|
||
| 透析充分性评估 | Kt/V 计算、URR 统计、达标率报表 | 客户需求确认 |
|
||
| 通路管理 | 血管通路类型、建立时间、使用评估 | 客户需求确认 |
|
||
|
||
> **建议：** 在开发前先与 3-5 家目标客户做需求调研，确认优先级后再投入开发。
|
||
|
||
### 4.2 AI 智能增强
|
||
|
||
| 项目 | 说明 | 预期效果 |
|
||
|------|------|---------|
|
||
| OCR 化验单识别 | 拍照自动提取化验指标，减少手动录入 | 上报效率提升 80% |
|
||
| 个性化健康建议 | 基于患者历史数据生成饮食/用药/运动建议 | 患者依从性提升 |
|
||
| 风险预测模型 | 基于体征趋势预测潜在风险，提前预警 | 从被动响应到主动预防 |
|
||
| 智能随访计划 | 根据患者病情自动生成随访频率和内容 | 医护工作量降低 |
|
||
|
||
### 4.3 用户体验升级
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| 医护端工作流优化 | 智能分诊、快捷回复模板、语音转文字 |
|
||
| 数据可视化增强 | 可交互的图表、自定义时间范围、PDF 报告导出 |
|
||
| 消息推送精细化 | 按患者画像定制推送内容和频率，避免打扰 |
|
||
|
||
---
|
||
|
||
## 5. Phase 4：扩展期（按需）— 规模化与生态建设
|
||
|
||
> **目标：** 支撑更多医疗机构接入，建立开放生态。
|
||
|
||
### 5.1 规模化运营
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| 多机构管理后台 | 集团/连锁机构统一管理视图，跨机构数据汇总 |
|
||
| 数据分析平台 | 患者群体分析、治疗效果对比、运营效率仪表盘 |
|
||
| 数据导入工具 | 历史患者数据批量导入，支持 Excel/CSV |
|
||
| 数据备份与恢复 | 自动化备份策略、一键恢复、灾难恢复演练 |
|
||
|
||
### 5.2 开放生态
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| HIS/EMR 集成 | 与医院信息系统对接，患者数据双向同步 |
|
||
| 设备厂商接入 | 标准化蓝牙/HTTP 协议，更多品牌设备即插即用 |
|
||
| 第三方服务集成 | 电子发票、物流跟踪、在线支付 |
|
||
| 开放 API | 合作伙伴可通过 API 接入平台能力 |
|
||
|
||
### 5.3 移动端扩展
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| 医生端独立 App | 更强大的移动工作台，离线支持 |
|
||
| 患者端 APP（可选） | 不依赖微信的独立应用，覆盖更多用户群 |
|
||
| 家属端 | 关注患者健康状况，接收告警通知 |
|
||
|
||
---
|
||
|
||
## 6. 版本里程碑总览
|
||
|
||
```
|
||
当前 ───────→ Phase 1 ───────→ Phase 2 ───────→ Phase 3 ───────→ Phase 4
|
||
v0.9 加固期 治理期 深化期 扩展期
|
||
MVP 2-3 周 2-4 周 4-6 周 按需
|
||
│ │ │ │ │
|
||
│ ├── 危急值闭环 ├── 积分拆分 ├── 血透专科 ├── 多机构管理
|
||
│ ├── 合规补全 ├── 测试补全 ├── AI 增强 ├── HIS 集成
|
||
│ └── 事件可靠性 ├── PII 扩展 └── 体验升级 └── 开放 API
|
||
│ │ │ │
|
||
▼ ▼ ▼ ▼ ▼
|
||
内测 安全达标 质量达标 功能达标 规模达标
|
||
可上线试运行 可正式运营 可专科化运营 可多机构运营
|
||
```
|
||
|
||
**关键决策点：**
|
||
- Phase 1 完成后 → 决定是否启动试运行
|
||
- Phase 2 完成后 → 决定是否正式上线
|
||
- Phase 3 启动前 → 需完成目标客户需求调研
|
||
- Phase 4 按业务增长节奏按需启动
|
||
|
||
|
||
|