医疗陪诊系统从零搭建：订单生命周期、小程序与合规要点全解析

如果你现在打开招聘网站搜“陪诊师”会发现这个职业正处在“看起来需求旺盛、实际供给混乱”的窗口期。大量创业团队冲进医疗陪诊赛道但第一版产品往往不是系统而是一个几百人的微信群家属在群里发单陪诊师在群里抢单结束后家属把红包转给群主群主再转给陪诊师。跑通三五单没问题一旦同时有几十个订单在跑信息断层、服务没人管、钱账对不上这三件事会同时爆炸。这也是为什么医疗陪诊系统、医院陪诊APP/小程序源码、功能模块这些词最近热度特别高——大家终于意识到陪诊是一门必须被流程管理起来的服务生意而不是靠聊天框驱动的跑腿业务。这篇文章写给三类人准备自己搭陪诊平台的产品经理和创业者给医院、养老机构做信息化服务的研发团队以及想买源码二次开发的程序员。我会按“业务痛点→角色权限→功能模块→技术选型→开发细节→审核合规”的顺序把一套可落地的医疗陪诊系统拆开讲重点放在订单全生命周期、小程序端的关键实现以及那些文档里不会写的坑。1. 陪诊行业的三个死结信息断层、履约失控、资金信任1.1 信息断层家属和陪诊师之间全靠“拍照往群里发”陪诊服务的用户多数是异地就医、独居老人、孕妇或者带娃抽不开身的年轻父母。家属下单之后最关心的问题是陪诊师到了没有、号取没取上、医生怎么说、检查做没做、药拿没拿到。而现实中这些信息全靠陪诊师手动拍照、发语音、发定位一张张图片堆在群里家属看不过来陪诊师也手忙脚乱。这不是个人能力问题是流程设计问题。任何服务只要依赖人工传递状态就一定会有遗漏和延迟。系统要做的事情不是让陪诊师多发消息而是把“服务进度”变成一条可查询的数据链路出发、到达、取号、候诊、就诊、检查、取药、离院每个节点都有标准动作和凭证上传家属打开小程序就能看到当前走到哪一步不需要追着问。1.2 履约失控排班靠脑记爽约只能扯皮第二个死结在供给侧。陪诊师通常同时接几个平台的单自己还接私活一天的排班全靠脑子和手机备忘录。什么时候上线、什么时候下线、一个时间段能接几单没有系统约束结果就是订单冲突、迟到、临时喊人顶班、甚至直接爽约。我自己见过最典型的场景同一个陪诊师上午十点同时在两家医院接了“取报告”单因为在他看来“取个报告半小时跑得快点就行”结果两家医院排队都超过一小时两边家属同时投诉。这类问题靠人管是管不过来的必须在派单环节就做好时段互斥同一陪诊师在重叠时间内只能被派一单或者在抢单时直接锁单。1.3 资金信任押金、尾款和跑单风险第三个死结是钱。陪诊客单价不低半天服务大多在两三百到五六百全天能到上千。家属不敢先把全款付给一个私人陪诊师怕服务缩水、怕临时放鸽子陪诊师也不敢完全先干活后收钱怕家属看完病赖账或者平台拖账。所以很多平台最后都选择了“定金尾款”模式这对系统和资金资质都提出了更高要求。支付链路做不好平台就只能退回线下转账但那样系统里就没有订单闭环后续的评价、风控、纠纷仲裁全都失去数据基础。可以说资金链路的设计直接决定了这个平台是“信息服务”还是“真正履约的交易平台”。2. 四端角色与权限边界你的系统里都有谁一个完整的陪诊平台至少包含四类角色。你可以在第一期就做完四个端也可以先砍掉后台的部分功能但角色模型必须一开始就定清楚不然后面加权限会非常痛苦。2.1 家属端下单、看进度、聊天、付费家属端就是用户下单的小程序/APP主入口。核心功能围绕“一次就诊服务的完整体验”选择服务类型、选择医院和科室、选择时间、填写患者信息、支付定金、查看陪诊师资料、订单进度、IM聊天、尾款支付、评价。这里有一个容易被忽略的设计点下单人家属和就诊人患者经常不是同一个人。比如子女给父母挂号下单人是子女但陪同去医院的可能是老人自己或者下单人要求陪诊师到医院后先联系自己。所以患者信息必须做成独立对象且下单时就要确认“候诊通知默认发给谁”。2.2 陪诊师端接单、打卡、留档陪诊师端应该是极简风格因为陪诊师在医院里经常单手操作界面要适合边走边用。核心功能包括上线/下线、接单/拒单、订单列表、服务节点打卡GPS定位拍照、查看患者备注、IM沟通、服务记录。陪诊师端有一点特别重要系统不要只记录结果还要记录过程。每个节点打卡的时间、定位、现场照片既是给家属看的进度也是将来纠纷仲裁的证据。我在设计时习惯把“打卡”和“服务凭证”合并成一个组件每次打卡必须携带至少一张照片或一个定位防止陪诊师随手点掉。2.3 平台管理后台派单、结算、风控管理后台是运营人员的作战台。功能模块包括服务目录管理、医院库管理、陪诊师入驻审核与资质管理、排班管理、订单监控、投诉处理、结算对账、数据报表。现在很多团队不重视后台的权限细分所有运营都拿同一个管理员账号登录这是很危险的。后台至少要拆成“运营、客服、财务、超管”四个角色客服只看和能处理投诉订单财务只能查看结算流水超管负责配置价格和审核陪诊师避免越权操作。2.4 权限控制与数据隔离四端数据隔离的原则就一句话每一端只能看到自己需要的数据也只能操作自己有权操作的状态。陪诊师不能看到平台全量订单池只能看到派给或可抢的单家属不能看到陪诊师手里的其他订单后台客服查看用户信息时手机号、身份证号要做掩码显示。数据隔离除了页面控制后端接口权限也要跟上。小团队可以先用一个简单的拦截器/中间件按角色过滤接口中期再引入完整的RBAC权限框架但无论如何不要让前端的“是否显示按钮”来决定后端的权限边界。3. 功能模块按订单生命周期拆解3.1 下单前服务目录、定价与医院库系统里第一个要建的模块不是订单而是服务目录和医院库。服务目录决定了你能卖什么普通陪诊半天/全天、代办挂号、代取报告、代取药、送检、异地陪诊等。每个服务要有SKU级别的配置城市、医院、服务时长、价格、包含内容。医院库比很多人想的更麻烦。同一个城市的三甲医院院区差异很大有些医院本院和分院隔了几公里科室分布也不一样。医院库至少需要医院名称、院区、地址、经纬度、联系电话、科室列表。这些数据建议一开始就人工维护你要开城的那几家核心医院不要急着接第三方POI数据因为后续的派单围栏、科室匹配都依赖这套数据的准确性。3.2 下单与支付定金尾款的双段设计订单流程我推荐这么做家属选择服务、医院、时间填写患者信息系统展示可选陪诊师列表按距离、评分、历史接单数排序家属可指定或交给平台指派创建订单状态为“待支付定金”支付定金比如总价的30%-50%后订单进入“待接单/待派单”陪诊师接单后订单状态变为“已接单”服务开始前家属可免费取消服务开始后取消按比例扣费服务完成后家属支付尾款陪诊师确认服务完成订单进入“已完成”双方互评。这种设计的好处是家属用定金锁定服务陪诊师用尾款倒逼服务质量平台则在中间掌握订单闭环。定金比例、取消规则、超时未支付自动取消的时长都需要在后台做成可配置项而不是写死在代码里。3.3 派单与抢单自动派单逻辑与冲突控制订单创建后如何找到合适的陪诊师是这个系统最核心的业务逻辑之一。常见的模式有三种平台派单后台或自动算法将订单分配给指定区域的在线陪诊师抢单模式订单在陪诊师端“订单池”展示先到先得混合模式先给“精选陪诊师”私单几分钟内未接则转为抢单池。实现上自动派单至少要考虑四个维度服务时间是否与已有订单冲突、直线距离或乘车时间、陪诊师的服务星级、当前在线状态。抢单模式看起来简单但并发最容易出问题多个陪诊师同时抢同一单如果接口没有做幂等和锁就会出现超卖。后面第5部分我会单独讲。3.4 服务进行中节点打卡与轨迹留痕服务执行阶段我建议把整个就诊流程拆成固定节点出发、到达医院、取号、候诊叫号、问诊、检查/缴费、取报告、取药、离院。每个节点做成子状态提交并允许陪诊师补充备注。家属端按时间线展示这些节点的进度比单纯看地图定位直观得多。同时节点数据要完整落库以后想评估陪诊师的服务质量、做服务复盘都能从这些数据里挖出来。这里补充一个做法系统在“取药完成”或“订单服务时间过半”时自动给家属发一条订阅消息提醒“服务即将结束请注意支付尾款”。这能显著降低尾款支付的遗漏率。订阅消息不要滥用一次服务最多推3-4条否则用户会关掉消息权限。3.5 售后取消、退款与评价取消和退款规则必须写清楚不能靠客服手动退。我的建议是未接单前全额退款已接单未开始服务可无损取消但需要陪诊师确认服务开始后按已服务时长比例退款服务完成则不再退款。评价模块要双向家属给陪诊师打分陪诊师也可以给家属/患者打标签如“老人行动不便需要搀扶”“患者有听力障碍”这些标签只对内部可见用于派单时匹配更合适的陪诊师。双向评价的思路家属评分影响陪诊师接单权重陪诊师的内部标签影响平台对订单的风险评估但标签不直接展示给家属。4. 项目结构、技术选型与核心表设计4.1 为什么用户端优先做小程序而不是APP如果你不是已经有强APP推广渠道的团队我强烈建议第一版先把微信小程序做起来。理由很简单获客成本低、不需要下载安装、微信生态内调用登录和支付顺畅、患者家属这个群体几乎人人都有微信。APP的定位更适合陪诊师端陪诊师需要频繁登录、后台运行定位、接收推送手机里常住一个APP是合理的。但如果预算有限第一版陪诊师端在微信小程序里也能跑只是要忍受小程序切后台的超时问题定位上报不如APP稳定。4.2 一套代码多端跑uni-app选型的思路现在做小程序很少直接从原生WXML起步。我自己的项目用 uni-app 做用户端和陪诊师端一套代码同时出微信小程序、H5后期有必要再编译成安卓/iOS APP。Taro 也是一个合理选项它更贴近 React 生态选哪个取决于团队技术栈但核心思路一样业务层写一套UI 层按平台做少量适配。要特别提醒的是小程序端的 UI 组件别贪多。医疗场景的页面大多很简单列表、详情、表单、聊天用 uni-app 自带的组件加少量自定义样式就够了上重量级组件库反而会拖累包体积和加载速度。4.3 后端分层与核心数据表后端技术栈上创业团队适合用 Node.jsNestJS或 GoGin研发资源充足的传统团队用 Spring Boot 也是常规操作。这不是什么“最优架构”问题关键是选团队最熟悉、能最快出活的那套。核心表我建议至少包含这几张字段从简按实际扩展订单表 orders字段类型说明idBIGINT主键order_noVARCHAR(64)业务订单号对外展示user_idBIGINT下单家属patient_idBIGINT就诊患者service_type_idINT服务SKUhospital_idINT医院IDvisit_dateDATE就诊日期visit_time_rangeVARCHAR(64)时间段statusTINYINT订单状态assignee_idBIGINT陪诊师IDtotal_amountDECIMAL(10,2)总价deposit_amountDECIMAL(10,2)定金pay_statusTINYINT支付状态create_time / update_timeDATETIME时间戳状态流转日志表 order_status_logs字段类型说明idBIGINT主键order_idBIGINT订单IDfrom_statusTINYINT原状态to_statusTINYINT新状态operator_typeTINYINT操作方类型operator_idBIGINT操作方IDremarkVARCHAR(255)备注create_timeDATETIME记录时间陪诊师排班表、患者信息表、服务SKU表、医院表这几张我就不逐一列字段了但注意患者信息表里的证件号、病史等敏感字段要设计成加密列或单独隔离存储。一个订单的生命周期里订单号和状态流转日志建议尽早落库。我见过很多团队为了省事不建状态日志表等到出了纠纷要追溯“到底是谁在什么时间改了订单状态”结果完全查不到只能被用户质疑。一张成本很低的日志表能帮你规避大额的信任危机。4.4 订单状态机状态表提前定义好订单状态机是这个系统的“法律文件”。建议第一版就只允许下列流转当前状态可流转到待支付定金已取消、已支付定金待接单待接单已接单、已取消退款已接单服务中、已取消部分退款服务中待支付尾款、已取消部分退款待支付尾款已完成、已取消需人工处理已完成无已取消 / 已退款无合法的状态迁移要在后端用一张映射表或枚举强制约束前端传过来的“目标状态”如果不在映射范围内直接拒绝。别小看这一步它能在开发中后期帮你挡住大量因为并发、重复点击、页面缓存造成的脏数据。5. 开发中容易翻车的五个实现细节5.1 手机号授权改版后的登录链路现在微信小程序获取手机号的标准做法是在小程序里放置一个open-typegetPhoneNumber的按钮用户点击后把返回的 code 传给后端后端再用这个 code 调用微信接口换取手机号然后静默绑定。这里有几个坑要注意。第一手机号快捷验证组件要求小程序必须已经认证且主体是企业或个体工商户个人主体不能使用这个能力。第二同一个用户短时间内反复触发手机号验证有次数管控不能拿它当“每天签到”的按钮用。第三登录这件事要区分“游客能力”和“实名能力”浏览服务列表、查看制度说明可以不需要登录只有下单、支付、聊天才要求登录这样可以显著减少注册环节的流失。5.2 医院围栏签到误差怎么处理陪诊师“到达医院”的打卡最简单的方式是小程序里调wx.getLocation拿经纬度对比医院坐标的半径距离。但实测下来医院楼体大、门诊入口分散、GPS在医院附近经常漂移单一的圆心半径判定要么太宽松在马路对面也算到了要么太严格明明在门诊楼里却提示没到。我的处理方式是把“围栏判定”当第一道门槛而不是唯一依据。具体做法在后台按院区维护多点围栏至少覆盖主要入口、门诊楼、急诊、住院部签到接口校验围栏内的点位时允许前端传入 GPS 坐标同时要求陪诊师拍照上传现场照片如果 GPS 判定不通过允许用户在打卡页“手动打卡”但标记为“位置异常”进入客服人工复核队列。这套逻辑不会让履约记录完美无缺但能保证“真实服务过程有留痕、异常情况有兜底”。5.3 抢单并发分布式锁和乐观锁都要上抢单场景的并发控制是重灾区。同一张订单两个陪诊师同时点击“抢单”如果代码里只是简单地把订单的 assignee_id 设置为请求方就会出现两个陪诊师都认为自己抢到了单。更麻烦的是还会有“在服务时间重叠的情况下同时接两单”的问题。基本解法是引入 Redis 分布式锁抢单请求进来先尝试获取锁锁不到就返回“已被抢/时间冲突”。订单更改状态的 SQL 也建议加乐观锁条件比如UPDATE orders SET assignee_id ?, status ? WHERE id ? AND status 待接单;更新影响行数为 0 就说明失败。两套机制一起上能挡住绝大多数并发问题。另外陪诊师在某个时间段已经有一个服务中订单时新订单的派单接口要主动做重叠校验而不是等服务冲突后靠客服人工处理。5.4 病历照片隐私存储和按订单隔离陪诊过程中患者病历、检查报告、缴费单都是必须拍照留存的但这些属于高度敏感的个人健康信息。千万不要把图片直接传到任意的公网图床或者用公开读的存储桶。建议用私有读的存储桶图片上传后生成带时效的临时 URL例如 30 分钟有效期给前端展示服务端保存完整路径前端拿到的图片链接过期后重新向后端换取。同时对陪诊师上传的图片做“按订单隔离”很重要。图片的键object key里建议包含订单号后端查询时校验访问者的角色和订单归属非本订单相关人员一律拒绝访问。这一点在需求文档里很容易被忽略出了问题却是最大的隐私事故。5.5 订阅消息别乱发审核会卡微信小程序的订阅消息现在每次发送都要求用户有“授权记录”一次性订阅的有效期只到用户下次进小程序前。很多团队一上来就想给家属推“订单状态全链路通知”结果用户一不注意点掉了授权后面根本推不出去。我建议把通知分成两类一类是强提醒比如陪诊师已接单、服务即将开始这类在上一次交互时弹出授权请求另一类是弱消息比如退款进度、活动提醒这类放到订单页内展示不占用订阅授权。另外订阅消息的标题和模板库申请有审核内容里不要出现“加群”“购买”“转发有奖”这类营销词医疗相关的表述更要注意用词中性、实事求是。6. 上线审核与合规我踩过的坑和总结的经验6.1 小程序类目与资质先问平台再写代码陪诊服务在小程序侧的类目归属不太稳定不同时期、不同主体资质下的审核口径会有差异。有的团队定位成“生活服务-私人管家”能过审有的被要求补充医疗相关资质或上门服务协议。我的建议是开发之前先在小程序后台提交一次类目审核咨询把审核结果以截图形式存档再照着已通过的类目准备业务流程。不要照搬两年前别人写的“陪诊小程序上架攻略”审核规则会变而且地区差异明显。6.2 支付分账与资金合规这是陪诊平台最容易被忽视的一块。如果平台代收用户全款再按比例结算给陪诊师这就有资金合规风险必须使用有资质的支付服务商方案比如微信支付的服务商模式 分账能力或者走持牌机构的资金存管。没有相应资质前更稳妥的模式是平台只做信息撮合和担保展示用户和陪诊师之间通过合规的收款通道完成交易平台以自己的服务费作为营收。很多小团队在开发阶段完全不考虑资金合规等上线跑出量之后被支付渠道风控才回来改交易结构改动成本非常高。我建议从原型阶段就把“资金流向图”画出来标清楚每一笔钱从谁到谁、平台怎么抽佣再决定支付模块怎么开发。6.3 隐私弹窗与用户授权小程序端在上架审核和实际使用中隐私权限有一堆手机号、位置、相机、相册、麦克风IM语音。每项采集都要在《用户隐私保护指引》里写清用途。前端也要在首次触发能力时给出明确的弹窗说明比如“拍照用于留存就诊凭证”“位置用于陪诊师签到和路线规划”。病历照片等敏感信息我建议在用户协议里单独加一段“健康信息处理说明”至少写清楚存储在哪、谁可以看、保留多久、用户如何申请删除。这不是文档层面的形式工作后期遇到投诉或纠纷时这份说明就是你最有效的解释依据。6.4 上线前灰度一座城市、一家医院、五个陪诊师最后是运营层面的建议。医疗陪诊是一个高度依赖本地化资源的生意系统再完善也得靠真实服务跑出口碑。我强烈建议不要一上来开十座城而是选一座城市、一家你熟悉的三甲医院、五个陪诊师先手工加系统混合跑三十单完整的服务流程把“下单→派单→服务→支付→售后”每个环节都真实走一遍收集伴随就诊中的意外情况医生临时停诊、检查改约、医院系统故障等再决定要不要扩城市和加功能。写到这里我想起自己第一次上线陪诊系统的时候最大的体会不是代码难写而是业务里的“非标”远比技术复杂。同一个三甲医院不同院区的取号窗口、检查流程、楼层布局都不同这些信息是系统永远无法自动生成的必须靠陪诊师在系统里持续补充。所以陪诊系统的核心竞争力从来不只是源码和功能模块而是你是否有能力在城市级的医疗服务网络里把每一个非标环节一点点标准化然后持续跑下去。如果你正准备做这块我的建议是第一版功能做减法订单闭环做完整剩下的交给真实订单去打磨。