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号）统一身份底座上构建运营管理后台，避免重复建设权限模型。 diff --git a/契合度/25-业务中台-模块规划.md b/契合度/25-业务中台-模块规划.md new file mode 100644 index 0000000..e265bb4 --- /dev/null +++ b/契合度/25-业务中台-模块规划.md @@ -0,0 +1,210 @@ +# 业务中台 模块规划 + +--- + +## 1. 模块定位 + +业务中台是整个医养平台的**共享业务能力底座**，通过服务化拆分将各业务系统共同依赖的核心能力抽离为独立微服务，对上层各业务系统（居家养老、商城、监管、康复等）提供统一调用接口，实现"能力复用、数据一致、避免烟囱"。 + +业务中台不直接面向终端用户，而是作为**平台级基础设施层**，支撑所有P0/P1业务系统的稳定运行。 + +--- + +## 2. 建设目标 + +1. 建立统一身份中心（用户/员工/机构/老人多主体统一管理） +2. 建立多端接入层（APP、小程序、PC、大屏、IoT设备统一接入） +3. 建立医疗业务中心（分级诊疗、家庭医生签约、服务契约管理） +4. 建立监管调度中心（DRG/DIP规则库、审批流引擎、合规校验） +5. 建立服务资源中心（适老化改造、商保结算网关、服务商结算） +6. 提供统一的消息通知和推送服务 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +1. 用户服务中心 +2. 医疗业务中心 +3. 监管调度中心 +4. 服务资源中心 +5. 消息通知中心 +6. 中台管理与治理 + +### 3.2 二级功能清单 + +**用户服务中心（统一身份）**： + +- 统一账号注册/登录/注销（手机号/微信/人脸等多方式） +- 多角色统一管理（老人/家属/护理员/医生/机构管理员/政府监管人员） +- 多端统一会话管理（微信小程序/APP/H5/PC） +- 账号安全策略（实名认证/设备绑定/异常登录检测） +- 老人档案统一主数据（身份信息/健康基线/家属关系/享受政策） +- 机构档案统一主数据（机构信息/资质证书/床位/签约服务商） + +**医疗业务中心**： + +- 分级诊疗流程（社区首诊→转诊大医院→下转康复） +- 家庭医生签约管理（签约关系/签约服务包/续签/违约处理） +- 服务契约管理（服务协议/服务标准/服务期限/续约提醒） +- 转介管理（机构间老人转接/流程审批/信息随行） +- 病历摘要共享（老人医疗信息跨机构安全访问，⚠️ 需医疗数据授权体系） + +**监管调度中心**： + +- DRG/DIP规则库维护（结合17号医保控费模块） +- 审批流引擎（可配置多级审批，供全平台业务使用） +- 合规预校验（服务上架合规/营销合规/资质有效期校验） +- 服务监督指标（服务完成率/投诉率/整改率联动追踪） + +**服务资源中心**： + +- 适老化改造项目管理（申请→审核→施工→验收，结合15号模块） +- 商保结算网关（对接商业险预授权与理赔结算，⚠️ 待确认商保合作方） +- 服务资源台账（护理员/设备/床位的统一资源登记与调配） +- 服务商结算统一入口 + +**消息通知中心**： + +- 统一消息路由（短信/推送/站内信/微信模板消息） +- 消息模板管理 +- 消息发送日志与状态追踪 +- 优先级队列（紧急预警 > 业务通知 > 营销消息） +- 对接13号短信平台 + +**中台管理与治理**： + +- API网关（统一鉴权/限流/熔断/路由） +- 微服务注册与发现（Nacos/Consul） +- 配置中心（各服务配置统一管理） +- 服务调用链路追踪（SkyWalking/Jaeger） +- 服务健康监控（Prometheus + Grafana） + +### 3.3 能力共享关系 + +| 上层业务系统 | 调用中台能力 | +| -------------- | --------------------------- | +| 居家养老（10） | 统一身份+消息通知+服务契约 | +| 医养商城（19） | 统一身份+消息通知 | +| 运营管理（24） | 统一身份（权限底座）+审批流 | +| 呼叫中心（06） | 统一身份+老人档案（主数据） | +| 健康管理（08） | 统一身份+老人档案+消息通知 | +| 长护险（18） | 监管调度+商保结算网关 | +| 评估系统（07） | 统一身份+老人档案 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +| 能力需求 | mall 现状 | 结论 | +| ------------------------------------- | ---------------------------------- | ---------- | +| 多主体统一身份（老人/医护/机构/政府） | mall 仅有消费者+商家+骑手+客服角色 | 须独立重建 | +| 分级诊疗与签约管理 | 无 | 须独立建设 | +| DRG/DIP规则库与合规校验 | 无 | 须独立建设 | +| 商保结算网关 | 无 | 须独立建设 | +| 微服务治理与API网关 | mall 为单一应用，无中台架构 | 须独立建设 | +| 审批流引擎 | 无 | 须独立建设 | + +mall 是通用电商单体/单角色系统，不具备医养平台所需的多主体、多角色、中台化治理能力，强行堆入会导致数据隔离失控和架构崩溃。 + +--- + +## 5. 规划判断 + +**独立建设（微服务中台架构）** + +- **API网关**：Kong / APISIX（统一鉴权/限流/路由） +- **服务注册与发现**：Nacos +- **消息中间件**：RabbitMQ / Kafka（异步消息解耦） +- **配置中心**：Nacos Config / Apollo +- **数据库**：PostgreSQL（主业务数据）+ Redis（缓存/会话） +- **链路追踪**：SkyWalking +- **容器化**：Docker + Kubernetes（K8s） + +--- + +## 6. 需新增业务能力 + +1. **多主体身份模型**：支持老人/家属/护理员/医生/机构管理员/政府监管6+类角色的统一管理 +2. **同一账号多角色切换**：一个手机号可关联多个角色（如一个人既是家属也是护理员） +3. **数据权限行级隔离**：不同机构的数据严格隔离，不同角色的数据访问范围不同 +4. **可视化审批流引擎**：拖拽式审批节点配置，供全平台各业务场景复用 +5. **医疗数据授权与访问控制**：老人授权特定医生访问其病历的细粒度权限控制 + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| ------------------------- | ---------------------------------------------------------------------------------------------------- | +| `unified_user` | id, phone, face_id, wechat_openid, real_name, id_card, roles(array), status | +| `elder_master` | id, user_id, gender, birth_date, address, health_baseline(JSONB), policy_tags(array), institution_id | +| `family_relation` | id, elder_id, family_user_id, relation_type, is_emergency_contact, authorized_access(JSONB) | +| `doctor_patient_contract` | id, doctor_id, elder_id, service_package_id, start_date, end_date, status, renewal_count | +| `approval_workflow` | id, name, nodes(JSONB), applicable_modules(array), version, is_active | +| `approval_instance` | id, workflow_id, apply_user_id, target_id, target_type, current_node, status, created_at | +| `message_record` | id, user_id, channel(sms/push/wechat), template_id, content, status, sent_at | +| `service_resource` | id, type, institution_id, resource_data(JSONB), status, available_from | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ------------ | -------------------- | -------------------- | +| API网关 | Kong / APISIX | 统一鉴权/限流/熔断 | +| 服务注册发现 | Nacos | 微服务治理 | +| 消息中间件 | RabbitMQ | 异步业务解耦 | +| 链路追踪 | SkyWalking | 微服务调用链路分析 | +| 监控 | Prometheus + Grafana | 服务健康监控 | +| 实名认证 | 公安三要素API | 老人/员工实名认证 | +| 人脸识别 | 百度/旷视 人脸SDK | 人脸登录/打卡核验 | +| 容器编排 | Docker + Kubernetes | 微服务部署与弹性伸缩 | + +--- + +## 9. 外部系统对接关系 + +| 对接系统 | 方向 | 内容 | +| ------------------ | ----------------------- | ------------------------ | +| 全平台所有业务系统 | 被调用 | 统一身份/消息/审批流提供 | +| 医保DIP（17） | 依赖 | 合规规则库同步 | +| 短信平台（13） | 调用 | 消息发送路由 | +| 第三方实名认证平台 | 调用（⚠️ 待确认供应商） | 实名核验 | +| 商保合作方 | 调用（⚠️ 待确认） | 预授权与理赔结算接口 | +| 政府监管系统（01） | 单向上报 | 合规数据上报 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ------------------ | ------------------------------ | -------------------------------------------- | +| 中台过度设计 | 过早抽象中台导致开发周期延长 | 先解决P0业务需求，逐步沉淀共性能力到中台 | +| 多角色权限矩阵复杂 | 角色多、权限细粒度设计复杂 | 采用成熟RBAC+ABAC框架，严格评审行级权限规则 | +| 数据隔离合规 | 多机构数据隔离是监管要求 | 行级安全（RLS）+ 租户ID过滤强制执行 | +| 医疗数据访问授权 | 老人病历跨机构访问涉及数据伦理 | 明确老人授权同意后才可访问，记录完整访问日志 | +| 商保网关接入复杂 | 各商业险公司接口不统一 | 先对接1-2家主流商保公司，逐步扩展 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P1（P0业务系统的必要前置）** + +| 分期 | 内容 | 说明 | +| ------ | ---------------------------------- | ------------------------- | +| 第一期 | 统一身份+多角色+API网关+消息通知 | P0/P1业务系统上线前须完成 | +| 第二期 | 审批流引擎+医疗业务中心+监管调度 | P1系统建设期间同步构建 | +| 第三期 | 商保结算网关+转介管理+中台治理完善 | P2阶段按需扩展 | + +--- + +## 12. 结论 + +业务中台是整个医养平台的**底层业务基础设施**，mall 不具备医养平台所需的多主体身份、中台化治理、审批流引擎等任何中台能力，**必须独立建设**。 + +业务中台应以"够用即可，避免过度设计"为原则：优先建设统一身份与API网关（所有P0系统都依赖），再随业务发展逐步将共性能力沉淀到中台，切忌一开始就追求完整中台架构导致项目延期。