SDTMとはなんだろう？

このブログでは、SDTMに関するよくある質問に回答します。SDTMの目的からSDTMデータセットの作成まで、その間のすべての内容を網羅しています。まずは基礎からはじめましょう。

臨床試験における SDTM とは何ですか？

Study Data Tabulation Model（SDTM）は、CDISCのデータ標準規格の中でも最も重要なものの一つです。これは、ヒト臨床試験で収集されたデータを整理するためのフレームワークです。このモデルは、医療研究データの収集、処理、提出時に使用する標準規格を開発する組織であるCDISC（Clinical Data Interchange Standards Consortium）によって開発されました。　

組織は、米国食品医薬品局（FDA）、英国医薬品医療製品規制庁（MHRA）、および日本の医薬品医療機器総合機構（PMDA）に臨床データを提出する際、SDTM標準を使用する必要があります。　

SDTM 規格では、データの整理および表示方法を正確に規定しています。これにより、規制当局の審査担当者は、各データセットの構造、属性、内容、および臨床試験の一部として提出された変数を明確に把握でき、内容の解析が容易になります。

組織にもメリットがあります：研究がより一貫性を持つため、すべてが同じ標準形式で実施されるからです。これにより、データの共有と再利用が容易になります。

SDTMは、規制当局の審査担当者に、各データセットの構造、属性、内容、および臨床試験の一部として提出された変数について、明確な説明を提供するためのものです。

CDISC SDTMが適用される前は、異なる研究では各ドメインに対して異なる名称が使用され、異なる変数や変数名も使用されていました。業界全体での標準化は確立されていませんでした。

その結果、レビューアはデータ自体をレビューするのではなく、各データセットのドメイン名や変数名を確認し、データを標準形式に変換する作業に莫大な時間を費やすことになりました。これにより、最終的に臨床試験のプロセスが長期化しました。

CDISC SDTMは、データ収集をエンドツーエンドで標準化することを可能にします。それには下記のようデータが含まれます。

• 標準ドメイン名
• 各ドメインの標準的な構造
• 標準変数
• SDTMデータセットの標準名称

これは、あらゆる研究で収集されたデータの一切が、現在では容易に特定できることを意味します。規制当局はデータをはるかに迅速に審査できるため、プロセス全体が大幅に効率化されました。

注釈

ドメインの構造を形式化することで、適合ルールも策定されました。これらのルールは、Pinnacle 21 Enterprise などのソフトウェア検証ツールにプログラムされ、SDTM 臨床データセットの適合ルールに対するチェックを自動化しています。　
CDISC は、2 つの重要なモデルから SDTM 標準を構築しています。

1. 『コア』研究データ集計モデル – コアモデルは、標準化された変数セットを「クラス」に分類し、特定の用途（SDTM-IGドメイン）向けに精緻化され、変数コレクションとして構築されます。　例としては、バイタルサインの観測値、有害事象、医療歴の報告などが挙げられます。
2. SDT実装ガイド（SDTM-IG）

CDISCは常に新しい分野の開発を進めています。最新の更新情報を確認するには定期的にCDISCのウェブサイトをご確認ください。標準規格の更新に関する詳細はこちらをご覧ください。

SDTM実装ガイド（SDTMIG）は非常に重要な文書ですので、詳しく説明します。

CDISC による説明: 「SDTM は、ヒトおよび動物研究におけるデータの整理とフォーマットの標準モデルを提供しますが、SDTMIG は、標準的な臨床試験の集計データセットの整理、構造、およびフォーマットをガイドすることを目的としています。」

SDTMIG は、データを SDTM にマッピングまたは変換する際の重要なリソースです。SDTM マッピングまたは変換を試みる前に、このリソースに慣れることを強く推奨します。

「SDTMデータセット」とは、規制当局への提出を目的として、SDTM規格に準拠して作成されたデータテーブルを指します。データセットには、臨床試験の参加者に関する詳細情報が含まれており、これには訪問、治療、および観察結果が含まれます。

以下は、DM（デモグラフィック）ドメイン用のSDTM+データセットの例です。

SDTMを正しく実装するためには、そのドメインと構造を十分に理解することが重要です。

CDISCによると、SDTMドメインは「臨床試験においてすべての被験者から通常収集される、共通の特定のテーマを持つ論理的に関連する観察項目の集合体です。　注釈：この関係の論理は、データの科学的テーマまたは試験におけるその役割に起因する可能性があります。

SDTMドメインはいくつありますか？

SDTMドメインは次のクラスに分類されます：

• 専用ドメイン
• 一般的な観察クラス
• 所見
• 臨床試験デザイン
• 関係データセット

SDTMは、臨床試験に参加している被験者から収集された観察データに基づいて作成されます。観察とは、研究中に収集されたデータの一種です。例えば、「対象者12は、研究日5から軽い頭痛を訴えました」。など。

収集された観測データのほとんどは、一般的な観測クラス（データクラスとも呼ばれる）のいずれかに分類する必要があります。一般的な観察クラスは次のとおりです：

• 介入データセットは、プロトコルに従って被験者に施される治療法や手順を記録します。　 例として、曝露（EX）、併用薬（CM）、物質使用（SU）などがあります。例えば、タバコ、カフェイン、アルコールなどです。
• イベントデータセットは、プロトコルで定められた計画されたマイルストーン（例：ランダム化、研究完了）を捕捉します。　 研究開始前または研究中に発生する予期しない事象も捕捉されます。例として、有害事象（AE）、処置結果（DS）、医療歴（MH）があります。
• 所見は、身体検査、検査室検査、心電図検査など、特定の質問に答えるための観察結果を記録します。所見については、介入とイベントのクラスに関連するデータを記録します。例として、バイタルサイン（VS）、身体検査（PE）、検査室検査（LB）、および被検者特性（SC）があります。
• イベントと介入に関する所見は、例えば有害事象に関する詳細な情報を記録します。

一般クラスは、特定のドメインに属さないデータを分類するための枠組みを提供します。サブカテゴリは、カスタムドメイン用にさらに詳細な変数のコレクションを提供します。

ドメインとは、共通のテーマを持つ観測値のグループです。例えば、医療歴やバイタルサインなどが該当します。現在、クラス内に多数のドメインが収集されており、CDISCは継続的に新たなドメインの開発を進めています。各ドメインは、名前と関連する略称から構成されます。例えば、以下のリストはSDTMドメインの一覧です：

• 人口統計（DM）
• 訪問調査（SV）
• 有害事象（AE）
• 検査結果（LB）
• バイタルサイン（VS）

「一般観察クラス」に加え、以下の4つの特別クラスがあります：

• 特殊目的ドメインのデータセットには、人口統計（DM）、コメント（CO）、主題要素（SE）、および主題訪問（SV）が含まれます。
• 試験設計には、試験の設計を説明するデータセットが含まれます。例としては、試験要約（TS）、試験群（TA）、および試験訪問（TV）があります。
• 関係データセットは、データセットとレコード間の関係を表現します。

研究固有の用語を表現するための構造を提供する研究参照データセットを分析します。例には、デバイス識別子（DI）と非宿主生物識別子（OI）が含まれます。

各SDTMドメインは通常、ドメイン名と同じ名前が付いたファイル（例：AE.xpt）で構成されています。

SDTMにおける安全性領域には、被験者の安全性に関する情報（例：服用した医薬品や発生した有害事象など）が含まれます。

ドメインは、変数をドメインにマッピングするために使用される2文字のドメインコードでプレフィクスが付きます。例えば、ドメイン「医療歴」はドメインコード「MH」でプレフィクスが付与されています。変数 –SEQ（シーケンス番号）には、ドメインコードが必要であることを示す2つのハイフンが含まれています。したがって、例はMHSEQとなります。

別の例として、Vital Signs（VS）ドメイン内の変数 –TESTCD（テストコード）が VSTESTCD に変更されます。各ドメインには、関連するデータの集合であるデータセットがあります。SDTMデータセットは、一連の命名された変数によって記述されます。これらの名前付き変数それぞれは、その役割に応じて分類されています。

役割カテゴリは、変数に関する特定の種類の情報を伝達します。変数は1つの役割しか持つことができません。

1. 識別変数は、記録の識別子、対象、領域、およびシーケンス番号を特定するために使用されます。
2. トピック変数 は、観察の焦点を表します。
3. タイミング変数は、観測の日付、時刻、および期間を記述します。　　
4. クオリファイア変数は、観測結果をテキストまたは数値で記述します。　　　　
5. ルール変数は、計算やループ条件のためのアルゴリズムや方法を記述し、主にトライアル設計領域で使用されます。　　　　

以下の例では、変数の役割が表の上段に示されています。

クオリファイア変数はさらに以下のとおり分類されます：

• Grouping qualifiers group observations together.
• Result qualifiers describe the result for a finding.
• Synonym qualifiers contain another name for the observation.
• Record qualifiers define the supplementary attributes of an observation.
• Variable qualifiers describe the value of an observation.

Core variables are a measure of compliance with the specific SDTM-IG domain model. The value of a core variable shows the importance of the variable to the overall domain structure.

Variables are divided into 3 categories:

1. Required variables are needed to identify a data record, e.g STUDYID, and USUBJID. Or, they are needed to make a record easily understood, e.g TERM and TEST. They must always be included in the dataset and cannot be null.
2. Expected variables are needed to make a record useful within a specific domain. They must always be included in the dataset but they can be null for some records. If no data is collected, a comment must be included to explain why.
3. Permissible variables must be included in the dataset if results are collected or derived, but they can be left null or blank.

Variables from the parent class can also be inserted into the domain if required.

So how do you implement SDTM?

The following section explains how to map source datasets to SDTM domains, as well as important considerations, and other necessary deliverables needed for SDTM dataset creation.

The SDTMIG extends and refines the SDTM core model with specific domain implementations, business rules, assumptions, and examples. It should be used along with the relevant version of SDTM. So, make sure you have the correct versions of both of these documents.

Here are some basic steps to help keep you on the right track with your SDTM dataset creation:

1. Determine which SDTM domains to create.
2. Compare the SDTM data to the SDTM metadata and map directly where possible.
3. Map the rest of the source datasets to SDTM domains.
4. Map variables in the source datasets to the variables in the SDTM domains.
5. Decide whether custom domains and SUPPQUAL domains need to be created.
6. Perform the data conversion – find out about our mapping and conversion tools designed to help you do this.
7. Validate the SDTM datasets.
8. Generate and validate Define.xml.

There are several different types of SDTM mappings you can do for steps 2, 3, and 4 above.

• Directly map to a domain variable without making any changes.
• Rename the source variable name and label without the need to make any other changes.
• Map values to standard units or terminology.
• Change the format of a source variable.
• Combine two or more source variables to make a single domain variable.
• Split a single source variable into two or more domain variables.
• Derive a domain variable from one or more source variables using logic, computation, algorithm or decoding.

Remember, you might need to use more than one type of mapping to create an SDTM variable.

SDTM mapping can be a complicated task, so it’s important to plan everything out in advance. By creating a mapping specification, you’ll know where data came from, how it got there, and where it’s to go to.

The SDTM mapping specification is an important document that’s used when designing the process by which raw data will be converted to SDTM. This document specifies how the raw data is to be converted and is used by the SDTM programmer and testing team.

1. Examine the CRFs and raw data and identify which SDTM domains you need.
2. Against each SDTM domain, note which raw dataset will provide the input data.
3. Against each SDTM domain, list all variables and describe how they are to be programmed.

It’s important to use the SDTM model and Implementation Guide during the SDTM mapping process. Some organizations also enlist the help of data mapping software in order to maximize chances of success.

SDTM mapping specifications should be developed at the same time as annotating case report forms (CRFs). The mapping specification tells the user how to do a mapping. An annotated CRF is a visual representation of a mapping showing how the source data relates to the SDTM data.

As part of your submission to the FDA, you must provide a blank CRF. The file should be called blankcrf.pdf. Each question on the form must be manually annotated to show the origin of variables. It links the fields on the form with the variables in the dataset (the source of the data). Annotations help the reviewer find where variables come from in the submitted SDTM datasets.

SDTM has standard code lists for particular variables, containing allowable values for these variables. These allowable values should be used in submissions to the regulator, so ensure the SDTM datasets are CDISC compliant. You should always use the most up to date version of controlled terminology when you start to map your SDTM datasets. Find out more about using controlled terminology for standardizing data.

CDISC and NCI Enterprise Vocabulary Services partnered up to develop a standard controlled terminology. However, the CDISC / NCI controlled terms for Lab tests are not unique. They require additional information for differentiation.

Other medical dictionaries can be used, such as MedDRA and WHOdrug.

Over the last 25 years, the LOINC project has provided a standard classification for health measurements. Most SDTM programmers will encounter ‘LOINC Code’ information in Lab data. But the classification system has been extended to cover other measurements such as ECG.

So, what is LOINC? LOINC is an internationally recognized classification system which is often requested in regulatory data submissions to provide context to clinical measurement data, such as Labs and ECG.

The FDA requires a Define.xml file to be included for all drug submissions. It describes the content and structure of data collected during the study which are domains, variables, methods, controlled terminology, and supporting documents. The Define.xml file makes the review of study data quicker and easier for the FDA.

Another important CDISC standard is the Analysis Data Model, or ADaM. ADaM relates to the creation of analysis datasets and associated metadata. The standard allows you to generate figures, listings, and tables more easily, and ensures traceability. This means that reviewers can assess and approve a submission more quickly. ADaM is a little different to SDTM. It’s less strict, but like SDTM it has a core model and an implementation guide.

The main differences between ADaM and SDTM:

Find out 3 things you should know about ADaM standards.

While SDTM is about organizing and formatting your data ready for submission, the purpose of the Clinical Data Acquisition Standards for Clinical Research (CDASH) is to harmonize your data collection with your SDTM submission.

The Standard for Exchange of Nonclinical Data (SEND) defines standardized domains for non-clinical trial data, whereas SDTM is concerned with the organization and formatting clinical trial data. Find out about SEND Explorer, our validated, web-based application designed by scientists to provide advanced viewing, data summarization, and visualization capabilities for nonclinical study data.

There are many benefits of implementing SDTM in your clinical trials, including:

• Consistency across studies – with standards in place you don’t need to reformat your data to use in different systems or different studies.
• Improved data quality and fewer errors, because studies are created in accordance with agreed standards.
• Metadata reuse (such as case report forms, terminologies, datasets) means less time and effort spent on each study.
• Faster, easier internal reviews.
• More efficient process for acquisition, aggregation, analysis and reporting.

データ基準が適切に実施されていれば、提出時にFDAの要件を満たしていることを確信できます。