規則に関するヒントとベストプラクティス

このページでは、試験のための規則を作成する上で役立つさまざまなヒントとベストプラクティスがリストされています。規則の作成の方法については、規則の作成を参照してください。

規則の詳細 (プロパティ)

規則の説明

• 短く、かつ完結した文章を使用します。
• すべてのパラメータを含む規則の意図を明示的に示します。
  • フォームおよびイベントを追加する場合、規則がどのように機能するかについての説明を入力します。
    • 例: 被験者はすべての適格性基準を満たしたか？「はい」の場合、治療イベントグループ (egTREAT) を追加します。
  • クエリの規則の場合、「... 以上または等しい」と「... より大きい」のように、値をどのように処理する必要があるかを正確に示します。
    • 例: 「終了日は開始日よりも前である。」と、「終了日は開始日と同じかそれよりも前である。」
• テスターは説明文に対するテストを行い、その規則が合格するかどうかを判断することに留意します
• 例えば、「AESTDAT」の代わりに「開始日」を使用するなど、試験の仕様を生成するために、説明文中に項目ラベルを使用します。

規則の範囲と動的アクション

必要に応じて、規則の範囲には常にイベントグループ内を選択することを確認します。これは、規則が想定通りに発動しない場合のトラブルシューティングによくある理由です。

メール送信ルール

Vault はメールルールのルール実行データを保存しないため、メール送信ルールを作成時は常にトークンを使用してください。

不足しているデータの評価 (空白処理)

ユーザ定義の規則の場合、データが不足していないことを確認するためのロジックを式内に含めます。不足しているデータがある場合のシナリオの考慮を忘れると、サーバエラー、クエリの重複、その他の予期せぬ動作に遭遇する可能性があります。

Not(IsBlank(ITEM)) を含めて、データが不足していない、または null ではないかを確認します。

数値フィールドを評価する場合、規則エディターの空白処理プロパティを使用して、Vault が空白値を処理する方法を選択する必要があります。以下のオプションから選択できます:

• As zero: 式計算を完了できるように、空白値に 0 が代入されます。
• As null: 空白値を null として扱い、式全体で null/blank 値を返します。

式とロジック

• #define 文は、識別およびコピーの効率を上げるために、項目の正確な名前を使って変数を識別するか、できるだけ正確に近い名前を使用する必要があります。
• アイテムの名前がアンダースコア (_) で始まる場合、#define 文内のアンダースコアを削除するために、変数を名前変更しなければなりません。これを行わないと、構文エラーが発生します。
• 規則を明確にする上で必要となる場合は、/* ... */ を使用して規則の先頭にコメントを追加します。これらは規則の式の最初に追加する必要があり、そうしない場合、規則を保存することができません。
• 試験実施中に、別のスタディデザイナーが必要になる可能性について検討します。式で項目に適切に名前が付けられていれば、規則を明確にするのに役立ち、改訂時の労力が軽減されます。
• 規則を明確化するために、空白と改行を使用します。

ここでは、スタディデザイナーは、ロジックの別々のセクションを分割するために余分の行を置くことを選択しました。また、式の中のそれぞれのロジック部分には別の行を使い、余分な空白で演算子を整列させています。

タイムゾーン

以下のベストプラクティスは、規則内のタイムゾーンに適用されます:

• DateValue を使用する場合は、常に @Site.timezone__v パラメータを含めます。これにより、Vault は確実にその施設のタイムゾーンを使用して日付を返します。または、選択したタイムゾーンを指定することもできます。タイムゾーンの入力形式については、こちらのリストを参照してください。
• 日付と時刻を一緒に加算して日時を返す場合、演算子 + はユーザのタイムゾーンを使用します。この操作を施設のタイムゾーンで行うには (CDMS の場合は推奨)、StartOfDate(date, @Site.timezone__v) + time を使用します。

アイテム値の設定と派生値の設定

22R3 リリースでは、派生値の設定ルールがアイテム値の設定をクロスフォームの派生機能に置き換えました。

このため、同じスタディ内にアイテム値の設定ルールと派生値の設定ルールを含めることはできないため、あるルールタイプを使用するスタディのルールを別のルールタイプを含むスタディにコピーすることも、その逆もできません。

項目値の設定ルールと派生値の設定ルールでは、@Form 浮動識別子 (「ワイルドカード識別子」とも呼ばれる) を使用する必要があります。これらのルールタイプは @Form 浮動識別子を使用するため、ルールアクションを同じレベルに修飾する必要があります。

派生値の設定ルール とアイテム値の設定ルールの詳細を御覧ください。

日付比較の規則

日時と日付の比較

以下の 2 つの例では、日時タイプの項目の値をイベント日付と比較する方法が示されています。この構文は、あらゆる日付/日時の比較に適用されます。

以下の不明なものを許容しない日時項目:

Not(IsBlank(DTC))
&&
Not(IsBlank(EVDAT))
&&
DateValue(DTC, @Site.timezone__v) != EVDAT

以下の不明なものを許容する日時項目:

Not(IsBlank(EVDAT))
&&
Not(IsBlank(VSDTC))
&&
If(Right(VSDTC , 4) = "UNKZ", DateValue(MinDateTime(VSDTC), 'UTC'), DateValue(MinDateTime(VSDTC), @Site.timezone__v)) != EVDAT

日付け、および日時を = で比較する場合、Vault は Vault が使用するタイムゾーンを使用して、日時を日付に変換します。施設のタイムゾーンを使用した場合、DateValue({datetime}, @Site.timezone__v) を使用します。

日時と日付 & 時刻の比較

日付アイテムと時刻アイテムを共に追加して日時 (DateItem + TimeItem) を作成する場合は、StartOfDay(Date, @Site.timezone__v) を使用してから、あなたの時刻値をそれに追加します。日付と一緒に使うと、StartOfDay は 00:00 を返します。

以下の例では、ラボの収集日時が経口投与の開始日と開始時間の 8 時間 +/- 30 分後であることを確認します。次のスタディ設計を参照します:

• LBDTC: ラボパネルフォームの日時タイプ アイテム
• EXSTDAT: 日付タイプ アイテム
• EXSTTIM: アイテム 同じ フォームの時刻タイプを EXSTDAT として

この例では @Form 浮動識別子 (「ワイルドカード識別子」とも呼ばれる) を使用しているため、ほとんどの場合、ルールアクションは同じレベルに修飾する必要があります。

#define LBDTC @Form.LBHEADER.LBDTC
#define EXSTTIM $eg_MAINC1.ev_VISIT1.EXOR.ig_EXOR.EXSTTIM
#define EXSTDAT $eg_MAINC1.ev_VISIT1.EXOR.ig_EXOR.EXSTDAT

Not(IsBlank(LBDTC))
&&
Not(IsBlank(EXSTTIM))
&&
Not(IsBlank(EXSTDAT))
&&
Not(InWindow(
    LBDTC,
    StartOfDay(EXSTDAT, @Site.timezone__v) + EXSTTIM,
    Minutes(450),
    Minutes(510),
    false,
    false
))

Rule Details Form: Lab

将来の日付規則

将来の日付をチェックするカスタム規則が必要な場合は、式内で DateValue(Now(), @Site.timezone__v) を使用します。Now() と Today() および DateValue() は UTC 形式に変換された日付を返します。協定世界時 (UTC) は、経度 0 度の子午線に基づく標準時です。

イタリア、南アフリカ、オーストラリアなど、日付や時刻が UTC 以外の国にある場合、@Site.timezone__v が含まれていない場合、規則が予期せず発動することがあります。ベストプラクティスとして、@Site.timezone__v を使用することで、変換された値を施設のタイムゾーンに返し、規則が想定通りに作動するようにします。

イベント日と日付項目の比較

スタディデザイナーは、@Event.event_date__v を浮動識別子として使用することで、イベントをより多く網羅し、書く規則の数をより少なくするよう試みることができます。ただし、@Form とは異なり、イベントは相互交換しません。@Event.event_date__v を持つ規則は、特定のイベント日が修正された場合には再評価されません。

ベストプラクティスとして、イベント日 ($EventGroup.Event.event_date__v または @EventGroup.Event.event_date__v) を比較する場合は、完全修飾されたイベント識別子を使用し、各イベントインスタンスに規則を 1 つ作成します。

例えば、以下のような規則では、ユーザがイベント内で定義済みのフォームに記入してイベント日を修正した場合、再評価されません。

#define EVDAT @Event.event_date__v
#define DAT @Form.ig_VS.VSDAT
EVDAT != DAT

以下の例では、完全修飾されたイベント日の識別子と、(不明な) 部分的日付を許容しない日付項目の比較が示されています:

#define QSDAT @Form.QS.QSDAT
#define EVDAT $FOLLUP.V7.event_date__v

Not(IsBlank(QSDAT))
&&
Not(IsBlank(EVDAT))
&&
QSDAT > EVDAT

Rule Details Form: QS

以下の例では、完全修飾されたイベント日の識別子と、不明な時間を許容する日時タイプ項目を比較しています。この式は、評価日時 (EGDTC) の項目がそのフォームのイベント日と同じでないときに、クエリを開くクエリアクションルールのためのものです。

#define EVDAT $FOLLUP.FOLLUP.event_date__v
#define EGDTC $FOLLUP.FOLLUP.ECG.ig_ECG.EGDTC
Not(IsBlank(EVDAT))
&&
Not(IsBlank(EGDTC))
&&
If(
     Right(EGDTC, 4) = "UNKZ",
     DateValue(MinDateTime(EGDTC), 'UTC'),
     DateValue(MinDateTime(EGDTC), @Site.timezone__v)
) != EVDAT

その他の @Event の使用例についてはどうですか？

@Event を使用して、同じイベント内の他のフォームを参照します。例えば、同じイベント内の薬剤管理 (EX) フォームの一定時間内にバイタルサインを取る必要がある場合、@Event.FORM.IG.ITEM を使用して他のフォームを参照することができます。このように式を記述することで、複数のイベントにまたがって規則を再利用することができます。

#define VSDTC @Form.VSTPT2.VSDTC
#define EXSTDTC @Event.EX.EX.EXSTDTC

Not(IsBlank(VSDTC))
&&
Not(IsBlank(EXSTDTC))
&& 
Not(InWindow(VSDTC, EXSTDTC, Minutes(5), Minutes(10), false, false))

Rule Details Form: VS

時刻と時刻 (時刻比較規則)

静的タイムポイント

例: 12:00pm 以降の時刻が入力された場合にクエリを発動

TIM1 > Time(12,0,0)

2 つの時刻の比較

時刻 - 時刻 は 2 つの時刻間の分数を返します。

これらの規則は、(TimeA - TimeB > #) という文として記述され、計算によって TimeA と TimeB の間のデルタを分単位で数値として返します。

例: 投与終了時刻が投与開始時刻と同じまたはそれ以降である

EXENTIM - EXSTTIM >= 0

例: 輸液終了時刻が輸液開始時刻から12時間以上経過している場合 (注記: 12 時間×60 分 = 720 分)

EXENTIM - EXSTTIM > 720 

この例は、項目と分数を計算する式とを比較することによっても作成することができます。

EXENTIM - EXSTTIM > 12*60

DateValue 付きの規則

DateValue() 関数を使用した規則を作成する場合は、常に `DateValue(, @Site.timezone__v) を使用します。

イベント日規則と「発生がありません」

被験者がイベントを欠席しても、引き続き次のイベントに参加できるプロトコールであるかどうかを検討することは重要です。同様に、施設がイベントについて発生がありませんとマークする可能性のあるイベント日を確認する規則についても考慮することが重要です。

規則の式の中で Not(IsBlank()) 関数を使用して、日付が入力されているかどうかを確認することは既にご存知のことでしょう。これを拡張して、イベントの変更理由 ($EventGroup.Event.change_reason__v) へのエントリを確認することで、施設が _ Event_ の変更理由を発生がありませんとマークしたかどうかを確認できます。Vault は、施設が選択したイベントが発生しなかった理由をここで記録します。

以下の例は、発生がありませんの理由を明示的に確認したものです:

#define EVDAT $TX.DAY9.event_date__v
#define EVDNO $TX.DAY9.change_reason__v

Not(IsBlank(EVDAT))
||
EVDNO = "Subject missed event"

この規則の式 (イベントの追加規則アクションで使用) では、変更理由を確認して、変更理由が被験者がイベントを欠席であった場合、次回のイベントのロールアウトが許可されています。施設が、「被験者による早期終了」を選択した場合、この規則では次のイベントは追加されません。

利用可能な変更理由についての正確なテキストを、お使いの試験の Vault で確認するようにしてください。これらの理由は、規則が正確に評価されるように、完全に一致する必要があります。ツール > システムツール > 変更理由から、標準およびカスタムの両方について利用可能な理由を表示させることができます。

ブーリアン項目 (チェックボックス) に関する規則

ブーリアン項目 (チェックボックス) で true または false に設定されていないものは空白 (「未定」) と見なされます。これは、施設がチェックボックスにチェックを入れていない場合と、チェックボックスにチェックを入れ、その後にチェックを外した場合に発生する可能性があります。規則の式内にある適切なロジックは、適切なシナリオが想定通りに評価されることを保証する上で役立ちます。ベストプラクティスは、規則の式の中で明示的にブーリアン値を = true または = false に設定することです。

ブーリアン値がすべて空白であることを評価する場合、適切な定義文を含めてください。フォーム/項目が意図的に空白にされている場合、運用する規則をどのようなものにする必要があるかを考慮します。

以下の例では、規則によって理由が入力され、1 つかそれ以上のチェックボックスが選択されたかがチェックされます。

#define ND1  @Form.ig_V1.V1ND
#define ND2  @Form.ig_V2.V2ND
#define ND3  @Form.ig_V3.V3ND
#define ND4  @Form.ig_V4.V4ND
#define REAS @Form.ig_V5.VREAS

Not(IsBlank(REAS)) && (ND1 = true || ND2 = true || ND3 = true || ND4 = true)

一連の項目またはチェックボックスが空白になっているかどうかを評価する場合、必要に応じて、フォームまたは項目が ILB とマークされていたら、定義文に「意図的な空白 (ILB)」を含めます。これにより、規則が発動されるべきでないときに確実に発動されないようにします。

#define AENONE @Form.AE.AENONE
#define AEMED @Form.AE.AEMED
#define AEACNOTH @Form.AE.AEACNOTH
#define AETRANS @Form.AE.AETRANS
#define FORMILB @Form.intentionally_left_blank__v

FORMILB = false
&&
(
    AENONE = false
    && 
    AEMED = false
    &&
    AEACNOTH = false
    &&
    AETRANS = false
)

Rule Details Form: Adverse Events

このロジックは、有害事象に関する規則、あるいは質問表や医療機器に関する規則に適用されることが多く、「該当するものすべてにチェックを入れる」チェックボックスが 1 つも選択されていないかどうかを評価します。このロジックが適用される一般的な規則には以下のようなものがあります:

• 「人種」の選択がされていない場合。該当するものすべてにチェックを入れます
• 取られたAE アクション: 何も選択されていない、または「投薬」、[その他]が選択されている。訂正してください。

年齢の規則

以下の規則例では、うるう年を考慮した年齢を計算し、クエリ Age を行います:

年齢の逸脱 (設定項目値)

このルール式の例では、人口統計フォームに入力されたデータから被験者の年齢を導出します。この式では @Form 浮動識別子 (「ワイルドカード識別子」とも呼ばれる) を使用しているため、ルール詳細パネルで参照先のフォームを選択する必要があります。ほとんどの場合、ルールアクションは識別子と同じレベルに修飾する必要があります。たとえば、項目の値を設定アクションを選択し、このフォーム > ig_DM > 年齢を選択します

#define BRTHDAT @Form.ig_DM.BRTHDAT
#define RFICDAT @Form.ig_DM.RFICDAT

If(BRTHDAT > RFICDAT - Years((Year(RFICDAT) - Year(BRTHDAT))), (Year(RFICDAT) - Year(BRTHDAT)) - 1, (Year(RFICDAT) - Year(BRTHDAT)) )

Rule Details Form: Demographics

年齢のクエリ (18 歳以下の場合のクエリ)

#define BRTHDAT $eg_SCREEN.ev_SCREEN.DM.ig_DM.BRTHDAT
#define EVDAT $eg_SCREEN.ev_SCREEN.event_date__v

Not(IsBlank(EVDAT)) && Not(IsBlank(BRTHDAT)) && ((EVDAT - MaxDate(BRTHDAT)) / 365.25) < 17.998

ルールを使用した試験スケジュールの作成

スタディデザイナーは、ルールを使用してフォーム、イベント、およびイベントグループを試験スケジュールに動的に追加できます。

以下の例では、ルールはイベントグループのシーケンス番号を評価して、特定のイベントシーケンスでルールアクションに構成されたフォームを追加します。これらの式の例では、剰余演算子を使用しています。繰り返しイベントグループで設定されたラベルに関連しているため、正確なシーケンス番号であることを確認してください。これらは、Studio で生成された試験デザイナン仕様のスケジュールツリータブでも参照できます。

まお、この例では浮動識別子 (「ワイルドカード識別子」とも呼ばれる) を使用するため、ほとんどの場合、ルールのアクションで同じ識別子を使用し、ルールの式とルールのアクションの両方を同じレベルに修飾する必要があります。

以下のすべての例では、ルール式の #define 文内の @EventGroup 浮動識別子と一致するように、ルールアクションで「このイベントグループ」を選択します。これにより、システムはルール式が true と評価されるイベントグループにのみ FORM1 を追加します。

例 1 のルール式では、繰り返しイベントグループのシーケンス番号が奇数かどうかを判定します。次に、スタディデザイナーは、式が true と評価されたときに、指定されたイベントグループ内のイベントに ECOG フォームを追加するようにルールアクションを構成できます。

例 1: サイクル内のすべての奇数イベントにフォームを追加する

#define EVDAT @EventGroup.ev_D1.event_date__v
#define EVSEQ @EventGroup.sequence__v

Not(IsBlank(EVDAT))
&&
(
     EVSEQ = 1
     ||
     EVSEQ % 2 = 1
)

Rule Action: Add Form: 'this event group' > ev_D1 > FORM1

例 2 のルール式では、繰り返しイベントグループのシーケンス番号が偶数かどうかを判定します。次に、スタディデザイナーは、式が true と評価されたときに、指定されたイベントグループ内のイベントに目的のフォームを追加するようにルールアクションを構成できます。

例 2: サイクル内のすべての偶数イベントにフォームを追加する

#define EVDAT @EventGroup.ev_D1.event_date__v
#define EVSEQ @EventGroup.sequence__v

Not(IsBlank(EVDAT))

&&

EVSEQ % 2 = 0

Rule Action: Add Form: 'this event group' > ev_D1 > FORM1

サイクル内のイベントグループのシーケンス番号を評価するルールを作成することもできます。例 3 では、サイクル 2 から開始する繰り返しイベントについて、繰り返しイベントグループのシーケンス番号を評価して、3 サイクルごとであるかどうかを判定します。

例 3: サイクル内の n 番目おきのイベントにフォームを追加する

#define EVDAT @EventGroup.ev_D1.event_date__v
#define EVSEQ @EventGroup.sequence__v

Not(IsBlank(EVDAT))

&&
(EVSEQ + 1) % 3 = 0

Rule Action: Add Form: 'this event group' > ev_D1 > FORM1

クエリメッセージ

• 問題および解決のための選択肢について明確に言及してください。事実に基づき、データにバイアスを与える可能性があるため、誘導的なメッセージの使用を控えてください。
• 特殊文字は、エクスポートファイルで正しく表示されない可能性があるため、使用は避けてください。
  • 例えば、「> or =」を使用する代わりに、「greater than or equal to (より大きい、または等しい)」をスペルアウトする。
  • 通常のキーボードの文字を使用する。Alt + キーや、下流のシステムまたはアプリケーションに影響を与える可能性のある記号を使用しない。
• 回答は一重引用符で囲む (例: 被験者は登録されましたか？が‘いいえ’であり…)。
• 二重引用符の使用は避ける。
• クエリメッセージには 500 文字の文字数制限があります。

浮動識別子 (@Form、@Event、@EventGroup) を含む規則

20R1 (2020 年 4 月) 以降、@Form (ワイルドカード識別子とも呼ぶ) などの浮動識別子を使用する新しいルールは、指定されたフォームが送信されるたびに、自動的にルールが評価されるようになりました。

相互交換規則

規則の式が複数のフォームのデータを参照する場合 (@ と完全修飾識別子の両方が使用される場合も)、Vault は、規則の詳細パネルで選択されたフォームの送信時に規則を評価し、規則の式で参照されるフォームのデータが変更されるたびに規則を再評価します。このプロセスは相互交換規則と呼ばれます。例えば、if you use @Form を使用して複数のイベントで使用する Vitals フォームを指し、さらに完全修飾識別子を使用して PE フォームを指す場合、 Vault はその規則を実行し、Vitals フォームまたは特定の PE フォームがサブミットされたときそれぞれが指す スタディオブジェクト内のデータを評価します。

規則詳細パネルで選択したフォームが繰り返しの完全修飾名である場合、Vault は各フォームインスタンス内でその規則を評価します。

完全修飾 vs 浮動識別子形式

[ルール式] フィールドに入力する識別子の形式は、完全修飾識別子を使用するか浮動識別子 (ワイルドカード識別子とも呼ばれる) を使用するかをシステムに示します。

ほとんどの場合、完全修飾識別子はドル記号 ($) で始まり、スタディオブジェクトへのリファレンスを完全修飾していることをシステムに示します。

完全修飾識別子の形式の例:

$EVENTGROUP.EVENT.FORM.ITEMGROUP.ITEM

浮動識別子は常にアットマーク (@) で始まり、コンテキストに基づいてポイントされている試験オブジェクトをシステムが参照することをシステムに示します。

浮動識別子形式の例:

@EventGroup.EVENT.FORM.ITEMGROUP.ITEM, @Event.FORM.ITEMGROUP.ITEM, or @Form.ITEMGROUP.ITEM

規則アクション内で、「@」は「このイベント」、「このイベントグループ」、または「このフォーム」として示されます。

ルールに完全修飾の繰り返しイベントグループ、イベント、またはフォームが含まれる場合、Vault はその識別子に一致するすべてのインスタンスを調べます。このため、すべてのオブジェクトに対してルールを実行する場合を除き、繰り返しオブジェクトには完全修飾識別子を使用しないことが推奨されます。

非互恵的動作 (20 R 1以前) を使用して新しいルールを作成する必要がある場合、Veeva サービスの担当者と協力して作成します。

ルールの順列を最適化するためのベストプラクティス

繰り返しフォームで集約を使用してルールを記述する場合、集約識別子 [*] を使用します。

集約識別子を使用した #define 文の例:

#define AEOUT   $LOGS.LOGS.AE[*].igAE.AEOUT

繰り返しフォームおよびイベントグループを参照するルールを記述する場合、@Form または @EventGroup 浮動識別子 (「ワイルドカード識別子」とも呼ばれる) を使用して、過剰な順列を防ぎます。

テストに関する推奨事項

ユニットテストであれ、より正式な規則の検証であれ、以下のベストプラクティスを検討してください:

• 範囲内の値および範囲外の値を含める。これには、数値、日付、日時ウィンドウが含まれます
• すべてのケースに対して、規則の発動と解決のテストを含める。
• コードリストからすべてのシナリオを確認する。
• フォームをまたぐクエリについては、第 1 および第 2 のフォーム (前と後の両方) の完了時に、規則が想定通りにクエリを作成および解決することを示すテストを含める。
• 規則が繰り返し項目グループ内の項目を参照する場合、項目グループの正確なシーケンス (インスタンス) でその項目に対するクエリが開き、解決するかどうかを検証します。
• 日時の範囲内、同一時間内、時間外をテストします。
• 「次の日」のシナリオをテストします。ウィンドウの範囲内で、次の暦日の時間を選択します。
• 項目のマスキングプロパティに従って、不明な (UNK) 時間、日、および月をテストします。
• 異なる拠点からデータを入力する際の規則をテストするために、タイムゾーンが適用される施設をセットアップします。
  • スタディに含まれる国から予想されるタイムゾーンのサンプルを示す、いくつかのテスト施設を TST に追加します。
  • 施設と、その施設に割り当てられた TST テストユーザの両方のタイムゾーンを設定します。
• 試験実施に適用されるタイムウィンドウ規則をテストします。例えば、点滴の時間を長くすると、終了時刻、予想される ECG または PK のタイムウィンドウが深夜に近くなる場合など。
• コードに関するピアレビューで品質を向上させ、かつユーザ受入テストでの発見事項を減らすことができる、テストに対するリスクベースのアプローチを検討してください。