HIS 医保结算：冲正、日终对账与可追溯流水

医保结算模块对接外部医保平台：费用明细上传、预结算、正式结算、退费冲正、日终结账。这条链路上任何「大概成功了」的写法，都会在退费或审计时变成无法自证的烂账。我在 .NET 服务里把「流水 + 状态机 + 补偿任务」作为三条主线，接口封装反而放在其次。

流水先行

本地先落结算流水——请求报文摘要、业务单号、患者标识、状态、时间、操作人——再调外部接口。回执到达后更新同一条流水，而不是「接口返回 200 了再补记一笔」。报文全文可按合规要求加密归档，列表页只展示摘要字段。

状态字段要够用

至少区分：待发送 / 已发送待回执 / 成功 / 失败可重试 / 失败需人工 / 已冲正。收银台 UI 只展示语义化文案，底层状态供对账与补偿 Job 使用。禁止用单一 bool IsSuccess 概括整条医保链路。

冲正补偿

结算成功后的退费、冲正必须关联原流水 ID，携带原平台交易号。窗口重复点击、网络重试、客户端崩溃后重发，都靠业务单号幂等——同一 settleNo 多次提交，只产生一笔有效结算或一笔有效冲正。

补偿任务

对「已发送待回执」超过阈值的记录，定时向平台查询结果或重发（需确认平台是否支持查询接口）。重发前检查本地状态，避免已成功却被再次提交。补偿日志单独记，与人工调账操作区分。

典型坑

• 冲正成功但 HIS 费用状态未回滚：费用明细状态变更应与流水更新在同一业务事务边界内设计好，外部回调用最终一致性补偿
• 平台返回「交易不存在」却本地标成功：对账任务必须打标「待核实」，不能静默忽略
• 日终前仍有大量待回执：不能强行关账，应阻塞日终并告警

日终对账

每日拉取平台账单，与本地「成功」流水逐笔比对：金额、人次、险种分类。差额单要能一键打开原始请求/响应报文、操作者、关联挂号记录。对账结果导出给财务，字段口径与 HIS 报表一致。

对账不是财务年底才做的事，而是每日运维动作。差额处理流程写进 Runbook：先查本地流水，再查平台侧，最后决定补发、冲正还是人工调账，每一步留操作记录。

与 HIS 其他模块的边界

结算模块不应直接改医嘱或处方表。通过应用服务通知收费处、住院处更新「医保已结 / 待补差」标志，保持依赖单向。医生站、护士站只读结算结果，不触发结算接口。

异常与降级

医保平台维护或链路中断时，收银不能简单「全站不可用」。应区分：可读卡但不可结算（先自费记账、事后补结）、完全不可读卡（人工流程）。降级策略写进配置，界面统一提示，避免各院区自行口头约定。

上线前检查清单

• [ ] 任意流水可还原请求/响应与状态迁移历史
• [ ] 冲正、退费均可关联原交易
• [ ] 日终对账差额有处理 SLA 与责任人
• [ ] 敏感报文存储与访问有权限控制
• [ ] 平台维护窗口有降级预案与事后补结流程

医疗信息化里，可解释的失败比「偶发自动好了」更值钱。审计问「这笔为什么退这么多」时，你能打开流水讲清楚每一步，系统才算合格。

小结

医保结算强调流水先行、冲正关联与日终对账。平台维护期要有降级策略，差异单要能打开报文轨迹。把「可解释的失败」做成模块能力，医院侧排障与信任都会好很多。