简介这是一份CDISC官方发布的《SDTMIG V 3.4》终版PDF文档面向从事临床试验数据标准化、SDTM数据集制作与递交的临床编程人员、数据管理员及统计人员帮助其理解并实施人类临床试验中的研究数据制表模型规范。文档基于SDTM 2.0模型编写除核心域模型与通用观测类别外还分章节详述各标准域的变量要求、映射规则、实施步骤及术语附录兼顾版本演进脉络便于新旧规范对照学习。压缩包内共1个文件为PDF格式整体大小6.88MB可直接用于查阅、检索并长期保存。目前已有775人参与学习下载对准备SDTM递交或想系统梳理规范细节的读者都有参考价值。内容上域规范覆盖干预类、事件类、发现类等主要SDTM标准域实施指南则从数据收集、存储到分享给出落地建议附录还提供术语表、数据类型与错误代码。读者既能获得各域的建模规则也能掌握整体实施路径从而降低数据递交的合规风险。 做临床数据标准化这几年我几乎每个项目都绕不开 CDISC SDTMIG V 3.4。如果你也是统计程序员、数据管理员、临床数据科学家或者CRO里负责交付数据集的人应该很清楚 SDTMIG 不是买来“读”的文档而是真正要对照着一行一行落实的操作手册。它规定了研究数据怎么拆域、怎么命名变量、怎么记录访视和时间最终把一套杂乱无章的原始数据整理成 FDA、PMDA、NMPA 能直接审阅的标准化数据集。这篇文章就围绕 SDTMIG V3.4 展开说说这个版本到底改了什么、实际落地时怎么用以及那些文档里不会写、但踩过坑才知道要注意的地方。不管你是刚入行的小白还是已经做了几年数据交付的熟手我都建议把这个版本的结构规则、映射逻辑和验证思路吃透因为它是目前国内外临床试验递交绕不开的基准版本之一。1. 项目概述SDTMIG V3.4 到底是干什么用的1.1 一份“数据接口说明书”而不是模板先理清两个容易混淆的概念。SDTM 是 CDISC 发布的数据表格模型英文全称是 Study Data Tabulation Model它告诉你一套提交给监管机构的数据应该长什么样。但模型本身偏抽象真正可操作的是 SDTMIG——Study Data Tabulation Model Implementation Guide也就是实施指南。打个比方SDTM 是建筑施工规范SDTMIG 就是在这个规范下写好的施工图集。它针对每一种情况给出推荐的房间布局、管线走向和验收标准你照着做基本不会跑偏。SDTMIG V3.4 就是这个图集目前很主流的一个版本配合 SDTM v1.7 使用面向递交场景定义了各域Domain、各变量Variable的标准名称、标签、类型、受控术语来源和逻辑关系。我在实际项目里的感受是SDTMIG 更像是一本“数据接口说明书”。它不关心你的 EDC 长什么样也不关心 CRF 页面怎么排它只定义最终交付的数据接口长什么样变量名叫什么、是字符还是数值、允许哪些值、域和域之间怎么关联。只要这些接口定义对齐了不管是监管审评还是统计分析都能用同一套语言来读数据。1.2 为什么 V3.4 这个版本值得重新看一遍很多人手上还在用 SDTMIG 3.2 或者 3.3一说升级到 3.4 就觉得麻烦。但这个版本发布之后已经成为很多药企和 CRO 内部默认的基线版本。一是监管层面越来越严格FDA 的数据标准目录里对递交格式有明确要求PMDA 也持续跟进 CDISC 标准国内 NMPA 在鼓励递交标准化的趋势下很多项目也开始按 CDISC 结构整理数据。二是 Pinnacle 21 Community 这类验证工具的默认规则集也是按最新版本去写的你用 3.2 的规则建出来的数据集跑一遍 3.4 的验证规则会冒出一堆变量标签不匹配、新增必选变量缺失之类的问题回头还是要改。单看 V3.4 本身官方在一众域定义上做了集中修订尤其是试验设计相关的几个域TV、TA、TE、TS 之间的引用关系越来越严密评审人员也习惯了用这套关系做交叉核对。再加上 SUPP--补充域和 RELREC关联数据集的用法在这个版本周期里更加成熟整体建库难度其实比旧版本要低只是第一步的学习成本躲不掉。2. 核心技术点拆解SDTMIG V3.4 的数据组织规则2.1 三大观测类与域Domain划分SDTMIG 的核心思想是把临床试验数据归纳成三大观测类再加上若干特殊用途域。干预类Interventions处理的是受试者接受了什么治疗或干预代表域包括 EX暴露、CM合并用药、SU物质使用、EC不良事件伴随治疗准确说应是伴随治疗或操作。事件类Events处理的是发生了什么比如 AE不良事件、MH病史、DV方案偏离、DS脱落/完成状态。发现类Findings处理的是检测到什么结果比如 LB实验室检查、VS生命体征、EG心电图、QS问卷量表、PC药代动力学浓度、RS疾病应答。这几类域在结构上有一个重要区别干预和事件类一条记录就是一次独立事件比如一次用药记录、一次不良事件而发现类通常是一条记录对应一次检测的“一个检测项”同一访视里测了十项指标就有十条记录。特殊用途域也值得单独记住比如 DM人口学、SE受试者要素、SV受试者访视、CO评论、TA试验组别、TE试验要素、TS试验摘要、TV试验访视。这些域不是三大观测类但承担着描述研究设计、描述受试者状态的关键作用。尤其是 TV如果你们项目还用老版本建的库没有 TV 域审评人员想看计划访视和实际访视的对应关系时会非常不方便。2.2 变量四分类Identifier、Topic、Timing、Qualifier一个标准 SDTM 域里的变量不是随便排列的。SDTMIG 把所有变量分成了四类理解了这套分类后面读任何域模板都能快速上手。第一类是标识变量Identifier比如 STUDYID研究编号、DOMAIN域简称、USUBJID受试者唯一编号、--SEQ域内记录序号。这些变量是数据的骨架用来定位一条记录的归属和顺序。第二类是主题变量Topic它描述这条记录“到底是什么”。干预和事件域里通常是 --TRT治疗名称或者 --TERM事件术语发现类域里则是 --TESTCD检测项短名和 --TEST检测项名称。主题变量是每个域里最关键的内容监管审评时最关注的也是它。第三类是时序变量Timing用来描述事件发生的时间或访视比如 --STDTC开始日期时间、--ENDTC结束日期时间、--DTC检测日期时间、 --VISIT访视名称、--VISITNUM访视编号、--EPOCH试验阶段。时间变量看似简单实际是最容易出错的地方因为格式和精度要求都很细。第四类是修饰变量Qualifier负责补充说明主题变量的属性和结果比如 --ORRES原始结果、--STRESC标准化字符结果、--STRESN标准化数值结果、--ORRESU原始结果单位、--DOSEA剂量、--DOSU剂量单位等。修饰变量里的“结果三兄弟”是发现类域的灵魂很多 QC 工作都耗在这里。2.3 V3.4 里的关键结构与新增倾向从我实际使用的体验看SDTMIG V3.4 有几个方向值得关注。第一个变化方向是试验设计域的强化。现在做一个新项目如果方案里有较复杂的分组和访视设计TV 和 TA、TE、TS 之间的引用关系必须要能闭环。比如 TA 里定义了有哪些 ARMTV 里定义了这些 ARM 有哪些计划访视SV 再记录每个受试者实际发生的访视。三者对不上验证工具立刻就会报警。第二个方向是 SUPP-- 的规范化使用。SDTMIG 从来都鼓励“能塞进核心域的就不要放补充域”但总有些非标准变量无处安放这种时候要用 SUPP-- 加 QNAM、QLABEL、QVAL、QORIG 等变量来承接。3.4 逻辑下SUPP-- 和主域的关联通过 IDVAR 和 IDVARVAL 来实现同时需要配合 RELREC 明确关系层级很多团队在这里偷懒后面 define.xml 生成时各种告警。第三个方向是对日期时间和 ISO 8601 格式的强调。--DTC 的全称是 Date/Time of Collection本质是一个字符型变量建议按 ISO 8601 标准存成四层精度只有年份就写“2023”有年月就写“2023-08”精确到日就写“2023-08-15”精确到时分秒就写“2023-08-15T09:30”。很多新人喜欢把日期存成 SAS 日期数值型对不起SDTM 里标准做法是字符型 DTC 加可能存在的 --DT 和 --TM。这个习惯越早改越好。3. 实操映射从 CRF 到 SDTM V3.4 的完整流程3.1 先做注释 CRF我参与过不少项目的 SDTM 建库最重要的一件准备工作不是写代码而是把 CRF 从头到尾注释一遍。所谓注释 CRF就是把临床研究表格里每一个采集字段标注上它对应到哪个 SDTM 域、哪个变量。比如年龄、性别、出生日期通常对应到 DM 域的 AGE、SEX、BRTHDTC不良事件页的 AE 描述、开始日期、结束日期、严重程度、因果关系分别对应 AE 域的 AETERM、AESTDTC、AEENDTC、AESEV、AEREL。注释得越细后面写映射规格时越省力。工具方面我见过团队用 PDF 编辑器直接标注也见过用专门的注释 CRF 系统甚至有人直接在原始文档管理系统的预览界面上加框选注释。无论工具是什么原则只有一条每个字段都要有归宿。如果哪个采集项在 SDTMIG 3.4 里找不到合适的放处就标记出来进入补充域或自定义变量的决策流程最怕的是“看着差不多先放着再说”最后验证阶段全部暴露。3.2 写 Mapping Spec关键的映射决策注释 CRF 完成后核心工作就是写 Mapping Specification也就是映射规格书。这是一份描述“源头数据如何变成 SDTM 数据集”的文档每行一个目标变量包括源库表名、源字段名、转换逻辑、编码规则、是否派生等。我写 Mapping Spec 时最常遇到的决策点有三个。第一个是域归属的判断。举个典型例子受试者既往病史和基线时发现的不良事件在 CRF 上可能都在一张表里但 SDTMIG 明确要求研究期间新发且符合 AE 定义的记录要进 AE基线前就存在的稳定问题要进 MH。怎么区分通常看 CRF 页面本身属于哪个模块如果问题问的是“是否有既往疾病史请列出”多半进 MH如果问的是“从上次访视以来是否出现不良事件”那就是 AE。不要自己发挥先看 CRF 的设计意图。第二个是结果变量的取舍。发现类域里--ORRES、--STRESC、--STRESN 经常让新手头疼。我的经验是ORRES 永远等于 CRF 上原始填写的内容比如血钾结果是 4.2 mmol/LSTRESC 是经过标准化和编码后的字符结果实际上如果是数值型指标STRESC 通常也会存成和 ORRES 几乎一样的内容只是统一了单位换算比如都换算成 mmol/LSTRESN 则是把字符串转成数值的版本前提是能安全转成数值单位也统一。对于定性结果比如“阴性/阳性”只用 ORRES 和 STRESCSTRESN 留空。第三个是编码变量的处理。AE 通常要映射 MedDRA 编码合并用药通常要映射 WHO Drug 编码。这些编码在 SDTM 里不放在 AE 和 CM 域本身的变量里而是通过 AEBODSYS、AEDECOD或者 CMDECOD 等标准化术语变量来承接。底层编码结果放在哪里由你公司的标准流程决定但最终提交的数据集里域内的术语变量必须存在且有内容。3.3 用 SAS 实现和验证Mapping Spec 写完后才轮到写程序。业内主流还是用 SAS 比较多但不管用什么语言要注意几个硬性限制。SDTM 递交数据集一般要求是 XPT 格式XPT V5 版本对变量名和变量标签长度有严格约束变量名不能超过 8 个字符变量标签不能超过 40 个字符。SDTMIG 3.4 里的变量名设计本身已经考虑了这个限制所以一般没问题但程序中间数据集如果用了过长的变量名最后转出 XPT 时会报错或者被截断这种问题在验证阶段非常常见。生成数据集之后一定要用 Pinnacle 21 Community 跑一遍。这个工具几乎是行业事实标准它会检查必选变量是否缺失、变量标签和类型是否与 SDTMIG 一致、外键引用是否存在、受控术语是否符合规范等。我每次都会把它的输出从头看到尾尤其是被标记为 Error 的条目绝不直接忽略。很多团队在时间压力下只把 Error 处理了就提交Warning 不管但这个习惯不好因为 Warning 往往指向数据语义上的模糊地带比如某个时间变量有日期但没时间某个受试者在两段 EPOCH 之间有重叠这些问题越早处理越省事。define.xml 也是递交包的一部分。它是一份机器可读的元数据文件描述每个数据集、每个变量的属性来源和编码信息。用 SAS 写数据集时我会同步整理变量级的注释和数据字典后期用工具生成 define.xml 时能省大量返工。4. 常见问题与排查技巧实录4.1 USUBJID 还是 --SEQ两条最容易混淆的标识有一次同事把 USUBJID 和 AE 域里的 AESEQ 搞混了导致后续跟实验室数据合并时受试者记录大量错位。这里要记住USUBJID 是受试者层面的唯一标识一个受试者在一项研究里只有一个值而 --SEQ 是域内记录层面的序号同一受试者在同一域内按某种顺序排号比如 AESEQ只保证在这个域内唯一。--SEQ 的生成逻辑在 SDTMIG 里有明确建议通常推荐按时间顺序排列没有时间窗口的就按 CRF 采集顺序排列。很多程序喜欢直接用数据集的行号当 SEQ看起来没问题但一旦中间做了去重、排序或者数据清洗SEQ 就不能再反映原始逻辑了。我建议 SEQ 的生成放在所有清洗和去重之后单独用一行逻辑处理。4.2 SUPP-- 和 RELREC 的关系处理这个坑我在项目里踩过不止一次。某个采集项是“其他不适”内容填的是“偶尔头痛”你把它放进 AE 域显然不合适放进 SUPPAE 好像也对但关系怎么建立按照 SDTMIG 3.4 的思路SUPP-- 里必须通过 RDOMAIN、IDVAR、IDVARVAL 三个变量来关联父域记录。比如 SUPPAE 里有一条记录RDOMAIN 等于 AEIDVAR 等于 AESEQIDVARVAL 等于 3意思是这条补充信息挂在 AE 域 SEQ3 的那条不良事件上。如果补充信息不属于某条具体父记录IDVAR 和 IDVARVAL 要留空。至于 RELREC很多人把它当成万能药实际上它更多用于一对多、多对多关系比如同一个实验室检查结果既关联到 LB 域的记录又关联到某个特定的不良事件这时候才需要 RELREC 去表达跨域关联。能用 SUPP-- 直接挂的就不要额外开 RELREC否则 define.xml 里会出现大量冗余关联验证工具也会提示。4.3 时间变量到底放 --DTC 还是 --DATETIME这个问题每个项目都会碰到。SDTMIG 的通用规则是发现类域用 --DTC表示检测时间点或采集时间干预类和事件类用 --STDTC 和 --ENDTC表示开始和结束时间。有些域模板里还提供了 --DATETIME这是从发现类域派生出来的时间变量一般不是直接从 CRF 搬过来的而是综合分析后生成的参考时间点比如药代动力学里的分析时间点。项目里最容易犯的错是把 CRF 上“年月日时分”直接塞进 --DTC没有保留原始精度信息也没有单独存一版数值型日期。我的习惯是在 SDTM 数据集里保留 --DTC 字符变量如果后续统计分析需要数值日期再单独维护一份 ADaM 数据集做转换。这样既符合递交规范又不影响分析。4.4 从 3.3 迁移到 3.4 要查哪些地方很多团队不是从零开始而是在已有数据集基础上从 SDTMIG 3.3 升到 3.4。这个迁移过程我建议重点关注四处。第一处是变量属性的变化某个变量是字符型还是数值型标签是否调整类型是否有改动。第二处是新增强制变量的补充比如某些域里新增的必选变量旧数据里没有必须补采或者派生。第三处是受控术语的更新3.4 对应的术语集版本会变化以前允许的值现在可能变成“非标准”需要重新映射。第四处是试验设计域的一致性TV 域如果没有得评估是否需要补写已存在的 TA、TE、TS要和法案做一遍交叉核对。我自己的习惯是先跑一次 Pinnacle 21 的版本对比报告把所有 Error 和 Warning 导出按“新增必选”“标签变更”“术语变更”“关联断裂”四类分类处理。这样做比手动翻发行说明有效率得多。5. 留给新人的几个习惯最后分享几个我在实际项目中沉淀下来的技巧。第一所有 DS 域的记录都要有始有终。受试者从开始入组到完成研究或者提前退出DS 里都要有对应的记录而且 DS 的 EPOCH 和 SV、TV 要能对应上。很多项目最后被质问“这个人去哪了”往往就是 DS 域缺失记录或者记录顺序错乱。第二别轻易改变量标签。SDTMIG 对标签的定义是审评工具识别变量的关键信息擅自改成“更易懂”的标签会导致验证工具报错。如果确实要加业务含义用 define.xml 里适当的注释去补充不要动标签本身。第三养成写版本记录的习惯。每次数据集更新记录修改人、修改日期、修改原因、影响的变量和范围。这是个看似很“过程”的要求但在项目后期特别是问询答复阶段能救你很多次。SDTMIG V3.4 看起来是一份很厚的规范文档真正用起来其实就几套规则的循环分域、定义变量、处理时间、管理关联、验证提交。多接几个项目特别是经历过一次完整的递交和审评问询之后你会慢慢形成自己的判断——哪些地方可以追求效率哪些地方必须按部就班。愿你少踩点坑。本文还有配套的精品资源点击获取