特殊门诊异地联网结算从备案到清算的完整链路文章目录特殊门诊异地联网结算从备案到清算的完整链路一、场景二、设计原则三、网上异地就医备案一个入口多路分发四、三级架构五、全流程从备案到清算六、病种目录对照最难的部分七、新增业务和修改业务八、各地差异九、总结参保地多改就医地少改。医疗机构甚至不用改。一、场景一个参保人在外地看特殊门诊。去之前先在线上办异地就医备案告诉系统我要去外地看病了。审批通过后在外地医院刷卡——系统要自动判断他有没有门诊大病待遇、能报哪些药、自付比例是多少。结算完参保地的医保基金要把钱划给就医地的医院。这背后是就医地、参保地、国家平台三级联动。二、设计原则这个系统的设计原则只有一条但很硬社保机构多改医疗机构少改甚至不改。参保地多改就医地少改。拆开就是三个决策医疗机构少改甚至不改——医院只负责读卡、登记、结算不关心报销规则。降低实施难度也降低医院的开发成本。就医地少改——保持智能审核等后台系统少改动便于监管。同住院原则一致——就医地目录参保地待遇。跟住院跨省结算一个规则参保人容易理解。这三条不是技术决策是落地决策。技术方案是根据这三条反推出来的。三、网上异地就医备案一个入口多路分发在去医院之前参保人要先在线上办备案。这个环节的核心问题不是审批是路由——备案申请要根据参保人的身份和参保地转发到正确的后台系统。参保人在线申请备案 │ ▼ 读取个人基本信息 │ ├─ 职工身份 → 调核心系统 → 查是否封锁 → 推送备案 │ └─ 居民身份 → 调城乡居民系统 → 查是否封锁 → 推送备案 │ └─ 不同参保地的居民系统不同按行政区划分发同一个备案页面后端根据参保人的身份类型和所属统筹区把请求路由到不同的系统。参保人完全不知道背后有多个系统在跑——他只看到一个提交按钮。伪代码实现// 备案路由分发 function 异地就医备案(身份证号, 就医省份, 就医医院): person 读取基本信息(身份证号) // 根据身份类型和参保地路由到不同系统 if person.身份类型 职工: // 全省职工统一走核心系统 result 核心系统.查询是否封锁(person.ID) if result.已封锁: return error(参保状态异常: result.封锁原因) 核心系统.推送备案(person.ID, 就医省份, 就医医院) elif person.身份类型 居民: // 居民系统分散在不同统筹区按行政区划路由 system 获取居民系统(person.参保行政区划) result system.查询是否封锁(person.ID) if result.已封锁: return error(参保状态异常: result.封锁原因) system.推送备案(person.ID, 就医省份, 就医医院) // 审批异步 task 创建备案审批任务(person, 就医省份, 就医医院) if 自动审批通过(task): // 无封锁的直接通过 短信通知(person.手机号, 异地就医备案已通过有效期至 计算有效期()) else: 转人工审批(task) // 有封锁的转人工 return 备案申请已提交 // 病种目录对照 function 病种查询转换(医院请求): // 由部平台转发到参保地 参保地 医院请求.参保地行政区划 本地审批 参保地系统.查询特殊病种审批(医院请求.身份证号) if 本地审批 is None: return error(无特殊病种审批记录) // 病种编码转换参保地编码 → 就医地编码 对照表 获取病种对照表(参保地, 医院请求.就医地行政区划) 就医地编码 对照表[本地审批.病种编码] if 就医地编码 is None: return error(该病种在就医地无对应编码) return {病种编码: 就医地编码, 审批时间: 本地审批.审批时间, 有效期: 本地审批.有效期}备案审批是异步的。申请提交后后台系统自动查参保人是否处于封锁状态欠费、待遇暂停没封锁的直接通过。有封锁的转人工。审批结果回调给前端短信通知。备案是联网结算的前置条件。没备案医院刷卡时会提示未备案不能走直接结算只能拿发票回去手工报销。四、三级架构就医地医院 │ ▼ 就医地医保平台 │ ▼ 国家平台部平台转发 │ ▼ 参保地医保平台 → 参保地核心系统医院的请求不直接发给参保地。全部经过就医地平台 → 部平台转发 → 参保地平台。国家平台是总路由保证任何两省之间的数据交换都走统一通道。五、全流程从备案到清算网上备案 → 审批通过 │ ▼ 医院读卡 → 查询特殊病种审批到参保地查审批信息 → 门诊登记就医地登记就诊信息 → 门诊结算费用、目录、报销计算 → 撤销结算支持退费 → 上传费用传给部平台 → 撤销登记 → 对账就医地和参保地对费用明细 → 清算基金划拨备案只做一次有效期半年到一年。有效期内去同一家医院复诊不用重新备案。每一步对应一个交易有成功有失败。撤销类操作支持回退——撤销结算后可以撤销登记。对账和清算是异步的不阻塞现场结算。六、病种目录对照最难的部分不同省份对门诊大病的定义不一样。同样的病甲省叫特殊病种乙省可能叫门诊特定病种。编码也不同。解决方案就医地上传本地的特殊病种目录到部平台。参保地从部平台下载就医地的病种目录做对照——把乙省的编码对到自己的编码上。查询时医院发起特殊病种审批查询 → 部平台转发给参保地 → 参保地查到自己系统里的审批记录 → 把审批信息中的病种编码转换成就医地的编码 → 返回给医院。医院查询请求 │ ▼ 部平台转发 │ ▼ 参保地查询审批 ├─ 有审批 → 病种转换本地编码 → 就医地编码→ 返回审批信息 └─ 无审批 → 返回错误及原因病种对照是线下完成的查询时只做一次转换毫秒级返回。七、新增业务和修改业务系统上线后又陆续加了几个业务业务发起方说明特殊病种上传就医地就医地上传本地的病种目录特殊病种下载参保地参保地下其他省病种目录特殊病种对照参保地本地编码→外地编码的对照表维护特殊病种审批查询就医地→部→参保地实时查询该患者在参保地的病种审批修改业务主要是目录更新新增病种、编码调整和特殊病种审批状态的变更。八、各地差异理论上一套规则全国通用但落地时各地差异很大各地自费的药品目录不同——A 省自费的药B 省可能报销各地乙类药品范围不同先自付比例也不同——同样的药不同省的自付比例可能差 10%部分地区相对简单——特殊门诊待遇不存在乙类药物主要差异就是乙类药品范围这些差异不能靠全国统一解决——统一不了。只能靠参保地待遇这条原则兜底参保人在哪里参保就按哪里的规则报销。费用明细是就医地传过来的报销计算是参保地算的。九、总结异地门诊结算跟住院结算逻辑完全一致但多了两个前置环节网上备案的路由分发和特殊病种的目录对照。整套设计最值钱的部分不是技术实现是开头那三条原则医疗机构少改甚至不改就医地少改同住院原则一致这三条保证了系统能被各省接住——不是写一个完美的方案让所有人迁就你而是写一个改得最少的方案让所有人能接。