线上陪诊预约小程序开发方案与功能拆解

线上陪诊预约小程序开发方案与功能拆解

老龄化加剧、异地就医、上班族无暇陪同就医，催生了陪诊服务需求。陪诊和普通家政服务差异很大，对人员资质审核、就诊隐私保护、订单时间调度、应急处理、资金结算都有更高要求。很多陪诊小程序只简单实现下单接单，缺少排班校验、隐私脱敏、服务节点留痕、纠纷仲裁机制，容易出现陪诊师爽约、患者信息泄露、服务边界模糊等问题。本文基于SpringBoot+UniApp，从业务链路、模块拆分、状态机设计、匹配调度、隐私安全、核心代码等维度，完整讲解线上陪诊预约小程序的落地方案。

一、业务角色与完整服务链路

系统分为C端用户、陪诊师、平台管理员三类角色。 C端用户：填写就诊人信息、选择医院、科室、预约时段、服务类型，提交订单支付； 陪诊师：提交实名认证、资质材料，平台审核通过后开启接单，查看订单、确认预约、打卡签到、上传服务记录； 平台管理员：审核陪诊师资料、医院信息维护、订单监控、纠纷处理、资金对账、评价管理。 完整业务链路：陪诊师入驻审核 → 用户填写就诊信息下单支付 → 系统自动匹配或抢单 → 陪诊师接单确认 → 服务前提醒 → 医院签到、全程节点记录 → 服务完成 → 用户评价 → 平台结算佣金。 服务类型可以分为：全程陪诊、取报告、代挂号、代办缴费、单人陪同检查，不同服务类型定价、时长规则独立配置。

二、技术架构与模块划分

前端采用UniApp一套代码编译用户端、陪诊师端小程序；后端SpringBoot+MyBatis-Plus，Redis存储陪诊师排班、位置缓存、分布式锁；MySQL存储就诊信息、订单、陪诊师档案、服务记录；RabbitMQ处理预约提醒、超时取消、结算事件。 模块划分：陪诊师入驻审核模块、医院科室管理模块、预约下单模块、订单匹配调度模块、服务节点打卡模块、消息通知模块、隐私加密模块、结算分佣模块、售后纠纷模块。 模块之间采用事件驱动，下单、接单、签到、完成都作为独立事件，互不阻塞主流程，方便后续扩展保险、增值服务。

三、核心数据模型与订单状态机设计

陪诊师档案表：姓名、身份证、联系电话、擅长医院科室、可服务时段、服务评分、保证金、审核状态。 就诊人信息表：就诊人姓名、性别、年龄、病症简述，敏感信息加密存储，仅本次订单可见。 订单主表：订单编号、用户ID、陪诊师ID、医院ID、科室、预约时间、服务类型、订单金额、佣金比例、订单状态。 服务节点记录表：订单号、节点类型（签到、候诊、检查、取药、结束）、上传时间、现场照片备注。 订单状态流转：待支付 → 待接单 → 待服务 → 服务中 → 待评价 → 已完成；异常分支：用户取消、陪诊师爽约、平台取消、退款中。 采用状态机管控流转，禁止跨状态跳转，避免脏数据，例如待支付订单不能直接标记为服务中，已完成订单不能再取消。

四、订单匹配接单核心代码

系统支持两种模式：自动智能派单、陪诊师抢单。派单时优先校验排班、距离、评分、当前负载，避免把订单派给已经排满的陪诊师。

@Service
@Slf4j
public class PeiZhenOrderService {
    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private WorkerScheduleMapper workerScheduleMapper;
    @Autowired
    private MatchEventSender matchEventSender;
    @Autowired
    private RedisTemplate<String,Object> redisTemplate;

    @Transactional(rollbackFor = Exception.class)
    public ResultDTO autoMatchOrder(Long orderId, Long hospitalId, LocalDateTime appointTime) {
        // 筛选该时段、该医院可接单陪诊师
        List<WorkerDO> availableWorkerList = workerScheduleMapper.selectAvailableWorker(hospitalId, appointTime);
        if(CollectionUtil.isEmpty(availableWorkerList)){
            log.info("订单{}暂无匹配陪诊师，转入抢单池",orderId);
            OrderDO order = orderMapper.selectById(orderId);
            order.setOrderStatus("WAIT_GRAB");
            orderMapper.updateById(order);
            return ResultDTO.success("无空闲陪诊师，进入抢单池");
        }
        // 按评分、距离、当前订单负载加权排序
        availableWorkerList.sort((w1,w2)->{
            double score1 = w1.getScore() * 0.5 - w1.getLoadCount() * 0.3;
            double score2 = w2.getScore() * 0.5 - w2.getLoadCount() * 0.3;
            return Double.compare(score2,score1);
        });
        WorkerDO targetWorker = availableWorkerList.get(0);
        OrderDO order = orderMapper.selectById(orderId);
        order.setWorkerId(targetWorker.getId());
        order.setOrderStatus("WAIT_CONFIRM");
        orderMapper.updateById(order);
        // 推送接单事件，下发消息提醒陪诊师
        matchEventSender.sendOrderMatchEvent(order,targetWorker);
        return ResultDTO.success("已匹配陪诊师，等待确认接单");
    }
}

陪诊师接单增加超时机制，超过设定时间未确认，订单自动释放，重新匹配或者进入抢单池。

五、服务节点打卡与轨迹留痕

陪诊师到达医院后，在小程序签到，上传现场照片，记录签到位置；服务过程中可以提交候诊、检查、缴费、取药等节点记录。 节点记录和订单强绑定，所有记录不可删除，作为纠纷仲裁凭证。 用户端可以实时查看订单进度，不需要实时获取陪诊师持续定位，兼顾安全和隐私，只有签到节点上报位置，降低隐私风险。 服务完成节点提交后，自动开启评价入口，评价内容会同步计入陪诊师综合评分，评分过低触发平台预警。

六、隐私安全方案（陪诊系统核心重点）

就诊信息属于敏感医疗相关信息，是开发重中之重。 就诊人姓名、病症、联系方式在数据库采用AES加密存储，前端展示脱敏，后台管理员默认看不到完整信息，需要审批后才可以查看原始数据； 陪诊师只能查看当前订单就诊信息，订单结束后，隐藏就诊敏感字段； 禁止将就诊信息用于其他营销推送，聊天记录留存仅用于订单纠纷核查； 陪诊师入驻必须实名认证，人脸核验，留存身份资料，平台做好资质存档。 同时在下单页面明确告知用户信息用途，符合隐私相关规范。

七、排班、取消规则与退款逻辑

陪诊师自主维护排班日历，设置可接单日期、时段，排班之外的时间不会被系统匹配订单。 取消规则分时段：预约前24小时取消，全额退款；临近预约时段取消，按规则扣除部分违约金；陪诊师爽约，平台自动赔付用户，同时扣罚陪诊师保证金。 退款流程支持用户发起，后台人工审核，避免恶意退款。所有退款记录、违约金记录单独留存对账。

八、结算、佣金与保证金体系

订单服务完成，评价窗口期结束后进入结算周期，支持T+1、T+3结算。 平台佣金可以按订单类型设置固定比例，订单金额自动拆分平台佣金和陪诊师收益。 陪诊师入驻缴纳保证金，用于爽约、投诉赔付；正常离职、无纠纷可申请退还保证金。 后台提供对账报表，陪诊师可以查看每一笔订单的收入、佣金、扣款明细，支持导出账单。

九、落地开发常见问题

第一，区分陪诊和普通上门服务，不要照搬家政派单逻辑，就诊信息加密、隐私脱敏是硬性要求； 第二，排班校验必须前置，防止同一陪诊师同一时间段承接多单，造成时间冲突； 第三，订单状态机严格管控，所有变更都记录操作日志，纠纷场景有据可查； 第四，医院、科室数据量大，支持用户手动输入医院，避免字典维护不全无法下单； 第五，消息提醒节点要充足：下单成功提醒、接单提醒、服务前一天提醒、签到提醒、服务完成提醒。

十、总结

线上陪诊预约小程序开发核心是资质审核严格、就诊隐私保护、订单状态可控、服务全程留痕。依托UniApp实现双端小程序，后端通过状态机管理订单、加权算法匹配陪诊师，搭配加密方案处理敏感就诊信息，打通下单、接单、签到、履约、评价、结算全链路。 这套方案适合本地同城陪诊服务商，可独立运营，也可以和家政、健康服务模块组合，是面向老年、异地就医人群的同城服务数字化方案。