成都市医保结算清单数据采集接口规范V1.0
第1章接口报文格式

第1章接口报文格式1.1接口输入报文格式定义报文采用JSoN格式,交易参数定义如下:12接口输出报文格式定义报文采用JSON格式,交易参数定义如下:表2交易输出参数定义1.3交易状态码说明交易状态码(infcode)规格如下:14重点说明•调用交易时INPUT、OUTPUT节点应按照接口安全相关要求进行签名。
•时间格式代码说明:yyyy(年,4位)、MM(月,2位)、dd(日,2位)、HH(24小时制,2位)、Inm(分钟,2位)、SS(秒,2位)、SSS(毫秒,3位)。
•日期时间型的数据元(例如开始时间)格式为:yyyy-MM-ddHH:mm:ss;日期型的数据元(例如开始日期)格式为:yyyy-MM-ddo•查询中输入开始结束时间,格式为yyyy-MM-dd,时间范围默认开始于00:00:00,结束于23:59:59o例如时间2023-01-01-2023-01-02则匹配时间2023-01-0100:00:00-2023-01-0223:59:59的数据。
•报文中的输入/输出项的字符型串中的根节点和各个子节点一律小写。
•类型为数值的参数,如果为空,必须传“0”,其他为空串(“"),TXT文件中空值使用“mi11”o•TXT文件使用字符集为UTF-8o•接口说明中声明的输入为输入报文中INPUT属性内容,输出为输出报文中OUTPUT属性内容。
•接口输入、输出数据元代码标识为“Y”的,字典内容参照文章中字典表部分内容。
•报文中INPUT/OUTPUT(输入信息/输出信息)要符合JSON格式的约定。
•如果信息中出现的下列字符,需要进行转义处理:1、转义为;2、“\”转义为“\\\\"。
15接口说明1.5.1.114101】医疗保障基金结算清单信息上传1.5.1.1.1交易说明通过此交易上传医疗保障基金结算清单信息。
1. 5.1.1.2重点说明1、交易输入结算清单信息为单行数据,输入其他信息均为多行数据;2、输入项信息按照《医疗保障基金结算清单填写规范》中的规范要求填写;3、每次接口调用只上传一位患者的信息。
BOSS系统技术规范(v1.0)

B O S S系统技术规范(v1.0)-CAL-FENGHAI-(2020YEAR-YICAI)_JINGBIAN中国移动业务运营支撑系统(BOSS)技术规范(1.0版)中国移动通信集团公司二○○一年四月目录目录 (3)1.总则 (8)1.1.概述 (8)1.2.目标和原则 (8)1.3.适用范围 (9)1.4.起草单位 (9)1.5.解释权 (10)2.BOSS系统的体系结构 (11)2.1.BOSS系统的等级结构 (11)2.2.BOSS系统的三层结构 (11)2.2.1.三层结构 (11)2.2.2.数据核心层............................................................... 错误!未定义书签。
2.2.3.业务逻辑层............................................................... 错误!未定义书签。
2.2.4.接入层....................................................................... 错误!未定义书签。
2.3.BOSS系统三层平台之间的关系 (15)2.4.BOSS系统的功能划分 (15)3.BOSS系统实体模型 (16)3.1.BOSS系统实体模型 (16)3.2.BOSS系统实体的说明及其属性 (18)3.2.1.客户管理类实体 (18)3.2.2.定单管理类实体 (18)3.2.3.产品及资费管理类实体 (19)3.2.4.资源管理类实体 (19)3.2.5.采集管理类实体 (20)3.2.6.结算管理类实体 (20)3.2.7.计费帐务管理类实体 (20)3.2.9.系统管理类实体 (22)3.3.BOSS系统实体间的关系 (23)3.3.1.客户管理类实体间关系 (23)3.3.2.定单管理类实体间关系 (23)3.3.3.产品及资费管理类实体间关系 (24)3.3.4.资源管理类实体间关系 (24)3.3.5.采集管理类实体间关系 (24)3.3.6.结算管理类实体间关系 (25)3.3.7.计费帐务管理类实体间关系 (25)3.3.8.配置管理类实体间关系 (26)3.3.9.系统管理类实体间关系 (27)4.BOSS系统业务功能实现 (27)4.1.客服与业务管理 (27)4.1.1.业务函数 (27)4.1.2.业务受理 (31)4.1.3.质量管理 (45)4.1.4.信息服务 (48)4.1.5.收费管理 (52)4.1.6.产品及资费管理 (63)4.1.7.客户管理 (66)4.1.8.大客户管理 (71)4.1.9.代销商管理 (73)4.1.10.资源管理 (75)4.2.计费结算 (83)4.2.1.业务函数 (83)4.2.2.功能描述 (84)4.2.3.功能实现总体结构 (85)4.3.帐务处理 (92)4.3.2.出帐处理 (93)4.3.3.帐务管理 (96)4.4.系统管理 (105)4.4.1.监控 (105)4.4.2.权限管理 (109)5.网络组织结构 (111)5.1.全国中心网络组织 (113)5.1.1.全国中心局域网拓扑结构 (113)5.1.2.全国中心与省中心的连接 (115)5.1.3.容灾备份中心与省中心的连接 (115)5.1.4.全国中心与中国移动其它计算机系统的连接 (115)5.1.5.全国中心与非中国移动的计算机系统的连接 (116)5.1.6.全国中心与电话通信网的连接 (116)5.2.省中心网络组织 (117)5.2.1.省中心局域网的组织 (117)5.2.2.省中心到地市的广域网连接 (119)5.2.3.省中心与中国移动其它计算机系统的连接 (119)5.2.4.省中心与国内非中国移动的计算机系统的连接 (120)5.2.5.省中心与移动通信网网元的连接 (120)5.2.6.省中心与电话通信网的连接 (120)5.3.BOSS系统使用的主要设备 (121)5.4.IP地址规划 (122)5.4.1.原则 (122)5.4.2.方法 (122)5.4.3.要求 (122)6.系统要求 (124)6.1.主机系统 (124)6.3.存储备份设备 (126)6.3.1.存储设备 (126)6.3.2.备份设备 (126)6.4.网络设备 (127)6.4.1.核心网络设备 (127)6.4.2.防火墙 (127)6.5.数据库 (128)6.6.开发工具 (129)6.7.应用软件 (129)6.8.系统测试环境 (130)6.9.系统文档资料 (130)6.10.设备选型原则 (131)7.BOSS系统的外部接口 (133)7.1.BOSS系统与通信网元的接口 (134)7.1.1.与移动交换机的接口 (134)7.1.2.与HLR、AUC的接口 (135)7.1.3.与短信中心的接口 (135)7.1.4.与语音信箱平台的接口 (136)7.1.5.与电话通信网的接口 (136)7.2.BOSS系统与公司内其它计算机系统的接口 (136)7.2.1.与MIS系统的接口 (137)7.2.2.与通信网网管系统的接口 (137)7.2.3.与WAP平台的接口 (137)7.2.4.与MISC平台的接口 (137)7.2.5.与IP计费认证中心的接口 (138)7.2.6.与其它增值业务逻辑层的接口 (139)7.3.BOSS系统与非中国移动计算机系统的接口 (139)7.3.1.与银行、邮储等计算机系统的接口 (140)7.3.2.与互联网的接口 (140)7.3.3.与其它电信运营者的接口 (140)7.3.4.与SP的接口 (141)7.4.全国中心与省中心之间的接口 (141)8.可靠性与安全 (142)8.1.系统可靠性 (142)8.1.1.网络 (142)8.1.2.主机 (142)8.1.3.存储、备份及恢复 (143)8.1.4.应用系统 (143)8.2.信息安全 (143)8.2.1.网络安全 (143)8.2.2.系统安全 (145)8.2.3.应用软件安全 (145)8.3.环境安全 (146)8.4.安全管理措施 (146)9.机房环境要求 (148)9.1.机房环境条件 (148)9.2.接地要求 (149)9.3.空调及电源 (150)1.总则1.1. 概述为了提高中国移动的服务水平、管理水平和经营决策水平,为客户提供及时、准确和高质量的服务,使中国移动向世界一流通信运营企业迈进,从技术上指导建立高效、科学的中国移动BOSS系统(Business & Operation Support System,业务运营支撑系统),依据《BOSS系统业务规范》,特制定本规范。
一、总体要求

一、总体要求1、项目完工时间要求:合同签订后7个工作日内完成全国住房公积金数据平台接入及住房公积金银行结算数据应用系统接口升级,若未按规定时间内完成,采购人有权终止中标人中标资格。
2、为确保售后服务质量,投标方必须在安徽省内注册或设有分支机构,需提供营业执照证明。
3、提供2年免费维保服务。
在维保期内,需要提供7*24小时响应服务,若出现故障,需保证在3小时内到达现场,到达现场后5个小时内解决,直到故障排除。
4、此次项目建设中涉及到中心业务核心系统的改造,相关改造费用包含在此次项目中,不再另行增加预算,投标方自行勘查现场,与业务核心系统承建商做好对接工作,且中心不更换业务核心系统。
5、本次结算应用系统2.0数据接口升级是由原有《住房公积金银行结算数据应用系统-与公积金中心公共接口标准V1.0.0》基础上升级,供应商在进行升级时,必须兼顾原有接口已生成待处理及在途的结算数据,确保兼容性。
6、有相关全国住房公积金数据平台接入及住房公积金银行结算数据应用系统经验的择优。
二、结算应用系统2.0 数据接口升级贯彻落实《关于印发住房公积金结算应用系统新版接口标准的通知》(建金信函〔2018〕47 号)要求,依据《住房公积金银行结算数据应用系统-与公积金中心公共接口标准V2.0.1》新版接口标准,对原有接口进行升级改造,及新增加接口的开发。
1、结算应用系统接口新增(BDC200)联行号模糊查询;系统按照新的接口功能开发联行号模糊查询模块,根据银行名称、地区名称和关键字等信息进行联行号模糊查询。
2、结算应用系统接口新增(BDC300)账户状态及信息查询;系统按照新的接口功能开发账户信息及状态查询模块,根据账户名称、账号、身份证号等信息查询账户上述信息是否一致,是否存在影响收付款的账户状态,是否一类账户。
此接口功能应用场景为支取、销户时判断账户是否有效,个人扣款(缴存扣款、贷款扣款)时存量账户及新增账户信息校验及账户有效性验证。
医院医保接口设备管理制度

第一章总则第一条为加强医院医保接口设备的管理,确保医保接口设备的正常运行,提高医保结算效率,保障医患双方合法权益,根据《中华人民共和国社会保险法》等相关法律法规,结合我院实际情况,特制定本制度。
第二条本制度适用于我院所有医保接口设备的采购、安装、使用、维护、报废等各个环节。
第三条医保接口设备管理遵循以下原则:1. 规范化:严格执行国家、地方及行业相关法律法规,确保医保接口设备管理规范有序。
2. 安全性:确保医保接口设备运行安全可靠,保障医保数据传输安全。
3. 高效性:提高医保结算效率,确保医患双方权益。
4. 经济性:合理使用医保接口设备,降低运行成本。
第二章职责分工第四条医院医保管理部门负责医保接口设备的整体规划、采购、安装、验收、维护和报废等工作。
第五条信息部门负责医保接口设备的网络接入、调试、运行监控及故障处理。
第六条财务部门负责医保接口设备的资金预算、采购支付及报销审核。
第七条使用部门负责医保接口设备的日常使用、维护和保养。
第三章设备采购与验收第八条医保接口设备的采购应严格按照国家、地方及行业相关法律法规进行,确保设备质量符合要求。
第九条采购医保接口设备前,医保管理部门应进行市场调研,比选供应商,并报经医院领导批准。
第十条采购的医保接口设备应具备以下条件:1. 符合国家、地方及行业相关法律法规要求;2. 具有完善的售后服务体系;3. 具有良好的市场口碑。
第十一条设备验收应严格按照采购合同、设备清单及验收标准进行,确保设备质量合格。
第四章设备安装与调试第十二条医保接口设备的安装应由具有资质的专业人员进行,确保设备安装到位、安全可靠。
第十三条设备安装完成后,应由信息部门进行调试,确保设备与医院信息系统兼容,满足医保结算需求。
第五章设备使用与维护第十四条使用部门应严格按照医保接口设备操作规程进行操作,确保设备正常运行。
第十五条使用部门应定期对医保接口设备进行维护和保养,确保设备处于良好状态。
第十六条信息部门应定期对医保接口设备进行运行监控,发现异常情况及时处理。
国家医疗保障疾病诊断相关分组(CHS-DRG)分组与付费技术规范(可编辑)

国家医疗保障疾病诊断相关分组(CHS-DRG)分组与付费技术规范(China Healthcare Security Diagnosis RelatedGroups,CHS-DRG)基于《国家医疗保障局印发疾病诊断相关分组(DRG)付费国家试点技术规范和分组方案》格式整理国家医疗保障局2019 年10 月编写说明按疾病诊断相关分组(DRG)支付是世界公认的较为先进和科学的支付方式之一,是有效控制医疗费用不合理增长,建立公立医院运行补偿新机制,实现医保患三方共赢和推进分级诊疗促进服务模式转变的重要手段。
近年来,国内也有部分地区开展了DRG 支付方式改革的探索,但版本众多,技术标准差异较大,运行情况和成效也有较大差别。
DRG 支付方式改革作为一项关键技术,也成为国家医保局成立以来的重要职责之一。
为此,国家医保局组织形成专家团队形成了医保DRG 支付方式改革分组标准与技术规范。
医保DRG 支付方式改革包括DRG 分组和付费两部分。
其中规范和科学分组是DRG 实施的重要前提,精确付费是DRG 实施的重要保障。
国家和地方实施医保DRG 支付方式改革,需要具备一定的如病案质量、统一编码和监管能力等基础条件,同时,还需要开展规范数据采集流程和审核等前期工作。
分组作为一项较为复杂的技术,需以临床经验和统计校验相结合,在遵循临床诊疗分类和操作技术等的基础上,对疾病诊断、手术、操作等遵循“临床特征相似,资源消耗相近”的原则,通过统计学分析进行验算,实现从MDC 到ADRG,直至DRG 组的逐类细化。
本规范在综述国外不同国家和国内不同版本的DRG 的主要做法和经验的基础上,主要针对DRG 分组和付费技术进行了表述。
由于时间有限,可能存在较多不足,还有待在全国试点过程中不断完善。
编委会2019 年10 月目录主要名词和缩略语表 (1)1. CHS-DRG 付费概述 (3)1.1 DRG 基本概念 (3)1.2 医保DRG 付费目标 (3)1.3 DRG 付费适用范围 (4)2.CHS-DRG 的实施条件和数据准备 (4)2.1 CHS-DRG 实施的基本条件 (4)2.2 CHS-DRG 实施的数据准备 (6)2.3 数据标化和上传 (8)2.4 数据审核 (10)3. CHS-DRG 分组策略与方法 (11)3.1 分组原则 (11)3.2 分组策略 (11)3.3 病组命名和编码规则 (13)3.4 分组过程和方法 (14)3.4.1 先期分组(Pre-MDC)的筛选原则与方法 (14)3.4.2 主要诊断大类(MDC)确定原则与方法 (15)3.4.3 核心疾病诊断相关组(ADRG)确定原则与方法 (17)3.4.4 细分DRG 的原则与方法 (18)3.5 分组效能评价 (22)4. CHS-DRG 相对权重计算与调整 (23)4.1 概念与内涵 (23)4.2 设定原则 (23)4.3 基础权重计算方法 (24)4.4 权重调整 (25)5. CHS-DRG 费率与付费标准测算 (26)5.1 基本思路 (26)5.2 测算原则 (27)5.3 测算流程 (27)5.4 测算方法 (27)5.5 费率与付费标准的验证与调整 (29)6. CHS-DRG 结算细则制定与实施 (31)6.1 制订结算细则的目的 (31)6.2 结算细则的主要内容 (31)6.3 DRG 结算效果评估与细则的修订 (36)7. CHS-DRG 监管考核与评价 (36)7.1 监管考核的目的与意义 (36)7.2 考核主体和对象 (37)7.3 DRG 监管考核指标体系 (37)7.4 考核办法和考核周期 (39)7.5 考核兑现与激励 (39)7.6 综合监测与评价 (39)附件1 CHS-DRG 核心疾病诊断相关组(ADRG)目录 (41)主要名词和缩略语表1.主要诊断大类(Major Diagnostic Category,MDC)2.核心疾病诊断相关组(Adjacent Diagnosis Related Groups,ADRG)3.疾病诊断相关分组(Diagnosis Related Groups, DRG)4.疾病诊断相关分组-预付费(Diagnosis Related Groups-Prospective Payment System, DRG-PPS)5.先期分组(Pre-Major Diagnostic Category, Pre-MDC)6.并发症与合并症(Complication & Comorbidity, CC)7.严重并发症与合并症(Major Complication & Comorbidity,MCC)8. 《疾病和有关健康问题的国际统计分类》第10 次修订本(International Classification of Diseases, Tenth Revision, ICD-10) 9. 国际疾病分类第9 版临床修订本第3 卷(InternationalClassification of Diseases, Ninth Revision, Clinical Modification, ICD-9-CM-3)10.变异系数(Coefficient of Variation, CV)11.总体变异减低系数(Reduction in Variance, RIV)12.DRG 相对权重(Related Weight, RW)13.费率(Payment Rate)14.病例组合指数(Case Mix Index, CMI)15.费用消耗指数(charge consumption index)16.时间消耗指数(time consumption index)17.死亡风险评分(Risk of mortality)国家医疗保障疾病诊断相关分组(CHS-DRG)分组与付费技术规范1.CHS-DRG 付费概述1.1 DRG 基本概念疾病诊断相关组(Diagnosis Related Groups,DRG)是用于衡量医疗服务质量效率以及进行医保支付的一个重要工具。
区本级医保支付接口规范

新疆(区本级)医保系统支付接口应用编程接口规范(初稿)银海软件2009年11月1、概述1.《新疆(区本级)医保系统支付接口应用编程接口规范》(以下简称规范)的使用对象为将使用银海医保支付组件库(以下简称组件库)来完成医保支付的为定点医疗机构提供应用软件的HIS供应商、药店MIS供应商或其它第三方应用软件供应商。
2.规范公布了组件库所提供的交易,规定了调用每一交易的前提条件,详细描述了每一交易的调用方法。
规范从编程的角度来介绍以上内容,对医保政策和医保支付流程的介绍不属于本规范的范围。
§1.1.术语及参考资料COM:Common Object ModelHIS:Hospital Information SystemMIS:Management Information System§1.2.应用模式1.银海医保支付组件库是一组运行在WINDOWS 32位环境下的COM组件,第三方应用软件使用相应的COM组件调用方式来调用它。
§1.3.环境要求§1.3.1.硬件环境2.2新疆(区本级)医保支付接口应用编程接口规范第 3 页 共 101 页§1.3.2. 网络环境§1.3.3. 网络拓扑图医院接口处理网络拓扑图§1.3.4. 系统软件§2.接口描述§2.1.总体描述1.组件库注册在每一台需要进行医保支付业务的客户机上(该客户端也必须能连接到医保网络),通过被动调用的方式将医保支付业务功能嵌入到定点医疗机构的系统中(以下简称HIS);2.接口交易组件库提供了六个公共方法(yh_interface_init 初始化,yh_interface_destroy 资源释放,yh_interface_call业务方法调用,yh_interface_confirm业务办理确认,yh_interface_cancel业务办理取消,yh_interface_getuncertaintytrade不确定交易查询),交易参数组织采用xml(所有社保经办机构交易调用及交易参数统一),差别处理对于HIS透明。
医保结算清单分析与质控

医保结算清单分析与质控医保结算清单是医疗机构与医保部门间的统一结算凭证,在国家医保局下发的文件中,对医保结算清单各项填写,进行了详细说明和指导。
如果填写不规范,不符合医保的要求,很有可能出现医保拒付的情况,直接影响到医院的经济利益。
一、医保结算清单三大功能医保结算清单实际上是在国家2011版住院病案首页、2019版医疗收费票据、国家异地就医结算单等其他结算凭证的基础上增加了用于医保费用结算的部分形成的。
其主要有三大功能。
一是用于医保审核与结算。
通过构建诊疗规则库,将住院诊疗信息和医疗收费信息匹配分析,对违规医疗行为稽核并做扣款等方式处理,提高医保基金的使用效率。
二是为DRG/DIP付费提供统一的医保信息采集标准,是各地医保局DRG/DIP数据采集的“唯一来源”。
医保结算清单的使用可以规范院内医保费用结算工作制度,有利于院内进行成本管理、临床路径管控。
三是方便医保局进行数据统计分析。
医保结算清单通过统一全国各地结算数据标准,可为CHS-DRG/DIP的细分规范提供统一、高质量的数据标准,方便后期国家医保局对权重、费率的测算,也方便为不同地区医院提供科学对标数据。
此外,还为推动全国临床路径建立,提供了大数据支撑。
二、适用范围医保结算清单具备普适性,能满足各种类型医保结算需求:L医院类型:各级各类医保定点医疗机构2.服务类型:门急诊住院、日间手术、门诊慢特病3.支付方式:现行各类医保支付方式三、清单与首页差异聚焦Ol目的不同医保清单:申请费用结算时提交的数据清单,开展大数据分析的重要工具。
病案首页:提高医疗机构科学化、规范化、精细化、信息化管理水平,加强医疗管理控制,完善病案管理,为付费方式改革提供技术基础。
02设计思路医保清单遵循“适用性、一致性、规范性”原则,而病案首页遵循“可及性、科学性、客观性、便捷性”原则。
03填写规范医保结算清单主要诊断的定义是经医疗机构诊治确定的导致患者本次住院就医主要原因的疾病(或健康状况),突出医疗资源消耗;而病案首页主要诊断一般是患者住院的理由,原则上应选择本次住院对患者健康危害最大、消耗医疗资源最多、住院时间最长的疾病诊断,突出疾病难易程度。
各级医疗机构(医院)医保系统API接口联调确认单

医疗机构名称 医疗机构编码 联调测试地址
确认接口列表
医疗机构基本信息
业 务 范 普通门诊 门慢特业务
购药业务
围
住院业务 异地就医业务
1、功能模块检查:
读卡接口
电子凭证
通过 不通过
社保卡
通过 不通过
通用类接口
【1101】人员信息获取
通过 不通过
【9001】签到
读卡接口电子凭证通过不通过身份证通过不通过社保卡通过不通过通用类接口1101人员信息获取通过不通过2001人员待遇享受检查通过不通过9001签到通过不通过9002签退通过不通过9101文件上传通过不通过9102文件下载通过不通过2601冲正交易通过不通过药店结算接口2101药店预结算通过不通过2102药店结算通过不通过2103药店结算撤销通过不通过门诊结算接口2201门诊挂号通过不通过2202门诊挂号撤销通过不通过2203门诊就诊信息上传通过不通过2204门诊费用明细信息上传通过不通过2205门诊费用明细信息撤销通过不通过2206门诊预结算通过不通过2207门诊结算通过不通过2208门诊结算撤销通过不通过住院办理接口2401入院办理通过不通过2402出院办理通过不通过2403住院信息变更通过不通过2404入院撤销通过不通过2405出院撤销通过不通过住院结算接口2301住院费用明细上传通过不通过2302住院费用明细撤销通过不通过2303住院预结算通过不通过2304住院结算通过不通过2305住院结算撤销通过不通过人员备案接口2501转院备案通过不通过2502转院备案撤销通过不通过2503人员慢特病备案通过不通过2504人员慢特病备案撤销通过不通过2505人员定点备案通过不通过2506人员定点备案撤销通过不通过明细审核及对账接口3101明细审核事前分析服务通过不通过3102明细审核事中分析服务通过不通过3201医药机构费用结算对总通过不通过3202医药机构费用结算对明细通过不通过信息采集接口4101医疗保障基金结算清单信息上传通过不通过4201自费病人费用明细信息上通过不通过4301门急诊诊疗记录通过不通过4302急诊留观手术及抢救信息通过不通过4401住院病案首页信息通过不通过4402住院医嘱记录通过不通过4501临床检查报告记录通过不通过4502临床检验报告记录通过不通过4503细菌培养报告记录通过不通过4504药敏记录报告记录通过不通过4505病理检查报告记录通过不通过4506非结构化报告记录通过不通过4601输血信息通过不通过4602护理操作生命体征测量记通过不通过4701电子病历上传通过不通过信息查询接口5101科室信息查询通过不通过5102医执人员信息查询通过不通过5201就诊信息查询通过不通过5202诊断信息查询通过不通过5203结算信息查询通过不通过5204费用明细查询通过不通过5205人员慢特病用药记
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
成都市医保结算清单数据采集接口规范
V1.0
成都市医保局
2020年03月
历史记录
目录
§1 概述 (5)
§1.1 文档编制目的 (5)
§1.2 目标 (5)
§1.3 术语和定义 (5)
1.3.1 交易Transaction (5)
1.3.2 消息Message (5)
1.3.3 请求消息Request Message (6)
1.3.4 应答消息Response Message (6)
1.3.5 报文Datagram (6)
1.3.6 请求方Requester (6)
1.3.7 应答方Responsor (6)
1.3.8 元素Element (6)
1.3.9 属性Attribute (6)
§1.4 采集指标项说明 (6)
§2 平台接口设计 (7)
§2.1 平台接口接入模式 (7)
§2.1.1 平台webservice接口模式 (7)
§2.2 平台接口调用流程 (8)
§2.3.1 数据采集交易调用流程 (8)
§2.3.2 数据采集交互流程 (8)
§3 平台接口交易详细设计 (9)
§3.1 交易说明 (9)
3.1.1 交易模式 (9)
3.1.2 交易安全性 (9)
3.1.3 交易错误处理 (9)
3.1.4 交易数据格式 (9)
§3.2 交易定义 (9)
3.2.1 数据采集交易定义 (9)
§3.3 消息报文定义 (10)
§3.3.1 消息报文结构 (10)
3.3.1.1 请求消息报文结构 (10)
3.3.1.2 应答消息报文结构 (10)
§3.3.2 消息头报文结构 (10)
3.3.2.1 请求消息头报文 (10)
3.3.2.2 应答消息头报文 (11)
§3.4 交易详细设计 (12)
3.4.1 数据采集交易详细设计 (12)
3.4.1.1 申请流水号 (E1001) (12)
3.4.1.2 数据上报 (E1002) (13)
3.4.1.3 数据撤销 (E1003) (17)
3.4.1.4 查询校验结果 (E1004) (18)
§4 附录 (19)
§4.1 结算清单指标项采集说明 (19)
§4.2 查询调用示例: (19)
§1 概述
根据《国家医疗保障局关于印发医疗保障标准化工作指导意见的通知》(医保发﹝2019﹞39号)、《国家医疗保障局关于开展医疗信息业务编码标准相关工作的通知》(医保发﹝2019﹞42号)、《四川省医疗保障局关于开展医疗保障信息业务编码相关工作的通知》(川医保办发〔2019〕36号)等要求,制定本次结算清单数据采集指标项及采集内容。
§1.1 文档编制目的
本接口规范文档主要表述成都市医保结算清单数据采集平台和第三方系统的接口设计方案,内容包含了接口的部署方案以及软件接口设计等内容。
本文档的阅读对象包括第三方系统开发商的软件设计人员、软件开发人员及软件实施人员。
§1.2 目标
为了保证成都市医保结算清算数据采集平台和第三方系统的完整性和独立性以及数据的同步性和一致性,需要提供一个标准的数据输入输出接口,建立一个公用的数据交换标准。
本接口提供一套API标准函数完成嵌入模块功能,只要将其嵌入到第三方系统即可完成数据交换。
§1.3 术语和定义
1.3.1交易Transaction
交易指计算机系统间通过结构化的数据交换来完成相应业务的事务处理单元。
1.3.2消息Message
消息是交易处理过程中数据交换的载体,用可扩展标记语言(XML)进行结构化描述的数据集合,内部封装了交易所需的信息,不设定或标识任何通信(头或尾、协议或字符码)
或保密的相关内容。
1.3.3请求消息Request Message
请求消息是交易涉及的一方向另一方提出业务处理申请的消息,消息中封装了与该业务处理所需的相关信息。
1.3.4应答消息Response Message
应答消息是消息应答方向消息请求方就其所发出的请求消息所发送的一个回复信息,回复信息里面应当包含处理情况或者处理结果。
1.3.5报文Datagram
报文是用于在机构之间交换信息的数据集合,它设定或标识了通信(头或尾、协议或字符码)或加密解密的有关内容,其主体部分是具体的消息。
1.3.6请求方Requester
请求消息的发送方,同时也是应答消息的接收方。
1.3.7应答方Responsor
请求消息的接收方,也是应答消息的发送方。
1.3.8元素Element
元素是某个数据集合内的具体数据项,是构成消息的最小单位。
1.3.9属性Attribute
属性是对象或者元素的特征,是对对象或者元素的进一步描述和说明,每个对象或者元素都可以有一个或者多个属性。
§1.4 采集指标项说明
医保结算清单共190个指标项,根据成都市医保系统实际情况,将指标项分为需通过本采集接口采集项75项,可通过原医保系统生成或提取115项,采集时将两部分数据进行组合
生成完整的结算清单数据指标项。
§2 平台接口设计
§2.1平台接口接入模式
§2.1.1平台webservice接口模式
平台统一提供webservice服务接口,第三方需要把对应的webservice服务接口内嵌到第三方系统里面,与数据采集平台交互时调用统一的webservice方法即可。
1、接口函数原型
public string MedPlatformInterface(string inputXml)
2、函数说明
完成所有数据采集平台业务的处理,具体描述在接口交易详细设计中描述。
3、输入参数说明
§2.2平台接口调用流程
§2.3.1数据采集交易调用流程
§2.3.2数据采集交互流程
§3 平台接口交易详细设计
§3.1交易说明
3.1.1交易模式
在本标准内,数据采集平台与第三方系统的交易均由两种消息组合,他们是请求消息和应答消息。
这样的模式通过交易代码将请求消息和应答消息关联起来。
3.1.2交易安全性
本标准建议通过对交易报文进行通信加密来提高交易的安全性,暂不规定具体的加密方法种类和措施。
3.1.3交易错误处理
在应答消息中会包含出错的消息,错误信息包括2个部分:第一部分包括整个交易状态(如:成功状态、失败状态,待处理状态等);第二部分包含对具体的错误信息的描述(如:发生什么错误等),所有的错误信息均采用标准化定义。
3.1.4交易数据格式
1.日期类型格式:yyyy-MM-dd
2.日期时间类型格式:yyyy-MM-dd HH:mm:ss
3.数字类型的节点不能为空值,没有数据时填0
4.没有数据的节点必须写<节点名></节点名>
5.所有节点必须小写
§3.2交易定义
3.2.1数据采集交易定义
§3.3消息报文定义
§3.3.1消息报文结构
消息分为两类,包括请求消息与应答消息。
消息由消息头和消息体组成,消息头包括了消息的标识信息,如交易代码等;消息体包括交易所需要的具体业务信息,如:数据上报、数据撤销、校验结果反馈信息等。
3.3.1.1请求消息报文结构
3.3.1.2应答消息报文结构
§3.3.2消息头报文结构
3.3.2.1请求消息头报文
3.3.2.2应答消息头报文
§3.4交易详细设计
3.4.1数据采集交易详细设计3.4.1.1申请流水号 (E1001)
3.4.1.2数据上报 (E1002)
3.4.1.3数据撤销 (E1003)
3.4.1.4查询校验结果 (E1004)
§4 附录
§4.1 结算清单指标项采集说明
结算清单指标项采集说明参考《医保结算清单术语集》
§4.2 查询调用示例:
测试地址:http://10.163.50.239:9501/med/services/ybJsShareService?wsdl 通用测试账号:
测试示例:
成都市医保结算清单数据采集接口规范V0.5
正式地址:http:// 10.163.27.38/med/services/ybJsShareService?wsdl ——————————————————————————————————————————————
第21 页/ 共21 页。