Clinical Data Acquisition Standards Harmonization

Clinical Data Acquisition
Standards Harmonization (CDASH)
Prepared by:
CDISC CDASH Core and Domain Teams
Revision History
Document Number
Release Date
Updates
CDASH_STD-1.0
01/OCT/2008
Initial release
Note: See “7.7 Representations and Warranties, Limitations of Liability, and Disclaimer.”
CDISC, Inc.
15907 Two Rivers Cove, Austin, Texas 78717
http://www.cdisc.org
© Copyright 2008 by CDISC, Inc.
All rights reserved. No part of this publication may be reproduced without the prior written consent of
CDISC.
CDISC welcomes user comments and reserves the right to revise this document without notice at any
time. CDISC makes no
representations or warranties regarding this document. The names of actual companies and products
mentioned herein are the trademarks
of their respective owners.
CDISC® and the CDISC logo are trademarks or registered trademarks of CDISC, Inc. and may be used
publicly only with the permission of
CDISC and require proper acknowledgement. Other listed names and brands are trademarks or
registered trademarks of their respective
owners.
注）
本資料は
本資料は、CDISC CDASH STD 1.0（2008 年 10 月 1 日発行）
日発行）の Section１～4 の
原文に
原文に日本語訳
日本語訳を追加したものです
追加したものです。
したものです。翻訳内容の
翻訳内容の保証は
保証は致しかねますが、
しかねますが、CDASH
を理解するための
理解するための補助
するための補助としてご
補助としてご参照
としてご参照下
参照下さい。
さい。
なお、
なお、CDISC CDASH STD 1.0 の著作権は
著作権は CDISC に帰属します
帰属します。
します。
2009
2009 年度 日本 CDISC ユーザーグループ CDASH グループ A チーム
［チームメンバー］
青沼 秀樹**
シミック株式会社
池田 雅行
株式会社シーエーシー
伊藤 康隆
三菱化学メディエンス株式会社
今庄 正明
万有製薬株式会社
大江 仁美
武田薬品工業株式会社
中里 進次
三菱化学メディエンス株式会社
並木 孝
アステラス製薬株式会社
松葉 尚子
イーピーエス株式会社
前田 洋一*
クインタイルズ・トランスナショナル・ジャパン株式会社
（**：チームリーダー、* ：チームサブリーダー）
翻訳文の基本書式
STANDARD
CDASH V1.0
Table of Contents
Section
Page
1. Orientation...................................................................................................................... 1
1.1. Purpose........................................................................................................................1
1.2. Organization of this Document.....................................................................................1
1.2.1. General Notes...........................................................................................................2
2. CDASH Alignment with Other Standards..................................................................... 3
2.1. The Study Data Tabulation Model (SDTM)...................................................................3
2.2. CDISC Controlled Terminology.....................................................................................3
2.3. Other Standards (Beyond CDISC)................................................................................4
3. Best Practice Recommendations ................................................................................. 5
3.1. Introduction to Best Practices .......................................................................................5
3.2. Recommended Methodologies for Creating Data Collection Instruments ....................5
3.3. Suggested CRF Development Workflow.......................................................................8
3.4. FAQs on Best Practices for Creating Data Collection Instruments...............................9
4. Overview of CDASH Domain Tables........................................................................... 13
4.1. Introduction..................................................................................................................13
4.2. Data Collection Fields Generally Considered Not Necessary to Collect on the CRF .13
4.3. Core Designations for Basic Data Collection Fields...............................................13
4.4. Explanation of Table Headers............................................................................14
5. CDASH Domain Tables ................................................................................................ 15
5.1. Common Identifier Variables ......................................................................................15
5.2. Common Timing Variables .........................................................................................16
5.3. Adverse Event – AE (Events) .....................................................................................17
5.4. Comments – CO (Special Purpose)............................................................................23
5.4.1. Solicited Comments versus Unsolicited Comments .............................................23
5.4.2. Considerations Regarding Usage of a General Comments CRF..........................23
5.4.3. Rationale...............................................................................................................23
5.4.4. Conclusion ............................................................................................................24
5.5. Prior and Concomitant Medications – CM (Interventions) ..........................................25
5.5.1. General Medications .............................................................................................25
5.5.2. Medications of Interest ..........................................................................................25
5.6. Demographics – DM (Special Purpose)......................................................................33
5.6.1. Collection of Age vs. Date of Birth.........................................................................33
5.6.2. Collection of Sex, Ethnicity and Race....................................................................34
5.7. Disposition – DS (Events)............................................................................................40
5.8. Drug Accountability – DA (Findings) ...........................................................................44
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
STANDARD
Table of Contents
Section
Page
5.9. ECG Test Results – EG (Findings) .............................................................................47
5.9.1. Scenario 1: Central reading...................................................................................47
5.9.2. Scenario 2: Local reading......................................................................................52
5.9.3. Scenario 3: Central processing (CRF includes site assessment of clinical
significance) ...........................................................................................................55
5.10. Exposure – EX (Interventions) .................................................................................60
5.11. Inclusion / Exclusion Criteria Not Met – IE (Findings) ..............................................65
5.11.1. Collecting IE Data and Mapping to the SDTMIG ................................................65
5.11.2. Adaptive Trial Design .........................................................................................65
5.12. Laboratory Test Results – LB (Findings)...................................................................68
5.12.1. Scenario 1: Central processing ..........................................................................68
5.12.2. Scenario 2: Local processing .............................................................................70
5.12.3. Scenario 3: Central processing (CRF includes site assessment of clinical
significance) …………………………………………………………………………....73
5.13. Medical History – MH (Events) ................................................................................75
5.14. Physical Examination – PE (Findings) .....................................................................79
5.14.1. Best Practice Approach.......................................................................................80
5.14.2. Traditional Approach ..........................................................................................81
5.15. Protocol Deviations – DV (Events)............................................................................84
5.15.1. Considerations Regarding Usage of a Protocol Deviations CRF........................84
5.15.2. Rationale.............................................................................................................84
5.16. Subject Characteristics – SC (Findings) ..................................................................86
5.17. Substance Use – SU (Interventions).........................................................................88
5.18. Vital Signs – VS (Findings) .......................................................................................92
6. Change Control and the Process for Creating New CDASH Domains ................... 94
7. Appendices ................................................................................................................... 95
7.1. Commonly Used CDISC Controlled Terminology .......................................................95
7.2. Regulatory References .............................................................................................102
7.2.1. Common Identifiers and Timing Variables...........................................................103
7.2.2. Adverse Events (AE)...........................................................................................104
7.2.3. Prior and Concomitant Medications (CM)............................................................108
7.2.4. Demographics (DM).............................................................................................109
7.2.5. Disposition (DS) ..................................................................................................110
7.2.6. Drug Accountability (DA).....................................................................................111
7.2.7. ECG Test Results (EG).......................................................................................112
7.2.8. Exposure (EX).....................................................................................................113
7.2.9. Inclusion / Exclusion Criteria Not Met (IE) ..........................................................114
7.2.10. Laboratory Test Results (LB) ............................................................................115
7.2.11. Medical History (MH).........................................................................................116
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
CDASH V1.0
Table of Contents
Section
Page
7.2.12. Physical Examination (PE) ...............................................................................117
7.2.13. Protocol Deviations (DV)...................................................................................118
7.2.14. Substance Use (SU) .........................................................................................119
7.2.15. Vital Signs (VS).................................................................................................120
7.3. CDASH Project Development Process ....................................................................121
7.3.1. Project Background.............................................................................................121
7.3.2. Process and Deliverables....................................................................................123
7.3.3. Volunteers............................................................................................................124
7.4. CDASH Core Team Members and Participating Companies ...................................125
7.4.1. CDASH Core Team Members.............................................................................125
7.4.2. Participating Companies .....................................................................................126
7.5. List of Abbreviations and Glossary ...........................................................................128
7.6. Acknowledgements ...................................................................................................131
7.7. Representation and Warranties, Limitations of Liability, and Disclaimers ................132
7.7.1. CDISC Patent Disclaimers ..................................................................................132
7.7.2. Representations and Warranties.........................................................................132
7.7.3. No Other Warranties/Disclaimers........................................................................132
7.7.4. Limitation of Liability............................................................................................132
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
STANDARD
オリエンテーション
1.1.目的
1.
1. Orientation
1.1. Purpose
The aim of the Clinical Data Acquisition Standards Harmonization (CDASH) Standard
Version 1.0 is to describe recommended basic standards for the collection of clinical trial
data. This document is intended to be used by those functions involved in the
planning,collection, management and analysis of clinical trials and clinical data, for
example, Clinical Investigators, Medical Monitors, Clinical Research Associates
(Monitors),Clinical Research Study Coordinators, Clinical Data Managers, Clinical Data
and Statistical Programmers, Biostatisticians, Drug Safety, Case Report Form (CRF)
designers and other functions tasked with the responsibility to collect, clean and ensure
the integrity of clinical trial data.
Clinical Data Acquisition Standards Harmonization(CDASH) Standard の Version 1.0 の
目的は、臨床試験データの収集のために推奨される基本的なスタンダードを紹介することで
す。このドキュメントは、臨床試験や臨床データの計画、収集、マネジメント、及び解析に
かかわる部署にて使用されることを意図しています。例えば、臨床試験担当医師、Medical
Monitors、CRA (モニター)、臨床試験コーディネーター、臨床試験データマネージャー、臨
床データや統計のプログラマー、統計担当者、安全性担当者、CRF デザイナー、及びそれ
以外の臨床試験データの収集、クリーニング、真正性の保証について責任のある部署です。
Sponsors will need to determine what additional data fields will need to be added to
address study-specific requirements based on regulatory and applicable business
practices. Until therapeutic area (TA) specific data fields have been standardized,
sponsors will need to add these fields to the CDASH recommendations to fulfill their
protocol-specific requirements.
依頼者は、規制や商慣習に基づいた試験特有の要求事項を扱うためには、どの様なデータフ
ィールドを追加する必要があるのか決定する必要があります。治療領域(TA)特有のデータフ
ィールドが標準化されるまで、依頼者は、プロトコルで決められた特有の要求事項を実現さ
せるため、CDASH の推奨モデルにそれらのフィールドを加える必要があります。
The CDASH standards are part of the Clinical Data Interchange Standards Consortium
(CDISC) Technical Road Map that is designed to realize the vision of a set of harmonized
standards that meet the CDISC Mission and Strategy. The set of standards has been,
and will continue to be, developed to support the streamlining of processes within
medical research from the production of clinical research protocols through to reporting
and/or regulatory submission, warehouse population and/or archive and post-marketing
studies/safety surveillance. For more information, click on the following link:
http://www.cdisc.org/downloads/CDISC_Road_Map_Spring2008.pdf.
CDASH 標準は、Clinical Data Interchange Standards Consortium (CDISC)の使命と戦略
に適う標準セット像を実現するために設計された CDISC テクニカルロードマップの一部
です。CDASH 標準は、これまでもこれからも、臨床研究のプロトコルの作成から規制当局
への報告や申請、症例情報の収集や保管、製造販売後試験/安全性調査まで、医療研究におけ
る業務プロセスの効率化を支援するために発展し続けるでしょう。
より詳細な情報を知りたい は、以 のリンクをクリックして さい:
http://www.cdisc.org/downloads/CDISC_Road_Map_Spring2008.pdf.
下
下
本書の
本書の構成
本書は以下のセクションより構成されています:
・セクション 1: Orientation —このセクションでは、CDASH Standard Version 1.0 の構成
について説明しながら、CDASH プロジェクトの目的や目標の概要を紹介しています。
・セクション 2: CDASH Alignment with Other Standards —このセクションは、CDASH
Standard Version 1.0 と、Study Data Tabulation Model Implementation
Guide(SDTMIG)や、規制用語、CDISC 以外のスタンダードとの関係について説明してい
1.2.
1.2. Organization of this Document
This document has been organized into the following sections:
• Section 1: Orientation—This
section provides an overall introduction to the purpose
Orientation
and goals of the CDASH project as well as describes the organization of CDASH
Standard Version 1.0.
• Section 2: CDASH Alignment with Other Standards—This
section describes the
Standards
relationship of CDASH Standard Version 1.0 to the Study Data Tabulation Model
Implementation Guide (SDTMIG), controlled terminology and other non-CDISC
standards.
方
ます。
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
CDASH V1.0
• Section 3: Best Practice Recommendations—This
section introduces the Best Practice
Recommendations
recommendations and methodologies for creating data collection instruments. There is
also a Frequently Asked Questions (FAQs) section on best practices for creating data
collection instruments.
• Section 4: Overview of CDASH Domain Tables—This
section contains a preview of the
Tables
new ideas and approaches recommended by the CDASH Domain Teams, introduces
data collection fields noted not necessary to collect, defines the core designations used
throughout CDASH Standard Version 1.0 and explains the table headers used in the
domain tables.
• Section 5: CDASH Domain Tables—This
section describes the approach taken
Tables
regarding common identifier and timing variables and contains metadata tables and/or
recommendations for the following domains:
セクション 3: Best Practice Recommendations —このセクションは、データ収集ツール
を作成するためのベストプラクティスとしての推奨と方法論を紹介しています。また、デ
ータ収集ツールを作成するためのベストプラクティスに関する FAQ のセクションもあり
・
ます。
セクション 4: Overview of CDASH Domain Tables —このセクションは、CDASH ドメイ
ンチームによって推奨された新しいアイディアやアプローチの紹介が含まれており、通常
は収集する必要がないデータフィールドの紹介や、CDASH Standard Version 1.0 を通じ
て使用されている核となる名称の定義、ドメインテーブルで使用されるテーブルヘッダー
の説明がされています。
・セクション 5: CDASH Domain Tables —このセクションは、共通の識別子やタイミング
変数の取り扱いを説明し、下記のドメインにおけるメタデータテーブルや推奨を含みま
・
す。:
Adverse Events (AE)
Inclusion and Exclusion Criteria (IE)
Comments (CO)
Laboratory Test Results (LB)
Adverse Events (AE)
Inclusion and Exclusion Criteria (IE)
Prior and Concomitant Medications (CM)
Medical History (MH)
Comments (CO)
Laboratory Test Results (LB)
Demographics (DM)
Physical Examination (PE)
Prior and Concomitant Medications (CM)
Medical History (MH)
Disposition (DS)
Protocol Deviations (DV)
Demographics (DM)
Physical Examination (PE)
Drug Accountability (DA)
Subject Characteristics (SC)
Disposition (DS)
Protocol Deviations (DV)
ECG Test Results (EG)
Substance Use (SU)
Drug Accountability (DA)
Subject Characteristics (SC)
Vital Signs (VS)
ECG Test Results (EG)
Substance Use (SU)
Exposure (EX)
Vital Signs (VS)
Exposure (EX)
• Section 6: Change Control and the
the Process for Creating New CDASH Domains—This
Domains
section describes the procedure for change control and maintenance of CDASH
Standard Version 1.0 as well as the procedure for creating new CDASH domains.
• Section 7: Appendices—This
section provides additional background material
Appendices
regarding the CDASH project as well as references and supplemental information
relevant to implementation of CDASH Standard Version 1.0.
セクション 6: Change Control and the Process for Creating New CDASH Domains—
Domains こ
のセクションは、新しい CDASH ドメインを作成するための手順とともに、CDASH
Standard Version 1.0 の変更管理とメンテナンスの手順について説明しています。
・セクション 7: Appendices—
Appendices このセクションは CDASH Standard Version 1.0 の実装に関
する参考資料や補足情報とともに、CDASH プロジェクトについての付加的な背景資料を
提供しています。
・
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
STANDARD
注意事項
1.2.1.
1.2.1. General Notes
記載がない場合、本書で使用される“CRF”という用
両方について言及しています。
• Fields vs Variables: データ収集“fields”という用語は、CRF で一般的に見られるフィール
ドについて言及しています。 データ収集“variables”という用語は、臨床データベースで見
られるものについて言及しています。
• Study Treatment vs Investigational (Medicinal) Product: “study treatment”という語句
は、すべてのタイプの試験デザインと試験薬を含めるため、“investigational (medicinal)
product”の代わりに使用されています。
• Mechanisms for Data Collection:
Collection: データの収集のされ方を統一するために、チェックボ
ックス、ラジオボタン、ドロップダウンリストなど異なるデータ収集方法を使用することが
出来ます。本書では、これらの用語は同義で使用されています。
• Paper CRFs vs Electronic CRFs: 特に
は、
の CRF と 子
の CRF の
• Paper CRFs vs Electronic CRFs: The term “CRF” used throughout this document
refers to both paper and electronic formats, unless otherwise specified.
語 紙媒体
• Fields vs Variables: The term data collection “fields” refers to fields that are commonly
seen on the CRF. The term data collection “variables” refers to what is seen in a clinical
database.
• Study Treatment vs Investigational (Medicinal) Product: The phrase “study treatment”
has been used instead of “investigational (medicinal) product” in order to include all
types of study designs and products.
• Mechanisms for Data Collection: Different data collection mechanisms can be used to
control how data are collected, e.g., tick boxes, check boxes, radio buttons, drop-down
lists, etc. For the purposes of this document, these terms will be used interchangeably.
電 媒体
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
CDASH V1.0
他のスタンダードと
スタンダードとCDASHの連携
2. CDASH Alignment with Other Standards
2.
2.1. The Study Data Tabulation Model (SDTM)
2.1. The Study Data Tabulation Model (SDTM)
The CDASH project identifies the basic data collection fields needed from a clinical,
scientific and regulatory perspective to enable more efficient data collection at the
investigative sites. The SDTM and the SDTMIG provide a standard for the submission of
data based on collected data. CDASH moves upstream in the data-flow and identifies a
basic set of highly recommended and recommended/conditional data collection fields that
are expected to be present on the majority of CRFs. The CDASH data collection fields (or
variables) can be mapped to the SDTM structure. When the data are identical between
the two standards, the SDTMIG variable names are presented in the CDASH domain
tables. In cases where the data are not identical, CDASH has suggested new variable
names. As part of this mapping, SDTMIG variable names have been provided under the
“Additional Information for Sponsors” column where applicable as an aid.
CDASHプロジ クトは、試験実 医療
においてより効率的なデータ収集を
にする
ため、臨床や 学及び規制の
から必要とされている基本的なデータ収集フィールドを特
定しています。SDTMとSDTMIGは収集されたデータに基づ データの申請に するスタン
ダードを
します。CDASHは、データフローを
て、大
のCRFに まれることが
され、highly recommended（特に推奨）
、 recommended/conditional（推奨/
）
というデータ収集フィールドの基本的なセットを特定しています。CDASHのデータ収集フ
ィールド(または
)は、SDTM 造にマッピングすることが
です。2つのスタンダード
の でデータが 一である
、SDTMIGの
はCDASHのドメインテーブルに まれ
ます。データが 一ではない
は、CDASHは しい
を
しています。このマッ
ピングの一部として、 “Additional Information for Sponsors”のカラムの中でSDTMIGの
を しています。必要
て
して さい。
The CDASH recommendations are based on the SDTMIG version 3.1.1. Where
appropriate and possible, forward compatibility with SDTMIG version 3.1.2 has been
incorporated, as in the case of the DA domain.
可能 場合
先んじ
互換 持
SDTMとCDASHは明確な関連性があります。全てのSDTMIGの“Required” (必須)の変数が
議論され、CDASH標準に含まれるか、導出されるか、もしくはCRF以外のデータソースか
ら得られるものとされました。従って、目的が異なる (すなわち、データ申請対データ収集)
ために変数が必ずしも一致しない事例があります。
導出データ
導出データ
SDTM標準は導出されたデータを含んでいますが、CDASHデータ収集フィールドはデータ
を取得する段階にあり導出されるものはありません。
には含まれないデータ収集
まれないデータ収集フィールド
収集フィールド
SDTMには含
CDASHの推奨には、SDTMIGには含まれていないデータ収集フィールド(例えば、「有害事
象はありましたか？」もしくは「併用薬が使われましたか？」)も含まれています。これらの
収集フィールドは、データのクリーニングや、欠測の有無を確認する手助けをするためのも
のです。これらのタイプのフィールドの使用を容易にするために、Variable Nameカラムで
推奨される変数名（例えば、AEYN, CMYN, CMONGO）を提示し、CDASHで推奨するデ
ータ収集の変数名でありSDTMIGの変数名ではないことを示すために、網掛けにされていま
期待
ェ
科
提供
間
数名 示
変数
同
同
施 機関
観点
遡っ
く
多数
構
可能
場合
変数名
場合
新 変数名 提案
応じ 参照 下
可能
対
含
条件付き
含
CDASHの推奨はSDTMIG version 3.1.1に基づいています。適当でかつ
である
には
DAドメインの
のように、
てSDTIM version 3.1.2との
性を たせました。
場合
SDTM and CDASH are clearly related. All SDTMIG “Required” variables have been
discussed and either included in the CDASH standard, determined to be derivable or can
be obtained from data sources other than the CRF. Therefore, there are instances where
the variables do not exactly match due to their different purposes (i.e., data submission
vs. data collection).
Derived Data
The SDTM standard contains some derived data whereas CDASH data collection fields
are not derived at the data acquisition stage.
Data Collection Fields not Included in the SDTM
The CDASH recommendation also includes some data collection fields that are not
included in the SDTMIG (e.g., “Were there any adverse events?” or “Were any
concomitant medications taken?”). These collection fields are intended to assist in the
cleaning of data and in confirming that no data are missing. To facilitate the use of these
types of fields, suggested variable names are provided (e.g., AEYN, CMYN, CMONGO)
in the Variable Name column and are shaded to denote that they are CDASH-suggested
data collection variable names and not SDTMIG variable names.
す。
CDISC, INC.
CDASH_STD-1.0
変
01/OCT/2008
CDASH V1.0
STANDARD
The CDASH Findings domain (i.e., DA, EG, IE, LB, SU, and VS) tables are presented in
a structure that is similar to the SDTM submission model, which is to list the variable
names and some examples of the tests. It is expected that implementers will need to
modify to include protocol specific tests in a CRF presentation layout. Sponsors should
use the CDASH recommendations to identify the types of data to collect while referring
to the SDTM and CDISC Controlled Terminology for additional metadata, (e.g., labels,
data type, controlled terminology, etc.).
The CDASH Domain Teams have intentionally not reproduced other sections of the
SDTM standard and implementers are asked to refer to the SDTM and SDTMIG on the
CDISC website for additional information
(http://www.cdisc.org/standards/index.html).
ち
CDASH Findingsドメイン（すなわ 、DA, EG, IE, LB, SU, 及びVS）テーブルはSDTM
submission modelに た 造で されており、項目の
と例 をリストしています。な
お、実 者は、実 のCRF でプロトコル特有の項目を めるため、項目の調 をする必要
があります。依頼者は、収集するデータの
を特定するためにCDASHの推奨を使用し、
一 で追加のメタデータ（例えば、ラ ル、データタイプ、規制用 、など）についてSDTM
やCDISC Controlled Terminologyを
することが必要です。
方
似 構 示
上
際
装
変数名 示
含
語
種類
整
ベ
参照
CDASHドメインチームは必要最低限と考えられる以外のSDTM標準は転載しませんでした
ので、 実装者はCDISCウェブサイトのSDTMとSDTMIGにて追加情報をご参照下さい。
(http://www.cdisc.org/standards/index.html)
2.2. CDISC Controlled Terminology
2.2. CDISC Controlled Terminology
Terminology applicable to CDASH data collection fields is either in production or under
development by the CDISC Terminology Team. Production terminology is published by
the National Cancer Institute’s Enterprise Vocabulary Services (NCI EVS) and can be
accessed via the following link:
http://www.cancer.gov/cancertopics/terminologyresources/CDISC.
CDASHのデータ収集フィールドに適用される用 は、すでに 用中であるかCDISC
Terminology Teamによ て
中です。 用中の用 はNational Cancer Institute’s
Enterprise Vocabulary Services (NCI EVS) によ て
され、
のリンクからアクセス
することが
ます。
http://www.cancer.gov/cancertopics/terminologyresources/CDISC.
In cases where a CDASH field has associated controlled terminology, the code list is
referenced in the Definition column in the domain tables.
CDASHフィールドに
する規制用 がある
ムにコードリストが 及されています。
In addition, the Commonly Used CDISC Controlled Terminology appendix includes
subsets of controlled terminology for selected data collection fields. Although users may
access directly the full EVS code lists (via the link above), we have identified the most
commonly used terms as an aid for implementers.
加えて、
のCommonly Used CDISC Controlled Terminologyは、
されたデータ収
集フィールドに する規制用 のサブセットを
でいます。 用者は（
のリンクから）
全てのEVSコードリストに
アクセスすることもで ますが、実 者の けとなるように
もよ 使用される用 を特定しました。
出来
付表
最 く
っ 検討
関連
言
対
語
語
語
直接
語
運
語
っ 公表 下記
運
場合には、ドメインテーブルのDefinitionカラ
含ん
き
利
厳選
上記
装 助
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
CDASH V1.0
2.3. Other Standards (Beyond CDISC)
他のスタンダード(CDISCの域を越えて)
医療関連のスタンダードの領域は広くて複雑であり、非常に多くのプレーヤーがこの舞台に
います。幸い、CDISCは臨床／医療研究のスタンダードの開発において”一日の長”がありま
す。CDISCは医療のスタンダードを開発している代表的な組織であるHealth Level
Seven(HL7)と協業を開始し、CDISCの臨床研究とHL7の医療のスタンダードの調和を図っ
てきています。CDISCとHL7は、2001年からチャーター合意を結んでいます。この協定は
2-3年ごとに更新されており、CDISCとHL7標準の調和に対する誓約も含まれています。実
際に、Biomedical Research Integrated Domain Group(BRIDG)モデルは、医療研究のため
のCDISC標準とHL7のReference Information Model(RIM)間の調和を確実にするための、
及びCDISC標準内の相互の調和を確実にするためのCDISCの取り組みを通じて始められた
ものです。BRIDGモデルは、現在はCDISC、HL7、NCI、及びFDAの共同プロジェクトに
なっています。加えて、BRIDGモデルは、HL7のRegulated Clinical Research Information
Management(RCRIM) ワークグループに彼らのドメイン解析モデルとして受け入れられま
した。それは、HL7 RCRIM Work Group内で開発されているHL7メッセージの相互運用の
ための基盤を形作るためです
2.3.
The landscape of healthcare-related standards is large and complex and there are
numerous players in this arena.Fortunately, CDISC has a “niche” in the development of
standards for clinical/medical research. CDISC has initiated a collaboration with a
leading healthcare standards development organization, Health Level Seven (HL7), to
harmonize the CDISC clinical research with the HL7 healthcare standards. CDISC and
HL7 have had a Charter Agreement since 2001; this agreement has been renewed every
2-3 years and includes a commitment to harmonize the CDISC and HL7 standards. In
fact, the Biomedical Research Integrated Domain Group (BRIDG) model was initiated
through the efforts of CDISC to ensure such harmonization between the CDISC
standards for medical research and the HL7 Reference Information Model (RIM) and
also to ensure that the CDISC standards themselves are harmonized among each other.
The BRIDG model is currently a collaborative project of CDISC, HL7, NCI and FDA. In
addition, the BRIDG model has been accepted by the HL7 Regulated Clinical Research
Information Management (RCRIM) Work Group as their domain analysis model, to form
the basis for interoperability for HL7 messages that are developed within the HL7
RCRIM Work Group.
There is growing recognition around the globe that proprietary standards prevent data
interchange, which is essential to effective partnering and information exchange
between and among clinicians and researchers. Clinical care can reap benefits through
medical research findings, and more clinicians will be interested in conducting research
if we can streamline the research process by integrating it into their clinical care
workflow. CDISC encourages the adoption of its global standards for clinical research,
which should continue to be harmonized with healthcare standards, to provide a means
for interoperability among healthcare and research systems such that medical research
can support informed healthcare decisions and improve patient safety.
CDISC has a long-time principle of working with others through productive
collaboration and not duplicating efforts. Hence, in addition to HL7, CDISC has many
and varying relationships with other standards developing organizations (SDOs) and
alliance partners. With Health Level 7 (HL7), the relationship is close and the standards
are being harmonized. With others, the relationships are more recent and, therefore, not
as welldefined or mature. CDISC was approved for Liaison A status with ISO in 2007.
This status allows the CDISC standards to be brought to ISO through a fast-track
procedure versus starting at the ground level. More recently, to harmonize healthcare
standards, ISO, CEN and HL7 formed the Joint Initiative Council. CDISC was accepted
into the Joint Initiative Council (JIC) in July 2008. CDISC has also been involved with
the U.S. Health Information Technology Standards Panel (HITSP) and the HITSP Board
since it was initiated in 2006, with a goal to ensure that these national harmonization
steps do not diverge from the global work being done by CDISC and HL7 and JIC.
独占的なスタンダードが臨床医と研究者の間の効果的な提携や情報交換に必要不可欠なデ
ータ交換を妨げる、という認識が世界中で高まっています。もし私たちが診療のワークフロ
ーにそれを統合することで研究プロセスを効率化することが出来れば、診療は医療研究の成
果から利益を得ることが出来、またより多くの臨床医が研究を実施することに興味を持つこ
とでしょう。CDISCは、臨床研究の国際的なスタンダードの導入を働きかけます。医療のス
タンダードとの調和を継続すべきであり、それは、医療と研究のシステム間の相互運用の手
段を提供するためであり、それにより、医療研究が情報に基づいた医療の判断を支援するこ
とができたり患者の安全性を向上させることができたりするようになります。
CDISCには、他者と共同開発を行い、また重複した作業を行わないという長きにわたる原則
があります。その結果、HL7に加えて、CDISCには他の標準化団体(Standards Developing
Organizations(SDOs))や協調関係にあるパートナーとの多種多様な関係があります。
Health Level 7 (HL7)とは、結びつきが強く、スタンダードの調和が進んでいます。その他
の組織との関係はより最近のもので、従って、それほど明瞭あるいは成熟したものではあり
ません。CDISCは、2007年にISOのLiaison A statusに承認されました。このステータスに
よってCDISC標準が、初期レベルから始めるよりも迅速な手順でISOに提示できるようにな
りました。ここ最近では、医療のスタンダードを調和させるために、ISO、CENとHL7はJoint
Initiative Councilを結成しました。CDISCは2008年7月にJoint Initiative Council(JIC)への
参加を受け入れられました。CDISCはまた、2006年の発足以来U.S. Health Information
Technology Standards Panel(HITSP)とHITSP Boardに関わっており、その目標はこれら
の国家的な調和のステップがCDISCとHL7とJICにより行われている国際的な作業からそ
れることがないよう保証することです。
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
STANDARD
ベストプラクティスとして
ベストプラクティスとしての
としての推奨
3.1.ベストプラクティス序論
ベストプラクティス序論
ベ ストプラクティスとしての推奨は、実 装者への補助を目的とし、 CDASH Standard
Version 1.0 に含まれています。オリジナルのプロジェクトチャーターの範囲外ではありま
すが、CDASH コア・チームはこれらの推奨が一貫した実装や CDASH 標準の最適な使用を
促進すると判断しました。これらのベストプラクティスは、データ収集ツール構築ための推
奨された方法論、提案された CRF 作成ワークフロー、及びデータ収集ツールを作成するた
めのベストプラクティスに関する FAQ のセクションから成ります。CRF レイアウトは
CDASH プロジェクトの範囲外ではありますが、ベストプラクティスセクションはレイアウ
トに関連するいくつかのコンセプトを含んでいます。これらが CRF を作成する際に考慮す
ることが重要であるためです。
「その試験の実施を特定化するプロトコルを除き、臨床試験データを得る際に使用されるツ
ールにおいて、これ以上の重要なドキュメントはありません。集められたデータの品質は、
そのツールの品質に最も影響を受けます。正確なデータポイントが集められなかった場合、
どれだけ多くの時間や労力がその試験を実施することに費やされたとしても、意味のある解
析は不可能となります。したがって、このようなツールのデザイン、作成及び品質保証に対
しては、最大限の注意を払わなければなりません。
」
3.
3. Best Practice Recommendations
3.1. Introduction to Best Practices
The Best Practice recommendations are included in CDASH Standard Version 1.0 as a
help to implementers. Although outside the original scope of the project charter, the
CDASH Core Team decided that these recommendations would encourage consistent
implementation and the most optimal use of the CDASH standard. These Best Practices
comprise the Recommended Methodologies for Creating Data Collection Instruments, a
Suggested CRF Development Workflow and a section of FAQs about Best Practices for
Creating Data Collection Instruments. CRF layout is out of scope for the CDASH project,
however, the Best Practices section includes some concepts related to layout because
these concepts are important to consider when developing CRFs.
“There is arguably no more important document than the instrument that is used to
acquire the data from the clinical trial, with the exception of the protocol, which specifies
the conduct of that trial. The quality of the data collected relies first and foremost on the
quality of that instrument. No matter how much time and effort go into conducting the
trial, if the correct data points were not collected, a meaningful analysis may not be
possible. It follows, therefore, that the design, development and quality assurance of
such an instrument must be given the utmost attention.” 1
データ収集
データ収集ツール
収集ツール構築
ツール構築のための
構築のための推奨
のための推奨された
推奨された方法論
された方法論
方法
根拠
必要なデータのみ
・収集されるデータに関連したコストと時
必要なデータのみ
CRFは、余剰なデータを収集しないよ 間を考慮し、通常、解析に使用されるデー
うにするべきであり、代わりに、プロ
タだけがCRFに集められるべきです。収集
トコルの質問への回答や適切な安全性
されたデータは、一般的に、レビューされ、
クリーニングされるべきです。
データを提供するために必要とされる
データだけを収集することにフォーカ
・解析に必要なパラメーターが収集され容
スすべきです。
易に解析できることを確認するために、入
手可能な場合、解析計画書(SAP)をレビュ
ーする必要があります。統計担当者は、
CRFが正確なデータ全てを収集すること
を確認するための責任を負います。
3.2. Recommended Methodologies for Creating Data Collection
Instruments
Rationale
Ref Methodology
1
Necessary Data Only
• Usually, only data that will be used for
CRFs should avoid collecting
analysis should be collected on the CRF
redundant data and should instead
due to the cost and time associated with
focus on collecting only the data
collecting data. Data that is collected
needed to answer the protocol
should generally be reviewed and
questions and to provide adequate
cleaned.
safety data.
• When available, the Statistical
Analysis Plan (SAP) needs to be
reviewed to ensure that the parameters
needed for analysis are collected and can
be easily analyzed. The Statistician is
responsible for confirming that the CRF
collects all of the correct data.
3.2.
Ref
1
1 Good Clinical Data Management Practices, Version 4, October 2005, Society for Clinical Data
Management
1 Good Clinical Data Management Practices、バージョン 2005
Clinical Data Management
年 10 月 4 日、Society for
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
Ref
2
3
Methodology
Control
The process of designing, printing,
distributing CRFs, and accounting
for unused CRFs must be controlled.
• The CRF development lifecycle
should be a controlled process using a
formalized, documented process that
incorporates design, review, approval
and versioning steps.
• The CRF development process
should be controlled by SOPs
covering, at a minimum, design,
development, QA, approvals, version
control and site training.
Adequate Review
The team that designs the data
collection instruments for a study
needs to be involved in the
development of the protocol and
should have appropriate expertise
represented on the CRF design team
(e.g., statistics, programming, data
management, clinical operations,
science,regulatory,
pharmacovigilance).
CDASH V1.0
Rationale
• A controlled process for developing
CRFs will help ensure that CRFs comply
with company standards and processes.
Ref
2
方法
管理
理
3
• Staff involved in CRF design should
review the protocol to ensure that it
is possible to collect the proposed
data.
• Statisticians should review the
CRF against their planned analyses
to make sure all required data will be
collected in an appropriate form for
those analyses.
• Clinical Operations staff should
review the CRF to make sure the
questions are unambiguous and that
it is possible to collect the data being
requested.
理
・CRFを作成するための管 プロセスは、
CRFの設計、
、
、及び 使用 CRFが社 のスタンダードやプロセスに
のCRFの計 プロセスについては、管
うことを保証する一 となります。
されなければなりませ 。
・CRF作成のライフサイクルは、 式
化された管 プロセス、つまり、設計、
ュー、
及び
管 について
文書化されたプロセスである
で
す。
・CRFの作成プロセスは、SOPで管
される
であり、
、設計、作
成、QA、
、バージョン管 及びサ
イトト ーニングについて
す
です。
・CRFデザインチームは、CRFが解析に必
試験用のデータ収集 ールをデザイン
要とされたデータをす て り
こと
するチームは、プロトコルの作成に
を保証するために、CRFの適 な
ュー
わる必要があり、また、CRFデザイン を実 する
です。 にチームは、依頼
者のプロセスと一 する
でデータが
チームにおいて適 な
的
を有
する
です。(例：統計学、プログラ 集められること、また、医療
で
す
ミング、データマネジメント、臨床
ることが
であることも保証する必要
ーション、サイエンス、規制、フ
があります。
ーマコ ィジランス)。
・
されたデータを収集することが
であることを 実とするために、
CRF設計に わるスタッフはプロトコ
ルを
ューする
です。
・統計担当者は、解析のために必要な
す てのデータが適 なフ ームで集
められることを 実にするために、計
画した解析と らし わせて、CRFを
ューする
です。
・臨床
ーションスタッフは、
があいまいでないこと、要求されて
いるデータを集めることが
である
ことを かめるためにCRFを
ュー
する
です。
レビ
• The CRF design team should perform
an adequate review of the CRF to ensure
that the CRF captures all of the data
needed for analysis. Furthermore, the
team needs to ensure that the data are
collected in a manner consistent with the
sponsor’s processes and should also be
easy for the site to complete.
根拠
印刷 配布 未
上
ん
形
理
承認 変更 理
べき
理
べき
最低限
承認
理
レ
網羅 べき
適切なレビュー
適切なレビュー
ツ
携
切 専門 技術
べき
オ
ペレ
ァ ヴ
提案
可能
確
携
レビ
べき
べ
切 ォ
確
照 合
レビ
べき
オペレ
質
問
可能
確
レビ
べき
従
内
助
べ 取 込む
切 レビ
施 べき 更
致 方法
機関 記入
容易
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
STANDARD
・プログラマーは、データがCRFに集
められる
が、プログラミングに
を及 さないことを保証するため
に、CRFを
ューする
です。
・ 学
は、有効性・安全性のデ
ータ収集項目について
し、またそ
れらのデータを集める
に してデ
ータマネジメント(CDM)スタッフを
する
です。
・規制の
は、す ての適 な規
制の
のためにCRFを
ューする
です。
・データエントリーはCRFの 要な
ーザー であり、そのような
も
様に
ューに まれている
で
す。
・フ ーマコ ィジランスは、適 な
データ収集や
な報告をサ ートす
るプロセスを 実にするために
ュ
ーする
です。
• Programmers should review the
CRF to ensure that the manner in
which the data are collected on the
CRF will not adversely affect the
programming function.
• Scientific experts should provide
input on the efficacy and/or safety
data collection fields, and educate the
Clinical Data Management (CDM)
staff on the type and methods of
collecting those data.
• Regulatory experts should review
the CRF for compliance with all
applicable regulations.
• Data Entry is an important “user”
of the CRF and their perspective
should be included in the review as
well.
• Pharmacovigilance should review to
ensure appropriate data capture and
process to support expedited
reporting.
方法
影響 ぼ
レビ
科 専門家
教
育 べき
専門家 べ 切
遵守
レビ
べき
重 「ユ
」
視点 同
レビ 含
べき
ァ ヴ
切
迅速
ポ
確
レビ
べき
理想的には、CRFはプロトコルとSAP
と同時に作成されるべきです。
Ideally, the CRF should be developed
in conjunction with the protocol and
SAP.
4
All research-related data on the CRF
should be addressed in the protocol to
specify how and when it will be
collected.
Site Workflow
The team developing the data
collection instruments needs to
consider the workflow at the site and
the standard of care.
べき
助言
方法 関
悪
上
関連
示 べき
医療機関のワークフロー
医療機関のワークフロー
データ収集ツールを作成するチーム
は、医療機関におけるワークフローや
対応のスタンダードについて考慮する
CRFの の全ての調査
のデータ
は、プロトコル中でいつどのように集
められるのか明 される
です。
• The CRF needs to be quick and easy for
site personnel to complete.
• Clinical Operations staff should review
the CRF for compatibility with site
workflow and site procedures.
• Although CDM may make the final
decisions about CRF design, those
decisions should be informed by study
and user requirements.
4
必要があります。
機関
速く容易 完
き
オペレ
機関 ワ
手順 合
レビ
べき
対 最終
下
ん
際
ユ
考慮
入 べき
・CRFは、医療
担当者が
に
成で るものである必要があります。
・臨床
ーションスタッフは、CRFが、
医療
の ークフローや
と適 し
ているか、
ューする
です。
・CDMはCRFデザインに して
決定
を すかもしれませ が、それらの決定に
しては試験及び ーザーの要求を
に れる
です。
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
Ref
5
Methodology
Employ Standards
Within the data collection
environment, standards should be
employed to collect consistent data
across compounds and TAs.
CDASH standards should be used
wherever possible and sponsor
standards developed as needed.
6
Clarity
CRF questions and completion
instructions should not “lead” the
site.
CDASH V1.0
Rationale
• Using data collection standards across
compounds and TAs saves time and
money at every step of drug
development.
• Using standards:
- reduces production time for CRF
design and reduces review and approval
time.
- reduces site re-training and queries
and improves compliance and data
quality at first collection.
- facilitates efficient monitoring,
reducing queries.
- improves the speed and quality of data
entry due to familiarity with standards
and reduces the training burden
in-house.
- enables easy reuse and integration of
data across studies and facilitates “data
mining” and the production of
integrated
summaries.
- reduces the need for new clinical and
statistical programming with each new
study.
-addresses FDA Critical Path
Opportunities 45.
Data need to be collected in a way that
does not introduce bias or errors into the
study data. Questions should be clear
and unambiguous. This includes
making sure that the options for
answering the question are complete
Ref
5
6
(i.e., may need to include options such
as “Other”, “None”).
方法
根拠
スタンダードの
・化合物間及び治療領域間でデータ収集の
スタンダードの使用
スタンダードは、データ収集の段階 スタンダードを使用することは、薬剤開発
において、化合物間及び治療領域間 のすべての段階において、時間やお金を節
で一貫性のあるデータを集めるため 約することにつながります。
に用いられるべきです。CDASH 標準 ・スタンダードを使用することは：
を可能な限り使用し、必要に応じ、 - CRF デザインの作業時間を減らし、また
依頼者のスタンダードを作成するべ レビューと承認期間を減らします。
きです。
- 医療 機関 の再 トレ ーニングとクエリを
減らし、また規制順守と初回収集時のデー
タの質を高めます。
- 効率的なモニタリングやクエリの削減
を促進します。
- スタンダードに精通することによりデ
ータエントリーのスピートと質が向上し、
社内でのトレーニングの負荷を減らしま
す。
- 試験 間でのデータの再利用や統 合を 容
易にし、”データマイニング”や統合した概
要の作成を促進します。
- 各新 規試験に 際して新 規の臨床と解析
のプログラミングの必要性を減らします。
- FDA Critical Path Opportunities 45 に
対応します。
明確さ
データは試験データにバイアスやエラー
明確さ
CRFにおける記載要領は、医療機関
を生じない方法で収集されることが必要
を”誘導”してはいけません。
です。質問は明瞭であるべきで、あいまい
なものであってはいけません。このことは
質問に答えるための選択肢が完全である
べきということを含みます（すなわち、“そ
の他”や“なし”のような選択肢を含む必要
があります）。
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
Ref
7
8
Methodology
Translations
Translations of CRFs into other
languages should be a parallel
process following the same set of
steps with separate reviews and
approvals by the appropriate experts.
CRF Completion Guidelines
CRF questions should be as
self-explanatory as possible, thereby
reducing the need for separate
instructions.
When instructions are needed,
prompts and short instructions may
be placed on the CRF page. More
detailed instructions may be
presented in a CRF completion
guideline for paper CRFs, or in a
context-sensitive help file for
electronic CRFs (eCRFs). All
instructions should be concise.
Instructions should be standardized
along with the CRF as much as
possible. This promotes
standardization in that all sites will
use the same conventions for
completing the fields.
STANDARD
Rationale
CRFs that are translated into other
languages should follow the same
development process as the original
CRF to ensure the integrity of the data
collected.
Cultural and language issues should be
addressed appropriately during the
process of translating CRFs to ensure
the CRF questions have consistent
meaning in all languages.
Putting short instructions and prompts
on the CRF increases the probability
that they will be read and followed and
can reduce the number of queries and
the overall data cleaning costs.
Ref
7
8
Well designed completion guidelines will
also enhance the flow of the CRF.
Providing short instructions and
prompts on the CRF, and moving long
instructions to a separate instruction
booklet, facing page or checklist will
decrease the number of pages in the
CRF, with the following benefits:
• Decreased CDM costs (e.g., decreased
data entry costs).
• Allows CRF to be formatted so that
the reader can easily identify the fields
to be completed.
• The format of the page is less cluttered
which makes it easier for site personnel
and monitors to identify fields with
missing responses.
方法
根拠
翻訳
他の言語へ翻訳されるCRFは、データ収集
CRFの他の言語への翻訳は、適切な専
の真正性を保証するために、オリジナルの
門家達による各レビューと承認を同一 CRFと同様の作成プロセスに従うべきで
のステップで行い、それぞれ平行したプ す。
ロセスで実施すべきです。
文化的及び言語的な問題は、CRF上の質問
がすべての言語において一貫を持つこと
を保証するために、CRFを翻訳するプロセ
スにおいて適切に明示されるべきです。
記載要領
記載要領
上 質問 可能 限 確
べき
個々 対 指
示
軽減
指示が必要とされる場合には、プロンプ
トや短い指示をCRFページ上に表記し
てもよいでしょう。より詳細な指示は、
紙のCRFに対してはCRF 記載要領に、
電子CRF（eCRF）に対してはその状況
に応じたヘルプファイルにて提示して
よいでしょう。すべての指示は簡潔であ
るべきです。
指示は可能な限りCRFと一緒に標準化
されるべきです。これは、すべての医療
機関が項目を記入する際に、同じ慣習を
用いるという点において、標準化を促進
CRF
CRF の
は
な り明 である
であり、それにより
に して
をする必要が
されます。
することになります。
上 短 指示
表記
読ん 指示 従
可能 高
数 体
減
CRF に い
やプロンプトを
す
ることは、それらを
で
に わせる
性を め、クエリの や全 的なクリ
ーニングに要するコストを らすことに
なります。
十分にデザインされた記載要領は、CRF
の使いやすさを高めます。CRF上に短い指
示とプロンプトを与えることや、長い指示
を別の指示用の小冊子や見開きページ、あ
るいはチェックリストに移すことは、CRF
のページ数が減るとともに、以下の利点が
あります：
・CDMのコスト減少（例：データエント
リーに要するコストが減る）。
・記入するフィールドを容易に特定するこ
とができるよう、CRFの形式を整えること
が可能。
・ページの形式がより煩雑ではなくなり、
医療機関担当者やモニターが、入力すべき
フィールドを容易に特定できるようにな
ります。
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
CDASH V1.0
3.3. Suggested CRF Development Workflow 3.3.
推奨CRF作成ワークフロー
作成ワークフロー
Suggested CRF Development Workflow
ワ
推奨CRF作成 ークフロー
新しい試験の計画開始
はい
確
修正(例，プロトコル固有)
( 定した)
プロトコル
案
門横断
レビ
部
的な
チームの
ュー2
変更が必要？
標準に基づいた
1
CRF
案
改訂 承認されたプロトコル
試験中の
試験での
CRF 使用
いいえ
いいえ
はい
承認された CRF
門横断的な承認
3
部
CRF
案の最終化
過程の完了
作成
High Level Overview of CRF Development Best Practices:
ベ
概
CRF作成の ストプラクティスの 要
•1Develop as early as possible with a stable draft Protocol, based on CDASH and internal standards
•1CDASH及び社 のスタンダードに い、 定したプロトコル を用いて、
な り
に作成します。
•2Develop as a cross-functional team, reviewing from the perspective of the respective disciplines, including:
•2部
的なチームとして、
の規 に基づいた
ューを行い作成します。
は以 を
ます：
•Is all data for analysis collected?
門横断
内
従 確
各々 則
？
レビ
案
可能 限 早期
内容 下 含み
・解析用のデータは全て収集されているか
•Is it possible to collect this way at the site?
機関においてこの方法で収集することは可能か？
・安全性に対処できる適切なデータを収集しているか？
• CRF is approved after Protocol is approved
• CRFはプロトコル承認後に承認されます。
・医療
•Are we collecting appropriate data to address safety?
3
3
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
STANDARD
3.4. FAQs on Best Practices for Creating Data Collection Instruments
Ref
Question
1
Should “Yes/No” questions be
preferred over “Check all that
apply” questions?
“はい/いいえ”式の
は” 当
するものす てにチ ック”式
の
より ましいとされる
ですか
べ
質問 望
べき ？
質問 該
ェ
CRF
Type
Paper
and
electroni
c
及び
子
紙
電
データ収集
データ収集ツール
収集ツール作成時
ツール作成時のベストプラクティスにおける
作成時のベストプラクティスにおけるFAQ
3.4.
Best
Best Practice Recommendation
Rationale
• If an assessment can have composite responses (e.g., presence or
absence of two or more symptoms), “Yes/No” questions for each
component response (e.g., symptom) are preferred to “Check all
that apply” questions.
・
が
の
を
うる
（例えば、2つ以 の症 の有 ）、
の要 の
（例えば、症 ）に して、“ 当するものにチ ッ
ク”式の
よりも“はい/いいえ”式の
の が ましいです。
• “Yes/No” questions provide a definite answer. The
absence of a response is ambiguous as it can mean
“No”, “None” or that the response is missing.
・“はい/いいえ”式の
は明 な えが えられま
す。
がないのは、“いいえ”、 “なし”あるいは
モ のい れかの
性があり、 明 です。
評価 複数 回答 持ち 場合
上 状 無
個々 素 回答
状 対
該
ェ
質問
質問 方 好
回答
レ ず
質問 確 答 与
可能
不 瞭
回答
• One exception to this recommendation might be assessments
where the majority of options would be answered “No”. An example
would be the collection of ECG abnormality data where
approximately 45 abnormalities may be listed but only a few will
apply.
・この推奨における一つの例外は、大
の
が“いいえ”と
される
かもしれませ 。例としては、 45項目の
項目がリス
トされ、
の
しか 当しないような
図
データの収集で
す。
多数 選択肢
約
異常
心電 異常
評価
ん
ほん 数個 該
2
Should there be a standard
order for “Yes/No” response
boxes and other standardized
lists?
“はい/いいえ“の
ックス
や の標準化リストに して
標準的な
はありますか
他
順序
回答ボ
対
？
Paper
and
electroni
c
及び
子
紙
電
回答
• Another exception is the “Check if ongoing” question. This is a
special use case of “Yes/No” where the question is usually
presented as a single possible response of “Yes” in conjunction with
an end date. In this case, if the box is checked, the field will contain
“Yes” and if it is blank and there is an end date present, it can be
mapped to “No”.
・もう一つの例外は、“ 続中の
チ ック”式の
です。これは“は
い/いいえ”式の特 な使用の ースで、
と
して、“はい”
を
で
とするような
です。この ースでは、 ックスがチ
ックされた
そのフィールドは“はい”の意 となり、
で
が
している
“いいえ”に
づけられます。
• It is recommended that a consistent order of “Yes/No” responses
be used.
・“はい/いいえ”の
の
を一 して用いることが推奨されます。
継 場合 ェ
質問
別
ケ
通常終了日 連動
単独 回答
質問
ケ
ボ
ェ
場合
味
空欄 終了
日 存在
場合
位置
回答 順番 貫
• A standard order of “Yes/No” response boxes
promotes ease of use of the CRF.
・“はい/いいえ”の
ックスの標準的な
はCRF
の 用を
にします。
利 容易
回答ボ
順序
• Presenting “Yes/No” responses in a standard
order is “one tool” that can be used to reduce bias,
but questions should also be carefully worded so
they don’t introduce bias or lead the investigator to
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
Ref
CDASH V1.0
Question
CRF
Type
Best
Best Practice Recommendation
Rationale
• CDASH recommends the unambiguous format DD-MMM-YYYY
where “DD” is the day as a 2-digit numeric value, “MMM” is the
month as a 3-character letter abbreviation in the local language,
and “YYYY” is the year as a 4-digit numeric value. For example for
an English CRF, the second day of February 2008 would be
“02-FEB-2008”, whereas for a French CRF it would be
“02-FEV-2008”.
・CDASHは一 的な 式であるDD-MMM-YYYYを推奨します。“DD”
は2 の
としての
、“MMM”は現
の3文 の 略 とし
ての 、”YYYY”は4 の
としての です。例えば、
のCRF
では、2008 2 の2 目の は、”02-FEB-2008”となりますが、フラ
ンス のCRFでは”02-FEV-2008”となります。
a desired response.
・標準の
で はい/いいえ の
を
すること
は、バイアスを らす 一つの
ですが、
は
バイアスを り まない、あるいは試験担当医師を
ましい
に
しないよう、
に 現される
です。
• Using the CDASH-recommended collection date
format (i.e., DD-MMM-YYYY) will provide
unambiguous dates and will be seen as the same
date by anyone who reads them. For example, the
date “06/08/02” is ambiguous because it can be
interpreted as “June 8, 2002” or “August 6, 2002”.
・CDASHが推奨する
式（すなわ 、
DD-MMM-YYYY）の使用は一 的な
を
し、
がそれを
でも
として
されるでしょ
う。
例えば、”06/08/02”の
は、”2002 6 8 ”と
も”2002 8 6 ”とも れるので、
です。
順番 “
減 “
取 込
回答 誘導
3
What date format should be
used for subject and
site-completed CRF data?
験者及び医療
が
す
るCRFデータでは、どのような
式が使われる
です
か
被
日付形
？
機関 記入
べき
Paper
and
electroni
c
及び
子
紙
電
義 形
桁 数字値
日付
月
桁 数字値
年月 番 日
語
年
地語
字 省 形
英語
• For electronic data capture (EDC), the user may be able to select
a date from a calendar, and this would also meet the
recommendation for an unambiguous date.
・ 子データ収集システム（EDC）においては、 ーザーはカ ンダ
ーから
を
することも
かもしれませ 、そしてこれは一
的な
の推奨
も たすでしょう。
電
日付 選択
可能
日付 条件 満
ん
ユ
レ
義
誰
” 回答 表示
手段”
質問
望
慎重 表
べき
日付形
ち
義 日付 提供
読ん 同じ日付 認識
日付
年月日
年月日 取
曖昧
• Note: If subject-completed CRF pages are
translated into a local language, the CDASH
recommended date format for collection may make
it easier to translate the documents.
・
： 験者が
するCRF ージが現
に翻訳
される
、CDASH推奨の収集用の
式は、文
書の翻訳がより
になるかもしれませ 。
注記 被
場合
記入
簡単
ペ
地語
日付形
ん
• Dates are collected in a user-friendly format, but
transformed and stored in the database as ISO 8601
format and submitted as ISO 8601.
・
は ーザーが 用しやすい 式で収集されます
が、ISO8601 式でデータ ースに
して保 さ
れ、ISO8601 式で申請されます。
日付 ユ
形
形
利
ベ
形
変換
存
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
STANDARD
Ref
Question
4
What time format should be
used for subject and
site-completed CRF data?
験者及び医療
が
す
るCRFデータでは、どのような
式が使われる
です
か
被
時間形
？
機関 記入
べき
CRF
Type
Paper
and
electroni
c
及び
子
紙
電
Best Practice Recommendation
Rationale
CDASH recommends the use of a 24-hour clock using the
HH:MM:SS format for recording times. 00:00:00 would indicate
midnight with the next day’s date.
CDASHは、
の
にはHH：MM：SS 式による24
を
推奨します。00:00:00は、その
の
の真 中を します。
As many of the HH:MM:SS elements should be
used as are needed for a particular field.
使用す
HH：MM：SSの 成の
け、特定のフ
ィールドが必要になります。
Subject-completed times may be recorded using a
12-hour clock and an A.M. or P.M. designation. The
time would then be transformed to a 24-hour clock
in the database.
験者が
する
は、12
と 前または
後 定を使 て
してもよい。
は、データ
ースで24
に
されます。
Times are collected in a 24-hour format which
eliminates the need to convert to the ISO 8601
format for submission.
は、申請のためにISO8601 式へ
する必要
がない24
式で収集されます。
Data items which can be calculated from other
data captured within the CRF are more accurately
reported if they are calculated programmatically
in-house using validated algorithms.
証されたアル リズムを用いて社 でプログラム
的に計 されるならば、 の の収集データから計
なデータ項目の が、より正 に報告されます。
Capturing both the source data items and the
calculated field would be a duplication of data.
データ項目と計 フィールドを
収集すると、
データが
する れがあります。
If the calculated field is used to make a treatment
and/or study conduct decision, the results of the
calculation would be required on the CRF to explain
the decision made.
計 フィールドが
や試験の実 決定に用いられ
る
、その決定
を 明するために、CRF に計
を要求されるでしょう。
Although the data recorded on worksheets are
supporting documentation for key information
collected elsewhere in the CRF, these data are not
時刻 記録
形
翌日 日付 夜 示
時間表記
•
•
•
べき
構 数だ
•被 記入 時刻
午 指 っ 記録
時間表記 変換
•
5
Should manually-calculated
data items be recorded on the
CRF?
で計 されたデータ項目
がCRF に
されなければ
なりませ か
手動 算
上 記録
ん ？
Paper
and
electroni
c
及び
子
紙
電
•
Manually-calculated fields should not typically be recorded
within the CRF when the raw data on which the calculation is
based are recorded in the CRF.
計 の となる データがCRFに
されると 、一 的に
計
フィールドは、CRF に
される
ではない。
An exception is when a treatment and/or study conduct decision
needs to be made based on those calculations. In those cases it may
be useful for the calculated field to be recorded within the CRF.
それらの計 に基づいて、
や試験の実 を決定する必要がある
は、例外とします。そのような
、CRF に
される計 フ
ィールドを設けると
です。
It may also be useful to provide the site a step-by-step worksheet
to calculate this data.
このデータを計 するための
を
した ークシートを医療
に
することも有用です。
• 算 元
算
•
生
内 記入
記録
べき
き 般 手動
•
算
処置
施
場合
場合
上 記録
便利
•
•
算
手順 記載 ワ
関 提供
6
Should all data collected on
CRFs be databased?
CRF に集められるす ての
上
CDASH_STD-1.0
べ
Paper
紙
算
機
• Data that are collected on CRFs should usually be databased.
• CRF上に収集されたデータは、通常データベース化されます。
• If data are not required for reporting or analysis, but collecting
•時刻
時間形
•
時間表記 午
時刻
ベ
形 変換
•検
ゴ
内
算
CRF 他
可能
方
確
•
•原
算
両方
重複 恐
•
• 算
場合
算結果
•
処置
根拠 説
施
算
上
CDISC, INC.
01/OCT/2008
STANDARD
Ref
CDASH V1.0
Question
ベ
ん ？
CRF
Type
データは、データ ース化され
なければなりませ か
Best Practice Recommendation
Rationale
the data aids the investigator or monitor, it is recommended that
data be collected on a worksheet. Worksheets used at the
investigator’s site are not typically brought in-house and will not
subsequently be databased (e.g., an entry criteria worksheet or a
dose titration worksheet).
報告または解析のために要求されていないデータ が、そのデータ
収集により試験担当医師またはモニターを支援することになる
、
ークシート でそれらのデータを収集することを推奨します。試験
実 医療
で用いる ークシートは、
、社 に
まれるこ
とはな 、その後データ ース化されることもありませ （例えば、
エントリー基準 ークシートまたは用
ークシート）。
Some fields, such as “Were there any Adverse Events – Yes/No”
may need to be databased, but will not be reported with submission
data.
有 事 がありましたか
はい/いいえ などのフィールドはデ
ータ ース化される必要があるかもしれませ が、申請データとして
報告されることはないでしょう。
Some fields, such as Investigator’s Signature, can be verified by
the data entry staff, but cannot actually be databased.
試験担当医師の署
のフィールドは、データエントリーのスタッ
フが
で ますが、実 的にデータ ース化で ないものです。
Note: All such worksheets should be considered source
documents or monitoring tools, and should be maintained at the
site with the study files.
：
のような ークシートは全て、
またはモニタリン
グ用 ールと え、試験フ イルとともに医療
で保管管 される
です。
Note: Worksheets should be developed in a parallel process to
ensure consistency.
： ークシートは、一 性を保つために並行したプロセスで作
成される
です。
The database should contain an indication that an assessment
was not performed. The mechanism for this may be different from
system to system or from paper to EDC.
データ ースは、
が実 されなか た、という
を
です。このためのメカニズムはシステム で、もし は とEDC で
なるかもしれませ 。
In some cases this might be a “Yes/No – assessment completed”
needed in the clinical database and do not need to
be recorded on the CRF.
ークシート に
されたデータは、 CRFで収
集された 要な情報の
け
になりますが、これ
らのデータは臨床データ ースに 要であり、CRF
に
される必要はありませ 。
•
ワ
上
施 機関
ワ
く
ベ
ワ
•
•「 害 象
ベ
•
•
確認 き
•
7
Should “Was assessment x
performed?” questions be
collected and/or databased?
And Should “Yes/No” exam
completed be preferred over
Check if not done”
questions?
“
Paper
and
electroni
c
及び
子
紙
電
• 注記 上記
ツ 考
べき
•
• 注記 ワ
べき
•
•
異
•
ベ
だ
記録
重
上 記録
裏付 資料
ベ 不
ん
各
上
通常 内 持ち込
ん
量漸増ワ
？–
名等
質
ワ
場合
•ワ
」
ん
ベ
き
原資料
機関
ァ
理
貫
評価 施
ん
っ
間
• This will provide a definitive indicator to both
clinical and statistical programmers that a data
field has missing data and has not been overlooked.
データフィールドが
データを つことになり、
されることがないために、決定的な 標を臨床
及び統計プログラマーの 者に
します。
This will prevent unnecessary data queries to
表示 含むべき •
く 紙
間 見過ご
•
欠測
持
指
両 提供
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
Ref
STANDARD
Question
“評価Xは実施されました
か？”という質問は、収集やデ
ータベース化すべきですか？
また、調査の完了“はい/いい
え”は“未実施時にチェック”
という質問より好まれます
か？
8
Should free text be an option
for a response to a specific
question?
(Also refer to the Comments
Domain for additional
information.)
特定の
に する
に、フ
リーテキストを プションと
して用いてもよいでしょう
か
(また、追加情報について
Commentsドメインを
し
て
さい。)
質問 対 回答
オ
CRF
Type
Paper
and
electroni
c
及び
子
紙
電
？
Rationale
question or a “Check if not done” box; in others it might be a blank
flag or list of values to indicate why data are missing. The “Yes/No
– assessment completed” question is preferred over the “Check if
not done” box because the “Yes/No” format helps to ensure that a
response is provided where as it is not absolutely clear if the “Not
done” box was missed/skipped if not checked.
これは
- はい/いいえ の
や、
実
にチ ック
ックスの
もあれば、 には、ブランクフラグやデータの
を す のリストとする
があるかもしれませ 。
実
に
チ ック
ックスよりも
- はい/いいえ の
の が
まれるのは、
実
ックスはチ ックが い
に
/ 略
したかどうかが全 明 でない一 で、 はい/いいえ
式は
が
されたことが 実であるためです。
The general recommendation from CDASH is that the collection
of free text comments and general comments pages should be
discouraged. Collection of free text should be limited to cases of
specific safety or therapeutic need in reporting or analysis, such as
Adverse Events, Concomitant Medications or Medical History.
CDASHの一 的な推奨では、フリーテキストコメントの収集及び
ジ ネラルコメント ージを推奨しないこととしています。フリーテ
キストの収集は、有 事 、 用薬、
のような、特定の安全性あ
るいは報告または解析に必要な治療の
に 定す
です。
CDASH recommends that questions be specific and clear rather
than open-ended. Instead of free text comment fields, CDASH
recommends a thorough review of the CRF by the protocol
development team to maximize the use of pre-defined lists of
responses.
CDASHは、
は
を求めるものより、 し
的で明
であることを推奨します。CDASHはフリーテキストコメントフィ
ールドの わりに、プロトコル作成チームがCRFを
的に
ュー
し、
が め定 されたリストを 大
用することを めます。
clarify whether an assessment has been performed.
これは、
が実 されたかどうかを明 にするた
めの 要なデータクエリの発 を
ます。
•
ェ
•
確
9
Should data be pre-populated
in the CRF?
データは、CRF に事前に
(
)してお
ですか
入力
CDASH_STD-1.0
上
くべき
記載
？
Paper
and
electroni
c
及び
子
紙
電
•
不
評価 施
確
生 防ぎ
• “評価完了
” 質問 “未 施時 ェ ”
ボ
場合
他
欠測理
由 示 値
場合
ん “未 施時
ェ ”ボ
“評価完了
” 質問 方
好
“未 施”ボ
ェ 無 場合 欠測 省
く 確
方 “
”形 回答
記入
確
•
• The collection and processing of free text requires
般
ペ
害 象 併
•
参照
くだ
Best Practice Recommendation
病歴
場合 限 べき
質問 自由回答
代
回答 予 義
最 限利
む ろ具体
徹底 レビ
勧
significant resources and is of limited use when
analyzing and reporting clinical data.
フリーテキストの収集と
は 大なリ ースが要
求され、かつ臨床データを解析及び報告する の有用
性は 定的です。
Sites may enter data into free text fields that
should be recorded elsewhere.
医療
が、 の
に
する
データをフリ
ーテキストフィールドに
するかもしれませ 。
Entering text from these fields into the database
is time consuming for data entry and requires CDM
resources to review the text for safety information
and inconsistencies with other recorded data.
これらのフィールドからテキストをデータ ースに
することは、データエントリーに
がかかり、
安全性情報のテキストの
ュー、そして の
デ
ータとの 一 を
ューするCDMのリ ースが必
要となります。
The CRF should be used as a tool to collect
unknown study data.
CRFは、 知の試験データを収集する ールとして
用される
です。
•
•
•
•
処理 多
限
機関 他 場所 記録 べき
入力
•
入力
• In general, study data should be collected and recorded by the •
site, not pre-populated.
• 一般に、試験データは医療機関で収集され記録されるべきで、事前 •
に記載(入力)すべきではありません。
利
• Fields in the database or on the CRF may be pre-populated if the
ソ
際
不 致 レビ
未
べき
レビ
ん
ベ
時間
他 記録
ソ
ツ
data are known to be the same for all subjects (e.g., MH CRF
CDISC, INC.
01/OCT/2008
STANDARD
Ref
Question
CDASH V1.0
CRF
Type
Best Practice Recommendation
Rationale
collects data for specific body systems - body systems may be
pre-populated), or if the data are assigned to the subject (e.g.,
subject ID, site ID).
す ての 験者が
データであることがわか ている
(例え
ば、MH CRFが特定の
部 のデータを収集
部 は め
(
)してもよい)、あるいは 験者に 当てられたデータの
(例え
ば、 験者IDや医療
ID)、データ ース あるいはCRF のフィ
ールドに事前に
されていても いませ 。
Note: This recommendation will be revisited once eCRFs are
integrated with electronic health records which will result in CRFs
populated with data from hospital or healthcare systems.
：eCRFが、
あるいは医療システムからのデータを
し
たCRFを作成する 子カルテと統 されれば、この推奨は
され
るでしょう。
Location data should be collected only when multiple possibilities
Location options are only used when the protocol
are present and the location is required to make a meaningful
specifies.
analysis of the data (e.g., a comparison of blood pressures collected
プロトコルが規定すると の 、部 の プション
supine, right arm and left arm).
が使用されます。
部 のデータは、
の
性が
し、部 が 要なデータ解析に
必要は
に り、収集される
です(例えば、
の
では
、
及び
を収集します）。
• べ 被 同じ
っ 場合
身体 位
‐身体 位 予 記載
入力
被 割
場合
被
機関
ベ 内
上
入力
構 ん
•
• 注記
10
11
Should location of
measurement and position of
subject (e.g., oral
temperature, blood pressure
from right arm, etc.) be
collected for each
assessment?
定部 及び 験者の
(例
えば、
、
の
)は、
とに収集する
でしょうか
Should sites be given
guidance on how to record
verbatim terms for adverse
events, concomitant
medications or medical
history in the CRF?
有 事 、 用薬あるいは
で用いる
用 のCRFへの
に して、医療
に
イダンスを
する
で
しょうか
測 位 被 体位
口腔体温 右腕 血圧
等 評価ご
べ
き
？
害 象併
病歴
記載 語
記録方法 関
機関
ガ
提供 べき
？
Paper
and
electroni
c
及び
子
紙
電
Paper
and
electroni
c
及び
子
紙
電
病院
電
反映
再検討
合
•
•
•
• 位
複数 可能 存在
場合 限
べき
右腕 左腕
位 重
血圧 比較 臥位
•
CDASH recommends not providing actual coding dictionaries to
the site for adverse events, concomitant medications or medical
history reported terms, as this may bias responses.
CDASHでは
にバイアスが る
性があるため、有 事 、
用薬あるいは
に する実 のコーディング 書を医療
に
しないことを推奨します。
•
併
供
回答
病歴 関
き み 位 オ
入 可能
際
辞
• CDASH recommends that guidance be provided
to the sites to ensure clear reporting of adverse
events, concomitant medications or medical history.
CDASHは、有 事 、 用薬または
の明 な
報告を 実にするために、医療
に イダンスを
することを推奨します。
For medications, this may include defining, for
example, whether generic or trade names are
permissible.
薬 について、例えば、一
または商品 が
かどうか定 することも
ます。
For medical history and adverse events, this may
include providing an understanding of the level of
害 象 •
機関 提
確
供
•
• 剤
可能
•
害 象 併
義
病歴 確
機関 ガ
提
般名
含み
名 許容
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
CDASH V1.0
Ref
Question
STANDARD
CRF
Type
Best Practice Recommendation
Rationale
detail needed for accurate medical coding (e.g.,
“Diabetes” should not be reported without also
providing the type) and sites may be encouraged to
record specific, medically correct terminology on the
forms (e.g., "hyperglycemia”, instead of "high blood
sugar").
と有 事 について、医学的に正 なコーディ
ングに必要な詳細な
ルを
すること(例えば、
はタイプが され 報告される
ではな
い)を
、医療
が
的で医学的に正しい用
(例えば、
の わりに
症 )をフ
ームに
することが ましいといえます。
• 病歴 害 象
確
レベ 把握
“糖尿病”
示 ず
べき
含み 機関 具体
語
“高血糖” 代 “高血糖 ” ォ
記録
望
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
CDASH V1.0
ドメインテーブルの概要
ドメインテーブルの概要
4. Overview of CDASH Domain Tables
4. CDASH
4.1. Introduction
4.1.
The CDASH data collection fields included in the following domain tables are the most
commonly used and should be easily identified by most implementers. It is recognized
and expected that sponsors will
will need to add additional data collection fields to capture
TA-specific data points as well as other data specified in the clinical study protocol or
required according to local regulatory requirements.
以 のドメインテーブルに まれるCDASHのデータ収集フィールドは、 も一 的に使用
されているものであり、
の実 者にと て
に特定されます。プロトコルに特定され
ていたり、 局の規制の要請で必要とされるようなデータと 様に、治療領域特有のデータ
イントを収集するために、
と
され、
されます。
Use the CDASH recommendations when developing company standards on the sponsor
level, taking into consideration the requirements of the stage of clinical development and
the individual therapeutic area requirements, and NOT on a trial-by-trial basis within
the sponsor organization.
下
序論
含
最 般
多く 装 っ 容易
同
依頼者が
依頼者が付加的なデータ
付加的なデータ収集
なデータ収集フィールドを
収集フィールドを追加
フィールドを追加する
追加する必要
する必要がある
必要がある
各
ポ
認識 予期
臨床開発のステージや各治療領域の要求を考慮し、依頼者組織内での試験ベースではなく、
依頼者レベルで社内のスタンダードを作成する際にCDASH推奨モデルを使用して下さい。
ァベ 順 配列
装 助
レ ウ
The CDASH domain tables are arranged in alphabetical order. CRF layout was not
within the scope of the CDASH project so as a help to implementers, the data collection
fields are presented in the order they commonly appear on a basic CRF.
CDASHドメインテーブルはアルフ
ット に
されています。CRF イア トは
CDASHプロジ クトの
外であるので、実 者の けとして、基本的なCRFで一 に
けられる
でデータ収集フィールドが用意されています。
The CO, IE, PE and DV domains contain new approaches that we would specifically like
to point out. These recommendations came about within the respective Domain Teams
and reflect the current thinking and standard practice taken by a significant number of
organizations/companies.
我々 指摘 新
含ん
各
内
多く 組織 企 取 入
在 考 方
施 反映
・Comments(
Comments コメント)(CO):非応答型コメントを集めるためのジェネラルコメント CRF の
作成は避けてください。特定のデータ収集フィールドに結びつけられた応答型コメントが、
• Comments: Avoid the creation of a General Comments CRF to collect unsolicited
comments. Solicited comments linked to specific data collection fields is the
recommended approach.
範囲
• Physical Examination: Record only whether or not an exam was done on the PE form.
Clinical sites are asked to record baseline abnormalities on a Medical History, Targeted
Medical History or Baseline Conditions CRF. Post baseline abnormalities or baseline
conditions that worsened during the clinical study are to be recorded on the Adverse
Event CRF.
• Protocol Deviations: Avoid creating a Protocol Deviations CRF if this information can
be derived from other domains or system functionalities.
CO、IE、PE、及び DV ドメインは、
が特に
したい しいアプローチを
でいま
す。これらの推奨は、 ドメインチーム で作成したものであり、
の
/ 業で り
れられている現 の え や標準的実 要領を
しています。
選択基準/除外基準)(IE): IEのフォームを用い、該当しない
・Inclusion/Exclusion Criteria(
Criteria
基準 けを収集します。
評価 だ
身体所見
ォ 検
み 記録 く
身体所見
施 機関 病歴 対象病歴
ベ
ベ
異常 記録
ベ
異常
悪 ベ
記録
・Protocol Deviations(
Deviations プロトコル逸脱
プロトコル逸脱)(DV): 他のドメインやシステム機能により本情報を
得ることができるのであれば、プロトコル逸脱CRFの作成は避けてください。
これらの推奨に関するより詳細な議論については、個々のドメインテーブルを参照下さい。
・Physical Examination(
)(PE): PE フ ームで 査が行われたかの を
して
Examination
さい。試験実 医療
は、
、
、あるいは ースラインコンディション CRF
において ースラインにおける
を
するよう求められます。 ースライン後の
や
試験中に 化した ースラインコンディションが、Adverse Event CRF に
されます。
だ
CDISC, INC.
CDASH_STD-1.0
般 見
推奨されるアプローチです。
• Inclusion/Exclusion Criteria: Use the IE form to collect only the criterion or criteria
NOT MET.
For a more detailed discussion regarding these recommendations please see the
individual domain tables.
受
ェ
順番
01/OCT/2008
CDASH V1.0
STANDARD
4.2. Data Collection Fields Generally Considered Not Necessary to Collect on
the CRF
As part of the development process each Domain Team reviewed sample CRFs currently
in use by the Domain Team members’ respective companies. After close review and much
discussion, the Domain Teams determined that some data collection fields were not
necessary to collect (i.e., not recommended for inclusion) on CRFs. These fields were
organized by domain and compiled into tables called “Data Collection Fields Generally
Considered Not Necessary to Collect on the CRF”. The “Rationale” column within the
tables contains the reasons(s) the Domain Teams determined the fields to be generally
not necessary to collect. In most cases it was because these fields would be derived or
would be collected elsewhere in the CRF. Sponsors are free to use these fields if deemed
appropriate for the type of study they are conducting and/or phase of development their
respective project is in. The tables are available for review on the CDISC website:
www.cdisc.org.
では通常収集
では通常収集する
通常収集する必要性
する必要性がないと
必要性がないと考
がないと考えられるデータ収集
えられるデータ収集フィールド
収集フィールド
4.2. CRF
各
各自
在
多く 議論
く
ち含
ご 整理
内
通常
理由 含ん
多く 場合
他 箇所
施
開 ェ
っ 切
考
場合
き
ウェ
上 レビ
作成のプロセスの中で、 ドメインチームは、メンバー
の会社で現 使用中のサンプル
CRF を
ューしました。
な
ューと
の
の後、ドメインチームは、い つ
かのデータ収集フィールドは CRF に収集される必要がない(すなわ
めるのは推奨されな
い)と決定しました。これらのフィールドは、ドメイン とに
され、“Data Collection
Fields Generally Considered Not Necessary to Collect on the CRF”というテーブルに集め
られました。テーブル の“Rationale”カラムは、ドメインチームが、
そのフィールドが
収集される必要はないと決定した
を
でいます。
の
、これらのフィールドは
されるか、CRF の の
で収集されます。依頼者は、実 している試験のタイプや
プロジ クトの 発フ ーズにと て適 であると えられる
には、これらのフィー
ルドを
に使用で ます。テーブルは CDISC
ブサイト:www.cdisc.org で
ュー
で ます。
レビ
導出
各 ェ
自由
き
綿密 レビ
基本データ
基本データ収集
データ収集フィールドのための
収集フィールドのための Core の定義
データ収集フィールドの異なるタイプの分類を容易にするために、以下のカテゴリが使用さ
4.3. Core Designations for Basic Data Collection Fields
4.3.
In order to facilitate classification of the different types of data collection fields, the
following categories were used:
れます:
• Highly Recommended: A data collection field that should be on the CRF (e.g., a
regulatory requirement).
・Highly Recommended（特に推奨）: CRF に
規制要 ）
。
件
• Recommended/Conditional: A data collection field that should be collected on the CRF
for specific cases or to address TA requirements (may be recorded elsewhere in the CRF
or from other data collection sources).
• Optional: A data collection field that is available for use if needed.
It is assumed that sponsors will determine which data collection fields will be collected
based on TA-specific data requirements, protocol and other considerations.
条件付き
存在すべきデータ収集フィールド（例えば、
別 場合
・Recommended/Conditional
）:特 な
、あるいは治療領域の要求事項
Recommended/Conditional（推奨/
のために、CRF に収集されるデータ収集フィールド(CRF の のどこかに、あるいは のデ
ータ収集 ースから
される
性があります)。
他
可能
・Optional（任意）: 必要に応じ利用可能なデータ収集フィールド。
ソ
記録
他
どのデータ収集フィールドが収集されるかは、治療領域特有の要求事項、プロトコル、また
の
す
事 に基づ 、依頼者が決定することになります。
他 考慮 べき 柄
き
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008
STANDARD
CDASH V1.0
4.4.
4.4. Explanation of Table Headers
1
Data
Collection
Field
2
Variable
Name
(CDASH
variable
name shaded)
shaded)
3
Definition
4
Case Report
Form
Completion
Instructions
5
Additional
Information
for
Sponsors
6
CDASH Core
テーブルのヘッダーに関
テーブルのヘッダーに関する説明
する説明
1
Data
Collection
Field
2
Variable
Name
(CDASH
variable
name shaded)
shaded)
3
Definition
4
Case Report
Form
Completion
Instructions
5
Additional
Information
for
Sponsors
6
CDASH Core
1. Data Collection Field: 収集される基本的なデータ
1. Data Collection Field: Basic data to be collected.
義
ベ
変数名
(網掛け
網掛けのCDASH変数名): 網掛けのカラムはCDASH特有を意味する変数名です(例えば、
CMONGO、CMTTIM)。これらの変数名は“SDTM類似の変数”であり、申請に必要となる
SDTMIG変数の導出を容易にします。
2. Variable Name: SDTMIGにて定 されているSDTM ースの
2. Variable Name: Lists the SDTM-based variable name defined in the SDTMIG.
(CDASH variable name shaded):
shaded): This column also provides suggested variable names
(e.g., CMONGO and CMTTIM). These variable names are “SDTM-like variables” and
can help facilitate the derivation of SDTMIG variables needed for submission.
3. Definition: Describes the purpose of the data collection field. The text may or may not
mirror the text in the SDTMIG (in the “Variable Label” or “CDISC Notes” columns).
Where applicable, CRF text examples are presented in italics. When an available code
list better describes the text, a reference to the code list will be provided, in the format
{code list name} (see Section 2.2 for information about controlled terminology).
4. Case Report Form Completion Instructions:
Instructions: Contains information for the clinical site
on how to enter collected information on the CRF.
5. Additional Information for Sponsors: Contains further information, such as rationale
and implementation instructions, on how to implement the CRF data collection fields.
6. CDASH Core: Contains the CDASH core designations for basic data collection fields
(see Section 4.3 for definitions of core designations).
3. Definition: データ収集フィールドの目的。テキストはSDTMIG(“Variable Label”または
“CDISC Notes”のカラム )のテキストを
することがある。
当する
、CRFテキストの例がイタリック で
されています。
テキストをより詳細に 明しているコードリストがあれば、コードリストの
が
さ
れます。 式は、{コードリスト } (規制用 に する情報はセクション2.2を
)、となり
ます。
該
場合
形
内
説
反映
名
体 提示
語 関
参照先 提示
参照
記入方法に関す
4. Case Report Form Completion Instructions:収集された情報のCRFへの
る試験実 医療
けの情報
施 機関向
装方法に関する、
5. Additional Information for Sponsors: CRFデータ収集フィールドの実
的
や実
などの追加情報
論理 根拠 装手順
6. CDASH Core: 基本的なデータ収集フィールドにおいて、CDASHのcoreとなるもの。(core
指定の定義はセクション4.3を参照)
CDISC, INC.
CDASH_STD-1.0
01/OCT/2008