24R3 の新機能

Pre-Release 日: 2024 年 11 月 4 日 | リリース日: 2024 年 11 月 22 日および 2024 年 12 月 6 日

Safety、QualityOne クライアントアプリケーション、RegulatoryOne、Veeva Claims の各アプリケーションのリリース日はそれぞれ異なることがあります。

---

Vault 24R3 のご紹介です。以下の新機能をご覧ください。新機能の有効化に関する情報については、24R3 リリースのインパクトアセスメントをご覧ください。開発者向け機能 (API、VQL など) については、開発者ポータルをご覧ください。

Platform

ハイライト

あらゆる Vault アプリケーションに対して最も影響を及ぼす更新に注目していただくために、Vault Platform のリリースノートにこの注目セクションを含めています。これらの主なポイントの概要は以下に表示されており、リンクから詳細情報にアクセスできます。Vault Platform リリースノートの残りの部分はテーマ別に分類され、最後のセクションでは軽微な機能強化について説明します。

これらの主要な機能のデモや、強力なコア機能に関するナレッジ記事を見るには、Veeva Connect で Vault Platform コミュニティに参加してください。

機能	説明
フラッシュレポート通知のカスタマイズ	フラッシュレポートをスケジュールするときに独自のメッセージテキストを追加できるようになりました。これにより、レポートが届いた理由や何をすべきかといった必要な背景情報をユーザに確実に知らせることができます。
プロセスレポーティング	レコードの履歴やレコードの状態の変化に直接基づいて主要なサイクルタイム指標をレポートする標準的な方法が提供されるようになりました。
参加者をプロンプト表示するワークフロータスク	タスクを完了すると、ユーザはワークフロー内の後続のタスクのワークフロー参加者を選択するように求められるようになりました。
個別ダッシュボードのタブ化	ダッシュボードを独立したタブとして表示できるようになりました。これにより、ユーザは主要な指標に簡単にアクセスして指標を参照できます。
レコード移行モードの機能強化	システムフィールドを設定し、レコードを Vault に移行するときに追加のルールを迂回できるようになりました。これにより、Vault でのデータの作成方法や更新方法をより柔軟に制御できます。
カスタム WebAPI	開発者は、特定のビジネス要件を満たすために、Vault Java SDK を使用してカスタム API エンドポイントを作成できるようになりました。
SDK プロファイラー: 要求の概要	開発者と管理者は、セッションがアクティブな間に発生したすべての SDK 要求を取得するプロファイリングセッションを作成できます。これにより、カスタム SDK ソリューションのトラブルシューティングが改善され、コードの品質が向上します。
開発者向け機能: ダイレクトデータ API - ワークフローのサポート	ダイレクトデータ API のエクスポートに、各ワークフロー、ワークフロー内の各項目、各タスク、参加者グループに関する情報を含むドキュメントおよびオブジェクトワークフローデータが含まれるようになり、エクスポートの包括性がさらに向上しました。

プロセスレポーティング

レポートにおいて、ライフサイクル状態に基づいてオブジェクトレコードのサイクルタイムを計算する新しい関数がサポートされました。

これにより、ユーザと管理者は、プロセスの特定の側面を実行するのにどれくらい時間がかかるか、特定の状態の変化がいつ発生したか、潜在的なボトルネックがどこにあるかをより簡単に理解できるようになります。これらの指標を使用してビジネスプロセス全体を改善し、チームのパフォーマンスを高めることができます。

たとえば、レポートの数式でこれらの関数を使用して、サイクルに焦点を当てたダッシュボードを作成できます。次の例は、各月に開始された契約 (複数の交渉サイクルを経ているものも含む) の交渉サイクルの数を示します。

次の例は、プロセスの各部分の所要時間をレコードのタイプ別に示したものです。

以下の関数が新たに使用可能になりました。

式	説明	パラメータ	出力データタイプ
firstTimeInState	レコードがある特定の状態に初めて移行した日付をレポートします。	フィールド名 (例: state_v) 値 (例: In Review)	DateTime
lastTimeInState	レコードがある特定の状態に最後に移行した日付をレポートします。	フィールド名 (例: state_v) 値 (例: Reviewed)	DateTime
previousState	以前の状態をレポートします。	値名 (例: state_v)	Text
durationInState	レコードがある特定の状態にあった日数をレポートします。レコードが同じ状態を複数回経た場合は、すべての回の日数が加算されます。	フィールド名 (例: state_v) 値 (例: In Review)	小数点付きの数字
countInState	レコードがある特定の状態になった回数をレポートします。	フィールド名 (例: state__v) 値 (例: In Edit)	数字

詳細に関しては、Vault 数式をご覧ください。

参加者をプロンプト表示するワークフロータスク

管理者は、タスク完了の一環としてタスク所有者にワークフロー参加者の選択を求めるようにワークフロータスクを設定できるようになりました。ワークフローの Start ステップでワークフロー参加者を定義するときに、管理者は Allow workflow task owners to select participants を選択できるようになりました。このオプションでは、ワークフロータスクを設定する際に、ワークフロー参加者コントロールをプロンプトとして追加します。

タスクの一環として、または特定の裁定の一部として (Single Verdict オプションを使用している場合) 参加者にプロンプトを表示できます。つまり、たとえば、ユーザーが項目を二次レビューに送信することを選択できるオプションのフローを構築できます。

このように設定されたワークフロー参加者コントロールは、ワークフローの開始時にワークフロー開始者に対して表示されず、プロンプトにはタスクまたは裁定ごとに最大 10 個の参加者コントロールを含めることができます。現在設定中のタスクに割り当てられている参加者グループを選択することはできません。この機能は、ドキュメントワークフローとオブジェクトワークフローの両方で使用できます。

この機能は、Vault Mobile で完了したタスクでは使用できません。

このリリースにおける他のワークフロー最適化機能については、プロセス最適化セクションをご覧ください。

フラッシュレポート通知のカスタマイズ

フラッシュレポートのスケジュール設定を行うユーザが、各フラッシュレポートのメール通知をカスタマイズできるようになりました。通知メッセージのカスタマイズにより背景情報を記載することが可能となるため、通知の受信者は、通知内容と理由、および自分が行うべき操作を理解しやすくなります。

フラッシュレポートのスケジュール作成権限を持つユーザは、Schedule Flash Report ダイアログボックスで、標準のメール通知文を使用するか、あるいはカスタムテキストを設定するかを選択できるようになりました。カスタムテキストを設定する場合は、Vault 設定時の通知テンプレート管理方法と同様に、自由テキスト、HTML タグとレポートトークンを組み合わせて使用できます。

レポートトークンにアクセスする際、ドル記号 ($) またはプラス記号 (+) を入力すると、使用可能なレポートトークン一覧が自動的に表示されます。

既存の Send to users in Group By user field オプションをすでに使用している場合は、レポート内に含まれるユーザにのみ通知を送信し、共有設定に手動で追加されたユーザには通知を送信しないユーザオプションも表示されます。Send to users in Group By user field オプションを使用中の場合、Send standard email notification to manually added report users オプションはデフォルトでは非選択の状態になります。

詳しくは、フラッシュレポートをご覧ください。この機能の詳細については、開発者向け機能をご覧ください。

個別ダッシュボードのタブ化

管理者は特定のダッシュボードを Vault 上の独立したタブとして設定し、Vault 上にある他のタブと同様に管理できるようになりました。

この機能強化により、ユーザが主要なダッシュボードと指標にアクセスしやすくなります。一部のアプリケーションのホームページは特殊で、ダッシュボードに似ている一方で任意に設定できないケースがあります。ダッシュボードをタブとして定義する機能を使うと、ダッシュボードをカスタム代替ページとして活用することが可能になります。

ダッシュボードタブを各ユーザのランディングタブとして使用することはできません。

詳細については、ダッシュボードとカスタムタブをご覧ください。この機能の詳細については、開発者向け機能をご覧ください。

カスタム WebAPI

開発者はカスタム WebAPI を作成し、インテグレーションと外部ツールで使用できるカスタムビジネスロジックによって Vault を拡張できるようになりました。例えば、開発者は複数のオブジェクトからレコードを返す複合 API を作成したり、同じトランザクション内で複数のオブジェクトレコードを作成または更新したりできます。さらに、カスタム WebAPI では、ドキュメントの作成、オブジェクトレコードへのファイルの添付、または Attachment フィールドの更新に使用できる単一ファイルのアップロードを受け入れることができます。カスタム WebAPI では、コンテンツがドキュメント、オブジェクトレコード添付ファイル、または Attachment フィールドである、単一ファイルの回答を返すこともできます。

カスタム WebAPI は、管理者が定義して権限セットに割り当てた WebAPI グループに割り当てられます。API 呼び出し元は、カスタム WebAPI にアクセスするには WebAPI グループへのアクセス権限を持っている必要があります。

この機能の詳細については、開発者向け機能をご覧ください。

SDK プロファイラー: 要求の概要

SDK プロファイラーを使用すると、開発者と管理者はカスタム Vault Java SDK のプロファイリングセッションを作成し、使用メモリや経過時間などのパフォーマンスを点検できます。これにより、開発者はカスタムコードを使用して運用上の問題をトリアージし、ソリューションのパフォーマンスを調整し、パフォーマンスの不具合がないかを確認するために変更点をテストできるようになります。その結果、高いコード品質が保証され、エンドユーザエクスペリエンスがカスタムコードによって影響を受けることはありません。プロファイリングセッションは、Vault 管理者の UI (Admin > Logs > Vault Java SDK) および Vault API を使用して管理できます。

ユーザエクスペリエンス

ドキュメントビューアツールバーの簡素化

すべてのツールとオプションをツールバー 1 行内に収めるため、ドキュメント ビューアの使用感が簡素化・最適化されました。これによりすべてのツールにアクセスしやすくなったほか、ドキュメントをサイズ変更する手間も最小限に抑えることができます。

注釈フィルタ

注釈フィルタツールを右側に配置して、表示されている全注釈と同じ側に配置しました。

埋め込みリンク

埋め込みリンクを操作する際にも、ビューアで使用中のモードやツールに関係なく、すべてのリンクがクリック可能になりました。以前は、Grab が選択されていない場合、リンク先に移動するにはカーソルを合わせて表示されるツールチップをクリックする必要がありました。今回のアップデートでツールチップは参照専用になり、ユーザはリンクを直接クリックして移動できるようになりました。

Annotate モードのデフォルト設定

その他ドキュメント ビューアに実装された機能強化には、注釈が存在する場合にのみデフォルトで Annotate モード表示される機能、即時的なプレーヤーのサイズ調整を含む動画レビュー機能の改善、動画を注釈付きで全画面表示する機能、および Notes ビューと Overlay モードの廃止などがあります。

詳細については、ドキュメント情報ページをご覧ください。

注釈の永続的 ID

Vault では、新規注釈と更新した注釈すべてに対して、一意の永続的 ID が自動作成されるようになりました。この補足的な ID は、注釈を新しいバージョンへと引き継いでも全ドキュメントバージョン間で保持されます。つまり、過去のドキュメントバージョンから引き継いだ注釈には、すべてのバージョンで同一の永続的 ID が適用されます。

この永続的 ID により、Bring Forward Annotations 操作による重複した注釈の作成が防止されます。この操作を実行すると、ターゲットバージョン中にすでに存在する注釈の永続的 ID に一致する注釈がソースバージョン中に見つかった場合、その個々の注釈は引き継がれません。これによりユーザは、注釈の重複コピーを発生させることなく、同一のソースバージョンまたは別のソースバージョンから Bring Forward Annotations を複数回実行できるようになります。

この ID はアンカー注釈の情報カードで確認でき、ユーザのクリップボードにコピーできます。ID の形式は常に Vault ID で始まります (例: VaultID_###)。ユーザはこの永続的 ID を Select Anchors ダイアログで検索することで、新しいドキュメントバージョンに引き継がれたアンカー注釈も見つけることができます。

詳細については、ドキュメントの注釈をご覧ください。この機能の詳細については、開発者向け機能をご覧ください。

外部ビューア: 閲覧できるレンディションがない場合にソースファイルのダウンロードを有効にする

外部ビューアを使用する各アプリケーションでは、目的のドキュメントに閲覧可能なレンディションがなく、かつそのドキュメントの設定でソースファイルのダウンロードが許可されている場合に、レンディションが存在しないことを示すメッセージと、ソースファイルのダウンロードを実行するボタンが表示されるようになりました。 

この機能強化により、zip 形式でファイル共有されたインシデントレポートを、QMS 内でフォーマットされた出力で共有するなどの用途が可能になります。

外部ビューアには直接 URL 経由でアクセスされ、Vault ユーザ以外にドキュメントを送信するためによく使用されます。複数のドキュメントを直接 URL 経由で外部ビューアに送信する一般的な使用例は次のとおりです。

• MedInquiry の回答パッケージの送信
• Medical と PromoMats の Approved Email
• SiteConnect を介した安全性情報の配布 (有効なアグリーメントのない施設に対して)
• SafetyDocs 内電子メールでの PVA ドキュメントの配布
• QMS: 外部関係者へのドキュメントの送信

レイアウト設定時の必須フィールド・読み取り専用フィールドの設定

24R3 より前は、管理者は特定のレイアウトでのみ、レイアウトルールを用いてフィールドを必須として表示したり読み取り専用として表示することができました。今回のリリースにより、管理者はレイアウトルールを使用せずに、特定レイアウト内のフィールドを常に Display as Required (必須として表示) または Display as Read-Only (読み取り専用として表示) するよう簡単に設定できるようになりました。

管理者は、直接レイアウト内で任意のフィールドについている鉛筆アイコンをクリックすることで、この設定を行えます。

さらに細かい条件付けと共に必須フィールド・読み取り専用フィールドを設定する場合には Vault のレイアウト表現エディタで従来のレイアウトルールを活用することもできますが、今回の機能強化により、特定のレイアウトで常に必須・読み取り専用として表示させる必要がある場合にその設定を適用しやすくなりました。

詳細については、オブジェクトレイアウトの設定をご覧ください。この機能の詳細については、開発者向け機能をご覧ください。

印刷レコードの機能強化

レイアウト上で利用可能な場合、印刷レコードによって生成される PDF にワークフロータイムラインセクションが含まれるようになりました。最初の 5 行のみが含まれます。さらに、PDF フッターに合計ページ数が追加されました。

詳細については、印刷レコードをご覧ください。

チェックリスト質問の参考画像

新たに実装された Reference Media フィールドを使用して、チェックリスト内の質問や複数選択式の回答に画像を追加できるようになりました。この機能は、質問・回答のより詳細な背景情報をチェックリスト回答者に提供するうえで役立ちます。参考画像は、ライブラリ質問とその複数選択式の回答にも追加できます。現在 Vault では、次の画像ファイル形式がサポートされています。

• *.jpg、*.jpeg

• *.png

• *.gif

• *.svg

• *.bmp

• *.webp

• *.avif

Visual Checklist Designer で各質問の Additional Configuration パネルにある Reference Media フィールドを有効にすると、各質問と回答に Reference Media フィールドが表示され、ライブラリから画像ドキュメントを選択できるようになります。

画像ドキュメントを選択した後に、表示したい特定のバージョンを選択する必要があります。24R3 で選択できるのは、画像ファイル形式タイプのドキュメントのみです。回答者に選択したドキュメントバージョンへのアクセス権がなくても、回答者が割り当てられたチェックリストに記入する際に該当のドキュメントバージョンがレンダリングされます。

Visual Checklist Designer を使用すると、選択した画像ドキュメントを保存前にプレビューできます。また、Translate モードを使用すると、選択した翻訳言語に対応する別の画像をアップロードすることもできます。その翻訳言語を選択したユーザには、元の画像ドキュメントの代わりにその代替画像が表示されます。

チェックリストデザインのプレビュー時、または回答者がチェックリストにアクセスしているときには、画像は最大幅 800 ピクセルで表示されます。画像をクリックすると、画面上で拡大できます。

新たに実装されたこの参考画像機能は、Vault Mobile でもサポートされています。

既存の Reference Document オプションではライブラリ内に格納されているドキュメントへのリンクが記載され、回答者はそのリンクを別タブで開いて確認する方式を取りますが、Reference Media 機能はそれとは異なり、選択したドキュメントの内容が同一ページ上にインライン表示される設計です。

このリリースでは、デフォルトで、すべてのチェックリストタイプの Visual Checklist Designer フィールド で Reference Media フィールドが使用可能な状態となっています。

詳細については、チェックリストの設定およびチェックリストの設計をご覧ください。

日付フィールド入力の改善

日付入力の際に、さまざまな日付形式が認識されるようになりました。認識される形式には、(ユーザのロケールに基づいて) スラッシュまたはドット区切り文字を使用した (または区切り文字なしの) 数値形式や、1 桁の月と日にゼロを加えた形式などが含まれます。日付は英数字形式でも入力できます。その場合、Vault で設定された日付形式に従って自動的に日付がフォーマットされます。

全て の [日付] と [日付時刻] フィールドは、各ユーザーとすべて の Vault のロケールに基づいて表示されます。既存のチェックボックス Format dates and times based on the user’s locale 設定は削除されました。

既存の各 Vault では、現在設定されている既存の日付形式が維持されます。24R3 以降に作成された新しい Vault では、Vault 日付形式の標準デフォルトとして英数字形式が設定されています。英数字はロケール間でより読みやすく曖昧さが少なく、現在ほとんどの Vault で使用されている設定です。

現在、Format dates and times based on the user’s locale オプションがオフになっている Vault の場合、ロケールが Vault ロケールと異なるユーザには、日付がユーザのロケールに基づいて表示されます。 

詳細については、Vault の日付 & 時刻形式をご覧ください。

今後の概要メール機能強化のオプトアウト設定

25R1 では、ユーザの受け取る過剰な通知数を削減するため、標準設定として概要メール通知をより頻繁に使用する方法による機能強化がいくつか導入されました。

• これまで多数の通知テンプレートにおいて Email Preference フィールドがEvery Occurence に設定されていた場合、このフィールドを (Platform とアプリケーション固有テンプレートの両方で) Summaryに設定
• Delivery Interval のデフォルト値を 1 時間に変更
• Annotation Replies、Send As Link、Shared Views、Favorite Document notification、Summary Email Interval など通知関連の一部フィールドをデフォルトで User Profile ページに表示。これにより、ユーザが各自で通知設定を調整できるようになります
• 25R1 では新しい通知カテゴリとして Favorite Document が追加され、これによりユーザがお気に入りドキュメント通知のメール設定を選択できるようになりました
• 25R1 では新しいフィールド Summary Email Interval が追加され、これによりユーザが各自にとって最適な配信間隔を選択できるようになりました

この変更は、すべてのユーザがこれまでどおり必要な情報を概要メールで受信しながら、Vault から受信するメールの総数を削減するうえで役立ちます。

24R3 では、より時間をかけて上記の変更に備えたいというユーザ向けに、25R1 で実装された変更を 25R2 Release まで延期するための新しいチェックボックスが Admin > Settings > General Settings に追加されています。

詳細については、概要メールをご覧ください。

厳密な一致調整

ドキュメントまたはオブジェクトレコードを検索する際、Vault は、項目が結果として返されるためにそれらの用語がいくつ一致する必要があるかに関するルールを適用します。このリリースでは、これらのルールを調整して、より多くの結果が返されるようにします (ルールを若干緩めます)。ただし、一致する項目が多すぎて結果セットが役に立たなくなることはありません。

新しいルールでは、項目が結果として返されるには、検索用語の 70% (切り捨て) が一致する必要があります。たとえば、次のようになります。

• 2 つの用語を含む検索では、そのうち 1 つが一致する必要がある
• 3 つまたは 4 つの用語を含む検索では、そのうち 2 つが一致する必要がある
• 5 つの用語を含む検索では、5 つのうち 3 つが一致する必要がある
• 8 つの用語を含む検索では、8 つのうち 5 つが一致する必要がある

これが、以前のルールと微妙に異なる点です。以前は、5 つ以上の用語を含む検索では、2 つを除くすべての用語 (この場合は 6 つ) が一致する必要がありました。

用語の 70% が一致する必要があるというこのルールでは、以前のルールセットよりも理解しやすく、返される結果の数がわずかに増えて、項目が予期せず省略されるのを防ぐことができます。

厳密な一致と Vault の検索設定の詳細をご覧ください。

ID パターン検索結果の改善

旧リリースでは、Vault で複数の ID パターン (ドキュメント番号など) を検索する際には、正確な結果を得るために「引用符」を使用する必要がありました。引用符を付けなかった場合は複数の検索語に分割して検索されるため、過剰な数の検索結果が返されていました。

24R3 では、引用符を付けなくても自動的に ID パターンが認識されるようになりました。たとえば「ABC-123 DEF-456」と検索すると、ハイフン、アンダースコアやスラッシュに関係なく、両方の ID が正しく識別されます。正確な ID 形式を忘れた場合でも、「ABC123 DEF456」と検索すれば、検索結果として ABC-123、ABC/123、または ABC_123 が返されます。この変更により、検索対象が見つかる可能性が高まります。

プロセス最適化

ワークフローでユーザ参照フィールドを参加者として使用

オブジェクトレコードのフィールドで特定のユーザーを指定する機能を使用すると、レコードの共有設定で特定のロールを持たない担当者またはプロセス所有者が選択されることがよくあります。ユーザー参照フィールドで選択されたユーザーにタスクを割り当て、通知を送信したり、Update Sharing Settings ワークフローステップを使用してユーザーをロールに追加したりできるようになりました。

ワークフローの Start ステップでワークフロー参加者を設定するときに、管理者は Use user reference field as participant を選択できるようになりました。これにより、オブジェクトのユーザー参照フィールドの 1 つを選択できます。

Use roles as participants と同様に、このタイプのワークフロー参加者は、そのフィールドのユーザーが誰であるかを Vault がすでに認識しているため、ワークフロー開始者に対して Start ステップに表示されません。

通常、Vault はワークフローの開始時にワークフロー参加者グループに誰が属しているかを判断します。ただし、これらのユーザー参照参加者については、それらを使用するワークフローステップ (タスクの作成、通知の送信、共有設定の更新など) が実行されるまで解決されません。これにより、そのユーザー参照フィールドがワークフローの序盤で設定された後、ワークフローの後半で (たとえば、タスク所有者として) 使用されるというプロセスが可能になります。

この機能のもう 1 つの重要な要素は、ワークフロー参加者が、ワークフローで定義されたオブジェクトの特定のユーザー参照フィールド (Manager フィールドなど) について、User オブジェクトの別のユーザー参照フィールドを参照するように設定できることです。

ワークフローでグループを参加者として使用

多くのお客様は、手動のユーザグループ (および動的アクセスコントロールで使用される自動管理グループ) を使用して、ドキュメントやデータを共有し、ワークフロータスクを割り当てています。24R3 では、Start ステップでワークフローを設定し、ワークフロー参加者を定義するときに、管理者は Use Vault user groups as participants を選択して、ユーザーグループ (上限 1) のユーザーをデフォルト設定できるようになりました。ワークフローが開始されると、Vault はその時点でそのユーザーグループに含まれるすべてのユーザーをワークフロー参加者グループに追加します (その後、タスクの割り当て、共有設定の更新、通知の送信などに使用されます)。

新しい Use Vault user group as participants オプションは、システム管理グループ、カスタムグループ、およびマネージャーグループ (Vault で有効になっている場合) をサポートしていますが、動的アクセスコントロールによって作成された自動管理グループはサポートしていません。これは現在の Use roles as participants オプションとほぼ同じように機能します。Vault がすべてのユーザー選択を処理するため、Workflow Participant フィールドはワークフロー開始者に対して Start ステップに表示されません。

ライフサイクル & ワークフロー条件 & エントリ条件検証での数式のサポート

ライフサイクル状態のユーザアクション、エントリアクションおよびエントリ条件を定義する際に、アクションを使用可能にする条件やアクションを実行する条件を数式表現を使用して設定できるようになりました。

Condition Type セレクターが、これまでラジオボタンでAlways または Perform with conditions を選択していた形式からドロップダウンフィールドへと変更されました。さらに、条件タイプとして新たに Formula evaluates to TRUE オプションが追加されました。上記の例では、日付フィールドに基づく条件設定を行う場合、この新しい形式の方がはるかに優れていることがわかります。たとえば、「未来の日付は選択できない」という条件を設定する際に、「過去 X 日以内」と設定する必要がなくなりました。

この新しい機能は、ワークフローにおいてアクションステップ (フィールド更新や状態変更など) の定義づけや、決断ステップで各ルールの条件を定義づけを行う際にも使用できます。

またこの機能強化によって、ライフサイクル状態のエントリ条件機能も大きく改善されました。数式を設定できる (「true」と判定された場合にのみ状態変更を許可する) だけでなく、数式により「false」と判定され状態変更が阻止された場合に表示する Validation Error Message を設定することもできます。

エントリアクション: Delete Annotation Comments on Latest Version

この機能では、ライフサイクル状態の新規エントリアクション Delete annotation comments on latest version が導入されました。このエントリアクションを使用すると、ドキュメントの最新バージョンからのみコメント注釈およびドキュメント レベルのコメントが削除されます。

24R3 より前は、管理者は既存のエントリアクション Delete annotation comments を任意で選択できました。このアクションでは、最新バージョンおよび最新バージョン以下に含まれるすべての下位バージョンからコメントを削除できる一方で、最新バージョンから注釈を削除することはできません。 

この機能強化によって、より確実なオプションを使用し、ライフサイクル状態の変更時に注釈コメント処理方法の標準化を行えるようになりました。この新規エントリアクションは、既存のエントリアクションと同様、ドキュメントリンクやアンカー注釈には影響しません。

データの管理

Attachment フィールド

新しい Attachment オブジェクトフィールドタイプを使用すると、ユーザーはファイルを選択してオブジェクトレコードにアップロードできます。オブジェクトレコードの Attachment セクションと呼ばれるレコード添付ファイルとは異なり、Attachment フィールドを使用すると、レコードに含める必要がある特定のファイル専用のアップロードスロットを設定できます。

この機能は、コンテンツを Long Text フィールドに貼り付けることができないが、一般的な添付ファイルとは対照的にファイルのコンテンツの目的を明確に識別したいような、大規模なデータ移行で役立ちます。

Attachment フィールドにファイルを直接ドラッグアンドドロップします。

Attachment フィールドには、最大 100 MB のファイルを 1 つだけ含めることができます。

レイアウトルールと検証ルールを isBlank() 関数、またはライフサイクル状態エントリ条件とともに使用して、これらのフィールドがライフサイクル内の特定のポイントで (または設定したロジックに従って) 入力されるようにすることができます。

Vault では、Attachment フィールドにアップロードされたファイルがレンダリングされないため、これらを表示するにはダウンロードする必要があります。ライフサイクル状態またはロールレベルで Atomic Security を介して Attachment フィールドを制御でき、VQL でこれらのフィールドにクエリを実行して、ファイル名、MIME タイプ、およびファイルサイズを取得できます。これらのフィールドは、Attachment フィールドが設定されているオブジェクトのレポートでも使用できます。ファイルステージングサーバーに追加されたファイルは、ファイルパス (ファイルステージングサーバー情報へのリンク) を参照することで、Loader 経由で Attachment フィールドに追加できます。最後に、Sandbox を含む Vault のコピー作成は、Attachment フィールドをサポートしています。つまり、Vault のコピーにオブジェクトレコードが含まれていて、Attachment フィールドにファイルが含まれている場合、それらのファイルはコピー作成された Vault およびレコードにコピーされます。

フィールドサブタイプ

24R3 では、今回のリリースで導入された新規フィールドサブタイプに対応するため、Create Field ページ (Admin > Configuration > Objects > [Object] > Fields > Create) の UI が更新されています。

既存のフィールドサブタイプである Link (テキストのサブタイプ) およびCurrency (数値のサブタイプ) に加えて、次の新規サブタイプが導入され、それぞれ異なる新規フィールドタイプとして表示されます。

• Percent (数値)
• Email (テキスト) - 「mailto」ハイパーリンクの書式になります (メールアドレスが実際に使用されているかどうかは検証されません)
• Phone (テキスト) - 可能な場合は、国際電話番号の書式になります
• Time (テキスト) - Vault UI の時刻セレクタでユーザの選択した時刻が、ユーザの現地時間に基づく書式になります

Format Mask を Percent、Email、Phone のように動作するようにカスタム設定できますが、これらの新しい標準フィールドサブタイプにより、今後は自分で管理する必要がなくなります。さらに、これらの標準フィールドサブタイプを使用すると、データの入力や検証を簡単に行うための特殊 UI を作成できます。

現在時刻に最も近い時刻が、セレクター内で強調表示されます。

フィールドサブタイプは、テキストおよび数値の各データタイプを特殊な方式で表示する方法であり、Vault で各オブジェクトのフィールドを確認すると、Data Type 列には本来のデータタイプが示されています。

この機能の詳細については、開発者向け機能をご覧ください。

User 対 Person 間の同期の機能強化

ユーザレコードに変更を加えると (直接または VeevaID ポータルを介して)、同期適格フィールド (First Name、Last Name、Language、Locale、Timezone、Email、Mobile、Image、Manager) が、すべての Vault 上の当該ユーザを参照する Person レコードに自動的に同期されるようになりました。

発生した変更の透明性を高めるため、Person オブジェクトに関連する Prior Person オブジェクトが新たに追加されました。このオブジェクトには、User 対 Person 間の同期プロセスが実施される前の値が格納されます。同期が行われるたびに Prior Person レコードが更新され、これらの自動同期された変更の完全な履歴を監査履歴で見ることができます。

この変更に加えて、Person レコードの同期適格フィールドに対する編集の制限がなくなり、Vault 管理者はこれらのフィールドを自由に編集できるようになりました。これまでは、関連付けられているユーザがクロスドメインユーザまたは VeevaID ユーザであった場合、これらのフィールドの編集は制限されていました。ただし、Person レコードが更新されたときの User 対 Person 間の同期によってクロスドメインユーザまたは VeevaID ユーザの User レコードが更新されることはありません。

Yes/No チェックボックスフィールドの機能強化

オブジェクトの Yes/No フィールドは常に null 値をサポートしていますが、チェックボックスとして設定された Yes/No フィールドはこの値をサポートしていません。ユーザーが能動的に Yes または No を選択しなかった場合、Yes/No フィールドは null になります。24R3 では、Yes/No チェックボックスフィールドは null 値もサポートしているため、レコードの作成および更新方法に影響を与えます。

新しいレコードの作成と Vault 設定に対する影響

• 新しいレコードを作成するときに、ユーザーが選択を行わない場合、フィールドにデフォルト値が設定されていないと、チェックボックスは null として保存されます。24R3 より前は、Vault はフィールドを No として保存し、チェックボックスをオフにしていました。
• Yes/No チェックボックスが null になっている場合、No 設定またはクリアされたチェックボックスと同じ見た目で表示されます。ただしツールチップにカーソルを合わせると、そのチェックボックスは null と表示されます。
• Yes/No フィールドをチェックボックスフィールドに変更しても、レコードの null Yes/No フィールドが更新されなくなりました (代わりに No に設定されます)。これは、Yes/No チェックボックスフィールドが null 値をサポートするようになったためです。
• オブジェクトまたはオブジェクトタイプに新しい Yes/No チェックボックスフィールドを作成しても、既存のレコードが更新されなくなりました。これは、Yes/No チェックボックスフィールドが null 値をサポートするようになったためで、すでに存在するレコードの場合に当てはまります。

動作を維持するためにリリースの夜に自動的に設定を更新

Veeva は、リリースの夜に既存の設定の自動アップグレードを行うことで、現在の動作を自動的に維持します。デフォルト値が設定されていない既存のカスタムの Yes/No チェックボックスフィールドでは、デフォルト値が No に設定されます。これは、24R3 より前のレコードの Create および Update 動作と一致しています。選択が行われなかった場合、Vault はフィールドを No として保存し、チェックボックスをオフにしていました。

統合とカスタム SDK コード

API では、API または SDK 経由で null 値を渡すことで、 Yes/No チェックボックスフィールドをクリアできるようになりました。統合とカスタム SDK コードは、Yes/No チェックボックスフィールドが null にならないことを前提に記述されている場合に確認する必要があります。例:

• レコードを作成していますが、Yes/No チェックボックスフィールドに明示的な値を設定していないため、作成後に No 値が設定されることを予想しています。
• コード内で Yes/No チェックボックスフィールドを null に設定していて、これが false になることを意図しています (24R3 では、これは null になります)。
• Yes/No チェックボックスフィールドの値を取得し、その値を評価して次のコード行を決定していますが、値が null になる可能性を考慮していません。

古い API バージョンは現在の動作を維持するため、API バージョンが更新されない限り、既存の統合は影響を受けません。

Yes/No チェックボックスフィールドを参照する Vault 設定のベストプラクティス

既存の設定は引き続き機能しますが、ベストプラクティスとして、Yes/No チェックボックスフィールドを含むすべてのフィールドタイプで常に null 値 (空白値と同じように扱われる) を考慮するように、数式、フィルタ、レポート、動的ロールの割り当てなどを識別することが重要です。

分析

ダッシュボードの色のコントラストの向上

24R2 リリースにおいて、より視覚的に際立ったユーザフレンドリーなエクスペリエンスを提供するためにいくつかの機能強化がなされ、Vault ユーザインターフェースの色のコントラストが向上しました。

24R3 では、Vault 全体にわたって視覚的エクスペリエンスの一貫性を確保するため、これらの変更がダッシュボードに拡張されました。これにより、今後ダッシュボードコンポーネントで使用されるデフォルトの色が変更されます。ただし、レポート作成者は引き続き、条件付きフィールドを使用してカスタムの色を作成できます。

詳細については、ダッシュボードの作成と編集およびダッシュボードの表示と共有をご覧ください。 

ダッシュボードのキャッシュを減らして最終更新時刻を表示

ダッシュボードは、手動で更新されない限り、12 時間ごとに自動的に更新されるようになりました。24R3 より前は、ダッシュボードのデータは 36 時間ごとにキャッシュされて自動的に更新されていたため、ユーザーは頻繁に手動で更新する必要がありました。

さらに、ダッシュボードコンポーネントでは、各グラフに最終更新時刻を示すアイコンが表示されるようになり、ユーザーは最終更新時刻に基づいてデータがどの程度最新であるかを簡単に把握できるようになりました。

ダッシュボードの詳細をご覧ください。

数式内の選択リストの機能強化

Veeva の共通データアーキテクチャ構築に向けた取り組みの一環として、新たに PicklistValues 関数が導入されました。この関数は、オブジェクトの数式表現で選択リストの値を返す方法として推奨されます。PicklistValues 関数は、選択リスト名の値入力時にハイフンをサポートしているほか、1 つの数式で複数の値を返すことができます。記述例としては、PicklistValues(picklist_field__c,'texas__c','new-york__c') などです。PicklistValues 関数では複数の値を返すことができますが、複数の値を持つ選択リストフィールドに、数式によって複数の値を入力する機能はまだサポートされていません。

ドキュメント数式フィールドをステータスと状態タイプに限定

次のドキュメント数式フィールド関数を使用する際、新しい数式フィールドでは、Document Status フィールドと Document State Type フィールドのみがサポートされます。

• DurationInValue()
• NumTimesInValue()
• FirstTimeInValue()
• LastTimeInValue()
• PreviousValue()

これらの関数は通常、サイクルタイムの計算を実行するために使用され、Document Status 以外のフィールドで使用されることはほとんどありません。フィールドは監査証跡を照会することで機能するため、これらの関数を Document Status と Document State Type に集中させることで、これらの関数の主な使用例をサポートしながら、Vault の監査証跡のスケーラビリティを向上させることができます。

これらの関数やその他のフィールドタイプを使用している既存のドキュメント数式フィールドは、24R3 以降も引き続き機能しますが、新しい数式フィールドでは、Document Status フィールドと Document State Type フィールドのみが使用可能です。

ドキュメント数式フィールドの詳細をご覧ください。

管理者エクスペリエンス

File Staging のリンク付け

今回のリリースにより、管理者は製品サポートに問い合わせることなく、Vault の File Staging サーバーを別の Vault にリンクできるようになりました。各 Vault には File Staging サーバーがあり、このサーバーは Vault でファイルをインポートまたはエクスポートする際の一時的なストレージ領域として機能しています。データ移行時には、ドキュメントを別々の File Staging サーバー間で手動移行するのではなく、File Staging をリンクする方法が一般的です。

Admin > Settings > File Staging Settings に新しいエリアが追加され、管理者が Vault の File Staging を変更できるようになりました。各 Vault に設定できる File Staging の数は 1 つのみですが、1 つの File Staging 領域に対して複数の Vault をリンクすることが可能です。 

File Staging の詳細については、こちらをご覧ください。

オブジェクトタイプの説明

オブジェクトタイプが有効になっているオブジェクトの場合、管理者は各オブジェクトタイプの背後にあるコンテキストを理解する必要がある場合があります。24R3 では、管理者はオブジェクトタイプの作成または編集時に Description フィールドに入力できるようになりました。オブジェクトタイプの説明は、メタデータの一部として含まれます。

データ使用量情報中のシステム管理オブジェクトの表示切り替え

Data Usage Information 表 (Admin > About > Vault Information) では、デフォルトでシステム管理オブジェクトが表示されなくなりました。この変更により、よりユーザデータに関連性の高い情報が表示されますが、Include System Managed Objects チェックボックスをクリックすることによりシステム管理オブジェクトのデータも表示できます。

Vault Loader レコード移行モードの機能強化

Record Migration Mode Enhancements 機能を最大限に活用できるよう、Vault Loader が機能強化されました。

外出先での Vault の使用

ドキュメントのお気に入り追加

Vault Mobile 上でドキュメントをお気に入り登録したり、お気に入りから削除できるようになりました。

この機能強化により、ユーザはウェブブラウザを開かなくても簡単にお気に入り操作を行えます。この機能は、ユーザがお気に入りドキュメントの通知を活用している場合に特に役立ちます。

詳細については、お気に入りドキュメントおよび Vault Mobile でのお気に入りドキュメントの通知 の使用方法をご覧ください。

サイトセレクタのサポート (SiteVault)

SiteVault ユーザーは、Vault Mobile アプリ内でサイトのコンテキストを表示および変更できるようになりました。各モバイルタブの上部に新しいサイトセレクタリストが表示され、ライブラリの結果を特定のサイトにフィルタ処理できるようになります。

SiteVault は特定のセレクタを活用して、ユーザーが SiteVault 内で研究組織やサイト間を移動できるようにします。アクセスまたは管理できるドキュメントは、選択したサイトコンテキストによって決まります。これにより、SiteVault ユーザーにとって、モバイルアプリと Web ブラウザ間のユーザーエクスペリエンスがより一貫したものになります。

SiteVault の詳細をご覧ください。

タイムラインビューの表示

Vault Mobile では特定ドキュメントのタイムラインビューを表示できるようになりました。これによりユーザは目的のドキュメントの履歴を確認できるほか、ワークフローの一部として組み込まれているドキュメントの場合は、タスク判定が未完であるか完了済みであるかも閲覧できます。

詳しくは、Vault Mobile をご覧ください。

Web でバインダーを開く

Vault Mobile アプリでバインダーにアクセスしようとするユーザーには、モバイルブラウザでそのバインダーを簡単に開くことができるようになりました。

Vault Mobile は、モバイルアプリ内でのバインダーのナビゲーションをまだ完全にはサポートしていませんが、この機能強化により、ユーザーはブラウザでバインダーをすぐに開いて必要な作業を実行できるため、ユーザーにとっての煩わしさや混乱が解消されます。 

詳しくは、Vault Mobile をご覧ください。

アプリがバックグラウンドにあるときにコンテンツをぼかす

Vault Mobile アプリがデバイスのバックグラウンドにある場合、アプリのコンテンツがぼやかされるようになりました。この機能強化により、ユーザーが複数のアプリを切り替えるときにアプリのコンテンツが表示されないようにするための安全対策が施され、同様の状況で動作する多くの銀行アプリや財務アプリと動作方法が一致します。

パフォーマンスおよび可用性

Vault コンポーネントを Raw オブジェクトに移行

より良い設定レポート、比較レポートや VPK の生成をサポートするため、Vault コンポーネント (vault_component__v) オブジェクトを Raw オブジェクトへと変更しました。これにより、このオブジェクトの使用時の操作パフォーマンスが向上します。

Document Usage オブジェクトが Raw オブジェクトへ移行

このリリースでは、Document Usage (document_usage__v) オブジェクトが標準容量オブジェクトから Raw オブジェクトへ移行することで、スケーラビリティのパフォーマンスが向上します。

Document Usage オブジェクトでは、定常状態のドキュメントに対する次の各アクションが自動的に追跡されます。

• View
• Download Source
• Download Rendition
• Make a Copy

Document Usage 向けに作成されるレコードは数百万件に達することがあるので、このオブジェクトが Raw オブジェクトに移行することでパフォーマンスの安定性が向上します。これは Raw オブジェクトなので、Document Usage レコードに適用するフィルタでは大文字と小文字を区別して使用する必要があります。Contains 演算子を使用しているレポートでは、大文字と小文字を適切に使い分けることをお勧めします。

また、Business Admin メニューに Document Usage オブジェクトが表示される場合、検索バーでは Name フィールドのみが検索範囲になります。アクセス権を持つユーザーは、検索バーではなく以下のフィールドでフィルタを使用する必要があります。

Document Usage オブジェクトと Raw オブジェクトの詳細をご覧ください。

マイナー変更

このセクションの項目は、Vault Platform に加えられた軽微な機能強化を示します。

Collaborative Authoring での XLSM ファイルのサポート

Collaborative Authoring で XLSM ファイルを編集できるようになりました。これまで Collaborative Authoring では XLS ファイルの編集はサポートされていましたが、Collaborative Authoring の導入当初は Sharepoint で XLSM がサポートされていませんでした。

この機能強化によりユーザは、XLSM ファイルを他のドキュメントと分けて編集管理する必要なく、マクロを含むスプレッドシートを共同編集できるようになりました。

詳細については、Collaborative Authoring をご覧ください。

Link Target オブジェクトへの注釈 ID の追加

Link Target 作成のインテグレーションをサポートするため、Link Target オブジェクトに新しく Annotation ID フィールドが追加されました。オブジェクトの作成時または更新時にこのフィールドに入力すると、自動的に Anchor ID、Anchor Title、Anchor Page、および Reference が設定されます。これにより、特定の Anchor ID を把握していなくても、この Anchor ID を更新することで、インテグレーションによりアンカーの Link Target を作成および更新することが可能です。

Link Target は Platform オブジェクトの一種であり、今回新たに実装されたフィールドはすべての Vault の Link Target オブジェクトに表示されます。ただし、Link Target は、主に Commercial Vault において Text Asset の管理に使用されます。

この機能の詳細については、開発者向け機能をご覧ください。

Linked Documents の使いやすさの改善

24R3 より前では、リンク注釈を削除しても、Enable Create & Import Document Linksから管理者フラグの選択を解除しない限り、Linked Document 関係は自動的に削除されませんでした。今回の更新により、注釈が削除されると、フラグのステータスに関係なく Linked Document 関係も自動的に削除されるようになりました。

また、Enable Create & Import Document Links を選択している場合、Linked Documents セクションでは特定のリンク属性 (アンカー名やページなど) および実行可能なアクションのみがユーザに表示されます。今回の更新により、上記の詳細情報とアクションがフラグ設定に関係なく常時表示されるようになりました。

Vault File Manager: ファイルステージングダウンロードの改善

Vault File Manager を使用してファイルステージングからコンテンツをダウンロードする際に、管理者は、ファイルパスが長くなると発生する可能性のある潜在的な問題を軽減する 2 つの変更点を確認できます。

まず、ファイルパスが Windows の最大値よりも長い場合、ステータスにカーソルを合わせると、Vault File Manager に新しいツールチップが表示されます。24R3 より前は、ステータスにカーソルを合わせると、ファイルパスの長さが対処すべき問題であることを具体的に示すのではなく、完全なファイルパスを表示しようとしていました。24R3 以降では、ステータスにカーソルを合わせると次の内容が表示されます。

次に、Vault File Manager は、Windows のファイルパス制限に達する可能性が低くなるように、フォルダのダウンロード時にフォルダ名に短い命名規則を使用します。24R3 より前の形式は、VaultID_{VaultID}__File_Staging_Download__{Datestamp} でした。24R3 以降、形式は {VaultID}_VFM_{Datestamp} になります。たとえば、VaultID_1000008_File_Staging_Download 2024-05-14 16-54-29-485 は、24R3 以降は 1000008_VFM_24-05-14 16-54-29-485 に短縮されます (文字数が 61 から 35 に削減されます)。

Windows ではファイルパスの長さに 256 文字の標準制限がありますが、これらの機能強化により、ダウンロードがこの制限を超える可能性が低くなります。また、ファイルパスの長さを超過した場合にユーザーに明確な情報が提供されるようになります。

Vault File Manager を使用してファイルステージングを操作する方法の詳細をご覧ください。

CrossLink ドキュメントのソース Vault 名を常に表示

ユーザは CrossLinks を利用する際に、ソース Vault へのアクセス権の有無に関係なく、CrossLink のメタデータ上で常にソース Vault 名 (ドメイン名を含む) を確認できるようになりました。旧リリースでは、Crosslink を閲覧しているユーザが目的のドキュメントのソース Vault へのアクセス権を持っていない場合、Crosslink ドキュメントのソース Vault 名は非表示になっていました。この変更により、Vault のパフォーマンスが向上します。

リーガルホールド検索ダイアログ: ユーザインターフェースの更新

Vault 上の他のダイアログボックスとの一貫性を高めるため、Apply Legal Hold または Edit Legal Hold の使用時に表示されるダイアログボックスのユーザインターフェースが若干更新されました。*Legal Hold が有効に設定されている Vault で自動的にオンになります。

「Change Related Object Lifecycle State」アクションでの Specific Document Version フィールドのサポート

ドキュメント参照フィールドがあるオブジェクトでは、ドキュメントライフサイクルに Change Related Object Lifecycle State エントリアクションを適用すると、ドキュメントの状態が変化した際に該当する各オブジェクトレコードの状態を自動的に変更できます。ただし旧リリースでは、このエントリアクションを設定できるのは、オブジェクトで最新バージョンとして設定されたドキュメント参照フィールドのみでした。24R3 ではこの機能が拡張され、特定のバージョンにも設定できるようになりました。

たとえば、あるドキュメントの最新バージョンが「Draft」状態にあり、Steady State バージョンがまだ「Approved」状態のままになっているとします。この状況で、あるオブジェクト内に、承認済みのドキュメントバージョン v1.0 を指定するドキュメント参照フィールドがあるとします。Draft 状態にあった新しいドキュメントバージョンが Approved に変わると、v1.0 が Superseded 状態になります。あるユーザは、この変更に対応してオブジェクトレコードを「Update Document」状態に移行させ、そのレコードのワークフローを自動的に開始し、担当者によるレビューを促したいとします。今回 Specific Version ドキュメント参照フィールドがサポートされたことにより、この例のような用途が可能になりました。

レコード移行モードの機能強化

レコード移行機能を向上させるため、レコード移行モードが強化され、レコードの作成と更新をより詳細に制御できるようになりました。

レコード移行モードを有効にすると、各種システムフィールド (ID、Created By、Created Date、Modified By、Modified Date) の設定が許可され、すべてのルールを迂回しますが、例外として次のルールが適用されます。

• 各フィールドは適切なデータタイプ (文字列、数値、日付など) と照らし合わせて検証されます。
• オブジェクトタイプとオブジェクトタイプフィールドが適用されます。
• ライフサイクル状態は指定必須ですが、アクティブまたは非アクティブのいずれでも可です。状態または状態タイプが指定されていない場合は、初期状態のレコードが作成されます。
• レコードの ID 設定はレコード作成時に行えますが、レコード更新時には行えません。

No Triggers 設定が新たに導入されました。Yes に設定すると、レコード移行モードの使用時にシステムトリガー、標準トリガーおよびカスタムトリガーがすべて迂回されます。 

これらのヘッダーは、移行モード権限を持つユーザのみ使用できます。

詳細については、レコード移行モードをご覧ください。

Email to Vault: メールサイズ制限の引き上げ

Email to Vault 機能を使用する際、Vault は、以前は 30 MB であった上限を引き上げて、最大 40 MB のサイズのメールをサポートするようになりました。24R3 より前は、メールが 30 ～ 40 MB の場合、Vault は Bounced 状態のメールレコードを作成していました。40 MB を超えるメールの場合、メールは Vault によって処理されず、AWS から送信者にバウンスメールが送信されていました。

この機能強化により、40 MB までのメールは Vault によって適切に処理され、サイズが原因でバウンスされなくなりました。メールが 40 MB のサイズ制限を超える場合、動作に変更はありません (Vault にメールレコードは作成されず、AWS から送信者にバウンスメールが送信されます)。

Vault へのメール の詳細をご覧ください。

3 か月後に通知をアーカイブ

エンドユーザが使用する All Notifications ページ、および管理者が使用する Email Notification Status ページに、過去 2 年間の通知ではなく過去 3 か月間の通知が表示されるようになりました。 

この機能強化により、エンドユーザ (All Notifications ページ) および管理者 (Email Notification Status ページ) 両方にとって、Vault ユーザインターフェースのパフォーマンスが最適化されます。管理者は引き続き Email Notification Status ページにある Export Full History オプションを使用して、すべての通知履歴にアクセスできます。

詳細については、Email Notification Status ページをご覧ください。この機能の詳細については、開発者向け機能をご覧ください。

マルチパスワークフローレポートでのタスクの除外

ワークフローレポートビューを含むマルチパスレポートを使用する際に、レポートに Task 列が含まれている場合、またはマルチパスレポートタイプでビューを結合するために Task 列が使用されている場合にのみ、Vault ではワークフローごとに複数の行が表示されるようになりました。

24R3 より前は、レポートでタスク関連の情報が使用されていない場合でも、Vault は常に各ワークフロー内の各タスクの行を作成していました。これにより、重複した行があるように見えるため、ユーザーの混乱を招いていました。この機能強化により、重複行に気を取られることがなく、ユーザーにとってよりわかりやすいレポートが提供されるようになります。

マルチパスレポート機能の詳細をご覧ください。

レポート構成移行の機能強化

構成移行パッケージを利用して環境間でレポートを移行する場合、レコード ID (id) ではなく Name (name__v) 値が使用されるようになりました。これにより、レポート移行時によくある問題に関して Vault から明確なメッセージが提供され、潜在的なエラーが減少します。

この変更により、オブジェクトレコードが移行先システム内に存在する一方で移行元システムと同一のレコード ID (id) を持たない場合でも、エラーが発生したり、フィルタが空白になることはなくなります。代わりにシステムは、目的のオブジェクトレコードの Name (name__v) を使用してリンクを確立します。

非固有オブジェクトへの参照を含むレポートを展開する場合は、選択された値を展開後に確定する必要があります。

詳細については、構成移行をご覧ください。この機能の詳細については、開発者向け機能をご覧ください。

予測可能なレポート幅

24R3 より前は、レポートの幅は 1 行あたり 21,884 文字に制限されており、この制限は実行時にのみ適用されました。そのため、レポートを作成するユーザは、制限に達したかどうかを確認するためにレポートを実行しなければならず、どのように変更すれば制限範囲内に収まるかが簡単にはわからなかったため、試行錯誤するケースが見受けられました。

今回のリリースから、レポートの幅は列の数によって制限されるようになります。レポートには最大 100 列を含めることができます。この変更により、レポートに大量のデータを取り込む機能を維持したまま、作成者や編集者が今までより簡単にレポートを管理できるようになります。 

21,884 文字の文字数制限は超えていないものの、列数が 100 列を超えているレポートがすでに存在する場合、それらのレポートはそのまま機能しますが、新しいレポートは文字数ではなく列数によって制限されます。

詳細については、レポートの作成をご覧ください。

Vault からのログアウト時に VeevaID セッションを終了

VeevaID ユーザが Vault からのログアウト操作を行った場合、Vault と VeevaID の両方からログアウトするようになりました。この機能強化により、VeevaID ユーザの混乱が軽減されます。

パスワードリセット時の強制パスワード検証

ユーザが新しいパスワードを入力したときに、パスワードが検証され、サポートされていない文字が含まれている場合はエラーが返されるようになりました。また、エラーメッセージ内に、以下のサポート対象文字も一覧表示されるようになりました。

Vault のパスワードに使用できるのは、標準文字 (A ～ Z、a ～ z)、数字 (0 ～ 9)、スペース記号、および次の特殊文字のみです: !“ # $ % & ‘ ( ) * + , - ./ : ; < = > ?@ [ \ ] ^ _ ` { | } \ ~ .アクセント付き文字 (é、ñ、ü など) や、その他の ASCII 文字以外の文字は使用できません。

24R3 より前のバージョンの Vault では、サポートされていない文字を含んでいても新規パスワードを保存でき、ユーザがその新規パスワードの使用を試みた時点で検証を強制実行していました。

この機能強化により、上記エラーがより積極的に検証され、ユーザの混乱が軽減されます。この機能強化は、ユーザが Vault ログインページまたは自身のユーザプロファイルからパスワードをリセットする場合に適用されます。

Vault とドメイン情報に関する管理者用 About タブ

管理者向けの About タブが新たに追加されました。この新しいホームぺージでは、Vault とドメイン情報を閲覧できます。この各種情報は、以前は Settings タブの General Settings ページにありました。About タブには、Settings タブにある設定可能なオプションとは別に、ライセンスや API、データ使用量情報などの設定不可の情報が記載されています。

ジョブの Vault Time 表示

ジョブ操作が、常に Vault タイムゾーン (通称 Vault Time) で表示および保存されるようになりました。実行時刻を選択する Vault Time フィールドの下に、ユーザの選択したタイムゾーンに対応する時刻が表示されます。この機能により、Admin > Settings > Language & Region Settings > Vault Information で定義した Vault Time がすべてのバックグラウンド操作に適用されるため、混乱が軽減され一貫性が向上します。

この機能の詳細については、開発者向け機能をご覧ください。

Vault Loader のアクションのシステム監査を削除

Vault Loader のイベントはシステム監査履歴に記録されなくなりました。オブジェクトレコードとドキュメントへの対応する更新はそれぞれ、オブジェクトレコード監査履歴と文書監査履歴に記録されます。

VQL での日付リテラルのサポート

VQL 式で日付リテラルがサポートされるようになりました。VQL クエリで Date 値または DateTime 値を入力する代わりに、TODAY、THIS_MONTH や DAYS_AGO:n などのリテラルを指定できます。 

詳細については、開発者ポータルの「VQL 日付リテラル」をご覧ください。

Sandbox Vault ページでのリリース警告

インフラストラクチャリリースイベントの進行中、Sandbox Vault ページでユーザーに警告 (UI アラート) が表示されます。このメッセージは、バックエンドのメンテナンスによって Sandbox のパフォーマンスが低下する可能性があるが、他の機能は影響を受けないことをユーザーに警告するものです。

Vault Java SDK への Java 17 の適用: 任意の有効化オプション

開発者が Java 新バージョンに伴うアップグレードを最大限に活用できるよう、次回以降の数回のリリースで Vault Java SDK が Java 17 にアップグレードされます。Java 17 には新しい機能が導入されているほか、Java 8 以上にパフォーマンスおよび効率を改善させる最適化が備わっているため、リソース使用量が削減されます。

今回のリリースでは、開発者と管理者は任意で Vault Java SDK への Java 17 適用を有効化し、新しい Java バージョンとカスタムコードとの互換性をテストできます。

Vault Loader CLI Java 17 のサポート

Vault Loader CLI の最新バージョンを使用するには、開発者は環境で Java 17 が利用可能であることを確認する必要があります。開発者は、Java 8 で古いバージョンの Vault Loader CLI を引き続き使用できます。

Scheduled Data Export のオブジェクト上限

現在 SDE を使用していない Vault では、Scheduled Data Export (SDE) のオブジェクト上限数 30 が適用されます。現在 Scheduled Data Export を実行している既存の Vault では、これまでどおりの動作が維持されます。

User Exception Message および User Exception Item の監査証跡を無効化

User Exceptions Message (UEM) オブジェクトと User Exception Item (UEI) オブジェクトのレコード変更は、監査証跡に含まれなくなりました。これらのオブジェクトは、統合管理を支援するための情報提供の目的で使用されます。

HTTP サービスに対するクライアント認証情報のサポート

Vault では、Client Credentials (client_crendentials__sys) タイプのレコードを作成できるようになりました。このレコードには、クライアント ID と暗号化されたクライアントシークレットを保存できます。以前は、ユーザーは Basic Authentication (basic_auth__sys) タイプの Connection Authorization レコードのみを作成できました。開発者は、Vault Java SDK でこれらの値を HTTP サービスと共に使用できます。

24R3 Platform データモデルの変更

24R3 Platform データモデルの変更をご覧ください。

Vault Connections

Clinical Operations と EDC の接続

Clinical Operations と EDC の接続: CDMS への Protocol Deviations リンク

この機能により、Clinical Operations と EDC の接続によって管理されるプロトコール逸脱については、Vault CTMS の Protocol Deviations に標準リンクフィールドが導入され、Vault EDC の Protocol Deviations レビューページに直接移動できるようになります。このリンクを使用すると、Vault CTMS で問題を確認する際に、ソースのプロトコール逸脱にすばやく簡単に移動できます。これは、被験者および被験者来院に Casebook Link が使用される方法に似ています。その他の新しい Clinical Operations の機能については、以下をご覧ください。

Clinical Operations と EDC: プロトコール逸脱の EDC ID を表示

Clinical Operations と EDC の接続において、プロトコール逸脱に EDC ID (edc_id__v) フィールドが追加されました。この新しいフィールドにはソースレコードのプロトコール逸脱に対応した EDC ID が表示されるため、ユーザはデータの閲覧や抽出、レポート作成を行う際に、Clinical Operations Vault から直接 EDC 上のソースレコードをすばやく識別できるようになりました。その他の新しい Clinical Operations の機能については、以下をご覧ください。

Clinical Operations と eCOA の接続

Clinical Operations のライフサイクル状態転送の強化

この機能により、Clinical Operations と eCOA の接続が強化され、標準およびカスタム治験、治験実施国、治験実施施設のライフサイクル状態が自動的に転送されるようになります。Clinical Operations と eCOA に加わったその他の新機能については、以下をご覧ください。

RIM と PromoMats の接続

RIM と PromoMats: 製品データの転送

製品および Registration 関連データレコードについて信頼できる唯一の情報源をさらにサポートするため、RIM Vault と PromoMats Vault 間に新たなインテグレーションが追加され、Regulatory と Commercial を使用する各ビジネスチーム間で必要な製品および登録情報の転送が可能になります。ブランド (商標名) 情報は、PromoMats Vault から RIM Vault 内の Regulatory Text オブジェクトへと転送されます。新しいインテグレーションでは、適応症も RIM から PromoMats に転送されます。

Brand レコードは PromoMats で作成および管理され、接続時に Drug Trade Name および Device Trade Name の各オブジェクトタイプの RIM 内で Regulatory Text オブジェクトに入力する際のソースとして使用されます。RIM Vault は引き続き、Commercial 内のビジネスプロセスに必要なその他すべての製品関連データおよび登録データに関して、信頼できるデータソースとして機能します。PromoMats データモデルが更新され、RIM 内のソースデータと同期されるオブジェクトおよびオブジェクト関係が新たに 10 個追加されました。各インテグレーションの概要は以下のとおりです。

インテグレーション	RIM オブジェクト	PromoMats オブジェクト	データ転送方向
Product	Product Family、Product、Product Family Product、Product Variant、Product Component、Packaging	Product Family、Product Form、Product Family Product Form、Product Variant、Product Component、Packaging	RIM > PromoMats
Therapeutic Indication	Therapeutic Indication	Indication	RIM > PromoMats
ブランド (商標名)	Regulatory Text (オブジェクトタイプ: Drug Trade Name、Device Trade Name)	Brand	PromoMats > RIM
登録	Registration、Registered、Regulatory Text、Registered Packaged、Medicinal Product、Registered Indication	Registration、Registered Brand、Registered Packaged Product、Registered Indication	RIM > PromoMats

新しく追加されたオブジェクト (詳細については、RIM と PromoMats の「データモデルの更新」を参照してください)

Regulatory と Commercial に加わったその他の新機能については、以下をご覧ください。

RIM と Clinical Operations の接続

RIM と Clinical Operations: Clinical Crosslink での治験のデフォルト設定ロジックを強化

RIM から Clinical Operations Vault にドキュメントを相互リンクする場合、接続によって RIM に Study が作成されていない場合 (link__sys フィールドが空白) でも、接続ではソースドキュメントの臨床 Study レコードが考慮され、Clinical Operations Vault 内の Study レコードとの照合が試行されるようになりました。接続の以前のクロスリンクロジックでは、RIM のソースドキュメントの Study レコードが Clinical の Study レコードにマップされていない場合 (link__sys フィールドに基づく)、それらのレコードは無視されます。この機能強化により、Clinical Operations Vault 内の Study レコードにマッピングできない Study レコードが、ソースドキュメントに含まれている場合、接続によってエラーメッセージが表示されます。Regulatory と Clinical Operations に加わったその他の新機能については、以下をご覧ください。

RIM と Clinical Operations: Clinical Study フィールドルールの更新

24R3 では、Vault Clinical Operations に 3 つの新しい標準フィールド: Type of Control、Study Type、および Study Subtype が追加されました。これらのフィールドは Vault RIM にすでに存在しており、お客様は RIM に情報を手動で入力するか、カスタムフィールドルールを作成しています。Vault Clinical Operations にこれらの標準フィールドが追加されたことにより、RIM と Clinical Operations の接続では、これらのフィールド値を Vault RIM に転送できるようにするための新しい標準フィールドルールが追加されました。この機能強化により、これらの値を手動で入力する必要がなくなるため、生産性とデータの整合性が向上します。Regulatory と Clinical Operations に加わったその他の新機能については、以下をご覧ください。

RIM と Clinical Operations: EU 固有の Clinical CrossLink の処理

RIM から Clinical Operations Vault にドキュメントを相互リンクする場合、ソースドキュメントの Country が European Union と指定されている場合、接続では Jurisdiction = European Union に基づいて Clinical Operations Vault 内の Study Countries にマッピングされます。Vault Clinical Operations 内で European Union は Country の値として認識されないため、現状の接続時クロスリンクロジックではクロスリンクを作成できません。今回の機能強化により、クロスリンクしたドキュメントが Vault Clinical Operations 内で確実に作成されるようになります。この機能を利用するには、Clinical Operations Vault 内でシンプルジョインオブジェクト Jurisdiction Country を使用して、欧州連合 Jurisdiction に Countries をマッピングする必要があります。Regulatory と Clinical Operations に加わったその他の新機能については、以下をご覧ください。

Safety と Clinical Operations の接続

Safety と Clinical Operations の接続: CRO のサポート

このリリースでは、Safety と Clinical Operations の接続が治験ごとに複数のスポンサー組織をサポートするようになり、開発業務委託機関 (CRO) が接続を利用できるようになりました。ユーザーが Clinical Operations Vault で Study レコードまたは Study Country レコードを作成または編集すると、接続により、Safety Vault で Study レコードまたは Study Registration レコードが作成または更新されます。CRO ユーザーは、Veeva Site Connect を使用して安全性レターを配布することもできます。

詳細については、Safety と Clinical Operations の接続の CRO サポートの設定をご覧ください。

Safety と EDC の接続

Safety と EDC の接続: SAE 報告者の詳細を Safety に送信

このリリースでは、Safety と EDC の接続を通じて SAE 報告者の連絡先情報が Vault Safety に転送されます。この機能強化により、Safety ユーザーと報告者間の直接的なコミュニケーションが容易になり、SAE に関する質問を明確化できるため、トリアージと処理の時間が短縮されます。EDC 管理者は、報告者の詳細を Adverse Event フォームに直接マッピングできます。今後のリリースでは、EDC Vault は、SAE を Vault Safety に送信する際に報告者の詳細を自動的に設定するためのサイト情報のデフォルト設定をサポートする予定です。

詳細については、Vault で Safety と EDC の接続を使用して SAE 報告者の詳細を Vault Safety へ送信するよう設定する方法をご覧ください。

Safety と EDC の接続: Vault Safety での複数の EDC への接続

このリリースにより、Vault Safety で、Safety-EDC Vault Connection を介した複数の EDC Vault への接続がサポートされるようになりました。管理者は、新しく追加された Copy to New アクションを使用して、各 EDC Vault インスタンスに対して Safety と EDC の接続を作成および設定できます。この機能強化により、複数の EDC Vault を持つユーザは、同じ接続を介して SAE データを Vault Safety へとシームレスに転送できるようになります。

詳細については、複数の EDC Vault 接続の確立をご覧ください。

Safety と EDC の接続: 新しいフィールド & エラー メッセージ

このリリースでは、EDC Vault と Safety Vault 間で転送されるデータが拡張され、Safety と EDC の Vault Connection が強化されました。これにより組織では、Case Adverse Events の Highlighted Term と Severity、および各 Case の Site Narrative を含め、さらに多くのフィールド値を自動転送できるようになりました。また、Safety Vault でカスタムフィールドが抜けている場合は明確なエラーメッセージによって具体的な問題が示され、管理者に設定を更新するよう促します。

詳細については、Safety と EDC の接続をご覧ください。

Safety と RIM の接続

Safety と RIM の接続強化

Safety と RIM の Vault Connection により、RIM から Safety への製品データマッピングが強化されました。RIM のオブジェクトタイプ Marketed Drug Product Registration および Marketed Device Product Registration は、Vault Safety で RIM Registration Type の適切な選択リスト値を指定するようになりました。RIM のオブジェクトタイプ Medical Device Product は、Vault Safety で オブジェクトタイプ Device Product を指定するようになりました。このような機能強化により、製品のデバイスタイプがより確実にサポートされ、RIM の製品および登録データモデルと正確に一致するようになりました。

詳細については、Safety と RIM の接続をご覧ください。

Clinical Operations

以下のリリースノートに加えて、Vault CTMS、Vault eTMF、Veeva Site Connect、Vault Study Startup、および Vault Study Training Veeva Connect コミュニティでは、General Release に関するお知らせ、リリースの注目機能、主要な機能のデモが提供されています。

Vault Connections セクションに記載されている以下の機能も、Clinical Operations アプリケーションファミリーに影響を与えます。

• Clinical Operations と EDC の接続: CDMS への Protocol Deviations リンク
• Clinical Operations と EDC: プロトコール逸脱の EDC ID を表示
• RIM と Clinical Operations: Clinical Crosslink での治験のデフォルト設定ロジックを強化
• RIM と Clinical Operations: Clinical Study フィールドルールの更新
• RIM と Clinical Operations: EU 固有の Clinical CrossLink の処理
• Safety と Clinical Operations の接続: CRO のサポート

Clinical Operations の全アプリケーション

Clinical ドキュメントの Document Deletion Log

新しいドキュメントアクション Delete Document with Reason を使用すると、ユーザは Document Deletion Log の作成と、システムからのドキュメントバージョン削除を同時に実行できます。Deletion Log は、Deletion Reason と任意の Deletion Comments、および削除したドキュメントのメタデータセットを追跡します。Deletion Log には、削除したドキュメントのコピーや監査証跡は保持されません。削除したドキュメントバージョンとの関係が紐づけられている Quality Issue はすべて削除され、その Quality Issue の Related Document フィールドは null に変更されます。透明性維持のため、Quality Issue レコードは Related Document Deletion の詳細情報を自動的に参照します。

ドキュメント削除ログを有効化するには、元に戻すことのできない一方向機能フラグが必要であるとともに、Disable Document Requiredness on Quality Issues 設定が有効になっている必要があります。

EDL アイテムで予想される数の自動管理

この機能により、エクスペクテッドドキュメントにおいて # Expected を一致したドキュメントの合計数と同期させるかどうかを項目ごとに導入することで、Update Requiredness, # Expected Based on EDL Matchings 機能に柔軟性がもたらされます。エクスペクテッドドキュメントとテンプレートエクスペクテッドドキュメントの新しいチェックボックスフィールドである Auto-Manage # Expected (automanage_expected__v) によって、各エクスペクテッドドキュメントの更新動作が決まります。このフィールドは、テンプレートレベルで設定でき、新しい Update Auto-Manage # Expected システムアクションを活用して治験ごとに管理できます。このフィールドのデフォルト値は false であり、この機能を活用するには設定の更新が必要です。有効にすると、エンドユーザーは # Expected フィールドを手動で変更できなくなります。

Veeva Standard Library Questions

この機能により、Veeva Standard Library Questions と Available Answers がすべての Clinical Operations Vault に導入されます。これらの Standard Library Questions と Available Answers は、施設フィージビリティ調査において参照できます。Standard Library Questions は、Veeva Standard Questions と再利用可能な回答機能もサポートしています。

Standard Library Question および Available Answer レコードをお客様側で編集することはできません。

Clinical Subartifacts

Clinical Subartifacts を使用すると、標準の Subartifact ドキュメントフィールドでドキュメントの Classification をさらに細かく設定でき、TMF Reference Model の subartifact で個別に Classification を指定する必要性がなくなります。この新しい Subartifact オブジェクトは、Document Type Details フィールドを通じて親 Classification を定義します。関係を確立することで、ドキュメントアップロード時に適用された Classification に基づいて Subartifact フィールドがフィルタリングされます。この新しいドキュメントメタデータはレポートで利用可能であり、TMF ビューアでは列フィルタリングがサポートされています。

Clinical Subartifacts がデータの完全性追跡を確実にサポートするため、EDL 項目マッチング機能が拡張され、Subartifacts に基づくマッチングをサポートするようになりました。EDL 項目には、subartifact を定義するための Subartifact フィールドが新たに追加されました。この値を入力すると、その EDL 項目が、Classification 値と Subartifact 値の両方およびその他適用されている照合基準に一致するドキュメントにマッチングされます。

Clinical Subartifacts データモデルは自動的にオンになりますが、ドキュメントと EDL アイテムで Subartifacts を使用開始するには設定を行う必要があります。

CTMS

CTMS Transfer の機能拡張: Subjects & Subject Groups

昨今、臨床試験ではますます複雑な試験デザインが採用されるようになり、治験依頼者から開発業務委託機関 (CRO) へと委託される複雑な治験の数も増えています。この傾向により必要となるのが、CRO と治験依頼者間で被験者データの転送を行える効率的かつシームレスなソリューションです。このようなソリューションにより、複雑な治験の包括的監視、さらには治験依頼者による被験者グループ登録のより詳細な精査や、プロトコール逸脱に関連する被験者の詳細把握が可能になります。

このような需要の増加に応えるために、今回 CTMS Transfer 機能が拡張されてオブジェクトタイプ Subjects および Subject Group が新たに加わり、ユーザが CRO の Vault から治験依頼者の Vault へとレコードを転送できるようになりました。さらに、新しい各オブジェクトタイプは CRO 側のソース Vault 内の Outbound Clinical Mappings UI で使用できるため、CRO は必要に応じてカスタム値をマッピングできます。

この機能強化により、外部委託モデルで作業する組織は複雑な臨床試験データをより効率的かつ正確に管理・転送できるようになり、臨床研究プラクティスの継続的な進化を促進できます。

日本の治験届 (CTN) 機能を Vault アプリケーション設定から削除

日本の治験届機能を有効にするには、導入のためのリソースとサポートを適切に監視するために Veeva サポートが必要になりました。

CTMS Transfer の移行モードの変更

治験依頼者と CRO 間の Vault 構成の不一致に起因する問題に対処するため、CTMS Transfer に重要な改善が加えられました。以前は、これらの Vault 構成の違いから転送が失敗するケースがよくありましたが、双方を完全に一致させるのは難題であり、またそうすると治験依頼者のビジネスプロセスに影響を及ぼす可能性もありました。今回導入された CTMS Transfer の機能強化により、CRO と治験依頼者間の Vault 構成の不一致が原因で転送が失敗する可能性は減少し、より信頼性の高い転送が保証されます。

転送先の治験依頼者 Vault で、あるオブジェクトタイプが無効になっている場合、CTMS Transfer の実行時にレコードが作成および更新されるようになりました。さらに、治験依頼者 Vault の必須フィールドが CRO Vault で空白のままになっている場合でも、レコードが正常に作成および更新されます。最後に、治験依頼者のエントリアクション、エントリ条件、およびイベントアクションは転送中に無視され、意図しないトリガーが防止されます。

Disclosures

Vault Disclosures の紹介

Vault Disclosures は、臨床試験の開示管理を一元化および合理化するために設計された包括的な製品です。データの事前入力と高度な自動化機能を備えた Vault Disclosures は、レジストリ登録を迅速化し、世界中の規制要件の遵守を向上させます。

今日のますます複雑化する規制環境において、臨床試験の開示を管理することはこれまで以上に困難になっています。Vault Disclosures は、組織が規制の複雑さを乗り越え、データの品質と正確性を確保し、異なるシステムやスプレッドシートの使用による非効率性を排除できるようにすることで、主要な課題に直接対処します。

Vault Disclosures は、開示コンテンツの作成、レビュー、承認などのすべての開示活動を一元化することで、臨床試験の開示管理を変革します。データやドキュメントの再利用によって効率を高めます。さらに、事前設定されたルール、世界各国のカントリーインテリジェンス、レジストリ更新の自動アラートを活用して、提出スケジュールを短縮し、より迅速でエラーのない提出を保証します。

Vault Disclosures の独自の利点は、Vault Clinical Operations Platform と統合されているためサードパーティの統合や手動プロセスが必要ないということです。そのセルフサービス構成により、特定の治験や組織のニーズに柔軟に対応できます。また、レポートとダッシュボードから、グローバルな提出ステータスや活動の進捗状況に関する実用的な洞察が得られるため、潜在的な問題を早期に特定して解決できます。

Vault Disclosures は、大手の治験依頼者から小規模なバイオテクノロジー企業や CRO まで、どのような規模の組織でも利用できるようにカスタマイズされており、臨床試験の多様な開示ニーズを満たす拡張性と適応性に優れたソリューションを提供します。この製品は、Vault CTMS のアドオンとして購入できます。

詳細については、Vault Disclosures をご覧ください。

Vault Payments

複雑な治験: 支払

複雑な治験の支援機能が強化され、Vault Payments がサポートされるようになりました。旧リリースでは、Payable Item の作成時に Fee の照合基準として使用できたのは Arms のみでした。今回のリリースでは、Visit Fee と Procedure Fee の両方の照合基準が拡張され、すべての Subject Group オブジェクトタイプ (Arm、Study Cohort、Substudy、Study Part および Study Element) がサポートされるようになりました。1 つの Fee に 1 つ以上の Subject Group が含まれている場合は、指定されたすべての Subject Groups に基づいてマッチングが実行されます (たとえば、1 つの Fee に Arm と Study Cohort が含まれている場合は、 Arm および Study Cohort に属する Subjects の Visits/Procedures のみが合致します)。 

Rate の基準が拡張され、Subject Group 指標をサポートするようになりました。Rate 基準は、特定の Rate Metric 内に含まれる被験者 (たとえば、登録済みステータスの被験者) の数に基づき、Vault が生成する Payable Items の数を制限します。Rate Subject Group を指定した場合は、それに対応する Subject Group Metric (たとえば、治験群 A 内で登録済みステータスの被験者など) が使用されます。Rate Subject Group 照合基準を使用するには、Subject Group に Enrollment Metrics が作成されている必要があります。 

支払の自動調整機能が強化され、Subjects の Subject Group 値への変更がサポートされるようになりました。Fee 照合基準に影響する Subject Group フィールドや Subject Group Metrics が変更された場合、関連する Payable Items の評価がトリガーされます。調整が実行された場合、Vault 上では Payable Item が Inactive としてマークされるか、あるいはすでに支払われた項目と未払いの項目を反映する Adjustment Payable Item が作成されます。 

詳細については、支払の自動調整と Rate 基準をご覧ください。

Fee Schedule 承認の自動化

この機能は、Fee Schedule の修正に対する承認プロセスを簡素化します。旧リリースでは、ユーザは新しいバージョンの Fee Schedule を承認する前に、既存の Fee Schedule に End Date を適用する必要がありました。この作業は一般に、個別のプロセスで行われていました。今回のリリースで Fee Schedule ライフサイクルに追加された新しいアクションを使用すると、ユーザは新規 Fee Schedule に対する承認プロセスの一部として、既存の関連 Fee Schedule に加えられた更新をレビューおよび承認できるため、時間が節約されるほか、エラーと手動で行う手順を削減できます。関連 Fee Schedule とは、承認済みのライフサイクル状態にあり、Study Site 値とPrimary Organization 値がマッチしている Fee Schedule を指します。 

ユーザが Fee Schedule の承認を自動化するアクションを実行すると、既存の関連 Fee Schedule に対する以下のような更新が提案されます。

• 次の新規 Fee Schedule で、対応する既存の Fee Schedule に End Date を自動適用する。
• 前の新規 Fee Schedule で、対応する既存の Fee Schedule に Start Date を自動適用する。
• 既存の Fee Schedule の日付範囲が Start/End Dates によって無効化または置き換えられる場合、既存の Fee Schedule を Superseded として自動的に設定する。

単一の更新を行う場合、ユーザは変更処理を実行して新規 Fee Schedule を承認する前に、システムにより提案された変更内容を確認するよう求められます。この追加の自動化機能は、ワークフローに組み込むことができます。また、一括アクションとして有効化して複数の Fee Schedule を更新することも可能です。

支払調整: Superseded 状態の Fee Schedule

この機能により、Superseded 状態の Fee Schedule がサポートされるようになりました。旧リリースの Vault では、Payable Items の生成および調整時には、ライフサイクル状態が Approved になっている Fee Schedule のみが考慮されていました。今回のリリースにより、Payable Items の生成および調整時にライフサイクル状態が Superseded の Fee Schedule も考慮されるようになりました。Payable Items が存在し、Approved 状態の Fee Schedule と Superseded 状態の Fee Schedule 間で Fees が同一である場合、アクションは実行されません。差異がある場合、Vault 上では Payable Item を調整し、Inactive としてマークされるか、あるいは Approved 状態の Fee Schedule に基づいてすでに支払われた項目と未払いの項目を反映する Adjustment Payable Item が作成されます。

上限引き下げ時の支払調整

支払の自動調整機能で、Maximum Count の上限引き下げがサポートされるようになりました。たとえば、Maximum Count が (4 から 3 になど) 引き下げられた場合、その引き下げに応じて Payable Items が調整されます。

詳細については、支払の自動調整をご覧ください。

Payable Event Date

今回新たに Payable Event Date (payable_event_date__v) フィールドが追加されました。このフィールドは、関連する Payable Event (Visit Date、Procedure Date や Site Fee Date など) に基づいて自動入力されます。Additional Fees の Payable Event Date は、ユーザが手動入力できます。

eTMF

多言語モデル

臨床試験は世界規模で行われ、TMF ドキュメントの大部分は英語以外の言語で記述されるため、スポンサーや CRO の TMF ドキュメントの 50% 以上が英語以外の言語で記述されていることは珍しくありません。これまで、TMF Bot は英語のテキストを含むドキュメントのみをトレーニングし、自動分類することができました。

TMF Bot の適用範囲を大幅に拡大するために、多言語モデル機能を導入しています。この機能強化により、TMF Bot は英語以外の言語で記述されたドキュメント内の主要なメタデータをトレーニングし、自動的に分類または検出できるようになります。30 以上の言語がサポートされています。

自動モデル更新

組織での最新の提出要件を TMF ボットにより一貫して適用するには、本番環境に展開したモデルを最新の TMF ドキュメントおよびデータに基づいて継続的にアップデートすることが極めて重要です。最近実施された TMF ボットパフォーマンス分析により、カスタムモデルを使用している一部のお客様は、(時には 18 か月を超える) 長期間にわたってモデル更新を実行していないことが明らかになりました。定期的な更新を実行しないことにより、TMF ボットの有効性に悪影響が及ぶ恐れがあります。

この状況に対応するため今回追加された本機能では、リリース日の夜にすべてのお客様の Vault で Training ジョブを自動的に有効化し、モデルがリリースごとに一貫して更新されるようにします。

ワンクリックでのモデルの再トレーニング

組織での最新のサブミッション要件を TMF ボットにより一貫して適用するには、本番環境に展開したモデルを TMF ドキュメントおよびデータの最新アップデートに基づきトレーニングすることが不可欠です。新規 Vault リリースごとにモデルの自動更新がスケジュールされていますが、分類やサブミッションガイドを更新したい場合には、より頻繁なモデル更新が必要となる場合があります。

この新機能により、合理化されたワンクリックプロセスで、展開およびトレーニング済みのモデルを更新できるようになりました。手動でモデルレコードをコピーして Training ジョブを開始する代わりに、Refresh Model アクションを使用できるようになりました。このアクションを実行すると、現状のモデルのディープコピーが自動的に作成され、Training プロセスが開始されます。この機能強化により必要な手順が削減されるだけでなく、ユーザが複数の Training ジョブを同時に開始する状況を防げるため、最適なシステムパフォーマンスを確保できます。

トレーニングセットの最適化

当社顧客ベース全体における TMF ボットのパフォーマンスを徹底調査した結果、トレーニングセット内のドキュメントの大部分 (50 ～ 70%) がごく少数の分類に振り分けられ、それぞれの分類に 1,000 件以上のドキュメントが含まれていることがわかりました。このような大量ドキュメントの分類分けは数自体は少ないものの (20 未満)、上限 20 万のモデルトレーニングスペースのうち大幅なスペースを消費します。このような不均衡により TMF ボットがトレーニングできる分類の種類が減り、ボットの有効性に影響を及ぼしている可能性があります。

モデルのトレーニング対象となる分類数を最大限に増やすため、TMF ボットのドキュメント抽出クエリのリファクタリングを行い、Vault 内でアクティブなドキュメント分類ごとに個別にドキュメント抽出クエリが実行されるようになりました。この変更により、トレーニングセット全体でよりバランスの取れた分類のバリエーションが確保され、自動分類の範囲とエラー率が改善されると予測されます。

リーガルホールド対象の治験をメタデータ抽出から除外

試験や製品が訴訟に関係する場合は、関連ドキュメントの完全性を維持することが不可欠です。Vault では、これらの維持されたドキュメントを再分類することはできません。

場合によっては、TMF Bot のメタデータ抽出によってリーガルホールド対象の治験が検出され、その値がドキュメントに設定されることがあります。このような状況では再分類がブロックされるため、このようなメタデータ予測により、ユーザーはインボックスからドキュメントを処理できなくなり、治験の業務や最終的なアーカイブプロセスが妨げられることになります。

この機能により、このシナリオに対処するためにメタデータ抽出プロセスが更新されます。TMF Bot は、Study が現在リーガルホールド対象である場合に、ドキュメントに Study 値が設定されるのを回避するようになりました。

Site Connect

Site Connect の支払情報

これまで、施設が完了した治験活動に対する支払プロセスの可視性は限られており、そのことが、支払いが行われるかどうか、またはいつ支払われるかについての不透明性につながっていました。治験依頼者や CRO から支払通知書が提供される場合でも、それらは簡単に報告できないため、治験全体または患者全体の総支払額を把握することは困難です。

このような課題に対処するため、Site Connect に支払情報機能が追加され、Vault Payments アプリケーションで収集された情報が表示されるようになりました。この機能により、権限のある施設担当者は、新しい Payment Information セクションから施設の支払詳細にアクセスし、支払済みまたは保留中の支払リクエストをフィルタリング、検索、ダウンロードできます。また、施設からの請求書とその支払を簡単に照合してメモを追加したり、支払リクエストに移動してそこに含まれる各支払項目を確認したりすることもできます。この合理化されたプロセスにより、透明性、トレーサビリティ、効率が向上し、施設での支払エクスペリエンスが大幅に改善されます。

施設のシステムリンク

施設ユーザは、施設ホームページに新しく追加された System Links セクションで、治験依頼者と CRO によって共有された治験システムリンクを閲覧できます。治験依頼者と CRO は、Site Connect タブの下にある Site System Links タブでシステム名、タイプ、URL および任意の説明を入力してシステムリンクを作成できます。

ドキュメントの自動交換

Site Connect では、治験施設へのドキュメントおよびドキュメントリクエストの自動送信がサポートされるようになりました。治験依頼者および CRO は、新しく追加されたドキュメント選択リストフィールド Auto-distribute document action を Revise & Return または None のいずれかに設定することで、どのドキュメントを自動送信するかを指定できます。このフィールドは、デフォルトでは読み取り専用としてドキュメント上に表示されますが、治験依頼者と CRO は編集可能に設定することができます。関連する Study の Connected Study Type フィールドが Document Exchange に設定されていて、かつ関連する Study Sites で新しいチェックボックス Auto-document exchange が有効に設定されている限り、1 時間ごとのジョブで指定ドキュメントが選択され Distribution Taskレコードが作成されます。ドキュメントでは、対象施設用に作成された Distribution Task の新しい Sponsor/CRO Comments テキストフィールドもサポートされるようになりました。

ドキュメントリクエストの自動作成のため、Expected Document (edl_item__v) レコードに、新たに Auto-request from Site チェックボックスフィールドおよび Sponsor/CRO Comments テキストフィールドが追加されました。Auto-request from site フィールドが true に設定されていて、かつ一致するドキュメントが Vault 内に存在しない場合は、施設レベルのすべての Required EDL レコードに対してドキュメントリクエスト Provide Original を指定する Distribution Task レコードが作成されます。上記のすべての施設タスクでは、期日はデフォルトで 1 週間後に設定されますが、ユーザは必要に応じて Distribution Task から直接期日を変更できます。自動配布で作成されたすべてのドキュメントおよびドキュメントリクエストに関する通知が、施設に対して 1 日 1 回送信されます。

ドキュメントリンクへのアクセス時の認証

Site Connect によるドキュメントアクセス時のセキュリティを強化するため、治験依頼者と CRO は、施設ユーザがメールで受信したドキュメントリンクにアクセスする際に、VeevaID による認証を必須に設定できるようになりました。この条件は、対応する Vault Clinical Docs artifact で Toggle Authenticate Document Links アクションを使用することにより、ドキュメントタイプごとに設定できます。

この機能は、ドキュメント交換、治験アナウンスメントおよび Safety Distribution のメール通知に適用されるほか、Download all document リンク内で 1 つ以上のドキュメントが認証必須と設定されている場合にも適用されます。

リコールの理由

サイトユーザー向けのドキュメント交換ワークフロープロセスの明確さと透明性を高めるために、スポンサーおよび CRO は、ドキュメントをリコールする際に理由 (最大 255 文字) を提供する必要があります。リコール理由が保存されると、影響を受けるサイトユーザーは、通知本文に含まれるリコール理由とともに、リコールされたドキュメントの詳細を記載した通知を受け取ります。

Site Connect ライセンス

Site Connect のお客様は、Clinical Operations Vault の Study Site License オブジェクトで Site Connect ライセンスを追跡できるようになりました。管理者は、Vault 設定でライセンスの消費量を確認できます。消費量がライセンス量を超えると、ユーザーに警告メッセージが表示されます。

Vault Clinical ドキュメントの追加サポート

Site Connect を使用すると、治験依頼者と施設間でドキュメントをシームレスに交換できます。この機能によって交換できるドキュメントタイプが以下のように拡張されました。特に明記されていない限り、治験依頼者と施設間で双方向にドキュメントを交換できます。

VCD 生成物	割り当て済みの施設ドキュメントタイプ	施設から送信可能か	新機能
関連コミュニケーション (施設管理)	通信	はい	新しい VCD 生成物。通信の施設ドキュメントタイプを施設から送信できるようになりました。
治験薬概要書変更点の概要	IB 変更点の概要	いいえ	既存の VCD 生成物は、これまでは治験薬概要書の施設ドキュメントタイプにマッピングされていましたが、現在は新しい IB 変更点の概要の施設ドキュメントタイプにマッピングされるようになりました。
IP 検証ステートメント	IP およびサプライ出荷	いいえ	新しい VCD 生成物。
規制当局進捗レポート	規制当局への提出	いいえ	新しい VCD 生成物。
インポートライセンス	IP およびサプライ出荷	いいえ	新しい VCD 生成物。
安全性/治験情報に関する規制当局向けシステムメッセージ	規制当局への提出	いいえ	新しい VCD 生成物。
IRB/IEC 進捗レポート	IRB/IEC の提出	いいえ	新しい VCD 生成物。
分析証明書	IP およびサプライ出荷	いいえ	新しい VCD 生成物。

Study Startup

Site Feasibility: Veeva Standard Questions と再利用可能な回答

治験実施可能性の検討段階で、治験施設は複数の治験依頼者から同じ質問への回答を求められることがよくあります。この回答作業には手間がかかり、多くの場合、施設からの回答が得られるまでより長い時間を要します。このような負担を軽減するため、Site Feasibility 機能に業界標準の調査用質問が導入されました。この質問と回答のセットは編集できず、回答は Vault 間で保存および再利用されます。Veeva Standard Question フィールドを Yes に設定している場合に、Veeva Standard Questions がライブラリ質問としてプロビジョニングされます。Standard Questions を調査テンプレート内で使用した場合、回答は Stored Responses オブジェクトに保存され、組織の Site Capabilities セクションから直接閲覧できます。

組織に基づいて回答を再使用した、再利用可能な回答の質問が Feasibility Survey に含まれている場合、調査回答者 (施設) は Universal Site Number (USN) を固有識別子として入力する必要があります。この固有識別子を入力することで、レジストリによって Vault 間で回答が保存および再利用されます。各施設は、Feasibility Survey 機能内に新しくできた View USN Suggestions or Sign Up バナーから、USN の検索や登録を行えます。

さらに管理者は、Question Library でカスタム標準質問を定義づけ、その質問を複数の調査テンプレートで使用することも可能です。ここで定義した質問は、Reuse Response フィールドと Standard Question Type に基づき単一の Vault 内で再利用されます。Vault では、組織および担当者に関連するカスタム Standard Questions がサポートされています。

Veeva Standard Questions と Available Answers は、SSU が有効化されているかどうかに関係なく、すべての Clinical Operations Vault でプロビジョニングされます。この機能を使用するには、既存の調査テンプレートを更新する必要があります。

標準調査質問の使用方法の詳細については、こちらをご覧ください。

Study Training

Study Training アプリケーションには、以下に記載されている機能に加えて、Quality: Training セクションに記載されている以下の機能の強化が適用されます。

• 学習者免除リクエスト
• My Team ページ & My Study Team ページの UI 更新
• トレーニングの強化

新しい標準責任

24R3 の Clinical Operations Vault において、次の Responsibility オブジェクトレコードが新たに追加されました。

• 名前: 適格基準 (選択/除外) の決定
• 責任カテゴリ: Medical

Study Training Vault では、この新しい責任は、対応する新しい Learner Role および Clinical Mapping レコードとして追加されます。

トレーニング完了を一括でマーク

ユーザは、My Study Team ページで複数の学習者を選択し、選択した学習者の複数のトレーニング割り当てを完了済みとマークすることができます。この機能は、Study Training では使用できますが、Vault Training では使用できません。

この変更以前は、トレーニング管理者は、Facilitated Training を使用してトレーニング要件を一度に 1 つずつ完了済みとしてマークする必要がありました。トレーニング管理者はこの操作により、1 つのトレーニング要件の完了マークを複数の学習者に適用できました。

今回加わった機能により、CRA などの信頼できるユーザは、複数のトレーニング要件の完了マークを複数の学習者に適用できるようになりました。したがって、ユーザはトレーニング完了情報を一括してシステムに手動で入力できます。

使用例: 施設立ち上げ訪問時に、CRA が一定数のスタッフを集めて、あるコンテンツ一式のトレーニングを行いたいとします。このトレーニングは、1 つまたは複数のトレーニング要件に相当します。トレーニング参加者の中には、トレーニングをすべて完了する人もいれば、途中で退席する人もいます。Mark Training Complete in Bulk 機能を使用すると、CRA (マネージャ) はこのようなトレーニング記録すべてを一括でシステムに入力できます。

• 最大 50 名の学習者を選択し、一括で完了とマークできます。
• この機能で、最大 40 件のトレーニング要件を一括処理できます。
• この機能は、管理者などの適切な権限を持つユーザ全員が利用できます。ただし主な対象ユーザは CRA です。
• この機能で、完了証明書をアップロードできます。
• 電子署名機能を有効化できます。
• Consent to Share が False に設定されたトレーニング割り当てのみが、この機能の適用範囲に含まれます。

学習者の選択:

トレーニング要件の選択:

各学習者に適用するトレーニング要件の選択:

詳細、および機能の有効化設定については、Veeva Vault ヘルプの「My Study Team」をご覧ください。

Clinical Operations データモデルの変更

詳細については、24R3 Clinical Operations データモデルの変更をご覧ください。

Veeva eCOA

Vault Connections セクションに記載されている Clinical Operations のライフサイクル状態転送の強化機能も eCOA アプリケーションに影響を与えます。

ePRO から eCOA への名称変更

この機能により、プラットフォームの幅広い機能を表すために、製品名が ePRO から eCOA に更新されます。現時点で ePRO という用語は、電子化された患者報告結果を指す場合にのみ使用され、情報収集に使用するアプリケーションを指すことはありません。

スタジオ

翻訳が未完了のコレクションの承認を有効化

この機能により、治験依頼者および CRO ユーザは翻訳が不完全なコレクションを承認できるようになります。Studio のユーザは、言語が承認されたコレクションに含まれていない場合、治験言語をコレクションから除外できます。除外された言語がコレクションの UAT 実施を妨げることはなく、コレクション承認時にはコレクション言語に含まれません。

イベントの無効化

この機能により、治験依頼者/CRO スタッフは、承認されたコレクションで使用されたイベントを無効化できるようになります。無効化することで、イベントに関連付けられた収集データが施設スタッフに引き続き表示されるようにしつつ、治験で使用しなくなったイベントを削除できます。まずは、すべてのスケジュール、ルール、アンカーイベントからイベントを削除する必要があります。無効なイベントは、他のデータに関連付けられていない限り、eCOA の参加者のイベントリストから削除されます。すでに収集されたデータはレポートに含められ、イベントの変更は監査レポートで追跡されます。必要に応じてイベントを後で再度有効化することもできます。

調査およびスケジュールエディタの強化およびスニペット追加

この機能により、コピーアンドペースト可能な JSON コードスニペットライブラリが追加され、治験依頼者/CRO ユーザの調査およびスケジュール作成機能が改善されます。さらに、スタディビルダーは最初のバージョンの調査を作成するときにスケジュール JSON を作成できるようになりました。

スニペットライブラリには、完全なテンプレートから質問ブロックやパラメータまで、さまざまなブロックが含まれており、スタディビルダーは完全に柔軟に JSON を構築できます。各スニペットには、コピーできる簡単なアクションとその使用に関する詳細な情報が含まれています。

データ変更の無効化または変更の時間枠の入力

この機能により、治験依頼者は、施設ユーザによる送信済み調査データの変更を無効にできるようになります。治験依頼者ユーザは、施設ユーザがデータを変更できる期間を設定して、データがタイムリーに変更されるようにすることもできます。必要が生じた場合には、治験中にいつでもこの設定を変更できます。

数値評価スケールの質問で空欄に対応

この機能により、治験依頼者/CRO スタッフは、スペーサーとして機能する空の文字列を含む数値評価スケール (NRS) ラベルを設定できるようになります。スペーサーにより、他のラベルが折り返され、ライセンス要件を満たす特定のラベル幅が作成されます。

「必要に応じた」各調査の期間設定

この機能により、治験依頼者または CRO スタッフユーザは、「必要に応じた」各調査に回答するための一定期間を追加できるようになります。特定の分数、時間数、または日数で回答できるように期間を設定できます。

ePRO Vault

調査ライブラリマネージャ

この機能により、治験依頼者/CRO スタッフユーザは、顧客ライブラリで再利用可能な調査を作成および編集できるようになります。調査ごとに翻訳をアップロードして管理することもできます。ユーザは、ライブラリ調査を公開、アーカイブ、またはアーカイブ解除することで、研究目的でのライブラリ調査の可用性を制御できます。ユーザは、新しいバージョンのライブラリ調査を作成して変更を加えることもできます。

施設担当者を招待する際のメールチェック

以下の更新がこの機能で利用できるようになります。

• 治験依頼者/CRO スタッフユーザが施設ユーザを追加すると、そのメールアドレスが eCOA Vault または他の Veeva アプリケーションで既に使用されているかどうかに関するインラインフィードバックが送信されます。このフィードバックは、Veeva アプリケーションで施設スタッフユーザにすでに関連付けられているメールアドレスを使用しているかどうかをユーザが確認するのに役立ちます。これは、施設スタッフユーザが複数のメールアドレスを所有している場合に役立ちます。
• このシステムにより、施設ユーザのセキュリティプロファイルの割り当てを制御して、施設ユーザ管理におけるエラーを最小限に抑えます。

レポート作成

24R3 機能の監査イベント

この機能により、システムは 24R3 機能の関連するユーザアクションを MyVeeva 監査証跡の監査イベントとして追加できます。

CDB エクスポート内の複数の表

この機能により、治験チームメンバーは CDB を 1 つの表でエクスポートするか、複数の表でエクスポートするかを選択できるようになります。デフォルトでは、引き続きデータは単一の表として CDB に入力されますが、新しいスポンサートグルを使用して、データを調査ごとに 1 つの表に分割できます。

API

参加者 ID 用の新しい API

臨床試験の実施方法によっては、参加者の ID が複数のシステムに記載される場合があります。この機能により、RTSM システムなどの認証システムから参加者リストをシーディングできる外部 API が作成され、施設スタッフが Veeva eCOA で参加者 ID 情報を手動で作成および更新する必要がなくなります。統合を設定する担当者は、前提条件を満たせるように Veeva を調整し、その後 Veeva eCOA と統合して、必要に応じて更新を行います。

Veeva eCOA (施設)

治験プレビュー

この機能により、すべての治験ユーザは、設定されているすべての調査、スケジュール、通知を含む治験スケジュールを確認および調査できます。スケジュールを操作して、どのイベントでどの調査を回答可能にするかを決定し、ブラウザで調査をプレビューして、ユーザと同じように体験できます。 

新しい施設翻訳 - イタリア語

この機能により、イタリアの施設ユーザは Veeva ePRO をイタリア語で表示できるようになります。

治験に参加しなくなった参加者の無効化

この機能により、施設スタッフは、調査に参加しなくなった参加者を無効化して、データ収集を終了できるようになります。無効化すると、参加者に通知が届かなくなり、今後の調査はキャンセルされ、eCOA で参加者を編集できなくなります。以下のアクティビティは引き続き許可されます。

• 調査が完了するまで、進行中の調査には引き続き回答できます。
• オフラインで完了した調査は、ユーザが再接続すると送信されます。
• 引き続き参加者はログインして、治験情報やリソースを閲覧できます。

必要に応じて参加者を再度有効化することもできます。

誤って収集された調査の削除

この機能により、施設スタッフは、調査データが誤って収集された場合に、そのデータをレポートに含めないようにすることができます。すべてのアクションは監査され、データ変更レポートの形式で治験依頼者が確認できます。完了した ePRO および eClinRO の調査が削除の対象となり、削除時に変更の理由が収集されます。治験依頼者は、治験設定で施設に調査削除機能を付与するかどうかを管理できます。

必要に応じて調査を復元することもできます。

サポート依頼に対するグローバル回答のステータス

この機能により、施設スタッフはヘルプリクエストを Open または Archived として分類し、どのリクエストに対する応答がまだ必要かを簡単に確認できるようになります。リクエストを Archived に移動するか、Open に戻すと、すべての施設スタッフの回答ステータスが更新されます。

施設のアプリ内通知の追加

この機能により、施設スタッフユーザはアプリ内通知を受信し、オプションとして治験に伴う通知のメール受信量を減らすことができます。ヘッダーからアクセスできる通知ベルには、未読の通知がある場合にインジケータが表示されます。

来院に関するエラーメッセージの改善

この機能により、来院が予定通りに患者に送信されなかった場合に、より具体的なエラーメッセージに更新されます。

調査データ損失防止

この機能により、バックエンドデータの確認に失敗した調査がサーバーに保存され、データの損失を防ぐことができるようになります。まれに、調査のデータチェックが失敗することがあります。その場合は、調査に無効なデータが含まれている可能性があることを施設ユーザに通知するインジケータが表示されます。Veeva が施設に連絡して、データをレコードに追加する必要があるかどうかを確認します。

MyVeeva for Patients

翻訳

24R3 における翻訳と新たな言語

MyVeeva ユーザは、アプリケーションのテキスト、メール、通知、利用規約、プライバシーポリシーを以下の言語で表示できるようになりました。

• アフリカーンス語 (南アフリカ)
• アッサム語 (インド)
• ベンガル語 (インド)
• 中国語 (繁体字) (香港)
• 中国語 (繁体字) (台湾)
• クロアチア語 (クロアチア)
• 英語 (イスラエル)
• 英語 (シンガポール)
• グジャラート語 (インド)
• ハイチ語 (ハイチ)
• ヒンディー語 (インド)
• カンナダ語 (インド)
• リトアニア語 (リトアニア)
• マレー語 (シンガポール)
• マラヤーラム語 (インド)
• マラーティー語 (インド)
• オディア語 (インド)
• パンジャブ語 (インド)
• ロシア語 (イスラエル)
• ロシア語 (リトアニア)
• ロシア語 (ウクライナ)
• セルビア語 (セルビア、キリル文字)
• スペイン語 (アルゼンチン)
• スペイン語 (チリ)
• スペイン語 (コロンビア)
• スペイン語 (ペルー)
• タミル語 (インド)
• タミル語 (シンガポール)
• テルグ語 (インド)
• ウクライナ語 (ウクライナ)
• ウルドゥー語 (インド)

全般的な UI

電話番号のないアカウントに送信されるメール通知

この機能を使用すると、アカウントにメールアドレスのみが関連付けられている未登録の参加者が、eConsent の通知を受信できます。これまでは、電話番号が未登録のユーザに通知を送信していませんでした。この更新により、リモート参加者は MyVeeva for Patients アプリでアカウントを簡単に登録できるようになります。

治験連絡先の追加

この機能により、施設は MyVeeva ユーザの連絡先電話番号をアプリに追加できます。必要に応じて電話番号を更新または削除できます。MyVeeva アプリでは、電話番号は Study タブの電話アイコンに関連付けられており、参加者がそのアイコンを選択すると、追加された電話番号に電話をかけるように求められます。

施設選択に基づく患者言語

言語設定プロセスを効率化するために、MyVeeva アプリの Account ページから言語ドロップダウンを削除しました。アプリでは施設スタッフが参加者を追加するときに選択した言語を使用するため、参加者が言語設定を更新することはできなくなりました。参加者は、Study タブの Details を表示することで、選択されている言語を確認できます。これまでは、ある言語のシステム通知と別の言語の治験情報を切り替えることで、参加者が混乱する可能性がありました。

ユーザによる iOS アプリでの生体認証設定の有効化および無効化

この機能により、アプリユーザはアプリの Account Settings 設定タブから Face ID を有効または無効にできるようになり、アプリを終了してデバイス設定で設定を変更する必要がなくなります。この変更は、アプリと Touch ID および Android デバイスとの連動と一致しており、参加者のエクスペリエンスを簡素化します。

フォーマットの改善、ワークフローの軽微な更新、ユーザガイダンスの改善を含む 24R3 ePRO/eClinRO の機能強化 & 修正

以下の更新がこの機能で利用できるようになります。

• eCOA の参加者プロファイルヘッダーが更新され、最小限のデータが見やすく表示され、さらに大きく拡大できるようになりました。
• 参加者を SiteVault から eCOA に追加する場合、アクティベーションコードは必要ないため、施設スタッフは参加者にアクティベーションコードを提供するように指示されません。
• 新しい治験バージョンが利用可能になると、施設スタッフユーザに治験バージョンを有効化するように求める通知が参加者リストの上に表示されます。
• 調査ボタンには、他の施設ボタンと一致するように軽微な更新が施され、MyVeeva ユーザは一貫したエクスペリエンスを得ることができます。

ユーザ言語に基づくデフォルトの電話番号の国コード

この機能により、空の電話番号入力フィールドに対してデフォルトで選択される電話番号の国コードがユーザの言語ロケールに基づいて更新されるようになります。米国の国コードではなく参加者の国コードを自動的に選択することで、アプリのエクスペリエンスが向上します。

モバイル eConsent の画像ビューの改善

この機能により、MyVeeva ユーザはデバイス搭載の機能を使用して、eConsent ドキュメント内の画像を拡大したりパンしたりできます。デバイス搭載の機能を使用すると、参加者によるアプリの使用が簡素化されるため、参加者は eConsent のコンテキストを離れることなく、より詳細な画像を表示できます。

SiteVault に戻る

この機能により、施設ユーザはデバイスを使用して参加者を承諾すると、SiteVault ログインページに戻るようになります。ワークフローを合理化することで、ユーザエクスペリエンスが向上します。

ユーザがモバイルアプリの強制アップグレードを一時的に延期

この機能により、MyVeeva ユーザは強制的に即時アップグレードする代わりに、MyVeeva で決定した期間、モバイルアプリのアップグレードを延期できるようになります。アップグレードは通常 14 日間延期されますが、緊急性の高い更新の場合は期間が短くなる場合があります。指定された期間が経過すると、ユーザは再度ログインするためにアプリをアップグレードする必要があります。この更新により、ユーザは更新をインストールする前に時間的制約のあるタスクを完了できるようになり、煩わされることなく治験に参加できるようになります。

Commercial

以下のリリースノートに加えて、Vault PromoMats Veeva Connect コミュニティでは、General Release に関するお知らせ、リリースの注目機能、主要な機能のデモを提供しています。

Vault Connections セクションに記載されている RIM と PromoMats: 製品データの転送機能も Commercial アプリケーションファミリーに影響します。

PromoMats

モジュラーコンテンツのプレビュー: 資料 (HTML)

このリリースにより、Vault ではレイアウトテンプレートに合わせてコンテンツモジュールが視覚化され、コンテンツ内でコンテンツモジュールがどのように表示されるかを確認できるようになります。プレビューは最大で 24 時間利用できます。

この機能では、レビュー担当者にとってレビュー中のコンテンツ解釈およびフィードバック提供をしやすくすることで、コンテンツモジュールとコンテンツモジュールの組み合わせに対するレビューと承認を支援します。

この機能は、Vault 内に保存されている HTML テンプレートを利用します。

モジュラーコンテンツ: CRM メールのプレビュー生成が非同期ジョブに移動

このリリースでは、全体的なパフォーマンス向上を目的として、CRM メールモジュールのプレビュー生成ジョブが非同期で実行されるように更新しました。これによりユーザは、通知リンクまたはメールリンクを介して生成されたプレビューにアクセスできるようになりました。プレビューは生成後最大で 24 時間有効でアクセス可能です。

モジュラーコンテンツ: Content Module アプリページのワークフローバナー

このリリースでは、レビュー担当者は Content Module レコードに移動するのではなく、Content Module アプリページでワークフロータスクを直接確認および完了できるようになりました。Vault では、コンテンツモジュールに対して単一のレコードワークフローが有効になっている場合にのみ、Content Module ページにワークフローバナーが表示されます。

初回バージョンアップロード時の自動リンク

管理者は Vault で自動リンク付けの自動実行を有効化することで、ユーザが Make a Copy を使用してドキュメントの初回バージョンをアップロードする際に、Text Assets を自動的にリンク付けおよび提案できるようになりました。このプロセスは設定されたドキュメントタイプに対して自動的に開始され、ユーザが自動リンク付けアクションを手動で開始したり、ドキュメントの状態を変更したりする必要がなくなります。

テキストアセットの参照アンカーの自動更新

リンク注釈 (参照など) に使用中のドキュメントが新たに定常状態にバージョンアップされると、Claims の証拠として使用される永久テキストアンカーが自動的に更新され、最新ドキュメントバージョンの詳細が反映されます。Claim レコードにある新しいセクション Archived References に前回のドキュメントバージョンが追加されます。 

Claims ページにできた新しい Archived References セクションでは Archived References の削除も行うことができ、削除するには表示されている 2 つの Remove オプションのうち最初のオプションを選択します。ただし、Archived References は Claims から削除しないよう強くお勧めします。  

この機能は、参照先ドキュメントのライフサイクルが定常状態にある場合のエントリアクションとして設定する必要があります。

Created From 関係タイプ

このリリースでは、新しい Created From ドキュメント関係が導入されました。ユーザがドキュメントのコピーを作成する際に、Created From 関係にある元のドキュメントが取得されます。この Created From 関係は既存の Based On 関係と似ていますが、Based On 関係とは異なるのは、ユーザがドキュメント作成後に API から、または UI から手動で Created From 関係にさらにドキュメントを追加できるという点です。

ローカルコピー作成ジョブのログ詳細度の向上

この機能により、ローカルコピーの作成ジョブ中にエラーが発生した場合に Vault ジョブログで提供されるログの詳細度が向上します。これにより予期しない結果のトラブルシューティングに役立ちます。

CRM Slide Notes の自動入力

この機能により、PromoMats Vault では、Create Presentation 機能で PowerPoint (PPTX) ソースファイルを元のドキュメントとして使用し複数スライドのプレゼンテーションを生成する際に CLM Slide Notes フィールドが自動入力されます。これにより、Veeva Vault または Vault CRM によって下流で使用するために、ユーザがスライドのメモをドキュメントメタデータフィールドに手動で抽出する必要がなくなります。

Commercial データモデルの変更

24R3 Commercial データモデルの変更をご覧ください。

Medical

以下のリリースノートに加えて、Vault MedComms および Vault MedInquiry Veeva Connect コミュニティでは、General Release に関するお知らせ、リリースの注目機能、主要な機能のデモを提供しています。

すべての Medical アプリケーション

Created From 関係タイプ

このリリースでは、新しい Created From ドキュメント関係が導入されました。ユーザがドキュメントのコピーを作成する際に、Created From 関係にある元のドキュメントが取得されます。この Created From 関係は既存の Based On 関係と似ていますが、Based On 関係とは異なるのは、ユーザがドキュメント作成後に API から、または UI から手動で Created From 関係にさらにドキュメントを追加できるという点です。

MedComms

コピーされたステートメントのデフォルト値の自動生成

このリリースでは、ユーザーが科学的ステートメントに対して Copy Record アクションを実行すると、システムで、新しく作成されたレコードの新しい Source Statement フィールドが自動的に入力されるようになりました。Vault は、レコードのコピー元の Statement の ID をフィールドに入力します。さらに、Statement に Reason for Copy フィールドが追加され、アクションレイアウトを使用して、 Source Statement フィールドと Reason for Copy フィールドが Copy Record アクション中にのみ表示されるように制限されます。

CRM Slide Notes の自動入力

この機能により、Create Presentation 機能で PowerPoint (PPTX) ソースファイルを元のドキュメントとして複数スライドのプレゼンテーションを生成するときに、MedComms Vault の CRM Slide Notes フィールドが自動入力されます。

CRM メールのコンテンツモジュール UI

Vault Medical では、CRM メールモジュール構築時に直感的なユーザインターフェースがサポートされるようになりました。このアップデートにより、ユーザはコンテンツモジュール UI で直接コメントすることも可能になりました。

MedInquiry

問い合わせ処理のドキュメントビューおよびダウンロードを Case Response に関連付け

この機能により、Fulfillment Document の外部ビューとダウンロードを追跡できます。Response Document Link が外部で開かれ、その中の Fulfillment Documents が表示またはダウンロードされるたびに、追跡されます。この機能には 2 つの主な目的があります。それは受信者が回答パッケージで送信されたドキュメントを表示したことを MedInquiry ユーザが確認できるようにすることと、外部でのコンテンツ表示を顧客が正確に報告できるようにすることです。

Standard Response に由来する Fulfillment Document レコードへのタグ付け

このリリースでは、Standard Response から Fulfillment Document が自動的に追加される場合、その Fulfillment Document に Standard Response Document のタグが付けられます。

Fulfillment Document 選択機能の強化

このリリースでは、Response Package に含まれるドキュメント管理用 Fulfillment Document セクションの使いやすさ改善が複数導入されました。

• ユーザは、Case Response ページから直接、Fulfillment Document の並べ替えや削除を行えるようになりました。
• ユーザは、ジョインレコードの代わりに標準ドキュメント選択を使用してドキュメントを追加できるようになりました。
• 更新後のインターフェースには、追加されたドキュメントの重要情報が表示されるようになりました。表示される情報には、Standard Response に含まれるドキュメントのタグ、ドキュメント番号、Product、ドキュメントの種類、外部アクセス統計 (閲覧とダウンロード) などが含まれます。

Case Response の Fulfillment Document に対する一意条件

この拡張機能は、ユーザが Case Response に重複した Fulfillment Document を追加するのを阻止するものです。ユーザが重複したドキュメントを追加しようとすると、エラーが表示されます。さらに、Generate Response Package アクションまたは Generate Preview Response Package アクションを実行する際に、そのパッケージに含まれるドキュメントが重複していないかどうかが自動的に検証されます。ドキュメントが重複している場合、アクションは失敗します。

Add Standard Fulfillment Documents アクションによる重複ドキュメントの追加を防止

この機能により、ドキュメントがすでに手動で追加されている場合に Add Standard Response Documents アクションを実行すると、その同じドキュメントが Case Response の Fulfillment Document レコードとして追加されなくなります。

Case Response あたりの Fulfillment Document 数を 100 に制限

このリリースで、Case Response 1 件あたりの Fulfillment Document 数が 100 件に制限されました。

取り込み時に過去の症例を表示

症例の取り込み時に、選択した症例連絡先の過去の症例が Medical Inquiry ユーザインターフェースに表示されます。

Medical Inquiry ユーザインターフェース: レコード作成アクションからのフィールド更新の表示

この機能を使用すると、Medical Inquiry UI に表示されるオブジェクトのライフサイクルのレコード作成アクションでフィールドの更新が定義されている場合に、それらの更新が保存時に Medical Inquiry UI に反映されます。

テレフォニーサポート: Conversations

Conversation 機能により、MedInquiry データ構造と大部分の電話通信業者との整合性が確保されます。Conversation (会話) とは、企業担当者と依頼者 (医療従事者、患者など) の 2 地点間における対話を指します。 

さらに、Conversations 機能では、テレフォニーインテグレーションにより共有されたデータを用いて Case 情報と Case Contact 情報を事前入力できます。Conversations 機能は、通話とチャットの転記および録音データにより、Cases に対する監査と品質保証でも役立ちます。

Medical Inquiry Keyword Tracking: クリーンアップジョブと再処理ジョブ

このリリースでは、3 年以上前の Case Request の Case Request Medical Inquiry Keyword レコードをすべて削除する毎日の定期ジョブが導入されています。この機能は、Medical Inquiry Keyword Tracking 機能によって Vault で生成されるデータの量を最適化します。

さらに、管理者は、すべての MedInquiry Vault で Medical Inquiry Keyword の標準レポートおよびダッシュボードを設定できるようになりました。

Medical データモデルの変更

24R3 Medical データモデルの変更をご覧ください。

Quality

全ての Quality アプリケーション

Quality Vault から LIMS オブジェクトを削除

次の LIMS 関連設定が Quality Vault から削除されました。

• 名称が lims_v で始まる全オブジェクト
• 以下のフィールド:

Object	削除されるフィールド
quality_batch__v	control_specification__v フィールド
quality_batch__v	release_specification__v フィールド
quality_batch__v	protocol__v フィールド
quality_batch__v	lims_generate_spec_execution__v アクション
asset__v	current_location__v フィールド
asset__v	current_location_svo__v フィールド
asset__v	label_definition__v フィールド
asset__v	lims_print_asset_labels__v アクション
asset_family__v	label_definition__v フィールド
asset_family__v	integration__v

QualityDocs

通知テンプレートの Document Change Control トークン

Document Change Control 通知テンプレートに含めることができる 3 つの新しいトークンが利用可能になりました。これらのトークンを使用すると、通知の受信者は、Document Change Control に関連付けられたドキュメントのリストを表示でき、それらのドキュメントが変更承認のためにルーティングされるか、有効化または除外されるかを確認できます。

新しいトークンは次のとおりです。

• ${mdccChangeAuthDocsList} は、変更承認のために送信されるドキュメントのコンマ区切りリストを表示します。
• ${mdccReleaseDocsList} は、有効化されるドキュメントのコンマ区切りリストを表示します。
• ${mdccObsoleteDocsList} は、除外されるドキュメントのコンマ区切りリストを表示します。

Quality Relationships パネルの機能強化

この機能により、ドキュメントの Quality Relationships パネルが拡張され、ドキュメント変更要求 (DCR) が表示されるようになりました。ユーザはこのパネルで直接 DCR を閲覧できるようになり、ドキュメントを離れて別のタブやレポートで関連 DCR を閲覧する必要がなくなりました。適切な権限を持つユーザは、このパネル内で DCR の作成および削除も行えます。ホバーカードには、DCR レコードの理由と申請された実装日が表示されます。

さらにこの機能により、既存の各関係ペインのホバーカードに以下の追加データも表示されるようになりました。

• Process Navigator
  • 説明
• Stations
  • 説明
• Training Requirements
  • Does this Training Requirement recur? (Yes/No) 

さらに、Quality Relationships パネルにある既存の各関係ペインにデータ列が追加されました。

プロセスナビゲータ: 階層ビルダー UI の機能強化

24R2 Release では、プロセスナビゲータの階層ビルダーが導入されました。この機能には、階層ビルダーのユーザーインターフェイス上のスタイル、間隔、プロセス区切り線、その他の視覚コンポーネントに対するいくつかの小さな機能強化が含まれており、ページの外観と使いやすさがさらに向上します。

Document Change Control における自動開始ワークフローのサポート

ドキュメントが手動開始ワークフローと 1 つ以上の 自動開始ワークフローの両方に割り当てられている場合、Document Change Control レコードの Docs to be Made Effective with Workflows セクションと Docs to be Made Obsolete with Workflows セクションでは、ワークフロー列にドキュメントの手動開始ワークフローと自動開始ワークフローの両方が表示されます。

Station Manager

Station Manager での重複ドキュメントの防止

このリリースより前は、ステーション管理者は同じバージョンのドキュメントを Station レコードに複数回追加することができました。この機能により、エラーメッセージが導入され、ステーション管理者は、Station レコードの Planned または Assigned セクションのいずれかにドキュメントバージョンがすでに存在する場合、そのドキュメントバージョンを追加できなくなります。

Station Manager へのログインの改善 (iOS)

この機能により、ログイン画面の外観と使いやすさがマイナー更新され、ログイン失敗時に表示されるエラーメッセージが改善されました。

Training

E ラーニング: ロック済みクイズでの報告のサポート

この変更により、クイズを含む SCORM 1.2 E ラーニングコースと Vault 間における学習者のクイズステータスの通信が改善されました。Vault と通信させるには、正しい変数を使用して E ラーニングコースを設定する必要があります。LearnGxP ContentDirect コースは、この機能をサポートをするよう設定済みです。

E ラーニングコース内にあるロック済みクイズにより、学習者のクイズステータスに基づいて Training Content Status レコードおよび E-Learning Status Details レコードが更新されるようになりました。学習者がクイズの最大試行回数に達すると、Vault の Training Assignment ページではクイズのロック済みステータスが表示され、管理者に連絡して試行回数をリセットするよう求められます。その後トレーニング管理者は、個々のレコードに対して Reset Learner’s Course Progress アクションを使用することにより、トレーニングのロックを解除できます。

さらに、Training Content Status レコードおよび E-Learning Status Details レコードはレポート可能なため、トレーニング管理者はロック済みコースの報告やリセットを行えるようになります。この変更以前は、SCORM 1.2 ドキュメントに基づくクイズを含むロック済み Learn GxP Training では、報告は行えませんでした。

インストラクター主導トレーニングの機能強化

学習者が、クラスに追加されたドキュメントにアクセスできる

この変更により、Class レコードの Materials セクションにドキュメントを追加すると、各参加者がそのライブラリドキュメントの受講生ロールに追加されるようになります。

この変更が導入される前は、Vault ではクラスルーム資料の共有設定にクラス参加者は追加されなかったため、学習者はそれらの資料を閲覧できない場合がありました。

開始日より前の日付の終了日を保存できないようにする

Vault では、クラスルームトレーニング要件のクラスを作成するときに、開始日より前の日付の終了日を挿入できなくなりました。

Edit 権限のないユーザが QR コードの生成アクションを使用できないようにする

この変更により、Class Schedule および Session オブジェクトに対する Edit 権限を持つユーザのみが、インストラクター主導トレーニングクラスで QR コードの生成アクションをトリガーできるようになります。これらの権限を持たないユーザには、このアクションは表示されません。

この変更が導入される前は、クラスへのアクセス権を持つすべてのユーザがこのアクションをトリガーできました。

インストラクターが、出席、欠席、マークなしの出席ステータスでフィルタリングできるようにする

この変更により、インストラクターは、出席ステータスによってクラス出席者リストをフィルタリングできるようになります。

クラスで学習者の電子署名が求められている場合、インストラクターは、出席していない学習者を簡単にフィルタリングし、欠席としてマークできます。

ILT ページのクラス情報セクションに Session Location フィールドを追加

この変更により、クラスの作成または編集時に Session Location フィールドが使用可能になります。このフィールドは、クラス情報セクションにデフォルトで追加されます。

インストラクター主導トレーニング: 参加者の最大人数と待機リスト

この変更により、インストラクターは参加者の最大人数を設定できるようになり、満席のクラスの待機リストに学習者を追加できるようになりました。名簿に空きが出ると、登録順に基づいて待機中の学習者がクラスに自動的に追加されます。

物理的なクラスルームやその他のスペースには座席数制限があるため、この変更は必要です。参加者の最大人数を設定することで、クラスに参加する全員が席を確保でき、待機リスト機能によって、席が無駄になるのを防ぐことができます。

• クラスの Registrations フィールドには定員が表示されます。
• フィールドが空白の場合、参加者の最大人数は適用されません。
• トレーニング管理者は学習者を待機リストに追加できます。
• インストラクターは、待機中の学習者をクラス名簿に移動できます。
• インストラクターは、クラスの定員が上限に達している場合でも、クラス名簿に学習者を追加できます。

詳細と設定については、「インストラクター主導のトレーニング」を参照ください。

インストラクター主導トレーニング: クラスで 100 人以上の学習者をサポート

この変更により、1 つのインストラクター主導トレーニングクラスの学習者の最大人数が増加し、クラスあたり 100 人を超える学習者が参加できるようになりました。新しいカスタム共有ルールにより、内部ユーザーはクラスルーム関連のオブジェクトを表示できます。

この機能により、ビジネスをサポートするための大規模なクラス、ウェビナー、その他のセッションをホストできるようになります。

• クラスあたりの学習者の新しい最大人数は 1000 人です。
• 22R2.2 より前の古いクラスルームトレーニング方法を使用しているお客様の場合、学習者の最大人数 100 人という制限が引き続き適用されます。
• この機能が実装される前にクラスルームオブジェクトへのアクセス権を持っていた学習者と管理者は、引き続きそれらのオブジェクトにアクセスできます。

詳細と設定については、「インストラクター主導のトレーニング」を参照ください。

学習者免除リクエスト

この変更により、学習者は Training Requirement の免除リクエストを送信できるようになります。トレーニング管理者は、提出されたドキュメントに基づいてリクエスト処理タスクを受け取ります。

この変更以前は、Training Assignment から免除の要請や許可は行えませんでした。

この機能の目的は、学習者が Training Assignment から免除リクエストを開始し、適切な日付と裏付け情報を送信できるようにすることです。

たとえば、あるトピックに関して豊富な経験と学習歴を持つ学習者は、Training Assignment の免除修了をリクエストするために自己能力を示す証拠を提出できます。

• Training Requirement に新しいフィールド「Allow Learner Exemption」が追加されました
• すべての Training Assignment タイプに新しいフィールド「Evidence Completion Date」が追加されました
• 新しいオブジェクト「Learner Request」
• 新しいワークフロー「Review Exemption Request」
• Completion Source に新しい選択リスト値「Exemption」が追加されました
• Review Exemption Request ワークフローが進行中の場合、学習者は対象の Training Assignment を自己完了できません。

詳細と機能の有効化方法については、第三者教育訓練での作業をご覧ください。

My Team ページ & My Study Team ページの UI 更新

この変更によりマネージャまたは CRA は、Eligible Learners (受講資格のある学習者) と Ineligible Learners (受講資格のない学習者) を切り替えられるようになりました。 

この変更以前は、Eligible Learners と Ineligible Learners はいずれも同じビュー内に表示されていました。 

この機能の目的は、Eligible Learners と Ineligible Learners を別々に閲覧できるようにすることで、マネージャまたは CRA がデータをより正確に把握して目的のアクションに集中できるようにすることです。

Require Re-Training ユーザアクション

この機能により、Training 管理者は過去に完了済みの Training を学習者または学習者グループに自動再割り当てするプロセスを手動で開始できます。再 Training を組み入れるアクションを Person および Curriculum オブジェクトで追加できるようになります。再割り当てしたトレーニングは、1 回限りの一時的な直接割り当てではなく、その学習者のトレーニングマトリックスの一部として組み込まれます。新しく設定した割り当てが、過去に設定された繰り返し日付、トレーニングマトリックスやドキュメントの更新よりも優先されます。

この変更以前は、再トレーニングの割り当ては直接割り当てでのみ行うことができました。トレーニング管理者はこの機能を使用して、CAPA の一環として再トレーニングを行う場合や学習者が休職後に復帰した場合など、直接割り当てと同様の用途でトレーニングを再割り当てできます。

トレーニングの強化

My Learning ページ: カリキュラムカードの完了率の値

この変更により、My Learning > Open > Curriculum Card に表示されるカリキュラム完了率の値が、Training Completion Status レコードのデータに対応するようになりました。これは、Curriculum Prerequisites 機能のカリキュラム完了率が計算されるのと同じ場所です。

この変更以前は、My Learning UI ロジックに基づいて完了率が計算されていました。この変更の目的は、システムパフォーマンスを向上させ、アプリケーション全体でカリキュラム完了率を統一することです。

完了したトレーニング割り当てに「On Time」または「Late」の文字をスタンプ

この変更により、割り当てのタスクの Due Date が空白の場合、Training Assignment オブジェクトの Completed Status フィールドに「On Time」という値が入力されるようになります。

今後のリリースでは、トレーニングがオプションの場合、Due Date フィールドに値は自動入力されなくなります。

Clinical Mapping の変更の制限

この変更により、ユーザは責任ベースのトレーニングで使用される Clinical Mapping 責任者レコードを作成、更新、または削除できなくなります。さらに、ユーザは Learner Role 内の Training Type フィールドを変更できなくなります。

たとえば、Training Type が Responsibility の場合、ユーザがレコードを作成、更新、または削除しようとすると、エラーメッセージが表示されます。

Clinical Mapping の詳細については、Veeva Vault ヘルプをご覧ください。

Study Training マトリックスの自動化 UI の向上

この変更は、Study Training マトリックスの折り畳みおよび展開動作に関するマイナーな更新です。これにより、確定時、または Study Training マトリックスにトレーニング要件を追加するときに、特定の条件下でセクションが自動的に折り畳まれるようになります。

たとえば、ユーザが Study Training マトリックスを確定すると、表示モードに切り替わるときにマトリックスが自動的に折り畳まれます。ユーザが Study Training マトリックスにトレーニング要件を追加した場合は、セクションは元の折り畳まれた状態、または開かれた状態を維持します。

詳細については、Veeva Vaultヘルプの「Study Training Matrix Builder」をご覧ください。

トレーニングマトリックスの視覚化でトレーニング要件にカーソルを合わせるとドキュメントの詳細が表示される

トレーニングマトリックスの視覚化において、ユーザがトレーニング要件上にカーソルを合わせると、追加の詳細フィールドを示すツールチップウィンドウが表示されます。

この変更以前は、トレーニング要件の名前が表示されていました。

QMS

Audit Room

このリリースでは、Vault QMS に Audit Room 機能一式とワークスペースが導入されました。Audit Room を使用することにより、リアルタイムで実施される第三者監査の進行および対応という、時間的制約が厳しく極めて重要度の高い作業を管理できます。今回追加された組織内監査対応チーム専用のツールは、スピード、正確性、共同作業と使いやすさを重視して設計されています。Audit Room 機能一式の主なコンポーネントは、Audit Room と Inspector Portal の 2 つです。Audit Room は、組織内監査対応チームが監査問い合わせの優先順位付け、共同作業、管理および公開を行うためのツールです。Inspector Portal は、監査員および査察官がお客様の組織とシームレスに連携し、コンテンツのやり取りや回答管理をメールで行う必要なく、問い合わせへの回答内容を審査するためのツールです。

Audit Room 内

監査対応チームは、Audit レコードから直接アクセスできる Audit Room ページに表示され、同ページで問い合わせ (Audit Room Requests) と回答の記録および管理を行えます。さらにこのページでは、設定可能なワークフローにより問い合わせ項目の優先順位付けとルーティングを行うことができ、Inspector Portal の査察官に回答を提出する前に回答の品質と正確性を確保できます。

下の画像は対応チームから見た Audit Room で、各インジケーターで問い合わせのステータスと優先順位が表示されています。

フィルタを活用することにより、監査対応マネージャは適切なタイミングで適切な対応を行うことができます。監査対応マネージャは、設定可能なワークフローとセキュリティを活用して、問い合わせを各ライフサイクル間でドラッグアンドドロップできます。

さらに、各問い合わせは Vault レコードと同様に個別に管理でき、全ワークフローとライフサイクルがサポートされています。Responses には、承認済みのフィールドと、Vault ドキュメントおよび/または添付ファイルの参照先のみが表示されます。査察官に対するセキュリティは自動的に管理されます。査察官は、要件を満たす Published 状態の回答のみを閲覧できます。

監査対応チームは、Audit Room Requests で正式な回答を管理する機能のほか、より非正式な共同作業に重点を置いた Scribe Notes によるコミュニケーションツールも利用できます。Scribe Note はリアルタイム共同編集が可能な Microsoft Word ドキュメントで、Audit Room 内のすべての社内ユーザが利用できます。Scribe Notes を使用するには、使用前に Vault ネイティブの Collaborative Authoring 機能を有効に設定する必要があります。

Inspector Portal

組織は Inspector Portal により、Veeva ID を使用して、監査目的で外部関係者を Vault に直接招待できます。監査人は Veeva ID を使用することにより、1 回のログインだけで、連携する Veeva 顧客の種類や数に関係なく Veeva ID 使用可能なソリューションを採用している複数の組織と連携できるようになります。または、監査人を外部ユーザとしてモデル化し、組織がプロビジョニングと招待のプロセスを制御することもできます。どのようなアプローチを使用してモデル化するかに関係なく、査察官または監査人はセキュリティ制御されたページにのみアクセスでき、そのページで参加招待された監査を閲覧できます。

以下に示した Inspector Portal ページには、査察官が閲覧権限を持つ監査が一覧表示されています。このページでは Vault のユーザエクスペリエンスが簡略化されており、Vault 内の他のエリアにはアクセスできないようになっています。

次に、目的の監査を入力して問い合わせと回答を確認します。監査および回答資料 (ドキュメント、添付ファイルなど) のセキュリティは、監査ライフサイクルの一環として自動的に管理されます。

査察官が Audit ページを開くと、要件を満たし Published 状態になった Audit Room Requests が一覧表示されます。各リクエスト項目で追加情報を確認できます。Inspector Portal 内で各リクエストの確認および終了処理を整理された環境で行えるよう、監査人と査察官向けの操作は簡素化されています。

最後に、すべての問い合わせデータと回答データが Vault 内に保存されるため、Vault の Reporting と ダッシュボードエンジンから、全 Audit および Audit Room のデータにアクセスできます。これにより、これまでにない方法で回答にアクセスできるほか、回答指標を詳しく分析して傾向や洞察を明らかにし、Vault 内の監査対応チームがネイティブに利用できるようにすることができます。

Audit Room は、各監査に応じて査察官または監査人を直接プロセスに参加招待するかどうかに関係なく使用できます。お客様の組織の主な目標が、共同作業と効率的なワークスペースを活用して監査または査察への回答を管理することである場合、この機能が最適です。

Audit Room は今回のリリースにより QMS Vault で利用可能となりましたが、使用するには設定を行う必要があります。Audit Room は、現在ご使用の監査および査察ワークフローやライフサイクルとシームレスに統合できます。Audit Room ソリューションの使用と構成の詳細については、Vault ヘルプをご覧ください。

Change Action パスの機能強化

今回のリリースでは、24R2 で導入された Action Paths & Steps 機能の使いやすさが向上しました。今回のリリース以降、ユーザビリティの改善がすべて自動的に有効化されます。

• 各 Action Step レコードの名称は、現状の STEP-###### から変更され、システム管理者が QMS Action Path Configuration で定義した Action Path の名称が、各 Action Step レコード名として反映されるようになります。

• Change Action 作成権限のないユーザが Change Control または Change Plan を編集しようとした場合、Action Step セクションにある Create ボタンが非表示になります。旧リリースでは、Create ボタンは非表示になっておらず、Change Action 作成権限のないユーザにはエラーメッセージが表示されていました。

• Change Action レコードを編集する際、ユーザは Action Step の割り当てを変更できます。この機能が導入される前は、利用可能な Action Step の一覧が、親 Change Control の Change Action に関連付けられた Action Step のみに絞り込まれていませんでした。今回のリリースから、ユーザは、親 Change Control の Change Action に関連付けられた各 Action Step のみを選択できるようになりました。これにより Change Action が常に、親 Change Control の変更範囲内に定義された Action Step に紐づけられるようになります。

たとえば、次の 1 枚目のスクリーンショットでは、24R3 より前のシステム動作を示しています。Change Action レコードの Action Step フィールドを編集する際、現在の親 Change Control レコードまたは Change Plan レコードで対象外となっている Action Step も含め、すべての Action Step が一覧表示されていました。

24R3 以降、選択できる Action Step の一覧は、親 Change Control レコードまたは Change Plan レコード内にある Action Step のみに限定され、Action Step 名は該当する Action Path に基づいて名付けられます。

アクションパス: Change Action Template のサポート

この機能により、Vault は、Change Action Template から作成された新しい変更アクションを、親の Change Control、Quality Event Change Control、または Change Plan の特定のアクションステップに自動的に割り当てることができます。

この機能が導入される前は、Change Action Template から変更アクションが作成されるたびに、新しい変更アクションは常に親レコードのその他のアクションに割り当てられていました。変更アクションが特定のアクションステップに属している場合、ユーザーは変更アクションを手動で更新して、目的のアクションステップを割り当てる必要がありました。この機能により、変更アクションの 2 次的な手動更新が不要になります。

Change Action Template の作成者は、Change Action Template にアクションステップを割り当てることができるようになりました。

Change Action Template から変更アクションが作成され、テンプレートで識別されたアクションパスおよびアクションステップを親レコードが使用する場合、Vault は新しい変更アクションをそのステップに自動的に割り当てます。

アクションステップ (実装前など) がすでに進行中または終了している場合、ユーザーはそのアクションステップの変更アクションを作成できません。したがって、ユーザーが、オープンではないアクションステップに関連付けられた Change Action Template から変更アクションを作成しようとすると、Vault は変更アクションを作成せず、「Change Action Template がすでに進行中または終了しているアクションステップに関連付けられているため、変更アクションを作成できなかった」という通知がユーザーに送信されます。

組織がすでに Change Action Template とアクションパスおよびステップ機能を設定しているとします。その場合、この機能を有効にするためにシステム管理者に必要な唯一の追加タスクは、Change Action Template オブジェクトレイアウトのセクションに新しい Change Action Template Action Path & Step コントロールを追加することです。

Change Action Template は、単一のアクションパスおよびアクションステップにのみ割り当てることができます。この機能は、親レコードがアクションパスを使用していない場合、Change Action Template から作成された変更アクションには影響を与えません。

外部コラボレーション: サプライヤーアンケート

外部コラボレーションは、お客様がやり取りする必要があるパートナー組織の個人の連絡先リストを維持できるように設計されています。この機能を使用すると、これらの連絡先は Vault への一時的なアクセス権を使用してタスクを受け取り、割り当てられたタスクを完了することができます。その後、Vault によってアクセス権が取り消されます。

24R3 では、企業管理者によって作成され、使用が承認されたチェックリストを完了するために、外部の共同作業者にタスクを割り当てる機能を追加することで、外部コラボレーターを拡張しています。

この機能により、組織はチェックリストを使用して、サプライヤーや委託製造業者にアンケートを送信できます。アンケートを作成および送信することで、新しいビジネスパートナーのオンボーディングを進めつつ、事前監査評価を円滑に実施できます。また、アンケートを作成して、既存のパートナーから情報を収集し、リスクに基づいて追加アクションの必要性を評価することもできます。

この機能を有効にするには、段階的な設定が必要です。External Collaboration: サプライヤーアンケートを設定する方法の詳細については、こちらをご覧ください。

チェックリストを使った作業の詳細をご覧ください。

外部コラボレーション: 外部コラボレーターの変更時にタスクを再割り当て

今回のリリースから、ユーザは任意の External Collaboration レコードの External Collaborator フィールドで新規個人の Person レコードを選択することにより、別の外部コラボレーターにタスクを再割り当てできるようになりました。前の共同作業者にタスクが割り当てられている場合、新しく選択した共同作業者がアクティブ化され、必要に応じてその作業者に対して Vault への招待が送信されます。その後、そのタスクは自動的にキャンセルされ、新しく選択した共同作業者に再割り当てされます。

現状では、ユーザが作業中の QMS レコードで外部コラボレーターの割り当てを変更したい場合には、管理者が External Collaborator フィールドを新しい値に更新した後に手動ユーザアクションを使用するか、進行中のワークフローをキャンセルして新しい外部コラボレーターをタスクに再割り当てする必要があったため、フローが中断されていました。

市場是正措置: ビジネスプロセスの統合と自動化

このリリースでは、Vault QMS に 市場是正措置 (FCA) の正式な管理ツールが導入されました。この機能は MedTech のお客様に対して、市場是正措置 (リコール管理) データモデル機能と併せ、Vault QMS 内で市場是正措置を管理するための新たなプロセスを提供します。これらの機能を併用することで、ユーザは市場是正措置を特定、記録、伝達および実行できるようになります。

まず、FCA は Create Product Tracking Records アクションをサポートします。このアクションは、特定の FCA に関連付けられたロットを自動的に評価し、そのロットの荷受人が組織内部者か組織外部者かに基づいて、適切な Containment または Product Action for Consignees を作成します。自動化には、特定の製品バリエーションのデバイスタイプに基づいて、資本設備デバイスに対する点検要請の作成処理を実行するための決定ロジックが含まれています。

適切な Field Corrective Action - Lot および Lot - Consignee レコードが作成されると、自動化機能によって適切な Product / Material レコードと Tracking レコードが作成され、ロット別の製品返品レコードと点検要請レコード、およびアウトリーチアクションが保存され、市場措置を担当するコーディネーターと所有者に対して適切なフォローアップの実行が促されます。適切なアクションと追跡レコードがすべて作成されると、FCA が自動更新され、その FCA で次の手順に進む準備ができている旨が市場措置の所有者およびコーディネーターに対して示されます。

QMS Vault への FCA アクセスの導入に伴い、FCA 管理をサポートする目的で次の主要な QMS 機能が拡張されます。

• Vault QMS の External Collaboration 機能を介して、外部コラボレーターを HHE プロセスに直接組み込むことが可能になりります。
• 外部関係者は、External Notification 機能によって Product Action の進行状況を常に把握できます。
  • External Notification 機能一式が FCA 管理用途でさらに拡張され、Vault 内で各伝達のメッセージ内容、タイミングおよび受信者を適切なアクションに関連付けて保存する Product Return Outreach レコードが自動作成されるようになりました。

Field Corrective Action: Automations 機能を使用するには、管理者が Vault の Administration > Settings > Application Settings からこの機能を有効にする必要があります。

Field Corrective Actions データモデル

このリリースでは、医療技術企業が市場是正措置とリコールを特定、記録、伝達、実行できる機能が導入されました。そのために、Field Corrective Actions (FCA) や Product / Material Tracking Outreach など、FCA を記録、管理、伝達および追跡するための標準ライフサイクルを備えた新しい標準オブジェクトがいくつか追加されました。

さらに、既存プロセスへのネイティブな統合をサポートするため、Containment、Product Return や Product Variant などの既存のオブジェクトに対して、標準データモデルの機能強化が導入されました。このデータモデルの具体的な変更の詳細については、24R3 Quality データモデルの変更をご覧ください。上述した新規標準オブジェクト定義および変更された標準オブジェクト定義は、リリース時に管理者に表示されますが、FCA 関連レコードを作成して使用するには、設定と有効化 (Administration > Settings > Application Settings) を行う必要があります。Field Corrective Actions に関連付けられた主要なオブジェクトの詳細については、Vault ヘルプをご覧ください。詳細については、今回のリリースに含まれる関連の Field Corrective Action: Automations 機能をご覧ください。

苦情メールプロセッサの更新: Complaint Intake のサポート

組織は消費者や医療従事者からの苦情を受け取ります。多くの場合、これらの苦情は Web サイトやコールセンターを通じて収集され、顧客関係管理 (CRM) システムに記録されます。苦情に品質保証の対応が必要な場合は、Vault QMS で Complaint レコードが作成されます。QMS Complaint レコードを作成するには、次の複数の方法があります。

• 受信した苦情を収集する IT システムとのカスタム統合により、Complaint レコードが自動的に作成される。
• 設定済みの Vault Email Inbox に送信されたメールに基づいて、Complaint レコードが自動的に作成される。
• QMS ユーザーによって Complaint レコードが手動で作成される。

24R2 Release では、QMS のお客様が Complaint Intake レコードと呼ばれる潜在的な苦情を収集し、実際の Complaint レコードに昇格させるかどうかを決定する前に Vault でトリアージできる、新しいオプションが導入されました。潜在的な苦情を作成する方法も複数あります。

• 受信した苦情を収集する IT システムとのカスタム統合により、Complaint Intake レコードが自動的に作成される。
• QMS ユーザーによって Complaint Intake レコードが手動で作成される。

このリリース以降、システム管理者はメールを受信し、受信したメールから Complaint Intake レコードを自動的に作成するよう、Vault Email Inbox を設定できるようになりました。潜在的な苦情の手動作成のみに依存することが不可能な場合や、潜在的な苦情の作成を自動化する別のシステムとのカスタム統合を構築することが不可能な場合は、この機能が役立ちます。Vault は、受信したメールとメール添付ファイルを、この機能で作成された Complaint Intake レコードに保存します。

Vault Email Inbox が、Vault にすでに存在する潜在的な苦情に関するメールを受信した (たとえば、送信者が元のメールに返信した) 場合、追加のメールと添付ファイルは元の Complaint Intake レコードに収集されます。

繰り返しイベントチェック: 編集可能な日付および一致フィールドプロンプト

このリリースでも繰り返しイベントチェックツールへの投資は継続されており、繰り返しイベントチェックを実行するユーザが日付範囲と Matching Fields を上書きできるようになりました。この新しい機能により、管理者は、特定のタイプの繰り返しイベントチェックが呼び出されたときに常に同じ方法でチェックを実行するか、またはチェック方法を柔軟に変更するかを決定できます。これにより、チェック項目ごとにチェックを実行するときに一致候補として返されるレコードの範囲を拡大できます。

この機能が導入される前は、繰り返しイベントチェックによって表面化するのは、たとえば認識日がある特定のレコードの認識日以前であるレコードのみでした。現在では、個々の繰り返しイベントチェックアクションを拡張して、ユーザが選択した任意の日付範囲での問題の再発を考慮できるようになりました。同様に、一致フィールドと日付範囲を必要に応じて調整することにより、繰り返しイベントチェックの期間を変更して「CAPA が X 月 X 日に導入されて以降「この問題」が再発したか」といった質問に焦点を当てることもできます。

この新しい機能を活用するには、管理者が既存の (または新しい) 繰り返しイベントチェックアクションに変更を加える必要があります。繰り返しチェック の詳細については、Vault ヘルプをご覧ください。

繰り返しイベントチェックのダイアログレイアウトの更新

このリリースでは、繰り返しイベントチェック機能専用の UI 設計が更新され、一致基準を表示する新しいレイアウトが導入されました。この新しい UI は、レコードチェックを起動するとき、進行中の繰り返しイベントチェックの結果を更新するとき、および比較ページで View Match Criteria ボタンをクリックしたときに適用されます。

繰り返しイベントチェックデータモデルの変更

今後リリース予定の Recurrence Check 機能に備えて、新しいデータモデルの変更が導入されました。影響を受けるコンポーネントについての詳細は、24R3 Quality データモデルの変更をご覧ください。この機能の詳細については、開発者向け機能をご覧ください。

PDF へのダウンロードをサポートする Email Body レイアウトセクション

このリリースでは、システム管理者向けの新しい設定オプション: Complaint、Complaint Intake、Quality Event Complaints、および Supplier Change Notification オブジェクトの Email Body レイアウトセクションが導入されています。このセクションには、Vault Email Inbox に送信され、Create Complaint または Supplier Change Notification メールプロセッサで処理され、その結果オブジェクトレコードが作成されたメールの内容が表示されます。以下のスクリーンショットは、 Supplier Change Notification および Complaint レコードの Email Body レイアウトセクションの例を示しています。

システム管理者は、オブジェクトレイアウトの Email Body フィールドを新しい Email Body レイアウトセクションに置き換えることをお勧めします。これは、Email Body レイアウトセクションが、24R2 で導入された Print Record 機能をサポートしているためです。Print Record 機能を使用すると、レコードの詳細ページに表示されているレコードのデータを含むダウンロード可能な PDF ファイルを生成できます。Email Body フィールドを Email Body レイアウトセクションに置き換えると、レコード上に表示されるメールの内容がエクスポートされたPDFファイルで読みやすくなります。PDF にエクスポートされたメールの内容は、元のメールのテキストバージョンです。

PDF にダウンロード: Vault QMS 固有のセクションおよびフィールドのサポート

このリリースでは、24R2 の Print Record 機能を拡張し、QMS 固有のアプリケーションコントロールの機能に重点を置いています。次のとおり、これまで Print Record ではサポートされていなかった QMS 全体のコントロールのほとんどがサポートされるようになりました。

• Quality Teams セクション
• Related Events アプリセクション
• Root Cause Analysis Tool セクション
• Notification Recipients セクション
• Risk Builder セクション
• Risk Level Assignment
• Record Check Insights リンク
• Quality Incident Configuration Data

これらのセクションは、Vault QMS の任意のレコードで Print Record 機能を使用すると、ネイティブにレンダリングされるようになりました。アプリケーション全体でネイティブ印刷機能の提供をさらに推進していく中で、今後のリリースでは、さらにいくつかのアプリケーションセクションが追加される予定です。今後のリリースでの更新にご期待ください。

材料と製品のマッピング

このリリースでは、マッピング機能強化を目的としたデータモデルの変更が実装されました。この変更で新しいオブジェクト Material-Product が導入され、Product 階層の任意のレベルに材料をマッピングできるようになりました。 

これにより、材料レベルで変更が加えられたことにより上流で複数の製品に影響が及んでいる場合や、製品レベルで変更が加えられたことにより下流で複数の材料が及んでいる場合など、ユーザが材料と製品の関係を把握しにくい一般的な場面に対処できます。

影響を受けるコンポーネントについての詳細情報は、24R3 Quality データモデルの変更をご覧ください。

変更理由

保健当局はライフサイエンス企業に対して、特定の主要プロセスに関連するレコードのデータフィールドを修正する際には、その変更理由を記録するよう求めています。この機能によりシステム管理者は、Vault QMS で、特定の状態にあるレコードの特定のフィールドをユーザが更新した際に変更理由を要求するよう設定できます。変更理由、変更内容、変更を行ったユーザ、変更日時が Vault QMS に記録されます。

Reason for Change 設定で管理されているフィールドをユーザが編集し、そのレコードを保存すると、変更理由データを収集するために次のようなダイアログが開きます。ユーザは、Reason for Change 選択リストに表示される組織の定義した有効な理由から、1 つを選択する必要があります。選択した理由オプションが裏付け情報必須として設定されている場合、Comments フィールドが入力必須となります。

ユーザが Reason for Change ダイアログの Save ボタンをクリックすると、下図に示すように、そのレコードの各フィールドへの変更が保存され、関連する Reason for Change レコードが自動作成されます。

Reason for Change レコードには、変更内容、変更理由、変更を行ったユーザ、変更日時が含まれます。

以下のスクリーンショットに、システム管理者がオブジェクトおよびオブジェクトタイプ (標準オブジェクトおよび標準オブジェクトタイプのみ) に対して Reason for Change 設定を定義する方法を示します。オブジェクトとオブジェクトタイプそれぞれ 1 つにつき、適用できる Reason for Change 設定は 1 つのみです。Reason for Change 設定 1 つにつき最大 30 件のフィールド (標準またはカスタム) を定義し、指定したライフサイクル状態において変更理由の入力を必須にするよう設定できます。さらにシステム管理者は、Reason for Change 選択リストのうち特定の理由に対して、理由の具体的補足のため Comment の自由テキスト入力を必須に設定することもできます。

Reason for Change 機能の詳細については、Vault ヘルプをご覧ください。この機能の詳細については、開発者向け機能をご覧ください。

24R3 QMS 標準レイアウト & データモデルの更新

24R1 リリースでは、アクション レイアウトの導入により、システム管理者はオブジェクト レコードのフィールドを表示するユーザー エクスペリエンスをカスタマイズできるようになりました。[レイアウト] は、オブジェクト レコードのフィールドを表示用に整理する方法と、フィールドを必須または非表示するタイミングなどを決定するルールを定義します。

24R2 Release では、多くの主要 QMS プロセスに対応した標準レイアウトが提供され、Vault QMS アプリケーションのレイアウト機能が強化されました。標準レイアウトは、QMS アプリケーションに含まれる標準オブジェクト向けの読み取り専用のレイアウトひな形です。標準レイアウトは、オブジェクト レコードをエンド ユーザーに表示する際には使用されません。標準レイアウトは、システム管理者が組織のビジネス要件に合わせてカスタムレイアウトを作成するベースとしてコピーして利用するために提供されています。標準レイアウトの利用により、システム管理者は個別の実装で新しい Action Layout 機能を簡単に適用できるようになりました。システム管理者は、標準レイアウトを編集、削除、アクティブ化したり、デフォルトレイアウトとして設定することはできません。標準レイアウトは、組織のカスタム Layout 制限のカウントには含まれません。

このリリースでは 24R2 で実装された機能向上を継続するため、さらなる QMS プロセスを対象に新しい標準レイアウトを追加しています。また、以前に展開した既存の標準レイアウトへの更新も実装されました。このような変更をサポートするために Vault Quality データモデルが更新され、新しいオブジェクト、フィールドおよび選択リストが含まれるようになりました。

さらにこの機能では、システム管理者の利用できる標準フィールド設定オプションへの更新が多数加わったほか、企業管理者を対象とした選択リストのメンテナンスオプションも導入されています。

24R3 Quality データモデルの変更にある、ダウンロード可能資料へのリンクをご覧ください。その資料には、この機能で導入された Vault Quality データモデルの変更、設定更新および選択リストのメンテナンスオプションがすべて記載されています。

Surveillance

eMDR: Section F

24R3 では、医療機器の輸入業者として機能する組織は、FDA に eMDR を提出できるようになりました。Vault Product Surveillance の一般的な方向性に沿って、eMDR の標準レイアウトは eMDR Section F データの操作をサポートするようになりました。既存のお客様は、この機能の導入の一環として、eMDR レイアウトに Section F アプリケーションセクションを追加できます。

eMDR フォームの Section F を取得およびサポートするための新しいメタデータフィールドが、Vault Product Surveillance の Adverse Event Reports およびサポートしている Complaints オブジェクトと MedTech Complaint Details オブジェクトに追加されました。この機能を使用するには設定が必要です。このセクションを eMDR プロセスに最も適切に実装する方法については、eMDR 標準レイアウトの例を確認することを強くお勧めします。これには、関連性のあるセクションのみをユーザーに表示するなど、ユーザーの集中力を維持する方法の例も含まれています。

報告価値評価の機能強化: 複数の意思決定ツリー

この機能によって複数の意思決定ツリー作成が可能になり、Vault QMS および/または Vault Product Surveillance をご使用の企業を対象とする Reportability Assessment 機能が強化されます。シンプルでグローバルな意思決定ツリーの導出方法を重視する組織では、その方法を実践できます。一方、より細かな意思決定パターンを必要とする組織では、評価者はこの意思決定ツリーをガイドとして使用することにより、特定の苦情に関連付けられたメタデータに基づいてより詳細な評価を行うことができ、報告価値に関する意思決定の精度と追跡可能性が向上します。Vault は Reportability Assessment の実行中に、Country of Incident や Product Variant、製品販売国、インシデント国の報告価値要件などのメタデータ、および意思決定ツリーで設定可能なその他の属性に基づき、特定の評価に該当する意思決定ツリーを自動的に選択およびプロビジョニングします。

使用に適した意思決定ツリーが自動選択されるだけでなく、特定の苦情 1 件に対して、その苦情に関連するメタデータに基づいて複数の意思決定ツリーをインスタンス作成する必要性も考慮されているため、影響を受ける各国に関する苦情を考慮しやすくなります。

ユーザが Create Reportability Assessment アクションを実行すると、該当する苦情のメタデータおよび意思決定ツリーの設定に基づいて個々の評価が作成されます。このアクションは、エントリアクションを用いてトリガーすることもできます。

最後に、Vault Product Surveillance が有効に設定されている場合は、該当する苦情に関連付けられた報告価値決定ツリーの結果に基づいて、必要な有害事象レポートが自動作成されます。Vault QMS および Vault Product Surveillance 内の報告価値評価ツールの詳細については、Vault ヘルプをご覧ください。

バッチリリース

ドキュメントをチェックに追加

この機能を使用すると、Batch Disposition Execution ページから計画外のドキュメントをチェックに追加し、処分が決定されるまでそれらのドキュメントを監視できます。この機能を有効にするには、Batch Disposition Check Requirement の Allow Add Documents フィールドを True に設定します。追加アイコンがチェックに表示され、これをクリックすると、チェックに追加するドキュメントを選択するための Add Document ダイアログが開きます。追加したドキュメントごとに、Disposition Check Item が作成されます。

Batch Release でのロールの割り当て

この機能により管理者および品質管理者は、各ロールに割り当て可能なユーザと、割り当て時に付与するアプリケーションロールを管理できます。Disposition Role 割り当ては、その子 Batch Disposition Checks にプッシュダウンされます。資格および割り当ての管理をより容易にしながら報告価値の高い割り当てを実現する目的で、この機能は、アプリケーションセキュリティや動的アクセスコントロール (DAC) を含め現状の Vault Platform セキュリティ機能に基づいて構築されています。

Check オブジェクトのクラスの変換

Batch Disposition Check オブジェクトは、User Task オブジェクトクラスタイプとして再実装されました。オブジェクト batch_disposition_check__v は batch_disposition_check_task__v に移行しました。User Task オブジェクトでは、ユーザに割り当てられた各レコードはホームページに表示されます。

レポート作成用系図

新たに追加されたバッチ系図機能では、新しいオブジェクト Batch Genealogy (batch_genealogy__v) 内に Batch Disposition が作成されると、レポート作成に使用できるバッチ関係レコードが自動作成されます。Batch Genealogy は処理するバッチに合わせてフラット化され、処理するバッチが Genealogy の最大 20 階層ですべてのバッチと関連付けられている状態となります。すべての Batch Disposition レコードが終了すると、その 1 か月後に、終了済みの各レコードはジョブで削除されます。Batch Disposition 終了時には、設定済みの任意のレポートを使用して PDF ドキュメントを作成できます。

Validation Management

管理者定義のリストレイアウト

24R3 では、管理者は Validation Requirements、Discrepancy、および Test Step Change レコードのベストプラクティスリストレイアウトを定義できます。既存のユーザーは、該当するオブジェクトデータグリッドに移動し、Restore defaults ハイパーリンクをクリックすることで、これらのレイアウトを採用できます。これにより、テスト作成、事前承認、テスト実行、および事後承認の UI でこれらのオブジェクトに対して表示される列のデフォルト設定が復元されます。24R3 以降に Vault に追加された新しいユーザーは、管理者が定義した設定をデフォルトのリストレイアウト設定として自動的に継承します。

テストステップの添付ファイル表示の機能強化

24R3では、Vault Validation Management によって、テストステップカードにおけるテストステップ添付ファイルの表示方法が機能強化されました。添付ファイルの種類に応じてアイコンが表示されるようになりました。この変更は、テストスクリプト実行インターフェース、テストスクリプトレビューインターフェース、およびテストプロトコルレビューインターフェースのテストステップカードに影響を与えます。

テストプロトコルのコピー

24R3 Release に伴い、Vault Validation Management ユーザは、テストプロトコルのコピー操作時に、すべての子テストステップ、追加プロンプト、共同作成者、およびそのテストプロトコルの再実行・再作成要件を含め、選択したテストスクリプトごとコピーできるようになりました。Copy アクションを実行すると、ユーザは新しいテストプロトコルにコピーする対象テストスクリプトとコピー先の Validation Deliverable を選択できます。この機能を使用するには設定が必要です。

テストスクリプトのコピーの機能強化

24R3 では、Vault Validation Management でのテストスクリプトに対する既存のディープコピー機能が強化され、Test Script レコードコピー機能のより広範な用途がサポートされるようになりました。この機能強化により、ユーザはテストスクリプトを別の Validation Deliverable や別の Test Protocol へとコピーできるようになります。さらに管理者は、エントリアクションを設定して、テストスクリプトを次の状態へと移行する前に、テストスクリプトに関連付けられているすべての検証要件の状態を検証できます。この機能を使用するには設定が必要です。

Approved 要件に対するデフォルトの要件バーンダウンフィルタ

24R3 より前は、ライフサイクル状態に関係なく、すべての要件 (ユーザー、機能、設計仕様) が要件バーンダウンビューに表示されていました。24R3 では、管理者はテストスクリプトの作成時に、要件バーンダウンビューから特定のライフサイクル状態の Validation Requirements をテスト作成者にデフォルトで表示するかどうかを決定できます。

管理者は、ライフサイクル状態を Validation Requirement Lifecycle の Approved 状態タイプに関連付けるオプションを使用できるようになりました。Approved 状態タイプが設定されていない場合、要件バーンダウンビューには、ライフサイクル状態に関係なくすべての要件が表示されます。テスト作成者は、他のライフサイクル状態の要件および仕様を表示する場合でも、デフォルトのフィルタを変更できます。これは、他のチームメンバーが要件を同時に作成している間に、先行してスクリプトを作成する場合に行われる可能性があります。

PDF にダウンロード: Vault Validation 固有のセクションおよびフィールドのサポート

24R3 では、Vault Validation Management の Download to PDF アクションに含めることができるアプリケーション管理フィールドが増え、さまざまなオブジェクトページレイアウトや、Validation Entity Version オブジェクトページレイアウトの Requirement Entity Version アプリケーション管理セクションにある、Requirement Owner、Activity Owner、Deliverable Owner、Author、Executor、Witness、Discrepancy Owner、Template Requirement、Co-Authors などのフィールドがサポートされるようになりました。各アプリケーション管理フィールドはプレーンテキストとして印刷されます。各アプリケーション管理セクションは、Validation Requirement オブジェクトで設定されたリストレイアウトに基づいて印刷されます。この機能は自動的にオンになります。

テストスクリプトのドライラン

24R3 では、スクリプト作成者は事前承認への提出前にテストスクリプトのドライランを開始することにより、スクリプトの正確性を検証できます。これにより、スクリプト作成者は検証チームメンバーに対してテストスクリプトのドライラン実行を要請できるようになりました。ドライラン実行者として割り当てられたユーザは、コメントの提供、テストスクリプトの問題特定、および改善点の提案を行えます。作成者が実行者のコメントに対処することにより、事前承認へのテストスクリプト提出前にスクリプトの品質を改善できます。この機能はデフォルトでは全 Validation Management ユーザに表示されるとは限らず、この機能を使用するには、既存の権限セットの変更などの設定変更が必要です。

テスト作成 UI でのテストステップカードの読み込みを最適化

この機能を使用すると、テスト作成者がテスト作成インターフェイスを開くと、各ステップの読み込みアイコンではなく、すべてのプロンプトの実際のサイズですべてのステップが表示されます。この読み込み動作により、データの読み込み後に不要なスクロールを行わずに済みます。

要件バーンダウン検索バー

24R3 では、テスト作成者はバーンダウンパネルから Validation Requirement オブジェクトのユーザー要件、機能要件、または設計仕様に存在する任意のフィールドを検索できるようになりました。新しい検索バーは、テスト作成インターフェイスの要件バーンダウンビューに表示されます。これによりテスト作成者は、特定の要件をすばやく見つけることができ、また、要件をテストステップまで追跡して、それらが検証されることを確認できます。

Validation Management: 標準の機能強化

24R3 で Validation Management アプリケーションは、アプリケーションの標準化を支援するために、標準データモデルおよびコンポーネント設計を継続的に強化しています。例として、さまざまなオブジェクトにさまざまな標準日付やキャンセル関連のフィールドを追加しています。このリリースでは、管理者が Vault Validation Management の標準オブジェクトから動的アクセスコントロール (DAC) 属性 (カスタム共有ルールや一致共有ルールなど) を有効にできないようにするコントロールも導入しました。これは、セキュリティが Validation Teams 機能によって管理されており、管理者が DAC を有効にすると不要な複雑さが生じるため、お客様に避けていただきたいからです。この変更は自動的に有効になるため、すべてのお客様は、24R3 Release 前の標準オブジェクト (たとえば、 val_requirement_svo__v や val_activity__v) で DAC を有効にしていないことを確認する必要があります。

また、組織が Validation Requirement オブジェクト (val_requirement_svo__v) で Configuration Specifications を管理しやすくするための新しいオブジェクトタイプも導入しています。オブジェクトタイプは非アクティブですが、24R3 がリリースされたら、テストスクリプトの作成、実行、またはレビュー/承認に関与するユーザーに対して、このオブジェクトタイプへの Read 権限を最低限付与する必要があります。さらなるガードレールを確実に設置するために、テストスクリプトごとに 500 のテストステップというハードリミットを導入しました。これは、24R3 Release で自動的に有効になります。

LIMS

サンプル結果の入力

管理者はこの機能により、主にサンプルのテスト結果を転記するために使用されるテストを設定できます。こうしたテストを使用して、結果をすばやく入力できます。この場合、実行メソッドが不要になり、入力をログに記録する必要もなく、クロステスト変数や集計結果もありません。

検出限界と定量限界

この機能により、Test Definitions および Test Definition Variations の検出限界 (LOD) と定量限界 (LOQ) の値を定義できるようになります。また、入力された結果が他のテスト結果の値を計算するために必要であり、LOD を下回っている場合に、使用する計算値を定義する機能も導入されています。入力されたテスト結果がそのテスト定義の LOD または LOQ を下回っている場合、システムはユーザーにその旨を表示します。システムは、テスト定義/バリエーションで定義された計算値も使用します。

Prevent Self Approval

LIMS Prevent Self Approval は、規定されたアクティビティに基づいてユーザーをレコードロールに配置します。次に、これらのロールをワークフローの役割分離の一部として設定して、特定のロールがワークフローに参加できないようにすることができます。その後、LIMS は次のことを実行します。

• ユーザーが Lab Test Result または Lab Test Input を入力または変更した場合は、そのユーザーを Contributed to Test Execution ロールに配置します
  • 共有設定は、Lab Test、Lab Sample、および Spec Execution レコードに対する手動ロール割り当てによって更新されます
• ユーザーが Lab Test のピアレビューに関与する場合は、そのユーザーを Contributed to Test Execution ロールに配置します
  • カスタムアクション: Cascade Contributor Roles を実行するには、追加のワークフロー設定が必要です
    • 共有設定は、Lab Test、Lab Sample、および Spec Execution レコードに対する手動ロール割り当てによって更新できます
• ユーザーが Study、Study Time Point、または Study Action レコードを作成または変更した場合は、そのユーザーを Contributed to Stability ロールに配置します
  • 共有設定は、変更されたレコードに対する手動ロール割り当てと、変更されていないレコードの Study によって更新できます
• ユーザーが Test Definition または子レコード、Sample Plan または子レコード、Spec Data または子レコードを作成または変更する場合は、そのユーザーを Contributed to Spec Data ロールに配置します
  • 共有設定は、変更されたレコードに対する手動ロール割り当てと、変更されていないレコードの Study によって更新できます

この機能を完全に有効にするには、次の設定が必要です。

1. ワークフローの役割分離を使用して、目的のワークフローからコントリビュータロールをブロックします (たとえば、Contributed to Test Execution はピアレビューワークフローに参加できない)
2. Lab Test、Lab Sample、または Spec Execution ワークフローでカスタムアクションを使用して、ワークフロー参加者を Contributed to Test Execution にカスケードします

Test Definition Variation

この機能により、既存の Test Definition Result と入力に基づいて、Test Definition 内でバリエーションを作成できるようになります。実行時に、Test Definition Variation を使用して作成されたテストには、Test Definition Variation で定義された結果と入力が含まれます。

この機能の一部として、次の 3 つの新しいオブジェクトが導入されています。

• Test Definition Variation
• Test Definition Variation Result
• Test Definition Variation Input

対応する Test Definition Input から Test Definition Variation Input が作成される場合は、Test Definition Input から次のフィールド値がコピーされます。次のフィールド値は Test Definition Variation Input レベルで変更でき、実行時に適用されます。

• Expected Amount (消耗品の場合)
• Expected Amount Units (消耗品の場合)
• Required

上記にリストされていないフィールドは、対応する Test Definition Input (Test Definition Step を含む) に基づいて定義されます。

対応する Test Definition Result から Test Definition Variation Result が作成される場合は、Test Definition Result から次のフィールド値がコピーされます。次のフィールド値は Test Definition Variation Result レベルで変更でき、実行時に適用されます。

• Calculation Formula (数値型の結果の場合)
  • 該当する変数は Test Definition Result レベルで定義する必要があります
• Data Class
• Data Entry Method
• External Name
• Notation (数値型の結果の場合)
• Picklist (選択リスト型の結果の場合)
• Precision (数値型の結果の場合)
• Precision Type (数値型の結果の場合)
• Required
• Rounding Rule (数値型の結果の場合)
• Unit of Measure (数値型の結果の場合)

上記にリストされていないフィールドは、対応する Test Definition Result (Test Definition Step を含む) に基づいて定義されます。

次の表は、3 つのバリエーションを持つ pH 分析の Test Definition の例を示しています。各バリエーションには同じ Test Definition Input が含まれますが、Test Definition Result は異なります。灰色のセルは、バリエーションに含まれていない (したがって、実行時に結果として作成されない) Test Definitions Result を示します。平均 pH の計算式もバリエーション 2 とバリエーション 3 では異なります。

テスト定義バリエーションの作成はオプションです。ただし、テスト定義に 1 つ以上のバリエーションがある場合、実行時テストは、ベースのテスト定義からではなくバリエーションからのみ作成できます。

このリリースでのみ、同じテスト定義バリエーションを持つ臨床検査をテストセットに組み合わせることができます。

テスト実行ユーザインターフェース (UI) の機能強化

24R2.2 では、テスト定義バリエーションが導入されました。バリエーションのあるテストに対応するためにテスト実行 UI が更新され、バリエーションによる各テストの違い (異なる単位を持つ結果、結果が特定のバリエーションには適用されても別のバリエーションには適用されない場合、バリエーション間の入力モードの違いなど) を視覚的に表示するように更新しました。UI の変更は、テスト定義バリエーションを使用中かどうかに関係なく、すべてのお客様に対して自動オン機能が適用されます。

このリリースでは、複数のテストを同一テストセットに追加するためには、各テストの Lab Test の入力値が完全に同一である必要があります。 

テスト実行 UI には、他にもいくつか追加変更が導入されています。

• Lab Test Inputs 入力セルと Results 入力セルは、Lab Test Step 完了前にはオープン/編集モードになります。入力必須セルは黄色で表示され、入力任意のセルは白色で表示されます。 
• 入力値は、Test Definition で定義した順序で表示されます。
• 1 つの Lab Test Set 内に複数バリエーションのテストがある場合、Results グリッド内では各バリエーションに色が割り当てられます (下のスクリーンショットを参照)。 
• (Test Definition に応じて) Method Document が表示されている場合、Lab Samples リストは圧縮されず、ユーザはスクロールして Lab Samples をさらに表示できます。
• Lab Test Step が完了した後に Lab Test Input または Lab Test Result に変更を加えるためには、ユーザは変更したい入力セルの Actions > Edit を使用できます。
• 計算結果および統合結果の上書きは、ユーザのユーザアカウントに必要なロールが割り当てられている限り、上書きしたい入力セルの Actions > Manually Override Result から行えます。 

ユーザがバリエーションに対応したテスト実行 UI を利用するには、次のオブジェクトへの Read 権限が必要です。

• Test Definition Variation
• Test Definition Variation Result
• Test Definition Variation Input

バリエーションのないテスト実行時の UI 例:

バリエーションのあるテスト実行時の UI 例:

その他のテスト実行ユーザインターフェース (UI) の機能強化

更新されたテスト実行 UI には、以下の機能強化が追加されました。

• ユーザはキーボードの矢印キーを使用して、Results グリッド内をナビゲートできるようになりました。選択したセルで Enter キーを押すことで結果を編集でき、Tab キーや Shift + Tab キーを使用してグリッド内をナビゲートすることもできます。
  • 入力グリッド内では、矢印キーを使用してナビゲートすることはできませんが、Tab キー、および Shift + Tab キーを使用してグリッド内をナビゲートすることができます。
• アラート例外アイコンの色が、黄色からオレンジ色に変わりました。
• 消耗品を選択するためのロジックとして、消耗品は状態タイプが「Available」であり、有効期限がないか、有効期限が現在の日付以降である必要があります。
• 以前に手動で上書きされた計算値が、その後再計算された場合 (計算で使用される結果が変更された場合など)、「以前に手動で上書き済み」の情報を示す、次の感嘆符アイコンが結果セル内に表示されます。

変更分析マージの追跡

管理者はこの機能により、変更分析を Review や Approval などの下流ワークフローに向けて送信する前に、変更分析がマージ済みであることを確認できます。

Lab Test の適合性追跡

この機能では、Lab Test に適合性フラグが追加されました。適合性を満たさない結果が見つかった Lab Test では、Conforms フィールドの値が false に設定されます。

以前に完了したテスト手順の追跡

ユーザが結果または入力内容に変更を加えると、Lab Test Step の完了フラグが true から false へと切り替わります。この機能では次の各要素が追加され、各手順が過去に完了済みであるかどうかを明確に追跡できるようになりました。

• 各 Lab Test Step に新しい Previously Completed フィールドを追加
• システムで Previously Completed フィールドを設定するロジック
• 既存の LIMS Vault で Previously Completed フィールドを設定するためのデータ移行

安定性試験の機能強化

使いやすさを向上させるために、安定性機能に次の変更が加えられました。

• Lab Study Design および Lab Study レビューページへの変更点は次のとおりです。
  • 右上隅に Exit Overview アイコンを追加しました
  • Create Design Data Copy アイコンを削除しました
  • ブレッドクラムトレイルを削除しました
  • レコード名 (Lab Study Design または Lab Study) がハイパーリンクになりました
• Lab Study Design レコードから Lab Study レコードを生成する際に、結果の Lab Study の名前を入力するように求められるようになります。名前が入力されない場合、結果の Lab Study には Lab Study Design レコードと同じ名前が付けられます。

• 初期時点 (たとえば、時点 0) に対応する安定性の Spec Executionで Results Spec Execution フィールドが入力されている場合 (つまり、バッチリリースの Spec Execution の場合)、再評価基準ロジックに次の変更が加えられます。
  • 安定性の Spec Execution レコード内でラボ基準評価レコードを生成および評価する際には、Results Spec Execution 内で有効な (Invalid = No) Lab Criteria Evaluation レコードのみが使用されます。
  • システムにより、少なくとも 1 つの Lab Criteria Evaluation レコードの一致があることを確認し、一致しない場合はエラーが表示されます。
  • Evaluate = “On Demand” の基準セットに属する Lab Criteria Evaluation レコードは、安定性の Spec Execution レコードでは生成されません。
• 開始された治験の時点から安定性の Spec Execution が作成されると、Spec Execution に次のフィールドが追加され、Study Time Point レコード内の対応する値に基づいて入力されます。
  • Time Stored
  • Time Stored Units

LIMS のライフサイクルユーザアクションをワークフロー手順としてサポート

この機能により、次のアクションをワークフローシステムアクションとして設定するためのサポートが追加されます。 

• Spec Execution の開始
• 基準の再評価
• Lab Study の開始
• Study Timepoint の開始
• 再サンプリングして保存
• アリコートサンプルの生成

Spec Execution 開始ロジックのハーモナイゼーション

この機能では、次の変更が導入されました。

• 変更分析については、Spec Data レコードにバージョン検証/完了アクションチェックが追加されました。このアクションチェックは、各 Sample Definition の Pull/Select Count 合計値 (pull_count__v) が同一 Sample Definition の Sample Collection Count 値 (sample_collection_count__v) 以下になるよう保証するためのものです。このチェックは、Aliquot タイプまたは Pool タイプの Spec Data Sample Action レコードを一切含まない Spec Data レコードのみを対象としています。 

• アプリケーション設定 Enable Full Sample Action Automation が削除されたとともに、Spec Execution 開始ロジックが 1 つのプロセスに統合されました。それに対応するため、すべての LIMS Vault で次の各フィールドにデータを入力する移行作業が進められています。

上記設定が有効になっていない Vault の場合 (Aliquoting 機能が有効になっていない場合、大部分の Vault に該当) は、以下のとおりです。

• Spec Data レコード:

  • initial_sample_auto_action_v = TRUE/YES に設定

• オブジェクトタイプが spec_data_pull_sample_action__v の Spec Data Sample Action レコード

  • auto_complete__v = TRUE/YES に設定
  • auto_match__v = TRUE/YES に設定
  • auto_generate__v = TRUE/YES に設定

• 次のオブジェクト/フィールドのオブジェクトレベル既定値を TRUE/YES に更新します。

  • lims_spec_data_v - lims_spec_data_sample_action_v
  • lims_spec_data_sample_action_v - auto_complete_v
  • lims_spec_data_sample_action_v - auto_match_v
  • lims_spec_data_sample_action_v - auto_generate_v

• Spec Execution レコードのいずれかが Initiated 状態になく (initiated__v = false または initiated__v = null/空白)、かつ initial_sample_auto_action_v フィールドが null/空白の場合は、initial_sample_auto_action_v フィールドを TRUE/YES に設定します。 

設定が有効になっている Vault (Aliquoting 機能が有効になっている Vault) の場合:

• initial_sample_auto_action__v = null/空白に設定されているすべての Spec Data レコードで、initial_sample_auto_action_v を TRUE/YES に設定します。タイプ spec_data_pull_sample_action__v のオブジェクトを持つ関連の Spec Data Sample Action レコードについて、次のフィールドのいずれかが空白/null または false/no になっている場合は、以下のようにフィールドを更新します。

• auto_complete__v = TRUE/YES に設定
• auto_match__v = TRUE/YES に設定

• auto_generate__v = TRUE/YES に設定

• 仕様の initial_sample_auto_action__v が TRUE/YES または NO/FALSE に設定されている Spec Data Sample Action レコードすべてに関しては、当該レコードおよび関連する Spec Data Sample Action のいずれにも更新は適用されません。

• Spec Execution レコードのいずれかが Initiated 状態になく (initiated__v = false または initiated__v = null/空白)、かつ initial_sample_auto_action_v フィールドが null/空白の場合は、initial_sample_auto_action_v フィールドを true/yes に設定します。 

• Enable Full Sample Action Automation 設定が有効になっていない Vault では、Spec Execution を開始すると、異なるユーザメッセージが表示されます。ユーザには、Spec Data の設定に応じて次のいずれかのメッセージが表示されます。

  • Spec Execution Auto Action has successfully completed for Spec Execution <record name>. (Spec Execution <レコード名> の Spec Execution 自動アクションが正常に完了しました。)
  • Spec Execution Auto Sample Matching did not occur for Spec Execution <record name>.Reason: one or more Lab Samples could not be located to perform auto-matching. (Spec Execution <レコード名> の Spec Execution 自動検体照合が実行されませんでした。理由: 自動照合を実行するために必要な 1 つまたは複数の Lab Samples が見つかりませんでした。)
  • Spec Execution Auto Sample Matching could not be completed for Spec Execution <record name>.Reason: one or more Lab Samples could not be located to perform auto-matching. (Spec Execution <レコード名> の Spec Execution 自動検体照合が実行されませんでした。理由: 自動照合を実行するために必要な 1 つまたは複数の Lab Samples が見つかりませんでした。)Refer to the following unmatched Spec Execution Sample Action record(s): <record name>. (Spec Execution <レコード名> の Spec Execution 自動検体照合を完了できませんでした。理由: 自動照合を実行するために必要な 1 つまたは複数の Lab Samples が見つかりませんでした。次に示されている未照合の Spec Execution Sample Action レコードを参照してください: <レコード名>。)

Material Detail ページの Mapping セクションに Spec Data を表示

この機能によりユーザは、Material Detail ページの Spec Data Mapping 関連リストに Spec Data 列を追加できます。管理者は、Vault REST API を使用して Pagelayout に Spec Data 列を追加できます。Pagelayout とマークアップの取得方法、新規 Pagelayout の実行と保存、および XML 文字列の設定についての詳細は、次のリンクを参照してください。

Spec Data Sample の Deep Copy アクション

この機能により、ロック解除された Spec Data Sample アクションに、次の内容をコピーする Deep Copy アクションが追加されます。

• Select/Pull Spec Data Sample アクションと、それに関連する Test Sample アクションおよび Spec Data Criteria レコード。 
• Test Sample アクションとそれに関連する Spec Data Criteria レコード。

Spec Data Sample の Deep Delete アクション

この機能により、ロック解除された Spec Data Sample アクションに、次の内容を削除する Delete アクションが追加されます。

• Select/Pull Spec Data Sample アクションと、それに関連する Test Sample アクションおよび Spec Data Criteria レコード。
• Test Sample アクションとそれに関連する Spec Data Criteria レコード。

Quality データモデルの変更

24R3 Quality データモデルの変更をご覧ください。

Regulatory

以下のリリースノートに加えて、Vault RIM Registrations と Vault RIM Submissions、Publishing、および Archive の Veeva Connect コミュニティでは、General Release に関するお知らせ、リリースの注目機能、主要な機能のデモが提供されています。

Vault Connections セクションに記載されている以下の機能も、Regulatory アプリケーションファミリーに影響を与えます。

• RIM と PromoMats: 製品データの転送
• RIM と Clinical Operations: Clinical Crosslink での治験のデフォルト設定ロジックを強化
• RIM と Clinical Operations: Clinical Study フィールドルールの更新
• RIM と Clinical Operations: EU 固有の Clinical CrossLink の処理
• Safety と RIM の接続強化

すべての RIM アプリケーション

RIM ボットの機能強化

今回のリリースでは、RIM ボットに多数の機能強化が追加されました。トレーニングセットの最適化により、モデルのトレーニングおよびテスト時に単一分類につき抽出されるドキュメント数が制限されます。この上限設定により、モデルをより多数の異なる分類に基づいてトレーニングできるようになります。

自動モデル更新により、トレーニング済みモデルが各 Vault General Release ごとに自動的に再トレーニングされるため、RIM ボットの良好な精度を長期的に維持するうえで役立ちます。24R2 で RIM ボット: すべての RIM Vault で自動オン の一部としてリリースされた自動トレーニングジョブは、すべての Production Vault で無効にされている場合も有効になり、無効化設定が防止されます。この自動再トレーニング機能により、システムに追加された新しいドキュメント分類が、RIM ボットの自動分類で検討されるようになります。

多言語モデルのサポートにより、RIM ボットのトレーニング対象範囲が英語ドキュメントだけでなく、英語以外のドキュメントにも拡張されます。

最後に、新たに追加されたワンクリックアクション Retrain Model を使用すると、各 General Release 間において手動でモデルを再トレーニングする作業が効率化されます。クリック数が削減され、手順が自動化されることにより、必要に応じたモデルの再トレーニングを行いやすくなります。

RIM Registrations

薬剤主導複合配合製品のサポート

このリリースでは、Create Registrations が強化されており、Co-Packaged または Integral Device が Yes に設定されている場合に複合製品の Registered Product レコードが生成されるようになりました。RIM データモデルの更新は前回のリリースで完了しました。この機能強化により、IDMP 要件である、提出データセットに共通パッケージ機器および一体型機器を含めることが可能になります。

Create Registrations で Procedure の国を設定可能

この機能を使用すると、RIM Registrations を一括で作成する際に、ハードコード化された国リストに頼るのではなく、設定 (Constraints を含む) を使用して Procedure タイプの国を管理することができます。Constraints の Region Specific Entry に設定された Health Authority フィールドは、その Constraints を参照する登録に対して設定されます。たとえば、保健当局が地方保健当局ではなく EMA である必要がある場合、中央管理手順 (CP) に設定されます。

この更新の理由には BREXIT が含まれ、規制の更新に基づいて国リストを複数回更新する必要がありました。このリストを設定可能にすることで、現在サポートされている CP の国リストを制限しやすくなります。同時に、EU CP と同様に動作する手順を実装する可能性のある地域に対して、今後および既存のサポートを提供できるようになります。

Create Related Records: 拡張された変更管理のサポート

今回加えられた Create Related Records ウィザードの更新により、製品関連の変更を、ラベル関連の変更追跡と類似した方法で、より詳細なレベルで追跡できるようになりました。製品関連の変更は、複数のイベントやアクティビティに紐づけられるため、柔軟性が向上します。

既存のお客様への影響: 拡張された変更管理の使用をご希望のお客様は、Event オブジェクトおよび Activity オブジェクトの各ページレイアウトに Product Changes セクションを追加する必要があります。Event Product Change レコードへの入力を開始すると、Create Related Records ウィザードによって入力済みレコードが Activity Product Changes に伝播されます。

Create Related Records: 検証機能の強化

この機能強化は、ユーザが Create Related Records アクションを実行した際の既存の検証を更新するものです。Event データに基づいて適時かつ動的な検証が実行されるよう設計されています。幅広いユースケースがサポートされているため、変更管理のサポートに必要なローカルデータを迅速かつ正確に伝播できます。

以下に、この機能強化で対処できるユースケース例を示します。

• Shelf Life の詳細が、関連する Packaging がない Regulatory Objective や Submission にプッシュされるのを防止する
• 関連する Packaging が存在する場合にのみ、新しい Packaging Site を追加する
• Registration がまだ存在しない場所での新しい製品承認
• 新規 Registration の作成を必要とする変更
• 申請に含まれていない (多くの場合、対照薬や参照品を含む) 新しい治験薬の追加

プレビューでは、ユーザレビューの支援機能として、潜在的なデータ品質の問題が提示されます。たとえば、Event の詳細情報に一致する既存の Application 関係が複数ある場合、プレビューではこのような Application 関係をレビューし、Regulatory Objective および/または Submission へコピーするよう促されます。

動的検証を意図したとおりに使用するには、ユーザが完全な Application 関係のセットを用意しておく必要があることにご注意ください。

既存のお客様への影響: 検証ロジックは、管理者設定 Enable dynamic validation for Create Related Records で有効化できます。前提条件として、Enable Application Relationships 設定が有効になっている必要があります。

Activity Dependency の機能強化

部門横断型であると判断された Event であれば、単一の Event にも複数タイプの依存関係を含めることができます。この機能はよくあるユースケースに対応したもので、ラベル表示以外の Event の Activities でラベル表示への影響が特定された場合 (たとえば、製造変更によりラベル表示への影響が特定された場合など) に、ラベル表示固有の Activity Dependency レコードを作成できるようになります。また、この機能により Application レベルで Country Dependency を指定できるようになります。これにより、Application に基づく依存関係を、異なる複数の市場、同一市場内、および同一 Application 内で適用することが可能になります。

既存のお客様への影響: アプリケーション設定で Rerun dependency checks when labeling impact is identified を有効にします。新しい Reference Application フィールドと Dependent Application フィールドをCountry Dependency オブジェクトおよび Application Dependency オブジェクトの各ページレイアウトに追加します。

Manage Registered Details のフィルタリングの機能強化

Manage Registered Details (MRD) ウィザードは、レコードの検索を絞り込んで更新を容易にするために、テキストフィールドに追加のフィルタ機能を備えています。これらのフィルタは、テキスト値と空白 (未定義) フィールドの検索をサポートしています。この機能は、Create Registrations ウィザードでも使用できます。

この機能により、より少ないクリック回数でレコードをより簡単かつ迅速に識別、選択、更新できるため、登録された詳細情報の更新が効率化され、容易になります。

eAF レポート生成の機能強化

Regulatory Objective から eAF レポートを生成する際には、同一の医薬品に関する既存レポートが置き換えられ、最新レポートのみが利用可能となります。これにより、経時的に重複したレポートが蓄積するのを防ぐことができます。

この機能強化は、eAF レポート生成を設定済みで、Medicinal Product および Regulatory Objective フィルタがレポートに設定されているすべての Vault で自動的に利用可能になります。

Registration Verification ワークフローでの複数レビュー手順のサポート

この機能により Registration Verification ワークフローが強化され、追加レビュータスクの設定がサポートされるようになりました。複数のレビュー手順を含む Registration Verification マルチレコードワークフローでは、未検証のレコードの裁定を Rejected に設定します。この変更以前の Vault では、CSV 結果ファイル内で裁定が Unknown に設定されていました。未検証のデータは削除されますが、この機能強化により実際の判定がより適切に表されるようになりました。

RIM Submissions

RLCP ドキュメントの GCP に対する自動照合

今回のリリースで、CTD モジュール 4 および モジュール 5 内のドキュメント照合先を、特定の Report Level Content Plan (RCLP) 内のドキュメントに制限できるようになりました。

ユーザは、Event Clinical Studies および Event Nonclinical Studies の作成時に、関連する RCLP を選択できます。選択した RLCP 値は、グローバルコンテンツプラン内の対応する試験関連セクションに伝播され、照合基準として使用されます。

Copy Content Plan アクションが Use for Content Planning フィールドを尊重

Copy Content Plan アクションを使用すると、コンテンツプランニングに使用される関係のみが、Submission レコードと Application レコード、およびターゲットの提出コンテンツプランにコピーされます。以前は、Copy Content Plan アクションは、Registration にのみ使用するよう指定されているものも含め、ソースの Submission からすべての関係レコードをターゲットの Submission とその親アプリケーションにコピーしていました。

Use for Content Planning フィールドが設定されていないか、No に設定されている場合、参照される関係は除外されます。Use for Content Planning = Yes または空白の場合、関係は対象の Submission に含まれます。結果通知には、関係設定が No であるため、指定された CP セクションがコピーされなかったというメッセージが含まれます。また、ターゲットの Submission にすでに設定が No である関係がある場合は、そのターゲットの Submission 設定が尊重され、その関係はターゲットに含まれません。

この機能強化により、Copy Content Plan ユーザーアクションが実行される際に、コンテンツプラン、Submission レコード関係、および Application 関係で必要なクリーンアップ作業が削減されます。この機能強化は、Submission レコードから実行される Copy Content Plan アクションにのみ影響を与え、既存の CP にセクションを直接ドラッグアンドドロップする操作には影響を与えません。ソースの Submission で Use for Content Planning = No に設定されているものも含め、ターゲット内のすべての関係が必要な場合は、コンテンツプランをコピーするのではなく、Submission レコード自体をコピーできます。

RIM Registrations、RIM Submissions

Content Plan Item Template Mapping のコピー作成が有効

展開の一環として Sandbox のスナップショットを作成したり環境のコピーを作成したりする際に、Content Plan Item Template Mapping (CPITM) (content_plan_item_template_mapping__v) レコードが含まれるようになりました。24R2 でリリースされた Dispatch Global Content Plan Across Templates 機能を設定する際に、CPITM オブジェクトレコードは Vault Loader または VPK 経由でのみ移行できました。この機能強化により、Dispatch Global Content Plan Across Templates の導入がより簡単かつ効率的になります。

GCP ディスパッチの検証

管理者はこの機能を使用することにより、グローバルコンテンツプラン内の関連レコードのライフサイクル状態に対する検証を設定できます。この機能により、グローバルコンテンツプランにバージョンロック済みのドキュメントのみを、Document Set 別または Country 別にグローバルコンテンツプランからディスパッチすることもできます。これにより、まだ完了していないドキュメントのディスパッチを防ぐことができます。

新たに加わった各種アプリケーション設定で、対象の Submission と各アクティビティのライフサイクル状態を検証できます。グローバルコンテンツプランの送信ユーザアクションに追加された新しいオプションから、一致した各ドキュメントがロック済みになっているかを送信前に検証できます。

詳細については、GCP ディスパッチの検証の設定をご覧ください。

RIM Submissions Archive

Submissions Archive ビューア: 規制項目別の通信のフィルタリング

Submissions Archive ビューアに表示される通信文書を、関連する規制項目別にフィルタリングできるようになりました。この機能強化より前は、Correspondence は Application または Submission によってのみフィルタリングできました。Regulatory Objective 列を含む新しい Correspondence サブセクションを、新規または既存の保存済みビューに追加できます。この追加のフィルタリングオプションにより、アーカイブの利用者は、選択した規制項目内のすべての提出書類に関連する保健当局の通信、または通信に Application および少なくとも 1 つの規制項目が設定されている保健当局の通信を確認できます。これは、通信文書が複数の規制項目に関連付けられている場合に特に役立ちます。

このリリースでは、Regulatory Objective の関連付けは、カスタム通信文書フィールド regulatory_objectives__c または標準ドキュメントフィールド regulatory_objectives__v (24R2 で導入) のいずれかから取得できます。Admin > Settings > Application Settings > Submissions Archive Features の新しい一時的な有効化オプションは、システムがカスタム関係を指すのか、標準関係を指すのかを決定します。

regulatory_objectives__c カスタムドキュメントフィールドを使用している、24R2 より前にプロビジョニングされた RIM Vault は、カスタムドキュメントフィールドから標準ドキュメントフィールドに移行することなく、この新機能をすぐに使い始めることができます。今後のリリースではこの設定は廃止されるため、その時点ですべてのお客様は、この属性をビューアで表示するために標準 regulatory_objectives__v ドキュメントフィールドを使用する必要があります。廃止については、今後、リリースノートのお知らせを通じて通知されます。一時的な設定を提供することで、お客様はドキュメントフィールドの値を標準フィールドに移行する時間を確保しながら、Regulatory Objective フィルタリングの利点をすぐに享受できるようになります。

Submissions Archive ビューア: ミニブラウザウィンドウのサイズ拡大

ポップアウトから Submissions Archive ドキュメントを開いた際に表示されるミニブラウザウィンドウの幅が拡大され、開いているドキュメントの表示可能なレンディションおよび情報パネルが一度に表示されるようになりました。

インポート通知の更新

Submissions Archive のインポート通知が強化され、サポートされていない設定によりインポートができない場合 (例: Submissions Archiveで管理する Document Types でドキュメントフィールドが Required に設定されている場合) にユーザに通知します。システムによって以下のメッセージが表示されます。

設定がサポートされていないため、システムではこのアクションを完了できません。以下のシステム管理の Document Types の 1 つ以上の Document Fields が Required に設定されています。

• Submissions Archive (archive__v)
• Submissions Archive > Content (archive_v.content_v)
• Submissions Archive > Structure (archive_v.structure_v)

EU eCTD v3.1

このリリースでは、Submissions Archive は、eCTD 提出用の EU モジュール 1 仕様バージョン 3.1 を使用して、欧州連合の提出書類のインポート、表示、およびエクスポートをサポートしています。

WHO eCTD v1.1

このリリースでは、Submissions Archive は eCTD 提出用の WHO-PQT 仕様バージョン 1.1 を使用して、WHO の提出書類のインポート、表示、およびエクスポートをサポートしています。

ECOWAS eCTD v1.0

このリリースでは、Submissions Archive は、eCTD 提出用の ECOWAS 仕様バージョン 1.0 を使用して、ECOWAS の提出書類のインポート、表示、およびエクスポートをサポートしています。

RIM Submissions、RIM Submissions Archive

Active Dossier での追加ステータスの追跡

この機能では、アクティブドシエ内における追加の規制承認シナリオの追跡がサポートされるようになりました。

• 新しいアクティブドシエのステータス:
  • Dispatched, Not Submitted
  • Rejected
  • Withdrawn
  • No Decision
• 新しく追加された Approval Type フィールドに、各ドキュメントが関連付けられている承認タイプを Explicit (明示的)、 Implicit (黙示的) あるいは Partial (部分的) から選択記録できるようになりました。
• ディスパッチ済みでありながら未提出の文書は、空白ではなく Dispatched, Not Submitted ステータスに設定されます。
• Regulatory Objective ライフサイクル状態に新しく追加された設定可能なエントリアクションにより、更新後の新しいステータスへの変更および Approval Type の設定に対応したアクティブドシエステータスの変更を自動化できます。
• グローバルコンテンツプランからアクティブドシエへの自動入力が更新されました。Local Disposition が Dispositions requiring submission after implementation または Dispositions for immediate implementation without additional activity に設定されているアクティビティに対して、Active Dossier 項目詳細 (ADID) が作成/更新されます。このようなアクティビティに作成された ADID の Approval Type は Implicit Approval に設定されます。

この新しいエントリアクションは設定が必要ですが、それ以外の上記機能はすべて自動的にオンになります。また、新しい Approval Type フィールドは Active Dossier Loader ではまだサポートされていませんが、今後のリリースで追加される予定です。

アクティブドシエ計算の更新: Pending Current への変更対象の絞り込み

このリリースでは、規制項目の承認によってトリガーされるアクティブドシエの自動計算ロジックが更新され、計算保留中に移動される対象レコード範囲がさらに絞り込まれました。Vault ではこれまで、関連する規制項目に属する全ステータスの候補レコードを Pending Current に設定するよう提案されていましたが、今後は Submitted ステータスの候補レコードのみを Pending Current に更新するようになります。これにより、一部のシナリオにおいて Active Dossier Item Details から Pending Current への変更を促す予期しない提案が防止されます。

アクティブドシエホバーカードの更新: Needs Submission

アクティブドシエビューアの項目詳細ホバーカードが更新され、Needs Submission フィールドが追加されました。これにより、ユーザーは、グローバルコンテンツプランが提出コンテンツプランにディスパッチされたときに、ドキュメントを提出する必要があるかどうかを確認できます。

アクティブドシエ翻訳処理の更新

アクティブドシエ生成のこの機能強化は、同じソースドキュメントの複数の翻訳が同時に提出された場合に、より関連性の高い翻訳追跡をサポートします。ADID の Country レコードと Vault の Country Language レコードに基づいて、新しい ADID レコードごとに Translation Document フィールドを設定します。国に複数の言語があり、翻訳が複数ある場合、Vault は ADID に最初のインスタンスを設定します。

Active Dossier ビューア & エディタの機能強化

この機能により Active Dossier ビューアおよびエディタが強化され、操作性が向上し、ユーザがアクティブドシエへの定期的更新や修正作業を行いやすくなりました。

Active Dossier ビューアには、次のような自動オン式の変更が加えられました。

• 新たな 2 つのレイアウト Country Overview および Item Detail が導入されました。
  • ユーザは、Submission、Regulatory Objective、および Event で Edit Active Dossier アクションを実行すると、Item Detail レイアウトに移動します。
• Item Detail レイアウトに新しい編集ボタンが導入されました。
• Current/All/Pending の表示切り替えがステータスセレクターに置き換えられ、表示したい各アクティブドシエ状態をより的確に選択できるようになりました。

次の機能が追加された、改良版 Active Dossier エディタも導入されました。

• Active Dossier Item Details レコードに対する、次のアクションによる個別または一括更新がサポートされました: 編集可能なフィールドの Editing、Deletion、Confirm Pending (保留ステータス変更を行う場合)。
• エディタ上で Deletion アクションおよび Confirm Pending アクションの実行や、アクティブドシエ状態の更新を行うと、国ステータスアイコンが自動更新され、Apply Pending Status Changes アクションを追加で実行する必要がなくなります。
• 各更新の進行状況と結果を追跡できるようになりました。
• ユーザが Edit または Delete アクション (Confirm Pending アクションは含まれません) を実行した際に、理由および任意のコメント入力が強制されるようになりました。
• Active Dossier エディタでは、保存済みビューがサポートされなくなりました。同様の保存済みビューの作成は、Active Dossier ビューアで行うことが推奨されます。

RIM Publishing

FDA 同期ゲートウェイプロファイルの廃止

RIM Vault では、すべての FDA 同期ゲートウェイプロファイルが削除され、ESG からの提出には使用できなくなりました。これは、廃止に関する 23R3 のお知らせ に対応するための更新です。すべての FDA ゲートウェイプロファイルは、FDA 非同期ゲートウェイプロファイルに移行する必要があります。

ソースドキュメントのオーバーレイ解像度をサポート

オーバーレイを使用したパブリッシングにおいて、さらなる柔軟性が得られるようになりました。現在、パブリッシング要素はパブリッシュ済みドキュメントのメタデータに基づいてトークンを解決するため、ドキュメント番号などが、マージされたドキュメントのすべてのページで同じ値になります。

今回の更新により、パブリッシング要素の新しい Picklist フィールドである Source of Published Overlay を使用すると、パブリッシュ済みドキュメントの値ではなくソースドキュメントの値に基づいてオーバーレイトークンの値を入力できます。特に、パブリッシュ済み出力をマージする場合、オーバーレイトークンは、コンテンツプランアイテムに一致するソースごとに異なる値に解決されます。この機能を実装すると、ソースドキュメントを起点に、マージされたパブリッシュ済み出力に至るまでの追跡可能性が向上し、マージされたドキュメントのより正確なナビゲーションがサポートされる可能性があります。例:

デフォルトでは、パブリッシング要素の Source of Published Overlay 選択リストフィールドが Published Document に設定されていない限り、Vault ではメタデータ情報のソースとして常にソースドキュメントが使用されます。

パブリッシングの事前検証の更新

Publishing 手順に進む前に、さらなる事前検証チェックが追加されました。

システムの生成した目次が 2500 行を超えると、パブリッシングおよび目次生成が失敗します。Publishing ステータスアイコンから、ユーザに表示される例外の CSV をダウンロードできます。

検証結果のアーカイブジョブの更新

検証結果のアーカイブジョブで、実際の提出日から 90 日後にアーカイブパッケージの ZIP ファイルが作成されるようになります。旧リリースでは、このパッケージは提出日の 365 日後に作成されていました。この変更により、お客様の Vault 内の不要なレコードが削減されるとともに、過去の提出時の検証結果にアクセスしやすくなります。検証結果のアーカイブジョブは、25R1 リリース以降すべての Vault でアクティブになります。

ファイル名検証ルールロジックのベストプラクティスの更新

各地域で許容されるファイル名をより正確に検証するため、以下の地域ルールの検証基準ルール ID が更新されました。

• CH: RuleCH15.BP3 (15.BP3)
• EU: Rule15.BP3 (15.BP3)
• GCC: RuleGCC13 (13)
• JO: RuleJO13 (13)
• TH: RuleTH15.BP3 (15.BP3)
• TW: RuleTWO.BP2 (OBP2)

上記の各検証基準ルール ID では、ルールロジックの変更は自動的にオンになります。

カナダ保健省検証ルールにより任意セクションについて警告を発するよう更新

検証ルール G.06 および G.08 に関するカナダ保健省の要件をより適切にサポートするため、新しい検証基準が 2 つ作成されました。今回追加された検証基準は、インデックスリーフに任意の属性が存在するかをチェックし、存在しない場合は警告として報告します。

既存の検証ルール G.06 および G.08 が更新され、必須のリーフ属性のみに関して報告するようになりました。

この機能には、検証基準の更新が必要です。これらの変更は、VPK パッケージを通じてカスタマーサポートチームに提供できます。ご使用の Vault に更新を適用しなかった場合は、ルール G.06 およびルール G.08 の新しいロジックのみが有効になります。

NeeS カナダ検証

カナダ保健省の eCTD 未提出書類 (NeeS) を公開するお客様は、HC NeeS v5.2 検証基準に基づいて公開出力を検証できるようになりました。

この機能には、検証基準の更新が必要です。これらの変更は、VPK パッケージまたはサポートポータルを通じてカスタマーサポートチームに提供できます。

HC NeeS v5.2 をサポートするためのすべての検証ルールおよびデータモデル更新は、VPK パッケージを介してカスタマーサポートチームに提供できます。

EU eCTD v3.1 の公開

このリリースでは、Vault Submission Publishing において、EMA eCTD ガイダンス v3.1 および検証 v8.0 に基づく EU ドシエの公開と検証がサポートされています。

この機能には、検証基準の更新が必要です。これらの変更は、VPK パッケージまたはサポートポータルを通じてカスタマーサポートチームに提供できます。

WHO eCTD バージョン 1.1 の公開

このリリースでは、Vault Submission Publishing において、WHO eCTD ガイダンス v1.1 および検証 v1.1 に基づく WHO ドシエの公開と検証がサポートされています。

この機能には、検証基準の更新が必要です。これらの変更は、VPK パッケージまたはサポートポータルを通じてカスタマーサポートチームに提供できます。

NeeS EAEU Publishing のサポート

このリリースでは、Vault Submission Publishing は、EAEU R0.22 仕様の v.1.1.0 に基づく EAEU 非 eCTD の公開をサポートします。EAEU Publishing をサポートする追加のオブジェクトおよびフィールドの作成については、RIM データモデルの更新を参照してください。

この機能には、検証基準の更新が必要です。これらの変更は、VPK パッケージまたはサポートポータルを通じてカスタマーサポートチームに提供できます。

RIM Publishing、RIM Submissions

マージ時における目次のページ番号処理を更新

マージを実行した場合の目次生成で、コンテンツプラン構造内における目次コンテンツプランアイテムの順序が考慮されるようになりました。

マージ対象のコンテンツプランアイテムが含まれるコンテンツプランセクションの上部、中央、あるいは下部に目次がある場合、目次の全体的なページ番号割り当てが、目次最上位のコンテンツプランセクション行に正確に反映されます。これまでは、目次がマージ対象の最初の Content Plan Item ではない場合、全体的なページ番号割り当てが正しく表示されないことがありました。

Regulatory データモデルの変更

詳細については、24R3 Regulatory データモデルの変更をご覧ください。

Safety

すべての Platform 機能を含む Safety 24R3 リリースは、2024年 11 月 27 日および 2024 年 12 月 13 日に暫定公開を予定しています。Safety Vault のCentral Dictionary の最新の更新については、Safety Central Dictionary の更新をご覧ください。

Vault Connections セクションに記載されているいくつかの機能も、Safety アプリケーションファミリーに影響を与えます。

Safety

送信者ベースのメールインボックスアイテムの事前入力

このリリースでは、Vault Safety は送信者のメールに基づいて、Inbox Item の Country フィールドと Report Type フィールドを自動的に設定できるようになりました。この機能により、管理者はトランスミッションプロファイルのこれらのフィールドに事前に入力することで、冗長なデータ入力を削減できます。Vault Safety では、このようにマップされた値を使用して Inbox Item が作成され、ユーザはこれらをより効率的にトリアージして割り当てられるようになります。この改善により、受信メールのトリアージが高速化され、データの繰り返し入力が不要になります。

この機能は自動オン仕様ですが、一部のコンポーネントでは追加の設定が必要です。

詳細

• 有効化: 送信者ベースのメール添付ファイル取扱いの有効化
• ユーザヘルプ: インボックスアイテムへのメール

Inbox Item フィールド: Report Type & Seriousness

このリリースでは、フィルタリングと優先順位付けをサポートするために、Inbox Item オブジェクトに Report Type フィールドと Seriousness フィールドが追加されました。このデータは、Vault が E2B や JSON 統合または Vault to Vault Connections (EDC と Safety の Connection など) から取得した構造化データから Inbox Items を生成する際によく含まれます。Report Type (Clinical または Post-Marketing) と Seriousness は、レポートのタイムラインに影響を与えます。Priority と Seriousness は、ユーザが Inbox Item に新しい情報を追加する際に計算され、コンプライアンスを確保するために Inbox Items のトリアージの優先順位を決定できるようになりました。

この機能は自動オン仕様ですが、一部のコンポーネントでは追加の設定が必要です。

詳細

• 有効化: Inbox Item の有効化
• ユーザヘルプ: Inbox Item の概要

重複 E2B XML ファイルの検出

このリリースでは、Vault Safety はインボックスアイテムにすでにインポートされている E2B XML ファイルを検出できます。管理者はトランスミッションプロファイルでこの設定を有効にすることができ、ユーザは手動でアップロードされたファイルにこの設定を適用できます。重複した E2B XML ファイルが検出されると、Vault Safety はインボックスアイテムを重複としてマークし、ソースドキュメントを元のドキュメントにリンクします。さらに、Vault Safety は ZIP ファイルの個々の E2B XML ファイルの元のファイル名を保持し、トレーサビリティを強化します。この機能強化により、MHRA や EMA などの保健当局から複数の E2B ファイルをインポートする際に、重複する E2B XML ファイルの検出が自動化されます。

この機能は自動オン仕様ですが、一部のコンポーネントでは追加の設定が必要です。

詳細

• 有効化: 受信トレイアイテムへの E2B インポートの有効化
• ユーザヘルプ: インボックス項目のインポート

重複インボックスアイテムのリンク

重複検出を実行した後、インボックスアイテムが重複としてマークされると、Vault は新しく追加された Linked Inbox Item フィールドで、重複したインボックスアイテムに一致する Inbox Item レコードをリンクします。この機能を使用すると、既存のインボックスアイテムに関連付けられている重複したインボックスアイテムを、簡単に識別して追跡できます。

詳細

• ユーザヘルプ:
  • Inbox Item フィールドの参照: System セクション
  • インボックスアイテムのフォローアップ: インボックスアイテムを症例比較ページに記入する

オンラインアンケートの回答をフォローアップインボックスアイテムへインポート

今回のリリースの Vault Safety では、オンラインアンケートの記入完了後にインボックスアイテムを作成する際、オンラインアンケートの回答がインボックスアイテムにインポートされるようになりました。Vault Safety では、管理者によって複数のアンケートデザインに適用できる標準の質問フィールドマッピングがプロビジョニングされるため、事前入力および回答インポートの設定を高速化できます。ユーザは、インポートされた回答を直接インボックスアイテムで、あるいは Inbox Item to Case Compare ページで確認できます。この機能強化によりフォローアッププロセスが簡素化され、手動によるデータ入力が最小限に抑えられるため、オンラインアンケートの回答処理の効率が向上します。

詳細

• 有効化: オンラインアンケートの回答のフォローアップインボックスアイテムへのインポートを有効化する
• 管理者ヘルプ: フォローアップオンラインアンケートの設定: 質問フィールドマッピングの作成
• ユーザヘルプ: 症例連絡先にフォローアップオンラインアンケートを送信する: アンケート完了後の手順

症例アクセスグループセキュリティ: インボックスアイテムの Study Type の更新

インボックスアイテムで Study が指定されていないが Study Type が参照されている場合、Vault は症例アクセスグループを割り当てる基準の一部として、Study Type を使用するようになりました。この機能強化は、Vault の Study ライブラリに設定されていないパートナーの治験の市販後調査などのシナリオをサポートします。インボックスアイテムと症例の両方の Study Type を考慮することで、Vault はより一貫性のある症例アクセスグループの割り当てを可能にします。

詳細

• 管理者ヘルプ: 症例アクセスグループのセキュリティ管理: Case Access Group Assignment フィールド

CDMS 被験者情報に対する症例アクセスグループ

今回のリリースにより、Vault Safety では、Safety-EDC Vault Connection から受信した EDC 被験者情報オブジェクトデータへのアクセスを症例アクセスグループに基づいて制限する機能がサポートされるようになりました。旧リリースでは、ユーザは全アクセスグループの被験者情報にアクセスできました。この機能により、個人を特定できる情報 (PII) をより細かく制御できるようになるため、セキュリティが大幅に向上し、コンプライアンスが強化されます。

詳細については、Safety と EDC の接続の設定をご覧ください。

症例処理中の重複検出

このリリースでは、ユーザは症例処理中に重複検出を実行して、現在の症例レコードを他の症例やインボックスアイテムと比較できます。症例処理担当者は、データ入力後に重複を識別できます。この機能強化により、手動での重複検出の労力が軽減され、過剰報告が緩和されます。

詳細

• 有効化: 症例処理中の重複検出を有効にする
• ユーザヘルプ: 症例の重複検出

最新の治験登録データのフォローアップ症例への反映

Vault Safety では、Study ライブラリにある最新の治験登録が、各フォローアップ症例バージョンへとスナップショット保存されるようになりました。Case Study Registrations セクションには、更新後の情報が自動的に反映されます。旧リリースでは、Create Follow-up アクションを使用した場合、Case フォローアップレコードには、初回症例作成後に追加された Study Registration レコードおよび詳細情報は反映されていませんでした。この機能によりコンプライアンスが強化され、症例処理担当者が意思決定に必要な最新データを利用できるようになります。

詳細

• ユーザヘルプ:
  • 症例データの入力: Study Registration フィールド
  • 提出と配布の概要: 提出書類の生成

グローバルインボックスアイテムからの国内症例のフォローアップ

このリリースでは、Vault Safety により、ユーザはグローバルインボックスアイテムから国内症例のフォローアップを作成できるようになりました。Global タイプまたは空白のローカリゼーションを持つインボックスアイテムの場合、インボックスアイテムで一致する国内症例を選択した後、ユーザは選択した国内症例のフォローアップ症例を Inbox Item to Case Compare ページで作成できるようになりました。この機能強化により、ユーザは各国内の症例について英語で受信したフォローアップを効率的に処理できるようになります。

詳細

• ユーザヘルプ: インボックスアイテムのフォローアップ: ローカライズされたデータ

ローカライズ済みの症例ナラティブ言語をフォローアップ情報に基づいて更新

このリリースでは、更新済みのローカリゼーション値を持つインボックスアイテムを既存の国内症例にマージすると、Vault Safety によって Narrative ドキュメントの ISO 言語が新しい値に更新されるようになりました。以前は、フォローアップでローカリゼーションが更新されても、Narrative ドキュメントは最初の症例のローカリゼーションにリンクされたままでした。この機能強化により、症例ドキュメントの正確性と一貫性が確保されます。

詳細

• ユーザヘルプ: インボックスアイテムのフォローアップ: マージ動作

ローカライズ済み症例: フォローアップでのグローバルナラティブの上書き

今回のリリースで管理者は、関連するグローバル症例ナラティブに基づいて、ローカライズ済み症例の既存のローカライズ済みナラティブを上書きするアクションを設定できるようになりました。Vault で Sync Global Narrative to Local Narrative アクションを実行すると、ローカライズ済みナラティブドキュメントがバージョンアップされ、既存のコンテンツがグローバルナラティブドキュメントのコンテンツに置き換えられます。このアクションにより、フォローアップでグローバルナラティブからローカライズ済みナラティブへとコンテンツをコピーする手作業が不要になります。この時間短縮に役立つ機能により、症例処理ワークフローが合理化され、ローカライズ済み提出物のコンプライアンスが向上します。

詳細

• 有効化: ローカライズ済み症例: フォローアップでのグローバルナラティブの上書きの有効化
• ユーザヘルプ: ローカライズ済み症例の準備

ローカライズ済み症例: フォローアップでの国内ナラティブの上書き

この機能は、ローカライズ済み症例: フォローアップでのグローバルナラティブの上書き機能を国内症例ナラティブへと拡張するものです。ユーザはローカライズ済み症例に対して Sync Global Narrative to Local Narrative アクションを使用することにより、関連する国内症例ナラティブに基づいて、既存のローカライズ済みナラティブを上書きできるようになりました。Vault でこのアクションを実行すると、ローカライズ済みナラティブドキュメントがバージョンアップされ、既存のコンテンツが国内ナラティブドキュメントのコンテンツに置き換えられます。このアクションにより、フォローアップで国内ナラティブからローカライズ済みナラティブへとコンテンツをコピーする手作業が不要になります。この時間短縮に役立つ機能により、症例処理ワークフローが合理化され、ローカライズ済み提出物のコンプライアンスが向上します。

ローカライズ済み症例: フォローアップでのグローバルナラティブの上書き機能が有効化されている Vaults では、この機能は自動的にオンになります。

詳細

• ユーザヘルプ: ローカライズ済み症例の準備

海外言語でローカライズした症例フォローアップへの各グローバルフィールドの同期

Vault Safety には、海外言語でローカライズした症例フォローアップに対して Transmission が作成された際に、ローカライズ済み症例のすべてのテキストフィールドを関連するグローバル症例の最新テキストで上書きするオプションが追加されました。旧リリースの Vault では、グローバルテキストフィールドの値は、ローカライズ済みフォローアップ症例で空白になっているローカライズ済みテキストフィールドにのみコピーされていました。

詳細

• ユーザヘルプ: ローカライズ済み症例の準備

症例バージョンの比較 ID

このリリースで Vault Safety には、全症例バージョン中の Case Adverse Event レコードや Case Product レコードなどの症例子レコードを識別するための ID が導入されました。この機能により、症例バージョン比較時の一致精度が向上します。

詳細

• ユーザー ヘルプ: 症例バージョンの比較

リンク付き症例コピー

Vault Safety では、症例 1 件につきコピーを最大 100 件作成できるようになりました。症例コピーには、コピー元症例のすべての親レコードと子レコード、および各カスタムフィールドが含まれます。これらのコピーではコピー元症例 の各種ドキュメントとのリンクが維持され、監査ログには症例がコピー作成された日時が明確に示されます。コピー元症例には、Vault で作成されたコピー数が表示されます。この機能により、特に文献症例・法的症例やその他お客様固有のニーズに対応する場合において、症例処理の効率が大幅に向上します。

詳細

• 有効化: リンク付き症例コピーの有効化
• ユーザヘルプ: 症例コピー

盲検化製品情報の隔離を設定済みの治験での一括盲検解除

今回のリリースにより Vault Safety では、Vault で盲検化製品情報の隔離機能を設定済みであり、試験群 を含まない治験 に対して、臨床試験症例の一括盲検解除がサポートされるようになりました。ユーザは治験の終了時に、関連する各症例を効率的に盲検解除できます。この機能では、治験継続中の各症例は未変更のまま残される一方、過去に盲検解除済みの各症例から盲検保護が削除され、盲検化された各症例の治験製品情報が自動入力されます。この機能強化により、治験終了時の盲検解除プロセスが合理化されます。

詳細

• 有効化: 盲検化製品情報の隔離を設定済みの治験での一括盲検解除を有効にする
• 管理者ヘルプ: 隔離された盲検化製品情報の一括盲検解除

盲検化された治験製品に対するデータシートの予測可能評価

今回のリリースで Vault Safety では、盲検試験症例の盲検化された治験製品に対して、Expectedness レコードを生成できるようになりました。管理者はこの機能を使用して、試験群を含まない二重盲検治験を設定する際に、データシートを治験製品プレースホルダー に関連付けることができます。Expectedness レコードの自動生成により、メディカルレビュー担当者は関連付けられたデータシート内にある関連するすべての値にアクセスできるようになり、盲検化された症例レビュー時の包括的評価に役立てることができます。

詳細

• 有効化: 盲検化された治験製品に対するデータシートの予測可能評価の有効化
• 管理者ヘルプ: データシートと自動予測可能の管理
• ユーザヘルプ: ローカライズ済み症例の準備

データシートの Expectedness Justification を症例評価にコピー

今回のリリースにより、Vault Safety では、データシートにある有害事象の予測可能性の根拠を症例評価にコピーできるようになりました。データシート に新しく追加された Expectedness Justification フィールドに入力すると、Vault は入力されたテキストを症例評価の期待度とローカライズ済み症例評価にマッピングします。旧リリースでは、データシート内で根拠を検索する作業に時間がかかっていました。根拠がマッピングされることにより、PMDA E2B(R3) レポートその他参考事項等 (J2.11) データ要素への正しい値のエクスポートが保証されます。この機能強化は PMDA 規制要件を満たしており、症例評価の効率向上につながります。

詳細

• 有効化: データシートの Expectedness Justification の症例評価へのコピーを有効にする
• 管理者ヘルプ: データシートと自動予測可能の管理
• ユーザヘルプ: 症例評価の期待度をどのように生成するか

10 年単位の年齢条件に基づく予測可能性評価の更新

年齢条件に基づく予測可能性が設定されている Vault では、10 年単位で入力された患者年齢に基づいて予測可能性を評価する際に、指定した 10 年単位の年齢範囲における上限値と下限値の両方を考慮して予測可能性評価が実行されるようになりました。たとえば、Number フィールドに 2、Unit フィールドに Decade と入力して患者の年齢を 10 ～ 20 歳の範囲内であると指定し、ある有害事象が 2 ～ 12 歳の年齢範囲でのみ予期されるとデータシート上で指定されている場合、指定した 10 年単位の年齢の上限値がこの年齢範囲に含まれないため、Vault では、この場合の有害事象は「予期されない」とみなされるようになりました。

詳細

• 管理者ヘルプ: データシートと自動予測可能の管理
• ユーザヘルプ: 症例評価の期待度をどのように生成するか

症例アップバージョンなしの MedDRA 一括再コード

このリリースでは、MedDRA 一括再コードを実行する際に、Vault Safety は最新の症例バージョン (オプションとしてすべての症例バージョン) で、組織によって直接定義された現在の MedDRA 用語を使用して、最新ではない用語を再コードするようになりました。以前は、Vault Safety によってマイナーバージョンが作成され、症例が再度開かれたため、ユーザはこれらの症例を終了する必要がありました。この機能により、MedDRA 一括再コードプロセスが効率化されます。

この機能は自動的にオンになりますが、ご使用の Vault で最新の症例だけではなく、すべての症例を一括再コード化するよう設定することもできます。

詳細

• 有効化: MedDRA 一括再コード症例を有効にする
• 管理者ヘルプ: 症例の MedDRA コード化用語の一括再コード化

症例の治験製品選択用の複数製品セレクタ

症例のプロモーション後に治験製品を選択しやすくするために、23R2 でインボックスアイテム用にリリースされた機能を拡張し、各症例で Specify Study Products アクションを実行できるようになりました。症例処理担当者は 1 つの症例に対し、複数の治験製品を一度に追加できるようになりました。この機能強化により、各インボックスアイテムや症例全体に対し、治験製品の入力の一貫性が確保されます。特に、多数のフェーズや製品が含まれる複雑な治験において、症例処理の効率性が向上します。

詳細

• 有効化: 症例の治験製品選択用の複数製品セレクタを有効にする
• ユーザヘルプ: 治験製品のコード化と閲覧

Product Indication が NullFlavor の場合に MedDRA コードを自動的に設定

このリリースでは、ユーザが Product Indication の Reason Omitted フィールドで nullFlavor を選択すると、Vault Safety は自動的に Name (MedDRA) フィールドを Drug use for unknown indication (10057097) へと設定します。この機能強化により、ICH E2B(R3) 仕様の G.k.7.r.2b に関連するビジネスルールへの準拠が保証され、データ入力が効率化されて、有害事象報告の精度が向上します。

詳細

• ユーザヘルプ: 症例データの入力

MedDRA のライセンスチェック

今回のリリースでは Vault Safety に、MedDRA 辞書更新プロセスの前提条件としてお客様の会社の MedDRA 認証情報の検証が追加されました。Vault で MedDRA 辞書をアップグレードする際には、Validate Dictionary License アクションで MedDRA ライセンス情報を検証できます。認証情報が無効な場合、Vault ではエラーメッセージが表示され、更新プロセスを続行できなくなります。この機能強化によりお客様の組織における MSSO ライセンス要件への完全な準拠が確保されるとともに、不正な更新を防ぎ、規制基準の維持に役立てることができます。

詳細

• 有効化: MedDRA のライセンスチェックの有効化
• 管理者ヘルプ: MedDRA 辞書の管理

JDrug および WHODrug Cross Reference Tool

WHODrug および JDrug 辞書が設定されている Vault では、対応する JDrug 外部製品 がコード化されている場合、Vault Safety では WHODrug Cross Reference Tool のライセンス所有者は WHODrug 製品を自動的にコード化することができ、その逆も同様です。この機能により、IDF および WHODrug コードを直接照合することで、時間のかかる二重コーディングがなくなり、より正確なコーディングがサポートされます。

詳細

• 有効化: JDrug および WHODrug Cross Reference Tool の有効化
• 管理者ヘルプ: WHODrug Cross Reference Tool (CRT) Japan の管理
• ユーザヘルプ:
  • Japan Drug Dictionary 製品のコード化
  • WHODrug 製品のコード化

DME ウォッチリストの更新: 免疫性血小板減少性紫斑病 (10074667)

今回のリリースでは、MedDRA 用語「免疫性血小板減少症 (10083842)」の最新情報を反映するため、DME リストの用語「免疫性血小板減少性紫斑病 (10074667)」 が更新されました。この機能強化で DME リスト内の廃止済み用語に対応することにより、報告要件への準拠を徹底することができます。

QC チェックリストの更新

今回のリリースで Vault Safety には、症例チェックリストの機能強化がいくつか導入されました。管理者は、カスタム状態および非標準状態で Checklist rules アクションを設定できるようになりました。ユーザは、チェックリスト生成ワークフローの一環として、あるいはレコードアクションを使用して、処理中チェックリストを生成できます。管理者はテスト目的で、必要に応じて終了後の QC チェックリストを生成できます。さらに今回のリリースで、終了後 QC チェックリストの生成間隔で「四半期ごと」と「年次」の各オプションは廃止されました。この機能により、QC チェックリスト生成プロセスにおける柔軟性とユーザ制御が大幅に向上します。

詳細

• 有効化: QC チェックリストの生成を有効にする
• 管理者ヘルプ: QC チェックリスト生成ルールの設定: チェックリスト作成ルールの作成
• ユーザヘルプ: QC チェックリストの生成: QC チェックリストの生成

FDA 対象の「最後にもう一度レポート作成」の改善

今回のリリースで Vault Safety では、バージョン間でトランスミッションプロファイルが切り替わる状況を回避するため、米国食品医薬品局 (FDA) への「最後にもう一度レポート作成」で、より堅牢な評価がサポートされるようになりました。旧リリースでは、症例に (いずれも自社所有の) 承認済み生物学的製剤および承認済み医薬品が含まれている場合、Vault は重複したトランスミッションを生成していました。

詳細

• ユーザヘルプ: 最後にもう一度レポート作成

NullFlavor フィールド用の設定可能な PII および E2B マスク化

このリリースでは、Vault Safety は nullFlavors を含めるように、Exceptions to PII Masking Safety ルールセットパラメータを拡張しています。マスク化されたレポートを生成するユーザが Exception to PII Masking Content Protection フィールドで Null Flavors を選択した場合、Vault は、生成されたレポートの Personal Identifiable Information (PII) フィールドで nullFlavor 値をマスク化しません。代わりに、Vault はレポートの Case から nullFlavor 値を入力します。以前は、Vault はマスク化されたレポートの nullFlavors の代わりに、「MSK/Privacy」をエクスポートしていました。情報が含まれていないフィールドをマスク化すると、そのフィールドに情報が含まれているかのように見せかけることができるため、この機能はコンプライアンスと明確性に対応しています。

詳細

• 有効化: NullFlavor フィールド用の設定可能な PII および E2B マスク化を有効にする
• ユーザヘルプ:
  • レポート作成ルールパラメータの参照: Exceptions to PII Masking
  • マスク化された安全性レポートの生成: Exceptions to Patient Content Protection

症例レベルの報告可能性表示

今回のリリースで Vault Safety には、症例作業負荷の優先順位付けをさらに簡素化するため、Case Reportability 分類が導入されました。管理者は、Case ページで新たに追加された Case Reportability フィールドを追加できます。このフィールドには、各症例に対する最新の規則エンジン実行結果に応じて、Health Authority、 Business Partner、Health Authority & Business Partner、または Not Reportable のいずれかが表示されるため、ユーザは目的の症例の報告価値ステータスを確認しやすくなります。これにより各症例が報告対象外か、あるいは 1 つ以上の保健当局またはビジネスパートナーに対して報告対象であるかが表示されるため、優先順位付けがより簡素化されます。

詳細

• 有効化: 症例レベルの報告可能性表示の有効化
• ユーザヘルプ: 症例データの入力: Case Reportability

国別試験薬の ICSR レポート作成

Vault では、国別試験薬 (IMP) の選択機能強化がサポートされるようになりました。Vault では、特定の治験実施国でのみ使用される治験薬がある場合に、治験薬および国の組み合わせに基づいて報告価値を評価できるようになりました。この機能では、新たに Study Product Country オブジェクトと Study Product Role レポート作成ルールパラメータが導入され、これにより治験製品の国別評価が判定されます。旧リリースの Vault では、症例内のすべての治験製品が、治験 登録先のすべての管轄区域で報告対象とみなされていました。この機能強化により、保健当局への過剰報告の問題に対処し、規制コンプライアンスが確保されます。

詳細

• 有効化: 国別試験薬の ICSR レポート作成を有効にする
• 管理者ヘルプ: 治験の管理: 国別試験薬を使用する治験
• ユーザヘルプ: レポート作成ルールパラメータの参照: Study Product Role

FDA MedWatch 3500A: 2024 年 8 月バージョン

このリリースにより、Vault Safety は 2022 年 11 月に FDA によって公開された最新バージョンの 3500A MedWatch フォームの生成をサポートするようになります。新しいバージョンは、Vault Safety で医薬品、生物学的製剤、医療機器、臨床試験の症例に関する ICSR のプレビュー、送信、配布に利用できます。

この機能は自動オン仕様ですが、一部のコンポーネントでは追加の設定が必要です。

詳細

• 有効化: FDA MedWatch 3500A: 2024 年 8 月版の有効化
• ユーザヘルプ: FDA 3500A 生成データのマッピング

EU Convention E2B (R2)

このリリースでは、Vault Safety は EU Convention E2B(R2) の個別症例安全性報告書の生成、提出、配布をサポートします。この機能により、ユーザーは、スイス医薬品局やオーストラリアの薬品・医薬品行政局 (TGA) などの機関に必要な地域要素を含めることができ、国際的な提出が容易になります。Vault Safety では、この機能を標準化することで、カスタム SDK 実装の必要性がなくなり、世界中の代理店やパートナーの提出プロセスが合理化されます。

EU Convention E2B(R2) 形式のレポートの生成は自動的にオンになります。ドキュメントタイプは、Transmission 書類の生成時に Document Types 選択リストで自動的に使用可能になります。電子提出書類を規制機関に送信するために Vault を設定するには、カスタムの トランスミッションプロファイルを設定する必要があります。

詳細

• ユーザヘルプ: E2B 生成: EU Convention E2B(R2) マッピング

読みやすい E2B レンディション

今回のリリースにより Vault Safety では、言語と構造が明確な読みやすい形式で E2B(R2) レポートおよび E2B(R3) レポートを生成し、PDF 形式でダウンロードできるようになりました。この機能強化により、提出、配布、検査、監査やその他の定期的な Quality チェックの各作業において、E2B ファイルのレビュープロセスが合理化および改善されます。

詳細

• 有効化: 読みやすい E2B レンディションの有効化
• ユーザヘルプ: 読みやすい E2B レンディションの生成

読みやすい E2B レンディションにおける MFDS 地域 E2B フィールド

このリリースでは、読みやすい E2B レンディションが MFDS 地域 E2Bデータ要素をサポートするようになります。この機能強化により、サブミッション、配布、検査、監査やその他の定期的な Quality チェックの各作業において MFDS E2B(R3) ファイルのレビュープロセスが合理化および改善されます。

読みやすい E2B レンディションを有効にしている Vault では、この機能は自動オンです。

詳細

• ユーザヘルプ: 読みやすい E2B レンディションの生成

MFDS E2B(R3)

このリリースでは、Vault Safety が MFDS E2B(R3) 形式での個別症例安全性報告書の生成と送信をサポートするようになります。韓国食品医薬品安全処 (MFDS) への MFDS E2B(R3) 形式の送信をサポートするために、この機能には新しい MFDS トランスミッションプロファイルも含まれています。

詳細

• 有効化: MFDS E2B(R3) の有効化
• 管理者ヘルプ: 基準当局への ICSR 提出
• ユーザヘルプ: E2B 生成: MFDS E2B(R3) のマッピング

提出時の登録情報を選択

今回のリリースで、Vault Safety では集積レポートのサポートが強化され、ICSR Submissionの生成時に使用された、適切な製品登録の詳細情報が含められるようになりました。この機能強化により、ユーザは ICSR Submission 生成時に使用された登録情報を追跡できるため、より正確な集積レポートの作成が可能になります。

FDA に対して一般的なレポートを生成する場合、Vault では、合格した症例製品または組み合わせ製品から報告対象製品を選択し、治験製品に関連した治験登録から報告対象の治験を選択します。治験以外の症例の場合、Vault は登録日の早さと登録番号の低さを優先し、製品に基づいてフォールバックロジックを適用します。治験症例の場合、Vault は登録番号の低さを優先し、登録の早さに基づいてフォールバックロジックを適用します。これにより、Vault ではレポートを作成する目的で、最も関連性の高い製品または治験を識別できます。

この機能は自動的にオンになりますが、一部のコンポーネントでは設定が必要な場合があります。

詳細

• 有効化: 提出時の登録情報の選択の有効化
• ユーザヘルプ: レポート作成ルールエンジンの理解

PMDA 市販後レポート: ローカル認知日でフィルタリング

このリリースの Vault Safety では、PMDA 市販後集積レポートの症例をローカル認知日でフィルタリングできます。旧リリースでは、ユーザは症例を症例受領日/最新情報入手日、または症例承認日でしかフィルタリングできませんでした。追加のフィルタリングオプションは、地域の関連会社が症例を認識する日付が、グローバル症例の承認日または最新情報入手日と異なる場合があるため、ローカライズ済み症例のレポートを生成する際に役立ちます。この機能強化は、すべての PMDA 市販後集計で利用できます。

詳細

• ユーザヘルプ: PMDA 市販後集積レポートの作成: 症例のフィルタリング条件

CIOMS II 集積レポートの追加フィルタ

このリリースでは、CIOMS II レポートの柔軟性が向上し、標準の CIOMS II ラインリスト形式で結果が表示される、より多様なレポートを生成できるようになりました。次のオプションフィルタが使用できるようになりました。

• Report Type
• Case Seriousness
• Case Relatedness
• Case Expectedness
• Expectedness Source
• Country の組み入れと除外

この機能は自動オン仕様ですが、一部のコンポーネントでは追加の設定が必要です。

詳細

• 有効化: CIOMS II ラインリストを有効にする
• ユーザヘルプ: CIOMS II レポートの作成

複数のトランスミッションプロファイルに対するゲートウェイのサポート

治験依頼者へのサポートを強化するため、Vault のゲートウェイおよび AS2 接続では、複数のトランスミッションプロファイルを割り当てられたゲートウェイの受信伝送が許可されるようになりました。

AS2 接続: AS2 接続の復元

Vault Safety では、Vault 更新後に Vault の AS2 接続を復元できるようになりました。これによって Vault の更新後に AS2 接続を再設定する必要がなくなり、開発サイクルの早い段階で AS2 接続を開始しやすくなります。この機能では、新しい管理アクション Refresh AS2 Connections が導入され、サンドボックスの更新と AS2 接続の管理が簡素化されます。

詳細

• 管理者ヘルプ: AS2 接続の復元

AS2 接続: AS2 接続の転送 (環境管理)

今回のリリースにより、管理者は複数の Vault 間で AS2 接続を転送できるようになりました。ただしこの転送は、同一のお客様が所有し、かつ同一展開リージョン内にあり、同一リリースタイプ (LR から Limited Release から Limited Release へ、または General Release から General Release へ) の Vault 間のみに限定されます。1 つの Vault 上で必要な AS2 接続を作成およびテストし終わったら、管理者は新たに追加された Transfer AS2 Connections ユーザアクションを使用して、作成した AS2 接続をすべての接続詳細情報 (AS2 設定、URL、許可する IP リスト、証明書) とともに新しい Vault 環境へと簡単に移行できます。この機能により、実装作業が軽減され、Vault 間の切り替え時に AS2 接続の誤設定が生じる可能性を低減できます。

詳細

• 管理者ヘルプ: AS2 接続の転送

Product Family Product レコードの自動生成

Vault Safety では、ユーザが新規 Product レコードを作成すると、自動的に Product Family Product レコードが生成されるようになりました。これにより効率が向上します。

Vault 式: カスタム安全性ルールパラメータ

このリリースにより、Vault Safety では Vault 式エンジンをレポート作成ルールエンジンに拡張します。管理者は、式を使用した症例データの評価にカスタムレポート作成ルールパラメータを設定できるようになりました。この機能強化により、報告価値の判断における柔軟性が向上し、カスタム SDK の開発を必要とすることなくカスタマイズされた評価基準を利用できるようになります。

詳細

• ユーザヘルプ:
  • レポート作成ルールパラメータ: 症例データ - 式
  • レポート作成ルールパラメータ: 症例データのカスタムレポート作成ルールパラメータの作成
  • レポート作成ルールの製品選択: 一般的な報告における優先度の高い報告対象製品の選択

Safety 標準化 24R3

このリリースでは、Vault Safety に標準コンポーネントが複数追加され、主要なビジネスプロセスのベストプラクティスを簡単に採用できるようになります。追加の標準化機能は今後のリリースで利用可能になります。

Safety Workbench

新しいアプリケーション: Vault Safety Workbench

Safety 24R3 Release では、Veeva Vault Safety Suite の一部として Vault Safety Workbench アプリケーションが導入されています。このアプリケーションを使用するには、Vault Safety Workbench と、Vault Safety ライセンスが必要です。Vault に Vault Safety Workbench をインストールして設定する方法については、Veeva 担当者にお問い合わせください。

Vault Safety Workbench は、アドホックおよび定期的なレポートのために大量の Vault Safety データを分析できます。このアプリケーションでは、組織のビジネスプロセスに応じて、より柔軟で設定可能なレポートも作成できます。詳細については、Vault Safety Workbench の概要をご覧ください。

Safety Signal

新しいアプリケーション: Vault Safety Signal

Safety 24R3 Release では、Veeva Vault Safety Suite の一部として Vault Safety Signal アプリケーションが導入されています。このアプリケーションを使用するには、Vault Safety Signal と、Vault Safety ライセンスが必要です。Vault に Vault Safety Signal をインストールして設定する方法については、Veeva 担当者にお問い合わせください。

Vault Safety Signal は既存の Vault Safety データベースのデータを使用して、医薬品に対する予期しない新しい有害事象や、既存の有害事象の変化を検出します。検出内容は市販後または臨床試験の症例に適用できます。詳細については、Vault Safety Signal の概要をご覧ください。

SafetyDocs

PSMF Periodic Review の通知テンプレートの更新

PSMF Periodic Review ワークフローの通知テンプレートは、受信者に割り当てられたタスクに関する詳細情報を提供します。新しい通知テンプレートを使用するには、管理者はワークフローの設定を更新する必要があります。この改善により、ユーザーには生産性を向上させるための追加のコンテキストが提供されます。

詳細

• 有効化: PSMF 定期レビューの有効化
• 管理者ヘルプ: PSMF 定期レビュージョブの設定
• ユーザヘルプ: PSMF 定期レビューの設定

CRO Vault での文献記事からのインボックスアイテムの作成

さまざまな治験依頼者の文献レビューを実行する開発業務委託機関 (CRO) のお客様をより適切にサポートするために、Vault SafetyDocs では、Literature Article オブジェクトと Literature Review オブジェクトに Organization フィールドが追加されました。Literature Article から Inbox Item を作成する場合、Vault では Organization フィールドが考慮されます。Literature Article のこのフィールドにデータが入力されている場合、Vault は Inbox Item の Organization フィールドを、その作成元となった Literature Article と同じ Organization 値に設定します。Literature Article のこのフィールドにデータが入力されていない場合、現在の動作に変更はありません。これらの追加フィールドにより、複数スポンサーの Vault を使用している CRO のお客様は、レビューと記事ごとに個別のスポンサー/組織を指定できます。

詳細

• 有効化: CRO Vault で文献記事からのインボックスアイテムの作成を有効にする
• ユーザヘルプ:
  • 文献レビュープロセスの管理: 文献レビューを作成する
  • 文献記事からインボックスアイテムを作成: 文献記事からインボックスアイテムを作成する
  • Inbox Item フィールドの参照: Organization and Region セクション

製品ファミリーへの文献コーディング

製品ファミリーレベルで完了する文献検索をサポートするために、Vault SafetyDocs では、文献記事を製品ファミリー、製品、またはその両方にコーディングできるようになりました。Search Term、Literature Standard Search Term、Literature Review、および Literature Article の各オブジェクトに Product Family フィールドが追加されました。この機能により、特定の製品を選択する必要がなくなり、文献記事のより正確なコーディングと、より広範なシグナル検出が可能になります。

詳細

• 有効化: 製品ファミリーへの文献コーディングの有効化
• 管理者ヘルプ: 文献標準検索用語の作成
• ユーザヘルプ: 文献レビュープロセスの管理

文献内の複数製品のサポート

Vault SafetyDocs では、同一文献記事内で各製品ごとの独立した判定がサポートされるようになりました。文献記事には複数社の製品が含まれる場合があります。ICSR 製品評価およびシグナル分析において、文献記事内でそれぞれの製品を検索し、薬剤間で生じ得る相互作用を特定する作業は不可欠です。この作業をサポートするため、Vault SafetyDocs には Literature Article Product オブジェクトが導入されました。ユーザが Literature Article レコードに Product を設定すると、Vault では Literature Article Product レコードが自動作成されます。さらに、Vault SafetyDocs では、判定を含む各 Literature Article Product レコードに対してインボックスアイテムが作成されます。これにより、複数の製品が含まれるケースがより適切にサポートされ、コンプライアンスが強化されます。

詳細

• 有効化: 文献内の複数製品のサポートの有効化
• ユーザヘルプ: 文献レビュープロセスの管理

PVA ドキュメント配布用の送信者メールアドレスのカスタマイズ

Vault SafetyDocs は、お客様の子メールドメインを使用して Vault メールを送信するように設定できます。これまで、Vault から送信されるメールには「@veevavault.com」というドメインが使用されていました。Vault が外部パートナーにメールを送信する医薬品安全性監視アグリーメント (PVA) 配布などのシナリオでは、メールがお客様のメールドメインから送信されていない場合、疑わしいものと見なされる (スパムフォルダに送信される) 可能性があります。「From」ドメインを設定する機能により、この課題に対処できます。

詳細

• 有効化: PVA ドキュメント配布用の送信者メールアドレスのカスタマイズを有効にする
• ユーザヘルプ:
  • 医薬品安全性監視アグリーメントの管理: PV アグリーメントの作成
  • メールでの PVA ドキュメントの配布: カスタム送信ドメインとメールの使用

医薬品安全性監視アグリーメントの使いやすさ向上

このリリースにより Vault SafetyDocs では、オブジェクトフィールドで医薬品安全性監視アグリーメント (PVA) オブジェクトが参照されている場合に、自動生成された名前ではなく意味のある値が表示されるようになりました。たとえば、参照先が PVA Contact の場合はユーザ名が表示され、 PVA Obligation の場合には Clause of Title フィールド値が表示されます。これにより、PVA 関連レコードの使いやすさが向上します。

詳細

• 有効化: PVA 管理の有効化

Risk Management の自動化

Vault SafetyDocs の Risk Management 機能では、ローカル Risk Management Plan (RMP) の作成が自動化され、Risk Management Measures (RMM) のバージョン管理およびローカライゼーションがサポートされるとともに RMP と RMM の有効なバージョンが管理されるようになりました。Vault では、対象製品が登録されているすべての市場で、ローカル RMP と RMM を、それぞれグローバル/コア RMP と RMM に基づいて自動生成できます。さらに、バージョン番号とライフサイクル状態をEffectiveに設定する新しいアクションが導入されました。リスク管理の自動化により、リスク管理プロセスでのユーザ効率が向上します。

文献抄録用のカスタム翻訳接続

Vault で、カスタム翻訳接続を用いた文献抄録の翻訳がサポートされるようになりました。以前は、Vault は Amazon Translate のみをサポートしていました。カスタム翻訳接続を使用すると、組織のニーズに合った任意の外部翻訳サービスに SafetyDocs を接続できます。

詳細

• ユーザーヘルプ: 文献抄録の翻訳

安全性調査への追加情報の記録

このリリースでは、ユーザは安全性調査でより詳細な情報を記録できるようになりました。ユーザは安全性調査において、説明の入力、期日の追跡、検証および処分の根拠記入を行えるようになりました。

詳細

• ユーザヘルプ: シグナル管理: 安全性調査フィールド

安全性調査への MedDRA 用語とクエリの追加

今回のリリースによりユーザは、MedDRA 用語と MedDRA クエリ を安全性調査に直接追加できるようになりました。ユーザは MedDRA ブラウザを使用して、任意の階層レベルにある複数の MedDRA 用語を選択し、MedDRA クエリを選択できます。この機能強化により、調査中の事象についてより詳細で一貫した表現が可能になるため、保健当局の要求との整合性が向上し、安全性調査の明確さを高めることができます。

詳細

• 有効化: 安全性調査への MedDRA 用語とクエリの追加を有効にする
• ユーザヘルプ: シグナル管理: 安全性調査への MedDRA 用語または MedDRA クエリの追加

文献記事から安全性調査を開く

このリリースで、ユーザは安全性調査を文献記事から直接開けるようになりました。ユーザは Open Investigation アクションを選択して、Safety Investigation および関連する Literature Data レコードを作成できます。この機能では Literature Article Products に対する Safety Investigations を効率的に作成し、New Safety Information の Investigation Review Outcome の生成が実現されるため、シグナル管理プロセスが強化されます。

詳細

• ユーザヘルプ:
  • シグナルデータソース: 文献
  • シグナル管理: 文献記事から開く安全性調査について
  • Literature Data を使用したシグナル検出
  • 安全性調査の作成: Literature Data から安全性調査を作成する

Product-Event Disposition の更新

このリリースでは、業界用語との整合性を向上させるため、Product-Event Disposition ラベルが PEC Period へと更新されました。Vault SafetyDocs では、PEC Period レコードの一意性ルールが強化されました。PEC Period レコードの Reporting Period フィールドは、レコードごとに一意である必要があります。また、PEC Period レコードに自動命名する場合は、Vault ではレコードをより適切に区別するため Detection Date の代わりに乱数が用いられます。上記変更は業界標準に準拠しており、シグナル検出およびレポート作成プロセスにおける精度が向上します。

SafetyDocs 標準化 24R3

このリリースでは、Vault SafetyDocs に多数の標準コンポーネントが追加され、主要なビジネスプロセスのベストプラクティスを簡単に採用できるようになります。追加の標準化機能は今後のリリースで利用可能になります。

Safety & SafetyDocs

E2B 生成: 文献の再送信

SafetyDocs の文献記事から作成された症例に関するレポート作成をサポートするため、Vault Safety では E2B ファイル生成時に、Literature Article レコードに添付されている文献ドキュメントを再送信できるようになりました。この機能により、インボックスアイテムのプロモーション後にドキュメントを手動でコピーおよび再分類する必要がなくなります。E2B の送信で文献ドキュメントの柔軟な再送信が可能になったことにより、コンプライアンスと使いやすさが向上します。

この機能は自動オン仕様ですが、一部のコンポーネントでは追加の設定が必要です。

詳細

• 有効化: 文献 E2B の再送信を有効にする
• ユーザヘルプ:
  • ローカライズ済み症例の準備
  • 規制レポートの生成

Safety データモデルの変更

24R3 Safety データモデルの変更をご覧ください。

QualityOne

以下のリリースノートに加えて、QualityOne Veeva Connect コミュニティでは、General Release に関するお知らせ、リリースの注目機能、主要な機能のデモを提供しています。

QualityOne

Teams の機能強化: 複数のソースオブジェクトから Team を継承する

今回のリリースで QualityOne Teams では、複数の親オブジェクトの Team から単一の Team 内の各 Team Role のロールメンバーシップを継承できるようになりました。以前のリリースでは、サブプロセスが複数の親プロセスに関連する可能性がある共有親子関係のシナリオ (アクションアイテムなど) では、親プロセスの各タイプに対応するために、サブプロセスにオブジェクトタイプごとに 1 つの Team 定義が必要になる場合がありました。

たとえば、CAPA、または Change Control、または Audit から派生する可能性のある Extension Request のような共有親子関係のシナリオでは、単一の Extension Request Team 定義をすべてのタイプの Extension Requests に使用できます。実行時に適切な親プロセスレコードからそのロールメンバーシップをインテリジェントに継承し、日常のアクティビティでユーザがやり取りする必要はありません。

この機能により、Team が有効化されたさまざまなオブジェクト間での再利用が可能になるため、Teams 設定の複雑さが軽減されます。

詳細については、Team ロールメンバーシップの継承をご覧ください。

Teams の機能強化: グローバル上限値の引き上げ

この機能により QualityOne Teams のパフォーマンスとスケーラビリティが強化され、これまで適用されてきたグローバル上限がいくつか緩和されます。管理者は、この公開値に設定を近付けるために Veeva 担当者に問い合わせる必要はありません。

Teams の設定は、グローバルに以下に対応できます。

• Vault につき最大 100 チーム
• Team あたり最大 10 ロール
• Team Role あたり最大チームメンバー 20 人

詳細については、Team の設定および Team での作業をご確認ください。

Teams の機能強化: チーム割り当ての管理

この開発者機能は、Team Role へのチームメンバーの一括追加および一括削除をサポートしています。この機能により Vault UI に通知テンプレートが追加され、Vault は上記変更を行ったユーザに対して、追加処理や削除処理が成功したかの通知を送信します。

この機能の詳細については、開発者向け機能をご覧ください。

詳細については、Team での作業をご覧ください。

イベントアクションの関連レコード自動化の機能強化

この機能は、Create Related Record アクションを強化し、イベントアクションとしてのパフォーマンスを向上させます。Create Related Record アクションは、イベントアクションとして設定されている場合に同期的に実行されるようになり、大規模なレコード作成の堅牢性とパフォーマンスが向上しました。

Create Related Record アクションの設定の詳細をご覧ください。

QMS (QualityOne)

追加の QMS プロセスのドキュメント生成

この機能は、次のオブジェクトを追加することで、以前に導入された Generate Documents using Object Record Actions for Audits 機能と Generate Documents for Standard QMS Processes 機能を拡張します。

• Lab Investigation
• 継続的な改善の取り組み
• インスペクション (COA 生成用)

この機能を使用すると、ユーザは、管理者が設定するエントリまたはユーザアクションを使用して、フォーマットされた出力またはドキュメントテンプレートからドキュメントを生成できます。ドキュメントを生成することにより、ユーザは Vault のドキュメント管理機能全体を活用でき、ドキュメントを手動で設定して Vault ライブラリにアップロードする必要がなくなります。ワンクリックソリューションを使用してドキュメントを生成すると、オブジェクトレコードと Vault ライブラリ内のドキュメントとの間のリンクも自動的に生成され、ユーザは生成されたドキュメントのコンテキストを確実に保持できます。

ドキュメントの生成およびドキュメント生成の設定の詳細をご覧ください。

Periodic Review: 社内施設の APQR

この機能により、ユーザーは社内施設の年次製品品質レビュー (APQR) を実施できるようになり、Periodic Review 機能のエンドツーエンドの機能が強化されます。旧リリースでは、ユーザーはサプライヤー組織に対してのみ APQR を実行できました。

定期レビューおよび APQR の実施の詳細をご覧ください。

Inspection Sample Test Result が Raw オブジェクトへ移行

この機能では、Inspection Sample Test Result オブジェクトを標準 Vault オブジェクト (SVO) から Raw オブジェクトに移行することで、このオブジェクトのスケーラビリティとパフォーマンスが向上します。この変更の詳細については Veeva 担当者にお問い合わせください。

インスペクションの設定およびオブジェクトアプリケーションセキュリティの定義の詳細をご覧ください。

COA インスペクション: COA バリアント一致の改善

この機能により、COA ファイルのヘッダーセクションからデータを抽出する際に、COA 一致ルールに改善済みの一致戦略が導入され、COA ファイル内の主要なデータに関連付けられたフィールドの一致が見つかる可能性が高まります。

COA 一致ルールおよび COA インスペクションの操作の詳細をご覧ください。

同一 HACCP 計画内での CCP と OPRP の再利用

ユーザはこの機能を使用すると、同一 HACCP 計画内の複数の危険性分析に適用されている重要な制御項目を、より効率的に管理できます。旧リリースでは、ユーザは HACCP 計画内にあるそれぞれのプロセス危険性分析に対して、個別に CCP と OPRP を作成して追加する必要がありました。今回のリリースによりユーザは、過去に別のプロセス危険性分析で定義した CCP と OPRP を、同一 HACCP 計画内に追加した別のプロセス危険性分析に追加できるため、危険性管理プラクティスで時間を短縮し一貫性を向上させることができます。

詳細については、危険性分析の実行をご覧ください。

HACCP フロー図およびデータドキュメントの生成

この機能により、ユーザーは HACCP フロー図からアクションを実行して、HACCP Plan レコードからドキュメントを生成できます。ユーザーがアクションを実行すると、Vault は HACCP フロー図の PDF レンディションと、関連する HACCP Plan のデータを含む別のドキュメントを生成し、これらのドキュメントの両方をライブラリのバインダーに保存します。管理者は、さまざまなドキュメントテンプレートを設定して、HACCP Plan から特定のフィールドデータを抽出し、Vault の Document Management 機能を活用して、生成された HACCP ドキュメントを管理することができます。

HACCP ドキュメントの生成の詳細をご覧ください。

HACCP フロー図: 危険性分析完全性チェックの改善

この機能は、24R2 で導入された危険性分析完全性チェック機能をさらに強化するものであり、次の改善が加えられています。

• 切り替えアイコンを 1 回クリックするだけで、プロセスステップに危険性分析完全性ステータスが表示されるようになり、HACCP フロー図を更新する必要がなくなりました。
• 危険性分析完全性ステータスが、HACCP フロー図にある Information パネルの各 Process Hazard Analysis レコードに表示されるようになりました。
• ユーザが HACCP フロー図の要素を編集するたびに、Vault で各プロセスステップの危険性分析完全性ステータスを自動的にチェックして更新するよう設定できます。このプロセスを自動化することにより、リスク管理業務の効率、正確性、一貫性および透明性が向上し、食品安全上の危険性を徹底的かつタイムリーに評価できるようになります。

詳細については、危険性分析完全性の評価をご覧ください。

HACCP フロー図: Connection ラインの位置調整

今回のリリースによりユーザは、HACCP フロー図上の各プロセスステップ間にある Connection ラインの位置を調整できるようになりました。

旧リリースでは、HACCP フロー図上の Connection ラインの位置決定は Vault の自動配置機能に依存し、必要に応じて調整することはできませんでした。上記変更により、ユーザは Connection のすべてのライン部分の位置を変更できるようになりました。

この機能により、HACCP フロー図上でプロセスフローレイアウトの視覚的な明瞭性が向上するとともに、表示されている情報の構造と編成をより細かく制御できるようになったほか、HACCP フロー図を再設計する必要なく、プロセス変更への対応や代替ワークフローの反映を行う上での柔軟性が向上します。

詳細については、HACCP フロー図の使用をご覧ください。

HACCP フロー図: PRP と対策の機能強化

この機能によりユーザは、Information パネルの Hazard Analysis セクションに一覧表示されている PRP および対策の簡単な概要を閲覧し、さらに各 PRP や対策を展開して詳細情報を表示できます。旧リリースでは、Information パネルには、PRP または対策の参照レコード名のみが表示されていました。この機能強化により、ユーザは個々のレコードに移動しなくても、HACCP フロー図上の各プロセスステップまたは各プロセスステップグループに関連付けられている 各 PRP と対策の背景情報を閲覧できるため、危険性分析の効率および精度が向上します。

詳細については、危険性分析の実行をご覧ください。

HACCP 計画の比較 ID

この機能により、HACCP Plan オブジェクトとその関連オブジェクトにデータモデル更新が加えられ、製造施設側の HACCP 計画とその作成元となった HACCP 計画設計との間のトレーサビリティが向上します。新たに追加された Comparison ID フィールドには、製造施設側の計画の元となった HACCP 計画に割り当てられている一意のシステム ID が含まれており、この ID は比較機能やトレーサビリティ機能の実装用途に使用できます。

詳細については、比較 ID をご覧ください。

HACCP フロー図: 保護された関係のアトミックセキュリティ標準化

この機能により HACCP フロー図の UI が強化され、保護された関係に対するアトミックセキュリティのユーザ権限がフロー図 UI に反映されたことにより、Vault 全体で一貫したユーザエクスペリエンスが提供されます。旧リリースでは、ユーザが 2 つのオブジェクト間の保護された関係に対して Edit 権限を持っていない場合に、そのユーザに実行許可のないユーザアクションが表示され、実行するとエラーが表示されていました。今回のリリースでは、HACCP フロー図の UI 上には、保護された関係に依存するレコードを追加するオプションは表示されなくなりました。

詳細については、HACCP フロー図の使用をご覧ください。

HACCP 計画の翻訳

このリリースにより、Vault では翻訳された HACCP 計画の作成プロセスがサポートされるようになりました。この機能により、組織は事前定義された HACCP 計画設計 のコピーを作成し、それを現地の製造施設で使用するために翻訳できるため、組織のベストプラクティスに沿っていない恐れのある HACCP 計画プランの独自翻訳バージョンを現地施設が維持する必要がなくなります。

この機能では、以下の機能が導入されています。

• HACCP Plan オブジェクトで使用できる新しいユーザアクションは、HACCP 計画処理手順、プロセス危険性分析、および HACCP 計画で使用されるあらゆるカスタムオブジェクトなど、HACCP 計画のあらゆる標準関連レコードを含む HACCP 計画の翻訳コピーの生成をサポートしています。
• HACCP Plan オブジェクトの新しいユーザアクションにより、HACCP 計画の翻訳コピーから翻訳可能な HACCP Plan フィールドデータをエクスポートし、翻訳済みデータの後続インポートを実行できます。インポート時に、Vault では翻訳済みデータを表示するために HACCP 計画を更新します。
• 管理者は、Details とオブジェクトレコードおよび HACCP フロー図の関連オブジェクトセクションに翻訳済みフィールドデータを表示するるように Vault を設定できます。
• 組織は、カスタムおよび標準参照オブジェクトの両方の翻訳済み参照データを定義して、HACCP 計画の作成時に再利用できます。
• HACCP 計画のレコードを作成する場合、ユーザの言語設定に応じて、翻訳済み参照レコードを選択できます。選択可能な参照レコードを制限するように VQL 基準が設定されている場合、管理者は翻訳済みレコードをフィルタリングするように基準を設定できます。

この機能により、HACCP 計画の翻訳プロセスが簡素化され、地理的に分散した組織でも食品安全性プラクティスの一貫性を確保できます。

詳細については、HACCP 計画の翻訳の設定およびHACCP 計画の翻訳をご覧ください。

QMS (QualityOne) および HSE

Proposed Audit の自動作成の機能強化

この機能は、Create Proposed Audits アクションで重複したProposed Audit を作成するためのロジックを強化します。このリリースでは、重複した Proposed Audit の作成は、Vault 内のすべての Audit Program ではなく、アクションが実行される Audit Program に制限されます。

Create Proposed Audits アクションの使用の詳細をご覧ください。

HSE

標準 HSE プロセスのドキュメント生成

この機能により、QMS で以前に導入された Generate Documents using Object Record Actions for Audits 機能と Generate Documents for Standard QMS Processes 機能が、次のオブジェクトに対して HSE で使用できるようになります。

• Audit
• HSE イベント
• 作業許可
• リスクレジスタ
• リスクスタディ

この機能を使用すると、ユーザは、管理者が設定するエントリまたはユーザアクションを使用して、フォーマットされた出力またはドキュメントテンプレートからドキュメントを生成できます。ドキュメントを生成することにより、ユーザは Vault のドキュメント管理機能全体を活用でき、ドキュメントを手動で設定して Vault ライブラリにアップロードする必要がなくなります。ワンクリックソリューションを使用してドキュメントを生成すると、オブジェクトレコードと Vault ライブラリ内のドキュメントとの間のリンクも自動的に生成され、ユーザは生成されたドキュメントのコンテキストを確実に保持できます。

ドキュメントの生成およびドキュメント生成の設定の詳細をご覧ください。

QualityOne データモデルの変更

24R3 QualityOne データモデルの変更をご覧ください。

RegulatoryOne

すべての Platform 機能を含む RegulatoryOne 24R3 Release は、2024 年 12 月 17 日に暫定公開を予定しています。

以下のリリースノートに加えて、RegulatoryOne Veeva Connect コミュニティでは、General Release に関するお知らせ、リリースの注目機能、主要な機能のデモを提供しています。

RegulatoryOne

アプリケーションライセンスの警告

この機能により、アプリケーションのセキュリティと整合性が向上します。この機能の目的は、アプリケーションのさまざまな部分にアクセスする際に、ユーザのアプリケーションライセンス使用を必須にすることです。Vault では、さまざまなアプリケーション機能へのアクセスを許可する前にユーザライセンスの有効性をチェックし、ユーザが保有中のライセンスでサポートされていない機能にアクセスしようとすると警告を表示するようになりました。今後のリリースでは、ユーザは保有中のライセンスに該当しない機能にはアクセスできなくなります。

RegulatoryOne および Veeva Claims データモデルの標準化

この機能では、RegulatoryOne アプリケーションと Veeva Claims アプリケーションにデータモデルの更新が導入されています。これにより、進化するニーズに対応してアプリケーション間の調和が実現され、ユーザーが Veeva の進化するベストプラクティスを活用できるようになります。

コンプライアンス管理

処方アンケート: 添付ファイルのインポート

ユーザはこの機能を使用すると、処方アンケートの添付ファイルを一括でアップロードして自動分類できるようになるため、各種サプライヤードキュメントを Vault にすばやく追加できるようになります。

詳細については、処方アンケートの添付ファイルのインポートをご覧ください。

処方アンケート: アンケート名トークン

管理者はこの機能を使用すると、カスタムトークンを使用して、処方アンケートの名前とそのアンケートの作成元となったアンケート種類を、サプライヤーへ送信するメールに追加できるようになります。これによりサプライヤーは、同じ処方に関して受信した複数のアンケートメールを簡単に判別できるようになります。

詳細については、処方アンケートの通知の設定をご覧ください。

レジストレーションおよびドシエ管理

ローカルインパクトアセスメントの機能強化: 評価結果の上書き

この機能はユーザに対して、Local Impact Assessment アクションの実行により、一致した Registration を上書きする柔軟性を提供します。ユーザは、別の Registration を検索して選択するか、もしくは対象 Registration Item の新規レコードを作成できるようになりました。

詳細については、Local Impact Assessmentアクションの実行後にRegistration を選択するをご覧ください。

ローカルインパクトアセスメントの機能強化: 登録内に複数の登録項目

この機能により、ユーザーは実行するアクションの順序に関係なく Local Impact Assessment アクションを実行できるため、既存の登録データの再利用が強化されます。このアクションでは、最初に Generate Registration Data アクションを実行しなくても、適切な Registration および Registration Objective の Registration Item レコードが識別されるようになりました。

詳しくは、ローカルインパクトアセスメントをご覧ください。

ローカルインパクトアセスメントの機能強化: Cancelled Objective と Withdrawn Objective を無視

この機能により、管理者は Cancelled および Withdrawn Registration Objectives を設定して、Local Impact Assessment アクションで、指定されたライフサイクル状態 (Active や In Progress など) の有効な Registration Objectives のみが考慮されるようにすることができます。これにより、評価から無関係なデータを除外できます。

詳細については、Local Impact Assessment アクションの設定をご覧ください。

Registration Attribute と Relational Token の設定管理のための管理者用 UI

この機能により、管理者は Configurations タブのアプリケーション設定から Registration Attribute および Relational Token の各設定コンポーネントを設定できるようになりました。これにより、これまでのように Postman から MDL を実行して Generate Registration Data、 Generate Requirements、ローカルインパクトアセスメントなど、サポートされている各種アクションのアプリケーション設定を管理する必要がなくなりました。

詳細については、Vaultで Registration Attribute と Relational Token 設定を作成する方法をご覧ください。

Create Document from Template アクション: 上限の引き上げ

この機能により、ユーザが Create Document from Template アクションで生成できる文書数が、50 件から 100 件に増加します。

詳細については、テンプレートからドシエドキュメントを自動作成するをご覧ください。

RegulatoryOne データモデルの変更

24R3 RegulatoryOne および Veeva Claims データモデルの変更をご覧ください。

Veeva Claims

すべての Platform 機能を含む Veeva Claims 24R3 リリースは、2024 年 12 月 17 日の暫定公開を予定しています。

以下のリリースノートに加えて、Claims Veeva Connect コミュニティでは、General Release に関するお知らせ、リリースの注目機能、主要な機能のデモを提供しています。

Veeva Claims

簡素化された Substantiation の機能強化

この機能では、Substantiation レコードの既存の Upload フィールドが拡張されて、ユーザーは新しい Substantiation レコードの作成後に参照ドキュメントをアップロードできるようになりました。ユーザーは、既存の Substantiation レコードを編集する際に、このフィールドを使用して参照ドキュメントをアップロードできるようになりました。

詳細については、Substantiations の作成と変更をご覧ください。

既存のクレームをプロジェクトに一括追加

この機能により、ユーザーは一括レコードアクションを利用して、Claims ライブラリから新規または既存の Project に複数の既存の Claim レコードを直接追加できます。このため、より効率的なレコード作成方法を使用することでユーザーの時間を節約できます。

詳細については、Project への Claims の追加をご覧ください。

24R3 Veeva Claims の機能強化

この機能により管理者は、Admin > Configuration ページの Application Configurations セクションにできた新しいページから、Bulk Create Local Adaptations (Project) アクションで除外するライフサイクル状態を定義できるようになりました。

詳細については、 Bulk Create Local Adaptations (Project) アクションの設定をご覧ください。

アプリケーションライセンスの警告

機能説明をご覧ください。

RegulatoryOne および Veeva Claims データモデルの標準化

機能説明をご覧ください。

Veeva Claims データモデルの変更

24R3 RegulatoryOne および Veeva Claims データモデルの変更をご覧ください。