EDCを利用した治験講座　その2

<連載 全3回>　

EDCを利用した臨床試験における信頼性調査対応講座　(第2回)

＊万が一文中に解釈の間違い等がありましても、当社では責任をとりかねます。
　本文書の改訂は予告なく行われることがあります。

EDC調査チェックリストの考察

1. はじめに

前回でも紹介したとおり、2009年10月19日に開催された「平成21年度GCP研修会」では、演題の一つとして「電子的に収集された臨床試験データに対する信頼性調査の留意点」と題した発表が行われた。
本発表において「EDC調査チェックリスト」の案が紹介され、信頼性調査の内容と事例に基づく留意点の説明があった。
今回と次回は、「EDC調査チェックリスト（案）」に関する考察を行ってみたい。

2.EDC調査チェックリスト

医薬品医療機器総合機構（以下、PMDA）によると、平成20年度以降、10社以上（20申請品目以上）でEDCを利用した試験を含む申請品目の適合性調査を実施したとのことである。
PMDAでは、平成 21年3月に、EDCデータに対する調査すべき事項を「EDC調査チェックリスト（案）」としてまとめた。
その後、平成21年5月から8月にかけて、「EDC調査チェックリスト（案）」を用いてパイロット調査を行ってきたという。
本チェックリストは、案のままではあるが、PMDAのホームページで公開されている。
http://www.pmda.go.jp/operations/shonin/outline/shinrai/checklist.html
本チェックリストは、Wordが治験依頼者用、pdfが医療機関用となっている。
また本チェックリストは、本来の調査項目に加えて、EDCを使用した場合に追加となる差分の項目のみが記載されている。
本チェックリストは、今後も改訂が繰り返されるものと思われるため、治験依頼者は常にPMDAのホームページをチェックし、最新のチェックリストを参照するよう心がけなければならない。

3. 治験依頼者用

本チェックリストの治験依頼者用は、以下の6つの章からなる。
1)　システムの概要について
2)　EDCシステム運用に関する治験依頼者の組織・体制・委託状況等
3)　バリデーションについて
4)　ユーザー管理について
5)　データの保存
6)　電子症例報告書の作成、修正及び署名について

3.1システムの概要について

チェックリストの冒頭は、システムの概要に関する調査である。（図1参照）

１　システムの概要について

使用システムの概要  □自社開発　□市販パッケージ
□市販パッケージ＋カスタマイゼーション
□WEB型　□クライアントサーバ型　□その他（　）　
アプリケーション名称（バージョン）：
アプリケーション開発者：
システムの管理状況□自社管理
□委託管理
□ASPサービス　□ハウジングサービス
□ホスティングサービス　□その他（　）
委託者名：
システムへのアクセス方法 実施医療機関からサーバー設置場所への通信方法
□専用回線
□インターネット
□SSL通信　□VPN接続　□その他（　）
□その他
ユーザー認証
□ID・パスワード認証　□ID・生体認証　□その他（　）
電子署名の利用□あり
□デジタル署名　□ID・パスワード認証　□ID・生体認証
□その他
□なし
その他 

図1　システムの概要について

この章の調査項目では、現在のEDCの一般的な利用形態というよりは、不必要な項目も含め、あらゆるパターンを列記したという感がする。

3.1.1 使用システムの概要

自社開発という選択肢があるが、EDCを自社開発している製薬企業はこれまでに聞いたことがない。
EDCの場合、試験毎に入力画面、帳票、ロジカルチェックプログラム等を作成しなければならず、市販パッケージをカスタマイズすることが一般的である。
また現在では、EDCに限らず、コンピュータシステムの多くは、クライアントサーバ型からWEB型に移行が進んでいる。
クライアントサーバ型の場合、クライアントPCにアプリケーションのインストレーション（撤去の際にはアンインストール）が必要となり、EDCのように、薬剤の開発を通じて不特定多数のユーザに利用されるようなシステムには不向きである。
またその他の利用形態として、USBメモリ等による症例データの収集を行うシステムも存在する。
一般にWEB型のように、クライアント側に追加のインストレーションが不要なシステムをThin Clientと呼び、クライアントサーバ型やUSBメモリ方式のように追加のインストレーションが必要なシステムをThick Clientと呼ぶ。

3.1.2 システムの管理状況

システムの管理状況は、大きく自社管理と委託管理の2つに分類されている。
そして委託管理の選択肢として、ASPサービスが記載されている。
この分類方法には、少なからず違和感を覚える。
自社管理は、おそらく自社内にEDCサーバを設置していることを指すのであろう。
ハウジングサービスとは、顧客（つまり製薬企業）がサーバを用意し、サービス事業者が場所と回線、電源などを提供することを言う。したがって、設置場所が社外というだけであって、保守や監視を除けば、自社管理であることには違いがない。
ホスティングサービスも同様に、サービス事業者が用意したサーバを借り受け、運用することを指し、やはり自社管理である。
これに対して、ASPサービスは様相がまったく異なる。
ASPサービスの場合、顧客はシステム（ソフトウェア）をレンタルし利用することになる。したがって、システムの管理は当該ASPプロバイダが行う。
一般にシステムの開発やカスタマイズ等も当該ASPプロバイダが実施する。
本調査項目は、自社管理とASPサービスの2つに分類するべきであると考える。
ちなみに治験数が多い大手製薬企業は、自社でサーバを持ち自ら管理することが多く、その他の製薬企業ではASPサービスを利用することが一般的である。

3.1.3 システムへのアクセス方法

実施医療機関からサーバ設置場所への通信方法として専用回線という選択肢があるが、これも一般的ではない。
多くの場合、インターネットを利用し接続している。
インターネット接続の場合は、FDAの21 CFR Part 11（以下、Part11）や厚労省ER/ES指針で言うところのオープンシステムに相当する。
インターネットを介したアクセスでは、盗聴・改ざん・なりすましといったリスクが存在する。
そこでPart11やER/ES指針では、オープンシステムに対して暗号化やデジタル署名の利用を求めている。
一般にWEB型のシステムを利用する場合、SSLを使用することが多い。
SSLとは、Netscape Communications社が開発した、インターネット上で情報を暗号化して送受信する通信プロトコルのことである。またデジタル署名やデジタル証明書の技術を組み合わせている。
SSLは、Part11等のオープンシステムの要件を満たしているのである。
またユーザ認証で、生態認証という選択肢があるが、これも一般的ではない。

3.1.4 電子署名の利用

電子署名とデジタル署名の定義を混同しがちであるので注意が必要である。
デジタル署名は電子署名を実現するための方式の一つであり、電子署名とは紙に署名する行為を電子的に代替する技術の一般的な総称のことを指す。
EDCシステムでは、最終的に症例報告書をpdf等の電子フォーマット（デジタル文書）により出力することになるが、紙に印刷しないため、手書きの署名ができない。
したがって、pdf等のデジタル文書では、デジタル署名を付さなければならない。
デジタル署名は、当該デジタル文書の作成者を証明し、かつ改ざんされていないことを保証することができる。
前者を「本人性の証明」と呼び、後者を「非改ざん証明」と呼ぶ。
EDCシステム上のデータベースに症例データが存在する場合は、ユーザIDとパスワードの管理で、「本人性の証明」と「非改ざん証明」は担保できる。
しかしながら、システムから出力されたpdfのようなデジタル文書の場合は、デジタル署名が必要不可欠である。
またデジタル署名を使用しなければ、電子署名法に違反することにもなる。
ちなみに欧米では、SAFEと呼ばれるデジタル署名が実用化されつつある。

3.2 EDCシステム運用に関する治験依頼者の組織・体制・委託状況等

2章は、治験依頼者の組織・体制・委託状況等に関する調査である。（図2参照）

２　EDCシステム運用に関する治験依頼者の組織・体制・委託状況等
2.1 EDCシステム運用に関する組織・体制等について規定されている。
□　適　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）2.2 EDCシステム運用に関する手順書が整備されている。
【第26条第1項】（運用通知）
□　適
手順書　名称：　　　　　　　　　　　　　　　　　　　　　　　　　　　　
当該治験期間に該当するSOPの作成日：平成　　年　　月　　日　　　　
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）2.3 EDCシステム運用に関する業務を委託している場合、契約を締結している。
□　委託あり　契約日：　　　　　　　　　　　　　　　　　　　　　　　　　　　
契約期間：　　　　　　　　　　　　　　　　　　　　　　　　　　委託業務内容：　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
□　委託なし
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）2.4 データのセキュリティシステム
2.4.1 当該システムのセキュリティに関する手順書が整備されている。
【第26条第1項】（運用通知）
□　適　　　
手順書　名称：　　　　　　　　　　　　　　　　　　　　　　　　　　　
当該治験期間に該当するSOPの作成日：平成　　年　　月　　日
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）2.4.2 手順書に則って適切にセキュリティシステムが保持されている。
【第26条第1項】（運用通知）
□　適　　　セキュリティの保持状況：　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）

図2　 EDCシステム運用に関する治験依頼者の組織・体制・委託状況等

3.2.1 EDCシステム運用に関する組織・体制等について規定されている

GCP実地調査を受けた経験のある人であればお分かりであろうが、GCP上の組織の調査がある。
同様にEDCを利用した場合、厚労省ER/ES指針に従い、電子記録・電子署名を利用するための責任者・管理者・組織に関する規定が必要である。
特に組織に関しては、組織図を準備しておかなければならない。

3.2.2 EDCシステム運用に関する手順書が整備されている

GCP運用通知の第26条第1項に関わる調査である。
注意が必要なのは、調査時点での手順書ではなく、当該治験当時の手順書を提示できなければならないということである。
したがって手順書等の履歴管理は極めて重要である。
調査に対して、口頭で説明するのではなく、実物が提示できなければならないということに留意が必要である。
以下、各種手順書に関しては同様である。

3.2.3 データのセキュリティシステム

これもGCP運用通知の第26条第1項に関わる調査である。
セキュリティに関する手順書が提示できなければならない。
加えて、当該手順書に基づいてセキュリティを確保した記録が提示できなければならない。

3.3 バリデーションについて

2章は、バリデーションに関する調査である。（図3参照）
EDCやデータマネージメントシステム、統計解析システムのように、症例の生データを取り扱うシステムは、バリデーションが極めて重要である。
なぜならばシステムの品質が、データの信頼性に大きく影響するからである。
一方で、ドキュメント管理システムのように、システムの品質がデータにあまり影響しない場合は、FDAなどは厳しいバリデーションを課していない。

３　バリデーションについて
電子データ処理システムが、完全性、正確性、信頼性及び意図された性能についての治験依頼者の要件を満たしていることを保証し、文書化すること（すなわちバリデーションされること）。        【第26条第1項】（運用通知）（治験依頼者の要件の例：監査証跡、ユーザーの識別、ユーザー権限設定、入力データの正確性、入力データの見読性、入力データの固定、セキュリティ、バックアップ機能など）

当該システムが、入力済みのデータを消去することなしに修正が可能で、データ修正の記録をデータ入力者及び修正者が識別されるログとして残せる（すなわち監査証跡、データ入力証跡、修正証跡が残る）ようにデザインされていることを保証すること。 【第26条第1項】（運用通知）

3.1　試験開始時のバリデーションについて
3.1.1　監査証跡等のバリデーション
□　バリデーションの実施者：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
（アプリケーション開発者 、 ASP 、治験依頼者等）□　治験依頼者の要件を満たしていることを保証する文書：
（報告書、保証書、仕様書等）
　　　　　　　　　　　　　　　　　　　　　　　　
作成日：平成　　年　　月　　日
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）3.1.2　その他（　　　　　　　　　　　　　　　　）のバリデーション
□　バリデーションの実施者：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
（アプリケーション開発者 、 ASP 、治験依頼者等）□　治験依頼者の要件を満たしていることを保証する文書：
（報告書、保証書、仕様書等）
　　　　　　　　　　　　　　　　　　　　　　　　
作成日：平成　　年　　月　　日
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）3.2　EDCシステムが改訂（バージョンアップ、改修等を含む）されている場合のバリデーションについて3.2.1　 バージョンアップ
□　非該当
□　バージョンアップあり
バージョン：
運用開始日：平成　　　年　　　月　　　日3.2.1.1　監査証跡等に関するバリデーション
□　バリデーションの実施者：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
（アプリケーション開発者、ASP、治験依頼者等）□　治験依頼者の要件を満たしていることを保証する文書：
（報告書、保証書、仕様書等）
　　　　　　　　　　　　　　　　　　　　　　　　
作成日：平成　　年　　月　　日
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）3.2.1.2　（                                ）に関するバリデーション
□　バリデーションの実施者：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
（アプリケーション開発者、ASP、治験依頼者等）□　治験依頼者の要件を満たしていることを保証する文書：
（報告書、保証書、仕様書等）
　　　　　　　　　　　　　　　　　　　　　　　　
作成日：平成　　年　　月　　日
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）バージョンアップ以外の改訂（治験実施期間中にバージョンアップがない場合は、抽出して確認）□　非該当
□　バージョンアップ以外の改訂あり
（改訂履歴）
運用開始日：　　　　　　　改訂内容：　　　　　　　　　　　　　　　　　　　　　
運用開始日：　　　　　　　改訂内容：　　　　　　　　　　　　　　　　　　　　　
運用開始日：　　　　　　　改訂内容：　　　　　　　　　　　　　　　　　　　　　3.2.2.1　（                                ）に関するバリデーション
□　バリデーションの実施者：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
（アプリケーション開発者、ASP、治験依頼者等）□　治験依頼者の要件を満たしていることを保証する文書：
（報告書、保証書、仕様書等）
　　　　　　　　　　　　　　　　　　　　　　　　
作成日：平成　　年　　月　　日
□　その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）

図3　バリデーションについて

一般にユーザの要件を満たしていることを保証し、文書化することをバリデーションと呼ぶ。
したがって、ユーザの要件を文書化した「ユーザ要求仕様書」は重要なバリデーション文書である。
チェックリスト中には、治験依頼者の要件の例がいくつかあげられているが、これらは要件のほんの一部に過ぎない。
ユーザの要件には、入力画面、出力帳票、入力レンジチェック、ロジカルチェックプログラム、クエリ、権限管理等をはじめ、多くの事項が検討されなければならない。

当然のことながら、ユーザ要件のひとつとして、ER/ES指針や製薬協自主ガイダンスへの準拠もあげられる。

3.3.1 試験開始時のバリデーションについて

試験開始時すなわち運用開始にあたって実施されたバリデーションに関する調査項目である。
冒頭に監査証跡のバリデーションに関する調査がある。
電子記録の真正性において、監査証跡は重要であるため、そのバリデーションは必要不可欠である。
多くの場合、監査証跡に限ったバリデーションの記録を作成しておらず、調査時に本項目に関して文書を提示することができないことが想定される。
今後EDCシステムのバリデーションを実施する際には、監査証跡機能を独立して検証しておかなければならない。
またバリデーションに関する調査項目のそれぞれには、治験依頼者の要件を満たしていることを保証する文書に関する調査が含まれている。
その例示として、報告書、保証書、仕様書等があげられているが、これらは大変まぎらわしい。特に保証書という例示は、不適切である。開発者が保証書1枚を発行すれば合格できるような錯覚を起こさせるきらいがある。
CSVをご存知の人であればお分かりであろうが、まずユーザの要件を満たさなければならない文書は、設計仕様書であり、ユーザ要求仕様書と設計仕様書間のトレーサビリティマトリックスを作成しなければならない。
さらに設計仕様書がユーザ要求を満たしていることを設計レビュ（かつてはDQと呼んだ）により確認しなければならない。
システムが設計仕様書の通り構築されたことを検証するためには、システムテスト（かつてはOQと呼んだ）やユーザ受入れテスト（かつてはPQと呼んだ）が実施されており、その記録が作成され、最終的に報告書として文書化されていなければならない。
一般にバリデーションの査察は、規制要件に沿ってCSVのSOP等が整備されており、SOPにしたがってCSV実施の記録が文書化されていることを調査しなければならないはずである。
すなわち、計画書、仕様書、テストスクリプト、テストログ、報告書等多岐に渡るのである。
しかしながら、厚労省はCSVに関する規制要件を発行していない現状においては、多くの課題を残しているといわざるを得ない。

3.3.2 その他のバリデーション

監査証跡以外の機能に関するバリデーションの調査である。
チェック項目にバリデーションの実施者がある。
言葉尻をとらえるわけではないが、バリデーションの実施者は製薬企業でなければならない。ここはテストの実施者と記載するべきである。
ソフトウェアのテストは、バリデーションの一部ではあるが、全部ではないことに留意が必要である。
注意するべきは、テストを誰が実施したか（すなわち誰に委託したか）ではなく、その最終責任は製薬企業にあり、テストの計画やテストデータ、テスト記録のレビュと承認を行わなければならない。

3.3.3 EDCシステムが改訂（バージョンアップ、改修等を含む）されている場合のバリデーションについて

ASPを利用している場合などは、プロバイダの都合などにより、EDCシステムがバージョンアップされることがある。
使用開始後にシステムのバージョンアップが行われた際には、再度バリデーションを実施しなければならない。
多くの場合、EDCシステム本体に対する機能レベルのバリデーションは、当該プロバイダが実施することになると思われる。
しかしながら、当該治験に特化した入力画面や出力帳票などは、ユーザ側による検証を行う必要がある。
バージョンアップ以外にも、何らかの事情で治験実施中に入力画面やロジカルチェックプログラム等の変更（改修）を行うことがある。この場合にも再度バリデーションを実施しなければならない。

4. おわりに

「EDC調査チェックリスト」が案のまま公表されていることについて多少の違和感を覚える。
この案がいつ最終化されるのかの情報もまったくない。
現状の「EDC調査チェックリスト」では、ER/ES指針の要件や、製薬協自主ガイダンスの要件を網羅した調査内容にはなっていない。
また本文中で述べたように、多くの現状とのギャップがみられる。
したがって本チェックリストは、今後少なからず改訂が必要と思われる。
次回も引き続き「EDC調査チェックリスト（案）」の考察を続けたい。

参考

1)　「平成21年度 GCP研修会 講演要旨集」　平成21年10月19日　財団法人 日本薬剤師研修センター
2)　「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」平成17年4月1日　薬食発第0401022号
3)　「臨床試験データの電子的取得に関するガイダンス」平成19年11月1日　日本製薬工業協会 医薬品評価委員会

EDCを利用した治験講座　その1　
EDCを利用した治験講座　その2　
EDCを利用した治験講座　その3　

関連記事一覧