SDTM作成プロセス事例と課題...– Define.xmlで要求されている情報の定義 SDTM作成準備 • スケジュール – タイムラインが今まで以上に重要

1

2014年12月4日

製薬協データサイエンス部会

タスクフォース2 サブチーム3

SDTM作成プロセス事例と課題

目次

2

• 発表の背景

• SDTM作成標準プロセス

– 試験に依存しないプロセス

– 試験毎のプロセス

– CROに作成を委託する際の留意点

– Legacy試験/Ongoing試験留意点

• まとめ

• (Back up) SDTM作成に関する経験談

3

発表の背景

発表の背景

4

製薬協データサイエンス部会タスクフォース2「CDISC標準の適正かつ効果的な利用の推進」

CDISC標準に関する教育（主にCDISC標準未導入製薬企業のために）

CDISC標準に関する技術的な内容の検討

CDISC標準のEnd to End での利用推進

サブチーム1緊急課題

サブチーム3短期的課題

(当たり前品質*)

サブチーム4長期的課題

(魅力的品質*)

*Kano, Noriaki; (1984). "Attractive quality and must-be quality". Journal of the Japanese Society for Quality Control

サブチーム3: CDISC標準に関する技術的な内容の検討短期的課題 (当たり前品質)

発表の背景

5

活動内容:SDTM作成プロセスを技術的な側面から検討

各社より、SDTM作成プロセスを集積

標準プロセスとして発表

6

SDTM作成標準プロセス


7

各社のプロセスを集積

プロセス検討

13社からのプロセス

4グループに分類（作成者、データの種類より）

Ongoing試験 Legacy試験

自社作成グループ1 グループ2

CRO作成グループ3 グループ4

作成担当者データの種類

グループ化

本発表では、下記のように定義

• Ongoing試験 : SDTM作成を試験実施中に行う試験• Legacy試験 : SDTM作成を試験の固定後に行う試験

必須プロセスは4グループで共通

標準プロセス試験に依存しないプロセス試験毎のプロセス


8

社内標準の作成・維持管理

SDTM作成準備

SDTM作成

Define.xml作成

SDTMデータレビュー (QC)

Reviewer’s guide作成

試験実施準備試験毎のプロセス

試験に依存しないプロセス

CRO委託

社内作成

社内部門間連携


9


SDTM作成準備

SDTM作成

Define.xml作成



試験実施準備

SDTM作成標準プロセス–CDISCで申請する際の部門間連携-

10



申請までのスケジューリング

電子データ作成(e.g. SDTM, ADaM, Define.xml…)

e-CTD作成

申請前相談

多部門間連携

申請パッケージ決定とCDISC対応状況の調査


11


SDTM作成準備

SDTM作成

Define.xml作成





12


SDTM作成標準プロセス–試験に依存しないプロセス-

• CDISC standardsに基づいた標準ドキュメントの作成、維持

標準化されることが望ましいドキュメント

• CRF/EDC仕様書

• 入力マニュアル

• Sponsor Defined Controlled Terminology• SDTM作成ガイドライン

• SDTM仕様書

• Annotated CRF for SDTM• Reviewer’s Guide

SDTM作成標準プロセス–試験に依存しないプロセス-

13

• 英語化のルール (日本語試験の場合)• CDISC Standards Version up 時の対応

(e.g. SDTM, Define.xml, Therapeutic Area Standards)• Controlled Terminology更新時の対応

(Sponsor Defined Controlled Terminologyを含む)• バリデーションプロセス

(e.g. 社内標準バリデーション計画書)• 標準Deliverableのプロセス

(e.g. プロトコール, CRF, SAP, SDTM, ADaM, TLFsのmock)


Sponsor Defined Controlled Terminologyの例

14

1. “Codelist Extensible”がYesの場合: Terminologyが追加可能

2. SDTM IGにて指定されているVariable: Sponsor Defined Controlled Terminologyが必要


15


SDTM作成準備

SDTM作成

Define.xml作成





SDTM作成標準プロセス–試験毎のプロセス-

16

• プロトコール

– 英語版プロトコール (一部、またはすべて英訳)– Controlled TerminologyのTermを利用

• CRF– 英語版CRF– (CDASHを考慮したCRF設計)

• 試験データベースセットアップ

– SDTM作成担当者によるデータベース定義書のレビュー

試験実施準備


17


SDTM作成準備

SDTM作成

Define.xml作成






18

• SDTM仕様書

• SDTMバリデーション計画書

• Annotated CRF for SDTM• SDTM変換プログラム

• 解析関連仕様書

(e.g. ADaM仕様書)• CRF外情報のデータ化

(e.g.プロトコール逸脱、採否)

SDTM作成準備


19

• SDTM仕様書様式

– SDTMへのマッピング

– Define.xmlで要求されている情報の定義

SDTM作成準備

• スケジュール

– タイムラインが今まで以上に重要

– 後工程との連携強化（タイムラインに影響しないように）

Define.xml のMetadata（一部）


20

• Annotated CRF for SDTM (SDTM aCRF) 作成

– SDTM Metadata Submission Guidelines(SDTM MSG)(SDTM aCRF作成の際に参考になる)

– SDTM作成前にSDTM aCRFを準備すると・・・→CRF-SDTM 変換もれの確認が容易

→ADaMの仕様検討が容易 (ADaM作成担当者)※CRFの改訂時はSDTM aCRFも変更が必要

• SDTM変換プログラム作成

– プログラムバリデーション (e.g. ダブルプログラミング)

SDTM作成準備


21


SDTM作成準備

SDTM作成

Define.xml作成






22

• ドメイン作成順の事前検討

– Trial Design Model(TDM)は先行作成

（特にTA, TE, TV）※試験デザインによっては、実データに

合わせてTDMを変更 (e.g. Oncology試験など

、時点数（サイクル数）がプロトコールで決められて

いない場合)

– 循環参照に注意

※循環参照の例：同意取得日

両変数のOriginが”Derived”にならないよう注意

SDTM作成

Trial Design Model

DM

SE, SV

General Observation ClassSUPP--

RELREC, CO

CRF

同意取得日

DMRFICDTC

DSDSSTDTC

SDTM

循環参照

作成順例

23


• PKデータの取り扱い

– PKデータプロセスの検討が別途必要

検討事項

・作成フロー

・作成担当者

・ Validation方法

・ Define.xml作成など

SDTM作成

当局の見解待ち


24


SDTM作成準備

SDTM作成

Define.xml作成






25

• Define.xml作成のためのツール

– OpenCDISC (version 2.0 以降を推奨)– SAS– その他

Define.xml作成


26


SDTM作成準備

SDTM作成

Define.xml作成





27

• SDTMデータレビューツール

(e.g. OpenCDISCバリデーションツール, チェックリスト)→多くの企業がOpenCDISCバリデーションツールなど、チェックツールを用いて確認。

※Define.xmlとSDTMのCrossチェックもOpenCDISC バリデーションツールにて可能

• 頻度・タイミング

– SDTM作成後の作業プロセスに合わせ、決定

※試験早期段階からOpenCDISCを実行すると・・・

→“見かけの上の”エラーが多発

（データが途中段階であることにより）

→一方で見逃していたエラーなども見つかることも

• SDTMバリデーション報告書作成




28

• OpenCDISCバリデーションツールで検出できないエラー

– SASプログラムで確認可能

・マルチバイト文字 (e.g. 全角文字、特殊文字)※versionによってはOpenCDISCで検出可能なものもある

– 目視チェックにて確認が必要

・ SDTM仕様書との不一致 (e.g. 導出変数)・ SDTMへの変換漏れ

・ Sponsor Defined Controlled Terminologyとの不一致


バリデーション


29


チェックリスト作成

チェックリストによる、マニュアルチェックSDTM aCRF/SDTM仕様書とRawデータ間で

(対象症例はサンプリング抽出)

OpenCDISCによる

バリデーション

SDTMバリデーション報告書

SDTMデータレビュープロセス一例

Reviewer’s guide

必要に応じてSDTM aCRF/SDTM仕様書、SDTM変換プログラムの修正


30


SDTM作成準備

SDTM作成

Define.xml作成






31

• (Ongoing試験では)試験終了後速やかにReviewer’s guideを完成させることを推奨– Open CDISCの解決できないWarningを記載する必要がある。

• 申請時に作成すると試験実施時のSDTM作成方針が不明になることもある。

• OpenCDISC バリデーションツールの解決できないWarningの一例

– 単位のない臨床検査項目 (A/G比)– Controlled TerminologyのExtensibleが「Yes」の項目にて

追加したTerminology


CRO委託

社内作成


SDTM作成標準プロセス–CROに作成委託する際の留意点-

32


SDTM作成準備

SDTM作成

Define.xml作成



試験実施準備


33

• 委託業務内容の決定例（SDTM作成を依頼する場合を想定）

– SDTMマッピング作業

– プログラミング、SDTMデータセット作成

– Define.xml作成

– OpenCDISCバリデーションツール実施

– Reviewer’s Guide作成

• CRO選定

• 情報提供（プロトコール, CRF, Raw Data, Raw Data Spec, SDTM関連社内標準ドキュメント等）

• 業務手順書（SDTM変換計画書等）作成、タイムライン合意

• 納品物 (SDTMデータ, SDTM作成プログラム, QC結果 (OpenCDISC実行結果及びマニュアルチェック結果), Define.xml, Reviewer’s guide等 )

• データ納品時には品質保証の陳述書を受領している企業もある。

CRO委託


34

• 自社のマッピングポリシー (特に、SDTM IGに定められていない箇所)• 項目名やコードの管理体制

• CROにおけるSDTM作成手順、作成期間の確認

• プログラム納品可否

• SDTMのバリデーション方法

(e.g. OpenCDISC実行の有無）

• プログラムバリデーション

• 経験 (e.g. 作成範囲、FDA申請有無、Legacy Data Conversion経験)

CRO委託

SDTM作成標準プロセス–Legacy試験/Ongoing試験留意点-

35

SDTM作成準備

SDTM作成

Define.xml作成



DB固定試

験中

SDTM作成準備

SDTM作成

Define.xml作成



準備

Legacy 試験 Ongoing 試験

完成完成

完成完成

*Legacy試験: SDTM作成を試験の固定後に行う試験

*Ongoing試験: SDTM作成を試験実施中に行う試験

本発表におけるLegacy試験/Ongoing試験の定義

SDTM作成標準プロセス–Legacy試験/Ongoing試験留意点-

36

• Controlled Terminology– Ongoing試験: 使用するControlled Terminologyはあらか

じめ決めてから試験開始。

– Legacy試験: 使用された用語がControlled Terminologyに存在するかどうか

まとめ

37

• SDTM作成標準プロセス

– 試験に依存しないプロセス

– 試験毎のプロセス

• DM/統計のみならず関連部門とともに標準化を進めていく必要がある

• CROにSDTM作成業務を委託する場合でも、社内でCDISC標準や関連する資料の理解が必要

メンバー

38

会社名名前

中外製薬株式会社根来茂樹(リーダー)

大塚製薬株式会社川又健一郎

(株)三和化学研究所中澤徹

キッセイ薬品工業株式会社

羽田純子

杏林製薬株式会社加藤木都

サノフィ株式会社小出紀子

ゼリア新薬工業株式会社大塚晶仁

会社名名前

大鵬薬品工業株式会社久田大輔(サブリーダー)

東レ株式会社黒川敬弘

富山化学工業株式会社松元靖浩

鳥居薬品株式会社田中久貴

日本たばこ産業株式会社乙黒俊也

マルホ株式会社武貞智紀

大日本住友製薬株式会社上町浩子

日本ベーリンガーインゲルハイム株式会社

長谷川秀美(発表者)

39

(Back up)SDTM作成に関する経験談

CDISC導入に際し苦労した点やもっとこうしたら良かったと思った点 (1)

40

• CRF標準集をDM以外の臨床試験を動かすメンバーを巻き込

み検討・了解を取ること

– CRF上モニタリングで必要な部分と申請データとして必要な

部分を明確にさせること

– プロトコルモデルドキュメントとCRF標準集が互いに影響して

いるので調整に時間がかかる

– 収集データ項目毎に定義(解説・入力見本・フォロー方針)を明確にする必要があった。

• SDTM作成の一貫性を持たせるためのSDTMガイドライン作成

• SDTMを利用する以降のプロセスの方(統計)と事前に業務切り

分けを明確にしておくこと

CDISC導入に際し苦労した点やもっとこうしたら良かったと思った点 (2)

41

• CDSIC標準の全体像を理解しないままSDTMデータセットを作成/業務委託を開始したため、出来上がった仕様書やデータセットを確認する視点がなく，ミスや修正が多く発生している。

• CDISCに対する理解が浅く、手探りで作業を進めたため、なかなか前に進まなかった。一度もSDTMを作成していない段階で，手

順やメリットについて検討しすぎた。まずは作成してみてからメリット・デメリットを検討した方が効率的だった。

• SDTM Implementation Guidelineなどガイドラインの勉強が必要。関連資料が全て英語のため、英語の理解に時間がかかる。

• プロセスが完全にFixしてからImplementすべきであった。中途半端であったため、Reworkがかなり生じた。Legacyの遺産（Standard macro programなど）を使うために、複雑なプロセスが発生した

• Pilot Projectは、できるだけシンプルな試験にするべきであった。

42

CDISC導入に際しどのくらいの工数と時間がかかったか

• 社内標準作成 (例)– CRF集(解説書・入力見本・フォロー方針) 約1.5年

• eCRF global library 0.5年

– SDTMガイドライン約0.5年

– SDTM変換ツール導入

• 評価・Validation記録 0.8年

• カスタマイズ 0.5年

CDISC導入時及び導入後の留意点 (1)

43

• 社内教育

– 最終的にSDTM・ADaMが完成すればよいと考えている方へCDISC標準のメリットを知ってもらう

– End to Endで行うことがプロセスで品質を確保することができ最終的に効率的で質の高いデータ*を提供することができる事を理解してもらう

*質の高いデータエラーや不備を全く含まない完璧なものではなくたとえ意思決定後にエ

ラーや不備が発見されたとしても既に行われた意思決定を変更する必

要がないデータ。

– 継続的なCDISC標準の勉強は必要である。誰か一人代表者が勉強して

その人のフィードバックを待つよりもメンバー各自が積極的に社外で情報収集，勉強した方がよい。

– CDISC導入後：SDTMのバージョンアップや新たなガイドラインなどに関して、グループ員への教育、どの試験から適応するか？Ongoing試験への適応検討など様々な対応事項がある。


44

• CROに業務委託する前に委託先の選定評価項目を決める

・CDISC標準対応に関する知識・経験・プログラミング能力，経験・品質管理体制・業務フロー・作成期間（Legacy試験）・DB Lockからデータ提供までの所要日数（Ongoing試験）

• SDTM作成スケジュールはCROによって3～5ヶ月くらいの違いがあった。

• プログラム納品不可であるCROもある。


45

• 申請までのスケジューリング：Legacy DataのConversionが必要な場合、申請時期を考慮し、SDTM・ADaMの作成完了時期をスケジューリングする必要がある。

(申請直前に申請パッケージに試験を追加するとSDTM、ADaM及びTFLsの完成が律速になることもある。)

CDISC導入のメリット・デメリット

46

• メリット

・変数とその内容が決められているので、データの理解が容易

・ CDISC標準のメンテナンスはCDISCがしてくれる

• デメリット

・自社標準のマクロプログラムが使えなくなった

・ SDTMのデータ作成までがDMの責任範囲となり、従来CRF dataの固定までが責任範囲だった時と比べ業務が増えた。

・解析データを作成する際、”SUPP—”は扱いづらいと解析プログ

ラマーからコメントあり。

(SUPP--の内容が煩雑でADaM担当者が理解しにくい。)・今までは同じデータセットに含まれていたデータが別のデータセッ

トになる。（例：AE情報（AE）とAEのコメント欄（CO））

CDISC導入により何が変わったか

47

• 導入前は各DMシステムやCROでDMからの固定データの仕様が

異なっていたので、解析担当者は固定データの理解から始めなくてはならなかったが、SDTMを利用することで解析に渡すデータの標準化ができるようになった。また、EDCやCRFへの標準化への意識も出てきた。

• これまでの業務にCDISC業務がプラスされたので、業務量が増えた

• 外部委託のコストが増えた

• SDTM変換しないときでも、DBの変数名の付与方法はSDTMに

従っており社内標準もだいぶできていたので、それなりに効率はよかった。が、SDTMに変換するようになり、業務が増えた印象があ

り、今のところ時間とコスト削減にはつながっていない。長い目で見て、申請時のデータ統合はSDTMでよかったと思えるのかもしれない。

• 標準ライブラリ、プロセス、Validationの種類

何を目標とし、何から手をつけたか(1)

48

• 最低限の運用を目的とし、社内標準の作成

• 社外活動へ参加し、情報収集

• テスト的にCROにSDTM作成を依頼し、IGの理解を確認

• CDISC管理チームの作成と担当業務の確認

• SDTM作成フローの作成

• Sponsor Defined Controlled Terminologyの管理のためのルール決め

• 第一選択として自社作成を目標にし、Legacy dataのconversionを実施することで、実現可能性を検討した

• 標準CRF、標準DBの作成を目標とし、各ドメイン毎にCDASH、SDTMと従来のCRF、DBとの差分比較を行った。その後、標準CRFについては開発部と協議し、データ項目を決定した。

何を目標とし、何から手をつけたか (2)

49

• SDTMを理解しADaMを含めた解析プロセスを検討することを目標に，Legacy dataでSDTMデータを作成してみた。

・ 2011年：初めてSDTM変換を実施（CRO委託）

・それまでSDTM IGの勉強などはしていた。

・ Trial domainの作成はなしで臨床データの変換のみを実施。

・経験してみようということで、とりあえずSDTMができたら目標達成。

• Legacy data （安全性関連のみ）のSDTM変換を行った。IGでほぼ理解可能なSDTMの一部（DM, DS, EX, AE, MH, LB, VS等、最大10ドメインのみ）の変換をCROに委託した

• データベース固定時に、「CRF OriginのデータがきちんとSDTMに反映されているか」に注力した。そのために、追加のValidationを行った。

• Legacy試験をSDTMに変換した。

具体的にどのような流れで目標まで達成したか(1)

50

• CDISCの公式トレーニングやCJUG (CDISC Japan User Group)活動に参加し、IGの知識習得に努めた。

• SDTMにmappingしやすい標準DBを作成するため、従来のデータベース定義と、SDTM IGに示される各ドメインの差分を抽出した。また、CDASHを考慮して、CRFの標準データ項目を検討している。なお、並行して、SDTMやSDTM IGの社内勉強会を実施した。

• 社内のDM・解析メンバーでCDISC対応チームを結成→メインメンバー（1人）が作成手順などを準備→ドメイン毎に担当を分けデータを作成し，相互レビューを通じてSDTMを理解→SDTM完成後，解析プロセスをどこから含めるか検討

具体的にどのような流れで目標まで達成したか(2)

51

• CROに業務委託し、マッピングのみ社内で実施（今は委託している）。

• CROに業務委託⇒CRO作成のマッピング仕様書をレビュー⇒SDTM変換⇒再集計・CSRの結果と比較

• Validation実施（Open CDISC、チェックリストを使用）

• CDISCに関する情報収集・知識習得。SDTM，SDTM IGを一通り読んで内容を理解する。

• マッピング・変換ルール作成を通して，SDTMを作成できる知識・能力を身につける。

• 各ドメインの役割を理解し，マッピングを汎用性が高いと考えられるAE，DMドメインから順に作成する。

何が一番大変だったか

52

• CROに委託すればSDTMができると思っている人達の意識改革

• マッピング（変数のマッピングだけではなく、日本語のControlled Terminologyへのマッピングも大変悩ましい）

• メインメンバーの準備に負荷が掛かった（仕様書のテンプレートや引用元となるドメイン（DM, SE, SVドメイン）の作成など）

• 自分たちでSDTMを作成したのでマッピング（変数名やロジックの記載）が大変。

• Legacy dataの場合、マッピングできない項目が出てきてしまう。

• Open CDISCのResultの理解。チェックリストの妥当性の理解。

• 作成したドメインが正しいのかどうかが不明。

実作業で工夫した点でよかったこと

53

• 社内体制を作成したことでDM担当者、SDTM管理チームの業務体制が明確になった

• 実装上の課題について、DM・統計で検討と共有を定期的に実施した

• 標準CRF、標準DBの検討時に統計担当者も参加し、データ項目の変化を共有しつつ作業を進めている

• 仕様書とプログラム作成を並行したので，データを見ながら仕様書を確認できたので，理解を深めやすかった

• 初めてSDTMを作成した時は、3人で担当し1ドメインを2人で分担した。

振り返ってみて反省点はどのようなこと?

54

• DM・統計以外の部門への教育が後手になってしまい、理解や協力が得にくい人もいた。

• マッピング（変数名やロジックの記載）が大変なので、次回は委託してこちらはレビューのみ行うことを考えた。

• マッピング仕様のレビューに時間をかけるべきだった

• Standard Teamにお任せではいけない。新たな変数が発生した際、実担当者がSDTMに合わせて変数を作成できるような知識を持つべき。

どのくらいの工数と時間がかかったか、また次の試験の業務において、工数、時間は短縮したか

55

• レビューなどにどのくらいの日数が必要かという目安ができた。同じCROに委託することでその時間はさらに短縮可能という感度も得られた。

今後、これから業務開始するにあたり、留意すべき点のアドバイス

56

• SDTM IGだけではなく、Therapeutic areaドメイン仕様書やFDA, CDISC及びその他関連団体の通知を読むことが必要。

• SDTM IGは不明瞭な記載が多いので、各社でConventionを作成した方がよい。

• 会社で管理する人はいた方がいいと思う。そのメリットとしては、CDSICなどの国内外の情報収集、一元化。それらの社内への適応。プロジェクトでの統一、一貫性が考えられる。

• CROに委託するのであれば、考え方、変換方針を一致させることが重要（conformanceが重要）。

• SDTMの経験のあるCROは増えてきているが、Define.xmlやReviewer’s Guideの作成経験は少なさそう。

• SDTMのTraining

Documents

SDTM作成プロセス事例と課題...– Define.xmlで要求されている情報の定義 SDTM作成準備 • スケジュール – タイムラインが今まで以上に重要