ルール (V2) の作成

ルールエンジンを使用することでデータ入力規則を作成し、Vault EDC でデータを検証することができます。次に Vault は、ルールの評価に基づいて特定のタスクを実行することができます:

• ユーザがフィールドから離れたらシステム生成クエリを作成します。
• 入力されたデータを基に、治験にイベントグループ、イベント、フォームが表示されます。
• 入力されたデータを基に、特定の項目、項目グループが条件付きで有効化・無効化されます。
• その他の入力されたデータを基に、項目に自動的に入力される値が導出されます。

式を使用して単位変換を定義することもできます。治験に単位変換を定義した場合、データ入力ユーザのローカライズされた入力形式にかかわらず、Vault EDC は正しい単位を使用して入力された値を変換・保存することができます。

データ入力規則はユーザ定義ルールタブにクリック可能リンクとして表示されます。リンクをクリックすると治験ルールの追加ダイアログが再度開き、ルールを編集することができます。ルールのプロパティパネルを開くには、任意のルールの行をクリックします。

EDC ツールへのアクセス権限を所有している場合、ルールタブにクエリアクションのルールを表示することができます。

タイムゾーンと規則の使用に関するヒントについての情報は、「規則に関するヒントとベストプラクティス」を参照してください。

システム管理データ入力規則

データ入力規則は単一の項目に制限を強制します。Vault EDC は、項目定義のプロパティパネルに定義されるプロパティを使用して、システム管理データ入力規則を作成します。Vault EDC は以下のプロパティにデータ入力規則を自動作成します:

• 必須フィールド (必須チェックボックス)
• 範囲バリデーション (最小値および最大値)
• 将来の日付のバリデーション (将来の日付)

デフォルトでは、システム管理ルールは、ユーザ定義ルールタブに表示されません。組織が Studio でこれらのルールの表示を希望する場合、表示するように選択することができます。

ルールのプロパティ

プロパティパネルからルールの追加の設定を行うことができます。プロパティの必須部分は黄色の背景で表示されます。使用可能なプロパティの説明については、ルール設計のプロパティを参照してください。

ルールを作成する方法

新しいルール定義は、Studio > ルールで、Studio から作成することができます。治験がいつ作成されたものであるかによって、ルールエディタとエクスプレッション文法はバージョン 1 またはバージョン 2 になります。治験でバージョン 1 のルールエディタと関数エクスプレッション文法を使用している場合、ルールの作成については、Studio (V1) でのルールの定義を参照してください。

新規ルールを作成するには:

1. Studio > ルールから、+ 新規ルールをクリックします。

2. ルールの名前を入力します。
3. 任意の作業: 治験でルールをすぐに有効にしたくない場合は、有効チェックボックスの選択を解除します。後で有効チェックボックスを再度オンにすることで、ルールを有効にすることができます。
4. 任意の作業: 説明を入力します。
5. 任意の作業: ルール検証のタイミングで、イベントグループ作成時を選択します。これを選択すると、フォーム送信時ではなく、新規イベントグループ作成時 (繰り返しイベントグループの場合) に、ルールが評価されます。このフィールドでデフォルトを選択すると、フォーム送信時にすべてのルールが評価されます。
6. ルールを適用するフォームを選択します。ルール式またはアクションに @Form 識別子が含まれている場合、またはルールにレビュー計画の上書き、項目値の設定、またはメール送信ルールアクションタイプが使用されている場合にのみ要求されます。
7. 任意の作業: 現在のイベントグループ内チェックボックスをオンにします。この設定により、イベントの追加ルールとフォームの追加ルールは、現在のイベントグループ内に、そのイベントグループのインスタンスではなくイベントまたはフォームのみを追加するよう Vault に要求します。
8. 任意の作業 (数値フィールド): 空白処理オプションを選択します。これは、ルール式の評価時に、空白値がどのように処理されるか制御します。詳しくは以下を参照してください。
9. 数式フィールドに式または数式を追加します。最初に、#define文を使用して任意の変数を定義し、新しい行に式を記述します。式の作成に関するヘルプについては、数式言語リファレンスをクリックしてください。Vault CDMS 数式リファレンスが開きます。CDMS ヘルプの内容。関数セレクタを使用して、式に関数を追加することができます。詳しくは以下を参照してください。Vault では、識別子、変数、演算子、関数のオートコンプリート機能を試行することもできます。Ctrl + スペースを押すと、オートコンプリートのオプションのドロップダウンリストが表示されます。アンダースコア (_) で始まる名前のアイテムを参照する変数を定義している場合は、#define 文で変数の名前を変更してアンダースコアを削除する必要があります。これを行わないと、構文エラーが発生します。
10. 式を検証するには検証をクリックします。エラーがある場合、行番号にエラーアイコンが表示されます。このアイコンにカーソルを合わせると、エラーの詳細を確認することができます。また、数式フィールドの下には、すべてのエラーが一覧表示されます。
11. ルールアクションを選択します。さまざまなアクションの詳細については、以下を参照してください。
12. 実行するアクションで求められる選択内容は、選択したルールアクションによって異なります。詳しくは以下を参照してください。
13. ルールを作成したら、保存して閉じるをクリックします。

関数セレクタを使用する

関数セレクタを使用して、関数を検索して追加することができます。

セレクタから関数を追加するには:

1. 関数をクリックすると関数セレクタが開きます。

2. 任意の作業: ドロップダウンから関数の種類を選択すると、関数の種類でリストがフィルタリングされます。

3. リストから関数を探します。
4. リスト内の関数をクリックすると、その関数の詳細が表示されます。関数をダブルクリックすると、数式に追加されます。

5. 任意の作業: この関数のヘルプをクリックすると、この関数の追加のドキュメントが表示されます。

6. 挿入をクリックすると、数式フィールドにその関数が追加されます。

特定の関数を検索するには:

1. 検索フィールドに関数の名前を入力します。
2. Enter を押します。
3. リスト内の関数をクリックすると、その関数の詳細が表示されます。関数をダブルクリックすると、数式に追加されます。
4. 任意の作業: この関数のヘルプをクリックすると、この関数の追加のドキュメントが表示されます。
5. 挿入をクリックすると、数式フィールドにその関数が追加されます。

サポートされていない関数

現行リリースでは、関数セレクタには、ルールでの使用がサポートされていない Vault プラットフォームのいくつかの関数が表示されます。次の関数はサポートされていません:

• AddMonths
• Ascii
• Begins
• BlankValue
• 含む
• CurrencyRate
• DayOfYear
• FromUnixTime
• Id
• InitCap
• IsoWeek
• IsoYear
• Pi
• PicklistCount
• Rand
• TimeNow
• TimeValue
• Trunc
• UnixTimestamp
• URL エンコード

項目セレクタを使用する

ルール作成時に、治験内の項目識別子を検索してルールの式に挿入することができます。デフォルトでは、ルールの詳細パネルで選択したフォームのすべての項目が一覧表示されます。

項目を検索するには:

1. まだ開いていない場合、項目をクリックします。

2. 任意の作業: すべてのフォームを選択すると、すべての治験のフォームが検索対象となります。ルール詳細パネルで選択したフォームのみを検索対象にする場合、このフォームのままにします。

3. 検索フィールドをクリックします。
4. 検索ボックスに 1 つ以上の語句を入力します。項目の名前またはラベルで検索することができます。完全一致検索には、用語に二重引用符を使用します ("インフォームドコンセント")。

5. 入力した内容で項目が検索されます。結果ドロップダウンから項目を選択すると、その項目が表示されます。

6. 任意の作業: 項目にカーソルを合わせて追加 () をクリックすると、項目の ID がルールの式に追加されます。

7. クリア () をクリックすると、検索がクリアされます。

検索結果には、各項目の名前 とラベルが表示されます。項目は項目グループにグループ化されます。

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

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

相互交換規則

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

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

相互フォームの動作は、ルールアクションにも適用されます。例えばクエリルールの場合、ルール式が評価されるインスタンスと同じインスタンスでクエリが実行されるようにするには、クエリルールのアクション識別子を式の識別子と一致させる必要があります。ルール式の識別子に @Form、@Event、@Event Group のいずれかが使用されている場合、クエリアクションはそれぞれ「このフォーム」、「このイベント」、「このイベントグループ」と一致する必要があります。

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

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

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

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

$EVENTGROUP.EVENT.FORM.ITEMGROUP.ITEM

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

浮動識別子形式の例:

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

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

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

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

ルール識別子と順列

ルール内の識別子の定義方法 (修飾方法) によって、それらの識別子が参照する治験データをルールエンジンがどのように評価するかが決まります。識別子の記述方法は、ルールの動作、場合によっては EDC のパフォーマンスにも影響します。ルールの順列によって、治験オブジェクトデータに対するルールの評価方法が異なります。

識別子は、ルールが紐付けられている治験オブジェクトへのパスです。システムは、オブジェクトが識別されている場所に一致するすべてのオブジェクトインスタンスを見て、そのレコードに対して実行します。完全修飾識別子を含むルールは、指定された場所の治験オブジェクトに対してのみ順列を生成します。ルールに繰り返しオブジェクトの完全修飾識別子が含まれている場合、ルールは繰り返しオブジェクトのすべてのインスタンスに対して評価されます。これにより、ルールが繰り返しイベントグループ、フォーム、または項目グループに対して実行されますが、それらに基づいてルールが実行されると、意図しない結果や過剰な順列が発生する可能性があります。ルールの順列を最適化するためのベストプラクティスについて説明します。

ルールの順列が多すぎる場合、フォームの送信時間や Vault のパフォーマンスに意図せず影響することがあります。ほとんどの場合、繰り返しオブジェクトを参照するルール式を記述する際は、@Form、@Event、@Event Group などの浮動識別子 (「ワイルドカード識別子」とも呼ばれます) を使用することをお勧めします。完全修飾識別子は、ルールで次の項目を評価する場合にのみ使用することをお勧めします:

• スケジュール内のオブジェクトの単一インスタンス。例:

  $SCREEN.SCREEN.DM.igDM.AGE
  

• 集約ロジック、例:

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

• イベントグループまたはフォームの特定のインスタンス。例:

  $TRT[1].WEEK.EX.igEX.EXSTDTC
  

次の例は、完全修飾識別子と浮動識別子の使用がルールの順列数にどのように影響するかを示しています。

正しくない例では、AE フォームが繰り返しフォームであるにもかかわらず、AEITEM が完全修飾されています。ここでは、AE フォームが出現するたびにルールを乗算するようにルールエンジンに指示しています。症例 ケースブックに AE フォームのインスタンスが 100 個ある場合、フォームが保存されるたびに識別子が指すデータを AE フォームのそれぞれで評価するため、ルールが 100 回順列を生成します。

誤った識別子の使用例、1 つの繰り返しフォーム:

$LOGS.LOGS.AE.igAE.AEITEM 

次の例では、被験者のケースブック内の 1 つの AE フォームインスタンスだけが参照されているため、このルールは、ルール式で参照される他のフォームが送信されるたびに 1 回だけ順列を生成します。

メインの繰り返しフォームに浮動識別子を使用した正しい識別子の使用例:

@Form.igAE.AEITEM 

複数の繰り返しフォームが完全修飾識別子を使用して参照される場合、可能な順列の数は、両方のフォームのインスタンスの数の倍数として増加します。例えば、ルールが完全修飾識別子を使用して繰り返し画面フォームと AE フォームの両方を参照し、奨励ケースブックに 100 個の AE フォームインスタンスと 20 個の MH フォームインスタンスがある場合、ルールは 100 個の AE x 20 個の MH フォームの繰り返し = 2000 個の順列を持つことになります。

誤った識別子の使用例、2 つの繰り返しフォーム:

$SCREEN.SCREEN.MH.igMH.MHITEM     
$LOGS.LOGS.AE.igAE.AEITEM 

次の例では、浮動識別子を使用しているため、被験者のケースブック内の 1 つの AE フォームインスタンスのみが参照されます。このルールは、ケースブックの 1 個の AE インスタンス x 20 個の MH フォームの繰り返し = 20の順列を持つことになります。

メインの繰り返しフォームに浮動識別子を使用した正しい識別子の使用例:

@Form.igAE.AEITEM1 
$SCREEN.SCREEN.MH.igMH.MHITEM   

複数の繰り返しフォーム上の複数の項目を示すために、ルール式でより完全修飾識別子が使用されると、それに伴い順列は増加し続けます。

次の例では、被験者のケースブックに 100個 の AE フォームインスタンスと 20 個の MH フォームインスタンスがあるため、ケースブック全体でのルールの順列数は 100^2 (AE フォームインスタンスの数) × 20^3 (MHフォームインスタンスの数)＝80,000,000になります。

誤った識別子の使用例、複数の識別子を持つ 2 つの繰り返しフォーム:

$LOGS.LOGS.AE.igAE.AEITEM1 
$LOGS.LOGS.AE.igAE.AEITEM2
$SCR.SCR.MH.igMH.MHITEM1
$SCR.SCR.MH.igMH.MHITEM2 
$SCR.SCR.MH.igMH.MHITEM3 

次の例では、被験者のケースブック内の 1 つの AE フォームインスタンスのみが参照されます。このルールは、ケースブックの 1 個の AE インスタンス x 20^3 個の MH フォームのインスタンス = 8,000 個の順列を持つことになります。

メインの繰り返しフォームに浮動識別子を使用した正しい識別子の使用例:

@Form.igAE.AEITEM1 
@Form.igAE.AEITEM2
$SCR.SCR.MH.igMH.MHITEM1
$SCR.SCR.MH.igMH.MHITEM2 
$SCR.SCR.MH.igMH.MHITEM3 

項目からフォームへのリンクおよびフォームからフォームへのリンクを使用して、繰り返しオブジェクトを参照するルールを記述することで、ルールの順列をさらに最適化できます。

ルール内の参照シーケンス番号

繰り返しイベントグループ、フォーム、または項目グループのシーケンス番号を参照して、繰り返しオブジェクトの特定のインスタンスに対してのみルールを評価したり、ルールアクションを実行することができます。例えば、その項目を含む繰り返し項目グループの最初の配列にのみ、その項目の値を設定するように項目値の設定ルールを設定することができます。

ルール式でシーケンス番号を参照するには、繰り返しオブジェクトの識別子の後とピリオドの間に、角括弧付きの数字を追加します。

@Form[2]またはTreatmentCycle[2].Visit1.event_date__v

浮動 (@) 識別子 (「ワイルドカード識別子」とも呼ばれます) を使用する場合、特定のシーケンス番号の代わりに、繰り返しオブジェクトの前または次のインスタンスを参照することもできます。この場合、括弧の中をシーケンス番号の代わりに「+1」(次) または「-1」(前) とします。例: @EventGroup[-1].Visit1.event_date__v。

前/次の識別子には、式内のアンカー識別子が必要です。アンカー識別子とは、前/次の識別子から上の階層にある、前/次で使用する識別子と同じ識別子のことです。例えば、式で@Form.PK[-1].Measurementが使用されている場合、@Form.PK.MeasurementまたはPK項目グループ内の他の項目も参照する必要があります。

以下の使用例がサポートされます:

• @Form.ItemGroup[-1/+1].Item
• @Form[-1/+1].ItemGroup.Item
• @Form/LinkedForm.ItemGroup[+1/-1].Item
• @EventGroup[-1/+1].Event.Form.ItemGroup.Item
• @EventGroup[-1/+1].Event.event_date__v

注: 前/次の修飾子の使用は、識別子ごとに 1 回に限られます。

ルールアクションの設定でシーケンス番号を参照するには、繰り返しオブジェクトにインスタンスを 1 つ選択してシーケンス番号を入力します。ルール式で浮動識別子 (「ワイルドカード識別子」とも呼ばれる) を使用する場合、ルール詳細パネルで参照先のフォームを選択します。ほとんどの場合、ルールアクションでも同じ識別子を使用し、ルールの式とルールアクションの両方を同じレベルに修飾する必要があります。

前のイベントからの参照値 (繰り返しなし)

治験内の繰り返しのないオブジェクト間で項目を再利用する場合、@PreviousEventを使用して前のイベントの値を参照することができます。

例えば、治験では、複数のイベントで 1 つの投薬フォームを使用することができます。@PreviousEventを使用すると、来院 2の投薬フォームの項目の値を、前のイベントである来院 1のその項目の値と比較することができます。

#define dose_amount @Form.dosing.dose_amount
#define previous_amount @PreviousEvent.dosing.dosing.dose_amount

dose amount != previous_amount

Rule Details Form: Dosing

1 つのルール式で@PreviousEventを複数回使用することができますが、@PreviousEventが指すことができるフォームは 1 つだけです。また、@PreviousEvent を使用する場合、@Form 識別子を使用してルールを前のインスタンスにアンカーを付ける必要があります。

@PreviousEventは、@Eventと同じ属性と識別子 (change_reason__v、did_not_occur__v、event_date__v、name__v、sequence__v、.Form で有効なすべての属性と識別子) をサポートします。

Vault は、イベントの並び順プロパティで定義した並べ替え順序を使用して、前のイベントを決定します。イベントの並び順のオプションには以下が含まれます:

• イベント日: Vault は、前のイベントを決定するときに、イベントをイベント日付で並べ替えます。例えば、1 つのケースブックには、イベント 1、2、3 が含まれます。この症例にはイベント 3 の後にイベント 2 がありました。イベント日付で並べ替える場合、ルールがイベント 3 中に前のイベントをチェックした場合、Vault は日付による最新であるため、前のイベントとして 1 を使用します。
• スケジュール: Vault は、イベント日に関係なく、ケースブックのスケジュールに表示されるとおりに (Studio の設計通り) イベントを並べ替えます。例えば、1 つのケースブックには、イベント 1、2、3 が含まれます。イベントはこの順序でスケジュールに表示されます。症例がイベント 3 の後にイベント 2 を持っていたとしても、Vault は 3 のルールを評価するときに、スケジュール順序であるため、依然として 2 を前のイベントとして使用します。繰り返しイベントとスケジュールされていないイベントは、シーケンス番号によって並べ替えられます。

@PreviousEvent は、オープンクエリルールと派生値の設定ルールにのみ使用できます。

意図的なブランクへの対応

@PreviousEvent ルールでは、デフォルトでDid Not Occur（発生がありません）とマークされたイベントはスキップされます。

これはルール詳細パネル内の意図的に空白のままにした値や未実施の値をスキップするチェックボックスにより制御されます。

集約識別子

繰り返しイベントグループ、フォーム、または項目グループ、リンクされたフォームでは、集約識別子を使用して、すべてのインスタンス間の値を指すことができます。例えば、集計識別子を使用して、繰り返し測定値フォームのすべてのインスタンスから病変サイズ項目を検索することができます。なお、浮動識別子 (「識別子」とも呼ばれる) では集約識別子は使用できません。

集約識別子には、繰り返しオブジェクトの名前の後に、角括弧付きのアスタリスク ([*]) を使用します。以下の例をご確認ください。

集約識別子は「ボトムアップ」です。集約識別子がある場合、下位階層にあるすべての繰り返し識別子も集約である必要があります。例えば、繰り返しフォームに繰り返し項目グループが含まれている場合、フォームで集約識別子を使用する場合、項目グループの集約識別子を使用する必要があります。下位レコードが繰り返しでない (繰り返しのない項目グループを持つ繰り返しフォーム) 場合は、この限りではありません。

$Visit_1.Visit_1.Measurements[*].Lesions.Lesion_Size
$Treatment_Visits[*].Visit.event_date__v
@Form.Physical_Exam[*].Abnormalities

• $eventgroup.event.form.itemgroup[*].item
• @eventgroup.event.form.itemgroup[*].item
• @event.form.itemgroup[*].item
• @form.itemgroup[*].item
• $eventgroup.event.form[*].itemgroup[*].item
• @eventgroup.event.form[*].itemgroup[*].item
• @event.form[*].itemgroup[*].item
• @form.itemgroup[*].item
• $eventgroup[*].event.form[*].itemgroup[*].item
• @event.form[*].itemgroup[*].item
• $eventgroup.event.form1/form2.itemgroup[*].item
• @eventgroup.event.form1/form2.itemgroup[*].item
• @event.form1/form2.itemgroup[*].item
• @form1/form2.itemgroup[*].item
• $eventgroup.event.form1/form2[*].itemgroup[*].item
• @eventgroup.event.form1/form2[*].itemgroup[*].item
• @event.form1/form2[*].itemgroup[*].item
• @form1/form2[*].itemgroup[*].item
• $eventgroup.event.form1[*]/form2[*].itemgroup[*].item
• @eventgroup.event.form1[*]/form2[*].itemgroup[*].item
• @event.form1[*]/form2[*].itemgroup[*].item
• $eventgroup[*].event.form1[*]/form2[*].itemgroup[*].item

• @event.form1[*]/form2[*].itemgroup[*].item

• プロパティを使用した上記の任意の組み合わせ
• 上記のうち、「*」ではなくシーケンス番号を持つもの (リンクフォームを除く)

集約識別子で使用できる特別な関数のセットが存在します。その他の関数は、集約識別子では使用できません。注: これらの関数の中には、一部 (Sumなど) 通常の識別子にも使用できるものがあります。集約識別子で使用される関数の詳細と使用例については、こちらを参照してください。

リンクフォームからのデータの参照

多くの場合、データ収集時には、類似または関連データをグループ化したり、原因と結果を示すために、2 つ以上の繰り返しフォームのデータを関連付ける必要があります。例えば、有害事象であれば、その有害事象に関連する 1 つ以上の併用薬とリンクさせることができます。

ルール式のデータは、ルールのフォームとそれにリンクされている任意のフォームの両方から参照することができます。たとえば、併用薬のフォームにルールを記述する場合、リンク先の有害事象のフォームからデータを参照することができます。

式には、リンクされたフォームのコンテキスト外にある識別子を含めることはできません。ルール詳細パネルで選択されるフォームは、@Form 浮動識別子 (「ワイルドカード識別子」とも呼ばれる) が参照する「メイン」フォームです。データには、このメインフォームにリンクされている任意のフォームからアクセスすることができます。式の他のすべての識別子は、このメインフォームまたはリンクされたフォーム上のいずれにある必要があります。例えば、ConMeds フォームが AE フォームにリンクされているが、受療歴フォームにリンクされていない場合、ルールを記述して AE 開始日が CM 開始日より前であることを確認することができますが、受療歴の開始日が CM 開始日より前であることは確認することができません。その理由は、この例では受療歴フォームが併用薬フォームにリンクされていないためです。

@Form 浮動識別子を使用する場合、ルール詳細パネルで参照先のフォームを選択する必要があります。ほとんどの場合、ルール式で浮動識別子を使用する場合は、ルールアクションでも同じ識別子を使用し、ルール式とルールアクションの両方を同じレベルに修飾する必要があります。これにより、規則アクションと規則式の範囲がケースブック内の同じオブジェクトインスタンスに限定されます。そうでない場合、規則アクションが意図しないフォームに影響を及ぼす可能性があります。

リンク先フォームの項目またはフォームレベルの属性を参照するには、フォーム識別子または@Formの後にリンク先フォームの識別子をスラッシュ (/) で区切って記入します。リンクされたフォームは、完全修飾識別子または浮動識別子で参照できます。以下の例では、識別子は、併用薬フォームにリンクされている有害事象フォーム上の有害事象進行中項目を指しています:

完全修飾フォームリンク識別子の例:

$Logs.CommonForms.ConcomitantMedication/AdverseEvent.AdverseEventDetails.Ongoing

浮動識別子フォームリンク識別子の例:

@Form/AdverseEvent.AdverseEventDetails.Ongoing

Rule Details Form: Concomitant Medication

例えば、併用薬のフォームに、リンクされた有害事象レコードがまだ進行中かどうかを確認するルールを記述することができます。

#define ongoing @Form/AdverseEvent.AdverseEventDetails.Ongoing

ongoing = true

Rule Details Form: Concomitant Medication

項目からフォームへのリンク識別子の例:

#define ongoing @Form.ig_CM.STDAT/AdverseEvent.AdverseEventDetails.Ongoing

ongoing = true

Rule Details Form: Concomitant Medication

アーカイブ化 (削除) ルール

削除されたルールは アーカイブ化されます。アーカイブされたルールは、無効なルールと同じ方法で動作します。Vault は、これらのルールを検証および文書化から除外し、(アーカイブ済みステータスで) デプロイし、ユーザがルールを有効としてマークできないようにします。これらのルールの実行は阻止されます。

デフォルトでは、アーカイブされたルールはユーザ定義のルールの一覧表示内に含まれません。アーカイブされたルールを表示チェックボックスをオンにすると、アーカイブされたルールを追加します。アーカイブされたルールには、アーカイブ済み列に緑色のチェックマーク () が表示されます。

ルールをアーカイブする方法

ルールをアーカイブするには:

1. スタディのスタジオ > ユーザ定義のルールに移動します。
2. リスト内のルールを見つけます。
3. ルールの名前にカーソルを合わせると、アクションメニューが表示されます。

4. アクションメニューから、アーカイブを選択します。

5. ルールをアーカイブ確認ダイアログで、アーカイブをクリックします。

あなたのルールは現在アーカイブされています。リスト内で表示するには、アーカイブされたルールを表示チェックボックスをオンにしてください。

ルールを復元する方法

アーカイブされたルールを復元するには:

1. スタディのスタジオ > ユーザ定義のルールに移動します。
2. アーカイブされたルールを表示チェックボックスをオンにします。
3. リスト内のルールを見つけます。
4. ルールの名前にカーソルを合わせると、アクションメニューが表示されます。
5. アクションメニューから、アーカイブされたルールを復元を選択します。

Vault が該当するルールを復元します。ルールは有効になり、通常通り実行されます。

コピールール

現在の治験と他の治験の両方からルールをコピーすることができます。

現在の治験から

既存のルール定義を開き、コピーを保存をクリックしてルールのコピーを保存します。

他の治験から

他の治験からルール定義をコピーすることもできます。注: 一致する識別子が (ターゲット) 治験に存在しない場合、ルールは「無効」としてコピーされるため、使用するには識別子を更新してルールを再度有効にする必要があります。

他の治験からルールをコピーする方法について詳しくは、設計定義の再利用を参照してください。

無効なルールを解決するには:

1. Studio > ルールから、ルールエディタで無効なルールを開きます。
2. 無効な識別子を有効な識別子に置き換えます。
3. 有効チェックボックスをオンにします。
4. 保存をクリックします。

無効なルールごとにこのプロセスを繰り返します。

使用可能なルールのアクションタイプ

Vault EDC のルールで使用できるアクションタイプは以下のとおりです:

ルールの処理順序

サイトユーザがフォームへの入力を終えると、Vault EDC によって次のアクションタイプの順序でルールが処理されます:

1. 項目の値を設定または派生値を設定する
2. イベントグループの追加
3. 事象の追加
4. フォームの追加
5. クエリ

Vault EDC によって各ルールタイプ内のルールが次の順序で処理されます:

1. 派生ルール
2. クロスフォーム - 同一イベントルール (管理オブジェクトと依存オブジェクトが異なるフォームにある)
3. クロスフォーム - クロスイベントルール (管理オブジェクトと依存オブジェクトが異なるイベントにある)
4. メール送信を除くすべてのその他ルール
5. メール送信ルール

この順序でルールが Vault で処理されることで、クエリタイプのルールが、値が導出されたりイベントグループ、イベント、フォームが追加されたりすることによって影響を受ける場合にデータの不足がない状態で処理できるようにしています。

無効化ルール

無効化アクションルールは他のルールアクションとは異なり、このルール処理順序に従いません (項目または項目グループを無効化しても他のルールのアクションの影響を受ける可能性がないため)。ユーザが管理項目を含むフォームを保存すると、Vault によって無効化アクションルールが評価されます。

ルールによるデータ入力規則クエリ

複数の項目全体にデータ入力規則を作成できるほか、システム管理ルールのプロパティに基づかずに単一の項目にルールを作成することができます。入力される項目値が定義した条件に一致しない場合、Vault はクエリを作成します。データ入力規則を作成するには、ルールアクションにクエリを選択します。

データ入力規則はルールタブにクリック可能リンクとして表示されます。リンクをクリックすると治験ルールの追加ダイアログが再度開き、ルールを編集することができます。作成したルールのプロパティパネルを開くには、任意のルールの行をクリックします。

ルールの実行

デフォルトでは、ルールはフォームの送信時 (サイトユーザが完了ボタンをクリックしたとき) に実行されます。クエリルールの場合、ルールを「保存後ルール」としてマークすることで、ルールの実行を遅らせることができます。これにより、ユーザがフォームを送信するとすぐにクエリが作成・表示されるのではなく、処理キューにルールが追加・完了された後にクエリが表示されます。これは特に、多くのデータポイントをチェックする複雑なルールにおいてルールのパフォーマンス向上に有効です。

ルールを保存後ルールとして設定するには、[ルールの詳細] パネルの [ルールの実行] の下にある [保存後ルール] チェックボックスをオンにします。

治験管理者は、[ツール] > [EDC ツール] > [ルール] > [エラーコンソール] で、保存後ルールの実行状況をモニタリングし、エラーを確認することができます。ルール実行権限を持つすべての治験ユーザは、エラー発生の都度通知を受け取ります。

オープンクエリルールの例

#define DIASBP @FORM.Blood_pressure.Diastolic_blood_pressure
#define SYSBP @FORM.Blood_pressure.Systolic_blood_pressure

DIASBP > SYSBP

Rule Details Form: Vital Signs

この例では、ルール詳細パネルで、評価する DIASBP 項目と SYSBP 項目を含むフォームを選択します。この場合、Vault EDC は、Diastolic_blood_pressure 項目が Systolic_blood_pressure 項目より大きいかどうかを評価します。治験デザイナーは、式が true と評価されたときにクエリを生成するようにルールアクションを設定することが可能です。DIASBP と SYSBP はどちらも数値であるため、治験デザイナーは空白の場合の処理を考慮する必要があります。このフォームは浮動識別子 (「ワイルドカード識別子」とも呼ばれる) を使用するため、ほとんどの場合、ルールのアクションで同じ識別子を使用し、ルールの式とルールのアクションの両方を同じレベルに修飾する必要があります。

特定のケースブックバージョンに限定したクエリの作成

特定のバージョンの被験者のケースブックのみを評価するようにルールを設定することができます。例えば、バージョンが 8 未満のすべてのケースブックを対象に、スクリー二ングイベント日がケースブックのバージョン 7 から 8 への改訂日より前の日付のイベントに対してのみ実行するルールを設定することができます。このタイプのルールは、新しい設計に基づいて特定のルールが無効になるようにケースブック定義を更新した場合に有用です。

バージョン番号を参照するには、@Casebookcasebook.version__vの構文を使用します。

#define EVDAT $Screening.Screening.event_date__v
#define CBV @Casebook.version__v
#define BRTHDAT $Screening.Screening.Demographics.DM.BirthDate.value__v

(( EVDAT > date(2018, 12, 15) 

&& 

CBV > 7))

&& 

((EVDAT - BRTHDAT) <= 18)

上記の式の例では、スクリーニングイベント日が 2018 年 12月 15 日以降で、ケースブックのバージョンが 7 より大きい場合、ルールによってスクリーニングイベントの時点で被験者が 18 歳でない場合にクエリが作成されます。また、人口統計フォームがスクリーニングイベントにのみ存在する場合に限り、@Form 浮動識別子 (「ワイルドカード識別子」とも呼ばれる) を使用してこのルールを記述することもできます。

なお、このルール式は浮動識別子を使用するため、ほとんどの場合、ルールアクションは同じレベルに修飾する必要があります。

ルールによる動的治験デザイン

Vault CDMS では、ユーザが入力したデータに基づいて、スタディにフォーム、イベント、およびイベントグループを追加するルールを使用して、スタディを動的に設計することができます。例えば、症例のコホートやランダムな数字に基づいて、ケースブックに表示されるイベントグループを制御するルールを設定したり、ユーザがフォームで フォローアップ訪問が必要 チェックボックスを選択したときに、フォローアップ訪問イベントを追加するルールを作成することができます。Vault CDMS では、フォームの追加 (フォームの追加)、イベントの追加 (イベントの追加)、およびイベントグループの追加 (イベントグループの追加)、およびスタディフォームに入力されたデータをトリガーとしてスタディの構造を変更するルールアクションを「動的アクション」と呼んでいます。

動的ルールアクションの範囲

動的スタディ構築ルールを記述する際、スタディスケジュールのどこでルールアクションが有効になるかを決定する 2 つの要素があります:

• ルールの詳細パネルの動的アクション範囲設定
• ルールアクション識別子、特に識別子が修飾されるレベル

ルールを使用してスタディスケジュールに動的フォームまたはイベントを追加する場合、ルールの詳細パネルで動的アクション範囲を設定し、ルールのアクションが実行される範囲を構成する必要があります。動的アクション範囲の設定には 3 つのオプションがあります:

• グローバル: ルールが評価されると、1つのアクションがケースブック全体で実行されます。ルールがどこから実行されるかに関係なく、ルールアクションのフォーム、イベント、またはイベントグループは、アクション識別子が一致する場所でスケジュールに追加されます。動的アクション範囲がグローバルに設定され、ルールのアクション識別子にフォームのみが指定された場合、フォームが存在するスケジュール内のすべてのイベントにフォームが追加されます。フォームとイベントの両方が登録された場合、そのフォームがイベントに登録されているスケジュール内のすべてのイベントグループにフォームが追加されます。

• イベントグループ: ルールが評価されると、そのルールが実行されたイベントグループインスタンス内で 1 つのアクションが実行されます。

• イベント: (フォームの追加ルールのみ) ルールが評価されると、そのルールが実行されたイベント内で 1 つのアクションが実行されます。アクションは、ルールがどこから起動されたかに基づいて、一致する各イベントに対して個別に実行され、ルールの結果はそのイベントに固有のものとなります。

イベントグループの追加ルールアクションは、デフォルトでグローバルレベルで有効になります。

ルールアクションの場所は、動的アクションのスコープとルールアクション識別子の資格レベルによって決まります。ただし、ルールがいつどのように実行されるかを理解することも重要です。これは、ルール式で提供されるコンテキストに基づいています。ルール式の記述の詳細

ルールの競合

ルールの競合は、複数の動的ルールが同じスタディオブジェクトをスケジュールに追加しようとしたときに発生します。たとえば、ルールアクションに同じ動的フォームを使用して設定された 2 つのフォーム追加ルールは、競合していると見なされます。このような状況では、システムは以下の階層に基づいてどのルールが「優位になるか」を判断します:

1. より具体的な動的アクション範囲を持つルールは、より具体的でない動的アクション範囲を持つルールよりも常に優先されます。グローバル範囲は最も特殊性が低く、イベント範囲は最も特殊性が高いと考えられています。
2. 競合するルールが同じ動的アクション範囲を持つ場合、最も具体的な (より修飾された) アクション識別子を持つものが「優位」となります。例えば、アクション識別子が egCYCLE_A > evDAY1 > VS1 であるフォーム追加ルールは、アクションがこのイベント > VS1 であるルールよりも優先されます。
3. 競合するルールが同じ動的アクション範囲とまったく同じアクション識別子を持つ場合、true と評価されるルールがオブジェクトをスケジュールに追加します。この場合、ルールの結果が true であれば、そのオブジェクトはスケジュールに残ります。削除するには、すべての既存の結果が false である必要があります。

イベントとフォームの追加

管理項目のアクションタイプイベントの追加またはフォームの追加を使用してルールを設定することで、ユーザが入力したデータを基に条件付きでイベントとフォームをケースブックに追加することができます。このルール式が True と評価されると、Vault EDCは依存するイベントまたはフォームをケースブックに自動的に追加します。ルールがFalseと評価された場合、イベントまたはフォームの追加は実行されません。

スケジュール内のイベントまたはフォームを動的として設定し、ルールを使用して条件付きで追加するには、Studio の学習スケジュール内の対象イベントまたはフォームのプロパティパネルで、動的をはいに設定する必要があります。

1 つのルールで複数のイベントまたは複数のフォームをスケジュールに追加することができます。同じルールで追加されたフォームやイベントは同じルール式を共有するので、1 つのフォームやイベントが追加や削除されたりすると、すべてのフォームやイベントが追加されます。1 つの (フォームの追加またはイベントの追加) ルールで複数のフォームまたはイベントをスケジュールに追加するには、ルールアクションに追加のオブジェクトを追加します。

イベントグループとは異なり、スタディにイベントやフォームのために、イベントの追加ルールとフォームの追加ルールを作成する必要はありません。フォームとイベントは、それらが条件付きでスケジュールに追加された場合のみ、動的として設定される必要があります。

フォーム追加ルールの範囲

動的ルールを設定する場合、スタディスケジュール内の適切な場所でルールアクションが実行されるように、動的アクション範囲とルールアクション識別子の両方が正しく設定されていることが重要です。

次の表は、動的アクション範囲とルールアクション識別子を選択した場合、LBHEMA というフォームがスタディスケジュールに追加されることを示しています。

フォーム追加ルールの動的アクション範囲とアクション識別子の設定

フォーム追加ルールの例

このルールは、出産可能性 (CHILDPOT) アイテムが「はい (Y)」と入力された状態で人口統計 (DM) フォームが提出された場合に、妊娠 (PREG) フォームを追加します。動的アクション範囲はイベントなので、PREG フォームは DM が送信されたイベントのみに追加されます。

#define CHILDPOT @Form.ig_DM2.CHILDPOT


Not(IsBlank(CHILDPOT))
&&
CHILDPOT = "Y"

Form: DM
Dynamic Action Scope: Event
Rule Action Identifier: this event > PREG

イベント追加ルールの範囲

以下の表は、動的アクション範囲とルールアクション識別子を選択した場合に、evDAY8 というイベントがスケジュールに追加される場所を示しています。

イベント追加ルールの動的アクション範囲とアクション識別子の設定

イベント追加ルールの例

このルールは、同じイベントグループの SURG フォームで「手術を実施済み」 (SURGYN) アイテムが「はい ("Y")」であれば、手術後 (evPOSTSURG) イベントを追加します。

#define SURGYN @Form.igSURG.SURGYN


Not(IsBlank(SURGYN))
&&
SURGYN = 'Y'


Form: SURG
Dynamic Action Scope: Event Group
Rule Action Identifier: this event group > evPOSTSURG

イベントグループの追加

イベントおよびフォームと同様に、イベントグループは、イベントグループの追加ルールアクションを使用して、スタディに動的に追加できます。ただし、イベントやフォームとは異なり、スタディスケジュールの最初のイベントグループ以降のイベントグループはすべて動的であり、ルールを使用して追加する必要があります。この例のイベントグループ追加ルールでは、症例が登録対象である場合、ログイベントグループがケースブックに追加されます。

#define ENROLLYN @Form.ig_ENROLL.ENROLLYN
Not(IsBlank(ENROLLYN))
&&
ENROLLYN = "Y"
Form: ENROLL
Dynamic Action Scope: Global
Rule Action Identifier: $eg_LOGS

1 つのルールで複数のイベントグループを追加するには、アクションパネルでイベントグループを選択し、追加 () をクリックして別のイベントグループを選択します。このルールを使用して、希望するすべてのイベントグループを追加するまで続けます。

ルールによる値の導出 (22R3 以前に作成された治験)

治験内のルールを使用して、自動的に項目フィールドに導出した値を入力することができます。

項目値の設定ルールは、派生項目タイプを使用した項目に対してのみ作成することができます。

項目値の設定ルールの例

フォームにBMIの項目フィールドが必要な場合があります。治験責任医師が各被験者の BMI を個別に算出する代わりに、この項目値を自動的に導出するように設定することができます。BMI の項目定義を作成して項目タイプのプロパティを派生に設定します。BMIの項目は、身長と体重の項目と同じフォームに置く必要があります。

次の式でルールを作成し、項目値の設定アクションを選択して、項目を派生BMI項目に選択します。このルール式では浮動識別子 (@Form) (「ワイルドカード識別子」とも呼ばれる) を使用しているため、アクションを同じレベルに修飾する必要があります (このフォーム > ig_VS > BMI の順に選択)。

#define WEIGHT @Form.ig_VS.mu_WEIGHT
#define HEIGHT @Form.ig_VS.mu_HEIGHT

WEIGHT / (HEIGHT * HEIGHT)

Rule Details Form: Vital Signs

ユーザがフォームに入力すると、BMI項目フィールドに式の結果が自動的に入力されます。

クロスフォームの派生

クロスフォーム派生では、Studio 内のドラッグアンドドロップエディタで派生項目レコードをフォームに追加して導出値の設定ルールを作成すると、ケースブックのフォーム間で値が導出されます。

派生項目の値はフォームの送信の有無に関わらず、導出された値はフォームの再送信なしで自動的に更新されます。派生項目は、データ入力と抽出の両方に対して表示の有無を設定することができます。

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

23R2 時点で、DEV からデプロイするには、結果がターゲットアイテムのデータ型と一致しない導出ルールを修正するか無効にする必要があります。

クロスフォームの派生の詳細については、クロスフォームの派生を参照してください。

訪問方法

訪問方法が構成されている場合は、訪問方法の値を参照するルールを作成し、VISMETHを使用してクエリを開いたり、プロトコル逸脱を作成したりすることができます。

次の例は、特定の訪問方法 (この場合は電話インタビュー) が施設で選択された場合に、ケースブックに動的なフォームを追加するために使用します。

もう 1 つの一般的なユースケースは、1 つのバーチャル訪問が 2 つ以上の連続したイベントで選択された場合にクエリを実行するルールを構成することです。

#define DAY3 @EventGroup.treatment_day_3.visit_method__v
#define DAY4 @EventGroup.treatment_day_4.visit_method__v

Not(IsBlank(DAY3))
&&
DAY3 = "virtual_visit__v"
&&
Not(IsBlank(DAY4))
&&
DAY4 = "virtual_visit__v"

なお、ルールエディタで訪問方法を参照する場合、コード値ではなく選択リストのラベル値を使用する必要があります。

訪問方法の詳細については、訪問方法を参照してください。

ルールによる症例ステータスの設定 (23R2)

治験内のルールを使用して、ユーザが入力したデータを基に被験者のステータスを自動的に設定することができます。

各被験者のステータスは経時的に履歴に保持されます。ユーザが後で管理データを編集した結果ルールが false と評価された場合、被験者のステータスは前 (最後) の状態に戻されます。

使用可能な症例ステータス

被験者ステータスに使用可能なオプションは以下の通りです:

• 立上げ中
• 同意済み
• スクリーニング中
• スクリーニング不適格
• 登録済み
• 無作為化
• 治療開始済み
• 治療の終了
• 回収済み
• フォローアップ開始済み
• フォローアップ喪失
• 完了

イベント日、日 (または日時) 項目のいずれかの値が、ステータス変更の日付として記録されます。ターゲットのステータスに応じて、被験者オブジェクト (subject__v) の異なるフィールドを使用してこの日付が記録されます。注: 立上げ中の場合、症例ステータスは最初のものになるため、被験者の日付フィールドがありません。

• スクリーニング中 → スクリーニング実施日 (screened_date__v)
• スクリーニング不合格 → スクリーニング不合格日 (screen_failed_date__v)
• 登録済み → 登録日 (enrolled_date__v)
• 無作為化 → 無作為化日 (randomized_date__v)
• 治療終了→ 治療終了 (end_of_treatment_date__v)
• 回収済み → 回収日 (withdrawn_date__v)
• 完了 → 治験終了日 (end_of_study_date__v)

ステータス変更日に項目を選択する場合、その項目は日付または日時データ型で、かつ繰り返し項目グループに属していない必要があります。日付と時刻が不明な場合、その日付または時刻の不明な部分は可能な最小値 (最も早いもの) に置き換えられます。

ルールが true と評価されると、そのステータスが最新であるかどうか、または被験者が実際にそのステータスに移行したかどうかに関わらず、常に特定のステータスのステータス日付が追加されます。

最も前進したステータスに設定するルールがロールバックされた場合 (フォームがリセットされた場合など) 、そのステータスの症例ステータスの日付も削除されます。スタジオ > 設定で[件名ステータス日のロールバックを有効にする]を[はい]に設定している場合、関連する症例ステータスルールが false と評価されると、件名に保存されているステータス日はすべて削除されます。

スタジオ > 設定で症例ステータス日のロールバックを有効にするをいいえ に設定しているとき、最も高度なステータスを設定していないルールが false と評価された場合、Vault はそのステータスの症例ステータス日を削除しません。

20R1 より前に作成された症例ステータスルールの設定

20R1リリース (2020 年 4 月) よりも前に作成された症例ステータスの設定ルールは、日付を選択せずに引き続き使用することができます。ただし、ルールを編集した場合は、ステータス変更の日付を選択するまでルールを保存することができません。

症例ステータスと被験者 ID の設定

治験でby_site被験者 ID 生成メソッドを使用している場合、既存の被験者 IDの値に関係なく、ルールがその被験者をスクリーニング中に返すたびに、被験者の ID が増加します。

症例ステータスルールの設定の例

スクリーニングイベントのイベント日を決定したら、被験者のステータスが自動的にスクリーニング中に設定されるようにしたい場合があります。症例ステータスの設定ルールを使用することでこれを行うことができます。

次の式でルールを作成し、症例ステータスの設定アクションタイプとスクリーニング中ステータスを選択します。

Not(IsBlank(@Screening.Screening.event_date__v)

スクリーニングイベントのイベント日が空白でなくなると (ユーザが日付を入力した後)、その被験者のステータスがスクリーニング中に更新されます。

ルールによる通知メールの送信

治験のルールを使用して、特定の条件が発生したときに自動的にユーザグループにメール通知を送信することができます。

詳細については、メール通知の送信を参照してください。

フォームの割り当てられたレビュープランを上書きする

レビュープランの上書きルールアクションを使用して、フォーム (ルールの詳細パネルで選択したフォーム定義) に割り当てられたデフォルトのレビュープランを別のレビュープランに上書きすることができます。例えば、有害事象のフォームには、レビューに必要な項目が少ない低リスクの SDV プランが割り当てられています。例えば、有害事象が「この有害事象は重篤か?」項目.

レビュープランの上書きルールの例:

#define aeser @Form.ig_AE.AESER

aeser = "Y"

Rule Details Form: Adverse Event

Rule Action: Override Review Plan: SDV or DMR

ルールアクションで、SDV または DMR のレビュープランの上書きを選択します。次に、ルールが true と評価されたときにデフォルトのレビュープランを上書きするレビュープランを選択します。

レビュープランを選択し、プランを表示をクリックするとフォームのレビュー要件を確認することができます。

単位変換の式

式を使用して単位変換を定義することもできます。Studio でのデフォルトの単位と変換の定義を参照してください。

使用可能な演算子および関数

複数の演算子と関数をデータ入力規則に使用することができます。全リストはVault CDMS 数式リファレンスをご覧ください。

空白の値の処理

数値型の識別子がある場合、ルールエディタの空白の処理プロパティで、空白の場合の処理方法を選択する必要があります。数値フィールドの場合、これは、Vault が式内の空白のフィールド値をどのように処理するかを決定します。以下のオプションから選択できます:

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

例

次の例では、空白処理オプションの違いによってこの式の結果がどのように影響するかを示しています:

数式:

NUM1 + NUM2