临床试验数据核查方法和装置、电子设备和存储介质

技术领域

本申请临床试验数据电子采集系统技术技术领域，具体涉及一种临床试验数据核查方法和装置、电子设备和存储介质。

背景技术

临床试验研究中，测试人员需要一次次的阅读临床试验方案，根据试验方案来设计测试方案，测试方案和试验方案具有很强的关联性。然而，临床试验方案在设计和执行过程中，经常发生变化，每次试验方案变更都需要重新进行一次测试，导致测试工作费时费力。

公开于该背景技术部分的信息仅仅旨在增加对本申请的总体背景的理解，而不应当被视为承认或以任何形式暗示该信息构成已为本领域一般技术人员所公知的现有技术。

发明内容

本申请的目的在于提供一种临床试验数据核查方法，其用于解决临床试验研究中的测试工作量大的问题。

为实现上述目的，本申请提供了一种临床试验数据核查方法，所述方法包括：

响应于用户的测试请求，基于预配置的数据核查逻辑，生成测试案例，其中，所述测试案例包括至少一个数据点和所述至少一个数据点对应的期望结果；

基于所述测试案例与数据核查方案的比对结果，确定所述数据核查逻辑的预配置是否符合数据核查方案。

一实施例中，所述方法还包括：

在所述测试案例与数据核查方案的比对结果一致时，基于目标协议标准和所述至少一条测试案例的数据点生成受试者文件；

基于所述受试者文件运行预配置的数据核查逻辑，以生成测试报告，其中，所述测试报告包括与所述测试案例对应的输出结果和所述期望结果。

一实施例中，所述数据点包括临床试验数据和所述临床试验数据在数据库中的存储结构，所述目标协议标准包括所述存储结构对应的模板文件；

基于目标协议标准和所述至少一条测试案例的数据点生成受试者文件，具体包括：

确定与所述存储结构匹配的模板文件；

利用所述临床试验数据填充所述模板文件，得到所述受试者文件。

一实施例中，所述方法还包括：

在所述测试报告的输出结果和期望结果不匹配时，在所述测试报告中突出显示所述输出结果和/或期望结果。

一实施例中，所述目标协议标准包括临床数据交换标准协会标准、临床数据采集整合模型、研究数据列表模型中的任一项。

一实施例中，所述用户的测试请求为对目标案例的测试请求；

在所述测试案例与数据核查方案的比对结果不一致时，所述方法还包括：

基于更新后的所述数据核查逻辑，生成与所述目标案例对应的更新测试案例。

一实施例中，所述期望结果包括对测试案例中至少一个数据点的质疑。

本申请还提供一种临床试验数据核查装置，所述方法包括：

生成模块，用于响应于用户的测试请求，基于预配置的数据核查逻辑，生成测试案例，其中，所述测试案例包括至少一个数据点和所述至少一个数据点对应的期望结果；

确定模块，用于基于所述测试案例与数据核查方案的比对结果，确定所述数据核查逻辑的预配置是否符合数据核查方案。

本申请还提供一种电子设备，包括：

至少一个处理器；以及

存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上所述的临床试验数据核查方法。

本申请还提供一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的临床试验数据核查方法。

与现有技术相比，根据本申请的临床实验数据核查方法，通过预配置的数据核查逻辑，直接生成测试案例，并根据测试案例与数据核查方案的比对结果，直接确定数据核查逻辑的预配置是否符合数据核查方案，相对于人工撰写测试案例，无需用户过多分析数据核查方案并撰写测试方案，减轻了测试人员的负担，且避免了人为编写的测试案例本身有错误的可能。

在另一个方面，本申请的临床实验数据核查方案，改变了分析数据核查方案-撰写测试方案-临床试验数据核查测试-人工撰写测试报告的测试逻辑，通过自动生成测试案例，自动执行生成测试结果和测试报告，相对现有的测试逻辑更为精简。

附图说明

图1是临床实验数据建库的流程示意图；

图2是根据本申请一实施例临床试验数据核查方法的应用场景示意图；

图3是根据本申请一实施例临床试验数据核查方法的流程图；

图4是根据本申请一实施例临床实验数据核查装置的模块图；

图5是根据本申请一实施方式电子设备的硬件结构图。

具体实施方式

以下将结合附图所示的各实施方式对本申请进行详细描述。但该等实施方式并不限制本申请，本领域的普通技术人员根据该等实施方式所做出的结构、方法、或功能上的变换均包含在本申请的保护范围内。

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

药物的临床试验指的是在人体进行的药物系统性研究，以确定药物的疗效和安全性。药物临床试验阶段分为I期、II期、III期临床试验、IV期临床试验。I期主要是涉及初步的临床药理学及人体安全性评价试验。II期可以理解为治疗作用初步评价阶段，主要涉及初步评价药物对目标适应症患者的治疗作用和安全性，也包括为III期临床试验研究设计和给药剂量方案的确定提供依据。III期可以理解为治疗作用确证阶段，主要进一步验证药物对目标适应症患者的治疗作用和安全性，评价利益与风险关系，最终为药物注册申请的审查提供充分的依据。IV期主要是药物上市后的临床试验，在药物上市后，可以继续追踪在广泛使用条件下的药物的疗效和不良反应，以评价在普通或者特殊人群中使用的利益与风险关系以及改进给药剂量等。

临床试验方案是一份描述临床试验将要如何进行开展的文件，包括目标、设计、方法、统计考虑和试验的组织，同时还提供了进行研究的背景和理由，所要解决的研究问题，以及对伦理问题的考虑等内容，以保证参与者的安全和收集的数据的完整性。

病例报告表(Case Report Form，CRF)，是按试验方案规定设计的一种文件，用以记录每一名受试者在试验过程中的数据，可用于向研究基地、申办者和统计部门提供临床试验的相关数据。临床试验数据电子采集(Electric Data Capture，EDC)系统适用于药物临床试验、医学随机对照试验和医学队列研究的核心信息化系统，其核心目的是用于记录受试者的信息，形成电子随访表单。

配合参图1，为一个示范的临床试验建库的流程，包括建库、建库测试、临床试验数据核查(DVP)配置、以及临床试验数据核查(DVP)测试。

建库可以是由临床数据管理员(DM)完成，但也可以是单独让DBD(DatabaseDesigner，建库员，也可以说是数据库编程人员)来做数据库设计。建库人员通过分析临床试验方案，进行CRF建库方案的设计，进而进行建库(electronic Case Report Form，eCRF)。建库测试中，CRF测试人员可以针对建库方案进行分析，从而撰写建库测试方案，在测试完成后还可以出具相应的建库测试报告。随后的临床试验数据核查配置中，建库人员进一步分析临床实验方案，进行临床实验数据核查方案设计和配置。最后，CRF测试人员通过分析临床实验数据核查方案，进行临床试验数据核查测试方案的设计，完成临床试验数据核查测试和测试报告。

在此过程中，可以看出测试人员需要在分析理解建库人员设计的临床试验数据核查方案的基础上，撰写出测试方案并进行测试。测试人员的负荷较大导致测试效率较难提升，并且，人工撰写的测试案例可能本身也不正确，可能无法真实客观地反应数据核查结果。因此，本申请期望通过改变以上的临床试验建库过程中的数据核查逻辑，达到简化数据核查流程，且能够更少依赖于人工进行测试的目的。

本申请可以应用于EDC系统的建库场景。具体地，请参阅图2，EDC系统可以依托于由终端设备和服务器组成的硬件环境。服务器以及终端设备可以为彼此独立的设备，也可以是集成于同一个系统内，此处不做限定。

配合参照图3，介绍本申请临床实验数据核查方法的一实施例。在本实施例中，该方法包括：

S11、响应于用户的测试请求，基于预配置的数据核查逻辑，生成测试案例。

用户可以是在建库和临床试验数据核查配置完成后，选择一个需要测试的目标案例发起测试请求。测试案例包括至少一个数据点和该至少一个数据点对应的期望结果。

具体地，数据点可以包括临床实验数据和临床试验数据在数据库中的存储结构，数据核查逻辑可以是基于用户根据临床试验业务规则制定的数据核查计划进行配置，数据核查逻辑包括输入值、输出值，以及输入值到输出值之间的映射关系。可以看出，数据核查逻辑生成测试案例时，可以是将数据点作为输入值，并通过映射关系将数据点映射到相应的“对象”，这里的“对象”也即与该数据点对应的期望结果。

输入值可以选自受试者的临床试验数据，临床试验数据可以是指在临床试验的过程中记录的数据或者电子健康档案(Electronic Health Records，EHR)。电子健康档案可以是指受试者在健康相关活动中直接形成的具有保存备查价值的电子化历史记录，可以包括医院电子化信息系统产生的有关生命体征、病史、诊断、物理检查、实验室检验、药物治疗等信息。

临床试验数据以电子病例报告表为载体存储在数据库中，电子病例报告表相当于临床试验数据的存储结构对应的模板文件。电子病例报告表的数据结构符合目标协议标准，目标协议标准是指临床试验领域制定的提交、收集、交换以及存档临床数据的协议标准。例如，目标协议标准可以是临床数据交换标准协会(Clinical Data InterchangeStandards Consortium，CDISC)标准。CDISC是一个开放的、包括各种学科的非盈利性机构，协会致力于开发行业标准，为医学和生物制药产品的开发提供临床试验数据和元数据的取得、交换、提交以及存档的电子手段。又如，目标协议标准可以是临床数据采集整合模型(Clinical Data Acquisition StandardsHarmonization，CDASH)，其描述了基础数据采集域和CRF标准问题文字描述的变量、实施指南和最佳操作方案的融汇，提供规范标准。再如，目标协议标准可以是研究数据列表模型(Study Data Tabulation Model，SDTM)。

需要说明的是，对于临床试验研究而言，数据核查可以分为系统核查和人工核查。系统核查可以依赖建库时的配置，如果数据录入有问题可以及时发出质疑，例如日期要求是yyyy-mm-dd格式，格式不对的话，系统会出质疑。人工核查可以检查系统难以实现的数据，比如受试者病史和合并用药之间的关系。但以上示范的系统核查和人工核查并非是限制性地，例如，可以通过合适的规则配置，将一些人工核查的内容转换为系统核查，又或者，人工核查也可以面向一些可以系统核查的内容。本申请所提供的临床试验数据核查方法可以根据不同的场景和方案设计，应用于临床试验研究中合适类型的数据核查。

以下示范性地给出一个测试案例。

测试案例1

数据点1：

访视：筛选期；

表单：人口学资料；

字段：年龄；

值：16；

数据点2：

访视：筛选期；

表单：入选标准；

字段：入选标准第一条；

值：“是”；

期望结果：数据点2上生成质疑，质疑内容：“年龄不在18-75区间内，5请确认。”；

质疑分类：系统至中心。

本实施例中，期望结果包括对测试案例中至少一个数据点的质疑。这里的质疑可以是数据存在缺失、不完整、不合理、不一致等，或者对数据存在

疑虑时发出质疑，解决疑虑。类似地，这里的质疑可以是在EDC系统上直接0发出，也叫作系统数据质疑，在一些场景中，还可以配合由DM、CRA、医

学人员等发出人工数据质疑，在此不再赘述。

S12、基于所述测试案例与数据核查方案的比对结果，确定所述数据核查逻辑的预配置是否符合数据核查方案。

测试案例与数据核查方案的比对可以是人工比对或者系统比对，如果测5试案例与数据核查方案的比对结果一致，则说明数据核查逻辑的预配置可能符合数据核查方案；反之，如果测试案例与数据核查方案的比对结果不一致，则说明数据核查逻辑的预配置可能不符合数据核查方案。

一实施例中，在测试案例与数据核查方案的比对结果一致时，可以先基

于目标协议标准和该至少一条测试案例的数据点生成受试者文件。目标协议0标准包括存储结构对应的模板文件。这种情况下，系统生成至少一条测试案例后，可以先确定与每条测试案例的存储结构匹配的模板文件，例如，采用文本匹配算法实现；然后，利用临床试验数据填充模板文件，得到受试者文件。

随后，再基于受试者文件运行预配置的数据核查逻辑，以生成测试报告。5测试报告包括与测试案例对应的输出结果和期望结果。在测试案例与数据核查方案的比对结果一致时，可以不将数据核查逻辑的预配置不符合数据核查方案的可能排除在外，而是通过生成测试报告，形成最终的数据核查结论。

测试报告中，在输出结果和期望结果不匹配时，可以在其中突出显示输出结果和/或期望结果。输出结果和期望结果的不匹配，意味着该条测试案例对应的核查逻辑需要调整。这种情况下，通过突出显示的方式，可以便于用户快速找到需要调整的核查逻辑。

以测试案例2为例。

测试案例2

数据点1：

访视：筛选期；

表单：人口学资料；

字段：年龄；

值：16；

数据点2：

访视：筛选期；

表单：人口学资料；

字段：年龄；

值：83；

数据点3：

访视：筛选期；

表单：人口学资料；

字段：年龄；

值：50；

数据点4：

访视：筛选期；

表单：入选标准；

字段：入选标准第一条；

值：“是”；

期望结果：数据点4上生成质疑，质疑内容：“数据点1和数据点2的年龄不在18-75区间内，请确认。”；

质疑分类：系统至中心。

如果比对数据核查方案发现，数据核查方案中对于年龄的入选标准为“18-75”，说明测试案例2与数据核查方案一致，可以直接以该测试案例生成测试报告。

一实施例中，在测试案例与数据核查方案的比对结果不一致时，可以选择不生成测试报告，概因为此时预配置的数据核查逻辑可能存在错误，使得测试报告的效用性降低。用户可以基于数据核查方案对数据核查逻辑配置进行检查，并修正或者重新设置数据核查逻辑。

还是以测试案例2为例，如果对比数据核查方案发现，数据核查方案中对于年龄的入选标准为“16-75”，说明测试案例2与数据核查方案不一致。按照数据核查方案，测试案例2应当对应的期望结果是：“数据点4上生成质疑，质疑内容：“数据点2的年龄不在16-75区间内，请确认。”，与测试案例2中生成的期望结果不一致。

在修正或者重新设置数据核查逻辑后，可以基于更新后的数据核查逻辑，生成与目标案例对应的更新测试案例。更新测试案例的生成可以是依赖于用户的新的测试请求，又或者由系统在检测到数据核查逻辑配置被修正或者重新设置后自动生成，本申请对此不做限制。

参图4，介绍本申请临床试验数据核查装置的一实施例。在本实施例中，该时间点表单的生成装置包括生成模块和确定模块。

生成模块用于响应于用户的测试请求，基于预配置的数据核查逻辑，生成测试案例，其中，所述测试案例包括至少一个数据点和所述至少一个数据点对应的期望结果；确定模块用于基于所述测试案例与数据核查方案的比对结果，确定所述数据核查逻辑的预配置是否符合数据核查方案。

一实施例中，确定模块还用于在所述测试案例与数据核查方案的比对结果一致时，基于目标协议标准和所述至少一条测试案例的数据点生成受试者文件；基于所述受试者文件运行预配置的数据核查逻辑，以生成测试报告，其中，所述测试报告包括与所述测试案例对应的输出结果和所述期望结果。

一实施例中，所述数据点包括临床试验数据和所述临床试验数据在数据库中的存储结构，所述目标协议标准包括所述存储结构对应的模板文件；确定模块具体用于确定与所述存储结构匹配的模板文件；利用所述临床试验数据填充所述模板文件，得到所述受试者文件。

一实施例中，确定模块还用于在所述测试报告的输出结果和期望结果不匹配时，在所述测试报告中突出显示所述输出结果和/或期望结果。

一实施例中，所述目标协议标准包括临床数据交换标准协会标准、临床数据采集整合模型、研究数据列表模型中的任一项。

一实施例中，所述用户的测试请求为对目标案例的测试请求；在所述测试案例与数据核查方案的比对结果不一致时，生成模块还用于基于更新后的所述数据核查逻辑，生成与所述目标案例对应的更新测试案例。

一实施例中，所述期望结果包括对测试案例中至少一个数据点的质疑。

如上参照图1到图3，对根据本说明书实施例临床试验数据核查方法进行了描述。在以上对方法实施例的描述中所提及的细节，同样适用于本说明书实施例的临床试验数据核查装置。上面的临床试验数据核查装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。

图5示出了根据本说明书的实施例的电子设备的硬件结构图。如图5所示，电子设备30可以包括至少一个处理器31、存储器32(例如非易失性存储器)、内存33和通信接口34，并且至少一个处理器31、存储器32、内存33和通信接口34经由总线35连接在一起。至少一个处理器31执行在存储器32中存储或编码的至少一个计算机可读指令。

应该理解，在存储器32中存储的计算机可执行指令当执行时使得至少一个处理器31进行本说明书的各个实施例中以上结合图1-图3描述的各种操作和功能。

在本说明书的实施例中，电子设备30可以包括但不限于：个人计算机、服务器计算机、工作站、桌面型计算机、膝上型计算机、笔记本计算机、移动电子设备、智能电话、平板计算机、蜂窝电话、个人数字助理(PDA)、手持装置、消息收发设备、可佩戴电子设备、消费电子设备等等。

根据一个实施例，提供了一种比如机器可读介质的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书的各个实施例中以上结合图1-图4描述的各种操作和功能。具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。

在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本说明书的一部分。

可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。

本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本说明书的保护范围应当由所附的权利要求书来限定。

需要说明的是，上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理客户实现，或者，有些单元可能分由多个物理客户实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所对应的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。