医疗连锁门诊 HMO/HIS/医保接口怎么对接最稳

医疗系统对接的特殊性：宕机 1 小时 = 几百个病人看不了病

零售系统挂了，顾客可以改天再来。医疗系统挂了，挂了号的病人在诊室门口坐着，排队的队伍从诊室排到大门外。

更严重的是医保实时结算接口断了——要么全额自费病人投诉，要么门诊垫付后要不回来钱。

医疗对接的第一原则：「接口可断，业务不能停」。所有外部接口都必须有降级方案和离线补偿机制。

第一层：接口适配层——不要让 HIS 直接对接医保

• 常见错误架构：HIS 系统直接调用医保中心接口、直接调用 HMO 保险公司接口。结果：医保接口文档升级了，你得改 HIS；HMO 接口换了，你还得改 HIS。
• 正确架构：HIS → 集成中台 ESB → 各外部接口（医保/HMO/商保/体检中心）。所有外部接口的协议转换、报文加签、证书管理都在 ESB 层做。
• HIS 只认一套内部标准报文（比如处方上传、费用结算、门诊登记），ESB 负责翻译成医保要求的格式、HMO 要求的格式。
• 好处：医保接口升级，改 ESB 层就行，HIS 不用动；HMO 新增一家，只需要在 ESB 上加一个适配器。

「系统解耦」四个字在医疗行业不是架构口号，是门诊能不能正常开门的生命线。

第二层：传输可靠性——每一笔交易的三次确认机制

医疗结算最怕「单边账」：门诊 HIS 显示医保结算成功了，医保中心那边没收到。或者反过来，医保扣了钱，HIS 没收到成功回执。

解决方案是「三次握手 + 幂等」：

第一次：HIS 发请求 → ESB 生成唯一流水号（门诊号 + 日期 + 序号）→ 发往医保；

第二次：医保返回结果 → ESB 持久化结果到本地（不管成功失败都存）→ 通知 HIS；

第三次：HIS 收到结果后回发一个「已收到」确认 → ESB 标记流水完成。

如果 30 秒内没收到上一步的确认，自动发起「状态查询」。任何流水号重复发送都返回上一次的结果（幂等），不会重复扣费。

第三层：降级方案——医保断网 2 小时也能正常接诊

医保中心的接口每个月总有那么几个小时不稳定（升级、维护、网络抖动）。你不能让门诊跟着停摆。

降级策略：ESB 检测到医保接口连续 3 次超时或失败 → 自动切换到「医保离线模式」：

门诊正常挂号、就诊、开处方、结算——所有原本要实时上传医保的数据先写入本地「离线队列」，给病人走「医保垫付」流程，打印全额垫付单据，告知患者「医保恢复后 3 个工作日内自动补结算，多退少补」。

医保接口恢复后（ESB 自动探测心跳），离线队列按顺序自动重传。重传成功率要求 100%，失败的进入人工补偿池。

第四层：对账与补偿——T+1 自动勾稽，差额自动定位

即使有了上面三层，仍然会出现极端情况：比如网络闪断导致某一笔的回执丢了，两边状态不一致。

所以必须有「T+1 自动对账」：每天凌晨 2 点，ESB 拉取前一天医保中心的所有结算明细，和 HIS 的本地结算明细按流水号一一比对。

比对结果分四类：① 完全匹配 → 标记 OK；② HIS 有医保无 → 触发补偿上传；③ 医保有 HIS 无 → 触发 HIS 补录并报警（可能是 HIS 丢单）；④ 金额不一致 → 进入人工对账池。

99% 的差额都能自动处理。剩下的 1% 人工一看就能定位，不用再花 3 天翻凭证。

HMO 对接的额外注意点

• HMO（商业医保）的接口标准远比公立医保混乱——每家保险公司的协议都不一样，要提前做好适配器开发
• 理赔规则差异大：有的 HMO 要求处方上传时就判定理赔范围，有的是事后结算。ESB 层要能支持「规则插件化」
• 理赔对账周期通常是周结/月结，对账文件格式每家不同（有的是 Excel 邮件、有的是 SFTP、有的是 API 拉取），要做统一对账文件解析层
• HMO 客户的体验要做好：就诊时实时显示「本次就诊商保报销 X 元，自付 Y 元」，别让患者出院了才知道报不了

落地自测：你的门诊系统稳吗？

• □ HIS 是否直接对接外部接口？是 → 考虑加 ESB 解耦
• □ 每笔交易是否有唯一流水号和幂等机制？没有 → 单边账风险极高
• □ 医保断网 2 小时能不能正常接诊？不能 → 补离线降级方案
• □ 有没有 T+1 自动对账和差额补偿？没有 → 月底财务苦不堪言
• □ 近 3 个月因系统问题导致的医疗纠纷 > 0 次？有 → 立刻启动稳定性改造