From 17114d492ea35db8951d06705e1394fd27932fbb Mon Sep 17 00:00:00 2001 From: iven Date: Wed, 20 May 2026 12:25:28 +0800 Subject: [PATCH] =?UTF-8?q?feat(health):=20=E4=B8=9A=E5=8A=A1=E9=93=BE?= =?UTF-8?q?=E8=B7=AF=E6=89=93=E9=80=9A=20=E2=80=94=20=E5=91=8A=E8=AD=A6?= =?UTF-8?q?=E8=87=AA=E5=8A=A8=E9=9A=8F=E8=AE=BF=20+=20=E5=81=A5=E5=BA=B7?= =?UTF-8?q?=E6=95=B0=E6=8D=AE=E7=A7=AF=E5=88=86=E6=BF=80=E5=8A=B1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 迁移 000157: follow_up_task 新增 source_type/source_id 字段追踪任务来源 - 迁移 000157: points_rule 新增 health_data_report/lab_report_upload/streak_7_days 种子规则 - P0-2: follow_up 事件处理器新增 health_data.critical_alert 消费，告警触发时自动创建随访任务 - 自动查找管床医生分配，critical 级别 1 天内、warning 级别 3 天内 - 新增 alert_auto 随访类型，source_type 标记来源为 critical_alert - P1-1: points 事件处理器新增 daily_monitoring.created 消费，日常监测上报自动获取积分 - P1-1: points 事件处理器新增 lab_report.uploaded 消费，化验报告上传自动获取积分 - 更新 HMS 系统设计思路文档 v2.0（实体数/链路图/业务链路章节全面更新） - 新增业务链路打通讨论记录 Co-Authored-By: Claude Opus 4.7 --- crates/erp-health/src/dto/follow_up_dto.rs | 8 + .../erp-health/src/entity/follow_up_task.rs | 4 + crates/erp-health/src/event/follow_up.rs | 132 ++++++++ crates/erp-health/src/event/points.rs | 143 ++++++++ .../src/service/follow_up_service.rs | 14 + crates/erp-health/src/service/validation.rs | 1 + crates/erp-server/migration/src/lib.rs | 2 + ...00157_follow_up_source_and_points_rules.rs | 104 ++++++ .../integration/health_follow_up_tests.rs | 2 + .../health_pii_encryption_tests.rs | 2 + .../2026-05-20-business-chain-optimization.md | 71 ++++ docs/健康管理/HMS系统设计思路.md | 319 ++++++++++++++---- 12 files changed, 744 insertions(+), 58 deletions(-) create mode 100644 crates/erp-server/migration/src/m20260520_000157_follow_up_source_and_points_rules.rs create mode 100644 docs/discussions/2026-05-20-business-chain-optimization.md diff --git a/crates/erp-health/src/dto/follow_up_dto.rs b/crates/erp-health/src/dto/follow_up_dto.rs index bbc3173..ef35dc8 100644 --- a/crates/erp-health/src/dto/follow_up_dto.rs +++ b/crates/erp-health/src/dto/follow_up_dto.rs @@ -21,6 +21,10 @@ pub struct CreateFollowUpTaskReq { pub planned_date: NaiveDate, pub content_template: Option, pub related_appointment_id: Option, + #[serde(default)] + pub source_type: Option, + #[serde(default)] + pub source_id: Option, } impl CreateFollowUpTaskReq { @@ -57,6 +61,10 @@ pub struct FollowUpTaskResp { pub status: String, pub content_template: Option, pub related_appointment_id: Option, + #[serde(skip_serializing_if = "Option::is_none")] + pub source_type: Option, + #[serde(skip_serializing_if = "Option::is_none")] + pub source_id: Option, pub created_at: chrono::DateTime, pub updated_at: chrono::DateTime, pub version: i32, diff --git a/crates/erp-health/src/entity/follow_up_task.rs b/crates/erp-health/src/entity/follow_up_task.rs index 6504a2d..5698726 100644 --- a/crates/erp-health/src/entity/follow_up_task.rs +++ b/crates/erp-health/src/entity/follow_up_task.rs @@ -17,6 +17,10 @@ pub struct Model { pub content_template: Option, #[sea_orm(skip_serializing_if = "Option::is_none")] pub related_appointment_id: Option, + #[sea_orm(skip_serializing_if = "Option::is_none")] + pub source_type: Option, + #[sea_orm(skip_serializing_if = "Option::is_none")] + pub source_id: Option, pub created_at: DateTimeUtc, pub updated_at: DateTimeUtc, #[sea_orm(skip_serializing_if = "Option::is_none")] diff --git a/crates/erp-health/src/event/follow_up.rs b/crates/erp-health/src/event/follow_up.rs index 6657ccb..be316d5 100644 --- a/crates/erp-health/src/event/follow_up.rs +++ b/crates/erp-health/src/event/follow_up.rs @@ -1,4 +1,7 @@ /// follow_up.overdue → 升级通知 + follow_up.created → 通知执行人 +/// health_data.critical_alert → 自动创建告警随访任务 +use sea_orm::{ColumnTrait, EntityTrait, QueryFilter}; + pub fn spawn(state: &crate::state::HealthState) -> Vec { let mut handles = Vec::new(); @@ -139,5 +142,134 @@ pub fn spawn(state: &crate::state::HealthState) -> Vec { + if erp_core::events::is_event_processed( + &critical_state.db, + event.id, + "critical_alert_followup_creator", + ) + .await + .unwrap_or(false) + { + continue; + } + + let patient_id = event + .payload + .get("patient_id") + .and_then(|v| v.as_str()) + .and_then(|s| uuid::Uuid::parse_str(s).ok()); + + let Some(pid) = patient_id else { + let _ = erp_core::events::mark_event_processed( + &critical_state.db, + event.id, + "critical_alert_followup_creator", + ) + .await; + continue; + }; + + let tenant_id = event.tenant_id; + let alert_obj = event.payload.get("alert"); + let metric_name = alert_obj + .and_then(|a| a.get("indicator")) + .and_then(|v| v.as_str()) + .unwrap_or("unknown"); + let metric_value = alert_obj + .and_then(|a| a.get("value")) + .and_then(|v| v.as_f64()) + .map(|v| v.to_string()) + .unwrap_or_default(); + let severity = alert_obj + .and_then(|a| a.get("level")) + .and_then(|v| v.as_str()) + .unwrap_or("critical"); + + // 查找管床医生 + let assigned_doctor: Option = + crate::entity::patient_doctor_relation::Entity::find() + .filter( + crate::entity::patient_doctor_relation::Column::PatientId.eq(pid), + ) + .filter( + crate::entity::patient_doctor_relation::Column::TenantId + .eq(tenant_id), + ) + .filter( + crate::entity::patient_doctor_relation::Column::DeletedAt.is_null(), + ) + .one(&critical_state.db) + .await + .ok() + .flatten() + .map(|r| r.doctor_id); + + let planned_date = chrono::Local::now().date_naive() + + chrono::Duration::days(if severity == "critical" { 1 } else { 3 }); + + let content = format!( + "系统自动创建：患者健康数据异常告警（{}: {}，严重程度: {}）", + metric_name, metric_value, severity + ); + + let req = crate::dto::follow_up_dto::CreateFollowUpTaskReq { + patient_id: pid, + assigned_to: assigned_doctor, + follow_up_type: "alert_auto".to_string(), + planned_date, + content_template: Some(content), + related_appointment_id: None, + source_type: Some("critical_alert".to_string()), + source_id: Some(event.id), + }; + + match crate::service::follow_up_service::create_task( + &critical_state, + tenant_id, + None, + req, + ) + .await + { + Ok(task) => { + tracing::info!( + patient_id = %pid, + task_id = %task.id, + metric = %metric_name, + "告警自动随访任务已创建" + ); + } + Err(e) => { + tracing::warn!( + patient_id = %pid, + error = %e, + "告警自动随访任务创建失败" + ); + } + } + + let _ = erp_core::events::mark_event_processed( + &critical_state.db, + event.id, + "critical_alert_followup_creator", + ) + .await; + } + Some(_) => {} + None => break, + } + } + }); + handles } diff --git a/crates/erp-health/src/event/points.rs b/crates/erp-health/src/event/points.rs index 87d1487..20f3134 100644 --- a/crates/erp-health/src/event/points.rs +++ b/crates/erp-health/src/event/points.rs @@ -1,4 +1,6 @@ /// points.earned/exchanged/expired → 积分变动通知 +/// daily_monitoring.created → 健康数据上报积分 +/// lab_report.uploaded → 化验报告上传积分 pub fn spawn(state: &crate::state::HealthState) -> Vec { let mut handles = Vec::new(); @@ -120,5 +122,146 @@ pub fn spawn(state: &crate::state::HealthState) -> Vec { + if erp_core::events::is_event_processed( + &dm_state.db, + event.id, + "daily_monitoring_points", + ) + .await + .unwrap_or(false) + { + continue; + } + + let patient_id = event + .payload + .get("patient_id") + .and_then(|v| v.as_str()) + .and_then(|s| uuid::Uuid::parse_str(s).ok()); + + if let Some(pid) = patient_id { + match crate::service::points_service::earn_points( + &dm_state, + event.tenant_id, + pid, + "health_data_report", + None, + ) + .await + { + Ok(tx) => { + tracing::info!( + patient_id = %pid, + points = tx.amount, + "健康数据上报积分已发放" + ); + } + Err(e) => { + // 无匹配规则时不告警（租户可能未配置该规则） + let err_str = e.to_string(); + if !err_str.contains("无匹配的积分规则") { + tracing::warn!( + patient_id = %pid, + error = %e, + "健康数据上报积分发放失败" + ); + } + } + } + } + + let _ = erp_core::events::mark_event_processed( + &dm_state.db, + event.id, + "daily_monitoring_points", + ) + .await; + } + Some(_) => {} + None => break, + } + } + }); + + // lab_report.uploaded → 化验报告上传积分 + let (mut lr_rx, lr_handle) = state + .event_bus + .subscribe_filtered("lab_report.".to_string()); + handles.push(lr_handle); + let lr_state = state.clone(); + tokio::spawn(async move { + loop { + match lr_rx.recv().await { + Some(event) if event.event_type == super::LAB_REPORT_UPLOADED => { + if erp_core::events::is_event_processed( + &lr_state.db, + event.id, + "lab_report_points", + ) + .await + .unwrap_or(false) + { + continue; + } + + let patient_id = event + .payload + .get("patient_id") + .and_then(|v| v.as_str()) + .and_then(|s| uuid::Uuid::parse_str(s).ok()); + + if let Some(pid) = patient_id { + match crate::service::points_service::earn_points( + &lr_state, + event.tenant_id, + pid, + "lab_report_upload", + None, + ) + .await + { + Ok(tx) => { + tracing::info!( + patient_id = %pid, + points = tx.amount, + "化验报告上传积分已发放" + ); + } + Err(e) => { + let err_str = e.to_string(); + if !err_str.contains("无匹配的积分规则") { + tracing::warn!( + patient_id = %pid, + error = %e, + "化验报告上传积分发放失败" + ); + } + } + } + } + + let _ = erp_core::events::mark_event_processed( + &lr_state.db, + event.id, + "lab_report_points", + ) + .await; + } + Some(_) => {} + None => break, + } + } + }); + handles } diff --git a/crates/erp-health/src/service/follow_up_service.rs b/crates/erp-health/src/service/follow_up_service.rs index 3e00007..a204f4b 100644 --- a/crates/erp-health/src/service/follow_up_service.rs +++ b/crates/erp-health/src/service/follow_up_service.rs @@ -129,6 +129,8 @@ pub async fn list_tasks( status: m.status, content_template: m.content_template, related_appointment_id: m.related_appointment_id, + source_type: m.source_type, + source_id: m.source_id, created_at: m.created_at, updated_at: m.updated_at, version: m.version, @@ -169,6 +171,8 @@ pub async fn get_task( status: m.status, content_template: m.content_template, related_appointment_id: m.related_appointment_id, + source_type: m.source_type, + source_id: m.source_id, created_at: m.created_at, updated_at: m.updated_at, version: m.version, @@ -205,6 +209,8 @@ pub async fn create_task( status: Set("pending".to_string()), content_template: Set(req.content_template), related_appointment_id: Set(req.related_appointment_id), + source_type: Set(req.source_type), + source_id: Set(req.source_id), created_at: Set(now), updated_at: Set(now), created_by: Set(operator_id), @@ -249,6 +255,8 @@ pub async fn create_task( status: m.status, content_template: m.content_template, related_appointment_id: m.related_appointment_id, + source_type: m.source_type, + source_id: m.source_id, created_at: m.created_at, updated_at: m.updated_at, version: m.version, @@ -346,6 +354,8 @@ pub async fn update_task( status: m.status, content_template: m.content_template, related_appointment_id: m.related_appointment_id, + source_type: m.source_type, + source_id: m.source_id, created_at: m.created_at, updated_at: m.updated_at, version: m.version, @@ -444,6 +454,8 @@ pub async fn batch_create_tasks( status: Set("pending".to_string()), content_template: Set(req.content_template.clone()), related_appointment_id: Set(None), + source_type: Set(None), + source_id: Set(None), created_at: Set(now), updated_at: Set(now), created_by: Set(operator_id), @@ -736,6 +748,8 @@ pub async fn create_record( status: Set("pending".to_string()), content_template: Set(None), related_appointment_id: Set(None), + source_type: Set(None), + source_id: Set(None), created_at: Set(now), updated_at: Set(now), created_by: Set(operator_id), diff --git a/crates/erp-health/src/service/validation.rs b/crates/erp-health/src/service/validation.rs index e7e3c3d..a435139 100644 --- a/crates/erp-health/src/service/validation.rs +++ b/crates/erp-health/src/service/validation.rs @@ -104,6 +104,7 @@ pub fn validate_follow_up_type(value: &str) -> HealthResult<()> { "visit", "online", "wechat", + "alert_auto", ] ); Ok(()) diff --git a/crates/erp-server/migration/src/lib.rs b/crates/erp-server/migration/src/lib.rs index 6886228..88b8152 100644 --- a/crates/erp-server/migration/src/lib.rs +++ b/crates/erp-server/migration/src/lib.rs @@ -158,6 +158,7 @@ mod m20260518_000153_ai_health_butler_v2; mod m20260519_000154_seed_ai_knowledge_permissions; mod m20260519_000155_fix_ai_menus_and_add_chat; mod m20260519_000156_fix_ai_menus_round2; +mod m20260520_000157_follow_up_source_and_points_rules; pub struct Migrator; @@ -323,6 +324,7 @@ impl MigratorTrait for Migrator { Box::new(m20260519_000154_seed_ai_knowledge_permissions::Migration), Box::new(m20260519_000155_fix_ai_menus_and_add_chat::Migration), Box::new(m20260519_000156_fix_ai_menus_round2::Migration), + Box::new(m20260520_000157_follow_up_source_and_points_rules::Migration), ] } } diff --git a/crates/erp-server/migration/src/m20260520_000157_follow_up_source_and_points_rules.rs b/crates/erp-server/migration/src/m20260520_000157_follow_up_source_and_points_rules.rs new file mode 100644 index 0000000..e4b0097 --- /dev/null +++ b/crates/erp-server/migration/src/m20260520_000157_follow_up_source_and_points_rules.rs @@ -0,0 +1,104 @@ +use sea_orm_migration::prelude::*; + +#[derive(DeriveMigrationName)] +pub struct Migration; + +#[async_trait::async_trait] +impl MigrationTrait for Migration { + async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> { + // 1. follow_up_task 新增 source_type 和 source_id 字段，追踪任务来源 + manager + .alter_table( + Table::alter() + .table(Alias::new("follow_up_task")) + .add_column(ColumnDef::new(Alias::new("source_type")).string().null()) + .add_column(ColumnDef::new(Alias::new("source_id")).uuid().null()) + .to_owned(), + ) + .await?; + + // 2. 新增积分规则种子：健康数据上报 + let insert_sql = r#" + INSERT INTO points_rule (id, tenant_id, name, event_type, points, daily_cap, is_active, created_at, updated_at, version) + SELECT + gen_random_uuid(), + t.id, + '健康数据上报', + 'health_data_report', + 5, + 10, + true, + NOW(), + NOW(), + 1 + FROM tenant t + WHERE NOT EXISTS ( + SELECT 1 FROM points_rule pr + WHERE pr.event_type = 'health_data_report' AND pr.tenant_id = t.id + ); + + INSERT INTO points_rule (id, tenant_id, name, event_type, points, daily_cap, is_active, created_at, updated_at, version) + SELECT + gen_random_uuid(), + t.id, + '化验报告上传', + 'lab_report_upload', + 20, + 40, + true, + NOW(), + NOW(), + 1 + FROM tenant t + WHERE NOT EXISTS ( + SELECT 1 FROM points_rule pr + WHERE pr.event_type = 'lab_report_upload' AND pr.tenant_id = t.id + ); + + INSERT INTO points_rule (id, tenant_id, name, event_type, points, daily_cap, is_active, created_at, updated_at, version) + SELECT + gen_random_uuid(), + t.id, + '连续上报奖励(7天)', + 'streak_7_days', + 50, + 50, + true, + NOW(), + NOW(), + 1 + FROM tenant t + WHERE NOT EXISTS ( + SELECT 1 FROM points_rule pr + WHERE pr.event_type = 'streak_7_days' AND pr.tenant_id = t.id + ); + "#; + manager + .get_connection() + .execute_unprepared(insert_sql) + .await?; + + Ok(()) + } + + async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> { + manager + .alter_table( + Table::alter() + .table(Alias::new("follow_up_task")) + .drop_column(Alias::new("source_type")) + .drop_column(Alias::new("source_id")) + .to_owned(), + ) + .await?; + + manager + .get_connection() + .execute_unprepared( + "DELETE FROM points_rule WHERE event_type IN ('health_data_report', 'lab_report_upload', 'streak_7_days');", + ) + .await?; + + Ok(()) + } +} diff --git a/crates/erp-server/tests/integration/health_follow_up_tests.rs b/crates/erp-server/tests/integration/health_follow_up_tests.rs index 3b82d70..0b4576f 100644 --- a/crates/erp-server/tests/integration/health_follow_up_tests.rs +++ b/crates/erp-server/tests/integration/health_follow_up_tests.rs @@ -15,6 +15,8 @@ fn default_create_task(patient_id: uuid::Uuid) -> CreateFollowUpTaskReq { planned_date: chrono::NaiveDate::from_ymd_opt(2026, 5, 15).unwrap(), content_template: Some("请询问血压情况".to_string()), related_appointment_id: None, + source_type: None, + source_id: None, } } diff --git a/crates/erp-server/tests/integration/health_pii_encryption_tests.rs b/crates/erp-server/tests/integration/health_pii_encryption_tests.rs index 8f1c21a..4b1142e 100644 --- a/crates/erp-server/tests/integration/health_pii_encryption_tests.rs +++ b/crates/erp-server/tests/integration/health_pii_encryption_tests.rs @@ -374,6 +374,8 @@ async fn test_follow_up_record_fields_encrypted() { planned_date: NaiveDate::from_ymd_opt(2026, 5, 1).unwrap(), content_template: None, related_appointment_id: None, + source_type: None, + source_id: None, }, ) .await diff --git a/docs/discussions/2026-05-20-business-chain-optimization.md b/docs/discussions/2026-05-20-business-chain-optimization.md new file mode 100644 index 0000000..9cb18f4 --- /dev/null +++ b/docs/discussions/2026-05-20-business-chain-optimization.md @@ -0,0 +1,71 @@ +# 业务链路打通方案讨论 + +> 日期: 2026-05-20 | 参与者: 产品 + 技术 + +## 背景 + +系统核心功能已开发完成（59 实体 / 376+ 路由 / 990+ 测试），但各业务模块之间的联动存在 5 个关键断点。用户要求全部打通，实现真正的"数据驱动健康管理闭环"。 + +## 讨论要点 + +### 断点 1: AI 分析被动触发 → 缺少主动分析能力 + +**现状:** AI 只在用户发消息时被动工作，不会主动巡检患者数据。 + +**打通方案:** +- 新增定时任务：每日自动巡检高风险患者（基于阈值 + 趋势） +- 新增事件：`health.ai_alert.sent`（已有常量但未使用）→ 触发医护端推送 +- 趋势预测告警：连续 N 天数据异常 → 发布 `health_data.critical_alert` 增强版 +- AI 分析结果回写：更新患者风险评估标签 + +### 断点 2: 告警只推医护 → 患者端无反馈 + +**现状:** 告警触发后只有医护收到，患者不知道自己数据异常。 + +**打通方案:** +- 告警事件消费：`alert.triggered` → 向患者发微信模板消息/站内通知 +- 小程序端新增"健康提醒"入口（消息 Tab 下） +- 轻量 AI 建议：告警触发时附带一句话建议（如"您的收缩压偏高，建议低盐饮食并按时服药"） + +### 断点 3: 随访手动创建 → 缺少数据驱动自动触发 + +**现状:** 随访任务主要靠手动或定时，没有根据数据异常自动生成。 + +**打通方案:** +- 告警 → 随访：`health_data.critical_alert` 事件被随访模块消费 → 自动创建随访任务 +- 护理计划 → 随访：`care_plan.activated` / `care_plan_item.completed` → 自动创建对应随访 +- AI 巡检 → 随访：AI 发现高风险 → 建议创建随访（需医护确认） + +### 断点 4: 积分激励面窄 → 健康行为无积分 + +**现状:** 积分只来自签到和活动，健康数据上报没有激励。 + +**打通方案:** +- 健康数据上报 → 积分：`daily_monitoring.created` 消费 → 调用 `earn_points("health_data_report")` +- 连续上报奖励：连续 7/14/30 天上报额外奖励（类似签到阶梯） +- 积分过期预警：过期前 3 天发通知 → `points.expiring_soon` 事件 +- 化验报告上传 → 积分：`lab_report.uploaded` 消费 → 积分 + +### 断点 5: 咨询孤立 → 与随访/AI 无联动 + +**现状:** 咨询是独立闭环，不能直接跳转随访或触发 AI。 + +**打通方案:** +- 咨询 → 随访：医生端新增"创建随访"按钮 → 调用 createTask API（关联 consultation_session_id） +- 咨询 → AI：医生可对咨询上下文触发 AI 分析（传 session_id 作为上下文） +- 告警 → 咨询：`alert.triggered` 消费 → 患者端展示"在线咨询"快捷入口 +- AI 分析结果主动推送：`ai_analysis.completed` → SSE 推送给关注该患者的医护 + +## 优先级排序 + +| 优先级 | 断点 | 价值 | 复杂度 | 预估工时 | +|--------|------|------|--------|---------| +| P0 | 断点 2: 告警推患者 | 高（直接影响患者体验） | 低 | 1 天 | +| P0 | 断点 3: 告警→自动随访 | 高（闭环核心） | 中 | 2 天 | +| P1 | 断点 4: 健康行为积分 | 中（提升活跃度） | 低 | 1.5 天 | +| P1 | 断点 1: AI 主动巡检 | 高（差异化竞争力） | 高 | 3 天 | +| P2 | 断点 5: 咨询联动 | 中（效率提升） | 中 | 2 天 | + +## 结论 + +全部 5 个断点需要打通，按 P0 → P1 → P2 分三批实施。总计约 9.5 天。 diff --git a/docs/健康管理/HMS系统设计思路.md b/docs/健康管理/HMS系统设计思路.md index 49e5e69..b0a7bda 100644 --- a/docs/健康管理/HMS系统设计思路.md +++ b/docs/健康管理/HMS系统设计思路.md @@ -1,6 +1,6 @@ # HMS 健康管理平台 — 系统设计思路 -> 版本: v1.0 | 日期: 2026-04-29 | 面向: 客户技术评审 +> 版本: v2.0 | 日期: 2026-05-20 | 面向: 客户技术评审 --- @@ -15,18 +15,19 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 ``` 患者上报数据 ──→ 实时展示（趋势图/仪表盘） ──→ 智能告警（异常指标自动通知医护） - ──→ AI 分析（趋势预测、健康报告） + ──→ AI 分析（ReAct Agent + 工具调用，趋势预测、健康报告） ──→ 随访触发（逾期未上报自动催办） ──→ 统计报表（运营决策依据） + ──→ 护理计划（数据驱动的个性化护理路径） ``` ### 1.2 三个设计原则 | 原则 | 含义 | 体现 | |------|------|------| -| **安全先行** | 医疗数据是敏感个人信息，安全不是"加一层"，而是架构的内建能力 | PII 字段加密存储、操作审计、知情同意、多租户隔离 | +| **安全先行** | 医疗数据是敏感个人信息，安全不是"加一层"，而是架构的内建能力 | PII 字段加密存储、操作审计、知情同意、多租户隔离、DTO 输入校验全覆盖 | | **渐进演进** | 不追求一步到位，但每一步都要为下一步打好基础 | 模块化单体架构，可按需拆分为微服务 | -| **开放集成** | 平台不封闭，能接入外部设备和系统 | 蓝牙设备协议、OpenAPI 文档、微信生态集成 | +| **开放集成** | 平台不封闭，能接入外部设备和系统 | BLE 蓝牙网关协议、FHIR R4 接口、OpenAPI 文档、微信生态集成 | --- @@ -35,25 +36,33 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 ### 2.1 三端覆盖 ``` -┌─────────────────────────────────────────────────┐ -│ HMS 健康管理平台 │ -├──────────────┬──────────────┬───────────────────┤ -│ 患者端 │ 医护端 │ 管理后台 │ -│ 微信小程序 │ 微信小程序 │ PC Web │ -│ │ │ │ -│ · 健康数据 │ · 患者管理 │ · 工作台仪表盘 │ -│ · 预约服务 │ · 咨询回复 │ · 患者管理 │ -│ · 在线咨询 │ · 随访管理 │ · 健康数据中心 │ -│ · 积分商城 │ · 告警处理 │ · 内容管理 │ -│ · AI 报告 │ · 报告解读 │ · 统计报表 │ -│ · 健康资讯 │ │ · 系统管理 │ -└──────────────┴──────────────┴───────────────────┘ +┌──────────────────────────────────────────────────────┐ +│ HMS 健康管理平台 │ +├──────────────┬──────────────┬────────────────────────┤ +│ 患者端 │ 医护端 │ 管理后台 │ +│ 微信小程序 │ 微信小程序 │ PC Web (React 19) │ +│ (Taro 4.2) │ (Taro 4.2) │ │ +│ │ │ │ +│ · 健康数据 │ · 患者管理 │ · 工作台仪表盘 │ +│ · 日常监测 │ · 咨询回复 │ · 患者管理 + 标签 │ +│ · 预约服务 │ · 随访管理 │ · 健康数据中心 │ +│ · 在线咨询 │ · 告警处理 │ · 预约排班 │ +│ · 积分商城 │ · 报告解读 │ · 随访模板 + 任务 │ +│ · AI 报告 │ · 透析管理 │ · 咨询管理 │ +│ · 健康资讯 │ · 护理计划 │ · 告警中心 + 规则 │ +│ · 轮播图 │ · 用药管理 │ · 内容管理 + 媒体库 │ +│ · 设备同步 │ │ · 积分商城 │ +│ · 长者模式 │ │ · 统计报表 │ +│ │ │ · AI 对话 + Copilot │ +│ │ │ · 系统管理 │ +└──────────────┴──────────────┴────────────────────────┘ │ │ │ └──────────────┼───────────────┘ │ ┌─────────┴─────────┐ │ 统一 API 网关 │ │ /api/v1/* │ + │ + /api/v1/fhir/* │ └─────────┬─────────┘ │ ┌───────────────┼───────────────┐ @@ -61,10 +70,14 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 ┌────┴────┐ ┌─────┴─────┐ ┌────┴────┐ │ 基础模块 │ │ 核心业务 │ │ AI 模块 │ │ │ │ │ │ │ - │ 认证权限 │ │ 健康管理 │ │ 化验解读 │ - │ 工作流 │ │ 预约排班 │ │ 趋势分析 │ - │ 消息中心 │ │ 随访管理 │ │ 报告摘要 │ - │ 系统配置 │ │ 透析管理 │ │ │ + │ 认证权限 │ │ 健康管理 │ │ AI 对话 │ + │ 工作流 │ │ 预约排班 │ │ 化验解读 │ + │ 消息中心 │ │ 随访管理 │ │ 趋势分析 │ + │ 系统配置 │ │ 咨询管理 │ │ 报告摘要 │ + │ 插件框架 │ │ 透析管理 │ │ Copilot │ + │ │ │ 内容管理 │ │ │ + │ │ │ 告警系统 │ │ │ + │ │ │ 积分商城 │ │ │ └────┬────┘ └─────┬─────┘ └────┬────┘ │ │ │ └───────────────┼───────────────┘ @@ -80,8 +93,8 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 | 层级 | 职责 | 特点 | |------|------|------| | **L1 基础层（erp-core）** | 错误体系、事件总线、模块 trait、共享类型 | 零业务依赖，所有模块的基础 | -| **L2 业务层** | 认证、配置、工作流、消息、健康管理、AI | 各模块独立，互不依赖，通过事件总线通信 | -| **L3 组装层（erp-server）** | Axum 入口，注册所有模块，统一路由 | 唯一的组装点，模块可插拔 | +| **L2 业务层** | 认证、配置、工作流、消息、插件、健康管理、AI、透析 | 各模块独立，互不依赖，通过事件总线通信 | +| **L3 组装层（erp-server）** | Axum 入口，注册 8+ 模块，统一路由，后台定时任务 | 唯一的组装点，模块可插拔 | 这种分层的设计意图是：**每个业务模块可以独立开发、独立测试、未来按需拆分为独立服务。** 模块之间不存在直接调用关系，所有跨模块通信都通过事件总线异步完成。 @@ -106,11 +119,11 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 ``` erp-core（基础层） | - +------+-------+-------+------+-------+ - | | | | | | - auth config workflow message health ai - | | | | | | - +------+-------+-------+------+-------+ + +------+-------+-------+------+-------+-------+ + | | | | | | | + auth config workflow message health ai dialysis + | | | | | | | + +------+-------+-------+------+-------+-------+ | erp-server（组装层） ``` @@ -158,9 +171,20 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 └──→ 统计模块：更新预约完成率 ``` +**事件系统规模：** + +| 指标 | 数量 | +|------|------| +| 事件类型 | 31 个（health 模块） | +| 全系统事件 | 51 个 | +| 事件发布点 | 82 个 | +| 事件消费模块 | 12 个 | + **可靠性保障：** - 所有事件持久化到 `domain_events` 表（Outbox 模式） +- PostgreSQL LISTEN/NOTIFY 实时投递 - 事件处理失败自动进入 Dead Letter 存储，不丢失 +- 消费端幂等保护（`processed_events` 表去重） - 支持事件重放，服务重启后可恢复未处理事件 ### 3.4 安全合规 — 内建而非外挂 @@ -172,34 +196,40 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 | 安全能力 | 实现方式 | |----------|---------| | **身份认证** | JWT + Access Token 15 分钟 + Refresh Token 7 天轮换 | -| **权限控制** | RBAC 角色权限 + 行级数据权限 + 按钮级控制 | -| **数据加密** | PII 字段（身份证、手机号）AES-256-GCM 加密存储 | -| **数据脱敏** | API 返回时自动脱敏（手机号 138****1234、身份证 ****1234） | +| **权限控制** | RBAC 角色权限 + 行级数据权限 + 按钮级控制，140 个细粒度权限码 | +| **数据加密** | PII 字段（身份证、手机号、咨询内容、随访记录）AES-256-GCM 加密存储 | +| **数据脱敏** | API 返回时自动脱敏（手机号 138\*\*\*\*1234、身份证 \*\*\*\*\*1234） | | **操作审计** | 关键操作记录变更前后状态，哈希链防篡改 | -| **输入防护** | SQL 注入防护（参数化查询）、XSS 防护、限流保护 | +| **输入防护** | SQL 注入防护（参数化查询）、XSS 防护、限流保护、SSRF 防护、DTO 全量校验 | | **知情同意** | 患者数据处理前获取明确同意，可随时撤回 | +| **接口安全** | SSE 支持 URL token 认证，FHIR OAuth client_credentials | --- ## 4. 数据架构 -### 4.1 实体模型（44 个业务实体） +### 4.1 实体模型（59 个业务实体 + 20 个 AI 实体） 平台围绕健康管理场景建模，覆盖从患者建档到长期随访的完整数据链路。 | 业务域 | 实体数 | 核心实体 | |--------|--------|---------| -| 患者管理 | 8 | 患者、家属、标签、医患关系、设备绑定、知情同意 | -| 医护管理 | 2 | 医生档案、排班 | -| 健康数据 | 9 | 健康档案、体征记录、体征小时聚合、日常监测、化验报告、趋势、诊断、用药记录、设备读数 | +| 患者管理 | 10 | 患者、家属、标签、标签关联、医患关系、患者分配、设备绑定、知情同意、盲索引、交接日志 | +| 医护管理 | 3 | 医生档案、排班、班次 | +| 健康数据 | 10 | 健康档案、体征记录、体征小时聚合、体征日聚合、日常监测、化验报告、健康趋势、诊断、用药记录、药物提醒 | | 透析管理 | 1 | 透析记录（独立 crate，可扩展为血透专科模块） | -| 预约排班 | 1 | 预约（原子 CAS 并发控制，防止超额） | +| 预约排班 | 2 | 预约、医生排班（原子 CAS 并发控制，防止超额） | | 随访管理 | 4 | 随访任务、随访记录、随访模板、模板字段 | | 咨询管理 | 2 | 咨询会话、咨询消息 | | 内容管理 | 5 | 文章、分类、标签、文章标签关联、文章修订 | | 告警系统 | 5 | 告警、告警规则、危急值告警、危急值响应、危急值阈值 | | 积分商城 | 6 | 积分账户、积分规则、商品、订单、积分流水、签到 | | 线下活动 | 2 | 活动、活动报名 | +| 护理计划 | 3 | 护理计划、计划项目、计划结果 | +| 媒体内容 | 3 | 媒体文件、文件夹、轮播图 | +| 设备接入 | 3 | BLE 网关、设备读数、网关患者绑定 | +| API 接入 | 1 | API 客户端（OAuth） | +| **合计** | **59** | | ### 4.2 数据安全策略 @@ -210,6 +240,7 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 │ 应用层 │ │ · JWT 认证 + RBAC 权限 + 行级数据范围 │ │ · API 统一入口，无直接数据库访问 │ +│ · DTO 输入校验全覆盖（44 处缺失已修复） │ ├─────────────────────────────────────────────┤ │ 数据层 │ │ · PII 字段加密（AES-256-GCM + KEK/DEK） │ @@ -235,13 +266,142 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 --- -## 5. 技术选型 +## 5. 核心业务链路 + +### 5.1 患者建档链路 + +``` +患者创建请求 + │ + ├── handler 层：输入校验（姓名非空、出生日期 ≤ 今天） + ├── service 层：业务校验（性别/血型枚举、身份证号 HMAC 去重） + ├── PII 加密：身份证号 + 紧急联系人电话 → AES 加密 + HMAC 盲索引 + ├── 写入 patient 表 + blind_indexes 表 + ├── 发布 patient.created 事件 + └── 记录审计日志 +``` + +**关键设计点：** 盲索引（HMAC-SHA256）确保加密存储后仍可按身份证号精确查重，避免重复建档。 + +### 5.2 预约排班链路（并发安全） + +``` +预约创建请求 + │ + ├── 校验患者 + 医生存在 + ├── 事务内原子 CAS： + │ UPDATE doctor_schedule + │ SET current_appointments = current_appointments + 1 + │ WHERE current_appointments < max_appointments + │ AND doctor_id = ? AND schedule_date = ? ... + ├── CAS 成功 → 插入 appointment 记录 + ├── CAS 失败 → 返回"排班已满" + ├── 发布 appointment.created 事件 + └── 定时任务：明日预约提醒（每小时检查） +``` + +**关键设计点：** 事务内 CAS（Compare-And-Swap）确保并发预约不会超额。取消时反向释放名额。 + +### 5.3 健康数据 → 告警链路 + +``` +体征数据上报（血压/心率/血糖...） + │ + ├── 写入 vital_signs 表 + ├── 调用 check_vital_signs_alert + │ ├── 加载 critical_value_threshold 阈值配置 + │ ├── 逐项检查收缩压/舒张压/心率/血糖 + │ └── 匹配阈值 → 发布 health_data.critical_alert 事件 + ├── 告警事件消费： + │ ├── 创建 alerts 记录 + │ ├── 发送站内通知（按严重级别分模板） + │ ├── SSE 实时推送给管床医生 + │ └── 告警聚合（抑制重复告警） + └── 设备数据同步 → 告警规则引擎评估（5 种设备类型） +``` + +**关键设计点：** 三级告警（阈值告警 → 规则告警 → 告警聚合抑制），SSE 实时推送确保医护第一时间收到。 + +### 5.4 AI 智能分析链路 + +``` +用户发送消息（POST /ai/chat） + │ + ├── 配额前置检查（租户/患者维度） + ├── AI 配置加载（动态 settings 表） + ├── Provider 解析：default_provider → fallback chain（claude → openai → ollama） + ├── Tool Registry 注册 9 个工具： + │ ├── 查询患者体征、化验报告、预约、用药 + │ ├── 分析化验报告、健康趋势 + │ ├── 获取健康洞察、搜索医学知识、查询患者档案 + ├── 角色沙箱：doctor/patient/admin 限制可用工具集 + ├── ReAct Agent 循环（FC provider 多轮 tool call） + ├── 非 FC provider 降级为普通对话 + ├── 会话持久化（session_id 模式，50 条历史） + └── SSE 流式输出 +``` + +**关键设计点：** ReAct Agent 架构使 AI 能够自主调用后端工具获取实时数据，不只是"聊天"而是真正的"分析"。 + +### 5.5 咨询管理链路 + +``` +患者发起咨询 → 创建 consultation_session (status=waiting) + │ + ├── 发送首条消息 → 自动切换 waiting → active + ├── handler 层通过 doctor_profile 推导 sender_role（不信任客户端） + ├── 消息内容 PII 加密后存储 + ├── CAS 更新会话 unread_count + last_message_at + ├── 发布 consultation.new_message 事件 + ├── 医生端：长轮询（先查 DB → 无消息则等事件总线通知） + └── 关闭会话 → consultation.closed 事件 +``` + +**关键设计点：** 长轮询 + 事件总线混合模式，兼顾实时性和可靠性。 + +### 5.6 随访管理链路 + +``` +创建随访任务 (status=pending) + │ + ├── 发布 follow_up.created 事件 + ├── 定时检查（每 6 小时）：过期任务标记 overdue → 发布 follow_up.overdue + ├── 执行随访： + │ ├── 随访结果 PII 加密后存储 + │ ├── 更新任务 status → completed + │ ├── 如指定 next_follow_up_date → 自动创建后续任务 + │ └── 发布 follow_up.completed 事件 + └── 批量操作：批量创建（≤100）、批量分配、批量完成 +``` + +**关键设计点：** 随访闭环（创建 → 执行 → 自动创建后续 → 过期催办），结合事件驱动确保不遗漏。 + +### 5.7 积分商城链路 + +``` +签到 → 获取积分 → 兑换商品 + │ + ├── 每日签到：连续天数 + 阶梯奖励（7/14/30 天） + ├── 积分获取：按规则表查找分值 → 检查 daily_cap → CAS 更新余额 + ├── 积分兑换： + │ ├── 校验商品上架 + 库存 + │ ├── FIFO 消费：按 expires_at ASC 扣减最早的 earn 交易 + │ └── 创建订单 + CAS 更新余额 + ├── 线下活动签到 → 自动发放活动积分 + └── 定时清理（每 24 小时）：过期积分 → 扣减余额 → 发布 points.expired +``` + +**关键设计点：** FIFO 积分消费确保先到期的积分优先使用，CAS 原子操作保障并发安全。 + +--- + +## 6. 技术选型 每一项技术选择都经过实际验证，不是纸上谈兵。 | 层次 | 选择 | 选择理由 | |------|------|---------| -| **后端语言** | Rust | 内存安全 + 高性能，无 GC 停顿，适合医疗系统长期稳定运行 | +| **后端语言** | Rust (edition 2024) | 内存安全 + 高性能，无 GC 停顿，适合医疗系统长期稳定运行 | | **Web 框架** | Axum 0.8 | Tokio 官方维护，类型安全路由，tower 中间件生态 | | **ORM** | SeaORM 1.1 | 异步、编译期类型检查、迁移工具链完善，SQL 错误在编译期暴露 | | **数据库** | PostgreSQL 18 | 企业级可靠性，JSON 支持，丰富的索引类型，医疗场景的稳妥选择 | @@ -249,7 +409,8 @@ HMS 平台的设计围绕一个核心命题：**让患者的健康数据产生 | **前端** | React 19 + Ant Design 6 | 企业后台 UI 标配，组件丰富，开发效率高 | | **状态管理** | Zustand 5 | 极简 API，无 boilerplate，适合中等复杂度应用 | | **小程序** | Taro 4.2 + React 18 | 跨端兼容，React 开发体验一致，微信生态集成成熟 | -| **AI 集成** | SSE 流式 + 大模型 API | 化验解读、趋势分析、报告摘要，流式输出实时反馈 | +| **AI 集成** | ReAct Agent + SSE 流式 + FC | 化验解读、趋势分析、报告摘要，Agent 自主调用后端工具 | +| **外部标准** | FHIR R4 | 医疗数据互操作标准，8 种资源类型只读接口 | **为什么选择 Rust？** @@ -262,18 +423,32 @@ Rust 在医疗系统中的独特价值： --- -## 6. 质量保障 +## 7. 质量保障 -### 6.1 测试金字塔 +### 7.1 测试体系 | 测试类型 | 数量 | 覆盖目标 | |----------|------|---------| -| 单元测试 | 225+ | 每个 service 函数、验证逻辑、脱敏逻辑 | -| 集成测试 | 159+ | API 端点 → 数据库完整链路，使用真实 PostgreSQL | +| 后端测试函数 | 990+ 个（802 同步 + 188 异步） | 每个 service 函数、验证逻辑、脱敏逻辑 | +| 后端测试文件 | 110 个 | 覆盖全部业务模块 | +| Web 前端单元测试 | 62 文件（~693 断言） | 组件、hooks、API 层 | +| E2E 测试 | 17 套 spec（~64 断言） | Web 13 套 + 小程序 4 套 | | 多租户测试 | 独立测试 crate | 数据隔离验证，确保跨租户不可见 | -| E2E 测试 | 5 套 | 前端关键用户流程（Playwright） | +| 角色权限测试 | R01-R05 五角色全覆盖 | 86.5% 通过率，5 个 BUG 已修复 | +| 小程序多角色测试 | MP 多角色验证 | 96.2% 通过率 | -### 6.2 验证机制 +### 7.2 代码质量 + +| 指标 | 状态 | +|------|------| +| Clippy 警告 | 全 workspace 0 警告 | +| utoipa 注解 | 94 个文件含 OpenAPI 注解 | +| 权限码 | 140 个（health 57 + ai 21 + auth 24 + 其他 38） | +| 依赖版本 | 全部最新主版本线 | +| UI 合规审计 | 60 页面全覆盖，评分 95/100 | +| 长者模式 | 58/58 页面 100% 覆盖 | + +### 7.3 验证机制 每个功能交付前必须通过： @@ -283,7 +458,7 @@ Rust 在医疗系统中的独特价值： - 生产构建 — `pnpm build` 前端生产构建通过 - 数据库验证 — 迁移可正向/反向执行 -### 6.3 关键数据保障 +### 7.4 关键数据保障 | 保障项 | 机制 | |--------|------| @@ -291,6 +466,41 @@ Rust 在医疗系统中的独特价值： | 数据不丢失 | 软删除 + 事件 Outbox 持久化 + Dead Letter | | 数据不篡改 | 乐观锁（version 字段）+ 审计日志哈希链 | | 接口一致性 | 统一 `ApiResponse` 包装，OpenAPI 文档自动生成 | +| 输入安全 | DTO 全量 Validate derive + handler 层 validate() 调用 + SSRF 防护 | + +--- + +## 8. 项目规模 + +### 8.1 关键数字 + +| 指标 | 值 | +|------|-----| +| Rust crate | 17 个 | +| Rust 源文件 | ~694 个（~125,000 行） | +| 数据库表 | 95 个（30 基础 + 49 健康 + 13 AI + 3 媒体） | +| 数据库迁移 | 156 个 | +| 后端路由 | 376+ 个（11 公开 + 14 FHIR + 2 网关 + ~350 受保护） | +| 后端测试 | 990+ 个函数 | +| Web 前端 | 316 个 TS/TSX 文件，36 活跃路由，161 页面 | +| 微信小程序 | 167 个 TS/TSX 文件，59 页面（12 主包 + 47 子包） | +| 事件类型 | 51 个全系统 / 82 发布点 / 12 消费模块 | +| 权限码 | 140 个 | +| Git 提交 | 927+ 次 | + +### 8.2 开发进度 + +| 阶段 | 状态 | +|------|------| +| 基础层（auth/config/workflow/message） | 已完成 | +| 健康管理核心模块（erp-health） | 已完成（59 实体 / 31 handler / 37 service） | +| AI 智能分析模块（erp-ai） | 已完成（20 实体 / ReAct Agent / 4 Provider） | +| 透析管理模块（erp-dialysis） | 已完成 | +| Web 管理后台 | 已完成（36 活跃路由） | +| 患者端小程序 | 已完成（59 页面 + 长者模式） | +| 医护端小程序 | 已完成（分包，独立导航栏） | +| 全系统审计 V2 | 已完成（85%，P0 安全修复已完成） | +| 系统评分 | 6.3/10 (B-)，V1 CONDITIONAL GO | --- @@ -298,16 +508,9 @@ Rust 在医疗系统中的独特价值： HMS 平台的设计围绕四个关键词展开： -1. **模块化** — 每个业务模块独立自治，通过事件总线协作，可按需拆分演进 -2. **安全合规** — 加密存储、操作审计、知情同意、多租户隔离，从架构内建安全能力 -3. **数据驱动** — 每条数据都有明确用途：展示、告警、分析、触发、统计 +1. **模块化** — 17 个 crate、8 个独立业务模块，通过事件总线协作，可按需拆分演进 +2. **安全合规** — PII 加密、操作审计、知情同意、多租户隔离、DTO 全量校验，从架构内建安全能力 +3. **数据驱动** — 59 个业务实体覆盖全链路，每条数据都有明确用途：展示、告警、分析、触发、统计 4. **渐进演进** — 当前是模块化单体，未来可按模块独立拆分为微服务，无需重写 -平台已完成核心功能开发，包括 44 个业务实体、25+ 管理后台页面、40 个小程序页面、225+ 单元测试。具备投入试运行的基础条件。 - - - - - - - +平台已完成核心功能开发：59 个业务实体、376+ 个 API 端点、36 个管理后台路由、59 个小程序页面、990+ 个后端测试。系统通过 V2 审计（85% 完成度），具备投入试运行的基础条件。