一种医疗机构的筛选系统及筛选方法

摘要

本申请提供了一种医疗机构的筛选系统及筛选方法，应用于医疗数据分析技术领域，所述医疗机构的筛选系统包括云端平台、至少一个探查条件计算装置以及至少一个数据处理装置；通过云端平台发送探查请求，在保证数据安全的情况下，获取到不同的待检测医疗机构的经过数据处理装置进行实体抽取后的医疗数据，同时探查条件计算装置能够高效地计算出各个待检测医疗机构与探查用户的探查条件的测评情况反馈给云端平台，云端平台筛选出符合探查请求的目标医疗机构，这样，有助于提升筛选出符合探查条件的医疗机构的准确率以及效率。

权利要求

1.一种医疗机构的筛选系统，其特征在于，所述筛选系统包括云端平台、至少一个探查条件计算装置以及至少一个数据处理装置；

所述云端平台，用于根据探查用户输入的至少一条探查条件，加密生成探查请求，并将所述探查请求发送至各个探查条件计算装置；接收各个探查条件计算装置发送各个待测评医疗机构的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构；

所述探查条件计算装置，用于在接收所述云端平台发送的探查请求后，向所述数据处理装置发送数据获取请求，接收所述数据处理装置反馈的至少一条目标医疗数据；根据解析后的探查请求中的至少一条加密探查条件比对关联的数据处理装置中的多条目标医疗数据，根据多条目标医疗数据与所述至少一条加密探查条件的匹配结果，确定关联的待测评医疗机构的探查条件测评结果，并将所述探查条件测评结果返回至所述云端平台；

所述数据处理装置，用于连接对应的待测评医疗机构的数据库，将连接的待测评医疗机构的数据库中的临床医疗数据基于预先训练好的医学概念及关系模型进行关键词抽取处理后，确定出至少一个待处理实体，并根据将所述至少一个待处理实体标准化后得到的多个医学实体，得到至少一条目标医疗数据；并在接收到所述探查条件计算装置的数据获取请求时，将所述至少一条目标医疗数据发送至所述探查条件计算装置；其中，每一条目标医疗数据中包括多个医学实体以及各个医学实体之间的关联关系。

2.根据权利要求1所述的筛选系统，其特征在于，所述数据处理装置包括实体抽取模块、实体标准化模块以及目标数据生成模块；

实体抽取模块，用于针对于所述待测评医疗机构中的每一条临床医疗数据，基于预先训练好的医学概念及关系模型，从该条临床医疗数据中抽取出至少一个待处理实体，并确定各个待处理实体之间的关联关系；并将所述至少一个待处理实体发送至所述实体标准化模块，同时将各个待处理实体之间的关联关系发送至所述目标数据生成模块；

实体标准化模块，用于基于预先制定的医学概念标准，对各个待处理实体进行标准化，确定出多个医学实体；并将所述多个医学实体发送至所述目标数据生成模块；

目标数据生成模块，用于将接收到的具有关联关系的两两医学实体进行关联加密后，生成至少一条目标医疗数据。

3.根据权利要求1所述的筛选系统，其特征在于，所述探查条件计算装置还用于：

在接收到的探查请求后，将所述加密探查条件利用与所述云端平台约定好的第一密钥进行解密，得到与所述探查请求对应的至少一条探查条件。

4.根据权利要求2所述的筛选系统，其特征在于，所述探查条件计算装置还用于：

针对于接收到的每一条目标医疗数据，利用与所述数据处理装置约定好的第二密钥，对该条目标医疗数据进行解密，确定出该条目标医疗数据中的数据主键以及数据值。

5.根据权利要求4所述的筛选系统，其特征在于，所述探查条件中包括探查目标以及探查阈值条件；所述探查条件计算装置还用于：根据所述探查目标，从所述至少一条目标医疗数据中，筛选出数据主键与所述探查目标一致的候选医疗数据；

针对于每一条候选医疗数据，若该条候选医疗数据中的数据值满足对应的探查阈值条件，确定该条候选医疗数据所属的待测评医疗机构命中一条探查条件。

6.根据权利要求1所述的筛选系统，其特征在于，所述云端平台用于通过以下步骤确定符合探查用户的探查需求的目标医疗机构：基于各个探查条件计算装置发送的探查条件测评结果，筛选出排序位于预设位置之前的多个符合探查用户的探查需求的目标医疗机构。

7.根据权利要求6所述的筛选系统，其特征在于，所述探查条件测评结果包括各个待测评医疗机构是否命中探查条件以及命中探查条件的数量；所述云端平台还用于：基于各个探查条件计算装置发送的探查条件测评结果，对各个待测评医疗机构按照命中探查条件的数量由高到低的顺序排序。

8.根据权利要求7所述的筛选系统，其特征在于，所述云端平台还用于：

若存在命中探查条件的数量一致的至少两个待测评医疗机构，则按照预先设定的探查条件的优先级，将至少两个待测评医疗机构按照命中探查条件的优先级由高到低的顺序排序。

9.根据权利要求1所述的筛选系统，其特征在于，所述云端平台还用于：

在接收到探查用户的登录请求时，根据所述探查用户的登录标识，检测在合作用户数据库中是否存在所述探查用户；

若在合作用户数据库中存在所述探查用户，检测所述探查用户输入的第一登录密码以及第二登录密码是否均正确；

若所述探查用户输入的第一登录密码以及第二登录密码均正确，接收所述探查用户的输入。

10.一种医疗机构的筛选方法，其特征在于，所述筛选方法应用于如权利要求1‑9中任一项所述的医疗机构的筛选系统，所述筛选方法包括：控制所述云端平台根据探查用户输入的至少一条探查条件，加密生成探查请求，并将所述探查请求发送至各个探查条件计算装置；接收各个探查条件计算装置发送各个待测评医疗机构的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构；

控制所述探查条件计算装置在接收所述云端平台发送的探查请求后，向所述数据处理装置发送数据获取请求，接收所述数据处理装置反馈的至少一条目标医疗数据；根据解析后的探查请求中的至少一条加密探查条件比对关联的数据处理装置中的多条目标医疗数据，根据多条目标医疗数据与所述至少一条加密探查条件的匹配结果，确定关联的待测评医疗机构的探查条件测评结果，并将所述探查条件测评结果返回至所述云端平台；

控制所述数据处理装置连接对应的待测评医疗机构的数据库，将连接的待测评医疗机构的数据库中的临床医疗数据进行关键词抽取处理，得到至少一条目标医疗数据；并在接收到所述探查条件计算装置的数据获取请求时，将所述至少一条目标医疗数据发送至所述探查条件计算装置；其中，每一条目标医疗数据中包括多个医学实体以及各个医学实体之间的关联关系。

说明书

一种医疗机构的筛选系统及筛选方法

技术领域

[0001] 本申请涉及医疗数据分析技术领域，尤其是涉及一种医疗机构的筛选系统及筛选方法。

背景技术

[0002] 当药企生产新药后，需要尽快地确定出合作医院以及参加临床试验的患者，为了满足药企的需求，衍生出了临床试验的过程，临床试验通过临床数据去挖掘探查医院临床试验的潜力，是医学领域非常重要的一块业务；但是，出于对病例等患者数据的安全性的考虑，具有探查需求的药企来说，无法获取到各个医疗机构的患者数据，即使是通过认证后，可以获取到医疗机构的临床数据后，由于临床数据量大、书写格式不规范（很多关键信息出现在医生手写的电子病历中）等一系列问题，还是无法高效准确地确定出符合药企需求的医疗机构，如何高效准确地筛选出符合药企需求的医疗机构成为亟待解决的问题。

发明内容

[0003] 有鉴于此，本申请的目的在于提供一种医疗机构的筛选系统及筛选方法，通过云端平台发送探查请求，在保证数据安全的情况下，获取到不同的待检测医疗机构的经过数据处理装置进行实体抽取后的医疗数据，同时探查条件计算装置能够高效地计算出各个待检测医疗机构与探查用户的探查条件的测评情况反馈给云端平台，云端平台筛选出符合探查请求的目标医疗机构，有助于提升筛选出符合探查条件的医疗机构的准确率以及效率。

[0004] 第一方面，本申请实施例提供了一种医疗机构的筛选系统，所述筛选系统包括云端平台、至少一个探查条件计算装置以及至少一个数据处理装置；

[0005] 所述云端平台，用于根据探查用户输入的至少一条探查条件，加密生成探查请求，并将所述探查请求发送至各个探查条件计算装置；接收各个探查条件计算装置发送各个待测评医疗机构的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构；

[0006] 所述探查条件计算装置，用于在接收所述云端平台发送的探查请求后，向所述数据处理装置发送数据获取请求，接收所述数据处理装置反馈的至少一条目标医疗数据；根据解析后的探查请求中的至少一条加密探查条件比对关联的数据处理装置中的多条目标医疗数据，根据多条目标医疗数据与所述至少一条加密探查条件的匹配结果，确定关联的待测评医疗机构的探查条件测评结果，并将所述探查条件测评结果返回至所述云端平台；

[0007] 所述数据处理装置，用于连接对应的待测评医疗机构的数据库，将连接的待测评医疗机构的数据库中的临床医疗数据进行关键词抽取处理，得到至少一条目标医疗数据；并在接收到所述探查条件计算装置的数据获取请求时，将所述至少一条目标医疗数据发送至所述探查条件计算装置；其中，每一条目标医疗数据中包括多个医学实体以及各个医学实体之间的关联关系。

[0008] 在一种可能的实施方式中，所述数据处理装置包括实体抽取模块、实体标准化模块以及目标数据生成模块；

[0009] 实体抽取模块，用于针对于所述待测评医疗机构中的每一条临床医疗数据，基于预先训练好的医学概念及关系模型，从该条临床医疗数据中抽取出至少一个待处理实体，并确定各个待处理实体之间的关联关系；并将所述至少一个待处理实体发送至所述实体标准化模块，同时将各个待处理实体之间的关联关系发送至所述目标数据生成模块；

[0010] 实体标准化模块，用于基于预先制定的医学概念标准，对各个待处理实体进行标准化，确定出多个医学实体；并将所述多个医学实体发送至所述目标数据生成模块；

[0011] 目标数据生成模块，用于将接收到的具有关联关系的每两个医学实体进行关联加密后，生成至少一条目标医疗数据。

[0012] 在一种可能的实施方式中，所述探查条件计算装置还用于：

[0013] 在接收到的探查请求后，将所述加密探查条件利用与所述云端平台约定好的第一密钥进行解密，得到与所述探查请求对应的至少一条探查条件。

[0014] 在一种可能的实施方式中，所述探查条件计算装置还用于：

[0015] 针对于接收到的每一条目标医疗数据，利用与所述数据处理装置约定好的第二密钥，对该条目标医疗数据进行解密，确定出该条目标医疗数据中的数据主键以及数据值。

[0016] 在一种可能的实施方式中，所述探查条件中包括探查目标以及探查阈值条件；所述探查条件计算装置还用于：

[0017] 根据所述探查目标，从所述至少一条目标医疗数据中，筛选出数据主键与所述探查目标一致的候选医疗数据；

[0018] 针对于每一条候选医疗数据，若该条候选医疗数据中的数据值满足对应的探查阈值条件，确定该条候选医疗数据所属的待测评医疗机构命中一条探查条件。

[0019] 在一种可能的实施方式中，所述云端平台用于通过以下步骤确定符合探查用户的探查需求的目标医疗机构：

[0020] 基于各个探查条件计算装置发送的探查条件测评结果，筛选出排序位于预设位置之前的多个符合探查用户的探查需求的目标医疗机构。

[0021] 在一种可能的实施方式中，所述探查条件测评结果包括各个待测评医疗机构是否命中探查条件以及命中探查条件的数量；所述云端平台还用于：

[0022] 基于各个探查条件计算装置发送的探查条件测评结果，对各个待测评医疗机构按照命中探查条件的数量由高到低的顺序排序。

[0023] 在一种可能的实施方式中，所述云端平台还用于：

[0024] 若存在命中探查条件的数量一致的至少两个待测评医疗机构，则按照预先设定的探查条件的优先级，将至少两个待测评医疗机构按照命中探查条件的优先级由高到低的顺序排序。

[0025] 在一种可能的实施方式中，所述云端平台还用于：

[0026] 在接收到探查用户的登录请求时，根据所述探查用户的登录标识，检测在合作用户数据库中是否存在所述探查用户；

[0027] 若在合作用户数据库中存在所述探查用户，检测所述探查用户输入的第一登录密码以及第二登录密码是否均正确；

[0028] 若所述探查用户输入的第一登录密码以及第二登录密码均正确，接收所述探查用户的输入。

[0029] 第二方面，本申请实施例还提供了医疗机构的筛选方法，所述筛选方法应用于上述医疗机构的筛选系统，所述筛选方法包括：

[0030] 控制所述云端平台根据探查用户输入的至少一条探查条件，加密生成探查请求，并将所述探查请求发送至各个探查条件计算装置；接收各个探查条件计算装置发送各个待测评医疗机构的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构；

[0031] 控制所述探查条件计算装置在接收所述云端平台发送的探查请求后，向所述数据处理装置发送数据获取请求，接收所述数据处理装置反馈的至少一条目标医疗数据；根据解析后的探查请求中的至少一条加密探查条件比对关联的数据处理装置中的多条目标医疗数据，根据多条目标医疗数据与所述至少一条加密探查条件的匹配结果，确定关联的待测评医疗机构的探查条件测评结果，并将所述探查条件测评结果返回至所述云端平台；

[0032] 控制所述数据处理装置连接对应的待测评医疗机构的数据库，将连接的待测评医疗机构的数据库中的临床医疗数据进行关键词抽取处理，得到至少一条目标医疗数据；并在接收到所述探查条件计算装置的数据获取请求时，将所述至少一条目标医疗数据发送至所述探查条件计算装置；其中，每一条目标医疗数据中包括多个医学实体以及各个医学实体之间的关联关系。

[0033] 第三方面，本申请实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如上述的医疗机构的筛选方法的步骤。

[0034] 第四方面，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如上述的医疗机构的筛选控制方法的步骤。

[0035] 本申请实施例提供的一种医疗机构的筛选系统及筛选方法，当探查用户在有探查需求时，可以通过登录云端平台输入多个探查条件，云端平台在接收到探查用户输入的多个探查条件进行加密后，生成探查请求，将分别探查请求发送给探查条件计算装置，探查条件计算装置在接收到云端平台发送的探查请求后，生成数据获取请求向数据处理装置获取至少一条目标医疗数据，数据处理装置在接收到探查条件计算装置发送的数据获取请求后，将存储的已经经过处理后的至少一条目标医疗数据发送至探查条件计算装置，探查条件计算装置根据目标医疗数据后，根据解析后的探查条件与接收到的目标医疗数据进行匹配，确定关联的待测评医疗机构的探查条件测评结果返回至云端平台，云端平台根据各个探查条件计算装置发送的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构。在本申请实施例中，通过云端平台发送探查请求，在保证数据安全的情况下，获取到不同的待检测医疗机构的经过数据处理装置进行实体抽取后的医疗数据，同时探查条件计算装置能够高效地计算出各个待检测医疗机构与探查用户的探查条件的测评情况反馈给
云端平台，云端平台筛选出符合探查请求的目标医疗机构，有助于提升筛选出符合探查条件的医疗机构的准确率以及效率。

[0036] 为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

[0038] 图1为本申请实施例所提供的一种医疗机构的筛选系统的结构示意图之一；

[0039] 图2为本申请实施例所提供的数据处理装置的结构示意图；

[0040] 图3为本申请实施例所提供的一种医疗机构的筛选系统的结构示意图之二；

[0041] 图4为本申请实施例所提供的一种医疗机构的筛选方法的流程图；

[0042] 图5为本申请实施例所提供的一种电子设备的结构示意图。

[0043] 图标：100‑筛选系统；110‑云端平台；120‑探查条件计算装置；130‑数据处理装置；131‑实体抽取模块；132‑实体标准化模块；133‑目标数据生成模块；140‑医疗机构数据库；
500‑电子设备；510‑处理器；520‑存储器；530‑总线。

具体实施方式

[0044] 为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的每个其他实施例，都属于本申请保护的范围。

[0045] 首先，对本申请可适用的应用场景进行介绍。本申请可应用于医疗数据分析技术领域。

[0046] 经研究发现，当药企生产新药后，需要尽快地确定出合作医院以及参加临床试验的患者，为了满足药企的需求，衍生出了临床试验的过程，临床试验通过临床数据去挖掘探查医院临床试验的潜力，是医学领域非常重要的一块业务；但是，出于对病例等患者数据的安全性的考虑，具有探查需求的药企来说，无法获取到各个医疗机构的患者数据，即使是通过认证后，可以获取到医疗机构的临床数据后，由于临床数据量大、书写格式不规范（很多关键信息出现在医生手写的电子病历中）等一系列问题，还是无法高效准确地确定出符合药企需求的医疗机构，如何高效准确地筛选出符合药企需求的医疗机构成为亟待解决的问题。

[0047] 基于此，本申请实施例提供了一种医疗机构的筛选系统，以提升筛选出符合探查条件的医疗机构的准确率以及效率。

[0048] 在一种可能的实施方式中，对本申请公开的一种医疗机构的筛选系统100进行介绍。

[0049] 请参阅图1，图1为本申请实施例所提供的一种医疗机构的筛选系统100的结构示意图之一，本申请实施例提供了一种医疗机构的筛选系统100，筛选系统100包括云端平台
110、至少一个探查条件计算装置120以及至少一个数据处理装置130；其中，云端平台110作为整个系统的总控制平台，当探查用户在有探查需求时，可以通过登录云端平台110输入多个探查条件，云端平台110在接收到探查用户输入的多个探查条件进行加密后，生成探查请求，将分别探查请求发送给探查条件计算装置120，探查条件计算装置120在接收到云端平台110发送的探查请求后，生成数据获取请求向数据处理装置130获取至少一条目标医疗数据，数据处理装置130在接收到探查条件计算装置120发送的数据获取请求后，将存储的已经经过处理后的至少一条目标医疗数据发送至探查条件计算装置120，探查条件计算装置
120根据目标医疗数据后，根据解析后的探查条件与接收到的目标医疗数据进行匹配，确定关联的待测评医疗机构的探查条件测评结果返回至云端平台110，云端平台110根据各个探查条件计算装置发送的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构。

[0050] 具体地，所述云端平台110，用于根据探查用户输入的至少一条探查条件，加密生成探查请求，并将所述探查请求发送至各个探查条件计算装置；接收各个探查条件计算装置发送各个待测评医疗机构的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构。

[0051] 在本申请实施例中，用户指的是有药物测评需求的用户，当用户需要测试某些药物在各个医疗机构可能被使用的情况时，可能需要从不同医疗机构中选择合适的进行临床试验的医疗机构，这时用户可以登录到云端平台110中输入自己的探查条件，值得注意的是，为了保证医疗机构的数据的安全性，可以的登录到云端平台110均是在云端平台110认证过的符合条件的用户，并且在用户登录过程中通过双重密码对用户的身份进行认证。

[0052] 在一种可能的实施例中，所述云端平台110还用于：

[0053] 在接收到探查用户的登录请求时，根据所述探查用户的登录标识，检测在合作用户数据库中是否存在所述探查用户；

[0054] 若在合作用户数据库中存在所述探查用户，检测所述探查用户输入的第一登录密码以及第二登录密码是否均正确；

[0055] 若所述探查用户输入的第一登录密码以及第二登录密码均正确，接收所述探查用户的输入。

[0056] 在本申请实施例中，探查用户的登录标识是可以表征用户身份的唯一标识，可以是用户的名称、注册时的昵称注册时的账号号码（如手机号）等，在用户注册时，云端平台110的合作用户数据库中会记录用户的唯一标识、密码信息以及用户的基本信息等，在接收到探查用户的登录标识后，需要根据登录标识到合作用户数据库中进行查找，若是在合作用户数据库中查找到与探查用户的用户标识一致的存储标识，确定该探查用户是已经注册过的用户，可以登录云端平台110。若是在合作用户数据库中并未查找到与探查用户的用户标识一致的存储标识，可以返回登录失败的信息，并提示探查用户可以在云端平台110上完成注册后再登录。

[0057] 在一种可能的实施方式中，在确定探查用户可以登录云端平台110时，需要对探查用户进行登录密码认证，在本申请实施例中，第一密码与第二密码可以是不同性质的密码，第一密码是静态密码是在用户注册时设置的密码，为了防止用户密码泄露导致的安全问题，第二密码设置为动态密码，在探查用户登录云端平台时，可以是通过用户注册时的手机号、邮箱号等向探查用户发送一个动态密码，在规定时间内接收探查用户输入的第一密码以及第二密码，只有探查用户输入的第一密码以及第二密码均正确时，才确定探查用户的登录验证通过，可以登录到云端平台110。

[0058] 在一种可能的实施方式中，云端平台110在接收到探查用户输入的多条探查条件后，为了保证探查过程的安全性，需要将探查用户输入的探查条件进行加密后生成探查请求在发送给各个探查条件计算装置120。

[0059] 在一种可能的实施方式中，云端平台110针对于探查条件的加密方式可以是对称性加密也可以是非对称性加密，密钥在云端平台110以及各个探查条件计算装置120处是公开的。

[0060] 在本申请实施例中，云端平台110在接收到各个探查条件计算装置120发送的各个待测评医疗机构的探查条件测评结果后，需要根据各个待测评医疗机构的探查条件测评结果进行排序后，确定出符合探查条件的目标医疗机构。

[0061] 具体地，所述云端平台110用于通过以下步骤确定符合探查用户的探查需求的目标医疗机构：

[0062] 基于各个探查条件计算装置120发送的探查条件测评结果，筛选出排序位于预设位置之前的多个符合探查用户的探查需求的目标医疗机构。

[0063] 在本申请实施例中，预设位置表征了需要筛选出的目标医疗机构的数量，这个数量可以是探查用户根据探查需求进行确定的。

[0064] 举例来说，探查用户在输入探查条件的同时，还可以规定出此次需要确定出的目标医疗机构的数量，若是探查用户指出此次需要确定出3个目标医疗机构，那么云端平台110在将各个待测评医疗机构进行排序后，需要将排序位置在前3位的待测评医疗机构确定为目标医疗机构。

[0065] 在一种可能的实施方式中，所述探查条件测评结果包括各个待测评医疗机构是否命中探查条件以及命中探查条件的数量，在此基础上，所述云端平台110还用于：

[0066] 基于各个探查条件计算装置发送的探查条件测评结果，对各个待测评医疗机构按照命中探查条件的数量由高到低的顺序排序。

[0067] 在本申请实施例中，可以是根据不同待测评医疗机构命中的探查条件的数量由高到低的顺序将各个待测评医疗机构进行排序。

[0068] 举例来说，解析各个探查条件测评结果可知，待测评医疗机构A命中探查用户的探查条件的数量为5个；待测评医疗机构B命中探查用户的探查条件的数量为7个；待测评医疗机构C命中探查用户的探查条件的数量为1个，那么待测评医疗机构的排序就可以是待测评医疗机构B、待测评医疗机构A、待测评医疗机构C。

[0069] 在一种可能的实施方式中，可以通过评分来记录待测评医疗机构命中探查用户的探查条件的数量，例如，可以是命中一条探查条件，就加1分。

[0070] 在本申请实施例中，若是在按照命中探查条件的数量对待测评医疗机构进行排序时，存在命中探查条件的数量时，需要在附加排序条件。

[0071] 在一种可能的实施方式中，所述云端平台110还用于：

[0072] 若存在命中探查条件的数量一致的至少两个待测评医疗机构，则按照预先设定的探查条件的优先级，将至少两个待测评医疗机构按照命中探查条件的优先级由高到低的顺序排序。

[0073] 具体地，探查用户在云端平台110设置探查条件时，可以设置不同探查条件的优先级，这个优先级可以表征探查用户在探查过程中比较关注的条件。

[0074] 这里，若是存在命中探查条件的数量一致的至少两个待测评医疗机构时，可以再根据不同待测评医疗机构命中的不同探查条件的优先级再次对至少两个待测评医疗机构按照命中的探查条件由高到低的顺序再次进行排序。

[0075] 举例来说，解析各个探查条件测评结果可知，待测评医疗机构X命中探查用户的探查条件的数量为1个；待测评医疗机构W命中探查用户的探查条件的数量也为1个；但是待测评医疗机构W命中的探查条件的优先级是高于待测评医疗机构X命中的优先级的，因此，在对待测评医疗机构进行排序时，待测评医疗机构W的排序是在待测评医疗机构X之前的。

[0076] 在另一种可能的实施方式中，还可以是根据不同待测评医疗机构命中每条探查条件的数据的数量来进行排序，具体地：

[0077] 若存在命中探查条件的数量一致的至少两个待测评医疗机构，则按照各个待测评医疗机构命中探查条件的数据的数量，将至少两个待测评医疗机构按照命中探查条件的数据的数量由高到低的顺序排序。

[0078] 针对于上述示例，解析各个探查条件测评结果可知，待测评医疗机构X命中探查用户的探查条件的数量为1个；待测评医疗机构W命中探查用户的探查条件的数量也为1个；但是待测评医疗机构W命中的探查条件的数量为10，而待测评医疗机构X命中探查条件的数量为5，因此，在对待测评医疗机构进行排序时，待测评医疗机构W的排序是在待测评医疗机构X之前的。

[0079] 所述探查条件计算装置120，用于在接收所述云端平台110发送的探查请求后，向所述数据处理装置130发送数据获取请求，接收所述数据处理装置反馈的至少一条目标医疗数据；根据解析后的探查请求中的至少一条加密探查条件比对关联的数据处理装置130中的多条目标医疗数据，根据多条目标医疗数据与所述至少一条加密探查条件的匹配结果，确定关联的待测评医疗机构的探查条件测评结果，并将所述探查条件测评结果返回至所述云端平台110。

[0080] 在本申请实施例中，为了保证探查用户的探查条件的安全性以及数据处理装置130中的医疗数据的安全性，在探查条件以及医疗数据在不同装置之间流转时，需要将探查条件以及医疗数据进行加密，因此，探查条件计算装置120在接收到云端平台110发送的探查请求以及数据处理装置130发送的目标医疗数据，均需要进行解密后然后再进行后续的处理过程。

[0081] 具体地，所述探查条件计算装置120还用于：

[0082] 在接收到的探查请求后，将所述加密探查条件利用与所述云端平台约定好的第一密钥进行解密，得到与所述探查请求对应的至少一条探查条件。

[0083] 在本申请实施例中，在接收到云端平台110发送的探查请求后，需要利用与云端平台110约定的第一密钥进行解密，从探查请求中解析出探查用户的至少一条探查条件。

[0084] 所述探查条件计算装置120还用于：

[0085] 针对于接收到的每一条目标医疗数据，利用与所述数据处理装置约定好的第二密钥，对该条目标医疗数据进行解密，确定出该条目标医疗数据中的数据主键以及数据值。

[0086] 在本申请实施例中，探查条件计算装置120与数据处理装置130是一一对应的，因此，不同探查条件计算装置120与数据处理装置130之间的第二密钥可以是相同的，也可以是不同的，可以是根据需求进行的设置，在此不做具体限定。

[0087] 在一种可能的实施方式中，由于数据处理装置130中的医疗数据均是经过蒸馏过的仅包含主键以及关联关系的数据，因此，探查条件计算装置120在解析完各条目标医疗数据后，还需要从各条目标医疗数据中确定出数据主键以及数据值，以便后续探查条件计算装置120根据目标医疗数据中的数据主键以及数据值与多条探查条件进行匹配，确定探查条件的命中结果。

[0088] 在本申请实施例中，针对于每一条探查条件来说，该探查条件表征了探查用户的探查需求，因为探查用户进行探查的目的在于，确定出各个待检测医疗机构中的患者的数据是否满足自己的试验需求，因此，在探查条件中包括了探查目标（条件主键）以及探查阈值条件（条件值），还可以包括条件类型等。

[0089] 具体地，所述探查条件计算装置120还用于：

[0090] 根据所述探查目标，从所述至少一条目标医疗数据中，筛选出数据主键与所述探查目标一致的候选医疗数据；

[0091] 针对于每一条候选医疗数据，若该条候选医疗数据中的数据值满足对应的探查阈值条件，确定该条候选医疗数据所属的待测评医疗机构命中一条探查条件。

[0092] 在本申请实施例中，针对于每一条探查条件，根据该探查条件中的探查目标，从探查条件计算装置120接收到的至少一条目标医疗数据中，筛选出数据主键与所述探查目标一致的候选医疗数据；针对于确定出的每一条候选医疗数据，若是确定出该条候选医疗数据中的数据值满足对应的探查阈值条件，那么确定该条目标医疗数据命中了对应的探查条件。

[0093] 值得注意的是，在确定待测评医疗机构命中探查条件时，只要该待测评医疗机构中的任一条目标医疗数据命中了探查条件，那么就确定该待测评医疗机构命中了该条探查条件。

[0094] 在本申请实施例中，由于是针对于医疗数据的探查，因此无论是探查条件中的探查目标还是目标医疗数据中的数据主键均是医学领域中的医学实体，包括但不限于：症状、查体、诊断、药品名、检查名称、检验名称、观察对象、手术名称等。

[0095] 在确定命中探查条件时，与探查条件中的探查目标一致的目标医疗数据均可确定为候选医疗数据。

[0096] 针对于整个探查条件命中的过程，下面通过一个示例来进行说明，探查条件计算装置120解析探查请求后，其中一条探查条件Z为“患者的体温高于38℃”，那么探查条件Z的探查目标为“患者体温”、探查阈值条件为“高于38℃”；探查条件计算装置120解析的多条目标医疗数据为：医疗数据1“……患者X体温正常为36.5℃……”，医疗数据2“……患者W连续咳嗽三天……”；医疗数据2“……患者M体温高为38.5℃……”；根据探查目标“患者体温”筛查后，可以得到符合探查目标的医疗数据为医疗数据1以及医疗数据3；再根据探查阈值条件“高于38℃”进行匹配后，确定医疗数据3命中探查条件Z，因此，探查条件计算装置120可以得出结论该待检测医疗机构命中探查条件Z，命中数量为1。

[0097] 在本申请实施例中，同样的，为了保证数据的安全性，探查条件计算装置120在向云端平台110发送探查条件测评结果时也可以将探查条件测评结果加密后再传输至云端平台110。

[0098] 在一种可能的实施方式中，由于不同的待测评医疗机构均会对应一个探查条件计算装置120，因此在各个探查条件计算装置120向云端平台110发送探查条件测评结果时，可以将自身的探查条件计算装置标识同时发送至云端平台110，以使云端平台110可以根据探查条件计算装置标识，识别出探查条件计算装置120关联的待测评医疗机构，进而根据各个待测评医疗机构命中探查条件的情况来对各个待测评医疗机构进行排序以及筛选。

[0099] 在另一种可能的实施方式中，可以同一设置一个探查条件计算装置120来接收不同的数据处理装置130发送的目标医疗数据，那么在探查条件计算装置120根据不同的数据处理装置130计算出对应的探查条件测评结果后，需要将各个数据处理装置130连接的待测评医疗机构的标识也关联在各个探查条件测评结果上，以对各个探查条件测评结果进行区分。

[0100] 所述数据处理装置130，用于连接对应的待测评医疗机构的数据库，将连接的待测评医疗机构的数据库中的临床医疗数据进行关键词抽取处理，得到至少一条目标医疗数据；并在接收到所述探查条件计算装置120的数据获取请求时，将所述至少一条目标医疗数据发送至所述探查条件计算装置120；其中，每一条目标医疗数据中包括多个医学实体以及各个医学实体之间的关联关系。

[0101] 在本申请实施例中，为了减少数据传输量，设置数据处理装置130将各个待测评医疗机构的数据库中的数据进行蒸馏处理，只保留医疗数据中的关键部分（医学实体）以及不同实体之间的关联关系，在数据传输过程中极大地减少了数据传输时间。

[0102] 在本申请实施例中，请参阅图2，图2为本申请实施例所提供的数据处理装置130的结构示意图，如图2所示，数据处理装置130包括实体抽取模块131、实体标准化模块132以及目标数据生成模块133；实体抽取模块131在从连接的待测评医疗机构的数据库中抽取出各个待处理医学实体以及实体关系后，将所述至少一个待处理实体发送至所述实体标准化模块132，同时将各个待处理实体之间的关联关系发送至所述目标数据生成模块133；实体标准化模块132在接收到各个待处理实体后，对各个待处理实体进行标准化处理，得到对应的医学实体后，将各个医学实体也发送至目标数据生成模块133；目标数据生成模块133根据接收到的各个医学实体以及不同实体之间的关联关系，将具有关联关系的每两个医学实体进行关联加密后，生成至少一条目标医疗数据，发送至探查条件计算装置120。

[0103] 具体地，实体抽取模块131，用于针对于所述待测评医疗机构中的每一条临床医疗数据，基于预先训练好的医学概念及关系模型，从该条临床医疗数据中抽取出至少一个待处理实体，并确定各个待处理实体之间的关联关系；并将所述至少一个待处理实体发送至所述实体标准化模块132，同时将各个待处理实体之间的关联关系发送至所述目标数据生成模块133。

[0104] 在本申请实施例中，可临床医疗数据是该待测评医疗机构中不同患者的病例数据，可以规定一个时间段，获取的是这个时间段中该待测评医疗机构全部患者的病例数据。

[0105] 在一种可能的实施方式中，医学概念及关系模型可以从患者的病例中提出病例中所包括的待处理医学实体，并且可以确定出不同实体之间的关联关系，针对于不同待处理医学实体之间的关联关系，可以是根据不同医学实体的属性，以历史医学实体应用过程中确定出的不同医学实体之间的关联关系。

[0106] 举例来说，某患者的临床医学病历中有这么一句话：“发热2天，咳嗽3天”，从这句话中，通过医学概念模型识别出以下几个医学概念实体：发热（症状），2天（持续时间），咳嗽（症状），3天（持续时间）；再通过医学概念关系模型，识别出发热（症状）与2天（持续时间）存在关系；咳嗽（症状）与3天（持续时间）存在关系。

[0107] 实体标准化模块132，用于基于预先制定的医学概念标准，对各个待处理实体进行标准化，确定出多个医学实体；并将所述多个医学实体发送至所述目标数据生成模块133。

[0108] 在本申请实例中，不同医疗机构可能会采用不同的病例书写格式，甚至是同一医疗机构中不同医生书写的病例书格式可能都会存在一定的差异，因此，在数据处理过程中需要对提取出的待处理医学实体进行标准化，得到统一格式的医学实体，这样有助于后续对医疗机构与探查条件的匹配过程更加准确以及流畅，提升对待检测医疗机构测评的效率。

[0109] 在一种可能的实施方式中，可以是参考国际疾病分类（International Classificataion of Diseases，ICD）标准定制临床试验领域探查常用医学概念字典，生成临床试验领域标准化字典，来对待处理医学实体进行标准化处理生成标准化的医学实体。

[0110] 目标数据生成模块133，用于将接收到的具有关联关系的每两个医学实体进行关联加密后，生成至少一条目标医疗数据。

[0111] 在本申请实施例中，根据接收到的医学实体以及不同医学实体之间的关联关系，将具有关联关系的每两个医学实体进行关联，并且为了保证数据的安全性，需要对关联后的每两个医学实体进行加密，生成至少一条加密后的目标医疗数据。

[0112] 同样的，在目标医疗数据中也由主键（医学实体类型）、值（医学实体）、数据类型（医学实体数据类型，如整型数据、浮点型数据等）三部分组成，即，目标医疗数据中包括多个医学实体以及各个医学实体之间的关联关系。

[0113] 在一种可能的实施方式中，目标医疗数据中的主键，主要通过医学概念实体的类型来确定；症状、查体、诊断、药品名、检查名称、检验名称、观察对象、手术名称等主要医学实体作为主键；而类型为时间、部位、数值、性质等医学实体，会作为主键对应的值。

[0114] 下面将通过一个具体示例，来阐述医疗机构的筛选系统100来对待测评医疗机构进行测评的过程：

[0115] 步骤一、探查用户通过云端平台110提出：探查条件：年龄（主键）>（逻辑比较，大于）18（数值）岁（单位），同时血糖（主键）<（比较逻辑，小于）7（数值）mmol/L（单位）；

[0116] 步骤二、某待测评医疗机构的临床病历文书描述为：“患者年龄30岁，上次体检查血糖7.6mmol/l。”，根据自然语言处理（Natural Language Processing，NLP）模型识别的医学概念实体序列为：患者_person年龄_WAT，30_value，岁_unit，上次_TEN，体检_MAN，血糖_test，7.6_value, mmol/l_unit。

[0117] 步骤三、通过医学概念关系模型，可以得到上述2中每两个实体的修饰关系；第一组关系：【年龄（主键），30（数值），岁（单位）】， 第二组关系：【血糖（主键），7.6（数值），mmol/l】；并将这两组数组存入数据处理装置130；

[0118] 步骤四、探查条件计算装置120根据探查条件从蒸馏数据引擎中取数据，如根据年龄，可以从数据处理装置130中取到数值30，根据探查条件类型可知，是一个比较逻辑（大于），阈值18；因为30>18，所以这个探查条件的判别结果为true，即该待测评医疗机构命中探查用户的该探查条件。

[0119] 在一种可能的实施方式中，请参阅图3，图3为本申请实施例所提供的一种医疗机构的筛选系统100的结构示意图之二，筛选系统100还包括至少一个医疗机构数据库140，每个医疗机构数据库140对应一个数据处理装置130，可以向数据处理装置130发送对应的医疗机构的多个患者的病例数据。

[0120] 在一种可能的实施例中，医疗机构数据库140可以有选择地向数据处理装置130发送患者的病例数据，而不是数据处理装置130主动向医疗机构数据库140索要数据，这样可以在很大的程度上保证患者病例数据的安全性。

[0121] 在一种可能的实施方式中，数据处理装置130中设置有定时数据处理任务，按照预设时间间隔来对数据处理装置130中的医疗数据进行实体抽取生成目标医疗数据的处理，保证新入库临床病历数据被及时处理，存入数据处理装置130中，以供后续探查使用，保证了数据处理的时效性。

[0122] 本申请实施例提供了一种医疗机构的筛选系统，当探查用户在有探查需求时，可以通过登录云端平台输入多个探查条件，云端平台在接收到探查用户输入的多个探查条件进行加密后，生成探查请求，将分别探查请求发送给探查条件计算装置，探查条件计算装置在接收到云端平台发送的探查请求后，生成数据获取请求向数据处理装置获取至少一条目标医疗数据，数据处理装置在接收到探查条件计算装置发送的数据获取请求后，将存储的已经经过处理后的至少一条目标医疗数据发送至探查条件计算装置，探查条件计算装置根据目标医疗数据后，根据解析后的探查条件与接收到的目标医疗数据进行匹配，确定关联的待测评医疗机构的探查条件测评结果返回至云端平台，云端平台根据各个探查条件计算装置发送的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构。在本申请实施例中，通过云端平台发送探查请求，在保证数据安全的情况下，获取到不同的待检测医疗机构的经过数据处理装置进行实体抽取后的医疗数据，同时探查条件计算装置能够高效地计算出各个待检测医疗机构与探查用户的探查条件的测评情况反馈给云端平台，云端平台筛选出符合探查请求的目标医疗机构，有助于提升筛选出符合探查条件的医疗机构的准确率以及效率。

[0123] 请参阅图4，图4为本申请实施例所提供的一种医疗机构的筛选方法的流程图。如图4中所示，本申请实施例提供的医疗机构的筛选方法，包括：

[0124] S401、控制所述云端平台根据探查用户输入的至少一条探查条件，加密生成探查请求，并将所述探查请求发送至各个探查条件计算装置；接收各个探查条件计算装置发送各个待测评医疗机构的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构。

[0125] S402、控制所述探查条件计算装置在接收所述云端平台发送的探查请求后，向所述数据处理装置发送数据获取请求，接收所述数据处理装置反馈的至少一条目标医疗数据；根据解析后的探查请求中的至少一条加密探查条件比对关联的数据处理装置中的多条目标医疗数据，根据多条目标医疗数据与所述至少一条加密探查条件的匹配结果，确定关联的待测评医疗机构的探查条件测评结果，并将所述探查条件测评结果返回至所述云端平台。

[0126] S403、控制所述数据处理装置连接对应的待测评医疗机构的数据库，将连接的待测评医疗机构的数据库中的临床医疗数据进行关键词抽取处理，得到至少一条目标医疗数据；并在接收到所述探查条件计算装置的数据获取请求时，将所述至少一条目标医疗数据发送至所述探查条件计算装置；其中，每一条目标医疗数据中包括多个医学实体以及各个医学实体之间的关联关系。

[0127] 在一种可能的实施方式中，所述控制所述数据处理装置连接对应的待测评医疗机构的数据库，将连接的待测评医疗机构的数据库中的临床医疗数据进行关键词抽取处理，得到至少一条目标医疗数据，包括：

[0128] 针对于所述待测评医疗机构中的每一条临床医疗数据，基于预先训练好的医学概念及关系模型，从该条临床医疗数据中抽取出至少一个待处理实体，并确定各个待处理实体之间的关联关系；

[0129] 基于预先制定的医学概念标准，对各个待处理实体进行标准化，确定出多个医学实体；

[0130] 将接收到的具有关联关系的每两个医学实体进行关联加密后，生成至少一条目标医疗数据。

[0131] 在一种可能的实施方式中，所述筛选方法还包括：

[0132] 控制所述探查条件计算装置在接收到的探查请求后，将所述加密探查条件利用与所述云端平台约定好的第一密钥进行解密，得到与所述探查请求对应的至少一条探查条件。

[0133] 在一种可能的实施方式中，所述筛选方法还包括：

[0134] 控制所述探查条件计算装置针对于接收到的每一条目标医疗数据，利用与所述数据处理装置约定好的第二密钥，对该条目标医疗数据进行解密，确定出该条目标医疗数据中的数据主键以及数据值。

[0135] 在一种可能的实施方式中，所述探查条件中包括探查目标以及探查阈值条件，所述根据解析后的探查请求中的至少一条加密探查条件比对关联的数据处理装置中的多条目标医疗数据，根据多条目标医疗数据与所述至少一条加密探查条件的匹配结果，确定关联的待测评医疗机构的探查条件测评结果，包括：

[0136] 根据所述探查目标，从所述至少一条目标医疗数据中，筛选出数据主键与所述探查目标一致的候选医疗数据；

[0137] 针对于每一条候选医疗数据，若该条候选医疗数据中的数据值满足对应的探查阈值条件，确定该条候选医疗数据所属的待测评医疗机构命中一条探查条件。

[0138] 在一种可能的实施方式中，通过以下步骤确定符合探查用户的探查需求的目标医疗机构：

[0139] 基于各个探查条件计算装置发送的探查条件测评结果，筛选出排序位于预设位置之前的多个符合探查用户的探查需求的目标医疗机构。

[0140] 在一种可能的实施方式中，所述探查条件测评结果包括各个待测评医疗机构是否命中探查条件以及命中探查条件的数量，所述筛选方法还包括：

[0141] 基于各个探查条件计算装置发送的探查条件测评结果，对各个待测评医疗机构按照命中探查条件的数量由高到低的顺序排序。

[0142] 在一种可能的实施方式中，所述筛选方法还包括：

[0143] 若存在命中探查条件的数量一致的至少两个待测评医疗机构，则按照预先设定的探查条件的优先级，将至少两个待测评医疗机构按照命中探查条件的优先级由高到低的顺序排序。

[0144] 在一种可能的实施方式中，所述筛选方法还包括：

[0145] 在接收到探查用户的登录请求时，根据所述探查用户的登录标识，检测在合作用户数据库中是否存在所述探查用户；

[0146] 若在合作用户数据库中存在所述探查用户，检测所述探查用户输入的第一登录密码以及第二登录密码是否均正确；

[0147] 若所述探查用户输入的第一登录密码以及第二登录密码均正确，接收所述探查用户的输入。

[0148] 其中，对于医疗机构的筛选方法的描述可以医疗机构的筛选系统的描述，并且能达到相同的技术效果，对此不做赘述。

[0149] 本申请实施例提供了一种医疗机构的筛选方法，当探查用户在有探查需求时，可以通过登录云端平台输入多个探查条件，云端平台在接收到探查用户输入的多个探查条件进行加密后，生成探查请求，将分别探查请求发送给探查条件计算装置，探查条件计算装置在接收到云端平台发送的探查请求后，生成数据获取请求向数据处理装置获取至少一条目标医疗数据，数据处理装置在接收到探查条件计算装置发送的数据获取请求后，将存储的已经经过处理后的至少一条目标医疗数据发送至探查条件计算装置，探查条件计算装置根据目标医疗数据后，根据解析后的探查条件与接收到的目标医疗数据进行匹配，确定关联的待测评医疗机构的探查条件测评结果返回至云端平台，云端平台根据各个探查条件计算装置发送的探查条件测评结果，确定出符合探查用户的探查需求的目标医疗机构。在本申请实施例中，通过云端平台发送探查请求，在保证数据安全的情况下，获取到不同的待检测医疗机构的经过数据处理装置进行实体抽取后的医疗数据，同时探查条件计算装置能够高效地计算出各个待检测医疗机构与探查用户的探查条件的测评情况反馈给云端平台，云端平台筛选出符合探查请求的目标医疗机构，有助于提升筛选出符合探查条件的医疗机构的准确率以及效率。

[0150] 请参阅图5，图5为本申请实施例所提供的一种电子设备的结构示意图。如图5中所示，所述电子设备500包括处理器510、存储器520和总线530。

[0151] 所述存储器520存储有所述处理器510可执行的机器可读指令，当电子设备500运行时，所述处理器510与所述存储器520之间通过总线530通信，所述机器可读指令被所述处理器510执行时，可以执行如上述图4所示方法实施例中的医疗机构的筛选方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。

[0152] 本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时可以执行如上述图4所示方法实施例中的医疗机构的筛选方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。

[0153] 所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

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

[0158] 最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。