CN111126947B - 业务数据的集成管理方法、装置、介质及电子设备 - Google Patents

Abstract

本发明提供了一种业务数据的集成管理方法、装置、介质及电子设备，该方法包括：确定一级业务主体以及与一级业务主体具有关联关系的多个二级业务主体；获取由业务申请主体提交的业务数据集成申请，并将业务数据集成申请发送至与业务申请主体相关联的业务初审主体，以得到由业务初审主体返回的业务初审结果；当业务初审结果为审核通过时，将业务数据集成申请以及业务初审结果发送至一级业务主体，以得到由一级业务主体返回的业务终审结果；当业务终审结果为审核通过时，根据业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志。该方法降低了业务数据的管理难度和管理成本，提高了业务处理效率。

Description

业务数据的集成管理方法、装置、介质及电子设备

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种业务数据的集成管理方法、业务数据的集成管理装置、计算机可读介质及电子设备。

背景技术

随着计算机和网络技术的发展，越来越多的企业和机构开始采用无纸化办公，利用网络工具进行数据交互和处理，从而提高业务处理效率、降低业务处理成本。对于具有较多分支机构的大型企事业单位而言，由于业务分级和分工的不同，一般难以实现多业务组织的统一管控，导致各分支机构各行其事，各采所需，无法发挥集团化的集中管控的成本和效率优势，也很难保障一体化的服务质量，更会在成本与效益核算方面带来巨大差异性和管理的复杂性。因此，如何实现业务数据的集成化管理是目前亟待解决的问题。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本发明的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本发明实施例的目的在于提供一种业务数据的集成管理方法、业务数据的集成管理装置、计算机可读介质及电子设备，进而至少在一定程度上克服相关技术中存在的业务处理效率低、数据管理难度大、数据管理成本高等技术问题。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明实施例的第一方面，提供了一种业务数据的集成管理方法，该方法包括：

确定一级业务主体以及与所述一级业务主体具有关联关系的多个二级业务主体，所述二级业务主体包括具有关联关系的业务申请主体和业务初审主体；

获取由所述业务申请主体提交的业务数据集成申请，并将所述业务数据集成申请发送至与所述业务申请主体相关联的业务初审主体，以得到由所述业务初审主体返回的业务初审结果；

当所述业务初审结果为审核通过时，将所述业务数据集成申请以及所述业务初审结果发送至所述一级业务主体，以得到由所述一级业务主体返回的业务终审结果；

当所述业务终审结果为审核通过时，根据所述业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志。

在本发明的一些实施例中，基于以上技术方案，所述获取由所述业务申请主体提交的业务数据集成申请，包括：

接收由多个所述业务申请主体发送的申请摘要，并将所述申请摘要保存至摘要处理队列；

依次从所述摘要处理队列中读取申请摘要，并从所述申请摘要中获取所述业务申请主体的主体标识信息和申请类型信息；

根据所述主体标识信息确定申请权限信息，并根据所述申请权限信息和所述申请类型信息判断所述业务申请主体是否具有申请权限；

当判定所述业务申请主体具有申请权限时，根据所述主体标识信息确定与所述业务申请主体相对应的数据接口；

通过所述数据接口获取由所述业务申请主体提交的业务数据集成申请。

在本发明的一些实施例中，基于以上技术方案，所述将所述申请摘要保存至摘要处理队列，包括：

获取与所述申请摘要相对应的优先级信息和时限信息；

根据所述优先级信息和时限信息确定所述申请摘要的排列位置；

基于所述排列位置将所述申请摘要保存至摘要处理队列。

在本发明的一些实施例中，基于以上技术方案，所述将所述业务数据集成申请发送至与所述业务申请主体相关联的业务初审主体，包括：

获取与所述业务申请主体相关联的业务初审主体的审核权限；

根据所述审核权限将所述业务数据集成申请中携带的申请数据划分为初审数据和终审数据；

对所述终审数据做加密处理后，将所述业务数据集成申请发送至所述业务初审主体。

在本发明的一些实施例中，基于以上技术方案，所述根据所述业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志，包括：

根据所述业务数据集成申请确定业务数据集成管理目录的目录更新信息，并将所述目录更新信息保存至目录区块链；

根据所述业务数据集成申请确定业务数据集成管理日志的日志更新信息，并将所述日志更新信息保存至日志区块链。

在本发明的一些实施例中，基于以上技术方案，所述将所述目录更新信息保存至目录区块链，包括：

将所述目录更新信息保存在待共识的当前目录区块的区块主体中；

在满足区块生成条件时，获取目录区块链中上一目录区块的区块头数据，并根据所述区块头数据计算得到当前目录区块的父区块哈希值；

根据所述当前目录区块的区块主体中保存的数据计算所述当前目录区块的区块主体哈希值；

将所述父区块哈希值、所述区块主体哈希值以及当前时间的时间戳保存在所述当前目录区块的区块头中；

将所述当前目录区块广播至区块链网络以对所述当前目录区块进行共识认证，并在认证通过时将所述当前目录区块链接至所述目录区块链上。

在本发明的一些实施例中，基于以上技术方案，所述将所述日志更新信息保存至日志区块链，包括：

将所述日志更新信息保存在待共识的当前日志区块的区块主体中；

在满足区块生成条件时，获取日志区块链中上一日志区块的区块头数据，并根据所述区块头数据计算得到当前日志区块的父区块哈希值；

根据所述当前日志区块的区块主体中保存的数据计算所述当前日志区块的区块主体哈希值；

将所述父区块哈希值、所述区块主体哈希值以及当前时间的时间戳保存在所述当前日志区块的区块头中；

将所述当前日志区块广播至区块链网络以对所述当前日志区块进行共识认证，并在认证通过时将所述当前日志区块链接至所述日志区块链上。

根据本发明实施例的第二方面，提供一种业务数据的集成管理装置，该装置包括：

主体确定模块，被配置为确定一级业务主体以及与所述一级业务主体具有关联关系的多个二级业务主体，所述二级业务主体包括具有关联关系的业务申请主体和业务初审主体；

业务初审模块，被配置为获取由所述业务申请主体提交的业务数据集成申请，并将所述业务数据集成申请发送至与所述业务申请主体相关联的业务初审主体，以得到由所述业务初审主体返回的业务初审结果；

业务终审模块，被配置为当所述业务初审结果为审核通过时，将所述业务数据集成申请以及所述业务初审结果发送至所述一级业务主体，以得到由所述一级业务主体返回的业务终审结果；

数据更新模块，被配置为当所述业务终审结果为审核通过时，根据所述业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志。

根据本发明实施例的第三方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述实施例中第一方面所述的业务数据的集成管理方法。

根据本发明实施例的第四方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中第一方面所述的业务数据的集成管理方法。

本发明实施例提供的技术方案可以包括以下有益效果：

在本发明的一些实施例所提供的技术方案中，通过采用两级管理模式，按照一级业务主体和二级业务主体的不同职能进行管理职责切分，实现了业务数据的多层级集成化管理，提高了数据管理效率和管理质量，同时也提升了业务数据在各个层级的各个主体之间的高效流转，降低了业务数据的管理难度和管理成本，提高了业务处理效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示意性地示出了本发明一些实施例中业务数据的集成管理方法的步骤流程图。

图2示意性地示出了本发明一些实施例中获取业务数据集成申请的步骤流程图。

图3示意性地示出了本发明一些实施例中保存申请摘要的步骤流程图。

图4示意性地示出了本发明一些实施例中向业务初审主体发送业务数据集成申请的步骤流程图。

图5示意性地示出了本发明一些实施例中更新业务数据集成管理目录和业务数据集成管理日志的步骤流程图。

图6示意性地示出了本发明一些实施例中保存目录更新信息的步骤流程图。

图7示意性地示出了本发明一些实施例中保存日志更新信息的步骤流程图。

图8示意性地示出了本发明一些实施例中的业务数据的集成管理装置的组成框图。

图9示意性地示出了本发明在一应用场景中的药品主数据管理流程。

图10示意性地示出了本发明在一应用场景中的耗材主数据管理流程。

图11示意性地示出了本发明在一应用场景中的设备主数据管理流程。

图12示意性地示出了本发明在一应用场景中的医疗服务主数据管理流程。

图13示意性地示出了本发明在一应用场景中的主数据管理系统功能架构。

图14示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本发明的各方面。

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

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

本发明首先提供一种业务数据的集成管理方法，用以实现在不同层级的多种组织机构之间进行业务数据的集成化管理。图1示意性地示出了本发明一些实施例中业务数据的集成管理方法的步骤流程图。如图1所示，该方法主要可以包括以下步骤：

步骤S110.确定一级业务主体以及与一级业务主体具有关联关系的多个二级业务主体，二级业务主体包括具有关联关系的业务申请主体和业务初审主体。

一级业务主体与二级业务主体属于两个不同的业务层级，具有不同的业务职能和数据管理权限。例如，一级业务主体为集团总部的某个职能部门，二级业务主体可以是与集团总部具有从属关系的多个分支机构。每个二级业务主体均包括有两个相关关联的业务申请主体和业务初审主体。业务申请主体用于发起业务数据的管理申请，而业务初审主体则用于对业务申请主体发起的管理申请进行初步审核。

步骤S120.获取由业务申请主体提交的业务数据集成申请，并将业务数据集成申请发送至与业务申请主体相关联的业务初审主体，以得到由业务初审主体返回的业务初审结果。

利用预先配置的主数据模板，每个二级业务主体中的业务申请主体均可以自主提交业务数据集成申请。针对不同的业务对象，可以配置相应的主数据模板，主数据模板中包括与业务对象相关的多个属性维度，例如可以包括对象基本属性、采购管理属性、财务管理属性、机构运营属性等等。业务申请主体通过采集业务对象的相关属性信息可以填写完成业务数据集成申请。业务数据集成申请可以包括针对业务对象的对象新增申请、对象变更申请、对象停用申请等多种申请类型。在获取到业务申请主体提交的业务数据集成申请后，可以将该申请发送至与业务申请主体具有关联关系的业务初审主体，在由业务初审主体对业务数据集成申请的内容进行初步审核后得到相应的业务初审结果。

步骤S130.当业务初审结果为审核通过时，将业务数据集成申请以及业务初审结果发送至一级业务主体，以得到由一级业务主体返回的业务终审结果。

经过业务初审主体的初步审核后，可以得到审核通过或者审核未通过两种业务初审结果。如果业务初审结果是审核未通过，那么该业务数据集成申请将被返回给业务申请主体，由业务申请主体根据业务初审结果调整申请内容或者放弃申请。如果业务初审结果是审核通过，那么本步骤可以将业务申请主体提交的业务数据集成申请以及业务初审主体得到的业务初审结果共同发送至对应的一级业务主体。一级业务主体接收到业务数据集成申请和业务初审结果后，可以结合业务初审结果对业务数据集成申请做进一步审核。

步骤S140.当业务终审结果为审核通过时，根据业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志。

经过一级业务主体的最终审核后，可以得到审核通过或者审核未通过两种业务终审结果。如果业务终审结果为审核未通过，那么该业务数据集成申请以及业务初审结果将被返回给业务申请主体，由业务申请主体根据业务终审结果调整申请内容或者放弃申请。如果业务终审结果为审核通过，那么本步骤可以根据业务数据集成申请的具体申请内容更新业务数据集成管理目录，同时更新与业务数据集成管理目录相关的业务数据集成管理日志。

在本发明实施例提供的业务数据的集成管理方法中，通过采用两级管理模式，按照一级业务主体和二级业务主体的不同职能进行管理职责切分，实现了业务数据的多层级集成化管理，提高了数据管理效率和管理质量，同时也提升了业务数据在各个层级的各个主体之间的高效流转，降低了业务数据的管理难度和管理成本，提高了业务处理效率。

每个二级业务主体中的业务申请主体均可以根据自身的业务需求发起业务数据集成申请，图2示意性地示出了本发明一些实施例中获取业务数据集成申请的步骤流程图。如图2所示，在以上实施例的基础上，步骤S120中的获取由业务申请主体提交的业务数据集成申请，可以包括以下步骤：

步骤S210.接收由多个业务申请主体发送的申请摘要，并将申请摘要保存至摘要处理队列。

为了提高业务数据集成申请的处理效率，本发明实施例可以利用摘要处理队列保存每个业务申请主体发送的申请摘要。当一个业务申请主体需要提交业务数据集成申请时，便可以先发送相应的申请摘要，保存在摘要处理队列中等待处理。

步骤S220.依次从摘要处理队列中读取申请摘要，并从申请摘要中获取业务申请主体的主体标识信息和申请类型信息。

按照摘要处理队列中各个申请摘要的排列顺序依次读取申请摘要，通过对申请摘要进行数据分析可以得到发出该申请摘要的业务申请主体的主体标识信息、申请权限信息以及申请类型信息。主体标识信息用于区分不同的业务申请主体，申请类型信息用于确定业务数据集成申请对应的业务对象的对象类型。

步骤S230.根据主体标识信息确定申请权限信息，并根据申请权限信息和申请类型信息判断业务申请主体是否具有申请权限。

不同的业务申请主体具有相同或者不同的申请权限，根据主体标识信息可以确定相应的申请权限信息，该申请权限信息即用于确定业务申请主体的申请权限。根据申请权限信息和申请类型信息可以判断业务申请主体是否具有申请权限。例如某些业务申请主体只能对指定类型的业务对象提交业务数据集成申请，对于超出指定类型范围的业务对象，业务申请主体不具有申请权限。

步骤S240.当判定业务申请主体具有申请权限时，根据主体标识信息确定与业务申请主体相对应的数据接口。

各个业务申请主体均配置有专门针对业务数据集成申请进行数据通信的数据接口。如果判定业务申请主体具有申请权限，本步骤便可以根据主体标识信息确定与业务申请主体相对应的数据接口。如果判定业务申请主体不具有申请权限，那么相应的数据接口将始终保持关闭状态。

步骤S250.通过数据接口获取由业务申请主体提交的业务数据集成申请。

通过步骤S240中确定的数据接口可以获取由业务申请主体提交的业务数据集成申请，后续便可以对获取到的业务数据集成申请进行审核。

摘要处理队列中申请摘要的排列顺序决定了各个申请摘要的处理顺序。图3示意性地示出了本发明一些实施例中保存申请摘要的步骤流程图。如图3所示，在以上各实施例的基础上，步骤S210中的将申请摘要保存至摘要处理队列，可以包括以下步骤：

步骤S310.获取与申请摘要相对应的优先级信息和时限信息。

为了提高对申请摘要的处理效率，每个申请摘要可以配置对应于不同处理优先级的优先级信息，优先级较高的申请摘要将被优先处理。同时，为了提高申请摘要的处理时效性，每个申请摘要还可以配置对应于不同处理时限的时限信息。

步骤S320.根据优先级信息和时限信息确定申请摘要的排列位置。

在摘要处理队列中可以按照处理时限和处理优先级两方面信息对申请摘要进行排序，例如可以首先按照处理优先级将摘要处理队列划分为多个子队列，一个子队列中的申请摘要对应于同一个处理优先级，优先级较高的子队列中的申请摘要将被优先处理。同一子队列中的申请摘要可以按照处理时限进行排序，对应于同一处理时限的多个申请摘要再按照提交时间的先后顺序进行排序。

步骤S330.基于排列位置将申请摘要保存至摘要处理队列。

根据优先级信息和时限信息确定申请摘要的排列位置后，本步骤按照确定的位置将申请摘要保存在摘要处理队列中。按照排列顺序依次对各个申请摘要进行处理后可以确定是否需要获取与申请摘要对应的业务数据集成申请。

图4示意性地示出了本发明一些实施例中向业务初审主体发送业务数据集成申请的步骤流程图。如图4所示，在以上各实施例的基础上，步骤S120中的将业务数据集成申请发送至与业务申请主体相关联的业务初审主体，可以包括以下步骤：

步骤S410.获取与业务申请主体相关联的业务初审主体的审核权限。

各个业务初审主体可以预先配置范围不同的审核权限，审核权限的范围大小与业务初审主体的自身属性、业务对象的类型和业务对象的属性等多种信息相关。一般而言，一个业务初审主体只能对一项业务数据集成申请中携带的部分申请数据具有审核权限。

步骤S420.根据审核权限将业务数据集成申请中携带的申请数据划分为初审数据和终审数据。

根据步骤S410中获取到的审核权限，本步骤可以对业务数据集成申请中携带的申请数据划分为两部分，其中属于业务初审主体审核权限范围内的部分数据为初审数据，在其审核权限范围之外的部分数据则为终审数据。

步骤S430.对终审数据做加密处理后，将业务数据集成申请发送至业务初审主体。

业务初审主体不具有终审数据的审核权限，为了提高数据安全性，本步骤可以对申请数据中的终审数据做加密处理，然后可以将携带初审数据和加密后的终审数据的业务数据集成申请发送至业务初审主体，由业务初审主体对未加密的初审数据部分进行初步审核。

在初步审核通过的情况下，后续可以再对终审数据进行解密处理，然后由一级业务主体对解密后得到的终审数据做进一步审核。若终审通过，则可以根据业务数据集成申请对业务数据集成管理目录以及业务数据集成管理日志进行更新。

图5示意性地示出了本发明一些实施例中更新业务数据集成管理目录和业务数据集成管理日志的步骤流程图。如图5所示，在以上各实施例的基础上，步骤S140中的根据业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志，可以包括以下步骤：

步骤S510.根据业务数据集成申请确定业务数据集成管理目录的目录更新信息，并将目录更新信息保存至目录区块链。

业务数据集成申请可以是针对业务数据集成管理目录中某一个或者某几个业务对象的新增申请、变更申请或者停用申请等不同的申请类型。基于业务数据集成申请确定的业务数据集成管理目录的目录更新信息可以保存在由区块链网络维护的目录区块链中，实现对业务数据集成管理目录进行数据共享的同时，提高业务数据集成管理目录的存储安全性。

步骤S520.根据业务数据集成申请确定业务数据集成管理日志的日志更新信息，并将日志更新信息保存至日志区块链。

业务数据集成管理日志用于记录针对业务数据集成管理目录的更新历史，用以提高业务数据集成管理目录的可追溯性。基于业务数据集成申请确定的业务数据集成管理日志的日志更新信息可以保存在由区块链网络维护的日志区块链中。目录区块链和日志区块链可以由同一区块链网络进行维护，提高数据共识的可靠性。

图6示意性地示出了本发明一些实施例中保存目录更新信息的步骤流程图。如图6所示，在以上各实施例的基础上，步骤S510中的将目录更新信息保存至目录区块链，可以包括以下步骤：

步骤S610.将目录更新信息保存在待共识的当前目录区块的区块主体中。

组成目录区块链的每个目录区块都包括有区块头和区块主体两部分数据存储区域，其中区块主体用于存储当前目录区块中记录的全部数据，例如目录更新信息便保存在当前目录区块的区块主体中。区块头用于存储当前目录区块与上一目录区块的链接信息，利用区块头中存储的数据可以将所有目录区块逐一链接形成完整的目录区块链。

步骤S620.在满足区块生成条件时，获取目录区块链中上一目录区块的区块头数据，并根据区块头数据计算得到当前目录区块的父区块哈希值。

在满足一定的区块生成条件条件时，本步骤可以获取目录区块链中的上一目录区块(即最近生成的新的目录区块)的区块头数据，根据该区块头数据可以计算得到当前目录区块的父区块哈希值。例如可以使用SHA256算法对上一目录区块的区块头数据进行哈希运算得到一哈希值，以作为当前目录区块的父区块哈希值。本步骤中的区块生成条件可以是距离上一目录区块的生成时间达到一时间阈值，也可以是当前目录区块的区块主体中存储的数据达到一数据量阈值，另外还可以是其他的用于触发新区块生成的任意预设条件，本实施例对此不做特殊限定。

步骤S630.根据当前目录区块的区块主体中保存的数据计算当前目录区块的区块主体哈希值。

当前目录区块的区块主体中存储有在一段时间内形成的目录更新信息。根据区块主体中保存的数据，本步骤可以得到一哈希值作为当前目录区块的区块主体哈希值。以哈希编码为例，区块主体中的所有目录更新信息可以以默克尔树(Merkle Tree)的形式保存在区块主体中。具体可以将目录更新信息保存在默克尔树的叶子节点中，将每两个相邻的叶子节点中保存的目录更新信息进行组合后再次做哈希运算即可得到一个子节点中保存的哈希值。采用这种对子节点存储的哈希值两两组合逐层向上做哈希运算的方式，最终可以得到一个根节点哈希值，该根节点哈希值即可以作为当前目录区块的区块主体哈希值。

步骤S640.将父区块哈希值、区块主体哈希值以及当前时间的时间戳保存在当前目录区块的区块头中。

由步骤S620和步骤S630分别计算得到父区块哈希值和区块主体哈希值后，本步骤可以根据当前时间生成一时间戳，该时间戳用于记录当前目录区块的生成时间。然后可以将父区块哈希值、区块主体哈希值以及时间戳共同保存在当前目录区块的区块头中。

步骤S650.将当前目录区块广播至区块链网络以对当前目录区块进行共识认证，并在认证通过时将当前目录区块链接至目录区块链上。

完成区块头数据的保存后，本步骤将把由区块头和区块主体构成的当前目录区块广播至区块链网络。在通过共识认证后，由区块链网络中的全部或者部分区块链节点对当前目录区块进行保存，即完成当前目录区块在目录区块链的入链过程。

图7示意性地示出了本发明一些实施例中保存日志更新信息的步骤流程图。如图7所示，在以上各实施例的基础上，步骤S520中的将日志更新信息保存至日志区块链，可以包括以下步骤：

步骤S710.将日志更新信息保存在待共识的当前日志区块的区块主体中。

组成日志区块链的每个日志区块都包括有区块头和区块主体两部分数据存储区域，其中区块主体用于存储当前日志区块中记录的全部数据，例如日志更新信息便保存在当前日志区块的区块主体中。区块头用于存储当前日志区块与上一日志区块的链接信息，利用区块头中存储的数据可以将所有日志区块逐一链接形成完整的日志区块链。

步骤S720.在满足区块生成条件时，获取日志区块链中上一日志区块的区块头数据，并根据区块头数据计算得到当前日志区块的父区块哈希值。

在满足一定的区块生成条件条件时，本步骤可以获取日志区块链中的上一日志区块(即最近生成的新的日志区块)的区块头数据，根据该区块头数据可以计算得到当前日志区块的父区块哈希值。例如可以使用SHA256算法对上一日志区块的区块头数据进行哈希运算得到一哈希值，以作为当前日志区块的父区块哈希值。本步骤中的区块生成条件可以是距离上一日志区块的生成时间达到一时间阈值，也可以是当前日志区块的区块主体中存储的数据达到一数据量阈值，另外还可以是其他的用于触发新区块生成的任意预设条件，本实施例对此不做特殊限定。

步骤S730.根据当前日志区块的区块主体中保存的数据计算当前日志区块的区块主体哈希值。

当前日志区块的区块主体中存储有在一段时间内形成的日志更新信息。根据区块主体中保存的数据，本步骤可以得到一哈希值作为当前日志区块的区块主体哈希值。以哈希编码为例，区块主体中的所有日志更新信息可以以默克尔树(Merkle Tree)的形式保存在区块主体中。具体可以将日志更新信息保存在默克尔树的叶子节点中，将每两个相邻的叶子节点中保存的日志更新信息进行组合后再次做哈希运算即可得到一个子节点中保存的哈希值。采用这种对子节点存储的哈希值两两组合逐层向上做哈希运算的方式，最终可以得到一个根节点哈希值，该根节点哈希值即可以作为当前日志区块的区块主体哈希值。

步骤S740.将父区块哈希值、区块主体哈希值以及当前时间的时间戳保存在当前日志区块的区块头中。

由步骤S720和步骤S730分别计算得到父区块哈希值和区块主体哈希值后，本步骤可以根据当前时间生成一时间戳，该时间戳用于记录当前日志区块的生成时间。然后可以将父区块哈希值、区块主体哈希值以及时间戳共同保存在当前日志区块的区块头中。

步骤S750.将当前日志区块广播至区块链网络以对当前日志区块进行共识认证，并在认证通过时将当前日志区块链接至日志区块链上。

完成区块头数据的保存后，本步骤将把由区块头和区块主体构成的当前日志区块广播至区块链网络。在通过共识认证后，由区块链网络中的全部或者部分区块链节点对当前日志区块进行保存，即完成当前日志区块在日志区块链的入链过程。

以下介绍本发明的装置实施例，可以用于执行本发明上述的业务数据的集成管理方法。

图8示意性地示出了本发明一些实施例中的业务数据的集成管理装置的组成框图。如图8所示，集成管理装置800主要可以包括：

主体确定模块810，被配置为确定一级业务主体以及与一级业务主体具有关联关系的多个二级业务主体，二级业务主体包括具有关联关系的业务申请主体和业务初审主体；

业务初审模块820，被配置为获取由业务申请主体提交的业务数据集成申请，并将业务数据集成申请发送至与业务申请主体相关联的业务初审主体，以得到由业务初审主体返回的业务初审结果；

业务终审模块830，被配置为当业务初审结果为审核通过时，将业务数据集成申请以及业务初审结果发送至一级业务主体，以得到由一级业务主体返回的业务终审结果；

数据更新模块840，被配置为当业务终审结果为审核通过时，根据业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志。

在本发明的一些实施例中，基于以上各实施方式，业务初审模块820可以进一步包括：

摘要接收模块，被配置为接收由多个业务申请主体发送的申请摘要，并将申请摘要保存至摘要处理队列；

摘要读取模块，被配置为依次从摘要处理队列中读取申请摘要，并从申请摘要中获取业务申请主体的主体标识信息和申请类型信息；

权限确定模块，被配置为根据主体标识信息确定申请权限信息，并根据申请权限信息和申请类型信息判断业务申请主体是否具有申请权限；

接口确定模块，被配置为当判定业务申请主体具有申请权限时，根据主体标识信息确定与业务申请主体相对应的数据接口；

申请获取模块，被配置为通过数据接口获取由业务申请主体提交的业务数据集成申请。

在本发明的一些实施例中，基于以上各实施方式，摘要接收模块可以进一步包括：

信息获取模块，被配置为获取与申请摘要相对应的优先级信息和时限信息；

位置确定模块，被配置为根据优先级信息和时限信息确定申请摘要的排列位置；

摘要保存模块，被配置为基于排列位置将申请摘要保存至摘要处理队列。

在本发明的一些实施例中，基于以上各实施方式，业务初审模块820可以进一步包括：

权限获取模块，被配置为获取与业务申请主体相关联的业务初审主体的审核权限；

数据划分模块，被配置为根据审核权限将业务数据集成申请中携带的申请数据划分为初审数据和终审数据；

数据加密模块，被配置为对终审数据做加密处理后，将业务数据集成申请发送至业务初审主体。

在本发明的一些实施例中，基于以上各实施方式，数据更新模块840可以包括：

目录更新模块，被配置为根据业务数据集成申请确定业务数据集成管理目录的目录更新信息，并将目录更新信息保存至目录区块链；

日志更新模块，被配置为根据业务数据集成申请确定业务数据集成管理日志的日志更新信息，并将日志更新信息保存至日志区块链。

在本发明的一些实施例中，基于以上各实施方式，目录更新模块可以进一步包括：

目录区块主体保存模块，被配置为将目录更新信息保存在待共识的当前目录区块的区块主体中；

目录父区块哈希值生成模块，被配置为在满足区块生成条件时，获取目录区块链中上一目录区块的区块头数据，并根据区块头数据计算得到当前目录区块的父区块哈希值；

目录区块主体哈希值生成模块，被配置为根据当前目录区块的区块主体中保存的数据计算当前目录区块的区块主体哈希值；

目录区块头保存模块，被配置为将父区块哈希值、区块主体哈希值以及当前时间的时间戳保存在当前目录区块的区块头中；

目录区块链接模块，被配置为将当前目录区块广播至区块链网络以对当前目录区块进行共识认证，并在认证通过时将当前目录区块链接至目录区块链上。

在本发明的一些实施例中，基于以上各实施方式，日志更新模块可以进一步包括：

日志区块主体保存模块，被配置为将日志更新信息保存在待共识的当前日志区块的区块主体中；

日志父区块哈希值生成模块，被配置为在满足区块生成条件时，获取日志区块链中上一日志区块的区块头数据，并根据区块头数据计算得到当前日志区块的父区块哈希值；

日志区块主体哈希值生成模块，被配置为根据当前日志区块的区块主体中保存的数据计算当前日志区块的区块主体哈希值；

日志区块头保存模块，被配置为将父区块哈希值、区块主体哈希值以及当前时间的时间戳保存在当前日志区块的区块头中；

日志区块链接模块，被配置为将当前日志区块广播至区块链网络以对当前日志区块进行共识认证，并在认证通过时将当前日志区块链接至日志区块链上。

由于本发明的示例实施例的业务数据的集成管理装置的各个功能模块与上述业务数据的集成管理方法的示例实施例的步骤对应，因此对于本发明装置实施例中未披露的细节，请参照本发明上述的业务数据的集成管理方法的实施例。

下面结合一具体应用场景对本发明以上各实施例的业务数据的集成管理方法以及集成管理装置的细节做出详细说明。

本应用场景是通过设计一套统一管理的药品、耗材、设备和服务等供应链主数据模型及数据标准，实现集团化的主数据统一管理，提升数据质量，提升药品数据在医疗单位组织里高效流转，快速支撑药品采购、入库与出库等流程。

本发明通过集团化两级医疗实体的调查研究，制定设计了一套适合集团化集中管控，可以覆盖多业态多形态医疗组织的药品、耗材、设备和医疗服务等内容的业务活动与场景。合理科学的主数据模板设计可以满足集团供应链部门的药品等物料的集团化管理，也可以满足二级医院组织机构的个性化业务模式的开展，以及药品订购、存储和使用的全流程的管控，包括病人使用了高价值耗材的长周期追溯等场景。

在集团定义满足集团和医院使用的药品、耗材、设备、服务的主数据模板，满足集团供应链部门和二级医院在药品、耗材、设备、服务的业务应用，并且统一定义包含的数据信息和定义。

表1为针对药品应用的药品主数据模板。该模板可以用于提交药品申请。

表1 药品主数据模板

图9示意性地示出了本发明在一应用场景中的药品主数据管理流程。如图9所示，药品采用两级管理模式，按照二级医疗机构和总部管理的职责进行管理职责切分，由实际药品需用的二级医疗机构提出药品申请，经本医疗机构相关部门科室进行业务审核后(重点审核归属医疗机构审核的部分)，流转至集团进行数据终审(审核集团管控部分内容)，审核通过的进入集团药品目录，可被使用。

表2为针对耗材应用的耗材主数据模板。该模板可以用于提交耗材申请。

表2 耗材主数据模板

图10示意性地示出了本发明在一应用场景中的耗材主数据管理流程。如图10所示，耗材采用两级管理模式，按照二级医疗机构和总部管理的职责进行管理职责切分，由实际耗材需用的二级医疗机构提出耗材申请，经本医疗机构相关部门科室进行业务审核后(重点审核归属医疗机构审核的部分)，流转至集团进行数据终审(审核集团管控部分内容)，审核通过的进入可使用耗材目录，可被使用。

表3为针对设备应用的设备主数据模板。该模板可以用于提交设备申请。

表3 设备主数据模板

图11示意性地示出了本发明在一应用场景中的设备主数据管理流程。如图11所示，设备采用两级管理模式，按照二级医疗机构和总部管理的职责进行管理职责切分，由实际设备需用的二级医疗机构提出设备申请，经本医疗机构相关部门科室进行业务审核后(重点审核归属医疗机构审核的部分)，流转至集团进行数据终审(审核集团管控部分内容)，审核通过的进入可使用设备目录，可被使用。

表4为针对医疗服务应用的医疗服务主数据模板。该模板可以用于提交医疗服务申请。

表4 医疗服务主数据模板

图12示意性地示出了本发明在一应用场景中的医疗服务主数据管理流程。如图12所示，医疗服务采用两级管理模式，按照二级医疗机构和总部管理的职责进行管理职责切分，由实际医疗服务需用的二级医疗机构提出本医院所需的医疗服务项目数据申请，经本医疗机构相关部门科室进行业务审核后(重点审核归属医疗机构审核的部分)，流转至集团进行数据终审(审核集团管控部分内容)，审核通过的进入可使用医疗服务项目目录，可被使用。

图13示意性地示出了本发明在一应用场景中的主数据管理系统功能架构。如图13所示，其核心功能包含数据模型管理，数据全生命周期操作管理、数据工作流、数集成、数据门户等，支持从数据模型定义到数据申请、校验、操作以及数据分发和数据服务提供等完整数据管理功能。

1、药品、耗材、设备、服务主数据模板管理

具备通过配置化的方式实现对药品、耗材、设备、服务主数据填报模板的定义、管理和授权。

(1)编码管理功能，进行药品、耗材、设备、服务主数据填报模板的编码规则定义，支持通过配置化方式进行流水码、有意义编码的定义，实现数据申请时的系统自动赋码功能，不再手工赋码。

(2)填报模板管理功能，进行药品、耗材、设备、服务主数据填报模板的定义，支持通过配置化的方式进行药品、耗材、设备、服务主数据填报模板定义的各属性的定义和维护，包含属性代码、属性名称、属性类型、属性长度、属性填写方式(文本框、下拉列表、引用其他数据标准)。

(3)填报模板校验管理功能，进行药品、耗材、设备、服务主数据填报模板的质量和填写控制定义，支持通过配置化的方式对药品、耗材、设备、服务主数据填报模板构成的各属性进行唯一性定义、取值范围校验、填写控制(必填、非必填、默认值、字段属性关联控制)、属性授权(授权该属性的维护角色)配置，最大化减少数据填写时的人工判断和校验。

(4)数据模型发布管理，数据模型包含上述的编码管理、填报模板管理、校验管理内容，完成所有相关配置后，进行数据模型发布，通过指定审核角色审核后，实现数据模型发布。

(5)数据模型维护管理，鉴于数据模型是随着管理深化和管理要求存在变化的，提供数据模型维护管理功能，支持通过维护功能对已发布的数据模型进行相应的编码规则、填写模板、校验控制进行修订和完善，然后再重新通过审核后发布使用，并记录数据模型的版本和变化内容。

2、药品、耗材、设备、服务主数据填报管理

提供系统在线的药品、耗材、设备、服务主数据填报、审核、发布、维护、停用等全生命周期管理功能。

(1)数据申请功能，当需要增加一条药品、耗材、设备、服务主数据时，可通过系统提供的数据申请功能进行数据的在线申请，支持单条或通过数据模板的excel批量申请操作，在数据申请时提供填写的系统智能校验，辅助填报用户进行数据填写错误的判断和提醒。填报时支持按照填报用户的数据权限进行数据视图划分，各数据填报角色仅填报自己权限内的数据内容，通过系统进行视图串联，满足管理所需的权限划分需要。填报完成，点击“保存”，进行数据单条或批量提交。

(2)数据审核功能，提供数据工作流管理功能，支持通过图形拖拽实现业务工作流的定义，来支撑药品、耗材、设备、服务主数据的两级管理审核流程定义。提供数据审核提醒功能，提醒数据审核角色人员及时登录系统进行数据审核操作，审核支持单条和批量数据审核，并且支持审核意见的录入功能。

(3)数据发布功能，当数据流转完所有工作流定义的审核节点后，正式发布。发布时有系统自动赋予编码。

(4)数据变更维护，当存在认为描述不准确或有需要调整的内容时，则通过选择需要变更维护的数据，进行单条或批量的数据变更维护操作；同样数据变更维护依然会进行数据填写模板符合性的校验，只有通过校验的数据才可保存；保存后同样需要进行数据变更的审核之后进行数据重新发布；提供数据版本的控制，来记录所有被变化调整的数据的变化内容和数据版本记录，便于数据的管理和审查。

(5)数据查询功能，支持通过模糊查询的方式来进行药品、耗材、设备、服务数据的查看，尤其是在数据申请前，应该先查询数据是否存在再进行添加。支持对用户进行查询权限控制，控制不同用户可查询的数据范围、数据信息内容和可导出的数据内容，提供数据安全控制。

3、药品、耗材、设备、服务主数据集成管理

药品、耗材、设备、服务主数据通过统一的主数据管理系统进行数据的创建、审核、发布，形成标准的数据代码池。主数据管理系统可通过提供数据服务接口的方式为集团供应链管理系统和二级医院机构的自用系统提供所需的药品、耗材、设备、服务数据。

(1)数据接口定义，当某一系统需要从主数据管理系统获取或提供数据时，需要与主数据管理系统进行接口对接，来实现自动化的数据传递，改变现在的数据分别录入维护现状，减少人工介入。主数据管理系统内嵌主流数据总线功能，支持通过配置化的方式进行数据对外服务接口的定义。通过配置化的方式可实现接口类型定义(数据接口、数据分发)、数据集成内容定义(集成的数据类型、集成的数据信息项)、数据集成频次(及时分发、定时分发，可定义数据分发的频次，最小计量到秒)、数据失败处理机制(数据集成失败提醒方式、失败后是否系统自动重发、重发次数)。

(2)数据接口日志管理，提供数据集成日志记录功能，对所有数据集成接口进行数据接收和分发日志记录，记录是否接收或分发成功，尤其是失败的数据，记录数据失败的原因。确保准确掌握与各需用系统的数据服务情况。

(3)数据集成技术规范生成，为了确保各对接系统方能够快速进行系统集成，主数据管理系统支持自动生成系统集成技术规范文档，将此文档提供给对接系统方，可辅导对方快速完成与主数据管理系统的集成。

(4)集成接口维护，支持对所有集成接口进行管理授权，并且支持在线的集成接口调整。

4、数据标准服务平台

主数据管理系统除了支持实现集团核心数据的标准化管理和提供数据服务外，还提供全集团的数据标准管理和标准查询和对外服务。

(1)支持进行集团所有标准和国家、行业内各类数据标准的系统内录入和展现，提供数据服务展现门户，便于全集团查看所需的数据权威标准。

(2)支持提供数据标准服务，支持通过数据导出或提供数据标准服务接口，实现手工或系统化的数据标准服务功能，实现数据标准对全集团的服务支持。

5、数据安全

数据资产是集团重要的资产类型之一，再提供数据管理的同时还要注重数据的安全性，避免外泄。主数据管理系统应具有完备的数据安全管理控制。

(1)权限控制，支持对本系统内管理的所有数据和标准提供查看、操作的权限控制，通过数据授权的方式进行数据管理，管理颗粒度精确到最小元数据级别。

(2)日志监控，支持对本系统内所有用户和接口端的操作进行全日志记录，记录所有的操作IP、操作人员、操作动作、操作内容，便于数据监控。

(3)账户控制，对所有系统账户进行密码复杂度、密码有效期和权限的管理。

(4)加密控制，本系统提供数据加密、数据脱敏、数据水印等数据加密功能，同时在数据库、集成接口、页面操作进行加密处理，避免数据外泄。

鉴于集团两级管理的模式，集团总部层面存在统一管理的数据内容，但由于各二级医院机构存在自身医院机构规模、自身管理特点的内容，所以由存在差异性。主数据管理系统需要保障集团总部对全集团管控统一性的基础上还要满足二级医院机构差异化内容的管理。因此主数据管理系统从设计上就考虑本特性，在数据模型定义和数据操作上提供了统一数据视图和各医院机构个性化视图的管理功能。实现了1+N的数据管理方式，即对每一家医疗机构是由集团统一的数据视图，即为“1”，和各医院自身的个性化视图构成，即为“N”，最终实现了集团统一和各二级医院机构差异化的数据管理和数据支持。

这种“1+N”的功能支持覆盖本系统数据模型管理、数据填报管理、数据集成、数据安全所有功能模块。

下面参考图14，其示出了适于用来实现本发明实施例的电子设备的计算机系统1400的结构示意图。图14示出的电子设备的计算机系统1400仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图14所示，计算机系统1400包括中央处理单元(CPU)1401，其可以根据存储在只读存储器(ROM)1402中的程序或者从存储部分1408加载到随机访问存储器(RAM)1403中的程序而执行各种适当的动作和处理。在RAM 1403中，还存储有系统操作所需的各种程序和数据。CPU 1401、ROM 1402以及RAM 1403通过总线1404彼此相连。输入/输出(I/O)接口1405也连接至总线1404。

以下部件连接至I/O接口1405：包括键盘、鼠标等的输入部分1406；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1407；包括硬盘等的存储部分1408；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1409。通信部分1409经由诸如因特网的网络执行通信处理。驱动器1410也根据需要连接至I/O接口1405。可拆卸介质1411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1410上，以便于从其上读出的计算机程序根据需要被安装入存储部分1408。

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

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如上述实施例中所述的

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

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

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (7)

1.一种业务数据的集成管理方法，其特征在于，所述方法包括：

确定一级业务主体以及与所述一级业务主体具有关联关系的多个二级业务主体，所述二级业务主体包括具有关联关系的业务申请主体和业务初审主体；

获取由所述业务申请主体提交的业务数据集成申请，并将所述业务数据集成申请发送至与所述业务申请主体相关联的业务初审主体，以得到由所述业务初审主体返回的业务初审结果；

当所述业务初审结果为审核通过时，将所述业务数据集成申请以及所述业务初审结果发送至所述一级业务主体，以得到由所述一级业务主体返回的业务终审结果；

当所述业务终审结果为审核通过时，根据所述业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志；

所述将所述业务数据集成申请发送至与所述业务申请主体相关联的业务初审主体，包括：

获取与所述业务申请主体相关联的业务初审主体的审核权限；

根据所述审核权限将所述业务数据集成申请中携带的申请数据划分为初审数据和终审数据；

对所述终审数据做加密处理后，将所述业务数据集成申请发送至所述业务初审主体；

在初步审核通过的情况下，对终审数据进行解密处理，将解密处理后的初步审核后的业务数据集成申请发送至一级业务主体；

所述根据所述业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志，包括：

根据所述业务数据集成申请确定业务数据集成管理目录的目录更新信息，并将所述目录更新信息保存至目录区块链；

根据所述业务数据集成申请确定业务数据集成管理日志的日志更新信息，并将所述日志更新信息保存至日志区块链；

所述将所述目录更新信息保存至目录区块链，包括：

将所述目录更新信息保存在待共识的当前目录区块的区块主体中；

在满足区块生成条件时，获取目录区块链中上一目录区块的区块头数据，并根据所述区块头数据计算得到当前目录区块的父区块哈希值；

根据所述当前目录区块的区块主体中保存的数据计算所述当前目录区块的区块主体哈希值；

将所述父区块哈希值、所述区块主体哈希值以及当前时间的时间戳保存在所述当前目录区块的区块头中；

将所述当前目录区块广播至区块链网络以对所述当前目录区块进行共识认证，并在认证通过时将所述当前目录区块链接至所述目录区块链上；

所述根据所述当前目录区块的区块主体中保存的数据计算所述当前目录区块的区块主体哈希值，包括：

将所述目录更新信息保存至默克尔树叶子节点，将每两个相邻的所述叶子节点保存的目录更新信息组合得到所述叶子节点的哈希值；

将所述叶子节点的哈希值逐层运算，得到所述区块主体的哈希值。

2.根据权利要求1所述的业务数据的集成管理方法，其特征在于，所述获取由所述业务申请主体提交的业务数据集成申请，包括：

接收由多个所述业务申请主体发送的申请摘要，并将所述申请摘要保存至摘要处理队列；

依次从所述摘要处理队列中读取申请摘要，并从所述申请摘要中获取所述业务申请主体的主体标识信息和申请类型信息；

根据所述主体标识信息确定申请权限信息，并根据所述申请权限信息和所述申请类型信息判断所述业务申请主体是否具有申请权限；

当判定所述业务申请主体具有申请权限时，根据所述主体标识信息确定与所述业务申请主体相对应的数据接口；

通过所述数据接口获取由所述业务申请主体提交的业务数据集成申请。

3.根据权利要求2所述的业务数据的集成管理方法，其特征在于，所述将所述申请摘要保存至摘要处理队列，包括：

获取与所述申请摘要相对应的优先级信息和时限信息；

根据所述优先级信息和时限信息确定所述申请摘要的排列位置；

基于所述排列位置将所述申请摘要保存至摘要处理队列。

4.根据权利要求1所述的业务数据的集成管理方法，其特征在于，所述将所述日志更新信息保存至日志区块链，包括：

将所述日志更新信息保存在待共识的当前日志区块的区块主体中；

在满足区块生成条件时，获取日志区块链中上一日志区块的区块头数据，并根据所述区块头数据计算得到当前日志区块的父区块哈希值；

根据所述当前日志区块的区块主体中保存的数据计算所述当前日志区块的区块主体哈希值；

将所述父区块哈希值、所述区块主体哈希值以及当前时间的时间戳保存在所述当前日志区块的区块头中；

将所述当前日志区块广播至区块链网络以对所述当前日志区块进行共识认证，并在认证通过时将所述当前日志区块链接至所述日志区块链上。

5.一种业务数据的集成管理装置，其特征在于，所述装置包括：

主体确定模块，被配置为确定一级业务主体以及与所述一级业务主体具有关联关系的多个二级业务主体，所述二级业务主体包括具有关联关系的业务申请主体和业务初审主体；

业务初审模块，被配置为获取由所述业务申请主体提交的业务数据集成申请，并将所述业务数据集成申请发送至与所述业务申请主体相关联的业务初审主体，以得到由所述业务初审主体返回的业务初审结果；

业务终审模块，被配置为当所述业务初审结果为审核通过时，将所述业务数据集成申请以及所述业务初审结果发送至所述一级业务主体，以得到由所述一级业务主体返回的业务终审结果；

数据更新模块，被配置为当所述业务终审结果为审核通过时，根据所述业务数据集成申请更新业务数据集成管理目录和业务数据集成管理日志；

所述业务初审模块包括：

权限获取模块，被配置为获取与所述业务申请主体相关联的业务初审主体的审核权限；

数据划分模块，被配置为根据所述审核权限将所述业务数据集成申请中携带的申请数据划分为初审数据和终审数据

数据加密模块，被配置为对所述终审数据做加密处理后，将所述业务数据集成申请发送至所述业务初审主体；

数据解密模块，被配置为在初步审核通过的情况下，对终审数据进行解密处理，将解密处理后的初步审核后的业务数据集成申请发送至一级业务主体

所述数据更新模块，包括：

第一保存单元，用于根据所述业务数据集成申请确定业务数据集成管理目录的目录更新信息，并将所述目录更新信息保存至目录区块链；

第二保存单元，用于根据所述业务数据集成申请确定业务数据集成管理日志的日志更新信息，并将所述日志更新信息保存至日志区块链；

所述第一保存单元，包括：

保存子单元，用于将所述目录更新信息保存在待共识的当前目录区块的区块主体中；

获取子单元，用于在满足区块生成条件时，获取目录区块链中上一目录区块的区块头数据，并根据所述区块头数据计算得到当前目录区块的父区块哈希值；

计算子单元，用于根据所述当前目录区块的区块主体中保存的数据计算所述当前目录区块的区块主体哈希值；

保存子单元，用于将所述父区块哈希值、所述区块主体哈希值以及当前时间的时间戳保存在所述当前目录区块的区块头中；

链接子单元，用于将所述当前目录区块广播至区块链网络以对所述当前目录区块进行共识认证，并在认证通过时将所述当前目录区块链接至所述目录区块链上；

所述计算子单元，包括：

组合元件，用于将所述目录更新信息保存至默克尔树叶子节点，将每两个相邻的所述叶子节点保存的目录更新信息组合得到所述叶子节点的哈希值；

运算元件，用于将所述叶子节点的哈希值逐层运算，得到所述区块主体的哈希值。

6.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1至4中任一项所述的业务数据的集成管理方法。

7.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至4中任一项所述的业务数据的集成管理方法。