Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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作成標準プロセス
SDTM作成標準プロセス
7
各社のプロセスを集積
プロセス検討
13社からのプロセス
4グループに分類 (作成者、データの種類より)
Ongoing試験 Legacy試験
自社作成 グループ1 グループ2
CRO作成 グループ3 グループ4
作成担当者データの種類
グループ化
本発表では、下記のように定義
• Ongoing試験 : SDTM作成を試験実施中に行う試験• Legacy試験 : SDTM作成を試験の固定後に行う試験
必須プロセスは4グループで共通
標準プロセス 試験に依存しないプロセス試験毎のプロセス
SDTM作成標準プロセス
8
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備試験毎のプロセス
試験に依存しないプロセス
CRO委託
社内作成
社内部門間連携
SDTM作成標準プロセス
9
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備
SDTM作成標準プロセス–CDISCで申請する際の部門間連携-
10
社内部門間連携
社内標準の作成・維持管理
申請までのスケジューリング
電子データ作成(e.g. SDTM, ADaM, Define.xml…)
e-CTD作成
申請前相談
多部門間連携
申請パッケージ決定とCDISC対応状況の調査
SDTM作成標準プロセス
11
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備試験毎のプロセス
試験に依存しないプロセス
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が必要
SDTM作成標準プロセス
15
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備試験毎のプロセス
試験に依存しないプロセス
SDTM作成標準プロセス–試験毎のプロセス-
16
• プロトコール
– 英語版プロトコール (一部、またはすべて英訳)– Controlled TerminologyのTermを利用
• CRF– 英語版CRF– (CDASHを考慮したCRF設計)
• 試験データベースセットアップ
– SDTM作成担当者によるデータベース定義書のレビュー
試験実施準備
SDTM作成標準プロセス
17
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備試験毎のプロセス
試験に依存しないプロセス
SDTM作成標準プロセス–試験毎のプロセス-
18
• SDTM仕様書
• SDTMバリデーション計画書
• Annotated CRF for SDTM• SDTM変換プログラム
• 解析関連仕様書
(e.g. ADaM仕様書)• CRF外情報のデータ化
(e.g.プロトコール逸脱、採否)
SDTM作成準備
SDTM作成標準プロセス–試験毎のプロセス-
19
• SDTM仕様書 様式
– SDTMへのマッピング
– Define.xmlで要求されている情報の定義
SDTM作成準備
• スケジュール
– タイムラインが今まで以上に重要
– 後工程との連携強化(タイムラインに影響しないように)
Define.xml のMetadata(一部)
SDTM作成標準プロセス–試験毎のプロセス-
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作成準備
SDTM作成標準プロセス
21
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備試験毎のプロセス
試験に依存しないプロセス
SDTM作成標準プロセス–試験毎のプロセス-
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
SDTM作成標準プロセス–試験毎のプロセス-
• PKデータの取り扱い
– PKデータプロセスの検討が別途必要
検討事項
・ 作成フロー
・ 作成担当者
・ Validation方法
・ Define.xml作成 など
SDTM作成
当局の見解待ち
SDTM作成標準プロセス
24
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備試験毎のプロセス
試験に依存しないプロセス
SDTM作成標準プロセス–試験毎のプロセス-
25
• Define.xml作成のためのツール
– OpenCDISC (version 2.0 以降を推奨)– SAS– その他
Define.xml作成
SDTM作成標準プロセス
26
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備試験毎のプロセス
試験に依存しないプロセス
27
• SDTMデータレビューツール
(e.g. OpenCDISCバリデーションツール, チェックリスト)→多くの企業がOpenCDISCバリデーションツールなど、チェックツールを用いて確認。
※Define.xmlとSDTMのCrossチェックもOpenCDISC バリデーションツールにて可能
• 頻度・タイミング
– SDTM作成後の作業プロセスに合わせ、決定
※試験早期段階からOpenCDISCを実行すると・・・
→“見かけの上の”エラーが多発
(データが途中段階であることにより)
→一方で見逃していたエラーなども見つかることも
• SDTMバリデーション報告書作成
SDTMデータレビュー (QC)
SDTM作成標準プロセス–試験毎のプロセス-
SDTM作成標準プロセス–試験毎のプロセス-
28
• OpenCDISCバリデーションツールで検出できないエラー
– SASプログラムで確認可能
・ マルチバイト文字 (e.g. 全角文字、特殊文字)※versionによってはOpenCDISCで検出可能なものもある
– 目視チェックにて確認が必要
・ SDTM仕様書との不一致 (e.g. 導出変数)・ SDTMへの変換漏れ
・ Sponsor Defined Controlled Terminologyとの不一致
SDTMデータレビュー (QC)
バリデーション
SDTM作成標準プロセス–試験毎のプロセス-
29
SDTMデータレビュー (QC)
チェックリスト作成
チェックリストによる、マニュアルチェックSDTM aCRF/SDTM仕様書とRawデータ間で
(対象症例はサンプリング抽出)
OpenCDISCによる
バリデーション
SDTMバリデーション報告書
SDTMデータレビュープロセス 一例
Reviewer’s guide
必要に応じてSDTM aCRF/SDTM仕様書、SDTM変換プログラムの修正
SDTM作成標準プロセス
30
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備試験毎のプロセス
試験に依存しないプロセス
SDTM作成標準プロセス–試験毎のプロセス-
31
• (Ongoing試験では)試験終了後速やかにReviewer’s guideを完成させることを推奨– Open CDISCの解決できないWarningを記載する必要がある。
• 申請時に作成すると試験実施時のSDTM作成方針が不明になることもある。
• OpenCDISC バリデーションツールの解決できないWarningの一例
– 単位のない臨床検査項目 (A/G比)– Controlled TerminologyのExtensibleが「Yes」の項目にて
追加したTerminology
Reviewer’s guide作成
CRO委託
社内作成
社内部門間連携
SDTM作成標準プロセス–CROに作成委託する際の留意点-
32
社内標準の作成・維持管理
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
試験実施準備
SDTM作成標準プロセス–CROに作成委託する際の留意点-
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委託
SDTM作成標準プロセス–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作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
DB固定試
験中
SDTM作成準備
SDTM作成
Define.xml作成
SDTMデータレビュー (QC)
Reviewer’s guide作成
準備
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試験への適応検討など様々な対応事項がある。
CDISC導入時及び導入後の留意点 (2)
44
• CROに業務委託する前に委託先の選定評価項目を決める
・CDISC標準対応に関する知識・経験・プログラミング能力,経験・品質管理体制・業務フロー・作成期間(Legacy試験)・DB Lockからデータ提供までの所要日数(Ongoing試験)
• SDTM作成スケジュールはCROによって3~5ヶ月くらいの違いがあった。
• プログラム納品不可であるCROもある。
CDISC導入時及び導入後の留意点 (3)
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