diff --git a/20-慢性病管理-模块规划.md b/20-慢性病管理-模块规划.md new file mode 100644 index 0000000..4ca2ff6 --- /dev/null +++ b/20-慢性病管理-模块规划.md @@ -0,0 +1,161 @@ +# 慢性病管理 模块规划 + +--- + +## 1. 模块定位 + +慢性病管理系统是面向**老年慢性病患者（高血压/糖尿病/冠心病等）全病程管理**的专业医疗信息化系统，覆盖患者服务端、移动医生端、医生工作站（嵌入HIS）和医院管理端四个角色视图，实现慢性病的早期筛查、连续监测、规范治疗、用药提醒和复诊管理。 + +本系统是连接"居家健康监测"（健康管理08）与"专业医疗诊疗"之间的慢病管理中间层，也是医养结合战略的核心医疗侧体现。 + +--- + +## 2. 建设目标 + +1. 为慢性病患者（老人）提供自我健康管理工具（用药提醒/血压血糖记录/随访提醒） +2. 支持移动医生端随时查看患者健康数据、开具随访计划 +3. 嵌入HIS的医生工作站，实现慢病管理与日常诊疗一体化 +4. 提供医院管理端的慢病患者群组分析和质量控制 +5. 打通健康管理（08）的体征数据，实现慢病异常早预警 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 患者服务端 +- 移动医生端 +- 医生工作站（嵌入HIS） +- 医院管理端 + +### 3.2 二级模块 + +- **患者服务端**：慢病档案、用药清单与提醒、血压/血糖自测记录、随访提醒、复诊预约、健康教育（文章/视频） +- **移动医生端**：我的患者列表、患者健康趋势、随访记录、在线问诊、处方开具（⚠️ 需互联网医院资质） +- **医生工作站（HIS嵌入）**：慢病患者库、慢病路径管理、历史随访记录、与HIS医嘱联动 +- **医院管理端**：科室慢病患者统计、达标率分析、医生绩效（随访完成率）、质量控制报表 + +### 3.3 核心功能说明 + +| 功能 | 描述 | 前提条件 | +| ---------- | ---------------------------------------------- | ----------------------------- | +| 慢病档案 | 基于老人档案（02）扩展，增加主诊断/用药/手术史 | 老人档案（02）就绪 | +| 用药提醒 | 按处方设置每日多次用药提醒，支持家属勾选确认 | 处方数据来源（HIS或手动录入） | +| 随访计划 | 医生设置随访时间表，系统提醒患者和医生双方 | 医生工作站在HIS中就绪 | +| 在线问诊 | 图文/视频问诊（需互联网医院牌照） | ⚠️ 需互联网医院资质 | +| 处方开具 | 电子处方（需与医保处方流转系统对接） | ⚠️ 需互联网处方资质 | +| 达标率分析 | 基于血压/血糖控制目标的患者达标率统计 | 患者体征数据积累足够 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 是通用电商平台，不具备任何慢性病管理能力： + +| 能力需求 | mall 现状 | 结论 | +| ---------------------------- | --------- | ------------------- | +| 慢病档案（诊断/用药/手术史） | 无 | 须独立建设 | +| 随访计划管理 | 无 | 须独立建设 | +| 医生工作站（HIS集成） | 无 | 须独立建设 | +| 互联网问诊/处方 | 无 | 须独立建设（+资质） | +| 达标率统计分析 | 无 | 须独立建设 | +| 医学体征趋势分析 | 无 | 须独立建设 | + +mall 是通用电商平台，不具备慢性病管理和医疗诊疗专业能力，强行堆入会导致数据合规失控和医疗责任风险。 + +--- + +## 5. 规划判断 + +**独立系统建设（专业医疗信息化系统）** + +- 患者端：uni-app（小程序+H5） +- 医生端：uni-app（移动端）+ Vue3 Web（工作站） +- 管理端：Vue3 Web +- HIS集成：通过HL7/FHIR接口与现有HIS系统对接 +- **互联网医院牌照**：在线问诊和处方需要机构具备互联网医院资质（⚠️ 非技术问题，需提前规划） + +--- + +## 6. 需新增业务能力 + +1. **慢病路径管理**：标准化慢病管理路径（高血压/糖尿病/冠心病等），按路径执行随访 +2. **体征数据整合**：整合健康管理（08）的IoT体征数据，提供医生视角的患者健康时间轴 +3. **随访计划执行**：自动生成随访任务提醒，记录随访完成情况 +4. **处方流转**：电子处方→药房取药/配送（联动中心药房21和医养商城19） +5. **患者教育内容**：慢病自我管理科普内容（文章/视频/问卷） +6. **质量控制**：科室或机构维度的慢病管理质量报表 + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| ------------------------- | --------------------------------------------------------------------------------------- | +| `chronic_disease_profile` | elder_id, disease_code(ICD-10), diagnosis_date, severity, medications(JSONB), doctor_id | +| `medication_reminder` | id, profile_id, drug_name, dosage, frequency, reminder_times(array), is_active | +| `followup_plan` | id, profile_id, doctor_id, cycle(月/季), next_date, items(JSONB) | +| `followup_record` | id, plan_id, actual_date, method, vitals(JSONB), notes, doctor_id | +| `online_consultation` | id, patient_id, doctor_id, consult_type, status, prescription_id, started_at | +| `e_prescription` | id, consultation_id, drug_list(JSONB), dispensed_at, pharmacy_id | +| `disease_control_target` | disease_code, metric_type, target_min, target_max, unit | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ---------- | --------------------------------- | ----------------- | +| 医疗互操作 | HL7 FHIR R4 | 与HIS系统数据交换 | +| 视频问诊 | 腾讯云TRTC / 声网 | 在线视频问诊 | +| 处方流转 | 各省处方流转平台接口（⚠️ 待确认） | 电子处方外配 | +| 电子病历 | 符合电子病历规范（卫生部标准） | 随访记录规范存储 | +| 推送 | 微信模板消息 | 用药/随访提醒 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 说明 | +| ---------------- | ----------------------------- | ------------- | +| 健康管理（08） | 患者体征数据（血压/血糖时序） | 内部API | +| 中心药房（21） | 电子处方流转取药 | 内部API | +| 医养商城（19） | 处方药品配送 | 内部API | +| 数据库系统（02） | 老人档案基础数据 | 内部API | +| 机构HIS系统 | 医嘱、诊断记录共享 | HL7 FHIR | +| 处方流转平台 | 电子处方外配（各省平台不同） | ⚠️ 待确认接口 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ----------------------- | ---------------------------------------------------- | -------------------------------------------------- | +| 互联网医院资质 | 在线问诊/处方需机构具备互联网医院牌照 | ⚠️ 需提前规划资质申请，技术可先建设 | +| 电子处方合规 | 处方须医生电子签名，且不得泄露 | CA电子签名（国密）+ 加密存储 | +| 医疗责任风险 | 平台提供建议而非诊断，界限须清晰 | 系统界面明确"本系统提供慢病辅助管理，不能替代问诊" | +| 数据合规 | 病历属于最高级别个人敏感数据 | 等保三级 + 国密 + 数据不出境 | +| 边界：不含急诊/住院管理 | 本系统管理慢性病，急性期就诊须到医院，不在系统范围内 | 明确功能边界 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P2** + +| 分期 | 内容 | 前置条件 | +| ------ | ---------------------------------------------- | ---------------------------------- | +| 第一期 | 慢病档案 + 用药提醒 + 随访计划（无需医院资质） | 老人档案（02）、健康数据（08）就绪 | +| 第二期 | 医生工作站 + HIS集成 + 随访记录 | HIS系统确认、接口规范 | +| 第三期 | 在线问诊 + 电子处方 + 处方外配 | 互联网医院资质获取 | + +--- + +## 12. 结论 + +慢性病管理系统是医养结合战略的医疗侧核心，其慢病路径、HIS集成、互联网问诊等能力在 mall 中完全缺失，**必须独立建设**。 + +建议第一期先建设不依赖医院资质的功能（慢病档案/用药提醒/随访提醒），快速给老人提供价值；互联网问诊和电子处方依赖资质准备，作为后续阶段叠加。 diff --git a/21-中心药房-模块规划.md b/21-中心药房-模块规划.md new file mode 100644 index 0000000..713cdf1 --- /dev/null +++ b/21-中心药房-模块规划.md @@ -0,0 +1,173 @@ +# 中心药房 模块规划 + +--- + +## 1. 模块定位 + +中心药房系统是面向**养老机构/医疗机构**的专业药事管理系统，覆盖药库（仓储）管理、门诊药房、住院药房、医养商城药房（线上配送）和共享中心药房（省阳采平台对接），实现药品的全生命周期管理（采购→入库→发药→追溯）。 + +本系统是典型的医疗信息化专业系统，需满足《药品管理法》《医院信息系统基本功能规范》等法规要求，并对接国家药品追溯系统和省级阳光采购平台。 + +--- + +## 2. 建设目标 + +1. 实现药库（院内药房仓储）的精细化管理（批次/效期/库存预警） +2. 落地门诊药房配药发药流程（医嘱核对→调配→发药→签收） +3. 管理住院药房的口服/静脉用药（摆药→送药→核对） +4. 对接医养商城，实现处方药线上购买与配送（⚠️ 需处方流转资质） +5. 接入共享中心药房模式（省阳光采购平台对接） +6. 实现药品全程追溯码管理 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 药库管理 +- 门诊药房 +- 住院药房 +- 医养商城药房（处方流转） +- 药品预警管理 +- 耗材管理 +- 设备管理（药房设备） +- 共享中心药房（省阳采） +- 药品追溯码管理 + +### 3.2 二级模块 + +- **药库管理**：药品采购入库、供应商管理、批次/效期管理、库存盘点、库存调拨 +- **门诊药房**：处方审核（药师审核）、调配出药、发药记录、用药指导 +- **住院药房**：摆药单生成、口服药摆药、静脉配药（PIVAS）、送药核对 +- **商城药房**：处方上传审核、线上付款、配送或自取、处方单存档 +- **药品预警**：近效期预警（3/6/12个月）、低库存预警、过期药品管理 +- **耗材管理**：医用耗材入库/发放/盘点 +- **设备管理**：药房设备台账（发药机/冰箱/保险柜）维护记录 +- **省阳采对接**：目录对接、在线采购、回款管理 +- **药品追溯**：条码扫描入库、发药扫码、药监局追溯系统上报 + +### 3.3 核心功能说明 + +| 功能 | 描述 | 合规要点 | +| -------------------- | ---------------------------------------------- | -------------------------------- | +| 处方审核（四查十对） | 药师审核处方（查处方/查药品/查配伍/查用法） | 《处方管理办法》要求 | +| 处方流转 | 电子处方→线上购药→外配药房发药 | 需互联网医院+处方流转资质 | +| 药品追溯码 | 每个药品包装扫码入库，发药时再次扫码，上报药监 | 《药品追溯条例》要求 | +| 近效期预警 | 批次效期提前预警，触发优先发药或退货 | GMP/GSP规范 | +| 省阳采对接 | 按省级阳光采购平台目录采购、回款 | 各省采购平台接口（⚠️ 差异大） | +| 高警讯药品管理 | 高危药品的特殊存储和发药记录 | 国家卫健委《高警讯药品管理规范》 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 有商品管理和库存体系，表面上与药库管理有相似性，但存在根本质的差异： + +| 能力需求 | mall 现状 | 结论 | +| -------------------- | -------------- | ----------------- | +| 药品批次/效期管理 | 商品无批次概念 | 须独立建设 | +| 处方审核（四查十对） | 无 | 须独立建设 | +| 药品追溯码系统 | 无 | 须独立建设 | +| 医嘱-处方联动 | 无 | 须独立（依赖HIS） | +| 省阳采平台对接 | 无 | 须独立建设 | +| 药监局接口上报 | 无 | 须独立建设 | +| 高警讯药品管理 | 无 | 须独立建设 | + +mall 是通用电商平台，不具备药事管理专业能力，强行堆入会导致数据合规失控和药品安全风险。 + +--- + +## 5. 规划判断 + +**独立系统建设（专业药事管理系统）** + +- 药师/仓库端：Vue3 PC Web（主要使用场景为院内PC） +- 移动辅助端：uni-app（送药/盘点扫码） +- 与慢性病管理（20）和HIS系统通过HL7接口对接处方数据 +- **建议评估采购成熟的HIS药房模块**，而非全自研 + +--- + +## 6. 需新增业务能力 + +1. **药品主数据库**：国家药品编码（YPH）、通用名/商品名、剂型、规格、价格 +2. **批次管理**：每个批次独立追踪（批号/生产日期/效期/供应商/入库单号） +3. **处方审核引擎**：内置配伍禁忌数据库、用药剂量校验 +4. **药品追溯码接入**：国家药品监管局追溯系统API（各省接口统一程度待确认） +5. **省阳采对接**：采购申请→省平台下单→入库核对→回款管理 +6. **共享药房能力**：多机构共享一个中心药房，按机构分账 + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| --------------------- | --------------------------------------------------------------------------------------------------------- | +| `drug_master` | id, national_code(YPH), generic_name, brand_name, dosage_form, specification, unit, category | +| `drug_batch` | id, drug_id, batch_no, manufacturer, produce_date, expire_date, purchase_price, quantity_in, quantity_out | +| `drug_stock` | drug_id, location_id, available_qty, locked_qty, last_updated | +| `prescription_review` | id, prescription_id, pharmacist_id, review_result, issues(JSONB), reviewed_at | +| `drug_dispensing` | id, prescription_id, batch_id, qty, dispensed_by, dispensed_at, patient_id | +| `drug_trace_record` | id, drug_id, trace_code, event_type(in/out/dispose), reported_at, report_status | +| `low_stock_alert` | drug_id, current_qty, min_qty, alert_at, handled | +| `near_expire_alert` | batch_id, expire_date, alert_days_before, alert_at, action_taken | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ----------- | ------------------------------------------ | --------------------- | +| 药品数据库 | 国家标准数据库（CFDA数据）或商业药品知识库 | 药品主数据 + 配伍禁忌 | +| 二维码/条码 | ZXing / 硬件扫码枪 | 药品追溯码扫描 | +| 医疗互操作 | HL7 FHIR | 与HIS/处方系统交换 | +| 省阳采平台 | 各省采购平台API（⚠️ 差异大） | 阳光采购对接 | +| 药监追溯 | 国家药品追溯系统API | 药品追溯码上报 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 说明 | +| ------------------ | ------------------------------ | --------------------- | +| 慢性病管理（20） | 电子处方流转到中心药房 | 内部API（HL7 FHIR） | +| 医养商城（19） | 处方药线上购买，从药房出库配送 | 内部API | +| 医保DIP（17） | 药品费用数据提供给医保审核 | 内部API | +| 机构HIS系统 | 医嘱→处方→发药 | HL7 FHIR | +| 国家药监局追溯系统 | 药品码上报 | 官方API | +| 省阳光采购平台 | 采购目录对接 | ⚠️ 各省接口规范待确认 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| -------------------- | ------------------------------------------------ | ---------------------------------------- | +| 药品追溯接口 | 各省药监局追溯接口进度不一 | 优先实现自建追溯记录，国家接口就绪后对接 | +| 省阳采差异 | 各省阳光采购平台接口规格不同 | 设计可配置的采购平台适配层 | +| 处方流转资质 | 需互联网处方流转资质 | ⚠️ 提前规划资质 | +| 效期管理复杂度 | 临期药品FIFO（先进先出）需严格执行 | 系统强制FIFO发药策略 | +| 边界：不含诊断和开方 | 本系统只管理处方后的药事流程，开方在HIS/慢病系统 | 明确与开方系统的接口边界 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P2** + +| 分期 | 内容 | 前置条件 | +| ------ | ------------------------------------ | ---------------------------------- | +| 第一期 | 药库管理 + 门诊药房（院内流程） | HIS系统确认 | +| 第二期 | 处方流转线上化 + 商城药房 | 处方流转资质、慢性病管理（20）就绪 | +| 第三期 | 省阳采对接 + 药品追溯 + 共享中心药房 | 各省接口确认 | + +--- + +## 12. 结论 + +中心药房系统是高度专业的药事管理系统，其批次/效期管理、处方审核、药品追溯等核心能力与 mall 的商品管理存在根本性差异，**必须独立建设**。 + +**强烈建议评估采购成熟的HIS药房模块**（如东软医疗、金仕达、卫宁健康等），大幅降低研发风险。处方流转与省阳采对接需提前开展资质申请和接口调研。 diff --git a/22-人工智能服务-模块规划.md b/22-人工智能服务-模块规划.md new file mode 100644 index 0000000..284cea3 --- /dev/null +++ b/22-人工智能服务-模块规划.md @@ -0,0 +1,193 @@ +# 人工智能服务 模块规划 + +--- + +## 1. 模块定位 + +人工智能服务平台是以**国产大模型（DeepSeek等）为基础**的医养专项AI能力集群，通过对医疗多模态数据的预训练和垂直微调，为医养平台各业务系统提供智能推荐、医疗审核辅助、知识检索、辅诊统计分析等标准化AI能力。 + +本系统不面向终端用户，而是作为**AI能力中间层**，通过API向其他业务模块（居家养老、医养商城、慢性病管理、全生命周期监测等）提供AI服务支撑。 + +--- + +## 2. 建设目标 + +1. 构建基于大模型的临床决策辅助系统（智能推荐+辅诊+医疗审核） +2. 构建医养知识检索系统（疾病/药物/诊疗方案多维度知识库） +3. 构建区域辅诊监测分析系统（机构级/区域级辅诊效果评估） +4. 提供大模型能力的安全、标准化API输出 +5. 建立AI模型的全生命周期管理（训练→测试→部署→监控→迭代） + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 智能推荐 +- 医疗审核 +- 知识检索 +- 区域辅诊监测分析 +- 大模型管理平台 + +### 3.2 二级功能清单 + +**智能推荐（11项）**： + +- 关联症状问诊推荐 +- 进一步问诊推荐 +- 疑似诊断推荐 +- 特殊疾病处置建议 +- 误诊提醒 +- 漏诊提醒 +- 危急重症提醒 +- 检查检验推荐 +- 用药推荐 +- 操作治疗推荐 +- 手术推荐 + +**医疗审核（4项）**： + +- 检查合理性审核 +- 检验合理性审核 +- 操作治疗合理性审核 +- 手术合理性审核 + +**知识检索（17项）**： + +- 关键字/疾病/药物/临床路径/指南/病历/检验/检查/症状/手术/操作治疗/量表/健教知识/文献/法律法规目录检索 +- 知识收藏 +- 知识库维护 + +**区域辅诊监测（7项）**： + +- 辅诊查询（机构/区域） +- 审核查询 +- 风险查询 +- 辅诊统计 +- 审核总体统计 +- 检查检验审核统计 +- 手术操作审核统计 +- 诊断质控统计 + +### 3.3 核心架构说明 + +| 层次 | 内容 | +| --------------- | ----------------------------------------- | +| 大模型基座 | DeepSeek等国产大模型，通用理解和生成能力 | +| 垂直预训练 | 医疗文献、临床指南、中医古籍、药品说明书 | +| 场景微调（SFT） | 辅诊任务、用药推荐、护理方案等场景数据 | +| AI应用层 | 各业务场景调用的标准化API接口 | +| 监控运维层 | 模型性能监控、Hallucination检测、版本管理 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 是通用电商平台，不具备任何医疗AI能力： + +| 能力需求 | mall 现状 | 结论 | +| -------------------- | --------- | ----------------------- | +| 大模型部署与微调 | 无 | 须独立建设（需GPU算力） | +| 医疗知识库与向量检索 | 无 | 须独立建设 | +| 辅诊推荐算法 | 无 | 须独立建设 | +| 医疗合规审核规则 | 无 | 须独立建设 | +| 区域AI监测分析 | 无 | 须独立建设 | + +mall 是通用电商平台，不具备任何AI训练和推理能力，强行堆入会导致架构崩溃（GPU算力需求与电商系统运行需求完全不同）。 + +--- + +## 5. 规划判断 + +**独立系统建设（AI平台，高专业性）** + +- AI推理服务：Python FastAPI（GPU服务器部署） +- 知识库检索：Elasticsearch + 向量数据库（Milvus/Qdrant） +- 管理界面：Vue3 Web（模型管理、知识库维护） +- 算力：GPU服务器（推荐A100/H100）或云GPU（阿里云/腾讯云GPU实例） +- 大模型：DeepSeek-R1 或 DeepSeek-V3（中文医疗能力强的国产模型） + +--- + +## 6. 需新增业务能力 + +1. **医疗知识图谱构建**：疾病-症状-药物-检查-治疗方案关联关系网络 +2. **向量化医学文档库**：临床指南/诊疗规范文档向量化存储，支持语义检索 +3. **大模型微调管道**：LoRA/QLoRA微调流程，支持定期增量训练 +4. **推理API服务**：各AI能力（辅诊/推荐/检索）的标准化REST API +5. **Hallucination防护**：医疗AI回答的置信度评分和人工审核机制 +6. **模型版本管理**：多版本模型对比测试，灰度发布 + +--- + +## 7. 需新增数据模型（AI平台侧） + +| 模型 | 关键字段 | +| ------------------- | ---------------------------------------------------------------------------------------------- | +| `ai_model_registry` | id, name, version, base_model, fine_tune_type, deploy_status, accuracy_metrics(JSONB) | +| `knowledge_doc` | id, category, title, content, vector_embedding(vector), source, updated_at | +| `ai_inference_log` | id, api_endpoint, request_hash, response_hash, latency_ms, model_version, created_at | +| `ai_audit_record` | id, inference_id, reviewer_id, review_result, issues, created_at | +| `disease_knowledge` | id, icd_code, disease_name, symptoms(array), treatments(JSONB), drugs(array), source_guideline | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ------------ | ---------------------------------------- | ------------------ | +| 大模型 | DeepSeek-R1/V3（本地部署）或DeepSeek API | 核心推理能力 | +| 向量数据库 | Milvus / Qdrant | 知识库语义检索 | +| 全文检索 | Elasticsearch | 知识文档全文检索 | +| 模型服务框架 | vLLM / TGI | 大模型高效推理服务 | +| 训练框架 | LLaMA-Factory / Axolotl（LoRA微调） | 垂直领域微调 | +| GPU算力 | 本地A100/H100 或 云GPU（阿里云/腾讯云） | 模型推理与训练 | +| 监控 | Arize AI / 自研 | 模型性能与幻觉监控 | + +--- + +## 9. 外部系统对接关系 + +| 对接方（调用方） | AI能力需求 | +| -------------------- | ---------------------------- | +| 慢性病管理（20） | 辅诊推荐、用药建议 | +| 医养商城（19） | 健康档案驱动的个性化商品推荐 | +| 全生命周期监测（23） | 异常行为识别、健康趋势预测 | +| 居家养老管理（10） | 服务方案AI推荐 | +| 运营管理（24） | 智能报告生成 | +| 数据中台（26） | 健康画像与风险预测模型 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| --------------------------- | -------------------------------- | -------------------------------------------------------- | +| 医疗AI幻觉（Hallucination） | 大模型对医疗建议可能输出错误内容 | 强制人工审核关键推荐 + RAG（知识增强检索）降低幻觉率 | +| GPU算力成本 | 本地GPU服务器成本高昂 | 初期用API接口（DeepSeek云API），规模化后自建 | +| 医疗AI合规 | 医疗AI辅助诊断受监管（需备案） | 明确定位为"辅助工具"而非"诊断工具"，符合医疗器械监管要求 | +| 数据训练合规 | 用患者数据训练模型需合规授权 | 数据脱敏处理 + 患者知情同意 | +| 边界：AI仅辅助，不替代医生 | 所有AI推荐须经医生确认后执行 | 系统界面明确标注"AI辅助建议，以医生判断为准" | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P2** + +| 分期 | 内容 | 前置条件 | +| ------ | ------------------------------------------ | ---------------------------- | +| 第一期 | 知识检索（RAG）+ 基础推荐（DeepSeek API） | 医疗知识库构建完成 | +| 第二期 | 辅诊推荐 + 用药建议 + 医疗审核 | 本地GPU算力就绪或API成本可控 | +| 第三期 | 垂直微调模型 + 区域辅诊监测 + 模型管理平台 | 标注数据积累足够 | + +--- + +## 12. 结论 + +人工智能服务是整个医养平台的"智慧大脑"，其大模型部署、医疗知识图谱、辅诊推荐等核心能力在 mall 中完全缺失，**必须独立建设**。 + +建议初期采用 DeepSeek API 方式快速落地知识检索和基础推荐，待标注数据积累到一定规模后再进行垂直微调和私有化部署，降低初期投入风险。所有AI医疗建议必须设置人工审核环节，确保医疗安全。 diff --git a/23-全生命周期监测平台-模块规划.md b/23-全生命周期监测平台-模块规划.md new file mode 100644 index 0000000..3f35e1f --- /dev/null +++ b/23-全生命周期监测平台-模块规划.md @@ -0,0 +1,213 @@ +# 全生命周期监测平台 模块规划 + +--- + +## 1. 模块定位 + +全生命周期监测平台（以下简称"监测平台"）是以**IoT传感器 + AI分析 + GIS空间定位**为三大技术支柱，面向机构养老、居家养老、社区养老三类场景的**全场景感知与智能响应系统**。 + +监测平台实现对老人生命体征、行动轨迹、生活行为的24小时全方位感知，并通过AI分析引擎对异常数据进行实时识别与智能调度，最终形成"感知→分析→预警→响应→复盘"的完整闭环。 + +--- + +## 2. 建设目标 + +1. 实现老人定位（室内+室外）及空间资源（床位/房间/设备）的统一管理 +2. 实现体征数据（心率/血压/血氧/血糖等）的持续监测与预警 +3. 实现行为分析（活动规律/睡眠质量/跌倒检测）与智能巡检 +4. 实现紧急事件的多级智能调度与响应追踪 +5. 提供给家属的实时服务互动与关爱功能 +6. 为运营管理、数据中台提供高质量监测数据资产 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +1. 智能定位与空间管理 +2. 健康监测与预警 +3. 行为分析与智能巡检 +4. 智能调度与响应 +5. 运营管理与质控 +6. 家属服务互动 +7. 系统管理与运维 + +### 3.2 二级模块 + +**智能定位与空间管理**： + +- 实时位置追踪（室内UWB/BLE定位 + 室外GPS） +- 电子围栏管理（自定义危险区域、夜间离床检测） +- 空间档案（床位管理、房间资源、设备位置地图） +- 人员流向与空间热力图分析 + +**健康监测与预警**： + +- 体征数据采集（手环/腕表/床垫传感器等多设备接入） +- 体征基线建立（个体化正常值区间） +- 实时预警（三级告警：提醒/警告/危险） +- 历史体征趋势分析与报告 +- 体征异常AI识别（结合AI服务22号模块） + +**行为分析与智能巡检**： + +- 活动量统计（步数/活跃时间/久坐检测） +- 睡眠质量分析（入睡时间/浅眠/深眠/REM） +- 跌倒智能检测（传感器 + 视频AI双重验证） +- 巡检任务管理（护理人员GPS打卡 + 任务清单） +- 巡检记录与异常上报 + +**智能调度与响应**： + +- SOS紧急呼叫（一键求救 + 自动定位） +- 多级调度规则（就近护理员→值班护士→急救系统） +- 响应计时与追踪 +- 事件处置闭环（处置记录 + 回访 + 总结） +- 对接120急救系统（⚠️ 待确认接口标准） + +**运营管理与质控**： + +- 护理服务质量指标看板 +- 巡检完成率、响应及时率等KPI统计 +- 老人满意度采集 +- 规范化服务流程审核 + +**家属服务互动**： + +- 家属APP/小程序（老人实时状态查看） +- 关爱视频通话（⚠️ 须协调隐私保护规则） +- 健康报告推送（周报/月报自动生成） +- 服务记录可视化（家属端查看护理记录） + +**系统管理与运维**： + +- 设备管理（设备注册/激活/更换/批量OTA升级） +- 账号权限管理（机构管理员/护理人员/家属多角色） +- 系统集成配置（与IoT平台16号模块接口对接） +- 异常日志与运维告警 + +### 3.3 核心功能矩阵 + +| 功能模块 | 技术支柱 | 关键指标 | +| -------- | --------------------- | -------------- | +| 室内定位 | UWB/BLE/RFID | 定位精度≤1m | +| 跌倒检测 | 加速度传感器 + 视频AI | 检测准确率≥95% | +| SOS响应 | 一键呼叫 + 调度 | 响应时长≤30秒 | +| 体征预警 | IoT + 规则引擎 | 预警延迟≤5秒 | +| 家属告知 | 推送 + APP | 及时通知率100% | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +| 能力需求 | mall 现状 | 结论 | +| --------------------------- | --------- | ---------- | +| IoT设备接入与数据采集 | 无 | 须独立建设 | +| 定位引擎（UWB/BLE/GPS融合） | 无 | 须独立建设 | +| 实时体征监测流处理 | 无 | 须独立建设 | +| AI行为分析（跌倒/睡眠） | 无 | 须独立建设 | +| 多级调度与响应引擎 | 无 | 须独立建设 | + +mall 是通用电商平台，不具备任何IoT感知和实时流处理能力，强行堆入会导致架构崩溃（实时流式数据处理与电商事务型处理的技术栈完全不同）。 + +--- + +## 5. 规划判断 + +**独立系统建设（IoT + AI + GIS综合平台）** + +- **IoT接入层**：通过16号模块（智能物联网管理系统，EMQX Broker）统一接入 +- **数据处理层**：Apache Kafka（实时流）+ TimescaleDB/InfluxDB（时序数据库） +- **AI分析层**：调用22号AI服务模块（跌倒检测/异常识别/行为分析） +- **GIS定位层**：室内用UWB/BLE定位SDK + 室外GPS，地图可视化用高德/百度SDK +- **应用层**：机构管理后台（Vue3）+ 家属小程序（uni-app）+ 护理人员APP + +--- + +## 6. 需新增业务能力 + +1. **室内定位引擎**：UWB硬件部署方案 + BLE信标融合定位算法 +2. **时序数据管理**：体征数据的高频写入、压缩存储、降采样查询 +3. **实时规则引擎**：可配置的体征预警规则，支持个体化阈值设置 +4. **跌倒检测算法**：基于加速度传感器数据的跌倒模型（或采购成熟IoT设备自带算法） +5. **多级调度流程**：可配置的事件升级规则，支持超时自动升级 +6. **视频流处理**：摄像头接入 + 隐私保护（模糊化处理） + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| --------------------- | --------------------------------------------------------------------------------------------------- | +| `elder_location` | id, elder_id, x, y, floor, location_type(indoor/outdoor), device_id, ts(时序主键) | +| `vital_sign_record` | id, elder_id, device_id, metric_type, value, unit, quality, ts | +| `vital_alert` | id, elder_id, alert_level(1/2/3), metric_type, trigger_value, threshold, status, resolved_at | +| `fall_event` | id, elder_id, detected_by, device_id, location, video_clip_url, confirmed, confirmed_by, created_at | +| `inspection_task` | id, elder_id, nurse_id, planned_time, checkin_time, checkin_location, status, items(JSONB) | +| `sos_event` | id, elder_id, trigger_type, location, assigned_nurse_id, response_time_s, resolved_at, summary | +| `space_resource` | id, institution_id, type(bed/room/area), code, floor, polygon_coords(JSONB), status | +| `family_notification` | id, elder_id, family_user_id, event_type, content, push_status, push_at | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ---------- | ------------------------------- | ---------------------- | +| 时序数据库 | TimescaleDB / InfluxDB | 体征数据高频存储与查询 | +| 消息流 | Apache Kafka | 实时体征数据流处理 | +| 室内定位 | 主流UWB设备（海康/大华/移远等） | 室内精确定位 | +| 规则引擎 | Drools / 自定义规则配置 | 可配置体征预警规则 | +| 地图SDK | 高德地图SDK | 室外定位可视化 | +| 实时通信 | WebSocket / MQTT | 前端实时状态推送 | +| 视频流 | GB28181协议 / RTSP | 摄像头视频接入 | + +--- + +## 9. 外部系统对接关系 + +| 对接系统 | 方向 | 内容 | +| ------------------------ | ----------------- | ------------------------------------ | +| 智能物联网管理系统（16） | 依赖 | 设备接入、OTA升级、设备状态管理 | +| 人工智能服务（22） | 依赖 | 跌倒检测、行为异常识别、健康趋势预测 | +| 呼叫中心（06） | 双向 | SOS事件传递、调度联动 | +| 安全系统（09） | 双向 | 围栏报警、安全事件联动 | +| 数据中台（26） | 单向输出 | 监测数据汇入数据湖 | +| 家属端小程序 | 双向 | 健康数据展示、推送通知 | +| 120急救系统 | 单向（⚠️ 待确认） | 危急事件自动通报 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| --------------- | ------------------------------------------ | ----------------------------------------- | +| 隐私保护 | 摄像头+位置追踪涉及个人隐私 | 严格权限管控 + 视频脱敏 + 获取知情同意 | +| 设备成本 | UWB室内定位硬件成本较高 | 低价值区域可用BLE替代（精度降低但成本低） | +| 数据量 | 高频体征数据量极大（秒级采样） | 时序数据库 + 数据降采样策略 | +| 跌倒漏报 | 传感器类跌倒检测存在漏报 | 多设备融合检测（传感器+视频双重验证） | +| 网络依赖 | 断网环境下感知数据无法上传 | 设备本地缓存 + 网络恢复后补传 | +| 边界：监测≠护理 | 本系统提供感知数据，护理操作由护理人员执行 | 清晰划分系统边界，避免功能重复建设 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P2** + +| 分期 | 内容 | 前置条件 | +| ------ | ---------------------------------------------- | ----------------------- | +| 第一期 | 健康监测（体征采集+预警）+ 家属通知 + 基础管理 | IoT物联网平台（16）就绪 | +| 第二期 | 室内定位 + 跌倒检测 + SOS响应调度 | UWB硬件采购安装完成 | +| 第三期 | AI行为分析 + 全场景可视化大屏 + 数据中台对接 | AI服务（22）就绪 | + +--- + +## 12. 结论 + +全生命周期监测平台是医养机构服务品质的核心保障，涉及IoT感知、实时流处理、AI分析和GIS定位等复杂技术栈，mall 完全缺乏这些能力，**必须独立建设**。 + +建议以"健康监测+家属通知"为MVP快速上线，以获得用户信任，再逐步扩展至室内定位、跌倒检测等高价值功能。室内定位设备须优先考虑已具备边缘计算能力的一体化IoT设备，降低软件开发成本。 diff --git a/24-运营管理系统-模块规划.md b/24-运营管理系统-模块规划.md new file mode 100644 index 0000000..3598486 --- /dev/null +++ b/24-运营管理系统-模块规划.md @@ -0,0 +1,235 @@ +# 运营管理系统 模块规划 + +--- + +## 1. 模块定位 + +运营管理系统是面向**平台运营人员、机构管理者和商务人员**的综合运营中枢，承担平台权限管控、服务生命周期管理、数字营销推广、财务分账结算、安全审计和经营决策分析等核心职能。 + +该系统是整个医养平台能够商业化运转的**管理骨干**，直接关系到平台运营效率、合规性和商业可持续性。 + +--- + +## 2. 建设目标 + +1. 建立统一的账号权限中枢，覆盖多机构、多角色、多租户管理 +2. 管理服务产品的全生命周期（上线→运营→下架） +3. 提供多维度数字营销工具（优惠券/补贴/广告位/活动） +4. 构建平台财务分账结算和提现管理体系 +5. 建立完整的安全审计与操作日志体系 +6. 提供关键经营指标的实时看板与决策分析报告 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +1. 权限管理中枢 +2. 服务生命周期管理 +3. 数字化营销工具箱 +4. 财务分账中枢 +5. 安全审计模块 +6. 决策支持与数据分析 +7. 商城运营功能（直播/智能设备/积分拼团等） + +### 3.2 二级功能清单 + +**权限管理中枢**： + +- 超级管理员账号体系（平台级） +- 机构管理员账号体系（机构级多租户） +- 角色权限矩阵（RBAC细粒度权限配置） +- 操作员批量导入/导出 +- 账号安全策略（密码周期/两步验证/IP白名单） + +**服务生命周期管理**： + +- 服务/产品上架审核流程 +- 服务类目管理与价格备案 +- 服务版本管理与历史记录 +- 服务下架工单与善后处理 +- 服务SLA指标配置（响应时效/评分门槛等） + +**数字化营销工具箱**： + +- 优惠券配置（折扣/减满/礼品卡） +- 平台补贴（老人减免/政府补贴联动） +- 广告位管理（Banner/首页推荐/弹窗） +- 活动策划（限时特卖/节日活动/抽奖） +- 积分体系管理（积分规则/兑换商品/有效期） +- 拼团活动管理（成团规则/价格配置） +- 会员等级与权益配置 + +**财务分账中枢**： + +- 订单对账（平台订单与财务账单核对） +- 多方分账规则配置（平台抽成/机构分成/服务商分成） +- 政府补贴资金台账 +- 服务商提现申请与审批 +- 财务报表（日/周/月/年报） +- 税务凭证导出（⚠️ 待确认开票接入方式） + +**安全审计模块**： + +- 全量操作日志（操作人/时间/IP/操作内容） +- 异常登录检测（异地登录/多次失败告警） +- 敏感数据访问审计 +- 合规性自检报告 +- 数据导出审批流程 + +**决策支持与数据分析**： + +- 关键经营指标实时看板（GMV/DAU/服务完成率等） +- 机构运营排行（服务量/评分/投诉率） +- 用户行为漏斗分析 +- 服务商绩效报告 +- 营销活动效果分析 +- 自定义报表导出 + +**商城运营功能（来源于源文档22号系统的商城描述）**： + +- 直播带货管理（主播入驻/场次管理/商品关联） +- 智能AI设备管理（配套设备销售与服务绑定） +- 积分拼团活动（与积分体系联动） +- 秒杀活动管理 +- 新人礼包配置 +- B2B批量采购专区管理 + +### 3.3 核心功能矩阵 + +| 功能模块 | 操作人员 | 业务价值 | +| -------- | -------- | -------------- | +| 权限中枢 | 平台超管 | 安全合规基础 | +| 分账结算 | 财务人员 | 商业模式落地 | +| 营销工具 | 运营人员 | 用户增长与留存 | +| 经营分析 | 管理层 | 决策依据 | +| 安全审计 | 合规人员 | 监管合规 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：B（中度契合，可参考 mall 架构后扩展建设）** + +### mall 可直接参考 / 复用的能力： + +| mall 现有能力 | 对应运营功能 | 参考方式 | +| ---------------- | ---------------- | ---------------------------------- | +| RBAC权限管理 | 权限管理中枢 | 直接参考架构，扩展多租户支持 | +| 优惠券与营销活动 | 数字化营销工具箱 | 参考优惠券数据模型，扩展补贴类型 | +| 商家分账与结算 | 财务分账中枢 | 参考分账逻辑，扩展政府补贴通道 | +| 订单统计报表 | 决策支持看板 | 参考报表结构，扩展医养业务指标 | +| 积分体系 | 积分与会员管理 | 直接复用积分规则引擎，扩展兑换商品 | +| 广告位管理 | 广告位管理 | 直接复用 | +| 直播管理模块 | 直播带货管理 | 直接参考 | + +### 须独立建设的能力（mall 没有）： + +| 医养特有需求 | 说明 | +| ---------------- | -------------------------------------- | +| 多机构多租户管理 | mall 不涉及机构树与多租户隔离 | +| 政府补贴台账 | 政府补贴与医保资金管理，非商业平台概念 | +| 服务SLA管理 | 养老服务有响应时效要求，mall 无此配置 | +| 合规审计报告 | 医养监管需要合规自检，mall 无此模块 | +| 医养类目管理 | 养老服务类目体系与商品类目完全不同 | + +--- + +## 5. 规划判断 + +**B级建设策略：以 mall 运营后台为参考基础，扩展医养特有运营能力** + +- 复用 mall 的权限框架（RBAC）、营销工具（优惠券/积分/广告位）等通用能力 +- 在此基础上扩展：多租户、政府补贴台账、服务生命周期管理、合规审计 +- 建议在业务中台（25号）统一身份基础上构建，避免权限体系重复 + +**技术选型**： + +- 后端：Node.js + PostgreSQL（与 mall 一致的技术栈，降低团队学习成本） +- 前端：Vue3 + Element Plus（PC端管理后台） +- 数据分析：ClickHouse（OLAP查询）+ ECharts（可视化） +- 分账服务：复用 mall 分账逻辑，扩展政府补贴通道 + +--- + +## 6. 需新增业务能力 + +1. **多租户机构管理**：机构树/区域隔离/数据权限边界 +2. **政府补贴资金管理**：补贴类型配置、资金到账确认、补贴发放核销 +3. **服务SLA引擎**：服务类型与响应时效绑定，超时自动预警 +4. **合规审计报告**：可导出的合规自检报告，支持监管查阅 +5. **医养类目管理**：养老服务分类体系（居家/机构/社区/医疗辅助） + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| --------------------- | ------------------------------------------------------------------------------------- | +| `institution` | id, parent_id, name, type, region_code, contract_start, contract_end, status | +| `operation_audit_log` | id, operator_id, module, action, target_id, target_type, ip, request_hash, created_at | +| `govt_subsidy_record` | id, elder_id, subsidy_type, amount, source, apply_at, approved_at, paid_at, status | +| `service_sla_config` | id, service_type, response_time_minutes, escalation_rules(JSONB), updated_by | +| `ad_slot` | id, slot_name, position, institution_id, start_time, end_time, media_url, click_count | +| `settlement_rule` | id, institution_id, platform_rate, merchant_rate, govt_channel, effective_date | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ------------ | ------------------------------------------ | ---------------------- | +| OLAP分析 | ClickHouse | 运营报表高性能聚合查询 | +| 数据可视化 | ECharts / AntV G2 | 经营看板图表 | +| 审计日志存储 | Elasticsearch | 全量操作日志快速检索 | +| 分账服务 | 复用 mall 分账 + 医保专属通道（⚠️ 待确认） | 多方分账与政府补贴 | +| 开票接口 | 百旺/航天信息云开票API（⚠️ 待确认） | 财务发票开具 | + +--- + +## 9. 外部系统对接关系 + +| 对接系统 | 方向 | 内容 | +| ------------------ | ---------------- | ------------------------------ | +| 业务中台（25） | 依赖 | 统一身份与权限底座 | +| 数据中台（26） | 依赖（数据查询） | 经营分析数据来源 | +| 医养商城（19） | 双向 | 商城活动配置/营销投放/财务对账 | +| 服务商管理（11） | 双向 | 服务商分账、绩效看板 | +| 政府监管系统（01） | 单向上报 | 合规数据上报 | +| 短信平台（13） | 调用 | 营销短信、账单通知 | +| 长护险（18） | 双向 | 政府补贴台账联动 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ---------------------------------------- | ------------------------------------ | -------------------------------------------------- | +| 权限设计复杂度 | 多机构+多角色+多租户权限矩阵设计复杂 | 采用成熟RBAC框架，严格数据权限行级过滤 | +| 分账合规 | 多方分账涉及税务和监管要求 | 与财务和法务团队确认分账规则，对接合规开票系统 | +| 政府补贴接入 | 各地政府补贴标准不统一 | 补贴类型/金额参数化配置，支持按区域定制 | +| 数据分析性能 | 运营报表涉及大量聚合查询 | PostgreSQL主库用于事务，ClickHouse用于分析 | +| 边界：本系统管商务运营，不管个人医疗数据 | 避免将老人健康数据直接暴露在运营后台 | 严格数据权限隔离，运营人员无法直接访问老人健康档案 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P0（核心基础，尽早建设）** + +| 分期 | 内容 | 说明 | +| ------ | ------------------------------------------------------- | ------------ | +| 第一期 | 权限中枢 + 服务管理 + 基础财务结算 | 平台上线必备 | +| 第二期 | 营销工具箱 + 经营看板 + 合规审计 | 运营增长必备 | +| 第三期 | 政府补贴台账 + 多维度分析报表 + 直播/拼团等商城扩展功能 | 商业化深化 | + +--- + +## 12. 结论 + +运营管理系统是平台商业化运转的核心骨干，**优先级最高（P0）**。 + +mall 的权限管理、营销工具、分账结算和积分体系可为本模块提供直接参考（B级），可节省约 40% 的开发工作量。但多机构租户、政府补贴、服务SLA、合规审计等医养特有能力须独立扩展建设。 + +建议以 mall 为参考基线，在业务中台（25号）统一身份底座上构建运营管理后台，避免重复建设权限模型。