2. 临床研究数据标准与交付规范
临床研究数据交付工程的核心矛盾在于：数据从采集端到监管审评端，中间要跨越多个组织、多套系统、多种格式。如果每个环节都按自己的习惯组织数据，最终提交的包就无法被审评人员快速理解。CDISC、ICH、FDA、NMPA 等标准体系正是为解决这一矛盾而建立的“共同语言”。理解这些标准对交付物的约束边界，是数据交付工程师的基本功。
标准体系的分工：谁管什么
这些标准并非彼此替代，而是分层协作。ICH 负责制定药物研发的总体技术要求和电子提交的框架性规范，其中 ICH E6(R2) 是药物临床试验质量管理规范（GCP）的核心，ICH M2 系列则定义了电子提交的标准。CDISC 提供的是数据内容层面的标准，即“数据长什么样”。FDA 和 NMPA 作为监管机构，发布的是“提交时必须满足什么”的法规性要求，包括电子提交的格式、数据集类型和验证规则。
一个常见的误解是把 CDISC 等同于交付标准。实际上 CDISC 是数据标准，它规定了 SDTM、ADaM、define.xml 等交付物的结构和内容规则；而 FDA 的 Study Data Technical Conformance Guide 和 NMPA 的《药物临床试验数据递交指导原则》才是把 CDISC 标准“翻译”为监管提交要求的文件。交付工程师需要同时掌握两层：底层是 CDISC 的数据模型，上层是监管机构的提交规范。
SDTM：原始数据的标准化组织
SDTM（Study Data Tabulation Model）是提交给监管机构的“原始数据”标准。这里的“原始”不是指未经处理的原始记录，而是指按照 SDTM 模型组织后的、可追溯至源数据的结构化数据集。SDTM 的核心是域（Domain）的概念，每个域对应一类观察或事件。例如 DM 域存放受试者人口学信息，AE 域存放不良事件，LB 域存放实验室检查结果。
SDTM 的规范边界体现在三个方面。第一，变量命名和角色固定：每个域有规定的变量列表，变量分为标识变量（如 STUDYID、USUBJID）、主题变量（如 AETERM）、时间变量（如 AESTDTC）等角色，不能随意增删。第二，受控术语约束：严重程度、结局、因果关系等字段必须使用 CDISC 受控术语（CT）中的取值，不能自造词汇。第三，结构规则：一个域内每条记录代表一次观察，通过 USUBJID 和 --SEQ 唯一标识，域之间通过 RELREC 等关系数据集建立关联。
实际交付中，SDTM 的常见问题集中在日期格式和部分日期处理上。ISO 8601 格式要求日期为 YYYY-MM-DD，但临床数据中经常只有“2023-05”或“2023”，此时必须按 SDTMIG 的规则使用 --DTC 变量并保留部分日期，不能擅自补全为具体日期。这个细节直接影响审评人员对数据可信度的判断。
ADaM：分析数据的标准化组织
ADaM（Analysis Data Model）是支持统计分析的数据集标准。与 SDTM 面向“收集了什么”不同，ADaM 面向“分析了什么”。ADaM 的核心原则是“可追溯性”和“可复现性”：每个分析数据集中的变量，必须能够追溯到 SDTM 中的源变量或明确的派生规则。
ADaM 的规范边界同样清晰。ADSL（Subject-Level Analysis Dataset）是每个受试者一行，包含治疗组、人群标志、基线特征等分析所需的受试者级变量，是所有其他 ADaM 数据集的“入口”。BDS（Basic Data Structure）用于时间点分析，如 ADLB、ADVS，其结构为“受试者 × 参数 × 时间点”。OCCDS（Occurrence Data Structure）用于事件类分析，如 ADAE。每个 ADaM 数据集必须附带元数据，说明变量来源和派生逻辑。
一个关键边界是：ADaM 中不应出现 SDTM 中没有的原始观察值。所有派生变量必须基于 SDTM 数据或明确的统计规则。例如，ADSL 中的 TRT01P（计划治疗组）来自 SDTM 的 DM 域，而 TRT01A（实际治疗组）可能来自 EX 域，两者的派生逻辑必须在 define.xml 中写清楚。
define.xml：交付物的“说明书”
define.xml 是数据交付包中最重要的元数据文件，它用机器可读的方式描述每个数据集、每个变量、每个受控术语的来源和派生规则。define.xml 的规范边界在于：它必须与数据集内容完全一致，不能出现“文档写了但数据里没有”或“数据里有但文档没写”的情况。
define.xml 通常包含几个核心部分：数据集元数据（ItemGroupDef）描述每个数据集的结构；变量元数据（ItemDef）描述每个变量的名称、类型、长度和来源；代码列表（CodeList）定义受控术语的取值；计算方法和注释（MethodDef、CommentDef）说明派生逻辑。监管机构的验证工具（如 FDA 的 Validator）会检查 define.xml 与数据集的一致性，任何不一致都可能导致提交被拒。
监管提交的实操边界
FDA 的电子提交要求以 Study Data Technical Conformance Guide 为核心文件，它明确了提交时必须使用 CDISC 标准、必须提供 define.xml、必须通过 Validator 检查等硬性要求。NMPA 的《药物临床试验数据递交指导原则》在框架上与 FDA 趋同，但在具体细节上存在差异，例如对中文注释的要求、对部分数据集的取舍规则等。
交付工程师在实际操作中需要关注几个关键边界。第一，SDTM 和 ADaM 的版本必须与监管机构当前接受的版本一致，不能使用过旧或过新的版本。第二，define.xml 必须使用监管机构指定的 schema 版本，且必须通过官方验证工具。第三，提交包中必须包含评审指南（Reviewer's Guide），说明数据集的整体结构、关键派生逻辑和已知问题。第四，所有日期、编码、术语必须符合 CDISC 受控术语的当前版本，不能使用已废弃的术语。
交付物之间的追溯关系
SDTM、ADaM、define.xml 三者之间不是孤立的文件，而是一个可追溯的链条。SDTM 是源，ADaM 是派生结果，define.xml 是两者的说明书。审评人员通过 define.xml 可以快速定位某个分析变量来自哪个 SDTM 变量、经过了什么派生逻辑。如果这个链条断裂，例如 ADaM 中的某个变量在 define.xml 中没有说明来源，审评人员就无法验证分析结果的可靠性。
因此，交付工程师在构建数据集时，应同步维护元数据。一个实用的做法是：在 SDTM 编程阶段就记录每个域的变量来源和派生规则，在 ADaM 编程阶段记录每个派生变量的计算逻辑，最后统一生成 define.xml。这样既能保证一致性，也能在监管问询时快速提供追溯证据。
总结来说，CDISC 定义了数据的内容标准，ICH 提供了框架性要求，FDA 和 NMPA 规定了提交的格式和验证规则。SDTM 负责原始数据的标准化，ADaM 负责分析数据的标准化，define.xml 负责描述两者的结构和来源。理解这些标准的边界和相互关系，是数据交付工程从“能交”走向“交得清楚、交得可信”的关键一步。