研究中心暂停入组或关闭时，随访工具不能把该中心下的全部未完成任务一起停掉。验收重点是区分“不能新增参与者”“中心不再执行某类工作”和“既有参与者仍有后续安排”三种状态，并确保责任迁移后任务不丢失、不重复、不过度开放权限。正式处置必须依据研究方案、伦理要求和本机构流程。
先把三类状态拆开测试
准备虚构的开放中心、暂停入组中心和关闭中心，每个中心放入未到期、窗口内、已超窗、待判定和已结束的参与者。分别改变中心状态，观察系统是否只影响预期动作。中心暂停入组后应禁止新入组，但不应自动取消已有访视。
个体结束不等于中心结束
参与者完成、退出、失访或撤回授权都有不同后果；中心关闭是组织层状态。工具若用一个“停用”开关处理所有情况，很容易误发提醒、丢失任务或继续暴露数据。
迁移前生成影响范围
系统应列出将迁移的任务数量、访视类型、时间窗、原责任人和目标队列，并明确排除项。用户可抽样核对后再执行。不能只显示“迁移成功”，却没有迁移前后的对账清单。
目标责任必须真实可用
测试目标人员无权限、已离岗、队列不存在和容量受限等情况。校验失败时应阻止相关任务迁移或标为明确失败，不能静默分配给默认管理员，也不能把责任字段留空。
重复执行不能制造双份任务
使用同一批次标识连续提交两次迁移，第二次应返回已处理结果，而不是再次创建访视、提醒和消息。网络超时后先查询批次状态，再决定是否重试。幂等验收要覆盖页面按钮、后台任务和接口。
部分失败要能安全续跑
例如十条任务中八条成功、两条因权限失败，结果应分别列明。修正权限后只重试失败项，并确认已成功的八条没有重复。批次总数、成功数、失败数和未处理数能够对账。
时间窗和计划日期不能被迁移重算
责任变化通常不应改变基准日期、访视窗口和已发生的联系记录。验收时比较迁移前后关键日期及规则版本。若正式方案要求重新安排，应通过独立、可审核的变更流程执行，而不是迁移操作的隐藏副作用。
提醒接收人要同步但不追发旧消息
未来提醒转到新队列，已经发送的消息保留原接收人与时间。测试切换发生在提醒生成前、生成后未发送、发送中和发送失败等边界，避免两边同时收到或谁都收不到。
权限收回与历史可追溯要同时成立
原中心人员完成交接后不再查看非职责范围的新数据，但其历史操作、签名和质疑回复仍保留。测试直接链接、搜索、收藏、导出文件和移动端后台恢复，确认权限变更没有旁路。
接收方不必获得全部中心资料
目标团队只获得完成后续任务所需的最小数据。对统计汇总、附件和敏感字段分别测试权限，避免迁移任务时顺带扩大整个项目的访问范围。
用导出和审计日志完成验收
迁移后导出任务清单，与迁移前影响范围逐条匹配；从任意一条记录可查到原责任、目标责任、批次、操作者、时间和原因。再模拟撤销或纠错，确认不会抹去历史。测试只使用虚构或脱敏数据。
上线后先小批量观察
先迁移少量非紧急任务，核对提醒、权限和队列，再按机构变更流程扩大范围。任何异常先停止批次并对账，不用反复点击提交。通用团队协作可参考案例分享，质量依据可参考行业动态。
FAQ
中心关闭后可以批量把任务设为完成吗？
不应这样做，完成状态应反映真实执行结果，并按正式流程处理。
迁移责任人需要重建访视计划吗？
通常不应自动重建；是否调整计划取决于正式方案和批准流程。
只核对任务总数相同就够了吗？
不够，还要逐条核对状态、日期、责任、提醒、权限和审计轨迹。