huangzhenbao/------------
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

上传文件至「/」

Browse Source
This commit is contained in:
huangzhenbao
2026-03-31 01:22:20 +00:00
parent d9a3cdae6d
commit 3678885e30
5 changed files with 975 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

161
20-慢性病管理-模块规划.md Normal file
View File

@@ -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 中完全缺失，**必须独立建设**。
建议第一期先建设不依赖医院资质的功能（慢病档案/用药提醒/随访提醒），快速给老人提供价值；互联网问诊和电子处方依赖资质准备，作为后续阶段叠加。

173
21-中心药房-模块规划.md Normal file
View File

@@ -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药房模块**（如东软医疗、金仕达、卫宁健康等），大幅降低研发风险。处方流转与省阳采对接需提前开展资质申请和接口调研。

193
22-人工智能服务-模块规划.md Normal file
View File

@@ -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医疗建议必须设置人工审核环节，确保医疗安全。

213
23-全生命周期监测平台-模块规划.md Normal file
View File

@@ -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设备，降低软件开发成本。

235
24-运营管理系统-模块规划.md Normal file
View File

@@ -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号）统一身份底座上构建运营管理后台，避免重复建设权限模型。