全省医保结算平台设计——一个中间层的自我修养

全省医保结算平台设计——一个中间层的自我修养一、这个平台是干什么的先说清楚一件事全省结算平台不是只为异地就医服务的。它的定位是省级医保结算的统一枢纽。无论你是本省参保人在本地看病还是外省参保人来本省就医所有的费用结算都经过这个平台。用一张简化的图来说明外省社保局 ←─────────────────────────── 结算结果回传 ↗ 外省参保人 ──→ 就医申请 → 审核入院 → 费用结算 ──→ 全省结算平台 本省参保人 ──→ 出院结算 → 费用结算 ────────→ ↕ ↘ 数据交换 定点医疗机构医院─── 费用清单 ──────────→ ↕ 市县社保数据库全省结算平台坐在中间往上对接外省社保局跨省结算时往下对接各市县的社保数据库往前对接医院的费用数据。它是一个中间层。中间层的宿命谁都要找你出了问题都怪你。二、流程图里藏着的架构决策原始的流程图是一张跨职能流程图泳道图5个泳道、4段流程。把里面的架构决策提炼出来每一条都值得展开。2.1 为什么需要全省这一层参保人的医保数据存在哪里市县社保数据库。那为什么不让医院直接和市县社保系统对接因为一个省可能有几十个甚至上百个市县系统每个系统的接口、数据格式、版本可能都不一样。如果每家医院都和每个市县单独对接连接数是 M×NM家医院 × N个市县根本管不过来。引入全省结算平台后变成星型结构没有平台M × N 条连接 医院1 ←→ 市县A 医院1 ←→ 市县B 医院2 ←→ 市县A ... 有平台M N 条连接 医院1 ←→ 全省平台 ←→ 市县A 医院2 ←→ 全省平台 ←→ 市县B这是典型的引入中间层减少耦合的架构模式。代价是多了一跳收益是所有参与方只需要对接一个平台。2.2 本省和外省两条链路的复杂度差异流程图里清晰地展示了两条链路本省参保人结算3步发起出院结算接受请求进行费用结算出院结算完成外省参保人结算8步提交就医申请及相关资料受理申请并且审核相关资料判断是否符合条件 → 不符合则退回情况说明上传相关信息提交入库就医申请通过数据交换传到市县发起身份认证 → 身份确认 → 判断是否符合要求接受入院 → 入院信息提交入库费用清单 → 费用清单提交入库下载费用清单信息 → 结算医疗费用 → 结算结果提交入库上传结算信息 → 传送 → 反馈结算结果信息给外省社保局为什么差距这么大本质是数据主权问题。本省参保人的数据就在本省市县社保数据库里结算平台可以直接查到参保信息、缴费记录、报销比例结算过程是内部事务。外省参保人的数据在外省社保局手里。本省平台不知道这个人有没有参保、缴费够不够、能不能报销所以需要先申请、审核、身份认证——这些都是在建立信任。结算完成后还要把结果回传给外省因为钱最终要从外省的医保基金里出。2.3 提交入库出现了5次仔细数一下流程图里提交入库这个动作就医申请审核通过 → 上传相关信息 →提交入库结算平台数据库就医申请 → 数据交换 → 市县社保数据库接受入院 → 入院信息提交入库费用清单 → 费用清单提交入库结算结果 → 结算结果提交入库每个关键环节的产出都要入库。这不是偶然而是可追溯性的要求。医保结算涉及钱每一笔都要经得起审计。如果某天有人质疑这笔费用是怎么算出来的你需要能拿出完整链路入院记录 → 费用清单 → 结算明细 → 支付凭证。任何一个环节没有入库链条就断了。这也是为什么流程图里有结算平台数据库和市县社保数据库两个数据库——平台库存的是过程数据申请记录、结算结果市县库存的是参保数据参保信息、缴费记录。两边的职责不同。2.4 数据交换是什么流程图里出现了两次数据交换连接着结算平台数据库和市县社保数据库。这个节点看起来简单实际上是最复杂的部分之一。省级平台和市县系统通常不是同一套技术栈甚至不是同一个供应商开发的。数据交换要解决数据格式对齐A市用的是2008年的老系统B市用的是2020年新上的字段定义、编码标准可能完全不同时序问题结算平台入库了但市县那边还没同步过来怎么办幂等性网络抖动导致重传同一笔结算不能入两次对账平台算的金额和市县那边对不上差了几分钱怎么调流程图里只画了一个框数据交换背后的工作量可能占整个平台的30%以上。2.5 “传送和反馈”跨省通信外省流程的尾部有两个特殊动作传送结算结果从结算平台传给外省社保局反馈结算结果信息外省社保局确认收到这是跨省数据通信。省级平台之间的对接通常走的是国家医保局的统一通道。但实际操作中各省系统的接口标准、报文格式、响应速度参差不齐。传送失败、超时、格式错误都是日常。三、身份认证这个网关入院登记流程里有一个关键节点身份认证。参保人 → 发起身份认证 → 接受信息进行身份确认 → 身份符合要求 ↓ 是 ↓ 否 接受入院 反馈身份认证信息这不是简单的你是谁的问题而是你是不是参保人— 查参保状态你的参保地是哪里— 决定走本省还是外省流程你的待遇标准是什么— 不同地区报销比例不同你有没有在其他地方同时住院— 防止骗保身份认证通过后才允许入院。这是一个前置网关——把不符合条件的请求挡在外面避免后续产生无法结算的费用。从架构角度看这是一个典型的Guard Pattern在流程入口做校验而不是在流程末尾做纠错。末尾纠错的成本远高于入口拦截。四、中间层的三个生存法则做全省结算平台这样的中间层系统有几条经验法则一所有数据都要留痕前面说了提交入库出现5次。中间层系统最大的风险是扯皮——医院说传了数据市县说没收到外省说结算结果不对。唯一能自证清白的方式就是每一步都入库带时间戳带操作方。法则二不要假设下游是实时的流程图里数据交换这个节点最容易犯的错误是假设它是同步的——平台入库了马上就能从市县查到。实际上市县系统可能是每小时批处理一次甚至每天一次。所以系统设计时要区分两种场景需要实时响应的身份认证、入院登记— 走同步接口可以延迟的费用清单同步、对账— 走异步消息 定时任务法则三对账比对结算更重要结算算出金额只是开始。真正花时间的是对账——平台算的、市县记的、医院报的、外省确认的四方面数据能不能对得上。流程图里没有体现对账流程但实际系统中对账模块的复杂度往往超过结算模块本身。五、如果重新设计站在今天看这个流程图有几个地方可以改进1. 身份认证可以更早目前的流程是申请审核通过 → 入院 → 身份认证。如果把身份认证前置到申请阶段可以在审核环节就确认参保状态减少无效申请。2. 费用清单可以实时推送流程图里是费用清单提交入库的批处理模式。如果改为实时推送每产生一笔费用就同步可以提前发现异常避免出院时一次性对不上。3. 本省流程可以更透明本省结算只画了3步看起来简单但实际操作中参保人最关心的能报多少、自付多少这个信息流程图里没有体现。应该在发起结算时就有预估而不是出院时才算。4. 补上异常流程流程图里符合条件判断只有两个出口通过和退回。但实际还有第三种挂起——材料不齐补交后再审。这种中间状态在流程图里没有体现但系统设计中必须考虑。六、回到中间层全省结算平台的本质是什么是一个数据路由器。它不产生数据参保信息在市县费用数据在医院不消费数据报销款从医保基金出它负责的是把数据在正确的时刻送到正确的参与方手中。就医申请 → 路由到市县确认参保状态费用清单 → 路由到结算引擎计算报销金额结算结果 → 路由到外省社保局确认付款这个定位决定了它的核心挑战不是计算能力而是数据一致性和多方协调。任何一个参与方掉链子整个链路就断了。中间层不好做但不可或缺。去掉它每个参与方都要和其他所有参与方直接对话复杂度会爆炸。留下它就要承受作为中间人的所有压力。这就是全省医保结算平台的日常。