Q. 業界で有名なパッケージをコンフィグ、カスタマイズなしで使用する場合には、Vendor Auditは行わなくてもよいのでしょうか？
A. CSVの目的はComputerized System（つまりコンピュータを使用する業務）が期待通りの品質で稼動し、品質保証を劣化させないことです。
Vendor Auditの目的は、
1．Vendorの品質保証方針（Methodology、文書体系、教育方針、作成文書等）を確認する
2．そのVendorの財政状況（買収や倒産のリスク）を確認する
3．規制要件（CSV、Part11）や業界の業務知識を持っているかというスキルを確認する
4．購入後のサービス（サポート、メンテナンス、バージョンアップ）を確認する
等の目的があります。
1．に関しては、Vendor品質保証レベルが、自社の品質保証レベルを下回る場合には発注できません。それでも発注する場合は、何らかの方策をMVPに記載し、事前にQAの承認を取る必要性があります。
導入するシステムが、パッケージであったとしても、ユーザが安心して利用するためには、上記のすべてをクリアする必要があります。ただし、Vendor Auditのタイミングと回数は、導入するシステムがパッケージか個別開発かによって変更してもかまいません。
ただしご質問のように業界で有名なパッケージの場合、信頼性が高い（と思われる）ので、他社のVendor Audit記録を参考にするか、簡単な質問を郵便等で行えば良いのではないかと思います。
Q. 一般的に、MS-Accessで、クエリーを組んだり、レポートを作成する場合、バリデーションが、大変だ！と言われていますが、何が大変なのか、今ひとつピンときません。具体的に教えて頂けますか？
A. MS-Accessの場合、ユーザが自ら作成しDebugする機会がほとんどです。
つまり、パッケージ導入の場合、業者がTEST（Debug）するのが普通なので、任せられるのですが、Accessはそうは行きません。
しかも、OO（Object Oriented）なシステムですので、従来の手続き型言語（Fortranなど）とは違い、Debugは経験と感（つまりセンス）が重要です。Debug Toolも3rd Vendorから出ているようですが、いずれにせよ、開発費を抑えるために、自社で作成するからValIDation（この場合はTEST）が大変になります。
Q. 統計解析ソフトSASについてですが、社内の統計解析業務で使用する場合に、CSVの観点からどのようなドキュメントを残しておけば良いのでしょうか？OTS（Off The Shelf）ソフトウェアなので、IQだけやっておけば良いのかなと思うのですが。
A. SASはOTSではありません。Programable Softwareです。
簡単であるとは言え、何らかのスクリプトを記述しますので、その内容をValidateしなければなりません。
あらゆる電子データ処理システムに関しては、多かれ少なかれCSVが必須です。
したがって、バリデーション計画書は必ず作成してください。
またSAS導入時のIQも実施が必要です。
OQは、作成したスクリプトに対して実施してください。
問題はPQなのですが、多くの場合は、2通りのプログラムを用いて結果が一致するか（丸め誤差が許容の範囲か）を検証します。
最近、厚労省のGCP査察でも、担当者が使用しているＰＣまで査察官が行って、「操作して下さい」と言われることがあるようです。
その際、
1．エラーが出ないか
2．受取ったデータを当局側で解析し、会社の担当者に同じプログラムをその場でやらせて、答えを合わせる
こともしているようです。
[ 追記 ]SASの場合、OQでは解析ロジックのテストを行わなければなりません。
別のプログラムで同等のテストを行い、結果が同じになるかどうかをテストする必要があるでしょう。
ただしご指摘の通り、自分でロジックを書かない場合は、OQは省略できます。
PQもほとんど必要はありませんが、再現性を確保しておいてください。
つまり、再解析を命じられても良いようにすべての作業などを記録しておいてください。
Q. CSVの世界ではPQのSOPと言うものは不要なのでしょうか？
この業界で知り合いの多くが「SOPが必要だ！」と言っています。
PQスクリプトがSOPと認識すべきなのでしょうか。
PQにおいてはシステムを基盤とし、全ての業務フローがURSに対して機能するかの検証作業ですので、システムを含有したSOPが必要だと思うのですが、いかがなものでしょうか。お考えをお聞かせ願います。
A. まずCSVに関するSOP一式が必要であり、その中でPQに関しても記述されていなければなりません。
その上で、実際のテストの際に各実施計画書（テスト計画書、IQ計画書、OQ計画書、PQ計画書）を作成する必要があります。
もちろんPQ計画書はURSに対するTraceability Matrix作成も必要ですね。
Q. CSVの整備したシステムがウィンドウズ上で稼動しています。先日、ウィンドウズのパッチが出ました。パッチを当てる予定なのですが、その場合、設置計画書／報告書だけを作成すれば良いのでしょうか？また、ＯＳ部分なのでメイカー側のものなのでバリデーションの範囲外でIQも取らなくても良いものなのでしょうか？
A. 作業記録とパッチのリリースバージョンのログだけを残せば結構です。
IQの目的の１つは、災害の際の現状回復です。
そのため構築後の作業の記録（変更記録）が必要なわけです。
ただし、パッチを当てる前の調査（アプリケーションに影響がないことの確認）は一応しておいた方が良いでしょう。
Q. 2004.06.08のメールマガジンに、「ただしその主旨から扱うデータが安全性、有効性、品質に何ら関係しないシステム（例えば旅費精算システテム等）である場合は、CSVから除外してもよいと考えられる。」とありました。
”品質”というと、旅費精算システムも単純に考えると「旅費の合計等を正確に計算しているか？」という点でシステムが取扱う一つの品質ではないかと考えると、CSVの対象ではないかと悩んでしまうのですが？
また、何故、このような質問をしたかというと、多くの製薬企業が某モニタリングシステムを利用されているかと思います。
GxP規制要件対象という点以外に、このシステムがCSV対象であるする”品質”とはシステム的にどのように解釈すれば良いのでしょうか？
治験の”安全性”、”有効性”データとは考えにくく、扱っているデータは「作成者」、「日付」、「内容」等ですよね。
A. おっしゃる通りなのですが、メルマガで対象としているＣＳＶは、あくまでも規制要件で必要な品質保証を対象としています。
もちろん旅費精算システムをＣＳＶに則ってバリデーションしてもかまいません。
ただしその場合、コストをかけただけのメリットをよく検討して作成成果物やテストの範囲を決定したほうが良いでしょう。
通常、あらゆるシステムは何らかの受け入れテストを行っているはずです。
メルマガのシリーズで解説しているような、システマティックなＣＳＶでは多少オーバースペックとなるかもしれません。
モニタリングは新GCPになってから、必須となりました。
つまり査察の対象となります。
したがって、そのデータの収集、保管、管理を行うモニタリング管理システムは、やはりＣＳＶの対象となります。
モニタリングのデータは、間接的に申請資料の品質に影響します。
ご指摘の通り、”安全性””有効性”そのもののデータではないかもしれません。
（モニタリング報告書の内容によります）
ホームページ上やメルマガですでに解説している通り、申請するデータに「直接的」「間接的」に影響するデータはすべてＣＳＶの適用範囲です。
ただしFDAの指導している、リスクベースアプローチの考え方にしたがって、それらのデータがどの程度の重要性を持つのかをまず判定してください。
リスクの低いものについては、ＣＳＶの程度を低くしてもかまいません。
リスク調査の結果については「リスク調査報告書」や「ファンクショナル・リスク・アセスメント」などのドキュメントに記載します。
メルマガでもいずれ個々のドキュメントの詳細な解説を行う予定です。
Q.ネットワークに接続されているGXPで管理されるコンピューターシステムがあります。
このようなコンピュータシステムに、ウイルス対策ソフトのアップデータを定期的に行う場合のCSV（チェンジコントロール）の範囲を教えてください。
A. 最近良くある質問です。
まず前提として、ウィルスソフト自体はバージョンアップせずにデータの更新だけと考えていいですね。
その場合は、チェンジコントロールで、いつ、どのバージョンをアップしたかを記録しておけばいいでしょう。
つまり作業記録が必要です。
「アップデートすることによるリスクアセスメント」というのはなかなか難しいと思われます。
本来は、開発ベンダーがアプリケーションに及ぼす影響を文書化し、配布することの方が望ましいのですが、そのようなことは余りされていません。
もしアプリケーションに何らかの影響が出ることが心配されるのであれば、システムのバックアップを事前にとっておいた方が良いでしょう。
ウィルスソフト自体をバージョンアップする場合は、IQ関連の文書を作成しなければなりません。
最近、ウィルスも災害対策や障害管理といったドキュメントに対応を記載する企業が増えてきました。
社内で統一された方針をまず定義し、対応するべきと考えます。
災害対策や障害管理についても順を追ってホームページで解説したいと思います。
Q.CSVにおいてVMP(バリデーションマスタープラン)を作成しますが、VMPには各バリデーションステップ毎に作成する文書名、時期、作成者承認者を現在記載しています。
実際にバリデーション作業を行う際に文書作成担当者、承認者がVMPから変更になる場合があるのですが、変更があるたびにいちいちChangeControlFormを立上げ、VMPをReviseする必要はありますか？
VMPに規定した各文書の作成日や作成者・承認者はあくまで予定なのでバリデーション組織変更の経緯が別の資料で残されていれば、VMPはReviseしなくてもいいのでしょうか？例えばVMPに「作成予定者」や「作成予定日」として記載しておけば変更管理対象とはならないのでしょうか？
A. あまり重要でない（ドラフトに対する変更など）変更は、いちいち変更管理フォームを起こしません。
軽微な変更については、口頭で要求を行い、当該文書の変更履歴に記載します。
このことは、あらかじめ変更管理計画書に記載しておいた方が良いでしょう。
変更管理が大切なのは、複数の文書にまたがる（影響する）記載の変更です。
つまり、文書間のトレーサビリティを保たなければならない際です。
また、VMPもある程度FIXするまではサインオフをしないのが普通です。
[ 追記 ]そもそもFDA等の規制当局が変更を管理することとを要求しているのは、ソフトウェアに関してです。
一般にソフトウェアはハードウェアに比べて比較的変更が容易と考えられます。
したがって、ソフトウェアには作為的に本来の目的とは違った機能を組み込んだり、変更することが可能です。
規制当局はこのことを重視し、変更管理を実施することを強く求めています。
「変更管理」の英語表記はChange Controlであり、Change Managementではありません。
すなわち管理するというような漠然とした意味ではなく、変更をコントロールすることが本来の意味です。
Q.CSVでは、ライフサイクルを決めて実施していますが、一般的には開発と運用時は別けて考えられていますか？特に運用時はどのようなやり方が一般的ですか？
A. 開発時（計画～移行）と運用時（利用～廃棄）は、別けて考えなければなりません。
何故ならば、プロジェクトチームは、移行フェーズが終了（つまりバリデーション報告書が承認された時点）で解散となり、以降はサポートチームとユーザにシステムが移管されるからです。
バリデーション計画書はバリデーション報告書の完成をもって役目を終えます。
バリデーション報告書が完成した後には、サポート品質計画書やサービスレベルアグリーメント（SLA）が作成されます。
サポート品質計画書は、運用時におけるバリデーション状態の維持を計画し保証するものです。
通常、開発（プロジェクト）は数ヶ月ですが、運用は5年以上、場合によっては10年も続きます。
FDA等の当局が懸念しているのは、この長い運用期間中にバリデーションされたシステムが、ノン・バリデート状態にならないことです。
バリデーションされた状態が維持されない理由は、変更によります。
変更には、1．ユーザ要求の変更（つまりSOP等が変更になる）2．規制要件の変更 3．規制要件の解釈の変更 があります。
1．は明らかです。
2．はPart 11が良い例です。Part 11発行後はそれまでバリデートされていたシステムが、すべてノン・バリデート状態とされてしまいました。 これは、Part 11がレガシーシステムを免責しなかったからです。 3．はScope & Applicationなどが例として挙げられるでしょう。
運用時にはどのようなやり方があるかというご質問ですが、上記のSLAを履行しつつ、サポート品質計画書に記載されたサポート組織、役割、責任で計画されたとおりのアクティビティを実施します。
例えば、システムアクセス管理（セキュリティ）、バックアップ（およびリカバリー）、メインテナンス、継続教育などがあります。
また最重要なのは、定期監査です。
具体的にご理解いただくためには、サポート品質計画書やSLA、定期監査報告書などの実例を見ていただくことが最善と思います。
メルマガでは、順を追って実例を解説していきたいと考えております。しばらくお待ちください。
Q.機器のバリデーションについてですが、
①値を表示するだけの電子天秤
②データを取り込むPCが繋がった電子天秤
①と②でCSVに違いがありますでしょうか？
また、機器にも単に操作を行うものや測定を行うものがあり、CSVの観点から実施の要否や作業の違い等ありましたらご教示ください。
A. そもそもCSVは、変更可能なソフトウェアを軸に考慮する必要性があります。
OSやDBやファームウェアの類は、普通はCSVの対象とはしません。
（もちろん工場の自動化システムを特注した場合なんかは、話は別ですが。）
①値を表示するだけの電子天秤
この場合は、キャリブレーションのみで良いと考えられます。
標準器を使用して、適切な期間ごとに調整を行います。
②データを取り込むPCが繋がった電子天秤
もしPCがデータを処理するソフトウェアを搭載する際には、そのCSVが必要になります。
単にOSを利用するに留まる場合（実際にはあまりありえませんが。）はCSVは必要ないと考えます。
FDA等の規制当局がコンピュータシステムに求めるのは、
1．バグ等の不具合によるデータの信頼性の低下の防止
2．ソフトウェアの変更に伴う、不具合の増加、潜在化の防止
3．変更管理（Change Contorol）外での改変の防止
があげられます。（注：もちろんこれらはCSVの目的の一部にすぎません。）
つまり、データの品質や品質保証に影響するような危険性（リスク）が潜むか否かによって、CSVの必然性を判定するということになります。
Q.パッケージソフトウェアのバリデーションにおいて、いわゆるOQテストはユーザ側では不要と考えてよろしいでしょうか？（但し、ベンダー側で相当するテストが実施されていることを確認する）
もし上記確認が出来ない場合には、ユーザ側でのOQテストは必要と考えるべきでしょうか？（保証書ではダメ？）
A. パッケージのバリデーションは出来るだけしたくないですよね。
例えば、MS-Excelのように繁用されている製品はほとんどCSVの必要性は無いでしょう。
しかしながら、パッケージが信用出来るか、出来ないかは開発元の信頼性に大きく依存します。
まずはベンダーオーディットを行って、当該ベンダーのバリデーションの記録を見てくる必要があります。
テスト計画書がちゃんと存在し、すべてのテストが行われ、すべての記録が無いといけません。
もちろん発見された不具合がすべて改善されていなければなりません。
私が経験する限り、多くのベンダーでは、これらのテストが不十分です。
またパッケージを調査して、どれくらいの出荷実績があるかも、自社でのCSVの程度を決める要因となります。
FDAはパッケージであっても、出来る限りCSVを行うこと、事前に不具合や制限事項を調べて回避策を検討することなどを求めています。
上記の趣旨からして、保証書だけではだめです。
OQを省略できるかどうかは、上記のベンダーオーディットやパッケージ調査の結果次第といえます。
Q.コンピュータバリデーションQA業務を正常に遂行する為にそのメンバーに求められる要件（知識・経験及び技術）とは、何と思われますか？
A. 一般にコンピュータシステムの信頼性保証を行うためのスキルは、
1．品質保証に関する知識（例：ISO）
2．規制要件（バリデーション、ER/ES等）の知識
3．ITの知識
4．ユーザ業務の知識
です。
更に外資系企業などでは、
5．英語
も必要でしょう。
これらのスキルミックス（スキルセット）で、システムのバリデーションを実施します。
ご質問のQA担当者のスキルとしては、この中で１．と２．が中心になります。
ちなみにQAは、Independentでなければなりません。
つまり利害関係のない第三者です。
品質保証とは、同じ品質（スペック）のアウトプットを繰り返し生産できると言う保証です。
つまり再現性が重要です。
例えば、プロジェクトチームがバリデーション計画書を作成した際に、第三者的にレビュし、もし自分が行ったとしても同様の計画にしたであろうかと言う観点で見ます。
またはバリデーション報告書は、もし自分がバリデーションをやったとしたら、同じ結果を導いていただろうかと言う観点でレビュします。
更にもう一度同じことをやったら、同じ結果になるだろうかと言うことも考察します。
逆の観点からすれば、プロジェクトチームは、利害関係のない第三者を説得しなければなりません。
社内の人間を説得できないようであれば、当局の査察官を納得させることは出来ないでしょう。
当社のコンサルタントは、よく製薬会社のバリデーションをお手伝いし、QA担当者のコメントを目にします。
多くが「てにをは」の修正や、単語の間違いの指摘など、おおよそ品質保証とは関係しないような指摘にうんざりすることが多々あります。
Q.GMPで、既にバリデーション体制（製造工程や設備のバリデーション）を持っている場合、CSVも既存のバリデーション体制で行うべきでしょうか？
A. バリデーションに限らず、発効中の文書（基準書）に従うことは当然です。
製造工程や設備のバリデーションと書かれていますので、プロセスバリデーションの組織を指しておられると理解いたしました。
CSVの実施に必要なスキルは、プロセスバリデーションとは異なります。
したがって、同じ組織でCSVを実施できるとは限りません。
まずCSVに関する文書（基準書）等を作成し、CSV実施体制を明確にするべきです。
Q.ER/ES責任者、ER/ES管理者はCSVの計画書、報告書に関与（署名等）するべきでしょうか？
A. ER/ESとCSVは、目的と体制が異なります。
CSVは、システムの信頼性を保証することが目的です。
ER/ESは、CSVにより信頼性が確保されたシステム上で利用する電磁的記録・電子署名の信頼性を保証するものです。
したがって、体制上ER/ES責任者、ER/ES管理者とCSV実施体制は直接関係しません。
ちなみに、ER/ES責任者は、社長以下、経営層を指しています。
ER/ES管理者は、電磁的記録を利用する部門の長を指しています。
FAQ：Part11関係
Q.Part11の解釈 その1 サブパートBの位置づけについて
サブパートＢの11.10クローズドシステムにおいて
最初に「電子記録を作成し・・・・秘密性も含めてこれらが保証されるように，また署名者が署名した記録が真性のものでないと否認することが・・・・併用管理しなければならない。」と記載があります。
また，(j)にもそのことが記載されています。
最初の文書を読むと，「また署名者が署名した記録が・・・・」と前の文章に並列で述べられているように見えますので，クローズドシステムには電子署名が必要と読めます。
また，そうであるならばオープンシステムは伝達時のデータの保証以外はクローズドシステムに準じますから全ての電子記録に電子署名が必要と解釈されると思います。
しかしながら，part11コメント26にあるようにFDAは全ての電子記録に電子署名が必要と言っている訳ではありません。
と言うことで，上記の「また署名者が署名した記録が・・・・」は，
「また電子署名を行う場合には署名者が署名した記録が・・・・」と言うように
まずクローズドシステムでの要件が記載されていて，更にクローズドシステムで電子署名を使う場合の要件が記載されていると解釈する方が妥当ではないかと考えるのですが
如何でしょうか？
更に，11.30オープンシステムではデジタル署名についての記載がありますが，これは11.10の電子署名と対になっている(クローズドシステムでは電子署名が必須で，オープンシステムではデジタル署名が必須と言っている)のではなく，あくまでもオープンシステムにおいて伝達時のデータを保証する手段の１つとして記載されていると考えて宜しいでしょうか？
と言うことで，サブパートＢというのはあくまでも電子記録に対する要件が記載されていて，その中でのバリエーションとして電子署名を利用する際の要件も記載されていると考えて宜しいでしょうか？
A. まず、Part11が作成された経緯から説明しなければなりません。
Part11は1990年頃、製薬業界の方から「ペーパーレスシステム」を認めるように要求したのが始まりです。
GMPの分野においては、工場のほとんどのプロセスがオートメーション化され、ペーパーレスが実現していました。
しかしながら、最終工程で製造記録に手書きの署名を行わなければならなかったため、そのためだけに大量の紙を印刷しなければなりませんでした。
これは非常に不合理であり、FDAへの要求となったわけです。
したがって、Part11は「GMPのための電子署名（ペーパーレス）に関する規則」であるといえます。
つまり、紙媒体を削除し、電子でもかまわないとリス規制緩和なのです。
それが証拠に、未だにPart11査察はGMPのみでしか実施されていませんし、cGMPと整合して、5つのガイダンスが昨年取り下げられました。
一方でFDAは、サブパートAとサブパートBを別々の規制として扱っても良いとコメントしています。つまり、ハイブリットシステム（電子の記録に手書きの署名をすること）を容認しています。
しかしながらこのハイブリットシステムは、記録と署名のリンクという難題があります。これはPart11対応のための３つの難題（電子記録の定義、データの長期保存、記録と署名のリンク）のうちの一つに数えられます。
1994年にドラフトルールが出され、業界から49のコメントに答える中で35ページにも及ぶPreambleが作成されました。Final Ruleが出されたのが、1997年ですからコメントに対する議論に3年を費やしたことになります。
Part11を議論していく中で、「電子署名」よりも「電子記録」の方が大切であると認識されるようになってきました。
つまり元々電子署名に関する規制を作成し始めていたのですが、長引く議論と改訂のため、条文が複雑になってしまったのです。
したがって、電子記録に関する重要な事項（たとえばパスワードの管理）もサブパートCに記載されています。
最後に、デジタル署名はおっしゃるとおり、オープンシステムを利用し送信する際のリスク（改ざん、成りすまし）を回避するための手段です。
また、盗聴を防止するためには暗号化が必要です。
Q.Part11の解釈 その2 サブパートC電子署名について
11.200電子署名の構成要素と管理についてですが
part11では上はバイオメトリックスによるもの，下はユーザIDとパスワードだけで電子署名と認めると言っています。
また，11.300ではユーザIDとパスワードだけの場合に対して詳細な説明がされていますからFDAはユーザIDとパスワードでの電子署名をむしろ推奨しているようにも見えます。
その反面，電子署名には法的拘束力が必要とも言っています。
法的に認められるのは電子署名法等に合致したものでしょうから,それから考えればデジタル認証が必要になり，ユーザIDとパスワードだけではその要求は達成できないと思われます。
法的根拠はユーザーが証明せよ，証明書は法的に根拠があると大まかに記載が有れば良いというような事もコメント119にありますが，ユーザーの気持ちだけでユーザIDとパスワードだけをもって法的拘束力があると言い放つのは無理があります。
これはどう解釈したら宜しいでしょうか？
11.100(c)2の「電子署名を使用する者は・・・・提出しなければならない」から，ユーザIDとパスワードだけをもって電子署名としたいユーザは，「この２つで行われた署名行為に対して署名の否認が出来ないことを認める」という契約を結びその契約書(手書きのサインつまり法的な合意が行われた印)をFDAに提出せよ，この契約によって技術的には本人性の保証ができないユーザIDとパスワードだけの電子署名であっても電子署名としての「法的効力」を持たせることができると言う解釈でしょうか？
(しかしながら，この解釈ですと，技術的には本人性の保証は出来ないので，ユーザ以外でも署名は可能であり，その署名に対してもユーザIDとパスワードが同一である場合にはユーザが署名したと認めるというユーザ側のリスクを伴った契約になる気がします。これではユーザが実施医師でメーカーが依頼者である場合，リスクを被るのは実施医師で，メーカーがデータを改竄するのは容易です。また，改竄だと思ってもユーザーは依頼者に文句が言えないということになります。FDAはそれでも良いと言っていることになりますが。)
A. まず電子署名とはについて解説しなければなりません。
電子署名は、業務中の単なる確認やデータの確定といったものを指していません。
あくまでもFDAに提出する申請資料等への署名を指します。（臨床開発で言うと、総括報告書等、非臨床で言うと試験計画書と試験報告書等）
R&Dの一研究員が法的拘束力を問われても仕方がありません。あくまでもGxPで定義した会社の責任者レベルに対して言っています。（非臨床で言うとStudy Director以上）
パスワード管理については、Part11条文の中で再三言及していますので、電子署名に関しては、ユーザIDとパスワードの組合せのみで十分といえます。
余談ですが、日本の電子署名に関する規制（E2Bなど）では、米国の電子署名のことをデジタル署名と訳しています。（話をややこしくしています。）
さらに余談ですが、バイオメトリックスは欧州のとある国では使用できません。個人のプライバシーにかかわる法律があるためです。
Q. Part11の解釈 その3 本家part11と日本語版ER/ES指針について
上記質問2にあるように，part11はユーザIDとパスワードだけでも電子署名と述べています。
一方の日本版part11は，電子署名法に準じる事を記載しています。
電子署名法は，技術についての記載は有りませんが現状で実現できるのはデジタル証明書を用いたものであろうと多方面で解釈されていますから，日本語版ER/ES指針での電子署名と言えば，ほぼデジタル署名のことであるといって間違いないのではないかと思います。
そうすると，本家をもとに作られたはずの日本語版ER/ES指針が本家に比べると極端に厳しい基準を持つことになるかと思います。
これは，日本での「法的拘束力」の解釈が間違っているということでしょうか？
また，米国でも電子商取引は当然ありますし，電子署名法のような法律もあります。
にも関わらず，そこでは到底認められない「ユーザIDとパスワードだけでも電子署名」という見解をなぜFDAはpart11に示したのでしょうか？
法律の間での不整合を敢えて認めたということなのでしょうか？
A. この件に関しましては、現在ある理由から詳しくはお答えできません。
Q. Part11の解釈 その4 part11のサブパートの下の番号について
part11のサブパートの下の番号(例えば11.100)は何故連番ではないのでしょうか？(11.10の次が11.30ですよね。)
A. ドラフトルールからファイナルルールになる過程で改訂（削除）されたためです。
Q. Part11の解釈 その5 電子署名について
臨床試験の場合，症例報告書には責任医師や協力医師の署名もしくは記名・捺印が必要となります。
で，EDCを行った場合，Web上でやりとりされるデータはeCRFとなりますから紙と同様に扱うためには「署名もしくは記名・捺印」に相当するものが必要となります。
これが果たして，IDとパスワードでOKなのかが問題です。
技術的な面で言えばIDとパスワードで良いとも言えますが，GCPで定められた「署名もしくは記名・捺印」に相当するもの，つまり法的に拘束力があるものと考えれば現状ではデジタル署名が必要になってしまうのでしょうか？
実際，医療現場でも電子化は進んでいますが，診断書や処方箋など捺印が必要な書類は電子署名の問題から電子化に至っていないですよね。
デジタル署名はその署名自身に署名者のプライベートな情報を含むため，利用するのをいやがる医師も多いでしょうし，利用するとなればID＋パスワードに比べて費用もかかりますから，EDCの普及の妨げになる事が予想され，出来れば避けたいと考えているのですが，それは可能でしょうか？
A. （現行の）Part11を正確に理解していただくことが必要です。
ディジタル署名が必要なのは、オープンシステムの場合です。
EDCを構築した場合、クローズドシステムであればディジタル署名は必要ありません。
逆にオープンシステムを利用する場合、症例報告書に限らずすべての伝送データにはディジタル署名が必要になります。
メルマガ（7.26）にも書きましたが、電子署名とディジタル署名はまったく違います。
これらを混同してはいけません。
現行のと書いたのは、FDAでは今、改定Part11として、オープンシステムとクローズドシステムを区別すべきか、そうでないかを議論しているからです。
なお、ディジタル署名を利用するのが嫌ななのであれば、EDCをクローズドシステムで構築してください。
Q. Part 11関係で質問をさせてください。ID，PW等ではその桁数に関しては特に記載がないのですが、現在、一般的に何桁がその妥当なところだと考えられているのでしょうか？私の経験では、６桁～８桁が多かったのですが、いかがでしょうか。
A. 私がPart11のコンサルティングを実施していますお客様では、6文字としていただいております。
もちろんそれ以上でも結構です。
業界の平均以下はまずいですね。
まぁ、みんなでわたれば怖くないというやつです。
Q. 本HPの「日本版ER/ESガイドライン(日本版Part11)解説」の文中に、『米国版が実質ＧＭＰ分野に絞って適用していることを考慮すると、・・・・』との記載がありますが、この根拠をご教示していただけないでしょうか？
クレーム管理のシステム化を検討していますが、FDA Part11にはどこまで対応すべきなのか苦慮しています。上記文書を逆説的に解釈すると、「GMP分野以外では対応する必要がないのでは・・・」という内部の意見もあります。
A. 米国版が実質GMP分野に絞って適用していることの根拠をというご質問ですが、趣旨を考慮して今回はクレーム処理（管理）システムに関してコメントを差し上げたいと思います。
結論から申しますと、クレーム処理システムはPart11対応が必須です。
FDAの査察でも調査された実績がありますし、米国等で販売されているシステムはほとんどがPart11対応をうたっています。
生産分野において、査察の対象となるデータを保持しているシステムはPart11対応が必須といえます。
FDAが（生産分野において）査察時に最も興味を持つ事項は、製品の品質に関するデータです。
製造指図、製造記録はもとより、品質管理（LIMS）、出荷判定、工程管理、クレーム処理に及びます。
FDAの査察官は、数日間の査察実施において、より多くのデータを調査したいと考えております。
その際に、紙ではなく電子でデータが保存されておれば、オンラインで即座に取り出すことができ、また目的のデータの検索も容易です。
もちろんPart11の条文にあるように電子コピーの持ち帰りも可能となります。
ただし、電子記録には（FDAにとって）大きな落とし穴があります。
紙だと、物理的に存在がわかるのですが、電子の場合ハードディスク上に記録されており、存在そのものを隠匿できてしまいます。
また一番危惧されるのは、データの改ざんです。
紙の場合は、改ざんすると証拠が残りますが、電子の場合は全く残りません。
そこで、FDAはPart11で変更履歴の機能をシステムに持たせることを義務付けています。
FDAは、査察の際のデータの信頼性を確保するため、電子記録を利用している場合は、Part11対応を求めます。
ただし、考慮点がいくつかあります。
1．現在Part11の改訂が検討されており、実質Part11査察、ワーニングレターの発行は止まっている。
2．Part11のみの査察は行われない。GXP→CSV→Part11となる。
3．クレーム処理システムは日本において著名なパッケージがなく、また海外のものは日本語対応されていない。
4．海外のパッケージを導入する場合、非常に高価である。またサポートや国内実績に不安がある。
5．自社開発した場合、CSV対応、Part11対応が困難である。
6．日本版ERES指針対応を検討する必要がある。
などでしょうか。
Q. Part11の対象と判断した分析機器で、スタンドアロンタイプ、クローズドシステムと仮定した場合の質問です。
Q1．この分析機器は、Part11の要求事項（SubpartB）を全て満たさなければならないのか？
[背景]例えば、
・当該機器がGXP試験に使用する頻度が低くい。
・Part11対応ソフトをベンダーが発売していない、又は発売していても費用がかかり予算を確保できない。等々、企業としてはなるべき費用はかけたくないのが本音です。このような場合、最終製品の品質結果に及ぼす影響が低いという理由（記録の重要度に関するリスクアセスメント？）で、Part11の要求事項の削除又は達成度を下げることは認められるのでしょうか？
また、似たような質問になりますが、
Q2．ユーザ要求仕様書（URS）には、ユーザーの要求事項を記載するとありますが、Q1の背景の理由から、例えば、「監査証跡」を外す事は可能でしょうか？
監査証跡は手書きで行うとし、その運用基準書を作成して対応することも考えられますがいかがでしょうか？
A. 当該機器をGXP試験に使用する頻度が高いか低くいかではなく、その扱うGXPデータの重要度（リスク）が相対的に高いか低いかが問題となります。
もし重要度が高ければ、優先してPart11対応を行わなければなりません。
これは、2003年9月に出された「Guidance for Industry Part11, Electronic Records; Electronic Signatures – Scope and Application」が推奨する「Risk Based Approach」の考え方に基づきます。
Part11が目的とすることは、
1．改ざんを許さないシステム（Security）
2．改ざんされたら容易に分かるシステム（Audit Trail）
の2つです。
この2つの要件は、現在FDAが今夏を目処にPart11を改定中ですが、改定されても決して落とされることのないものです。
つまり、当該機器が電子記録を保持する場合が問題になり、保持した電子記録のSecurityとAudit Trailが論点となります。
たとえリスクベースが低いと判断された場合でも、電子記録を保持する限りはPart11対応のスコープに入り、遅かれ早かれ対応を行わなければならないわけですが、電子記録を保持しなければ問題は別です。
つまり、当該機器から即座にデータを他のシステム上のDBに移し、当該機器では記録を保持させない（消去する）ことです。
これが難しい場合には、善後策としてCD-Rなどの電子媒体にコピーしておくのも良いでしょう。
つまり、改ざんが難しい方式で電子記録を保持しておくのです。（FDAが納得するかどうかは、対応者の説得力によるでしょうけど。）
また監査証跡は手書きでも良いかというご質問ですが、Part11でも日本版ER/ES指針でも、システムが自動的に記録することが必須要件です。
したがって、電子記録を保持し、Part11の対応が必須と判断された場合は、監査証跡（特に変更履歴）は、システムに持たせないといけません。
FAQ：IQ、OQ、PQ関係
Q. IQはさておきOQやPQにおいては同条件で何回検証する必要があるのでしょうか？
この業界ではバリデーションと言う特殊なものが存在し、私のような製剤研究出身の者はバリデーションと言えばそりゃ～「3回」でしょ！っと、考えてしまいがちです。現在、CSVの実際はどうなのでしょうか。
A. おっしゃるとおり、日本での実験における”バリデーション作業”は3回が常識です。
これは、日本では「人は信用するが、機械は信用しない」という信条から来ています。
ところが、USではこれが逆転して、「機械は信用するが、人は信用しない」というのが信条なんですね。
したがって、コンピュータシステムのバリデーションの場合、1回が原則です。
つまり機械を信用しますので、1度のテストでも”結果は再現されるはず”という風に考えます。
Q. COTSを導入する場合は、IQは必要でしょうか？
普通に考えれば、OQ/PQは不要でも、パッケージソフトを導入するに当たり、IQのみは文書化する方がいいかと考えますが、実際のところはどんなものなのでしょうか。
A. IQの目的のひとつは、システムクラッシュなどの際に、速やかに復旧できることです。
パッケージの説明書にインストール方法が書かれていれば、省略できます。
ただし、パラメータの変更やDBのスキーマ等の設定は当然のことながら文書化が必要です。
COTSのメリットは生かしたいですよね。
注）GAMP5ではIQという概念はなくなりました。
Q. PQテストを実施する際には、当該コンピュターシステムを用いた業務に関するSOPを事前に作成しておかなければならないのでしょうか？
それともPQテストスクリプトに記載してあれば良いのでしょうか？
PQテストは、コンンピュータ化された業務の適合性（穴がないか）を確認するテストなので、業務SOPが必要だと思うのですが。
また、システムの負荷テストなどもPQで行うのでしょうか？
A. ユーザ要求仕様書（URS）およびPQシナリオのインプットはSOPです。
新SOPはDeployment（移行）フェーズで用意します。
ただしPQ実施時までに用意するのは新SOPのドラフトです。
新SOPの元になるのは、URSです。
つまりURSにはユーザが導入するコンピュータシステムを使って、どんな業務を行いたいかを記載しています。
PQはURSを元に実施します。
PQの実施結果に応じて、新しいSOPのドラフトをファイナライズします。
システムの負荷テストもPQで実施します。
たとえば、多人数で使用するとか、ネットワークのスピード、大きなファイルのアップロードなどです。
Q. システムを新しい環境に入れ替える場合、ソフトウェアおよび運用手順に全く変更がなければ、データ移行のバリデーションとIQのみを行い、OQ、PQは不要と考えてよろしいでしょうか？
A. 一概にはそうとは言えません。
まず新しい環境というのが、例えばサーバの交換などのようなH/Wの変更を指すのでしょうか。
H/Wの変更やOSのバージョンの違いによって、ソフトウェアの動作に影響しないとは断言できません。
特に周辺機器（分析機器、スキャナー、プリンター）との接続がある場合には注意が必要です。
一通りの動作確認をOQとして実施することが望まれます。
当然のことながら、機能のテストを実施する必要はありません。
またURSに従って、ユーザの望むパフォーマンスが出せることの確認もPQとして必要ですね。
以上のことは、システムの重要性、規模、複雑性に従って、適切なテスト計画を作成するのが普通です。
また、上記のようなシステム変更に伴う懸念事項が全くないという確信がある場合には、OQ、PQは省略できるでしょう。
ただしその場合も、OQ、PQを行わない根拠を文書化しておいた方が良いでしょう。
Q. 一般的なソフトウェア開発において、単体・結合・システム・受入テストを行いますが、これらのテストとCSVで出てくるOQ、PQテストとの関係がわかりません。単体・結合テストを実施していれば、OQテストは不要と言えるのでしょうか？
A. 単体・結合（連結）テストは、ベンダー側が構築（Build）フェーズに実施します。
一方、IQ、OQ、PQはユーザ側（製薬会社側）で実施します。
GAMPにも紹介されていますが、システムテストのことをOQと呼びます。また受け入れテスト（User Acceptance Test = UAT）をPQと呼びます。
システムテストと呼ぶかOQと呼ぶかなどは、国や業界によって異なるようです。
FAQ：日本版ER/ES関係
Q. ER/ESの通知では、4．電子署名利用のための要件に、電子署名及び認証業務に関する法律に基き・・・とのくだりがあります。ER/ESでは電子署名法でいう電子署名までの要件を求めているとは思えません。例えば暗号化はER/ESでは触れていませんが、電子署名法を完全に準拠する必要があるのでしょうか？
A. 問題点として、そもそも電子署名法は、インターネットなどのオープンな環境で商取引を行う際の印鑑に代わる電子署名を法的に認めるというものです。電子には印鑑を押すことができないからです。
電子の世界では、相手の顔を見ずに、また声も聞かずに注文や契約が行われます。つまり本人を確認する方法がありません。
リアルな世界では、書類に実印をつきます。また契約が本当に本人の行為であるかどうかは、印鑑証明書と陰影を比べればわかります。これを「文書の真正な成立の推定」と呼びます。
電子の世界で、印鑑証明に代わるものが認証局です。
したがって、電子署名法は電子署名に根拠を持たせ、さらに認証局を定義しています。
つまり電子署名法は、「実印」を電子的に押印するための法律であって、製薬会社の社内で行われるような承認作業（せいぜい認印）をカバーするものではありません。
この電子署名法を参考にSOPを作成したならば、社員が実印を持って出社するのと同じことになってしまいます。
電子署名法に準拠しなければならないのは、安全性電子報告など、社長印を押して当局へ提出する場合に限られます。
暗号化は追加措置として検討が必要です。
ちなみにインターネットなどのオープンなネットワークでは、
1．盗聴
2．改ざん
3．なりすまし
のリスクがあります。
1．は暗号化で、2．3．はディジタル署名で回避します。
もうひとつの問題点は、「電子署名」の定義が電子署名法とER/ES指針で異なるということです。
電子署名法の「電子署名」はER/ES指針の「ディジタル署名」に相当します。
ER/ES指針の電子署名は、「電子的に署名をする」という行為をさしています。
電子署名法の電子署名は、「電子的署名の技術」をさしています。
Q. 「ER/ESの考え方」の中に、電源（UPS等の対策）がありますが、これは、「真正性」の要件？それとも「保存性の要件」？どちらでしょうか？ 貴社のプレゼン資料には、真正性の中にあるリスクの中に、
－電磁的記録を削除されてしまうリスク
－電磁的記録および電子署名を誤って変更・削除してしまうリスク
があります。
同様に、保存性の中にあるリスクに、
－保存した電磁的記録および電子署名が消失・変質・破壊されるリスク
－保存した電磁的記録および電子署名が読み出せなくなるリスク
どちらにも該当するように見えますが、ご意見お聞かせ下さい。
A. あえて言うならば、「真正性の要件」です。
決して「保存性の要件」ではありません。
「保存性」はあくまでも電磁的記録媒体上にある、静的な維持状態です。
「真正性」が最も忌み嫌う「改ざん」が起きるのは、電源アップ時です。
UPSは、停電時などに、安全にシステムをシャットダウンするためのものですので、「バックアップ」の要件にも似ているともいえます。
Q. 今回のER/ES（これに伴う関連法規）によって、eCRFに電子署名をつけることによって紙のCRFの提出はしなくて良い、との判断は、出来るのでしょうか？
（想定は、EDCです。現状は、EDCからプリントアウトして、その紙にDｒのサインをしてもらったものを当局に提出していますが、EDC上で、電子署名をした場合、紙はいらない？？）
A. 電子文書法などの関連法規上（厚生労働省令44号を含む）では、紙は省けます。
しかしながら、GCPの必須文書の規定では、医療機関側でCRFの副本を保存しておく義務があります。
EDCを利用した場合は、CRFなどの生データが、製薬会社側のシステム上にしか存在しないことになります。
したがってCRFを紙に印刷し、責任医師の署名か記名・捺印をした上で、医療機関側でも保存しておいていただく必要性があります。
またEDCの運用に当たっては相当な検討が必要です。
EDCそのもののCSV、データの信頼性保証、SDV、医療機関側での電子カルテの信頼性などなどです。
Q. 日本版ER/ES指針では、「バックアップ」が真正性の要件（3.1.1 (3)）に記載されていますが、何故保存性(3.1.3)の要件ではないのでしょうか?言い方を変えると、「バックアップ」と真正性にはどういう関係があるのでしょうか？
A. パブリックコメントの回答の80番でも、同様の質問があります。
指針の「3.1.1. 電磁的記録の真正性」には、「電磁的記録が完全で、正確で、信頼できるとともに」と記載されています。
この中の「信頼できる」に該当するのではないかと思います。つまり、バックアップによって災害など万が一の際に復旧が可能であれば、データを電磁的記録として維持しておいても信頼できるからです。
なお「保存」と「バックアップ」はその目的も方法も全く異なりますので、混同しないようにしてください。
電磁的記録による「保存」とは、紙媒体によってキャビネットに入れて保存する代わりに、電磁的記録により、ハードディスクなどに記録し、適切に保存することを指します。
一方「バックアップ」は、その電磁的に保存された状態を、マグネチックテープなどに複製しておくことを言います。
「保存」中の資料（記録）は常に検索･抽出が可能な状態でなければなりません。「バックアップ」は検索･抽出には利用しません。また災害等でデータが失われない限り、バックアップしたデータは再利用しません。
Q. 本HPの「日本版ER/ES指針ワンポイント（初級編）」内に『Clintrial等のDMシステム中のデータは日本版ER/ES指針の対象ではありません。』とありますが、これは普通にCRFを入力画面から入力していれば、対象にならないのでしょうか。
①例えば、計算文により年齢を求め、その値を使用し解析をしている場合でも当局に資料・原資料を紙で提出・保管するのであれば、ER/ESの対象にならないのですか。
②またER/ESの対応が必要ではないとなると、「データの真正性」はどのように保証されるのでしょうか。（データの真正性が保証されていないデータを使用して、解析を実施したということにはならないのですか。）
A. 日本版ER/ES指針は、当局が受け取る書面を電磁的記録により提出する場合と、当局が査察（書面調査）する書面を電磁的記録により保存する場合の要件です。
しかもそれらが作成（承認）後、保存または提出したものを対象としています。承認もされていない文書を当局が査察しません。
ご質問は、後者の方だと理解します。
後者の書面を日本版ER/ES指針では「原資料」と呼んでいます。
これは薬事法及び関連法令により保存が義務づけられている書面を指し、GCPでは必須文書のことです。
必須文書は、当局がGCP省令に基づき、査察を行う権限を有しています。
ご質問のClintrialに入力されたデータや、Clintrialから出力された帳票は、必須文書でしょうか？
（つまり薬事法及び関連法令により保存が義務づけられている書面でしょうか？）
言い換えると当局が査察を行う根拠があるでしょうか？
もし、その帳票に改ざんが見られた場合、当局はどんな行政処分を発動できるでしょうか？
その根拠はどこにあるでしょうか？
上記から明らかです。
なお、日本版ER/ES指針の適用を受けないことと、GCPの実地調査とは別物ですので、ご注意ください。
GCPの実地調査では、治験の信頼性保証を確認するためさまざまな調査が行われます。
Clintrialのデータも例外ではないでしょう。
ただし、日本版ER/ES指針査察ではありません。
Q. ER/ES指針 5．その他に….電磁的記録及び電子署名を「利用しようとする者は」、電磁的記録及び電子署名の利用のために「必要な責任者、管理者、組織、設備及び教育訓練に関する事項を規定しておくこと」。と記載されています。
「利用しようとする者は」とは、会社のトップでしょうか？それとも各GXP部門の責任者でしょうか？
「必要な責任者、管理者、組織、設備及び教育訓練に関する事項を規定しておくこと」。とは全社的な管理が出来るような規定を作成することでしょうか？それとも各GXP部門で行えばいいのか、またはシステムオーナーの事を言っているのでしょうか？
A. 平成17年8月2日に、ER/ESシンポジウムが開催された際に、冒頭で総合機構の井本昌克氏が、「（利用しようとする者とは）社長に言っています。」とコメントされました。
つまり会社のトップを指しています。
100歩譲って取締役、200歩譲って執行役員です。
GXP部門の長が取締役であれば問題ないでしょう。
規定（方針書）は、会社規模で作成することが望ましいですが、R&Dと生産では対応に温度差が出ることが多いです。
部門別にならざるを得ないでしょう。
システムオーナーは、管理者ではありませんので、注意してください。
日本版ER/ES指針が指す、管理者は電磁的記録の管理者（データオーナ）です。
システムの管理者ではありません。
FAQ：電子署名関係
Q. 「電子記録」には手書きであれ，電子であれ何らかの署名が必要なのでしょうか？
A. いいえ。電子だから特別に署名が必要というわけではありません。
Part11の多い誤解の1つに、今回のようなご質問があげられます。
Part11は、単に電子化する際の規制（実は規制緩和なのです）であって、電子化したから署名を増やさないといけないものではありません。
紙ベースで行っている（または行っていた）署名活動はそのまま電子になっても同じはずです。
手書きの署名を電子署名に置き換えてもいいというのがPart11の精神です。
FAQ：臨床試験関係
Q. 現在、臨床試験のフェーズⅠ（健常者試験）は、日本国内で実施されているのでしょうか？
実施されている場合、ボランティア者の報酬は如何程なのでしょうか？
（フェーズⅡ＆Ⅲは、それぞれ約7,000円と聞いております。）
私の中では、「日本国内でフェーズⅠ試験の実施は難しい」という認識です。
というのも、「ボランティアに対して報酬を支払うことが出来ない」というようなことを聞いたような気がして・・・。
私も臨床が専門ではないので、間違ってたら申し訳ありません。
このあたり、いろいろHPで調べてみたのですが、どうしても資料を探し出すことが出来ませんでした。
もし、ご存知のことがあれば、お教え願えないでしょうか？
可能であれば、関連するHPのアドレスをお教え頂ければ幸いです。
A. 実施されています。
健常人ボランティアパネルを持っているCROと契約して実施することになります。
Phase2、Phase3の7,000円は、ボランティア報酬ではなく、治験協力者への負担軽減費用として、1通院当たり7,000円の交通費支給が認められているもので、患者を対象とした治験は本来無償が原則とされています。（患者が治療の手段の一つとして、治験をボランティアで選択）
Phase1の場合は健常者が通常対象ですので、採血の回数などにもよりますが被験者1人当たり、十万～数十万円程度の報酬は支払われます。（治療の必要のない健常人に対して、投薬、侵襲的検査等を行う報酬）CROと契約するときに、被験者1人当たりの報酬なども含めて行います。
治験ネット：http://www.chiken-net.com/（※フェーズIの募集はしていません。）
Q. 「microdose試験」というのは、既に日本国内で実施されているのでしょうか？「microdose臨床試験」というのは、最大投与量が100μg（0.1mg）で、欧州では認められている試験のようです。（私も又聞きなので定かではありませんが・・・。）
A. 今年（2004年）5月から、英国でもPhase I試験が規制当局に審査されるようになるのと引き替えに、既に昨年7月からEU全域で「単回microdose臨床試験」という名のスクリーニングPhase I試験 (ICH基準よりも少ない非臨床試験で実施できるスクリーニング目的のPhase I試験）がEU全域（今年から25カ国）で実施可能となりました。
米国では以前からこの種の試験も当局と企業の協議で実施できますので、日本だけ「蚊帳の外」です。
日本と欧米との規制の地域差がまた拡大したわけです。
よって、まだ日本では実施していません。
FAQ：その他
Q. 申請文書の管理システム導入によって、得られるメリットは何でしょうか？
A. 論理的には、申請までのスピードが早くなります。
ただし、
1．Publishing Toolを入れた場合に、申請資料の作成が短縮化される。（数週間）
2．ビジネスプロセスを改革することによって、IB、プロトコール、CSRの作成が短縮化される。
（しかし、臨床試験そのものが滞れば同じ）
3．グローバルな治験の場合、文書の交換、レビュ、承認が促進される。
4．規模が大きい組織の場合、オーバーヘッドを極力抑えることができる。
5．作成文書の品質を改善することによって、やり直し（2度手間）を防ぐことができる。
6．検索機能により、当局、CRO、共同開発会社などからの問い合わせに即答することができるようになり、審査期間の短縮が図れる。
という感じです。
通常、申請文書管理システムには、もっと根本のビジネスストラテジーの改革を抱き合わせます。
つまり、申請方針（ストラテジー）の早期決定と変更管理をVisualに行うことによって、開発途中での方針変更、申請直前の駆け込みによるつじつま合わせを防ぎます。
具体的には、開発基本計画を策定し、常に計画と試験（非臨床、臨床）報告書の完成をチェックします。
往々にして、各社では基本計画があっても、チェックポイントがなかったり、計画が守れなかったり、元々守れない計画であったりと、杜撰な管理が目立ちます。
また申請直前に必要な試験が足りなかったというような、ヘマも防ぎます。
そういう意味では、申請文書管理とプロジェクト管理は表裏一体です。
その2つの仕組みと斬新な新ビジネスプロセスを組めあわせて、はじめて申請のスピードアップと品質向上が図れます。
ご存知のとおり、業務プロセスを変革するには、大変な労力が必要です。
強力なリーダシップと精神力、明確なゴールなどが必要と言えます。
Q. EDCにおける原本データとは？
EDCを実施する際にはASPであったり，サーバだけを借りたりと第三者機関を利用することも多いと思われます。その場合，依頼者は試験終了後にデータのみを引き取ることになります。
また，システムはベンダーのものなので試験終了と同時に無くなってしまいます。引き取ったデータはコピーであり，原本データはシステムと同時に無くなります。システムを維持できない理由がレガシーシステムの場合とは異なるのですが，このような場合，データはpart11上保証できなくなるのでしょうか？
逆にシステムが無い状況でもそのシステムを利用したデータの作成(収集)と管理を保証するためにはどうしたら良いのでしょうか？
A. まずPart11に対応しなければならないのであれば、Part11に対応してくれるベンダーやASPと契約することです。
次にシステムの廃止（廃棄）については、「正確かつ完全なコピー」が取れることが条件となっています。
ここで言う「完全な」というのは、監査証跡などのメタデータを含めてすべて電子コピーが作成されることを示します。
これは「臨床試験を再現できる」という、「Computerized System Used in Clinical Trials」の要件を満たす必要があるからです。
また原本は電子ではなく、カルテなどの原資料、CRFであると思われますので、必ずしも電子データをオリジナルシステムで保管する必要性はないと考えます。
もし電子コピーも作成不可能で、紙で保管せざるを得ない場合でも、上記の要件（正確かつ完全）を満たさなければなりません。
Q. 「前提」
・システム開発を伴わない測定機器を導入する場合。
・ベンダーは、査察の結果、信頼性が保証できた。
ユーザーがURSを作成し、ベンダーに提出した後、ベンダーから回答を得た。そのURSの回答は、ユーザーのPQにおける要求仕様の確認の根拠データに使用できるのでしょうか？
例えば、URSに「監査証跡機能があること」という要件を記載し、ベンダーの回答が「Yes」だった場合、ユーザーはOQやPQで「監査証跡」に関するテストを行わず、URSの回答から「適合」と判断することは許されるのでしょうか？
A. 結論から申しますと、OQやPQの問題ではありません。
ご質問者は、各検証作業（DQ、OQ、PQ）を混同されているように感じます。
ご質問に回答する前に、整理をしたいと思います。
まずOQはシステムの機能を検証します。つまり仕様を満たしているかどうかをユーザ側で確認するわけです。
前提とされている「システム開発を伴わない測定機器」の場合、ベンダーの保証を得ているならば、OQの大部分は省略することができます。（もちろん各社のSOPに明記されていなければなりませんが。）
OQを実施しなければならないのは、設置後何らかの他の装置と接続していたり、ソフトウェアのモジュールやライブラリを組み合わせた場合など、いわゆるカスタマイズ（カスタムメイド）を行った部分の検証（テスト）です。
次にPQは「ユーザの意図した性能」を満たすかどうかを検証します。
同じシステムを導入したとしても、ユーザによっては使用方法（業務プロセス）が異なり、PQはそれぞれ異なります。
多くの場合、どんなシステムであれ、PQを省略できるケースはほとんどありません。
通常（正常）の業務プロセスと、少し複雑（またはイレギュラー）な業務プロセスを織り交ぜてテストケースを作成します。
PQでは、よりリスクの高い業務プロセスの特定と運用環境の安定性の保証を目的とします。
さてベンダーが「監査証跡の機能がある」と回答した場合、ユーザ側で何を行わないといけないかというと「監査証跡機能のレビュ」です。
何故ならばユーザが想定している「監査証跡の機能」とベンダーが実装している「監査証跡の機能」が果たして一致しているかどうかは、詳細を調べてみなければわからないからです。
これは、通常DQ（Design Qualification ＝ 設計レビュ）で行います。
DQは設計フェーズの最後（つまり製造フェーズの前）に行うのですが、パッケージ製品のように、出来合いのものを購入する場合は、事前にパッケージ調査（GAP分析）を行います。
「監査証跡の機能」の場合、操作履歴が記録されるか、作成履歴が記録されるか、変更履歴が記録されるか、削除履歴が記録されるか。
または、どのデータに関して監査証跡が記録できるか。
監査証跡は、どういった手順で確認できるか。
監査証跡はどのタイミングから記録されるか。
など、仕様はまちまちのはずです。これらの仕様がユーザの要求（URS）と合致しているかどうかを購入前に調査しておくべきです。
Comment