CN110020955B - 在线医保信息处理方法及装置、服务器和用户终端 - Google Patents

Abstract

本申请涉及一种在线医保信息处理方法及装置、服务器和用户终端。该在线医保信息处理方法包括：接收请求报文，所述请求报文包括用户的社保信息和所述社保信息对应的城市标识；根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址；通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口；接收所述城市的医保系统接口根据所述社保信息获取的返回报文。根据本申请的技术方案，能够实现各地医保系统接口的统一接入和请求的分散处理。

Description

在线医保信息处理方法及装置、服务器和用户终端

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种在线医保信息处理方法及装置、服务器、用户终端和计算机可读介质。

背景技术

人力资源和社会保障局(下文，简称人社局)的医保系统负责受理基本医疗保险、工伤保险、生育保险和离休干部医药费等统筹基金的核定、支付、管理以及其它日常事务，为参加基本医疗保险、工伤保险和生育保险等的用人单位、职工、离休干部等提供相应的管理服务。

现有技术中，医院公众号需要直接与各地的人社局医保系统相连，而通常一个地市就有一个人社局，就有一套独立的医保系统，几乎全国各地市的人社局医保系统都不同，都是由不同开发商开发的，所以对外提供的接口也都不尽相同，医院公众号线上要实现医保在线支付和查询等，必须各家医院都要完成与各地的人社局医保系统的对接，包括开发、测试、联调、上线等步骤，实现周期长，用户体验差。

发明内容

本申请公开一种在线医保信息处理方法及装置、服务器、用户终端和计算机可读介质，能够实现各地医保系统接口的统一接入和请求的分散处理。

根据本申请公开的一个方面，提供一种在线医保信息处理方法，包括：接收请求报文，所述请求报文中包括用户的社保信息和所述社保信息对应的城市标识；根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址；通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口；接收所述城市的医保系统接口根据所述社保信息获取的返回报文。

在本申请公开的一种示例性实施例中，所述对应关系中一个城市对应一个独立的网关服务地址，且各个网关服务地址对应不同城市的医保系统接口。

在本申请公开的一种示例性实施例中，所述方法还包括：判断所述城市的医保系统接口接收到的请求并发数是否超过预设阈值；当超过所述预设阈值时，将所述请求报文对应的请求等待处理。

在本申请公开的一种示例性实施例中，所述方法还包括：当所述请求报文的来源IP存在于来源方白名单中时，对所述请求报文进行处理；当所述请求报文的来源IP不存在于所述来源方白名单中时，拒绝对所述请求报文进行处理。

在本申请公开的一种示例性实施例中，所述方法还包括：当所述请求报文的数据包完整时，进行校验签名；和/或解析所述返回报文，获取所述返回报文中的签名；根据签名规则，校验所述返回报文的签名是否正确；当所述返回报文的签名校验正确时，将所述返回报文转发至发送所述请求报文的业务平台。

在本申请公开的一种示例性实施例中，所述方法还包括：记录所述在线医保信息处理方法的执行日志；设置所述执行日志按级别显示。

根据本申请公开的一个方面，提供一种在线医保信息处理方法，包括：接收用户的社保信息；解析所述社保信息获取对应的城市标识；将所述用户的社保信息和所述社保信息对应的城市标识打包发送至用于连接各城市的医保系统的连接器系统。

根据本申请公开的一个方面，提供一种在线医保信息处理装置，包括：第一接收模块，用于接收请求报文，所述请求报文中包括用户的社保信息和所述社保信息对应的城市标识；查找模块，用于根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址；调用模块，用于通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口；第二接收模块，用于接收所述城市的医保系统接口根据所述社保信息获取的返回报文。

根据本申请公开的一个方面，提供一种在线医保信息处理装置，包括：输入模块，用于接收用户的社保信息；解析模块，用于解析所述社保信息获取对应的城市标识；发送模块，用于将所述用户的社保信息和所述社保信息对应的城市标识打包发送至用于连接各城市的医保系统的连接器系统。

根据本申请公开的一个方面，提供一种服务器，包括：至少一个处理器；存储装置，用于存储计算机程序；当所述计算机程序被所述至少一个处理器执行，使得所述至少一个处理器实现如上所述的在线医保信息处理方法。

根据本申请公开的一个方面，提供一种用户终端，包括：至少一个处理器；存储装置，用于存储计算机程序；当所述计算机程序被所述至少一个处理器执行，使得所述至少一个处理器实现如上所述的在线医保信息处理方法。

根据本申请公开的一个方面，提供一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现如上所述的在线医保信息处理方法。

根据本申请公开的实施例，通过对接收到的请求报文进行解析，获取该请求报文中的城市标识，并通过查找城市标识与网关服务地址的映射规则来获取该城市标识对应的城市的网关服务地址，从而能够根据该网关服务地址对应的网关服务调用所述城市的医保系统接口，接收该城市的医保系统接口的返回报文，因此，能够实现各地医保系统接口的统一接入和请求的分散处理。

附图说明

图1示出现有技术中的一种医保在线支付的流程图；

图2示出根据本申请一实施例的在线医保信息处理方法的流程图；

图3示出根据本申请另一实施例的在线医保信息处理方法的流程图；

图4示出根据本申请又一实施例的在线医保信息处理方法的流程图；

图5示出根据本申请再一实施例的在线医保信息处理方法的流程图；

图6示出根据本申请一实施例的在线医保信息处理装置的框图；

图7示出根据本申请另一实施例的在线医保信息处理装置的框图；

图8示出根据本申请又一实施例的在线医保信息处理装置的框图；

图9示出根据本申请一实施例的连接器系统的框图。

图10示出根据本申请一实施例的电子设备的框图。

具体实施例

现在将参考附图描述实施例。附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

如图1所示，现有技术中用户通过医院公众号进行在线支付的流程包括以下步骤：

1、医院公众号获取到用户扣费信息；

2、由医院公众号向当地人社局医保系统发起扣费请求；

3、当地人社局医保系统接收到该扣费请求，进行数据解包；

4、该人社局医保系统完成扣费，并向该医院公众号返回扣费结果。

图2示出根据本申请一实施例的在线医保信息处理方法的流程图。

如图2所示，该在线医保信息处理方法可以包括以下步骤：

在步骤S110中，接收请求报文，所述请求报文中包括用户的社保信息和所述社保信息对应的城市标识。

通过http(HyperText Transfer Protocol，超文本传输协议)协议传递的参数容易被拦截，从而可能导致潜在的危险，所以本申请实施例的Web API(ApplicationProgramming Interface，应用程序编程接口)接口层采用了https(全称：HypertextTransfer Protocol over Secure Socket Layer)协议，也就是采用SSL(Secure SocketLayer，安全套接层)对传输的请求报文进行安全性的加密。

https，是以安全为目标的http通道。即http下加入SSL层，https的安全基础是SSL，因此加密的内容就需要SSL。它是一个URI scheme(抽象标识符体系)，句法类同http:体系。用于安全的http数据传输。https:URL表明它使用了https，但https存在不同于http的默认端口及一个加密/身份验证层(在http与TCP之间)。这个系统提供了身份验证与加密通讯方法，可以被用于万维网上安全敏感的通讯，例如交易支付方面。

其中https协议需要到ca(是系统中通信双方信任的实体，被称为可信第三方(Trusted Third Party，简称TTP))申请证书。http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。http的连接很简单，是无状态的；https协议是由SSL+http协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

https有两种基本的加解密算法类型：

1)对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES(Data Encryption Standard，数据加密标准)、AES(AdvancedEncryption Standard，高级加密标准)等；

2)非对称加密：密钥成对出现(且根据公钥无法推知私钥，根据私钥也无法推知公钥)，加密解密使用不同密钥(公钥加密需要私钥解密，私钥加密需要公钥解密)，相对对称加密速度较慢，典型的非对称加密算法有RSA(是由Ron Rivest、Adi Shamir和LeonardAdleman一起提出的，RSA就是他们三人姓氏开头字母拼在一起组成的)、DSA(DigitalSignature Algorithm，数字签名算法)等。

https的特点如下：

1)客户端产生的密钥只有客户端和服务器端能得到；

2)加密的数据只有客户端和服务器端才能得到明文；

3)客户端到服务端的通信是安全的。

其中SSL用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取及窃听。它被用于Web浏览器与服务器之间的身份认证和加密数据传输。

SSL协议位于TCP/IP(Transmission Control Protocol/Internet Protocol，传输控制协议/因特网互联协议，又名网络通讯协议)协议与各种应用层协议之间，是一种国际标准的加密及身份认证通信协议,为TCP提供一个可靠的端到端的安全服务，为两个通讯个体之间提供保密性和完整性(身份鉴别)。SSL协议可分为两层：SSL记录协议(SSL RecordProtocol)：它建立在可靠的传输协议(如TCP)之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL握手协议(SSL Handshake Protocol)：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

其中SSL协议可用于保护正常运行于TCP之上的任何应用协议，如HTTP、FTP(FileTransfer Protocol，文件传输协议)、SMTP(Simple Mail Transfer Protocol，简单邮件传输协议)或Telnet的通信，最常见的是用SSL来保护HTTP的通信。SSL协议的优点在于它是与应用层协议无关的。高层的应用协议(如HTTP、FTP、Telnet等)能透明地建立于SSL协议之上。SSL协议在应用层协议之前就已经完成加密算法、通信密钥的协商以及服务器的认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的安全性。SSL协议使用通信双方的客户证书以及CA根证书，允许客户/服务器应用以一种不能被偷听的方式通信，在通信双方间建立起了一条安全的、可信任的通信通道。该协议使用密钥对传送数据加密，许多网站都是通过这种协议从客户端接收信用卡编号等保密信息。可以用于交易过程中。

客户对服务器的身份认证:SSL服务器允许客户的浏览器使用标准的公钥加密技术和一些可靠的认证中心(CA)的证书，来确认服务器的合法性。

服务器对客户的身份认证:也可通过公钥技术和证书进行认证，也可通过用户名，password来认证。

建立服务器与客户之间安全的数据通道:SSL要求客户与服务器之间的所有发送的数据都被发送端加密、接收端解密，同时还检查数据的完整性。

在示例性实施例中，所述方法还可以包括：判断发送所述请求报文的来源IP是否存在于来源方白名单中；当所述请求报文的来源IP存在于所述来源方白名单中时，对所述请求报文进行处理；当所述请求报文的来源IP不存在于所述来源方白名单中时，拒绝对所述请求报文进行处理，例如，还可以将该请求报文丢弃不予处理。

在示例性实施例中，所述方法还可以包括：判断所述请求报文的数据包是否完整；当所述请求报文的数据包完整时，进行校验签名。

在步骤S120中，根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址。

在示例性实施例中，所述对应关系中一个城市对应一个独立的网关服务地址，且各个网关服务地址对应不同城市的医保系统接口。

网关(Gateway)又称网间连接器、协议转换器。网关在网络层以上实现网络互连，是网络互连设备，仅用于两个高层协议不同的网络互连。网关既可以用于广域网互连，也可以用于局域网互连。使用在不同的通信协议、数据格式或语言，甚至体系结构完全不同的两种系统之间，网关是一个翻译器。与网桥只是简单地传达信息不同，网关对收到的信息要重新打包，以适应目的系统的需求。

在步骤S130中，通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口。

在示例性实施例中，所述方法还可以包括：判断所述城市的医保系统接口接收到的请求并发数是否超过预设阈值；当超过所述预设阈值时，将所述请求报文对应的请求等待处理。

在步骤S140中，接收所述城市的医保系统接口根据所述社保信息获取的返回报文。

在示例性实施例中，所述方法还可以包括：解析所述返回报文，获取所述返回报文中的签名；根据签名规则，校验所述返回报文的签名是否正确；当所述返回报文的签名校验正确时，将所述返回报文转发至发送所述请求报文的业务平台。

在示例性实施例中，所述方法还可以包括：记录所述在线医保信息处理方法的执行日志；设置所述执行日志按级别显示。

图3示出根据本申请另一实施例的在线医保信息处理方法的流程图。

如图3所示，该在线医保信息处理方法可以包括以下步骤：

在步骤S210中，接收用户的社保信息。

在示例性实施例中，所述社保信息可以包括用户名、社保卡号、身份证号、电话号码、手机号码、就医扣费信息、查询信息等中的一种或者多种。

例如，当用户在医院就医时，打开其用户终端上安装的微信上的该医院公众号/药店公众号/第三方医保在线支付APP等(下面的实施例中均以医院公众号为例进行举例说明，但本申请并不限定于此)，输入其用户名(可以是该用户的真实姓名，例如张三)以及其社保卡号，该医院公众号收到该用户名和社保卡号后，可以将其对应的扣费信息推送至该医院公众号并进行显示。

在步骤S220中，解析所述社保信息获取对应的城市标识。

其中，该医院公众号可以对用户输入的社保信息进行解析获取该用户的医保所对应的城市。例如，为了实现医保扣费的目的，一般可以根据用户输入的社保卡号获知该用户的医保关系所对应的城市，并根据预设规则对该城市进行唯一标识，例如使用城市编码作为城市标识，比如北京城市编码可以为110000。

需要说明的是，这里的城市编码可以采取任意方式进行编码，只要其能够将各个城市之间进行区别开来即可，本申请对此不作限定。

在步骤S230中，将所述用户的社保信息和所述社保信息对应的城市标识打包发送至用于连接各城市的医保系统的连接器系统。

在其他实施例中，在用户终端上也可以不对所述社保信息进行解析，而是直接将所述用户的社保信息打包发送至用于连接各城市的人社局医保系统的连接器系统，由该连接器系统来对所述社保信息进行解析，获得所述社保信息对应的城市标识。

本申请实施例中，医院公众号等业务平台不再与全国各地的人社局医保系统直接相连，而是与本申请实施例所述的连接器系统相连，全国各地市所有医院都可以使用本申请所述的连接器系统实现在线医保支付和/或查询。

其中，用户在医院就医，打开医院公众号后，该医院公众号根据本申请实施例所述的连接器系统对外提供的接口地址发起调用，假设连接器系统提供的接口地址为https:// wemi.xxxx.com/api(这里仅是一个举例)，该连接器系统收到请求后，根据请求参数里的城市编码cityid，查找对应的人力资源和社会保障网关服务(以下简称为“人社网关服务”)并发起调用，由人社网关服务继续向对应的人社局医保系统接口发起调用，将该请求转发至该人社局医保系统，该人社局医保系统对该请求进行相应的处理，例如如果是扣费请求，则进行相应的扣费处理；如果是查询请求，则返回相应的查询结果；然后该人社局医保系统通过该人社局医保系统接口将返回结果通过该连接器系统返回给该医院公众号

图4示出根据本申请又一实施例的在线医保信息处理方法的流程图。

如图4所示，该在线医保信息处理方法可以包括以下步骤：

在步骤S1中，用户医院就医。

用户在医院就医后，会进行挂号、缴费、查询等各种操作，这些操作例如可以通过其用户终端上安装的该医院的医院公众号来完成。用户将其真实姓名、手机号码、社保卡号甚至身份证号等信息输入至该医院公众号后，该医院公众号会获取到该用户的缴费信息、挂号信息等，并且用户可以对其进行查询。

在步骤S2中，医院公众号发送请求至连接器系统。

该医院公众号向该连接器系统发起请求，该连接器系统提供的连接器服务的接口地址例如可以为https://wemi.xxxx.com/api，但本申请并不限定于此。

在步骤S3中，人社网关服务启动。

该连接器服务的人社网关服务启动。

在步骤S4中，连接器系统绑定服务器IP。

该人社网关服务启动后，该连接器系统绑定该连接器系统部署的服务器的IP地址。

在步骤S5中，监听端口。

例如，假设连接器系统对外提供的为https接口，其端口采用443，可以监听443端口。

在步骤S6中，该连接器系统接收医院公众号发送过来的请求数据。

在示例性实施例中，服务器上部署的连接器服务接收到该请求数据的报文后，打印日志并保存该日志。

在示例性实施例中，所述方法还可以包括：在该服务器上预先设置一来源方白名单，该来源方白名单中存储有允许向该服务器发送请求报文的客户端IP和/或端口；当该连接器系统接收到医院公众号发送过来的请求数据后，可以首先在该来源方白名单里查找来源IP(例如发送请求的医院公众号的IP)；如果该来源IP存在于该来源方白名单内，则该连接器系统对该请求数据进行处理；反之，拒绝对该请求数据进行处理。

在步骤S7中，数据解包。

该连接器系统接收到该医院公众号发送过来打包的请求数据后，对该请求数据进行解包。本申请实施例对具体的解包方法不作限定。

在步骤S8中，判断解包后的包是否完整；当包是完整的时，进入步骤S9；当包不是完整的时，跳转到步骤S19结束本次操作。

在步骤S9中，校验签名。

当解包后的包是完整的，再对解包后的数据进行签名校验。本申请实施例对校验签名的方法不作限定，具体的校验签名方法可以根据发送请求时的数据的加密算法确定相应的解密算法。

在步骤S10中，判断签名校验是否通过；当签名校验通过时，进入步骤S11；当签名校验未通过时，跳转到步骤S19结束本次操作。

在步骤S11中，获取城市编码。

例如，该连接器系统对接收到的请求报文进行数据解包后，解析出例如http报文，当签名校验通过后，可以从该http报文中获取该请求报文中包括的城市编码cityid。

在步骤S12中，根据所述城市编码查找对应的网关服务。

根据上述步骤S11中获取的城市编码cityid，查找该连接器系统中预置的城市编码与网关服务地址的映射规则(即对应关系)，假设得到的网关服务地址为10.1.1.1:7029，通常该网关服务地址是内网地址，但本申请对此不作限定，然后将由连接器服务请求该网关服务地址。

本申请实施例中，城市编码与网关服务地址之间是一一对应的关系，从而可以对于不同城市的人社局医保系统的请求分而治之，对于部署、运营和运维分而治之。

在步骤S13中，判断是否找到对应的网关服务；当网关服务找到时，进入步骤S14；当网关服务未找到时，跳转到步骤S19结束本次操作。

根据上述步骤S12中是否能够查找到对应的网关服务地址来判断是否找到对应的网关服务。即当根据所述城市编码找到对应的网关服务地址时，判定找到了对应的网关服务；当根据所述城市编码找不到对应的网关服务地址时，判定找不到对应的网关服务。

在步骤S14中，转发所述医院公众号发送给所述连接器系统的请求到所述网关服务对应的网关。

如图4所示，例如当所述城市编码对应的城市为深圳时，调用深圳人社局医保系统对应的人社网关服务，或者当所述城市编码对应的城市为成都时，调用成都人社局医保系统对应的人社网关服务，或者当所述城市编码对应的城市为郑州时，调用郑州人社局医保系统对应的人社网关服务。

需要说明的是，虽然图4的实施例中以深圳、成都、郑州为例进行举例说明，但本申请并不限定于此，可以根据具体的应用场景设置不同的城市编码对应不同的城市的人社网关服务，且人社网关服务的数量也不作限定。

在示例性实施例中，所述方法还可以包括：查找流量控制状态，当转发至所述网关服务的请求并发数(即同一时间接收到的请求数量)超过预设阈值时，判断当前的人社局医保系统处于过载状态，则让该请求等待，否则继续处理该请求。

在步骤S15中，通过所述对应的人社网关服务调用对应城市的人社局医保系统接口，通过其提供的医保后台服务对所述请求进行处理。

如图4所示，例如深圳人社网关服务调用深圳人社局医保系统，或者成都人社网关服务调用成都人社局医保系统，或者郑州人社网关服务调用郑州人社局医保系统，但本申请并不限定于此。

在步骤S16中，通过相应城市的人社局医保系统返回数据包。

该相应城市的人社局医保系统接收到该请求报文后，对该请求进行处理，例如进行扣费或者查询等，然后返回相应的数据包。

在步骤S17中，对返回数据包进行校验签名。

在步骤S18中，将校验签名通过后的返回数据包返回客户端。

这里的客户端可以是指向该连接器系统发送该请求报文的医院公众号等。

本申请实施例中，网关服务向相应城市的人社局医保系统接口的地址发起请求(假设深圳人社局医保系统服务器上部署了医保后台服务，该医保后台服务向外提供的接口地址假设为https://10.192.1.1:8080/api)，该连接器系统收到该人社局医保系统返回报文后，对该返回报文进行解析，得到该返回报文中的签名，根据签名规则，校验该返回报文的签名是否正确。当该返回报文的签名校验正确时，将该返回报文转发给医院公众号系统。

在步骤S19中，结束。

图5示出根据本申请再一实施例的在线医保信息处理方法的流程图。

如图5所示，该在线医保信息处理方法与上述图4所示的实施例的区别之处在于：其根据城市编码找到对应网关服务后，并不是将请求转发至对应网关，然后由该对应网关来调用相应城市的人社局医保系统，在图5所示的实施例中，其是根据城市编码查找对应的人社局医保系统接口，当找到该对应的人社局医保系统接口后，直接调用该人社局医保系统，并通过该人社局系统的医保后台服务返回数据包。

图5所示的实施例可以应用于互联网+医疗挂号系统，与上述实施例中的在线医保支付、查询等业务上有点类似，属于一种挂号分发的在线解决方案，但其与上述实施例的技术架构上不同，缺乏组件化。并且就医平台只需要和挂号平台如就医160、微医等第三方挂号平台对接即可，属于一种代理服务，本申请上述实施例描述的医保支付不但要对接人社局医保系统，还有医院，属于两头都要打通的医保支付能力连接器，且可移植性强，可以以SDK(Software Development Kit，软件开发工具包)的形式把支付能力提供出去，医院公众号、APP等各类产品形态都可以基于本申请上述实施例描述的医保支付能力完成在线医保支付。

并且医疗挂号平台的实现方式跟图5所示的实施例类似，缺点是很明显的，比如，采用统一处理的网关服务来应对多城市多样性的接口服务，这样做的好处是系统架构层次简单，易于理解；弊端也显而易见，耦合性太强，牵一发而动全身。一旦某一个城市的业务量太大导致资源被大量占用，其他城市都将受到影响，甚至导致服务不可用，另外，如果后续某一个城市的业务变更，上线时都将对其他城市造成服务中断，带来不可预估的风险。

图5所示的实施例采用的统一处理会让城市与城市间耦合在一起，不利于架构上的轻重部署，并且会带来配置复杂，发布上线流程复杂等弊端，而上述实施例中采用的分而治之的连接器系统不会存在这些问题。

此外，上述实施例描述的连接器系统并非一种代理服务，他是独立的一种连接各个医疗平台(比如医院APP、公众号等)和人社局医保系统的一种连接器系统，在全国医院数量巨大、各地市人社局医保系统差异性、数量巨大的背景下，上述实施例描述的连接器系统采用分而治之的策略，根据城市编码可以将请求路由到不同的城市网关，对于请求分而治之，对于部署、运营、运维分而治之，可以做到轻重分离，根据不同的城市的业务量个性化部署，城市间解耦，互不影响。

图6示出根据本申请一实施例的在线医保信息处理装置的框图。

如图6所示，该在线医保信息处理装置100可以包括第一接收模块110、查找模块120、调用模块130以及第二接收模块140。

其中，第一接收模块110可以用于接收请求报文，所述请求报文中包括用户的社保信息和所述社保信息对应的城市标识。

查找模块120可以用于根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址。

调用模块130可以用于通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口。

第二接收模块可以140用于接收所述城市的医保系统接口根据所述社保信息获取的返回报文。

图7示出根据本申请另一实施例的在线医保信息处理装置的框图。

如图7所示，该在线医保信息处理装置200可以包括输入模块210、解析模块220以及发送模块230。

输入模块210可以用于接收用户的社保信息。

解析模块220可以用于解析所述社保信息获取对应的城市标识。

发送模块230可以用于将所述用户的社保信息和所述社保信息对应的城市标识打包发送至用于连接各城市的医保系统的连接器系统。

上述装置实施例中的其他内容可以参考上述方法实施例中的内容，在此不再赘述。

图8示出根据本申请又一实施例的在线医保信息处理装置的框图。

如图8所示用户医院就医时可以通过医院公众号向连接器系统发送请求，该连接器系统对外只提供一套接口标准，并且为https协议，因此该连接器系统可以移植到很多业务平台；该连接器系统主要负责部署网络服务、访问对应人社网关服务，以及通过该对应人社网关服务调用对应城市的人社局医保系统的医保后台服务，并接收该人社局医保系统返回的数据包，还可以对人社局医保系统返回包进行签名校验。

图9示出根据本申请一实施例的连接器系统的框图。

本申请实施例中，在连接器服务器上部署本申请实施例所述的连接器系统。

如图9所示，该连接器系统可以包括网络模块、数据模块、日志模块和安全模块。

其中，该网络模块主要负责接收医院公众号发送来的请求报文，解析出报文内容并保存，再根据请求报文中的城市编码cityid访问对应城市的人社局医保系统的服务器的服务地址，将该请求报文作为该对应城市的人社局医保系统的请求报文。该网络模块可以包括绑定主机IP、监听端口、数据发送、数据接收等职责。

本申请实施例中，该连接器系统在实施上述方法实施例中的步骤之前，还对该网络模块进行初始化，即首先在该连接器服务器上部署网络后台服务，该网络后台服务首先绑定本机IP(假设为10.2.2.2)、端口(443)，这些信息标识了该网络后台服务在本机的地址，客户端就可以通过此IP和端口向本网络后台服务发送请求报文。

其中，该数据模块负责将该网络模块接收到的报文解包，得到实际传输的应用层内容(例如http协议内容)，从而得到城市编码cityid，根据配置的城市编码和网关服务地址的映射规则，获取该城市对应的网关服务地址，并通过该对应的网关服务地址找到该城市对应的人社局医保系统的接口地址，将这些信息一起打包为一个新的应用层内容(即新的hppt协议内容)。另外，在人社局医保系统接口发送的对请求进行处理后的数据包返回后，还可以解析返回报文，得到该返回的数据包中的数字签名sign，并根据公钥校验签名是否正确。该数据模块包括数据解包、查找城市编码对应的人社网关服务接口地址、数据封包、签名校验等职责。

本申请实施例中，该连接器系统在实施上述方法实施例中的步骤之前，还对该数据模块进行初始化，加载城市编码与网关服务地址的映射规则，这里假设只有一个映射规则：434400＝>10.1.1.1:7029(实际中该连接器系统可以对接多少个城市的人社局医保系统，则相应的有多少个映射规则)。再加载数据签名规则，假设使用MD5(Message-DigestAlgorithm 5，信息-摘要算法5)的计算签名方式。

MD5用于确保信息传输完整一致，又译为摘要算法、哈希算法。将数据(如汉字)运算为另一固定长度值，是杂凑算法的基础原理，MD5的前身有MD2、MD3和MD4。MD5算法具有以下特点：

1、压缩性：任意长度的数据，算出的MD5值长度都是固定的。

2、容易计算：从原数据计算出MD5值很容易。

3、抗修改性：对原数据进行任何改动，哪怕只修改1个字节，所得到的MD5值都有很大区别。

4、强抗碰撞：已知原数据和其MD5值，想找到一个具有相同MD5值的数据(即伪造数据)是非常困难的。

MD5的作用是让大容量信息在用数字签名软件签署私人密钥前被“压缩”成一种保密的格式(就是把一个任意长度的字节串变换成一定长的十六进制数字串)。除了MD5以外，其他实施例中，还可以采用sha-1、RIPEMD以及Haval等。

其中，该日志模块负责记录整个流程中的执行日志，可以用于追溯问题，系统异常时可以保存现场，根据日志来查找失败原因，并恢复数据。本申请实施例中，所述日志模块还可以加载日志级别规则，即可以设置日志按级别显示，例如可以将日志分为信息级、调试级、警告级、错误级，该各类级别分别对应0、1、2、3。具体地，该日志级别规则中，0对应信息级，1对应调试级,2对应警告级，3对应错误级。如果设置级别为警告级(2)，则小于等于2的警告级的日志会显示出来，即信息级、调试级、警告级等级别的日志会显示出来。除此之外，该日志模块还可以设置为定期清理日志，从而避免无用的日志占用大量的磁盘空间，浪费资源。即该日志模块主要包括日志分级、日志保存、日志清理等职责。

本申请实施例中，该连接器系统在实施上述方法实施例中的步骤之前，还对该日志模块进行初始化，加载日志级别规则(例如0＝>信息级，1＝>调试级,2＝>警告级，3＝>错误级)。再加载日志属性(包括异步标记即是否异步打印日志，日志保存目录，日志清理频率，清理时间等)。

其中，该安全模块主要负责整个系统的安全方面的职责，用于保证在报文传输过程中数据不被泄露，因为大多数使用专线的服务器都是跟大量敏感数据打交道的系统，安全问题不容忽视。本申请实施例中，该安全模块可以采用SSL+数字签名的方式保证数据的安全性。在一些实施例中，该安全模块还可以采用来源方白名单机制保证来源的可靠性，只有白名单中的IP对应的客户端发送的报文，该系统才会处理，反之，丢弃不予处理。

上面两种机制是用于保证数据传输安全的，除此之外，该安全模块还可以增加流量控制职责，由于各地市人社局医保系统服务器的负载能力优先，如果有高并发的请求，人社局医保系统服务器会因为过载挂掉，那么所有客户端都将不可用。本申请实施例中，流量控制的方法可以是设置一个预设阈值，并发数不会超过这个阈值，超过的部分需要等待。该安全模块主要包括SSL数据加密、来源方白名单、流量控制等职责。

本申请实施例中，该连接器系统在实施上述方法实施例中的步骤之前，还对该安全模块进行初始化，加载SSL安全库，用于建立连接时的握手规则，数据报文加密等。再加载来源方白名单规则，如10.1.1.1、10.3.3.3，只有在规则内的IP，该网络后台服务才会处理，否则拒绝处理。再加载流量控制规则，用于保护外部专线服务器(例如人社局医保系统服务器)，避免并发过高造成外部专线服务器过载DOWN机，不能提供服务。其中流量控制规则可以为一个阈值，假设为200(但本申请并不限定于此)，如果请求队列里的请求数量不超过200，则正常处理，否则，超出的部分等待。

继续参考图9，该连接器系统还可以包括人社网关服务群，可以包含多个人社网关服务，例如图示中的网关服务1至6，需要说明的是，虽然图9中仅示出了网关服务1至6，但实际的网关服务数量与该连接器系统对接的城市的数量相匹配，N个网关服务分别对应N个城市的全国各地人社局医保系统的医保后台服务。在一个实施例中，全国有多少个地方人社局医保系统，该人社网关服务群就可以有几个网关服务，每个网关服务负责跟对应城市的人社局医保系统接口交互，发起和接收请求。

本申请实施例中，该连接器系统在实施上述方法实施例中的步骤之前，还对该人社网关服务群进行初始化，根据上述的城市编码与网关服务地址的映射规则，有几个城市编码就相应的部署几个网关服务，网关服务绑定映射规则对应的IP、端口，并循环接收请求，并发送请求至对应城市的人社医保系统接口，等待返回。

本申请实施例所述的连接器系统采用统一接入、分散处理的方法向外提供服务，对外提供组件的形式可以有两种，https接口和SDK两种方式。系统整体架构采用分层的策略，在接入层做网络接入、封包、解包，在逻辑层做通用的业务逻辑，在网关层做各城市分治，一个城市独立一个服务，相互之间完全解耦，在数据包发送给各地市人社局医保系统之后，等待返回结果，然后在逻辑层汇总，通过接入层返回给调用方，例如微信支付平台、医院(药店)公众号等等业务平台。

该连接器系统具备了全国地市的医保支付能力，其本身的可移植性比较强，采用了宽进窄出的思路，对外只提供一套接口标准，并且为https协议，因此该连接器可以移植到很多业务平台，比如微信支付、医院(药店)的公众号上，用户可以在这些业务平台完成社保卡或者医保卡的扣款和查询。

下面参考图10，其示出了适于用来实现本申请实施例的电子设备300的结构示意图。该电子设备300可以是服务器，也可以是用户终端。图10示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图10所示，电子设备300包括中央处理单元(CPU)301，其可以根据存储在只读存储器(ROM)302中的程序或者从存储部分306加载到随机访问存储器(RAM)303中的程序而执行各种适当的动作和处理。在RAM 303中，还存储有电子设备300操作所需的各种程序和数据。CPU 301、ROM 302以及RAM 303通过总线304彼此相连。输入/输出(I/O)接口305也连接至总线304。

以下部件连接至I/O接口305：包括硬盘等的存储部分306；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分307。通信部分307经由诸如因特网的网络执行通信处理。驱动器308也根据需要连接至I/O接口305。可拆卸介质309，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器308上，以便于从其上读出的计算机程序根据需要被安装入存储部分306。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分307从网络上被下载和安装，和/或从可拆卸介质309被安装。在该计算机程序被中央处理单元(CPU)301执行时，执行本申请的系统中限定的上述功能。

进一步的，本申请实施方式还提供了一种服务器，包括：至少一个处理器；存储装置，用于存储计算机程序；当所述计算机程序被所述至少一个处理器执行，使得所述至少一个处理器实现如下步骤：接收请求报文，所述请求报文中包括用户的社保信息和所述社保信息对应的城市标识；根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址；通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口；接收所述城市的医保系统接口根据所述社保信息获取的返回报文。

进一步的，本申请实施方式还提供了一种用户终端，包括：至少一个处理器；存储装置，用于存储计算机程序；当所述计算机程序被所述至少一个处理器执行，使得所述至少一个处理器实现如下步骤：接收用户的社保信息；解析所述社保信息获取对应的城市标识；将所述用户的社保信息和所述社保信息对应的城市标识打包发送至用于连接各城市的医保系统的连接器系统。

进一步的，本申请实施方式还提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现如下步骤：接收请求报文，所述请求报文中包括用户的社保信息和所述社保信息对应的城市标识；根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址；通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口；接收所述城市的医保系统接口根据所述社保信息获取的返回报文。

进一步的，本申请实施方式还提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现如下步骤：接收用户的社保信息；解析所述社保信息获取对应的城市标识；将所述用户的社保信息和所述社保信息对应的城市标识打包发送至用于连接各城市的医保系统的连接器系统。

通过以上的详细描述，本领域的技术人员易于理解，根据本申请实施例的装置和方法具有以下优点中的一个或多个。

根据本申请的一些实施例，该在线医保信息处理方法及装置、服务器、用户终端和计算机可读介质，通过一种基于全国各地人社局医保系统接口的分而治之的可移植的连接器系统，其可以应用于解决医保在线支付的问题，通过该连接器系统的连接、分而治之、可移植特点，一方面，不需要全国各地医院都与各地市的人社局医保系统对接，本申请实施例提供的连接器系统提供统一的接入方案，连接器系统组件化，接入方便快捷。另一方面，业务平台不需要关心全国各地市人社局医保系统接口的差异性、复杂性，只需要理解一套接口标准，这个标准是全国各地市人社局医保系统接口的抽象、包装。此外，为了全国各地市的人社局医保系统接口的调用互不影响，敏感信息独立脱敏处理，采用了分而治之的思想，做到轻重分离，各司其职，根据城市编码可以将请求路由到不同的城市网关，对于请求分而治之，对于部署、运营运维分而治之。同时，通过城市编码与网关服务地址的映射规则来路由，灵活可配置，有几个城市编码就部署几个网关服务，城市与城市间解耦，互不影响，不会因为某城市人社医保系统挂掉而导致全国各地医院公众号都无法调用。另外，还可以按照不同城市不同的业务量，个性化部署网关服务，业务量大的采用多台服务器提供服务，业务量少的则用少量的服务器提供服务。该连接器系统具备了全国地市的医保支付能力，其本身的可移植性比较强，采用了宽进窄出的思路，对外只提供一套接口标准，并且为https协议，因此该连接器可以移植到很多业务平台，比如微信支付、医院(药店)的公众号上，用户可以在这些业务平台完成社保卡或医保卡的扣款和查询。

根据本申请的一些实施例，该在线医保信息处理方法及装置、服务器、用户终端和计算机可读介质，还可以通过签名校验机制可以保证整个流程中报文不会被非法篡改，确保了报文的完整性与正确性。

根据本申请的一些实施例，该在线医保信息处理方法及装置、服务器、用户终端和计算机可读介质，还可以通过流量控制解决外部专线服务器因为过载DOWN机提供不了服务的问题。

根据本申请的一些实施例，该在线医保信息处理方法及装置、服务器、用户终端和计算机可读介质，提供了严格的安全模块，不但有SSL模块可以对数据加密，还有白名单机制，不在白名单内的客户端IP会拒绝服务，只有信任白名单内的IP才提供服务，保护了敏感数据不被泄露。

根据本申请的一些实施例，该在线医保信息处理方法及装置、服务器、用户终端和计算机可读介质，还可以通过对整个流程中进行日志的分级保存，用于追溯系统异常的具体原因，并且为了不必要日志占用大量磁盘空间，该系统会定期清理日志。

通过以上的实施例的描述，本领域的技术人员易于理解，本申请实施例可以通过硬件实现，也可以通过软件结合必要的硬件的方式来实现。因此，本申请实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者智能设备等)执行根据本申请实施例的方法。

Claims (10)

1.一种在线医保信息处理方法，其特征在于，所述方法由用于独立的连接业务平台以及各城市的医保系统的连接器系统执行，所述连接器系统并非一种代理服务，所述连接器系统用于根据城市标识将接收到的请求报文路由到不同的城市的医保系统对应的网关服务，在所述连接器系统中预置城市标识与网关服务地址的对应关系，所述网关服务用于对收到的信息重新打包，以适应目的系统的需求，所述方法包括：

接收所述业务平台发送的请求报文，所述请求报文中包括用户的社保信息和所述社保信息对应的城市标识；

根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址，所述对应关系中一个城市对应一个独立的网关服务地址，且各个网关服务地址对应不同城市的医保系统接口，以对不同城市的医保系统的请求报文分而治之；

通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口；

接收所述城市的医保系统接口根据所述社保信息获取的返回报文，以将所述返回报文返回至所述业务平台；

所述方法还包括：

判断所述城市的医保系统接口接收到的请求并发数是否超过预设阈值；

当超过所述预设阈值时，将所述请求报文对应的请求等待处理；

当所述请求报文的来源IP存在于来源方白名单中时，对所述请求报文进行处理；

当所述请求报文的来源IP不存在于所述来源方白名单中时，拒绝对所述请求报文进行处理。

2.如权利要求1所述的在线医保信息处理方法，其特征在于，所述方法还包括：

当所述请求报文的数据包完整时，进行校验签名；和/或

解析所述返回报文，获取所述返回报文中的签名；

根据签名规则，校验所述返回报文的签名是否正确；

当所述返回报文的签名校验正确时，将所述返回报文转发至发送所述请求报文的业务平台。

3.如权利要求1所述的在线医保信息处理方法，其特征在于，所述方法还包括：

记录所述在线医保信息处理方法的执行日志；

设置所述执行日志按级别显示。

4.一种在线医保信息处理方法，其特征在于，所述方法由业务平台执行，所述方法包括：

接收用户的社保信息；

解析所述社保信息获取对应的城市标识；

将所述用户的社保信息和所述社保信息对应的城市标识打包发送至用于独立的连接所述业务平台以及各城市的医保系统的连接器系统，所述连接器系统并非一种代理服务，所述连接器系统用于根据城市标识将接收到的请求报文路由到不同的城市的医保系统对应的网关服务，在所述连接器系统中预置城市标识与网关服务地址的对应关系，所述网关服务用于对收到的信息重新打包，以适应目的系统的需求；

其中，所述连接器系统用于：根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址，所述对应关系中一个城市对应一个独立的网关服务地址，且各个网关服务地址对应不同城市的医保系统接口，以对不同城市的医保系统的请求报文分而治之；通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口；接收所述城市的医保系统接口根据所述社保信息获取的返回报文，以将所述返回报文返回至所述业务平台；判断所述城市的医保系统接口接收到的请求并发数是否超过预设阈值；当超过所述预设阈值时，将所述请求报文对应的请求等待处理；当所述请求报文的来源IP存在于来源方白名单中时，对所述请求报文进行处理；当所述请求报文的来源IP不存在于所述来源方白名单中时，拒绝对所述请求报文进行处理。

5.一种在线医保信息处理装置，其特征在于，所述装置设置于用于独立的连接业务平台以及各城市的医保系统的连接器系统，所述连接器系统并非一种代理服务，所述连接器系统用于根据城市标识将接收到的请求报文路由到不同的城市的医保系统对应的网关服务，在所述连接器系统中预置城市标识与网关服务地址的对应关系，所述网关服务用于对收到的信息重新打包，以适应目的系统的需求，所述装置包括：

第一接收模块，用于接收所述业务平台发送的请求报文，所述请求报文中包括用户的社保信息和所述社保信息对应的城市标识；判断所述城市的医保系统接口接收到的请求并发数是否超过预设阈值；当超过所述预设阈值时，将所述请求报文对应的请求等待处理；当所述请求报文的来源IP存在于来源方白名单中时，对所述请求报文进行处理；当所述请求报文的来源IP不存在于所述来源方白名单中时，拒绝对所述请求报文进行处理；

查找模块，用于根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址，所述对应关系中一个城市对应一个独立的网关服务地址，且各个网关服务地址对应不同城市的医保系统接口，以对不同城市的医保系统的请求报文分而治之；

调用模块，用于通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口；

第二接收模块，用于接收所述城市的医保系统接口根据所述社保信息获取的返回报文，以将所述返回报文返回至所述业务平台。

6.一种在线医保信息处理装置，其特征在于，所述装置设置于业务平台，所述装置包括：

输入模块，用于接收用户的社保信息；

解析模块，用于解析所述社保信息获取对应的城市标识；

发送模块，用于将所述用户的社保信息和所述社保信息对应的城市标识打包发送至用于独立的连接所述业务平台以及各城市的医保系统的连接器系统，所述连接器系统并非一种代理服务，所述连接器系统用于根据城市标识将接收到的请求报文路由到不同的城市的医保系统对应的网关服务，在所述连接器系统中预置城市标识与网关服务地址的对应关系，所述网关服务用于对收到的信息重新打包，以适应目的系统的需求；

其中，所述连接器系统用于：根据所述城市标识查找城市标识与网关服务地址的对应关系，获取所述城市标识对应的城市的网关服务地址，所述对应关系中一个城市对应一个独立的网关服务地址，且各个网关服务地址对应不同城市的医保系统接口，以对不同城市的医保系统的请求报文分而治之；通过所述网关服务地址对应的网关服务调用所述城市的医保系统接口，并将所述社保信息发送至所述城市的医保系统接口；接收所述城市的医保系统接口根据所述社保信息获取的返回报文，以将所述返回报文返回至所述业务平台；判断所述城市的医保系统接口接收到的请求并发数是否超过预设阈值；当超过所述预设阈值时，将所述请求报文对应的请求等待处理；当所述请求报文的来源IP存在于来源方白名单中时，对所述请求报文进行处理；当所述请求报文的来源IP不存在于所述来源方白名单中时，拒绝对所述请求报文进行处理。

7.一种服务器，其特征在于，包括：

至少一个处理器；

存储装置，用于存储计算机程序；

当所述计算机程序被所述至少一个处理器执行，使得所述至少一个处理器实现如权利要求1-3中任一所述的在线医保信息处理方法。

8.一种用户终端，其特征在于，包括：

至少一个处理器；

存储装置，用于存储计算机程序；

当所述计算机程序被所述至少一个处理器执行，使得所述至少一个处理器实现如权利要求4中所述的在线医保信息处理方法。

9.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-3中任一所述的在线医保信息处理方法。

10.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求4中所述的在线医保信息处理方法。

Images