統計学者は、データ エラーが分析および調査結果に及ぼす全体的な影響を評価する責任を負います。
適正臨床データ管理基準 (GCDMP、章: データ品質保証および管理) および ICH E9 (臨床試験の統計原則) によれば、データ マネージャーはクリーニングと検証を通じてデータの正確性と完全性を確保し、統計担当者は観察されたデータの不一致が統計的に有意であるかどうか、または研究結果の妥当性、検出力、解釈可能性に影響を与える可能性があるかどうかを判断します。
品質監査担当者（C）は問題を特定して報告しますが、分析の影響を定量化することはありません。治験責任医師（D）は臨床的な監督責任を負いますが、統計的評価は担当しません。したがって、データベース監査後、統計担当者（B）は正式な評価を行い、エラーの規模と性質が結果にバイアスを与える可能性があるか、あるいは再分析が必要かどうかを判断します。
参考資料（CCDM検証済みソース）:
SCDM 適正臨床データ管理基準（GCDMP）、章：データ品質保証と管理、セクション7.3 - データ監査と影響評価 ICH E9 - 臨床試験の統計原則、セクション3.2 - データ品質と分析の影響評価 FDA業界向けガイダンス：臨床試験で使用されるコンピュータ化システム - データ検証と分析レビュー

フロントエンド チェックは、データ入力時に実行されるリアルタイム検証の一種で、通常は電子データ キャプチャ (EDC) システムまたはデータ入力インターフェイス内で実行され、ユーザーが続行したりレコードを保存したりする前に、テキスト ボックス (または任意の入力フィールド) に入力されたデータが有効で、論理的に正しく、予期されたパラメータの範囲内であることを確認するように設計されています。
優良臨床データ管理基準（GCDMP）の「データ検証とクリーニング」の章によると、編集チェックはデータの正確性、一貫性、完全性を保証するデータ検証の不可欠な要素です。フロントエンドチェックはデータ収集インターフェース内に実装されており、データが入力されるとすぐに実行されます。これにより、無効な入力（数値フィールドへの文字入力、範囲外の値、不適切な日付形式など）がシステムに受け入れられるのを防ぎます。
フロントエンドチェックの例は次のとおりです。
数値フィールドが数字のみを受け入れることを確認します (例: 重量にテキスト文字を含めることはできません)。
日付が許容範囲内であることを確認します（例：対象者の生年月日より前ではないこと）。
先に進む前に必須フィールドへの入力を求めます。
これは、バックエンドチェックやプログラムチェックとは異なります。バックエンドチェックは通常、入力後のデータの不整合を特定するためにバッチプロセスで後から実行されます。手動チェックは、人間が行うレビューであり、多くの場合、自動的に検証できないコンテキストやデータ（例：ナラティブ評価）を対象とします。
フロントエンドの編集チェックは、可能な限り推奨されます。これは、ソースコードでのエラーを防ぎ、下流のデータクエリとクリーニングサイクルの数を削減できるためです。これは、データ品質の保証、規制遵守、そしてデータ管理業務の効率化に大きく貢献します。
参考資料（CCDM検証済みソース）:
臨床データ管理協会（SCDM）、適正臨床データ管理基準（GCDMP）、章：データ検証とクリーニング、セクション6.2 - 編集チェックとリアルタイムデータ検証、FDA業界向けガイダンス：臨床研究で使用されるコンピュータ化システム、セクション6 - データ入力および検証管理、ICH E6（R2）適正臨床実施基準、セクション5.5 - データ処理と記録の整合性、CDISC運用データモデル（ODM）仕様 - 編集チェック実装標準

電子データキャプチャ（EDC）システムでは、編集チェックは実行時期と方法に基づいて分類されます。通常、即時（データ入力時）またはバッチ（入力後）です。複数の訪問やフォームからのデータを必要とするチェックは、システムにまだ存在しない情報に依存する可能性があるため、データ入力時に実行するのは一般的に非効率的です。
適正臨床データ管理基準（GCDMP、章「データ検証とクリーニング」）によれば、ベースラインとフォローアップの血圧の比較や、スクリーニングと投薬の日付順序の検証といった、複数回の訪問における一貫性チェックは、データ入力時ではなく、バッチ検証またはスケジュール検証として実行する必要があります。これらの複雑なチェックをリアルタイムで実行すると、システムパフォーマンスが低下し、クエリ負荷が不必要に増加し、関連データがまだ入力されていない場合には施設ユーザーに混乱をもたらす可能性があります。
逆に、有効な範囲、形式、または定義済みの値リスト (オプション A、C、および D) に対する編集チェックは、基本的なエラーを防ぐためにデータ入力時にすぐに実行される単純なローカル検証です。
したがって、クロス訪問整合性チェック (オプション B) は後で実行することが最適であり、リアルタイムのデータ入力検証には非効率的です。
参考資料（CCDM検証済みソース）:
SCDM 適正臨床データ管理基準（GCDMP）の章：データ検証とクリーニング、セクション6.4 - リアルタイム編集チェックとバッチ編集チェック、FDA 業界向けガイダンス：臨床研究で使用されるコンピュータ化システム - 編集チェックとデータ検証ロジックに関するセクション、CDISC SDTM 実装ガイド - 時間的データ一貫性検証に関するセクション

1 年後の全死亡率の有効性エンドポイントは、各被験者の死亡日によって直接左右されるため、オプション D - 死亡日が必須のデータ要素となります。
GCDMP（臨床試験プロトコルおよびデータ計画の章）およびICH E3/E9ガイドラインによれば、主要な有効性解析は、特にエンドポイントが死亡または生存に関わる場合、イベント発生までの時間データに基づく必要があります。死亡日を知ることで、ランダム化からイベント発生までの時間を正確に計算することができ、これは生存解析（例：カプラン・マイヤー曲線）に不可欠です。
死亡原因（C）は安全性や二次解析のために収集される場合がありますが、全死亡率には原因を問わずあらゆる死亡が含まれます。薬物濃度（A）と凝固時間（B）は薬力学的または探索的なエンドポイントとして機能する場合がありますが、死亡率を直接測定するものではありません。
参考資料（CCDM検証済みソース）:
SCDM 適正臨床データ管理基準（GCDMP）、章：データ管理計画とプロトコルレビュー、セクション5.4 - エンドポイントに必要なデータの定義、ICH E9 - 臨床試験の統計原則、セクション2.3 - イベント発生までの時間エンドポイント、FDA業界向けガイダンス：医薬品開発および承認のための臨床試験エンドポイント

研究データを CDISC SDTM 形式で FDA に提出するには、スポンサーは研究の運用データベース (EDC など) から収集したデータを SDTM 準拠のドメインにマッピングして変換する必要があります。
GCDMP (章: 標準とデータ統合) および CDISC SDTM 実装ガイドによると、このプロセスには以下が含まれます。
臨床データベースの生データ要素を SDTM ドメイン (DM、AE、VS など) にマッピングします。
SDTM の構造および命名規則に準拠するようにデータを変換します。
CDISC コンプライアンス ツール (例: Pinnacle 21) を使用して出力を検証します。
データ（B）の再入力は不要であり、意向書（C）も不要です。SDTMはFDAによって遡及的申請と将来的申請の両方で明示的に認められているため、（D）は誤りです。
したがって、オプション A が正解です。つまり、規制当局への提出のために既存のデータを SDTM 形式にマッピングして変換します。
参考資料（CCDM検証済みソース）:
SCDM GCDMP、章：標準とデータ統合、セクション5.3 - データ変換とCDISCマッピング、CDISC SDTM実装ガイド、バージョン3.4 - データ変換と提出要件、FDA研究データ技術適合ガイド、セクション2.2 - SDTMマッピングと検証