做过MRCT的中国sponsor大概都经历过这种场景：FDA BIMO检查官坐在会议室里，要求你现场调出RTSM系统的randomization audit trail，追溯某个受试者的分组时间戳、分配 concealment 记录，以及该次随机对应的药物批次和分发签收。如果你准备不充分，这几分钟的沉默会格外漫长。
RTSM（Randomization and Trial Supply Management），也就是早期的IWRS/IRT系统，是MRCT中承载数据完整性（data integrity）的关键基础设施。随机化逻辑出了偏差，整个试验的统计学效力可能受损；药物核算记录对不上，FDA会引用21 CFR §312.57和§312.59，直接质疑sponsor是否履行了对试验药物disposition的追踪义务。IQVIA的一项分析显示，FDA现场检查中约15-20%的site会收到findings，而drug accountability一直是高频被挑毛病的地方。
就实际经验而言，中国sponsor在做全球MRCT时，对RTSM供应商的审计往往停留在"看了CSV package、签了validation certificate"的层面。但这远远不够。FDA在2024-2025年间发出的Warning Letter多次提到unvalidated system和用Excel追踪critical records却缺少audit trail的问题。ICH E6(R3)在2025年1月正式定稿后，更是把randomization和drug accountability明确列为"critical to quality"因素。也就是说，这两个领域是监管检查的"必考题"。
这篇文章不是科普RTSM是什么——如果你正在读这篇，你应该已经有了基本的认知。我们想做的，是给出一份站在buyer side的审计就绪清单，帮助中国sponsor在FDA BIMO或EMA GCP inspection到来之前，逐项核对RTSM供应商的合规状态。
随机化逻辑验证：别只看UAT报告
随机化是临床试验数据完整性的基石。allocation concealment一旦被打破——不管是系统bug还是人为操作——受试者的分组信息就可能影响入组决策，引入选择偏倚。
我们在审核供应商的randomization模块时，关注几个具体层面。
分层（stratification）和区组（block size）的配置验证。方案规定了按region和biomarker status分层，block size为4——这些参数在系统里是怎么配置的？供应商的UAT（User Acceptance Testing）是否覆盖了这些组合场景？我们建议要求供应商提供具体的test case，而不是只看一份笼统的UAT summary report。检查每个strata的randomization list是否按方案独立生成，seed number有没有记录和锁定。
Allocation concealment的保障机制。RTSM在受试者入组前，是否向site人员暴露了下一个分组信息？有些老旧系统在screening阶段就会预分配treatment arm，这在adaptive design中尤其危险。确认系统的设计是"实时分配"而非"预分配list"。或者更准确地说，确认在受试者确认入组资格的那一刻，系统才调用randomization algorithm返回分组结果。
随机化算法的独立验证。别完全信任供应商说"我们用的是SAS PROC PLAN"或"R的blockrand包"。要求看到algorithm的描述文档，以及一份独立的verification report——可以是biostatistics团队用相同参数重新生成randomization list并比对的结果。这个步骤在FDA看来不是"过度验证"，而是基本的due diligence。
药物核算与调和审计：从shipment到destruction的完整链条
21 CFR §312.57要求sponsor维护"an accurate disposition of the drug"，包括shipment dates、quantities received、dispensed to subjects、以及returned or destroyed。RTSM系统理论上记录了这条链上的每一个节点，但理论跟现实之间往往存在gap。
全流程可追溯性检查。shipment → depot receipt → site receipt → dispense → return/destruction，每个环节在RTSM里是否有独立的timestamp和责任人记录？我们见过的情况是，depot receipt到site receipt之间的运输记录有时在系统之外（比如用email确认），这就会造成reconciliation的盲区。要求供应商演示完整的traceability report，随机抽几个batch number跑一遍。
药物调和偏差（reconciliation discrepancy）的处理流程。RTSM记录的药物数量与site物理inventory不一致时，系统如何处理？是否有自动的discrepancy flag？SDV（Source Data Verification）团队是如何介入的？FDA检查时，发现药物数量对不上但没有任何解释文档，这是一个很可能触发finding的场景。确认供应商的SOP中明确了discrepancy investigation的流程和时限。
温度偏离与药物状态联动。对于需要冷链运输的生物制品，温度excursion是否自动触发药物status的变更（比如从"available"变为"quarantined"）？这个联动是否在系统validation中做过测试？McKinsey的一项研究指出，RTSM系统如果配置得当，可以减少15-20%的药物浪费和成本——其中很大一部分来自减少温度偏离导致的药物报废。但前提是联动逻辑经过了验证。
Part 11与CSA合规证据：验证文档不是摆设
FDA的21 CFR Part 11对电子记录和电子签名提出了明确要求。2025年9月FDA定稿的Computer Software Assurance（CSA）guidance引入了基于风险的方法论——当然，2026年2月又发布了一份更新版本，与新的QMSR（21 CFR 820 harmonization with ISO 13485）保持一致。虽然CSA guidance的适用范围是production和quality system software，但其risk-based的理念对clinical系统同样有参考价值。
Audit trail的完整性。这是Part 11合规的核心。检查RTSM的audit trail是否记录了每一次data creation、modification和deletion——包括操作者ID、时间戳、修改前后的值、以及修改原因。我们建议随机抽取10-20条audit trail记录，与实际操作日志做交叉验证。特别关注随机化相关的操作：有没有在系统上线后修改randomization parameters却没有留下change reason的记录？
User access control和electronic signature。每个用户的权限是否与其角色匹配？有没有shared account？离职人员的账号是否及时deactivate？electronic signature的含义是否符合Part 11的要求（即signer确认了签名等同于手写签名）？这些看起来是"基础操作"，但在FDA BIMO inspection中，access control问题几乎是最常见的finding之一。
Validation documentation的深度。供应商提供的CSV（Computer System Validation）package，不应只是IQ/OQ/PQ的checklist。我们通常会要求看到：Requirements Specification（明确记录了系统的functional requirements）、Design Specification（设计如何满足requirements）、Traceability Matrix（每个requirement对应哪些test case）、以及Deviation Log（validation期间发现的偏差及处理）。如果供应商说"这是standard configuration，不需要做full validation"——这本身就是一个red flag。
紧急揭盲流程验证：24/7可用性不是口头承诺
在MRCT中，当受试者发生SAE（Serious Adverse Event）需要紧急揭盲时，site必须在任何时间都能联系到unblinding service。这听起来简单，实际操作中的坑不少。
确认供应商的紧急揭盲服务覆盖所有时区。如果你的MRCT横跨北美、欧洲和亚太，意味着24小时不间断——供应商是否有全球支持团队？有没有书面承诺的response time SLA？揭盲后的documentation是否完整：谁在什么时间因什么原因揭了哪个受试者的盲，揭盲后的treatment assignment如何通知到site和sponsor的medical monitor？
还有一个容易忽略的点：紧急揭盲后，RTSM系统是否自动记录这次unblinding event，并关联到该受试者的数据？如果unblinding信息只存在于电话记录或email中，而RTSM里该受试者的status仍然显示"blinded"，这会造成严重的数据不一致。
方案修正对随机化和药物供应的影响评估
临床试验几乎都会经历protocol amendment。每次修正如果涉及入排标准、剂量调整、或新增cohort，都可能影响随机化配置和药物供应策略。
要求供应商提供一份"amendment impact assessment"的流程文档。当sponsor发出protocol amendment通知后，RTSM团队是否有一个标准的assessment checklist，评估 amendment对randomization（比如新增stratification factor）、drug supply（比如新增的dosage cohort需要多少kit）、以及system configuration的影响？
这个评估的结果应该形成书面记录——一份简短的impact assessment memo就够了。FDA在检查时如果发现amendment改变了随机化参数，但系统里没有对应的change control记录，会直接追问sponsor是否评估了变更对data integrity的影响。
数据对接：RTSM与EDC、安全数据库的reconciliation
RTSM不是孤立运行的。它需要与EDC（Electronic Data Capture）系统做访视和用药数据的reconciliation，可能还需要与safety database对接——特别是在紧急揭盲场景下，treatment assignment信息需要传递给药物安全团队做因果关系判断。
RTSM↔EDC reconciliation的频率和差异处理。两个系统之间的数据同步是real-time还是batch？如果是batch，频率是多少？同步后的discrepancy如何处理？有没有自动的reconciliation report？我们通常建议sponsor在database lock之前，做一次完整的RTSM-EDC reconciliation——不仅仅是数量对得上，还要核对具体的数据点（比如dispense date、dose amount）。
与safety数据库的对接验证。当紧急揭盲发生时，treatment assignment信息是自动推送到safety database，还是需要manual entry？如果是自动推送，这个interface是否在validation中做过end-to-end测试？如果依赖manual entry，出错的风险有多大？
供应商CSV Package审查：具体要什么
把前面散落的线索汇总一下——当你坐在供应商的audit room里（或视频会议上），应该要求查看哪些具体文件：
- System Requirements Specification（SRS）：确认functional requirements覆盖了你的study protocol的所有场景
- Validation Plan和Validation Summary Report：不是走过场的sign-off page，要看具体的test results和deviation handling
- Traceability Matrix：每个requirement → test case → test result的对应关系
- Configuration Specification：你study的randomization、drug supply、user role等配置文档
- Change Control Log：系统上线后的所有变更记录，包括变更原因、影响评估、审批
- Audit Trail Review SOP：供应商如何定期review audit trail、处理anomaly
- Business Continuity / Disaster Recovery Plan：系统宕机时的应急方案，特别是randomization和unblinding服务
- User Administration SOP：账号创建、权限分配、离职处理的流程
- Training Records：关键岗位人员的training documentation
这份清单不是要把供应商审到"寸步难行"。准确地讲，核心目的是确保在FDA或EMA检查官问出那个关键问题时——"请向我证明这个系统的randomization logic是正确的，drug accountability是完整的"——你能在30分钟内拿出完整的evidence package。
Everest Group在2025年的RTSM PEAK Matrix评估中分析了20家供应商，包括Veeva RTSM（Indero等CRO已在上面跑了40+个study）、Suvoda、Signant Health、Perceptive、Endpoint Clinical等。选择供应商是一回事，审计就绪是另一回事——再好的供应商，如果sponsor不主动审查和确认，合规gap也会在检查日暴露。
对我们中国sponsor来说，RTSM审计不是"选做项"。在全球MRCT的监管环境下，它和EDC、safety database一样，是data integrity链条上不可断的一环。提前做好功课，总比在检查室里面对沉默要好。
相关文章
肿瘤临床试验生物标志物检测实验室怎么选：从PD-L1 IHC到NGS panel的实操尽调
PD-L1、NGS、探索性终点——肿瘤临床试验的生物标志物检测实验室选择不是比价格，而是比平台一致性、样本通量、周转时间、以及跨中心数据可比性。这篇从中国申办方全球MRCT视角拆解尽调框架。
中心实验室数据传到EDC和TMF之后不一致怎么办：临床数据对账的实操框架
中心实验室、EDC、eTMF三个系统之间的数据不一致，是临床数据管理中最耗时的隐形工作。这篇拆解数据传输协议设计、对账频率、差异根因分类、以及中国申办方跑全球MRCT时的数据治理实操。
EDC、中心实验室、eCOA、安全数据库各用不同供应商：临床数据API集成的风险地图
当EDC、中心实验室、eCOA和安全数据库分别由不同供应商提供时，API接口成为临床数据质量的最大隐患。这篇拆解接口断裂的六种模式、数据丢失的三个高发场景、以及中国申办方在合同和验证层面能做的预防措施。