From 2181b01ab65406df7fd2d6959002043c99c8e515 Mon Sep 17 00:00:00 2001 From: huangzhenbao <17818024429@163.com> Date: Tue, 31 Mar 2026 01:28:07 +0000 Subject: [PATCH] =?UTF-8?q?=E4=B8=8A=E4=BC=A0=E6=96=87=E4=BB=B6=E8=87=B3?= =?UTF-8?q?=E3=80=8C=E5=A5=91=E5=90=88=E5=BA=A6=E3=80=8D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 契合度/16-智能物联网管理系统-模块规划.md | 161 ++++++++++++++++++ 契合度/17-医保DIP智能控费-模块规划.md | 166 ++++++++++++++++++ 契合度/18-长护险与居家服务管理-模块规划.md | 168 +++++++++++++++++++ 契合度/19-医养商城-模块规划.md | 185 +++++++++++++++++++++ 契合度/20-慢性病管理-模块规划.md | 161 ++++++++++++++++++ 5 files changed, 841 insertions(+) create mode 100644 契合度/16-智能物联网管理系统-模块规划.md create mode 100644 契合度/17-医保DIP智能控费-模块规划.md create mode 100644 契合度/18-长护险与居家服务管理-模块规划.md create mode 100644 契合度/19-医养商城-模块规划.md create mode 100644 契合度/20-慢性病管理-模块规划.md diff --git a/契合度/16-智能物联网管理系统-模块规划.md b/契合度/16-智能物联网管理系统-模块规划.md new file mode 100644 index 0000000..a3a84b9 --- /dev/null +++ b/契合度/16-智能物联网管理系统-模块规划.md @@ -0,0 +1,161 @@ +# 智能物联网管理系统 模块规划 + +--- + +## 1. 模块定位 + +智能物联网管理系统是整个智慧医养平台的 **IoT 设备基础设施管理层**，负责对全平台所有智能终端设备（智能呼叫终端、定位终端、健康监测设备、跌倒监测设备）进行统一注册、状态监控、数据接入、固件管理和告警处理。 + +本系统是底层技术中间件，不直接对终端用户提供功能界面，而是为安全系统（09）、健康管理（08）、家庭床位（15）等上层业务模块提供设备能力支撑。 + +--- + +## 2. 建设目标 + +1. 构建统一的 IoT 设备注册和台账管理体系，支持 4 类主要设备类型 +2. 实现设备状态实时监控（在线/离线/低电量/故障） +3. 提供标准化的设备数据接入协议（MQTT/HTTP双模） +4. 支持批量设备管理（固件远程升级、批量配置下发） +5. 建立设备告警处理闭环（设备告警→业务系统→调度→处置） + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 设备注册与台账 +- 设备状态监控 +- 数据接入层（MQTT/HTTP） +- 设备分组管理 +- 固件管理 +- 告警管理 +- 数据API（供上层业务调用） + +### 3.2 二级模块 + +- **设备注册**：4类设备（呼叫终端/定位终端/健康监测/跌倒监测）注册、SN码绑定老人 +- **状态监控**：实时在线率、最近心跳时间、电量、信号强度、异常设备清单 +- **MQTT接入**：设备端MQTT连接、Topic规范（设备状态/数据上报/指令下发） +- **设备分组**：按机构/区域/设备类型分组，支持批量操作 +- **固件管理**：新固件包上传、兼容性校验、批量或定向远程升级 +- **告警管理**：设备离线告警、低电量预警、故障上报、告警转业务系统 +- **数据API**：历史数据查询、实时状态查询、设备列表过滤 + +### 3.3 核心功能说明 + +| 设备类型 | 主要功能 | 数据上报频率 | 告警触发条件 | +| ------------ | --------------------- | -------------- | ------------------- | +| 智能呼叫终端 | SOS按键、通话 | 心跳1次/5分钟 | SOS触发/离线>30分钟 | +| 定位终端 | GPS/LBS定位、运动轨迹 | 定位1次/5分钟 | 离开围栏/低电<20% | +| 健康监测 | 血压/心率/血氧 | 每次测量时 | 指标超阈值 | +| 跌倒监测 | 三轴加速度实时采集 | 跌倒事件触发时 | 跌倒检测阳性 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 是电商平台，完全不具备 IoT 基础设施能力： + +| 能力需求 | mall 现状 | 结论 | +| -------------------------- | --------- | ---------- | +| MQTT Broker（IoT消息接入） | 无 | 须独立建设 | +| 设备注册与台账管理 | 无 | 须独立建设 | +| 设备固件OTA升级 | 无 | 须独立建设 | +| 时序数据存储与查询 | 无 | 须独立建设 | +| 设备状态实时监控仪表盘 | 无 | 须独立建设 | + +mall 是通用电商平台，不具备任何 IoT 设备通信能力，强行堆入会导致架构崩溃。 + +--- + +## 5. 规划判断 + +**独立系统建设（IoT基础设施层）** + +- MQTT Broker：EMQX（开源版或企业版） +- 设备管理平台：后端 Go/Java + Vue3 Web管理端 +- 时序数据库：TimescaleDB（PostgreSQL扩展） +- 规则引擎：EMQX Rule Engine 或 自研告警规则服务 + +--- + +## 6. 需新增业务能力 + +1. **MQTT Broker 部署与配置**：高可用EMQX集群，支持TLS双向认证 +2. **设备接入协议规范**：制定统一的MQTT Topic命名规范和数据格式（JSON Schema） +3. **设备认证体系**：每个设备预烧入证书，防止伪设备接入 +4. **OTA固件升级**：分批次推送固件，支持升级失败自动回滚 +5. **告警路由规则**：按告警类型和严重级别路由到对应业务系统（MQ） +6. **设备可视化地图**：GIS地图展示全部设备的地理分布和状态 + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| ------------------- | ----------------------------------------------------------------------------------------------------------- | +| `iot_device` | id, device_type, device_sn, manufacturer, model, elder_id, org_id, status, firmware_version, last_heartbeat | +| `iot_device_cert` | device_id, cert_pem, private_key_hash, issued_at, expire_at | +| `iot_telemetry` | device_id, metric_type, value, reported_at（时序表） | +| `iot_alert` | id, device_id, alert_type, severity, payload(JSONB), received_at, routed_to, routed_at | +| `iot_firmware` | id, version, device_type, file_url, release_notes, compatible_models(array) | +| `iot_firmware_task` | id, firmware_id, target_device_ids(array), status, progress, started_at | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ----------- | ------------------ | ------------------------------- | +| MQTT Broker | EMQX（开源/企业） | IoT设备消息接入，支持百万级连接 | +| 时序数据库 | TimescaleDB | 设备上报的时序数据存储 | +| 消息队列 | Kafka | 设备告警事件的高吞吐处理 | +| GIS | 高德地图API | 设备分布地图 | +| OTA | 自研 + OSS文件存储 | 固件文件存储与下发 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 方式 | +| ------------------ | -------------------------- | ------------- | +| 安全系统（09） | SOS/跌倒/定位数据输出 | Kafka消息消费 | +| 健康管理（08） | 健康监测数据输出 | Kafka消息消费 | +| 家庭床位（15） | 入户设备注册 | 内部注册API | +| 政府监管（01） | 设备在线率统计 | 内部统计API | +| 系统管理中心（05） | 设备接口型号注册（主数据） | 内部API | +| 技术中台（27） | API网关和服务注册 | 内部基础设施 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ------------------ | -------------------------------------------------- | ------------------------------------------ | +| 设备兼容性 | 不同厂商设备通信协议不统一 | 建立设备入网认证标准，要求厂商适配统一协议 | +| 高并发数据写入 | 大量设备同时上报数据时写入压力大 | 时序数据库 + 写入缓冲队列（Kafka） | +| MQTT安全 | 设备证书管理不当可能导致非授权接入 | TLS双向认证 + 设备证书轮换策略 | +| 边界：不含设备采购 | 本系统只负责软件接入管理，不负责设备硬件选型和采购 | 明确边界，由运营方制定设备白名单 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P2（但需在P1阶段完成基础框架，支撑安全系统SOS功能）** + +| 分期 | 内容 | 前置条件 | +| -------- | ------------------------------------------------------ | ---------------- | +| P1配合 | MQTT Broker部署 + SOS设备接入（支撑呼叫中心+安全系统） | 基础设施部署完成 | +| P2第一期 | 设备注册台账 + 状态监控 + 告警路由 | — | +| P2第二期 | OTA固件升级 + 设备地图 + 时序数据查询API | — | + +--- + +## 12. 结论 + +智能物联网管理系统是全平台 IoT 能力的基础设施层，mall 完全不具备此类能力，**必须独立建设**。 + +建议采用 EMQX 开源版本起步，视设备规模决定是否升级为企业版。MQTT Broker 的部署应在 P1 阶段与安全系统（09）同步完成，以支撑 SOS 紧急响应的核心安全功能。 diff --git a/契合度/17-医保DIP智能控费-模块规划.md b/契合度/17-医保DIP智能控费-模块规划.md new file mode 100644 index 0000000..a4c8e6e --- /dev/null +++ b/契合度/17-医保DIP智能控费-模块规划.md @@ -0,0 +1,166 @@ +# 医保DIP智能控费 模块规划 + +--- + +## 1. 模块定位 + +医保DIP智能控费系统是面向**医疗机构和医保管理人员**的医保费用智能管控平台，基于按病种分值付费（DIP）和疾病诊断相关组（DRG）规则，实现医保编码智能辅助、入院前费用预测、住院中实时控费预警和出院结算审核。 + +本系统属于**医疗信息化（HIS/医保）** 专业领域，是高度垂直的医保费用管理系统，与养老服务主业存在领域差异，但与养老机构（提供医疗服务的）的医保结算存在关联。 + +--- + +## 2. 建设目标 + +1. 实现医保智能编码辅助（ICD-10疾病编码、手术操作编码） +2. 提供病例DRG/DIP分组自动判定，减少编码错误和拒付风险 +3. 构建住院费用实时监控，超出分值预警并给出控费建议 +4. 支持出院结算审核（自动校验编码与费用的匹配度） +5. 提供医保费用分析报表（科室/病种/医生维度） + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 医保智能编码 +- 医保智能审核 +- DRG/DIP智能管理 + +### 3.2 二级模块 + +- **医保智能编码**： + - 主诊断编码辅助（ICD-10，41个子功能） + - 手术操作编码辅助 + - 编码知识库维护 + - 编码错误校验 +- **医保智能审核**（77个子功能）： + - 入院指征审核 + - 用药合理性审核（超适应症/超量） + - 耗材合规审核 + - 诊疗行为监控 +- **DRG/DIP智能管理**（77个子功能）： + - 病例DRG自动分组 + - DIP分值计算 + - 分组异常预警 + - 费用超支预测与控制建议 + - 科室DIP点数分析 + - 医保基金使用率仪表盘 + +### 3.3 核心功能说明 + +| 功能 | 描述 | 专业要求 | +| -------------- | --------------------------------------------------- | --------------------------- | +| ICD-10编码辅助 | 医生输入疾病名称→智能匹配ICD-10编码，提示高风险编码 | 国家医保局ICD-10规则库 | +| DRG自动分组 | 根据主诊断+手术操作+并发症自动判定DRG分组 | 国家DRG分组规则（CHS-DRG） | +| DIP分值计算 | 病种+均次费用→计算DIP分值，与医保支付额比对 | 各省DIP分值表（地区差异大） | +| 费用实时监控 | 住院中实时预测最终费用是否超出DRG上限 | 费用预测模型 | +| 审核规则库 | 内置超5000条医保合规规则（诊疗+用药+耗材） | 持续更新国家/地方医保政策 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 是通用电商平台，不具备任何医保相关能力： + +| 能力需求 | mall 现状 | 结论 | +| ------------------ | --------- | ---------- | +| ICD-10医疗编码体系 | 无 | 须独立建设 | +| DRG/DIP分组算法 | 无 | 须独立建设 | +| 医保合规规则引擎 | 无 | 须独立建设 | +| HIS系统集成 | 无 | 须独立建设 | +| 医保费用分析 | 无 | 须独立建设 | + +mall 是通用电商平台，不具备医保编码/DRG分组等专业医疗信息化能力，强行堆入会导致数据合规失控。 + +--- + +## 5. 规划判断 + +**独立系统建设（专项医疗信息化系统）** + +- 系统性质：高度专业的医疗信息化系统，通常需要专业医疗IT厂商参与 +- 集成方式：可考虑采购成熟的DRG/DIP控费产品（如嘉和美康、海虹医保等），而非全自研 +- 与养老平台关系：通过API对接，养老机构的医疗服务数据输入本系统 + +--- + +## 6. 需新增业务能力 + +1. **ICD-10编码知识库**：国家医保局官方编码库（41880+编码条目） +2. **DRG/DIP规则引擎**：全国版DRG规则 + 各省DIP分值表（⚠️ 地区差异大，需分省配置） +3. **医保合规规则库**：5000+条诊疗/用药/耗材医保合规规则，持续更新 +4. **HIS数据集成接口**：从养老机构HIS系统获取就诊数据（HL7 FHIR标准） +5. **费用预测模型**：基于历史数据训练的住院费用预测 +6. **实时预警推送**：费用超预警时推送给主治医生/财务 + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| ------------------------ | --------------------------------------------------------------------------------------------- | +| `icd10_code` | code, name, category, effective_date, is_medical_insurance_covered | +| `drg_group_rule` | id, version, conditions(JSONB), drg_code, base_payment | +| `dip_score_table` | province_code, disease_code, score, effective_year | +| `admission_case` | id, patient_id, org_id, admit_date, discharge_date, main_diagnose_code, drg_group, total_cost | +| `insurance_audit_record` | id, case_id, rule_id, hit_type, description, risk_level, suggested_action | +| `cost_alert` | id, case_id, alert_type, threshold, actual_cost, predicted_cost, alerted_at | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ---------- | ---------------------------------- | -------------------------------- | +| 医疗互操作 | HL7 FHIR R4协议 | 与HIS系统数据交换 | +| 规则引擎 | Drools / 自研规则引擎 | 医保合规规则执行 | +| NLP | 医疗NLP（自研或第三方） | 疾病名称→ICD-10编码智能匹配 | +| 数据仓库 | ClickHouse | 医保费用分析报表（大数据量OLAP） | +| 医保数据 | 各省医保局API（⚠️ 待确认接入条件） | 实时分值获取和结算 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 说明 | +| ----------------- | ------------------------- | ------------------------------- | +| 养老机构HIS系统 | 电子病历、医嘱、费用数据 | HL7 FHIR接口 | +| 国家/省医保局系统 | DRG/DIP分值查询、结算提交 | ⚠️ 待确认各省接口规范和接入条件 | +| 中心药房（21） | 药品费用数据 | 内部API | +| 数据中台（26） | 医保费用数据汇入 | 内部数据管道 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ------------------------ | ---------------------------------------------------- | ---------------------------------- | +| 各省DIP规则差异 | DIP分值表和规则每省不同，且每年更新 | 规则可配置，建立规则版本管理机制 | +| 医保接口准入门槛 | 需经过医保局系统对接资质认证 | ⚠️ 提前了解各省医保局接入要求 | +| 数据合规（病历数据） | 医疗数据属于最高级别隐私数据 | 等保三级、国密加密、数据不出境 | +| 专业性门槛高 | DRG/DIP业务逻辑需要医保专业人员参与 | 建议与专业医保IT厂商合作，非全自研 | +| 边界：不含医保结算资金流 | 本系统处理规则和预警，实际资金划拨由医保经办机构完成 | 输出结算建议，不直接操作资金 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P2** + +| 分期 | 内容 | 前置条件 | +| ------ | ------------------------------ | ----------------------------- | +| 第一期 | 编码辅助 + 基础DRG分组 | HIS系统确认、医保接口条件确认 | +| 第二期 | 实时费用监控 + 合规审核规则库 | — | +| 第三期 | DIP智能控费 + 医保费用分析报表 | — | + +--- + +## 12. 结论 + +医保DIP智能控费是高度专业的医疗信息化系统，其ICD-10编码体系、DRG/DIP规则引擎、医保合规规则库等核心能力在 mall 中完全缺失，**必须作为独立系统建设**。 + +鉴于专业门槛高、规则更新频繁、各省差异显著，**强烈建议评估采购成熟的医保控费产品**（国内头部厂商）而非全自研，平台侧主要负责集成接口和数据展示，以降低研发风险和维护成本。 diff --git a/契合度/18-长护险与居家服务管理-模块规划.md b/契合度/18-长护险与居家服务管理-模块规划.md new file mode 100644 index 0000000..676936e --- /dev/null +++ b/契合度/18-长护险与居家服务管理-模块规划.md @@ -0,0 +1,168 @@ +# 长护险与居家服务管理 模块规划 + +--- + +## 1. 模块定位 + +长护险与居家服务管理系统是对接**长期护理保险（长护险）政策**的服务履约与结算管理系统，覆盖长护险资格申请评估、服务计划制定与派单、上门服务执行（GPS签到+人脸/电子签名+照片留存）、服务记录审核、医保经办机构结算对账，以及可选的 AI 辅助服务规划。 + +本系统是平台与医保基金直接挂钩的高价值业务通道，服务质量直接影响医保结算资金回款。 + +--- + +## 2. 建设目标 + +1. 实现长护险参保资格核查与失能等级评估（对接07号评估系统） +2. 构建符合医保合规要求的服务计划制定和派单体系 +3. 提供服务执行的三要素留证：GPS定位 + 人脸识别/电子签名 + 照片 +4. 实现服务完成后的结算清单生成与医保经办机构对账 +5. 支持 AI 辅助服务方案推荐（可选，基于老人评估数据） + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 申请评估管理 +- 服务计划制定与派单 +- 服务执行监管 +- 结算对账 +- AI服务集成（可选） +- 居家服务管理 + +### 3.2 二级模块 + +- **申请评估**：参保资格核查、失能等级认定（来自07评估）、护理等级核定（轻/中/重） +- **服务计划**：按护理等级配置服务项目（国家规定的长护险服务包）、月度小时数上限 +- **派单**：按服务计划派单给服务商/护理员，支持长期定期派单 +- **服务执行**：护理员上门 GPS 打卡→开始计时→人脸识别老人→执行服务→老人签字→照片→提交 +- **审核**：机构/医保经办审核服务记录（照片/签名/GPS轨迹） +- **结算对账**：月度服务工时汇总、应付金额计算、医保经办机构结算清单生成、差异处理 +- **AI辅助**：基于评估数据智能推荐服务方案（⚠️ 待确认AI能力建设时间点） +- **居家服务管理**：非长护险服务（自费/政府补贴）的同平台统一管理 + +### 3.3 核心功能说明 + +| 功能 | 描述 | 合规要求 | +| ------------ | ---------------------------------------------------- | ------------------------- | +| GPS定位签到 | 护理员必须到达老人家200m范围内才可打卡开始 | 医保稽查要求 | +| 人脸识别确认 | 服务完成后对老人进行人脸识别，确认本人在场 | 防止"挂空单" | +| 电子签名 | 老人/家属在手机或PAD上手写签字确认服务完成 | 合规留证 | +| 照片留存 | 每次服务至少拍3张照片（开始/过程/结束）附时间水印 | 医保稽查留证要求 | +| 月度结算清单 | 每月月末生成服务工时汇总，对应护理费用，提交医保经办 | 长护险结算规范 | +| 服务包配置 | 按各省长护险政策配置服务项目目录和每次时长标准 | ⚠️ 各省政策差异，需可配置 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：C（低契合，服务型订单框架可参考）** + +mall 的服务型订单框架（预约→分配→执行→确认→结算）与本系统在整体流程上有一定相似性： + +| 能力 | mall 现状 | 可复用程度 | +| ------------------------ | ------------- | ---------------------------------------- | +| 服务订单状态机 | 有（C级参考） | 可参考状态流转 | +| 服务人员GPS打卡 | 骑手端有 | C - 可参考移动端交互框架 | +| 支付结算 | 有（C/B级） | 长护险是医保结算非消费支付，逻辑完全不同 | +| **长护险资格核查** | **无** | **须独立建设** | +| **医保服务包配置** | **无** | **须独立建设** | +| **人脸识别老人身份** | **无** | **须独立建设** | +| **医保经办机构结算接口** | **无** | **须独立建设** | +| **三要素留证体系** | **无** | **须独立建设** | + +**建设路径：mall + 独立微服务（以独立为主，参考 mall 服务订单框架）** + +--- + +## 5. 规划判断 + +**mall + 独立微服务（以独立为主）** + +- 护理员执行端：uni-app（GPS+人脸+签名+拍照，独立应用） +- 老人/家属端：uni-app（查看服务记录、电子签名） +- 机构管理端：Vue3 Web（派单+审核+对账） +- 结算对接：⚠️ 需对接各省医保经办机构结算API，接口规范待确认 + +--- + +## 6. 需新增业务能力 + +1. **长护险参保资格核查**：接入医保系统查询老人参保状态（⚠️ 待确认接口） +2. **服务包规则引擎**：按护理等级和省份配置服务项目、每次时长、月度上限 +3. **三要素留证引擎**：GPS + 人脸识别 + 签名三要素同时验证，缺一不可提交 +4. **服务记录防篡改**：留证数据加密存储（可选区块链存证） +5. **月度批量结算**：按月汇总工时、生成符合各省医保规范的结算清单格式 +6. **结算差异处理**：医保核减后的差异原因分析、重审申请 + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| --------------------------- | --------------------------------------------------------------------------------------------------------------- | +| `ltc_insurance_eligibility` | elder_id, insured_no, nursing_grade, start_date, end_date, monthly_hours_limit | +| `ltc_service_plan` | id, elder_id, nursing_grade, items(JSONB), monthly_hours, plan_period | +| `ltc_service_order` | id, plan_id, elder_id, staff_id, scheduled_at, service_type, duration_min, status | +| `ltc_execution_record` | id, order_id, checkin_gps, checkin_time, face_verify_result, photos(array), signature_url, checkout_time, notes | +| `ltc_monthly_settlement` | id, org_id, period_month, total_orders, total_minutes, amount_claimed, amount_approved, status | +| `ltc_settlement_item` | settlement_id, order_id, service_type, minutes, unit_price, claimed_amount, approved_amount, reject_reason | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| -------------- | ----------------------------------- | -------------------- | +| 人脸识别 | 腾讯云人脸识别 / 百度人脸 | 服务完成老人身份确认 | +| 定位 | 高德SDK + 地理围栏 | 护理员到场验证 | +| 电子签名 | Canvas手写签名 | 老人确认签字 | +| 区块链（可选） | 蚂蚁链/腾讯TBaaS | 服务记录存证防篡改 | +| 医保对接 | 各省医保经办机构API（⚠️ 待确认SDK） | 结算清单提交 | +| 加密存储 | 国密SM4 | 留证数据加密 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 说明 | +| ------------------ | ------------------------------------------ | ----------------- | +| 评估系统（07） | 失能等级→护理等级认定依据 | 内部API（只读） | +| 医保系统 | 参保资格查询 + 月度结算清单提交 | ⚠️ 待确认各省接口 | +| 服务商管理（11） | 护理员来源、技能资质 | 内部API | +| 居家养老管理（10） | 服务订单共享（长护险派单在10的框架下执行） | 内部API | +| 短信平台（13） | 服务确认短信（老人/家属） | 内部API调用 | +| 数据中台（26） | 结算数据归集用于分析 | 内部数据管道 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| -------------------------- | ---------------------------------------- | -------------------------------------- | +| 各省长护险规则差异 | 服务包项目、报销比例、每月上限均不同 | 服务包规则全部可配置化，不硬编码 | +| 医保接口准入 | 需经医保局系统对接备案 | ⚠️ 提前规划准入申请 | +| 稽查留证要求 | 医保稽查对留证格式有规范要求 | 严格按当地医保规范设计留证格式 | +| 三要素误识别 | 人脸识别失败导致服务无法提交 | 保留手动上报备用通道（但需更严格审核） | +| 边界：不含医保保险公司管理 | 本系统负责服务履约侧，不管理医保基金收付 | 清单提交后由医保经办机构处理 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P1（高商业价值，政策驱动）** + +| 分期 | 内容 | 前置条件 | +| ------ | ---------------------------------------------------- | ---------------------------- | +| 第一期 | 服务计划派单 + 护理员执行（GPS+照片+签名）+ 月度汇总 | 评估（07）、服务商（11）就绪 | +| 第二期 | 人脸识别留证 + 结算清单对接医保 | 人脸服务申请、医保接口确认 | +| 第三期 | AI服务规划推荐 + 区块链存证 | AI能力就绪 | + +--- + +## 12. 结论 + +长护险与居家服务管理是平台与医保基金直接挂钩的核心业务，三要素留证合规（GPS+人脸+签名）和医保结算接口是本系统成功的关键。 + +mall 的服务订单框架有一定参考价值（C级），但长护险合规留证、医保服务包规则引擎、医保经办结算对接等核心能力须独立建设。**建议在P1阶段优先完成**，把握长护险推进带来的政策业务机遇。 diff --git a/契合度/19-医养商城-模块规划.md b/契合度/19-医养商城-模块规划.md new file mode 100644 index 0000000..7638350 --- /dev/null +++ b/契合度/19-医养商城-模块规划.md @@ -0,0 +1,185 @@ +# 医养商城 模块规划 + +--- + +## 1. 模块定位 + +医养商城是整个智慧医养平台中**与 mall 契合度最高（A级）的模块**，面向老人、家属及机构提供医疗养老相关商品和服务的 B2C/B2B 电商平台，涵盖商品销售（医疗器械/保健品/辅具/适老化用品）、服务类商品（上门护理/到家就诊）、IoT 设备租赁、直播带货等 420+ 功能细项。 + +mall 的核心电商能力（商品管理/订单/支付/物流/营销/商家入驻）可以直接在此场景复用，但需识别出"写在医养商城章节但本质属于其他系统（HIS/IoT/EMR）的功能"，这些功能须独立建设，不可堆入 mall。 + +--- + +## 2. 建设目标 + +1. 基于 mall 平台快速构建医养垂直电商能力，覆盖实物商品和服务商品 +2. 接入多品类服务商（医疗器械/保健品/适老化/康复辅具），实现多商家入驻 +3. 提供 IoT 设备租赁/分期购买能力（呼叫器/血压仪/防跌倒手环等） +4. 落地直播带货能力（老人适用的直播形式） +5. 实现私域流量体系（家庭群/社区群/老人圈互动转化） +6. 打通与其他模块的数据（健康档案→智能推荐，服务评估→服务类商品推荐） + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 商品管理 +- 用户交互 +- 订单管理 +- 物流配送 +- 数据分析 +- 营销推广 +- 客服售后 +- 商家入驻 +- 生态商家对接 +- 私域营销 +- 直播带货 + +### 3.2 二级模块 + +- **商品管理**：商品CRUD、SPU/SKU、分类（医疗器械/保健品/适老化/康复辅具/服务类）、审核、下架、批量导入 +- **用户交互**：搜索/筛选/评价、老年友好界面（大字体/高对比色/语音搜索） +- **订单管理**：下单/付款/发货/收货/退款/客服全链路，含服务类订单（预约制） +- **IoT设备租赁**：设备租期管理、押金、到期续租、设备归还、维修工单 +- **物流配送**：接入快递（快递100聚合）+ mall骑手配送（本地即时配送） +- **营销推广**：优惠券/满减/积分/会员/拼团/闪购/推荐奖励 +- **客服售后**：在线客服（IM）+ 工单 + 退款仲裁 +- **商家入驻**：资质审核（医疗器械经营许可）+ 商品审核 + 结算分账 +- **生态商家对接**：外部健康服务平台API接入（⚠️ 待确认合作商家） +- **私域营销**：家庭群裂变、家属端分享给子女、社区话题种草 +- **直播带货**：商品链接挂载、直播间下单、直播数据分析 + +### 3.3 核心功能说明 + +**区分关键：mall能力可复用 vs 须独立建设** + +| 功能类型 | 功能 | 归属 | 建设方式 | +| -------- | ---------------------------------- | ----------------------- | ------------------- | +| 真正电商 | 商品管理/SKU/购物车/下单/支付/退款 | mall核心 | **直接复用/小改造** | +| 真正电商 | 商家入驻/结算分账/物流 | mall能力 | **直接复用** | +| 真正电商 | 优惠券/积分/会员/拼团 | mall营销 | **直接复用** | +| 真正电商 | 在线客服/工单 | mall能力 | **直接复用** | +| 垂直扩展 | 医疗器械分类/资质审核（经营许可） | 医养扩展 | mall基础+扩展字段 | +| 垂直扩展 | 服务类商品（预约制订单） | 医养扩展 | mall订单+服务化改造 | +| 垂直扩展 | 老年友好UI/语音搜索 | 前端改造 | uni-app改造 | +| 须独立 | IoT设备租赁管理（租期/押金/归还） | IoT管理（16）+ 商城联动 | 独立租赁服务 | +| 须独立 | 健康档案驱动的智能推荐 | AI服务（22）提供 | 独立AI推荐服务 | +| 须独立 | 直播带货 | 22或独立直播服务 | 独立流媒体服务 | +| 须独立 | 处方流转/药品销售（需资质） | 中心药房（21） | 独立药房系统 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：A（高契合，核心电商功能直接复用）** + +mall 作为本模块的技术底座，可以直接提供以下能力： + +| 能力域 | 可复用内容 | 复用程度 | +| ---------- | -------------------------------- | ------------------------------------ | +| 商品体系 | SPU/SKU/分类/属性/图片/价格/库存 | **A - 直接使用，扩展医养分类字段** | +| 订单全链路 | 下单→支付→发货/预约→完成→退款 | **A - 实物商品直接用，服务类需适配** | +| 支付体系 | 微信支付/支付宝/钱包/积分抵扣 | **A - 直接使用** | +| 物流 | 快递聚合API + 骑手即时配送 | **A - 直接使用** | +| 营销 | 优惠券/积分/活动/拼团/闪购 | **A - 直接使用** | +| 商家入口 | 商家入驻审核/商品管理/账单 | **A - 扩展医疗器械资质字段** | +| 客服 | IM客服/工单/退款 | **A - 直接使用** | +| 推荐 | 基础推荐算法 | B - 需扩展健康数据维度 | + +**补充说明**：mall 中已有直播带货的代码框架，但根据需求文档描述该功能尚未完善，需进一步开发完善。 + +--- + +## 5. 规划判断 + +**mall 内扩展（A级，优先P0推进）** + +- 在 mall 现有代码基础上扩展医养商城 +- 新增：医养商品分类体系、医疗器械资质字段、服务类订单适配、老年友好UI +- 独立建设：IoT设备租赁服务（对接16号模块）、直播带货服务、AI推荐服务 +- **WARNING**：不要将 HIS/EMR/IoT 功能硬塞进 mall 代码，这些在需求文档中写在"医养商城"章节内，但本质上是独立系统 + +--- + +## 6. 需新增业务能力 + +1. **医养商品分类体系**：医疗器械（一/二/三类）/保健品/适老化用品/康复辅具/服务的分类体系 +2. **商家资质扩展**：医疗器械经营许可证号、药品经营许可证（与中心药房21联动） +3. **服务类订单适配**：无库存的预约制服务（上门护理/到家就诊），时间段选择 +4. **老年友好UI**：大字体模式、简化导航、语音搜索（无障碍设计） +5. **IoT设备租赁**：租期（月/季/年）、押金管理、到期提醒、归还处理 +6. **完善直播带货**：商品链接挂载、实时弹幕购物车、回放 + +--- + +## 7. 需新增数据模型（在 mall 基础上扩展） + +| 模型/字段扩展 | 说明 | +| ---------------------------- | -------------------------------------- | +| `product.medical_license_no` | 医疗器械注册证号 | +| `merchant.device_license_no` | 医疗器械经营许可证 | +| `product_category`（扩展） | 新增医养分类树（医疗器械/辅具/服务等） | +| `service_product_schedule` | 服务类商品的可预约时间段配置 | +| `iot_rental_order` | 租赁订单：设备ID/租期/押金/状态 | +| `live_stream_room` | 直播间配置、关联商品、观看数、下单数 | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| -------- | ---------------------------- | ---------------- | +| 直播 | 腾讯云直播（CSS）+ 播放器SDK | 商品直播带货 | +| 语音搜索 | 科大讯飞语音识别 | 老年用户语音输入 | +| 无障碍 | uni-app无障碍API | 老年友好UI | +| 推荐引擎 | 依托22号AI服务模块 | 健康档案驱动推荐 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 方式 | +| ---------------- | ------------------------------ | ------------- | +| IoT管理（16） | 设备租赁关联设备台账 | 内部API | +| 居家养老（10） | 服务类商品预约对接居家服务订单 | 内部API | +| 运营管理（24） | 商城运营数据汇聚 | 内部数据API | +| AI服务（22） | 健康档案驱动个性化推荐 | 内部AI推荐API | +| 中心药房（21） | 处方药品销售（处方流转） | 内部API | +| 数据库系统（02） | 老人身份验证、健康档案关联 | 内部API | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ----------------- | ------------------------------------------------- | ---------------------------------------------- | +| 医疗器械经营合规 | 销售二/三类医疗器械需特定资质 | 平台需获取医疗器械经营许可，或仅作信息撮合平台 | +| 处方药销售合规 | 处方药需处方流转合规 | 对接中心药房（21）的处方流转系统 | +| IoT租赁设备归还 | 设备归还、押金退还、设备检验复杂 | 建立标准化退租流程，与IoT管理联动 | +| 直播内容合规 | 医疗器械直播有严格广告法约束 | 建立商品直播审核机制 | +| 边界：不含HIS系统 | 商城中的诊疗建议/健康评估功能须对接独立的专业系统 | 严格区分电商功能与医疗功能 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P0（最优先推进，mall核心能力直接可用）** + +| 分期 | 内容 | 说明 | +| -------- | ----------------------------------------------------- | ----------------------------- | +| P0第一期 | 医养商品分类 + 商家入驻（医疗器械资质）+ 实物商品销售 | 基于mall直接扩展，2-4周可上线 | +| P0第二期 | 服务类商品预约 + 营销工具 + 客服 | — | +| P1配合 | IoT设备租赁 + 老年友好UI | IoT管理（16）就绪 | +| P1-P2 | 直播带货 + AI推荐 + 私域营销 | 直播技术验证后 | + +--- + +## 12. 结论 + +医养商城是全平台中与 mall **契合度最高的模块（A级）**，mall 的商品管理、订单全链路、支付、物流、营销、商家入驻等核心能力可直接复用，**预计在 mall 基础上2-4周内可完成医养商城MVP版本上线**。 + +关键注意事项：需求文档中"医养商城"章节内包含的部分功能（IoT设备租赁管理、健康档案驱动推荐、直播带货、处方流转）本质上属于其他独立系统，**不应堆入 mall 代码**，而应通过 API 对接方式实现协作。 + +建议立即将医养商城列为P0优先启动项目，以此验证 mall 平台的医养化改造路径，为后续模块建设积累经验。 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 中完全缺失，**必须独立建设**。 + +建议第一期先建设不依赖医院资质的功能（慢病档案/用药提醒/随访提醒），快速给老人提供价值；互联网问诊和电子处方依赖资质准备，作为后续阶段叠加。