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:19:04 +00:00
parent 5e6b718b82
commit e661853dff
5 changed files with 841 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

161
15-家庭床位及适老化改造系统-模块规划.md Normal file
View File

@@ -0,0 +1,161 @@
# 家庭床位及适老化改造系统 模块规划
---
## 1. 模块定位
家庭床位及适老化改造系统是对接**政府补贴政策**的居家养老基础设施建设管理系统，覆盖家庭养老床位的申请审核、适老化改造项目管理、智能硬件设备安装与管理、上门服务管理以及完工后的监管与数据反馈全生命周期。
本系统是政府"家庭养老床位"补贴项目落地的数字化载体，兼具政策性（审批合规）和服务性（改造施工管理）特征。
---
## 2. 建设目标
1. 实现家庭床位申请→政府审核→签约的在线化流程
2. 管理适老化改造项目（无障碍改造/辅具适配/智能设备安装）的施工进度
3. 提供智能硬件设备的入户安装记录和运营状态管理
4. 构建上门服务管理（改造施工人员的任务派发与执行记录）
5. 支持改造完成后的监管验收和数据分析
---
## 3. 核心功能范围
### 3.1 一级模块
- 家庭床位申请与签约
- 适老化改造管理
- 智能硬件设备管理
- 上门服务管理
- 监管与验收
- 数据分析
### 3.2 二级模块
- **申请与签约**：老人/家属提交申请（住房信息/失能等级）→政府审核→合同签约→补贴确认
- **适老化改造**：改造项目清单（防滑扶手/坡道/加宽门框等）、预算核定、施工队派单
- **硬件设备**：智能设备清单（呼叫器/摄像头/传感器）、安装记录、设备与老人档案绑定
- **上门服务**：施工人员任务分配、进场打卡（GPS+照片）、阶段验收、完工交付
- **监管验收**：政府/机构人员现场验收、照片留存、验收结论、补贴拨付触发
- **数据分析**：改造户数、覆盖率、改造类型分布、设备使用率
### 3.3 核心功能说明
| 功能 | 描述 | 技术要点 |
| ------------ | -------------------------------------------------------- | --------------------------------- |
| 改造项目清单 | 标准化改造项目目录，老人可选择，自动计算补贴金额 | 项目目录 + 补贴单价配置 |
| 施工进度追踪 | 施工人员上传每阶段进度照片，管理员远程查看 | 移动端拍照 + OSS存储 + 进度状态机 |
| 硬件设备绑定 | 设备SN码与老人档案绑定，安装完成后自动接入安全系统（09） | 设备注册API调用 |
| 验收流程 | 竣工照片+验收人员签字→触发补贴核定指令 | 电子签名 + 工作流 |
| 数据看板 | 改造进度、户数统计、资金使用率 | ECharts |
---
## 4. 与现有 mall 的关系
**契合度：C（低契合，部分结构可参考）**
mall 的服务型订单和上门服务概念与本系统有部分相似性：
| 能力 | mall 现状 | 可复用程度 |
| -------------------------- | -------------------- | ---------------------------------- |
| 服务订单状态机 | 有（居家服务参考） | C - 可参考状态流转设计 |
| 上门服务人员（类骑手） | 骑手端GPS打卡+照片 | C - 可参考移动端设计，场景差异大 |
| 审核流程 | 商家入驻审核（基础） | C - 参考意义有限，合同签约逻辑不同 |
| **家庭床位申请（政策性）** | **无** | **须独立建设** |
| **改造项目目录与补贴核算** | **无** | **须独立建设** |
| **IoT设备入户安装** | **无** | **须独立建设** |
| **政府验收与补贴拨付触发** | **无** | **须独立建设** |
**建设路径：mall + 独立微服务（以独立为主，参考 mall 服务订单设计模式）**
---
## 5. 规划判断
**mall + 独立微服务（独立为主）**
- 老人/家属申请端：uni-app（小程序）
- 施工人员端：uni-app（移动端）
- 管理/验收端：Vue3 Web
- 服务端：独立项目管理服务
- 与安全系统（09）和IoT管理（16）通过API对接完成设备注册
---
## 6. 需新增业务能力
1. **家庭床位申请流程**：在线填写住房信息、上传证明材料、等待政府审核
2. **标准改造项目目录**：国家/地方补贴支持的改造项目清单和补贴金额上限
3. **施工人员任务派发**：按地区和技能分配施工任务，移动端接单
4. **多阶段验收机制**：开工照片→中期照片→竣工照片→政府/机构验收
5. **设备入户注册**：安装设备后自动注册到IoT平台，与老人档案绑定
6. **补贴核算与拨付请求**：验收通过后自动生成补贴申请单，流转至审批系统（04）
---
## 7. 需新增数据模型
| 模型 | 关键字段 |
| ------------------------- | -------------------------------------------------------------------------------------------------- |
| `home_bed_application` | id, elder_id, address, house_type, disability_grade, status, approved_at, contract_url |
| `renovation_project` | id, application_id, items(JSONB), total_estimated_cost, subsidy_amount, start_date, end_date |
| `renovation_item_catalog` | id, name, category, unit, max_subsidy_per_unit, description |
| `renovation_execution` | id, project_id, worker_id, checkin_time, checkin_photo, phase, phase_photos(array), notes |
| `renovation_acceptance` | id, project_id, acceptor_id, accept_type(gov/platform), accept_date, result, photos, signature_url |
| `iot_device_install` | id, project_id, device_sn, device_type, elder_id, install_at, registered_to_iot_at |
---
## 8. 需新增技术栈 / 第三方能力 / 中间件
| 类别 | 技术选型 | 用途 |
| -------- | ---------------------- | ------------------------ |
| 文件存储 | 阿里云OSS | 施工照片存储 |
| 电子签名 | Canvas签名 / 法大大 | 验收签字 |
| 工作流 | 参考04号模块轻量工作流 | 申请→审核→签约→施工→验收 |
| GIS | 高德地图 | 施工人员打卡定位 |
---
## 9. 外部系统对接关系
| 对接方 | 内容 | 方式 |
| ---------------- | ------------------------------------ | ------------- |
| 审批系统（04） | 家庭床位申请政府审核、验收后补贴申请 | 内部工作流API |
| 数据库系统（02） | 老人档案查询、失能等级核验 | 内部API |
| IoT管理（16） | 安装设备注册到IoT平台 | 内部API |
| 安全系统（09） | 安装设备后与老人绑定，启动监测 | 内部API |
| 政府监管（01） | 改造覆盖率、验收完成率统计 | 内部API |
---
## 10. 风险与边界
| 风险 | 说明 | 应对 |
| ------------------------ | ---------------------------------------------------------------- | ----------------------------------- |
| 补贴政策地区差异 | 各地适老化改造补贴标准不同 | 改造项目目录和补贴金额可按地区配置 |
| 施工质量纠纷 | 改造完工后老人不满意 | 完整照片留存 + 验收签字防止事后争议 |
| 设备安装标准 | 不同品牌设备安装规范不同 | 建立设备安装规范文档 |
| 边界：不含房屋结构性改造 | 只管理适老化改造（辅具/设备/无障碍），不涉及房屋产权和结构性施工 | 明确改造项目范围 |
---
## 11. 实施优先级与分期建议
**优先级：P1（政策窗口期必须抓住）**
| 分期 | 内容 | 前置条件 |
| ------ | ------------------------------------------ | --------------------------------- |
| 第一期 | 家庭床位申请 + 基本改造项目管理 + 施工执行 | 老人档案（02）就绪 |
| 第二期 | 政府验收流程 + 补贴核算 + IoT设备注册 | 审批系统（04）、IoT管理（16）就绪 |
| 第三期 | 数据分析 + 政府监管对接 | — |
---
## 12. 结论
家庭床位及适老化改造系统兼具政策性和服务性，mall 的服务订单框架对本系统有一定参考价值（C级），但改造项目管理、政府审批闭环、IoT设备入户注册等核心医养特性须独立建设。
**建议以独立系统建设为主**，在P1阶段优先完成申请→审核→施工→验收的核心流程，把握政府"家庭养老床位"建设补贴的政策窗口期。

161
16-智能物联网管理系统-模块规划.md Normal file
View File

@@ -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 紧急响应的核心安全功能。

166
17-医保DIP智能控费-模块规划.md Normal file
View File

@@ -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 中完全缺失，**必须作为独立系统建设**。
鉴于专业门槛高、规则更新频繁、各省差异显著，**强烈建议评估采购成熟的医保控费产品**（国内头部厂商）而非全自研，平台侧主要负责集成接口和数据展示，以降低研发风险和维护成本。

168
18-长护险与居家服务管理-模块规划.md Normal file
View File

@@ -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阶段优先完成**，把握长护险推进带来的政策业务机遇。

185
19-医养商城-模块规划.md Normal file
View File

@@ -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 平台的医养化改造路径，为后续模块建设积累经验。