指导原则: Metadata Submission Guidelines v1.0

本文以下提到的例子可下载于CDISC官网 - Metadata Submission Guideline (MSG) for SDTMIG

http://www.cdisc.org/standards/foundational/study-data-tabulation-model-implementation-guide/metadata-submission

Study Data Tabulation Model Metadata Submission Guidelines (SDTM-MSG) V1.0 - Section 3: Define.xml中介绍了关于define.xml提交的标准， 翻译如下(非专业翻译，如有歧义， 以英文原版为准)

3.1 简介

define.xml文档详细说明了提交Case Report Tabulation Data Definitions的标准，该文档为XML格式，并用于提交给管理机构（如FDA）。define.xml本质上是描述所提交数据集格式和内容的元数据。元数据，以及用于描述元数据的stylesheet，由以下几部分构成。

    × Dataset-level元数据，通常指的是目录（Table of Content， Section 3.2）

    × Variable-level元数据，通常指的是数据定义表（Data Definition Tables， Section 3.3）

    × Value-level元数据（Section 3.4）

    × 控制术语表，通常指的是Codelists（Section 3.5）

    × 呈现xml文件的样式表（Stylesheet， Section 3.6）

    × Define.xml schema validation（Section 3.7）

3.2 Dataset-Level元数据

Dataset-level元数据提供了sdtm文件夹下关于每个数据集的基本信息。元数据的格式由define.xml说明预先定义。 "ItemGroupDef"元素在提交中被提供给每个SDTM数据集。 每个"ItemGroupDef"元素包含"ItemRef"元素的集合，这些"ItemRef"元素与SDTM数据集中的变量相关联。 SDTM variable-level元数据在"ItemDef"元素中进行描述。详见CRT-DDS。

对于数据集中没有观测的情况（例如，一个小型试验中没有伴随用药的受试者），空的数据集不应被提交，也不应在define.xml中进行描述。参见Section 4.1.1中关于如何对这种情况做注释的信息（译注：Section 4.1.1的翻译内容参见http://blog.csdn.net/bowen_wu/article/details/53423642）

3.2.1 组织

所有制表数据集，包括CDISC标准和sponsor定义的数据集， 必须包含在dataset-level元数据中，并且应当按SDTM类组织。在define.xml文件中，数据集应当在每个SDTM类中，按名称的字母表顺序排列。对于分裂域的情况，上述条件是不充分的，可以使用其他附加属性排序。

推荐的SDTM类的排序方式为

    Trial design datasets

    special-purpose domains

    intervention domains

    events domains

    findings domains

    relationship datasets

3.2.2 内容

dataset-level元数据的结构由define.xml的框架和说明预先定义。格式的呈现方式由sponsor选择的样式表定义。在没有发布指导的情况下，sponsor需要决定呈现哪种元数据属性。

def:Class

域的类别暗示了预定义的变量的集合，并且有助于数据的审阅和检验

def:Structure

结构的描述应当与数据集一致，并且可以与SDTMIG中的描述不同。

def:DomainKeys

如Table3.2.2.1所示，keys的主要目的是唯一识别数据集中的观测。keys相当于审阅者的助手，方便他们理解数据集的结构和排序。但是，不要求keys必须反映提交数据集的排序。

在材料中提供的提交范例中的keys仅作为例子，sponsor应当根据偏好和实际需要来设置数据集的keys。对于受试者相关数据，前两个keys通常为STUDYID和USUBJID。这些keys后面经常接主题变量和时间变量，可能是--term，--dtc（对于Event和Intervention域）或者--testcd，visitnum，--tptnum（对于findings域）。

3.3 Variable-Level元数据

Variable-Level元数据包含每个数据集中每个变量的属性。在define.xml中，每个变量由"ItemDef"元素表示，该元素用来描述对应变量的元数据。详见CRT-DDS。

标准化的数据集，比如Findings General Observation Class和SUPPQUAL数据集，由value-level元数据进一步描述。详见3.4节

3.3.1 组织

每个在datasetlevel元数据（define.xml "ItemGroupDef"）中列出的数据集都会有关联的variable-level元数据（define.xml "ItemDef"）。样式表中应当提供从在dataset-level元数据中列出的“Description”列到variable-level元数据中每个数据集的超链接。

在样式表生成的结果中，variable-level表中数据集的列出顺序应当与dataset-level元数据表中数据集的顺序一致。在样式表中，这一规则由“ItermGroupDef"和包含的”ItemRef"的嵌套循环来保证。参见样式表（define2-0-0.xsl）中关于该规则如何实现的说明。

每个数据集中的变量（在define.xml体现为"ItemGroupDef"中的"ItemRef"）必须根据SDTMIG Section 4.1.1.4中指定的顺序排序。样式表应当保证能够维护该排序。另外，define.xml中变量的顺序和数据集中变量的顺序必须是相同的。

3.3.2 内容

variable-level元数据的内容在define.xml框架和说明中预先定义。相关的样式表提供的展示的格式。

在define.xml说明中，ItemRef和ItemDef描述了variable-level的元数据。ItemRef列出了数据集中的变量，并且列出了在每个数据集中的变量顺序，角色和是否强制。ItemDef描述了变量的属性，如标签，数据类型，长度，来源。这种结构使得像STUDYID和USUBJID之类的通用变量，只需定义一次，但是可以在所有数据集中使用。

Variable-Level元数据包含以下项目

Type:

Type指的是提交变量的数据类型。最终提以XML的形式交给FDA数据，Type会反映XML的数据类型；但是，当前的数据是包含在SAS transport file中。define.xml和SAS data类型之间的对应关系在Table3.3.2.1中有描述。对于数值型变量，可能包含整型(integer)和浮点型(float)，浮点型数据应当制定足够的长度和精度来适应整个数据结果

Controlled Terms or Formats:

Controlled terms必须在define.xml中的codelist部分指定。在define中controlled terms列链接到table of terms。由于与变量相关联的控制术语表通过codelist定义， 不推荐将格式目录作为提交材料的一部分。因此，外部的SAS格式不应当应用到SDTM的变量中。注意到关联到数值列表的变量(如VSTESTCD，QNAM)一般不会与codelist关联，这是因为所有可能的数值列表是由数值列表描述（？？）

如果controlled terminology是基于外部字典（如MedDRA，WHODRUG），需要在define中加入外部字典部分的链接。

Origin:

SDTMIG中定义了多种origin的值。如果origin指定为“Derived”，那么或者在Comments field中指定导出的定义，或者参考computational method（def:ComputationMethod），或提供补充数据定义文档(def:SupplementalDoc)。

如果origin是aCRF中的页码，那么应当保证在样式表中设置关于aCRF中页码的超链接。如果一个form出现多次，那么只在origin field中列出第一次出现的情况。后续的页码不应列出。如果收集的变量或者预设信息在CRF做了注释，则origin必须是CRF。

Comments:

Comments主要用来定义数据的导出规则。 如果导出规则的叙述简单，可以直接将其放在Comments field中。如果叙述比较长，或者sponsor有偏好，可以选择在define.xml "def:ComputationMethod"元素中描述导出规则，并且从define.xml "ItemDef"中描述SDTM变量(define.xml "def:ComputationMethodOID")。样式表应当保证生成从"Comments"列到"Computational Algorithms"的超链接。多个变量可以链接到同一个computational method。

如果对于一个域中的特定变量的导出规则叙述比较长，并且包括复杂的逻辑和图表，那么可以用Comments列来提供一个链接到独立PDF文件的注释。这可以通过在样式表中搜索文本（如See Note xx）来实现，

3.4 Value-Level Metadata

标准化的SDTM Finding类数据和SUPP数据提供了一种高效的数据交换结构。 由于不同类型的观测值可能呈现在同一个结构中，从而有必要提供附加的元数据来描述数据集中数据的性质。比如， 如果VS数据集中收集了heart rate, weigth 以及 frame size， 其中heart rate是数值整数型，weight是数值浮点型，frame size是字符型。在审阅VS数据集的元数据时，这种差别不易被发现。 对于这种类型的标准化数据集，所有的--TESTCD以及每个--TESTCD对应结果的属性都应该被提供。对于一些情况，通过连接--TESTCD（如VSTESTC）可以获得一个完全列表，对于其他情况，则对于--TESTCD进行分层。详见下文讨论。 类似地， 对于SUPP数据集， 变量的列表（QNAM的值）以及它们的属性应当被提供。这一信息是“Value-level”的元数据，因为它的值是基于特定变量的值（--TESTC和QNAME的值）。 value-level元数据对于Findings Class和SUPP是必须的。对于Events和Interventions中的变量，value-level虽不是必须，但是十分有用。

value-level元数据的属性描述和variable-level元数据相同。 Name和Label属性列出所有可能的值和标签。 例如，在Finding Class数据集VS中， VSTESTCD的每一个可能的值都会被描述，并有对应VSTEST的值作为标签。对于SUPP数据集，QNAM的所有可能的值都会被描述，并有对应的QLABEL作为标签。

剩下的属性（DataType, CodeListRef, Orign, Comment等）描述变量的结果。对于SUPP数据集，这些属性描述QVAL。 对于包含原始值和标准值的FInding Class数据集，define.xml的机制只能描述其中一种值。如果原始值存在的话，元数据应当描述原始值。如果有必要，可以使用comment或者method描述标准值的导出规则。

以VS数据集为例说明以上概念。在define的variable-level表中，有关于变量VSTESTCD的超链接。 当variable-level ItemDef的子元素def:ValueListRef存在时，该超链接就会被创建。通过这个链接可以查询VSTESTCD的value-level元数据。注意如下几点：

1. 在value-level元数据表中，VSTESTCD的所有可能的值和标签都会被列出。define.xml元数据中的test code的值和标签和VS数据集中的VSTESTCD/VSTEST是对应的。

2. Data type反映每个test code的原始结果（VSORRES）的收集方式。数据类型（text, integer, float），长度， 和小数位数根据不同的test code有所变化。

3. Orign描述每个值的来源。在示例中，所有vital signs测试的结果都来源于CRF， 但是有可能测试的结果出现在CRF的不同页面上，或者多种来源并存，比如CRF和eDT。

4. 在示例中，Controlled Term or Format Column列出来FRMSIZE的codelist。 这个codelist提供了test code为FRMSIZE的测试结果（VSORRES）的所有可能的值。注意到在variable-level元数据中，VSORRES并没有关联codelist，因为这个codelist并不适用于所有的test结果。

在一些情况下，为了分组主题变量， 可能有必要对value-level元数据进行归类（“nest"），因为主题变量自身不具有特殊性，不能够展示属性信息。例如，如果试验收集了多个问卷，并且都储存在单个的QS数据集中，那么可以这样来描述数据，即首先给出基于参照QSCAT的value list。 这个value list用来描述每个问卷的手机来源。 然后将value list关联到每个QSCAT的值。 每个“次级”value list描述每个问卷中test code和结果的属性。同样地，当使用CDISC标准lab test code字典时，可能有必要按照lab specimen, method,等进行归类， 从而针对有相同test code但是结果类型不同的测试，提供适当的描述。 例如， serum glucose, quantitative urine glucose和qualitative urine glucose(dipstick) 三者共有同一个LBTESTCD的值（GLUC）， 但是可能具有不同的数据类型，来源，长度等属性。

Sponsor需要决定什么情况下使用必要的多水平结构，从而适当地描述test的属性。在示例中， QS，LB和IE都以--CAT进行归类。这只是一个例子，sponsor可以在define中进行自定义。

以上概念在示例中有详细展示。 关于进一步的补充说明可以参考Section 6.3.

对于问卷数据集需要注意如下几点：

1. 在variable-level表中，有链接关联到QSCAT。 打开链接可以看到QSCAT的value-level元数据。

2. 在value-level元数据表中，QSCAT的值描述了QS数据中的问卷内容。每个问卷的值是一个链接。这个链接导向每个问卷的test codes（问题）。

对于lab数据集需要注意如下几点：

1. 在variable-level表中，有链接关联到LBCAT。打开链接可以看到LBCAT的value-level元数据。

2. 在value-level元数据表中，LBCAT的值描述了测试的类别（CHEMISTRY, HEMATOLOGY, URINALYSIS）。每个类别都链接到specimen(LBSPEC) ,因为specimen记忆不定义了LBTESTCD的唯一性。这种区分是有必要的， 因为相同的LBTESTCD可能具有不同的LBCAT。

3. LBCAT=URINALYSIS使用了同一个LBTESTCD（GLUC）和同一个LBSPEC（URINE），从而需要通过method（LBMETHOD=DIPSTICK OR QUANT）进一步分类，来保证test的唯一性。

3.5 控制术语表

试验中所使用的控制术语表必须包含在SDTM元数据中，无论是Sponsor定义的，CDISC标准的，或是外部字典的控制术语表。所有可能的值都应当包含到define.xml中，除了外部字典中的术语。SDTM数据集变量的值必须与define.xml中的术语表一致，包括大小写。如果“MULTIPLE"是可能存在的值，则也应当包含在codelist中。这种推荐做法适用于sponsor自定义的或者CDISC标准的codelist， 包括那些non-extensible的codlist。 可以参考示例中DM.RACE。在value-level元数据（--TESTCD，--TEST）中体现的值不必重复出现在define.xml的术语表中。 需要注意，在value-level中，the codelist is associated with the --ORRES variable as opposed to either the --STRESC or the --STRESN variables.

3.5.1 Define.xml

3.5.2 CDISC控制术语表

CDISC控制术语表经常更新。目前有一种阶段性的方法来开发控制术语表。推荐sponsor使用CDISC定义的控制术语表，该术语表需要一个计划性过渡。 如果sponsor决定将现有数据集映射到CDISC术语表， 映射规则的解释需要被提供。最简单的情况是，这种映射规则通过CRF注释来实现。对于其他一些情况，define.xml中的comments域可以指明映射的规则。如果sponsor数据到SDTM属于表的映射不清晰，可以进一步在comments或者补充数据中提供解释。

3.6 Define.xml的样式表(Stylesheets)

样式表是将XML文件转换成另外一种格式的工具。样式表的一种使用方式是动态地将XML转换为HTML， 从而可以在浏览器中方便地展示查阅XML文档的内容。设计XML是为了储存数据，样式表是为了展示数据。当提交define.xml至FDA时，样式表是必须的。

在CDISC网站可以下载基本的样式表，或者sponsor可以使用示例中给出的样式表。 CDSIC计划开发样式表。目前，sponsor可以选择开发自己的样式表，或者修改示例中的样式表。示例中的样式表将最低限度的信息展示给审阅者，但同时也包含了一些功能， 如书签，连接导航功能。

3.7 Define.xml Schema Validation

Define.xml schema需要在提交之前进行验证。可以再CDISC网站下载XML Schema Validation白皮书:

http://www.cdisc.org/stuff/contentmgr/files/0/464923b10ea16b477151fcaa9f465166/misc/definereport_v1_0.pdf