一种医保信息交互方法、装置、电子设备及存储介质与流程

1.本技术涉及数据处理技术领域，具体而言，涉及一种医保信息交互方法、装置、电子设备及存储介质。


背景技术：

2.随着血液透析行业的发展，已将独立血液透析中心纳入医疗机构范围并支持社会资本办医、完善血液透析中心的设立标准和规范、鼓励血液透析中心连锁化和社区化发展，以激发独立血液透析中心行业的投资热潮，推动独立血液透析中心市场进一步扩大。同时，大病医保的广泛覆盖及报销比例的不断提升将极大加速国内透析治疗需求的释放，也将透析中心与医保紧紧地绑定在了一起。患者想要持续透析，减少高额的透析费用，必然需要使用医保报销；而透析中心为了收回成本/盈利，也需要满足医保对透析治疗过程中的数据处理要求。
3.his系统(hospital information system，医院信息系统)在签约当地客户上线使用时，需要配合开发调试当地医保相关接口的功能，实现门诊、住院收费等功能。不同地区的医保接口不尽相同，并且因为医保网络不能与互联网相通的要求，从而导致需要编写大量冗余的代码用来适配不同地区的医保接口。


技术实现要素：

4.鉴于此，本技术的目的在于提供一种医保信息交互方法、装置、电子设备及存储介质，能够适配不同的医保接口平台，实现his系统的收费功能，满足客户进行医保结算的需求。
5.第一方面，本技术实施例提供一种医保信息交互方法，应用于中台服务器，所述方法包括以下步骤：
6.接收客户端发送的获取医保信息的请求；其中，所述请求携带的第一医保参数为所述客户端进行页面显示的第一标准数据；
7.根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数；以使所述客户端根据所述接口地址向所述目标医保服务器发送所述请求参数；
8.接收所述客户端发送的请求结果，并且将所述请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据之后，发送给所述客户端；其中，所述请求结果是所述目标医保服务器根据接收到的所述请求参数向所述客户端发送的。
9.在一些实施例中，所述请求携带的第一医保参数包括读卡目的、就诊凭证类型、证件类型、证件号码、参保地中的一种或多种。
10.在一些实施例中，所述根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数，包括以下步骤：
11.预设与所述客户端交互的所有医保服务器针对所有请求的执行逻辑；其中，不同
的执行逻辑对应不同的请求参数；
12.根据所述请求携带的第一医保参数，从与所述客户端交互的多个医保服务器中确定出目标医保服务器；
13.根据所述目标医保服务器针对所述请求的目标执行逻辑，确定与所述请求相对应的请求参数，以及针对该请求确定所述客户端与所述目标医保服务器进行医保信息交互的接口地址。
14.在一些实施例中，所述根据所述请求携带的第一医保参数，从与所述客户端交互的多个医保服务器中确定出目标医保服务器，包括以下步骤：
15.根据所述请求携带的第一医保参数，确定请求人的归属医院，并且根据所述归属医院确定其地区编码；
16.根据所述地区编码从与所述客户端交互的多个医保服务器中确定出目标医保服务器；其中，与所述客户端交互的多个医保服务器是基于地区划分的，并且不同地区的所述医保服务器针对同一请求的执行逻辑不同。
17.在一些实施例中，所述还包括以下步骤：
18.预置所述客户端与所有所述医保服务器之间进行医保信息交互的加密方式，以使所述客户端根据所述接口地址将所述请求参数按照预置的所述加密方式进行加密之后发送给所述目标医保服务器；
19.以及以使所述目标医保服务器按照预置的所述加密方式对接收到的所述请求参数进行校验之后，获取相应的请求结果。
20.在一些实施例中，其中，所述请求结果携带的第二医保参数具有固定的编码格式，基于所述编码格式对所述请求结果携带的第二医保参数进行解析，得到所述客户端进行页面显示的第二标准数据。
21.在一些实施例中，所述方法还包括以下步骤：
22.记录所述客户端与所述医保服务器之间进行医保信息交互的日志信息并进行保存。
23.第二方面，本技术实施例提供一种医保信息交互装置，所述装置包括：
24.接收模块，用于接收客户端发送的获取医保信息的请求；其中，所述请求携带的第一医保参数为所述客户端进行页面显示的第一标准数据；
25.发送模块，用于根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数；以使所述客户端根据所述接口地址向所述目标医保服务器发送所述请求参数；
26.转换模块，用于接收所述客户端发送的请求结果，并且将所述请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据之后，发送给所述客户端；其中，所述请求结果是所述目标医保服务器根据接收到的所述请求参数向所述客户端发送的。
27.第三方面，本技术实施例提供的一种电子设备，包括处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面任一项所述的医保信息交互方法的步骤。
28.第四方面，本技术实施例提供的一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面任一项所述的医保信息交互方法的步骤。
29.本技术所述的一种医保信息交互方法、装置、电子设备及存储介质，通过中台服务器接收客户端发送的获取医保信息的请求；根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数；以使所述客户端根据所述接口地址向所述目标医保服务器发送所述请求参数；接收所述客户端发送的请求结果，并且将所述请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据之后，发送给所述客户端。从而实现对客户端与不同医保服务器之间医保信息交互的统一控制，使得医保对接流程代码统一化、简介化。
附图说明
30.为了更清楚地说明本技术实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
31.图1示出了本技术实施例所述医保信息交互方法的流程图；
32.图2示出了本技术实施例所述客户端响应用户发送的读卡请求时的显示页面示意图；
33.图3示出了本技术实施例所述根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数的流程图；
34.图4示出了本技术实施例所述医保信息交互装置的结构示意图；
35.图5示出了本技术实施例所述电子设备的结构框图。
具体实施方式
36.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，应当理解，本技术中附图仅起到说明和描述的目的，并不用于限定本技术的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本技术中使用的流程图示出了根据本技术的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本技术内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。
37.另外，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本技术实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本技术的实施例的详细描述并非旨在限制要求保护的本技术的范围，而是仅仅表示本技术的选定实施例。基于本技术的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
38.需要说明的是，本技术实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。
39.鉴于背景技术所提出的技术问题，本技术提供一种医保信息交互方法、装置、电子设备及存储介质，能够实现对客户端与不同医保服务器之间医保信息交互的统一控制，使得医保对接流程代码统一化、简介化。
40.参见说明书附图1，本技术实施例提供的一种医保信息交互方法，应用于中台服务器，包括以下步骤：
41.s1、接收客户端发送的获取医保信息的请求；其中，所述请求携带的第一医保参数为所述客户端进行页面显示的第一标准数据；
42.s2、根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数；以使所述客户端根据所述接口地址向所述目标医保服务器发送所述请求参数；
43.s3、接收所述客户端发送的请求结果，并且将所述请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据之后，发送给所述客户端；其中，所述请求结果是所述目标医保服务器根据接收到的所述请求参数向所述客户端发送的。
44.需要说明的是，在本技术实施例中，所述客户端可以是安装有his系统的医护或者患者电脑端、移动端、平板端，用于与不同医保服务器进行对接，以实现获取参保人信息、进行住院相关业务、门诊的相关业务、个账消费的相关业务等。
45.所述中台服务器可以是一个单独的系统，也可以与客户端集成在一起，用于统一控制客户端与不同医保服务器之间的医保信息交互。
46.其中，在步骤s1中，所述客户端向所述中台服务器发送的获取医保信息的请求，可以是用户通过操作客户端的页面所生成的。例如，查询有卡人员基本信息服务的请求、传入费用明细等待保存或结算服务的请求、打印单据服务的请求、普通住院登记服务的请求、打印住院告知单服务的请求、上传凭单服务的请求、出院结算服务的请求、撤销出院服务的请求、删除一条费用凭单服务的请求、门诊结算服务的请求、获取自付比例服务的请求等。
47.参见说明书附图2，在一实施例中，客户端响应用户发送的读卡请求时，需要输入的第一标准数据即为该请求携带的第一医保参数，包括读卡目的、就诊凭证类型、证件类型、证件号码和参保地。
48.参见说明书附图3，在步骤s2中，中台服务器根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数，包括以下步骤：
49.s201、预设与所述客户端交互的所有医保服务器针对所有请求的执行逻辑；其中，不同的执行逻辑对应不同的请求参数；
50.s202、根据所述请求携带的第一医保参数，从与所述客户端交互的多个医保服务器中确定出目标医保服务器；
51.s203、根据所述目标医保服务器针对所述请求的目标执行逻辑，确定与所述请求相对应的请求参数，以及针对该请求确定所述客户端与所述目标医保服务器进行医保信息交互的接口地址。
52.即，中台服务器集合了医保服务器所有的业务服务(函数)，以供客户端直接进行调用，从而避免现有技术中，客户端针对不同医保服务器的不同医保接口，所需要编写大量冗余的代码用来适配的弊端。例如，医保服务器a将有卡获取人员信息、无卡获取人员信息
共用一个接口，需要传输参数如下：
53.参数代码参数名称mdtrt_cert_type就诊凭证类型mdtrt_cert_no就诊凭证编号card_sn卡识别码begntime开始时间psn_cert_type人员证件类型certno证件号码psn_name人员姓名
54.医保服务器b将有卡获取人员信息、无卡获取人员信息分为两个接口，并且调用参数不同：
55.参数名称类型中文名称grbhstring*个人编号xmstring*姓名yltclbstring*医疗统筹类别sbjgbhstring*社保机构编号xzbzstring险种标志
56.在该实施例中，所述业务服务(函数)即为客户端发送的请求所对应的执行逻辑，其中，不同的执行逻辑对应不同的请求参数。
57.具体的，中台服务器先根据用户输入的读卡目的、就诊凭证类型、证件类型、证件号码或参保地等信息确定出用户的归属医院，并根据该归属医院确定其地区编码，再根据该地区编码从与客户端交互的多个医保服务器中确定出目标医保服务器，其中，与客户端交互的多个医保服务器是基于地区划分的，并且不同地区的医保服务器针对同一请求的执行逻辑不同。例如，地区m的医保服务器a针对读卡请求执行其在地区m的逻辑，所需要的请求参数为mdtrt_cert_type、mdtrt_cert_no、card_sn、begntime、psn_cert_type、certno、psn_name；而地区n的医保服务器b针对读卡请求执行其在地区n的逻辑，所需要的请求参数为grbh、xm、yltclb、sbjgbh、xzbz。
58.则中台服务器在根据客户端发送的请求得到与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数之后，将该接口地址以及请求参数返回至客户端，由客户端调用该接口地址并将获取的请求参数发送给目标医保服务器，而目标服务器在接收到该请求参数之后，通过数据库查询得到所述请求相对应的请求结果，并将该请求结果返回给客户端。
59.在其他实施例中，可以预先设置所述客户端与所有所述医保服务器之间进行医保信息交互的加密方式，以使所述客户端根据所述接口地址将所述请求参数按照预置的所述加密方式进行加密之后发送给所述目标医保服务器；同时，以使所述目标医保服务器按照预置的所述加密方式对接收到的所述请求参数进行校验之后，获取相应的请求结果。
60.例如，所述客户端与所有所述医保服务器之间进行医保信息交互的加密方式为crc加密算法，则客户端针对要发送的请求参数的文件，先计算其crc校验码，并将所述crc校验码放置到所述文件的指定位置，得到待发送文件，然后才将所述待发送文件传输给目
标医保服务器，目标医保服务器对接收到的所述待发送文件进行crc校验，若校验正确，则通过数据库查询得到所述请求相对应的请求结果；若校验错误，则向客户端发送校验错误的反馈信息，以使中台服务器向客户端重新发送请求参数。
61.其中，crc加密算法应为本领域技术人员所熟知的技术手段，在此不进行赘述。并且，在其他实施例中，还可以根据实际应用采用不同的加密方式，以保证数据传输的安全性，本技术并不对此进行限制和固定。
62.在步骤s3中，当客户端接收目标医保服务器返回的请求结果之后，由于该请求结果的数据并非客户端能够进行页面显示的标准数据，所以需要中台服务器将其进行转换，即将请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据。例如，目标医保服务器a针对读卡请求所返回的请求结果如下：
63.[0064][0065]
由于，目标医保服务器返回的请求结果具有一定的编码格式，所以在中台服务器中预置相应的解析规则，就能够将解析出请求结果中的编码和名称，并展示在客户端的显
示界面上。从而节省了客户端计算资源。
[0066]
进一步的，中台服务器还记录所述客户端与所述医保服务器之间进行医保信息交互的日志信息，并进行保存。在用户遇到外部问题需要处理时，能够方便快捷地溯源并进行响应，减少了处理时间，极大提高用户的使用体验。
[0067]
可见，本技术提供的一种医保信息交互方法，中台服务器集合了与所述客户端交互的所有医保服务器针对所有请求的执行逻辑，能够根据用户请求获取与客户端进行医保信息交互的目标医保服务器的接口地址以及相对应的请求参数，并且能够将医保服务器返回的请求结果解析为客户端进行页面显示的标准数据，从而实现对客户端与不同医保服务器之间医保信息交互的统一控制，使得医保对接流程代码统一化、简介化。
[0068]
基于同一发明构思，本技术实施例中还提供了一种医保信息交互装置，由于本技术实施例中的装置解决问题的原理与本技术实施例上述一种医保信息交互方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
[0069]
如说明书附图4所示，本技术还提供了一种医保信息交互装置，所述装置包括：
[0070]
接收模块401，用于接收客户端发送的获取医保信息的请求；其中，所述请求携带的第一医保参数为所述客户端进行页面显示的第一标准数据；
[0071]
发送模块402，用于根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数；以使所述客户端根据所述接口地址向所述目标医保服务器发送所述请求参数；
[0072]
转换模块403，用于接收所述客户端发送的请求结果，并且将所述请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据之后，发送给所述客户端；其中，所述请求结果是所述目标医保服务器根据接收到的所述请求参数向所述客户端发送的。
[0073]
在一些实施例中，所述请求携带的第一医保参数包括读卡目的、就诊凭证类型、证件类型、证件号码、参保地中的一种或多种。
[0074]
在一些实施例中，所述发送模块402根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数，包括：
[0075]
预设与所述客户端交互的所有医保服务器针对所有请求的执行逻辑；其中，不同的执行逻辑对应不同的请求参数；
[0076]
根据所述请求携带的第一医保参数，从与所述客户端交互的多个医保服务器中确定出目标医保服务器；
[0077]
根据所述目标医保服务器针对所述请求的目标执行逻辑，确定与所述请求相对应的请求参数，以及针对该请求确定所述客户端与所述目标医保服务器进行医保信息交互的接口地址。
[0078]
在一些实施例中，所述发送模块402根据所述请求携带的第一医保参数，从与所述客户端交互的多个医保服务器中确定出目标医保服务器，包括：
[0079]
根据所述请求携带的第一医保参数，确定请求人的归属医院，并且根据所述归属医院确定其地区编码；
[0080]
根据所述地区编码从与所述客户端交互的多个医保服务器中确定出目标医保服务器；其中，与所述客户端交互的多个医保服务器是基于地区划分的，并且不同地区的所述
医保服务器针对同一请求的执行逻辑不同。
[0081]
在一些实施例中，所述装置还包括预置模块，用于阈值所述客户端与所有所述医保服务器之间进行医保信息交互的加密方式，以使所述客户端根据所述接口地址将所述请求参数按照预置的所述加密方式进行加密之后发送给所述目标医保服务器；以及以使所述目标医保服务器按照预置的所述加密方式对接收到的所述请求参数进行校验之后，获取相应的请求结果。
[0082]
在一些实施例中，所述请求结果携带的第二医保参数具有固定的编码格式，基于所述编码格式对所述请求结果携带的第二医保参数进行解析，得到所述客户端进行页面显示的第二标准数据。
[0083]
在一些实施例中，所述装置还包括记录模块，用于记录所述客户端与所述医保服务器之间进行医保信息交互的日志信息并进行保存。
[0084]
本技术提供的一种医保信息交互装置，通过接收模块接收客户端发送的获取医保信息的请求；通过发送模块根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数；以使所述客户端根据所述接口地址向所述目标医保服务器发送所述请求参数；通过转换模块接收所述客户端发送的请求结果，并且将所述请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据之后，发送给所述客户端。从而实现对客户端与不同医保服务器之间医保信息交互的统一控制，使得医保对接流程代码统一化、简介化。
[0085]
基于本发明的同一构思，说明书附图5所示，本技术实施例提供的一种电子设备500的结构，该电子设备500包括：至少一个处理器501，至少一个网络接口504或者其他用户接口503，存储器505，至少一个通信总线502。通信总线502用于实现这些组件之间的连接通信。该电子设备500可选的包含用户接口503，包括显示器(例如，触摸屏、lcd、crt、全息成像(holographic)或者投影(projector)等)，键盘或者点击设备(例如，鼠标，轨迹球(trackball)，触感板或者触摸屏等)。
[0086]
存储器505可以包括只读存储器和随机存取存储器，并向处理器501提供指令和数据。存储器505的一部分还可以包括非易失性随机存取存储器(nvram)。
[0087]
在一些实施方式中，存储器505存储了如下的元素，可保护模块或者数据结构，或者他们的子集，或者他们的扩展集：
[0088]
操作系统5051，包含各种系统程序，用于实现各种基础业务以及处理基于硬件的任务；
[0089]
应用程序模块5052，包含各种应用程序，例如桌面(launcher)、媒体播放器(media player)、浏览器(browser)等，用于实现各种应用业务。
[0090]
在本技术实施例中，通过调用存储器505存储的程序或指令，处理器501用于执行如一种医保信息交互方法中的步骤，能够适配不同的医保接口平台，实现his系统的收费功能，满足客户进行医保结算的需求。
[0091]
本技术还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如医保信息交互方法中的步骤。
[0092]
具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述医保信息交互方法。
[0093]
在本技术所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0094]
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0095]
另外，在本技术提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0096]
功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0097]
最后应说明的是：以上实施例，仅为本技术的具体实施方式，用以说明本技术的技术方案，而非对其限制，本技术的保护范围并不局限于此，尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本技术实施例技术方案的精神和范围。都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以权利要求的保护范围为准。

技术特征：
1.一种医保信息交互方法，其特征在于，应用于中台服务器，所述方法包括以下步骤：接收客户端发送的获取医保信息的请求；其中，所述请求携带的第一医保参数为所述客户端进行页面显示的第一标准数据；根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数；以使所述客户端根据所述接口地址向所述目标医保服务器发送所述请求参数；接收所述客户端发送的请求结果，并且将所述请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据之后，发送给所述客户端；其中，所述请求结果是所述目标医保服务器根据接收到的所述请求参数向所述客户端发送的。2.根据权利要求1所述的一种医保信息交互方法，其特征在于，其中，所述请求携带的第一医保参数包括读卡目的、就诊凭证类型、证件类型、证件号码、参保地中的一种或多种。3.根据权利要求1所述的一种医保信息交互方法，其特征在于，所述根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数，包括以下步骤：预设与所述客户端交互的所有医保服务器针对所有请求的执行逻辑；其中，不同的执行逻辑对应不同的请求参数；根据所述请求携带的第一医保参数，从与所述客户端交互的多个医保服务器中确定出目标医保服务器；根据所述目标医保服务器针对所述请求的目标执行逻辑，确定与所述请求相对应的请求参数，以及针对该请求确定所述客户端与所述目标医保服务器进行医保信息交互的接口地址。4.根据权利要求3所述的一种医保信息交互方法，其特征在于，所述根据所述请求携带的第一医保参数，从与所述客户端交互的多个医保服务器中确定出目标医保服务器，包括以下步骤：根据所述请求携带的第一医保参数，确定请求人的归属医院，并且根据所述归属医院确定其地区编码；根据所述地区编码从与所述客户端交互的多个医保服务器中确定出目标医保服务器；其中，与所述客户端交互的多个医保服务器是基于地区划分的，并且不同地区的所述医保服务器针对同一请求的执行逻辑不同。5.根据权利要求4所述的一种医保信息交互方法，其特征在于，所述方法还包括以下步骤：预置所述客户端与所有所述医保服务器之间进行医保信息交互的加密方式，以使所述客户端根据所述接口地址将所述请求参数按照预置的所述加密方式进行加密之后发送给所述目标医保服务器；以及以使所述目标医保服务器按照预置的所述加密方式对接收到的所述请求参数进行校验之后，获取相应的请求结果。6.根据权利要求5所述的一种医保信息交互方法，其特征在于，其中，所述请求结果携带的第二医保参数具有固定的编码格式，基于所述编码格式对所述请求结果携带的第二医保参数进行解析，得到所述客户端进行页面显示的第二标准数据。
7.根据权利要求6所述的一种医保信息交互方法，其特征在于，所述方法还包括以下步骤：记录所述客户端与所述医保服务器之间进行医保信息交互的日志信息并进行保存。8.一种医保信息交互装置，其特征在于，所述装置包括：接收模块，用于接收客户端发送的获取医保信息的请求；其中，所述请求携带的第一医保参数为所述客户端进行页面显示的第一标准数据；发送模块，用于根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数；以使所述客户端根据所述接口地址向所述目标医保服务器发送所述请求参数；转换模块，用于接收所述客户端发送的请求结果，并且将所述请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据之后，发送给所述客户端；其中，所述请求结果是所述目标医保服务器根据接收到的所述请求参数向所述客户端发送的。9.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至7任一所述的医保信息交互方法的步骤。10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至7任一所述的医保信息交互方法的步骤。

技术总结
本申请提供了一种医保信息交互方法、装置、电子设备及存储介质，涉及数据处理技术领域，通过中台服务器接收客户端发送的获取医保信息的请求；根据所述请求向所述客户端发送与目标医保服务器进行医保信息交互的接口地址，以及与所述请求相对应的请求参数；以使所述客户端根据所述接口地址向所述目标医保服务器发送所述请求参数；接收所述客户端发送的请求结果，并且将所述请求结果携带的第二医保参数转换为所述客户端进行页面显示的第二标准数据之后，发送给所述客户端。从而实现对客户端与不同医保服务器之间医保信息交互的统一控制，使得医保对接流程代码统一化、简介化。简介化。简介化。


技术研发人员：何正刚 周云 曾涛
受保护的技术使用者：深圳云净之信息技术有限公司
技术研发日：2023.07.18
技术公布日：2023/9/23