上传文件至「/」
This commit is contained in:
168
18-长护险与居家服务管理-模块规划.md
Normal file
168
18-长护险与居家服务管理-模块规划.md
Normal 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阶段优先完成**,把握长护险推进带来的政策业务机遇。
|
||||
Reference in New Issue
Block a user