.jpg){kind=link}
- 发布
- 更新
- 来源核查
在安全性报告中，生成文件、完成医学评估和跟踪报告提交是不同的工作。完成其中一项，并不能证明其他工作也已完成。设计土耳其 SUSAR 报告操作流程时，应同时考虑评估责任、报告时间表、电子消息质量和随访记录。本文将人用药品临床试验相关的 2026 年资料转化为团队可执行的工作计划。
国家 SUSAR 模块与 2026 年更新范围
TİTCK 于 2026 年 5 月 20 日发布的公告说明，临床试验模块下已开发国家 SUSAR 模块。公告将相关指南的公布与生效起始日期列为 2026 年 5 月 15 日。本文审阅的 KAD-KLVZ-07 为第 13 次修订版。这些日期不同于本文的发布日期 2026 年 10 月 27 日。
不要仅让信息技术团队负责过渡评估。药物警戒、医学评估、监管事务和研究运营团队应从各自责任角度审阅同一个示例病例。目的不仅是检查系统页面能否打开，更是证明组织内部的工作交接能够运行。
将报告时限与正确事件及责任人对应
KAD-KLVZ-07 第 6.20 条规定：对于致死或危及生命的 SUSAR，应在申办方收到信息后最迟 7 天内报告；其他 SUSAR 应在首次获知信息后最迟 15 天内报告。研究者报告严重不良事件的 24 小时规则则规定在第 6.17 条，并包含方案规定的例外。
我们的操作建议是，不要只设一列“截止日期”，而应分别记录获知事件、移交评估以及提交报告的时间，并为每项任务确定后备人员。这些记录不能自动完成医学分类，但有助于核查什么信息何时送达了谁。时限计算应依据适用于该研究的相关条款确认。
E2B(R3) XML 验证不只是格式检查
KAD-KLVZ-07 第 6.23.1 条说明了土耳其境内相关 SUSAR 的单例 E2B(R3) XML 报告。附录 2 区分了 XSD 符合性、字段必填与重复规则、ICH 业务规则以及额外的 TİTCK 检查。因此，一个技术上可以打开的 XML 文件，并不等于已通过全部内容核查。
将错误记录转化为团队能够处理的任务，注明受影响字段、发现的错误、预期修正责任人以及复核结果。对类似错误，与其仅靠重复提交来关闭，不如检查源系统映射。使用示例病例测试时，应选择受控的虚构数据，而非真实受试者信息。
结合本地业务规则理解国际标准
ICH 于 2026 年 1 月发布的 E2B(R3) 培训模块 III 说明了共同标准之外区域实施指南的重要性。提交、接收、确认消息和系统中断属于不同的实施议题。生成符合某一国家要求的消息，并不意味着满足另一国家的所有本地要求。
在实际适配中，先梳理数据字段在源系统中的对应关系，再明确土耳其特有的检查、缺失字段的处理方法以及版本变更后需要重测的场景。若将其视为一次性的文件格式转换，就难以识别后续更新的影响。
对报告工具及其变更实施受控管理
EMA 的临床试验计算机化系统指南涉及个人账户、与职责相适应的访问权限、数据变更追踪以及适合预定用途的验证。本文将其作为评估多国报告系统质量设计的国际参考，而不是将其转化为土耳其新的申请规定。
据此，应记录生成或编辑消息的软件版本。字段映射或检查规则变更时，重新评估受影响的场景。结合人员变动审查用户权限，防止任务交接时尚未完成的报告失去责任人。
围绕病例标识整合跟踪记录
如果不同团队用不同名称记录同一个病例，查找文件和评估状态会更加困难。我们建议的操作记录将机构内部病例标识、相关研究、任务责任人和后续行动放在一起展示。该记录不改变临床评估，而是帮助协调团队之间的沟通。
从一开始就明确，关闭一项行动需要哪些证据。提交问题、补充信息请求以及等待医学评估的事项，不应归入同一种状态。这样，管理视图中的绿色标记就不会掩盖未解决的依赖关系。延误分析也能着眼于流程在哪个环节受阻，而不是仅寻找个人失误。
团队准备情况的可执行核查清单
- 评估、技术文件生成和提交的责任人及后备人员是否明确？
- 获知信息与交接记录是否可关联至同一事件？
- 虚构示例是否同时测试了常规流程与字段错误场景？
- 是否记录检查错误的处理责任人和重新评估结果？
- 发生中断时，是否能获取最新官方指引与支持渠道？
- 团队交接时，新的责任人是否确认接收尚未完成的跟踪行动？
常见问题
- XML 文件能够打开，就足以完成 SUSAR 报告吗？
- 不够。KAD-KLVZ-07 附录 2 将技术模式、字段规则、ICH 内容规则及 TİTCK 检查列为不同阶段。
- 本文也涵盖医疗器械安全性报告吗？
- 不涵盖。本文审阅的资料针对人用药品临床试验。医疗器械应根据研究及产品范围，另行审阅相应官方流程。
- 门户显示了文件状态，是否代表官方报告已完成？
- 仅凭这一点不能作此判断。应区分内部任务状态与官方流程中的记录和结果，并依据相应证据作出关闭决定。