1. 从“数据孤岛”到“通用语言”为什么我们需要SDTM如果你在临床研究的数据管理、编程或统计分析岗位上工作过一段时间大概率经历过这样的场景申办方A的试验数据变量名是PATIENT_ID、VISIT_DATE、RESULT申办方B的可能就变成了SUBJID、VISDT、VAL。同一个实验室检查指标在CRO公司X的数据库里叫ALT到了Y公司可能就成了ALAT。更头疼的是数据结构有的把所有访视数据堆在一行有的则是一行一个访视。当你需要快速理解一个试验的数据、进行跨研究的汇总分析如ISS/ISE或者将数据提交给监管机构时这种不一致性就成了巨大的障碍需要投入大量人力进行数据映射、清洗和标准化效率低下且容易出错。CDISC临床数据交换标准协会的SDTM研究数据制表模型就是为了解决这个核心痛点而生的。它不是某个公司或机构的内部标准而是一个全球性的、被监管机构如美国FDA、日本PMDA广泛接受并推荐甚至强制要求的数据提交标准。你可以把它理解为临床研究数据领域的“通用语”或“世界语”。当所有人都用同一种语法和词汇来描述数据时沟通成本将急剧下降。而SDTMIGSDTM实施指南特别是我们这里要讨论的3.2版本就是这本“世界语”的详细“语法说明书”和“词典”。SDTM模型定义了宏观的框架和原则比如数据要按“观察”来组织每个观察包括主题Who、变量What、时间When等。但具体到某个治疗领域血压该怎么记不良事件严重程度的编码规则是什么这些实操层面的细节就需要SDTMIG来明确。3.2版本是一个里程碑式的更新它整合并取代了之前的多个疾病领域专属的IG形成了一个更通用、更强大的核心指南。理解SDTMIG 3.2对于从事临床数据标准化工作的从业者来说不是“加分项”而是“必备技能”。它意味着你能用业界公认的最高效方式构建出清晰、合规、便于审阅和分析的数据资产。2. SDTMIG 3.2的核心架构与模型思想拆解SDTMIG 3.2的文档结构庞大但它的核心思想可以归结为一点基于“观察”的数据组织逻辑。这与我们传统的关系型数据库设计思维围绕实体和事务有显著不同。理解这一点是掌握SDTMIG的关键。2.1 四大类域Domain与通用观察类General Observation ClassesSDTM将所有的数据表称为“域”分为四大类这是数据组织的顶层框架特殊用途域Special-Purpose Domains这是每个研究都必须有的“基石”域。主要包括DM人口学描述受试者的基本不变特征如性别、出生日期、种族等。它是连接所有其他数据的核心。CO评论用于记录那些无法归类到其他标准域的、非结构化的文本评论。SE受试者要素定义受试者在试验中的分组要素如筛选队列、治疗组。在3.2版本中其重要性更加凸显。SV访视定义研究的计划访视时间表。TA/TE/TI试验设计描述试验方案本身如试验组TA、试验要素TE和试验入选TI。这部分数据通常由数据集xpt文件和可阅读的PDFdefine.xml共同提供。干预类域Interventions Domains记录研究中施加于受试者的“动作”。例如CM合并用药记录受试者在试验期间服用的所有药物。EX暴露记录试验方案规定的治疗试验用药品的给予情况。PR操作记录手术、放疗等医疗操作。SU物质使用记录咖啡、烟草、酒精等物质的使用情况。事件类域Events Domains记录在研究中发生的、计划外或需要关注的“事情”。例如AE不良事件这是最重要的安全性域之一。DS处置记录受试者如何退出研究如完成、失访、死亡。MH病史记录试验前的医学状况。发现类域Findings Domains记录通过检查、测量或评估产生的“结果”。这是数量最多的一类域例如VS生命体征血压、体温、心率等。LB实验室检查血常规、血生化、尿常规等。EG心电图。QS问卷各类量表评分。PE体格检查。在发现类域中SDTMIG 3.2进一步引入了“通用观察类”的概念。这是3.2版本的一大优化。它定义了发现类数据中一些共通的、结构化的记录方式主要包括结果Result如实验室数值LBSTRESN、问卷分数QSSTRESN。时间点Timing如相对于给药的时间LBRFTDTC。基线标志Baseline Flag如何定义和标记基线值LBBLFL。参考范围Reference Range正常值上下限LBNRLO, LBNRHI。通过遵循通用观察类的规则不同发现类域的数据结构会高度一致极大地方便了后续的编程和分析。2.2 变量角色--TESTCD, --TEST, --ORRES, --STRESN的深刻含义SDTM中的变量命名遵循一套严格的规则理解变量后缀的角色至关重要。以实验室检查LB域为例LBTESTCD (Test Code)这是测试的短编码必须是标准化的、机器可读的、用于编程的键值。例如“ALT”代表丙氨酸氨基转移酶。它在同一研究中必须唯一标识一项测试。LBTEST (Test Name)这是测试的完整文本描述是人类可读的。例如“Alanine Aminotransferase”。它与LBTESTCD一一对应。LBORRES (Original Result)记录从源数据如CRF中收集到的原始结果。它通常是字符型可能包含数字、文本甚至“5”这样的不等式。这是最“原始”的数据。LBSTRESN (Standardized Result in Numeric)标准化后的数值型结果。这是为了进行统计分析的“干净”数据。如果LBORRES是“5”那么LBSTRESN可能是“4.9”或一个根据方案规定的衍生值如5/√2。这里有一个关键点LBSTRESN必须是一个纯粹的数值不能包含单位或比较符。单位记录在LBSTRESU中。LBSTRESC (Standardized Result in Character)标准化后的字符型结果。当原始结果无法或无需转换为数值时使用如“阳性”、“阴性”、“TRACE”。为什么设计得如此复杂这体现了SDTM“保留原始信息同时提供标准化分析值”的哲学。LBORRES保留了数据核查的审计线索而LBSTRESN则为统计分析提供了直接可用的输入。在生成ADaM分析数据集时程序员通常会优先或只能使用--STRESN这类标准化变量。2.3 标识变量与时间变量数据关系的纽带标识变量USUBJID唯一受试者标识符是连接所有域数据的黄金键值。它通常由研究编号、中心编号和受试者编号拼接而成。--SEQ序列号则确保同一个域内同一受试者的每条记录都有唯一标识。时间变量SDTM强烈推荐使用ISO 8601格式YYYY-MM-DDThh:mm:ss记录日期时间。--DTC日期/时间变量记录事件发生的日期。对于发现类数据--DTC通常表示标本采集或评估的日期。--TPT时间点名称和--TPTNUM时间点数字用于表示计划内的访视或时间窗这对于按时间点分析至关重要。3. SDTMIG 3.2版本的关键更新与实施要点SDTMIG 3.2并非对旧版本的简单修订它是一次重要的整合与升级。对于实施者来说需要特别关注以下几点变化和要点。3.1 从多个IG到单一核心IG的整合在3.2之前CDISC发布了多个疾病领域专属的实施指南如SDTMIG v3.1.3 for Medical Devices, SDTMIG v3.1.2 for Oncology。这导致不同领域的标准存在细微差异增加了复杂性和学习成本。SDTMIG 3.2的一个主要目标就是创建一个统一的核心实施指南将大部分疾病领域的共性要求整合进来同时通过“治疗领域用户指南”来补充特定领域的规则。这意味着无论你做什么治疗领域的研究核心的数据结构域和变量都首先遵循SDTMIG 3.2然后再去参考特定的TAUG。实施影响这要求数据标准团队建立一套以SDTMIG 3.2为核心的基础标准如CRF标准、数据集规范确保其通用性。对于特定项目再通过项目级的元数据在define.xml中说明或少量自定义变量/域来满足TAUG的要求。3.2 新域与变量的引入3.2版本正式引入或显著增强了一些域FQ功能问卷这是一个新的发现类域专门用于记录那些评估身体功能或残疾状态的标准化问卷如EQ-5D。它与QS域一般问卷的区别在于FQ更侧重于功能性的、与健康相关生活质量的评估。在实施时需要仔细区分哪些量表应该放入FQ哪些放入QS。RP生殖系统检查这也是一个新域用于标准化记录生殖系统检查和妊娠相关事件的数据。这在一些特定治疗领域如妇科、产科相关药物的试验中非常重要。SE受试者要素域的强化SE域在试验设计中的应用被更清晰地定义。它可以用来记录受试者在试验期间所属的动态分组例如在适应性设计或伞式/篮式研究中受试者可能被分配到不同的子研究或队列。正确使用SE域对于复杂试验设计的分析至关重要。3.3 关于“是否必须”Controlled Terminology and Core Status的精确理解SDTMIG中每个变量都有一个“核心状态”Core Status它定义了该变量在提交数据集中的必要性必需Required该变量必须出现在数据集中且不能全为空值。例如所有域的USUBJID、--SEQ以及发现类域的--TESTCD、--TEST。预期Expected除非不适用否则应该出现。如果适用但数据缺失需要说明原因在define.xml中。例如AESER严重不良事件对于AE域就是预期的。如果某个AE不是严重不良事件该变量值应为“N”不能缺失。允许Permissible可根据需要选用。通常是一些提供额外背景信息的变量。一个常见的实施误区把“允许”的变量全部不加选择地加入数据集导致数据集过于臃肿。正确的做法是根据研究的具体需求和CRF设计谨慎地添加“允许”变量只添加那些对数据理解或分析确有价值的。此外许多变量如--TESTCD、AESER、AEOUT等的值必须来自CDISC发布的受控术语Controlled Terminology。这不是建议而是强制要求。在实施前必须从CDISC官网下载最新的CT包并在映射规范中严格引用。使用自定义术语会导致提交的数据集不被接受。4. 从原始数据到SDTM实战映射逻辑与常见“坑点”了解了理论框架我们来看如何将收集到的原始数据通常来自CRF或EDC系统转换成SDTM格式。这个过程称为“映射”Mapping。4.1 映射的基本流程与决策树映射不是简单的重命名而是一个基于逻辑判断的过程。以下是一个简化的决策流程识别数据主题这条数据记录的是什么是一个测量值发现类、一个发生的事件事件类、一个给予的治疗干预类还是受试者的固有信息特殊类确定目标域根据上一步找到对应的SDTM域。例如血压测量 - VS域服用的伴随药物 - CM域。分配--TESTCD和--TEST对于发现类数据这是最关键的一步。必须使用CDISC CT中定义的代码和名称。如果CT中没有完全匹配的需要寻找最接近的或在极少数情况下申请新术语。切忌自创代码。处理原始结果与标准化结果将CRF上记录的原样值填入--ORRES。如果原样值是数值如“120”且单位与标准单位一致如mmHg则可以将数值直接填入--STRESN单位填入--STRESU。如果原样值包含非数字字符如“10”、“Trace”、“Negative”则需要根据方案或数据审核计划DVP中的具体规则将其转换为--STRESN可能为数值或空和--STRESC。这个转换规则必须在前期明确文档化。处理时间信息尽可能获取精确的日期时间。如果只有日期时间部分可以留空。--TPT和--TPTNUM需要根据试验计划访视表进行映射。处理缺失数据SDTM要求区分“未收集”、“不适用”和“未知”。通常用空值表示“未收集”。对于“不适用”有时需要使用特定的受控术语如“N/A”。4.2 高频“踩坑点”与解决方案坑点一实验室单位转换的混乱场景中心实验室提供的ALT单位是U/L但方案要求的标准单位是µkat/L。映射时程序员在LBSTRESN中直接写入了转换后的数值但忘记了在LBSTRESU中更新单位或者LBORRES和LBSTRESU的单位不一致。解决方案建立清晰的单位转换规则表。在生成LBSTRESN的编程中必须同步更新LBSTRESU。在QC时必须检查同一行记录中LBORRES/--ORRESU与LBSTRESN/LBSTRESU的逻辑一致性。最佳实践在数据标准中预先定义所有可能测试的标准单位并在EDC建库或数据接收规范中要求供应商尽可能提供标准单位的数据。坑点二不良事件“结束日期”的逻辑陷阱场景不良事件“持续中”或“直至研究结束”。AEENDTC结束日期该如何记录直接留空可能被误解为数据缺失。解决方案根据SDTMIG如果事件在数据截断时仍未结束AEENDTC应留空。但这需要在define.xml的注释中加以说明。更好的做法是在CRF设计时增加一个“事件状态”字段如“进行中”、“已恢复”通过AESTDTC和状态来推断。对于“直至研究结束”可以将研究结束日期作为AEENDTC但这需要明确的方案规定。坑点三合并用药“开始日期”缺失的处理场景受试者报告“一直服用阿司匹林”无明确开始日期。CMSTDTC不能为空如果适用但又没有数据。解决方案不能随意编造一个日期。正确的做法是如果CRF允许应记录为“开始日期未知”。在SDTM中CMSTDTC可以记录一个部分日期如“-01-01”表示只知道年份或者使用受控术语“UNKNOWN”。同时在CMDOSFRQ给药频率中记录“一直服用”的信息。关键在于CRF的设计应能捕获这种不确定性而不是留给数据转换阶段去猜测。坑点四访视窗偏差数据的归属场景计划在第8天±3天进行的访视受试者在第12天来了。采集的实验室数据LBDTC是第12天那么VISITNUM和VISIT应该记为“第8天访视”还是“第12天访视”解决方案VISITNUM/VISIT反映的是计划访视而不是实际发生日期。因此只要该数据是在为“第8天访视”这个计划时间点收集的即使实际日期有偏差其VISITNUM仍应映射为第8天访视对应的数字和名称。实际日期偏差通过LBDTC来体现。这个逻辑必须贯穿所有域保持一致。5. Define.xmlSDTM数据集的“导航图”与“说明书”生成SDTM数据集.xpt文件只是工作的一半。另一半是生成与之配套的define.xml文件。这个XML文件是审阅者理解你数据集的唯一权威指南其重要性不亚于数据集本身。5.1 Define.xml的核心构成元数据Metadata变量级元数据对数据集中的每一个变量进行说明包括Variable Name: 变量名。Variable Label: 变量标签描述。Type: 数据类型Char, Num。Length: 长度。Controlled Terms or Format: 使用的受控术语或显示格式。Core: 核心状态Req, Exp, Perm。Origin: 数据来源如CRF, Derived, Assigned。这里需要清晰说明衍生变量的规则。Role: 变量角色Identifier, Topic, Timing等。值级元数据对于非标准术语或需要解释的取值提供说明。例如你自定义了一个AECAT事件类别的值“PROCEDURE_RELATED”需要在这里解释其含义。数据来源Source Data通过链接或描述说明SDTM变量与原始CRF或其它数据源的对应关系。通常使用注释工作表Comment Worksheets或CRF截图来实现。分析结果元数据Analysis Results Metadata指向基于这些SDTM数据集生成的分析如ADaM数据集、统计图表的链接。5.2 制作Define.xml的实用工具与技巧手动编写define.xml极易出错且效率低下。强烈推荐使用专业工具Pinnacle 21 Community这是行业免费标准工具。它的“Validator”部分用于检查数据集合规性“Define.xml Generator”部分可以帮助你从数据集和Excel规范文件生成define.xml。你需要先准备一个符合其模板格式的Excel元数据文件。商业软件如PHUSE OpenCDISC, SAS Clinical Standards Toolkit等。制作经验从Excel规范开始在项目早期就用一个结构化的Excel文件来记录数据集规范包括变量名、标签、类型、核心状态、术语、来源、衍生规则等。这个文件既是编程的输入也是生成define.xml的源头。保持“单一事实来源”。详细描述衍生规则对于--STRESN、--BLFL、--SEQ等衍生变量在Origin和Comment中必须提供清晰、无歧义的程序逻辑或描述。例如“LBSTRESN: 当LBORRES为纯数字且单位已为标准单位时直接转换当LBORRES为‘5’时取值为4.9。”善用“Where Clauses”在定义--TESTCD的受控术语时如果同一个--TESTCD在不同条件下对应不同的CRF问题可以使用“Where Clauses”来精确描述这种条件关系使审阅者一目了然。彻底验证用Pinnacle 21 Community同时验证数据集和生成的define.xml确保两者描述一致且无任何致命错误Fatal Error或重大警告Significant Warning。6. 验证与质量控制用Pinnacle 21 Community守住最后一道关在提交数据之前必须使用验证工具对SDTM数据集进行严格检查。Pinnacle 21 Community (P21C) 是业界事实上的标准。6.1 P21C验证的关键层级P21C的检查分为多个层级关注点不同合规性检查检查是否符合SDTM模型和SDTMIG的具体规定。例如变量名是否正确、必需的变量是否存在、变量类型和长度是否符合要求、是否使用了有效的受控术语。这是最基本的门槛。数据一致性检查检查数据内部的逻辑关系。例如AESTDTC开始日期是否早于或等于AEENDTC结束日期LBSTRESN的数值是否在LBNRLO和LBNRHI参考范围之间同一个受试者的USUBJID在所有域中格式是否一致业务规则检查这部分检查与具体试验方案相关的逻辑。P21C提供了一些通用规则但更多需要用户根据方案自定义。例如“严重不良事件AESER‘Y’的记录其AESEV严重程度不能为‘MILD’轻度”。6.2 如何解读和处理验证错误P21C的报告会列出错误Error、警告Warning和通知Info。处理原则如下错误必须修复所有导致数据集不符合SDTM标准的错误都必须修复。例如使用了无效的受控术语变量名拼写错误。警告评估后决定警告通常表示潜在的数据问题或不一致但不一定违反标准。例如“发现重复记录”、“日期格式不一致”。你需要逐一评估是否为真问题重复记录可能是合理的如同一时间点测量了坐位和卧位血压。是否影响分析或审阅如果影响则需要修复或澄清。是否在define.xml中已有说明如果是一个已知的、合理的例外可以在define.xml的注释中说明从而“解释”掉这个警告。通知通常仅作参考提供一些信息如数据汇总统计一般无需处理。一个重要的经验是验证不是一次性的活动而应贯穿于数据集构建的全过程。在映射规范制定后、编程进行中、数据集初版完成后等多个节点运行验证可以尽早发现问题避免在最后阶段积重难返。掌握SDTMIG 3.2本质上是掌握了一套将杂乱的临床数据转化为结构化、标准化、可互操作信息资产的方法论。它要求从业者不仅有扎实的编程技术更要有对临床研究逻辑的深刻理解、对细节的苛刻追求以及跨部门沟通协作的能力。每一次成功的数据转换和提交都是对研究质量的一次重要贡献。