フォームに関するヒントとベストプラクティス
このページでは、試験でフォームや関連レコードを作成・設計する際に役立つさまざまなヒントやベストプラクティスを紹介しています。
- フォームの作成方法の詳細については、フォーム、品目グループ&品目の作成を参照してください。
- フォームの設計方法の詳細については、フォームの設計を参照してください。
一般的なヒント
スタディのフォームを作成する際に役立つ一般的なヒントを以下に示します。
- フォームを設計する際には、安全性とエンドポイントを考慮します。分析に不要な品目を過剰に収集しないようにします。
- 施設での入力フローに沿ったフォームを設計します。
- 可能な場合、イベント間でフォームを再利用します。
- 施設がアイテムを記入していない場合、値が「いいえ(No)」または「False」と解釈される可能性があるため、「存在の有無を確認」スタイルブール値のアイテムを使用しないでください。品目を空白のままにする場合、代わりに品目を故意に空白にするとマークするようにサイトに指示します。
- コメントやテキストフィールドの使用はできるだけ避けてください。コメントやテキストフィールドに記入された場合、分析での使用が困難になります。有害事象用語’(Adverse Event Terms)、併用薬(Concomitant Medications)、病歴(Medical Histories)は医学辞典でコード化されているため、例外とします。
- 同じ質問を収集するために、異なるフォームで複数の品目が使用されていないことを確認します。代わりに、1 つの同一品目を各フォームに作成して使用します。
- 可能な限り、品目グループと個々の品目全体をフォーム間で再利用します。
フォームレビューでの質問
スポンサーとのキックオフミーティングやレビュー会議で質問する標準的な質問リストを用意しておくと良いでしょう。次の質問を検討してください:
- フォームにはフォームリンクが必要ですか?(ConMed への AE、受療歴、投薬の中断等)
- 繰り返しフォームと繰り返し項目グループのどちらを使用する方がよいですか?
- 繰り返しフォームに必要な最大繰り返し回数は何回ですか?
- 日付と日時では、どちらの形式を使用すべきですか?品目は不明を許容するべきですか?計算やルールでは、不明な日付をどのように扱いますか (最小または最大の日付)?
- このフォームのアイテムに、ケースブックのヘッダーに表示したいものはありますか?
フォームの説明を含める
フォームの説明は、SOA品質チェックおよびルール作成中にフォームの目的を伝えるのに役立ち、スタディにフォームのバージョンが複数必要な場合に特に役立ちます。フォームのプロパティ(Properties)パネルに説明(Description)を追加できます。
例えば、心電図フォームには、それが3回連続か単一かを示す説明を追加できます。また、VSフォームには、それがベースラインフォームか治療フォームかを示す説明を追加できます。
説明例:
- 心電図 - 3 回連続、タイムポイントなし
- 心電図 - 3 回連続、タイムポイントあり
- VS - 身長を含むベースライン
- VS - 治療
項目グループ
品目グループの表示
アイテムグループは、臨床概念に基づいてデータをグループ化し、抽出されたデータの整合性を保つのに役立ちます。ヘッダー表示(Header Visible)、視覚化グループ(Visual Group)、表示形式(Display Format)プロパティを使用して、Vaultではフォーム上でアイテムグループがどのように表示されるかを変えることができます。
ヘッダー表示
ヘッダー表示プロパティでは、グループのアイテムの上にアイテムグループのラベル(Label)が表示されます。フォーム上でアイテムのグループ化を見やすくするために、アイテムグループのプロパティパネルでヘッダー表示を常にはい(Yes)に設定しておくことをお勧めします。
なお、1つのフォームに複数のアイテムグループがある場合、ヘッダーの表示の選択に関わらず、すべての抽出で個別の行として表示されます。
視覚化グループ
視覚化グループプロパティでは、アイテムグループ内のアイテムを境界線で区切ります。アイテムを論理的なグループに視覚的に分割するために、アイテムグループのプロパティパネルで視覚化グループを常にはいに設定しておくことをお勧めします。
フォーマットの表示
繰り返しアイテムグループについては、施設ユーザがデータを要約形式で表示できるように、プロパティパネルの表示形式を常にグリッドビュー(編集可能グリッド(Editable Grid)または読み取り専用グリッド(Read Only Grid))に設定しておくことをお勧めします。
繰り返し項目グループ
- 必要に応じて繰り返し項目グループを使用して、1 つのフォームに複数回収集される関連する質問 (項目) のセットをグループ化します。ただし、この機能をボックスを独立させるためだけに過度に使用することは避けてください。
- 各品目グループは抽出の際に個別の行として表示されることにご留意ください。生物統計学プログラマは、最初の品目グループの Yes/No または日付値などを、同一フォームの後続の品目グループに引き継ぐ必要がある場合があります。
- 繰り返しフォームに繰り返し項目グループを追加した場合、繰り返しフォームインスタンスのテーブルビューを表示することができなくなります。
- フォーム間で品目グループを再利用します。例:異なるイベントで異なるタイムポイントをキャプチャする必要があるさまざまなPK(または心電図またはバイタルサイン)フォームに同じアイテムグループを使用します。「PCTPT」というアイテムを1つ作成して、異なる繰り返しアイテムグループのPKフォーム全体で使用できます。単純に、必要な値を繰り返し項目グループのコードリストから選択するだけです。
- 繰り返しアイテムグループ内で、異なるタイムポイントで異なるアイテムを収集するには(最終タイムポイントのみでの「体温」アイテムの収集や特定の物質使用に関連するアイテムの収集など)、プログレッシブディスプレイ(Progressive Display)を使用します。
項目
- アイテムラベルで使用する文字を各単語の語頭を大文字にしたスタイルに統一します。語頭を大文字化するスキーム (タイトルケース、センテンスケース、最初の単語のみ大文字にするなど) を選択し、すべてのアイテムで使用できます。
- 品目のラベルの最後にコロン (:) を使用しないでください。これらはCDB、主要リスト(Core Listings)、スタディデータ抽出(Study Data Extracts)の順に伝送されるため、EDC以外のラベルの変更を必要とする問題を引き起こす可能性があります。
- 可能であれば、フォームあたりの品目数は 50 以内を目安にしてください。この項目数には、繰り返し項目グループの最大繰り返し回数から合計した項目を含みます。繰り返しアイテムグループの使用にあたっては、繰り返しフォームの方が適切かどうかを検討し、制限数を下回るようにします。
- ヘルプコンテンツプロパティを使用することで、難解なアイテムに対する簡単な説明や、ルールごとに質問が予想される範囲のヒントを提供することができます。ここに入力したテキストは、品目のラベルにカーソルを合わせると表示されます。
名前
- 品目の名前の文字にはすべて大文字を使用します。これらの名前は、抽出の際にフィールド名として使用されます。
- ルール内でアイテムを使用するときにエラーが発生しないようにするには、そのアイテム名の最初の文字にアンダースコア(_)を使用しないでください。
- アイテムの命名のベストプラクティスについては、命名規則をご覧ください。
外部 ID
外部ID(External ID)は、EDCと他のアプリケーションで命名規則が異なる場合があるため、主にIRTなどのサードパーティシステムとの連携に使用されます。また、外部IDは、Veevaによって作成されたカスタムソリューションで、CDMS、Vault APIとSDK、およびCDB(データワークベンチ)内でサードパーティデータをインポートする際にも使用することができます。
- 一意の外部IDを使用します。外部 IDが試験内で一意でない場合、ケースブックのバリデーションで警告が表示されます。
- サードパーティ製システムとの連携に品目を使用する場合、必ず外部 IDを指定してください。外部 ID と名前は、一致する必要はありません。外部システムが異なるIDを要求する場合には、名前と外部IDの不一致が想定されます。
- 「CYCLE_2」のように、繰り返しオブジェクトを参照するために外部 ID を使用しないでください。サイクルの詳細については、スタディスケジュールに関するヒント&ベストプラクティスを参照してください。
必須チェック
ほとんどの場合、アイテムのプロパティパネルで必須(Required)をはいに設定する必要があります。はいに設定すると、故意に空白にするにマークがないアイテムを施設ユーザが空白のままにした際、Vaultではそのアイテムに対するクエリが開くようになります。品目値の設定ルールによって入力された派生品目や、IRT システムによって入力された品目など、読み取り専用の品目などは例外です。
将来の日付チェックなし
ほとんどの場合、日付と日時のアイテムのプロパティパネルで将来の日付なし(No Future Date)をはいに設定する必要があります。はいに設定すると、施設ユーザがアイテムに将来の日付を入力するたびに、システムによってクエリが開くようになります。IRT システムによって入力された日付などの読み取り専用の品目や、製品の有効期限を扱う日付などの将来の日付が想定される品目は例外となります。
プログレッシブ表示のヒント (20R1 以降、ルールバージョン 2)
注: プログレッシブ表示は、ルールのバージョン 2を使用している 20R1 リリース以降に作成された試験でのみ使用することができます。
- 可能な限り、プログレッシブ表示を使用するようにしてください。これにより、試験のルール数を大幅に減少することができます。
- 表示(Show)または有効(Enable)のいずれかに使用を統一してください。プログレッシブディスプレイ(複合アイテムの一方が他方を制御する)を使用している複合アイテムでは、どちらのオプションも使用できます。
- フォームがすべて複合品目 (サイドバイサイドレイアウト) で構成されている場合、プログレッシブ表示の対象となる品目は、品目が適切に配置されるために、「表示」ではなく「有効」を使用する必要があります。
- 繰り返し項目グループにデフォルトデータを使用している場合、この項目の値を使用して、プロトコールごとに初回または最終時点の体温の項目を表示するなど、プログレッシブ表示を制御することを検討してください。
また、1 つの品目を使用して、品目グループ全体を「表示」または「有効」にすることもできます。また、[故意に空白にする (ILB)] を選択することもできます。ユーザは、個々の品目を ILB としてマークするだけでなく、品目グループ全体をマークすることもできます。
コードリスト
- 値、順序、および「いいえ/はい、未完了、不明、その他」のコードリストで一貫性を保ちます。サイトはあなたの使用順序に順応するようになります。デザインの一貫性を保つことで、より迅速かつ正確にデータを入力および分析できるようになります。
- 試験が開始され、施設でのデータ入力が発生した場合、新しいコードリスト品目のみを追加する、または不要になった品目を非表示にしてください。この時点では、コードリスト品目を削除することはできません。変更不可のすべての一覧については、試験更新制限を参照してください。
- 複数のコードリストにまたがって使用される値は、必ず同じ形式で保存されるようにしてください。例えば、「NY」と「NYUNK」という 2 つのコードリストがある場合、両方のコードリストで「Yes」を「Y」として保存します。
- フォームをコピーする際は、常に複製によるコードリストの重複が発生しないように確認してください。コードリストで「_1」や「_2」を検索して、複製による不要な重複を削除します。たとえば、「NY」と「NY_1」が存在する場合、コードリスト「NY_1」は複製による重複です。正しいコードリストを参照するように関連する品目を更新し、複製による重複を削除します。
- 試験の設計要件で特に指定されていない限り、値はラベルのすべて大文字のテキストである必要があります。例えば、ラベルが「Oral」の場合、値は「ORAL」になります。SDS ですばやく品質確認を実施することができます。
- コードリスト内の「その他」の値の使用方法について話し合います。可能であれば、「その他」を削除し、代わりに臨床的意味合いを持つ選択肢を含めるようにします。
日付 & 日時品目
日付と日時のアイテムでは、治療歴の開始日(Start Dates)、併用薬、有害事象(Adverse Event)フォームなどで、不明を許可するように設定されていることを必ず確認します。
日付と時刻を収集する場合、日時タイプアイテムを使用することをお勧めします。日付と時刻のアイテムを分離すると、スタディ設定、データ入力、SDV、およびデータ管理が複雑になります。
Veeva EDCでは、完全な日付/時刻収集(DTC)に対応しており、不明な月、日、時刻を許容します。日時データタイプを使用することで、一貫性のある正確なデータ収集が保証されます。この方法では、時刻は常に該当する日付に関連付けられ、ISO規格に準拠した形式になります。
これらの日時に関するベストプラクティスを遵守することによるメリット:
- データ入力時のデータ品質向上
- SDTM のデータセットに対する ISO8601 の日時品目の自然な下流への効率化
- データクリーニング、ルール設定の手間を削減
- 全ての日付要素の一括記録
- DTC の他の日付および日時品目との簡単な比較
- 将来の日付をシステムで本質的にチェック
- ルールの指定やプログラミング、テスト、ユーザ受入テスト時の手間の削減
- データクリーニングの手間の削減
イベント日と評価日の比較
フォームの評価日(Assessment Date)アイテムが日付タイプのアイテムで、収集日が常にイベント日(Event Date)と同じ日になる場合、評価日アイテムをすべて削除します。すべてのデータ抽出にはイベント日は含まれており、これを評価日として利用することができます。
このアプローチの利点は次のとおりです:
- 設定する品目数の削減
- 設定するルール数の削減
- 仕様、テスト、およびユーザ受入テストの要件を軽減する
- 重複データの監視とクリーニングの必要性の低減
- 不要なデータ入力の削減
評価日時(Assessment Date and Time)を収集する必要がある場合、または評価日がイベント日と異なる可能性がある場合、フォームに評価日アイテムのみを使用する必要があります。
品目のデータ型を変更する
シナリオ: 試験は開発環境にあります。TST 環境へはデプロイされていませんが、ルールの作成を開始しました。テストの最中に、日付型から日時型へ、または不明な日付や時刻の許容/禁止を変更するなど、品目のデータ型を変更する必要があります。
品目のデータ型を変更するには:
- 品目のプロパティの将来の日付チェックボックスと必須チェックボックスをオフにします。
- 品目グループから品目を削除します。フォームをまたいで同一の品目グループが使用されている場合は注意が必要です。これは SDS を品目名でフィルタリングすることで簡単に確認することができます。
- 新しいデータ型を使用した新しい品目を作成し、将来の日付チェックボックスと必須チェックボックスをオンにして、その新しい品目を品目グループに追加します。
- 削除した品目を参照するすべてのルールを特定します。SDS の「ルール」ワークシートの「ルール構文」列でその品目の名前を検索すると、簡単に特定することができます。新しい品目を参照するように、これらのルールの見直しを行います。不明を許容するように変更した場合、必要に応じて
MinDate()、MaxDate()、またはDateValue()関数を追加してください。詳細については規則に関するヒント&ベストプラクティスを参照してください。 - ケースブックのバージョンのバリデーションを実行して、修正する必要があるルールの見落としがないかを確認します。
- 不要になった元の品目を削除します。
すでに展開を行っている場合、バージョン間で特定の変更が許可されないことを考慮してください。変更不可のすべての一覧については、試験更新制限を参照してください。ケースブックバージョンが本番環境にデプロイされると、アイテムのデータタイプを変更することは破壊的な変更となり、許可されません。
同一の TST インスタンスまたは本番環境にデプロイする前に、PDFまたは抽出のセットを取得してケースブックの変更前のデータのスナップショットを保持することを検討してください。品目グループとフォームから品目を削除した後に修正を展開した場合、その品目は抽出に含まれなくなります。新しい品目のみが存在するものとして扱われます。
アイテムの削除
スケジュールからオブジェクトを削除する場合は、まずスケジュールからオブジェクトを削除してから、オブジェクト自体を削除することをお勧めします。そうすることで、特にオブジェクトが運用後のスタディ更新の一環として削除される場合に、その後のバージョン管理の問題を防ぐことができます。
スタディデザインがTSTまたは本番環境にデプロイされると、スタディオブジェクトはバージョン管理され、削除することができなくなります。アイテムを削除する必要がある場合は、スタジオのドラッグ&ドロップエディタ(Studio’s Drag and Drop Editor)で削除(Remove)()をクリックするか、時刻&イベントスケジュールエディタ(Time and Events Schedule Editor)で関連する削除アクションをクリックして、アイテムグループからアイテムを削除できます。これにより、品目と品目グループの関係は削除されます (フォームに含まれなくなります) が、品目自体は削除されません。
TST にデプロイし、本番環境にデプロイしていない場合、[プロパティ] パネルからアイテムを削除できます。開発環境または TST でテスト中に品目のデータを入力した場合、次回の TST デプロイは次のエラーで失敗します:
リソース [オブジェクトキー] を削除できません: リソースは [オブジェクトタイプ] で使用されています
スタジオのドラッグ&ドロップエディタのアイテムのプロパティパネルから、またはアイテムリストのアクションメニューからアイテムを削除できます。
このエラーを解決するには、次の選択肢を検討します:
- 新しいTST 環境を作成します。
- TST へのデプロイを開始する場合、スタディデザインのデプロイダイアログで、スタディデータの削除および詳細 PDF の作成チェックボックスをオンにします。
- 品目のデータが送信されたケースブックのフォームまたはイベントをリセットします。また、被験者を削除することもできます。被験者が複数存在する場合や、複数のフォームにまたがって品目が再利用されている場合、エラーが解決されるまでに複数の展開の試行が必要になることがあるため、他の 2 つの選択肢を検討する方が簡単になります。
これはLAB パネルでも重要になります。TST にスタディをデプロイした後で、Analyte ライブラリから検査項目を削除しないでください。