流程说明
数据库修订范围：任何EDC建库端的变更均属于数据库修订，包括但不限于访视结构、eCRF页面、eCRF字段及其属性、逻辑核查程序、项目设置的变更。仅方案版本信息的变更、系统功能的升级不属于数据库修订范围。
项目数据经理（TDM）根据修订版方案或其他需要变更的内容撰写《数据库修订计划》，应充分评估风险及数据库修订后的操作，尤其是对于删除字段、访视等类型的修订，如系统中已有数据，应考虑EDC修订前后旧数据的处理问题。数据库常用修订方案可参考 常用修订方案.pdf文档。《数据库修订计划》需要数据管理经理、医学经理、统计师、项目经理、编程经理、EDM（按需）、随机经理（按需）审阅。
注：（1）关于《数据库修订计划》的审批人员，由项目数据经理（TDM）自行斟酌调整。如项目涉及外包，由TDM评估是否需要外包人员参与审核。
（2）对于数据库变更控制编号中的“改库次数”，老项目使用新SOP时建议在既往改库的基础上叠加。
（3）对于HRTAU 4.1.8项目，如需在改库时增加外院范围录入相关功能，详见eCRF设计与搭建相关描述。
（4）撰写《数据库修订计划》的Tips:
- 如修订原因为方案修订，需结合track版方案及方案修订说明，明确方案前后版本的修订内容，全面考虑对数据库的影响，同时应包含涉及的访视/表单激活条件；
- EC修订：修订既往设置不合理的EC，包括但不限于：质疑逻辑不严谨或未导致数据更新，是否需调整核查逻辑或补充前提条件；DM手工高频质疑且导致数据更新，是否可补充为在线EC；
- 日常数据管理过程中，及时记录待下次改库修订内容，待正式改库时评估是否需修订。
① eCRF修订：根据方案或项目组需求更新eCRF，完成eCRF构建与审阅，具体审阅流程见eCRF搭建。
注：如仅新增访视，不涉及Unique eCRF版本更新，仅需更新Casebook eCRF和数据库定义的版本日期，版本号不变。更新的Casebook eCRF和数据库定义需补充上传至eCRF设计与搭建章节。
使用Rave及HRTAU 4.0的项目，若eCRF修订过程中需要新增变量或表单，需参照HRTAU eCRF Library手动新增变量和表单。
使用HRTAU 4.1的项目可直接从eCRF Library复制新增表单或参照HRTAU eCRF Library手动新增变量。
培训视频：RAVE系统新增表单和字段
HRTAU 4.1 新增表单-eCRF library.mp4
②eCRF填写指南修订：根据方案或最新eCRF或项目组需求更新eCRF填写指南，完成审阅，具体审阅流程见eCRF填写指南。
③DMRP修订：根据方案或最新eCRF或项目组需求更新DMRP，完成审阅，具体审阅流程见数据审核计划(DMRP)。
④DVS和EC修订：根据方案或最新eCRF或最新DMRP更新DVS，并进行Edit check的修改和测试，完成审阅，具体审阅流程见数据核查说明(DVS)、EC编程与测试。
⑤项目设置修订：根据方案或最新eCRF或项目组需求更新项目EDC通用功能，具体设置流程见eCRF搭建。
同行发布和跨行发布的使用场景如下：
|
使用场景 |
同行发布 |
跨行发布 |
|
方案版本变更，eCRF版本不变 |
√ |
√ |
|
方案版本变更，eCRF版本变更，但变动较小，如：修改字段描述、编码描述、失效字段、隐藏字段 |
√ |
√ |
|
eCRF版本不变，如：核查规则变更、自动取值变更 |
√ |
√ |
|
eCRF版本变更，且变动较大 |
|
√ |
|
同时存在两个eCRF版本 |
|
√ |
注：
- 对于上述使用场景1-3，同行发布和跨行发布均适用，可自行选择发布方式。
- 当跨行改库发布时若出现问题可以找百奥知技术支持退回发布前的版本。若进行同行改库发布，则改动不可逆。
- 仅方案修订时，如果选择跨行发布，需要联系技术支持修改功能参数【eCRF版本强制变更】，同时DM在建库端eCRF版本和DVP版本处选择既往eCRF版本修改对应的方案版本号，不做新增操作（eCRF版本新增不能重复添加）。
- 数据库再发布前需完成以下工作，根据实际修订情况而定：
|
工作内容 |
修订流程 |
CDTMS存放位置 |
|
《数据库修订计划》定稿并签字 |
NA |
设计阶段 - 数据库修订计划 |
|
eCRF（Unique eCRF, annotated eCRF and casebook）已定稿，《eCRF审批表》已签字（按需） |
链接 |
设计阶段 - eCRF设计与搭建 |
|
数据库定义报告 |
NA |
设计阶段 – eCRF上线审批 |
|
eCRF修订记录（按需） |
NA |
设计阶段 - eCRF设计与搭建 |
|
UAT完成，UAT报告已签字(包含DM内部和项目组对于EDC的界面UAT，和RTSM) |
链接 |
设计阶段 –UAT |
|
eCRF填写指南已定稿并签字（按需） |
链接 |
设计阶段 – eCRF填写指南 |
|
DMRP已定稿并签字（按需） |
链接 |
设计阶段 – 数据审核计划(DMRP) |
|
DVS已定稿并签字（按需） |
链接 |
设计阶段 – 数据核查说明(DVS) |
|
逻辑核查测试报告完成并签字（按需） |
链接 |
设计阶段 – EC编程与测试 |
|
《外部数据传输协议》更新（按需） |
NA |
设计阶段-数据传输协议（EDM负责上传） |
|
《医学编码计划》更新（按需） |
NA |
设计阶段 – 医学编码计划（医学编码员负责上传） |
|
改库后EDC培训材料（按需） |
NA |
人员与沟通 – 用户培训 |
|
实验室正常值范围模板已更新（仅适用于DM负责维护参考值范围项目）（按需） |
NA |
NA |
|
数据库质控完成，《数据管理质控报告》已签字
|
链接 |
设计阶段 – 数据库上线质控 |
|
《EDC上线清单及上线审批表》已签字 |
链接 |
设计阶段– eCRF上线审批 |
- 数据库再发布后需及时完成以下工作：
|
工作内容 |
修订流程 |
CDTMS存放位置 |
|
《数据库修订报告》已签字 |
链接 |
设计阶段 -数据库修订报告 |
|
Push到PRO的截图 |
NA |
设计阶段 – eCRF上线与备份计划 |
|
DMP更新（数据库修订再上线后五个工作日内定稿） |
数据管理文件 – 数据管理计划 |
除第一次EDC上线需进行完整的测试，之后任何修订，至少需保证修改的部分及可能会影响的部分进行充分的测试。
数据库修订完成后，TDM应将定稿的eCRF和数据库定义报告及时传输给编程同事。
数据库修订质控流程与上线质控流程类似，详情见上线质控流程。
数据库修订再上线前的准备工作完成后，需和项目组协调再上线的时间，如涉及方案变更，需在组长单位方案伦理通过后再执行数据库发布；如不涉及方案变更，上线前工作完成即可执行发布。执行正式migration前，需完成数据库上线审批表签字。
5.1 RAVE
① 在正式执行migration前3天左右，TDM发邮件给Rave SME 公邮（ravesme@hengrui.com）并抄送尔康（erkang.zhou@hengrui.com），申请Mig环境和admin权限。待Mig环境Admin权限开通后，TDM需在Mig环境添加Prod环境的site，并给DM开通Mig环境的Rave EDC DM/TDM Role。
注：每一次修订，如涉及eCRF修订，需申请一个新的mig环境。在Mig环境添加Prod环境的site的建议原则：1.数据较多、质疑较多的中心 2.尽量涵盖所有的受试者状态 3.中心有能体现此次修订内容的受试者。
如既往进行过数据冻结或锁定，且此次修订内容包含已冻结或锁定的数据，需勾选Architect-项目代码-Studies Environment Setup-Modify Locked DataPoints（Prod环境和本次修订所用的mig环境）。
② DM进行Pre-Migration/Dry-run Migration，导出相关比对报告（报告名称详见第⑤步表格），查看Pre-Migration结果。
注：Pre-Migration过程中需要解决所有的问题，确保pre-migration后达到预期效果且没有数据被hard-delete。
培训视频： RAVE系统Pre-migration操作.mp4
③ TDM邮件告知项目组migration时间，并提醒PM通知中心人员在这段时间内不要进EDC进行任何操作。因Medidata Rave同一个URL上同一时间只能有1个项目改库，TDM还需提前在部门企业微信群通知migration时间，以免与其他项目改库时间冲突。
④ DM提前至少三个小时下载Prod环境的SAS数据集和query detail，收到SAS数据集后再发布新版本到Prod环境，并把发布成功的界面截图存档（截图需保留电脑桌面的日期时间）。正式migration完成后邮件给CDSC Rave SME公邮（ravesme@hengrui.com）申请刷新clinical view。
培训视频： RAVE系统Migration操作.mp4
⑤ 正式migration完成后就可以下载报告（详见下方表格），收到clinical view重置完成的邮件后，下载数据集（详见下方表格），SAS数据集可使用SAS Server上的数据集比对程序（Clinprojects(W:)\Projects\GRP_CDSC_ALL\项目编号\pgm_out\运行导出_数据比对）进行比对，完成Migration结果比对。
数据集比对程序使用方法：将新数据集放在data/raw下，旧数据集放在data/edc下，运行程序，输出结果在output下查看。
|
Document name |
Pre-Migration |
Migration |
|
Difference report |
√ |
√ |
|
Subject compare reports |
√ |
NA |
|
Migration Audit trial report |
√ |
√ |
|
Subject CRF version report |
√ |
√ |
|
Stream-Query detail Stream-Query Summary report |
√（包括Pre-mig前PRO环境和Pre-mig后Mig环境中的质疑) |
√(包括迁移前PRO环境和迁移后PRO环境中的质疑) |
|
SAS数据集 |
NA |
√（包括迁移前PRO环境和迁移后PRO环境中的数据集） |
|
SAS dataset compare reports |
NA |
√ |
⑥一般来说，比对结果不会有问题，所有的问题理论上都应该在Pre-migration中解决掉，所以Pre-migration过程中仔细比对相关报告，确保正式migration的准确性。若比对结果有问题，需权衡migration失误造成的影响有多大，如果只是 label修改错误或添加了不必要的表单，可以再进行一次migration来进行修正；如果是某些数据被彻底删除了，只能尝试联系Medidata恢复数据集（Medidata没有承诺可以做版本的roll back）。若migration后确认比对无误后，邮件告知项目组改库完成，并导出邮件作为上线通知，存档CDTMS-设计阶段- eCRF上线与备份计划。如仅涉及EC修订，需执行Quick Publish操作。
⑦在点击Quick Publish前，可先点击Amendment Manager，创建计划但不执行，用于获取引用的Quick Publish版本与当前版本的difference Report。
Tips:
- 为避免系统出错，一次Quick Publish的EC修订数据最好小于30条。
- 一定不要把改库后的新版本发布到Prod 环境。
- Quick Publish没有办法做Dry-run，点击Publish前需要仔细检查。
- Quick Publish时，会忽略Bypass During Migration，直接运行EC，如果想要不运行EC，那么只能做Migration。
- 如果想要重新运行CF，那么只需要运行这条CF关联的EC即可；如果想要删除掉一个CF，那么需要inactivate这条CF关联的EC。
- 若需要更新EC的逻辑，建议失活当前EC并新建一条新的EC；若仅需更新EC的message，可以直接在当前EC上进行修改。
- 5.2 HRTAU EDC
① eCRF更新发布到UAT环境并完成UAT，勾选通过UAT的eCRF版本与Prod环境的eCRF版进行配置比对, 并确认无计划外的修改发生。若比对结果无误，可进行正式环境的数据库修订。
培训视频： HRTAU EDC UAT和PRO配置比对.mp4
HRTAU EDC 4.0&4.1 数据集及报告导出.mp4
② TDM在建库端的临床研究-项目设置-项目维护中设置项目维护计划，在计划时间前勾选项目维护计划点击“通知”开始系统维护，并邮件告知项目migration时间，提醒PM通知中心人员在这段时间内不要进EDC进行任何操作。 项目维护计划示例：
培训视频： HRTAU设置项目维护计划.mp4
③正式数据库版本升级的前一天邮件给技术支持（hrtau.support@hengrui.com），技术支持会在正式库维护开始后备份数据集（邮件中需要附上EDC的登陆网址，项目名称以及开始维护时间）。
④ DM在开始维护后下载升级前Pro环境的SAS数据集和报告(Excel数据集和质疑报告)。
⑤ 技术支持和DM备份完成后，对生产环境进行升级，升级后勾选UAT的eCRF版本与Prod环境的eCRF版进行配置比对，确保发布到Prod环境的eCRF版本与UAT环境一致。根据升级需求，对适当的已存在受试者进行数据库版本变更（注：同行发布，系统会直接覆盖上一个数据库版本，无需进行数据库版本变更；新增一行发布，需要关联新的数据库版本）。
受试者CRF版本升级操作如下：当存在多个数据库版本，CRC选择非最新eCRF版本时，需将部分非最新数据库版本的受试者变更至最新数据库版本，可通过DM角色在PRO环境的数据管理/数据库版本变更实现。此操作无需执行数据库修订流程，且无需数据库备份和数据集比对。
培训视频： HRTAU数据库版本更新.mp4
⑥ PRO升级完后，下载修订后的SAS数据集及报告（Excel数据集和质疑报告），完成SAS数据集和质疑报告的对比，SAS数据集（注：4.0系统下载UTF-8格式的SAS数据集；4.1系统下载TXT的UTF-8格式的SAS数据集）使用SAS Server上的数据集比对程序（Clinprojects(W:)\Projects\GRP_CDSC_ALL\项目编号\pgm_out\运行导出_数据比对）完成比对，质疑报告使用工作站上的excel比对(D:\hr_tool\excel)程序进行比对。
数据集比对程序使用方法：将新数据集放在data/raw下，旧数据集放在data/edc下，运行程序，输出结果在output下查看。
⑦ 比对完成后，若比对结果有问题，需要分析其原因，若为系统原因，需要联系技术支持（hrtau.support@hengrui.com）说明具体情况；若为个人原因，需要邮件给技术支持并抄送颜总（charles.yan@hengrui.com），申请数据集恢复。若比对结果确认无误后, 邮件通知项目组数据库升级完成，并导出邮件作为上线通知，存档CDTMS-设计阶段- eCRF上线与备份计划。
6.数据库修订报告
数据库发布完成后，需进行《数据库修订报告》撰写及签字，以对本次数据库修订变更内容及相关系统文件进行总结，包括：
①修订前后数据管理文件版本更新，其中用户验收测试报告包括DM UAT报告及Team UAT报告；
②修订前后数据集比对是否一致，
- 如因数据库修订导致的数据不一致，需评估是否需要采取修正措施。
- 执行数据库修订期间请注意通知项目组不要进入EDC录入数据，导出数据库修订前后数据集时间尽量不要间隔太久，防止有太多因录入原因导致的数据不一致情况。对于因录入原因导致的不一致情况，在数据库修订报告中可汇总一条统一列出。
③根据《数据库修订计划》、实际执行情况等列出本次数据库修订实际修订的全部内容，修订内容描述可尽量清晰简洁。如增加访视，可统一描述为按照方案访视流程，添加XXX的访视及对应表单。
7.受试者迁移与受试者中心变更
7.1 受试者迁移（Rave）/受试者中心变更(HRTAU)的适用情况
项目进行过程中，会因为某些原因需要将受试者迁移到新的中心，具体可见下方举例:
（1）在不可抗力的情况下，例如：疫情，导致原始中心关闭，需要将原始中心中的受试者迁移到新中心下，继续接下来的临床试验。
（2）在EDC中，原始中心的中心名称错误，且与CTA沟通后无法直接在系统中对原始中心名称进行修改，需添加正确的中心，将原始中心的受试者迁移到正确的中心中。
（3）受试者的主观因素，例如：居住地变更，更希望在新中心下继续临床试验。
注：受试者迁移和受试者中心变更仅是EDC的特殊功能，不算做数据库修订。
7.2 受试者迁移信息确认
TDM需与项目组沟通确认受试者迁移相关信息，包括需要迁移的受试者编号、新旧中心编号，rave系统还需要确认迁移的具体方法等，达成一致后形成正式的邮件。
Rave系统存在两种受试者迁移方法，分别如下：
① Share Subject：被迁移的受试者会同时存在于两家中心，且两家中心下的人员均可以对数据进行操作，且Share Subject操作可逆，可随时取消Share Subject。8.1（1）和8.1（3）情况下建议采用Share Subject的操作。
② Reassign Subject：被迁移的受试者只会存在于新中心，新中心的人员才可以对数据进行操作。8.1（2）情况下建议采用Reassign Subject的操作。
HRTAU系统（适用于4.0、4.1及之后的版本），DM可以对受试者进行中心变更操作，使受试者在中心之间进行变更，之前的项目可参考使用。8.1所述的3种情况在HRTAU系统种均可使用中心变更操作。若项目涉及随机，已随机的受试者在进行中心变更操作后，不会影响随机内容；未随机的受试者如需变更中心，建议不使用受试者中心变更操作，受试者直接去新的中心重新进行筛选后随机。
两种系统在进行受试者迁移/受试者中心变更的过程中，均不会改变受试者代码。在受试者迁移/受试者中心变更过程中，需要考虑与EDC对接的其他系统数据是否会有影响，包括但不限于：随机系统、实验室系统、CTMS系统、eTMF系统。
7.3受试者迁移/中心变更具体操作方法
7.3.1 Rave系统
A. Share Subject
① 项目确定需要进行受试者迁移后，TDM需要以cloud admin权限在UAT环境中添加原始中心与新中心用于测试。
② 发送邮件给Rave SME公邮（ravesme@hengrui.com）通知Client Admin在系统后台对原始中心与新中心进行关联。
③ DM在 UAT 环境中进行 Share Subject 的测试。若项目涉及到其他系统的对接，需通知系统对应的负责人及时到UAT下测试，测试无误后，数据管理员在 Prod 环境下进行Share Subject的操作。
④ 若项目后期被迁移的受试者需要回到原始中心继续试验，也可以取消Share Subject，该受试者将仅存在于原始中心。
培训视频： RAVE系统Share Subject操作.mp4
Tips:
- Share Subject操作后，被迁移受试者的实验室正常值范围的更新（新提供/修正/更新）只能在原始中心进行更新，无法在新中心实现实验室正常值范围的更新。（DM核查的时候需注意，原始中心的其他受试者不可选择已迁移受试者在新中心的实验室正常值范围）。
- Share Subject操作对EDC中已产生的数据不会任何的影响，包括Audit trail和与其他系统对接的数据等。
- Share Subject操作后，若项目由随机系统创建受试者或受试者由CRC手动录入，则对后续添加的受试者编号没有任何的影响；若受试者由普通CRC角色(非 IxRS - CRC)创建，且受试者代码是程序自动生成的，则需要联系CF公邮（Rave-CF@hengrui.com）修改“自动生成受试者代码”的程序。
- Share Subject操作本质上并没有对受试者进行真正的迁移，所以对接的系统并不会受到影响。
- Share Subject操作后，迁移受试者会在两家中心同时存在，即两家中心都可以对该 Subject 进行清理；若确认原始中心不再参与接下来的试验，需要在迁移前将所有数据清理干净并冻结。
B. Reassign Subject
项目确定需要进行受试者迁移后，TDM发送邮件（邮件内容至少需包含需要迁移的受试者编号，新中心编号）给Rave SME公邮（ravesme@hengrui.com）通知系统管理员在 Site Administration 中进行 Reassign Subject的操作，操作完成之后，系统管理员需回复邮件通知 DM 到 EDC 中确认，迁移受试者只存在于新中心下。
Tips:
- Reassign Subject操作并不会将原始中心的实验室正常值范围一起迁移过来，在Reassign Subject完成后后，需要在新中心中重新录入实验室正常值范围。（已产生数据无影响，后续如需使用原参考值才需录入）
- Reassign Subject操作对EDC中已产生的数据不会任何的影响，包括Audit trail和与其他系统对接的数据等。
- Reassign Subject操作后，若项目由随机系统创建受试者或受试者由CRC手动录入，则对后续添加的受试者编号没有任何的影响；若项目由普通CRC角色（非 IxRS – CRC）创建受试者，则需要在申请reassign前联系项目的CF编写人员修改“自动生成受试者代码”的程序，并通过Quick Publish 应用到生产环境 。
- 若项目上对接的随机发药系统为 Medidata 自身的随机系统，那么对于 reassign 后的受试者，需要在EDC中重新填写随机表单，将最新的数据同步到RTSM中，之后才可以从该中心发药 。若项目对接的随机发药系统为外部随机系统，例如：IRTON 等，在 reassign 之后不需要任何的操作。
- Reassign 之后的 subject只会存在于一家中心，所以不影响数据清理。
7.3.2 HRTAU系统
受试者中心变更
-
- 检查项空白CRF：激活过的访视中不能留有空白 CRF 页，如确实无数据，应设置未采集或未发生。
- 检查项签字：已有数据的CRF页中PI须完成签字。
- 检查项冻结：已有数据的 CRF页中DM须完成数据冻结（冻结又包括数据核查打勾完成且无未关闭质疑等要求）。
- DM进入中心管理-受试者中心变更界面，点击右上角“查询”按钮，弹出查询条件筛选框。
- 根据目标受试者信息录入查询条件，点击“搜索”按钮，弹出符合筛选条件的受试者列表。
- 点击“操作”按钮，弹出受试者 CRF 数据检测结果信息，判断当前受试者是否可以变更中心。
- 检查项全部OK后，点击“变更”按钮，弹出中心切换设置框。
- 选中目标切换中心及研究者信息，点击 确定 按钮，受试者中心变更成功。
培训视频： HRTAU系统受试者中心变更.mp4
Tips:
- 受试者变更时，两个中心关联的数据库版本须保持一致。
b. 查询规则：中心编号（单选）、研究者（模糊查询）、受试者代码（模糊查询）、 受试者状态（单选）、 e CRF 版本号（单选），支持多条件组合查询。
数据库修订计划
CDTMS填写要求
- 请简要描述本次修订的原因，并上传相关文件。
- 修订原因：概述本次修订内容，如根据更新后方案修订给药记录、PK采血模块等。
- 修订计划：修订计划表。
- 开始日期：修订计划发出的日期。
- 数据库变更控制编号：用于记录修订次数、并且可以追溯同一次修订下的具体工作内容。
- 数据库修订计划是数据库变更的源头，该表单下填写的“数据库变更控制编号”，可以关联给相应节点供选（如eCRF设计、DMRP、DVS、CCG等）。
数据库修订报告
CDTMS填写要求
- 修订报告：项目组签字确认的数据库修订报告。数据库修订产生的数据集比对报告，系统文件（如HRTAU系统的配置比对报告、RAVE系统的Amendment Report等），也需归档在此处。
- 数据库比对报告说明：改库后的生产环境与上一版生产环境的数据库比对报告。若只涉及EC修订，Rave系统：上传引用的Quick Publish版本与当前版本的difference Report（应符合修改内容）；HRTAU系统：若同行发布，上传 UAT和改库前PRO的比对报告（应符合修改内容），改库后PRO与UAT报告（需完全一致）；跨行发布，上传改库前后PRO比对报告（应符合修改内容）。
- 【数据库修订报告】填写后，每轮数据库修订下的具体工作可统一在该轮【数据库变更控制】树下查看。