2015, Vol. 50
对制药企业而言,临床试验数据是最有价值的产出之一,是整个临床试验开发过程的核心,是分析、提交、批准及一个产品的标签和上市的基础。如果没有高质量的临床数据,药物的价值可能无法完全实现。GCP要求所报告的试验数据必须是准确且完整的[1, 2]。
国内外的监管当局均根据GCP和药物临床试验质量管理规范对临床数据的真实性和可靠性作出相应的规定。而临床数据管理则是保障数据真实性和完整性的一个重要步骤。
GCP要求质量控制应适用于数据处理的每个阶段,以确保所有的数据是可信的,并已正确处理[1, 2]。通常的临床数据管理工作应该从方案设计开始,决定数据管理的一些基本要求,如数据库系统的选择,数据的采集和清理等。
本文将从行业规范的角度出发,阐述临床数据核查的目的、数据核查计划书的撰写、数据核查的原理和类型以及数据库建库后如何进行充分而全面的测试,为国内从事数据管理工作的同仁提供一些参考。
1 数据核查的目的数据管理的目的是确保临床试验中所得到数据的可靠性、完整性、准确性以及能真实地再现临床试验全过程的基本信息[3, 4]。临床研究往往是一个具有许多步骤的较为复杂的过程。而实际操作中,无论多好的设计,或在数据的采集、录入、传输或处理的过程中如何小心翼翼,都可能有潜在的错误或不一致的发生,这些数据的错误和不一致可以不同形式存在于数据库中,并需要在后期的数据审核和清理的过程中发现并解决。由于临床数据管理员的经验、医药相关知识面的差异,在实际的数据审核的清理过程中对数据问题的发现能力就有不同。虽然试验设计时会对特殊的试验采取不同的处理方法,但数据的操作方法在一定程度上有着共同之处。每一阶段都需一定数据清理和核查的步骤以确保数据的一致性和准确性,所以有必要对数据核查进行规范化。当临床数据管理员进行数据核查清理时,肉眼疲劳、粗心通常是人为错误发生的主要原因。为提高效率和数据质量,应该尽可能利用数据库或临床数据管理系统 (clinical data management system,CDMS) 的自动核查功能。所以对每一个临床试验而言,制订数据核查计划书 (data validation plan,DVP) 是非常有必要的。
2 数据核查计划书撰写 2.1 数据核查计划书撰写准备数据核查计划书通常是由项目的主要数据管理员或被指派者负责撰写。撰写者应该具有丰富的数据核查清理的经验,熟知临床试验中经常发生的数据问题点和每个域的核查特点。一般在试验方案被定稿及CRF草案被审核通过后着手DVP的撰写,并在数据库建立的过程中被审核并更新。DVP被撰写时有些文件必须具备,如试验方案、审核过的CRF草案和DVP的模板等。
2.2 数据核查计划书的内容数据核查计划书通常包含以下内容: ① 标题; ② 版本履历和详细的更新内容; ③ 各个域核查条目数的总结; ④ 编辑核查; ⑤ 离线核查清单。
DVP撰写时主要数据管理者必须很清楚核查什么,为什么要进行数据核查。
2.3 数据核查计划书的审核和批准DVP需要满足不同用户的需求,所以在DVP撰写时应该征求不同用户的意见,并得到他们的审核。如数据核查是由CRO执行,则数据核查计划书必须得到申办方的审批,因为申办方是数据质量的最终责任者[1]。以下是不同用户在审核DVP草案时的审核重点 (表 1)。
|
表 1 数据核查计划书的用户和审核要求 |
每个制药企业或CRO的数据核查计划书可能是不一样的,但一个数据核查计划书必须满足如下最低要求[5]: ① 在编辑核查设计前,方案必须定稿,基本的数据库说明必须完成; ② 基于CRF的参数和方案的有效性和安全性参数来撰写编辑核查; ③ 编辑核查必须涵盖所有主要终点指标和安全性数据; ④ 如果适用,外部数据如中心实验室数据的一致性核查应该包含: 确保所有编辑核查根据标准操作规程 (SOP) 的要求被编程、测试和记录确保所有的数据核查计划书版本齐全,并有正确的版本控制; 给参与数据核查的相关人员提供足够的培训。
如果可能,在核查计划书中应将方案违背的核查作为编辑核查的内容之一。通过对CRF中所采集的数据的核查,检出与方案规定的纳入标准、排除标准、伴随用药、治疗用药或操作的时间窗等相违背的情况。
核查计划书的草案完成后在用户接受测试 (user acceptance testing,UAT) 之前应该得到相关用户和统计编程人员的严格审核。数据库通过测试并启动后,在实际运行的过程中,可能会发现编辑核查的某些不足之处,应该在以后CRF的更新过程中加以调整。如数据核查计划书和系统的编辑核查有更新,则相应的UAT要被执行。
3 数据核查的原理所谓数据核查就是通过对数据质量的检查确保被统计分析前的数据的合理性和试验的依从性。
数据的合理性必须满足数据的完整性 (complete)、准确性 (correct)、一致性 (consistency) 三条规则。
试验的依从性主要是通过核查确认采集的数据是否符合方案 (protocol) 的要求,如纳入/排除标准、伴随用药中是否有禁忌用药、有无超过警示值、终点指标如有效性和安全性的评价时间是否在计划内、有无超窗等。
考虑核查数据的完整性时,应该进一步审核CRF和CRF填写指南,确保方案要求的所有数据被收集。完整性核查可被应用于任何类型的数据。核查数据的完整性时应注意: ① 非所有字符段空白表示数据缺失: 有些字符段不能缺失,任何的遗漏都是一种数据错误,如访问日期、身高和民族等; 有些字符段可有条件缺失 (一致性),如退出试验理由仅被要求于受试者退出时,不良事件未发生时,相应字符段被要求是空的。② 非所有数据录入字符段表示数据完整: 有些字符段有时不要求有数据录入 (一致性),如男性受试者时妊娠试验。
数据的准确性核查时通常会利用数值范围进行检查。范围检查主要用于数字型字段: ① 检查数据的合理性 (非合理的数值): 如身高、体重和血压等。大部分受试者的体重应该都在40～140 kg之间,如果超出这个范围,系统可提醒数据录入者是否数据录入错误,或受试者的极端异常是否反映在相关的安全性数据中; ② 日期和时间,通过程序把无效的日期和时间,如32MAY97和24∶30等拒绝于数据库之外; ③ 方案中提供的年龄、数值型的入排标准、时间窗等。如年龄在18岁和65岁之间; ④ 由申办方或机构提供的数据,如临床检查值的正常范围; ⑤ 有效值的核查可用于分类代码,特定于某数据库或字段,如不良事件的严重程度 = 1/2/3,结果 = O/R/D/U等; “SEX”必须是男或女; ⑥ 有效范围核查: 检查字符段的值是否在有效范围内 (其范围被规定在方案中或由申办方提供)。
数据的一致性核查是参照数据库中其他数据来判断的。数据的不一致可发生在不同数据之间,也可发生在不同的表单之间。如: ① 选项为其他时,应该描述具体内容; ② 不良事件的开始日期和结束日期的前后次序; ③ 不良事件的转归和严重程度的一致性; ④ 临床检查值异常且有临床意义时和相应不良事件的一致性; ⑤ 不良事件的对应措施为伴随用药和相应伴随用药的一致性。
4 数据核查的种类数据核查可分成系统核查、自动核查和手工核查三大类。系统核查通常被定义于电子病例报告表的规范中,因为电子数据采集系统 (electronic data capture,EDC) 的不同可有不同,以Medidata Rave为例,有些字符段是不能空的 (IsRequired),有些不符合格式要求 (NonConformant) 的数据是不能被接受的,如日期规定是YYYYMMDD的格式,那么25JAN2014这种数据格式会被拒绝。其他将来的日期 (future date)、无效的日期也是会被拒绝的。
自动核查是数据库编程员或数据管理员根据核查计划书中有关编辑核查(edit checks) 的定义在系统中编程来实现的。这部分内容可以是基于不同的EDC系统可有不同,主要包括临床数据管理中通用的核查标准和方案特有的核查标准两部分。
手工核查通常定义于数据核查计划书中离线核查列表部分,用于检查自动核查 (edit checks) 难以实现的数据,如文字类的描述、纵向检查 (同一个受试者数据之间的一致性,如疾病史或不良事件与合并用药之间一致性的核查) 和核查数据的趋势,尤其是有效性和安全性数据。还用于核查那些系统自动发现的不一致的数据,需要进一步确认信息。如研究中有ECG的结果是异常且有临床意义,数据管理员需进一步确认是否记录成不良事件,且不良事件发生的日期是否和ECG结果的日期相一致。有时也可以将方案违背的内容放在离线核查列表中,数据管理人员可以通过离线核查列表确认数据库收集数据中存在的方案违背。
离线核查列表部分的内容主要取决于方案要求和EDC系统功能,除了基本的列表核查内容,也会有些各个方案专属的离线核查列表确认。如果EDC系统功能足够强大,人工核查的内容就会相对减少,如果EDC系统功能不能实现,那么人工核查的内容都需要放在离线核查列表中。
数据核查时有单变量和多变量的不同。单变量 核查是利用系统检查一个数据字段,如“SEX”必须是男或女一种,一种“硬”核查被用于那种不被允许的数值,如: 身高 (HEIGHT) 必须大于0; 一种“软”核查被用于不大可能发生的数值即数据的合理性,如男性身高 < 150 cm,虽然也有成年男子身高在150 cm以下或200 cm以上,但比较罕见,通常以数据记录错误为多。多变量核查通过程序检查2个以上数据字段的不一致。如发现收缩压 < 舒张压时,开始多变量核查之前先通过单变量核查。
5 数据库测试EDC系统越来越被临床试验所广泛采用,抛弃耗时费力的纸质CRF已成为了趋势,无论是国外的EDC系统还是国内的EDC系统,都如雨后春笋般活跃在这个领域。EDC具有很多纸质研究所无法代替的优越功能,对于研究中心数据的采集以及数据核查的及时性更是纸质研究所无法比拟的。EDC实现了在线数据采集、报告、质疑解决、随机化以及数据在线核查,大大提高了临床研究的效率[6]。数据管理人员将根据CRF进行EDC数据库的搭建,在首例患者入组 (first patient in,FPI) 之前,EDC应该搭建完成,并经过充分的测试 (technical quality control,TQC和UAT) 后,才能宣布数据库启动。如果没有经过充分的测试,再强大的系统和功能也无法完美地展现,现实中没有经过测试便启动使用最终导致惨重后果而付出巨大代价的例子太多,所以数据库测试也是数据质量保证的重要一环。
5.1 数据库建库的流程临床数据库是什么？可以理解为临床数据库是受试者在临床试验中所产生的数据的电子仓库,这个仓库镶嵌着一系列根据方案制订的数据核查条件,用以针对性地核查进入到这个电子仓库的所有数据。临床数据库有时还需要整合外部数据,如随机化系统、中心实验室数据等,最终临床数据库中的数据将被汇总导出,用于最后统计分析。
研究方案定稿后,数据管理人员根据方案进行CRF的设计,可以直接设计为纸质CRF或eCRF。CRF经过各职责人员审核并经过申办方批准后,数据管理人员开始搭建纸质CRF数据库或EDC数据库,两类数据库都是最终受试者临床数据的接收仓库,但纸质CRF数据库的用户为数据管理员,由数据录入人员将数据独立双录入到数据库中,并且由于国内纸质CRF有时是在最后一例受试者出组才被回收,所以CRF/系统设置测试和核查规则的测试可以分开进行,使得建库时间比较充裕; EDC数据库的用户为数据管理员、数据监查员和中心用户等,测试的范围相比纸质CRF数据库范围扩大,除了功能确认之外,还包括用户接受测试,根据不同的情况,可能还包括第三方数据传输测试等。由于EDC数据库直接面向研究中心用户,所以CRF测试和核查规则测试需同时进行,并在首例受试者入组前完成测试,数据库启动使用。
5.2 数据库测试数据库测试是为确保数据库符合用户 (研究者、研究协调员、数据录入人员、数据管理员) 的需求和数据的真实可靠性。数据库的测试必须是全面而充分的测试,这样才能确保数据库的核查功能达到预期。数据库测试前,必须对所有数据库测试参与人员进行数据核查计划书的培训。以下主要对以EDC为基础的数据库测试进行介绍。
数据库测试过程需要数据库程序员、数据管理员等参与,数据库程序员负责建立数据库,编辑核查的系统编程,在测试过程中提供技术支持并根据测试结果进行程序的修改; 数据管理员通常包括主要数据管理员,主要负责统筹整个测试活动以及文件审核、沟通,其他数据管理员主要负责撰写测试脚本、撰写测试数据、执行测试以及完成相关文件。
5.2.1 测试脚本的撰写测试脚本是完整的测试指南,内容应包括但不局限于以下: 项目信息 (项目编号以及申办方等)、修改履历、测试目的和内容、测试步骤说明、注意事项、期待的结果以及签字页。
一次全面的数据库测试必须涵盖系统功能测试、CRF测试以及数据核查计划测试。系统功能测试的着重点取决于系统本身、时区、质疑前缀、电子签名文本、账号权限设置等; CRF测试主要关注于CRF的可填性、格式、字符长度、布局架构、访视结构以及数据库整合情况等; 数据核查计划测试应该涵盖数据核查计划书中的所有逻辑条件、动态访视设置、自动计算公式设置、邮件通知设置、离线核查工具测试等。
测试脚本应该经过内部审批之后才能正式开始进行数据库测试,如果测试脚本内容变更或所需的文件 (数据核查计划书等) 有版本更新时,测试脚本的版本也必须进行相应的更新,更新后仍需经过内部审批之后才能使用。
5.2.2 测试数据的撰写撰写测试数据应该全面,尽可能地反映临床中所能出现的所有情况,尤其是极端情况。有些测试数据可以直接填写进数据库,即刻测出结果; 有些测试数据需要形成单独的文件,通常是数据核查计划所要求的非测试EDC系统本身的数据,测试人员按照测试数据文件进行测试。
测试数据撰写的原则是应尽可能全面,符合数据库要求和不符合数据库要求的、符合逻辑设定的和不符合逻辑设定的,尤其是临界值的情况都应涵盖在测试数据中。如果涉及到一些多个数据点比较,则应该在测试数据中详细写明每个数据点都应该如何填写,并且每个测试情况应该得到什么结果,有质疑还是没有质疑。以下为测试数据的全面性的举例 (表 2):
|
|
表 2 测试数据举例 |
举例1: 逻辑条件 (范围): “体重范围应在40～140 kg之间”。
测试数据: 39.9 (dirty,Query),40 (clean,No Query),40.1 (clean,No Query),140 (clean,No Query),40.1 (dirty,Query)。
举例2: 逻辑条件 (比较): “血样采血日期 (LBDAT) 应该与访视日期 (VISITDAT) 为同一天”。
举例3: 逻辑条件 (数据缺失): “知情同意书签署日期必须提供”。
测试数据: 留空 (dirty,Query),27-Aug-2015 (clean,No Query)。
5.2.3 测试脚本的执行数据库程序员搭建完数据库并进行逻辑编辑后,通知数据管理员数据库测试环境已经准备就绪。测试人员在执行测试之前,需要完成相关文件和系统的培训。在测试过程中,应完全按照测试脚本的说明和规定进行测试,即只测试脚本中规定的,并不得擅自修改测试脚本,不要随意假想测试要求,只有经过客观的测试才能得到客观的结果。
测试应该留下完整的、可追溯、可重现的测试记录,应如实记录测试人、测试日期、测试账号、测试的受试者编号、访视等信息,精准详细描述测试画面显示和测试结果。任何不同于测试脚本期待结果的测试结果,都属于测试失败,需要对失败的测试进行原因分析。一般情况失败的原因包括两类: 第一类为文件原因,逻辑不符合方案或不完备、测试脚本中的测试执行说明模糊等; 第二类为系统原因,与CRF定义不符、应该出现质疑却没有出现、不应出现质疑时却出现、质疑文本描述与核查计划书不符和数据库的问题则需要由程序员进行更新,文件相关的问题则需要由文件撰写人员进行修改,并由数据管理员进行第二轮测试。如此反复,直至所有测试通过。每一轮的测试都应该有详尽的测试记录,作为项目文件进行保存。
5.3 离线核查列表测试离线核查列表属于数据核查计划书的一部分,一般情况该部分测试会包含在数据核查计划书测试脚本中。离线核查列表的测试不同于EDC数据库的测试,主要是检查离线列表的编程是否正确,数据输出是否符合预期离线核查列表的设置,输出的数据是否与EDC数据库一致。
数据管理员按照离线核查列表的逻辑设置,直接将测试数据填写到EDC数据库中,测试数据也应该保持全面、有代表性、涵盖临界值以及极端情况的原则,并记录测试的受试者编号。测试数据填写完成后,将测试受试者编号提供给SAS程序员,由程序 员进行编程、输出工作。
数据管理员对输出的离线列表进行核查确认,核查的要点包括: 离线列表输出的数据点是否为DVP中规定的数据点,有无增加或漏失; 离线列表输出的数据是否与填写到EDC数据库中的数据完全一致,有无数据输出错误; 离线列表是否按照DVP中设定的逻辑条件输出的; 离线列表的布局、数据的排序是否便于数据管理员核查; 离线列表的标题是否与DVP一致等。数据管理员应该记录测试意见,形成完整的测试记录,其要点与数据库测试相同。
6 结语数据管理的目的是确保临床试验中所得到数据的可靠性、完整性、准确性以及能真实地再现临床试验全过程的基本信息。数据核查就是通过对数据质量的检查确保被统计分析前的数据的合理性和试验的依从性。数据核查必须撰写详尽的计划,并经审核批准,然后编写数据库编辑核查或SAS离线核查程序。为确保数据库和离线核查列表程序符合用户的需求,数据库和离线核查列表程序必须经过完整而全面、反复多次的测试,直至所有测试通过才能正式启动。数据库和离线核查列表程序测试后应该留下完整的、可追溯、可重现的测试记录。
| [1] | International Conference on Harmonisation. Guidance for Industry, E6 Good Clinical Practice: Consolidated Guidelines [S]. 1996. |
| [2] | China Food and Drug Administration. Good Clinical Practice (药品临床试验质量管理规范) [S]. 2003. |
| [3] | Rondel RK, Varley SA. Clinical Data Management [M]. 2nd ed. Webb, John Wiley & Sons, Ltd, 2000. |
| [4] | Center of Drug Evaluation, CFDA. Technical Guidelines for Data Management in Clinical Trials (临床试验数据管理 工作技术指南) [S]. 2012.http://www.cde.org.cn/news.do? method=largeInfo&id=312673. |
| [5] | Society for Clinical Data Management. Good Clinical Data Management Practices (GCDMP) [S]. 2007. |
| [6] | Emam KE, Jonker E, Sampson M, et al. The use of electronic data capture tools in clinical trials: web-survey of 259 Canadian trials [J]. J Med Internet Res, 2009, 11: e8. |