CN116795725B - 一种临床电子数据采集***的自动验库方法和*** - Google Patents

Abstract

本申请涉及了一种临床电子数据采集***的自动验库方法和***，本方法针对逻辑测试的底层逻辑，在获取人为设计的当前逻辑规则后，从规则定义中提取通配符、取值变量和动态表格映射，进而裂变出若干个可能的场景，进而利用Transformer框架自动得到每个测试场景对应的测试案例，最后将测试案例写入当前逻辑规则，并提交至EDC***，以使EDC***得到当前逻辑规则的验证结果。本实施例无需人工介入，不仅采用裂变方式获取了大量的可能的测试案例，且测试案例是由Transformer框架通过程序自动问答得出，节省了大量的测试时长，还能够确保逻辑规则验证过程的数据可溯源。

Description

一种临床电子数据采集***的自动验库方法和***

技术领域

申请实施例涉及EDC***数据处理技术领域，尤其涉及一种临床电子数据采集***的自动验库方法和***。

背景技术

用户在使用各类临床电子数据采集***时，其中最为耗时的环节是：电子病历报告表的测试/验证工作。而这个过程中最复杂、耗时的就是：逻辑测试/验证。

目前市面上对于逻辑测试通用做法是：用户在逻辑测试需要提前设计好DVP文件，然后初始化DVP中各类逻辑的测试数据，最后通过人工的方式对各类逻辑规则进行用例测试，以界面反馈的结果与DVP中期望结果进行人工核对。

这种方式既耗时容易出现遗漏，当测试过程中发现存在配置问题的逻辑，需要用户修正对应的逻辑后，再次人工测试验证。这种方式其测试质量完全取决于测试人员的综合素质，其测试成本大，效率也很低，对电子病历报告表的上线将带来不可预知的潜在风险。并且在测试过程中通过Excel文件方式记录是无法做到全程可溯源、留痕的。

发明内容

以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。

本公开实施例的主要目的在于提出一种临床电子数据采集***的自动验库方法和***。能够节省大量的测试时间，而且测试过程产生的数据可以进行存档进而保证测试数据可溯源。

为实现上述目的，本公开实施例的一种临床电子数据采集***的自动验库方法，所述临床电子数据采集***的自动验库方法包括：

获取电子病例报告表中待验证的当前逻辑规则；

从所述当前逻辑规则的逻辑规则定义中提取通配符、取值变量和动态表格映射，从提取的所述通配符、取值变量和动态表格映射中裂变出若干个测试场景；

将每一个所述测试场景输入至预设的Transformer框架中进行问答响应，以得到每一个所述测试场景对应的测试案例，并将每一个所述测试案例写入所述当前逻辑规则中对应的位置；

将所述当前逻辑规则提交至临床电子数据采集***中，以便得到所述临床电子数据采集***对于所述当前逻辑规则的验证结果。

在一些实施例中，在所述获取电子病例报告表中待验证的当前逻辑规则之后，所述临床电子数据采集***的自动验库方法还包括：

提取所述当前逻辑规则中的逻辑规则定义和逻辑说明；

对所述逻辑规则定义和所述逻辑说明之间的对应关系进行逻辑校验。

在一些实施例中，所述对所述逻辑规则定义和所述逻辑说明之间的对应关系进行逻辑校验，包括：

根据所述逻辑规则定义中的字符，从所述电子病例报告表中寻找对应的元素；

将所述元素替换所述逻辑规则定义中的对应字符，形成待验证表达式；

校验所述待验证表达式和所述逻辑说明之间的逻辑。

在一些实施例中，所述将每一个所述测试案例写入所述当前逻辑规则中对应的位置，包括：

确定所述测试案例在所述当前逻辑规则中的所属位置；

将所述变量元素填写在所述当前逻辑规则中的所属位置中。

在一些实施例中，在所述获取电子病例报告表对应待验证的当前逻辑规则之前，所述临床电子数据采集***的自动验库方法还包括：

提取所述电子病例报告表中的待检测元素；

若所述待检测元素不符合检测标准，则修复所述电子病例报告表中不符合所述检测标准的所述待检测元素。

在一些实施例中，所述当前逻辑规则通过如下方式进行验证：

对所述当前逻辑规则中每一个所述测试案例进行验证，得到验证结果；

当预设期望结果与所述验证结果相符合，验证成功。

在一些实施例中，在所述得到所述临床电子数据采集***对于所述当前逻辑规则的验证结果之后，所述临床电子数据采集***的自动验库方法还包括：

保存所述当前逻辑规则的验证过程形成的验证过程数据；

根据所述验证过程数据生成验证报告；

根据所述验证报告生成DVP文件。

为实现上述目的，本公开实施例的第二方面提出了一种临床电子数据采集***的自动验库***，所述临床电子数据采集***的自动验库***包括：

逻辑规则获取单元，用于获取电子病例报告表中待验证的当前逻辑规则；

测试场景生成单元，用于从所述当前逻辑规则的逻辑规则定义中提取通配符、取值变量和动态表格映射，从提取的所述通配符、取值变量和动态表格映射中裂变出若干个测试场景；

测试案例生成单元，用于将每一个所述测试场景输入至预设的Transformer框架中进行问答响应，以得到每一个所述测试场景对应的测试案例；

测试案例赋值单元，用于将每一个所述测试案例写入所述当前逻辑规则中对应的位置；

逻辑规则验证单元，用于将所述当前逻辑规则提交至临床电子数据采集***中，以便得到所述临床电子数据采集***对于所述当前逻辑规则的验证结果。

为实现上述目的，本公开实施例的第三方面提出了一种电子设备，包括至少一个存储器；

至少一个处理器；

至少一个计算机程序；

所述计算机程序被存储在所述存储器中，处理器执行所述至少一个计算机程序以实现：

如第一方面实施例任一项所述的临床电子数据采集***的自动验库方法。

为实现上述目的，本公开实施例的第四方面还提出一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行：

如第一方面实施例任一项所述的一种临床电子数据采集***的自动验库方法。

本申请实施例第一方面提供了一种临床电子数据采集***的自动验库方法，方法针对逻辑测试的底层逻辑，首先是通过在EDC***中集成相应程序，在获取人为设计的当前逻辑规则后，从规则定义中提取通配符、取值变量和动态表格映射，进而裂变出若干个可能的场景，进而利用Transformer框架自动得到每个测试场景对应的测试案例，最后将测试案例写入当前逻辑规则，并提交至EDC***，以使EDC***得到当前逻辑规则的验证结果。本实施例无需人工介入，不仅采用裂变方式获取了大量的可能的测试案例，且测试案例是由Transformer框架通过程序自动问答得出，节省了大量的测试时长，而且能够确保逻辑规则验证过程的数据可溯源。

可以理解的是，上述第二方面至第四方面和相关技术相比存在的有益效果和上述第一方面和相关技术相比存在的有益效果相同，可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例的一些实施例，对于本领域普通技术人员来说，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一个实施例提供常规的逻辑测试的流程框图；

图2是本申请一个实施例提供的临床电子数据采集***的自动验库方法的流程图；

图3是本申请另一个实施例提供的临床电子数据采集***的自动验库方法的流程图；

图4是本申请一个实施例提供的一种元素检测的流程图；

图5是本申请一个实施例提供的采血记录表的实例图；

图6是本申请一个实施例提供的逻辑校验的流程图；

图7是图6中步骤S1052的具体流程图；

图8是本申请一个实施例提供的测试案例写入的流程图；

图9是本申请一个实施例提供的对当前逻辑规则进行验证的流程图；

图10是本申请一个实施例提供的DVP文件生成示意图；

图11是本申请一个实施例提供的一种电子设备的结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

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

EDC（Electronic Data Capture System）即临床电子数据采集***/数据管理***。

传统的临床试验是通过纸质材料的方式进行临床试验数据收集，后续因信息化发展过渡至使用信息化***进行临床试验数据收集，以达到：真实、可靠、可溯源目的。请参照图1，用户在使用各类临床电子数据采集***时，其中最为耗时的环节是：电子病历报告表的测试/验证工作。而这个过程中最复杂、耗时的就是：逻辑测试/验证，常规的逻辑测试需要经过以下几个步骤：

步骤S201、DVP文件设计（Design Verification Plan）；

步骤S202、逻辑规则设计；

步骤S203、创建测试受试者；

步骤S204、对照DVP文件中测试案例一条一条的填写受试者中对应元素的数据，人工核查结果是否符合预期；

步骤S205、对合格/不合格记录通过excel文件存档记录。

步骤S206、重新修改逻辑规则设计；

步骤S207、再次执行步骤S203至步骤S206步骤，直至测试案例通过。

如图1，用户在逻辑测试需要提前设计好DVP文件（包含测试案例的描述、测试案例、期望结果），然后初始化DVP中各类逻辑的测试数据，最后通过人工的方式对各类逻辑规则进行测试案例的测试，以EDC界面反馈结果与DVP中期望结果进行人工核对，直至所有测试案例全部通过。

在试验中存在这样一条日期校验：筛选期D-7~D-1--知情同意--签署时间≠第一周期访视日期--试验开始日期前1-7天。该场景是需要***自动检查筛选期D-7~D-1--知情同意--签署时间的录入值与第一周期访视日期--试验开始日期的录入值是否在1-7天内。

步骤S301、用户编写一条逻辑规则，逻辑规则内容为：

表达式（由逻辑规则的定义转换而来）：datesDiff(date2, date1, 'd')>7 ordatesDiff(date2, date1,'d')<1；

变量名（date1）：第一周期D1~D2 / 访视日期 / 访视日期 / 访视开始日期；

变量名（date2）：筛选期D-7~D-1 / 知情同意 / 知情同意 / 签署时间；

质疑内容：知情同意--签署时间不在第一周期访视开始日期前1-7天，请核实。

步骤S302、用户要验证该逻辑规则配置是否正确，需要进行DVP文件设计，根据逻辑规则定义设计出逻辑规则的参考数据及期望表现。

步骤S303、用户手动创建受试者，并进入筛选期D-7~D-1 / 知情同意 / 知情同意/ 签署时间变量位置录入：2022/10/12 11:47。

步骤S304、用户需要切换至第一周期D1~D2 / 访视日期 / 访视日期 / 访视开始日期位置，并且录入：2022/10/26。

步骤S305、用户观察第一周期D1~D2 / 访视日期 / 访视日期 / 访视开始日期是否产生了数据质疑。

因此，用户就需要检查逻辑规则配置是否存在问题。

重复上述的过程，直至最终结果符合DVP文件中的期望结果。

这种方式既耗时，而且容易出现遗漏，当测试过程中发现存在配置问题的逻辑规则，需要用户修正对应的逻辑规则后，再次人工测试验证。这种方式其测试质量完全取决于测试人员的综合素质，其测试成本大，效率也很低，对电子病历报告表（eCRF）的上线将带来不可预知的潜在风险。

电子病历报告表中的逻辑测试主要是根据现有的逻辑规则定义，从而产生该逻辑规则定义对应的测试场景（测试案例是源自测试场景的基本活动）、测试案例、期望结果。用户在执行测试过程中是通过分析测试场景后在临床电子数据采集***中找到对应录入界面；填写该测试场景的测试案例后提交，根据提交后的界面展现结果和测试场景的期望结果进行人工比对，以判定该测试场景是否通过。

基于上述的场景分析，电子病历报告表（eCRF）的逻辑测试这项工作底层逻辑是：

根据逻辑规则定义产生测试场景及测试期望结果，分析出该测试场景的理论测试案例；输入测试案例数据后提交；检查提交数据后的表现是否符合期望结果。

参照图2至图10，图2为本申请的一个实施例，提供一种临床电子数据采集***的自动验库方法，应理解，本申请实施例的临床电子数据采集***的自动验库方法包括但不限于步骤S102、步骤S104、步骤S106和S108，以下结合图2对步骤S102至步骤S108进行详细介绍：

步骤S102、获取电子病例报告表对应待验证的当前逻辑规则。

当前逻辑规则是暂未经过验证或是已经过验证不合格后进行修改后的逻辑规则。若当前逻辑规则是暂未经过验证的逻辑规则，则当前逻辑规则为人工提前设置，若当前逻辑规则验证不合格后，继续由人工进行修改。还需要注意的是，除去当前逻辑规则生成或修改，其余步骤均由本方法自动执行，无需人工参与。

参照图4，在步骤S102之前，本方法还包括步骤S1011和1012：

步骤S1011、提取电子病例报告表中的待检测元素。

步骤S1012、若待检测元素不符合检测标准，则修复电子病例报告表中不符合检测标准的待检测元素。本实施例提供了电子病例报告表的元素检测功能，用户通过该检测功能可以减少不必要的页面反复测试工作，在逻辑规则设计之初就能确保相应元素的设计是符合要求的。

步骤S104、从当前逻辑规则的逻辑规则定义中提取通配符、取值变量和动态表格映射，从提取的通配符、取值变量和动态表格映射中裂变出若干个测试场景。

临床电子数据采集***中对逻辑规则的定义由：规则编号、规则说明、逻辑规则定义（逻辑规则定义可转换为表达式）、触发变量、目标元素组成，任何一条逻辑规则的配置都是由上述五个部分组成。其中触发变量和目标元素由：访视、表单、变量组、变量构成。因此，在触发变量、目标元素的配置时***支持以下几种裂变场景：通配符、取值变量、动态表格映射。

通配符是指逻辑中触发变量或目标元素的访视、表单信息使用通配符“*”代替，表示：该逻辑自动匹配任意访视、任意表单中存在指定变量组的指定字段。参照图5，具体使用说明：一个临床试验有2个给药周期，各给药周期中都存在血样采集表格（PC），血样采集中存在开始时间（PCDAST）、结束时间字段(PCDAEND)，在进行数据采集时需要验证2个周期中血样采集表格中的开始时间是否小于结束时间。在进行此类规则配置时其触发变量、目标元素的配置将使用通配符，例如：触发变量（var1）为*/*/PC/PCDAST、触发变量（var2）为*/*/PC/PCDAEND。

取值变量是指逻辑规则配置时配置一个中间变量，该变量的取值由一系列字典组成。当规则中配置了取值变量时，***在运行时将由根据取值变量的字典值数据进行裂变。仍以图5为例，给药后0.25h、给药后0.5h、给药后0.75h这三个点的开始时间与结束时间存在一个窗口校验逻辑。即：开始时间与结束时间之间的时间窗口为±1分钟。在配置该逻辑时将设置一个取值变量：timepoint，该变量的取值是：给药后0.25h、给药后0.5h、给药后0.75h，然后再设置一个timewindow，该变量的取值：1。触发变量仍然是（var1）为*/*/PC/PCDAST、触发变量（var2）为*/*/PC/PCDAEND。动态表格是指逻辑中的触发或目标元素指定的字段是属于动态表格中的元素。动态表格是指该变量组是一个表格，但是该表格最终会产生多少行数据是动态的、不确定的。因此，在进行逻辑规则设计时只能指定至该表格的列头字段元素，***在实际执行时会根据该表格的实际行数据进行裂变分析。

本实施例可采用由笛卡尔乘积和集合运算的裂变算法，并结合***的通配符、取值变量配置设计来实不同测试场景。笛卡尔乘积和集合运算的裂变算法为现有算法，此处不再细述。

参照图6，在步骤S104之后，本方法还包括如下步骤：

步骤S1051、提取当前逻辑规则中的逻辑规则定义和逻辑说明。

步骤S1052、对逻辑规则定义和逻辑说明之间的对应关系进行逻辑校验。

参照图7，其中，步骤S1052具体包括如下：

步骤S10521、根据逻辑规则定义中的字符，从电子病例报告表中寻找对应的元素。

先将逻辑规则定义转换成表达式，例如：

逻辑规则的定义描述为：筛选期D-7~D-1--知情同意--签署时间≠第一周期访视日期--试验开始日期前1-7天。将这一条日期校验的逻辑规则定义描述作为例子，将定义描述转换成如下表达式：

datesDiff(date2, date1, 'd')>7 or datesDiff(date2, date1,'d')<1。

步骤S10522、将元素替换表达式中的对应字符，形成待验证表达式。

步骤S10523、校验待验证表达式和逻辑说明之间的逻辑。

例如表达式为：x>y，***将读取x、y变量对应的电子病例报告表的元素值，然后x、y替换成对应的元素值。

本实施例提供了逻辑规则定义（可转换成表达式）与逻辑说明的逻辑一致性核查。即：逻辑执行之前***将分析表达式的内容是否符合逻辑说明，当检测到可能存在逻辑错误的数据时，自动中断该逻辑规则的自动测试，减少错误的配置执行了错误的测试案例给用户带来人工介入验证的复杂度。

当表达式分析通过后，将进行测试的案例生成阶段。在此阶段将提取逻辑规则定义（可转换成表达式）的各项数据，采用裂变算法自动匹配所有可能的案例场景。在裂变了所有测试场景后，根据具体的测试场景结合定义中触发变量的类型进行智能化问题生成，最后结合Transformer实现测试案例生成。具体如下步骤S106所示。

步骤S106、将每一个测试场景输入至预设的Transformer框架中进行问答响应，以得到每一个测试场景对应的测试案例，并将每一个测试案例写入当前逻辑规则中对应的位置。

在本申请的一些实施例中，Transformer框架为ChatGPT（Chat Generative Pre-trained Transformer，是OpenAI研发的聊天机器人程序）。将测试场景输入至ChatGPT，得到ChatGPT输出对测试场景的响应，即得到ChatGPT输出测试场景对应的测试案例。

例如：将datesDiff(date2, date1, 'd')>7输入ChatGPT，ChatGPT将输出变量元素：''date2'': ''2023-05-23 08:00:00''。后续把''date2'': ''2023-05-23 08:00:00''作为测试案例，将测试案例填写如当前逻辑规则中的指定位置。

参照图8，在本申请的一些实施例中，将每一个测试案例写入当前逻辑规则中对应的位置，包括如下步骤S1071和S1072：

步骤1071、确定测试案例在当前逻辑规则中的所属位置。

步骤1072、将变量元素填写在当前逻辑规则中的所属位置中。

步骤S108、将当前逻辑规则提交至临床电子数据采集***中，以便得到临床电子数据采集***对于当前逻辑规则的验证结果。

在将逻辑规则提交至临床电子数据采集***（即EDC）后，EDC***将自动触发逻辑规则执行运算。

在本申请的一些实施例中，本步骤S1011至步骤S1072可使用集成于EDC***中的Transformer框架执行相应程序执行。

参照图9，在EDC***中，通过如下方式对当前逻辑规则进行验证：

步骤S1081、对当前逻辑规则中每一个测试案例进行验证，得到验证结果。

步骤S1082、当预设期望结果与验证结果相符合，验证成功。

在开始验证前，可基于用户需求设定一个期望结果，例如设置产生质疑作为期望结果，根据需要进行验证的变量元素对当前逻辑规则进行验证，如果EDC***验证不成立，产生对变量元素的质疑结果，则逻辑规则验证成功。

若验证结果不合格的话，重新设计该逻辑规则，再次验证。这里不进行细述。

参照图10，在本申请的一些实施例中，在得到临床电子数据采集***对于当前逻辑规则的验证结果之后，临床电子数据采集***的自动验库方法还包括：

步骤S1091、保存当前逻辑规则的验证过程形成的验证过程数据。

步骤S1092、根据验证过程数据生成验证报告。

步骤S1093、根据验证报告生成DVP文件。

相较于常规的方式，采用本实施例方案进行逻辑规则测试极大了缩短了验证的时间。而且相较于DVP文件的验证方式采用Excel文件方式记录是无法做到全程可溯源，采用本方案能够存档所有验证过程数据从而形成验证报告。

另外，EDC***生成的验证报告还能够实现反向输出DVP文件，释放用户DVP文件设计的工作量。示例：***中每一条逻辑规则测试后都将产生其测试历史数据。当用户需要根据***的测试数据进行DVP文件反向输出时，其测试案例即未应用本方法时，需要人工设计的数据；通过应用本方法结合测试案例数据可以实现该列数据自动生成，而该DVP文件中其他列的数据均可以从***中获取相关信息。

而且，Transformer在经过不断的训练进行数据积累后，在未来还可以实现对临床试验方案中进行关键字提取，将逻辑规则设计中各种关键参数提取整合后，实现逻辑规则设计自动生成。

本实施例针对逻辑测试的底层逻辑（根据逻辑规则定义产生测试场景及测试期望结果，分析出该测试场景的理论测试案例；输入测试案例数据后提交；检查提交数据后的表现是否符合期望结果），首先是通过在EDC***中集成相应程序，在获取人为设计的当前逻辑规则后，从规则定义中提取通配符、取值变量和动态表格映射，进而裂变出若干个可能的场景，进而利用Transformer框架自动得到每个测试场景对应的测试案例，最后将测试案例写入当前逻辑规则，并提交至EDC***，以使EDC***得到当前逻辑规则的验证结果。本实施例无需人工介入，不仅采用裂变方式获取了大量的可能的测试案例，且测试案例是由Transformer框架通过程序自动问答得出，节省了大量的测试时长，而且能够确保逻辑规则验证过程的数据可溯源。

本实施例还提供了电子病例报告表的元素检测功能，用户通过该检测功能可以减少不必要的页面反复测试工作，在逻辑规则设计之初就能确保相应元素的设计是符合要求的。

本实施例还提供了逻辑规则定义与逻辑说明的逻辑一致性核查。减少错误的配置执行了错误的测试案例给用户带来人工介入验证的复杂度。

本申请的一个实施例，提供了一种临床电子数据采集***的自动验库***，所述临床电子数据采集***的自动验库***包括逻辑规则获取单元、测试场景生成单元、测试案例生成单元、测试案例赋值单元和逻辑规则验证单元，其中，具体包括如下：

逻辑规则获取单元用于获取电子病例报告表中待验证的当前逻辑规则。

测试场景生成单元用于从当前逻辑规则的逻辑规则定义中提取通配符、取值变量和动态表格映射，从提取的通配符、取值变量和动态表格映射中裂变出若干个测试场景。

测试案例生成单元用于将每一个测试场景输入至预设的Transformer框架中进行问答响应，以得到每一个测试场景对应的测试案例。

测试案例赋值单元用于将每一个测试案例写入当前逻辑规则中对应的位置。

逻辑规则验证单元用于将当前逻辑规则提交至临床电子数据采集***中，以便得到临床电子数据采集***对于当前逻辑规则的验证结果。

需要注意的是，本实施例与上述方法实施例是基于相同的发明构思，因此上述的方法实施例的相关内容同样适应于本实施例，此处不再赘述。

参照图11，本申请实施例还提供了一种电子设备，本电子设备包括：

至少一个存储器；

至少一个处理器；

至少一个程序；

程序被存储在存储器中，处理器执行至少一个程序以实现本公开实施上述的临床电子数据采集***的自动验库方法。

该电子设备可以为包括手机、平板电脑、个人数字助理（Personal DigitalAssistant，PDA）、车载电脑等任意智能终端。

下面对本申请实施例的电子设备进行详细介绍。

处理器1600，可以采用通用的中央处理器(Central Processing Unit，CPU)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本公开实施例所提供的技术方案；

存储器1700，可以采用只读存储器（Read Only Memory，ROM）、静态存储设备、动态存储设备或者随机存取存储器(Random Access Memory，RAM)等形式实现。存储器1700可以存储操作***和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1700中，并由处理器1600来调用执行本公开实施例的临床电子数据采集***的自动验库方法。

输入/输出接口1800，用于实现信息输入及输出；

通信接口1900，用于实现本设备与其他设备的通信交互，可以通过有线方式（例如USB、网线等）实现通信，也可以通过无线方式（例如移动网络、WIFI、蓝牙等）实现通信；

总线2000，在设备的各个组件（例如处理器1600、存储器1700、输入/输出接口1800和通信接口1900）之间传输信息；

其中处理器1600、存储器1700、输入/输出接口1800和通信接口1900通过总线2000实现彼此之间在设备内部的通信连接。

本公开实施例还提供了一种存储介质，该存储介质是计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令用于使计算机执行上述临床电子数据采集***的自动验库方法。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本公开实施例描述的实施例是为了更加清楚的说明本公开实施例的技术方案，并不构成对于本公开实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本公开实施例提供的技术方案对于类似的技术问题，同样适用。

本领域技术人员可以理解的是，图中示出的技术方案并不构成对本公开实施例的限定，可以包括比图示更多或更少的步骤，或者组合某些步骤，或者不同的步骤。

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

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、***、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上是对本申请实施例的较佳实施进行了具体说明，但本申请实施例并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请实施例精神的前提下还可作出种种的等同变形或替换，这些等同的变形或替换均包含在本申请实施例权利要求所限定的范围内。

Claims (8)

1.一种临床电子数据采集***的自动验库方法，其特征在于，所述临床电子数据采集***的自动验库方法包括：

获取电子病例报告表中待验证的当前逻辑规则；

从所述当前逻辑规则的逻辑规则定义中提取通配符、取值变量和动态表格映射，从提取的所述通配符、取值变量和动态表格映射中裂变出若干个测试场景；

提取当前逻辑规则中的逻辑规则定义和逻辑说明；对逻辑规则定义和逻辑说明之间的对应关系进行逻辑校验；其中，所述对逻辑规则定义和逻辑说明之间的对应关系进行逻辑校验包括：根据逻辑规则定义中的字符，从电子病例报告表中寻找对应的元素；将元素替换表达式中的对应字符，形成待验证表达式；校验待验证表达式和逻辑说明之间的逻辑；当表达式分析通过后，将进行测试的案例生成阶段；

将每一个所述测试场景输入至预设的Transformer框架中进行问答响应，以得到每一个所述测试场景对应的测试案例，并将每一个所述测试案例写入所述当前逻辑规则中对应的位置；

将所述当前逻辑规则提交至临床电子数据采集***中，以便得到所述临床电子数据采集***对于所述当前逻辑规则的验证结果。

2.根据权利要求1所述的临床电子数据采集***的自动验库方法，其特征在于，所述将每一个所述测试案例写入所述当前逻辑规则中对应的位置，包括：

确定所述测试案例在所述当前逻辑规则中的所属位置；

将所述测试案例填写在所述当前逻辑规则中的所属位置中。

3.根据权利要求1所述的临床电子数据采集***的自动验库方法，其特征在于，在所述获取电子病例报告表对应待验证的当前逻辑规则之前，所述临床电子数据采集***的自动验库方法还包括：

提取所述电子病例报告表中的待检测元素；

若所述待检测元素不符合检测标准，则修复所述电子病例报告表中不符合所述检测标准的所述待检测元素。

4.根据权利要求1所述的临床电子数据采集***的自动验库方法，其特征在于，所述当前逻辑规则通过如下方式进行验证：

对所述当前逻辑规则中每一个所述测试案例进行验证，得到验证结果；

当预设期望结果与所述验证结果相符合，验证成功。

5.根据权利要求1至4任一项所述的临床电子数据采集***的自动验库方法，其特征在于，在所述得到所述临床电子数据采集***对于所述当前逻辑规则的验证结果之后，所述临床电子数据采集***的自动验库方法还包括：

保存所述当前逻辑规则的验证过程形成的验证过程数据；

根据所述验证过程数据生成验证报告；

根据所述验证报告生成DVP文件。

6.一种临床电子数据采集***的自动验库***，其特征在于，所述临床电子数据采集***的自动验库***包括：

逻辑规则获取单元，用于获取电子病例报告表中待验证的当前逻辑规则；

测试场景生成单元，用于从所述当前逻辑规则的逻辑规则定义中提取通配符、取值变量和动态表格映射，从提取的所述通配符、取值变量和动态表格映射中裂变出若干个测试场景；提取当前逻辑规则中的逻辑规则定义和逻辑说明；对逻辑规则定义和逻辑说明之间的对应关系进行逻辑校验；其中，所述对逻辑规则定义和逻辑说明之间的对应关系进行逻辑校验包括：根据逻辑规则定义中的字符，从电子病例报告表中寻找对应的元素；将元素替换表达式中的对应字符，形成待验证表达式；校验待验证表达式和逻辑说明之间的逻辑；当表达式分析通过后，将进行测试的案例生成阶段；

测试案例生成单元，用于将每一个所述测试场景输入至预设的Transformer框架中进行问答响应，以得到每一个所述测试场景对应的测试案例；

测试案例赋值单元，用于将每一个所述测试案例写入所述当前逻辑规则中对应的位置；

逻辑规则验证单元，用于将所述当前逻辑规则提交至临床电子数据采集***中，以便得到所述临床电子数据采集***对于所述当前逻辑规则的验证结果。

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

至少一个存储器；

至少一个处理器；

至少一个计算机程序；

所述计算机程序被存储在所述存储器中，处理器执行所述至少一个计算机程序以实现：

如权利要求1至5任一项所述的临床电子数据采集***的自动验库方法。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行：

如执行权利要求1至5任一项所述的临床电子数据采集***的自动验库方法。