Viedoc での査察対応

査察対応

規制当局は、臨床試験で使用されているシステムに関する関連ドキュメントを確認できることを期待しています。しかし、何が重要なのか、スポンサーやその代理人（CRO）は何を手元に置くべきなのか、システムサプライヤーが保有するものとして何が認められるのか。

本書では、臨床試験における被験者データの収集にViedocのようなマルチテナントクラウドソリューションを使用する際に考慮すべき点について説明します。

EMA GCP IWG査察官の期待

2023年3月9日、EMAは「Guideline on computerised systems and electronic data in clinical trials（臨床試験におけるコンピュータ化システムと電子データに関するガイドライン）」EMA/INS/GCP/112288/2023を発表し、2023年9月9日に発効した。

EMAは本ガイドラインの附属書2.1「General Principles（一般原則）」（コンピュータ化システムのバリデーション）において以下のように述べています：

「責任者は、臨床試験で使用されるシステムが適切にバリデートされ、ICH E6 及び本ガイドラインで定義される要件を満たすことが実証されていることを確認すること。

システムは、責任当事者の要請により開発されたものであるか、商業的に入手可能であるか、自由に利用可能であるか、サービスとして提供されるものであるかとは無関係に、バリデーションされなければならない。

責任当事者は、ベンダーが実施したバリデーション活動及び関連ドキュメントが適切であると評価した場合には、システムのベンダーが提供するバリデーションドキュメントに依拠してもよい。」

さらに、次のようにも述べています。

「責任当事者がベンダーのバリデーションドキュメントを使用したい場合、責任当事者は、そのドキュメントが責任当事者の意図する使用方法、及び責任当事者の定義したニーズと要求事項を網羅していることを確認しなければならない。責任当事者は、ベンダーの品質システム及びバリデーション活動を熟知している必要がある。この審査は、資格のあるスタッフが、活動に十分な時間を費やし、ベンダーの協力を得て実施すべきである。実際の活動に十分に深く入り込み、適切な数の関連する主要要件と対応するテストケースをレビューし、このレビューをドキュメント化すべきである。審査報告書は、ベンダーのバリデーションプロセスとドキュメント化が満足のいくものであることをドキュメント化すべきである。欠点があれば、責任者は、例えば、追加のバリデーション活動を要求または実施することによって、それを緩和すべきである。

サービスプロバイダーによっては、システムの新版や更新版を急遽リリースする場合があり、責任当事者がバリデーションを実施したり、サービスプロバイダーから提供されたバリデーションドキュメントをレビューしたりするための十分な時間が残されていない場合がある。このような状況では、責任当事者が本番リリース前にベンダーのバリデーションプロセスを評価し、自らの定期的なレビューと変更管理プロセスを強化することが特に重要である。責任当事者は、新機能のバリデーションを行うか、ベンダーのドキュメントをレビューして評価するまで、新機能を使用すべきではない。

責任当事者がベンダーのバリデーションドキュメントに依存している場合、検査官は、責任当事者によるベンダーの検査の完全なドキュメントと報告へのアクセスを与えられるべきである。この検査が監査報告書にドキュメント化されている場合は、報告書へのアクセスを提供することが必要となる場合がある。責任当事者、または該当する場合は、審査業務を代行するサービスプロバイダーは、バリデーションドキュメントを詳細に理解していなければならない。

契約に関する附属書1に記載されているように、バリデーションドキュメントは、責任当事者又はシステムのベンダーのいずれから提供されるかにかかわらず、検査員が適時に利用できるようにすべきである。治験依頼者がシステムの使用を中止した場合、またはベンダーがシステムのサポートを中止した場合、もしくはその活動を停止した場合であっても、法的に定められた保存期間中、このドキュメントへの継続的なアクセスを確保するための契約上の取決めがなされなければならない。」

このドキュメントでは、Viedocが上記のEMAの期待事項を遵守するためにどのような支援を行っているかについて説明します。

FDA の期待

2017年6月、FDAはガイダンス案「Use of Electronic Records and Electronic Signatures in Clinical Investigations Under 21 CFR Part 11 - Questions and Answers」を発表しました。ドラフトガイダンスである本書は、まだ実施されておらず、拘束力のない推奨事項のみが記載されています。しかし、FDAの期待がEMAのそれと同様であることを明確に示しています。

このガイダンスの中でFDAは次のように書かれています。

「スポンサーやその他の規制対象団体は、規制要件を満たす責任がある。」

「スポンサー及び他の規制対象団体は、電子サービスベンダーとサービス契約を締結すべきである。契約を締結する前に、スポンサー又は他の規制対象団体は、電子サービスベンダーがパート11の要件及びデータセキュリティ保護措置を満たす能力に基づいて、電子サービスを評価し選択すべきである...。
サービス契約には、これらの特定要件及び電子サービスベンダーの役割と責任に関する明確な説明が含まれるべきである。」

スポンサーと他の規制対象団体は、外部委託された電子サービスを使用する規制対象施設のそれぞれで、FDAの要求に応じて以下の情報を入手できるようにしておくべきである。

外部委託された電子サービスの特定の要件

電子サービスベンダーに期待されることを定義したサービス契約書

「外部委託された電子サービスが適切にバリデートされていることを確認するのは、最終的にはスポンサー又は他の規制対象の事業者の責任である。スポンサー及びその他の規制対象組織は、アウトソーシングされた電子サービスが意図された方法で機能することを立証するために、標準的な操作手順及びテストとバリデーションの結果の説明を含む（ただしこれに限定されない）ドキュメントを電子サービスベンダーから入手するべきである。」

このドキュメントでは、Viedocが上記のFDAの期待に応えるためにどのように支援するかを説明しています。

PMDA の期待

PMDAは2013年3月、臨床試験でEDCを使用する際に記入する「EDC管理シート」を公表しました。その第1章「記載上の注意事項」では、本書の基本的な考え方について以下のように書かれています。

「EDCを利用した治験等について、データ等の品質確保に関するプロセスの概要等を記載すること。
電磁的記録の使用においては、データの改ざんや消失の発生を未然に防ぐため、適切なシステムの選定、適切なユーザーへの入力及び修正権限の付与、権限を付与されたユーザーによる適切な利用等が重要になることから、これらのデータ等の品質確保のための手段、手順等について、具体的に記載すること。」

このドキュメントでは、ViedocがPMDAの期待に応えるためにどのように支援するかを説明しています。

薬事申請準備パッケージ

臨床試験用システムの調達

Viedocでは、Viedocのバリデーションを信頼していただくことをお勧めします。これは、お客様がViedocを臨床試験向けに選択する際に、当社が提供するサービスの考え方の一つでもあります。私たちにお任せいただければ、多くの時間、労力、そして精神的負担を軽減することができます。

薬事申請準備パッケージ (VIRP: Viedoc Inspection Readiness Packet)は、規制当局の期待に応えるために必要な情報を提供します。

常時利用可能なViedocドキュメント

規制当局は、臨床試験に使用されるEDCシステムを、被験者の安全性とデータの完全性の両方に関して重要なコンピュータ化されたシステムであるとみなしています。規制当局は、スポンサーがこのシステムを完全に理解していることを期待しています。スポンサー（または業務委任されているCRO）は、使用するEDCシステムの機能を完全に理解し、その理解度を示し、そのシステムがどのようにバリデートされたかを説明できることが期待されています。

Viedocでは、URSをEpic、Feature、User Storyからなる分かりやすいフォーマットで公開しています。

Epicは、監査証跡、ePRO、医療コーディングなど、Viedoc内のモジュール全般を説明します。
Featureは、Viedoc Connect、フォームリンクアイテム、電子メールアラートなど、特定の機能をより詳細に設営します。
User Storyは、システム開発者がViedocを設計、実装、バリデーションする際に使用する、詳細かつ細分化された要件です。

査察官の期待に応えるために、私たちはViedocのすべてのリリースに以下のドキュメントを提供しています。

User Requirement Specification（URS:ユーザー要求仕様書）：リリースに含まれるEpicとFeature¹を説明し、User Storyをリストアップしています。
User Requirement Traceability Matrix: URSの各要件に対して実施されたテストの詳細です。
Validation Summary Report: このリリースで実施されたバリデーション活動とその結果です。
Release Note: 各リリースで Viedoc に追加された内容の説明です。
Release Certificate: 各リリースの実装と関連する活動において、ドキュメント化された手順に従ったことを証明する証明書です。
EDC Checklist: PMDAに提出するための EDC管理シートです。
Acknowledgement Form（確認書）: レビューの必要性を説明し、レビューが完了したことを証明するために署名する欄があるフォーム。
Quality System TOC: Viedoc Technologies がこのリリースの開発に適用した、該当する SOP のリストです。
VIRP Introduction: 薬事申請準備パッケージ(VIRP : Viedoc Inspection Readiness Packet )の内容を説明した序文です。

独自に作成するドキュメント

Viedocでは、Epicレベルの試験に必要な機能（無作為化モジュール、患者ePROモジュール、コーディングモジュールなど）および、必要に応じて個々のFeatureのチェックリストを使用することを推奨しています。

各モジュールがどのように開発され、設定され、実際に動作するかについての実際の詳細は、通常、重要ではありません。あなたはシステムを使用するだけであり、それを開発するわけではないので、要件にこのレベルの詳細を定義する必要はありません。必要な情報は、トレーニングやシステムドキュメントでカバーされているため、担当者は臨床試験でシステムを使用する方法を知ることができます。

私たちが推奨するように、期待されるEpicとFeatureのチェックリストを使用して臨床試験に使用するシステムを定義した場合、Viedocがチェックリストに定義した各Epicを持っていることをドキュメント化するだけでよいのです。これは通常1～2ページのドキュメントで、各必要なEpicにYes、No または Partly のチェックボックスを持つものになります。いずれかのモジュールの回答が「No」または「Partly」である場合、そのモジュールのワークアラウンド（例：システムの代わりに手続き、または代替システム）の説明を調査に含める必要があります。

では、ViedocのURSを責任をもって管理するのは誰になるでしょうか。私たちViedocです。私たちは、Viedocの開発に必要なすべての要件を指定し、Viedocの各リリースにおいてこれらの要件をバリデーションする責任を負っています。私たちは、すべての要件、テストケース、および完全なトレーサビリティのためのテストケースの実行結果を保存する高度な要件データベースを含む最新の開発手法とツールを採用しています。このデータベースは、Viedocの各リリースの新しい要件、テストケース、テスト結果で更新され、Viedocのすべての新バージョンはリリース前に完全にバリデーションされます（このバリデーションはドキュメント化されます）。この情報は、ユーザー要求仕様書とトレーサビリティ・マトリックスを作成するために使用され、各リリースの薬事申請準備パッケージの一部として同梱されます。

査察官が閲覧を希望する場合は、詳細な要件、テストケース、テストレポート、テストエビデンスを当社から入手できますが、Viedocは複雑なシステムであり、完全な要求仕様と関連するすべてのバリデーションドキュメントが複雑であるため、査察官に情報を案内する必要があります。また、要求仕様書や関連するバリデーションドキュメントもすべて複雑なため、査察官が弊社に来社したり、オンラインでドキュメントについて説明したりすることができると有利になります。査察官が要件データベースに自由にアクセスできるようにするには、すべての査察官が持っているわけではない、システム開発知識に関する専門的なトレーニングが必要になります。

管理すべき追加ドキュメント

Viedoc 薬事申請準備パッケージを利用する場合、どのような責任がユーザーにはありますか？

URSを独自に作成する代わりに、当社のViedoc 薬事申請準備パッケージに頼るという決定をドキュメント化する必要があり、規制当局はこれをリスクベースの評価という形で行うことを推奨しています。

ICH E6（GCP）R2 には次のように書かれています：

「バリデーションのアプローチは、システムの使用目的、被験者保護及び臨床試験結果の信頼性に影響を及ぼす可能性を考慮したリスクアセスメントに基づくべきである。」

EMAはガイドラインの中でこう書かかれています。

「責任者は、ベンダーが実施したバリデーション活動及び関連文書が適切であると評価した場合、システムのベンダーが提供するバリデーション文書に依拠することができる。」

また、FDAはガイダンス案で次のように書いている。

「外部委託された電子サービスについては、検証にリスクベースのアプローチをとるべきである。」

Viedocの品質システムおよび認定活動を理解していることを示すことができなければなりません。規制当局の期待については、EMAの「Guideline on computerised systems and electronic data in clinical trials（臨床試験におけるコンピュータ化されたシステムと電子データに関するガイドライン）」に詳しく記載されていますが、以下のようなものがあります
- 責任者は、ベンダーの品質システムおよびバリデーション活動について十分に理解している必要があります。この理解は、通常、体系的な詳細な調査（例：監査）を通じて得ることができます。
- この調査は、資格を持つスタッフによって行われるべきであり、十分な時間をかけて活動が実施され、ベンダーの協力が必要です。
- 調査は実際の活動に十分に深く入り込み、関連する重要な要件および対応するテストケースの適切な数が確認されるべきです。また、この確認は文書化されなければなりません。
- 調査報告書には、ベンダーのバリデーションプロセスおよび文書が満足のいくものであることが記載されるべきです。何らかの不備がある場合、責任者はそれを軽減するために、追加のバリデーション活動の依頼や実施などの対策を講じるべきです。
- 責任者、または該当する場合にはその代わりに調査活動を実施するサービス提供者は、バリデーション文書を詳細に理解している必要があります。

独自のURSを用意しない

多くの企業では、臨床試験で使用するシステムに期待する内容をユーザー要求仕様書（URS）で指定していますが、これは不必要であると同時に、大量の追加作業を生み出す可能性があります。

Viedocは顧客ごとに開発されることはありません。Viedocの顧客別バージョンは存在せず、顧客固有の開発やバリデーションは行われません。開発するシステムを定義するわけではないので、URSという形で要件をドキュメント化する必要はありません。

URSは、開発するシステムを規定するために使用されます。URSに直接付随することとして、URSのすべての要件がバリデーションされることが期待されています。システムを調達する手順の一部としてURSを作成した場合、そのシステムがURSのすべての要件を実際に満たしていることをバリデ―ションする必要があります。バリデーションを実施するのは、あなたユーザー自身です。URSに従ったシステムのバリデーションをシステムサプライヤーに依存する場合、サプライヤーがURSの各要件に対するテストケースを持っていることを証明できなければならず、テストケースとそのテストケースの実行結果の両方を査察官に見せることができなければなりません。試験中にシステムの複数のリリースが使用される場合、このテストは各リリースで繰り返されなければなりません。

実行する2つのバリデーション

ユーザーの責任 - 試験構成

Viedocは、標準機能（バリデーション済みの）を設定することで、個々の試験に適応させることができます。これは、お客様の試験のための試験プロトコルにシステムを適応させるために行われます。この設定は、お客様の担当者が行うこともできますし、弊社または第三者に委託して行うこともできます。

誰が試験設定を行うかにかかわらず、試験が試験プロトコルに準拠して設定されていることをバリデーションする責任はお客様自身にあり、Viedocの担当者に委任することはできません。

試験が正しく設定されていることを証明する一連のテストケースを定義し、それらのテストケースを実行した結果をドキュメント化する必要があります。これは、試験の複雑さや、バリデーションした以前の試験と同じかどうかなどの側面を含むリスク評価に基づいている必要があります。

試験中に試験構成に変更を加える場合（例えばプロトコルの修正）、これらの変更の結果必要となるバリデーションの程度を評価し、上記のステップに従ってバリデーションを実行する必要があります。

Viedocを使用する場合、スポンサーごとや試験ごとに顧客独自の開発は行われないため、Viedocのバリデーションに対する責任はこれが限界となります。

では、エディットチェックはどうでしょうか。試験ごとに行われる顧客独自のプログラミングの例ではないのでしょうか。Viedocでは、すべてのエディットチェックは「サンドボックス化」されています。つまり、エディットチェックは治験のデータにのみアクセスでき、そのデータを読むだけで、変更することはできません。既存の試験データから計算される派生値を定義することはできますが、元のデータを変更することはできません。エディットチェックによって試験データを変更したり、Viedocプログラムコードを変更したりすることはできません。エディットチェックの使用は、Viedocの基本的な機能の再バリデーションを必要とせず、試験のデータ完全性に対する危険もありません。唯一のバリデーション要件は、エディットチェックが複雑な場合、試験プロトコルに準拠しているかどうか、つまり、あなたが望むことを本当にチェックしているかどうかをバリデーションする必要があることです。

Viedoc の責任範囲 - Viedocの新リリースとEDCリリースチェックリスト

Viedocの新バージョンは、年に約7～8回（通常6週間に1回）リリースされます。各新バージョンは、リリース前に完全にバリデーションされています。これらのリリースはすべての本番サーバーに同時にインストールされるため、すべての顧客とすべての試験が同時に更新されることになります。

進行中の試験に影響を与えないようにするため、Viedocのすべての新しいリリースは、次の2つの要件を満たしています。

新しいリリースは、100%後方互換性があること。
そのリリースに含まれる新機能は、進行中の試験に対してデフォルトで無効化されること。

この2つの条件を満たすことで、リリースが進行中の試験に影響を与えないことを保証します。実際、進行中の試験は、新しいリリースが作られたことを通知しません。

100％後方互換性

この要件の理由は単純です。新しいリリースでは、進行中の試験の設定を変更したり、これらの試験の設定の再バリデーションを必要としたりしてはなりません。後方互換性を100％確保することで、すべてのユーザーにとって、試験が同じように見え、動作することを保証します。進行中の試験のユーザーから気づかれないようにViedocの新規リリースを実施できば場合に、成功と考えています。

新機能の無効化

これは、ユーザーがトレーニングを受けていない新機能が突然現れ、混乱やエラーの可能性を引き起こさないようにするためです。

試験管理者は、進行中の試験で表示されるようになる前に新しい機能を有効にする必要があり、試験担当者は、影響を受けるすべてのユーザーが事前に訓練されていることを確認する時間を与えなければなりません。新しい機能が試験で有効になった場合、その機能の構成はその時点で試験プロトコルに照らしてバリデーションされ、それはドキュメント化されなければならないことに留意してください。

マイナーアップデート（システムテキストのスペルミスや文法ミスの修正、エクスポートにおける新しいフィルタリングの可能性の追加など）は、デフォルトで無効にする必要はなく、理解が容易ですべての試験に有用であるため、直接リリースされます。

EDC管理シート

試験中に使用されたシステムの異なるバージョンとバージョン間の違いの概要は、試験記録の一部として企業の（e）TMFに保存されるべきです。

PMDA EDC 管理シートは、試験に使用した EDC システムを記録するために使用します。日本国外で実施される試験であっても、同様の記録を残しておくことをお勧めします。以下にEDC管理シートの例を示します。

EDC 管理シート（日本語）

現在、Viedocの各リリースで、日本語のホームページでアップデート版を公開しています。

治験クラウドシステムチェックリスト

JPMAは2024年4月、「治験クラウドシステムチェックリスト」を発表しました。このチェックリストは、スポンサーやCROがクラウドサービスプロバイダーを監視する際に役立つことを目的としています。

試験終了 — 廃棄

Viedocのようなマルチテナント型クラウドソリューションを試験に使用する場合、試験廃棄の性質が変化します。試験終了時にシステムそのものが廃棄されるのではなく、試験が「廃棄」されるのです。次のようなことが行われます。

データがクリーニングされる（全データのレビュー、クエリーの作成と終了）
試験はロックされ、それ以上の変更はできない
すべての試験データおよびメタデータはViedocからダウンロードされスポンサーおよび治験責任医師の（e）TMFにアーカイブされる
Viedocから試験が削除される（すべてのデータ、メタデータを含む）

試験データおよびメタデータをアーカイブするためにダウンロードする場合、リスクベースのアプローチをドキュメント化し、それに従う必要があります。以下の複数の形式のデータをアーカイブすることを推奨しますが、これに限定されるわけではありません。

静的ファイル（データ入力時に治験責任医師が表示したスクリーンショットを示すPDFなど
すべての試験ユーザーと試験でのロールを示すユーザーとロールのログなどの静的なファイル
高度なデータ解析が可能なSASデータセットなどの動的ファイル
データおよびメタデータ（監査証跡、クエリ履歴、メディカルコーディング、レビューステータス、ユーザーとロールのログなど）を分析のためにソートおよびフィルタリングできるMicrosoft Excelデータセットなどの動的なファイル
ランダム化リスト、アロケーションリスト、キット履歴リストなどの動的なファイル
試験構成も含むCDISC ODMデータアーカイブフォーマットなどの動的なファイル

上記のフォーマットはすべてViedocからエクスポートすることができる。

試験終了時の廃棄措置に採用された手順は、試験SOPにドキュメント化する必要があります。

避けるべき落とし穴

私たちは、査察官の期待に完全に応えてViedocで試験を実施できるように、上記のような方法論を開発しました。ほとんどの試験は、試験ごとに複数のシステム（10以上）を実装しており、その中には（Viedocがそうであるように）マルチテナントクラウドソリューションがますます増えてきています。試験の他のシステムで気をつけるべき落とし穴は何でしょうか。

お客様固有のソフトウェア

例えば、Viedocのように標準的なバリデーション済みの機能を使用するのではなく、新しいソフトウェアを作成することでシステムを構成しているものもあります。

システムの顧客専用バージョンは、要件（URS）、テストケース、テスト結果をドキュメント化した、そのシステムの顧客専用バリデーションも必要となります。これは、ソフトウェアがスポンサーの要望でカスタマイズされたものであるため、スポンサーの責任となります。

この作業は、試験が初めてリリースされる前に必要なだけでなく、ソフトウェアの新しいリリースや試験構成の変更のたびに繰り返されなければなりません。確かにViedocほど頻繁に新バージョンをリリースするシステムは多くありませんが、一方で一般的な臨床試験は1～2年実施され、その間に何度も新バージョンをリリースし、プロトコルを修正することも考えられ、そのたびにスポンサー/CROによるシステムの完全なバリで―ションが必要になります。

リリースの新機能

Viedocのように新機能がデフォルトで無効化されているのではなく、単に新しいリリースで登場する場合、新機能を使用する前に、試験プロトコルに対する新機能の設定のバリデーションおよびすべてのユーザーのトレーニングの両方が必要となります。

試験に適合させるためには、スポンサー/CROがリリースの日時を変更し、リリース前にすべてのバリデーションとトレーニングが行われたことを確認することがほぼ常に可能でなければなりません。

これは、大規模なマルチテナントシステムでは急速に維持できなくなり、コンプライアンス違反につながります。

リリースの後方互換性の欠如

リリース後にシステムの動作が変更された場合、試験構成は試験プロトコルに照らして再度バリデーションされなければなりません。

試験に適合させるためには、スポンサー/CROがリリースの日時を変更し、リリース前にすべてのバリデーションと必要なトレーニング活動が行われたことを確認することが、ほぼ常に可能でなければならないことを意味します。

これは、大規模なマルチテナントシステムでは急速に維持できなくなり、コンプライアンス違反につながります。

エディットチェック

エディットチェックが「サンドボックス化」されていないシステムでは、複雑なエディットチェックがシステムソフトウェア自体や試験データの完全性に影響を与えるという現実的なリスクがあります。

このような事態が起こらないようにするためには、そのようなエディットチェックが書き込まれたとき、またエディットチェックが修正されるたびにシステム全体を再バリデーションする必要があり、スポンサー/CROに大きな負担がかかります。

結論

Viedocでは、独自のURSを作成し、独自のバリデーションを行うのではなく、弊社のドキュメントに依存することを推奨しています。

私たちにお任せいただければ、時間や労力、そして精神的負担を軽減することができます。

Viedocを使用する際には、試験構成が試験プロトコルに準拠しているかどうかをバリデーションする必要があるだけです。Viedocでは、スポンサーごと、あるいは試験ごとに実施される顧客固有の開発は存在しないことを忘れないでください。

査察官の期待に応えるために、Viedocの各リリースでViedoc薬事申請準備パッケージを提供しています。どうぞご利用ください。