业务背景
陪诊服务的本质是线下医疗服务过程线上化。
与常规预约类应用不同，陪诊系统需要处理的不只是"下单—接单"两个节点，
而是从服务发起、到院执行、过程记录、结束确认到结算评价的完整链路。
典型的陪诊订单涉及患者（或代下单家属）、陪诊服务人员、平台运营方三类核心主体，部分项目还会引入医疗机构、合作服务商等
参与方。每个角色对同一笔订单的关注点和操作权限不同，系统需
要在保证服务过程可追溯的同时，确保数据边界清晰。
系统架构
陪诊平台建议采用前后端分离的多端架构：
端 | 核心职责 |
|---|---|
用户端（患者/家属） | 服务需求发布、订单跟踪、费用查看、评价 |
服务人员端（陪诊员） | 订单接收、签到、进度更新、凭证上传、结算查看 |
运营管理端 | 审核、派单、异常干预、退款处理、数据统计 |
开放接口层 | 与互联网医院、健康档案、慢病管理系统的数据交互 |
后端采用 RESTful API + 消息队列的组合，订单状态变更通过事件驱动通知相关角色，保证服务过程中的信息同步实时性。
订单状态机设计
陪诊业务的核心模型是订单状态机。一笔订单的主干状态流如下：
同时需要预留以下分支状态：
- 取消类：用户取消、服务人员取消
- 变更类：订单改期、服务改派
- 异常类：超时未接单、服务中断、退款中、异常结束
状态迁移需要明确的前置条件和触发动作。例如"待服务→服务中"必须由服务人员的签到动作触发，而不是系统自动流转。每个状态变更都应写入订单操作日志，用于后期纠纷追溯和运营分析。
服务流程建模
一次陪诊服务应被建模为流程实例（Process Instance），而非单一订单记录。流程实例包含一组有序的服务节点（Service Node）：
- 联系患者（出发前）
- 到达医院签到
- 取号/挂号
- 陪同候诊
- 陪同检查
- 协助缴费
- 取报告
- 服务确认完成
不同服务包可配置不同的节点组合。服务人员按节点逐步更新状态并上传必要的现场凭证（如挂号单、报告照片等），平台可实时查看服务进度。这种设计使服务过程完全留痕，避免了"只有结果、没有过程"的管理盲区。
权限与数据边界
陪诊系统采用 RBAC（基于角色的访问控制） 模型，不同角色的可见数据范围不同：
- 患者/家属：仅可见本人关联的订单及对应服务人员信息
- 服务人员：仅可见已接订单的患者必要信息（姓名、联系方式、医院、科室、就诊时间）
- 运营人员：可按权限查看订单全貌，但患者敏感信息需按需授权展示
- 机构管理员（多机构场景）：仅可见本机构下的订单和人员数据
数据隔离建议在数据库层面通过
tenant_id（机构标识）+ role_scope（角色范围）双重控制，而非仅在应用层做过滤。订单完成后，历史数据按合规要求设定留存策略，敏感字段可脱敏展示。关键接口设计
接口类别 | 说明 |
|---|---|
订单创建 | 接收服务需求，生成流程实例和初始状态 |
派单/接单 | 支持抢单或派单模式，含改派和超时重新分配逻辑 |
状态更新 | 服务人员签到、节点完成、异常上报 |
凭证上传 | 支持图片/文件上传，与订单节点关联 |
结算接口 | 服务完成后自动计算服务费、佣金和结算金额 |
消息通知 | 订单状态变更时推送至相关角色 |
外部系统对接 | 与健康档案、互联网医院平台的数据同步接口 |
扩展方向
基础服务流程跑通后，可根据业务需要逐步扩展：
- 会员与套餐：高频用户的权益体系
- 多城市运营：城市级服务范围和服务人员管理
- 多机构协同：多个医疗机构共享平台，租户间数据隔离
- 护理服务延伸：陪诊之外的居家护理、康复陪护等服务品类
- 健康管理融合：将陪诊数据纳入慢病管理闭环，形成诊前—诊中—诊后连续服务
小结
陪诊服务平台的核心不是页面数量，而是三点：订单可追踪、角色有权限、过程有记录。
状态机设计决定系统能否稳定运行，权限模型决定数据是否安全合规，流程建模决定服务过程是否可控可追溯。
在医疗健康场景下，任何线下服务线上化都需要以数据安全、权限清晰、过程可审计为前提。这是陪诊系统设计的底线，也是整个医疗服务数字化系统建设的基本原则。
山东虎嗅网络科技有限公司
医疗健康 · AI应用 · 智能硬件 · 企业数字化系统
官网：huxiukeji.com本文为软件项目研发经验分享，不涉及医疗诊断与治疗建议。
