1. 医疗支付平台业务全景与架构目标

医疗支付平台并不是一个单纯的“收银台”，它处在医院信息系统（HIS）、医保核心系统、商业保险公司、第三方支付渠道与患者之间，承担着把一次就诊行为转化为一笔可结算、可对账、可追溯的资金流的职责。理解这个平台，第一步不是看技术栈，而是把业务全景摊开：谁发起支付、钱从哪里来、经过哪些系统、最终如何确认成功。只有业务边界清晰，架构目标才有落点。

一、四类支付场景的业务差异

医疗支付的核心场景可以归纳为四类，它们的资金属性、参与方和时效要求差异很大。

医保结算是最典型的场景。患者挂号或缴费时，系统需要先调用医保接口完成“预结算”，得到医保统筹支付、个人账户支付、个人自费三部分的金额拆分，再由患者支付自费部分。医保结算的关键约束是：金额必须与医保返回结果严格一致，任何一分钱的偏差都会导致后续对账失败。医保接口通常有明确的超时限制（例如 3~5 秒），且部分地区的医保核心系统在夜间有停机窗口，平台必须能识别并优雅降级。

商保直付面向购买了商业健康险的患者。患者在挂号时授权保险公司，就诊结束后由医院直接向保险公司发起理赔请求，保险公司审核后把赔付款打给医院，患者只需支付免赔额和自付比例部分。商保直付的难点在于：不同保险公司的接口协议、理赔规则、审核时效完全不同，有的实时返回，有的 T+1 才返回结果，平台需要支持异步状态流转。

自费支付是患者全额自付，接入微信、支付宝、银联等渠道。它看起来最简单，但恰恰是并发压力最大的场景——早高峰挂号、门诊缴费窗口集中放号时，瞬时并发可能达到每秒数千笔。自费支付的核心要求是“快”和“准”：支付结果必须可靠回调，不能出现用户已扣款但订单仍显示待支付的情况。

惠民保是近年各地推出的普惠型补充医疗保险，通常由多家保险公司共保。它的特点是参保人数多、单笔金额小、理赔规则相对标准化，但往往要求与医保结算联动——先走医保，再走惠民保，最后才是个人自费。这意味着一次缴费可能触发多次结算调用，平台需要编排好调用顺序和失败回滚。

二、从业务全景推导架构目标

把上述场景放在一起看，平台面对的是“多资金来源、多外部系统、多时效要求”的组合。由此可以推导出四个必须同时满足的架构目标。

高可用。医保结算和自费支付都发生在患者就诊的关键路径上，平台不可用会直接导致窗口排队甚至业务中断。医保接口本身可能超时或不可达，平台不能因为一个外部依赖挂掉就整体不可用。合理的做法是对医保、商保、第三方渠道分别做熔断和降级：医保不可用时，允许患者先全额自费、后续补报销；第三方渠道某一家不可用时，自动路由到备用渠道。平台自身的关键服务（订单、支付网关）应做到多实例部署，避免单点。

高并发。自费支付的峰值往往集中在放号后的几分钟内。假设某三甲医院日门诊量 1.5 万人次，其中 60% 通过线上支付，早高峰 10 分钟内完成 40% 的支付，则峰值 TPS 约为 1.5万×60%×40%÷600 ≈ 6 笔/秒——单看数字不大，但如果是区域平台承载几十家医院，峰值会放大到数百甚至上千 TPS。平台需要在订单创建、渠道调用、回调处理三个环节都具备水平扩展能力，并且对同一订单的重复回调做幂等处理。

强一致。医疗支付涉及医保基金、保险赔款和个人资金，金额拆分必须准确。一次医保结算返回“统筹 80 元、个账 30 元、自费 20 元”，平台记录的三个金额之和必须等于 130 元，且与医保返回完全一致。订单状态、支付流水、对账文件三者之间不能出现“订单已支付但流水缺失”或“流水成功但订单仍待支付”的情况。这要求平台在关键写路径上使用可靠的事务边界，并通过定时对账兜底。

合规安全。医疗支付涉及个人身份信息、就诊信息、银行账户和保险保单，属于敏感数据。平台需要做到：支付授权可追溯（谁在什么时间授权了哪笔扣款）、敏感字段脱敏存储、接口调用双向认证、操作日志留存满足监管要求。惠民保和商保直付还涉及保险公司与医院之间的数据共享边界，必须明确哪些字段可以传、哪些必须脱敏。

三、一个可落地的订单状态设计示例

架构目标最终要落到具体的数据结构和状态流转上。以一笔“医保+自费”混合支付为例，订单可以设计为如下状态：

INIT        订单已创建，尚未发起任何结算
MEDICAL_ING 医保预结算中
MEDICAL_OK  医保预结算成功，已拆分金额
PAYING      自费部分支付中
PAID        自费支付成功，订单完成
FAILED      任一环节失败且不可重试
REFUNDING   退款中
REFUNDED    已退款

状态流转的关键约束是：只有 MEDICAL_OK 之后才能进入 PAYING；PAID 必须同时满足“医保结算成功”和“自费支付成功”两个条件；任何一步失败都要记录失败原因和外部流水号，便于人工介入。这个状态机看似简单，但它把“强一致”从抽象目标变成了可检查的规则——每一笔订单在任何时刻都处于且仅处于一个确定状态，且状态之间的迁移有明确的前置条件。

四、业务全景对后续章节的牵引

本章梳理的四类场景和四个架构目标，会贯穿后续所有章节。医保结算的接口适配、商保直付的异步状态、自费支付的高并发网关、惠民保的多段编排，分别对应不同的技术方案；而高可用、高并发、强一致、合规安全则是对所有方案的共同约束。换句话说，后面每一章讨论的具体设计，都可以回到本章的全景图上找到它的位置和它要解决的问题。

在进入具体设计之前，建议先明确一件事：你的平台服务的是单家医院还是区域多机构？这个边界决定了并发量级、对账复杂度和合规要求的起点，也决定了后续架构取舍的优先级。