治験グレード

「治験グレード」は、治験がベストプラクティスに準拠しているかどうかに基づいて治験をレビューし、等級付けする機能です。展開後、治験のスタディデザインに対して一連のチェックを実行する治験グレードジョブが実行されます。これらのチェックでは、Veeva CDMS のベストプラクティスに照らして定義または定義のグループをレビューし、スタディデザイン、パフォーマンス、およびデータ抽出に影響を与える領域を明らかにします。治験グレードは [治験グレード] タブで確認できます。

前提条件

必須権限

標準の CDMS 治験設計者治験ロールを持つユーザは、デフォルトで下記のアクションを実行することができます。組織がカスタム治験ロールを使用する場合、お客様のロールに以下の権限が付与されている必要があります:

タイプ	権限ラベル	制御
標準タブ	Studio タブ	Studio タブへのアクセス権限
標準タブ	治験グレードタブ	試験グレードタブへのアクセス権限
機能権限	治験グレードの表示	治験グレード記録の閲覧

治験に制限付きデータが含まれている場合、それを閲覧するには制限ありデータアクセス権限が必要です。

治験ロールについて詳しくご確認ください。

注：この一連の確認の目的は、現在または将来のスタディデザインの変更を純粋に評価し、（検証の警告と同様に）提案することです。スタディデザインの複雑さと多様性から、一部の選択がベストプラクティスから逸脱することがあり、それにより全体の評価が低くなることがあることは理解されています。そのため、この機能は特定の個人のパフォーマンスを測定または評価するために設計されたものではなく、そのように使用することはできません。

治験グレードの使用方法

DEV から TST への展開が成功すると、治験グレードが自動的に実行されます。展開後、Vault はジョブを実行してスタディデザインを評価し、その結果をログに記録して Excel™ ファイル形式にフォーマットされます。ジョブが完了すると、全体的な定量的スコアと各チェックの詳細なスコアを含む治験グレードレコードが [治験グレード] タブに作成されます。

スタディが定量的スコアを受け取ると、その結果が Veeva CDMS サービスによってレビューされ、スタディデザインに必要な改良点が示されます。これらの提案は、定性的スコアとともに、治験グレードレコードの [治験グレードレビュー] サブタブに記録されます。

スタディがレビューされ評価が下された後、Veeva サービスのレビュー担当者と協力して次のステップを決定することができます。

治験グレードおよび治験グレードレビューの表示方法

各治験グレードレコードには、[詳細]、[システムグレード]、[治験グレードレビュー]、[治験グレードスコア]、[その他情報]、[添付ファイル] の各サブタブがあります。

詳細: このセクションには、名前、スタディ、スタディバージョン、ビルド、および最終実行またはレコードがシステムによって最後に更新された時刻などのスタディ情報が表示されます。
システムグレード: このセクションには、治験グレードスコアの加重平均を計算して算出されるスタディの定量的スコアが表示されます。このスコアは、[このスタディはベストプラクティスを使用] フィールドに表示されます。
治験グレードレビュー: このセクションには、Veeva Services のレビュー担当者によって作成された定性的スコアおよび評価である治験グレードレビューが表示されます。
治験グレードスコア: このセクションには、スタディ環境に対して実行されたチェック項目の一覧と対応するスコアの詳細が表示されます。
その他の情報: このセクションには、作成日や最終更新日など、治験グレードレコードに関する基本情報が表示されます。
添付ファイル: このセクションには、Excel™ ファイル形式の治験報告書カードが添付されています。

チェック項目とその解決方法

次の表に、可能性のある治験グレードのチェック項目と、ログに記録されたエラーの解決方法を示します：

名前	ラベル	解決方法
codelist_consistency	コードリストの書式が一貫している	異なるコードリストのコードおよびデコードについて、コードリストおよびコードリスト項目の書式（大文字と句読点）が一致していることを確認します。
codelist_display	コードリストが、コードリスト内の項目数に応じて適切に表示されている	ベストプラクティスでは、6 項目未満のコードリストはラジオボタン、6 項目以上のコードリストは選択リストとして表示することを推奨しています。多くの場合、コードリストはラジオボタンの方が見やすくなりますが、選択肢が多すぎるとフォームの表示方法やサイトでの使用方法に影響します。
event_group_repeating	繰り返しイベントグループが可能な場所で使用されている	類似フォームを持つイベントを確認し、可能であれば、類似フォームを持つイベントを使用して繰り返しイベントグループを作成します。
event_group_usage	イベントグループが適切に使用されている	スタディでのイベントグループの使用状況を確認：イベントグループが過剰に使用されている（イベントごとに 1 つのイベントグループを保有していないか）、または十分に使用されていない（イベントグループを 1 つしか保有していないか）事象グループ? 注：場合によっては、1 つのイベントグループがスタディに適していることがあります。
form_order	複数のイベント間で再利用されるフォームが、同じ相対順序になっている	フォームの順序に関連するチェックを受け取った場合、複数のイベント間でフォームを再利用しており、それらのフォームのいくつかが（互いに関連して）異なる順序になっています。これを解決するには、フォームを再利用しているイベントを確認してフォームが使用されているすべてのイベントで同じ相対順序になるように整理します。チェックでは正しい順序を判断できないため、正しい順序を判断し、それに従ってフォームをモデリングする必要があります。
form_total_items	フォームに正しい数のアイテムが表示されている	このチェックでは、1 つのフォームに表示するアイテム数が多すぎる可能性がある状況を探します。これが発生した場合、デフォルトの繰返しアイテムグループが多数の行を生成しているか、繰返しアイテムグループ内に多数のアイテムがあるか、または繰返しアイテムグループの繰返し最大値が極端に大きいなどの可能性があります。これを解決するには、データセットの要件に照らしてアイテムグループを確認します。すべてのデータがこのデータセットで収集する必要があるかどうか、既定値が予期される既定値のみであることを確認し、繰り返しの最大値を適切な値に更新します。私たちは、研究の要件のためにこれらの更新ができない場合があることを認識していますが、フォームが大きくなりすぎると EDC のパフォーマンスに影響を与える可能性があることに留意してください。
form_unnecessary_copy	フォームの不要なコピーが回避されている	可能な場合は、アイテム、アイテムグループ、およびフォームを再利用します。この問題が避けられない場合もあります。
rule_blank_checks	ルールの NULL 値および空白値チェック	必要に応じて、テキスト、日付、数値の識別子に IsBlank() を使用するルールを作成します。
rule_complexity	ルールの複雑さが適切	ルール全体の数を減らすために複雑なルールを作成する必要がある場合が多くありますが、これらのルールの順列によってパフォーマンスの問題が発生する場合もあります。このような場合、1 つのルールで可能な順列の数を減らすために、これらのルールの一部を分割する必要がある場合もあります。この問題を解決するには、完全修飾されていない識別子またはアクションと繰り返しオブジェクトを確認して、チェック項目数を減らすか、これらの一部を別のルールに分割できる可能性があるかどうかを確認します。
rule_dynamics_results	動的ルールアクションが、グローバルを適切に利用している	アクションのターゲットとイベントグループに一致するように動的アクション範囲を変更します。スコープがグローバルで、完全修飾アクション識別子があり、イベントグループが繰り返しの場合、いずれかの値を変更する必要があります。アクション識別子で @Event を使用するか、スコープをグローバル以外に変更します。
rule_qualified_identifiers	ルールが繰り返しオブジェクトに @ 識別子を使用している	繰り返し定義（イベントグループ、フォーム、アイテムグループ）に反するルールは、修飾せずにイベントまたはイベントグループの一致するスコープを持つか、修飾せずにグローバルスコープを持つ必要があります。
rule_scope	ルールのスコープがアクションに対して適切に設定されている	アクションのターゲットおよび式で使用される識別子は、すべて完全修飾されているか、すべて完全修飾されていない必要があります。@Form、@Event などの使用に一致するようにアクションまたは識別子を更新します。