一种数据对接方法、装置、电子设备及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种数据对接方法、装置、电子设备及存储介质。

背景技术

随着医疗信息化的发展，医院使用的各种医疗平台层出不穷，不同平台之间的对接日益增多，不同平台之间，信息不互通，导致医护人员一件事情需要做两遍，甚至更多遍，增加了医护人员的工作量。

为了解决上述问题，不同的业务部门往往会开发对应的子系统，例如，血透部门会开发对应的血透系统，对于具体的血透业务，在血透平台中进行操作，但是，由于血透平台这类业务系统往往都是由第三方所提供，因此往往不能与医院的医院信息系统(HospitalInformation System，HIS)互通，因此，血透平台中的数据需要和医院的医院信息系统做对接，双方将患者的基础信息、药品信息等做同步，减少重复性工作，但由于业务平台和医院的医院信息系统数据同步涉及库存等问题，因此对接效率低下。现有技术中缺少相应的解决手段。

发明内容

有鉴于此，本申请实施例提供了一种数据对接方法、装置、电子设备及存储介质，能够提高对接效率。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种数据对接方法，包括以下步骤：

在单位时间内通过第一系统为每个患者开药，并通过所述第一系统获取所述单位时间内所述每个患者的开药信息，所述开药信息不超过所述第一系统的药品库存；

对所述开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，其中，所述第二系统的数据与所述第一系统的数据不互通；

在所述第二系统中基于所述目标数据对所述每个患者的治疗信息进行附加处理。

在一种可能的实施方式中，所述对所述开药信息进行封装处理，得到目标数据，包括：

针对所述开药信息创建目标视图，将所述目标视图作为所述目标数据；

针对所述目标视图创建目标接口，其中，所述目标接口用于获取所述目标视图。

所述将所述目标数据同步至第二系统，包括：

通过所述目标接口将所述目标数据同步至所述第二系统。

在一种可能的实施方式中，所述将所述目标数据同步至第二系统，包括：

在预设的目标时间节点时将所述目标数据同步至所述第二系统；

若所述第二系统中存在历史目标数据时，基于所述目标数据对所述历史目标数据进行覆盖；

或者，获取所述目标数据相较于所述历史目标数据的额外数据和差异数据，将所述额外数据写入所述历史目标数据以及将差异数据覆盖至存在差异的原数据，并对该差异进行标注。

在一种可能的实施方式中，所述方法还包括：

针对每次将所述目标数据同步至第二系统的同步操作，对所述同步操作进行记录，得到同步版本；

响应于针对所述同步版本的回溯操作，将所述目标数据回溯至对应的同步版本。

在一种可能的实施方式中，所述方法还包括：

若将所述目标数据同步至第二系统后，所述开药信息发生了改变，通过手动或自动的方式，对该改变进行同步；

当通过手动的方式对该改变进行同步时，响应于针对目标数据的同步请求，将改变后的所述目标数据手动同步至所述第二系统；

当通过自动的方式对该改变进行同步时，响应于针对预设频率的检测请求，对所述开药信息进行检测处理，若所述开药信息发生了改变，将改变后的所述目标数据自动同步至所述第二系统。

在一种可能的实施方式中，所述将所述目标数据同步至第二系统后，所述方法还包括：

针对预设的目标数据类型，对所述目标数据中与所述目标数据类型相匹配的数据进行隐藏；

对同步后的所述目标数据添加同步记录；

显示同步后的所述目标数据。

在一种可能的实施方式中，所述开药信息包括患者信息和医嘱信息；

所述患者信息包括以下信息至少之一：患者姓名、身份证号；

所述医嘱信息包括以下信息至少之一：药品名称、药品ID、单次用量、给药途径、开药数量、注射费用。

第二方面，本申请实施例还提供一种数据对接装置，所述装置包括：

获取模块，用于在单位时间内通过第一系统为每个患者开药，并通过所述第一系统获取所述单位时间内所述每个患者的开药信息，所述开药信息不超过所述第一系统的药品库存；

同步模块，用于对所述开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，其中，所述第二系统的数据与所述第一系统的数据不互通；

处理模块，用于在所述第二系统中基于所述目标数据对所述每个患者的治疗信息进行附加处理。

第三方面，本申请实施例还提供一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行第一方面任一项所述的数据对接方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行第一方面任一项所述的数据对接方法。

本申请实施例具有以下有益效果：

通过在单位时间内使用第一系统为每个患者开药，并通过第一系统获取单位时间内每个患者的开药信息，对开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，这样，在医院侧，仅需要提供封装后的数据(视图)即可，后续的开发可都由具体业务侧的工程师完成，减少沟通成本，最后，可以在所述第二系统中基于目标数据对所述每个患者的治疗信息进行附加处理，例如具体业务的后续收费，提高了业务侧与医院侧对接的效率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1是本申请实施例提供的步骤S101-S103的流程示意图；

图2是本申请实施例提供的步骤S201-S202的流程示意图；

图3是本申请实施例提供的步骤S301-S302的流程示意图；

图4是本申请实施例提供的步骤S401-S402的流程示意图；

图5是本申请实施例提供的步骤S501-S502的流程示意图；

图6是本申请实施例提供的数据对接装置的结构示意图；

图7是本申请实施例提供的电子设备的组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

在以下的描述中，所涉及的术语“第一第二第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一第二第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语是为了描述本申请实施例的目的，不是在限制本申请。

在实施本申请实施例时，申请人发现当前的对接方式存在如下问题：

(1)和his工程师沟通时，依赖于对方的配合程度和理解程度，当前这种对接方案，主要堆在工作量在his工程师身上，如果对方不配合，很难推进。

(2)同步his字典时，无法同步库存，分药品在血透系统开具后，his系统没有库存，his也无法开出这个药品。

(3)在实际业务中，一天的患者量在100-200左右，一个个患者传输，需要在页面上操作很多遍，很费时间。

(4)信息传输到his后，his在进行医保结算时，医保对信息有各种安全性、完整性、合规性的校验，传输到his的数据，无法直接使用。

参见图1，图1是本申请实施例提供的数据对接方法步骤S101-S103的流程示意图，将结合图1示出的步骤S101-S103进行说明。

步骤S101，在单位时间内通过第一系统为每个患者开药，并通过所述第一系统获取所述单位时间内所述每个患者的开药信息，所述开药信息不超过所述第一系统的药品库存；

步骤S102，对所述开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，其中，所述第二系统的数据与所述第一系统的数据不互通；

步骤S103，在所述第二系统中基于所述目标数据对所述每个患者的治疗信息进行附加处理。

上述数据对接方法，通过在单位时间内使用第一系统为每个患者开药，并通过第一系统获取单位时间内每个患者的开药信息，对开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，这样，在医院侧，仅需要提供封装后的数据(视图)即可，后续的开发可都由具体业务侧的工程师完成，减少沟通成本，最后，可以在所述第二系统中基于目标数据对所述每个患者的治疗信息进行附加处理，例如具体业务的后续收费，提高了业务侧与医院侧对接的效率。

下面分别对本申请实施例的上述示例性的各步骤进行说明。

在步骤S101中，在单位时间内通过第一系统为每个患者开药，并通过所述第一系统获取所述单位时间内所述每个患者的开药信息，所述开药信息不超过所述第一系统的药品库存。

这里，单位时间可以理解为任意长度的时间段，可以是一小时、一天、一周等任意的时间段，在本申请实施例中，单位时间选择为一天。

在一些实施例中，所述开药信息包括患者信息和医嘱信息；

所述患者信息包括以下信息至少之一：患者姓名、身份证号；

所述医嘱信息包括以下信息至少之一：药品名称、药品ID、单次用量、给药途径、开药数量、注射费用。

这里，第一系统可以是HIS系统，在开药时，仍然是在HIS系统中进行，然后进行医保结算，开药信息可以包括：患者姓名、身份证号、药品名称、药品ID、单次用量、给药途径、开药数量、注射费用。

在步骤S102中，对所述开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，其中，所述第二系统的数据与所述第一系统的数据不互通。

这里，第二系统可以是任意的业务平台，例如血透平台。同步目标数据时，不需要同步库存，因为开药信息是先在his系统生成，经过封装后同步到血透平台，如果his里面没有库存，则根本无法生成数据。

在一些实施例中，所述对所述开药信息进行封装处理，得到目标数据，包括：

针对所述开药信息创建目标视图，将所述目标视图作为所述目标数据；

针对所述目标视图创建目标接口，其中，所述目标接口用于获取所述目标视图。

这里，开药信息可以封装为目标视图的形式，视图，是指计算机数据库中的视图，是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。在将开药信息转换为视图后，可以设置对应的目标接口，用于获取目标视图，便于血透平台获取到这部分数据。

所述将所述目标数据同步至第二系统，包括：

通过所述目标接口将所述目标数据同步至所述第二系统。

这里，在血透平台获取到目标数据后，即可将目标数据同步到血透平台进行后续处理。

在一些实施例中，参见图2，图2是本申请实施例提供的步骤S201-S202的流程示意图，所述将所述目标数据同步至第二系统，可以通过步骤S201-S202实现，将结合各步骤进行说明。

在步骤S201中，在预设的目标时间节点时将所述目标数据同步至所述第二系统。

在步骤S202中，若所述第二系统中存在历史目标数据时，基于所述目标数据对所述历史目标数据进行覆盖；

或者，获取所述目标数据相较于所述历史目标数据的额外数据和差异数据，将所述额外数据写入所述历史目标数据以及将差异数据覆盖至存在差异的原数据，并对该差异进行标注。

在将目标数据同步至血透平台时，可以选择固定的同步时间，例如凌晨的某个时间点，在进行同步时，可以选择直接覆盖的方式，以新数据覆盖旧数据，永远只保留最新的数据；另一方面，也可以将目标数据和历史目标数据进行对比，获取新增的额外数据以及与历史目标数据不同的差异数据，对于新增的额外数据，直接添加即可，对于差异数据，覆盖掉存在差异的原数据并将差异予以标注，便于后续查看。

在一些实施例中，参见图3，图3是本申请实施例提供的步骤S301-S302的流程示意图，将集合各步骤进行说明。

在步骤S301中，针对每次将所述目标数据同步至第二系统的同步操作，对所述同步操作进行记录，得到同步版本。

在步骤S302中，响应于针对所述同步版本的回溯操作，将所述目标数据回溯至对应的同步版本。

这里，同步的数据会一直保留，覆盖的数据也会保留之前的所有记录，在每次进行同步时，都会记录队形的同步操作，例如，之前的记录为版本v1，同步后的版本为v2，同步操作为v1→v2，那么，在需要回溯时，可以将v2版本回滚至v1。并且，当用户需要查看任意版本的数据时，也可以查找对应版本的数据。

在一些实施例中，参见图4，图4是本申请实施例提供的步骤S401-S402的流程示意图，将集合各步骤进行说明。

在步骤S401中，若将所述目标数据同步至第二系统后，所述开药信息发生了改变，通过手动或自动的方式，对该改变进行同步。

在步骤S402中，当通过手动的方式对该改变进行同步时，响应于针对目标数据的同步请求，将改变后的所述目标数据手动同步至所述第二系统。

在步骤S403中，当通过自动的方式对该改变进行同步时，响应于针对预设频率的检测请求，对所述开药信息进行检测处理，若所述开药信息发生了改变，将改变后的所述目标数据自动同步至所述第二系统。

这里，血透系统在闲时，例如每天凌晨，会自动同步一次目标数据。同步后的白天中，若开药信息发生了改变，例如，患者补开了A药品，那么在血透平台中，由于第二次同步需要等到下一个凌晨，此时的数据已经发生了改变，因此，需要在执行一次同步，同步的方式可以采用手动同步的方式或自动同步的方式。

作为手动同步的示例，用户可以在血透平台中点击对应的同步按钮，发起同步请求，此时，会将HIS平台会将更新后的开药信息进行再次封装，然后同步至血透平台，血透平台在同步完成之后，即可进行后续操作。

作为自动同步的示例，可以在限时设定一个检测频率，例如，每半小时一次。每当经过半小时时，便会对开药信息进行主动检测，检测开药信息是否发生了改变。若开药信息发生了改变，则再执行一次同步，以保证血透平台和HIS平台的数据一致。

这样的方式，提供了多种在开药信息发生改变之后的应对方式，在开药信息发生了改变后，能够及时将本次改变进行同步。

在一些实施例中，参见图5，图5是本申请实施例提供的步骤S501-S502的流程示意图，将集合各步骤进行说明。

在步骤S501中，针对预设的目标数据类型，对所述目标数据中与所述目标数据类型相匹配的数据进行隐藏。

在步骤S502中，对同步后的所述目标数据添加同步记录。

在步骤S503中，显示同步后的所述目标数据。

示例的，在HIS系统中开药时，还会附带有例如注射费等相关费用信息，但是对于血透系统，无需关注这类信息，所以在同步之后，会汇总成一个列表，并在在列表中会默认隐藏掉这类无需关注的信息，以便于血透平台侧的用户进行查看。并且，该列表中的各项信息可以自行手动隐藏或者显示，以应对不同的需求。

这样的方式，使血透平台侧可以灵活调整需要显示的内容，并且对于通常无需关注的信息，会进行自动隐藏，减少了用户的操作量。

在步骤S103中，在所述第二系统中基于所述目标数据对所述每个患者的治疗信息进行附加处理。

示例的，在血透系统中，可以走正常的透析流程。该透析流程为血透系统中所涉及的具体业务，例如，血透过程中的后续收费。

综上所述，通过本申请实施例具有以下有益效果：

通过在单位时间内使用第一系统为每个患者开药，并通过第一系统获取单位时间内每个患者的开药信息，对开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，这样，在医院侧，仅需要提供封装后的数据(视图)即可，后续的开发可都由具体业务侧的工程师完成，减少沟通成本，最后，可以在所述第二系统中基于目标数据对所述每个患者的治疗信息进行附加处理，例如具体业务的后续收费，提高了业务侧与医院侧对接的效率。

基于同一发明构思，本申请实施例中还提供了与第一实施例中数据对接方法对应的数据对接装置，由于本申请实施例中的装置解决问题的原理与上述数据对接方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

如图6所示，图6是本申请实施例提供的数据对接装置600的结构示意图。数据对接装置600包括：

获取模块601，用于在单位时间内通过第一系统为每个患者开药，并通过所述第一系统获取所述单位时间内所述每个患者的开药信息，所述开药信息不超过所述第一系统的药品库存；

同步模块602，用于对所述开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，其中，所述第二系统的数据与所述第一系统的数据不互通；

处理模块603，用于在所述第二系统中基于所述目标数据对所述每个患者的治疗信息进行附加处理。

本领域技术人员应当理解，图6所示的数据对接装置600中的各单元的实现功能可参照前述数据对接方法的相关描述而理解。图6所示的数据对接装置600中的各单元的功能可通过运行于处理器上的程序而实现，也可通过具体的逻辑电路而实现。

在一种可能的实施方式中，同步模块602对所述开药信息进行封装处理，得到目标数据，包括：

针对所述开药信息创建目标视图，将所述目标视图作为所述目标数据；

针对所述目标视图创建目标接口，其中，所述目标接口用于获取所述目标视图。

所述将所述目标数据同步至第二系统，包括：

通过所述目标接口将所述目标数据同步至所述第二系统。

在一种可能的实施方式中，同步模块602将所述目标数据同步至第二系统，包括：

在预设的目标时间节点时将所述目标数据同步至所述第二系统；

若所述第二系统中存在历史目标数据时，基于所述目标数据对所述历史目标数据进行覆盖；

或者，获取所述目标数据相较于所述历史目标数据的额外数据和差异数据，将所述额外数据写入所述历史目标数据以及将差异数据覆盖至存在差异的原数据，并对该差异进行标注。

在一种可能的实施方式中，同步模块602还包括：

针对每次将所述目标数据同步至第二系统的同步操作，对所述同步操作进行记录，得到同步版本；

响应于针对所述同步版本的回溯操作，将所述目标数据回溯至对应的同步版本。

在一种可能的实施方式中，同步模块602还包括：

若将所述目标数据同步至第二系统后，所述开药信息发生了改变，通过手动或自动的方式，对该改变进行同步；

当通过手动的方式对该改变进行同步时，响应于针对目标数据的同步请求，将改变后的所述目标数据手动同步至所述第二系统；

当通过自动的方式对该改变进行同步时，响应于针对预设频率的检测请求，对所述开药信息进行检测处理，若所述开药信息发生了改变，将改变后的所述目标数据自动同步至所述第二系统。

在一种可能的实施方式中，同步模块602将所述目标数据同步至第二系统后，所述方法还包括：

针对预设的目标数据类型，对所述目标数据中与所述目标数据类型相匹配的数据进行隐藏；

对同步后的所述目标数据添加同步记录；

显示同步后的所述目标数据。

在一种可能的实施方式中，所述开药信息包括患者信息和医嘱信息；

所述患者信息包括以下信息至少之一：患者姓名、身份证号；

所述医嘱信息包括以下信息至少之一：药品名称、药品ID、单次用量、给药途径、开药数量、注射费用。

上述数据对接装置通过在单位时间内使用第一系统为每个患者开药，并通过第一系统获取单位时间内每个患者的开药信息，对开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，这样，在医院侧，仅需要提供封装后的数据(视图)即可，后续的开发可都由具体业务侧的工程师完成，减少沟通成本，最后，可以在所述第二系统中基于目标数据对所述每个患者的治疗信息进行附加处理，例如具体业务的后续收费，提高了业务侧与医院侧对接的效率。

如图7所示，图7为本申请实施例提供的电子设备700的组成结构示意图，所述电子设备700，包括：

处理器701、存储介质702和总线703，所述存储介质702存储有所述处理器701可执行的机器可读指令，当电子设备700运行时，所述处理器701与所述存储介质702之间通过总线703通信，所述处理器701执行所述机器可读指令，以执行本申请实施例所述的数据对接方法的步骤。

实际应用时，所述电子设备700中的各个组件通过总线703耦合在一起。可理解，总线703用于实现这些组件之间的连接通信。总线703除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图7中将各种总线都标为总线703。

上述电子设备通过在单位时间内使用第一系统为每个患者开药，并通过第一系统获取单位时间内每个患者的开药信息，对开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，这样，在医院侧，仅需要提供封装后的数据(视图)即可，后续的开发可都由具体业务侧的工程师完成，减少沟通成本，最后，可以在所述第二系统中基于目标数据对所述每个患者的治疗信息进行附加处理，例如具体业务的后续收费，提高了业务侧与医院侧对接的效率。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有可执行指令，当所述可执行指令被至少一个处理器701执行时，实现本申请实施例所述的数据对接方法。

在一些实施例中，存储介质可以是磁性随机存取存储器(FRAM，FerromagneticRandom Access Memory)、只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM，ErasableProgrammable Read Only Memory)、电可擦除可编程只读存储器(EEPROM，ElectricallyErasable Programmable Read Only Memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD ROM，Compact Disc Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，HyperTextMarkupLanguage)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

上述计算机可读存储介质通过在单位时间内使用第一系统为每个患者开药，并通过第一系统获取单位时间内每个患者的开药信息，对开药信息进行封装处理，得到目标数据，并将所述目标数据同步至第二系统，这样，在医院侧，仅需要提供封装后的数据(视图)即可，后续的开发可都由具体业务侧的工程师完成，减少沟通成本，最后，可以在所述第二系统中基于目标数据对所述每个患者的治疗信息进行附加处理，例如具体业务的后续收费，提高了业务侧与医院侧对接的效率。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法和电子设备，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，平台服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。