FAQ よくある質問とその回答集

• 業界で有名なパッケージをコンフィグ、カスタマイズなしで使用する場合には、Vendor Auditは行わなくてもよいのでしょうか？
• 一般的に、MS-Accessで、クエリーを組んだり、レポートを作成する場合、バリデーションが、大変だ！と言われていますが、何が大変なのか、今ひとつピンときません。具体的に教えて頂けますか？
• 統計解析ソフトSASについてですが、社内の統計解析業務で使用する場合に、CSVの観点からどのようなドキュメントを残しておけば良いのでしょうか？
• CSVの世界ではPQのSOPと言うものは不要なのでしょうか？
• CSVの整備したシステムがウィンドウズ上で稼動しています。先日、ウィンドウズのパッチが出ました。パッチを当てる予定なのですが、その場合、設置計画書／報告書だけを作成すれば良いのでしょうか？
• 2004.06.08のメールマガジンに、「ただしその主旨から扱うデータが安全性、有効性、品質に何ら関係しないシステム（例えば旅費精算システテム等）である場合は、CSVから除外してもよいと考えられる。」とありました。
  ”品質”というと、旅費精算システムも単純に考えると「旅費の合計等を正確に計算しているか？」という点でシステムが取扱う一つの品質ではないかと考えると、CSVの対象ではないかと悩んでしまうのですが？
• ウイルス対策ソフトのアップデータを定期的に行う場合のCSV（チェンジコントロール）の範囲を教えてください。
• CSVにおいてMVP(マスターバリデーションプラン)を作成しますが、MVPには各バリデーションステップ毎に作成する文書名、時期、作成者承認者を現在記載しています。
  実際にバリデーション作業を行う際に文書作成担当者、承認者がMVPから変更になる場合があるのですが、変更があるたびにいちいちChangeControlFormを立上げ、MVPをReviseする必要はありますか？
• CSVでは、ライフサイクルを決めて実施していますが、一般的には開発と運用時は別けて考えられていますか？特に運用時はどのようなやり方が一般的ですか？
• 機器のバリデーションについてですが、�@値を表示するだけの電子天秤�Aデータを取り込むPCが繋がった電子天秤�@と�AでCSVに違いがありますでしょうか？また、機器にも単に操作を行うものや測定を行うものがあり、CSVの観点から実施の要否や作業の違い等ありましたらご教示ください。
• パッケージソフトウェアのバリデーションにおいて、いわゆるOQテストはユーザ側では不要と考えてよろしいでしょうか？（但し、ベンダー側で相当するテストが実施されていることを確認する）
  もし上記確認が出来ない場合には、ユーザ側でのOQテストは必要と考えるべきでしょうか？（保証書ではダメ？）
• コンピュータバリデーションQA業務を正常に遂行する為にそのメンバーに求められる要件（知識・経験及び技術）とは、何と思われますか？
• GMPで、既にバリデーション体制（製造工程や設備のバリデーション）を持っている場合、CSVも既存のバリデーション体制で行うべきでしょうか？
• ER/ES責任者、ER/ES管理者はCSVの計画書、報告書に関与（署名等）するべきでしょうか？

• Part11の解釈　その1 サブパートBの位置づけについて
• Part11の解釈　その2 サブパートC電子署名について
• Part11の解釈　その3 本家part11と日本語版ER/ES指針について
• Part11の解釈　その4 part11のサブパートの下の番号について
• Part11の解釈　その5 電子署名について
• Part 11関係で質問をさせてください。ID，PW等ではその桁数に関しては特に記載がないのですが、現在、一般的に何桁がその妥当なところだと考えられているのでしょうか？
• 本HPの「厚労省ER/ES指針ガイドライン(日本版Part11)解説」の文中に、『米国版が実質ＧＭＰ分野に絞って適用していることを考慮すると、・・・・』との記載がありますが、この根拠をご教示していただけないでしょうか？
  クレーム管理のシステム化を検討していますが、FDA Part11にはどこまで対応すべきなのか苦慮しています。
• Part11の対象と判断した分析機器で、スタンドアロンタイプ、クローズドシステムと仮定した場合の質問です。
  Q1．この分析機器は、Part11の要求事項（SubpartB）を全て満たさなければならないのか？
  Q2．ユーザ要求仕様書（URS）には、ユーザーの要求事項を記載するとありますが、Q1の背景の理由から、例えば、「監査証跡」を外す事は可能でしょうか？

• IQはさておきOQやPQにおいては同条件で何回検証する必要があるのでしょうか？
• COTSを導入する場合は、IQは必要でしょうか？
• PQテストを実施する際には、当該コンピュターシステムを用いた業務に関するSOPを事前に作成しておかなければならないのでしょうか？また、システムの負荷テストなどもPQで行うのでしょうか？
• システムを新しい環境に入れ替える場合、ソフトウェアおよび運用手順に全く変更がなければ、データ移行のバリデーションとIQのみを行い、OQ、PQは不要と考えてよろしいでしょうか？
• 一般的なソフトウェア開発において、単体・結合・システム・受入テストを行いますが、これらのテストとCSVで出てくるOQ、PQテストとの関係がわかりません。単体・結合テストを実施していれば、OQテストは不要と言えるのでしょうか？

• ER/ESの通知では、4．電子署名利用のための要件に、電子署名及び認証業務に関する法律に基き・・・とのくだりがあります。ER/ESでは電子署名法でいう電子署名までの要件を求めているとは思えません。例えば暗号化はER/ESでは触れていませんが、電子署名法を完全に準拠する必要があるのでしょうか？
• 「ER/ESの考え方」の中に、電源（UPS等の対策）がありますが、これは、「真正性」の要件？それとも「保存性の要件」？どちらでしょうか？
• 今回のER/ES（これに伴う関連法規）によって、eCRFに電子署名をつけることによって紙のCRFの提出はしなくて良い、との判断は、出来るのでしょうか？
• 厚労省ER/ES指針では、「バックアップ」が真正性の要件（3.1.1 (3)）に記載されていますが、何故保存性(3.1.3)の要件ではないのでしょうか?
• 本HPの「厚労省ER/ES指針ワンポイント（初級編）」内に『Clintrial等のDMシステム中のデータは日本版ER/ES指針の対象ではありません。』とありますが、これは普通にCRFを入力画面から入力していれば、対象にならないのでしょうか。
• ER/ES指針　5．その他に....電磁的記録及び電子署名を「利用しようとする者は」、電磁的記録及び電子署名の利用のために「必要な責任者、管理者、組織、設備及び教育訓練に関する事項を規定しておくこと」。と記載されています。
  「利用しようとする者は」とは、会社のトップでしょうか？それとも各GXP部門の責任者でしょうか？
  「必要な責任者、管理者、組織、設備及び教育訓練に関する事項を規定しておくこと」。とは全社的な管理が出来るような規定を作成することでしょうか？それとも各GXP部門で行えばいいのか、またはシステムオーナーの事を言っているのでしょうか？

• 「電子記録」には手書きであれ，電子であれ何らかの署名が必要なのでしょうか？

• 現在、臨床試験のフェーズ�T（健常者試験）は、日本国内で実施されているのでしょうか？
• 「microdose試験」というのは、既に日本国内で実施されているのでしょうか？

• 申請文書の管理システム導入によって、得られるメリットは何でしょうか？
• EDCにおける原本データとは？
• ユーザーがURSを作成し、ベンダーに提出した後、ベンダーから回答を得た。そのURSの回答は、ユーザーのPQにおける要求仕様の確認の根拠データに使用できるのでしょうか？

1. CSVの目的はComputerized System（つまりコンピュータを使用する業務）が期待通りの品質で稼動し、品質保証を劣化させないことです。
   
   Vendor Auditの目的は、
   1．Vendorの品質保証方針（Methodology、文書体系、教育方針、作成文書等）を確認する
   2．そのVendorの財政状況（買収や倒産のリスク）を確認する
   3．規制要件（CSV、Part11）や業界の業務知識を持っているかというスキルを確認する
   4．購入後のサービス（サポート、メンテナンス、バージョンアップ）を確認する
   等の目的があります。
   
   1．に関しては、Vendor品質保証レベルが、自社の品質保証レベルを下回る場合には発注できません。それでも発注する場合は、何らかの方策をMVPに記載し、事前にQAの承認を取る必要性があります。
   
   導入するシステムが、パッケージであったとしても、ユーザが安心して利用するためには、上記のすべてをクリアする必要があります。ただし、Vendor Auditのタイミングと回数は、導入するシステムがパッケージか個別開発かによって変更してもかまいません。
   
   ただしご質問のように業界で有名なパッケージの場合、信頼性が高い（と思われる）ので、他社のVendor Audit記録を参考にするか、簡単な質問を郵便等で行えば良いのではないかと思います。

戻る

1. MS-Accessの場合、ユーザが自ら作成しDebugする機会がほとんどです。
   つまり、パッケージ導入の場合、業者がTEST（Debug）するのが普通なので、任せられるのですが、Accessはそうは行きません。
   
   しかも、OO（Object Oriented）なシステムですので、従来の手続き型言語（Fortranなど）とは違い、Debugは経験と感（つまりセンス）が重要です。Debug Toolも3rd Vendorから出ているようですが、いずれにせよ、開発費を抑えるために、自社で作成するからValIDation（この場合はTEST）が大変になります。

戻る

1. SASはOTSではありません。Programable Softwareです。
   簡単であるとは言え、何らかのスクリプトを記述しますので、その内容をValidateしなければなりません。
   
   あらゆる電子データ処理システムに関しては、多かれ少なかれCSVが必須です。
   したがって、バリデーション計画書は必ず作成してください。
   またSAS導入時のIQも実施が必要です。
   OQは、作成したスクリプトに対して実施してください。
   問題はPQなのですが、多くの場合は、2通りのプログラムを用いて結果が一致するか（丸め誤差が許容の範囲か）を検証します。
   
   最近、厚労省のGCP査察でも、担当者が使用しているＰＣまで査察官が行って、「操作して下さい」と言われることがあるようです。
   その際、
   1．エラーが出ないか
   2．受取ったデータを当局側で解析し、会社の担当者に同じプログラムをその場でやらせて、答えを合わせる
   こともしているようです。
   
   [ 追記 ]
   SASの場合、OQでは解析ロジックのテストを行わなければなりません。
   別のプログラムで同等のテストを行い、結果が同じになるかどうかをテストする必要があるでしょう。
   ただしご指摘の通り、自分でロジックを書かない場合は、OQは省略できます。
   
   PQもほとんど必要はありませんが、再現性を確保しておいてください。
   つまり、再解析を命じられても良いようにすべての作業などを記録しておいてください。

戻る

1. まずCSVに関するSOP一式が必要であり、その中でPQに関しても記述されていなければなりません。
   その上で、実際のテストの際に各実施計画書（テスト計画書、IQ計画書、OQ計画書、PQ計画書）を作成する必要があります。
   もちろんPQ計画書はURSに対するTraceability Matrix作成も必要ですね。

戻る

1. 作業記録とパッチのリリースバージョンのログだけを残せば結構です。
   IQの目的の１つは、災害の際の現状回復です。
   そのため構築後の作業の記録（変更記録）が必要なわけです。
   
   ただし、パッチを当てる前の調査（アプリケーションに影響がないことの確認）は一応しておいた方が良いでしょう。

戻る

1. おっしゃる通りなのですが、メルマガで対象としているＣＳＶは、あくまでも規制要件で必要な品質保証を対象としています。
   もちろん旅費精算システムをＣＳＶに則ってバリデーションしてもかまいません。
   ただしその場合、コストをかけただけのメリットをよく検討して作成成果物やテストの範囲を決定したほうが良いでしょう。
   通常、あらゆるシステムは何らかの受け入れテストを行っているはずです。
   メルマガのシリーズで解説しているような、システマティックなＣＳＶでは多少オーバースペックとなるかもしれません。
   
   モニタリングは新GCPになってから、必須となりました。
   つまり査察の対象となります。
   したがって、そのデータの収集、保管、管理を行うモニタリング管理システムは、やはりＣＳＶの対象となります。
   
   モニタリングのデータは、間接的に申請資料の品質に影響します。
   ご指摘の通り、”安全性””有効性”そのもののデータではないかもしれません。
   （モニタリング報告書の内容によります）
   ホームページ上やメルマガですでに解説している通り、申請するデータに「直接的」「間接的」に影響するデータはすべてＣＳＶの適用範囲です。
   ただしFDAの指導している、リスクベースアプローチの考え方にしたがって、それらのデータがどの程度の重要性を持つのかをまず判定してください。
   リスクの低いものについては、ＣＳＶの程度を低くしてもかまいません。
   リスク調査の結果については「リスク調査報告書」や「ファンクショナル・リスク・アセスメント」などのドキュメントに記載します。
   メルマガでもいずれ個々のドキュメントの詳細な解説を行う予定です。

戻る

1. 最近良くある質問です。
   まず前提として、ウィルスソフト自体はバージョンアップせずにデータの更新だけと考えていいですね。
   その場合は、チェンジコントロールで、いつ、どのバージョンをアップしたかを記録しておけばいいでしょう。
   つまり作業記録が必要です。
   
   「アップデートすることによるリスクアセスメント」というのはなかなか難しいと思われます。
   本来は、開発ベンダーがアプリケーションに及ぼす影響を文書化し、配布することの方が望ましいのですが、そのようなことは余りされていません。
   もしアプリケーションに何らかの影響が出ることが心配されるのであれば、システムのバックアップを事前にとっておいた方が良いでしょう。
   
   ウィルスソフト自体をバージョンアップする場合は、IQ関連の文書を作成しなければなりません。
   
   最近、ウィルスも災害対策や障害管理といったドキュメントに対応を記載する企業が増えてきました。
   社内で統一された方針をまず定義し、対応するべきと考えます。
   
   災害対策や障害管理についても順を追ってホームページで解説したいと思います。

戻る

1. あまり重要でない（ドラフトに対する変更など）変更は、いちいち変更管理フォームを起こしません。
   軽微な変更については、口頭で要求を行い、当該文書の変更履歴に記載します。
   このことは、あらかじめ変更管理計画書に記載しておいた方が良いでしょう。
   
   変更管理が大切なのは、複数の文書にまたがる（影響する）記載の変更です。
   つまり、文書間のトレーサビリティを保たなければならない際です。
   
   また、VMPもある程度FIXするまではサインオフをしないのが普通です。
   
   [ 追記 ]
   そもそもFDA等の規制当局が変更を管理することとを要求しているのは、ソフトウェアに関してです。
   一般にソフトウェアはハードウェアに比べて比較的変更が容易と考えられます。
   したがって、ソフトウェアには作為的に本来の目的とは違った機能を組み込んだり、変更することが可能です。
   規制当局はこのことを重視し、変更管理を実施することを強く求めています。
   
   「変更管理」の英語表記はChange Controlであり、Change Managementではありません。
   すなわち管理するというような漠然とした意味ではなく、変更をコントロールすることが本来の意味です。

戻る

1. 開発時（計画〜移行）と運用時（利用〜廃棄）は、別けて考えなければなりません。
   何故ならば、プロジェクトチームは、移行フェーズが終了（つまりバリデーション報告書が承認された時点）で解散となり、以降はサポートチームとユーザにシステムが移管されるからです。
   バリデーション計画書はバリデーション報告書の完成をもって役目を終えます。
   バリデーション報告書が完成した後には、サポート品質計画書やサービスレベルアグリーメント（SLA）が作成されます。
   
   サポート品質計画書は、運用時におけるバリデーション状態の維持を計画し保証するものです。
   通常、開発（プロジェクト）は数ヶ月ですが、運用は5年以上、場合によっては10年も続きます。
   FDA等の当局が懸念しているのは、この長い運用期間中にバリデーションされたシステムが、ノン・バリデート状態にならないことです。
   
   バリデーションされた状態が維持されない理由は、変更によります。
   変更には、1．ユーザ要求の変更（つまりSOP等が変更になる）2．規制要件の変更　3．規制要件の解釈の変更　があります。
   1．は明らかです。
   2．はPart 11が良い例です。Part 11発行後はそれまでバリデートされていたシステムが、すべてノン・バリデート状態とされてしまいました。 これは、Part 11がレガシーシステムを免責しなかったからです。 3．はScope & Applicationなどが例として挙げられるでしょう。
   
   運用時にはどのようなやり方があるかというご質問ですが、上記のSLAを履行しつつ、サポート品質計画書に記載されたサポート組織、役割、責任で計画されたとおりのアクティビティを実施します。
   例えば、システムアクセス管理（セキュリティ）、バックアップ（およびリカバリー）、メインテナンス、継続教育などがあります。
   また最重要なのは、定期監査です。
   
   具体的にご理解いただくためには、サポート品質計画書やSLA、定期監査報告書などの実例を見ていただくことが最善と思います。
   メルマガでは、順を追って実例を解説していきたいと考えております。しばらくお待ちください。

戻る

1. そもそもCSVは、変更可能なソフトウェアを軸に考慮する必要性があります。
   OSやDBやファームウェアの類は、普通はCSVの対象とはしません。
   （もちろん工場の自動化システムを特注した場合なんかは、話は別ですが。）
   
   �@値を表示するだけの電子天秤
   この場合は、キャリブレーションのみで良いと考えられます。
   標準器を使用して、適切な期間ごとに調整を行います。
   
   �Aデータを取り込むPCが繋がった電子天秤
   もしPCがデータを処理するソフトウェアを搭載する際には、そのCSVが必要になります。
   単にOSを利用するに留まる場合（実際にはあまりありえませんが。）はCSVは必要ないと考えます。
   
   FDA等の規制当局がコンピュータシステムに求めるのは、
   1．バグ等の不具合によるデータの信頼性の低下の防止
   2．ソフトウェアの変更に伴う、不具合の増加、潜在化の防止
   3．変更管理（Change Contorol）外での改変の防止
   があげられます。（注：もちろんこれらはCSVの目的の一部にすぎません。）
   
   つまり、データの品質や品質保証に影響するような危険性（リスク）が潜むか否かによって、CSVの必然性を判定するということになります。

戻る

1. パッケージのバリデーションは出来るだけしたくないですよね。
   例えば、MS-Excelのように繁用されている製品はほとんどCSVの必要性は無いでしょう。
   しかしながら、パッケージが信用出来るか、出来ないかは開発元の信頼性に大きく依存します。
   まずはベンダーオーディットを行って、当該ベンダーのバリデーションの記録を見てくる必要があります。
   テスト計画書がちゃんと存在し、すべてのテストが行われ、すべての記録が無いといけません。
   もちろん発見された不具合がすべて改善されていなければなりません。
   私が経験する限り、多くのベンダーでは、これらのテストが不十分です。
   
   またパッケージを調査して、どれくらいの出荷実績があるかも、自社でのCSVの程度を決める要因となります。
   
   FDAはパッケージであっても、出来る限りCSVを行うこと、事前に不具合や制限事項を調べて回避策を検討することなどを求めています。
   上記の趣旨からして、保証書だけではだめです。
   OQを省略できるかどうかは、上記のベンダーオーディットやパッケージ調査の結果次第といえます。

戻る

1. 一般にコンピュータシステムの信頼性保証を行うためのスキルは、
   1．品質保証に関する知識（例：ISO）
   2．規制要件（バリデーション、ER/ES等）の知識
   3．ITの知識
   4．ユーザ業務の知識
   です。
   更に外資系企業などでは、
   5．英語
   も必要でしょう。
   
   これらのスキルミックス（スキルセット）で、システムのバリデーションを実施します。
   ご質問のQA担当者のスキルとしては、この中で１．と２．が中心になります。
   
   ちなみにQAは、Independentでなければなりません。
   つまり利害関係のない第三者です。
   品質保証とは、同じ品質（スペック）のアウトプットを繰り返し生産できると言う保証です。
   つまり再現性が重要です。
   例えば、プロジェクトチームがバリデーション計画書を作成した際に、第三者的にレビュし、もし自分が行ったとしても同様の計画にしたであろうかと言う観点で見ます。
   またはバリデーション報告書は、もし自分がバリデーションをやったとしたら、同じ結果を導いていただろうかと言う観点でレビュします。
   更にもう一度同じことをやったら、同じ結果になるだろうかと言うことも考察します。
   逆の観点からすれば、プロジェクトチームは、利害関係のない第三者を説得しなければなりません。
   社内の人間を説得できないようであれば、当局の査察官を納得させることは出来ないでしょう。
   
   当社のコンサルタントは、よく製薬会社のバリデーションをお手伝いし、QA担当者のコメントを目にします。
   多くが「てにをは」の修正や、単語の間違いの指摘など、おおよそ品質保証とは関係しないような指摘にうんざりすることが多々あります。

戻る

1. バリデーションに限らず、発効中の文書（基準書）に従うことは当然です。
   製造工程や設備のバリデーションと書かれていますので、プロセスバリデーションの組織を指しておられると理解いたしました。
   CSVの実施に必要なスキルは、プロセスバリデーションとは異なります。
   したがって、同じ組織でCSVを実施できるとは限りません。
   まずCSVに関する文書（基準書）等を作成し、CSV実施体制を明確にするべきです。

戻る

1. ER/ESとCSVは、目的と体制が異なります。
   CSVは、システムの信頼性を保証することが目的です。
   ER/ESは、CSVにより信頼性が確保されたシステム上で利用する電磁的記録・電子署名の信頼性を保証するものです。
   したがって、体制上ER/ES責任者、ER/ES管理者とCSV実施体制は直接関係しません。
   ちなみに、ER/ES責任者は、社長以下、経営層を指しています。
   ER/ES管理者は、電磁的記録を利用する部門の長を指しています。

戻る

1. まず、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に記載されています。
   
   最後に、デジタル署名はおっしゃるとおり、オープンシステムを利用し送信する際のリスク（改ざん、成りすまし）を回避するための手段です。
   また、盗聴を防止するためには暗号化が必要です。

戻る

1. まず電子署名とはについて解説しなければなりません。
   電子署名は、業務中の単なる確認やデータの確定といったものを指していません。
   あくまでもFDAに提出する申請資料等への署名を指します。（臨床開発で言うと、総括報告書等、非臨床で言うと試験計画書と試験報告書等）
   R&Dの一研究員が法的拘束力を問われても仕方がありません。あくまでもGxPで定義した会社の責任者レベルに対して言っています。（非臨床で言うとStudy Director以上）
   
   パスワード管理については、Part11条文の中で再三言及していますので、電子署名に関しては、ユーザIDとパスワードの組合せのみで十分といえます。
   
   余談ですが、日本の電子署名に関する規制（E2Bなど）では、米国の電子署名のことをデジタル署名と訳しています。（話をややこしくしています。）
   
   さらに余談ですが、バイオメトリックスは欧州のとある国では使用できません。個人のプライバシーにかかわる法律があるためです。

戻る

1. この件に関しましては、現在ある理由から詳しくはお答えできません。

戻る

1. ドラフトルールからファイナルルールになる過程で改訂（削除）されたためです。

戻る

1. （現行の）Part11を正確に理解していただくことが必要です。
   ディジタル署名が必要なのは、オープンシステムの場合です。
   EDCを構築した場合、クローズドシステムであればディジタル署名は必要ありません。
   逆にオープンシステムを利用する場合、症例報告書に限らずすべての伝送データにはディジタル署名が必要になります。
   
   メルマガ（7.26）にも書きましたが、電子署名とディジタル署名はまったく違います。
   これらを混同してはいけません。
   
   現行のと書いたのは、FDAでは今、改定Part11として、オープンシステムとクローズドシステムを区別すべきか、そうでないかを議論しているからです。
   
   なお、ディジタル署名を利用するのが嫌ななのであれば、EDCをクローズドシステムで構築してください。

戻る

1. 私がPart11のコンサルティングを実施していますお客様では、6文字としていただいております。
   もちろんそれ以上でも結構です。
   
   業界の平均以下はまずいですね。
   まぁ、みんなでわたれば怖くないというやつです。

戻る

1. 米国版が実質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指針対応を検討する必要がある。
   などでしょうか。

戻る

1. 当該機器を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の対応が必須と判断された場合は、監査証跡（特に変更履歴）は、システムに持たせないといけません。

戻る

1. おっしゃるとおり、日本での実験における”バリデーション作業”は3回が常識です。
   これは、日本では「人は信用するが、機械は信用しない」という信条から来ています。
   
   ところが、USではこれが逆転して、「機械は信用するが、人は信用しない」というのが信条なんですね。
   したがって、コンピュータシステムのバリデーションの場合、1回が原則です。
   つまり機械を信用しますので、1度のテストでも”結果は再現されるはず”という風に考えます。

戻る

1. IQの目的のひとつは、システムクラッシュなどの際に、速やかに復旧できることです。
   パッケージの説明書にインストール方法が書かれていれば、省略できます。
   
   ただし、パラメータの変更やDBのスキーマ等の設定は当然のことながら文書化が必要です。
   
   COTSのメリットは生かしたいですよね。
   
   注）GAMP5ではIQという概念はなくなりました。

戻る

1. ユーザ要求仕様書（URS）およびPQシナリオのインプットはSOPです。
   新SOPはDeployment（移行）フェーズで用意します。
   ただしPQ実施時までに用意するのは新SOPのドラフトです。
   
   新SOPの元になるのは、URSです。
   つまりURSにはユーザが導入するコンピュータシステムを使って、どんな業務を行いたいかを記載しています。
   PQはURSを元に実施します。
   PQの実施結果に応じて、新しいSOPのドラフトをファイナライズします。
   
   システムの負荷テストもPQで実施します。
   たとえば、多人数で使用するとか、ネットワークのスピード、大きなファイルのアップロードなどです。

戻る

1. 一概にはそうとは言えません。
   まず新しい環境というのが、例えばサーバの交換などのようなH/Wの変更を指すのでしょうか。
   H/Wの変更やOSのバージョンの違いによって、ソフトウェアの動作に影響しないとは断言できません。
   特に周辺機器（分析機器、スキャナー、プリンター）との接続がある場合には注意が必要です。
   一通りの動作確認をOQとして実施することが望まれます。
   当然のことながら、機能のテストを実施する必要はありません。
   
   またURSに従って、ユーザの望むパフォーマンスが出せることの確認もPQとして必要ですね。
   
   以上のことは、システムの重要性、規模、複雑性に従って、適切なテスト計画を作成するのが普通です。
   また、上記のようなシステム変更に伴う懸念事項が全くないという確信がある場合には、OQ、PQは省略できるでしょう。
   ただしその場合も、OQ、PQを行わない根拠を文書化しておいた方が良いでしょう。

戻る

1. 単体・結合（連結）テストは、ベンダー側が構築（Build）フェーズに実施します。
   一方、IQ、OQ、PQはユーザ側（製薬会社側）で実施します。
   
   GAMPにも紹介されていますが、システムテストのことをOQと呼びます。また受け入れテスト（User Acceptance Test = UAT）をPQと呼びます。
   システムテストと呼ぶかOQと呼ぶかなどは、国や業界によって異なるようです。

戻る

1. 問題点として、そもそも電子署名法は、インターネットなどのオープンな環境で商取引を行う際の印鑑に代わる電子署名を法的に認めるというものです。電子には印鑑を押すことができないからです。
   電子の世界では、相手の顔を見ずに、また声も聞かずに注文や契約が行われます。つまり本人を確認する方法がありません。
   リアルな世界では、書類に実印をつきます。また契約が本当に本人の行為であるかどうかは、印鑑証明書と陰影を比べればわかります。これを「文書の真正な成立の推定」と呼びます。
   電子の世界で、印鑑証明に代わるものが認証局です。
   
   したがって、電子署名法は電子署名に根拠を持たせ、さらに認証局を定義しています。
   
   つまり電子署名法は、「実印」を電子的に押印するための法律であって、製薬会社の社内で行われるような承認作業（せいぜい認印）をカバーするものではありません。
   この電子署名法を参考にSOPを作成したならば、社員が実印を持って出社するのと同じことになってしまいます。
   
   電子署名法に準拠しなければならないのは、安全性電子報告など、社長印を押して当局へ提出する場合に限られます。
   
   暗号化は追加措置として検討が必要です。
   ちなみにインターネットなどのオープンなネットワークでは、
   1．盗聴
   2．改ざん
   3．なりすまし
   のリスクがあります。
   1．は暗号化で、2．3．はディジタル署名で回避します。
   
   もうひとつの問題点は、「電子署名」の定義が電子署名法とER/ES指針で異なるということです。
   電子署名法の「電子署名」はER/ES指針の「ディジタル署名」に相当します。
   ER/ES指針の電子署名は、「電子的に署名をする」という行為をさしています。
   電子署名法の電子署名は、「電子的署名の技術」をさしています。

戻る

1. あえて言うならば、「真正性の要件」です。
   決して「保存性の要件」ではありません。
   
   「保存性」はあくまでも電磁的記録媒体上にある、静的な維持状態です。
   「真正性」が最も忌み嫌う「改ざん」が起きるのは、電源アップ時です。
   
   UPSは、停電時などに、安全にシステムをシャットダウンするためのものですので、「バックアップ」の要件にも似ているともいえます。

戻る

1. 電子文書法などの関連法規上（厚生労働省令44号を含む）では、紙は省けます。
   しかしながら、GCPの必須文書の規定では、医療機関側でCRFの副本を保存しておく義務があります。
   EDCを利用した場合は、CRFなどの生データが、製薬会社側のシステム上にしか存在しないことになります。
   したがってCRFを紙に印刷し、責任医師の署名か記名・捺印をした上で、医療機関側でも保存しておいていただく必要性があります。
   
   またEDCの運用に当たっては相当な検討が必要です。
   EDCそのもののCSV、データの信頼性保証、SDV、医療機関側での電子カルテの信頼性などなどです。

戻る

1. パブリックコメントの回答の80番でも、同様の質問があります。
   
   指針の「3.1.1. 電磁的記録の真正性」には、「電磁的記録が完全で、正確で、信頼できるとともに」と記載されています。
   この中の「信頼できる」に該当するのではないかと思います。つまり、バックアップによって災害など万が一の際に復旧が可能であれば、データを電磁的記録として維持しておいても信頼できるからです。
   
   なお「保存」と「バックアップ」はその目的も方法も全く異なりますので、混同しないようにしてください。
   電磁的記録による「保存」とは、紙媒体によってキャビネットに入れて保存する代わりに、電磁的記録により、ハードディスクなどに記録し、適切に保存することを指します。
   一方「バックアップ」は、その電磁的に保存された状態を、マグネチックテープなどに複製しておくことを言います。
   「保存」中の資料（記録）は常に検索･抽出が可能な状態でなければなりません。「バックアップ」は検索･抽出には利用しません。また災害等でデータが失われない限り、バックアップしたデータは再利用しません。

戻る

1. 日本版ER/ES指針は、当局が受け取る書面を電磁的記録により提出する場合と、当局が査察（書面調査）する書面を電磁的記録により保存する場合の要件です。
   しかもそれらが作成（承認）後、保存または提出したものを対象としています。承認もされていない文書を当局が査察しません。
   
   ご質問は、後者の方だと理解します。
   後者の書面を日本版ER/ES指針では「原資料」と呼んでいます。
   これは薬事法及び関連法令により保存が義務づけられている書面を指し、GCPでは必須文書のことです。
   必須文書は、当局がGCP省令に基づき、査察を行う権限を有しています。
   
   ご質問のClintrialに入力されたデータや、Clintrialから出力された帳票は、必須文書でしょうか？
   （つまり薬事法及び関連法令により保存が義務づけられている書面でしょうか？）
   言い換えると当局が査察を行う根拠があるでしょうか？
   もし、その帳票に改ざんが見られた場合、当局はどんな行政処分を発動できるでしょうか？
   その根拠はどこにあるでしょうか？
   上記から明らかです。
   
   なお、日本版ER/ES指針の適用を受けないことと、GCPの実地調査とは別物ですので、ご注意ください。
   GCPの実地調査では、治験の信頼性保証を確認するためさまざまな調査が行われます。
   Clintrialのデータも例外ではないでしょう。
   ただし、日本版ER/ES指針査察ではありません。

戻る

1. 平成17年8月2日に、ER/ESシンポジウムが開催された際に、冒頭で総合機構の井本昌克氏が、「（利用しようとする者とは）社長に言っています。」とコメントされました。
   つまり会社のトップを指しています。
   100歩譲って取締役、200歩譲って執行役員です。
   GXP部門の長が取締役であれば問題ないでしょう。
   
   規定（方針書）は、会社規模で作成することが望ましいですが、R&Dと生産では対応に温度差が出ることが多いです。
   部門別にならざるを得ないでしょう。
   
   システムオーナーは、管理者ではありませんので、注意してください。
   日本版ER/ES指針が指す、管理者は電磁的記録の管理者（データオーナ）です。
   システムの管理者ではありません。

戻る

1. いいえ。電子だから特別に署名が必要というわけではありません。
   Part11の多い誤解の1つに、今回のようなご質問があげられます。
   
   Part11は、単に電子化する際の規制（実は規制緩和なのです）であって、電子化したから署名を増やさないといけないものではありません。
   紙ベースで行っている（または行っていた）署名活動はそのまま電子になっても同じはずです。
   手書きの署名を電子署名に置き換えてもいいというのがPart11の精神です。

戻る

1. 実施されています。
   健常人ボランティアパネルを持っているCROと契約して実施することになります。
   
   Phase2、Phase3の7,000円は、ボランティア報酬ではなく、治験協力者への負担軽減費用として、1通院当たり7,000円の交通費支給が認められているもので、患者を対象とした治験は本来無償が原則とされています。（患者が治療の手段の一つとして、治験をボランティアで選択）
   
   Phase1の場合は健常者が通常対象ですので、採血の回数などにもよりますが被験者1人当たり、十万〜数十万円程度の報酬は支払われます。（治療の必要のない健常人に対して、投薬、侵襲的検査等を行う報酬）CROと契約するときに、被験者1人当たりの報酬なども含めて行います。
   
   治験ネット：http://www.chiken-net.com/（※フェーズIの募集はしていません。）

戻る

1. 今年（2004年）5月から、英国でもPhase I試験が規制当局に審査されるようになるのと引き替えに、既に昨年7月からEU全域で「単回microdose臨床試験」という名のスクリーニングPhase I試験 (ICH基準よりも少ない非臨床試験で実施できるスクリーニング目的のPhase I試験）がEU全域（今年から25カ国）で実施可能となりました。
   米国では以前からこの種の試験も当局と企業の協議で実施できますので、日本だけ「蚊帳の外」です。
   日本と欧米との規制の地域差がまた拡大したわけです。
   よって、まだ日本では実施していません。

戻る

1. 論理的には、申請までのスピードが早くなります。
   
   ただし、
   1．Publishing Toolを入れた場合に、申請資料の作成が短縮化される。（数週間）
   2．ビジネスプロセスを改革することによって、IB、プロトコール、CSRの作成が短縮化される。
      （しかし、臨床試験そのものが滞れば同じ）
   3．グローバルな治験の場合、文書の交換、レビュ、承認が促進される。
   4．規模が大きい組織の場合、オーバーヘッドを極力抑えることができる。
   5．作成文書の品質を改善することによって、やり直し（2度手間）を防ぐことができる。
   6．検索機能により、当局、CRO、共同開発会社などからの問い合わせに即答することができるようになり、審査期間の短縮が図れる。
   という感じです。
   
   通常、申請文書管理システムには、もっと根本のビジネスストラテジーの改革を抱き合わせます。
   つまり、申請方針（ストラテジー）の早期決定と変更管理をVisualに行うことによって、開発途中での方針変更、申請直前の駆け込みによるつじつま合わせを防ぎます。
   具体的には、開発基本計画を策定し、常に計画と試験（非臨床、臨床）報告書の完成をチェックします。
   往々にして、各社では基本計画があっても、チェックポイントがなかったり、計画が守れなかったり、元々守れない計画であったりと、杜撰な管理が目立ちます。
   また申請直前に必要な試験が足りなかったというような、ヘマも防ぎます。
   
   そういう意味では、申請文書管理とプロジェクト管理は表裏一体です。
   その2つの仕組みと斬新な新ビジネスプロセスを組めあわせて、はじめて申請のスピードアップと品質向上が図れます。
   
   ご存知のとおり、業務プロセスを変革するには、大変な労力が必要です。
   強力なリーダシップと精神力、明確なゴールなどが必要と言えます。

戻る

1. まずPart11に対応しなければならないのであれば、Part11に対応してくれるベンダーやASPと契約することです。
   次にシステムの廃止（廃棄）については、「正確かつ完全なコピー」が取れることが条件となっています。
   ここで言う「完全な」というのは、監査証跡などのメタデータを含めてすべて電子コピーが作成されることを示します。
   これは「臨床試験を再現できる」という、「Computerized System Used in Clinical Trials」の要件を満たす必要があるからです。
   また原本は電子ではなく、カルテなどの原資料、CRFであると思われますので、必ずしも電子データをオリジナルシステムで保管する必要性はないと考えます。
   もし電子コピーも作成不可能で、紙で保管せざるを得ない場合でも、上記の要件（正確かつ完全）を満たさなければなりません。

戻る

1. 結論から申しますと、OQやPQの問題ではありません。
   ご質問者は、各検証作業（DQ、OQ、PQ）を混同されているように感じます。
   
   ご質問に回答する前に、整理をしたいと思います。
   まずOQはシステムの機能を検証します。つまり仕様を満たしているかどうかをユーザ側で確認するわけです。
   前提とされている「システム開発を伴わない測定機器」の場合、ベンダーの保証を得ているならば、OQの大部分は省略することができます。（もちろん各社のSOPに明記されていなければなりませんが。）
   OQを実施しなければならないのは、設置後何らかの他の装置と接続していたり、ソフトウェアのモジュールやライブラリを組み合わせた場合など、いわゆるカスタマイズ（カスタムメイド）を行った部分の検証（テスト）です。
   
   次にPQは「ユーザの意図した性能」を満たすかどうかを検証します。
   同じシステムを導入したとしても、ユーザによっては使用方法（業務プロセス）が異なり、PQはそれぞれ異なります。
   多くの場合、どんなシステムであれ、PQを省略できるケースはほとんどありません。
   通常（正常）の業務プロセスと、少し複雑（またはイレギュラー）な業務プロセスを織り交ぜてテストケースを作成します。
   PQでは、よりリスクの高い業務プロセスの特定と運用環境の安定性の保証を目的とします。
   
   さてベンダーが「監査証跡の機能がある」と回答した場合、ユーザ側で何を行わないといけないかというと「監査証跡機能のレビュ」です。
   何故ならばユーザが想定している「監査証跡の機能」とベンダーが実装している「監査証跡の機能」が果たして一致しているかどうかは、詳細を調べてみなければわからないからです。
   これは、通常DQ（Design Qualification ＝ 設計レビュ）で行います。
   DQは設計フェーズの最後（つまり製造フェーズの前）に行うのですが、パッケージ製品のように、出来合いのものを購入する場合は、事前にパッケージ調査（GAP分析）を行います。
   「監査証跡の機能」の場合、操作履歴が記録されるか、作成履歴が記録されるか、変更履歴が記録されるか、削除履歴が記録されるか。
   または、どのデータに関して監査証跡が記録できるか。
   監査証跡は、どういった手順で確認できるか。
   監査証跡はどのタイミングから記録されるか。
   など、仕様はまちまちのはずです。これらの仕様がユーザの要求（URS）と合致しているかどうかを購入前に調査しておくべきです。

戻る