郑州预约挂号小程序开发落地 打通医院系统实现线上便捷挂号缴费一体化

      做郑州某三甲医院预约挂号小程序的那段时间，我先从痛点说起：医院系统多为老旧HIS，接口不统一，挂号与缴费各自为政，患者线上操作往往半天打水漂。项目要求把挂号、扣款、就诊卡余额、排队叫号一体化，这不是简单拉个API，而是需要在现网与移动端之间搭一层可控的中间件。

      技术选型上我倾向于“简单能跑，能扩”的组合：前端采用微信小程序原生框架结合云函数处理少量授权逻辑；后端以Spring Boot微服务为主，使用gRPC做内部高并发RPC，外曝RESTful给小程序。数据库用MySQL主从+读写分离，Redis做库存（号源）预占与分布式锁。之所以不用分布式事务，是因为挂号-支付场景更适合Saga补偿策略，实操中我实现了基于消息队列（RabbitMQ）驱动的补偿流程，降低回滚复杂度。

      对接医院HIS最耗时间。我用了Mirth Connect做HL7报文的适配器，将不同厂商的报文标准化为内部统一DTO，同时写了若干转换规则以应对字段缺失。遇到过最棘手的问题是时间戳不同步导致重复挂号——排查时借助tcpdump与Wireshark定位报文重发，再在业务层增加幂等键（手机号+门诊+时间窗）与乐观锁，最终把并发冲突概率降到可接受范围。

      支付环节走微信支付API，核心在异步通知和对账。我在回调处理加了双写确认：先写支付流水到本地库，再通过消息队列通知挂号服务完成扣款并下发HIS。实操中常见问题是回调丢失或重复到达，因此签名校验、幂等处理和最终一致性校验不可少。线上监控我用Prometheus+Grafana监控关键指标，异常警戒用钉钉告警并拉起自动重试队列。

      实现过程中学到的几点心得：与其追求一个覆盖所有场景的协议，不如先做稳定的适配层并留扩展口；用轻量工具模拟HIS比直接在真实环境调试高效；安全方面我建议至少启用TLS1.2以上、敏感字段AES-256加密且做访问审计。未来可逐步引入FHIR或GraphQL做长期演进，但在落地阶段，务实比前沿更重要。