What's New in 25R2

Pre-Release 日: 2025 年 7 月 7 日 | リリース日: 2025 年 7 月 25 日および 2025 年 8 月 1 日

25R2 以降のすべてのリリースでは、Veeva LIMS、Veeva Safety、Veeva RegulatoryOne、Veeva Claims は、Veeva Vault Platform と同日にリリースされます。

---

Vault 25R2 のご紹介です。以下の新機能をご覧ください。新機能の有効化に関する情報については、25R2 Release Impact Assessment をご覧ください。開発者向け機能 (API、VQL など) については、開発者ポータルをご覧ください。

Platform

ハイライト

Vault Platform の主なポイントの概要は以下に表示されており、リンクから詳細情報にアクセスできます。Vault Platform リリースノートの残りの部分はテーマ別に分類され、最後のセクションでは軽微な機能強化について説明します。

これらの主要な機能の一部のデモを見たり、その他のコアプラットフォーム機能に関するナレッジ記事を読むには、Veeva Connect で Vault Platform コミュニティに参加してください。

機能	説明
Action Trigger	管理者は、Vault UI 内で直感的な IF-THEN-ELSE アクションブロックを使用して高度なロジックを直接実装できます。そのため、自動化されたビジネスプロセスを容易に設定でき、セットアップが短時間で完了します。
Document Readiness パネル	レンディションを生成する際に Vault がドキュメントに対して実行するプロセスの可視性を向上させます。管理者はこのパネルを使用して、ドキュメントタイプ別にユーザ向けチェックリストを設定できます。
Tree Security	定義された階層構造に基づいて、オブジェクトレコードのセキュリティ設定を構成できます。この構造により、ユーザは階層を通じて階層を下るロールを付与され、階層を通じて集約されたオブジェクトレコードにアクセスできるようになります。
Child Object Security	親からセキュリティを自動的に継承することで、子レコードに簡単にアクセスできるようにします。

Action Trigger

Action Trigger を使用すると、管理者はレコードに対して CREATE、UPDATE、または DELETE 操作が発生したときに実行される単純な条件付きロジックを記述できます。これにより、Vault は、以前は Vault Java SDK レコード トリガーを使用することでのみ可能だったアクションを実行できるようになります。以下にいくつかの例を示します。

• フィールドが更新されたら、通知を送信する
• フィールドが更新されたら、別のフィールドを更新する
• フィールドが更新されたら、関連レコードのフィールドを更新する (親または子)
• レコードが作成されたら、ワークフローを開始する
• 定義された条件下ではレコードの保存を禁止し、カスタムエラーメッセージを表示する

Action Trigger は、IF-THEN-ELSE ステートメントのブロックとして記述されたシンプルで直感的なロジックであり、CREATE、UPDATE、および DELETE 操作の BEFORE イベントと AFTER イベントとして作成できます。この機能には、Action Trigger の作成を支援するコンテキスト依存エディターが付属しています。実行可能なアクションの完全なリストは次のとおりです。

• レコードの作成、更新、または削除
• 通知の送信
• 状態の変更
• ワークフローの開始またはキャンセル
• 「レコードの作成を禁止する」などのカスタムメッセージを使用した操作のキャンセル

詳細については、Action Triggers をご覧ください。

Document Readiness パネル

Vault ユーザと管理者は、Vault でドキュメントを使用する準備に貢献するプロセスをより詳細に把握できるようになりました。ドキュメントビューアの Document Readiness パネルには、レンディションの生成、検索可能性、注釈の準備に関連するステータスが表示されます。このパネルには、これらの操作に関連する警告とその対処方法の情報も表示されます。

このパネルには、ドキュメント情報ペインの新しいアイコンからアクセスできます。

パネルには、Content Processing および Warnings セクションが表示されます。

Content Processing セクションには、標準の Vault レンディションプロセスの高レベルのステータス情報が表示されます。

• Viewable: 表示可能なレンディションの作成ステータスを示します。
• Searchable: ドキュメントビューア内、または詳細検索を使用してドキュメントコンテンツを検索するときのドキュメントコンテンツの検索可能性の状態を示します。
• Ready to Annotate: ドキュメントに注釈を付ける準備ができているかどうかを示します。

Warnings セクションはほとんどの場合表示されませんが、Vault が Merge フィールドトークンを解決できないなどの問題が処理中に発生した場合、このセクションではこれらの問題が分類され、ユーザは警告に移動して推奨される解決策を確認できます。

さらに、ユーザは警告を無視することもできます。

無視された警告は明るいテキストで表示されたまま、リストの一番下に移動されます。以前のバージョンで無視された警告は、最新バージョンでも無視されたままになります (警告がまだ存在する場合)。

処理が完了したときに Document Readiness パネルが表示されず、Vault で警告が特定された場合は、ユーザに警告を確認するように指示するメッセージが表示されます。

Document Readiness パネルは、Edit Document 権限を持つユーザにのみ表示されます。これらのユーザは、問題が特定された場合に対処できる権限を持つユーザです。Document Readiness パネルは、以前のバージョンや、Steady 状態のドキュメントバージョンでは表示されません。

管理者は、Document Readiness パネルに含める Document Checks を設定することもできます。これにより、ドキュメントのレビュー作業をガイドするドキュメントタイプ別のチェックリストをユーザに表示できます。また、エントリ条件で Document Checks を使用することで、ドキュメントのライフサイクルを進める前にチェック漏れを防ぐことができます。

Document Checks は、Admin > Configuration > Document Checks で設定します。

これらのチェックは、Document Readiness パネルの独立したセクションでユーザに表示されます。

さらに、レポート用の新しいオブジェクト Document Readiness Metrics (document_readiness_metrics__sys) を使用すると、未解決の問題に関する追加のレポートを作成できます。Document Readiness Metrics をレポートするには、管理者は Admin > Configuration > Report Types で必要なレポートタイプを作成する必要があります。

詳細については、Document Readiness panel をご覧ください。

Tree Security

管理者には、定義された階層構造に基づいてオブジェクトレコードへのアクセスを許可できる追加のセキュリティ設定オプションが提供されるようになりました。この構造により、ユーザは階層を通じて階層を下るロールを付与され、階層を通じて集約されたオブジェクトレコードにアクセスできるようになります。

Security Tree の定義

新しいオブジェクトを作成するときに、Security Tree と呼ばれる新しいオブジェクトクラスが使用できます。これにより、次のようなノードで構成される Security Tree 階層の作成が容易になります。

Tree ノードへのオブジェクトの割り当て

オブジェクトは設定内の特定の Security Tree に割り当てることができ、レコードは特定のノードに割り当てることができます。

オブジェクトレコードが Security Tree ノードに割り当てられると、同じノードに割り当てられているすべてのユーザ、または階層内の上位のノードに割り当てられているすべてのユーザに表示されます。たとえば、Record C は、Vendor Management、EVP、または CEO の Security Tree ノードに割り当てられたユーザに表示されます。

Tree ノードへのユーザの割り当て

システム管理のユーザツリー割り当てオブジェクトを使用して、ユーザにアプリケーションロールアクセスを付与できます。ノードに割り当てられたユーザは、同じノードに割り当てられたオブジェクトに直接アクセスできます。たとえば、この割り当てにより、User A に、EVP ノードに割り当てられたすべてのレコードと、子ノードに関連付けられたすべてのレコードへの Viewerアクセス権が付与されます。

上記では、Vendor Management が EVP の子ノードであるため、User A に Vendor Management ノードに関連付けられた Vendor レコードへの Viewer アクセス権が付与されます。アクセスを増やすために、より具体的な割り当てを追加することもできます。たとえば、ユーザに Editor アプリケーションロールの割り当てが Vendor Management ノードにも付与されている場合:

Editor から Vendor Management ノードへの割り当てレコードにより、Vendor Management ノードに関連付けられたレコードに対するユーザのアクセス権が Viewer から Editor に増加しますが、Viewer アクセス権は、EVP またはその下位のノードに関連付けられたレコードに対しては維持されます。

静的割り当てまたは自動割り当て (ユーザ参照フィールドに基づく)

Security Tree ノードを特定のオブジェクトレコードに割り当てる作業は、個別に実行できます (「静的割り当て」と呼ばれます)。また、Restrict Users to a Single Node Assignment オプションが Security Tree クラスオブジェクトでオンになっており、保護対象のオブジェクトに User 参照フィールドが含まれている場合は、レコードが作成されると Vault によって自動的に割り当てられることもあります。有効にすると、Vault は、設定された User 参照フィールド内の指定された User がどのノードに割り当てられているかを評価し、同じ Security Tree ノードへのシステム管理レコード割り当てを作成します。

このオプションは、ユーザに対して既存の静的割り当てがない場合にのみ選択できます。選択すると、制御対象オブジェクトはアクセス許可について User フィールドを参照するように設定できます。

この設定では、レコードごとに個別のオブジェクトツリーの割り当ては必要ありません。ただし、ユーザは 1 つの Security Tree ノードにのみ割り当てることができます。

詳細については、Security Tree Administration をご覧ください。

Child Object Security

管理者には、親レコードへのアクセス権に基づいて子オブジェクトレコードへのユーザアクセスを有効にする簡単なオプションが提供されるようになりました。親子関係が存在する場合、管理者は、親を参照する子オブジェクトのフィールドで Replicate sharing settings from parent object というチェックボックスを使用できるようになります。

25R2 より前は、子オブジェクトのアクセスを親オブジェクトに基づいて決定するには、親オブジェクトとすべての子オブジェクトに対してセキュリティ設定 (カスタム共有ルール、一致共有ルール、Secufity Tree など) を複製する必要がありました。このオプションは、親オブジェクトレコードに割り当てられたロールを自動的に継承することにより、これらのシナリオで管理者に、より高速でシンプルな構成アプローチを提供します。

関係でこの設定を有効にすると、Vault は子オブジェクトの既存の一致共有ルールまたはカスタム共有ルールを削除します。

この設定は、親オブジェクトのカスタム共有ルール、一致共有ルール、または Secufity Tree が有効になっている場合にのみ使用できます。このオプションは、特定の標準オブジェクトでは使用できない場合があります。

詳細については、Child Object Security をご覧ください。

ドキュメントの管理

Collaborative Authoring: Automatic Mentioning for Task Reassignment

共同編集ワークフローアクションを使用する場合、Vault では、タスクが再割り当てされたときに、新しいタスク所有者が共同編集セッションで自動的に @ メンションされるようになりました。

25R1 では、Vault で共同編集時にワークフロー参加者に @ メンションを自動的に許可できる機能強化が導入されました。この機能強化により機能が拡張され、タスクが再割り当てされるときにも同じ動作が適用されるようになります。

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

Synchronous Lifecycle & Workflow Actions for Collaborative Authoring

Collaborative Authoring のためにライフサイクルアクションとワークフローアクションを使用すると、ワークフローに含まれるドキュメントが 1 つのみの場合や、状態の変更が 1 つのドキュメントに対してのみ実行された場合に、Vault は Check Out、Check In、Cancel Editin のアクションを同期的に実行するようになりました。

25R2 より前では、影響を受けるドキュメントの数に関係なく、これらのアクションは常に非同期で実行されていました。これは、ユーザの混乱を招く可能性があります。たとえば、ページは更新されるものの、非同期アクションが終了していないため、ドキュメントはまだチェックアウト済みとして表示されます。ユーザは再度ページを更新する必要があり、最新バージョンに移動されるのではなく、チェックアウトしたバージョンに留まります。

単一ドキュメントのシナリオでこれらのアクションを同期的に実行すると、ユーザエクスペリエンスが向上し、エンドユーザの混乱が軽減されます。ページが更新されると、ユーザはアクションが完了したこと (ドキュメントはもうチェックアウトされないこと) と、最新バージョンになっていることを確認できます。

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

PDF 表示可能なレンディションのメタデータのクリア

管理者は、ソースファイルから選択したメタデータ値を PDF 表示可能なレンディションで維持するか削除するかを定義できるようになりました。

新しいレンディションプロファイル設定、Remove document properties from Viewable Rendition が利用可能になりました。これにより、表示可能なレンディションのプロパティからすべてのソースファイルメタデータ (ファイル名を除く) が削除されます。この設定は、すべてのソースファイルと、自動的に生成された表示可能なレンディションにのみ適用されます。選択すると、この設定は Include source document properties in the Viewable Rendition 設定よりも優先されます。

詳細については、 Auto-Generated Viewable Renditions をご覧ください。

Bring Forward Annotations: Use Coordinates for Text Placement

メモ、リンク、アンカーなどのテキスト選択注釈を移行するときに、選択したテキストがターゲットバージョンに複数回出現する場合、Vault は可能であれば、ソース注釈の座標を使用して、ターゲットバージョンでの正しい配置を確認します。これには、手動または自動で移行された注釈が含まれ、移行されたテキスト注釈の自動配置の成功率が大幅に向上します。

たとえば、このソースバージョンでは、History of the Modem というフレーズが 2 回注釈されています。

以前は、選択したテキストが同じページに複数回表示される場合、それらの移行された注釈はページレベルの注釈として作成されていました。

この機能強化により、移行された注釈が正しく配置されるようになりました。

詳細については、Bringing Forward Annotations をご覧ください。

Auto Bring Forward Annotations from Latest Version

ドキュメントに対して自動の Bring Forward Annotations を実行すると、最新バージョンの注釈のみが移行されるようになりました。以前のバージョンに対象となる注釈がない場合、注釈は移行されません。これにより、より予測可能な結果が得られ、以前のバージョンで解決された注釈メモが前のバージョンから移行されるなどの特定の望ましくない結果が回避されます。

以前は、自動の Bring Forward Annotations により、最新の対象バージョンから注釈が移行されていましたが、これには最新ではない以前のバージョンも含まれる可能性がありました。

Allow Document Owner to Delete Annotations

管理者は、Document Owners に他のユーザの注釈の削除を許可できるようになりました。これにより、誰が作成したかに関係なく、Document Owner ロールに対象となる注釈を個別に削除する権限が与えられます。

25R2 より前は、注釈を削除できるのは注釈を作成したユーザのみでした。この機能強化により、注釈を削除するための余分な労力とコミュニケーションが不要になります。

Document Owner は注釈の削除に必要な権限を持っている必要があり、ドキュメントは Legal Hold の対象になっていません。また、インバウンド参照のあるアンカー注釈は削除できません。

詳細については、nnotating Documents および Managing Annotation Settings をご覧ください。

作成日による注釈のフィルタリング

注釈をフィルタリングする際に、注釈の Created Date でフィルタリングするオプションが追加されました。

この機能は、重要なイベントの前後に作成された注釈に焦点を当てるという一般的なニーズをサポートします。

この機能は、24R3 リリースで廃止されたメモビューでの日付による並べ替えを使用していたユーザにも役立ちます。フィルターは、注釈自体の Created Date と、その最新の返信に基づいて適用されます。

Created Date でフィルタリングする場合、ユーザは以下を使用できます。

• In the range: 特定の日付範囲を選択します。両方のフィールドに同じ日付を指定することで、単一の日付を含めることができます。
• After: 特定の日付以降に作成された注釈を選択します。
• Before: 特定の日付より前に作成された注釈を選択します。

All dates: デフォルトの設定。作成日で注釈をフィルタリングしません。このフィルターを適用しても、ユーザ設定としては保存されません。

詳細については、Annotating Documents をご覧ください。

データの管理

Word Formatted Outputs: Support for Traversing Multiple Outbound Object Levels

Word Formatted Outputs では、単一のフィールド値に対して、ドット表記法 (テーブルをネストする必要はありません) で最大 3 レベルの送信関係のフィールド参照がサポートされるようになりました。たとえば、次の構文がサポートされるようになりました。

audit__vr.facility__cr.country__cr.abbreviation__v

この例では、Vault は 3 つのオブジェクト (Audit から Facility へ、さらに Country へ) を遷移して、Abbreviation フィールドの情報を取得しています。25R2 より前は、送信関係のドット表記で使用できる関係は 1 つだけであったため、他の関係にアクセスするにはテーブルをさらにネストする必要がありました。

この同じ構文は、${HideRowIf(...)} および ${HideTableIf(...)} 構文で使用される式内でも利用できます。

詳細については、Managing Word Formatted Output Templates をご覧ください。

Word Formatted Outputs: Attachment フィールドの画像を印刷する

Word Formatted Outputs では、Attachment フィールドから画像ファイルを表示する機能がサポートされるようになりました。この機能は、以前はレコード添付ファイルとして含まれる画像ファイルに対してサポートされていました。これにより、同じ機能が Attachment フィールドに拡張されます。

Attachment フィールドから画像を表示するには、フィールドトークンに imageSize パラメータを追加する必要があります。ここで、推奨サイズを定義できます。

imageSize パラメータを使用すると、Vault は画像の最大寸法 (高さまたは幅) が指定されたピクセルサイズに一致するように画像を縮小します。

詳細については、Managing Word Formatted Output Templates をご覧ください。

Word Formatted Outputs: Increase Template Page Limit

Word Formatted Outputs は 25R1 リリースで導入され、特定のテンプレートファイルには 10 ページの制限がありました。最初のフィードバックに基づいて、より複雑な出力をサポートするために、この制限は 10 ページから 20 ページに増やされます。

詳細については、Managing Word Formatted Output Templates をご覧ください。

Prevent Creation of New Adobe Formatted Outputs

新しい Adobe 形式の出力テンプレートは、Vault では作成できなくなりました。25R1 で Word Formatted Outputs が導入されたため、新しい形式の出力テンプレートでは Word を使用する必要があります。既存の Adobe テンプレートは引き続き編集して使用できます。

Copy Record Action Security

管理者は、オブジェクトの Copy Record アクションを制限できるようになりました。この機能を使用するには、Admin > Configuration > Objects > [オブジェクト] > Details > Action Security で、オブジェクトの Use Action security to control Copy Record 設定を有効にする必要があります。これを有効にすると、管理者は Permission Sets、Atomic Security: Actions、および Object Types (有効になっている場合) で Copy Record アクションを管理できます。

Copy Record Action Security は、ディープコピーの実行時にすべてのオブジェクトに対して評価されます。たとえば、子オブジェクトで Action Security が有効になっている場合に、アクセス権を持たないユーザが親オブジェクトレコードのディープコピーを実行しようとすると、コピーされたレコードに子オブジェクトレコードは含まれません。

Related Object Section: Record Limits

レコード詳細ページを表示する際に安定したパフォーマンスを確保するため、単純な結合関係を表す関連オブジェクトセクションで取得される関連レコードの数を最大 10,000 件に制限しています。単純な結合関係の場合、関連オブジェクトセクションには単純な結合オブジェクト自体ではなく「もう一方の親」が表示されるため、取得に時間がかかります。

つまり、関連オブジェクトセクションで検索する場合、検索では最初の 10,000 件の単純結合レコードからの結果のみが取得されます。Criteria VQL が使用される場合、それらはデータセット全体ではなく、最初の 10,000 件のレコードに適用されます。これにより、実行時にユーザが参照できるレコード数が 10,000 件未満になる可能性があります。

Enhanced Picklist Field Dependency Administration

この機能は、選択リストフィールドの依存関係の設定やメンテナンスを行うための管理者ユーザインターフェースを大幅に改善するもので、複雑な依存関係設定の柔軟性と効率を高めます。管理者はこれまで、大量の選択リストの組み合わせを扱う際に Vault UI から依存関係を管理できませんでしたが、このユーザビリティの大きな制限が解消されます。

Enhanced Picklist Administration: Reorder Large Picklists

このリリースでは、200 以上の値を持つ選択リストを管理者 UI から並べ替えることができます。これまでは、この操作を行うには Vault API を使用する必要がありました。

今回の更新で導入された並べ替えと順序変更は、すべてのページにわたって機能します。以前のリリースに存在していた、UI 内で並べ替えまたは順序変更できる項目の数の制限はなくなりました。

複雑な関係に対するすべて選択

管理者は、複雑な関係オブジェクトに対して新しい構成オプション Enable Select All を選択できます。このオプションにより、関連オブジェクトセクションで複数のレコードを同時に関連付けるときに、ユーザがすべてのレコードを選択できるようになります。以前は、このオプションは単純な関係オブジェクトに対してのみ使用可能でした。

Checklists: Available Answer Enhancements & Randomization of Question & Answer Order

以前は、Checklists Design から作成された Available Answer レコードは、実際の Checklist が Checklist Design (インスタンス化) から作成されるたびに複製されていました。この変更により、インスタンス化された Checklist に対して Available Answer レコードのコピーは作成されなくなります。代わりに、Available Answer のセットは、Checklist Design から作成された Checklist 間で共有されます。

この更新の一環として、管理者は Question と複数選択の Available Answer を Checklist 内でランダム化することもできます。さらに、Checklist が削除されたときに Available Answer レコードが削除されなくなりました。重複した Available Answer レコードは、25R3 で削除されます。

Checklists: Long Text & Rich Text Support for Comments

チェックリストは、質問に関連する回答者からの Text (1,500) コメント、Long Text (32,000) コメント、Rich Text (32,000) コメントを受け入れるように構成できるようになりました。

管理者は、新しいオプションを表示するには、Admin > Configuration > Checklist Types の下にある関連するチェックリストタイプごとに、Comment Type フィールドを Visual Checklist Designer Fields > Question Design セクションに追加する必要があります。

Label Limit Increases for Layouts

オブジェクトページレイアウトのラベル制限が次のように増加されました。

• セクションヘルプコンテンツ: 255 → 500
• セクションラベルl: 40 → 150
• ページラベル: 40 → 60
• レイアウトラベル: 100 → 150

ユーザエクスペリエンス

Flexible Multilingual Search

多言語ドキュメント処理が有効になっている Vaults では、ユーザはいつでもすべての言語を柔軟に検索できるようになります。言語設定を指定する必要がなく、多言語検索に伴うパフォーマンスの低下もありません。

クエリ言語検出

ユーザが検索語を入力すると、Vault は語句の言語を検出し、動詞の時制や名詞の単数形と複数形の違いなど、言語固有のニュアンスを失うことなく、正しいテキストが検索されるようにします。Vault 言語とユーザの言語のテキストが常に検索されます。

言語に依存しないインデックス化

言語検出によってユーザが検索している言語を確実に判断できない場合、ユーザの検索語句はインデックス内の新しい多言語フィールドと照合され、テキストがどの言語で書かれているかに関係なく、柔軟な照合のために単語が分析および分割されます。

この新しいアプローチにより、ユーザは検索する言語を検討したり指定したりすることなく、アクセスできるすべてのドキュメントを検索できます。新しい多言語フィールドと高速言語検出を組み合わせることで、Vault はこれらの多言語検索を効率的に実行できるようになります。

この機能強化により、ユーザプロファイルの Search Preferences セクションは廃止され、UI から削除されます。このセクションは、ユーザが検索する言語を指定できるようにするために用意されていましたが、Vault では常にすべての言語が検索されるようになったため、これらの設定は不要になりました。

Summary Email Enhancements & User-Driven Notifications

25R1 では、ユーザの受け取る過剰な通知数を削減するための機能強化を導入しました。お客様にはこれらの変更を 25R2 まで延期するオプションがありました。延期を有効にした Vault は、次の更新を受け取ります。

• 具体的には、次のように設定なしにメール通知全体を削減します。
  • これまで多数の通知テンプレートにおいて Email Preference フィールドが Every Occurence に設定されていた場合、このフィールドを (Platform とアプリケーション固有テンプレートの両方で) Summary に設定。
  • None に設定されていた場合は、タスクリマインダー通知 (object_task_reminder_notification__v および task_reminder_notification__v) の Notification Category フィールドを Tasks に設定。
  • Delivery Interval のデフォルト値を 1 時間に変更。
  • Annotation Replies、Send As Link、Shared Views、Favorite Document 通知フィールド、Summary Email Interval 選択リストなど通知関連の一部フィールドをデフォルトで User Profile ページに表示。これにより、ユーザが各自で通知設定を調整できるようになります。
    • Tasks と User Mentions はデフォルトでは追加されませんが、以前にすでに追加されている場合は削除されません。

この変更は、すべてのユーザがこれまでどおり必要な情報を概要メールで受信しながら、Vault から受信するメールの総数を削減するうえで役立ち、管理者の労力を削減します。管理者は、カスタム Notification Categories の作成、テンプレートによる設定の調整、Email Summary 設定の調整、User Profile ページに表示するフィールドの調整など、追加のカスタマイズを実行できます。

詳細については、Summary Emails をご覧ください。

Additional Notification Enhancements

過剰な通知数をさらに削減し、概要メールをより明確にするために、すべての Vault に 2 つの追加通知拡張機能が導入されます。これは、25R1 で Summary Email Enhancements & User-Driven Notifications 機能を受け取った Vault と、その機能を 25R2 まで延期することを選択した Vault の両方に適用されます。

管理者は、ユーザの Favorite Documents カテゴリが Never に設定されている場合に、Favorite Documents の変更に関する Vault 通知が送信されないようにする新しいフラグ (デフォルトで有効) をクリアできるようになりました。Favorite Documents メール設定がないユーザは、Favorite Documents 通知テンプレートの Email Preferences が Never に設定されている場合、Vault 通知を受信しません。フラグは Admin > Settings > General Settings で利用できます。

Summary Email Enhancements & User-Driven Notifications 機能の導入により、ユーザは Favorite Documents に関するメール通知を受信するかどうかを制御できるようになりましたが、Vault 自体の通知は常に送信されます。この変更により、ユーザは Vault とメールの両方で、Favorite Documents に関する通知を受信するかどうかを完全に制御できるようになります。

さらに、Vault 概要メールの件名には、メールを生成した Vault の名前が含まれるようになりました。ユーザが受信する概要メールが増えるため、複数の Vault にアクセスできるユーザは、各メールがどの Vault に適用されるかを区別しやすくなります。

詳細については、Email and Messages Administration をご覧ください。

Vault Delegation: Usability Enhancements

アクセス権の委任機能を使用すると、ユーザはより合理化されたエクスペリエンスを得られるようになります。

Homeタブから委任者を選択すると、Vault にはユーザが現在所属する Vault の委任されたアカウントのみが表示されるようになりました。

25R2 より前は、ドメイン全体の委任されたアカウントがすべてユーザに表示されるため、委任者を選択するときにユーザがどの Vault にリダイレクトされるのかが不明瞭でした。

さらに、メインアカウントに戻ったときに、ユーザは委任者としてアクセスしていた Vault に留まるようになりました。

25R2 より前は、My Vaults が有効になっている場合、ユーザは My Vaults ページにリダイレクトされ、作業していた Vault に戻るには余分なクリックが必要でした。

詳細については、Using Delegate Access をご覧ください。

Email to Vault: バウンス通知

Email to Vault 機能を使用すると、Email レコードが Bounced 状態で作成された場合、Vaultは User および Person の送信者に通知するようになりました。

メールがスパムとしてマークされている場合、承認されていない送信者から送信されている場合、またはメール認証 (SPF、DKIM、DMARC を含む) に失敗した場合、Vault は Email レコードを Bounced 状態で作成します。25R2 より前は、顧客は動的フラッシュレポートを利用して、Bounced Email レコードの通知を受ける必要がありました。

この機能強化により、Email レコードが作成された時点で送信者に直接通知されるようになります。

この機能を有効にするために、受信メールアドレス設定で新しいチェックボックスが使用できます。管理者がこれを使用することで、バウンスメールに関する通知を送信するかどうかを決定できます。

この設定は、既存のすべての受信メールアドレス設定でデフォルトで無効になっています。

詳しくは、Vault へのメールの設定をご覧ください。

Allow VeevaID Users to Change Email

VeevaID ユーザは、自身のアカウントに関連付けられたメールアドレスを変更できるようになりました。メールアドレスを変更すると、ユーザ名も更新されます。My Account ページで、ユーザは自身のメールアドレスとユーザ名を編集できます。

メールアドレスを更新した後、画像ベースの認証チェックが行われる場合もあります。

認証チェックを完了すると、次のような確認メールが届きます。

最後の確認ステップで、以前のメールアドレスとパスワードを入力するよう求められます。

25R2 より前は、メールアドレスがユーザ名としても使用されていたため、VeevaID ユーザはメールアドレスを変更できませんでした。この機能強化により、セキュリティを損なわずに柔軟性を得られます。

VeevaID のメールアドレスとユーザ名の更新は、変更後にユーザが初めて Vault にログインしたときに、Person および Prior Person レコードにも同期されます。この同期をサポートするため、Person オブジェクトと Prior Person オブジェクトに新しい User Name フィールドが追加されました。

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

分析

マルチパスレポートでのセルの結合

マルチパスレポートでは、重複する値を含むセルの結合がサポートされるようになりました。この機能強化により、Vault ユーザインターフェース内でマルチパスレポートをより簡単に解釈できるようになります。

Advanced Options の新しいオプションを使用すると、レポート編集者はレポートでセルを結合するかどうかを選択できます。

このオプションを選択すると、レポート編集者は結合する列を指定できます。

これは、Long Text と Rich Text を除くすべてのデータ型でサポートされています。オブジェクトおよびドキュメント参照の場合、フィールドは Name ではなく ID に基づいて結合されます。グループ化を含むレポートの場合、Vault はセルの結合に基づいて集計値を再計算しません。

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

Combined Dashboard Prompts Enhancement

ダッシュボードプロンプトを、被参照オブジェクトと演算子ではなくプロンプトラベルを使用して結合できるようになりました。これにより、ユーザは基になるレポートのエイリアス機能を使用して複数のプロンプトに同じラベルを付け、ダッシュボードでそれらのプロンプトをラベルに基づいて結合できます。

25R2 より前は、プロンプトラベルに基づいて結合する機能はレポートプロンプトに対してのみ使用できました。ダッシュボードプロンプトは常に、同じオブジェクトに存在する同じ演算子を持つプロンプトに基づいて結合されていました。このロジックをダッシュボードプロンプトに拡張することで、エクスペリエンスの一貫性と柔軟性が向上し、より多くのプロンプトを結合できるようになりました。

新しいダッシュボードを作成するとき、または既存のダッシュボードの名前を編集するときに、ダッシュボードで何に基づいてプロンプトを結合するかを選択するオプションが表示されるようになりました。デフォルトでは、25R2 より前のリリースの動作が選択されています (Referenced Field)。

基になるレポートでエイリアスを使用して複数のプロンプトに同じラベルを付けている場合、Prompt Label を選択できます。

詳細については、Creating & Editing Dashboards、および How to Define Filters and Prompts をご覧ください。

Enhanced Contains & Search Operators in Report Filters

ユーザは、既存の大文字と小文字を区別する演算子に加えて、大文字と小文字を区別しない演算子を使用して、レポート内のオブジェクトテキストフィールドをフィルタリングできるようになりました。

さらに、新しい検索演算子を使用して、レポートで Long Text フィールドと Rich Text フィールドをフィルタリングできるようになりました。

これらの機能強化により、レポートユーザはより柔軟に必要な結果を得られるようになります。

詳細については、Using Report Filters をご覧ください。

レポート数式フィールドの空白処理の機能強化

レポートで数式フィールドを作成する場合、ユーザは空白を空白として扱い続けるか、ゼロまたは空の文字列として扱うかを選択できるようになりました。これにより、レポート数式での空白フィールドの処理方法に柔軟性が得られ、空白値の処理方法について、他の Vault 数式フィールドとの一貫性も確保されます。

上記のスクリーンショットでは、Blank Field Handling が Treat blank fields as blanks に設定されていて、Document Title フィールドが空白の場合、全体的に空白の値が返されます。Blank Field Handling を Treat blank fields as zeros and empty strings に設定すると、Document Title フィールドが空白のドキュメントに対して Vault は Hello を返します。

25R2 より前では、これを実現するには、ユーザは複数の IsBlank() 関数と If() 関数を使用して関数を記述する必要がありました。

詳細については、Report Formula Fields をご覧ください。

マルチパスマトリックスレポート

レポート作成者は、マルチパスレポートタイプを使用してマトリックスレポートを作成できるようになりました。マトリックスレポートはピボットテーブルに似た構造になっており、これまでは標準レポートタイプでのみサポートされていました。Create Report ページでマルチパスレポートを選択すると、Report Format として Matrix を選択できるようになりました。

レポートエディタでは、レポートビュー全体の任意のフィールドを選択して、行をグループ化したり、列をグループ化したりできます。

標準のマトリックスレポートと同様に、お客様はグループ化されたデータを各グループの詳細な表形式レポートで表示できます。お客様は、基礎となるレポートビューに列を追加することで、これらのビューの列レイアウトをカスタマイズできます。Vault は、詳細表示で最大 100 列をサポートします。

標準的なレポート機能に加えて、マトリックスマルチパスレポートでは Vault 数式フィールドと高度なフィルターロジックもサポートされており、お客様はより強力で柔軟なレポートを作成できます。

この機能はラダーマルチパスレポートではサポートされていません。

詳細に関しては、Matrix Reports および Multi-Pass Reports をご覧ください。

Include Tags in Report Exports

表紙を含めてレポートをフォーマット済み Excel としてエクスポートした場合、エクスポートされたファイルの表紙にレポートタグが含まれるようになりました。

さらに、PDF レポートのエクスポートでは、Report Export Cover Page (Business Admin > Templates > Signature & Cover Pages) で、${reportTags} トークンを使用してレポートタグを含められるようになりました。

詳細については、Configuring the Tags Picklist をご覧ください。

Document Formula Fields: Deprecation of Non-State Fields

ドキュメントレポート数式フィールドで Process Reporting 機能をサポートするために Cycle Time 関数が利用可能になったため、既存の設定済みドキュメント数式フィールドのうち、以下の関数を使用していて、なおかつ Document Status または State Type を使用していないものは、空白を返すようになります。

• CountInValue
• DurationInValue
• PreviousValue
• FirstTimeInValue
• LastTimeInValue

Document Status または State Type を使用する既存の数式フィールドはこれまで通り機能します。

Support Last Modified By & Created By in Object Formulas

他のユーザ参照フィールドと同様に、Last Modified By および Created By フィールドを数式で利用できるようになりました。25R2 より前は、これらの 2 つのフィールドはどの Vault 数式エディタでも選択できませんでした。以下の領域のオブジェクトで使用できるようになりました。

• 検証ルール
• 数式フィールド
• フィールドデフォルト

これらのフィールドは既存の機能と組み合わせて使用できます。たとえば、Id(created_by__v) は、Created By フィールドにユーザの ID を返します。

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

Enhanced Document Picklists in Formulas

ドキュメント選択リストフィールドは、ライフサイクルおよびワークフローの数式のラベルではなく、選択リスト値の名前を返すようになりました。この動作は、レポート内のオブジェクト選択リストフィールドとドキュメント選択リストフィールドと一致するようになりました。ライフサイクルおよびワークフローの数式でのドキュメント選択リストの既存の使用は、Text() 関数にラップされ、ラベルを返して現在の動作を維持します。

この機能が導入される前は、Vault 式間でのドキュメント選択リストの動作に一貫性がなく、ライフサイクルとワークフロー式内でのオブジェクトとドキュメントの選択リスト間に一貫性がなかったため、ユーザに混乱が生じていました。

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

管理者エクスペリエンス

Direct Data API: Admin Enablement

管理者は、サポートチケットを開かなくても、Admin > Settings > General Settings で Direct Data API を有効にできるようになりました。この有効化は一方向であるため、一度有効化すると元に戻すことはできません。

CountIf & CountA for Multi-Item Workflow Conditions

既存の CountA() 関数と新しい CountIf() 関数により、管理者はタスクとアイテム (ドキュメントまたはオブジェクト) の数を使用する決定ステップとアクションステップの条件を設定できるようになりました。

• CountA() はタスクまたはアイテムの合計数を返します。
• CountIf() は条件に一致するタスクまたはアイテムの合計数を返します。

タスクがキャンセルされていないことを確認したい場合は、CountIf() を使用して、ステータスが TaskStatus.CANCELED であるタスクの数がゼロ (0) であることを確認できます。

CountIf(Tasks.review__c.status, x, x = TaskStatus.CANCELED) = 0

より複雑な例として、すべての参加者に割り当てられたすべてのタスクが承認されていること、および Legal や Regulatory などの重要な参加者グループからキャンセルされたタスクがないことを確認したい場合があります。この機能が導入される前は、タスクがキャンセルされた場合でも、「すべての判定は Approved」のままでした。ただし、以下の式に基づく評価により、すべての参加者がタスクを完了し、キャンセルがないことを確認できます。

AND( CountIf(Tasks.review__c.verdict, x, x = "Approved") = CountA(Tasks.review__c.verdict), CountIf(Tasks.review__c.status, x, x = TaskStatus.CANCELED) = 0 )

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

オブジェクト参照フィールドのデフォルト値

関連レコードフィールドセレクターを Object > Field > Default Value の式エディタに置き換えることで、管理者がオブジェクトフィールド値をデフォルト設定できる方法を拡張しました。

関連レコードフィールドによるデフォルト設定 (送信)

式エディタの横にある自動補完トークンボタンをクリックすると、以前の機能と同様に、送信オブジェクトの関係を参照し、同じオブジェクトに対して設定されている任意のフィールドを選択できます。送信関係からのフィールドは、最大 3 レベルまでサポートされます。

RecordByUniqueField() 関数によるデフォルト設定

デフォルトとして設定しようとしているオブジェクトレコードが関係に基づいていない場合は、RecordByUniqueField() 関数を使用して、一意のフィールド値によって任意のオブジェクトレコードを識別できます。

以下は、選択した国に基づいて、Region オブジェクトフィールドをデフォルトに設定する例です。

IF( country__cr.name__v = "USA", RecordByUniqueField($region__c, {$name__v:"North America"}), RecordByUniqueField($region__c, {$name__v:"Other"}) )

また、数式の記述を容易にするために、RecordByUniqueField() 関数にユーザフレンドリーな数式ヘルパーも提供しました。式エディタの上にある Records タブをクリックするとダイアログが開き、ドロップダウンリストから適切なパラメータを選択できます。選択すると、正しいパラメータを含む数式が式エディタに挿入されます。

詳細については、Setting Object Field Defaults をご覧ください。

フラッシュレポート設定移行のサポート

管理者は、設定移行パッケージを使用して環境間でフラッシュレポートを移行できるようになり、移行後にレポートを再スケジュールする手間が軽減されます。25R2 より前は、関連付けられたジョブを移行できなかったため、関連付けられたスケジュールを維持しながらフラッシュレポートを移行することはできませんでした。

今後、設定移行パッケージにフラッシュレポートを含める場合、管理者は関連するジョブを含めることができます。

View/Add Dependencies オプションを使用すると、ジョブは依存関係としても表示されます。

Runs As ユーザがターゲット Vault で使用できない場合は、移行ユーザがフラッシュレポートの Runs As ユーザとして設定されます。フラッシュレポートが移行され、関連するジョブが移行されない場合、レポートは通常のレポートとして移行されます。

詳細については、Flash Reports をご覧ください。

Vault User Layout Enhancements

管理者が Admin > Users & Groups からユーザレコードを表示するときのユーザインターフェースが更新され、他のオブジェクトと同じになりました。また、すべてのオブジェクトレイアウト機能も完全にサポートされました。

24R1 で、レイアウトのカスタマイズ性を高めるさまざまな機能強化を提供するために、Action Layouts が導入されました。ただし、Users & Groups ページでは、これらの機能強化の一部が提供されておらず、たとえばページは使用できませんでした。

この機能強化により、管理者は他のオブジェクトをカスタマイズする場合とまったく同じように、ユーザ管理のエクスペリエンスをカスタマイズできるようになりました。

また、今回の更新により、User レコードで Download as PDF 機能がサポートされました。

Include Collaborative Authoring Settings in Sandbox Refreshes

最新の Collaborative Authoring 設定 (Collaboration User なし) を使用して、検証済みの接続を持つ別の Vault から Vault が更新されると、Collaborative Authoring 設定は更新の一部として維持されます。これにより、管理者の労力が軽減されます。25R2 より前、または従来の Collaborative Authoring 設定を使用している場合は、Collaborative Authoring 接続を設定して、更新ごとに再検証する必要があったためです。

この機能強化により、更新前にその環境に存在していた接続が明示的に再適用されます。Collaborative Authoring 接続は、親 Vault から複製またはコピーされません。

すべてのお客様は、26R1 リリースまでに Collaborative Authoring 設定を最新の方法に更新する必要がありますが、この設定を早めに更新すると、管理者はよりスムーズにサンドボックスを更新できるようになります。

Security Policy Conversion

管理者は、ユーザのセキュリティポリシーをパスワード/SSO から VeevaID またはクロスドメインに、またはクロスドメインからパスワード/SSO に変換できるようになりました。

25R2 より前は、ユーザのセキュリティポリシーを変更することはできませんでした。つまり、必要な場合には、既存のアカウントを非アクティブ化して新しいアカウントを作成する必要がありました。既存のアカウントがドキュメント、レコード、またはタスクを所有している場合、それらの再割り当てが必要になるため、この作業は非常に手間がかかる可能性があります。

ユーザのセキュリティポリシーを変換した後、そのユーザの完全な履歴と現在進行中の作業は維持されます。

ユーザのセキュリティポリシーを変換するとき、管理者は User Name も更新する必要があります。たとえば、クロスドメインユーザの User Name は常に、ユーザのホームドメインの User Name になります。

ユーザのセキュリティポリシーを VeevaID に変換することはできますが、VeevaID ユーザを別のセキュリティポリシーに変換するメカニズムはありません。

詳細については、Security Policies をご覧ください。

Vault Loader Enhancements for Object Record Create, Update, Delete Operations

オブジェクト操作 Upsert、Update、および Delete に対して Loader ログに返される回答が強化され、回答とともに追加情報が提供されるようになりました。

• キー値 (idParam) が指定された場合、指定されたフィールドに対応する値が、回答内の id_param_value 列に含まれます。
• キー値 (idParam) を使用して Upsert が要求された場合、レコードレベルの結果 (Create または Update) が回答に含まれます。

Enable Inbound & Outbound Package Settings for All Vaults

このリリースより前は、顧客は管理者設定を使用して、受信パッケージと送信パッケージを手動で有効にする必要がありました。このリリースでは、受信パッケージと送信パッケージがデフォルトで有効になり、この機能を管理するための以前の管理者設定は削除されました。

式で使用できる Vault トークン

Vault では、数式内での Vault トークンの使用がサポートされるようになりました。25R2 より前は、@Vault システム変数を使用してアクセスできたのは、Domain、Timezone、Vault ID のみでした。管理者は他の標準トークンを返したり、Vault の数式にカスタムトークンを含めたりできるようになりました。

デフォルトでは、管理者は次の標準 Vault トークンを数式で利用できます。

• Domain
• Timezone
• Vault DNS
• Vault ID
• Vault Name

これらのトークンは次の領域で活用できます。

• オブジェクト:
  • 検証ルール
  • 数式フィールド
  • フィールドデフォルト
  • レイアウトルール
• ドキュメントとオブジェクトの両方のワークフローとライフサイクル条件
• レポート数式フィールド

さらに、管理者は Admin > Configuration > Vault Tokens でカスタム Vault トークンを設定できます。

これらのカスタムトークンは数式でも使用できます。

詳細については、Creating Formulas in Vault および Vault Tokens をご覧ください。

Jobs: Timeout Statuses

ジョブのステータスを正確に表すために、次の新しいジョブステータスが利用できるようになりました。

• Timeout: キュー処理中のジョブがタイムアウトしたかどうかを示します。
• Completed due to Inactivity: 実行中のジョブがタイムアウトしたかどうかを示します。

キュー処理状態またはキュー処理中状態のジョブのキャンセル

管理者は、キャンセルの対象となるキュー処理された、またはキュー処理中のジョブインスタンスを個別にキャンセルできるようになりました。

• 日付ベースのカスタムドキュメントおよびオブジェクト操作ジョブ

• キャンセル可能に指定されたカスタム SDK ジョブ

• アプリケーションチームがキャンセル可能と指定した標準ジョブとアプリケーション固有のジョブ

以前は、管理者がキュー処理されたジョブをキャンセルするには、サポートチケットを作成する必要がありました。対象となるジョブは、Operations > Job Status ページで個別にキャンセルできます。Running 状態のジョブはキャンセルできません。

Vault Loader: No Triggers の使用のキャプチャ

ジョブの詳細と通知で、レコード移行モードに No Triggers フラグが使用されたかどうかをキャプチャします。

マイナー変更

Object Lifecycle Entry Criteria Limit

このリリースでは、関連レコードの状態に対するオブジェクトライフサイクル状態エントリ条件の検証において、関連レコード数の制限が 20,000 レコードに増加しました。

Object Reference Field Item Limit

ドキュメントのフィールドでオブジェクトレコードを選択する場合、選択できるレコード数は 250 件までという制限があります。25R2 より前は、レコード選択ダイアログボックスから Select All を使用する場合、この制限は適用されませんでした。今後、この制限はすべての場合に適用され、レコードを個別に選択する場合にも、Select All を使用する場合にも適用されます。

ドキュメントビューア: ズームのキーボードショートカットの更新

ドキュメントビューアでのズームインおよびズームアウトのキーボードショートカットが、次のように更新されました。

Windows:

• Zoom In: Shift + Ctrl + + (Shift + Ctrl + plus)
• Zoom Out: Shift + Ctrl + - (Shift + Ctrl + minus)

Mac:

• Zoom In: Shift + Cmd + + (Shift + Cmd + plus)
• Zoom Out: Shift + Cmd + - (Shift + Cmd + minus)

25R2 より前のバージョンでは、ショートカットに Shift が含まれていなかったため、ブラウザのショートカットと競合する可能性がありました。

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

Document Viewer: Updated Keyboard Shortcut for Grab

Document viewer toolbar の Grab & Pan ボタンを切り替えるためのキーボードショートカットが、Ctrl + Shift + P (Windows) および Cmd + Shift + P (MacOS) に更新されました。これにより、以前のショートカットキー Shift + Space を使用した場合に発生していた予期しない結果を回避できます。

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

ドキュメント処理が完了するまで手動の注釈移行を無効にする

以前のバージョンから注釈を手動で移行する場合、光学式文字認識 (OCR) が完了するまで、Bring Forward Annotations ボタンが無効になります。

注釈が移行されたときに OCR が完了していない場合、テキストは認識されず、Vault は移行された注釈を適切に配置できません。この機能強化により、ページレベルの注釈になる可能性を減らすことができます。

ユーザはページを更新する必要はありません。OCR が完了すると、Bring Forward Annotations ボタンが自動的に有効になります。

さらに、OCR は完了しているものの、注釈が自動移行中の場合、ボタンは無効のままになります。

Text Selection & Copy Text Limit Increased to 500 Words

ドキュメントビューアでドキュメントからテキストをコピーする場合、最大 500 語まで選択してコピーできるようになりました。25R2 より前は、200 語に制限されていました。この機能強化により、ユーザの柔軟性が向上し、Veeva RIM での保健当局の質問抽出などのアプリケーション固有の機能がサポートされます。

詳細については、Copy Text をご覧ください。

Vault File Manager: Improved Clear Button on Uploads & Downloads Tabs

Vault File Manager の Uploads タブと Downloads タブの Clear ボタンを使用すると、次のステータスにあるすべてのドキュメントが削除されます。

• Complete
• Failed
• Corrupted
• File Not Found
• Cancelled

25R2 より前は、Complete または Cancelled のドキュメントのみが削除され、その他のドキュメントは個別に削除する必要がありました。

この機能強化により、管理者は Vault File Manager 内でエラーを簡単にクリーンアップおよび削除できるようになり、数百または数千のファイルをアップロードまたはダウンロードする場合に特に役立ちます。

詳細については、Accessing Your File Staging Server in Vault File Manager をご覧ください。

Enhanced Duplicate Attachment Detection

この更新により、MD5 チェックサムがまだ計算されていない既存の添付ファイルとまったく同じファイル名を持つ新しい添付ファイルをアップロードできなくなりました。このセーフガードにより、ファイルの一意性とデータの一貫性が保証されます。

Automatic Mentioning in Collaborative Authoring: Updated Messages in CSV

Collaborative Authoring で自動メンションを使用すると、オプションの CSV 通知で更新された文言がユーザに表示されるようになりました。Check Out to Collaborative Authoring ワークフローアクションでの Vault と Office 365 間のやり取りをより正確に反映するために、オプションの CSV 通知内のメッセージが更新され、Vault が SharePoint 上のドキュメントに対する Edit 権限を明示的に付与することが反映されます。

25R2 より前のバージョンでは、CSV メッセージに、ユーザに @ メンションする権限が付与されていることが記載されていましたが、Microsoft テナントの設定や、ユーザが外部ユーザであるかどうかによっては、必ずしもそうとは限りません。

この機能はユーザの動作を変更するものではありませんが、成功メッセージと失敗メッセージの表現がより明確になります。

詳細に関しては、About Notifications for Collaborative Authoring Workflow Actions をご覧ください。

Collaborative Authoring Error Log: 拡張されたログ

Collaborative Authoring Error Log に、Collaborative Authoring ドキュメントのチェックアウトとチェックインに関連して Microsoft Graph API によって返されたすべてのエラーが表示されるようになりました。以前は、チェックアウト中のファイルのアップロードとチェックイン中のファイルの削除に関連するエラーのみがログに表示されていました。

Vault File Manager: Updated Naming for Excel Files

Microsoft Excel で角括弧を含むファイル名の取り扱いが変更されたことに伴い、Vault File Manager で Excel ファイルをチェックアウトするときにファイル名に含まれる角括弧が丸括弧に置き換えられるようになりました。

Object & Document Audit Logs Date Filter Limit

Admin > Logs で Object Record Audit History および Document Audit History ページを表示するとき、 Timestamp が必須フィルタになりました。指定できる期間は 365 日に制限されています。

この変更の目的は、Vault のパフォーマンスを保護することにあります。他のフィルタを指定したとしても、監査証跡のサイズによっては、複数年にわたるデータを取得する場合にパフォーマンスの問題が生じる可能性があります。

詳細については、Viewing Admin Logs をご覧ください。

Login Audit History: My Vaults Page

My Vaults ページが有効になっているドメインでは、ユーザがログインして My Vault ページに入ったときに、Login Audit History に Enterprise Home User Login という新しいイベントタイプが記録されるようになりました。

この機能強化により、ユーザがどこで認証されたかが明確になり、正確性が向上します。25R2 より前は、ユーザがログインして My Vaults ページを開始した場合、これは通常のログインイベントとして記録されていました。

システム監査ログ: フィールド依存性の変更時にレコードラベルを表示

Controlled by Document Field に設定されたドキュメントフィールド依存性を作成または編集し、条件がオブジェクトレコードを参照する場合、システム監査履歴は ID ではなくラベルによってレコードを識別するようになりました。この機能強化により、ID でレコードを検索する必要がなく、監査ログ内の特定の変更を簡単に識別できるようになります。

たとえば、このフィールド依存性は、Project オブジェクト参照フィールドに対して、Controlled by Document Field に設定されています。

フィールド依存性自体には Project 1 が選択されます。

システム監査履歴には、レコード ID の代わりに特定のレコードラベル Project 1 が表示されるようになりました。

詳細については、Managing Dependent Fields をご覧ください。

Prior Person: Lock Format Mask for Name Fields

管理者は、Prior Person オブジェクトで First Name、Last Name、User Name フィールドの書式マスクを設定できなくなりました。

Rename Vault Java SDK Logs to Developer Logs

Vault UI で、Vault Java SDK Logs の名前が Developer Logs に変更されました。デバッグログとランタイムログをダウンロードする統合は、この変更の影響を受けません。

25R2 Platform Data Model Changes

変化するニーズと新機能をよりよくサポートできるように、データモデルはリリースのたびに更新されます。

Veeva Connect で 25R2 のデータモデルのドキュメンテーションにアクセスしてください。

• Vault Platform
• Clinical Operations
• Commercial
• Quality
• Regulatory
• Safety
• Consumer Products

Veeva Connections

Clinical Operations と EDC の接続

Clinical Operations-EDC Connection: Final CRFs

この機能は、最終的な (クローズアウト) 症例報告ファイル (CRF) を Veeva EDC から Veeva eTMF に自動的に送信することで、Clinical Operations と EDC 間の接続を改善します。これにより、CRF が被験者ごとに個別の PDF ドキュメントとして Veeva eTMF に自動的に保存されるため、手作業が大幅に削減されます。

また、CRF ファイルが Veeva EDC で再生成された場合、それらの最終 CRF TMF ドキュメントも自動的に更新されます。これにより、試験終了ドキュメントの管理がより効率的になり、SiteConnect を使用して Veeva eTMF から施設に CRF を簡単に送信できます。

対象ドキュメントには、Study、Study Country、Study Site、ドキュメントの Title (被験者の名前に基づく) などの関連情報が自動的に入力されます。eTMF に保存されるドキュメントのバージョンは、ソース CRF のバージョンと一致します。この転送を有効にするには、いくつか設定を行う必要があります。

その他の新しい Clinical Operations の機能については、以下をご覧ください。

Clinical Operations-EDC Connection: Automatic Procedure Definitions Alignment

現在、Clinical Operations-EDC Connection の Procedure 統合を有効にするには、ユーザは Clinical Operations と EDC Vault の両方で Procedure Definitions を手動で作成する必要があります。この機能はこのプロセスを自動化するもので、EDC の Procedure Integration Configuration Definitions を利用して Clinical Operations 内に対応する Procedure Definitions を自動的に作成します。EDC 内の対応するコネクションが削除されても、このコネクションでは CTMS 内の Procedure Definitions は削除されません。ユーザは、自動支払いの設定など、必要に応じて CTMS で Procedure Definitions を引き続き作成することができます。

この新しい Procedure Definition 統合ポイントは、アクティブな Procedure 統合を持つ顧客については、リリース時にデフォルトで有効になります。この変更は、Procedure に Clinical Operations-EDC Connection を使用しない顧客 (つまり、Procedure 統合が非アクティブ) には影響しません。アクティブな Procedure 統合を持つ顧客の場合、EDC の Procedure Definition の次回更新から、このコネクションにより必要に応じて CTMS に Procedure Definitions が作成されます。既存の Procedure Definitions は、このコネクションによって変更されません。

この機能強化により、コネクションの Procedure Definitions の処理が Visit Definitionsの管理と整合され、システム全体で EDC と CTMS 間のメタデータ管理に対する一貫したアプローチが確保されます。さらに、自動化によって手作業が排除され、エラーのリスクが軽減されるため、プロセスが合理化および簡素化されます。

その他の新しい Clinical Operations の機能については、以下をご覧ください。

Clinical Operations-EDC Connection: CTMS Visit Definition to Visit Group Relationship

現在、CTMS 内で明示的に接続されていなくても、Clinical Operations-EDC Connection により、EDC システムから CTMS に Visit Group Definitions と Visit Definitions が自動的に取り込まれます。

この機能により、Clinical Operations-EDC Connection が強化され、CTMS 内で Visit Definitions および Visit Group Definitions 間の直接的な関係を作成および管理できるようになりました。これは、新しいオブジェクトと、EDC 内の対応する関係に基づいてこれらのリンクを自動的に確立する専用の統合ポイントを通じて実現されます。システムでは、EDC で見つかった関連ペアごとに CTMS 内の既存のレコードを更新するか、新しいレコードを作成します。一致する Visit Definition または Visit Definition が CTMS に見つからない場合、ユーザ例外メッセージが生成されます。新しい統合ポイントは Inactive として提供されます。

この機能強化により、CTMS での治験訪問構造の表現がより詳細かつ正確になり、治験プロトコルでの管理と整合性が向上します。

その他の新しい Clinical Operations の機能については、以下をご覧ください。

Medical-CRM Connection

Medical-CRM Connection: Medical Inquiries

このリリースでは、Veeva Medical Vaults と Vault CRM 間の新しい標準 Veeva Connection が導入されました。Vault CRM で発生した医学的照会を処理するため、対応する Account 情報を使用して医学的照会を Veeva Medical と共有できます。Veeva Medical で行われた Case の更新と終了に関する情報は、Vault CRM に戻されて共有されます。データ使用契約で許可されている場合、Case Contact の情報は、Veeva Medical で設定された既存の Case Contacts に合わせられます。

この新しい強力なコネクションは、複数の Veeva Medical Vault と複数の Vault CRM の接続をサポートしており、ドキュメントとオブジェクトデータのシームレスなフローを可能にするスケーラブルで標準化されたフレームワークを実現します。

その他の新しい Medical の機能については、以下をご覧ください。

PromoMats と Medical の接続

PromoMats-Medical Connection: Auto Update Anchor Support

コネクションによって作成されたアンカーは、Crosslink が定常状態に移行する前に、Crosslink のドラフト状態で使用できます。この機能強化により、Update Claims Reference Anchors 定常状態エントリアクションがサポートされ、Reference Crosslink を使用するテキストアセットが最新であることが保証されます。

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

Quality と RIM の接続

Quality-RIM Connection: Event Auto-Create Per Change Control & Product Family

このリリースは、Quality-RIM Connection の Enhanced Change Control 機能をベースに構築されており、Event をより正確に自動で作成できるようになります。Change Control と Product Family の組み合わせごとに一意の Event を自動的に作成できるようになりました。

合理化されたイベント管理

Quality-RIM: Change Item to Event and Event Change Item 統合ポイントが更新され、Change Control およびProduct Family の特定の組み合わせに基づいて個別のイベントを作成できるようになりました。これにより、よりきめ細やかで組織的なアプローチでイベントを管理できるようになります。

主な利点

• きめ細かなイベント追跡: Change Control と Product Family の組み合わせごとに個別のイベントが自動的に作成され、品質関連のアクティビティをより正確に追跡および管理できるようになります。
• 効率性の向上: イベント作成を自動化することで手作業を削減して、ワークフローを合理化し、貴重な時間とリソースを節約できます。
• データ整合性の強化: イベントを関連する Change Control および Product Family に自動的にリンクすることで、イベントを正確に記録できます。
• 適用範囲の拡大: この機能強化は、スタンドアロンの Change Control オブジェクトまたはレガシーの Quality Event オブジェクト (Change Control タイプ) のいずれかを使用している QMS ユーザに提供されます。

重要な情報

• Vault の互換性: この機能は、あらゆる RIM およびあらゆる Quality Vault と互換性があります。Quality-RIM Variation Management 機能と同様に、Registrations と QMS に限定されるものではありません。
• 要設定: 機能を有効にするには、特定の設定が必要です。

この機能強化により、自動イベント作成の精度と効率性が向上し、より堅牢で合理化されたアプローチで Quality Event を管理できるようになります。

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

Quality-RIM Connection: Product Data Enhancements

Veeva RIM アプリケーションは、Veeva Quality アプリケーションを含む Vault アプリケーションの製品データのソースです。Quality-RIM Connection には、Product Transfer 機能が含まれており、組織は Quality Vault の製品データを RIM Vault と同期させることができます。RIM Vault の Product Family、Product および Product Variant レコードを接続された Quality Vault にコピーします。Product レコードが Quality Vault に存在しない場合、コネクションにより作成されます。RIM Vault の製品レコードのデータフィールドに変更が加えられた場合、コネクションにより Quality Vault の Product レコードが更新されます。

一部の組織では、Vault 外部の外部システムでマスター製品データを管理し、カスタム統合を構築して外部システムから Vault に直接製品データをプッシュします。この機能により、外部システムにより RIM および Quality Vault に Product レコードが作成され、Quality-RIM Connection を使用して Quality Vault の製品データを RIM Vault の製品データに同期するという特定の状況に対処できます。

具体的には、Product Data Enhancements により、コネクションで RIM からの Product レコードが Quality にすでに存在するかどうかを把握できるようになります。これは、Product レコードの新しい External ID フィールドを使用することで実現されます。外部システム統合によって各 Vault に Product レコードが作成される際、レコードの External ID フィールドに一意の識別子を割り当てる必要があります。コネクションにより、RIM Product レコードの External ID 値が Quality Vault の Product レコード内の External ID 値と一致すると判断された場合、2 つの Product レコードが一致していることを把握して、それらのレコードをリンクします。一致する RIM と Quality の Product レコードの間で対応する Product フィールドのいずれかが異なる場合、コネクションにより Quality Product レコードフィールドが更新され、RIM との同期が維持されます。外部システム統合によって Quality に Product レコードが作成される場合、重複が作成されないように、その External ID を持つレコードがすでに存在していないことを確認する必要があります。

この機能は、25R2 リリースの結果、すべてのお客様の Quality Vaults で自動的に有効になります。詳細については、Quality-RIM Connection の Product Transfer 機能をご覧ください。

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

Quality-Safety Connection

Quality-Safety Connection: Create Safety Inbox Items from Veeva Quality

25R1 リリースでは、検証済みの Vault-to-Vault (V2V) Quality-Safety Connection が導入されました。

このリリースは、Create Safety Inbox Items from Veeva Quality 機能を導入することで、Quality-Safety Connection をさらに強化するものです。この機能により、Safety で発生した Complaints の調査結果を Quality から Safety Intake Team に送り返すことができるため、組織は Safety PQC プロセスを完結させることができます。Quality-Safety プロセスを完結させることは、PQC のフォローアップと報告にとって重要です。

Quality 組織は、潜在的な有害事象を含む PQC を受け取ることもできます。この機能により、Quality では Quality で発生した PQC を Safety に送信できるようになるため、Safety Intake Team が潜在的な有害事象についてトリアージできるようになります。

組織は、エントリアクション、ユーザアクションまたはシステムアクションを使用して、Quality Vault の Complaint レコードに関する情報を送信します。Quality-Safety Connection により、Quality Vault から受信した各 Complaint レコードに対して、Safety Vault 内に 1 つの Inbox Item レコードが自動的に作成されます。Quality Complaint レコードに Safety Case Number が含まれている場合、作成された Inbox Item はフォローアップとみなされるため、元の Safety Case レコードにリンクされます。それ以外の場合、Quality Complaint レコードに Safety Case Number が含まれていない場合、新規 Inbox Item レコードが作成されます。Safety Inbox Item レコードが正常に作成されると、Quality-Safety Connection では Safety Inbox Item の ID を使用して Quality Complaint レコードも更新し、トレーサビリティを実現します。

この機能は、スタンドアロンの Complaint オブジェクトと、Quality Event オブジェクトの Complaint オブジェクトタイプに対応しています。この機能を展開するには、システム管理者による設定が必要です。

詳細については、Quality Complaint レコードから Safety Inbox Item レコードにデータを転送する標準フィールドマッピングを含め、Quality-Safety Connection をご覧ください。

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

RIM と Clinical Operations の接続

RIM-Clinical Operations Connection: Regulatory Tracking for Clinical Trials

臨床試験の初期承認に関する規制追跡は RIM で管理されますが、臨床試験のマイルストーンを管理し、治験活動を開始するために提出日と判定についてのインサイトを必要とするのは Study Start Up チームです。現在、同じフィールドの追跡は RIM と Clinical の 2 つのシステムで行われており、お客様はデータの二重入力と、その結果発生する可能性のあるデータ整合性の問題を回避する方法を必要としています。RIM Vault と Clinical Operations Vault の新しい統合により、Regulatory Objective や Country Decision Detail などのさまざまな RIM オブジェクトから臨床試験の初期承認に関する関連規制追跡情報が RIM-Clinical Operations Connection を介して Clinical マイルストーンに送信されます。

この機能は、米国 IND、カナダ CTA、EU CTR などのグローバル臨床試験の初期承認手順の日付転送に対応しています。

主な利点:

• 二重データ入力を排除: 手作業による労力を削減し、Study Start Up チームの貴重な時間を節約します。
• データの正確性と整合性の向上: 臨床チームが最新かつ最も信頼性の高い規制承認情報に基づいて作業できるようにします。
• 治験の開始を効率化: 重要な日付にタイムリーにアクセスできるようにすることで、臨床試験活動の開始を加速します。
• コラボレーションの強化: 規制チームと臨床運用チーム間のコミュニケーションと連携を強化します。
• 遅延のリスクを軽減: 正確ですぐに利用できる承認情報を使用して、治験のタイムラインを積極的に管理します。

有効化: 統合、フィールド、選択リスト、値、ライフサイクルを有効にするには、RIM と Clinical の両方で設定が必要になります。

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

RIM-Clinical Operations Connection: Update to CrossLink Behavior to Respect Sites

RIM からの CrossLink を Clinical Operations Vaults で処理する方法に大幅な改善が実装され、システム間のデータの精度と一貫性が向上しました。

主な変更点: RIM で作成された CrossLink は、RIM ソース ドキュメントに入力された施設情報をインテリジェントに認識して優先します。施設が Clinical に存在しない場合は、ユーザ例外メッセージが生成され、CrossLink が作成または更新されることはありません。

影響:

• データの整合性の改善: RIM のドキュメントで施設が指定されている場合、Clinical の対応する CrossLink がその特定の施設に正しく関連付けられるようになりました。
• 提出の誤りを防止: 以前は、RIM の施設が Clinical に存在しない場合、CrossLink が治験レベルで誤って提出され、データの不一致が生じる可能性がありました。この問題は解決されました。

この更新により、データ管理が合理化され、RIM および Clinical Operations 間での CrossLink の信頼性が大幅に向上します。

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

Safety と Clinical Operations の接続

Safety-Clinical Operations Connection: Enhanced Error Handling

Safety-Clinical Operations Connection でデータを効率的に処理し、不要なリソースの消費を最小限に抑えるためには、失敗したレコードの処理を最適化することが重要です。以前は、記録を 1 つ失敗するとバッチ全体の失敗につながりました。また、再処理アクションがありませんでした。この 2 つが組み合わさった結果、極端な場合にはリソース負荷につながり、下流システムでデータを取得する際にデータ量が多くなったり、遅延が発生したりするなど、お客様にとって課題となる可能性があります。

この新しい機能により、Safety-Clinical Operations Connection により効率的な処理メカニズムが導入されます。まず、このコネクションでは、各統合ポイントの Last Successful Run Time (LSRT) と Last Run Time (LRT) の記録が保持されるようになり、データ処理の可視性が向上します。また、このコネクションでは失敗を自動的に再処理することもできます。

この機能強化は、Safety-Clinical Operations Connection のすべてのお客様に対して自動的に有効にされ、より高速で効率的、かつリソースを意識したデータ統合が実現します。

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

Safety と EDC の接続

Safety-EDC Connection: Configurable Significance Rules

このリリースでは、管理者は Safety-EDC Connection を介してインポートされた Inbox Items の重要度ルールを設定できます。これにより、Vault で重要および緊急性の高い重要な Inbox Items を識別する方法をカスタマイズおよび管理できるようになります。主な機能強化には以下が含まれます。

• 特定のフィールドおよびオブジェクトに関連付けられたルールを管理するための Significance Criteria オブジェクトの導入。
• ルール式の作成を簡素化する Significance Criteria Builder。
• ユーザが Inbox Item の重要度ステータスに影響を与えたルールを把握する上で役立つ、Inbox Items 内の Significance Result オブジェクトの導入。
• 以下を含む、新しい式関数に対応。
  • VS_CHANGED: 新しい Inbox Items および既存の Cases 間の変更を検出します。
  • VS_NEW: 既存の Cases と比較して、受信した Inbox Items 内の新しいレコードを特定します。

詳細については、Safety-EDC Connection によって生成される Inbox Items の configuring Significance Criteriaをご覧ください。

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

Safety-EDC Connection: Enhancements

このリリースでは、Veeva Safety により Safety-EDC Connection に以下の改善を導入しました。

• ラベルの更新: Inbox Item および Case Version オブジェクトの CDMS Subject Information フィールドが、用語との整合性を高めるために EDC Subject Information というラベルに変更されました。
• 小数点切り捨て処理: 現在、Safety データモデルの小数点精度を超える EDC 数値フィールドは切り捨てられて表示されず、Vault により警告として User Exception Item が生成されます。これまで、この問題によりレコードを保存できませんでした。
• 重複するグローバル ID の管理: Vault では、Case Product Dosages または Event Product Assessments における重複するグローバル ID を無視します。Vault では、特定の被験者に関する Case Product Dosages または Event Product Assessments の重複が原因で障害が発生した場合、ユーザに警告として User Exception Item を生成して知らせます。

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

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

Safety-EDC Connection: Safety Case Follow-Ups Honor Safety Decisions

Safety-EDC Connection では、Vault 間の Safety に関する決定のシームレスな通信とトレーサビリティに対応できるようになりました。これにより、Safety で開始された決定が EDC と共有されるだけでなく、下流で発生する関連する更新についても積極的に追跡されるようになります。

ユーザが Add Relevant Subject Information アクションを実行して被験者関連の情報を選択すると、Vault では正式な Safety の決定を生成します。この決定は自動的に EDC Vault に送信され、対応する被験者のデータに関連付けられます。

Vault から Safety の決定が EDC に送信されると、Vault では関連する EDC Form Safety Case の情報に対するその後の変更や更新を継続的に監視します。Safety の決定を受け取った後にユーザが EDC 内の関連データを変更した場合、Vault では Safety Vault にフォローアップを送り返します。これにより、Safety チームにあらゆる進展が速やかに通知され、継続的な症例評価と規制遵守に対応できます。

Safety Vault 内の Case に個別の Cases に分割された複数のイベントが含まれることも、複数の Cases が 1 つの Case にマージされることもあります。このリリースでは、EDC の臨床データと施設のリンクに関する決定は変更されませんが、Safety 側で行われた追加、削除、分割またはマージに関する決定は、Vault が EDC から次の更新を収集する際に優先されます。これには、Safety 側で追加された併用薬の保護が含まれ、以前のリリースでは EDC の施設によってリンクされておらず、コネクションによって無視されていた関連する Concomitant Medication フォームに変更が加えられた場合、Case が必ずフォローアップされます。

この強化されたクローズドループのワークフローにより、Vault 間のデータの一貫性が強化され、意思決定の追跡が改善され、Safety 担当者が被験者の Cases を管理する際に常に最新の情報に基づいて作業できるようになります。

この機能をテストする際は、アドホックフォローアップをトリガーする前に、Safety の決定が EDC に反映されるまで 10 分間お待ちください。

詳細については、Safety-EDC Connection で Safety の決定を尊重する仕組みをご覧ください。

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

Study Training-Clinical Operations Connection

Study Training-Clinical Operations Connection: Multi-Study Document Enhancement

この機能により、Study Training で複数治験ドキュメント (複数の Study で使用されるドキュメント) の Training Requirements を自動作成する方法が強化されます。現在、Vault がコネクションを介して eTMF から Study Training に複数治験ドキュメントを転送すると、Study Training では複数の Study Training マトリックス間で共有される 1 つの Training Requirement が作成されます。その結果、セキュリティが不完全になります。この機能強化により、ドキュメントが複数の治験で再利用される場合、Study Training では各 Study に固有の Training Requirement が作成されます。

この機能をサポートするには、“Populate Study from Curriculum” エントリアクションを、このアクションが設定されているすべての Training Requirement オブジェクトライフサイクル状態、その中でも特に Ready for Use 状態から、削除する必要があります。このアクションが実行されると、Curriculum レコードの Study 値が関連する Training Requirement レコードにコピーされるため、トレーニングマトリックスの公開中にジョブが失敗する可能性が高くなります。

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

Study Training-Clinical Operations Connection: Support for Specialized Responsibilities

25R2 では、Veeva Clinical Operations で、既存の標準化された Responsibilities のリストに Specialized Responsibilities を追加する機能が導入されています。この機能強化により、ユーザがより詳細な Responsibilities を作成できるようになることで、Study Training における責任ベースのトレーニングが強化されるため、施設スタッフの過剰トレーニングを防ぐことができます。

トレーニング管理者は、専門的な Responsibilities が標準化された責任と同じように動作することを期待できます。コネクションにより、それらは Clinical Operations から転送され、Study Training で Learner Roles として扱われます。

この機能により、該当する Integration Points に対する Active Query Object Rule の更新が導入され、さらに Clinical Responsibilities および Study Person-Responsibilities に関する新しいフィールドが導入され、これらのレコードを Study Training に送信する必要があるかどうかを判断できます。

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

Clinical Operations

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

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

• Clinical Operations-EDC Connection: Final CRFs
• Clinical Operations-EDC Connection: Automatic Procedure Definitions Alignment
• Clinical Operations-EDC Connection: CTMS Visit Definition to Visit Group Relationship
• RIM-Clinical Operations Connection: Regulatory Tracking for Clinical Trials
• RIM-Clinical Operations Connection: Update to CrossLink Behavior to Respect Sites
• Safety-Clinical Operations Connection: Enhanced Error Handling
• Study Training-Clinical Operations Connection: Multi-Study Document Enhancement
• Study Training-Clinical Operations Connection: Support for Specialized Responsibilities

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

Study Responsibilities

施設スタッフの効果的なトレーニングは、その関連性にかかっています。一般的なトレーニングコンテンツによくある問題として、プロトコルにおける各自の職務に直接関連しないトレーニングが施設スタッフに割り当てられることが挙げられます。これは不要なトレーニングの負担や学習効果の低下といった非効率性につながり、多様な試験要件の遵守を困難にします。

このリリースでは、施設スタッフの責任ベースのトレーニングをサポートするため、Study Responsibilities を作成および管理できるようになりました。この柔軟性の高い機能により、試験チームはプロトコルに該当する責任を正確に選択することができ、その結果、試験チームが要求する責任のみがトレーニング対象として選択されます。

Specialized Responsibilities

臨床試験に携わる施設スタッフに包括的かつカスタマイズされたトレーニングを確実に提供するために、トレーニングの課題がスタッフの特定の職務を正確に反映していることが不可欠です。24R2 リリースで導入された Study Person Responsibilities 機能により、Study Training における責任ベースのトレーニングを円滑に実施するために標準化された責任のリストが提供されました。この標準リストは Veeva によって管理されており、業界のベストプラクティスを示しています。

Specialized Responsibilities により、施設スタッフに対する治験特有のトレーニングを柔軟に管理できます。お客様は、Veeva が管理する標準的な責任に加えて、限られた数の追加の専門的な責任を定義および管理できるようになりました。

専門的な責任を含められるようにすることで、組織は施設スタッフが必要なタスクに関するトレーニングをきちんと受けられるようにして、不必要な過剰トレーニングを最小限に抑え、最終的に臨床試験業務の効率と有効性を向上させることができます。

Enhanced Study Person Responsibility Selection Dialog

Study Personnel の責任選択ダイアログが更新され、Study Responsibilities リストに更新されました。これには Study Responsibilities が記載され、Standard Responsibility の下に Specialized Responsibilities が見やすくグループ化されます。

Study Responsibilities とは、Study に割り当てられる責任です。

Study Document Audit Trail Export

この機能により、ユーザは Study のライフサイクルでのユーザアクションを通じて Study のドキュメントの完全な監査証跡をエクスポートできます。新しいシステムアクション、Export Full Study Audit Trail では、最初に開始者にオプションの日付範囲の入力を求め、次に統合された CSV ファイルを生成します。システムではデフォルトで Start Date を今日から 30 日前に設定します。日付範囲が選択されていない場合は、完全な Study ドキュメント監査証跡がエクスポートされます。

削除された Study ドキュメントは、ドキュメント監査証跡のエクスポートに含まれています。CSV ファイルが生成されると、システム通知とメールが送信されます。

Content Defaulting Refactor

この機能により、より正確にドキュメントの Content (blinding__v) フィールドをデフォルト設定するための新しい要素が導入され、TMF で盲検化を管理する際のエンドユーザの労力が軽減されます。新しい機能を活用するには、新しいアプリケーション設定、Enable Enhanced Blinding Defaulting を有効にする必要があります。

コンテンツのデフォルト設定では、Study が Masking (masking__v) Study フィールドを通じて盲検化されているかどうかが考慮されるようになりました。Open Label が Masking フィールドに入力されている Studies では、デフォルトですべてのドキュメントが Blinded に設定されます。一方、Masking フィールドに Single-blind または Double-blind の値がある Studies では、Masking に基づいてドキュメントの Content フィールドが自動的にデフォルト設定されることはありません。

Study でマスキングが追跡されない場合、または Masking フィールドが Single または Double-blind に設定されている場合は、ドキュメントタイプレベルで定義できる新しい Document Type Group、Allow Unblinded (unblinded__v) が参照されます。盲検解除済みコンテンツを含む可能性のあるドキュメントの場合、Allow Unblinded Document Type Group を適用することで、ドキュメントをアップロードするユーザが盲検解除済みコンテンツをアップロード可能な場合に、ドキュメントの Content フィールドがデフォルトで Unblinded に設定されるようにすることができます。ドキュメントタイプに Allow Unblinded Document Type Group が適用されていない場合、アップロード者の権限に関係なく、ドキュメントはデフォルトで Blinded コンテンツに設定されます。

ソースドキュメントに盲検値がある場合、ドキュメントが API 経由で、または Vault Connection を使用して作成された際は、この新しいデフォルト設定機能によって Content ドキュメントフィールドが上書きされることはありません。Content フィールドが空白の場合、システムでは新しいデフォルト設定動作に基づいてデフォルト設定します。

Prevent Re-Defaulting Content Field on Reclassification

このリリースでは、再分類中にコンテンツフィールドを更新する仕組みが更新されています。これにより、ドキュメントが再分類されたり、Study、Study Country、Study Site などのフィールドが変更されたりしても、以前のように Content フィールドが自動的に更新されることはなくなります。再分類中のコンテンツ更新に対するこの変更は、リリース時に自動的にオンになります。以前の動作を希望するお客様は、この機能をオフにするようにリクエストできます。

Selective Ad Hoc Events

この機能により、Ad Hoc Events に新しい機能が導入され、開始者が特定のイベントに該当する Study Countries と Study Sites を選択できるようになるため、選択したレコードに対してのみ Milestones と Expected Documents が作成されます。さらに、各 Ad Hoc Event に Version Name を指定するオプションが提供されるため、結果として得られるマイルストーンを Version Name で識別できます。

Ad Hoc Event を開始すると、ユーザは Story Event を選択し、オプションで Version Name を指定できます。続行すると、Story Event に下位レベルで Template Milestone Sets が含まれている場合、新しいモーダルが表示され、該当する Study Countries や Study Sites を選択できるようになります。選択内容を確認して確定すると、システムにより選択内容に基づいて Milestones と Expected Documents が生成され、インスタンス化されたすべての Milestones に Version Name を加えて名前が付けられます。

この機能を活用するには、新しいアプリケーション設定、Enable Selective Ad Hoc Events を有効にする必要があります。

Alphabetize Story Events

Ad Hoc Event が開始されると、システムでは Story Events のリストをアルファベット順に並べ替えられるようになりました。この機能は、リリース当日の夜にすべての Clinical Operations Vault に自動的に適用されます。

Subartifact Support for Create Related Document from Template System Action

Create Related Document from Template システムアクションが、Clinical Subarifacts に対応するようになりました。管理者はオプションでシステムアクションに Subartifact を追加することができ、システムによりドキュメントが生成される際に Subartifact ドキュメントフィールドに値が入力されます。選択済みの Document Type にマッピングされた Subartifacts のみが選択可能になります。

この機能を活用するには、Enable Subartifacts アプリケーション設定を有効にする必要があります。

Create Related Document from Template システムアクションは、Monitoring Event Confirmation Letters、Follow-up Letters、Payment Letters などを生成するために使用されます。

Generate Document from Formatted Output

Clinical Operations は、すべてのオブジェクトライフサイクルでエントリアクションまたはユーザアクションとして使用できる新しいレコードアクション Generate Document from Formatted Output に対応しています。このアクションにより、指定された Formatted Output Template とドキュメント Classification に基づいてライブラリドキュメントが生成されます。Site Survey または Outreach Target Survey オブジェクトのライフサイクルで設定されている場合は、追加の設定である Send Copy to Survey Respondent が含まれます。これは、Completed Survey Notification および Electronic CDA 機能で、生成されたドキュメントのコピーを調査回答者に送信するために使用されます。

このアクションを複数回実行した場合、以前に作成されたドキュメントのバージョンアップには対応しません。アクションを実行すると、毎回新しいドキュメントが作成されます。

Default Contact Information for Sync PI

PI フィールドを治験担当者と同期する機能により、Study Person レコードの Primary Contact Information フィールドが自動的に入力されるようになり、該当する場合は Pre-default on non-required field when only one reference record is available 設定に従います。以前は、設定が有効になっていて、単一の Contact Information レコードが存在する場合でも、この自動化では Primary Contact Information を入力できず、システムの動作に一貫性がなくなり、ユーザによる手動入力が必要になりました。この機能強化により、Study Person レコードが手動で作成されたか、PI の同期機能を使用して作成されたかに関係なく、「事前デフォルト」設定が均一に適用されるため、ユーザの労力が軽減され、一貫したデータ入力が保証されるようになります。

USN Sign Up Enhancements

このリリースでは、USN サインアッププロセスに新しい必須フィールドが追加されました。First Name、Last Name、Email の各フィールドは、すべての USN サインアップで必須になりました。Department フィールドは、病院および大学病院の場合は必須です。この情報を収集することで、Veeva Site Support チームは、情報に基づいた適切な意思決定を行い、クエリのある施設に効率的に連絡し、SiteVault サインアッププロセスとの連携を改善できます。

さらに、施設は USN 申請のステータスに関する自動メール通知を受信できるようになります。申請者は、USN 申請が正常に作成されたとき、承認されたとき、および拒否されたときにメール通知を受け取ります。この機能は自動的にオンになります。

この機能は、Study Start Up で標準の質問を使用して実行可能性調査を実施しているとき、または Site Connect で Site Addresses を作成するときにのみ、USN サインアップに使用されます。

Study Migration Status Bulk Update API

Vault の Migration Mode が大幅に改善され、大規模なデータ移行プロセスが合理化されました。これまで、管理者は Vault UI を使用して、個々の Study ごとに Migration Mode の設定を手動で調整する必要がありましたが、これは特に大規模な移行プロジェクトにおいて時間のかかる作業でした。今回の更新により、管理者は単一の API 呼び出しを使用して、複数の Studies の Migration Mode 設定を一度に効率的に管理できるようになりました。この一括更新機能により、多くの場合に時間枠によって制限される、治験を移行モードに設定したり、移行モードから解除したりするのにかかる時間が大幅に短縮され、データ移行がより高速かつ効率的になります。

Available as Study Site Field Added to Organization

この機能により、すべての Clinical Operations Vault の Organization オブジェクトに新しい Available as Study Site フィールドが導入されます。有効にすると、このフィールドが TRUE に設定されている Organizations のみが Study Sites として選択できるようになり、Global Directory レコードが適切に使用されるようになります。

OpenData Clinical (ODC) が有効になっていない限り、このフィールドは無効としてプロビジョニングされ、有効になっている場合は有効としてプロビジョニングされます。

この機能強化により、ユーザは親 Organizations と、実際の Study Sites として機能する特定の部門または場所を明確に区別できるようになります。Available as Study Site 制御は一般に利用可能ですが、ODC レコードでは必須のコンポーネントです。

Enable Child Object Security in Clinical Operations

Veeva Vault Platform に Child Object Security が導入されました。これは、親レコードに対するユーザのアクセス権に基づいて子オブジェクトレコードへのアクセスを有効にする、シンプルな新しいオプションです。この機能は、Clinical Operations の以下の親子関係に使用できます。

• budget__v に対する budget_item__v
• edl__v に対する edl_item__v
• milestone__v に対する milestone_package_document__v
• monitoring_event__ctms に対する monitored_informed_consent_form__ctms
• monitoring_event__ctms に対する monitored_metrics__ctms
• monitoring_event__ctms に対する monitored_sdr_item__v
• monitoring_event__ctms に対する monitored_subject__ctms
• monitoring_event__ctms に対する monitored_subject_visit__ctms
• monitoring_event__ctms に対する monitoring_visti_participant__ctms
• visit_group_definition__v に対する repeat_instance_identifier__v
• study_arm__v に対する study_country_subject_group__v
• study_arm__v に対する subject_group_milestone_schedule__v
• study_risk__v に対する study_risk_mitigation__v
• study_risk__v に対する study_risk_critical_data__v
• study_risk__v に対する study_risk_critical_process__v
• study_country_subject_group__v に対する study_site_subject_group__v
• subject__clin に対する subject_informed_consent_form__v

詳細については、Child Object Security をご覧ください。

CTMS

CTMS Transfer: Oversight Issues from Sponsor to CRO

完全に外部委託された治験では、治験依頼者は CTMS Transfer を介して受託臨床試験実施機関 (CRO) から毎日直接治験データを受け取ることができるため、独自のシステムで試験管理を監視できます。この監視の重要な部分として、治験依頼者が転送された CTMS データ (Monitoring Events、Milestones および Issue レコードなど) に対する Oversight Issues を提起します。迅速な是正措置を講じるには、これらの問題を CRO にタイムリーに伝えることが重要です。現在、こういったコミュニケーションは、通常、メール、会議、Veeva CTMS や他のトラッカーからの個別の情報共有などの非効率的な方法に依存しており、遅延や誤解が生じる可能性があります。

このデータ交換を加速し簡素化するために、CTMS Transfer は双方向に拡張され、Oversight Issues の転送に対応できるようになりました。既存の治験転送契約を活用して、Sponsor Veeva CTMS (信頼できる情報源) で追跡された Oversight Issues が、CRO Veeva CTMS に直接転送されるようになりました。CRO がソース データを修正するか、監視問題に対処するための措置を講じると、治験依頼者は Veeva CTMS で Oversight Issue を終了できます。

この機能強化により、CRO に監視問題を通知して解決を促進するための合理的かつ自動化された方法が提供され、問題管理の速度と精度が向上します。

Protocol Deviation Categories & Subcategory Transfer Enhancements

製薬業界および臨床研究業界では、プロトコル逸脱の正確な分類が非常に重要です。これにより、一貫したデータ収集が保証され、傾向分析が容易になり、効果的なリスク管理が可能になり、最終的には患者の安全とデータの整合性に貢献します。ただし、プロトコル逸脱の Categories と Subcategories を管理する現在のアプローチでは、CTMS Transfer に課題が生じます。標準が細分化されていないため、これらのカテゴリまたはサブカテゴリは特定の組織のニーズを満たすために高度にカスタマイズされることが多く、データ転送中のマッピングプロセスが非常に複雑になります。ソース Veeva CTMS でのカスタマイズを通じて確立された固有の Category > Subcategory 関係が転送で簡単に維持できないために、こういった複雑さが生じます。その結果、これらのカスタムエントリをターゲット CTMS にマッピングすると、時間がかかり、リソースを大量に消費し、エラーが発生しやすくなり、重要な治験データのシームレスな共有が妨げられる可能性があります。

これらの課題に直接対処し、プロトコル逸脱の転送を効率化するために、25R2 リリースでは以下の機能強化が導入されています。

• 新たに Other サブカテゴリを標準として追加します。これは、ターゲットシステムに直接対応するものがない、ソース Veeva CTMS から生成されたカスタムサブカテゴリ値をマッピングするための指定オプションとなります。
• 対象の問題レコードに、Source Category と Source Subcategory という 2 つの新しいテキストフィールドをプロビジョニングします。転送時に、これらのフィールドには、ソースのプロトコル逸脱から Category と Subcategory の値の逐語的なラベルが自動的に入力されます。これにより、特にカスタム値が関係する場合に、逸脱の原因に関する貴重なコンテキストを入手できます。

カスタムのマッピングされていない Categories または Subcategories を活用する際の問題は、今後も転送されず、エラーが生成されるため、カスタム設定の正確なマッピングの重要性が強調されています。

これらの機能強化により、特に高度にカスタマイズされたカテゴリおよびサブカテゴリ構造を持つ環境でのプロトコル逸脱に関する CTMS 転送プロセスが大幅に簡素化され、最終的にデータ転送がより効率的かつ正確になります。

Last Subject Milestones: Earlier Last Subject Screened Population

この機能により、Last Subject Milestones に対する Automated Enrollment Milestone の動作が強化されます。

Study Site の No New Subjects フィールドがオンになっている場合、Vault では特定の基準に基づいて、Last Subject 関連のマイルストーンの Actual Finish Date を自動入力します。スクリーニングと登録の間にギャップがあるプロトコル設計に対応するために、マイルストーンの完了をより詳細に追跡できるようにこれらの基準を更新しました。これにより、Last Subject が Study Site でスクリーニングされると、ユーザは No New Subjects フィールドをオンにして、Last Subject Screened および Last Subject Consented Milestones を更新できます。Last Subject In、Last Subject Randomized および Last Subject Started Treatment Milestones は、以下の追加基準が満たされた場合にのみ入力されます。

マイルストーンタイプ	自動入力値
Last Subject In	Study Site のすべての Subjects に以下のいずれかがある場合の Subject の最新の Enrolled Date。 Screen Failure、Enrolled または Withdrawn の Subject Status Screen Failed Date、Enrolled Date または Withdrawn Date の値
Last Subject Randomized	Study Site のすべての Subjects に以下のいずれかがある場合の Subject の最新の Randomized Date。 Screen Failure、Randomized または Withdrawn の Subject Status Screen Failed Date、Randomized Date または Withdrawn Date の値
Last Subject Started Treatment	Study Site のすべての Subjects に以下のいずれかがある場合の Subject の最新の Started Treatment Date。 Screen Failure、Started Treatment または Withdrawn の Subject Status Screen Failed Date、Started Treatment Date または Withdrawn Date の値

この機能は、Enable Automated Enrollment Milestones が有効になっている Vault では自動的にオンになります。

Last Subject Milestones: Preferred End of Treatment Date

この機能により、Last Subject Treated Milestone の Automated Enrollment Milestones の完了基準が更新されます。以前は、Vault では Site における Subjects の最新の End of Treatment Date または Withdrawn Date を使用して、Last Subject Treated Milestone Actual Finish Date を入力していました。現在、Vault ではどの Subjects にも End of Treatment Date が入力されていない場合にのみ、最新の Withdrawn Date を使用します。それ以外の場合、Vault では最新の End of Treatment Date を使用します。

この機能は、Enable Automated Enrollment Milestones が有効になっている Vault では自動的にオンになります。

Last Subject Milestones: Incomplete Subject Status Dates

この機能により、Subject オブジェクトに新しい Incomplete Subject Status Dates フィールドが追加されます。このフィールドが Subject に対して Yes に設定されている場合、空白の Subject Date フィールドは Automated Enrollment Milestones の動作から除外されます。たとえば、Study Site に 3 人の Subjects がいて、そのうち 2 人の Enrolled Dates が入力され、1 人の Subject ステータスが In Screening で Enrolled Date がない場合、どの条件も満たされていないため、Vault では Last Subject In Milestone が入力されません。ただし、Subject のステータスが In Screening であり、Incomplete Subject Status Dates フィールドが Yes とマークされている場合、Vault では Last Subject In Milestone が自動入力されます。

Incomplete Subject Status Dates フィールドは無効としてプロビジョニングされます。このフィールドが無効な場合、評価されず、Automated Enrollment Milestone の動作に変更はありません。

この新しいフィールドにより、Subject データが不完全な場合に、マイルストーンの完了をより柔軟に管理できるようになります。

Subartifact Support for Create Trip Report System Action

Monitoring Event からの Trip Report ドキュメントの作成に対応する Create Trip Report システムアクションが、Clinical Subartifacts に対応するようになりました。管理者はオプションでシステムアクションに Subartifact を追加することができ、システムにより Trip Report ドキュメントが生成される際に Subartifact ドキュメントフィールドが入力されます。選択済みの Document Classification にマッピングされた Subartifacts のみが選択可能になります。

この機能を活用するには、Enable Subartifacts アプリケーション設定を有効にする必要があります。

Subject Transfer Support for Seeding Subject Visits on Monitoring Events

この機能により、Seed Monitored Enrollment および Proactively Seed Monitored Enrollment アクションが強化されます。これらのアクションは Monitoring Events で使用され、被験者転送シナリオに対応しています。この更新により、Monitoring Event にシーディングされた被験者来院は、Subject の現在の Study Site への来院に限定されます。

Recruitment Planning: Consistency & Error Handling Improvements

Subject Recruitment Planning により、ユーザは時間の経過に伴う被験者募集指標 (スクリーニング、登録、ランダム化) を計画できます。Create Metrics Over Time アクションにより、Study設計に基づいて、該当する Study、Study Country、Study Site および Subject Group についてこれらのレコードが生成されます。

この機能には、Create Metrics Over Time の一貫性とエラー処理に関する以下の機能強化が含まれています。

• 成功または失敗の通知とジョブログの詳細
• 重複した Metrics レコードの処理
• Milestone の日付が Create Metrics Over Time アクションが最初に実行されたときの元の範囲と重複しない場合の計画された値を使用した被験者募集計画の再作成
• Metrics Not In Use および Global Subject Metric Enablement ステータスの優先
• 適切なレベルとタイプの非 Subject Group マイルストーンが見つからない場合の Subject Group マイルストーンのデフォルト使用

Removed Vault Setting: Prevent User Updates to Date-Based Metric Actual Field

24R2 では、Date-Based Studies でユーザが Metrics レコードの Actual フィールドを編集できないようにロックする feature が導入されていました。お客様が調整する時間を確保できるように一時的なオプトアウト設定が組み込まれました。現在、この設定は削除されています。つまり、Study Metric Calculation が Date-Based に設定されているすべての Vault で、ユーザが Metrics レコードの Actual フィールドを編集することはできなくなりました。

CTMS Licensing: Enrollment Metrics Tracking

Study Site License オブジェクトの CTMS ライセンス追跡に、Enrollment Metrics が含まれるようになりました。治験実施施設に、Actual 値が 0 より大きい Monitoring Event、Issue、または Metric レコードが少なくとも 1 つある場合、CTMS ライセンスを消費しているとみなされるようになりました。

管理者は、Vault の About ページでライセンスの消費量を確認できます。消費量がライセンス量を超えると、ユーザーに警告メッセージが表示されます。

Clinical Transfer CDX Enhancements

臨床試験に関与するさまざまなパートナー間で円滑かつ効率的なチームワークを促進するには、異なる Vault 間で重要な情報を正確かつ迅速に移動することが不可欠です。こうした転送の複雑さを理解しているため、接続されているすべての Vault 間での情報共有をより明確かつ統一されたものにするために、Clinical Transfer 機能を継続的に改善しています。

25R2 リリースでは、Clinical Transfers に以下のいくつかの重要な改善が導入されています。

1. CTMS Transfer により、Recurring Milestone Schedules の定期的なマイルストーンスケジュールがトリガーされます。以前は、CTMS Transfer を介して転送されたマイルストーンにより、ターゲット Vault 内の Recurring Milestone Schedules の開始または終了がトリガーされることはありませんでした。この制限は解決されました。Action または Inactivation イベントとして参照されるマイルストーンが CTMS Transfer を介して転送されると、ターゲット Vault 内の対応する Recurring Milestone Schedules が自動的に開始または終了します。この機能強化により、定期的なアクティビティを含む監視計画の実行が効率化され、タイムリーな監視の実行と運用効率の向上が実現します。

2. CTMS Transfer により、新しい Source Milestone Type および Source Monitoring Event Type Fields が入力されます: 転送されたレコードのコンテキストとトレーサビリティを強化するために、ターゲットの Milestone および Monitoring Event レコードに 2 つの新しいテキストフィールドである Source Milestone Type および Source Monitoring Event Type が導入されました。転送時に、これらのフィールドにはソース Vault の Milestone Type および Source Monitoring Event Type の値の正確なラベルが自動的に入力されます。これは、Source Vault 内のカスタムタイプを処理する場合に特に役立ち、これらのレコードの作成元と性質を明確に把握できるようになります。

3. 長時間にわたる Agreement Transfers のタイムアウト: システムパフォーマンスを最適化し、無期限の処理を防止するために、Extracting 状態のまま 24 時間を超える Agreement Transfers は自動的にタイムアウトし、Finished 状態に移行します。これにより、転送プロセスが効果的に管理され、システムリソースが不必要に停滞することがなくなります。

これらの機能強化により、臨床データ転送プロセスはより効率的で透明性が高く、信頼性の高いものとなり、最終的には精度と、臨床試験に関わるすべての関係者間の連携が向上します。

Monitored Study Site Addresses

新しい Monitored Study Site Address オブジェクトを使用して、モニタリングイベント中に訪問した Study Site Addresses を記録できるようになりました。このオブジェクトは、訪問時点での施設住所のスナップショットを取得します。モニターは、その施設の既存の Study Site Addresses から選択することで Monitored Study Site Address レコードを手動で作成します。これにより、モニタリングイベント中に訪問した住所が明確に記録されます。

この機能は設定を通じて使用可能です。この機能を使用するには、Study Site Addresses 機能を使用する必要があります。

Disclosures

Check for Updates & Update Disclosure Data

Disclosure が作成されると、データが特定のフィールドに事前に入力され、保存されます。ただし、データが最初に事前入力された後は、データは更新されません。そのため、ユーザはフォームデータを編集、修正、制御できるようになります。この機能により、ユーザは Disclosure 内のデータを CTMS の新しい情報と並べて比較することができます。そして、ユーザはどの更新を Disclosure に組み込むかを決定し、最新の情報がパブリックレジストリに開示されるようにすることができます。

ClinicalTrials.gov API Two-Way Enhancements

新しい Registration オブジェクトでは、Study とその結果を ClinicalTrials.gov または他のレジストリに登録する必要があるかどうかを追跡します。Disclosure Scope フィールドにより、治験で US Registration や Results Disclosures を自動生成するかどうかを制御します。

ClinicalTrials.gov プロトコル登録システム (PRS) API が強化され、Study の更新を毎晩ポーリングして、Record Status、Study の NCTID および潜在的なコメントなどのデータを取得できるようになりました。これらの値は、報告とフィルタリングのために Registration オブジェクトに保存されます。

Company Website Disclosures Support: Custom Fields & XML

この機能により、Disclosure または Study オブジェクトのカスタムフィールドを US Disclosures の新しいカスタム XML 送信ファイルに含める設定が導入されます。ファイルを生成する新しいユーザアクションが利用できるようになりました。お客様はこのユーザアクションを使用して Clinical Trial Search ウェブサイトを更新できます。

Posting Documents to ClinicalTrials.gov

Clinical Trial を ClinicalTrials.gov に登録して完了したら、ユーザは Clinical Trial Results とともに必要な書類を提出する必要があります。この機能により、Veeva Disclosures のユーザは、これらのドキュメントを Disclosure ワークフローに含めてレビューおよび承認し、新しい Post/Update Documents アクションを使用して ClinicalTrials.gov PRS に自動的に送信できます。

Disclosures: Copy Protocol & US Validation Enhancements

この機能は、Veeva Disclosures のオンボーディングと設定中にアーリーアダプターから寄せられた重要なフィードバックに対応するものです。導入を成功させるには、以下の機能強化が不可欠です。

• 新しい Copy Entire Protocol ユーザアクションでは、プロトコルとそれを構成するすべてのリンクされたオブジェクト (翻訳を含む) がコピーされます。
• 検証エラーファイルに US Registrations の追加検証を追加しました。

Enhancements for Triggering Disclosures

この機能は、Disclosures のオンボーディングと設定中にアーリーアダプターから寄せられた重要なフィードバックに対応するものです。導入を成功させるには、次の機能強化が不可欠です。

• 新しい Subject Screened Milestone 開示ルール: ClinicalTrials.gov の「治験開始日」の定義はさまざまな方法で解釈できるため、顧客のニーズも異なります。より早いトリガーを必要とする顧客に対応するために、新しい開示トリガールールを追加しました。このルールを有効にすると、First Study Subject Screened マイルストーンの Actual Date から 21 日後に期限が切れる Disclosures が生成され、First Subject In マイルストーンの代替として提供されます。
• 新しい開示の Compliance Date (自動計算): 元のコンプライアンス日がわからなくなることへの懸念に対処するため、新しい読み取り専用の Compliance Date フィールドを導入しました。このフィールドは、Disclosure Rules によって Disclosure 生成時に自動的に計算されるもので、ユーザが編集可能な Due Date フィールドとは異なります。
• 新しい Reason Created フィールド: 開示チームが Disclosures の自動作成のコンテキストを理解できるように、新しい Reason Created フィールドを追加しました。このフィールドには、Disclosure の作成を開始したトリガールールの Label が表示されます。
• Disclosure フォームに自動的に事前入力されるフィールドの追加: データ入力の効率を高めるために、Disclosure フォームには次のデータポイントが自動的に事前入力されます。
  • Study Recruitment Status (治験から)
  • Primary Completion Date (マイルストーンから導出)
  • Actual Enrollment (治験メトリクスから導出）
  • EU CT Number
  • NIH Grant Number

Payments

Generate Payment Requests Populates Source

より正確な支払いのトラッキングをサポートするため、標準システムアクションを使用して支払いリクエストを生成するときに、Payment Requests の Payment Source フィールドが自動的に入力されるようになりました。リクエストの生成時に Payment Source が治験依頼者/CRO に設定されるため、一貫性が確保され、手入力が削減されます。Payment Source フィールドがデフォルトで表示されるのは Site Connect のみですが、この値は Payments をご利用のすべてのお客様において入力されます。Source フィールドは、支払いリクエストが施設のインボイスから作成されたか、または治験依頼者/CRO から直接発行されたかを示すことに注意してください。今回の更新により、リクエストの生成時に発行元が明確に指定されるため、支払いワークフローの効率が向上します。

eTMF

Risk-Based Document QC

この機能により、Document Types をリスクレベルにマッピングし、そのリスクレベルに基づいて QC する必要があるドキュメントのルールを設定する機能が導入されます。新しいオブジェクト、Document Type Risk Mapping では、指定された Classification と、オプションで Subartifact の QC Risk Level を追跡します。Classification と Subartifact ごとに、Document Type Risk Mapping を 1 つだけ生成できます。

QC Risk Rule は、各 QC Risk Level に関連付けられたルールを定義する新しいオブジェクトです。これらのレコードにより、QC Type、Pre-Approval または Post-Approval、およびリスクレベルをサンプリングする割合が設定されます。これらのルールは、Study、Country または Organization に基づいて定義することもできます。各 QC Risk Rule に対して Risk Rule Metric がシステムによって生成されます。このレコードでは、QC Risk Rule に対して Number of Docs Requiring QC と Number of Matched Documents を自動的に追跡します。

ドキュメント所有者は、新しい Risk Assessment System Action ステップを含む、更新された QC ワークフロー設定を通じてドキュメントのリスクを評価できます。リスク評価アクションを使用する Classifications に、Primary および Secondary QC Status ドキュメントフィールドを追加する必要があります。このアクションを通じて、システムでは定義された Document Type Risk Mappingsに基づいてドキュメントのリスクレベルを識別します。一致したマッピングに基づいて、システムでは QC Risk Ruleを割り当て、関連付けられた Risk Rule Metric の Number of Matched Documentsを増分し、乱数生成に基づいてドキュメントをサンプリングするかどうかを判断します。生成された数が Percent Sampled より少ない場合、ドキュメントの Primary または Secondary QC Status が QC Required に更新され、システムでは Risk Rule Metric レコードの Number of Documents Requiring QC を増分します。また、システムにより評価の詳細を含む Risk Assessment Memo ドキュメントフィールドが更新されます。

多言語モデル

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

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

Additional Source Text Fields for Transfers

整理され、簡単にナビゲートできる Trial Master File (TMF) を維持することは、臨床試験の成功と規制遵守に不可欠であり、最終的には迅速な承認と円滑な検査につながります。TMF Reference Model バージョン 3 では、「サブ生成物」の概念が導入され、生成物内のドキュメントをさらに定義できるようになります。これにより、同様の文書を同じ「場所」内でファイリングしながらも、区別できるようになります。

この業界標準を基に、Veeva Clinical Operations では 24R2 リリースで Subartifact に対応できるようになりました。これには、専用の Subartifact オブジェクトを搭載した新しい Subartifact ドキュメントフィールドが含まれます。現在、複数の受託臨床試験実施機関 (CRO) と治験依頼者がこの機能を活用し、ソース Veeva システムの Subartifact フィールドをきっちりと管理していることを考えると、TMF Transfer または CTMS Transfer を介してドキュメントがターゲット Veeva システムに転送されるときに、この貴重な情報が失われないようにすることは重要です。このデータの整合性を確保することで、直接的な結果として TMF 検査の準備が改善され、潜在的なコンプライアンスリスクが軽減されます。

次の 25R2 リリースでは、臨床転送機能の強化により、このニーズに直接対応します。これにより、ソースドキュメントに Subartifact フィールドが存在する場合、TMF および CTMS Transfer の両方で、対応するターゲットドキュメントに Source Subartifact フィールドが自動入力されるようになります。このサブ生成物ト情報のシームレスな転送により、ドキュメントの詳細なコンテキストがターゲットシステムで保持され、TMF より完全で正確、かつ検査可能になります。重要なのは、柔軟性を維持するために、Subartifact フィールドが空白であるか、ソース Veeva システムに存在しない場合でも、ドキュメントは正常に転送されることです。

eTMF License Calculation

この機能により、eTMF Study Site ライセンスを計算するための新しい方法が導入されます。システムにより、各 Study Site で TMF Reference Model (バージョン 3.0) にマッピングされたドキュメントの存在に基づいて eTMF ライセンスの消費が決定されるようになりました。Study Site では、以下に記載されているもの (CTMS および SSU ライセンスに関連付けられているもの) を除く、TMF Reference Model 生成物にマッピングされたドキュメントが少なくとも 1 つ含まれている場合、eTMF ライセンスを消費します。

CTMS 生成物:

• Pre Trial Monitoring Report
• Trial Initiation Monitoring Report
• Monitoring Visit Report
• Final Trial Close Out Monitoring Report

SSU 生成物:

• Feasibility Documentation
• Data Privacy Agreement
• Confidentiality Agreement

eTMF ライセンスの消費を追跡するために、新しい eTMF フィールドが Study Site License オブジェクトに追加され、関連するドキュメントが Study Site に存在する場合は Yes とマークされます。非同期ジョブにより、ドキュメントの作成、更新、削除などのドキュメントの変更があった Study Sites に応じて、eTMF フィールドが更新されます。リリースされ次第、システムではすべての Study Sites で初期 eTMF ライセンス計算を実行し、結果に応じて eTMF フィールドが更新されます。

管理者は、Vault の About ページでライセンスの消費量を確認できます。この変更により、他の Clinical Operation アプリケーションにおけるライセンス消費の追跡方法との一貫性が確保され、より透明性が高く、統一されたアプローチでライセンスを管理できます。

Site Connect

Support VeevaID Email Change

施設ユーザの主なメールアドレスが変更されることは一般的であり、合併やブランド変更などの組織的な変更、または名前の変更などの個人的な理由により変更されることがよくあります。このリリースより前は、VeevaID では一度ユーザが主なメールを設定すると、それ以降の更新に対応できませんでした。その結果、新しい VeevaID を作成する必要があり、ユーザは Site Connect の既存の治験アクセス権をすべて失い、治験依頼者は関連する各治験へのアクセス権を手動で再割り当てする必要があります。

このリリースでは、VeevaID now supports でユーザの主なメールアドレスの更新に対応できるようになりました。この Site Connect 機能により、Site Connect ではこれらの VeevaID メールの変更にシームレスに対応できるようになります。現在、施設ユーザが VeevaID の主なメールアドレスを更新すると、Site Connect では Veeva Clinical Operations Platform 内の対応するレコードを更新して、メールアドレスの変更を自動的に反映します。この機能強化により、施設ユーザは中断されることなく割り当てられた治験にアクセスできるようになり、治験依頼者がユーザアクセスを手動で再設定する必要はなくなります。

このプロセスを自動化することで、管理上の負担が軽減され、アクセスが中断される可能性が最小限に抑えられ、施設ユーザと治験依頼者の両方でよりスムーズなエクスペリエンスを実現します。

New Standard Study Team Roles & Application Roles

この機能により、以下の施設向けロールに対して新しい標準の Study Team Roles と Application Roles が導入されます。

• Budgets & Contracts (budgets_contracts__v)
• Data Coordinator (data_coordinator__v)
• Other Non-Investigator (other__v)
• Pharmacist (pharmacist__v)
• Regulatory Coordinator (regulatory_coordinator__v)
• Research Nurse (research_nurse__v)

すべての Vault において、これらのレコードはデフォルトで Inactive になります。

Safety Distribution Responsibility

この機能により、Site Connect で Safety Distribution Recipients をより柔軟に選択できるようになります。リリース後、Study Person は、それぞれ Assess Safety Notifications (Primary) または Assess Safety Notifications (Secondary) Study Person Responsibility がある場合に、プライマリまたはセカンダリの安全性受信者であると判断されます。

これら 2 つの Study Person Responsibilities は、Study Team Role があり、Safety Distribution Recipient が Primary または Secondary に設定されている Study Persons に対して自動的に作成されます。これにより、リリース後に動作がすぐに変化することはありません。

リリース当日の夜には、治験の Connected Study Type フィールドに Safety Distribution が含まれている場合、Study Team Role Safety Recipient フィールドが Primary または Secondary に設定されているすべての Study Persons に対して、それぞれの Study Person Responsibility が作成されます。これにより、既存の Study Persons 全員に引き続き適切な Safety Recipient が割り当てられることになります。

この変更に備えて、Responsibility および Study Person Responsibility オブジェクトの権限を設定し、Study Person ページレイアウトで Study Person Responsibility セクションを設定することを管理者にお勧めします。これらのオブジェクトはすでに利用可能なため、25R2 リリースの前にこの設定を実行できます。これにより、ユーザは Safety Recipients の Study Person Responsibilities を効果的に管理できるようになります。

Document Exchange Responsibility

この機能により、Document Exchange 通知を受信するユーザをより柔軟に選択できるようになります。リリース後、Study Person は、Maintain Essential Documents タイプ Study Person Responsibility がある場合にのみ、Document Exchange 通知を受け取ります。

この Study Person Responsibility は、Study Team Role があり、Document Exchange Recipient がオンになっている Study Person に対して自動的に作成されます。Study Team Role のこの新しいフィールドは、標準の Principal Investigator、Sub-Investigator、Clinical Research Coordinator および Regulatory Coordinator Study Team Roles に対して自動的にオンになります。これにより、リリース後に動作がすぐに変化することはありません。

リリース当日の夜には、治験の Connected Study Type フィールドに Document Exchange が含まれている場合、Site Connect ユーザであるすべての Study Persons に対して、この Study Person Responsibility が作成されます。これにより、既存の Study Person 全員が引き続き Document Exchange 通知を受け取ることになります。

Respect Start & End Dates on Responsibilities

この機能により、Site Connect のさまざまな機能へのアクセスと通知が、Study Person Responsibilities で定義された Start Date および End Date によって厳密に制御されるようになります。つまり、ユーザは現在の日付が、割り当てられた Study Person Responsibility の Start Date および End Date の範囲内にある場合にのみ、機能にアクセスして、通知を受け取ることができます。

この機能強化の影響を受ける機能には、Safety Distribution (プライマリおよびセカンダリの安全性配布アクセスと通知の両方)、Document Exchange (通知のみ)、Unblinded Documents (非盲検コンテンツアクセスと通知) および Payment Information (支払い情報へのアクセス) が含まれます。

この変更に備えて、Responsibility および Study Person Responsibility オブジェクトの権限を設定し、Study Person ページレイアウトで Study Person Responsibility セクションを設定することを管理者にお勧めします。これらのオブジェクトはすでに利用可能なため、25R2 リリースの前にこの設定を実行できます。これにより、ユーザは Study Person Responsibility の Start Date と End Date を効果的に管理できるようになります。

Revoke Site Connect Access

この更新により、施設ユーザの Site Connect アクセスも取り消す機能が追加され、Revoke Access from Study Persons with End Date ジョブが強化されました。以前は、このジョブは内部ユーザのアクセスのみを取り消していました。ただし、Site Connect の顧客は、Study Persons を使用して施設スタッフのユーザアクセスも管理します。一貫性を確保し、Site Connect アクセスを取り消す手動の手順をなくすために、このリリースでは既存のジョブが強化されています。

これで、日次ジョブが実行されると、End Date がジョブの実行日以前である Study Persons の Site Connect User フィールドのチェックが外されます。この機能は、Revoke Access from Study Persons with End Date ジョブを有効にした Site Connect 顧客の場合、自動的にオンになります。

この機能の利用に備えるために、Revoke Access from Study Persons with End Date を有効にするようにお客様にお勧めします。この機能の有効性は、終了日が正しく使用されているかに依存するため、Study Persons の End Date を正確に設定するためのプロセスを確立することも重要です。

Subartifact Support for Site Packages

この機能により、ドキュメント交換内で Subartifact に対応できるようになります。新しい Subartifact フィールドが Site Package Document レコード内で利用可能になり、Site Connect を利用するお客様は以前のリリースで導入された新しいドキュメントファイリング構造を活用できるようになります。

Enable Subartifacts フラグが有効な場合、Subartifact フィールドは Site Package Documents に対して必須になり、パッケージを通じて開始されたアドホックドキュメントリクエストでは、Clinical Operations ユーザが Subartifact を指定しなければならなくなります。施設ユーザにとってより明確になるように、システムにはアドホックリクエストのコメントに、選択された Subartifact 名が自動的に含まれます。

さらに、Subartifact フィールドがドキュメント交換グリッドに表示され、各ドキュメントの特定の Subartifact に関するインサイトが提供されます。Subartifact 情報も Distribution Tasks に保存され、一貫性のあるシームレスなドキュメント交換エクスペリエンスが保証されます。

施設ユーザがドキュメントの Subartifact 値を設定することはありません。ドキュメントリクエストの場合、関連付けられている Distribution Task の値に基づいて、Site によって提供されたドキュメントの Subartifact がシステムにより設定されます。ドキュメントが施設によってアドホックにアップロードされる場合、Subartifact は分類名に一致するものに設定されます。

Subartifacts を有効にしていないお客様の場合、施設パッケージを介したドキュメント交換グリッドとアドホックドキュメントリクエストは変更されず、Subartifact フィールドは表示されません。

Sync Auto-Requests with Automatic Document Exchange

この機能により、Expected Documents からの Automated Document Exchange が強化され、動的なプロセスを通じて効率が向上します。システムでは、# Expected の数と All Document Count を比較して、ドキュメントリクエストを動的に管理できるようになりました。

• 自動リクエスト: Auto-request from site としてフラグが付けられた必須の Expected Documents の # Expected フィールドの値が All Document Count フィールドの値を超えると、Provide Original 配布タスクが作成されます。

• 自動キャンセル: # Expected フィールド値が減少するか、手動アップロードされた新しいドキュメントが Expected Document と一致して、All Document Count フィールド値が増加すると、オープン配布タスクはキャンセルされます。このキャンセルは、このリリース以降に作成された配布タスクにのみ適用されます。

この機能強化の一環として、すべての配布タスクに Expected Document フィールドが追加されました。この新しいフィールドにより、システムでは対応する予測ドキュメントからの参照 (人物、組織またはサブ生成物) が存在する場合、施設から返されたドキュメントにその参照を自動的に適用できるようになります。

Site Connect Vault Clinical Document Updates

Site Connect を使用すると、治験依頼者と施設間でドキュメントをシームレスに交換できます。この機能により、交換できるドキュメントの種類が拡大しました。

以下の Document Types を施設から受け取ることができるようになりました。

• Site Training Material
• IP Shipment Documentation

以下の Document Types を施設に送信できるようになりました。

• Regulatory Notification of Trial Termination
• IP Shipment Documentation

Site Connect Hardening

このリリースには、Site Connect をより適切にサポートするためのいくつかの機能強化が含まれています。

• Provide Original タスクへの応答として施設から返されたドキュメントは、常にリクエストされた Classification および Sub-Artifact にファイリングされます。
• Site Connect では、Distribution Tasks の最初の完了者と完了日を管理します。
• Site Connect では、コンテンツが変更されていない場合、In Progress から Approved に移動されたドキュメントへのアクセスを引き続き許可します。
• ジョブ順序を現在に更新し、ジョブの重複を回避して効率的な実行時間を実現します。
• 改善により、数千人の Study Persons で Site Connect User を有効にする必要がある場合でも、ユーザは一括で Site Connect Users を有効にできるようになりました。
• 関連するSite Connect User が無効な場合、Distribution Tasks は失敗します。
• 多数の安全性配布物を含む Gap Packs がメール形式に対応していることを確認します。

Study Startup

Electronic CDA

Study Startup では、Site Feasibility Surveys 内で電子 CDA プロセスに対応できるようになりました。Site Surveys に、受信者が eCDA に同意するための検証をトリガーする Response Flag、Electronic Confidentiality Confirmed を含められるようになりました。有効なメールを持ち、Respondent Type フィールドが Confidentiality Recipient に設定された Study Person レコードとして CDA 受信者を追跡する必要があります。CDA 受信者が Site Survey を完了しようとすると、新しいダイアログボックスで回答者は Full Name と、Study Person レコードに関連付けられたメールに送信された一意の検証コードを入力するように求められます。回答者が正しくコードを入力すると、調査を確認して完了することができます。システムにより、検証ダイアログボックスから Full Name が完了した調査レコードの Confidentiality Respondent フィールドにコピーされます。

CDA ドキュメントは、調査が完了すると Formatted Output Template から生成され、TMF 内にファイリングされます。CDA 受信者には、ダウンロード可能な PDF 版の CDA が含まれる新しい通知テンプレート eCDA Confirmed を使用して通知が送信されます。ダウンロード可能な CDA へのリンクの期限は 60 日以内です。

Completed Survey Notification

Veeva Study Startup では、アンケート回答者に完了したアンケートのコピーを送信し、その完了したアンケートを TMF にファイリングする機能に対応できるようになりました。Generate Document from Formatted Output アクションが Site Survey または Outreach Target Survey オブジェクトのライフサイクルで設定されている場合、システムでは新しい Site Survey または Outreach Target Survey Response Formatted Output Templates に基づいて調査回答ドキュメントを生成し、指定された Document Classification に回答ドキュメントをファイリングし、生成されたドキュメントを Site Survey および Outreach Target Survey オブジェクトの新しい Response Document フィールドにリンクします。

Site Survey および Outreach Target Survey オブジェクトの新しい Person Responsible Email フィールドでは、Survey を送信した調査回答者のメールを自動的に追跡します。この調査回答者に回答ドキュメントのコピーを送信するには、Generate Document from Formatted Output アクションの Send Copy to Survey Respondent チェックボックスをオンにする必要があります。調査回答者に生成された回答ドキュメントへのダウンロードリンクを送信するために、Site Survey および Outreach Target Survey オブジェクトで新しい Notification Templates、Download Survey Response を使用できます。完了したアンケートの PDF コピーへのリンクの期限は 60 日以内です。

Update Survey USN Banner

Veeva Study Startup では、Veeva Standard Questions を使用した Feasibility Surveys の既存の USN Banner が機能強化されました。色、アイコン、アクセシビリティ、リンクではなくボタンの追加など、いくつかのコンポーネントを更新しました。ユーザは、Enter USN ボタンで USN を選択し、Update USN ボタンで USN を更新できるようになりました。

Study-Level Expected Documents in Multi-Country & Site Submission

Multi-Country and Site Submission 機能が強化され、Select Specific Country and Site フィールドが True に設定された Country レベル Submission Application Milestones の Study レベル Expected Document のインスタンス化に対応できるようになりました。この機能強化は自動的に利用可能になりますが、使用するにはテンプレートの設定が必要です。つまり、Study レベル Template Expected Document には、Country レベルのマイルストーンタイプが関連付けられている必要があります。

Study Training

Training Matrix Draft

この機能により、トレーニング管理者は Training Matrix への変更の下書きを保存し、後で作業に戻ることができます。これまで、ユーザが Training Matrix を編集した場合、その変更を破棄するか、すぐに公開するかのいずれかを選択できました。

ユーザは以下のことを行えるようになりました。

• Training Matrix を編集し、必ずしも公開することなく作業を保存する
• 必要に応じて中断して後で戻る
• 現在のライブ Training Matrix と Training Matrix Update の下書きを切り替える
• Training Matrix Update の下書きが不要になった場合に破棄する
• Training Matrix Update を公開し、新しいライブマトリックスにする

さらに、Training Matrix の下書きを編集している際に、ユーザはユーザマトリックスの自動化に頼らずに、Training Matrix に手動で Study Country セクションを追加できます。Study Training Matrix Builder 内に直接配置された新しいボタンを使用すると、ユーザは国レベルの Training Requirements に新しい Study Country セクションを柔軟に追加できるようになります。これまで、eTMF ドキュメントが承認され、Connected with Veeva Study Training と明示された場合にのみ、新しい Study Country セクションが Training Matrix に表示されていました。

この機能では、Vault Owner Actions、Vault Training: Business - Administrator Actions、Vault Training: Study Training Admin Actions、Vault Training: System Administrator Actions の権限セットを自動的に更新して、Training Matrix Update オブジェクトの Read および Edit 権限を含めることができます。

この機能は、Automated Training Matrix (V2 Matrix) を使用する治験では自動的にオンになります。手動マトリックス (V1) を使用した治験には影響しません。

Study Training Matrix Builder Enhancements

Study Filter

ユーザが Study Training Matrix Builder に追加する Training Requirement を選択すると、Vault ではユーザが現在表示している Study レコードを使用して、新しい Study フィルタを事前入力します。

Global Section Re-labeled for Studies

Study Training Matrix の「Global」セクションのラベルが「Study」に変更されました。これまで、「Global」というラベルは、治験に固有ではない項目を伝えるため、誤解を招く可能性がありました。

Study Training での VeevaID シングルサインオン (SSO) のサポート

この変更により、Study Person レコードを Study Training へ転送する前に、Federated ID を Person に追加できるようになりました。

この機能の目的は、Federated ID が検出されなかった場合に、自動的に Person レコードに Federated ID を割り当てることです。たとえば、Study Training-Clinical Operations Vault Connection を介して Study Training 内に Study Person が作成され、かつ関連する Clinical Person に Federated ID 値がある場合、Vault では Clinical Person レコードの Federated ID を Study Training で作成された Veeva ID に転送します。Federated ID がすでに存在する場合、その値は維持され、上書きされません。

Federated ID のない既存ユーザの場合、お客様が該当するユーザレコードを手動で更新する必要があります。

詳細と機能の有効化設定については、Study Training 向け Veeva ID をご覧ください。

OpenData Clinical

Investigator Affiliation to Multiple Sites

この機能により、複数の研究施設に所属する OpenData Clinical Investigators の複数の Contact Information レコードが Vault に作成されます。OpenData Clinical データセット内では 1 つの所属が Primary とみなされますが、Person レコードに対するアクションにより、お客様は特定の Investigator に対してどの施設の所属を Primary とみなすかを選択できます。これにより、お客様は OpenData Clinical のキュレーションされたデータから引き続きメリットを得ながら、ビジネスニーズに合わせてデータを調整できます。

Parent Site Records

この機能により、OpenData Clinical (ODC) データセットの一部として親 Organization レコードが提供され、配布された Site レコードを更新してその親を参照できます。これにより、大規模な病院やセンター内の複数の部門、または研究ネットワーク内のクリニックが、単一の親レコードの下に揃えられるようになります。そのため、貴重な組織コンテキストが提供されるほか、明確かつシンプルな階層での施設間の報告に対応できます。

この機能の一部として、ODC では新しい Available as Study Site フィールドを活用します。適切な研究施設ではない親エンティティの Available as Study Site を FALSE に設定しつつ、その中の子 Sites の値を TRUE にできます。これにより、確実に Study Sitesとしてのレコードが適切に使用されます。

eCOA

eCOA Vault

End-of-Study Database Lock for Sites and Studies

この機能により、Study Builder または新しい Lead Data Manager ロールを持つ治験依頼者または CRO スタッフが、治験施設と治験データベース全体を eCOA Vault からロックおよびロック解除して、治験終了時のデータの整合性を確保できるようになります。

主な機能は以下のとおりです。

• 施設のロック: 施設ユーザのアクションを制限し、参加者を無効にします。ロック開始後に受信したデータは個別に保持され、リクエストに応じて処理されます。
• 施設のロック解除: 特定の権限を持つ施設ユーザに対してデータ更新を許可します。施設がロックされている間に受信したデータを受け入れるには、その前に施設のロックを解除する必要があります。
• 治験のロック: eCOA Vault および Studio でのすべてのアクションを制限し、施設のロックが解除されるのを防ぎます。
• 治験のロック解除: ユーザに対して治験に必要な更新と施設のロック解除を許可します。

詳細については、locking databases と unlocking databases をご覧ください。

Generate End-of-Study Media

この機能により、必要な権限を持つ治験依頼者または CRO スタッフは、ロックされた治験について以下の包括的な治験および施設データを生成およびダウンロードできるようになります。

• 参加者データ (臨床データ監査証跡を含む)
• システム監査証跡
• ユーザアクセス情報

データは施設ごとにパッケージ化されます。治験に制限されたデータが含まれている場合は、制限されたデータがすべて含められます。eCOA Vault 内のドキュメントへのアクセスは、ユーザが付与されている、制限されたデータへのアクセス権と一致しています。このメディアは、施設データの保持、規制遵守、eTMF ファイリングに使用できます。

詳細については、generating end-of-study media をご覧ください。

Studio

Display Vertical Visual Analog Scale as Simple Line

この機能により、治験依頼者または CRO スタッフは新しい displayType パラメータを使用して、垂直方向の視覚的アナログスケールが単純な線として表示されるように設定できます。この単純な線は、調査の表示に関する著作権や利害関係者の期待に応えるために必要に応じて使用できます。このパラメータが設定されていない場合、視覚的アナログスケールはデフォルトでバーとして表示されます。

詳細については、configuring a Visual Analog Scale (VAS) をご覧ください。

Upload Multiple Translation Files at Once

治験依頼者/CRO スタッフは、複数の .JSON 翻訳ファイルを一度にアップロードすることで時間を節約できます。ファイルが正常にアップロードされなかった場合、特定のファイルと、アップロードを妨げている問題を説明するエラーログが表示されます。

さらに、翻訳ベンダーのニーズを満たすため、治験依頼者/CRO スタッフはソース言語が取り込まれた翻訳もダウンロードできるようになりました。

詳細については、managing study languages and translations をご覧ください。

Language Search, AP/EU Reports, In-Person Enrollment Error, Collection Languages UI, Offset Days Validation, English Survey Display Labels in Item Data Columns

この機能には、以下の改善が含まれています。

• 言語検索: Library Manager と Studio の言語リスト内の検索を可能にします。
• 強化された実行レポート (AP/EU): アジア太平洋 (AP) および欧州連合 (EU) 地域の施設ユーザの実行レポートに関する操作を改善します。
• 対面アンケートを実施する際のポップアップエラー: 施設スタッフユーザがポップアップを有効にせずに対面調査を開始しようとすると、説明的なエラーメッセージが表示されます。
• Collection Languages タブのテキストの改善: Collection Languages タブの UI テキストが更新され、意味がわかりやすくなりました。
• オフセット日数の検証: ゼロまたは極端に大きい値を入力できないように、Offset Days フィールドに検証を追加します。
• アイテムデータ列の調査表示ラベルの英語表記: 監査証跡のために、調査表示ラベルを含むアイテムデータ列には、どの言語で調査が実施されたかにかかわらず、ラベルは英語で表示されます。

Configurable Export Job Schedules

この機能により、治験依頼者/CRO スタッフは各 FTP および CDB エクスポートジョブのスケジュールと開始タイミングをカスタマイズできます。治験依頼者/CRO スタッフは、すべてのジョブの繰り返し間隔 (1 時間ごと、数日ごと、月 1 回など) を選択することもできます。

詳細については、configurable export job scheduling をご覧ください。

Custom Exports

この機能により、治験依頼者または CRO スタッフは、列の選択、列見出しの名前変更、フィルタリングと並べ替えの設定を行うことで、カスタムデータエクスポートを作成できます。治験依頼者は、Export Jobs でこれらのカスタムエクスポートを使用でき、Study Home でも利用できるように設定できます。

詳細については、working with custom exports をご覧ください。

Enhanced Export Options (Domains, Configurable Export Labels, Local Time Zones)

この機能により、治験依頼者が調査ドメイン (QS、FT、RS) を定義し、質問名、質問見出し、回答名、回答ラベルのエクスポート値をカスタマイズして、Study Data Tabulation Model (SDTM) 標準との整合性を高めることができるように、標準レポートが改善されます。ユーザは、データが収集されたローカルタイムゾーンでシステムタイムスタンプをエクスポートすることもできます。

詳細については、customizing export values をご覧ください。

Study Home and Reporting

New Standard Reports

この機能では、以下の 2 つの新しい標準レポートが導入されます。

• Participant Events
• Participant Groups

これらのレポートでは、参加者イベントまたは参加者グループの情報がすべて 1 つのビューに含まれており、Study Home から実行することも、Studio の Export Job として実行することもできます。

詳細については、Participant Events report specifications と Participant Groups report specifications をご覧ください。

New Study Home Reports: Site Clinical Data and Non-Clinical Data Audit Trail Report Separation in Study Home

この機能は、既存の Site Audit Trail レポートを Site Clinical Audit Trail レポートと Site Non-Clinical Data Audit Trail レポートに分離します。これらのレポートは、治験依頼者/CRO スタッフが Study Home で閲覧できます。

参加者のプライバシーを保護するため、治験依頼者のビューでは個人を特定可能な情報 (PII) が秘匿化されます。治験依頼者/CRO ユーザは、治験実施国、施設、日付範囲 (タイムゾーンパラメータを含む) によって監査証跡レポートをフィルタリングすることもできます。

詳細については、new report specifications をご覧ください。

Criteria Check Results

治験依頼者または CRO スタッフは、Study Home の参加者レベルの Events セクションで、施設基準チェックイベントの結果にアクセスできるようになりました。基準チェックリンクを選択すると、その参加者の関連する結果すべてを表示するドロワーが開き、時系列で最新のログが一番上に表示されます。この機能強化により、治験依頼者はレポートを生成したり検索したりすることなく、個々の参加者のイベント結果を表示できるようになります。

詳細については、Study Home の viewing criteria check results with the participant-level data をご覧ください。

CDB Connection Improvements

この機能により、次の Clinical Database (CDB) の更新が可能になります。

• ファイルセキュリティの強化: CDB ファイルを配信するシステムが、より安全なファイルステージングサーバーに更新されました。この変更により、データ転送の信頼性とセキュリティが向上します。
• コンプライアンスレポートの可用性: コンプライアンスレポートが CDB コネクションに含まれるようになりました。調査データと同じパッケージに含まれています。
• 説明的な命名: CDB .ZIP ファイルの命名形式がより説明的になり、_eCOA_.zip になりました (例: GLR305-E001_eCOA_20241218030251234.zip)。

25R2 Feature Audit Events

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

Veeva eCOA (Sites)

New Survey Status: Intentionally Left Blank

施設スタッフは、期限がまだ過ぎていない参加者アンケートを Intentionally Left Blank としてマークできるようになりました。これにより、施設では参加者のタスクリストをクリーンアップし、重複したデータのキャプチャを回避できます。このステータスの調査は転記可能です。

監査ログとレポートにはこのステータスが含まれます。

詳細については、managing survey availability and status をご覧ください。

Reduced PII Collection for Participant and Caregiver Registration

この機能により、eCOA の参加者と介護者の登録プロセスが更新され、生年のみの入力が求められるようになり、名、姓、生年月日を収集する必要がなくなります。

Support Chat for Sites

この機能により、すべての eCOA ページにチャットボタンが追加され、施設スタッフは現在のタスクを離れることなく、Veeva サポートチャットに直接アクセスして支援を受けることができます。

Downtime Notification Immediately Before eCOA System Upgrade

この機能は、eCOA の更新によるシステムのダウンタイムが始まる直前に通知を表示し、計画されたダウンタイムを施設スタッフに知らせ、データの損失を避けるために進行中の作業を保存するように促します。

MyVeeva for Patients

General

Password-Authentication Added for In-Person Access

この機能により、治験依頼者または CRO スタッフは参加者に対面調査へのアクセスにパスワードを使用するように求めて、セキュリティを強化できます。Enable In Person Flow で Password-Authenticated 設定が選択されている場合、参加者は既存の MyVeeva ログイン情報を使用してログインするか、施設スタッフが対面調査を開始する際にログイン情報を作成します。この設定は治験レベルで制御され、eCOA Vault の国または施設レベルではオフにすることができます。

詳細については、managing in-person survey access をご覧ください。

翻訳

25R2 Translations and New Languages

MyVeeva ユーザは、アプリケーションのテキスト、メール、通知をルーマニア語 (ルーマニア) と南ソト語 (南アフリカ) で表示できるようになりました。

25R1 Maintenance Release New Languages

MyVeeva ユーザは、アプリケーションのテキスト、メール、通知をラトビア語 (ラトビア) とロシア語 (ラトビア) で表示できるようになりました。

Commercial

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

Veeva Connections セクションに記載されている PromoMats-Medical Connection: Auto Update Anchor Support 機能も、Commercial アプリケーションファミリーに影響を与えます。

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

OCR for Images in PowerPoint & Word Files

画像を含む Microsoft Office Word および PowerPoint のソースドキュメントでは、光学文字認識 (OCR) が実行されるようになりました。これらのドキュメントの画像内に含まれるテキストが抽出され、ドキュメント上の既存のテキストと結合されて最終的な OCR 出力が生成されます。これにより、Word および PowerPoint のドキュメントが PDF ドキュメントで実行された OCR と一致するようになります。

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

PromoMats

MLR Bot

MLR Bot は、AI を活用した PromoMats のレビューアシスタントです。レビューサイクルを大幅に減らし、承認までの時間を短縮するのに役立ちます。これはコンテンツ所有者と MLR レビュー担当者向けに特別に設計された Commercial スイート内の新しいアプリケーションで、大規模言語モデル (LLM) を活用して PromoMats の資料に存在するさまざまな一般的な問題を未然に特定します。

MLR Bot は PromoMats に直接統合されています。つまり、ドキュメントとデータは Veeva Vault 環境内に留まるため、データの安全性が確保され、ユーザセキュリティが完全に尊重されます。

MLR Bot には、以下のような品質チェック項目が事前定義されています。

編集

スペル: 明確さを損ない、専門的なプレゼンテーションに影響を与える可能性のあるスペルエラーを特定します。

文法: 明確さ、専門性、コンプライアンスに影響を与える可能性のある文法エラーを指摘します。

規制および市場ガイドライン

危険信号フレーズ: 根拠のない有効性の主張、リスクの最小化、誤解を招く比較など、保健当局の規制に違反している可能性のある単語、用語、フレーズを検出します。

ブラックボックス警告: FDA に従い、ドキュメントに記載されている製品にブラックボックス警告が必要かどうかを判断します。必要に応じて、警告の存在、場所、一般的な形式を評価します。

重要な安全情報 (ISI): 関連する ISI ドキュメントがある場合、そのドキュメントに記載されている重要な安全情報が現在のドキュメントに正確に反映されているかどうかを評価し、欠落や不正確な箇所を特定します。

チャネルルール

プライバシーポリシーリンクと配信停止リンク: 内容と使用目的に基づいてプライバシーポリシーリンクまたは配信停止リンクが必要かどうかを判断し、ドキュメント内のそのようなリンクが Website オブジェクト内のレコードと一致しているかどうかを確認します。

アクセシビリティ

代替テキストと色のコントラスト: コンテンツがアクセシビリティ標準に準拠しているかどうかを検証するため、障害を持つユーザにとっての潜在的な障壁を特定し、視覚的要素 (色のコントラストや代替テキストなど)、構造、WCAG の原則に基づく読みやすさを評価します。

AI アシスタント

自動的な品質チェックに加えて、ユーザは直感的な AI アシスタントも利用できます。このアシスタントに閲覧中のドキュメントバージョンについて直接質問することで、重要な点をすばやく把握し、要約を作成できます。また、文脈を理解するシステムにより、複数パートからなる会話を交わすこともできます。このリリースでは、アシスタントはドキュメントのテキストや画像、および品質チェックの包括的な結果を活用して、洞察に富んだ応答を返します。

Claims: Auto-Linking Deduplication

この機能強化により、Veeva PromoMats は、Auto-Linking が実行されるたびに新しい Claim リンクのみを提供します。拒否されたリンクでユーザアクションが実行されるように設定していない限り、以前に拒否されたリンクは再作成されません。また、同じテキスト座標の完全一致および近似一致へのリンクも作成されません。For Suggested Links, bypass Approve step on exact matches 設定が無効になっている場合、重複した Claim リンクが発生する可能性があります。この機能は、ユーザによる重複した手作業を削減することで、Claims のリンクエクスペリエンスを合理化するのに役立ちます。

Text Assets: Product Data Model for Auto-Linking

PromoMats で Product Family、Product Form および Product Variant を使用しているお客様の場合、フィールドが Text Assets に合わせてプロビジョニングされ、Auto-Linking で使用できるようになりました。ドキュメントが拡張データモデルに固有の場合、同じ値を持つ Text Assets のみが自動リンクされます。これらのフィールドは、Text Assets を手動でリンクする場合のフィルタとしても使用できます。

Disable Suggest Links Until Document Processing is Complete

ドキュメント上で手動で Suggest Links を実行する場合、光学文字認識 (OCR) が完了するまで Suggest Links ボタンは無効になります。

OCR が完了する前に Suggest Links を実行すると、一部のドキュメントテキストが認識されず、不完全な結果につながる可能性があります。この機能強化により、その可能性を軽減できます。ユーザはページを更新する必要はありません。OCR が完了すると、Suggest Links ボタンが自動的に有効になります。

詳細については、OCR for Scanned and Mobile Files をご覧ください。

Portal: Dynamic Widgets

Vault では Dynamic Widgets に対応できるようになったため、ユーザは Vault Library または Portal Library のカスタムビューを使用して、Portal ウィジェットにドキュメントを自動的に取り込むことができます。手動によるキュレーションが必要な静的ウィジェットとは異なり、動的ウィジェットでは定義されたフィルタ条件に一致するドキュメントが Vault に入ると自動的に更新されます。

この機能により、手動によるメンテナンスの労力が削減され、Portal 内のコンテンツが最新の状態に保たれることで、ポータル管理者、ビジネス管理者およびエンドユーザにメリットがもたらされます。これにより、チームはウィジェットを手動で更新することなく、ドキュメントセットの更新されたビューを自動的に公開できるようになります。

ポータル管理者は、Portal ごとに最大 10 個の Dynamic Widgets を作成できます。

eCTD: Empty Required Fields Warning Message

このリリースでは、eCTD コンプライアンスパッケージを生成する際に、パッケージに含まれるドキュメントに空の必須フィールドがある場合、ユーザに警告メッセージが表示されます。

Commercial Content Kernel Updates

ブランドガイドラインの Commercial Content Kernel に新しいドキュメントタイプを導入しました。また、References > Labeling ドキュメントサブタイプの説明が更新され、医薬品ガイドが含まれるようになりました。

Product Family Generic Name Field Length Increase

この機能により、Product Family (product_family__v) オブジェクトの Generic Name (generic_name__v) フィールドが 500 文字に増えます。これまで、このフィールドの最大長は 100 文字でした。

PromoMats Notification Templates: Vault Support Updated to Veeva Support

この機能強化により、選択した Notification Templates のメール本文と通知テキスト内の「Vault Support」というフレーズが「Veeva Support」に置き換えられます。以下のテンプレートは、通知のテキストがお客様によって変更されていない場合にのみ更新されます。つまり、お客様がテンプレートを変更した場合、その変更が上書きされることはありません。

この機能により、以下のテンプレートが更新されます。

• auto_image_rendition_fail__v
• auto_image_rendition_failure__v
• automated_image_rendition_failure__v
• formgenerationfailure__v
• generateclmpreviewerror__v
• make_a_local_copy_job_failure__v
• mergefieldsnotifications__v
• pdfacreationfailure__v
• pdfcreationfailure__v
• sandbox_job_error__v
• sandbox_snapshot_upgrade_failure__sys
• scheduledjobcancellationnotice__v
• scheduledjoberror__v
• veevaid_vault_user_creation_exception__v

Medical

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

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

• Medical-CRM Connection: Medical Inquiries
• PromoMats-Medical Connection: Auto Update Anchor Support

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

Medical Settings & Field Relabeling

次の設定とフィールドのラベルが変更されました。

• Admin > Settings > Application Settings
  • 現在のラベル: Medical Inquiry
  • 新しいラベル: MedInquiry Settings
• Admin > Configuration > Objects > language_v
  • 現在のフィールドラベル: Vault Medical UUID
  • 新しいフィールドラベル: Medical UUID
• Admin > Configuration > Objects > controlled_vocabulary_v
  • 現在のフィールドラベル: Vault Medical UUID
  • 新しいフィールドラベル: Medical UUID

Medical Notification Templates: Vault Support Updated to Veeva Support

この機能強化により、選択した Notification Templates のメール本文と通知テキスト内の「Vault Support」というフレーズが「Veeva Support」に置き換えられます。以下のテンプレートは、通知のテキストがお客様によって変更されていない場合にのみ更新されます。つまり、お客様がテンプレートを変更した場合、その変更が上書きされることはありません。

この機能により、以下のテンプレートが更新されます。

• auto_image_rendition_fail__v
• auto_image_rendition_failure__v
• automated_image_rendition_failure__v
• formgenerationfailure__v
• generateclmpreviewerror__v
• make_a_local_copy_job_failure__v
• mergefieldsnotifications__v
• pdfacreationfailure__v
• pdfcreationfailure__v
• sandbox_job_error__v
• sandbox_snapshot_upgrade_failure__sys
• scheduledjobcancellationnotice__v
• scheduledjoberror__v
• veevaid_vault_user_creation_exception__v

MedComms

Scientific Statements: Harvesting

Scientific Statements を Document Link 注釈から収集できるようになりました。Veeva MedComms では、エントリアクションまたはユーザアクションのいずれかを使用して、強調表示されたテキストと裏付けとなる参照資料を抽出し、Scientific Statement オブジェクトレコードへの自動入力が試みられます。この機能は、エリア注釈とテキスト注釈の両方に使用でき、重複する Scientific Statement レコードの生成を識別し、回避するように設計されています。

詳細については、harvesting Scientific Statements をご覧ください。

Scientific Statements: Statement Assets

このリリースでは、画像、チャート、表、その他のドキュメントベースのコンテンツなどのアセットを Scientific Statementに追加するオプションが導入されました。多くの場合、記述をグラフィカルに表現するチャートなどの視覚的またはグラフィカルな要素によって Scientific Statements を説明できます。

Scientific Statements: Auto-Linking Deduplication

この機能強化により、Veeva では Auto-Linking が実行されるたびに新しい Scientific Statement リンクのみを提供し、ユーザアクションが拒否されたリンクで実行されるように設定していない限り、以前に拒否されたリンクは再作成されません。また、同じテキスト座標の完全一致および近似一致へのリンクも作成されません。For Suggested Links, bypass Approve step on exact matches 設定が無効になっている場合、重複した Statement リンクが発生する可能性があります。この機能は、ユーザによる重複した手作業を削減することで、Statement のリンクエクスペリエンスを合理化するのに役立ちます。

Scientific Statements: Lifecycle Entry Criteria for Substantiation

この機能により、ユーザは裏付け資料を必要とすることなく、Scientific Statements を定常状態に移動し、コンテンツにリンクできます。このリリース以前は、Scientific Statements を定常状態にするには参照資料が必要であり、実証が不要な Scientific Statements の使用が制限されていました。

Communication Objectives for Documents

ユーザは、Communication Objectives をコンテンツにリンクすることで、戦略的な成果に関する洞察を得られるようになりました。さらに、Scientific Statement Auto-Linking を使用すると、Scientific Statements にリンクされた Communication Objectives が自動的にドキュメントに関連付けられます。

詳細については、Communication Objectives をご覧ください。

Medical Portal: Dynamic Widgets

Vault では Dynamic Widgets に対応できるようになったため、ユーザは Vault Library または Portal Library のカスタムビューを使用して、Portal ウィジェットにドキュメントを自動的に取り込むことができます。手動によるキュレーションが必要な静的ウィジェットとは異なり、動的ウィジェットでは定義されたフィルタ条件に一致するドキュメントが Vault に入ると自動的に更新されます。

この機能により、手動によるメンテナンスの労力が削減され、Portal 内のコンテンツが最新の状態に保たれることで、ポータル管理者、ビジネス管理者およびエンドユーザにメリットがもたらされます。これにより、チームはウィジェットを手動で更新することなく、ドキュメントセットの更新されたビューを自動的に公開できるようになります。

ポータル管理者は、Portal ごとに最大 10 個の Dynamic Widgets を作成できます。

MedInquiry

Automatically Detect Product During Email Intake

現在、MedInquiry は取り込まれたメールの自動 Product 検出に対応しています。この機能により、新しい製品データモデルを考慮して、Product 検出を拡張し、Local Product 検出を含めることができます。

Incoming Calls & Chats Open in a New Tab

ユーザが着信通話またはチャットを受け入れると、新しいタブにリダイレクトされ、そこで問い合わせ、有害事象、製品品質に関する苦情の記録を開始できます。この動作を有効にするには、Veeva サポートにご連絡ください。

MedInquiry: Vault CRM HCP Lookup

MedInquiry ユーザは、Case Contact Search を使用して、統合された Vault CRM 環境に保存されている HCP レコードを検索できます。検索中は、統合環境ごとに 1 つずつ存在する専用の CRM タブに HCP データが表示されます。Case Contact が Case に割り当てられると、HCP データが新しい Case Contact レコードにインポートされるか、既存のレコードが更新されます。

このデータフローにより、HCP データを CRM から MedInquiry に移行する必要がなくなり、チームは単一の ID と照らし合わせてエンゲージメントデータを集約できます。

Standardization of Responses & Interactions

MedInquiry をさらに標準化するため、新しい Case Response オブジェクトタイプ (Chat と Internal Email)、新しい Case Response フィールド (Written Content と Interaction Type)、Event Product の新しいフィールド (Case)、Case、Case Request、Case Response、Event オブジェクトの Cancelled ライフサイクル状態がプロビジョニングされました。

Quality

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

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

• Quality-RIM Connection: Event Auto-Create Per Change Control & Product Family
• Quality-RIM Connection: Product Data Enhancements
• Quality-Safety Connection: Create Safety Inbox Items from Veeva Quality
• Study Training-Clinical Operations Connection: Multi-Study Document Enhancement
• Study Training-Clinical Operations Connection: Support for Specialized Responsibilities

QualityDocs

Dynamic Association of Process Navigator Documents

Process Navigator では、設定された一致ルールに基づいて、特定のプロセスに関連付けられたドキュメントのリストを動的に入力できるようになりました。このリリースより前は、プロセスまたはドキュメントの所有者は、ドキュメントの Quality Relationship パネルまたは Process Navigator ホームページを介して手動でのみドキュメントを関連付けることができました。この手動による関連付けでは、多くの場合、プロセス所有者による継続的なメンテナンスに多くの労力が必要になります。

この新しい機能により、プロセス所有者は、特定のプロセスから Document Association Criteria と呼ばれる新しいユーザアクションを呼び出すことができます。適切な作成権限を持つプロセス所有者は、プロセスごとに最大 3 つの一致ルールを設定でき、システムは OR ロジックを使用してそのルールを実行します。これらの一致ルールは、必要に応じて、Document Type (必須)、Subtype (オプション)、および Classification (オプション) ごとに作成できます。一致ルールを設定した後、プロセス所有者はルールを編集することや、システムによって自動的に一致したドキュメントのリストをプレビューすることもできます。

各一致ルールでは、プロセス所有者は複数のドキュメントフィールドを活用して一致基準を構築できます。プロセス所有者が使用できるドキュメントフィールドの選択は、管理者によって事前定義されています。管理者は、ブール型、オブジェクト参照型、または選択リスト型のドキュメントフィールドを最大 10 個定義できます。

ドキュメントをプロセスに手動で関連付けているお客様の場合、動的に生成されたリストと手動リストとの間の重複が解決されてから、ドキュメントがアルファベット順に表示されます。関連ドキュメントのリストは、Process Navigator のランディングページの Associated Documents パネルと、Process Navigator の詳細ページの Documents セクションに表示されます。プロセスあたり 200 ドキュメントという現在の制限は尊重されます。ドキュメントが 200 を超える場合、関連するドキュメントパネルに「Only the first 200 documents will be displayed (最初の 200 件のドキュメントのみが表示されます)」という警告バナーが表示されます。

Prevent Duplicate Documents in Process Navigator

同じ Visual Hierarchy レコード上で別の Hierarchy Document レコードを介してすでに追加済みの同一のソースドキュメントを持つ Hierarchy Document レコードをユーザが追加しようとすると、Vault にエラーが表示されます。

Add Document Hovercard in the Associated Documents Panel in Process Navigator

Process Navigator の Associated Documents パネルでドキュメントにマウスカーソルを合わせると、標準のドキュメントホバーカードが表示され、ユーザはこれを使用して、ドキュメントのサムネイルや、ドキュメントのタイトル、タイプ、サブタイプ、最終変更情報などの追加のドキュメント情報をすばやく表示できます。これは、ドキュメントの名前が数値であったり説明的でなかったりする可能性がある Vault で特に役立ちます。

Remove Superseded & Obsolete Documents from the Document Control Homepage

Superseded および Obsolete ステータスのドキュメントは Periodic Reviews の対象になりませんが、設定によっては、これらのドキュメントに Start Periodic Review Date フィールド値がある場合があります。Document Control ホームページ の Documents with Upcoming Periodic Reviews セクションに、Superseded または Obsolete 状態のドキュメントが表示されなくなっています。

Create a separate section for System Managed Document Relationships in the Quality Relationships Panel

Quality Relationships パネルの Document Relationships セクションにある、新しい System Managed Relationships サブセクションには、Based On、Original Source、Linked Documents など、Vault によって自動的に作成される標準的な関係が表示されます。これにより、これらのタイプの関係を、既存の Target および Source サブセクションの下に表示される、ユーザによって作成される関係と区別できるようになります。

Associate Document Change Request & Periodic Review Records During Change Authorization

Document Change Control プロセスの Change Authorization セクションを使用する場合、ユーザは、Change Authorization レコードのターゲットドキュメントに関連する Document Change Request レコードと Periodic Review レコードを手動または自動で関連付けることができます。これにより、影響評価者と変更承認者は、それぞれのタスクを完了する際に、Document Change Control に含まれるドキュメントへの提案された変更に関する追加の参照とコンテキストを得ることができます。この機能強化の前は、Document Change Request レコードと Periodic Review レコードを関連付けられるのは、Document Change Control が変更承認を受け取った後でした。

Prevent Selection of Proposed Implementation Date Field in the Past

この機能強化により、ユーザは、Document Change Control オブジェクトの Proposed Implementation Date フィールドに過去の日付を選択できなくなります。設定されている場合、Vault は、Update Change Control Document エントリアクションの実行時に、Proposed Implementation Date を関連するドキュメントフィールドにコピーします。日付は、自動有効性ジョブまたは自動廃止ジョブの実行時に、それぞれのドキュメントが有効/廃止になる時期を制御します。この機能は、人為的エラーによる予期しない有効性や廃止を防ぐのに役立ちます。ユーザが過去の Proposed Implementation Date でレコードを保存しようとすると、Vault にエラーメッセージが表示されます。

Allow Deletion of Documents with Inactive Controlled Copies

24R2 リリースでは、1 つまたは複数の関連付けられた Controlled Copy Trace レコードのあるドキュメントをユーザが削除することを Vault が妨げないようにする機能が導入されました。この機能強化により、関連付けられている Controlled Copy Trace レコードのあるドキュメントは削除可能なままですが、関連付けられているすべてのレコードが非アクティブ状態にある場合のみ削除できるようになり、機能がさらに向上しました。新しいアプリケーション設定を有効にすると、関連付けられているターゲットドキュメントが削除されたときに、非アクティブな Controlled Copy Trace レコードが自動的に削除されます。

Training

Automated Generation of Training Requirement Impact Assessment (TRIA) & Display in Document Change Control (DCC)

この変更では、新しい設定コンポーネントにより、Vault 管理者は QualityDocs と Training の Document Change Control (DCC) および Training Requirement Impact Assessment (TRIA) プロセスを組み合わせることができます。

この変更以前は、これら 2 つのプロセスは分断されており、DCC プロセス中にドキュメントが Approved 状態に達した場合にのみ TRIA がトリガーされました。

この変更の主な目的は次のとおりです。

• ドキュメントが Issued (Training 準備完了) 状態になる前に TRIA プロセスを完了します。これにより、学習者はドキュメントが Effective になる (定常状態に達する) 前に、より多くの時間をかけてドキュメントをトレーニングできます。同様に、このプロセスにより、学習者は Obsolete になるドキュメントのトレーニングを要求されなくなります。
• ドキュメントコントローラを TRIA プロセスに含めることができるようにします。
• DCC レコードと TRIA レコードをリンクすることで、両方のプロセスの可視性を高めます。

たとえば、Vault が DCC Impact Assessment ワークフローを開始し、DCC レコードを In Document Review 状態に移行させ、新しい DCC ライフサイクルエントリアクションによって DCC のドキュメントを Effective や Obsolete にするための TRIA レコードも作成されます。さらに、Vault は、(DCC レコードに割り当てられたロールに従って) DCC プロセスの参加者に TRIA ワークフロータスクを割り当てます。また、新しいエントリ条件により、関連するすべての TRIA ワークフローが完了した場合にのみ DCC を閉じることができます。

Automatic Completion Credit for Document Participants

特定のシナリオでは、ドキュメント参加者 (Owners や Approvers など) は、作業したドキュメントのトレーニングを完了する必要はありません。この機能により、トレーニング管理者は選択したドキュメント参加者にトレーニングクレジットを自動的に付与できます。

Vault 管理者は、ドキュメントまたはドキュメント変更管理 (DCC) ワークフロー内で、Provide Participant Training Completion Credit システムアクションを設定できます。ワークフロー内の 1 つ以上の参加者グループを選択して、自動クレジットを付与できます。Vault でそのドキュメントの Training Requirement のトレーニングを発行すると、グループ参加者の関連する課題が自動的に完了します。

管理者は、関連する課題を発行する際に Vault により自動的にクレジットが付与されるすべての学習者が表示される Training Requirement Impact Assessment (TRIA) オブジェクトページレイアウト (「Training Completion Credit Users」) にセクションを設定することもできます。この情報を使用して、トレーニング管理者はユーザのリストを変更できます。この機能は、複数のドキュメントを含む Vault Document Training Requirements には対応していません。要件の最新の TRIA に関連付けられたコンテンツセットに複数の項目がある場合、Vaultは「This is a multi-item training requirement. Automated participant credit is not currently supported.」という警告メッセージを表示します。

この新しい機能により、トレーニング管理者は Training Requirement レベルで自動完了クレジットを許可するかどうかを決定することもできます。要件の新しい Allow Document Participant Credit? フィールドを使用して、その要件を自動クレジットで処理するかどうかを指定できます。この新しいフィールドは TRIA オブジェクトにも存在し、トレーニング管理者はそこで評価中にフィールドを変更できます。どちらかのフィールドが変更されると、Vault により変更が同期されます。

Facilitated Training: 過去版のドキュメントのトレーニング課題の完了

この Facilitated Training の機能強化により、トレーニング管理者は、過去版のドキュメントのキャンセルされた Training Assignments を完了できるようになります。これは、学習者が Vault の外部でトレーニングを完了し、その後トレーニング管理者が学習者に代わって Vault に履歴を記録するような大規模な組織で役立ちます。このプロセスには時間がかかるため、その間に関連ドキュメントが過去版になり、関連する Training Assignments がキャンセルされる可能性があります。

Curriculum と Training Requirement の Facilitated Training Request オブジェクトタイプに新しい Cancelled Training Assignment ページレイアウトセクションが追加され、トレーニング管理者は、関連する Training Content Set 内でキャンセルされた Training Assignment レコードとそれに関連するドキュメントを確認して選択できるようになりました。Facilitated Training Request レコードが、Update Training Assignments エントリアクションが設定されているライフサイクル状態に移行すると、Facilitated Training 非同期ジョブによって、これらのキャンセルされた課題が Completed 状態に移行されます。

Equivalency Substitute Training Rules

この機能により、Equivalent Training Rules が導入され、主な Training Requirement (または学習者の現在の Training Matrix の一部) を別の主な要件と同等であるとみなすことができます。Learner が同等のトレーニングを完了すると、以下のユースケース 1 で示されているように、両方のクレジットが付与されます。同等を双方向にすることもできます。その場合、ユースケース 2 のように、設定されたルールにより、学習者はどちらかの主な要件を完了し、両方のクレジットを取得できます。

この機能により、既存の Substitute Training Rule 機能も改善され、主な Training Requirement を別の主な要件の代替とみなすことができる新しいユースケースの実現が可能になります。これまで、主な Training Requirement は、学習者のマトリックス外の要件によってのみ置き換えることができました。同等のルールとは対照的に、Substitute Training Rules を双方向にすることはできません。つまり、要件が 2 つ (プライマリまたは非プライマリ) ある場合、そのうちの 1 つだけが他の要件と置き換えられます。この新しい機能はユースケース 3 で確認できます。

新しい Training Rule Substitution Type 選択リストを使用すると、トレーニング管理者は Substitute Training Rule を作成するときに、Full オプションを選択して、1 つの主な要件を別の主な要件と完全に「交換」することができます。その他の選択リスト値は、この機能に付随する Delta Training および Refresher Training 機能に対応しています。

ユースケース 1: 単純な同等ルール

学習者の Training Matrix には、ガウニングに関するトピックの 2 つの Training Requirements が含まれます。1 つはインストラクター主導のトレーニング (ILT) のためのもので、もう 1 つは Learner が自主的にトレーニングドキュメントを読んで理解を確認するためのもの (R&U) です。「Gowning ILT」は R&U トレーニングよりも詳細ですが、学習者は現在、両方の課題を完了する必要があります。これは、どちらの課題も主要な Training Requirements (トレーニングマトリックス内の任意の要件) に基づいているためです。

この機能を使用すると、トレーニング管理者は「Gowning R&U」要件に対して、「Gowning ILT」が同等とみなされるようなトレーニングルールを設定できます。つまり、学習者は (トレーニングドキュメントを読む代わりに) ガウニングに関する ILT セッションにのみ参加し、Training Matrix を遵守したまま「Gowning R&U」の課題の完了要件を自動的に満たすことができます。

ユースケース 2: 双方向の同等ルール

「Gowning R&U」の要件と関連する Training Materials では 2 年ごとにレビューが実施されます。レビュー中に、「Gowning ILT」インストラクターはトレーニング管理者に、「Gowning R&U」要件の更新された資料が ILT セッションで扱われるコンテンツの詳細度と一致し、これらの要件が相互に同等になったことを通知します。

Training Matrix 内でこれに対応するために、トレーニング管理者は、「Gowning R&U」が「Gowning ILT」と同等であるとみなされる 2 番目のトレーニングルールを設定します。Vault により、設定されたトレーニングルールが影響を受けるすべての要件内で表示されるようになるため、この新しいルールはどちらの要件でも設定できます。

上記のルールを組み合わせることで、同等関係は双方向になります。つまり、学習者は「Gowning R&U」または「Gowning ILT」のいずれかの課題を完了して、完了していない課題の要件を満たすことができるようになります。

ユースケース 3: 完全な代替による双方向同等ルール

前述の「Gowning R&U」要件の 2 年ごとのレビューの一環として、要件の新しい英語の Training Materials がスペイン語に翻訳され、それらの資料は現在新しい「Gowning R&U - Spanish」要件の一部となっています。この新しい要件は、既存の Substitutes 機能のユースケースに対応しています。この機能により、Vault で学習者のロケールに基づいてトレーニングを動的に割り当てることができます。

Equivalency Substitute Training Rules 機能を使用すると、トレーニング管理者は双方向同等性などのより複雑な状況に基本的な代替動作を適用できます。この要件グループの 3 番目のトレーニングルールでは、「Gowning R&U」を完了することを選択した学習者の Person レコードの Language が「Spanish」の場合、自動的に「Gowning R&U Spanish」が割り当てられます。この英語とスペイン語の「交換」は完全な代替とみなされます。他の代替タイプについては、Delta Training と Refresher Training を参照してください。

Delta Training

Delta Training を使用すると、組織はデルタトレーニングコンテンツ (ドキュメントバージョン間の変更) に重点を置いた短いトレーニング資料を作成し、その要件の課題をこれまでに完了している学習者に割り当てることができます。これにより、学習者は最新の更新内容を理解するだけで済むため、トレーニング時間が短縮され、知識の保持率が向上します。

Delta Training を導入する前は、トレーニングが繰り返された結果、小さなプロセス更新の場合でも、学習者はすべてのトレーニング資料の再トレーニングを受ける必要がありました。Delta Training を使用すると、トレーニング管理者は、例えば、ガウニング標準業務手順書 (SOP) の最新の更新のみを網羅した簡単な PowerPoint プレゼンテーションを学習者に送信できます。これが Training Matrix 内でどのように表示されるかについては、以下のユースケースを参照してください。

ユースケース: デルタの代替による単一同等ルール

Training Matrix で「Gowning R&U」Training Requirement (主な Training Requirement) が割り当てられた学習者は、これまでに完了しているトレーニング (新入社員トレーニングの一環など) の主な要件に含まれる資料一式の代わりに「Gowning R&U Delta」要件を完了することができます。

この Delta Substitute Rule の例は、このリリースの Equivalency Substitute Training Rules 機能で示されている別のユースケースと似ています。ユースケース 3 では、特定のケースにおいて Vault ではスペイン語のトレーニング資料の代わりに英語のトレーニング資料一式が提供されます (Full Substitute Rule)。ここでは、Delta Substitute Rule により、Vault で「Gowning R&U」要件のトレーニングを割り当てる際に、代わりにデルタ資料を提供できるようになります。「Gowning ILT」要件で「Gowning R&U」要件を満たす方法の詳細については、Equivalency Substitute Training Rules 機能を参照してください。

Refresher Training

Refresher Training により、組織は Training Matrix の要件の最も重要な側面 (主な Training Requirement) に関する学習者の知識を復習または「更新」することに重点を置いた短いトレーニング資料を開発できます。Vault では、トレーニング管理が設定した Refresher Substitute Rule を使用して、これらの専門的な資料を発行します。主な要件が繰り返しである場合、Vault ではその要件について以前にトレーニングを受けた学習者に対して、主な要件のコンテンツを復習コンテンツに置き換えます。

たとえば、特定の SOP の Vault Document Training Requirement は、学習者がその要件の課題を最後に完了した時点から 2 年ごとに繰り返されます。この要件が Refresher Substitute Rule で設定されている場合、Vault では主な要件の Training Materials の代わりに、復習要件のコンテンツを学習者に割り当てます。これにより、学習者は復習重視のコンテンツにのみ集中すればよいため、トレーニング時間が短縮され、知識の保持が向上します。

LearnGxP ContentDirect: Learner Homepage Course Images

この新機能の目的は、Learner Homepageカードに LearnGxP Training Requirements の画像を表示できるようにすることです。これまでは、トレーニング管理者が手動で画像をアップロードする必要がありました。画像を表示することで、学習者はコースを簡単に識別でき、管理者のメンテナンス時間を節約できます。

LearnGxP ContentDirect で有効にすると、登録者の Vault は SCORM コンテンツとともに画像を自動的に取得します。したがって、Vault が Training Requirements を自動作成すると、関連ジョブによって、関連する画像がコースに自動的に関連付けられ、Learner Homepageに表示されます。

Training & Study Training Enhancements

Instructor-Led Training Search Enhancements

タブを切り替えるときに検索をクリアするなど、複数の Instructor-Led Training セクションの検索機能が改善されました。さらに、検索値に関係なく、Roster と Waitlist に表示される学習者の合計数は同じままです。

Quality Relationships Panel: Support for External and Evaluation Training Requirement Types

Quality Relationships パネルの Training Requirements セクションには、ユーザがダイアログから Training Requirements を選択できる Add ボタンがあります。選択された要件のコンテンツセットにはドキュメントが追加されます。以前は、ドキュメントを含めることができるのは Document および Classroom タイプのみであったため、この機能はこれらのタイプにのみ適用されていました。

Learner Homepage & Task Page: Assignments with Archive Documents

これまで、アーカイブされたドキュメントを含む Training Assignment を表示すると、Learner Homepageと課題のタスクページで学習者にエラーが表示されていました。この機能が強化されてからは、学習者がこれらの場所で Archived ドキュメントを含む課題を表示すると、対象ドキュメントがアーカイブ済みであることを示すメッセージが表示されるようになります。

Learner Home Page: Desktop View Accessible from Mobile

My Learning Mobile ビューには、Open、History および Explore タブへのリンクが含まれるようになりました。これらのタブは、選択するとブラウザタブで開かれます。

Learner Home Page: Open Training Assignments Count Matches the Filtered Training Assignment Count

My Learning > Open タブで、ユーザがフィルタを適用すると、左側のサイドバーにある Open Training Assignments の数が更新されるようになりました。これまで、フィルタを使用する際に、この数字が自動的に更新されることはありませんでした。

Station Manager

Android Station Manager: Background Sync Enhancement

Android OS バージョン 15 で、Station Manager アプリケーションをバックグラウンドで実行した状態での Vault との同期が可能になりました。

QMS

APQR Programs

Annual Product Quality Review (APQR) は、医薬品の品質基準に関する重要な年次評価です。製品の仕様、製造プロセスまたは管理手順に変更が必要かどうかを評価します。

このリリースにより、お客様は標準化されたデータモデルセットを活用して、定義された期間の APQR プログラムを開始、計画および承認できるようになりました。APQR プログラムが有効になると、Proposed APQR から APQR レコードが自動的に生成されます。実行が進むにつれて、Proposed APQR が更新され、承認された計画との整合性が追跡されます。

これらの APQR プログラムは、以前に作成され承認された APQR Program Template を使用して生成できます。

アクションが実行されると、作成が完了したことがユーザに通知され、Vault によって APQR Program レコードが生成されます。Proposed APQR が、Approved ライフサイクル状態タイプに割り当てられたライフサイクル状態にある場合、Proposed APQR が開始日に達するとシステムアクションがバックグラウンドで自動的に実行され、APQR が生成されます。

Qualification & Organization History

このリリースでは、Organization および Qualification レコードのデータの特定時点のスナップショットを作成する機能が導入されました。これにより、Organization レコードが承認されたとき、および更新後に再承認されるたびに、Organization レコードの履歴コンテキストを取得できるようになります。同様に、最初の適格性評価後、および再適格性評価が行われるたびに、Qualification レコードの履歴を保存できるようになりました。

ユーザは、Organization または Qualification レコードの各履歴のスナップショットを簡単に表示できます。これは、監査人がレコードの存続期間中のさまざまな時点での Organization または Qualification レコードに関する情報を要求する監査などの状況で役立ちます。

このセクションのエントリをクリックすると、スナップショットが作成された時点のレコードのフィールドデータが表示されます。

各レコードのスナップショットはドキュメントとして Quality Vault に保存され、次の新しい標準ドキュメント階層のいずれかを使用して分類されます。

オブジェクト	ドキュメントタイプ	ドキュメントサブタイプ	ドキュメント分類
Organization	QMS Generated	Supplier Quality Management	Organization History
Qualification	QMS Generated	Supplier Quality Management	Qualification History

この機能には、システム管理者による設定が必要です。お客様は、ライフサイクル状態エントリアクションとユーザアクションを使用して、Organization および Qualification レコードのスナップショットの作成を有効にすることができます。レコードのスナップショットに含まれるデータと、そのデータのフォーマット方法は、Formatted Output 機能を使用して設定できます。Formatted Output 設定では、読み取り専用の PDF 形式でレコードのスナップショットを生成する必要があります。システム管理者は、ユーザがコンテンツやメタデータを編集できないように、Organization History および Qualification History ドキュメントのセキュリティも設定する必要があります。

Organization Scalability Improvements

このリリースでは、既存のオブジェクトに加えて、柔軟性の向上と長期的なスケーラビリティをサポートするように設計された新しい専用オブジェクトが導入され、組織データのモデル化と管理の方法が大幅に強化されています。

これらの新しいオブジェクトは、内部エンティティと外部エンティティの表現に対するアプローチがより構造化され、明確な区別を可能にし、組織関係の管理方法の複雑さを軽減します。画一的なモデルから脱却することで、お客様は現実世界の構造をより適切に反映した、より直感的でスケーラブルなアーキテクチャを設計できるようになりました。

この機能強化により、よりクリーンなデータモデルが実現され、カスタム関係への依存が軽減されます。この新しいフレームワークは、進化するビジネスニーズをサポートするだけでなく、将来の成長に向けた強力な基盤も提供し、組織の複雑さが増してもシステムの保守と拡張が容易になります。

組織データモデルの詳細については、Veeva Connect の Data Model Documentation をご覧ください。

Quality Teams: Advanced User Search

以前のリリースでは、Quality Teams のユーザ選択ドロップダウンにはユーザ名のみが表示されていたため、特に大規模なユーザベースを持つ組織や、Constraining Roles や Exclusive Membership などのフィルタを使用していない組織では、同じ名前のユーザを区別することが困難でした。

このリリースでは、双眼鏡アイコンからアクセスできる高度な検索ダイアログを導入し、チームメンバーの選択エクスペリエンスを強化しました。この新しいダイアログにより、ユーザは追加のユーザメタデータに基づいてチームメンバーを検索して選択できるようになり、精度と使いやすさが向上します。

検索結果には、Exclusive Membership および Constraining Roles フィルタが適用されます。ただし、Constraining Role のユーザ数が 10,000 を超える場合、検索ダイアログは Constraining Roles のフィルタリングを適用しません。この場合、ユーザは無効な選択を追加できなくなります。

詳しくは、Vault ヘルプで、Quality Teams との連携をご覧ください。

Quality Teams API Permission Enhancements

このリリースでは、パブリック Quality Teams API エンドポイントと Quality Teams 一括管理機能が更新され、Quality Team 管理者の権限が不要になりました。指定されたエンドユーザは、意図しない設定変更のリスクなしに、一括更新タスクを安全かつ効率的に実行できるようになりました。

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

Duplicate Check Expansion: Complaint Intake, SCN, QI

このリリースでは、QMS の Duplicate Check 機能への投資を拡大し、標準オブジェクトである Complaint Intake、Supplier Change Notification および Quality Intake に対応しました。組織は、主なリソースを費やしてすでに提起および処理されている問題のトリアージと調査を行う前に、固有の受信レコードの処理、フラグの特定、およびこれらの受信レコードのファイリングの高速化にチームを集中させることができます。

サポートされている標準QMSオブジェクトの全リストについては、Configuring Duplicate Checks を参照してください。

Recurrence Check Insights: Associate Related Records

ユーザがソースレコード上で直接 Investigations、CAPA、Effectiveness Checks を表示および作成できる既存の Recurrence Check Insights 機能を基に、このリリースでは、Recurrence Check Insights から既存のレコードをリンクする機能を導入しています。

適切な権限があれば、ユーザは複数の既存の Investigations、CAPA、Effectiveness Checks を選択し、ソースレコードに関連付けることができます。選択が完了すると、新しい Relate to Source ボタンがアクティブになり、使用できるようになります。関係が正常に作成されると、新しくリンクされたレコードがソースレコードの関連項目セクションの下に表示されます。

Recurrence Check Insights の詳細、およびその設定方法については、Vault ヘルプをご覧ください。

Reason for Change: Expanded Support for Standard Objects

Reason for Change 機能 は 24R3 リリースで利用可能になりました。Veeva は、完了済みレコードの特定のデータフィールドを組織が更新する理由を把握しようとする保健当局からの要件に対応する機能を導入しました。このリリースでは、この機能で対応できる QMS 標準オブジェクトが拡張され、以下のオブジェクトが含まれるようになりました。

• Assessment Risk (fmea_risk_event__v)
• Assessments (fmea_risk_assessments__v)
• Assessment Risk Mitigation (assessment_risk_mitigation__v)
• Severity (severity__v)
• Occurrence (occurrence__v)
• Detectability (detectability__v)
• Risk Matrix (risk_matrix__v)
• Risk Level (risk_level__v)
• Criticality (criticality_level__v)
• Organization (qms_organization__qdm)
• Auditor Profile (auditory_profile__v)
• Auditor Role (auditor_role__v)
• Context (context__qdm)

サポートされている標準QMSオブジェクトの全リストについては、Configuring Reason for Change を参照してください。

Reason for Change: Print Record Support

このリリースでは、Print Record 機能が拡張され、Reason for Change Details オブジェクトとReason for Change 機能を活用するあらゆるオブジェクトの Reason for Change への対応が新たに導入されました。Reason for Change 機能とレイアウト上に表示される Change History セクションを介して変更が追跡された印刷レコードには、追跡された値の変更と変更の詳細が明確かつ判読可能な形式で記載された Change History セクションが含まれるようになりました。理由が取得された個々の変更イベントについて、より詳細な調査が必要な場合は、関連する Reason for Change Details レコードを個別に印刷できるようになりました。これにより、ページレイアウトで使用できるアプリケーションコントロールが完全にサポートされ、特定の変更操作に関連する追加のメタデータが提供されます。

機能と対応済みのオブジェクトの詳細な説明については、Providing a Reason for Change をご覧ください。

QMS Email Processors: Email Thread Detection

Veeva QMS アプリケーションは、Vault Email Inbox に送信された Email から、Complaint、Complaint Intake、および Supplier Change Notification のレコードを作成できます。Vault は、受信した各メールのレコードを保存し、関連する QMS レコードを作成し、それをメールに関連付けます。

この機能により、以前のメールから作成された QMS レコードに関するフォローアップメールが Vault Email Inbox に転送されるときに処理される方法が強化されます。個人がフォローアップメールを送信して、元のメールに含まれていなかった追加情報を提供します。この機能強化の前は、転送されたフォローアップメールごとに Vault によって新しい QMS レコードが作成されていました。しかし、お客様は、通常、元のメールから作成された QMS レコードに関連する転送メールを望んでいます。

通常、お客様は、企業メールインボックスを使用して、メールを Vault Email Inbox に転送します。企業のメールシステムは不要なメールをフィルタリングで除外し、不要な QMS レコードの作成を防止します。Verteo という QMS のお客様が企業メールインボックスを Vault Email Inbox と共に使用する方法の例を以下に示します。

企業のメールシステムインボックス	企業のメールシステムインボックスの目的
complaints@verteo.com	Verteo は、この企業メールインボックスを設定し、患者や医療提供者から来る可能性のある製品品質に関する苦情のメールを受信するようにしました。この企業メールインボックスで受信したメールは complaint-intake@verteo-vault-prod.com に自動的に転送されます。これは、Complaint Intake レコードを作成する Verteo の Vault Email Inbox に関連付けられたメールアドレスです。
supplier-change@verteo.com	Verteo は、Verteo のサプライヤーから材料やプロセスへの変更提案を説明するメールを受信するため、この企業メールインボックスを設置しました。この企業メールインボックスで受信したメールは scn@verteo-vault-prod.com に自動的に転送されます。これは、Supplier Change Notice レコードを作成する Verteo の Vault Email Inbox に関連付けられたメールアドレスです。

これらの企業メールインボックスに受信されたメールは迷惑メールフィルタを通過し、残りのメールは、企業メールインボックスに設定された自動転送ルールを通じて適切な Vault Email Inbox に自動的に転送されます。このリリースの前は、フォローアップメールが既存の QMS レコードに関連付けられるのではなく、転送されたフォローアップメールによって新しい Complaint Intake および Supplier Change Notification レコードが作成されていました。

このリリースでは、Email Thread Detection と呼ばれる新しい設定オプションが導入されています。このオプションを Root Message ID に設定すると、Vault Email Inbox で転送されたフォローアップメールのスレッドを識別できるようになります。Vault はメールのスレッドを使用して、元のメールと、関連する QMS レコードを見つけます。次に、転送されたフォローアップメールが QMS レコードに関連付けられます。この設定オプションにより、転送されたフォローアップメールごとに新しい QMS レコードが作成されることがなくなります。以下の図は、苦情メールを受信して Complaints 用の Vault Email Inbox に転送する企業メールインボックスの例を使用し、これがどのように機能するかを示しています。

Email Thread Detection が Complaint Vault Email Inbox で Match on Root Message ID に設定されている場合、返信を元の苦情メールに転送すると、Vault では新しい Complaint Intake レコードを作成するのではなく、返信メールを Complaint Intake レコードに関連付けます。新しい Email Thread Detection オプションは、システム管理者が Vault Email Inbox の設定に使用する画面に、下図のように表示されます。

Email Thread Detection オプションが Match on Message IDに設定されている場合、Vault Email Inbox に転送された元のメールへの返信によって新しい QMS レコードが作成されます。このリリースの前は Match on Message ID がデフォルト設定でしたが、このリリース以降、QMS Vault の既存のすべてのメールプロセッサで選択される Email Thread Detection オプションになります。元のメールが Vault に転送された後にメールメッセージを交換し、それらのメールを、メールから作成された元のレコードに関連付けたいお客様には、代わりに Match on Root Message ID を選択することをお勧めします。

Vault Email Inbox が Complaint、Complaint Intake、 および Supplier Change Notification のレコードを作成する方法の詳細をご覧いただけます。

Supporting Records: Inspector Role

Audit Room の Supporting Records 機能が更新され、レコードアクセスの Viewer ロールを活用するユーザコミュニティに影響を与えることなく、査察官と共有されるレコードへのアクセスをより詳細に制御し、より細かくアクセス権を設定できるようになりました。このリリースでは、すべての Supporting Records 機能は、以前は Viewer (viewer__v) ライフサイクルアプリケーションロールを活用していたすべての側面で、Inspector (inspector__v) ライフサイクルアプリケーションロールを活用するようになりました。ライフサイクルに Inspector アプリケーションロールが追加されているオブジェクトのみ、レコードを査察官と共有できます。これらのレコードを査察官と共有すると、レコードの現在のライフサイクル状態で承認された特定のフィールドとセクションのみが査察官に表示されるように、アトミックセキュリティ設定が考慮されます。

Auditor Profile: Delete User Role Setup When Role Qualification Status Is Deleted

このリリース以降、ユーザ に関連付けられた User Role Setup レコードは、対応する Auditor Role が削除されると自動的に削除されるようになりました。

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

Change Related Object Lifecycle State Enhancements & Expansion

24R2 では、QMS Change Related Object Lifecycle State アクションを Audit Program および FMEA Risk Assessment オブジェクトに対して導入しました。このアクションは、レコード制限なしで非同期ジョブを実行し、同期バージョンの上限である 1,000 レコードを超えて関連オブジェクトのライフサイクル状態の移行を可能にします。また、一部の関連レコードの状態移行中にエラーが発生した場合でも、定義済みの状態にプライマリオブジェクトが移行することができます。

このリリースでは、この非同期アクションのサポートを次のオブジェクトに拡張しています: Quality Event、Change Control、Complaint、Continuous Improvement、Deviation、Finding、Lab Investigation、および Nonconformance。さらに、管理者は、アクションの完了時にどのレコードロールに通知するかを設定できるようになりました。

Related Event App Section: User Interface Modifications

Quality Events の関連イベントアプリセクション (スタンドアロンと Quality Events オブジェクトの一部の両方) が更新され、ユーザに対してより明確で適切なガイダンスが提供されるようになりました。部分的なレコードの作成は許可されなくなり、セクション内に表示できるレコードを表示する権限がユーザに割り当てられていない場合は表示されなくなりました。

Related Record Configurations: Hide Invalid Target Fields in Field Mappings

このリリースでは、Related Record Configurations を設定する際の管理者エクスペリエンスが強化され、エラーが減り、設定がより直感的になりました。

新しい設定で Field Value Mappings を定義すると、システム管理フィールド、ルックアップ、および非アクティブなフィールドが、選択可能なソースフィールドとターゲットフィールドのリストから除外されるようになりました。さらに、ソースフィールドの最大文字数が 100 文字であるのに対し、ターゲットフィールドでは 10 文字しか入力できない場合など、互換性のないテキストフィールドは選択できません。設定エラーが発生した場合、保存時に明確なエラーメッセージが表示されるため、誤った設定を防止できます。

5 Whys Analysis: User Experience Improvements

5 Whys Analysis ツールがアップグレードされ、Why カードを編集して保存する際に、よりシームレスで直感的なエクスペリエンスが得られます。カードの保存中はフィールドは使用できません。新しい変更が行われるまで、Saved インジケータが表示されます。

Generate Document from Word Formatted Output

このリリースでは、Generate Document from Formatted Output アクションが機能強化されました。管理者は、Microsoft Word (*.docx) ファイル形式または PDF ファイル形式で作成された Formatted Output Template を選択できるようになりました。

Vault は、Generate Document from Formatted Output アクションが実行され、Formatted Output Template が Microsoft Word ファイル形式であることを検出すると、プレースホルダードキュメントを作成します。アクションの設定では、生成されたドキュメントへの参照を格納するレコード上のフィールドを指定します。Formatted Output が生成されると、Vault はプレースホルダードキュメントをアップバージョンし、Formatted Output コンテンツを追加します。Download Source 権限を持つユーザは、ドキュメントのソースファイルをダウンロードできます。View Content 権限を持つユーザは、ドキュメントの表示可能なレンディションを表示およびダウンロードできます。

アクションがユーザアクションとして実行された場合、アクションを実行したユーザには、ドキュメント生成が進行中であることを示す通知バナーが表示されます。

管理者が Microsoft Word Formatted Output Template を使用してこのアクションを設定する場合、アクションがエントリアクションとして実行されたときに、レコードのどのロールが完了通知を受信するかをオプションで定義することもできます。

特定されたロールのいずれかにユーザが手動で割り当てられると、そのユーザには完了通知が送信されます。手動で割り当てられたユーザは、Quality チームを使用するか、共有設定を通じて直接レコードのロールに追加されます。動的アクセス制御 (DAC) 設定を使用して自動的にロールに割り当てられたユーザには、完了通知は送信されません。

Formatted Output の生成が成功し、アクションで Microsoft Word Formatted Output Template が使用された場合:

• アクションがユーザアクションとして実行された場合、完了通知は開始したユーザに送信されます。
• アクションがエントリアクションとして実行された場合、完了通知は、ライフサイクル状態の変更をトリガーしたユーザと、アクションの設定でロールに手動で割り当てられたユーザに送信されます。

Formatted Output の生成が失敗し、アクションで Microsoft Word Formatted Output Template が使用された場合:

• 完了通知には、生成が失敗した理由を示すエラーメッセージが含まれます。
• アクションがユーザアクションとして実行された場合、完了通知は開始したユーザと Vault 所有者に送信されます。
• アクションがエントリアクションとして実行された場合、完了通知は、ライフサイクル状態の変更をトリガーしたユーザ、Vault 所有者、アクションの設定でロールに手動で割り当てられたユーザに送信されます。

アクションが PDF Formatted Output Template を使用するように設定されている場合、完了通知は送信されません。

Generate Document from Formatted Output アクションが、Vault システムアカウントとして実行されるようになりました。さらに、Microsoft Word Formatted Output を使用すると、アクションは非同期的に実行されます。そのため、顧客は、後続のステップが発生するまでに Formatted Output ドキュメントが存在することを前提とするプロセスを設定すべきではありません。これには、既存のビジネスプロセスの変更が必要になる場合があります。これがプロセスに影響を及ぼすかどうか、また適切な調整方法を評価するうえでサポートが必要な場合は、Veeva の担当者にお問い合わせください。

Field Corrective Action Enhancements

このリリースでは、Veeva QMS 内の Field Corrective Actions 管理ソリューションにいくつかの主要な機能改善が加えられ、追跡された Safety Notice を新しいタイプの Product Action として送信する機能や、Complaints の管理に使用できるものと同様の、設定可能なメール送信元アドレスのサポートが追加されました。

Safety Notice は、所有者に通知する必要があるものの特定の医療機器を返却する必要がない場合に最適です。これらの通知は External Notification の追跡メールと同様に追跡され、メール送信元設定をサポートして組織が送信または配信の失敗を認識できるようにします。

さらに、FCA-Lot レコードに関して Product / Material Tracking が更新され、Product Return アクションおよび Service Request アクション向けに簡素化されました。どちらのタイプのアクションも、完了状態ではない FCA-Lot レコードの識別に関する自動化をサポートするようになりました。外部の Consignees の場合、Vault は、Product Return または Service Request アクションが示された FCA-Lot レコードに対して、Product / Material Tracking レコードを作成または更新します。どちらのタイプのアクションでも、内部の Consignees の場合、Containment レコードが自動的に作成されます。この自動化では、アクションが指定されていない FCA-Lot レコードがスキップされます。

QRM: Probability Support for Hazard & Harm Analysis

ISO 14971 をサポートするために、リスクマトリックスは、そのような状況から生じる Probability of a Hazardous Situation (P1) と Probability of Harm (P2) の定義をサポートできるようになりました。これらの値は、リスクマトリックスの一部として、Dimensions 選択リストフィールドの Severity、Probability、Occurrence の新しいエントリを介して設定され、リスクの全体的な重大度スコアの計算の一部となるようになりました。

Risk Builder も更新され、アセッサーが P1 と P2 の両方をリスクの一部として適切に示すことができるようになりました。

Risk Matrices と Risk Assessments の両方で、この機能を導入する際に組織が参照できるように、標準レイアウトの新しい更新も行われています。

QRM Enhancements: Reorder Risks, Heat Map Ordering

このリリースでは、リスクを扱う際のユーザエクスペリエンスにいくつかの大きな変更が導入されています。このリリースより前は、リスクの順序付けを活用する場合で、既存のリスクの順序を変更する必要がある場合は、Record Details ビューで両方のリスク (または影響を受けるすべてのリスク) を開き、それぞれの Risk Order フィールドを手動で変更しなければなりませんでした。Risk Builder で新しい Reorder 機能が利用できるようになり、リスクをドラッグアンドドロップして希望の順序に並べ替えることができます。

管理されているリスクの種類が論理グループの一部である場合 (FMEA など)、直感的な UI により、簡単なジェスチャでそれらのグループ内で順序を変更できます。考慮事項として、この自動番号付けの変更により、既存のリスクの Process Step (または論理グループ) を Risk Order フィールドで変更すると、リスクの新しい Risk Order がゼロ (0) に設定されます。これにより、アセッサーが新しい構造でリスクを簡単に見つけて並べ替えることができるようになります。なぜなら、Process Step への変更が、ソースとデスティネーションの両方の Process Step の既存のリスクのリスク順序に大きな影響を与える可能性があるためです。

さらに、リスクヒートマップを使用している組織向けに、2D および 3D ヒートマップの Y 軸の順序を変更し、最も重要なエントリがマップの上部に表示されるようにすることで、生成されたヒートマップの読みやすさが向上しました。この並べ替えは、リリース後に生成 (または再生成) されたすべてのヒートマップに自動的に適用されます。

QMS Standard Application Enhancements

この機能には、標準の Veeva QMS アプリケーションに対する次の機能強化が含まれています。

標準 QMS オブジェクト

Veeva は、標準オブジェクトをそれがサポートするアプリケーションに合わせて調整します。これにより、ライセンスを付与されたユーザは、Veeva アプリケーションの利用に必要なすべてのオブジェクトに完全にアクセスできるようになります。また、Veeva アプリケーションに含まれていない不要なオブジェクトがユーザに表示されないようにします。

このリリースでは、いくつかの標準オブジェクトが更新され、Veeva QMS アプリケーションのユーザがアクセスできるようになります。詳細については、25R2 Quality Data Model Documentation スプレッドシートをご覧ください。このドキュメントは、25R2 リリース前に Veeva QMS Connect コミュニティに公開される予定です。

Related Event オブジェクトの標準レイアウト

Related Event オブジェクトには、関係の性質など、ソースレコードの関連レコードに関する詳細が表示されます。このリリースでは、情報の表示方法を制御するレイアウトルールを含む、Related Event オブジェクトの標準的なベストプラクティスレイアウトが導入されています。標準レイアウトは非アクティブであり、変更できませんが、顧客はそれを独自の Vault にコピーできます。

生成された QMS ドキュメントの標準ドキュメントタイプ、ドキュメントフィールド、およびライフサイクル

Veeva QMS アプリケーションには、QMS レコードの情報からドキュメントを自動的に生成する機能が含まれています。このリリースでは、QMS によって生成されたドキュメントの標準ドキュメントタイプ、フィールド、およびライフサイクルが導入されています。これらの標準コンポーネントを追加すると、QMS で生成されたドキュメントに対応するために QualityDocs の設定を変更する必要がなくなるため、Veeva QualityDocs を使用する Veeva QMS の顧客にメリットがもたらされます。

標準ドキュメントライフサイクル

このリリースでは、QMS Generated (qms_generated__v) 標準ライフサイクルが導入されています。ライフサイクルはデフォルトでは非アクティブですが、管理者がアクティブにすることができます。

標準ドキュメントタイプ

このリリースでは、QMS Generated Document (qms_generated_document__v) 標準ドキュメントタイプが導入されました。これには、Quality Events、Audits、Issue Escalations、および SCAR プロセスの標準サブタイプと分類が含まれています。詳細については、25R2 Quality Data Model Documentation スプレッドシートをご覧ください。このドキュメントは、25R2 リリース前に Veeva QMS Connect コミュニティに公開される予定です。

新しい標準ドキュメントタイプ、サブタイプ、および分類では、QMS Generated 標準ライフサイクルが使用されます。これらはデフォルトでは非アクティブですが、管理者がアクティブにすることができます。

標準ドキュメントフィールド

QMS Generated Document をそのソース QMS レコードに関連付けるには、ドキュメントにフィールドが必要です。QMS ドキュメントを生成する機能は、生成されたドキュメントのフィールドに、ソース QMS レコードを指す参照を自動的に入力します。このリリースでは、この関係を保存するために、QMS Generated Document のサブタイプと分類で使用される標準の共有ドキュメントフィールドが導入されています。すべてのフィールドはデフォルトでは非アクティブですが、管理者がアクティブにすることができます。詳細については、25R2 Quality Data Model Documentation スプレッドシートをご覧ください。このドキュメントは、25R2 リリース前に Veeva QMS Connect コミュニティに公開される予定です。

QMS Generated Document の標準オブジェクトフィールド

ソース QMS レコードを QMS Generated Document に関連付けるには、QMS レコードにフィールドが必要です。QMS ドキュメントを生成する機能は、ソースレコードのフィールドに、QMS Generated Document を指す参照を自動的に入力します。このリリースでは、この関係を保存するために標準 QMS オブジェクトに標準フィールドが導入されています。すべてのフィールドはデフォルトでは非アクティブですが、管理者がアクティブにすることができます。詳細については、25R2 Quality Data Model Documentation スプレッドシートをご覧ください。このドキュメントは、25R2 リリース前に Veeva QMS Connect コミュニティに公開される予定です。

QMS プロセスの標準組織フィールド

多くの標準的な QMS プロセスでは、Organization オブジェクトを使用して、レコードの Owning Facility を識別します。このリリースでは、いくつかの標準 QMS オブジェクトに対して標準の Owning Facility フィールドが定義されています。詳細については、25R2 Quality Data Model Documentation スプレッドシートをご覧ください。このドキュメントは、25R2 リリース前に Veeva QMS Connect コミュニティに公開される予定です。

QMS プロセスとドキュメントを関連付ける標準のシンプルな結合オブジェクト

顧客が QMS レコードからドキュメントへの参照を作成する必要がある場合は、たいてい、ドキュメント参照フィールドを含むカスタムオブジェクトを作成します。Vault は、パフォーマンス上の理由から、ドキュメントに対するカスタム受信関係の数を制御します。したがって、このリリースでは、標準の QMS プロセスをドキュメントに関連付けるためのいくつかの標準的な単純な結合オブジェクトが導入されています。これにより、一般的に必要となるカスタム関係を作成する必要がなくなり、顧客の Vault のパフォーマンスが維持されます。詳細については、25R2 Quality Data Model Documentation スプレッドシートをご覧ください。このドキュメントは、25R2 リリース前に Veeva QMS Connect コミュニティに公開される予定です。

Veeva Quality Study の Protocol Title フィールドの長さを増やす

このリリースでは、Veeva Quality Study (study__v) オブジェクトの Protocol Title (protocol_title__v) フィールドが 128 文字から 500 文字に増えました。このフィールドは、Veeva Clinical の Protocol Title フィールドのデータを使用して、Clinical Operations から Quality へのコネクションによって入力され、最大 500 文字まで許可されます。

Recurrence Check: Add Criteria VQL for Related Objects

このリリースでは、関連する各オブジェクトに Criteria VQL サポートを導入することで、Quality Record Check 設定機能が強化されました。管理者は追加のフィルタリングルールを適用して、関連オブジェクトの一致基準を絞り込むことができるようになりました。

これは、ユーザが特定のフィールド値や関連オブジェクトのその他の基準に基づいて繰り返しを検索するシナリオで特に役立ち、繰り返し検出の精度と制御が向上します。

Quality Record Check 作成の詳細については、Vault ヘルプをご覧ください。

Recurrence Check: Record Check Result Object Control

このリリースでは、管理者が Record Check Result オブジェクトのページレイアウトに追加できる新しいオブジェクトコントロールが導入されました。このコントロールは、既存の Filters、Fields Searched、および Matching Search Terms の代替として設計されています。また、Print Record (Download to PDF) 機能もサポートしており、より合理的で一貫したユーザエクスペリエンスを提供します。

Duplicate Check: Do Not Allow Fields With a Time Subtype as Search Fields

この機能により、管理者が Duplicate Check の Search Fields コンポーネントを設定する際に適切なエラーが発生し、適切な処理が行われるようになります。このリリース以前は、管理者は Time サブタイプのフィールドを Search Field として設定できましたが、このデータ型はサポートされておらず、チェックの実行時に予期しない結果が生じていました。今回のリリースでは、管理者がこれらの設定で Qualityrecordcheck コンポーネントを保存しようとすると適切な検証エラーが表示されるようになりました。これにより、サポートされていない設定が保存されるのを回避できます。

Surveillance

QMS & VPS: Reportability for Domestic Versus Foreign Incidents

レポート可能性評価の決定に携わる Veeva Product Surveillance および QMS の顧客は、国内で発生した Incidents と国外で発生した Incidents を組織が報告すべき期間について、異なる期間をサポートできるようになりました。このリリース以前は、組織はレポートプロセスを完了するために、許容されるタイムラインの差を手動で追跡する必要がありました。このリリースでは、Reporting Requirement 選択リストが更新され、Country of Incident 選択リストの値ラベルが Domestic Incidentsに変更され、Foreign Incidents をサポートする新しいエントリが導入されました。レポート可能性要件をすでに活用している組織は、以前に Country of Incident の値を使用していた既存のレポート可能性ルールを処理するための措置を講じる必要はありません。組織は、レポート可能性設定に行を追加して、Foreign Incidents に使用する期間を定義できるようになりました。Domestic Incidents と Foreign Incidents に同じ期間を適用するレポート可能性要件を持つ組織は、引き続き Global Incidents オプションを活用できます。

VPS: Japan AE Reporting Custom UI Enhancements

Veeva QMS の MedTech 有害事象レポート管理ソリューション内の日本 PMDA レポートをサポートするために、Adverse Event Report ワークフローの UI にいくつかの機能強化が加えられ、さまざまなコードの管理と操作が容易になりました。

Health Effect Codes、Device Problem Codes、Component Codes、および nvestigation Codes の管理に変更が導入されています。Adverse Event Report のこれらの各領域が更新され、ユーザが適切なコーディング用語集からコードを選択できるようになり、該当する場合は第 2 レベルのコードの依存関係を適用するようになりました。

Investigation Codes には追加の処理が施され、Investigation Code の Type の選択によって Finding Codes とそのサブコード、および Investigation Conclusion Code のサブコードで使用可能なオプションが決定されるようになりました。

これらの変更は、エクスペリエンスを合理化し、Adverse Event Report を作成する際のコード選択のエラーを大幅に削減することを目的としています。

VPS: Japan AE Reporting Health Authority Validations

このリリースでは、日本の PMDA に提出可能な Adverse Event Report に記載されている 50 を超えるフィールドに自動フィールド検証が導入されています。これらの検証は、FDA eMDR および EU MIR Adverse Event Reports に対する既存のサポートと同様に、Vault UI で適用されるフィールドにインラインで表示されます。このリリース以前は、組織は Adverse Event Reports 用の XML ファイルを生成し、提出を試み、提出内容に欠落した値や不適切な形式の値があるかどうかを把握する必要がありました。

これらの検証は、日本の PMDA に提出可能なすべての Adverse Event Reports に対して、設定なしですぐに利用できます。

VPS: AER Configurability

このリリースでは、管理者向けの VPS: Adverse Event Report Configurations コンポーネントが導入され、ユーザが有害事象レポート作成エクスペリエンスのさまざまな部分をどのように処理するかをレポートタイプごとに管理したい組織は、より詳細に制御できるようになります。これにより、ユーザが Adverse Event Reports の操作の一環としてソースレコードを直接更新する方法を制御したり、その動作を禁止して、代わりにユーザが意識的にソースレコードにアクセスし、そこで直接ソースデータの変更を行うように要求したりできるようになります。たとえば、このリリースより前のバージョンでは、Complaint のメタデータを編集する権限が割り当てられているユーザが、AER で作業していて、Complaint に保存されているデータフィールドを変更しようとすると、Vault によってその変更が直接 Complaint レコードに自動的に複製されていました。新しいコンポーネントを使用すると、管理者はレポートタイプごとに、AER への変更と基礎となるオブジェクト間の自動データ交換をオプトアウトすることを選択できるようになりました。

VPS: Consolidation of Complaint Details

Veeva Product Surveillance 内のデータ保存、アクセス、およびレポート可能性モデルを簡素化するために、Vault では、デバイス関連の追加の Complaint Details が Complaint Details および MedTech Complaint Details オブジェクト間で分割されなくなります。代わりに、Vault は、Complaint および Adverse Event オブジェクトへの標準化されたマッピングで、すべての追加の Complaint Details を合理化します。Medtech Complaint Details オブジェクトレコードに保存されている既存のレコードデータはそこに保持されますが、 Medtech Complaint Details レコードが関連付けられていない Complaint レコードの新しくキャプチャされるデータはすべて、新しいモデルでキャプチャされます。

VPS: Product Master Data Automation

このリリースでは、Veeva QMS で管理されるいくつかのタイプの Adverse Event Reports に対して新しいアプリケーション設定が導入されています。Use Regional Product Attributes オプションは、FDA eMDR、EU MIR、カナダ保健省、および日本の PMDA Adverse Event Reports の Brand Name、Common Device Name、Device Description などの国固有または地域固有の製品属性を必要とする組織向けであり、レポートタイプごとに利用できます。

有効にすると Adverse Event Report フォームに新しいエントリが追加されます。これは、組織が管理するマスターデータセットから取得した、地域固有バージョンのメタデータを表します。地域データは、基礎となる Complaint の指定されたデータと一致する、Regional Product Attributes オブジェクトの行から自動的に選択されます。

このフラグはオプションであり、特定のタイプの Adverse Event Report に対して有効にされない限り、Veeva QMS Adverse Event Report ソリューション内の製品データマッピングの動作は影響を受けません。

VPS: Adverse Event Report Improvements

このリリースで FDA eMDR Adverse Event Report のセクション D9 が更新され、Device Available for Evaluation に対するユーザの回答に基づいた値がより明確に保存されるようになりました。具体的には、値が Destroyed または No の場合、フィールドは一律に No に設定されます。値が Returned to Manufacturer/Importer または Yes の場合、フィールドは一律に Yes に設定されます。選択した値がその他である場合は、すべてフィールドは空白になります。

この変更は、変更された eMDR を次に保存した時点で有効になります。

Batch Release

Change State Configuration

この機能では、Change Control ライフサイクル状態が Batch Dispositions によって監視されるように設定するため、Approved 状態タイプに関連付けられた変更に限らず、あらゆる状態の変更を監視できるようになります。

現在、Approved (approved__v) 状態タイプに関連したライフサイクル状態の変化を監視しています。この機能により、Check Requirement で設定可能になるため、あらゆる状態の変更を監視できるようになります。

Batch Disposition Check Requirement の Change Control State フィールドには、Change Control ライフサイクル状態のリストが表示されます。ユーザは一度に複数の状態を選択できます。Vault では Check Requirements オブジェクトタイプが Quality Event Type であり、バッチ Quality Event が Change Control であり、表示するように設定されている場合にのみ、このフィールドを評価します。

Disposition Dependency

複数の Batch Dispositions Plans を持つバッチ材料には、他の処分決定が下されるまで他の処分決定をブロックする依存関係が存在する場合があります。たとえば組織では、バッチの GMP Batch Disposition が承認されるまで、すべての市場出荷の決定をブロックする場合があります。

製造施設固有の計画

製造施設固有の計画

Batch Disposition Plans を製造施設に関連付けられるようになりました。これらのプランを製造施設に関連付けることで、当該プランを、それらの施設で製造された対象バッチで使用するものとして指定します。これは、製造施設固有の要件を満たす必要がある場合に役立ちます。

ドキュメントチェックのサブタイプと分類のサポート

ドキュメントの Batch Disposition Check を作成するときは、ドキュメントの種類を指定するだけでなく、ドキュメントのサブタイプと分類も指定できます。これにより、監視するドキュメントをより細かく指定できます。

バッチのロールアップフィールド

Batch Dispositions と Batch Disposition Checks に関するレポートを改善するために、3 つの新しいブール型フィールドが導入されました。

• Item State Check: Batch Disposition Check のすべてのアイテムが Closed の場合、このフィールドは True に設定されます。
• Check Decision Check: Batch Disposition のすべてのチェック決定が Compliant の場合、このフィールドは True に設定されます。
• Check State Check: Batch Disposition のすべての Batch Decision Checks が Complete の場合、このフィールドは True に設定されます。

Monitor Documents Not Batch-Specific

この機能により、BSE/TSE ドキュメントなどのバッチ固有ではないドキュメントが Batch Disposition Check に含まれるようになり、処分の決定を下す前にそれらのドキュメントを確認できます。これらのドキュメントは通常すでに完成しているか、定常状態にあります。

この機能を使用するには、Item Requirement Copy フィールドを No に設定します。フィールドが Yes に設定されている場合、または null の場合、Vault では Batch Disposition ごとに Item Requirement ドキュメントをコピーするという既存の動作を継続します。

Disposition Archival Design

この機能では、大容量の環境でパフォーマンスが低下しないように、バッチリリースレコードをアーカイブします。

Closed または Cancelled などの終了状態にある Batch Dispositions が 24 か月を超えている場合はアーカイブされます。Vault では、すべての Batch Disposition、Batch Disposition Check および Batch Disposition Item データを含むバッチに PDF ドキュメントが添付され、Batch Disposition、Batch Disposition Check、Batch Disposition Item および Batch Disposition - Country レコードは削除されます。

Validation Management

Reference Table Support for Requirements & Specifications

25R2 リリースでは、Vault に Requirement および Specification レコード内で直接、参照テーブルを追加および管理する機能が導入されました。この機能強化により、ユーザは要件に関連付けられた表形式のデータを構造化して維持できるようになり、明確さと効率性の両方が向上します。ユーザは、要件ごとに最大 10 列、100 行の参照テーブルを作成できます。表は、標準のスプレッドシートアプリケーションと同様に、ナビゲーションやインライン編集用のキーボードショートカットを含む豊富な編集機能に対応しています。

ユーザは、すべての要件と参照テーブルを含む Validation Entity Version から PDF を生成できます。ユーザが Validation Entity Versionから PDF を生成するときに、要件に参照テーブルが含まれていない場合は、すべての要件が 1 つの表に統合されます。少なくとも 1 つの要件に参照テーブルが含まれている場合、各要件は個別の表にエクスポートされ、対応する要件の直後に参照テーブルが表示されます。ユーザは、参照テーブルが存在する場合はそれも含めて、個々の要件レコードを PDF としてエクスポートすることもできます。

Template Requirements に、参照テーブルを含めて、事前定義された構造を提供することができます。テンプレート内の表をすべて入力する必要はありません。テンプレートから Validation Requirement が作成されると、参照テーブル構造がコピーされます。ユーザは、元のテンプレートのトレーサビリティを損なうことなく、必要に応じて表を変更できます。

この機能はデフォルトでは Validation Management ユーザに表示されず、この機能を使用するには、既存の権限セットの変更などの設定変更が必要です。

Periodic Review for Entities

25R2 では、ユーザはエンティティの Periodic Reviews を作成および管理できるようになります。エンティティを異なる範囲 (システムレビュー、アクセス制御レビューなど) を持つ複数の定期レビューに関連付けることができます。Periodic Reviews は、アドホックまたは定期的に実行することができ (選択したタイプに基づく)、複数のエンティティ (たとえば、生産ラインシステムのレビュー) に関連付けることができます。Periodic Reviews には、ユーザが Periodic Reviews を計画して、期日が近づいたときにのみタスクを開始できるようにし、Periodic Review を完了すると定期アクティビティの次の Periodic Review を自動的に作成する自動化も含まれます。この機能はデフォルトでは Validation Management ユーザに表示されず、この機能を使用するには、既存の権限セットの変更などの設定が必要です。

Display Workflow Task Information on Validation Management Interfaces

25R2 では、テストスクリプトまたはテストプロトコルを作成、実行、確認、または承認するタスクを持つユーザには、テスト作成 UI やテスト実行 UI などの Validation Management インターフェイスを使用するときに、割り当てられたタスクを完了するためのタスクバーが表示されるようになりました。これにより、ユーザはタスクの期限と提供された指示を把握しやすくなります。この機能は、タスクを持つユーザが Vault 内のレコードを確認するときに表示される既存のタスクバーの動作を模倣します。この機能は自動的にオンになります。

LIMS

Quantity Tracking for Stability Studies

このリリースでは、安定性治験の追跡機能が強化され、組織は治験期間全体にわたって製品の数量を管理できるようになりました。

主な変更点:

• 新しい標準フィールド: 安定性治験の数量追跡専用のフィールドが追加されました。
• 計画された保管量と引き出し量: Stability Study Design の一環として、条件と方向ごとに各時点の計画された保管量と引き出し量を追跡します。
• 自動数量更新: 製品がテスト用に引き出されると、Quantity Pulled、Quantity Remaining、および Quantity Required for Pending Timepoints フィールドが自動的に更新されます。
• 在庫管理: 計画された保管と実際の保管を自動的に追跡し、各時点および各保管条件/方向における製品の在庫状況を明確に把握できるようにします。これにより、テストや潜在的な再テスト、治験の延長に十分な材料を確保できます。

System Suitability Testing

この機能により、組織は、システム (機器、装置) が使用に適していること、すなわちサンプルテストの前または最中に期待どおりの結果が得られ、システムが基準を満たしていることを確認できます。

Test Definitions には、Quality Control Sample のさまざまなタイプ (System Suitability Sample、Reference Standard、Blank など) の Variations を含めることができます。各 Quality Control (QC) Sample には独自の受入基準があり、テスト実行中にこれらの基準が評価されます。QC サンプルが基準を満たしていない場合は、承認されたユーザが次の手順 (実行の無効化や再テストなど) を決定できるワークフローが自動的に起動します。

さらに、この機能により、Test Set を無効にすることもできます。

Stability Timepoint Zero: Use Batch Results

この機能により、臨床検査技師は、Batch Release Test の結果を Initial Timepoint (T0) Stability Study の結果に再利用できます。そのため、バッチのリリースプロセスのテストを使用して T0 基準を評価できる場合、不要な再テストにかかる時間と労力を節約できます。

Test Definition: Operational Criteria

この機能により、各 Test Definition に対して Test Set Result (メソッドパラメータ) を定義できます。これらの結果は Test Set 全体に対して固有であり、独自の Test Definition Criteria を持ちます。Set Result はテスト実行中に評価され、結果が基準を満たしていない場合はフラグが付けられます。

Change Analysis Enhancements: Bulk Update References to Latest Versions

この機能は、Spec Data レコードが Sample Plan または Test Definitions の古いバージョンを参照している可能性があるインスタンスをユーザが自動的に解決する方法を提供します。

Change Analysis Enhancements: View Dependencies

この機能は、検証と承認の妨げとなっているその他の Change Analysis レコードのビューを提供することで、Re-merge Change Analysis ユーザアクションを強化します。依存関係にあり、まだワークフローに含まれていない Change Analysis レコードが事前に選択されます。

Change Analysis: Re-Merge Change Analysis

この機能では、既存のワークフロー Envelope に Change Analysis レコードを追加できる新しいユーザアクションが提供されます。すでにワークフロー内にある Change Analysis レコードは追加できません。

Convert Controlling Lookup Fields to Reference Fields

この機能は、当初 25R1 で導入されました。依存フィールドを制御するためにルックアップフィールドが時間内に更新されない問題に対処するために、データモデルに新しいフィールドを導入しました。

以前は、この機能は Veeva サポートによって有効化される必要があり、すべてのシステムロジックが更新されて新しいフィールドを参照し、それらの新しいフィールドを入力するための自動データ移行が促進されていました。新しいフィールドに完全に切り替えるには、お客様固有の追加設定 (レイアウト、レポートなど) が必要です。

25R2 以降、この機能はすべての Vault で自動的に有効になります。当社チームは皆様と協力してこの準備に取り組んでまいりました。ご質問や追加サポートのご要望がある場合は、Veeva サポートまでお問い合わせください。

Stability: Pull Window & Pull Compliance

この機能により、ユーザは、早期プルウィンドウと遅延プルウィンドウの両方を選択でき、それぞれ異なる値を持つことができます。現在、システムは、上限プルウィンドウと下限プルウィンドウが異なるシナリオをサポートしていません。この更新には Study Design 側と Study 側の両方に適用される Review Study Overview UX の変更も含まれており、早期プルウィンドウと遅延プルウィンドウを組み込みます。

さらに、この機能によって、Pull Compliance for Lab Samples を追跡する機能が導入され、ユーザは指定されたプルウィンドウ内でサンプルが取得されたかどうかを監視できるようになります。

Stability: Standardization of Unit of Measure

この機能により、Unit of Measure オブジェクトに、事前定義された値を持つ新しい標準 picklist フィールドが導入されます。システムは、この選択リストを参照して治験開始時に時間ベースの計算を行うようになりました。さらに、標準化された選択リストを使用して、Study Design UI と Study UI の両方で、時点を左から右へ昇順に自動的に並べ替えます。

Stability: Study Schedule User Interface Enhancements

Study Schedule UI が Study Design と Study に対して更新されました。以下の変更が行われました:

• LIMS の他の部分と一致するようにカラースキームが更新されました。
• Test 専用のセクションがあります。Schedule セクションのヘッダーが削除されました。
• Filter アイコンが削除されました。
• Storage Counts セクションが削除されました。
• 左のパネルが折りたたみ可能になりました。
• Timepoint Hover Display が更新されました。

Calculation: Log Function Support

この機能により、数式/式を作成するときに 2 つの新しい関数が追加されます。log 関数は任意の有効な底（例：底が10の場合）で指定できますが、ln 関数は自然対数の底として e を想定します

Test Set: Enhanced Ways to Search & Select Samples

この機能により、サンプルの検索と選択に次の機能強化が追加されます。

テスト実行:

• 検索ボックス、バーコード入力、バーコードのフィルタリング機能を含む、Sample Select ダイアログを追加
• 左パネルのレコードリストを更新
• 右パネルの選択されたレコードを更新
• ダイアログ名を Sample Set に更新

サンプル結果の入力:

• ダイアログ名を Sample Set に更新

Display Expected Amount & Unit for Inputs

テスト実行ユーザインターフェース (UI) に、Inputs の予想量と単位が表示されるようになりました。

Support Quality Events & Test Sets in Lab Investigations

この機能により、Quality Event オブジェクト内での Lab Investigations の作成のサポートが拡張されます。管理者は、スタンドアロンの Lab Investigations を作成するか、Quality Event オブジェクト内で Lab Investigations を作成するかを選択できます。さらに、テスト実行中に問題が発生した場合、Test Set から Lab Investigation Request を作成できます。

Test Set Contains the Test Definition It Is Associated With

Test Set が作成されると、Test Definition が Test Setにスタンプされるようになりました。

All Test Set & Lab Test Result Object Records Updated with New Field Values

System Suitability および Operational Criteria 機能の一部として、以下のオブジェクトレコードが自動的に更新されました。

• Test Set: Invalid フィールドを false に設定
• Lab Test Results: Step Definition に参照を設定

Simplified Aliquot Configuration

この機能により、Select Sample アクションで Aliquot Sample アクションを参照できるようになります。このトレーサビリティにより、特定のアリコートアクションの適切な選択アクションにサンプルを自動的に一致させることができます。

Stability Study Export: Not Expected Result Value Updated

安定性治験で予期されない結果については、エクスポートファイルでは N/A ではなく – で示されます。

Generate Tests Logic Enhancement or Avoid Duplicates When Generating Tests

システムでは Generated フィールドの値をチェックしてから、Test を作成するようになりました。False の場合、Vault では Tests を生成します。True の場合、Vault では Tests を生成しません。これにより、重複したテストが作成されるというまれな競合状態を回避できます。

Increased Sample Quantity Limit for Test Sets

さまざまなサンプルで Test Set に最大 100 個の Tests を含めることができるようになりました。

Do Not Notify Vault Owners on Design Data Portability File Failed to Import

Design Data Import ジョブが Errors Encountered で終了した場合、Vault Owners はこれまで「AsyncOperation did not finish successfully」という通知と、問題の詳細が網羅された、ジョブ自体からの通知の 2 つのメールを受け取っていました。最初のメールは送信されなくなりました。

Lab Criteria Evaluation Records Created on Test Creation

以前は、Spec Execution レコードが開始されると、Test が作成されていなくても、Lab Criteria Evaluation レコードが作成されていました。今後は、Lab Criteria Evaluation レコードは、その Test が作成された場合にのみ作成されます。

Lab Location Records That Meet Certain Conditions Can Be Deleted

以下の条件をすべて満たしている場合、Lab Locations とその関連レコードを削除できます。

• Lab Location (または Hierarchy Change 参照を介した関連する Location) が、Asset、Consumable または Lab Sample に割り当てられていない。
• Lab Locationの親が、最初に作成されてから一度も変更されていない。
• Lab Location に子が存在する場合、そのすべての子は前述の制約を満たしている必要がある。

Refined Revision Tracking for Results

この機能は、Test Result に Revision を設定するためのロジックを更新します。当初失敗した計算結果が後で正常に計算された場合、または初期値のない手動結果に後で初期値が与えられた場合、訂正は記録されません。

Initiate Spec Execution Can Use Spec Data Mapping Records in the Standard Active State

Spec Execution が作成される場合 (Batch がログに記録される場合)、使用される Spec Data は、以下の条件を満たす Spec Data Mapping に基づきます。

• カスタムライフサイクル状態 (既存) のステータスが Active の Spec Data Mapping レコード
• Standard Active 状態の Spec Data Mapping レコード

Increased Sample Quantity Limit for Test Sets

さまざまなサンプルで Test Set に最大 100 個の Tests を含めることができるようになりました。

Version History Section for Test Definition-Document Records

特定の Test Definition-Document レコードについて、ユーザはそのレコードの以前のバージョンを表示できるようになりました。

Data Model: Dynamic Access Control Property is No Longer Editable for Spec Data Criteria Set

Spec Data Criteria Setを含む設計データオブジェクトのセキュリティは、アプリケーションセキュリティによって自動的に実行されます。Spec Data Criteria Set には、設定可能なセキュリティはもう含まれていません。

Remove Unused Data Model & Components from LIMS Vaults

他の Quality アプリケーションに固有で、LIMS では使用されない特定のデータモデルとコンポーネントは、すべての LIMS Vault から削除されました。

Regulatory

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

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

• Quality-RIM Connection: Event Auto-Create Per Change Control & Product Family
• Quality-RIM Connection: Product Data Enhancements
• RIM-Clinical Operations Connection: Regulatory Tracking for Clinical Trials
• RIM-Clinical Operations Connection: Update to CrossLink Behavior to Respect Sites

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

Health Authority Interaction Extraction Updates

このリリースでは、Health Authority Interaction 抽出機能を使用して最大 500 語を抽出できるようになりました。さらに、Health Authority Interactions ドキュメントパネルに対して、いくつかの小さな UI 更新が行われました。

• 削除アイコンは常に表示されるのではなく、カードの上にマウスを置いたときにのみ表示されるようになりました。
• HAQ または Commitment のいずれかの抽出のみが有効で、両方のオブジェクトが有効というわけではない場合、オブジェクトドロップダウンは無効になります。

RIM Bot: Multilingual Model

この機能は、英語以外の言語のドキュメントのトレーニングと自動分類をサポートすることで、RIM Bot の適用範囲を拡大します。30 以上の言語がサポートされています。この機能は、25R2 ではサポートによる有効化が必要ですが、将来のリリースでは自動的にオンになる予定です。

RIM Registrations

IDMP Data Model Updates (IG v2.2)

IDMP データモデルと出力生成アルゴリズムは、EMA の EU IDMP 実装ガイド、バージョン 2.2 および 2.3 の第 2 章で導入された変更を反映するように更新されました。この EMA の更新は主に出力構造に影響するもので、既存のエントリオブジェクトとフィールドに対する変更は軽微ですが、「Package PMS ID」フィールドが追加されたことには注意する必要があります。

出力構造のこの変更を組み込むために Registrations に実装された変更には、製造の詳細を Medicinal Product Element オブジェクトから新しい個別の Manufacturer Element に移動する処理が含まれます。Vault はこれを次のように参照します。

• Medicinal Product Element を使用して、関連する製造業者の概要を参照する。
• Manufactured Item Ingredient Element を使用して、特定の製造責任をリンクする。

IDMP ビューアはこれらの変更を自動的に反映します。

XEVMPD Validation Enhancements

この機能は、新しい許容可能な認証ステータス (AP.12.3)「有効 - 国内段階保留中」を組み込むことにより、XEVMPD データ検証を EMA の最新 (2025 年 1 月) XEVMPD 3.II ガイダンスに合わせて更新します。このステータスは、関係加盟国 (CMS) でまだ評価中である間に、相互承認 (MRP) または分散手続き (DCP) に基づいて参照加盟国 (RMS) によって認可された医薬品に適用されます。

市販医薬品の XEVMPD データの提出と管理を担当するユーザは、検証エラーを受け取ることなく、この認証ステータスを正確に反映できるようになり、提出物が最新の EMA 要件に準拠していることを保証できます。更新された検証ルールは、データ集約中にこの新しい用語を自動的に認識します。

この新しいステータスを有効にするには、管理者は既存の Vault に新しい Controlled Vocabulary レコードを追加する必要があります。検証エラーの動作の更新は、リリース時にすべての環境で自動的にオンになります。

EUDAMED UDI Market Information Updates: UDI Submission Generation

この機能により、ユーザは EUDAMED に登録されている市場情報を更新するための UDI サブミッションを生成できるようになりました。これらのサブミッションは EUDAMED に手動でアップロードする必要があります。この機能には、将来的に EUDAMED へのコンテナパッケージの提出をサポートする場合に備えたデータモデルの更新も含まれています。

主なハイライト

• 市場情報提出用の新しい専用 UDI サブミッションタイプを RIM で有効にすると、EUDAMED に手動でアップロード可能な市場情報更新サブミッションを生成できます。
• RIM により、市場情報更新用の EUDAMED UDI サブミッションが仕様に準拠して生成され、関連する市場情報が組み込まれます。これには、新しい市場と、関連する登録に基づく既存の市場の開始日/終了日の変更が含まれます。

このリリースにより、EUDAMED の市場情報要件の複雑さに完全に準拠できるようになります。今後のリリースで、UDI サブミッションビューアを使用して市場情報のサブミッションを確認し、RIM から EUDAMED に直接送信できるようになる予定です。

UDI Submission Support for Multiple Products with the Same Basic UDI

この新しい Veeva Registrations 機能により、各 Product に固有の Basic UDI を設定する必要がなくなり、RIM で製品を定義する際の柔軟性が向上し、単一の UDI サブミッション内に同じ Basic UDI を共有する複数の製品の情報を含めることができるようになります。

重要な機能の有効化と考慮事項

この強化された機能を活用するには、次の点を考慮してください。

1. Enable enhanced UDI attribute locations 設定を有効にする必要があります。
2. 同じ Basic UDI を持つ複数のレコードを許可するには、Device Identifier オブジェクトの命名パターンを更新する必要があります。
3. 欧州連合の Marketed Device Registrations の Registration Scope は Marketed Product Group に設定する必要があり、同じ Basic UDI を共有するすべての製品は、同じ欧州連合のレジストレーションおよび関連国のレジストレーションに含める必要があります。
4. ユーザアクセス管理は重要です。ある製品に対する UDI サブミッションを生成するためのアクセス権を付与されたユーザが、同じ Basic UDI と UDI-DI を持つ関連パッケージを共有する他のすべての製品に必要なアクセス権を持っていることを確認します。そうしないと、データのレジストレーションが不完全になる可能性があります。
5. Basic UDI-DI が 300 を超えるレジストレーションでは、同じ Basic UDI-DI を持つ製品が複数の UDI サブミッションに分割されている場合、不整合が発生する可能性があります。

この機能強化により、EUDAMED UDI 規制に準拠しながら、より柔軟に製品データを管理できるようになります。

Create & Manage Event Details: Support for Change Items & Labeling Concepts

このリリースでは、Create and Manage Event Details 機能が大幅に強化され、ユーザがラベルの変更を含むイベント関連の変更をより細かく制御し、効率的に管理できるようになっています。Create Event Details インターフェースから直接、Change Items と Labeling Concepts を Events にシームレスに統合できるようになりました。

変更に Change Items を追加するには、プラス記号をクリックして既存の Change Items を選択するか、ポップアップダイアログで新しい Change Items を作成します。Labeling Concepts を変更に追加して、それを 1 つ以上の Change Items に関連付けることもできます。

主な機能強化:

• Change Item の管理
  • 新しい Change Item の作成について、イベントから 1 つずつ直接作成するよりもはるかに速く、Create and Manage Event Details インターフェース内で作成できます。
  • RIM で作成されたか、Quality-RIM Connection によって作成されたかに関係なく、既存の Change Item をイベントに追加できます。
  • Change Item を使用して、他のイベント詳細の製品およびパッケージ情報を入力し、データ入力を効率化できます。
• Labeling Concept の統合
  • 新しい Labeling Concept を Create and Manage Event Details インターフェース内で直接作成できます。
  • Event Change Item と Labeling Concept の間に多対多の関係を確立し、変更がラベル付けに与える影響を包括的に追跡できます。
• 管理者設定
  • Exclude change item lifecycle states from Create Event Details 設定: 管理者は、ライフサイクル状態に基づいて既存の Change Item の選択可能性を制御できます。
  • Allow creation of change items in Create Event Details 設定: 管理者は、Create Event Details インターフェース内での新しい Change Item の作成を有効または無効にすることができます。
  • イベント変更タイプに Change Item と Labeling Concept の詳細を追加する: 管理者は、Create and Manage Event Details インターフェースで、どのタイプの変更についてユーザに Change Item や Labeling Concept の入力を求めるかを設定できます。
  • 管理者は、Change Item の新しい RIM オブジェクト設定を確認する必要があります。この設定は、Create Event Details でこれらのレコードを作成するときに表示されるフィールドの順序を決定するために使用されます。

利点

• 効率性の向上: Change Item と Labeling Concept を Create Event Details 内で直接管理できるため、クリック回数が減り、イベントの更新にかかる時間が短縮されます。
• データの正確性の強化: Change Item を Labeling Concept にリンクし、Change Item を使用してイベントの詳細を入力することで、一貫性と正確性を確保します。
• 詳細な制御: 管理者は、新しい設定を通じて Change Item の可用性と作成を詳細に制御できるようになります。

この機能強化により、ユーザはイベントをより正確かつ効率的に管理できるようになり、関連するすべての変更とラベル付けの考慮事項が正確に追跡および管理されるようになります。

Create Event Details: Optional Preview

このリリースでは、Create Event Details に Optional Preview が導入されています。25R1 で導入された Optional Preview for Create Related Records と同様に、ユーザはレコードのプレビューを生成するか、Create Event Details から直ちに作成するかを選択できるようになり、レコード作成プロセスにおける柔軟性と制御の向上が期待できます。

プレビューをスキップするには、Generate Preview ではなく Finish をクリックします。

Create Related Records & Splitting Support for Labeling Concept Validation

関連レコードの作成と分割ウィザードの検証が更新され、Labeling Concepts が、それらが関連付けられている Change Items に基づいて適切な Activities にのみ追加されるようになりました。

Vault が関連レコードの作成を通じて Activity Labeling Concepts を作成するときに、ラベル付けコンセプトがイベント変更項目に関連付けられている場合、それらの Change Items の少なくとも 1 つがそのアクティビティに追加するために必要な検証に合格した場合にのみ、Vault は Activity Labeling Concepts を作成します。Activities を分割する場合、Vault には、選択した Activity Change Item に関連する Activity Labeling Concepts と、その Labeling Concepts がアクティブな Event Change Items に関連していない Activity Labeling Concepts のみ表示されます。

主な利点: Activities には、関連付けられている Event Change Items に実際に関係する Labeling Concepts のみが含まれるようになります。これにより、不要な評価が削減され、ローカルのラベル付けの影響がある場所を理解しやすくなります。

考慮事項:

• この機能では、ユーザは、関連レコードの作成またはバンドルを使用して、特定のラベル付けコンセプトを選択し、イベントからアクティビティにコピーすることはできません。ユーザは引き続き変更項目を選択し、ウィザードは新しい多対多の関係を使用して、どのラベル付けコンセプトをどのアクティビティにリンクするかを決定することが期待されます。

• Activities の作成後に Event に対して新しい Labeling Concepts が作成されると、その Labeling Concepts は、後ですべての Activities に関連していない Change Items のサブセットにリンクされる可能性がある場合でも、既存のトリガーによって既存のすべての Activities にプッシュされます。

Create Related Records Validation Enhancements for Change Items

このリリースでは、Create Related Records 機能が強化され、特にパッケージレベルの変更項目が適切なアクティビティに正確に関連付けられるようにすることに重点が置かれています。Vault では、各市場に関連する製品とパッケージタイプに基づいて、Activity Change Item を作成するタイミングを決定するための、より堅牢な検証ロジックが実装されるようになりました。

主な変更点:

• パッケージレベルの変更項目のきめ細かな制御: Event Change Items から Activity Change Items を作成するロジックが更新され、Change Item の Packaging フィールドが考慮されるようになりました。これにより、特定のパッケージタイプに関連する変更が、関連するアクティビティにのみ適用されるようになります。
• アクティビティ変更項目の作成:
  • パッケージの追加または置き換え: Change Item の Packaging フィールドが入力され、Related Change Type が Add、Replacing、または空白の場合、Activity Change Item は、パッケージに関連付けられた製品バリエーション (または複合製品) が、Activity に関連付けられている登録済み製品に含まれている場合にのみ作成されます。
  • 既存のパッケージの更新、回収、または置換: Packaging フィールドが入力され、Related Change Type が Update、Withdraw、または Replacing の場合、Activity Change Item は、特定のパッケージが、Activity に関連付けられている登録済みパッケージにリストされている場合にのみ作成されます。
• 包括的な検証ルール: 検証ロジックでは、Change Item の Product Family、Product、Product Variant、Packaging フィールドが考慮されるようになりました。
• アクティブレコードの検証: 検証プロセスでは、アクティブな Registered 関係レコードのみが考慮されます。
• ユーザによる変更に関する考慮事項: 検証ロジックでは、アクティブな Application 関係レコードだけでなく、プレビュー段階でユーザがアクティブ化することを選択する可能性のある非アクティブな Application 関係レコードも考慮されます。

影響: これらの機能強化により、自動的に作成された Activity Change Items の正確性と関連性が向上し、製品とパッケージ市場の関連性に基づいて正しいアクティビティに変更が適用されるようになります。この結果、次のようになります。

• 手作業による介入とやり直しが減る。
• データの整合性と一貫性が向上する。
• 変更管理プロセスの効率が向上する。

Dynamic Validation Enhancements

このリリースでは、24R3 で導入された Create Related Records 検証プロセスが更新され、イベントとアプリケーション、規制項目、およびサブミッション間の関係を確立する際のデータの整合性が強化されています。これらの更新により、データ生成を効果的に管理するための検証ルールが改善され、導入されます。具体的には、「Add」のイベント変更アクションの一致ルールについてです。

以下の更新が含まれます。

• 新しいルールでは、container__v および device__v の Event Shelf Life レコードまたは Condition レコードからの詳細の追加が検証されるようになりました。これは、packaged_product__v オブジェクトタイプレコードの既存の機能と一致しています。
• 成分アプリケーションの場合、新しいルールにより、Event Active Substance レコードからの詳細の追加が Application Active Substance に対して検証されるようになりました (新規アプリケーションの場合のチェックは除外されます)。
• 非臨床試験/臨床試験と製品ファミリーの関係を検証するためのルールでは、Study オブジェクトの Primary Product Family フィールドの代わりに、Product Family Nonclinical Study および Product Family Clinical Study の関係オブジェクトが使用されるようになりました。
• 添加剤の詳細を追加するときに、製品検証にフォールバックが追加されました。Event Inactive Ingredient’s Product フィールドが空の場合、Vault はマスターデータ内でその添加剤に関連する製品バリエーションを検索し、関連付けられている製品を取得して検証を実行します。
• 有効成分の詳細を追加すると、製品検証が成分アプリケーションにスキップされるようになりました。
• アプリケーションが新規の場合、施設アプリケーションへの施設の詳細の追加に対する検証はスキップされるようになりました。
• 承認の詳細を追加するためのルールでは、Event 関係で利用可能な場合に Product Variant が優先されるようになりました。それ以外の場合は、Product を使用します。

これらの機能強化により、ユーザは関連レコードを作成する際のエラー削減と信頼性の向上というメリットを得ることができます。

Defaulting Local Differences in Product Variants onto Application Relationships

このリリースでは、Veeva RIM の Create Related Records and Bundling 機能が強化されています。この機能強化は、新しいアプリケーション関係を作成するときに、製品バリエーションの地域的な違いの処理を改善することに重点が置かれています。具体的には、新しいアプリケーション関係を作成するときに、基本語と、各製品バリエーションに定義されている国固有の例外に基づいて、Active Substance Name や Strength などの属性の地域的な違いがデフォルトで自動的に設定されるようになりました。

主な変更点

• Active Substance と Inactive Ingredients については、基本語または Product Variant レコードの値を参照することによって、新しいアプリケーション関係のローカル名フィールドと強度フィールドに値が入力され、それらの値が対応する Submission および Regulatory Objective 関係に渡されます。国固有の例外も考慮されます。基本語/値も例外も存在しない場合、これらのフィールドは空白のままになります。これにより、地域的なバリエーションが新しいアプリケーションレコードに正確に反映されます。
• Products については、新しい Application Product Characteristics レコードの Local Manufactured Dosage Form フィールドは、国固有の例外を考慮して、Product Manufactured Dosage Form レコードの優先される管理用語に基づいて入力され、これがローカル関連レコード上の関係にも適用されます。基本語または例外が見つからない場合、このフィールドは空白のままになります。

重要な考慮事項:

• 今回の更新により、成分 (Active Substance または Inactive Ingredient) の Name + Strength と Manufacturing Details の組み合わせから、複数のレコードが表示されるようになりました。これは想定内の動作であり、ユーザは関連するすべての詳細を確認できます。
• 管理者は、Name フィールドの Values must be unique チェックボックスをオフにするか、Event、Application、Regulatory Objective、Submission、Registration 用の Active Substance Inactive Ingredient 結合オブジェクトの名前が、強度や名前が異なる場合でも一意になるような命名パターンを定義することが推奨されます。

これらの更新により、ローカルデータの入力が自動化され、手動入力が削減され、一貫性が向上するため、関連レコードの作成とバンドルのプロセスが効率化されます。この機能は、25R1 で導入された「IDMP Support for Local Differences in Product Variant Attributes」機能のデータモデルの変更に依存しており、自動的に有効になります。

Population of XML ICH DTD / XSD Version on Submissions Created by Bundling & Splitting

アプリケーションで XML ICH DTD / XSD Version フィールドに値が入力されると、バンドルまたはスプリットプロセスによってそのアプリケーション用に作成された新しいサブミッションには、アプリケーションのフィールド値と同じフィールドが入力されます。これにより、バンドルまたはスプリットによって新しいサブミッションが作成されるときに、データの一貫性が確保されます。

Impact Assessment Report Prompt Population from Change Items

Enhanced Change Management を使用しているお客様の場合、この更新により、Event に関連付けられた Change Items からの関連情報が自動的にレポートプロンプトに入力されるため、影響評価プロセスが効率化されます。

Vault では、次の情報に基づいて影響評価レポートプロンプトが自動的に入力されるようになりました。

• 製品プロンプト: Event に関連付けられた Change Item レコードにリストされている Products が入力されます。
• 製品バリエーションプロンプト: Event に関連付けられた Change Item レコードにリストされている Product Variants が入力されます。
• パッケージプロンプト: Event に関連付けられた Change Item レコードにリストされている Packagings が入力されます。

主な利点:

• 効率性の向上: ユーザは、関連する Products、Product Variants、および Packagings を手動で識別して、影響評価レポートプロンプトに追加する必要がなくなりました。
• 正確性の向上: 自動入力により、関連項目を見落とすリスクが軽減され、より包括的な影響評価が可能になります。
• ワークフローの簡素化: 影響評価レポートを作成するプロセスがより直感的になり、作業時間が短縮されました。

この機能強化により、影響を受ける可能性のあるすべての項目が、影響評価プロセス中にすぐに検討できるようになります。

Automated Counts of Total & Completed Events for Change Items

このリリースでは、関連するすべての Events にわたる Change Items の完了ステータスをユーザが明確に把握できるようにする新しい機能が導入されています。Veeva RIM では、Change Item に関連付けられた Total Events の数と Completed Events の数を自動的に追跡して表示します。

Change Item オブジェクトに Total Events フィールドと Completed Events フィールドがあります。

主な利点:

• 自動追跡: Veeva RIM は、Change Items に関連付けられたイベントの合計数と完了数を、Event Change Item オブジェクトを通じて自動的に管理します。
• 完了したイベントの定義: 管理者は、新しい管理設定を使用して、どの Event ライフサイクル状態が完了したとみなされるかを定義できます。
• 可視性の向上: ユーザは、Change Item に関連する Events がいくつ完了したかを簡単に確認できます。この情報は、ユーザがさまざまな市場や関連プロセスにわたる Change Item の実装の進行状況を理解するのに役立ちます。
• 追跡の効率化: 自動更新により、Change Items のイベント完了ステータスを手動で追跡する必要がなくなります。

この機能強化により、変更項目の全体的な進捗状況と完了に関する貴重な情報が得られ、関連するイベント全体の管理と調整が容易になります。

この機能を有効にするには設定が必要です。さらに、Enable Counts of Total Events and Completed Events for Change Items という新しい設定が、Use regulatory objective data as source when bulk creating registrations 設定の下に追加されました。この設定は、デフォルトでは無効になっています。有効にすると、Completed Event States コントロールが表示され、Vault 管理者は Event オブジェクトのライフサイクルから、完了とみなす 1 つ以上のライフサイクル状態を選択できるようになります。管理者は、有効化設定を保存するには、少なくとも 1 つの完了状態を選択する必要があります。

RIM Submissions

Warning File for Excluded Sections in GCP Dispatch or SCP Compare & Merge

「Copy Relationships」が無効になっている場合に意図的に除外されるソースコンテンツプランセクションをログに記録するための新しい警告ファイルが、Dispatch Global Content Plan および Submission Compare & Merge ユーザアクションに追加されました。除外動作には変更はありませんが、予想されるシステム動作をエンドユーザにより適切に伝えるために、ダウンロード可能な CSV 警告ファイルが導入されました。

主な利点:

より詳細な警告メッセージにより、例外が発生したことがエンドユーザに警告され、顧客は外部のサポートを必要とせずに GCP ディスパッチエラーのトラブルシューティングと修正が可能になります。

主な変更点:

次の例は、GCP ディスパッチ、同期、または比較およびマージのアクション中に 1 つ以上の CP/CPI レコードのコピーが失敗する一般的な構成設定に関する、より詳細な警告メッセージの概要を示しています。

例	以前の情報	新しい情報
対象にサポート関係が存在せず、かつ Copy Relationships が有効になっていない	ディスパッチステータス = Complete	ディスパッチステータス = Complete - With Errors 警告メッセージ: {Event 関係オブジェクトラベル}: {Event 関係名} が {対象の Submission 名} に存在しないため、含まれません
対象の Submission 関係が Use for Content Planning = No に設定されている	ディスパッチステータス = Complete	ディスパッチステータス = Complete - With Errors 警告メッセージ: {Submission 関係オブジェクトラベル}: {対象の Submission 関係名} の Use for Content Planning フィールドラベル = No のため、含まれません

考慮事項: 警告は階層順に表示されます。CP セクション全体 (子 CP および CPI を含む) がディスパッチされていない場合は、セクションの最上位の CP レコードに対してのみ警告が表示されます。これには、ルート CP レベルでのコピーの失敗が含まれます。

RIM Publishing

Singapore eCTD 3.2 Publishing & Validation (SG v1.0)

Veeva Publishing は、シンガポール保健局 (HSA) 地域仕様パッケージ v1.0 に基づいて、シンガポール eCTD (ICH eCTD 仕様 3.2) の公開と検証をサポートするようになりました。Publishing 顧客は、新しい HSA モジュール 1 テンプレートを含む eCTD 提出コンテンツプランを作成し、XSD v1.0 に従って準拠した提出物を公開し、HSA 検証基準 v1.0 に従って検証することができます。

シンガポール eCTD 公開には以下の設定が必要ですが、これは展開を支援するために VPK 経由で顧客に提供できます。

• 新しいシンガポール v1.0 モジュール 1 コンテンツプランテンプレート
• HSA アプリケーションおよび提出タイプ/サブタイプ、国/保健当局、および DTD 用の新しい統制用語と制約
• 検証基準 v1.0 パッケージ
• オブジェクトレイアウトの追加設定

Taiwan eCTD 3.2 Publishing & Validation (TW v2.0)

Veeva Publishing は、台湾食品薬物管理署 (TFDA) 地域仕様パッケージ v2.0 に基づいて、台湾 eCTD (ICH eCTD 仕様 3.2) の公開と検証をサポートするようになりました。Publishing 顧客は、新しい TFDA モジュール 1 テンプレートを含む eCTD 提出コンテンツプランを作成し、XSD v2.0 に従って準拠した提出物を公開し、TFDA 検証基準 v2.0 に従って検証することができます。

Support Language Attribute in HC eCTD DTD 2.2 Submissions

カナダ保健省の DTD 更新に従って、Veeva Publishing は特に Product Monograph セクション (モジュール 1.3.1) において、地域 XML リーフの言語属性の生成に対応するようになりました。

主な更新点:

これらの変更は、2025 年 7 月 18 日に発効する HC 要件に対応しています。Content Plan Item に設定された Language for Submission 値に関連付けられた言語コードに基づいて、公開時に XML 言語属性が追加されます。

考慮事項: カナダ保健省が XML 言語属性を使用した自主的な提出の受け入れを開始したため、これらの変更は以前は 25R1.0 に関連付けられた Maintenance Release に含まれており、すべての Production Vaults に自動的にプッシュされました。Content Plan Templates を更新するための設定は必須であり、展開を支援するために VPK 経由でお客様に提供できます。

Health Canada REP Version 5.0.0

カナダ保健省 REP 提出物をサポートするために、CA eCTD および非 eCTD 検証ルール I11 が更新され、以前のバージョン 4.4.3 に代わって現在のソフトウェアバージョンが検証されるようになりました。

影響: 次の XML タイプはソフトウェアバージョン 5.0.0 の範囲内です。

• ヒト用医薬品
• 動物用医薬品
• 生物製剤および放射性医薬品、消毒剤

考慮事項: カナダ保健省は 2025 年 3 月 28 日より 5.0.0 で REP XML の検証を開始したため、これらの変更は以前は 25R1.0 に関連付けられた Maintenance Release に含まれており、すべての Production Vaults に自動的にプッシュされました。

Update Acceptable File Formats for US eCTD Rule 1255

eCTD 仕様を使用したファイル形式タイプの仕様の更新に従い、CDER への提出物用にモジュール 5 で次のファイル形式が受け入れられるようになりました。

• .gpsqlite
• .gpproject
• .gpsettings

考慮事項: 米国 FDA 検証ルール Rule1255CDER は、許可されるファイルタイプを反映するように更新されました。FDA は 2025 年 2 月 18 日に新しいファイル形式の受け入れを開始したため、これらの変更は以前は 25R1.0 に関連付けられた Maintenance Release に含まれており、すべての本番 Vault に自動的にプッシュされていました。

Update US eCTD Valid Values XML

包括的な目次見出しと階層の更新に従って、モジュール 4 またはモジュール 5 の治験タグ付けファイル (STF) を含む米国の eCTD 提出物は、util フォルダ内の ICH STF 有効値 v6.0 XML とともに公開されるようになりました。

考慮事項: FDA は 2025 年 2 月 18 日に v6.0 の受け入れを開始したため、これらの変更は以前は 25R1.0 に関連付けられた Maintenance Release に含まれており、すべての Production Vaults に自動的にプッシュされました。新しい STF 有効値ファイルタグを含め、コンテンツプランテンプレートを更新する設定が必要です。これは、展開を支援するために VPK 経由で顧客に提供できます。

Automatic Deployment of Publishing Validation Rule RIM114

公開検証基準ルール RIM114 は、Veeva Submissions Publishing のライセンスが付与された Vault 上のすべての Submissions Publishing ジョブで自動的に展開および実行されます。これまで RIM114 は設定可能な機能だったため、すべてのパブリッシュ済み提出物に対して実行されていました。

主な更新点: これまで RIM114 が検証ルールグループに追加されていなかった Veeva Publishing 環境では、Submission Publishing System Validation Rules グループが自動的にプロビジョニングされ、ルール RIM114 が入力されます。RIM114 がすでに基準グループに追加されている場合、Submissions Publishing System Validation Rules は実行されません。

Update RIM114 Validation Checks

公開検証基準ルール RIM114 が更新され、公開された出力内のプレースホルダードキュメントの識別とレポート作成が改善されました。この更新では、ドキュメントがプレースホルダーとして公開される理由を判断するための追加のチェックが導入され、ユーザが問題をより効果的に理解して解決できるように詳細なエラーメッセージも表示されます。

ルール RIM114 チェックの全リスト

更新された RIM114 検証ルールでは、次のシナリオでプレースホルダーが公開されている場合にエラーが報告されます。

• Source for Published Document フィールドが空 (新規)
• Source for Published Document フィールドに、有効なレンディションタイプではない値が含まれている (新規)
• 一致したドキュメントの Ready For Publishing フィールドが「Yes」ではない
• Published Output Location が空で、操作が「Delete」ではない
• Matched Document Count が Expected Steady State Count より少ない
• Source for Published Document が「Viewable Rendition」に設定されている場合に、表示可能なレンディションが存在しない
• Source for Published Document が「Viewable Rendition」または「Source Document」以外の値に設定されている場合に、手動レンディションが存在しない

上記のチェックのいずれかが失敗した場合、失敗の理由を説明する詳細なエラーメッセージが表示されます。すべてのチェックに合格してもプレースホルダードキュメントが生成される場合は、プレースホルダーが存在することを示す一般的な失敗メッセージが表示されます。

この機能を使用するには Vault の設定の更新が必要です。RIM114 検証ルールがすでに Vault 内に存在する場合、追加のチェックは追加のアクションを必要とせずに自動的に適用されます。

Update PDF Validation Rule to Capture Opening View Settings

カナダ (Rule B43) およびオーストラリア (Rule 6.22) の規制に準拠するために PDF を開く設定を検証する新しい基準 ID、RuleB43 が導入されました。

主な更新点:

• ブックマークペイン: ブックマークが設定されたドキュメントを開くと、ブックマークペインが表示されます
• 拡大: 拡大設定が「デフォルト」に設定されていることを確認します
• ページレイアウト: ページレイアウト設定が「デフォルト」に設定されていることを確認します

上記のロジックを有効にするには、次の設定変更が必要です。

• 次の UUID で、Vault RIM 検証基準 ID を RuleB43 に更新します。
• 236c6ccd-7f88-46a2-9a77-d60c161d2337
• 1d6edc75-5600-4c30-9050-974a42445947
• e13554a2-fa65-4f02-a1ad-623270165697
• e3d6aa9b-7bc2-498a-ac08-960ec5160dc2

影響: カナダとオーストラリアの規制要件への準拠を保証するために、すべての Publishing 顧客にこの更新をお勧めします。

Populate Merge Document Field on Root Content Plan for Submission Content Plans

Submission Content Plans で Merge and Publish Content Plan ワークフローが実行されたとき、ルート Content Plan レコードで、Content Plan オブジェクトの Merged Document フィールドに Submissions Archive ドキュメントへのリンクが入力されるようになりました。

主な更新点:

この機能強化により、ルート Content Plan の Merged Document (merged_document__v) フィールドに、新しく生成されたマージ済みドキュメントが自動的に入力されるようになりました。ユーザは設定手順を活用して、ソースドキュメントの承認時にマージされたドキュメントを自動的に Steady State に移行できるようになりました。そのためには、Content Plan ライフサイクルの Locked 状態に対してエントリアクションを設定する必要があります。

この変更により、マージされたドキュメントを Steady State に設定する機能に関して、Section Level Merge と完全なバインダーマージ間の動作の一貫性が確保されます。

Prevent Publishing Submissions with Shared Content Plans

新しいシステムチェックにより、提出レコードのコンテンツプランフィールドが別の提出レコードによって使用されている場合、公開が開始されなくなります。ルートコンテンツプランの主な提出物が別のレコードに重複していることが判明した場合、公開は失敗し、エラーログに記録されます。

主な変更点:

複数の提出レコードに同じコンテンツプランが使用されている場合、公開は失敗し、ユーザに次のエラーログメッセージが通知されます。

「コンテンツプラン {コンテンツプラン ID} は、複数の提出物 {すべての提出物のコンマ区切りリスト} で使用されています。コンテンツプランは 1 つの提出物にのみ関連付ける必要があります。他の提出物で使用されないように、提出レコードのコンテンツプランを更新してください。」

考慮事項:

このチェックは自動的に有効になり、すべての提出物に対して次のことが実行されます。

• 提出物間で重複したコンテンツプランによって発生するデータの不整合や競合を回避する
• 提出物の公開後にコンテンツプランに意図しない変更が生じないようにし、各提出物の整合性と独立性を維持する

Render Published Documents on Rendition Bulk Queue

Veeva のパブリッシュ済み出力のドキュメントレンディションが、レンディション一括キューによって処理されるようになりました。これはバックエンドの変更であり、ユーザエクスペリエンスや Veeva Publishing のパフォーマンスには影響しません。この変更は、スケーラビリティを向上させ、進行中の大規模なパブリッシングジョブや一括インポートによるドキュメントレンダリングの遅延を軽減することを目的とします。

Support Link Opening Preference in RLCP Publishing

Report Level Content Plan オブジェクトの新しい選択可能なフィールド、Published Links Opening Setting を使用すると、RLCP 発行者は外部ドキュメントのハイパーリンクを新しいウィンドウで開くか、パブリッシュ済みハイパーリンクをユーザの設定に従って開くかを選択できます。リンクを開く設定は Submissions Publishing に対して決定されますが、これまで RLCP のリンクを開く設定は地域固有ではなく、RLCP パブリッシュ済み出力がパブリッシュ済み提出物に含まれていてもリセットされませんでした。

主な更新点:

設定すると、RLCP ユーザは Published Links Opening Setting (pub_link_open_setting__v) フィールドの Clinical Study Report (clinical_study_report__v)、Nonclinical Study Report (nonclinical_study_report__v) および Report (report__v) Content Plan オブジェクトタイプで以下の選択リストオプションから選択できるようになります。

• Open in New Window (open_in_new_window__v)
• Window Set by User Preference (user_preference__v)

RLCP 公開中に公開プロセスによって解決されるすべてのリンクでは、Published Links Opening Setting を優先します。フィールドに値が入力されていない場合、システムではすべてのリンクの開く設定を Window Set by User Preference に設定します。

Support Additional Tokens for Table of Contents Referencing Section Merged Documents

セクションレベルのマージで公開されたドキュメントに目次 (TOC) が含まれている場合、TOC トークンはコンテンツプランのセクションレベルでキャプチャされた、マージされたドキュメントの値に基づいて解決されます。以前は、トークンはソースファイルのコンテンツプラン項目に基づいて解決されていました。これらの更新により、セクションレベルの TOC は、セクションレベルで結合されたドキュメントのコンテンツをより正確に反映するようになります。

影響: これらの変更は、提出コンテンツプランとレポートレベルコンテンツプランの両方のセクションのマージに適用されます。

主な変更点:

TOC がセクション結合ドキュメントを対象とする場合、TOC トークンは次のルールに基づいて解決されるようになりました。

• edl_item_v.xlink_href__v: マージされたセクションのコンテンツプランの section_merge_published_output_location__v フィールドを使用します。
• edl_item_v.xml_title__v: マージされたセクションのコンテンツプランの title__v フィールドを使用します。
• その他のすべてのトークン: マージされたセクションの最初のコンテンツプラン項目 (CPI) を使用して解決します (CPI が TOC であったり、空の値に解決されたりしても)。

South Africa (ZA) eCTD 3.2 Publishing: Controlled Vocabulary Regulatory Update

南アフリカ健康製品規制当局 (SAHPRA) の技術ファイルの更新 (バージョン 13) に従い、Veeva Publishing のドキュメントマトリックス (document-matrix.xml) に必要な更新が加えられ、以下の新しい Controlled Vocabulary 値がサポートされました。

• application-type
• contact-type
• evaluation-path
• sequence-type
• submission-lead
• submission-type

主な更新点:

これらの変更は、SAHPRA での施行日である 2025 年 7 月 1 日をサポートします。Controlled Vocabularies を更新するための設定と、以下の検証基準ルールが必要です。これらは、展開を支援するために VPK を通じてお客様に提供できます。

• 4.7.11a Envelope: submission
• 4.7.11b Envelope: submission (Attribute Code Validity)
• 4.7.11d Envelope: submission (Submission Combination Validity)
• 4.7.12a Envelope: evaluation-path
• 4.7.12b Envelope: evaluation-path (Attribute Code Validity)
• 4.7.13 Envelope: submission-lead
• 4.7.13b Envelope: submission-lead (Attribute Code Validity)
• 4.7.15a Envelope: sequence
• 4.7.15b Envelope: sequence (Attribute Code Validity)
• 4.7.1a Envelope: application
• 4.7.1b Envelope: application (Attribute Code Validity)
• 4.8.1 Required documents and prohibited documents
• 4.8.2 Expected documents and documents that should not be provided
• 4.8.3 Possible documents
• 4.8.4 Content Checklist

RIM Submissions Archive

Taiwan eCTD 3.2 Archive & Viewing (TW v2.0)

このリリースでは、Submissions Archive は、eCTD サブミッション用の TW FDA の仕様 eCTD-V-R2 を使用して、台湾向けサブミッションのインポート、表示、およびエクスポートをサポートしています。

eCTD 4.0 Archive & Viewing Core Capabilities

このリリースでは、ICH eCTD 4.0 実装ガイドバージョン 1.6 に従って、ICH eCTD 4.0 標準をサポートするために、Submissions Archive に対して重要な機能強化が導入されています。日本向け eCTD 4.0 サブミッションのインポートでは、25R2 リリース以降、これらの機能が活用されるようになります。eCTD 4.0 の将来の地域サポートもこれらの機能強化に基づいて行われます。

主な更新点:

サブミッションのインポート: Submissions Archive は、以下のすべてのインポート方法による eCTD 4.0 サブミッションのインポートをサポートしています。

• ユーザインターフェース (「Upload now」、ローカル マシンからファイルを選択)
• Vault File Manager
• Vault API
• File Staging (ルートフォルダとユーザフォルダ (構成されている場合))

ICH eCTD 4.0 ベースのサブミッションが Submissions Archive にインポートされると、システムは submissionunit.xml に存在する各 Keyword Definition に対して、Application eCTD Keyword レコードを作成します。

サブミッションの削除: ICH eCTD 4.0 ベースのサブミッションを Submission Archive から削除すると、そのサブミッションに関連付けられた Application eCTD Keyword レコードも削除されます。

表示: 単一の ICH eCTD 4.0 ベースのサブミッションが Submission フィルタに適用されると、Submissions Archive ビューアの Submission Unit (submissionunit.xml) と SHA-256 チェックサム (sha256.txt) ファイルが Name 列に表示されます。Submission フィルタに複数のサブミッションが適用されると、Submissions Archive ビューアでは Submission Unit および SHA-256 ファイルが非表示になります。

eCTD キーワードの表示: Submissions Archive ビューアには、eCTD 4.0 の Sender Defined Keywords および Health Authority Defined Keywords が表示されます。グリッドセル内の Keyword の右側に、Keyword Display Name とキーインジケータ () が表示されます。

キーインジケーターの上にマウスを移動すると、Keyword ホバーカードが表示され、Display Name、Submission、Sequence ID、および Actual Submission Date の各情報が表示されます。たとえば、Sender Defined Key は次のように表示されます。

この初期リリースは、次のように動作します。

• Sender Defined Keywords (送信者定義のキーワード) は、グリッドセルと Keyword Hovercard に Display Name とともに表示されます。

• Health Authority Defined Keywords (保健当局定義のキーワード) は、グリッドセルの Keyword Code 値と、Keyword Hovercard の Display Name に表示されます。

Health Authority Defined Keywords は、Code 値とともに表示されます。初期リリースでは、これらのキーワードに対して分かりやすい Label (ラベル) は表示されません。

eCTD キーワードの検索: Submissions Archive ビューアの XML 列は、テキストベースのフィルタ列です。25R1 を使用すると、ユーザはテキストベースのフィルタ列の Keywords を Code 値で検索できます。分かりやすい Label は、テキストベースの列で検索しても結果を得られません。

eCTD Metadata Updates (eCTD 4.0): Submissions Archive ビューアは、オンデマンドで CSV ファイルをエクスポートし、適用された Submission フィルタによりビューアグリッドに表示されないメタデータ更新 (つまり、Priority Number および Document Title の更新) のリストを提供します。

eCTD メタデータ更新のエクスポート: 少なくとも 1 つの ICH eCTD 4.0 ベースのサブミッションがアプリケーションのサブミッションにインポートされると、新しいユーザアクション eCTD Metadata Update が、Submissions Archive ビューアグリッドの All Actions メニューに表示されます。このアクションは自動的に表示され、Submissions Archive ビューアに表示するために設定を変更する必要はありません。

CSV ファイルがダウンロード可能になると、開始したユーザに通知ベルとメールで通知が送信されます。報告する新しい更新がない場合、または適用されたビューアグリッドフィルタにすべての更新が公開されている場合、eCTD メタデータ更新のエクスポートでは結果は生成されません。

eCTD メタデータの更新 - CSV列	説明
Type of Update	行を Priority Number または Document Title の更新として識別します
UUID	固有識別子の値。Type of Update = Priority Number の場合、これは Priority Number の更新の対象となる使用コンテキストの UUID です。Type of Update = Document Title の場合、これは Document Title の更新の対象となるドキュメントの UUID です。
Orphaned Update?	これが False の場合、システムはアプリケーションビューの Submissions Archive ビューアでメタデータの更新を完全に解決できます (つまり、Submission 列フィルタに Submission フィルタが適用されていません)。これが True の場合、Priority Number または Document Title の更新の使用コンテキストまたはドキュメントがシステム内に見つからないため、システムはメタデータの更新を解決できません。これは、サブミッションが順番どおりにインポートされなかった場合、または以前のサブミッションがシステムにインポートされなかった場合に発生する可能性があります。
Value (Before Update)	eCTD 4.0 メタデータの更新 (Priority Number または Document Title の更新のいずれか) による更新前の Update Target の値が表示されます。この列は、Update Target 列を含む Sequence ID と連携して動作します。2 つの列の代表的な例については以下を参照してください。
Sequence ID containing the Update Target	Update Target (使用状況またはドキュメント) が送信された Sequence ID です。完全な内容の更新を確認するには、以下のサンプルテーブルを参照してください。
Value (After Update)	eCTD 4.0 メタデータの更新 (Priority Number または Document Title の更新のいずれか) による更新後の Update Target の値が表示されます。この列は、(更新が行われた) Sequence ID 列と連携して動作します。2 つの列の代表的な例については以下を参照してください。
Sequence ID (where the update was made)	Update Target (使用状況またはドキュメント) が送信された Sequence ID です。完全な内容の更新を確認するには、以下のサンプルテーブルを参照してください。
Sequence ID applied in Viewer	Submission 列に適用されている Submission レコードの Sequence ID 値が表示されます。たとえば「7, 9」は、シーケンス ID が 7 のサブミッションとシーケンス ID が 9 のサブミッションを意味します。
Link to Viewer with Submission filters that produced this output	eCTD メタデータ更新の CSV ファイルを生成した特定の Submissionレコードに Submission フィルタが適用された Submissions Archive ビューアを開く URL が提供されます。
Link to Viewer with Submission filters to visualize all updates	すべての更新を表示するために必要な Submission フィルタを備えた Submissions Archive ビューアを開く URL が提供されます。

考慮事項: Vault では、自動的なフィルタリングまたは並べ替えが行われた CSV 出力ファイルは生成されません。

完全な eCTD Metadata Updates の例: 更新前後の値が示されています。

Japan eCTD 4.0 Archive & Viewing (JP v1.4, v1.5, v1.6)

このリリースでは、Submissions Archive は、PMDA eCTD 4.0 モジュール 1 実装ガイドのバージョン 1.4、1.5、および 1.6 に従って公開された日本向けサブミッションのインポート、表示、およびエクスポートをサポートしています。

考慮事項: Japan v1.4、v1.5、v1.6 のサブミッションは、連続した順序でインポートする必要があります (例: シーケンス ID 1 はシーケンス ID 2 より前にインポートし、シーケンス ID 2 はシーケンス ID 3 より前にインポートします)。サブミッションが順番どおりにインポートされない場合、サブミッションの構造が期待どおりに表示されない可能性があります。

Update FTP Terminology

Veeva の標準用語との整合性を高めるため、Submissions Archive のユーザインターフェースおよび通知における「FTP」という用語はすべて、「File Staging Server」、「File Staging」、または「FSS」に変更されます。Submissions Archive 機能やステージング済みファイルへの接続性には変更はありませんが、システムの使用中にユーザが用語のわずかな変更に気付く可能性があります。例:

従来の動作: このダイアログからインポートするには、サブミッションパッケージのサイズが 4GB 未満でなければなりません。それ以上のサイズのサブミッションをインポートする場合は、Vault FTP を使用してください。

今後の動作: このダイアログからインポートするには、サブミッションパッケージのサイズが 4GB 未満でなければなりません。それ以上のサイズのサブミッションをインポートする場合は、Vault File Staging サーバーを使用してください。

South Africa (ZA) eCTD 3.2 Archive & Viewing: Controlled Vocabulary Regulatory Update

Submissions Archive ビューアの表示が更新され、南アフリカ健康製品規制当局 (SAHPRA) eCTD 技術ファイルの更新 (バージョン 13) に対応するわかりやすいラベルが含まれるようになりました。これらの変更は、SAHPRA での施行日である 2025 年 7 月 1 日をサポートします。

考慮事項: 2025 年 7 月 1 日から 25R2 General Release までの間にパブリッシュまたはインポートされたサブミッションでは、新しい Controlled Vocabulary 値のラベルが正しく表示されない可能性があります。必要に応じて、General Release 後に ZA 地域 XML を再レンダリングして、ラベルが正しく表示されるようにしてください。

RIM Registrations、RIM Submissions

GCP Dispatch Relationship Matching Logic Excludes Related Change Type

Global Content Plan (GCP) ディスパッチと Create Related Records (CRR) はどちらも、ソースイベントとターゲットアプリケーション間、およびサブミッションレコード間の一致関係を識別しますが、一致動作にはいくつかの違いがあります。このリリースでは、GCP ディスパッチの照合ロジックから Related Change Type を除外する更新を導入しています。

ユースケース: このシナリオでは、2 つの Drug Product (医薬品) 関係を持つ Source Event (ソースイベント) があり、既存の Drug Product Manufacturer (医薬品製造元) (置換元) を新しい Drug Product Manufacturer (置換先) に置き換えようとしています (Related Change Type = Replace)。ただし一部の市場では、サブミッションが新しい Drug Product Manufacturer 関係を 1 つだけ持つことになります (Related Change Type = New)。

従来の動作: GCP ディスパッチは置換先の Drug Product Manufacturer を探すため、新しい Drug Product Manufacturer を持つサブミッションには一致しませんでした。Copy Relationships 設定を無効にすると、新しい Drug Product Manufacturer に対応するコンテンツプラン (CP) セクションは除外されます。Copy Relationships 設定を有効にすると、置換先の Drug Product Manufacturer に対して重複した関係が作成され、CP セクションが含まれます。

今後の動作: GCP ディスパッチは、新規または置換先の Drug Product Manufacturer 関係を持つサブミッションを照合し、すべての Submission Content Plan に適切な CP セクションを含めます。

主な利点:

• 信頼性の向上: GCP セクションが正しくディスパッチされ、データ損失が防止されます。
• データ整合性の強化: 重複した関係の作成を防ぎ、データの整合性を維持します。

RIM Registrations、RIM Submissions、RIM Submissions Archive

Active Dossier Population from GCP Dispatch: Support Dispatch Across Templates

GCP ディスパッチで Populate Active Dossier チェックボックスをオンにしているお客様は、クロステンプレートのディスパッチ (24R2 でリリースされた機能) を使用した場合に、Active Dossier レコードも自動的に生成されるようになりました。

以前の 24R2 リリースでは、マッピングを介して、異なるコンテンツプランテンプレート (CPT) を持つサブミッションに GCP をディスパッチする機能が導入されました。これにより、治験薬申請 (CTA、IND) および MedTech 申請全体での GCP の使用、および CTD のさまざまなモジュール 1 構造がサポートされます。

このリリースでは、同じコンテンツプランテンプレート (CPT) を使用して構造とドキュメントの両方をディスパッチしたときだけでなく、クロステンプレートのディスパッチシナリオ (ドキュメントのみのディスパッチ) でも Active Dossier レコードが生成されるようになりました。これにより、異なる CPT を使用して GCP をサブミッションにディスパッチするときに、必要な条件が満たされていれば、対応する Active Dossier レコードが必ず生成されます。マップされていないドキュメントや、後で比較で拒否されたドキュメントに対しても、Active Dossier レコードが作成されることに注意してください。

RIM Submissions、RIM Submissions Archive

Active Dossier: Configurable Template Support

このリリースでは、Active Dossier Template (ADT) レコードを構成する機能と、複数の Active Dossier 階層のサポートが導入されています。これにより、多様なニーズを持つ顧客に対応する柔軟性が高まり、医薬品の Common Technical Dossier (CTD) 構造を超えて Active Dossier を使用できるようになります。また、新しい標準の Investigational CTD AD Template を導入し、RIM 参照モデルをサポートします。これらの機能強化により、次のことができるようになります。

標準の Active Dossier Template のカスタマイズ

ユーザは、組織の用語や特定のビジネス要件に合わせて、標準の Active Dossier Template をカスタマイズできるようになりました。次のようなカスタマイズが可能です。

• Displayed Section Name フィールドを変更する。
• 階層の単一レベル内で ADT レコードを並べ替える。
• 追加の顧客固有のドキュメントを追跡するために新しいレコードを組み込む。

テンプレートに加えられた更新は、Active Dossier レコードに自動的に同期されます。

制限事項: トークンを使用してセクションの表示名を更新したり、トークンを使用してカスタム ADT レコードを作成したりする操作はサポートされていないことに注意してください。

既存の Active Dossier Template の更新:

• Active Dossier Template の RIM Reference Model フィールドは、標準テンプレート用に編集することはできません。このフィールドは以前は編集可能だったため、標準との矛盾がある場合は、顧客環境の既存の標準テンプレートが更新され、RIM Reference Model フィールドの値が更新されます。
• Active Dossier Template には、システム管理の新しい Root Template フィールドが追加されています。既存の Active Dossier Template で自動的に設定されます。

カスタム Active Dossier Template の作成

多様な製品タイプやビジネスニーズ (動物の健康追跡など) に対応するために、新しいテンプレート階層の作成がサポートされるようになりました。階層あたりのノード数の制限は最大 500 個です。標準テンプレート階層内でのカスタム Active Dossier Template の作成もサポートされています。

複数の Active Dossier Template の活用

• アプリケーションに新しい Active Dossier Template フィールドが追加され、そのアプリケーションの Active Dossier の入力と表示に使用する適切なテンプレートを指定できるようになりました。
• Active Dossier Viewer では、複数の階層が存在する場合の階層の選択がサポートされるようになりました。Vault 内に Active Dossier 階層が 1 つしかない場合、またはまったくない場合、セレクターは表示されません。

これらの更新により、管理者は Active Dossier Template をより柔軟に制御できるようになり、特定の組織要件やさまざまな製品タイプに合わせてシステムをカスタマイズできるようになります。

有効化

• ADT レコードを更新および作成する機能が自動的にオンになります。
• 新しい Active Dossier Template を最大限に活用し、複数の Active Dossier 階層を管理するには、追加の設定が必要になります。

Active Dossier: Dates & Comments Tracking

Active Dossier ユーザは、Active Dossier Item Detail (ADID) レコードの新しいフィールドで関連するステータスの日付とコメントを追跡できるようになりました。新しいフィールドは、AD Viewer と AD Editor でフィルタリングおよび並べ替えが可能であり、消費者向けの情報をよりわかりやすく視覚化して整理できます。

主な更新点:

リリース後は、次の新しいフィールドが自動的にアクティブになり、使用できるようになります。

• Dispatch Date: この日付は、GCP ディスパッチから Active Dossier Item Detail (ADID) が最初に作成されたときに自動的に記録されます。組織でグローバルコンテンツプランを使用していない場合は、このフィールドを非アクティブ化できます。
• Submitted Date: このルックアップフィールドには、関連する Submission レコードの Actual Submission Date の値が表示されます。
• Approval Date: この日付は、ADID が「Pending Current」ステータスに移行したとき、または Regulatory Objective の計算中に既存の (Pending Current、Current) ADID が見つかったときに、Regulatory Objective レコードの Actual Decision Date の値が自動的に入力または更新されます。
• End Date: ADID が Pending Superseded または Pending Deprecated として計算された場合、この日付は、それに代わる Regulatory Objective の Actual Decision Date の値に自動的に設定されます。ADID が Rejected または Withdrawn from a Regulatory Objective state change に移行した場合にも、自動的に設定されます。
• Comments: ユーザがレコードに関するメモや追加のコンテキストを追記できる自由テキストフィールド。

Active Dossier Viewer の使いやすさを向上させるために、次のような追加の変更も行われています。

• 複数のグローバルフィルタの適用のサポート: Product Family と Product Family など、複数のグローバルフィルタを適用できるようになりました。また、任意のフィルタオブジェクトに適用できる新しい Date フィルタを利用できます。
• Item Detail レイアウトの並べ替えの更新: Active Dossier Viewer/Editor の各セクションでは、アイテムはまずアプリケーション名 (アルファベット順) で並べ替えられ、次に Active Dossier のステータス (アルファベット順) で並べ替えられるようになります。

• Country Overview レイアウトの並べ替えの更新: Active Dossier Viewer の Country Overview では、項目はまずソースドキュメント名 (アルファベット順) で並べ替えられ、次にドキュメントのバージョン (新しい順) で並べ替えられるようになります。

• ドキュメントは、Vault 内のドキュメントを表示する他の領域に合わせて、MIME タイプのアイコンで表示されます。これにより、ドキュメントのファイルの種類を一目で識別しやすくなります。

• Active Dossier Viewer 内の権限適用が更新され、グローバルフィルタを適用するために、フィルタオブジェクトと Active Dossier オブジェクトの各フィールドに対してユーザの権限が適用されるようになりました。

利点:

• 重要な日付の可視性により、Active Dossier 内のレコードの順序を簡単に追跡できます。
• ビューアの新しいフィルタリング機能と並べ替え機能により、効率性と使いやすさが向上しました。
• コメントによる追加のコミュニケーションが可能です。
• 改善されたホバーカードの詳細と Country Overview コンテンツにより、情報に簡単にアクセスできます。
• 新しいフィールドを Excel 形式でエクスポートできます。

Active Dossier: Latest for Authoring Tracking

Active Dossier ユーザは、作成者がコンテンツの更新に使用するソースドキュメントの最新バージョンをアプリケーション別に簡単に識別できるようになりました。これらの変更により、Active Dossier の入力プロセスと、ビューアおよびエディタのインターフェースの使い勝手が改善され、どのドキュメントをバージョンアップする必要があるかを識別するためにドキュメントを比較するというエラーが発生しやすい手動プロセスが置き換えられます。

主な更新点:

Active Dossier Viewer グリッドで使用できる 2 つの新しいフィルタリング可能なフィールドにより、AD ユーザは、最新の内部承認済みバージョンではないソースドキュメントを除外したり、以前のバージョンが置き換えられた日付を特定したりすることができます。

• Latest for Authoring (latest_for_authoring__v): 表示されているドキュメントが作成者が使用すべき最新の内部承認済みドキュメントであるかどうかを追跡する、フィルタリング可能な Yes/No フィールド。
• Latest for Authoring End Date (latest_for_authoring_end_date__v): このドキュメントのバージョンが作成用として最新版ではなくなった日付を取得するフィルタリング可能な日付フィールド。

ADID レコードの作成または更新時に、フィールドに入力するための計算が行われます。

影響:

Latest for Authoring フィールドおよび Latest for Authoring End Date フィールドは、サブミッション、グローバル コンテンツ プラン (GCP) からのディスパッチ、Active Dossier Editor へのドラッグ & ドロップ、および Active Dossier Loader によって新規作成されたレコードから新しい Active Dossier Item Details が作成されるたびに更新されます。

新しいフィールドは、AD Loader と AD Excel ツリーのエクスポートの両方でサポートされます。

利点:

AD の機能を更新するための最新のドキュメントバージョンに対応した追加のフィルタリングにより、特に多数のアクティブな製品を持つ大規模なグローバル顧客の場合は、更新を作成する開始点として使用したり、新しい市場でのサブミッションの入力に使用する正しいバージョンのドキュメントを迅速に特定したりできるようになります。特に、並行したバリエーションや変更を伴う複数のイベントを管理するユーザは、最新のドキュメントバージョンが更新されていること、およびドキュメントが最新ではなくなった日付を知ることができるというメリットを得られます。これにより、更新が必要なドキュメントを AD Viewer で探すのにかかる時間も短縮されます。

Disable Archive Path in Active Dossier Population

サブミッションから Active Dossier を入力するときに、Submission Archive (ソース参照を介してリンク) にあるソースドキュメントに基づいて Active Dossier レコードを作成しないようにシステムを設定できます。この更新により、サブミッションから入力する際にコンテンツプランを唯一の信頼できるソースにすることで、Active Dossier の入力プロセスが合理化されます。

主な更新点:

Populate the Active Dossier アクションの新しいオプション設定により、システムはコンテンツプランのドキュメントとメタデータのみを検索してレコードを作成し、Active Dossier を入力するときに Submissions Archive を無視するようになります。

Active Dossier Item Details の「Archive」関連のフィールドは、Archive ドキュメントの Source Relationship や Submission レコード関係からの情報の混合ではなく、コンテンツプランからの対応する情報に基づいて直接入力されるようになりました。つまり、この設定がオンになっている場合、ADID の Submissions Archive Document フィールドは、Vault で公開されたサブミッションに対してのみ設定されます。

利点:

• Active Dossier には、コンテンツプランとアーカイブの両方ではなく、Submission Content Plan で一致したドキュメントのみが反映されます。
• コンテンツプランを調べることで、予期しないレコードに簡単に対処でき、Submissions Archive 関係を調べる必要もありません。
• 非 eCTD サブミッションを公開するお客様の場合、この更新により、明らかに重複したレコードが作成される可能性が防止されます。以前は、コンテンツプランとアーカイブの両方からレコードが生成されるため、クリーンアップ作業が必要でした。今後は、コンテンツプランのみが作成を行います。

Active Dossier Performance & Scalability Improvements

このリリースでは、Active Dossier プロセスが更新され、単一のコンシューマキューからマルチスレッドの Vault ジョブキューフレームワークに移行しました。これにより、並行処理が可能になり、Active Dossier のスケーラビリティが向上します。これらの変更は主にバックエンドのものですが、以下のような変更はユーザが認識する可能性があります。

• Active Dossier ジョブが Vault Jobs Admin ページに表示されるようになりました。
• ドキュメントのバージョンが変更された場合でも、Document Version ID、Document Major Version、Document Minor Version の各フィールドが同期されません。これらのフィールドは引き続き、Active Dossier Item の最初の作成時に設定されます。
• Active Dossier Template の無効化は、Active Dossier レコードにカスケードされなくなります。

そして、Active Dossier Viewer のパフォーマンスを向上させるために、クエリの最適化も導入されました。

Support Approval Type Field in Active Dossier Loader

このリリースでは、Active Dossier Loader を使用して Approval Type フィールドに値をロードする機能が導入されました。

以前に 24R3 でリリースされた、Active Dossier Item Detail オブジェクトの Approval Type フィールドは、ステータスの追跡 (Explicit (明示的)、Implicit (黙示的)、または Partial Approval (部分的承認)) をサポートしています。お客様は Active Dossier Loader を介してこのフィールドに値をロードできるようになるため、Active Dossier ベースラインの移行が効率化されます。

詳細に関しては、Active Dossier Loader をご覧ください。

RIM Publishing、RIM Submissions Archive

System-Managed Data Made Read-Only

Submission Metadata (submission_metadata__v) オブジェクトレコードは、ビジネス管理者ユーザインターフェース (UI) から作成、更新 (標準フィールド、つまり __v で終わるオブジェクトフィールドの)、または削除できなくなりました。システムによって管理される標準オブジェクトフィールドは、インポートまたは公開された提出物を Submissions Archive ビューアで適切に表示するために必要なため、システムによって変更が防止されます。ビジネス管理者が標準フィールドを更新しようとすると、以下に示すように、その操作はサポートされていないことを説明するポップアップメッセージが表示されます。この変更の目的は、下流での大幅な修復作業が必要となるような変更を顧客が行うことを防ぐことです。

主な変更点:

• システム管理者: Vault オブジェクトの説明が、「Submissions Archive のインポートプロセスと Submissions Publishing を介した公開を通じて取り込まれるシステム管理オブジェクト」に更新されます。
• ビジネス管理者: ビジネス管理者 UI から Submission Metadata レコードを作成、編集、または削除しようとすると、新しいエラーメッセージ「この操作はサポートされていません。データはシステム管理されているため、読み取り専用です。」が表示されます。

eCTD 4.0 Publishing Core Capabilities

このリリースでは、ICH eCTD 4.0 実装ガイドバージョン 1.6 に従って、ICH eCTD 4.0 標準をサポートするために、Vault Submissions Publishing に対して重要な機能強化が導入されています。日本向け eCTD 4.0 サブミッションのパブリッシングでは、25R2 リリース以降、これらの機能が活用されるようになります。eCTD 4.0 の将来の地域サポートもこれらの機能強化に基づいて行われます。

主な更新点:

ドキュメントの再利用: eCTD 4.0 では、オンデマンドパブリッシングおよび連続パブリッシング中のドキュメントとファイルの再利用が改善されました。システムは、同じリードマーケット、保健当局、保健当局部門内で以前に提出された eCTD 4.0 サブミッション内のドキュメントを自動的に識別します。このようなドキュメントがコンテンツプランアイテムと一致すると、システムは Published Output Location を相対パスに変更し、Node Type を Reference Leaf に設定することで、ドキュメントを参照リーフとして自動的に処理します。さらに、コンテンツプランアイテムテンプレートと Content Plan Item オブジェクトに新しいフィールドが追加され、ユーザは特定のコンテンツプランアイテム間での自動再利用を無効にできるようになりました。

ドキュメントメタデータの更新: オンデマンドパブリッシングおよび連続パブリッシングワークフロー内でのドキュメントメタデータ (タイトル) の更新のサポートにより、ドキュメントのリビジョンを効率的に管理できます。コンテンツプランアイテムに新しいユーザアクション Set Document Update Operation が利用可能になりました。このアクションにより、アプリケーション内で以前に送信されたドキュメントを選択し、そのドキュメントのタイトルを更新するためのダイアログボックスがユーザに表示されます。システムは、eCTD 4 Modified Files フィールドを以前に送信されたドキュメントの ID に設定し、Node Type を Document Metadata Update に設定します。

Set Leaf Operation の機能強化: Set Leaf Operation ユーザアクションとインターフェースの機能強化により、新しい submissionunit.xml で XML 生成を適切に処理しながら、以前に 3.2 および 4.0 形式で送信されたドキュメントを置換、一時停止 (削除)、アクティブ化 (新規) できるようになりました。さらに、置換操作では、ユーザは一対多または多対一の関係で、以前に送信された複数のドキュメントを選択できます。Set Leaf Operation を保存すると、システムは Set Leaf ダイアログで選択した値に基づいて XML 操作を設定し、eCTD 4 Modified Files フィールドを以前に送信されたドキュメントの ID に設定します。

ライフサイクルの削除/一時停止および新規/アクティブ化オペレーション:

以前に送信した複数のファイルを置換:

以前に中断されたファイルを再アクティブ化:

キーワード管理: システムは、Application および Submission 参照関係オブジェクトに新しい表示名フィールドを導入するなど、eCTD 4.0 Sender Defined Keyword の処理をサポートします。さらに、eCTD 4 Code Name と eCTD 4 Display Name というコアオブジェクトに新しいフィールドが追加され、eCTD 4.0 アプリケーション/サブミッションのトランザクションオブジェクトのコードと表示名をデフォルト設定するために使用できるようになりました。詳細については、25R1 および 25R2 の RIM データモデルの更新を参照してください。

Priority Number Generation and Updates: Veeva Submissions Publishing は、eCTD 4.0 サブミッション内の Context of Use (CoU) の優先番号を設定および定義する機能をサポートするようになりました。これらのアクションにより、Submissions Archive 内の Context of Use (CoU)/ドキュメントの表示順序を制御できます。サブミッションがパブリッシングされると、システムは各 Context of Use (CoU) の優先番号を自動的に「32」ずつ増分して設定します。コンテキストグループ内では、グループに新しい CoU が追加されるごとに、Context of Use の優先順位番号が 32 増加します。

さらに、新しいユーザアクション Update Priority Numbers を使用すると、ユーザはコンテキストグループ内の Context of Use (コンテンツプランアイテム) の表示順序を変更できるようになります。新しい Update Priority Numbers ダイアログを使用すると、ユーザはコンテンツプランアイテムの優先順位番号を更新し、Submissions Archive ビューアに表示されるドキュメントの順序を変更できます。

• Sort Alphabetically: コンテキストグループ内のすべての Context of Use を、ドキュメントのタイトルまたはファイル名のアルファベット順に並べ替えます。

• Move to Top: 現在の Context of Use をコンテキストグループの先頭へ移動します。

• Move to Bottom: 現在の Context of Use をコンテキストグループの最下部へ移動します。

• Move Below: 特定の Context of Use (タイトルとシーケンス番号) を検索して、現在の Context of Use をその下に配置します。

考慮事項: これらの機能強化により、eCTD 4.0 サブミッションを管理するための堅牢なプラットフォームが総合的に提供され、現在の ICH eCTD 4.0 標準への準拠が保証されます。これらの機能強化は、地域に特化しない一般的な機能です。その他の地域向けの eCTD 4.0 パブリッシングサポートは、世界の保健当局が提供するタイムラインに基づいて今後のリリースで追加される予定です。

eCTD 4.0 パブリッシングを有効にするには、設定、データモデルの強化、コアデータの更新、コンテンツプランテンプレートの更新、および準拠したサブミッションを準備するためのビジネスプロセスの変更が必要です。eCTD 4.0 パブリッシング有効化のサポートについて、または eCTD 4.0 のトレーニング機会の詳細については、Veeva アカウントチームにお問い合わせください。

Viewing eCTD Lifecycle Histories

このリリースでは、Submissions Archive ビューアのユーザインターフェースが再設計および改善され、eCTD 3.2 および eCTD 4.0 サブミッションの eCTD ライフサイクル履歴を確認できるようになりました。この新しいユーザインターフェースは、以前に Veeva Publishing でインポートまたは公開されたすべてのコンテンツのほか、リリース後にインポートまたは公開されたすべてのサブミッションにそのまま対応しています。

主な更新点:

履歴ライフサイクルの表示:

このユーザインターフェースの機能強化は、Historical Lifecycle of Document (eCTD サブミッション内の Documents から実行可能なユーザアクション) と Cumulative View (eCTD セクションで実行可能なユーザアクション) に適用されます。

Historical Lifecycle of Document (eCTD 3.2 サブミッション):

Historical Lifecycle of Document (eCTD 4.0 サブミッション):

• ライフサイクル履歴は、各シーケンスを表す列を持つ水平タイムラインとして表示されます。
• Sequence ID 列ヘッダーの外観と順序 (左から右) は、Submission レコードに入力された値によって決まります。
• 単一のサブミッションが Submission 列フィルタに適用され、Historical Lifecycle of Document が開かれると、Sequence ID 列ヘッダーにチェックマークアイコン () が表示され、Current filtered sequence (現在フィルタされているシーケンス) が示されます。このアイコンは、Submission フィルタで複数のサブミッションが適用されている場合は Historical Lifecycle of Document に表示されず、セクションの Cumulative View にも表示されません。
• Name 列の動作が更新され、オレンジ色でハイライトされたセルの網掛けが表示されるようになり、アクションが開始された場所を簡単に識別できるようになりました。アクションが継続している限り、オレンジ色でハイライトされたセルの網掛けも継続して表示されます。
• ドキュメントをクリックすると、埋め込まれたドキュメントビューアで Viewable Rendition が開きます
• Historical Lifecycle of Document アクションがドキュメントに対して起動されます
• Cumulative View アクションは、ドキュメントを含むセクションから起動されます

ドキュメントカード:

ドキュメントカードは、Sequence ID 列に表示されます。ミニブラウザで表示アイコン () およびサブミッションの詳細アイコン () が表示されているドキュメントカードは、eCTD ライフサイクルでアクティブな Documents を表します。一方、リーフのアイコンのみが表示されている Documents は、削除済み (ICH eCTD 3.2) または停止中 (ICH eCTD 4.0) です。

• Historical Lifecycle of Document では、ビューが起動されたドキュメントカードが特別なスタイル (青い網掛け) で表示されます。
• ドキュメントカードの左側または右側から線が伸び、XML 操作に接続されます。ライフサイクルが壊れている、または予期しない状態になっていると思われる場合は、Import Notification メールをチェックして、Import Warnings や Content Plan (Veeva Publishing を使用している場合) を確認してください。
• ドキュメントが Delete 操作 (ICH eCTD 3.2) または Suspend 操作 (ICH eCTD 4.0) によってライフサイクルから削除されると、それぞれ 削除済みのドキュメントカードまたは一時停止中のドキュメントカードが特別なスタイル (点線の縁取りのある薄い灰色) でユーザインターフェースに表示されます。以下に ICH eCTD 4.0 ライフサイクルの例を示します。削除されたドキュメントは Sequence ID 列 5 に表示されます。

オペレータアイコン:

• オペレータアイコンは Sequence ID 列の間に表示され、ドキュメントカードから伸びる線で接続されています。
• ICH eCTD のバージョン (3.2 または 4.0) に応じて、オペレータアイコンは次のように表示されます。

セクションの Cumulative View:

• Cumulative View には、Submissions Archive ビューアのセクション内のドキュメントがドキュメントヘッダーとして表示されます
• ドキュメントヘッダーは Sequence ID の昇順でソートされます
• Cumulative View が起動すると、最初のドキュメントヘッダーが自動的に展開されます。ドキュメントヘッダーは折りたたみ可能です。
• Vault では、一度に 1 つのドキュメントヘッダーを展開できます。折りたたまれたドキュメントヘッダーを展開すると、開いていたドキュメントヘッダーは自動的に折りたたまれます。

Japan eCTD 4.0 Publishing (JP v1.6)

Veeva Publishing は、医薬品医療機器総合機構 (PMDA) の地域仕様パッケージ v1.6.0 に基づいて、日本の eCTD 4.0 パブリッシングをサポートするようになりました。この機能により、PMDA の要件に従って準拠したサブミッションと submissionunit.xml ファイルを生成する機能が導入されます。

主な更新点:

日本向け submissionunit.xml の生成: Vault は、PMDA が要求する形式で、eCTD 4.0 サブミッション用のコア XML ファイルである submissionunit.xml を作成できるようになりました。

日本のサブミッション方法のサポート: システムは、PMDA によって定義された 3 つの異なるサブミッション方法を処理し、選択された方法に基づいて正しい XML 出力を保証します。Submission オブジェクトの Category Event フィールドを含む新しいメタデータフィールドが入力されると、システムは適切なサブミッション方法を定義します。たとえば、サブミッションに治験データやドキュメントが含まれているかどうかによって、情報の方法や取り扱い方が変わる場合があります。

サブミッション管理情報の更新: 製品情報を含む submissionunit.xml の subject2.review 要素は、Update Submission Administrative Information ダイアログで指定された値に基づいて submission XML 内に生成され、入力されます。既存のユーザアクション Update Submission Administrative Information を使用すると、ユーザはこのデータを入力して管理できます。

ドキュメント再利用ロジック: システムは、ICH eCTD 4.0 仕様および PMDA によって定義されているドキュメント再利用の特定のルールを実装します。これには、ドキュメントが再利用できるかどうかを判断するためのアプリケーションタイプとサブミッション日のチェックが含まれます。

考慮事項: ICH eCTD 4.0 パブリッシングには、eCTD 4.0 データモデル (25R1 および 25R2 でリリース) の採用と、ICH 仕様要件をサポートするためのデータ強化アクティビティが必要です。PMDA 仕様 v1.6.0 および ICH eCTD 4.0 をサポートするためのコンテンツプランテンプレートの更新も必要です。今後のリリースには、日本 eCTD 4.0 の検証が含まれる予定です。新しいサブミッションタイプを作成するには、コアデータの更新、特に CV と制限が必要です。日本向け v1.6.0 サブミッションのパブリッシング検証基準は、今後のリリースで提供される予定です。eCTD 4.0 パブリッシング有効化のサポートについては、Veeva アカウントチームにお問い合わせください。

Safety

25R2 以降のすべてのリリースでは、Safety は、Veeva Vault Platform と同日にリリースされます。Safety Vault 中央辞書の最新の更新については、Safety 中央辞書の更新を参照してください。

Veeva Connections セクションに記載されているいくつかの機能も、Safety アプリケーションファミリーに影響を与えます。

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

Safety

Automated Acknowledgement of Email to Inbox

このリリースでは、Veeva Safety は、メールが Vault によって正常に受信され、Inbox Item が作成されたことを送信者に通知する確認メールを自動的に送信します。この機能では、Inbound Email タイプの Transmission Profile の選択リストが導入され、管理者は確認応答を受信する送信者を指定できるようになりました。

詳細

• 有効化: 受信トレイへのメールの自動確認を有効にする
• 管理者ヘルプ:
  • Safety インボックスアイテムへのメールを設定する
  • トランスミッションプロファイルの管理
• ユーザヘルプ: メールからの Inbox Item 生成

Standard Health Canada Mappings for Safety Inbox Item Processor

このリリースでは、Veeva Safety はカナダ保健省の標準化されたフィールドマッピングをサポートしており、Safety Inbox Processor とシームレスに組み合わせて使用できるため、複数の Case を表形式データでインポートできます。以前は、管理者はこの保健当局に対応した Tabular Data Format、Import Field Mappings、および Import Code Mappings を手動で構成する必要がありました。

この更新によりセットアップが簡素化され、構成時間が短縮され、ユーザエラーが最小限に抑えられるほか、カナダ保健省に対するサブミッション全体の一貫性が確保されます。

詳細

• 管理者ヘルプ: 表形式の複数症例データのインポートを管理

Document Intake Highlighter: Product Extraction

このリリースでは、Veeva Safety の Document Intake Highlighter パネルが改善されており、ドキュメント取り込みプロセスの効率が向上しています。管理者は、非構造化ドキュメントと半構造化ドキュメントから自社製品を自動的に識別してパネルに抽出する機能を設定できるようになりました。Intake ユーザには、製品を Inbox Item に追加する前に、抽出された用語を確認して拒否するオプションが用意されているため、引き続き制御が可能です。以前は、抽出を行うためにはドキュメント内の製品をユーザが手動でハイライトする必要がありました。この更新により手作業の労力が削減され、精度が向上し、管理者とユーザは取り込みワークフローをより細かく制御できるようになります。

詳細

• 有効化: Document Intake Highlighter を有効にする
• ユーザヘルプ: Document Intake Highlighter

Document Intake Highlighter: User Interface Updates

このリリースでは、Veeva Safety の Document Intake Highlighter パネルに次のようないくつかの改善が加えられています。

• ページネーションの強化: ユーザはパネル内で最大 500 個の製品と 500 個のイベントを強調表示できます。以前は 10 個に制限されていました。パネルでは、ナビゲーションを改善するために項目がページ分けされています。
• 高度なフィルタリング: サマリービューでは、製品項目ごとに注釈をフィルタリングできるため、関連データにすばやくアクセスできます。
• 強化されたホバーカード: ユーザは、表示モードと編集モードのどちらでも、ホバーカードで製品とイベントの詳細を表示できます。
• 追加の製品分類: ユーザは、将来の分類のために、パネル内の製品を Similar Device および Unknown に分類できるようになりました。
• ドラッグアンドドロップによる分類: ユーザは、製品を特定のナビゲーションタイルにドラッグして別のセクションに移動することで、製品を再分類できるようになりました。これにより、整理が容易になります。
• 柔軟な削除オプション: ユーザは、保存していないアイテムを直ちに削除したり、将来的な Case のプロモーション時に既存のアイテムが削除されるようにマークしたりできます。

これらの更新により、ユーザのワークフローが合理化され、製品データの管理とレビューがより迅速かつ直感的になります。

詳細

• 有効化: Document Intake Highlighter を有効にする
• ユーザヘルプ: Document Intake Highlighter

Case Promotion Waiting Page

このリリースでは、Inbox Item を Case にプロモーションしているときに、より情報量の多い遷移画面が表示されるようになりました。この機能強化により、基本的な読み込みスピナーが情報メッセージに置き換えられます。また、進行状況の詳細と、Case プロモーションプロセスを中断することなく Inbox Item タブに移動するためのリンクがユーザに提供されます。

Duplicate Search Potential Matches Page Setting

このリリースでは、Veeva Safety に新しい設定 Duplicate Search Potential Matches App Page が導入されました。

注: この設定は、今後のリリースで導入予定の機能の管理に用いられます。

詳細

• 管理者ヘルプ: Safety アプリケーション設定および設定オプション

Formula Expressions for Online Questionnaire Follow-up Rules

このリリースでは、Veeva Safety は、ルールの Case データを評価するためのフォローアップアンケートルールエンジンの数式表現をサポートします。以前は、Follow-up Rule Criteria では、より高度なビジネスユースケースをサポートするための複雑なルール表現の使用は許可されていませんでした。

詳細

• 有効化: フォローアップオンラインアンケートを有効化する
• 管理者向けヘルプ: フォローアップオンラインアンケートの設定
• ユーザヘルプ: 症例連絡先にフォローアップオンラインアンケートを送信する

Online Questionnaires for Manual Correspondence Using Document Templates

このリリースでは、Veeva Safety で、Follow-up Questionnaire Rule に承認済みの Questionnaire Design が含まれていない場合でも、手作業での通信のためにフォローアップオンラインアンケート用のアクティブなテンプレートからドキュメントを生成できるようになりました。これにより、手作業の負担が軽減され、Cases でオンラインアンケートが使用されていない場合でもフォローアップアクションをタイムリーに行うことができます。

詳細

• 管理者向けヘルプ: フォローアップオンラインアンケートの設定

QC Checklists: Post Closure Checklist Log

このリリースでは、Veeva Safety は CSV ログファイルを生成し、QC Checklist Generation が有効になっている Vault で指定された Post-Closure QC Interval 設定に従って、該当する Post-Closure Checklist Creation Rule に添付ファイルとして追加します。

詳細

• 管理者ヘルプ: QC チェックリスト生成ルールの設定

Increase Generic Name Field Length to 500 Characters

このリリースでは、Product Family オブジェクトの Generic Name フィールドが 100 文字から 500 文字に増えており、Safety-RIM Connection がサポートされるようになりました。

Rules Based Narratives: Updates

このリリースでは、Rules Based Narrative Generation 機能に、症例処理中の効率性をさらに高める次のような更新が加えられています。

• 一括非盲検化: 一括非盲検化フォローアップの作成中に、ユーザが Narrative Text フィールドにテキストを入力すると、Vault はフィールド値の内容を含む Case Follow-up Statement を生成します。
• ナラティブアウトラインのコピー: Narrative Outline とそれに関連付けられた Narrative Statements をコピーする新しいアクション。
• 新しい関数: Statement Formulas を Narrative Statement Options 用に設定するときに使用する新しい関数。
  • 投薬回数: 管理者は、"every 0.5 days" ではなく "2 times per day" のような形式で投与回数を指定できます。
  • プレフィックスによる日付範囲: 管理者は日付のエクスポート方法をフォーマットしたり、最初の文字を大文字にするか小文字にするか指定したりできます (例: "From "{start date}" から "{end date}")。
• 症例のフォローアップステートメント: Vault は、以前のバージョンから新しい Case に Case Follow-Up Statements をコピーします。

詳細

• 有効化: ルールベースのナラティブ生成の有効化
• 管理者ヘルプ: ルールベースのナラティブの設定
• ユーザヘルプ: 症例のナラティブの生成

Expectedness Reevaluation for Postmarket Follow-Ups

このリリースでは、Veeva Safety は市販後 Cases のフォローアップ情報に基づいた期待度の再評価をサポートします。有効にすると、Vault は、新しい情報が進行中の Case にマージされるか、フォローアップの Case にプロモーションされるたびに、期待度を再評価します。

詳細

• 有効化: 市販後フォローアップの期待度再評価を有効にする
• ユーザヘルプ: 症例データの入力

Exclude External Products During Assessment Generation

このリリースでは、管理者は自動的な Case Assessment の生成中に External Products を対象から除外することを選択できます。以前は、Vault は、External Products を含むすべての製品とイベントの組み合わせに対して Case Assessments を作成していました。不要な Case Assessments を削減することで、Case Processors は Case のサブミッションに必要な関連情報のみに集中でき、データ入力が合理化され、効率が向上し、作業負荷が軽減されます。

詳細

• 有効化: 評価レコードアクションの生成の有効化
• ユーザヘルプ: 評価の生成

Case Assessment Expectedness Datasheet Type Identification

このリリースでは、期待度を評価するために使用される Datasheet のタイプを明確に示すために、Veeva Safety の Case Assessment Expectedness レコードに Datasheet Type フィールドが導入されています。以前は、これらのレコードは特定の Datasheet のみを識別していました。これにより、ユーザは関連レコードを確認して Datasheet のタイプを判断する必要がなくなります。

詳細

• 有効化: 症例評価の期待度データシートのタイプの識別を有効にする
• ユーザヘルプ: 症例評価の期待度をどのように生成するか

Simplified Case Product Registration Deletion

このリリースでは、Veeva Safety は、Case Product Registrations を 1 回のクリックで削除する操作をサポートしています。削除は、関連付けられているローカライズされたレコードにカスケードされ、関連レコード内の参照がクリアされます。これらの更新は、Inbox Item to Case Compare ページを通じてフォローアップ項目をマージまたはプロモーションするときに、Localized Cases の Case Product Registrations で参照されている Case Products を削除する場合にも適用されます。以前は、ユーザはさまざまなオブジェクトにわたって複数のレコードを手動で削除する必要があったため、時間がかかり、エラーが発生しやすい状況でした。この機能強化により、時間が節約され、手作業が軽減され、Case 処理中のデータの不整合のリスクが最小限に抑えられます。

詳細

• ユーザヘルプ: PMDA の症例の取り込みと処理の完了

Agency Units of Measurement Update

このリリースでは、Veeva Safety で Agency Unit of Measurement オブジェクトの IU international unit(s) が無効化されました。これは国際単位の重複エントリです。この更新は、保健当局への提出のために正確かつ標準化された単位レコードを保持することで、規制遵守をサポートします。

Auto-Ranking Case Adverse Events

このリリースでは、Veeva Safety に Case Adverse Events の自動ランク付け機能が導入され、最も重大または保守的な事象を第一位の事象として特定できるようになりました。管理者は、重篤度、関連度、予測可能性に基づいて事前定義されたランク付けルールを使用して、事象の優先順位を設定できます。使用可能な設定は次のとおりです。

• 重篤度 > 関連度 > 予測可能性 (デフォルト)
• 関連度 > 重篤度 > 予測可能性

同順位の事象がある場合は、転帰、重症度、CTCAE グレード、作成日を使用して、決められた順序でタイブレーカーを実施します。

自動ランク付けは、ユーザアクション、エントリアクション、またはユーザ更新 (評価レコードの変更など) を通じて実行できます。完了すると Rank フィールドに値が入力されますが、この値は手動で上書きできます。

さらに、Overall Case Seriousness フィールドも導入されます。このフィールドには、ある特定の症例において、ランクに関係なくすべての有害事象の中で重篤度が最も高い値が設定されます。

この機能により、症例レビューが効率化され、事象の優先順位付けの一貫性が向上します。また、重篤な転帰の可視性が高まり、手作業の負担が軽減されます。

詳細

• 有効化: 症例有害事象の自動ランク付けを有効にする
• ユーザヘルプ:
  • 症例有害事象の自動ランク付け方法
  • 症例データの入力

MedDRA Support for Additional Languages

このリリースでは、Veeva Safety は、クロアチア語、エストニア語、フィンランド語、ギリシャ語、アイスランド語、ラトビア語、リトアニア語、ポーランド語、スウェーデン語の 9 つの言語で MedDRA 用語の閲覧、検索、コーディングをサポートします。この機能は、追加言語での MedDRA 用語の参照と検索をサポートすることで、グローバルなアクセシビリティと効率性を向上させます。

詳細

• 管理者ヘルプ: MedDRA 辞書の管理

MedDRA Dual-Language Coding for Case Processing

このリリースでは、Veeva Safety の国内向け Cases のユーザインターフェースが更新されており、サポートされている英語以外の言語で報告された医学用語のコーディングが容易になっています。この更新は、Case Adverse Events、Case Drug Histories、Case Test Results、Case Causes of Death、Case Product Indications、および Case Diagnoses に適用されます。報告された用語およびコード化された用語は、選択したローカル言語と英語の両方で表示されるようになりました。

詳細

• ユーザヘルプ: MedDRA 用語のコーディング

MedDRA Chinese, Japanese, & Korean Language Search Improvements

このリリースでは、Veeva Safety が中国語、日本語、韓国語の MedDRA 辞書で医学用語を検索する際の検索結果が改善されています。以前は、MedDRA は中国語、日本語、韓国語の用語の部分的な検索一致をサポートしていませんでした。

WHODrug Link Korea

このリリースでは、Veeva Safety はコード化された WHODrug 用語に基づいて、国内および海外のローカライズされた韓国語の Cases の External Product 情報を自動的にコード化するため、ローカライズされた MPID 値を手動で入力する必要がなくなります。これにより、効率、正確性、一貫性、規制遵守が向上します。

詳細

• 有効化: WHODrug Link Korea を有効にする
• 管理者ヘルプ: WHODrug Link Korea の管理
• ユーザヘルプ: WHODrug 製品のコード化

Centralized Medical Assessment View

メディカルレビューを効率化するために、関連するすべての評価の詳細を一元的に表示するビューが Veeva Safety に導入されています。Case レイアウト上の構成可能な Medical Assessment セクションでは、すべての Case Assessments、Case Assessment Results、および Case Assessment Expectedness レコードを 1 か所で表示および評価できます。以前は、メディカルレビューを完了するには、ユーザは Case 内の 3 つの異なるセクション間を移動する必要がありました。この機能強化により、重要な情報が単一のアクセスしやすいビューに統合され、効率が大幅に向上し、レビュー時間が短縮されます。

詳細

• 有効化: 一元的なメディカル評価ビューを有効にする
• ユーザヘルプ: メディカル評価を実施する

Unified Code for Units of Measure (UCUM): Code Updates

このリリースでは、Veeva Safety における Unified Code for Units of Measure (UCUM) のサポートを強化するため、無効なコードが更新され、廃止されたコードが無効化されました。これらの改善により、高いデータ整合性が維持され、規制基準の遵守が保証されます。また、保健当局への提出におけるエラーのリスクが軽減され、最終的に効率とコンプライアンスの向上につながります。

Generate Case Collections by Case Version

24R1 Release では、Veeva Safety は Case Collections を導入し、Cases のグループをレビューおよびレポートする機能を強化しました。この機能により、最新の Case バージョンの複数の E2B および CIOMS I フォームを一度にエクスポートできるようになりました。このリリースでは、Case Collections を、最新バージョンに加えて特定の Case バージョンに対して作成できるようになりました。これにより、Case データの管理の柔軟性が向上し、より正確なレポートと分析が可能になります。

詳細

• 有効化: 症例および安全性レポートコレクションの作成およびエクスポートを有効にする
• ユーザヘルプ: 症例および安全性レポートのコレクションを管理する

LATAM VigiFlow E2B Generation

このリリースでは、Veeva Safety は中南米へのサブミッションに対応した LATAM E2B(R3) 形式での個別症例安全性報告書の生成とサブミッションをサポートしています。この機能には、VigiFlow Industry eReporting 有害事象管理システムへの送信を容易にするために、中南米諸国で必要なすべての地域データ要素が含まれています。

詳細

• 管理者ヘルプ: 基準当局への ICSR 提出
• ユーザヘルプ: E2B 生成: LATAM E2B(R3) マッピング

E2B: Localized Case Product Dosage Export Update

このリリースでは、Localized Cases の ICH E2B(R3) および EMA E2B(R3) ファイルを生成する際、Localized Case Product Dosage の Dosage Text フィールドに何らかの値が含まれている場合、またはこのレコードの Dose (Unit) の値がグローバル Case と異なる場合にのみ、G.k.4.r.8 Dosage Text データ要素がエクスポートされるようになりました。これまでは、Dosage Text フィールドが空白の場合に G.k.4.r.8 データ要素がエクスポートされていました。

詳細

• ユーザヘルプ:
  • E2B 生成: EMA E2B(R3) のマッピング
  • E2B 生成: ICH E2B(R3) のマッピング

Case Validation for FDA E2B(R3)

このリリースでは、Veeva Safety は FDA E2B(R3) ファイル タイプのバリデーションをサポートしています。このバリデーションにより、お客様は FDA にファイルを提出する前に、フォームの情報が当局のビジネスルールに準拠していることを確認できます。

詳細

• ユーザヘルプ: 症例およびサブミッションのバリデーション

FDA E2B(R3) for Clinical Trials: Result of Assessment Update

このリリースでは、臨床治験 Cases の FDA E2B(R3) ファイルを生成する際、Related が Suspected に設定され、Not Related が Not Suspected に設定された Case Assessment Results が G.k.9.i.2.r.3 Result of Assessment データ要素にエクスポートされるようになりました。この機能は、FDA 規制の遵守をサポートします。

詳細

• ユーザヘルプ: E2B 生成: FDA E2B(R3) のマッピング

Masked CIOMS I: Parent Route of Administration Update

このリリースでは、Mask Dosage on Blinded Forms が有効になっている CIOMS I フォームのセクション II.16 をエクスポートするとき、投与経路が次のように表示されるようになりました。

• Parent RoA が存在しない場合は、マスクインジケータ ***** を使用して Patient RoA のみがエクスポートされます。
• Parent RoA が存在する場合は、マスクインジケータ ***** を使用して Parent RoA と Patient RoA が両方ともエクスポートされます。

これまでは、Parent RoA が存在しない場合でも、Parent RoA のマスクインジケータがエクスポートされていました。この更新により、盲検化された提出において明確さが向上し、規制遵守が確保されます。

詳細

• ユーザヘルプ: マスクした安全性レポートの生成

MFDS E2B(R3): Missing Age Information Masking Update

このリリースでは、MFDS E2B(R3) ファイルを生成する際に Date of Birth、Age at Vaccination、Age、Age Group、および Gestation が空白の場合、MSK が D.2.1 Date of Birth データ要素にエクスポートされます。この機能は、MFDS 規制の遵守をサポートします。

詳細

• ユーザヘルプ: E2B 生成: MFDS E2B(R3) のマッピング

PMDA Foreign Localized Case Assessment Generation Update

このリリースでは、PMDA の外国の Localized Case にリンクされているグローバル Case で有害事象が追加または更新された場合、日本の Localized Case に対する Case Adverse Events と Case Assessments の同期は、外国の Localized Case の同期時にのみ行われるようになりました。これまでは、変更が発生するたびに外国の Localized Case との同期が行われていました。

Convert EMA E2B(R3) Validations to Vault Expressions

このリリースでは、Veeva Safety が EMA E2B(R3) Case および Submission データに対して実行する検証において、JSON ではなく Vault Expressions が使用されるようになりました。これにより、EMA E2B(R3) ビジネスルール検証の保守性と読みやすさが向上します。さらに、Safety の EMA E2B(R3) 検証が更新され、規制当局の最新のビジネスルールと完全に一致するようになりました。

詳細

• ユーザヘルプ: 症例およびサブミッションのバリデーション

European Commission Manufacturer Incident Report (EU MIR) PDF Generation

このリリースでは、Veeva Safety で、欧州委員会の重大事故 (MDR/IVDR) および事故 (AIMDD/MDD/IVDD) に関する製造業者事故報告書 (MIR) バージョン 7.2.1 (欧州連合 (EU) テンプレートを使用して PDF 形式で出力されたもの) の生成と提出がサポートされました。この機能により、仕様に準拠した報告書の生成と欧州医療機器データベース (EUDAMED) への送信に必要なデータを入力できるオブジェクトとフィールドが導入されます。

詳細

• 有効化: 欧州連合製造業者事故報告書 (EU MIR) の PDF 生成を有効にする
• ユーザヘルプ:
  • EU MIR 生成データのマッピング
  • 症例データの入力

FDA, NMPA, & EU Regional Fields: Data Model

このリリースでは、FDA、NMPA、EU MIR フォームの生成に必要な地域フィールドが Veeva Safety のデータモデルに導入されました。これらのフィールドは将来の機能の基盤となります。

Early Notification Reports

Veeva Safety では、レポートルールエンジンを使用して、エージェンシーやパートナーへの早期通知 (24/48/72 時間) レポートの送信を自動化する機能がサポートされるようになりました。この機能では、Early Notification Report ルールパラメータと Evaluate Early Notification Obligations アクションが導入されています。Evaluate Early Notification Obligations アクションが実行されると、Safety ルールエンジンは Early Notification Report ルールパラメータを使用してルールを評価し、必要な Transmissions を生成します。

詳細

• 管理者ヘルプ: 早期通知レポートを有効にする
• ユーザヘルプ:
  • 早期通知、サブミッション、配布の概要
  • Early Notification Report を作成する
  • レポート作成ルールパラメータの参照

DSUR and PBRER: Active Comparator Breakdown

DSUR Aggregate Report および PBRER Aggregate Report において、各 Active Comparator の組み合わせに対する Case の数の内訳が提供されるようになりました。これは、DSUR および PBRER 累積表内の新しい Active Comparator Breakdown タブに表示されます。以前は、すべての Active Comparators が 1 つの列にグループ化されていました。この機能強化により、Case データレポートをより明瞭かつ詳細に作成でき、Active Comparators の組み合わせをより正確に分析できるようになります。

詳細

• 管理者ヘルプ: 集積レポートテンプレートの設定
• ユーザヘルプ:
  • DSUR Aggregate Report の作成
  • PBRER Aggregate Report の作成

DSUR: Ability to Include Fatal Adverse Events in Cause of Death Column

このリリースでは、DSUR の死亡した患者のリストの集計に、死亡原因に関する追加情報ソースを含めるオプションが追加されました。このオプションを有効にすると、Case で致命的と示されているすべての Adverse Events の優先語 (PT) も Cause of Death 列に含まれます。

詳細

• 管理者ヘルプ:
  • DSUR の死因列への致命的有害事象の表示を有効にする
  • Safety アプリケーション設定および設定オプション
• ユーザヘルプ: DSUR Aggregate Report の作成

Individual Case Routing Criteria

このリリースでは、Veeva Safety により、管理者は、Signal やメディカルレビューなどの専門的なレビューのために Cases にフラグを付けるルールを設定できるようになりました。Case が条件を満たすと、Veeva Safety はルーティングタグを適用し、アクションをトリガーできます。この機能により、カスタム SDK ロジックが、柔軟でスケーラブルかつ保守可能なソリューションに置き換えられます。

詳細

• 有効化: 個別の症例ルーティング基準を有効にする
• 管理者ヘルプ: 個別の症例ルーティング基準を設定する

Safety Data Expression Building Blocks

このリリースでは、Veeva Safety に Safety Data Expression Building Blocks が導入されています。管理者は、それぞれに Case データ評価式が含まれる 1 つ以上の Safety Data Expression Building Block レコードを作成できます。管理者は、新しい Safety Data Expression Building Blocks レポート作成ルールパラメータを使用して、任意の数の Safety Rules 内でこれらの Safety Data Expression Building Blocks を参照する (およびオプションで組み合わせる) ことができます。これにより、Safety Rules をより効率的に作成できるようになり、Safety Rules の大規模なグループの管理に必要な労力が軽減されます。

詳細

• 管理者ヘルプ: Safety Data Expression Building Blocks の作成
• ユーザヘルプ: レポート作成ルールパラメータの参照

Submit to Gateway for Custom E2B Integrations

このリリースでは、Veeva Safety のゲートウェイへの自動提出アクションが改善されており、カスタム E2B Transmission ドキュメントの統合に対応しています。以前は、Vault は E2B Transmission ドキュメントの最初のバージョンを生成し、ゲートウェイに送信していました。これまで、カスタムの E2B Transmission ドキュメント統合を使用しているお客様は、エントリアクションを使用してドキュメントを生成し、Transmission を送信するように Transmission Lifecycle を構成する必要がありました。この機能強化により、お客様はカスタムの E2B Transmission ドキュメント統合と組み合わせて、ゲートウェイへの自動提出アクションを使用できるようになりました。

AS2 Connection: Sponsor Certificate Generation

このリリースでは、管理者が Vault 内で治験依頼者証明書を作成し、AS2 Connection で使用する機能が Veeva Safety に導入されています。以前は、これらの証明書は Vault の外部で作成する必要がありました。また管理者は、Vault の外部で作成された AS2 Connection の治験依頼者証明書を引き続きアップロードすることもできます。治験依頼者証明書を作成またはアップロードした後で、管理者は接続に関連付けられたパートナーと共有するための治験依頼者公開証明書をダウンロードできます。

詳細

• 管理者ヘルプ: AS2 接続証明書の管理

AS2 Connection: Deprecate API Name Support for Compression

このリリースでは、Vault は接続のデータを圧縮して送信するか圧縮せずに送信するかを決定するために、AS2 Connection の API Name を使用しなくなりました。代わりに Vault は、AS2 Connection の AS2 Compression Settings のみを使用して、接続の圧縮動作を決定するようになりました。以前は、接続の API Name が ucr_ で始まっている場合、接続の AS2 Compression Settings に関係なく、Vault はメッセージを圧縮せずに送信していました。

詳細

• 管理者ヘルプ:
  • FDA AS2 接続の設定
  • EMA AS2 接続の設定
  • カナダ保健省 AS2 接続の設定
  • MHRA AS2 接続の設定
  • PMDA AS2 接続の設定
  • NMPA AS2 接続の設定
  • RZN AS2 接続の設定
  • MFDS AS2 接続の設定
  • TGA AS2 接続の設定
  • カスタム AS2 接続の設定

AS2 Connection: Deprecate API Name Support for ACK on MDN Setting

このリリースでは、Vault は、接続が MDN URL で ACK を受け入れたかどうかを判断するために、AS2 Connection の API Name を使用しなくなりました。代わりに Vault は、AS2 Connection の AS2 Partner Sends ACK on MDN URL 設定のみを使用して、この動作を決定するようになりました。以前は、接続の API Name が ucr_russia_gateway で始まっている場合、AS2 Partner Sends ACK on MDN URL が No に設定されている場合でも、Vault は MDN URL で ACK を許可していました。

詳細

• 管理者ヘルプ:
  • FDA AS2 接続の設定
  • EMA AS2 接続の設定
  • カナダ保健省 AS2 接続の設定
  • MHRA AS2 接続の設定
  • PMDA AS2 接続の設定
  • NMPA AS2 接続の設定
  • RZN AS2 接続の設定
  • MFDS AS2 接続の設定
  • TGA AS2 接続の設定
  • カスタム AS2 接続の設定

Standardized Lifecycle State Changes

このリリースでは、Veeva Safety が他の Veeva アプリケーションと連携し、ライフサイクル状態の変更中に障害が発生した場合にオブジェクトレコードのライフサイクル状態が保持されます。たとえば Case は、障害が発生していない場合にのみ Data Entry から QC 状態に移行し、障害が発生した場合は Data Entry 状態に留まります。

詳細

• ユーザヘルプ: 症例データの入力

Assessment Dechallenge: Data Model

このリリースでは、Veeva Safety の Dechallenge および Dechallenge (Override) フィールドに Case Assessment オブジェクトが導入されています。このリリース以降、ユーザは内部参照のみを目的として、Dechallenge (Override) フィールドにデチャレンジ値を手動で入力できます。Dechallenge フィールドの自動入力は、将来のリリースで導入される予定です。

Safety Workbench

注: Veeva Safety Workbench はアーリーアダプターのお客様のみご利用いただけます。詳細については、Veeva 担当者にお問い合わせください。

Document Sensitivity Classification

このリリースでは、ユーザは Workbench Reports と Workbench Report Definitions に Document Sensitivity 値を設定できるようになりました。分類は生成されたレポートに継承され、Vault ライブラリにアップロードされたドキュメントに自動的に適用されます。

詳細

• ユーザヘルプ:
  • Workbench Reports の管理
  • Workbench Report Set の管理

Filter Workbench Reports and Dashboards by MedDRA Queries

このリリースでは、Veeva Safety Workbench に、Workbench Reports および Workbench Dashboards を、Case Adverse Events の Event (LLT) フィールドを使用して、標準またはカスタムの MedDRA Query 内で定義された任意の用語でフィルタリングする機能が導入されました。

この機能により、MedDRA クエリ内の用語が最下位レベルの用語 (LLT) に制限されなくなるため、フィルタ構成が簡素化されます。カスタムの MedDRA クエリも維持および再利用できるため、ユーザはより効率的にレポートを作成できます。

詳細

• 管理者ヘルプ: Safety Workbench で Safety ビューを追加する
• ユーザヘルプ:
  • Workbench Reports の管理
  • Workbench Report フィルタの使用

Use Workbench Report Parameters in SQL

このリリースでは、Veeva Safety Workbench は、Workbench Report の実行時に、関連付けられた Workbench View の SQL で直接参照できるレポートパラメータをユーザが入力できるようになりました。これにより、ユーザが作成した SQL を使用してユーザが作成できる Workbench Views の範囲が拡張されます。

詳細

• 管理者ヘルプ: Safety Workbench で Safety ビューを追加する
• ユーザヘルプ:
  • Workbench Report でのカスタムテンプレートの使用
  • Workbench Report フィルタの使用
  • Workbench Report Set の管理

Totals and Sorting for Grouped Data on Workbench Reports

このリリースでは、Veeva Safety Workbench は、Workbench Report レイアウトでグループ化されたデータをユーザが並べ替えられるようにすることで、アドホックのグループ化を強化しました。ユーザは、読みやすさと一貫性を向上させるために、Country や Seriousness などのグループ化されたフィールドごとにレポート結果を整理できます。さらに、ユーザはレポート出力ですべてのグループのサマリー合計を表示するように選択できます。この機能により、カスタム Workbench Views への依存が軽減され、サマリー表の作成が簡素化されます。

詳細

• ユーザヘルプ:
  • Workbench Report レイアウトの設定
  • Workbench Report でのカスタムテンプレートの使用

Multi-Level Sorting for Workbench Reports and Dashboards

このリリースには、Veeva Safety Workbench に複数レベルのレポート並べ替えが導入されています。ユーザは、アドホックレポートとダッシュボードの複数のフィールド列を基準として並べ替えることができるようになりました。この機能により、レポートデータ編成の柔軟性とユーザ制御が向上し、複雑な並べ替え要件を提供するために SQL を使用する必要性が軽減されます。

詳細

• ユーザヘルプ:
  • Workbench Report レイアウトの設定
  • Workbench ダッシュボードでデータを並べ替える

Generate Case Collections from a Workbench Case Series

このリリースでは、Veeva Safety Workbench により、Workbench Case Series から Case Collection を生成して、Veeva Safety で使用できます。これにより、CIOMS I のマスクなしレポートとマスク化レポート、および E2B(R3) レポートを一括生成して共有できるようになります。Case Collections は最大 1,000 個の Case バージョンをサポートし、外部パートナーとのデータ交換を効率化します。

詳細

• 有効化: Workbench Case Series からの症例コレクションの生成を有効にする
• ユーザヘルプ: Workbench Case Series からの症例コレクションの生成

Generate Reports from Workbench Report Definitions

このリリースでは、Veeva Safety Workbench により、Workbench Report Set を必要とせずに、Workbench Report Definition から直接新しいレポートを生成できます。Workbench Report Definitions からレポートを生成すると、管理者はレポート生成の標準を実装でき、ユーザはレイアウト、テンプレート、および詳細オプションを再利用して一貫性を高めることができます。この機能は、ユーザによるレポート標準の採用をサポートし、再利用可能で検出可能なレポートテンプレートを通じて効率性を向上させます。

詳細

• 有効化: Workbench Report Definitions からのレポート生成を有効にする
• ユーザヘルプ: Workbench Report Definitions からのレポートの生成および実行

Workbench Report Set Scheduling

このリリースでは、スケジュールに従って Workbench Report Set から Workbench Report を自動的に実行する機能が Veeva Safety Workbench に導入されました。これにより、タイムリーなコンプライアンスが確保され、定期的なレポートの生成に必要な手作業の負荷が軽減されます。

Workbench Report Set を作成するときに、ユーザは定義済みのスケジュールを選択して、Vault が次の操作を実行できるようにします。

• 指定されたスケジュールで Workbench Report Set 内のすべての Workbench Report を実行する
• 生成された Workbench Report Excel ファイルを Library にアップロードする
• Workbench Report Set の閲覧者に新しいレポートドキュメントを通知する

詳細

• 有効化: Workbench Report Set のスケジューリングを有効にする
• 管理者ヘルプ: スケジュールレコードの設定
• ユーザヘルプ: Workbench Report Set からのレポートの生成および実行

Ability to Specify Products and Studies in Aggregate Reporting Groups

このリリースでは、集積レポート作成グループで Products と Studies を指定できるようになりました。これにより、DSUR などの Products または Studies に基づいた Workbench 集積レポートを生成する際のレポート作成プロセスが効率化されます。この機能により、レポートデータセットの選択基準が簡素化され、規制提出の一貫性と効率性が向上します。

詳細

• 管理者ヘルプ: 集積レポート作成グループの設定

Workbench DSUR Aggregate Reports

このリリースでは、Veeva Safety Workbench に、以下の開発の安全性に関する最新報告書 (DSUR) コンポーネントを生成する機能が導入されています。

• 臨床試験に由来する対象期間中の重篤な副作用ラインリスト
• 重篤な有害事象の累積表
• 臨床試験に由来する重篤な副作用
• 死亡した患者のリスト

また、以下の追加コンポーネントも含まれます。

• Case Series レポート
• Open Cases レポート

管理者は、特定の報告要件を満たすために、これらのレポートをマスク化形式とマスクなし形式で設定できます。

この機能は自動オン仕様ですが、一部のコンポーネントでは追加の設定が必要です。

詳細

• 管理者ヘルプ: Workbench DSUR Aggregate Report の設定
• ユーザヘルプ:
  • Workbench DSUR Aggregate Report の作成
  • Workbench Report での集積レポートテンプレートの使用

Workbench PBRER Aggregate Reports

このリリースでは、Veeva Safety Workbench に、以下の定期損益評価レポート (PBRER) コンポーネントを生成する機能が導入されました。

• 臨床試験に由来する対象期間中の重篤な副作用ラインリスト
• 臨床試験に由来する重篤な有害事象の累積表
• 市販後調査による医薬品副作用のサマリー表

また、以下の追加コンポーネントも含まれます。

• Case Series レポート
• Open Cases レポート

管理者は、特定の報告要件を満たすために、これらのレポートをマスク化形式とマスクなし形式で設定できます。

この機能は自動オン仕様ですが、一部のコンポーネントでは追加の設定が必要です。

詳細

• 管理者ヘルプ: Workbench PBRER Aggregate Report の設定
• ユーザヘルプ:
  • Workbench PBRER Aggregate Report の作成
  • Workbench Report での集積レポートテンプレートの使用

Safety Signal

注: Veeva Safety Signal はアーリーアダプターのお客様のみご利用いただけます。詳細については、Veeva 担当者にお問い合わせください。

EBGM Calculations Updated with Case Counts

このリリースでは、Veeva Safety Signal は Empirical Bayes Geometric Mean (EBGM) 計算で使用される標準ビューを更新し、製品とイベントのペア数ではなく、固有の Case 数を使用するようになりました。FDA などの機関は EBGM の計算で固有の Case 数を考慮することが多いため、このアプローチで重複したレポートや規制上の意思決定の影響が軽減され、正確性が向上します。

詳細

• ユーザヘルプ:
  • シグナル検出の計算
  • PV Data を使用したシグナル検出

FAERS Case Reconciliation Report

このリリースでは、Veeva Safety Signal に Workbench Report が導入されました。このレポートは FAERS データを使用して実行され、FAERS と Veeva Safety 間の調整をサポートするために Case リストを生成します。このレポートでは、Safety では見つからない FAERS の症例が特定され、その後、潜在的なシグナル分析のためにレビューされます。この機能は、症例の完全性と保健当局が報告するデータとの整合性をサポートしています。

注: この機能を使用するには、Veeva Safety Workbench のライセンスが必要です。

詳細

• ユーザヘルプ: FAERS と VAERS の調整

VAERS Case Reconciliation Report

このリリースでは、Veeva Safety Signal に Workbench Report が導入されました。このレポートは VAERS データを使用して実行され、VAERS と Veeva Safety 間の調整をサポートするために Case リストを生成します。このレポートでは、Safety では見つからない VAERS の症例が特定され、その後、潜在的なシグナル分析のためにレビューされます。この機能は、症例の完全性と保健当局のワクチン安全性データとの整合性をサポートしています。

注: この機能を使用するには、Veeva Safety Workbench のライセンスが必要です。

詳細

• ユーザヘルプ: FAERS と VAERS の調整

Individual Case Review for Signal Analysis

このリリースでは、Veeva Safety Signal にシグナル検出のための個別の Case レビュー (ICR) が導入されます。シグナル ICR は、ルーティングルールに基づいて自動的に作成され、特定の Case Products にリンクされます。シグナルレビュー担当者は、進行中の Case 処理に影響を与えることなく個々の Case を評価し、Safety Investigation が必要かどうかを判断できます。

詳細

• 有効化: シグナルの個別の症例レビューの実行を有効にする
• ユーザヘルプ: シグナルの個別の症例レビューの実行

Signal Case Series Generation with Scheduled Calculations

このリリースでは、スケジュールされた Signal Calculations によって、Signal Case Series を自動的に生成できるようになりました。Case シリーズは、基礎となる Case データを表し、シグナル分析用の Case バージョンの静的リストを維持します。この機能により、手動のシグナル計算とスケジュールされたシグナル計算間の一貫性が確保されます。

詳細

• 管理者ヘルプ: Scheduled Signal Calculations & Alerts の設定
• ユーザヘルプ: Scheduled Signal Calculations & Alerts

SafetyDocs

Literature Article QC Sampling

このリリースでは、Veeva SafetyDocs に、文献記事のランダム化品質管理 (QC) サンプリングを実施する機能が導入されました。設定すると、SafetyDocs は指定されたサンプリングパーセンテージを使用して、選択された判定を含む Literature Articles をレビューワークフローにルーティングし、データ品質を確保します。

詳細

• 有効化: 文献レビュープロセスの管理の有効化
• ユーザヘルプ: 文献レビュープロセスの管理

Literature Inclusion in Aggregate Reports

このリリースでは、Veeva SafetyDocs は Literature Articles および Literature Article Products に関する追加の判定をサポートし、ユーザは集計レポートに含める記事を評価できるようになりました。この機能では以下が導入されます。

• Literature Articles と Literature Article Products に関する 2 つの新しい集計レポート関連フィールド
• 含めるようにマークされた Literature Articles と Literature Article Products をフィルタリングし、Product Family と Access Date でプロンプトフィルタリングする新しい標準レポートタイプ

詳細

• 管理者ヘルプ: 集積レポートに文献を含める操作を有効にする
• ユーザヘルプ: 文献レビュープロセスの管理

Automated Distribution of PVA Reports

このリリースでは、Veeva SafetyDocs はスケジュールされた PVA Vault Report または Workbench Report Set ドキュメントの自動配布をサポートしています。これにより、手動によるディスパッチの必要がなくなり、定期的なレポートを回覧する際のパートナーとのコミュニケーションが効率化されます。

詳細

• 有効化: PVA スケジューリングの有効化
• ユーザヘルプ:
  • 電子メールでの PVA ドキュメントの配布
  • Vault タスクを使用した PVA ドキュメント配布
  • 医薬品安全性監視アグリーメントの管理

Multi-Recipient PVA Document Distribution

このリリースでは、Veeva SafetyDocs の PVA ドキュメントの配布機能が拡張され、PVA Activity ドキュメントを 1 人のユーザだけでなく複数のユーザに配布する機能が導入されています。この機能強化により、パートナー組織からのバックアップサポートを必要とする PVA 配布への対応能力が向上します。この機能は、電子メールと Vault タスクベースの両方の PVA アクティビティの配布で利用できます。

詳細

• 有効化: 複数の受信者への PVA ドキュメント配布を有効にする
• ユーザヘルプ:
  • 電子メールでの PVA ドキュメントの配布
  • Vault タスクを使用した PVA ドキュメント配布
  • 医薬品安全性監視アグリーメントの管理

Document State Automation for PVA

このリリースでは、Veeva SafetyDocs の PV Agreement オブジェクトに 2 つの新しいアクションが導入され、リンクされた PV Agreement. の状態と一致するように、Vault が特定のドキュメントを Vault の固定状態または過去版状態に更新できるようになりました。これにより、PVA ドキュメントは関連する PV Agreement の状態に応じて自動的に状態を遷移できるようになり、Vault で PVA ドキュメントを管理するために必要な手作業の労力が軽減されます。

詳細

• 有効化: Document State Automation for PVA を有効にする
• ユーザヘルプ: 医薬品安全性監視アグリーメントの管理

Risk Implementation Strategy Enhancements

このリリースでは、Veeva SafetyDocs のリスク実装戦略管理が強化されており、以下の点でより具体的な対応が可能になります。

• Copy to New Version および Create Local Implementations アクションが更新され、Core Implementation Strategy ドキュメントの新しいバージョンが作成されないようになりました。これにより、ユーザはより柔軟に更新できるようになります。
• 以前の Global Risk Measure がない地域に対して、ローカル専用の Local Risk Measures を作成するように、Create Local Implementations が拡張されています。
• すでに Local Implementation Strategy が存在する Countries に対して重複した Local Implementation Strategy レコードが作成されないようにすることで、重複レコードの可能性を排除します。

詳細

• ユーザヘルプ: 実装戦略の管理

Multiple Product Families on Safety Investigations

このリリースでは、ユーザは新しいオブジェクト Safety Investigation Product を使用して、複数の Products および Product Families を Safety Investigation に含めることができるようになりました。以前は、Safety Investigation に追加できるのは、主要な単一の Product Family のみでした。この機能により、複数の Products および Product Families にわたる安全性の問題を調査する際の柔軟性が向上し、調査アプローチがより包括的なものになります。たとえば、Safety Investigation の主要な Product と同時に実行される、または相互作用する Products および Product Families を含めることができるようになります。

詳細

• 有効化: 安全性調査で複数の製品ファミリーを有効にする
• ユーザヘルプ:
  • シグナル管理
  • 安全性調査の作成

Safety & Safety Workbench

Latest Case Version in Period for Ad-Hoc Reporting & Analytics

このリリースでは、Veeva Safety は、Case バージョンを置き換えるタイミングを判断するための更新されたアプローチを導入しています。Vault では、フォローアップ Case の作成時ではなく、Case が終了状態に達した場合にのみ、Cases が置き換えられたものとしてマークされるようになりました。さらに、Case のバージョン履歴の可視性を高め、レポートと分析をサポートするために、Vault では新しいアプリケーション設定が導入されています。有効にすると、Vault は次の新しい Case オブジェクトフィールドを通じて、過去版の Cases に日付情報をさらにマッピングします。

• Next Case Version
• Next Case Version New Info Date
• Next Case Version Approval Date

詳細

• 有効化: アドホックレポートおよび分析の期間中の最新の症例バージョンを有効にする

Safety Workbench & SafetyDocs

Distribute Workbench Reports Externally

このリリースでは、Veeva SafetyDocs の PVA スケジューリング機能とドキュメント配布機能が Workbench に拡張され、以下の機能が追加されました。

• 定義されたスケジュールに従って、Workbench Report Set から Workbench Report とそのドキュメントを自動的に生成する
• これらのドキュメントを Vault タスク経由で PVA Activities として、またはメール経由で外部パートナーに配布する

この機能強化により、レビューのためにパートナーにドキュメントを配布するために必要な手作業が削減され、スケーラブルなパートナー配布が可能になります。

詳細

• 有効化: 外部への Workbench Report の配布を有効にする
• ユーザヘルプ: 医薬品安全性監視アグリーメントの管理

QualityOne

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

QualityOne

New Application: QualityOne HACCP

このリリースでは、既存の HACCP 機能を新しいアプリケーションである QualityOne HACCP に移行しました。QualityOne HACCP を使用すると、組織は製造拠点や地域全体で安全な食品生産手順を確立し、維持することができます。HACCP 機能を新しい QualityOne HACCP アプリケーションに移行することで、お客様は QualityOne ソリューションの柔軟性をさらに高めることができます。

詳細に関しては、QualityOne HACCP をご覧ください。

注: QualityOne HACCP は現在、アーリーアダプターのお客様のみご利用いただけます。詳細については、Veeva 担当者にお問い合わせください。

Tree & Child Object Security on Standard Objects

Tree Security および Child Object Security プラットフォーム機能は、特定の Veeva Vault アプリケーションにのみ適用され、QualityOne 標準オブジェクトには適用されません。

QMS (QualityOne)

5 Whys Analysis: UX & Permission Error Handling Enhancements

このリリースでは、特に重要な権限が不足している場合に、5 Whys Analysis のユーザインターフェースに個々のユーザ権限がより正確に反映されるようになりました。たとえば、ユーザに Why レコードに対する Delete 権限がない場合、対応する削除アイコンは無効になります。また、ユーザが Why オブジェクトなどの特定の要素を操作しているときに権限の問題に遭遇した場合、状況の解決方法に関するガイダンスを含む、より明確で詳しいメッセージが表示されます。

詳しくは、5 Whys Analysis の実行をご覧ください。

CoA: Ingest Text-Based Variations of Comparison Symbols

この機能により、「larger than」や「less than」など、比較演算子記号の言語ベースのバリエーションを含む CoA ファイルの取り込みが改善されます。このリリースでは、管理者は Comparison Variant レコードを作成して、Vault が CoA ファイルからこれらのバリエーションを抽出し、Inspection Sample Test Result レコードの対応する記号の値を設定できるようになり、大規模な CoA ファイル処理の正確性と効率が向上します。

詳しくは、Comparison Variants の設定をご覧ください。

注: この機能は現在、アーリーアダプターのお客様のみご利用いただけます。詳細については、Veeva 担当者にお問い合わせください。

CoA: Supplier Site Address Ingestion Improvement

この機能により、Organization データモデルが強化され、ユーザはより詳細な住所データを入力できるようになるため、CoA ファイルから住所情報が正常に取り込まれる可能性が高まります。Analyze COA アクションが実行されると、Vault は新しい Address オブジェクトと、設定済みの Organization Matching Variant のデータを使用し、CoA ファイルをスキャンして最も近い住所を検索し、一致が見つかると、Inspection レコードをサプライヤー施設の住所で更新します。一致する住所が見つからない場合、Inspection レコードの住所は更新されず、既存データの整合性が維持されます。この機能により、Organization の住所データの取り込みの精度と制御が向上し、CoA ファイルのストレートスルー処理が向上し、手動によるデータ入力が削減されます。

詳しくは、Organization Matching Variant の管理をご覧ください。

注: この機能は現在、アーリーアダプターのお客様のみご利用いただけます。詳細については、Veeva 担当者にお問い合わせください。

HACCP

注: QualityOne HACCP は現在、アーリーアダプターのお客様のみご利用いただけます。詳細については、Veeva 担当者にお問い合わせください。

Manage HARPC within the Flow Diagram

このリリースでは、HACCP フロー図で、より広範で積極的な危険性分析アプローチを実現する危険性分析およびリスクベースの予防管理 (HARPC) プロセスがサポートされるようになりました。HARPC 機能により、組織はすべての潜在的な危険を評価し、予防管理を実施して食品生産プロセス全体のリスクを軽減できます。これにより、別個のシステムを必要とすることなく、食品安全強化法 (FSMA) や同様の EU 規制などの世界的な規制や安全性基準に対するコンプライアンスが強化されます。

詳しくは、HARPC プランの作成と危険性分析の実行をご覧ください。

Add Materials to HACCP Plan

これまでユーザは、最終製品または半製品を表すために、単一の Material レコードを HACCP Plan に関連付けることしかできませんでした。このリリースでは、ユーザは、HACCP Plans の新しい HACCP Plan Materials セクションから HACCP Plan - Material レコードを作成することにより、HACCP Plan に複数の材料を追加できます。さらに管理者は、翻訳された材料フィールドデータを表示するように HACCP Plan Materials セクションを設定できます。この機能により、組織は同じ HACCP Plan を複数の類似製品間で再利用できるため、HACCP プログラムの全体的な効率が向上します。

詳細については、configuring the HACCP Plan Materials section および adding materials to HACCP Plans をご覧ください。

HACCP Flow Diagram: Configurable Information Panel

このリリースでは、管理者は Information パネルを設定して、ユーザのワークフローに関連するセクションとフィールドのみを表示できるため、効率が向上します。この機能により、管理者は、これらのプロセスが図の外部で管理されることを想定して、Hazard Assessment セクションおよび Categorization of Control Measures セクションを無効にしたり、Hazard Assessment セクションおよび Potential Hazard Description セクション内でフィールドを追加および削除したりできます。

詳細については、HACCP フロー図の設定と HACCP フロー図の使用をご覧ください。

HACCP Flow Diagram: Minimap Navigation

このリリースでは、HACCP Flow Diagram のキャンバスにミニマップが表示され、ユーザは大規模な HACCP Plans をすばやくナビゲートできるようになりました。ミニマップには、HACCP Flow Diagram の構造が表示され、ユーザの注目領域が強調表示されます。ユーザはミニマップをクリックしてドラッグし、図内のさまざまな領域に移動できます。この機能により、ナビゲーションとコンテキスト認識が向上し、ユーザは何度もスクロールしたり拡大/縮小しなくても、図のさまざまな部分を即座に見つけて移動できるため、時間と労力を節約できます。

詳細については、HACCP フロー図の使用をご覧ください。

HACCP Flow Diagram: Resizable Information Panel

以前は、Information パネルは固定サイズに制限されていました。このリリースでは、Information パネルの端をクリックしてドラッグし、画面サイズに合わせて幅を大きくしたり小さくしたりすることができます。この機能により、ユーザは一度により多くのデータを確認できるため、危険性分析の効率と容易さが向上します。

詳細については、HACCP フロー図の使用をご覧ください。

Process Step Search within the HACCP Flow Diagram Canvas

この機能により、HACCP フロー図のキャンバスに検索バーが追加され、表示名でプロセスステップを検索できるようになります。これにより、ユーザはフロー図全体を手動でスクロールすることなく、関連する詳細情報にアクセスして管理できるようになります。

詳細については、HACCP フロー図の使用をご覧ください。

HACCP Flow Diagram: Hazard Analyses Section Filtering

この機能は、以前にリリースされた Hazard Analyses セクションのページネーション機能と連携して、Hazard Analysis セクションに表示されるレコードのリストを、1 つ以上の Hazard Classification 値と特定のハザード分析の完全性ステータスに一致するようにフィルタリングする機能を提供します。

詳細については、working with the Information panel および performing hazard analysis をご覧ください。

HACCP Flow Diagram: Subsequent Steps Enhancements

このリリースでは、ユーザが危険性分析中に後続のステップを追加または削除すると、Information パネルの Hazard Analyses セクションにある Process Hazard Analysis および PHA - Subsequent Step レコードに表示されているレコードリストと危険性分析の完全性ステータスおよび理由が自動的に更新されます。これにより、ユーザはパネルを更新しなくても最新の情報を表示できるようになります。また、ユーザが一度に追加または削除できる後続のステップ数は 50 個までに制限されます。

詳しくは、後続のステップの追加をご覧ください。

HACCP Plan Translation: File Size Limit

ユーザが HACCP Plan の翻訳ファイルをエクスポートおよびインポートする場合、Vault では JSON ファイルのサイズが 250 MB に制限されるようになりました。

詳しくは、HACCP プランの翻訳をご覧ください。

QualityOne Client Application

以下の QualityOne クライアントアプリケーションは、2025 年 8 月 8 日のリリースを目標にしています。

• Apple App Store リリース: QualityOne 監査チェックリストモバイル、および QualityOne Station Manager
• Google Play リリース: QualityOne 監査チェックリストモバイル

注: QualityOne Station Manager には互換性アップデートのみが含まれており、25R2 の新機能は含まれていません。Android 版 QualityOne 監査チェックリストモバイルには、軽微な問題の修正と互換性アップデートのみが含まれており、25R2 の新機能は含まれていません。

Audit Checklist Mobile for iOS: Save Progress to Vault

この機能により、QualityOne Audit Checklist Mobile の iOS バージョンのユーザは、一部完了した監査チェックリストの進行状況をモバイルから Vault に保存できます。Vault またはモバイルでチェックリストの編集を続行することもできます。この機能は、25R1 において QualityOne Audit Checklist Mobile の Android バージョンのためにリリースされました。

Audit Checklist Mobile for iOS: Requiredness Indicator

この機能により、QualityOne Audit Checklist Mobile アプリケーションの iOS バージョンの UI が強化されます。このリリースでは、監査チェックリスト上の必須の質問、コメント、添付ファイル、Audit Finding フィールドに、必須を示すインジケータが表示されるようになりました。

詳細については、QualityOne Audit Checklist Mobile の使用をご覧ください。

QMS (QualityOne) & Document Control (QualityOne)

External Collaboration Management: Enhanced License Assignment

このリリースでは、Create and Activate External Collaborator アクションで作成された外部ユーザには、QMS または Document Control のライセンスが排他的に割り当てられるようになりました。これにより、シームレスな外部コラボレーションプロセスが保証され、他の Vault アプリケーションとのライセンスの競合が防止されます。

外部コラボレーションについて詳しくは、QMS オブジェクトおよびドキュメントのレビューと承認をご覧ください。

QMS (QualityOne) および HSE

Audit Checklist Reassignment

この機能によりユーザは、Audit Checklist オブジェクトに対する Reassign Audit Checklist ユーザアクションを使用して、監査チェックリストを完了するタスクを別のユーザに再割り当てできます。この機能を使用すると、監査チェックリストを完了する担当者がいなくなった場合でも、ユーザは新しい担当者に割り当てるために別の Audit Checklist レコードを生成することなく、簡単にタスクを再割り当てできます。

詳細については、監査チェックリストの再割り当てをご覧ください。

Generate Document From Formatted Output Action: Word Formatted Outputs Compatibility Update

このリリースでは、QualityOne の Generate Document From Formatted Output アクションは、Word Formatted Output テンプレートを使用して PDF と Word の両方のドキュメントの生成をサポートします。この更新により、ユーザは、Word Formatted Output テンプレートによって提供される柔軟性、セットアップ、メンテナンスの向上のメリットを享受できるようになります。

ドキュメントの生成およびドキュメント生成の設定の詳細をご覧ください。

Enhance Create Audit Record & Create Proposed Audits Actions

この機能は、Create Audit Record アクションと Create Proposed Audits アクションを拡張し、生成されたオブジェクトレコードのフィールド入力の正確性を向上させます。

Proposed Audit オブジェクトおよび Audit オブジェクトについて詳しくは、監査プログラムでの作業およびフィールド入力の設定をご覧ください。

Audit Report Printable View Enhancements

この機能により、Audit Report Printable View 機能の使いやすさが向上し、より直感的な改ページの動作、チェックリストの質問に対する制限の引き上げ、PDF ドキュメントのページ幅の最適化などが可能になります。

詳細については、Audit Report Printable View の操作をご覧ください。

QMS (QualityOne), HSE, & Training Management

Compatibility with Platform Available Answer Enhancements

現在、チェックリストの Available Answer データモデルに対する Platform の改善との互換性を確保するために、チェックリストから Action Items を作成する機能や QualityOne Audit Checklist Mobile アプリケーション内の機能など、QualityOne 固有のチェックリスト機能がリファクタリングされています。これにより、継続的な効率性、スケーラビリティ、および強化された Platform のチェックリスト機能とのシームレスな互換性が保証されます。

詳細については、working with audit checklists および using QualityOne Audit Checklist Mobile をご覧ください。

RegulatoryOne

25R2 以降のすべてのリリースでは、RegulatoryOne は、Veeva Vault Platform と同日にリリースされます。

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

RegulatoryOne

Packaging Hierarchy Data Model Updates

この機能は、Formulation オブジェクト内のパッケージの詳細を統合することにより、パッケージデータの機能を強化します。この効率化されたアプローチにより、これまでパッケージデータでは利用できなかった処方アンケートや定量評価などの高度な機能が利用できるようになります。

Tree & Child Object Security on Standard Objects

Tree Security および Child Object Security プラットフォーム機能は、特定の Veeva Vault アプリケーションにのみ適用され、RegulatoryOne または Veeva Claims 標準オブジェクトには適用されません。

レジストレーションおよびドシエ管理

Manage Registrations from Events

この機能により、ユーザは Registrations と Registration Objectives を作成し、Event に関連付けられたすべての Registration Items に登録データを入力できるため、ユーザが大規模なドシエを 1 人で管理するための時間と手順が削減されます。

Event に関連付けられたすべてのドシエについて詳しくは、登録データの生成およびRegistrations と Registration Objectives の作成をご覧ください。

Manage Requirements from Events

この機能により、ユーザは Event に関連付けられた Requirements を作成および更新できます。そのため、ユーザが大規模なドシエを 1 人で管理するための時間と手順が削減されます。

詳細については、Event 内のすべての Registration Objectives に対する generating Requirements をご覧ください。

Create Missing Documents for Requirements from Events

この機能により、複数のドシエ間で同じドキュメントテンプレートを使用する Requirements を効率的にグループ化することで、Event の複数のドシエの Requirements に対して不足しているドキュメントを作成できます。

Event について詳しくは、テンプレートからドシエドキュメントを自動作成するをご覧ください。

Veeva Claims

25R2 以降のすべてのリリースでは、Veeva Claims は、Veeva Vault Platform と同日にリリースされます。

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

Veeva Claims

Selectively Create Claims Dialog Enhancements

この機能により、表示される Statements 数と Products 数の増加など、Selectively Create Claims ダイアログの使いやすさが複数の点で向上します。

詳しい使い方については、Selectively Create Claims ダイアログをご覧ください。

Enable Hierarchical Copy for Project Local Adaptations

この機能により、管理者は Copy Record アクションを設定できるため、ユーザはコピーした Local Adaptation を既存のリンクされた Projectに追加できるようになります。これにより、地域内の国向けに Local Adaptation のコピーを作成する場合など、ユーザが新しくコピーした Local Adaptations を既存の Projectsにリンクする必要があるプロセスが効率化されます。

Tree & Child Object Security on Standard Objects

機能説明をご覧ください。