試験グレード
「試験グレード」は、試験がベストプラクティスに準拠しているかどうかに基づいて試験をレビューし、等級付けする機能です。展開後、試験のスタディデザインに対して一連のチェックを実行する試験グレードジョブが実行されます。これらのチェックでは、Veeva CDMS のベストプラクティスに照らして定義または定義のグループをレビューし、スタディデザイン、パフォーマンス、およびデータ抽出に影響を与える領域を明らかにします。試験グレードは [試験グレード] タブで確認できます。
前提条件
注:この一連の確認の目的は、現在または将来のスタディデザインの変更を純粋に評価し、(検証の警告と同様に)提案することです。スタディデザインの複雑さと多様性から、一部の選択がベストプラクティスから逸脱することがあり、それにより全体の評価が低くなることがあることは理解されています。そのため、この機能は特定の個人のパフォーマンスを測定または評価するために設計されたものではなく、そのように使用することはできません。
試験グレードの使用方法
DEV から TST への展開が成功すると、試験グレードが自動的に実行されます。展開後、Vault はジョブを実行してスタディデザインを評価し、その結果をログに記録して Excel™ ファイル形式にフォーマットされます。ジョブが完了すると、全体的な定量的スコアと各チェックの詳細なスコアを含む試験グレードレコードが [試験グレード] タブに作成されます。
スタディが定量的スコアを受け取ると、その結果が Veeva CDMS サービスによってレビューされ、スタディデザインに必要な改良点が示されます。これらの提案は、定性的スコアとともに、試験グレードレコードの [試験グレードレビュー] サブタブに記録されます。
スタディがレビューされ評価が下された後、Veeva サービスのレビュー担当者と協力して次のステップを決定することができます。
試験グレードおよび試験グレードレビューの表示方法
各試験グレードレコードには、[詳細]、[システムグレード]、[試験グレードレビュー]、[試験グレードスコア]、[その他情報]、[添付ファイル] の各サブタブがあります。
- 詳細: このセクションには、名前、スタディ、スタディバージョン、ビルド、および最終実行またはレコードがシステムによって最後に更新された時刻などのスタディ情報が表示されます。
- システムグレード: このセクションには、試験グレードスコアの加重平均を計算して算出されるスタディの定量的スコアが表示されます。このスコアは、[このスタディはベストプラクティスを使用] フィールドに表示されます。
- 試験グレードレビュー: このセクションには、Veeva Services のレビュー担当者によって作成された定性的スコアおよび評価である試験グレードレビューが表示されます。
- 試験グレードスコア: このセクションには、スタディ環境に対して実行されたチェック項目の一覧と対応するスコアの詳細が表示されます。
- その他の情報: このセクションには、作成日や最終更新日など、試験グレードレコードに関する基本情報が表示されます。
- 添付ファイル: このセクションには、Excel™ ファイル形式の試験報告書カードが添付されています。
あなたのスタディグレードを理解する
Vaultは、スタディグレードの1つとして、2つのスコア(0~4)を提供します。1つは、症例ごとに評価とスコアリングを行うチェックベースのスコア、もう1つは、個々のチェックスコアの加重計算に基づく総合的な計算スコアです。
これらのスコアの意図は、システムの観点からのチェックの概要を提供することです。これらのスコアは標準化されていますが、スタディデザインのばらつきや要件によっては、逸脱が必要になる場合があります。そのため、定性的なレビュープロセスを導入しています。
以下の表は、スタディグレードの採点システムの概要を示しています。
スコア | 説明 |
---|---|
0 - 該当なし | このコンテンツでは、そのデザインは評価に適用できませんでした。このスコアは、システムがデザインと指定された基準との関連性を判断できない場合、または測定対象の側面がこの特定のレコードに適用されない場合に発生することがあります。その結果、評価は行われませんでした。* |
1 - まったく同意しない | そのデザインはシステムの期待から大幅に逸脱しており、パフォーマンスやユーザビリティの基準を大きく下回っています。これは、整合性に大きなギャップがあることを示しています。 |
2 - 同意しない | このデザインは、期待されるデザイン基準に沿ったものですが、パフォーマンスやユーザビリティに関する主な期待にはまだ応えられていません。いくつかの機能は動作するかもしれませんが、全体的な設計は不十分であり、システムのベースライン基準を満たすには改善が必要です。 |
3 - 同意する | デザインは期待される基準にうまく適合しています。パフォーマンスと操作性はシステムの期待に沿っており、デザインは要件を満たしています。若干の改善の余地はあるかもしれませんが、概ね機能的で効率的な記録です。 |
4 - まったく同意する | そのデザインは、システムのパフォーマンスとユーザビリティに対する期待に応え、基準に理想的な形で適合しています。 |
*Vaultは、以下の場合はレコードの評価をスキップします。
- スケジュールには使用されていません
- これらはルールに関連しており、以下の基準を満たしています。
- 1つ以上の識別子が使用中の定義と一致しません。
- それらは非アクティブまたはアーカイブされています。
チェック項目とその解決方法
次の表に、可能性のある試験グレードのチェック項目と、ログに記録されたエラーの解決方法を示します:
名前 | ラベル | 解決方法 |
---|---|---|
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 などの使用に一致するようにアクションまたは識別子を更新します。 |