comclib
c02029a5f3
- Spring Boot 后端服务 (hss-home-service) - delivery-miniapp 配送小程序 - website 官网 (Nuxt) - docs 架构设计文档 - Docker 容器化部署配置 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
1780 lines
92 KiB
Markdown
1780 lines
92 KiB
Markdown
# 居家上门服务系统 — 服务闭环流程文档
|
||
|
||
> 文档版本：V2.0 工程落地增强版
|
||
> 更新日期：2026-05-15
|
||
> 适用项目：梅州市智慧医养数字赋能平台（一期）
|
||
> 依据文档：《居家上门服务系统详细开发文档（居家子系统）》
|
||
|
||
---
|
||
|
||
## 一、服务闭环总览
|
||
|
||
居家上门服务系统实现的是一条**从需求发起到归档完结**的全链路闭环服务流程，核心思想是：
|
||
|
||
> **每一个服务请求都有始有终、每一步操作都可追溯、每一个异常都有处理、每一笔费用都有结算。**
|
||
|
||
### 1.1 闭环全景图
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────────────┐
|
||
│ 居家上门服务闭环全景 │
|
||
│ │
|
||
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
|
||
│ │ 需求 │──▶│ 评估 │──▶│ 方案 │──▶│ 派单 │──▶│ 执行 │──▶│ 验收 │ │
|
||
│ │ 发起 │ │ 定级 │ │ 制定 │ │ 调度 │ │ 服务 │ │ 反馈 │ │
|
||
│ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ │
|
||
│ │ │ │ │ │ │ │
|
||
│ ▼ ▼ ▼ ▼ ▼ ▼ │
|
||
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
|
||
│ │ 退回 │ │ 异议 │ │ 拒签 │ │ 改派 │ │ 异常 │ │ 问题 │ │
|
||
│ │ 修改 │◀──│ 复核 │◀──│ 异议 │ │ 撤单 │ │ 上报 │ │ 反馈 │ │
|
||
│ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ │
|
||
│ │ │ │ │ │ │
|
||
│ │ └──────────┼─────────────────────┘ │ │
|
||
│ │ ▼ │ │
|
||
│ │ ┌──────────┐ │ │
|
||
│ │ │ 过程监管 │◀───────────────────────────┘ │
|
||
│ │ └──────────┘ │
|
||
│ │ │ │
|
||
│ ▼ ▼ │
|
||
│ ┌──────────────────────────────────────┐ │
|
||
│ │ 结算归档（闭环终点） │ │
|
||
│ └──────────────────────────────────────┘ │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 1.2 闭环七阶段
|
||
|
||
| 阶段 | 名称 | 核心目标 | 关键产出 |
|
||
|------|------|---------|---------|
|
||
| 一 | 需求受理 | 采集服务需求、校验申请资格 | 合格的服务申请单 |
|
||
| 二 | 评估定级 | 评估护理等级与风险等级 | 评估报告（护理等级+风险等级） |
|
||
| 三 | 方案制定 | 编制个性化服务方案 | 已签署的服务方案 |
|
||
| 四 | 派单调度 | 匹配合适的服务人员 | 已派单的工单 |
|
||
| 五 | 上门执行 | 按方案提供上门服务 | 服务执行记录 |
|
||
| 六 | 验收反馈 | 确认服务质量、收集评价 | 验收结果+满意度评价 |
|
||
| 七 | 结算归档 | 费用结算、业务归档 | 结算单+电子台账 |
|
||
|
||
---
|
||
|
||
## 二、各阶段详细流程
|
||
|
||
### 阶段一：需求受理
|
||
|
||
#### 2.1.1 流程图
|
||
|
||
```
|
||
服务对象/家属 系统 受理员
|
||
│ │ │
|
||
│──提交服务申请─────────────▶│ │
|
||
│ │──自动校验──┐ │
|
||
│ │ ▼ │
|
||
│ │ ┌─────────────────┐ │
|
||
│ │ │ 材料完整性校验 │ │
|
||
│ │ │ 资格校验(≥60岁) │ │
|
||
│ │ │ 重复申请校验 │ │
|
||
│ │ └────────┬────────┘ │
|
||
│ │ │ │
|
||
│ │ 校验通过？│ │
|
||
│ │ ┌────┴────┐ │
|
||
│ │ │ │ │
|
||
│ │ ▼ ▼ │
|
||
│ │ 通过 不通过 │
|
||
│ │ │ │ │
|
||
│ │ │ └──退回修改──▶ │
|
||
│ │ │ 受理员退回
|
||
│ │ │ │
|
||
│ │ └──进入待受理池────────▶│
|
||
│ │ │
|
||
│ │◀───────受理通过────────────│
|
||
│ │ │
|
||
│ │──状态变更为"待评估"───┐ │
|
||
│ │ │ │
|
||
│◀──收到受理通知────────────│ │ │
|
||
│ │ ▼ │
|
||
```
|
||
|
||
#### 2.1.2 角色与职责
|
||
|
||
| 角色 | 职责 | 操作端 |
|
||
|------|------|--------|
|
||
| 服务对象/家属 | 通过电话/APP/微信/社区/医院渠道提交服务申请 | 消费者端小程序 |
|
||
| 系统 | 自动校验材料完整性、资格条件、重复申请 | 后端自动执行 |
|
||
| 受理员 | 审核校验结果，确认受理或退回修改 | 管理端PC |
|
||
|
||
#### 2.1.3 状态流转
|
||
|
||
| 当前状态 | 触发条件 | 目标状态 | 说明 |
|
||
|---------|---------|---------|------|
|
||
| — | 提交申请 | 1-待受理 | 申请创建 |
|
||
| 1-待受理 | 受理通过 | 2-待评估 | 进入评估环节 |
|
||
| 1-待受理 | 受理退回 | 7-已退回 | 需修改后重新提交 |
|
||
| 1-待受理 | 主动取消 | 8-已取消 | 服务对象取消 |
|
||
|
||
#### 2.1.4 闭环保障点
|
||
|
||
- **入口闭环**：所有渠道（电话/APP/微信/社区/医院）的申请统一进入系统，不遗漏
|
||
- **校验闭环**：三项自动校验（材料完整性、资格、重复）确保申请质量
|
||
- **通知闭环**：受理结果通过小程序消息通知服务对象
|
||
|
||
---
|
||
|
||
### 阶段二：评估定级
|
||
|
||
#### 2.2.1 流程图
|
||
|
||
```
|
||
受理员 系统 评估员 服务对象/家属
|
||
│ │ │ │
|
||
│──发起评估派发─────────▶│ │ │
|
||
│ │──推荐评估员(算法)──┐ │ │
|
||
│ │ ▼ │ │
|
||
│ │ ┌──────────────┐│ │
|
||
│ │ │ 区域匹配 ││ │
|
||
│ │ │ 技能匹配 ││ │
|
||
│ │ │ 工单量均衡 ││ │
|
||
│ │ └──────┬───────┘│ │
|
||
│ │ │ │ │
|
||
│◀──确认派发─────────────│ │ │ │
|
||
│ │──MQTT推送通知──▶│ │ │
|
||
│ │ │ │ │
|
||
│ │ │──上门评估(签到+评估)──▶│ │
|
||
│ │ │ │ │
|
||
│ │ │◀──对象确认─────────────│ │
|
||
│ │ │ │ │
|
||
│ │◀──提交评估结果──│ │ │
|
||
│ │ │ │ │
|
||
│ │──生成评估报告───┐ │ │
|
||
│ │ │ │ │
|
||
│ │ ┌─────┐ │ │ │
|
||
│ │ │异议？│ │ │ │
|
||
│ │ └──┬──┘ │ │ │
|
||
│ │ 无 │ 有 │ │ │
|
||
│ │ ▼ ▼ │ │ │
|
||
│ │ 进入 异议复核 │ │ │
|
||
│ │ 方案 流程 │ │ │
|
||
│ │ 制定 │ │ │
|
||
│ │ │ │ │
|
||
│ │ ┌──── 异议复核 ────┐ │ │
|
||
│ │ │ │ │ │
|
||
│ │ 维持原结论 修改结论 │ │
|
||
│ │ │ │ │ │
|
||
│ │ ▼ ▼ │ │
|
||
│ │ 进入方案制定 重新评估(回到评估派发) │ │
|
||
```
|
||
|
||
#### 2.2.2 角色与职责
|
||
|
||
| 角色 | 职责 | 操作端 |
|
||
|------|------|--------|
|
||
| 受理员/调度员 | 派发评估任务，选择评估员 | 管理端PC |
|
||
| 系统 | 推荐评估员（区域+技能+工单量匹配） | 后端RPC函数 |
|
||
| 评估员 | 上门评估、GPS签到、录入评估指标、出具报告 | 管理端移动端 |
|
||
| 服务对象/家属 | 确认评估、对结果提出异议 | 消费者端小程序 |
|
||
|
||
#### 2.2.3 状态流转
|
||
|
||
| 当前状态 | 触发条件 | 目标状态 | 说明 |
|
||
|---------|---------|---------|------|
|
||
| 2-待评估 | 派发评估员 | 3-评估中 | 评估任务创建 |
|
||
| 3-评估中 | 评估员签到 | 3-评估中（签到已记录） | GPS 200米内 |
|
||
| 3-评估中 | 提交评估结果 | 6-已通过 | 评估完成 |
|
||
| 3-评估中 | 对结果有异议 | 4-待复核 | 进入异议复核 |
|
||
| 4-待复核 | 复核维持原结论 | 6-已通过 | 进入方案制定 |
|
||
| 4-待复核 | 复核修改结论 | 3-评估中 | 重新评估 |
|
||
|
||
#### 2.2.4 闭环保障点
|
||
|
||
- **签到闭环**：GPS 200米内签到 + 现场拍照，确保评估员真实上门
|
||
- **异议闭环**：服务对象对评估结果有异议可发起复核，复核可修改结论或维持
|
||
- **通知闭环**：评估派发通过MQTT即时通知评估员
|
||
|
||
---
|
||
|
||
### 阶段三：方案制定
|
||
|
||
#### 2.3.1 流程图
|
||
|
||
```
|
||
方案制定员 系统 服务对象/家属
|
||
│ │ │
|
||
│──编制服务方案─────────▶│ │
|
||
│ (引用评估结果) │ │
|
||
│ │ │
|
||
│ ┌──────────────────┐ │ │
|
||
│ │ 选择服务项目 │ │ │
|
||
│ │ 配置服务频次 │ │ │
|
||
│ │ 从模板导入 │ │ │
|
||
│ │ 实时计算金额 │ │ │
|
||
│ └──────────────────┘ │ │
|
||
│ │ │
|
||
│──配置收费与报销───────▶│ │
|
||
│ (长护险抵扣计算) │ │
|
||
│ │ │
|
||
│──提交方案─────────────▶│──推送签署通知───────────────▶│
|
||
│ │ │
|
||
│ │ ┌─── 签署结果 ───┐│
|
||
│ │ │ ││
|
||
│ │ 确认签署 拒签/异议│
|
||
│ │ │ ││
|
||
│ │ ▼ ▼│
|
||
│ │ 方案生效 方案退回修改│
|
||
│ │ │ ││
|
||
│ │ │ ┌────┘│
|
||
│ │ │ │ │
|
||
│ │ │ 重新编制方案│
|
||
│ │ │ (版本号+1) │
|
||
│ │ │ │ │
|
||
│ │ ▼ ▼ │
|
||
│ │ 进入派单调度 │
|
||
```
|
||
|
||
#### 2.3.2 角色与职责
|
||
|
||
| 角色 | 职责 | 操作端 |
|
||
|------|------|--------|
|
||
| 方案制定员 | 编制服务方案、配置收费、管理模板 | 管理端PC |
|
||
| 系统 | 自动引用评估结果、实时计算金额、长护险抵扣 | 后端计算 |
|
||
| 服务对象/家属 | 签署方案或提出异议 | 消费者端小程序 |
|
||
|
||
#### 2.3.3 状态流转
|
||
|
||
| 当前状态 | 触发条件 | 目标状态 | 说明 |
|
||
|---------|---------|---------|------|
|
||
| 1-草稿 | 保存草稿 | 1-草稿 | 可反复修改 |
|
||
| 1-草稿 | 提交签署 | 2-待签署 | 推送签署通知 |
|
||
| 2-待签署 | 对象确认签署 | 3-已生效 | 进入派单 |
|
||
| 2-待签署 | 对象拒签 | 2-已拒签 | 退回修改 |
|
||
| 2-待签署 | 对象提出异议 | 3-异议中 | 重新编制 |
|
||
| 3-异议中 | 重新提交 | 2-待签署 | 版本号+1 |
|
||
|
||
#### 2.3.4 闭环保障点
|
||
|
||
- **评估联动闭环**：方案必须引用评估结果，护理等级决定可选服务项目
|
||
- **费用闭环**：总金额 = Σ(项目单价 × 频次)，自费 = 总金额 - 长护险抵扣，计算透明
|
||
- **签署闭环**：方案必须经服务对象签署确认才生效，拒签可重新编制（版本管理）
|
||
- **逾期闭环**：逾期未签自动提醒，支持批量催签
|
||
|
||
---
|
||
|
||
### 阶段四：派单调度
|
||
|
||
#### 2.4.1 流程图
|
||
|
||
```
|
||
调度员 系统 服务人员
|
||
│ │ │
|
||
│──方案生效生成工单─────▶│ │
|
||
│ │ │
|
||
│──选择派单方式─────────▶│ │
|
||
│ ┌──────────┐ │ │
|
||
│ │ 自动派单 │───────▶│──匹配算法──┐ │
|
||
│ │ 人工派单 │ │ ▼ │
|
||
│ └──────────┘ │ ┌──────────────────┐ │
|
||
│ │ │ 区域匹配(30分) │ │
|
||
│ │ │ 技能匹配(30分) │ │
|
||
│ │ │ 在线状态(20分) │ │
|
||
│ │ │ 工单量均衡(20分) │ │
|
||
│ │ └────────┬─────────┘ │
|
||
│ │ │ │
|
||
│ │ 匹配成功？│ │
|
||
│ │ ┌────┴────┐ │
|
||
│ │ │ │ │
|
||
│ │ ▼ ▼ │
|
||
│ │ 成功 失败 │
|
||
│ │ │ │ │
|
||
│◀──推荐人员列表─────────│ │ 人工调度台 │
|
||
│ │ │ │ │
|
||
│──确认派单─────────────▶│ │ │ │
|
||
│ │──MQTT推送──▶│ │
|
||
│ │ │ │
|
||
│ │ │──接单确认─▶│
|
||
│ │ │ │
|
||
│ │◀────────────│ │
|
||
│ │ │
|
||
│ ── 异常情况 ── │ │
|
||
│ │ │
|
||
│──改派(换人)───────────▶│──通知原人员+新人员──▶│ │
|
||
│──撤单(取消)───────────▶│──通知服务人员──────▶│ │
|
||
```
|
||
|
||
#### 2.4.2 角色与职责
|
||
|
||
| 角色 | 职责 | 操作端 |
|
||
|------|------|--------|
|
||
| 调度员 | 选择派单方式、确认派单、改派、撤单 | 管理端PC |
|
||
| 系统 | 自动匹配算法（区域+技能+状态+工单量） | 后端RPC函数 |
|
||
| 服务人员 | 接收工单通知、确认接单 | 管理端移动端 |
|
||
|
||
#### 2.4.3 状态流转
|
||
|
||
| 当前状态 | 触发条件 | 目标状态 | 说明 |
|
||
|---------|---------|---------|------|
|
||
| 1-待执行 | 确认派单 | 1-待执行（已分配人员） | 推送通知 |
|
||
| 1-待执行 | 改派 | 7-已改派 | 原工单关闭，新工单创建 |
|
||
| 1-待执行 | 撤单 | 6-已取消 | 填写撤单原因 |
|
||
|
||
#### 2.4.4 闭环保障点
|
||
|
||
- **匹配闭环**：自动派单算法四维度打分（区域30+技能30+在线20+工单量20），推荐Top5
|
||
- **冲突闭环**：检测时间冲突，冲突工单明确标注
|
||
- **改派闭环**：改派需填写原因，原人员收到通知，新人员收到派单
|
||
- **调度监控闭环**：实时地图展示人员位置，超时预警，异常工单即时可见
|
||
|
||
---
|
||
|
||
### 阶段五：上门执行
|
||
|
||
#### 2.5.1 流程图
|
||
|
||
```
|
||
服务人员 系统 服务对象
|
||
│ │ │
|
||
│──查看待执行工单───────▶│ │
|
||
│ │ │
|
||
│──导航到服务地址──────────────────────────────────▶│
|
||
│ │ │
|
||
│──GPS签到(200米内)────▶│ │
|
||
│ (拍照+对象确认) │ │
|
||
│ │──状态→已签到───────────▶│
|
||
│ │ │
|
||
│──按项目执行服务───────▶│ │
|
||
│ ┌──────────────┐ │ │
|
||
│ │ 逐项记录完成 │ │ │
|
||
│ │ 拍照/录像/录音│ │ │
|
||
│ │ 上传执行记录 │ │ │
|
||
│ └──────────────┘ │ │
|
||
│ │ │
|
||
│ ── 正常完成 ── │ │
|
||
│ │ │
|
||
│──提交完成─────────────▶│──状态→已完成───────────▶│
|
||
│ │ │
|
||
│ ── 异常情况 ── │ │
|
||
│ │ │
|
||
│──一键上报异常─────────▶│──状态→异常────────────▶│
|
||
│ (对象不在/拒绝/ │ │
|
||
│ 条件不具备/突发) │──MQTT通知调度员───────▶│
|
||
│ │ │
|
||
│ │ ┌── 异常处理 ──┐ │
|
||
│ │ │ │ │
|
||
│ │ 改派他人 协调后继续 │
|
||
│ │ │ │ │
|
||
│ │ ▼ ▼ │
|
||
│ │ 新工单 恢复执行 │
|
||
```
|
||
|
||
#### 2.5.2 角色与职责
|
||
|
||
| 角色 | 职责 | 操作端 |
|
||
|------|------|--------|
|
||
| 服务人员 | 签到、执行服务、记录过程、上报异常 | 管理端移动端 |
|
||
| 系统 | GPS距离校验、轨迹记录、异常通知 | 后端自动执行 |
|
||
| 调度员 | 处理异常工单（改派/协调） | 管理端PC |
|
||
|
||
#### 2.5.3 状态流转
|
||
|
||
| 当前状态 | 触发条件 | 目标状态 | 说明 |
|
||
|---------|---------|---------|------|
|
||
| 1-待执行 | GPS签到 | 2-已签到 | 200米内+拍照 |
|
||
| 2-已签到 | 开始服务 | 3-服务中 | 自动或手动触发 |
|
||
| 3-服务中 | 服务完成 | 4-已完成 | 提交执行记录 |
|
||
| 3-服务中 | 上报异常 | 5-异常 | 通知调度员 |
|
||
|
||
#### 2.5.4 闭环保障点
|
||
|
||
- **签到闭环**：GPS 200米校验 + 现场拍照 + 对象确认，三重验证确保真实到岗
|
||
- **执行闭环**：按项目逐项记录完成情况，图文音视频证据留存
|
||
- **轨迹闭环**：服务期间GPS轨迹实时记录，异常停留点标注
|
||
- **异常闭环**：异常即时上报，MQTT秒级通知调度员，调度员可改派或协调
|
||
|
||
---
|
||
|
||
### 阶段六：过程监管（贯穿执行全程的并行保障）
|
||
|
||
#### 2.6.1 流程图
|
||
|
||
```
|
||
监管员 系统 服务人员
|
||
│ │ │
|
||
│──抽查计划─────────────▶│ │
|
||
│ ┌──────────────┐ │ │
|
||
│ │ 电话抽查 │ │ │
|
||
│ │ 视频抽查 │ │ │
|
||
│ │ 现场抽查 │ │ │
|
||
│ │ GPS轨迹核查 │ │ │
|
||
│ └──────────────┘ │ │
|
||
│ │ │
|
||
│──执行抽查─────────────▶│──调取工单/轨迹数据───▶│ │
|
||
│ │ │ │
|
||
│ ┌── 抽查结果 ──┐ │ │ │
|
||
│ │ │ │ │ │
|
||
│ ▼ ▼ │ │ │
|
||
│ 通过 发现违规 │ │ │
|
||
│ │ │ │ │ │
|
||
│ │ ▼ │ │ │
|
||
│ │ 记录违规──▶│──通知服务人员─────────▶│ │
|
||
│ │ │ │ │ │
|
||
│ │ 发起整改──▶│──跟踪整改进度─────────▶│ │
|
||
│ │ │ │ │ │
|
||
│ │ ┌────┴───┐│ │ │
|
||
│ │ │ ││ │ │
|
||
│ │ 整改通过 整改未通过 │
|
||
│ │ │ ││ │ │
|
||
│ │ ▼ ▼│ │ │
|
||
│ │ 关闭违规 继续整改 │
|
||
│ │ │ │ │ │
|
||
│ ▼ ▼ │ │ │
|
||
│ 记录审计日志─────────▶│ │ │
|
||
│ │ │ │
|
||
│ ── 紧急事件 ── │ │ │
|
||
│ │ │ │
|
||
│──紧急事件处置─────────▶│──即时通知相关责任人───▶│ │
|
||
│ (记录处置过程) │ │ │
|
||
```
|
||
|
||
#### 2.6.2 角色与职责
|
||
|
||
| 角色 | 职责 | 操作端 |
|
||
|------|------|--------|
|
||
| 监管员 | 制定抽查计划、执行抽查、处理违规、跟踪整改 | 管理端PC |
|
||
| 系统 | 自动轨迹核查、违规预警、整改到期提醒 | 后端自动执行 |
|
||
| 服务人员 | 接收违规通知、执行整改 | 管理端移动端 |
|
||
|
||
#### 2.6.3 闭环保障点
|
||
|
||
- **抽查闭环**：四种抽查方式覆盖（电话/视频/现场/GPS），抽查结果记录存档
|
||
- **违规闭环**：违规记录 → 处罚 → 整改 → 复核 → 关闭，全流程可追溯
|
||
- **整改闭环**：整改有截止日期，到期自动提醒，复核不通过继续整改
|
||
- **审计闭环**：所有监管操作记录审计日志，不可篡改
|
||
|
||
---
|
||
|
||
### 阶段七：验收反馈
|
||
|
||
#### 2.7.1 流程图
|
||
|
||
```
|
||
服务对象/家属 系统 调度员/监管员
|
||
│ │ │
|
||
│──收到验收通知─────────▶│ │
|
||
│ │ │
|
||
│ ┌── 验收结果 ──┐ │ │
|
||
│ │ │ │ │
|
||
│ ▼ ▼ │ │
|
||
│ 确认验收 拒绝验收 │ │
|
||
│ │ │ │ │
|
||
│ ▼ ▼ │ │
|
||
│ 满意度评价 填写原因──▶│──通知调度员───────────▶│ │
|
||
│ │ │ │ │
|
||
│ ┌──────────────┐ │ │ │
|
||
│ │ 星级评分(1-5) │ │ │ │
|
||
│ │ 标签评价 │ │ │ │
|
||
│ │ 文字评价 │ │ │ │
|
||
│ │ 图片评价 │ │ │ │
|
||
│ │ 语音评价 │ │ │ │
|
||
│ └──────────────┘ │ │ │
|
||
│ │ │ │
|
||
│──提交评价─────────────▶│──更新服务人员评分───▶│ │
|
||
│ │ │ │
|
||
│ ── 问题反馈 ── │ │ │
|
||
│ │ │ │
|
||
│──登记问题反馈─────────▶│──通知处理人─────────▶│ │
|
||
│ │ │ │
|
||
│ │──跟踪处理进度─────────▶│ │
|
||
│◀──反馈处理结果────────│ │ │
|
||
```
|
||
|
||
#### 2.7.2 角色与职责
|
||
|
||
| 角色 | 职责 | 操作端 |
|
||
|------|------|--------|
|
||
| 服务对象/家属 | 验收确认、满意度评价、问题反馈 | 消费者端小程序 |
|
||
| 系统 | 评分同步更新服务人员平均分 | 后端自动执行 |
|
||
| 调度员/监管员 | 处理验收拒绝、处理问题反馈 | 管理端PC |
|
||
|
||
#### 2.7.3 闭环保障点
|
||
|
||
- **验收闭环**：服务完成必须验收确认，拒绝验收需填写原因并通知调度
|
||
- **评价闭环**：评价数据同步影响服务人员评分，评分影响后续派单优先级
|
||
- **反馈闭环**：问题反馈有处理跟踪，处理结果通知反馈人
|
||
- **适老化闭环**：大按钮评分、标签选择、语音评价，确保老年人可操作
|
||
|
||
---
|
||
|
||
### 阶段八：结算归档（闭环终点）
|
||
|
||
#### 2.8.1 流程图
|
||
|
||
```
|
||
结算员 系统 服务对象
|
||
│ │ │
|
||
│──生成结算单───────────▶│ │
|
||
│ (按周期自动汇总) │ │
|
||
│ │ │
|
||
│ ┌──────────────────┐ │ │
|
||
│ │ 关联方案信息 │ │ │
|
||
│ │ 执行记录汇总 │ │ │
|
||
│ │ 收费项明细 │ │ │
|
||
│ │ 长护险抵扣明细 │ │ │
|
||
│ │ 自费明细 │ │ │
|
||
│ └──────────────────┘ │ │
|
||
│ │ │
|
||
│──结算审核─────────────▶│ │
|
||
│ ┌── 审核结果 ──┐ │ │
|
||
│ │ │ │ │
|
||
│ ▼ ▼ │ │
|
||
│ 审核通过 审核不通过 │ │
|
||
│ │ │ │ │
|
||
│ ▼ ▼ │ │
|
||
│ 确认支付 退回修改──▶│ │
|
||
│ │ │ │
|
||
│ ▼ │ │
|
||
│──支付跟踪────────────▶│──通知服务对象付款───▶│ │
|
||
│ │ │
|
||
│ │◀───────支付完成──────────│ │
|
||
│ │ │
|
||
│──归档台账─────────────▶│ │
|
||
│ ┌──────────────────┐ │ │
|
||
│ │ 选择归档周期 │ │ │
|
||
│ │ 生成归档文件 │ │ │
|
||
│ │ 确认归档 │ │ │
|
||
│ └──────────────────┘ │ │
|
||
│ │ │
|
||
│ │ ★ 服务闭环完成 ★ │
|
||
```
|
||
|
||
#### 2.8.2 角色与职责
|
||
|
||
| 角色 | 职责 | 操作端 |
|
||
|------|------|--------|
|
||
| 结算员 | 生成结算单、审核结算、确认支付、归档台账 | 管理端PC |
|
||
| 系统 | 自动汇总执行记录、计算费用、长护险抵扣 | 后端RPC函数 |
|
||
| 服务对象 | 支付自费部分 | 消费者端小程序 |
|
||
|
||
#### 2.8.3 状态流转
|
||
|
||
| 当前状态 | 触发条件 | 目标状态 | 说明 |
|
||
|---------|---------|---------|------|
|
||
| 1-待结算 | 生成结算单 | 2-待审核 | 自动汇总 |
|
||
| 2-待审核 | 审核通过 | 3-已审核 | 进入支付 |
|
||
| 2-待审核 | 审核不通过 | 1-待结算 | 退回修改 |
|
||
| 3-已审核 | 支付完成 | 4-已支付 | 通知对象 |
|
||
| 4-已支付 | 归档确认 | 5-已归档 | 闭环完成 |
|
||
|
||
#### 2.8.4 闭环保障点
|
||
|
||
- **费用闭环**：结算金额 = 方案总金额 - 长护险抵扣，与方案和执行记录联动
|
||
- **审核闭环**：结算需审核通过才可支付，不通过退回修改
|
||
- **支付闭环**：支付状态实时跟踪，支付完成通知服务对象
|
||
- **归档闭环**：所有业务数据归档为电子台账，永久可查
|
||
|
||
---
|
||
|
||
## 三、闭环反馈机制
|
||
|
||
### 3.1 正向流转（主流程）
|
||
|
||
```
|
||
需求受理 → 评估定级 → 方案制定 → 派单调度 → 上门执行 → 验收反馈 → 结算归档
|
||
```
|
||
|
||
### 3.2 反向反馈（回退机制）
|
||
|
||
| 回退场景 | 回退起点 | 回退终点 | 处理方式 |
|
||
|---------|---------|---------|---------|
|
||
| 申请不合格 | 受理校验 | 需求受理 | 退回修改，重新提交 |
|
||
| 评估异议 | 评估结果 | 重新评估 | 异议复核，可能重新评估 |
|
||
| 方案拒签 | 方案签署 | 方案制定 | 重新编制，版本号+1 |
|
||
| 派单冲突 | 派单结果 | 派单调度 | 改派或人工调度 |
|
||
| 执行异常 | 上门执行 | 派单调度 | 上报异常，调度员处理 |
|
||
| 验收拒绝 | 验收反馈 | 上门执行 | 问题反馈，重新处理 |
|
||
| 结算不通过 | 结算审核 | 结算生成 | 退回修改结算单 |
|
||
|
||
### 3.3 并行监管（贯穿全程）
|
||
|
||
```
|
||
过程监管 ── 抽查 ── 违规处理 ── 整改跟踪 ── 审计日志
|
||
│ │
|
||
└──── 贯穿 阶段四~阶段六 全程 ────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 四、数据闭环验证
|
||
|
||
### 4.1 核心数据流转
|
||
|
||
```
|
||
hss_service_applications (申请单)
|
||
│
|
||
├──▶ hss_evaluation_tasks (评估任务)
|
||
│ │
|
||
│ ├──▶ hss_objections (异议复核) ──可回到── 评估任务
|
||
│ │
|
||
│ └──▶ hss_service_plans (服务方案)
|
||
│ │
|
||
│ ├── 方案签署 ──可回到── 方案编制(版本+1)
|
||
│ │
|
||
│ └──▶ hss_work_orders (工单)
|
||
│ │
|
||
│ ├──▶ hss_spot_checks (抽查) ──▶ hss_violations (违规) ──▶ hss_corrections (整改)
|
||
│ │
|
||
│ └──▶ hss_acceptances (验收评价)
|
||
│ │
|
||
│ └──▶ hss_settlements (结算)
|
||
│ │
|
||
│ └──▶ hss_ledgers (台账归档)
|
||
│
|
||
└── hss_patient_profiles (患者画像) ── 贯穿全程
|
||
```
|
||
|
||
### 4.2 数据完整性校验规则
|
||
|
||
| 校验点 | 校验内容 | 校验时机 |
|
||
|--------|---------|---------|
|
||
| 申请→评估 | 申请状态必须为"待评估" | 派发评估任务时 |
|
||
| 评估→方案 | 必须有已完成的评估报告 | 编制方案时 |
|
||
| 方案→工单 | 方案状态必须为"已生效" | 生成工单时 |
|
||
| 工单→验收 | 工单状态必须为"已完成" | 发起验收时 |
|
||
| 验收→结算 | 必须有验收记录 | 生成结算单时 |
|
||
| 结算→归档 | 结算状态必须为"已支付" | 归档台账时 |
|
||
|
||
---
|
||
|
||
## 五、闭环关键指标
|
||
|
||
### 5.1 流转效率指标
|
||
|
||
| 指标 | 计算方式 | 目标值 |
|
||
|------|---------|--------|
|
||
| 申请受理时效 | 受理时间 - 申请时间 | ≤24小时 |
|
||
| 评估完成时效 | 评估完成时间 - 派发时间 | ≤3个工作日 |
|
||
| 方案签署时效 | 签署时间 - 方案提交时间 | ≤5个工作日 |
|
||
| 派单响应时效 | 接单时间 - 派单时间 | ≤30分钟 |
|
||
| 服务完成时效 | 签退时间 - 签到时间 | ≥方案规定时长 |
|
||
| 验收反馈时效 | 评价时间 - 服务完成时间 | ≤3个工作日 |
|
||
| 结算归档时效 | 归档时间 - 月末 | ≤次月10日 |
|
||
|
||
### 5.2 质量指标
|
||
|
||
| 指标 | 计算方式 | 目标值 |
|
||
|------|---------|--------|
|
||
| 签到合规率 | GPS签到合格次数 / 总签到次数 | ≥95% |
|
||
| 服务完成率 | 正常完成工单数 / 总工单数 | ≥90% |
|
||
| 异常工单率 | 异常工单数 / 总工单数 | ≤5% |
|
||
| 满意度评分 | 平均评分 | ≥4.5分 |
|
||
| 违规整改率 | 整改通过数 / 违规总数 | ≥95% |
|
||
|
||
### 5.3 闭环完整率
|
||
|
||
| 指标 | 计算方式 | 目标值 |
|
||
|------|---------|--------|
|
||
| 申请→评估转化率 | 进入评估数 / 受理通过数 | ≥95% |
|
||
| 评估→方案转化率 | 生成方案数 / 评估完成数 | ≥90% |
|
||
| 方案→执行转化率 | 生成工单数 / 方案生效数 | ≥95% |
|
||
| 执行→验收转化率 | 验收完成数 / 服务完成数 | ≥90% |
|
||
| 验收→结算转化率 | 结算完成数 / 验收完成数 | ≥95% |
|
||
|
||
---
|
||
|
||
## 六、异常场景与闭环处理
|
||
|
||
### 6.1 异常场景矩阵
|
||
|
||
| 异常场景 | 发生阶段 | 影响范围 | 处理方式 | 回退点 |
|
||
|---------|---------|---------|---------|--------|
|
||
| 申请材料不齐 | 需求受理 | 该申请 | 退回补充材料 | 需求受理 |
|
||
| 不符合资格条件 | 需求受理 | 该申请 | 退回并说明原因 | 需求受理 |
|
||
| 评估员无法按时评估 | 评估定级 | 该评估任务 | 重新派发评估员 | 评估派发 |
|
||
| 评估结果异议 | 评估定级 | 该申请 | 异议复核流程 | 评估派发 |
|
||
| 方案被拒签 | 方案制定 | 该方案 | 重新编制方案 | 方案编制 |
|
||
| 无合适服务人员 | 派单调度 | 该工单 | 人工调度台处理 | 派单调度 |
|
||
| 服务人员临时请假 | 派单调度 | 该工单 | 改派其他人员 | 派单调度 |
|
||
| 对象不在家 | 上门执行 | 该工单 | 异常上报→改约 | 派单调度 |
|
||
| 对象拒绝服务 | 上门执行 | 该工单 | 异常上报→记录 | 工单关闭 |
|
||
| 服务条件不具备 | 上门执行 | 该工单 | 异常上报→协调 | 派单调度 |
|
||
| 突发状况 | 上门执行 | 该工单 | 紧急事件处置 | 视情况 |
|
||
| 服务质量不达标 | 验收反馈 | 该工单 | 拒绝验收→问题反馈 | 上门执行 |
|
||
| 结算金额有误 | 结算归档 | 该结算单 | 审核不通过→退回修改 | 结算生成 |
|
||
|
||
### 6.2 闭环保障原则
|
||
|
||
1. **不遗漏原则**：每一个申请都有最终状态，不会停留在中间状态无后续处理
|
||
2. **可追溯原则**：每一步操作都有时间戳、操作人、操作内容记录
|
||
3. **超时预警原则**：各环节设置超时阈值，超时自动预警通知
|
||
4. **异常必处理原则**：异常工单必须有人处理，不能悬而未决
|
||
5. **数据联动原则**：上游数据变更自动影响下游（如评估等级变更触发方案修订）
|
||
|
||
---
|
||
|
||
## 七、服务闭环总结
|
||
|
||
### 7.1 闭环核心逻辑
|
||
|
||
```
|
||
需求入口（多渠道统一）
|
||
→ 资格过滤（自动校验+人工审核）
|
||
→ 专业评估（上门+定级）
|
||
→ 个性化方案（评估驱动+费用透明）
|
||
→ 智能调度（算法匹配+人工兜底）
|
||
→ 规范执行（签到+记录+轨迹）
|
||
→ 质量保障（监管+验收+评价）
|
||
→ 财务闭环（结算+支付+归档）
|
||
→ 数据沉淀（台账+审计+分析）
|
||
```
|
||
|
||
### 7.2 闭环的三个层次
|
||
|
||
| 层次 | 内容 | 保障机制 |
|
||
|------|------|---------|
|
||
| 业务闭环 | 申请→评估→方案→派单→执行→验收→结算→归档 | 状态机强制流转，不可跳跃 |
|
||
| 质量闭环 | 监管抽查→违规发现→整改执行→复核确认 | 全程可追溯，违规必整改 |
|
||
| 数据闭环 | 每阶段数据为下阶段输入，最终归档沉淀 | 数据完整性校验，关联约束 |
|
||
|
||
### 7.3 实现服务闭环的必要条件
|
||
|
||
1. **状态机完整**：14张核心表覆盖全部业务数据，状态枚举覆盖所有流转路径
|
||
2. **角色分工明确**：9种角色各司其职，操作权限与角色绑定
|
||
3. **通知及时**：MQTT实时推送 + 小程序消息，确保各角色及时响应
|
||
4. **异常可处理**：每个环节都有异常处理路径，不会出现死锁
|
||
5. **数据可追溯**：审计日志 + 版本管理，任何变更可查
|
||
6. **费用可结算**：从方案到执行到结算，费用数据完整链路
|
||
7. **归档可查询**：电子台账永久保存，支持历史查询和导出
|
||
|
||
---
|
||
|
||
*文档结束*
|
||
|
||
|
||
---
|
||
|
||
# V2.0 工程落地增强设计方案
|
||
|
||
> 本章节是在原 V1.0 业务闭环文档基础上的工程增强版设计。目标不是推翻原流程，而是补齐可开发、可联调、可验收、可审计、可运营所需的状态机、数据模型、接口、权限、调度、通知、合规、安全、结算与测试方案。
|
||
|
||
## 一、V2.0 设计目标
|
||
|
||
原文已经完成了“需求受理 → 评估定级 → 方案制定 → 派单调度 → 上门执行 → 验收反馈 → 结算归档”的业务闭环说明。V2.0 需要补齐以下工程能力：
|
||
|
||
| 增强方向 | 解决的问题 | 设计结果 |
|
||
|---|---|---|
|
||
| 全局状态机 | 防止流程跳跃、重复提交、非法结算 | 建立申请、方案、工单、结算四层状态机 |
|
||
| 数据模型 | 支撑长期服务计划、多次上门、多版本方案、按次结算 | 增加服务计划、工单实例、执行明细、证据链、通知回执、审计日志 |
|
||
| 调度算法 | 避免“看起来智能”，实际不可解释 | 区分硬约束过滤与软约束评分，保留推荐解释 |
|
||
| 通知可靠性 | 防止 MQTT 丢失、重复、离线不可达 | 引入 Outbox、通知回执、失败重试、多通道兜底 |
|
||
| 移动端执行 | 防止服务人员端只是简单接单 | 设计 delivery 端任务工作台、签到、执行、异常、补录、离线缓存 |
|
||
| 合规安全 | 处理老人、健康、位置、音视频等敏感数据 | 数据分类分级、单独同意、最小必要、访问审计、证据留存策略 |
|
||
| 结算对账 | 防止金额不可追溯 | 方案价、执行记录、验收、支付、长护险抵扣、退款补差全链路关联 |
|
||
| 测试验收 | 防止文档无法转化为测试项 | 给出接口、权限、状态、异常、合规、压测验收清单 |
|
||
|
||
## 二、总体工程架构
|
||
|
||
```text
|
||
┌────────────────────────────────────────────────────────────┐
|
||
│ 用户访问层 │
|
||
│ 消费者端小程序 delivery端 管理端PC │
|
||
└───────────────────────┬────────────────────────────────────┘
|
||
│
|
||
┌───────────────────────▼────────────────────────────────────┐
|
||
│ API 网关层 │
|
||
│ 登录认证 / 权限校验 / 租户隔离 / 限流 / 日志 / 参数校验 │
|
||
└───────────────────────┬────────────────────────────────────┘
|
||
│
|
||
┌───────────────────────▼────────────────────────────────────┐
|
||
│ 业务服务层 │
|
||
│ 申请服务 评估服务 方案服务 调度服务 工单服务 │
|
||
│ 监管服务 验收服务 结算服务 支付服务 通知服务 │
|
||
└───────────────────────┬────────────────────────────────────┘
|
||
│
|
||
┌───────────────────────▼────────────────────────────────────┐
|
||
│ 基础能力层 │
|
||
│ 状态机引擎 / 调度算法 / Outbox消息 / 审计日志 / 文件存储 │
|
||
│ GPS校验 / 证据链 / 数据脱敏 / 字典配置 / 定时任务 │
|
||
└───────────────────────┬────────────────────────────────────┘
|
||
│
|
||
┌───────────────────────▼────────────────────────────────────┐
|
||
│ 数据存储层 │
|
||
│ MySQL/PostgreSQL / Redis / 对象存储 / 消息队列 / 日志归档 │
|
||
└────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
核心原则：
|
||
|
||
1. 数据库状态为准，MQTT、小程序订阅消息、短信只作为通知通道。
|
||
2. 所有状态流转必须经过后端状态机，前端只能发起动作，不能直接指定目标状态。
|
||
3. 所有写操作必须幂等，尤其是提交申请、接单、签到、完成服务、生成结算、支付回调。
|
||
4. 所有关键操作必须可追溯，记录操作人、时间、前状态、目标状态、业务原因、IP、设备信息。
|
||
5. 评估、方案、价格、抵扣规则、协议签署必须版本化，不能覆盖历史数据。
|
||
6. GPS、照片、录音录像、健康信息必须按最小必要原则采集。
|
||
|
||
## 三、全局状态机设计
|
||
|
||
### 3.1 主链路状态
|
||
|
||
```text
|
||
APPLICATION_CREATED
|
||
↓
|
||
PENDING_ACCEPTANCE
|
||
↓ 受理通过
|
||
PENDING_ASSESSMENT
|
||
↓ 派发评估员
|
||
ASSESSING
|
||
↓ 评估完成
|
||
ASSESSMENT_PASSED
|
||
↓ 编制方案
|
||
PLAN_DRAFTING
|
||
↓ 提交签署
|
||
PLAN_PENDING_SIGN
|
||
↓ 签署通过
|
||
PLAN_EFFECTIVE
|
||
↓ 生成服务计划/工单
|
||
ORDER_PENDING_DISPATCH
|
||
↓ 派单成功
|
||
ORDER_ASSIGNED
|
||
↓ 服务人员接单
|
||
ORDER_ACCEPTED
|
||
↓ GPS签到
|
||
ORDER_CHECKED_IN
|
||
↓ 开始服务
|
||
ORDER_IN_SERVICE
|
||
↓ 完成服务
|
||
ORDER_COMPLETED
|
||
↓ 验收通过
|
||
ORDER_ACCEPTED_BY_USER
|
||
↓ 生成结算
|
||
SETTLEMENT_PENDING_REVIEW
|
||
↓ 审核通过
|
||
SETTLEMENT_PENDING_PAYMENT
|
||
↓ 支付/确认抵扣
|
||
SETTLEMENT_PAID
|
||
↓ 归档
|
||
ARCHIVED
|
||
```
|
||
|
||
### 3.2 申请状态机
|
||
|
||
| 状态编码 | 状态名称 | 允许动作 | 下一状态 | 约束条件 |
|
||
|---|---|---|---|---|
|
||
| DRAFT | 草稿 | 提交申请 | PENDING_ACCEPTANCE | 必填材料完整 |
|
||
| PENDING_ACCEPTANCE | 待受理 | 受理通过 | PENDING_ASSESSMENT | 年龄、资格、重复申请校验通过 |
|
||
| PENDING_ACCEPTANCE | 待受理 | 退回补充 | RETURNED | 必须填写退回原因 |
|
||
| PENDING_ACCEPTANCE | 待受理 | 取消申请 | CANCELLED | 申请人本人或授权家属 |
|
||
| RETURNED | 已退回 | 重新提交 | PENDING_ACCEPTANCE | 补齐材料后重新校验 |
|
||
| PENDING_ASSESSMENT | 待评估 | 派发评估 | ASSESSING | 指定评估员或进入自动推荐 |
|
||
| ASSESSING | 评估中 | 提交评估 | ASSESSMENT_PASSED | 必须有签到、评估表、对象确认 |
|
||
| ASSESSING | 评估中 | 发起异议 | REVIEWING | 必须填写异议原因 |
|
||
| REVIEWING | 复核中 | 维持结论 | ASSESSMENT_PASSED | 复核人不能是原评估员 |
|
||
| REVIEWING | 复核中 | 重评 | ASSESSING | 创建新的评估任务版本 |
|
||
|
||
### 3.3 方案状态机
|
||
|
||
| 状态编码 | 状态名称 | 允许动作 | 下一状态 | 约束条件 |
|
||
|---|---|---|---|---|
|
||
| PLAN_DRAFT | 方案草稿 | 保存 | PLAN_DRAFT | 可多次保存 |
|
||
| PLAN_DRAFT | 方案草稿 | 提交签署 | PLAN_PENDING_SIGN | 必须引用已完成评估报告 |
|
||
| PLAN_PENDING_SIGN | 待签署 | 签署通过 | PLAN_EFFECTIVE | 记录签署人、时间、协议版本 |
|
||
| PLAN_PENDING_SIGN | 待签署 | 拒签 | PLAN_REJECTED | 必须填写拒签原因 |
|
||
| PLAN_PENDING_SIGN | 待签署 | 提出异议 | PLAN_OBJECTION | 生成异议记录 |
|
||
| PLAN_REJECTED | 已拒签 | 重新编制 | PLAN_DRAFT | 新版本号 +1，旧版本冻结 |
|
||
| PLAN_OBJECTION | 方案异议中 | 重新提交 | PLAN_PENDING_SIGN | 新版本号 +1 |
|
||
| PLAN_EFFECTIVE | 已生效 | 生成服务计划 | SCHEDULE_GENERATED | 生成周期性服务计划 |
|
||
| PLAN_EFFECTIVE | 已生效 | 终止方案 | PLAN_TERMINATED | 未执行部分停止生成工单 |
|
||
|
||
### 3.4 工单状态机
|
||
|
||
| 状态编码 | 状态名称 | 允许动作 | 下一状态 | 约束条件 |
|
||
|---|---|---|---|---|
|
||
| ORDER_CREATED | 已创建 | 自动/人工派单 | ORDER_ASSIGNED | 服务计划已生效 |
|
||
| ORDER_ASSIGNED | 已派单 | 接单 | ORDER_ACCEPTED | 服务人员身份、资质有效 |
|
||
| ORDER_ASSIGNED | 已派单 | 拒单 | ORDER_REJECTED | 记录拒单原因，触发重派 |
|
||
| ORDER_ACCEPTED | 已接单 | GPS签到 | ORDER_CHECKED_IN | 位置、时间、照片、对象确认通过 |
|
||
| ORDER_CHECKED_IN | 已签到 | 开始服务 | ORDER_IN_SERVICE | 服务项目清单加载成功 |
|
||
| ORDER_IN_SERVICE | 服务中 | 暂存执行记录 | ORDER_IN_SERVICE | 支持多次暂存 |
|
||
| ORDER_IN_SERVICE | 服务完成 | ORDER_COMPLETED | 所有必做项目有执行结果 |
|
||
| ORDER_IN_SERVICE | 上报异常 | ORDER_EXCEPTION | 异常类型和证据必填 |
|
||
| ORDER_EXCEPTION | 异常中 | 协调继续 | ORDER_IN_SERVICE | 调度员处理后恢复 |
|
||
| ORDER_EXCEPTION | 异常中 | 改派 | ORDER_REASSIGNED | 原工单关闭，生成新工单 |
|
||
| ORDER_EXCEPTION | 异常中 | 关闭 | ORDER_CLOSED | 对象拒绝、无法服务等场景 |
|
||
| ORDER_COMPLETED | 已完成 | 发起验收 | ACCEPTANCE_PENDING | 完成记录已冻结 |
|
||
| ACCEPTANCE_PENDING | 待验收 | 验收通过 | ACCEPTED | 用户确认或超时默认规则触发 |
|
||
| ACCEPTANCE_PENDING | 待验收 | 拒绝验收 | ACCEPTANCE_REJECTED | 必须创建问题处理单 |
|
||
| ACCEPTED | 已验收 | 进入结算 | SETTLEMENT_READY | 验收记录已冻结 |
|
||
|
||
### 3.5 结算状态机
|
||
|
||
| 状态编码 | 状态名称 | 允许动作 | 下一状态 | 约束条件 |
|
||
|---|---|---|---|---|
|
||
| SETTLEMENT_READY | 待结算 | 生成结算单 | SETTLEMENT_PENDING_REVIEW | 关联已验收工单 |
|
||
| SETTLEMENT_PENDING_REVIEW | 待审核 | 审核通过 | SETTLEMENT_APPROVED | 金额核算一致 |
|
||
| SETTLEMENT_PENDING_REVIEW | 待审核 | 审核退回 | SETTLEMENT_RETURNED | 必须填写退回原因 |
|
||
| SETTLEMENT_APPROVED | 已审核 | 发起支付 | PAYMENT_PENDING | 自费金额大于0 |
|
||
| SETTLEMENT_APPROVED | 已审核 | 零元确认 | SETTLEMENT_PAID | 自费为0且抵扣确认完成 |
|
||
| PAYMENT_PENDING | 待支付 | 支付成功 | SETTLEMENT_PAID | 支付回调幂等 |
|
||
| PAYMENT_PENDING | 待支付 | 支付失败 | PAYMENT_FAILED | 可重新支付 |
|
||
| SETTLEMENT_PAID | 已支付 | 归档 | ARCHIVED | 账单、凭证、台账完整 |
|
||
| SETTLEMENT_PAID | 已支付 | 退款/冲正 | REFUNDING | 必须关联原支付单 |
|
||
| REFUNDING | 退款中 | 退款完成 | REFUNDED | 生成冲正凭证 |
|
||
|
||
### 3.6 状态流转记录表
|
||
|
||
新增 `hss_state_transitions`：
|
||
|
||
| 字段 | 说明 |
|
||
|---|---|
|
||
| id | 状态流转ID |
|
||
| entity_type | application / plan / work_order / settlement |
|
||
| entity_id | 业务对象ID |
|
||
| from_status | 原状态 |
|
||
| action | 操作动作 |
|
||
| to_status | 目标状态 |
|
||
| operator_id | 操作人 |
|
||
| operator_role | 操作角色 |
|
||
| reason | 操作原因 |
|
||
| request_id | 请求幂等ID |
|
||
| created_at | 操作时间 |
|
||
|
||
规则：前端只传动作，不传目标状态；后端根据当前状态、动作、角色和数据完整性决定是否允许流转；相同 `request_id + action + entity_id` 重复提交只能返回第一次处理结果。
|
||
|
||
## 四、核心数据模型增强
|
||
|
||
### 4.1 数据域划分
|
||
|
||
| 数据域 | 核心表 | 说明 |
|
||
|---|---|---|
|
||
| 申请域 | hss_service_applications | 服务申请主表 |
|
||
| 用户画像域 | hss_patient_profiles | 服务对象基本画像、护理风险 |
|
||
| 评估域 | hss_assessment_tasks、hss_assessment_reports | 评估任务和报告 |
|
||
| 方案域 | hss_service_plans、hss_service_plan_items、hss_plan_versions | 服务方案和版本 |
|
||
| 计划域 | hss_service_schedules | 周期性服务计划 |
|
||
| 工单域 | hss_work_orders、hss_work_order_items | 每次上门服务实例 |
|
||
| 执行域 | hss_checkins、hss_execution_records、hss_evidence_files | 签到、执行记录、证据 |
|
||
| 异常域 | hss_exceptions、hss_exception_actions | 异常上报和处理动作 |
|
||
| 监管域 | hss_spot_checks、hss_violations、hss_corrections | 抽查、违规、整改 |
|
||
| 验收域 | hss_acceptances、hss_complaints | 验收、评价、投诉 |
|
||
| 结算域 | hss_settlements、hss_settlement_items、hss_payments、hss_refunds | 结算、支付、退款 |
|
||
| 归档域 | hss_ledgers、hss_archive_files | 台账和归档文件 |
|
||
| 通知域 | hss_notification_outbox、hss_notification_receipts | 通知发送与回执 |
|
||
| 审计域 | hss_audit_logs、hss_state_transitions | 审计日志和状态流转 |
|
||
| 合规域 | hss_consent_records、hss_data_access_logs | 授权同意和敏感数据访问日志 |
|
||
|
||
### 4.2 关键建模决策
|
||
|
||
#### 决策一：方案不是工单
|
||
|
||
推荐链路：
|
||
|
||
```text
|
||
服务方案 → 服务计划 schedule → 每次上门工单 work_order
|
||
```
|
||
|
||
原因：居家上门服务通常是周期服务，例如每周3次、持续3个月。如果直接从方案生成一个工单，会无法处理每次上门的签到、异常、验收和结算。
|
||
|
||
#### 决策二：价格、服务项目、报销规则必须版本化
|
||
|
||
需要冻结的数据包括：服务项目名称、单价、频次、服务时长、抵扣比例、自费金额、协议版本、服务人员资质要求。
|
||
|
||
#### 决策三：工单必须支持部分完成
|
||
|
||
| 项目状态 | 含义 |
|
||
|---|---|
|
||
| COMPLETED | 已完成，可结算 |
|
||
| PARTIAL_COMPLETED | 部分完成，需按规则折算 |
|
||
| NOT_COMPLETED | 未完成，不可结算或需人工审核 |
|
||
| EXCEPTION_SKIPPED | 因异常跳过，需异常处理 |
|
||
| USER_REFUSED | 用户拒绝，按取消规则处理 |
|
||
|
||
## 五、权限矩阵增强
|
||
|
||
系统需要采用 `RBAC + 数据范围 + 字段权限 + 审计` 的权限体系：
|
||
|
||
```text
|
||
用户 → 角色 → 权限点 → 数据范围 → 字段级控制
|
||
```
|
||
|
||
| 控制层 | 示例 |
|
||
|---|---|
|
||
| 功能权限 | 是否能审核申请、派单、改派、查看结算 |
|
||
| 数据范围 | 只能看本机构、本社区、本区域、本人的工单 |
|
||
| 字段权限 | 家庭地址、联系电话、健康信息、轨迹、音视频证据分级展示 |
|
||
| 操作权限 | 查看、编辑、导出、下载、审核、作废、归档 |
|
||
|
||
高风险操作需要二次确认并记录原因：人工改派、撤销工单、关闭异常工单、修改已生效方案、结算审核通过、退款冲正、下载敏感证据、导出个人信息。
|
||
|
||
## 六、调度算法设计
|
||
|
||
### 6.1 两阶段调度
|
||
|
||
第一阶段：硬约束过滤。必须满足服务人员状态正常、资质匹配、区域匹配、时间不冲突、不在黑名单、未超过最大工单量、高风险服务有认证。
|
||
|
||
第二阶段：软约束评分。
|
||
|
||
```text
|
||
score = distance_score * 0.25
|
||
+ skill_score * 0.25
|
||
+ workload_score * 0.20
|
||
+ rating_score * 0.15
|
||
+ response_score * 0.10
|
||
+ familiarity_score * 0.05
|
||
```
|
||
|
||
| 因子 | 说明 |
|
||
|---|---|
|
||
| distance_score | 距离越近得分越高 |
|
||
| skill_score | 技能匹配度、证书等级、服务经验 |
|
||
| workload_score | 当前负载越低得分越高 |
|
||
| rating_score | 历史满意度评分 |
|
||
| response_score | 历史接单速度、迟到率 |
|
||
| familiarity_score | 是否服务过该对象且评价良好 |
|
||
|
||
### 6.2 推荐解释
|
||
|
||
自动推荐必须保存解释：
|
||
|
||
```json
|
||
{
|
||
"staff_id": 10086,
|
||
"score": 87.5,
|
||
"hard_constraints": "passed",
|
||
"reasons": [
|
||
"距离服务地址1.2公里",
|
||
"具备康复护理资质",
|
||
"今日剩余工单量较低",
|
||
"历史满意度4.8分"
|
||
]
|
||
}
|
||
```
|
||
|
||
### 6.3 公平性机制
|
||
|
||
需要加入新人员冷启动保护、工单量均衡、同等条件轮询、培训整改后恢复、人工改派原因分析，避免高评分人员长期垄断派单。
|
||
|
||
## 七、通知可靠性设计
|
||
|
||
### 7.1 通知通道定位
|
||
|
||
| 通道 | 作用 | 定位 |
|
||
|---|---|---|
|
||
| MQTT | delivery端实时提醒 | 快速触达，允许重复 |
|
||
| 小程序订阅消息 | 服务对象/家属提醒 | 重要节点提醒 |
|
||
| 短信 | 离线兜底 | 重要超时、支付、异常提醒 |
|
||
| 电话 | 人工兜底 | 紧急事件和长期未响应 |
|
||
|
||
### 7.2 Outbox 模式
|
||
|
||
```text
|
||
业务状态变更成功 → 同事务写 notification_outbox → 异步发送通知 → 写 notification_receipt
|
||
```
|
||
|
||
这样可以避免“状态已变更但通知没发”或“通知发了但状态没变”。
|
||
|
||
### 7.3 通知回执状态
|
||
|
||
| 回执状态 | 含义 |
|
||
|---|---|
|
||
| CREATED | 已创建 |
|
||
| SENT | 已发送 |
|
||
| DELIVERED | 已送达 |
|
||
| READ | 已读 |
|
||
| CONFIRMED | 已确认 |
|
||
| FAILED | 发送失败 |
|
||
| EXPIRED | 已过期 |
|
||
|
||
## 八、合规、安全与审计设计
|
||
|
||
### 8.1 数据分类分级
|
||
|
||
| 数据级别 | 数据类型 | 控制措施 |
|
||
|---|---|---|
|
||
| 普通业务数据 | 服务项目、服务时间、工单状态 | 登录可见、按角色授权 |
|
||
| 个人身份数据 | 姓名、手机号、身份证、家庭地址 | 脱敏展示、最小可见 |
|
||
| 敏感个人信息 | 健康状况、护理等级、行踪轨迹、音视频 | 单独授权、强审计、限制下载 |
|
||
| 财务数据 | 支付记录、抵扣明细、退款记录 | 结算员/管理员可见，操作留痕 |
|
||
| 审计数据 | 登录、导出、查看证据、状态变更 | 只追加、不允许物理删除 |
|
||
|
||
### 8.2 授权同意
|
||
|
||
以下场景必须记录授权：采集健康与护理评估信息、GPS定位签到和轨迹核查、上传现场照片/录音/视频、向家属/机构/监管人员展示服务信息、支付和长护险抵扣相关处理。
|
||
|
||
### 8.3 最小必要采集
|
||
|
||
| 数据 | 推荐采集策略 |
|
||
|---|---|
|
||
| GPS定位 | 默认只采集签到、签退、异常节点；高风险服务才开启过程轨迹 |
|
||
| 照片 | 签到、签退、必要证据采集，不要求全过程拍摄 |
|
||
| 录像/录音 | 默认关闭，只有特定服务或争议处理时启用 |
|
||
| 健康信息 | 只采集与服务方案相关的字段 |
|
||
| 家庭地址 | 前端展示脱敏，导航时短时解密使用 |
|
||
|
||
### 8.4 审计日志
|
||
|
||
审计日志必须记录谁访问了敏感数据、什么时候访问、访问哪个对象、做了什么操作、是否导出或下载、请求来源IP、设备、端类型、访问理由或业务上下文。高风险审计建议追加写，不允许普通管理员修改。
|
||
|
||
## 九、异常工单 SOP
|
||
|
||
| 异常类型 | 触发人 | 处理人 | 推荐处理 |
|
||
|---|---|---|---|
|
||
| 对象不在家 | 服务人员 | 调度员 | 联系对象，改约或关闭 |
|
||
| 对象拒绝服务 | 服务人员/对象 | 调度员 | 记录拒绝原因，按协议处理 |
|
||
| 地址错误 | 服务人员 | 受理员/调度员 | 核实地址，必要时改约 |
|
||
| 无法联系 | 服务人员 | 调度员 | 多通道联系，超时关闭或改约 |
|
||
| 服务条件不具备 | 服务人员 | 调度员/监管员 | 协调条件，必要时暂停 |
|
||
| 身体突发异常 | 服务人员 | 调度员/家属/紧急联系人 | 启动紧急事件流程 |
|
||
| 服务质量争议 | 服务对象 | 监管员 | 调取证据，整改或重服 |
|
||
| 服务人员迟到 | 系统/对象 | 调度员/监管员 | 记录违规，影响评分 |
|
||
| 证据缺失 | 系统 | 服务人员/监管员 | 要求补录或人工审核 |
|
||
| 结算金额争议 | 服务对象/结算员 | 结算员/监管员 | 暂停支付，复核金额 |
|
||
|
||
紧急事件流程：
|
||
|
||
```text
|
||
服务人员触发紧急事件
|
||
↓
|
||
系统弹出紧急操作页
|
||
↓
|
||
一键联系家属 / 调度员 / 120
|
||
↓
|
||
记录事件时间、地点、描述、照片/录音
|
||
↓
|
||
调度员跟进处理
|
||
↓
|
||
监管员复核
|
||
↓
|
||
形成事件归档
|
||
```
|
||
|
||
## 十、delivery 端页面设计
|
||
|
||
### 10.1 页面定位
|
||
|
||
delivery 端是服务人员的移动作业端，核心不是“浏览订单”，而是“完成当天服务任务，并留下完整证据链”。
|
||
|
||
### 10.2 页面清单
|
||
|
||
| 页面 | 路由建议 | 核心功能 |
|
||
|---|---|---|
|
||
| 登录页 | `/pages/delivery/login` | 账号登录、角色校验、机构校验 |
|
||
| 工作台 | `/pages/delivery/index` | 今日任务、待接单、待签到、服务中、异常、待补录 |
|
||
| 工单列表 | `/pages/delivery/orders` | 按状态筛选：待接单、待服务、服务中、已完成、异常 |
|
||
| 工单详情 | `/pages/delivery/order-detail` | 对象信息、地址导航、服务项目、注意事项、联系人 |
|
||
| 接单确认页 | `/pages/delivery/accept` | 接单/拒单，拒单原因 |
|
||
| 签到页 | `/pages/delivery/checkin` | GPS定位、拍照水印、对象确认 |
|
||
| 服务执行页 | `/pages/delivery/execute` | 项目逐项执行、记录时长、上传证据 |
|
||
| 异常上报页 | `/pages/delivery/exception` | 一键选择异常类型、上传证据、提交调度 |
|
||
| 签退/完成页 | `/pages/delivery/finish` | 服务总结、签退定位、提交完成 |
|
||
| 补录上传页 | `/pages/delivery/offline-sync` | 弱网缓存、失败重传、证据补传 |
|
||
| 消息通知页 | `/pages/delivery/messages` | 派单、改派、异常处理、整改通知 |
|
||
| 我的资质页 | `/pages/delivery/profile` | 服务人员信息、资质、评分、工单统计 |
|
||
|
||
### 10.3 工作台设计
|
||
|
||
工作台顶部展示今日关键指标：今日总工单、已完成、待执行、异常；中部展示最近一单；快捷入口包含待接单、待签到、服务中、异常待处理、待补录；底部展示即将超时、未接单、未签到、证据缺失等预警。
|
||
|
||
### 10.4 工单详情设计
|
||
|
||
工单详情必须包含预约时间、服务对象脱敏信息、服务地址和导航按钮、紧急联系人、服务项目清单、护理等级/风险提示、服务注意事项、历史服务摘要、费用是否需要现场确认，以及接单、导航、签到、开始服务、异常上报按钮。
|
||
|
||
### 10.5 执行页设计
|
||
|
||
执行页必须按项目逐项记录：服务项目名称、标准服务时长、实际开始/结束时间、完成状态、证据要求、异常入口。不能只有“完成服务”一个按钮。
|
||
|
||
## 十一、结算对账增强
|
||
|
||
结算金额必须来自以下链路：
|
||
|
||
```text
|
||
签署方案价格快照 → 服务计划 → 已验收工单 → 项目级执行记录 → 长护险/补贴抵扣 → 自费金额 → 支付/确认 → 台账归档
|
||
```
|
||
|
||
| 场景 | 结算策略 |
|
||
|---|---|
|
||
| 正常完成并验收 | 按方案项目单价和频次结算 |
|
||
| 部分完成 | 按项目级完成情况折算，需人工审核 |
|
||
| 用户拒绝服务 | 按取消规则处理，可能不计费 |
|
||
| 对象不在家 | 根据协议判断是否收取上门空跑费 |
|
||
| 服务人员原因未完成 | 不计费，并可能生成违规 |
|
||
| 质量不达标 | 暂停结算，整改后再审核 |
|
||
| 长护险抵扣失败 | 进入人工复核，不能直接要求用户补全 |
|
||
|
||
对账对象包括用户支付账、平台收款账、服务机构结算账、服务人员绩效账、长护险/补贴抵扣账、退款/冲正账。
|
||
|
||
## 十二、测试与验收清单
|
||
|
||
### 12.1 状态机测试
|
||
|
||
| 测试项 | 验收标准 |
|
||
|---|---|
|
||
| 合法状态流转 | 每个动作都能从正确前置状态进入目标状态 |
|
||
| 非法状态拦截 | 未签署方案不能生成工单，未验收工单不能结算 |
|
||
| 重复提交 | 同一个 request_id 重复提交不会产生重复数据 |
|
||
| 回退流程 | 拒签、异议、异常、结算退回均可正确回退 |
|
||
| 版本冻结 | 旧评估报告、旧方案、旧价格不被覆盖 |
|
||
|
||
### 12.2 接口测试
|
||
|
||
| 测试项 | 验收标准 |
|
||
|---|---|
|
||
| 申请接口 | 必填校验、重复申请、退回补充完整 |
|
||
| 评估接口 | 签到、提交报告、异议复核完整 |
|
||
| 方案接口 | 费用试算、签署、拒签、版本化完整 |
|
||
| 派单接口 | 推荐、派单、接单、拒单、改派完整 |
|
||
| 执行接口 | 签到、项目执行、异常、完成、补传完整 |
|
||
| 结算接口 | 生成、审核、支付、退款、归档完整 |
|
||
|
||
### 12.3 权限测试
|
||
|
||
| 测试项 | 验收标准 |
|
||
|---|---|
|
||
| 角色隔离 | 服务人员不能查看非本人任务 |
|
||
| 租户隔离 | 机构A不能访问机构B数据 |
|
||
| 字段脱敏 | 手机、身份证、地址、健康信息按角色脱敏 |
|
||
| 高风险操作 | 导出、下载证据、退款、改派均有审计 |
|
||
|
||
### 12.4 弱网与通知测试
|
||
|
||
| 测试项 | 验收标准 |
|
||
|---|---|
|
||
| MQTT重复 | 重复通知不导致重复接单/完成 |
|
||
| MQTT丢失 | 任务列表仍能从数据库拉取正确状态 |
|
||
| 离线执行 | 本地暂存恢复后能补传 |
|
||
| 通知重试 | 失败通知按策略重试并记录失败原因 |
|
||
| 超时预警 | 到达阈值后自动提醒对应角色 |
|
||
|
||
### 12.5 合规安全测试
|
||
|
||
| 测试项 | 验收标准 |
|
||
|---|---|
|
||
| 授权同意 | 未授权不能采集GPS、照片、健康信息 |
|
||
| 访问审计 | 查看敏感数据有日志 |
|
||
| 数据脱敏 | 非必要角色不能看到完整地址、电话、证据 |
|
||
| 导出控制 | 导出敏感数据需要权限和记录 |
|
||
| 证据留存 | 证据文件有业务关联、留存周期和访问控制 |
|
||
|
||
## 十三、实施优先级
|
||
|
||
### 13.1 MVP 必须完成
|
||
|
||
1. 申请、评估、方案、工单、验收、结算主链路。
|
||
2. 四层状态机。
|
||
3. delivery 端工作台、工单详情、签到、执行、异常、完成。
|
||
4. 项目级执行记录。
|
||
5. 基础派单算法。
|
||
6. 通知 Outbox 和回执。
|
||
7. 结算金额与执行记录关联。
|
||
8. 审计日志和权限矩阵。
|
||
|
||
### 13.2 第二阶段增强
|
||
|
||
1. 自动调度评分优化。
|
||
2. 轨迹异常检测。
|
||
3. 投诉处理闭环。
|
||
4. 监管抽查策略。
|
||
5. 长护险接口或规则引擎。
|
||
6. 服务人员绩效结算。
|
||
7. 数据看板和质量分析。
|
||
|
||
### 13.3 第三阶段智能化
|
||
|
||
1. 基于历史工单的调度优化。
|
||
2. 服务风险预测。
|
||
3. 异常工单自动识别。
|
||
4. 费用合理性校验。
|
||
5. 服务对象画像驱动的个性化方案推荐。
|
||
|
||
## 十四、最终结论
|
||
|
||
V2.0 方案保留原文的业务闭环主线，但将其升级为工程可落地的实现方案。核心变化是：
|
||
|
||
1. 从“阶段流程”升级为“四层状态机”。
|
||
2. 从“工单完成”升级为“项目级执行记录”。
|
||
3. 从“方案生成工单”升级为“方案 → 服务计划 → 每次上门工单”。
|
||
4. 从“即时通知”升级为“Outbox + 多通道 + 回执 + 幂等”。
|
||
5. 从“GPS签到”升级为“定位、照片、对象确认、证据链、合规授权”。
|
||
6. 从“费用结算”升级为“方案价、执行、验收、抵扣、支付、对账、归档全链路”。
|
||
7. 从“业务说明文档”升级为“开发、联调、测试、验收都能使用的工程设计文档”。
|
||
|
||
一句话总结：
|
||
|
||
> 这套系统的核心不是把服务流程画完整，而是让每个服务请求在系统中都能被状态机约束、被数据链路证明、被异常机制兜底、被权限和审计保护，并最终形成可结算、可追溯、可监管、可验收的服务闭环。
|
||
|
||
---
|
||
|
||
## 十五、行业优秀实践借鉴与本项目落地映射（V2.1 增强）
|
||
|
||
> 本章节不是照搬外卖、即时配送、网约车平台的算法，而是吸收其在“供需匹配、实时调度、ETA 预测、运力运营、履约监控、SRE 稳定性、主数据治理”等方面的成熟经验，并结合居家医养服务的安全、合规、资质、服务连续性要求进行改造。
|
||
|
||
### 15.1 借鉴原则：可以借鉴方法论，不能照搬业务目标
|
||
|
||
美团、达达、DoorDash、Uber 等平台的调度核心目标通常是“更快送达、更低成本、更高履约效率”。居家上门服务不能简单追求“最快”，而应采用多目标平衡：
|
||
|
||
```text
|
||
综合最优 = 安全合规 + 服务连续性 + 准时履约 + 资质匹配 + 成本效率 + 用户体验
|
||
```
|
||
|
||
| 即时配送场景 | 居家医养上门场景 | 改造方式 |
|
||
|---|---|---|
|
||
| 骑手接单送达 | 护理员/评估员上门服务 | 从“配送能力”升级为“服务能力+资质能力” |
|
||
| ETA 送达时间 | 预计到达时间 + 预计服务完成时间 | ETA 只作为约束，不作为唯一目标 |
|
||
| 距离优先 | 距离 + 技能 + 熟悉度 + 风险等级 | 高风险老人优先熟悉人员和资质匹配 |
|
||
| 多单合并配送 | 多工单路线编排 | 仅适合低风险、同区域、时间窗兼容任务 |
|
||
| 动态调价调节供需 | 动态运力调度和服务预约容量控制 | 医养场景不建议强动态涨价，应偏向容量预约和人工兜底 |
|
||
| 骑手效率考核 | 服务质量、合规、安全、满意度考核 | 不能只考核速度，必须纳入质量和合规 |
|
||
|
||
### 15.2 借鉴美团配送：三层调度体系
|
||
|
||
美团配送的经验可以抽象为三层：长期规划、中期供需平衡、实时调度。居家上门服务也应该采用类似的分层，而不是只做一个“派单按钮”。
|
||
|
||
```text
|
||
长期规划层：服务区域、机构网格、人员配置、资质结构
|
||
↓
|
||
中期排班层：周/月服务计划、人员排班、预约容量、风险预留
|
||
↓
|
||
实时调度层：当天工单派发、改派、异常处理、路径调整
|
||
```
|
||
|
||
#### 15.2.1 长期规划层：服务网格与运力容量
|
||
|
||
长期规划主要解决“有没有足够合适的人服务这个区域”的问题。
|
||
|
||
| 设计项 | 落地方案 |
|
||
|---|---|
|
||
| 服务网格 | 按社区/街道/乡镇划分服务网格，每个网格绑定可服务人员池 |
|
||
| 人员资质结构 | 统计每个网格中护理、康复、助浴、评估等资质人员数量 |
|
||
| 服务容量 | 计算每个网格每天可承接的服务时长和服务次数 |
|
||
| 缺口预警 | 当某网格未来7天预约量超过可用容量时提前预警 |
|
||
| 机构协同 | 支持跨机构借调、临时支援、人工调度审批 |
|
||
|
||
推荐新增表：
|
||
|
||
| 表名 | 作用 |
|
||
|---|---|
|
||
| `hss_service_grids` | 服务网格表 |
|
||
| `hss_grid_capacity_daily` | 网格每日服务容量 |
|
||
| `hss_staff_skill_capacity` | 人员技能与容量 |
|
||
| `hss_capacity_forecasts` | 未来容量预测 |
|
||
| `hss_capacity_alerts` | 容量缺口预警 |
|
||
|
||
#### 15.2.2 中期排班层：预约容量与服务计划
|
||
|
||
中期排班解决“未来几天/几周怎么排更稳”的问题。
|
||
|
||
| 设计项 | 落地方案 |
|
||
|---|---|
|
||
| 周期服务计划 | 根据签署方案生成未来服务计划 |
|
||
| 时间窗预约 | 服务对象可选择上午/下午/指定时间窗 |
|
||
| 预约容量控制 | 某区域某时间窗容量满后不再开放预约 |
|
||
| 风险缓冲 | 高风险服务预留更长服务时间和调度缓冲 |
|
||
| 批量预排 | 每晚生成次日工单候选排班，调度员复核 |
|
||
|
||
排班目标：
|
||
|
||
```text
|
||
最小化 总出行时间
|
||
最小化 超时风险
|
||
最大化 服务连续性
|
||
最大化 资质匹配度
|
||
控制 单人工作负载
|
||
保留 异常应急容量
|
||
```
|
||
|
||
#### 15.2.3 实时调度层：当天派单与异常改派
|
||
|
||
实时调度解决“今天发生变化后怎么快速调整”的问题。
|
||
|
||
| 场景 | 调度策略 |
|
||
|---|---|
|
||
| 服务人员临时请假 | 找同网格、同资质、低负载人员改派 |
|
||
| 对象不在家 | 改约，释放该时段人员容量 |
|
||
| 上一单超时 | 动态调整后续工单预计到达时间 |
|
||
| 突发紧急事件 | 冻结服务人员后续工单，触发调度员重排 |
|
||
| 恶劣天气 | 提前扩大路程时间缓冲，降低日容量 |
|
||
| 高风险老人服务 | 优先派熟悉人员，不盲目按距离最近派单 |
|
||
|
||
### 15.3 借鉴即时配送 ETA：从“预计到达”升级为“服务履约时间预测”
|
||
|
||
外卖 ETA 主要预测“多久送达”。本项目应拆成四个时间预测：
|
||
|
||
```text
|
||
T_arrive = 预计到达时间
|
||
T_start = 预计开始服务时间
|
||
T_finish = 预计完成服务时间
|
||
T_buffer = 异常缓冲时间
|
||
```
|
||
|
||
最终对用户展示：
|
||
|
||
```text
|
||
预计上门时间窗：09:00 - 09:30
|
||
预计服务完成：10:20 左右
|
||
```
|
||
|
||
对调度系统使用：
|
||
|
||
```text
|
||
下一单可接时间 = T_finish + 路程时间 + 风险缓冲
|
||
```
|
||
|
||
#### 15.3.1 ETA 特征体系
|
||
|
||
| 特征类型 | 示例 |
|
||
|---|---|
|
||
| 地理特征 | 距离、路网时间、城乡道路类型、小区进入难度 |
|
||
| 时间特征 | 早晚高峰、工作日/周末、节假日 |
|
||
| 天气特征 | 暴雨、高温、台风、低温 |
|
||
| 人员特征 | 历史准时率、平均服务时长、熟悉区域 |
|
||
| 服务对象特征 | 小区门禁、楼层、电梯、是否需要家属配合 |
|
||
| 服务项目特征 | 助浴、康复、护理、助洁等标准时长和波动范围 |
|
||
| 异常特征 | 历史拒访率、历史等待时长、最近投诉或争议 |
|
||
|
||
#### 15.3.2 ETA 输出不能只有一个点值
|
||
|
||
推荐输出区间和置信度：
|
||
|
||
```json
|
||
{
|
||
"arrive_time_window": ["09:00", "09:30"],
|
||
"finish_time_window": ["10:10", "10:40"],
|
||
"confidence": 0.82,
|
||
"risk_factors": ["小区进入耗时较长", "该服务项目时长波动大"]
|
||
}
|
||
```
|
||
|
||
业务价值：
|
||
|
||
1. 对用户：减少“为什么还没到”的焦虑。
|
||
2. 对服务人员：避免不合理压缩服务时长。
|
||
3. 对调度员：提前识别高超时风险工单。
|
||
4. 对结算员：服务时长异常可解释。
|
||
|
||
### 15.4 借鉴 VRPTW：把排班建模为“带时间窗的上门服务路径问题”
|
||
|
||
居家上门服务天然适合参考 VRPTW（Vehicle Routing Problem with Time Windows，带时间窗车辆路径问题）。只是这里的“车辆”变成“服务人员”，“客户点”变成“服务对象家庭”。
|
||
|
||
#### 15.4.1 建模方式
|
||
|
||
| VRPTW 概念 | 本项目映射 |
|
||
|---|---|
|
||
| Vehicle | 服务人员/评估员 |
|
||
| Customer Location | 服务对象家庭地址 |
|
||
| Time Window | 预约上门时间窗 |
|
||
| Service Time | 服务项目标准时长 |
|
||
| Capacity | 服务人员每日可服务时长/最大工单数 |
|
||
| Skills | 护理、康复、助浴、评估等资质 |
|
||
| Depot | 服务站点/人员起点 |
|
||
| Penalty | 超时、改派、拒单、跨区、服务连续性破坏成本 |
|
||
|
||
#### 15.4.2 工程实现建议
|
||
|
||
MVP 不建议一开始就上复杂优化器。推荐三阶段演进：
|
||
|
||
| 阶段 | 方法 | 适用情况 |
|
||
|---|---|---|
|
||
| 阶段1 | 规则 + 打分 | 当前项目 MVP，易解释、易上线 |
|
||
| 阶段2 | 局部搜索/启发式优化 | 工单量上升，需要优化区域内多工单顺序 |
|
||
| 阶段3 | OR-Tools/运筹优化 | 工单量大、约束复杂、需要批量预排 |
|
||
|
||
阶段1 评分公式：
|
||
|
||
```text
|
||
score = 资质匹配 * 0.30
|
||
+ 时间窗可达 * 0.20
|
||
+ 服务连续性 * 0.15
|
||
+ 距离/路程 * 0.15
|
||
+ 当前负载 * 0.10
|
||
+ 历史质量 * 0.10
|
||
```
|
||
|
||
阶段2 引入局部优化：
|
||
|
||
```text
|
||
先生成候选人员 → 再对每个人当天路线做插入成本计算 → 选择整体影响最小方案
|
||
```
|
||
|
||
插入成本：
|
||
|
||
```text
|
||
insert_cost = 新增路程时间
|
||
+ 后续工单延误风险
|
||
+ 破坏熟悉服务关系成本
|
||
+ 超过工作时长惩罚
|
||
+ 资质冗余/不足惩罚
|
||
```
|
||
|
||
阶段3 引入 OR-Tools：
|
||
|
||
```text
|
||
输入：人员、工单、时间窗、服务时长、路程矩阵、资质约束
|
||
输出：每个服务人员当天的最优或近似最优服务序列
|
||
```
|
||
|
||
### 15.5 借鉴骑手智能助手：delivery 端不只是执行按钮，而是“服务人员智能助手”
|
||
|
||
服务人员端可以借鉴骑手智能助手的思路，把系统从“被动记录工具”升级为“主动辅助工具”。
|
||
|
||
#### 15.5.1 delivery 端智能提醒
|
||
|
||
| 场景 | 智能提醒 |
|
||
|---|---|
|
||
| 出发前 | 提醒服务对象风险、所需工具、历史注意事项 |
|
||
| 路上 | 提醒预计迟到风险，建议联系对象 |
|
||
| 到达小区 | 提醒门禁、楼栋、电梯、联系人 |
|
||
| 签到失败 | 解释失败原因：距离过远、定位漂移、未授权、照片缺失 |
|
||
| 服务中 | 根据项目清单提醒未完成项 |
|
||
| 服务超时 | 判断是合理超时还是异常停留 |
|
||
| 提交前 | 自动检查证据是否完整 |
|
||
| 异常上报 | 根据异常类型推荐处理流程 |
|
||
|
||
#### 15.5.2 语音与大按钮适老/适岗设计
|
||
|
||
服务人员在上门现场可能双手忙碌，因此可以逐步加入：
|
||
|
||
1. 大按钮操作。
|
||
2. 语音输入备注。
|
||
3. 常用话术快捷选择。
|
||
4. 异常一键上报。
|
||
5. 证据缺失自动提醒。
|
||
6. 离线缓存自动恢复上传。
|
||
|
||
### 15.6 借鉴平台运营经验：建立“运力运营中心”
|
||
|
||
原文已有人员、调度、监管，但还缺少“运力运营”的视角。建议新增“运力运营中心”。
|
||
|
||
#### 15.6.1 运力运营中心看板
|
||
|
||
| 指标 | 含义 |
|
||
|---|---|
|
||
| 今日可用人员数 | 当前可接单人员 |
|
||
| 分资质可用人员 | 护理、康复、助浴、评估等 |
|
||
| 网格容量利用率 | 某社区/街道服务容量使用比例 |
|
||
| 超时风险工单 | 预计无法准时到达或完成 |
|
||
| 高风险服务占比 | 高护理等级/高风险对象服务占比 |
|
||
| 异常工单热力图 | 哪些区域异常频发 |
|
||
| 人员负载分布 | 是否有人过载或闲置 |
|
||
| 服务连续性 | 同一对象由固定人员服务的比例 |
|
||
|
||
#### 15.6.2 运力分层
|
||
|
||
| 人员层级 | 适配任务 |
|
||
|---|---|
|
||
| 新手人员 | 低风险、标准化服务、近距离任务 |
|
||
| 熟练人员 | 普通护理、助洁、陪诊类任务 |
|
||
| 专项人员 | 康复、助浴、失能老人照护 |
|
||
| 高级人员 | 高风险、复杂护理、评估复核 |
|
||
| 机动人员 | 异常改派、紧急补位、跨区支援 |
|
||
|
||
### 15.7 借鉴主数据平台：把“人员、机构、服务项目、区域、资质”做成主数据
|
||
|
||
美团配送架构演进中强调主数据平台，用于支撑履约和运营系统边界。本项目也应该尽早建设主数据，否则后期会出现“每个模块一套人员、区域、服务项目字段”的问题。
|
||
|
||
#### 15.7.1 本项目主数据对象
|
||
|
||
| 主数据 | 说明 |
|
||
|---|---|
|
||
| 机构主数据 | 医院、养老机构、服务站、社区 |
|
||
| 人员主数据 | 服务人员、评估员、监管员、调度员 |
|
||
| 资质主数据 | 护理证、康复资质、助浴资质、评估资质 |
|
||
| 服务项目主数据 | 助洁、助浴、康复、陪诊、健康管理 |
|
||
| 区域主数据 | 市、区县、街道、社区、服务网格 |
|
||
| 价格主数据 | 服务项目价格、补贴规则、长护险抵扣规则 |
|
||
| 服务对象主数据 | 服务对象基础信息、护理等级、风险标签 |
|
||
|
||
#### 15.7.2 主数据服务边界
|
||
|
||
```text
|
||
主数据服务负责：定义、维护、版本、权限、同步
|
||
履约系统负责：申请、派单、执行、验收
|
||
结算系统负责：计费、支付、对账、归档
|
||
监管系统负责：抽查、违规、整改、审计
|
||
```
|
||
|
||
### 15.8 借鉴 SRE：把“稳定性”纳入方案，而不是上线后再补
|
||
|
||
居家上门服务存在紧急事件、老人服务、支付结算和监管审计，系统稳定性不能只靠测试。建议引入 SLO 和错误预算思想。
|
||
|
||
#### 15.8.1 核心 SLO
|
||
|
||
| 能力 | SLO 建议 |
|
||
|---|---|
|
||
| 工单列表可用性 | 99.9% |
|
||
| 签到接口成功率 | 99.5% |
|
||
| 派单状态一致性 | 99.99% |
|
||
| 支付回调幂等正确率 | 100% |
|
||
| 异常上报成功率 | 99.9% |
|
||
| 通知创建成功率 | 99.9% |
|
||
| 证据文件上传成功率 | 99.5% |
|
||
| 敏感数据审计覆盖率 | 100% |
|
||
|
||
#### 15.8.2 降级策略
|
||
|
||
| 依赖故障 | 降级方案 |
|
||
|---|---|
|
||
| MQTT不可用 | 工单列表轮询 + 小程序/短信兜底 |
|
||
| 地图服务不可用 | 手动输入到达说明 + 后补定位 |
|
||
| 对象存储不可用 | 本地缓存证据，恢复后补传 |
|
||
| 支付通道不可用 | 生成待支付账单，稍后重试 |
|
||
| ETA服务不可用 | 使用规则估算时间 |
|
||
| 调度算法不可用 | 切换人工调度台 |
|
||
| OCR/AI能力不可用 | 人工录入，不阻塞主流程 |
|
||
|
||
### 15.9 借鉴 A/B 测试与灰度：调度算法不要一次性全量上线
|
||
|
||
调度算法影响服务人员权益、服务对象体验和运营成本，必须灰度上线。
|
||
|
||
#### 15.9.1 灰度策略
|
||
|
||
| 阶段 | 范围 | 目标 |
|
||
|---|---|---|
|
||
| Shadow 模式 | 只计算推荐，不实际派单 | 对比人工派单效果 |
|
||
| 小范围试点 | 选1个社区/机构 | 验证准时率、满意度、异常率 |
|
||
| 半自动派单 | 算法推荐，调度员确认 | 收集人工修改原因 |
|
||
| 自动派单 | 低风险标准服务自动派单 | 提升效率 |
|
||
| 智能重排 | 异常场景自动给出重排建议 | 降低调度压力 |
|
||
|
||
#### 15.9.2 算法效果指标
|
||
|
||
| 指标 | 说明 |
|
||
|---|---|
|
||
| 准时到达率 | 是否按预约时间窗到达 |
|
||
| 服务完成率 | 是否顺利完成服务 |
|
||
| 异常工单率 | 是否减少异常 |
|
||
| 改派率 | 是否减少人工改派 |
|
||
| 服务连续性 | 是否尽量固定熟悉人员 |
|
||
| 人员负载均衡 | 是否避免过载和闲置 |
|
||
| 用户满意度 | 是否提升评价 |
|
||
| 监管违规率 | 是否降低违规 |
|
||
| 单次服务综合成本 | 是否降低运营成本 |
|
||
|
||
### 15.10 本项目最终推荐升级路线
|
||
|
||
#### MVP：规则调度 + 人工确认
|
||
|
||
```text
|
||
硬约束过滤 → 综合评分 → 推荐Top5 → 调度员确认 → 派单
|
||
```
|
||
|
||
适合当前一期项目，优点是容易解释、容易联调、风险低。
|
||
|
||
#### 第二阶段：服务计划预排 + 局部重排
|
||
|
||
```text
|
||
每天晚上批量生成次日排班 → 调度员复核 → 当天异常触发局部重排
|
||
```
|
||
|
||
适合工单量逐渐增多后，降低调度员压力。
|
||
|
||
#### 第三阶段：ETA预测 + 运力容量预测
|
||
|
||
```text
|
||
预测服务时长、路程时间、迟到风险、区域容量缺口
|
||
```
|
||
|
||
适合形成历史数据后，让调度从“事后处理”升级为“事前预防”。
|
||
|
||
#### 第四阶段：运筹优化 + 智能运营
|
||
|
||
```text
|
||
VRPTW/OR-Tools 批量排班 + 运力中心 + 质量风险预测 + 自动化监管
|
||
```
|
||
|
||
适合规模化推广到多机构、多社区、多服务类型后使用。
|
||
|
||
### 15.11 本章结论
|
||
|
||
行业经验可以明显提升本项目方案质量，但必须经过医养场景改造。最值得吸收的是：
|
||
|
||
1. 美团式三层体系：长期规划、中期排班、实时调度。
|
||
2. 即时配送 ETA 思路：从单点承诺升级为时间窗和置信度。
|
||
3. VRPTW 建模：把上门服务排班抽象为带时间窗、带资质、带容量的路径优化问题。
|
||
4. 智能助手思路：delivery 端从记录工具升级为服务人员辅助工具。
|
||
5. 运力运营中心：把人员、资质、区域、容量纳入运营管理。
|
||
6. 主数据平台：统一人员、机构、区域、资质、项目、价格等基础数据。
|
||
7. SRE 稳定性：为签到、异常、支付、通知、证据上传设定 SLO 和降级方案。
|
||
8. 灰度与 A/B：调度算法先影子运行，再小范围试点，最后逐步自动化。
|
||
|
||
最终目标不是做一个“像美团一样快”的系统，而是做一个“像成熟即时履约平台一样可调度、可预测、可监控、可优化，同时符合医养服务安全和合规要求”的居家上门服务闭环系统。
|
||
|
||
---
|
||
|
||
## 十六、第四步：边界限制与实现硬约束（核心）
|
||
|
||
> 本章用于锁定本次从方案进入实现阶段的工程边界。后续数据库 DDL、接口契约、状态机、delivery 端、小程序端、管理端联调、测试验收都必须以本章为基准。除非项目负责人明确变更，否则不得在开发过程中随意切换技术栈、接口风格、数据模型边界或端侧范围。
|
||
|
||
### 16.1 边界结论
|
||
|
||
| 边界项 | 结论 |
|
||
|---|---|
|
||
| 后端技术栈 | Spring Boot / Java 17 为主，采用模块化单体优先，不一开始拆微服务 |
|
||
| 数据库 | PostgreSQL 优先；若现有平台统一 MySQL，则允许 MySQL 8 替代 |
|
||
| 缓存与锁 | Redis 用于缓存、短期幂等、分布式锁、验证码、热点数据，不作为最终业务状态来源 |
|
||
| 消息与通知 | MQTT/小程序消息/短信只作为通知通道；业务状态以数据库为准；通知采用 Outbox 模式 |
|
||
| 对象存储 | 服务照片、音频、视频、签署文件、归档文件统一进入对象存储，不进入数据库大字段 |
|
||
| 接口风格 | 外部端侧接口采用 RESTful；内部复杂动作采用 action-style REST；调度算法保留内部 service 调用 |
|
||
| API 契约 | 必须输出 OpenAPI 3.1 文档，供前端、测试和后续代码生成使用 |
|
||
| 数据库设计权限 | 允许自由设计新表结构和 DDL，但表名前缀、审计字段、租户字段、状态字段必须统一 |
|
||
| 向后兼容 | 居家子系统从零搭建，不兼容历史居家业务表；但账号、角色、机构、用户、文件能力要与现有平台兼容 |
|
||
| 前端范围 | delivery 端小程序属于本次范围；消费者端和管理端涉及居家流程的页面也属于接口联调范围 |
|
||
| 部署方式 | 一期采用单体后端 + 单库 + Redis + 对象存储 + MQTT Broker；预留后续拆分能力 |
|
||
| 性能目标 | 先按一期中小规模设计，但接口、索引、分页、异步任务、幂等必须按生产方式实现 |
|
||
| 安全合规 | 敏感个人信息、健康信息、轨迹、音视频证据必须有授权、脱敏、访问审计和留存策略 |
|
||
|
||
### 16.2 技术栈硬约束
|
||
|
||
后端采用 Java 17+、Spring Boot、Spring MVC、Spring Security/JWT、MyBatis-Plus 或 Spring Data JDBC、Spring Validation、Spring Scheduler/Quartz、OpenAPI 3.1。核心履约链路不引入 Python/Node 作为主业务服务；调度算法一期以 Java 规则引擎/策略模式实现，Python 只用于后续离线分析或算法实验。
|
||
|
||
数据库以 PostgreSQL 15+ / 17 优先，若平台已有统一 MySQL 8.0，可替代。所有核心业务数据必须进入关系型数据库；服务状态、金额、结算、审计、授权、异常不得只存 Redis；JSON 字段只用于扩展配置、快照、算法解释，不替代核心关系建模；大文件进入对象存储，不进入数据库大字段；状态字段使用稳定枚举编码，不使用中文状态作为数据库值。
|
||
|
||
Redis 只用于缓存、短期幂等、分布式锁、热点字典；MQTT 只用于 delivery 端实时通知；业务成功与否以数据库事务和状态机为准。所有通知必须经过 notification_outbox 和 notification_receipts，重复消息、重复回调、重复点击必须通过幂等键处理。
|
||
|
||
### 16.3 数据库 DDL 设计边界
|
||
|
||
本次允许新增完整居家服务业务表，不强行复用商城订单表或配送表。表规范统一为：表名前缀 hss_，主键 id bigint，租户字段 tenant_id，机构字段 org_id，created_at、updated_at、deleted/deleted_at、version、status、created_by、updated_by 必备。
|
||
|
||
必须独立建模：hss_service_applications、hss_patient_profiles、hss_assessment_tasks、hss_assessment_reports、hss_service_plans、hss_service_plan_items、hss_service_schedules、hss_work_orders、hss_work_order_items、hss_checkins、hss_execution_records、hss_evidence_files、hss_exceptions、hss_acceptances、hss_settlements、hss_settlement_items、hss_notification_outbox、hss_notification_receipts、hss_state_transitions、hss_audit_logs、hss_consent_records。
|
||
|
||
禁止用一个大表保存申请、方案、工单、结算所有字段；禁止把执行记录塞进工单 JSON 后不建明细表；禁止将状态流转只写在业务表 update_time 中；禁止用中文作为枚举值；禁止用前端传入金额作为最终结算金额。
|
||
|
||
### 16.4 接口风格硬约束
|
||
|
||
外部接口采用 RESTful + action-style REST 混合模式。资源查询使用 GET /api/hss/work-orders、GET /api/hss/work-orders/{id}、POST /api/hss/service-applications、PUT /api/hss/service-plans/{id}。状态动作使用 POST /api/hss/applications/{id}/accept、POST /api/hss/work-orders/{id}/check-in、POST /api/hss/work-orders/{id}/finish、POST /api/hss/work-orders/{id}/report-exception、POST /api/hss/settlements/{id}/approve 等动作接口。
|
||
|
||
统一响应格式包含 code、message、data、requestId、timestamp。统一错误格式包含 code、message、details、requestId。所有写接口必须支持 Idempotency-Key；所有分页接口必须支持 page、size、sort；所有列表接口必须按租户、机构、角色做数据范围过滤；所有状态动作必须写 hss_state_transitions；所有高风险动作必须写 hss_audit_logs；OpenAPI 文档必须与后端接口保持同步。
|
||
|
||
### 16.5 向后兼容边界
|
||
|
||
需要兼容现有登录认证、用户 ID、角色权限、机构部门、文件上传能力、小程序工程结构。不需要兼容旧居家服务业务表、商城订单状态、普通配送员订单模型、商城结算表结构、旧调度算法。
|
||
|
||
### 16.6 性能 SLA 与容量边界
|
||
|
||
一期目标：工单列表查询 P95 ≤ 300ms，工单详情 P95 ≤ 300ms，签到接口 P95 ≤ 500ms，服务完成提交 P95 ≤ 800ms（不含大文件上传），派单推荐 P95 ≤ 1s，单批 1000 工单内异步结算，业务提交后 5 秒内生成通知记录。
|
||
|
||
一期容量假设：服务对象 1 万以内，服务人员 1000 以内，日工单量 5000 以内，年工单量 200 万以内，证据文件按对象存储扩容，审计日志按月分区或归档。超出后升级分区表、读写分离、调度服务拆分、异步结算和独立搜索服务。
|
||
|
||
### 16.7 前端协作边界
|
||
|
||
本次 delivery 端小程序在仓库范围内，需要实现登录与角色校验、工作台、工单列表、工单详情、接单/拒单、GPS 签到、服务执行记录、异常上报、证据上传、离线缓存/失败补传、消息通知页、我的资质/评分。
|
||
|
||
前端不得自行判断业务最终状态、不得自行计算最终结算金额、不得绕过后端状态机直接修改状态、不得将敏感信息长期缓存在本地、不得将未脱敏地址/手机号/健康信息暴露给无权限角色。
|
||
|
||
### 16.8 部署环境边界
|
||
|
||
一期推荐：Nginx/API 网关 + Spring Boot 单体应用 + PostgreSQL/MySQL + Redis + 对象存储 MinIO/云 OSS + MQTT Broker + 日志监控。状态机、结算、通知 Outbox、审计日志必须与主库事务一致；文件存储必须支持私有访问、签名 URL、访问审计；生产环境必须区分 dev/test/prod 配置；定时任务必须支持幂等和重复执行保护。
|
||
|
||
### 16.9 本阶段最终硬约束清单
|
||
|
||
1. 后端以 Spring Boot / Java 为主，不在核心链路引入多语言服务。
|
||
2. 新增 hss_ 业务表，允许自由设计 DDL。
|
||
3. 方案、服务计划、工单必须分离建模。
|
||
4. 工单必须有项目级执行明细。
|
||
5. 所有状态流转必须经过后端状态机。
|
||
6. 前端只发动作，不传目标状态。
|
||
7. 所有写接口必须幂等。
|
||
8. 所有通知必须经过 Outbox。
|
||
9. MQTT 不是业务状态依据。
|
||
10. 结算金额以后端基于方案快照和执行记录计算为准。
|
||
11. delivery 端小程序属于本次实现范围。
|
||
12. 敏感数据必须授权、脱敏、审计、控制留存。
|
||
|
||
### 16.10 下一步进入第五步
|
||
|
||
边界限制确定后，下一步进入“第五步：系统模块拆分与工程目录设计”，输出后端模块包结构、前端 delivery 页面目录、数据库 migration 目录、OpenAPI 契约目录、状态机代码目录、调度算法代码目录、通知 Outbox 目录和测试用例目录。
|