comclib
c02029a5f3
- Spring Boot 后端服务 (hss-home-service) - delivery-miniapp 配送小程序 - website 官网 (Nuxt) - docs 架构设计文档 - Docker 容器化部署配置 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
69 KiB
69 KiB
居家上门服务系统 — 服务闭环流程文档
文档版本：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 闭环保障原则
- 不遗漏原则：每一个申请都有最终状态，不会停留在中间状态无后续处理
- 可追溯原则：每一步操作都有时间戳、操作人、操作内容记录
- 超时预警原则：各环节设置超时阈值，超时自动预警通知
- 异常必处理原则：异常工单必须有人处理，不能悬而未决
- 数据联动原则：上游数据变更自动影响下游（如评估等级变更触发方案修订）
七、服务闭环总结
7.1 闭环核心逻辑
需求入口（多渠道统一）
→ 资格过滤（自动校验+人工审核）
→ 专业评估（上门+定级）
→ 个性化方案（评估驱动+费用透明）
→ 智能调度（算法匹配+人工兜底）
→ 规范执行（签到+记录+轨迹）
→ 质量保障（监管+验收+评价）
→ 财务闭环（结算+支付+归档）
→ 数据沉淀（台账+审计+分析）
7.2 闭环的三个层次
| 层次 | 内容 | 保障机制 |
|---|---|---|
| 业务闭环 | 申请→评估→方案→派单→执行→验收→结算→归档 | 状态机强制流转，不可跳跃 |
| 质量闭环 | 监管抽查→违规发现→整改执行→复核确认 | 全程可追溯，违规必整改 |
| 数据闭环 | 每阶段数据为下阶段输入，最终归档沉淀 | 数据完整性校验，关联约束 |
7.3 实现服务闭环的必要条件
- 状态机完整：14张核心表覆盖全部业务数据，状态枚举覆盖所有流转路径
- 角色分工明确：9种角色各司其职，操作权限与角色绑定
- 通知及时：MQTT实时推送 + 小程序消息，确保各角色及时响应
- 异常可处理：每个环节都有异常处理路径，不会出现死锁
- 数据可追溯：审计日志 + 版本管理，任何变更可查
- 费用可结算：从方案到执行到结算，费用数据完整链路
- 归档可查询：电子台账永久保存，支持历史查询和导出
文档结束
V2.0 工程落地增强设计方案
本章节是在原 V1.0 业务闭环文档基础上的工程增强版设计。目标不是推翻原流程，而是补齐可开发、可联调、可验收、可审计、可运营所需的状态机、数据模型、接口、权限、调度、通知、合规、安全、结算与测试方案。
一、V2.0 设计目标
原文已经完成了“需求受理 → 评估定级 → 方案制定 → 派单调度 → 上门执行 → 验收反馈 → 结算归档”的业务闭环说明。V2.0 需要补齐以下工程能力：
| 增强方向 | 解决的问题 | 设计结果 |
|---|---|---|
| 全局状态机 | 防止流程跳跃、重复提交、非法结算 | 建立申请、方案、工单、结算四层状态机 |
| 数据模型 | 支撑长期服务计划、多次上门、多版本方案、按次结算 | 增加服务计划、工单实例、执行明细、证据链、通知回执、审计日志 |
| 调度算法 | 避免“看起来智能”，实际不可解释 | 区分硬约束过滤与软约束评分，保留推荐解释 |
| 通知可靠性 | 防止 MQTT 丢失、重复、离线不可达 | 引入 Outbox、通知回执、失败重试、多通道兜底 |
| 移动端执行 | 防止服务人员端只是简单接单 | 设计 delivery 端任务工作台、签到、执行、异常、补录、离线缓存 |
| 合规安全 | 处理老人、健康、位置、音视频等敏感数据 | 数据分类分级、单独同意、最小必要、访问审计、证据留存策略 |
| 结算对账 | 防止金额不可追溯 | 方案价、执行记录、验收、支付、长护险抵扣、退款补差全链路关联 |
| 测试验收 | 防止文档无法转化为测试项 | 给出接口、权限、状态、异常、合规、压测验收清单 |
二、总体工程架构
┌────────────────────────────────────────────────────────────┐
│ 用户访问层 │
│ 消费者端小程序 delivery端 管理端PC │
└───────────────────────┬────────────────────────────────────┘
│
┌───────────────────────▼────────────────────────────────────┐
│ API 网关层 │
│ 登录认证 / 权限校验 / 租户隔离 / 限流 / 日志 / 参数校验 │
└───────────────────────┬────────────────────────────────────┘
│
┌───────────────────────▼────────────────────────────────────┐
│ 业务服务层 │
│ 申请服务 评估服务 方案服务 调度服务 工单服务 │
│ 监管服务 验收服务 结算服务 支付服务 通知服务 │
└───────────────────────┬────────────────────────────────────┘
│
┌───────────────────────▼────────────────────────────────────┐
│ 基础能力层 │
│ 状态机引擎 / 调度算法 / Outbox消息 / 审计日志 / 文件存储 │
│ GPS校验 / 证据链 / 数据脱敏 / 字典配置 / 定时任务 │
└───────────────────────┬────────────────────────────────────┘
│
┌───────────────────────▼────────────────────────────────────┐
│ 数据存储层 │
│ MySQL/PostgreSQL / Redis / 对象存储 / 消息队列 / 日志归档 │
└────────────────────────────────────────────────────────────┘
核心原则：
- 数据库状态为准，MQTT、小程序订阅消息、短信只作为通知通道。
- 所有状态流转必须经过后端状态机，前端只能发起动作，不能直接指定目标状态。
- 所有写操作必须幂等，尤其是提交申请、接单、签到、完成服务、生成结算、支付回调。
- 所有关键操作必须可追溯，记录操作人、时间、前状态、目标状态、业务原因、IP、设备信息。
- 评估、方案、价格、抵扣规则、协议签署必须版本化，不能覆盖历史数据。
- GPS、照片、录音录像、健康信息必须按最小必要原则采集。
三、全局状态机设计
3.1 主链路状态
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 关键建模决策
决策一：方案不是工单
推荐链路：
服务方案 → 服务计划 schedule → 每次上门工单 work_order
原因：居家上门服务通常是周期服务，例如每周3次、持续3个月。如果直接从方案生成一个工单，会无法处理每次上门的签到、异常、验收和结算。
决策二：价格、服务项目、报销规则必须版本化
需要冻结的数据包括：服务项目名称、单价、频次、服务时长、抵扣比例、自费金额、协议版本、服务人员资质要求。
决策三：工单必须支持部分完成
| 项目状态 | 含义 |
|---|---|
| COMPLETED | 已完成，可结算 |
| PARTIAL_COMPLETED | 部分完成，需按规则折算 |
| NOT_COMPLETED | 未完成，不可结算或需人工审核 |
| EXCEPTION_SKIPPED | 因异常跳过，需异常处理 |
| USER_REFUSED | 用户拒绝，按取消规则处理 |
五、权限矩阵增强
系统需要采用 RBAC + 数据范围 + 字段权限 + 审计 的权限体系：
用户 → 角色 → 权限点 → 数据范围 → 字段级控制
| 控制层 | 示例 |
|---|---|
| 功能权限 | 是否能审核申请、派单、改派、查看结算 |
| 数据范围 | 只能看本机构、本社区、本区域、本人的工单 |
| 字段权限 | 家庭地址、联系电话、健康信息、轨迹、音视频证据分级展示 |
| 操作权限 | 查看、编辑、导出、下载、审核、作废、归档 |
高风险操作需要二次确认并记录原因：人工改派、撤销工单、关闭异常工单、修改已生效方案、结算审核通过、退款冲正、下载敏感证据、导出个人信息。
六、调度算法设计
6.1 两阶段调度
第一阶段：硬约束过滤。必须满足服务人员状态正常、资质匹配、区域匹配、时间不冲突、不在黑名单、未超过最大工单量、高风险服务有认证。
第二阶段：软约束评分。
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 推荐解释
自动推荐必须保存解释：
{
"staff_id": 10086,
"score": 87.5,
"hard_constraints": "passed",
"reasons": [
"距离服务地址1.2公里",
"具备康复护理资质",
"今日剩余工单量较低",
"历史满意度4.8分"
]
}
6.3 公平性机制
需要加入新人员冷启动保护、工单量均衡、同等条件轮询、培训整改后恢复、人工改派原因分析，避免高评分人员长期垄断派单。
七、通知可靠性设计
7.1 通知通道定位
| 通道 | 作用 | 定位 |
|---|---|---|
| MQTT | delivery端实时提醒 | 快速触达，允许重复 |
| 小程序订阅消息 | 服务对象/家属提醒 | 重要节点提醒 |
| 短信 | 离线兜底 | 重要超时、支付、异常提醒 |
| 电话 | 人工兜底 | 紧急事件和长期未响应 |
7.2 Outbox 模式
业务状态变更成功 → 同事务写 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
| 异常类型 | 触发人 | 处理人 | 推荐处理 |
|---|---|---|---|
| 对象不在家 | 服务人员 | 调度员 | 联系对象，改约或关闭 |
| 对象拒绝服务 | 服务人员/对象 | 调度员 | 记录拒绝原因，按协议处理 |
| 地址错误 | 服务人员 | 受理员/调度员 | 核实地址，必要时改约 |
| 无法联系 | 服务人员 | 调度员 | 多通道联系，超时关闭或改约 |
| 服务条件不具备 | 服务人员 | 调度员/监管员 | 协调条件，必要时暂停 |
| 身体突发异常 | 服务人员 | 调度员/家属/紧急联系人 | 启动紧急事件流程 |
| 服务质量争议 | 服务对象 | 监管员 | 调取证据，整改或重服 |
| 服务人员迟到 | 系统/对象 | 调度员/监管员 | 记录违规，影响评分 |
| 证据缺失 | 系统 | 服务人员/监管员 | 要求补录或人工审核 |
| 结算金额争议 | 服务对象/结算员 | 结算员/监管员 | 暂停支付，复核金额 |
紧急事件流程：
服务人员触发紧急事件
↓
系统弹出紧急操作页
↓
一键联系家属 / 调度员 / 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 执行页设计
执行页必须按项目逐项记录：服务项目名称、标准服务时长、实际开始/结束时间、完成状态、证据要求、异常入口。不能只有“完成服务”一个按钮。
十一、结算对账增强
结算金额必须来自以下链路：
签署方案价格快照 → 服务计划 → 已验收工单 → 项目级执行记录 → 长护险/补贴抵扣 → 自费金额 → 支付/确认 → 台账归档
| 场景 | 结算策略 |
|---|---|
| 正常完成并验收 | 按方案项目单价和频次结算 |
| 部分完成 | 按项目级完成情况折算，需人工审核 |
| 用户拒绝服务 | 按取消规则处理，可能不计费 |
| 对象不在家 | 根据协议判断是否收取上门空跑费 |
| 服务人员原因未完成 | 不计费，并可能生成违规 |
| 质量不达标 | 暂停结算，整改后再审核 |
| 长护险抵扣失败 | 进入人工复核，不能直接要求用户补全 |
对账对象包括用户支付账、平台收款账、服务机构结算账、服务人员绩效账、长护险/补贴抵扣账、退款/冲正账。
十二、测试与验收清单
12.1 状态机测试
| 测试项 | 验收标准 |
|---|---|
| 合法状态流转 | 每个动作都能从正确前置状态进入目标状态 |
| 非法状态拦截 | 未签署方案不能生成工单，未验收工单不能结算 |
| 重复提交 | 同一个 request_id 重复提交不会产生重复数据 |
| 回退流程 | 拒签、异议、异常、结算退回均可正确回退 |
| 版本冻结 | 旧评估报告、旧方案、旧价格不被覆盖 |
12.2 接口测试
| 测试项 | 验收标准 |
|---|---|
| 申请接口 | 必填校验、重复申请、退回补充完整 |
| 评估接口 | 签到、提交报告、异议复核完整 |
| 方案接口 | 费用试算、签署、拒签、版本化完整 |
| 派单接口 | 推荐、派单、接单、拒单、改派完整 |
| 执行接口 | 签到、项目执行、异常、完成、补传完整 |
| 结算接口 | 生成、审核、支付、退款、归档完整 |
12.3 权限测试
| 测试项 | 验收标准 |
|---|---|
| 角色隔离 | 服务人员不能查看非本人任务 |
| 租户隔离 | 机构A不能访问机构B数据 |
| 字段脱敏 | 手机、身份证、地址、健康信息按角色脱敏 |
| 高风险操作 | 导出、下载证据、退款、改派均有审计 |
12.4 弱网与通知测试
| 测试项 | 验收标准 |
|---|---|
| MQTT重复 | 重复通知不导致重复接单/完成 |
| MQTT丢失 | 任务列表仍能从数据库拉取正确状态 |
| 离线执行 | 本地暂存恢复后能补传 |
| 通知重试 | 失败通知按策略重试并记录失败原因 |
| 超时预警 | 到达阈值后自动提醒对应角色 |
12.5 合规安全测试
| 测试项 | 验收标准 |
|---|---|
| 授权同意 | 未授权不能采集GPS、照片、健康信息 |
| 访问审计 | 查看敏感数据有日志 |
| 数据脱敏 | 非必要角色不能看到完整地址、电话、证据 |
| 导出控制 | 导出敏感数据需要权限和记录 |
| 证据留存 | 证据文件有业务关联、留存周期和访问控制 |
十三、实施优先级
13.1 MVP 必须完成
- 申请、评估、方案、工单、验收、结算主链路。
- 四层状态机。
- delivery 端工作台、工单详情、签到、执行、异常、完成。
- 项目级执行记录。
- 基础派单算法。
- 通知 Outbox 和回执。
- 结算金额与执行记录关联。
- 审计日志和权限矩阵。
13.2 第二阶段增强
- 自动调度评分优化。
- 轨迹异常检测。
- 投诉处理闭环。
- 监管抽查策略。
- 长护险接口或规则引擎。
- 服务人员绩效结算。
- 数据看板和质量分析。
13.3 第三阶段智能化
- 基于历史工单的调度优化。
- 服务风险预测。
- 异常工单自动识别。
- 费用合理性校验。
- 服务对象画像驱动的个性化方案推荐。
十四、最终结论
V2.0 方案保留原文的业务闭环主线，但将其升级为工程可落地的实现方案。核心变化是：
- 从“阶段流程”升级为“四层状态机”。
- 从“工单完成”升级为“项目级执行记录”。
- 从“方案生成工单”升级为“方案 → 服务计划 → 每次上门工单”。
- 从“即时通知”升级为“Outbox + 多通道 + 回执 + 幂等”。
- 从“GPS签到”升级为“定位、照片、对象确认、证据链、合规授权”。
- 从“费用结算”升级为“方案价、执行、验收、抵扣、支付、对账、归档全链路”。
- 从“业务说明文档”升级为“开发、联调、测试、验收都能使用的工程设计文档”。
一句话总结：
这套系统的核心不是把服务流程画完整，而是让每个服务请求在系统中都能被状态机约束、被数据链路证明、被异常机制兜底、被权限和审计保护，并最终形成可结算、可追溯、可监管、可验收的服务闭环。