# 居家上门服务系统 — 服务闭环流程文档 > 文档版本：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：调度算法先影子运行，再小范围试点，最后逐步自动化。 最终目标不是做一个“像美团一样快”的系统，而是做一个“像成熟即时履约平台一样可调度、可预测、可监控、可优化，同时符合医养服务安全和合规要求”的居家上门服务闭环系统。