バリデーション計画書の書き方


<連載 全12回> CSV実践講座(第2回)

CSV実践について研究するページです。

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

バリデーション計画書の書き方

1. はじめに

CSVを実施する過程で、いったい何種類のドキュメントを作成しなければならないのだろうか。前回のビジネスプロセスマップに示すとおり、全部で約50種類ものドキュメントが考えられる。
しかしながら、実際には当該システムの重要性・規模・複雑性によって、作成するべきドキュメントの種類を適切に判断しなければならない。例えば、MS-ExcelのマクロのCSVと、生産工場の自動化システムでは、当然作成するドキュメントの種類も程度も異なってくるのである。
CSVを実施する際には、ユーザ要求仕様書User Requirements Specification 以下、URS)を評価することによって、当該システムの重要性・規模・複雑性を判定しなければならない。その評価の結果は、バリデーション計画書Validation Master Plan 以下、VMP)に引き継がれ、CSV実施の際のバリデーションの程度、すなわち作成するドキュメントの種類があらかじめ決定される。
今回は、VMPの書き方について解説する。

2. リスクの評価

CSVは、ユーザ要求仕様書の作成から始まる。ユーザが、電子化をしたい業務にはどれぐらいリスクがあるかということを評価し、CSV実施の程度を決定する。(表1 リスク評価チェックリスト参照)
リスク評価は、プロジェクトに利害関係のない第三者が行うことが望ましい。
CSVはリスクの回避および軽減といえる。リスク回避策および軽減策が事前に計画されていない場合には、当該プロジェクトを開始してはならない。後続のVMPでは、これらリスクの回避策および軽減策を文書化し、リスクに応じた十分な程度のバリデーション計画を明らかにしなければならない。

表1 リスク評価チェックリスト

1) GxP 評価

質問

質問

回答

理由/コメント

V.1

当該システムは、厚生労働省の薬事法および関連法令(GVP、GCP、GLP、GMP、GPSP)の対象となるデータ、文書、プロセスを管理するか?

  • いいえ
    本システムは、バリデーションを要求されないため、調査はここで終了

  • はい
    次の質問に回答

 

V.2

当該システムは、FDAのGCP、GLP、GMP規制の対象となるデータ、文書、プロセスを管理するか?

  • いいえ
    FDAの規制要件遵守は必要なし

  • はい
    2章の質問に回答

 

2) 21CFR Part 11 評価

質問

質問

回答

理由/コメント

P.1

当該システムは、FDAの規制に遵守していることを証明する必要のある電子記録を作成、変更、維持、アーカイブ、検索または伝送するか?

  • いいえ
    本システムは、Part11遵守を要求されないため、調査はここで終了

  • はい
    次の質問に回答

 

P.2

当該システムは、主にFAXやスキャンイメージ等の電子的手段による紙記録の送信に使用されるか?

  • いいえ
    本システムは、Part11遵守を要求されないため、調査はここで終了

  • はい
    次の質問に回答

 

P.3

FDA規制は、要求されるドキュメンテーションに対して電子記録の利用を許可しているか?
回答が「いいえ」の場合、記録が紙フォーマットのみで維持することを要求する特定のCFRの参照を記載すること。
CFR Part(s)

  • いいえ
    本システムは、Part11遵守を要求されないため、調査はここで終了

  • はい
    次の質問に回答

 

P.4

当該システムは、「オープンシステム」または「クローズドシステム」のどちらか?

  • オープン

  • クローズド

 

3) ER/ES 評価

質問

質問

回答

理由/コメント

E.1

薬事法及び関連法令に基づいて、医薬品、医薬部外品、化粧品及び医療機器の承認又は許可等並びに適合性認証機関の登録等に係る申請、届出又は報告等にあたって提出する資料として電磁的記録又は電子署名を利用するか?

  • いいえ
    本システムは、ERESを要求されないため、調査はここで終了

  • はい
    ER/ESに準拠

 

E.2

原資料、その他薬事法及び関連法令により保存が義務づけられている資料として電磁的記録及び電子署名を利用するか?

  • いいえ
    本システムは、ERESを要求されないため、調査はここで終了

  • はい
    ER/ESに準拠

 

E.3

1.2.の資料等を最終的に紙媒体で作成する過程において、電磁的記録及び電子署名を利用するか?

  • いいえ
    本システムは、ERESを要求されないため、調査はここで終了

  • はい
    ER/ESに準拠

 

E.4

「治験の実施に関する手順書」で定める資料を、電磁的記録及び電子署名を利用して作成するか?

  • いいえ
    本システムは、ERESを要求されないため、調査はここで終了

  • はい
    ER/ESに準拠

 

E.5

上記1.〜4.の資料等を作成する過程において、本指針発効日以降に作成または変更された電磁的記録及び電子署名を利用するか?

  • いいえ
    本システムは、ERESを要求されないため、調査はここで終了

  • はい
    ER/ESに準拠

 

4) 安全性、有効性、品質及びビジネスリスクに関する評価

質問

質問

回答

理由/コメント

R.1

当該システムの故障は、安全性、有効性、品質のリスクとなりえるか?該当するする項目全てまたは「リスクなし」にチェックをすること

  • 安全性に関わるリスク

  • 有効性に関わるリスク

  • 品質に関わるリスク

  • リスクなし

 

R.2

1日以上の当該システムの故障またはサービスの停止は、業務に重大な影響を及ぼすか?

  • リスクHigh

  • リスクModerate

  • リスクLow

  • N/A

 

R.3

当該システムが故障した場合のビジネスリスクのレベルはどれか?

  • リスクHigh

  • リスクModerate

  • リスクLow

  • システムはビジネス上重要ではない

 

R.4

(自社開発又は個別開発を実施する場合のみ回答)システムの開発が失敗した場合、重大なビジネス上の影響があるか?

  • 影響なし

有りの場合、影響を備考欄に記載。

 

R.5

(自社開発又は個別開発を実施する場合のみ回答)システムの開発が失敗した場合、法的要件及び規制要件への適合に影響があるか?

  • 有り

  • なし

有りの場合、影響を備考欄に記載。

 

R.6

(自社開発又は個別開発を実施する場合のみ回答)ソリューションは当社の方針に合う、確立された技術(WindowsやOracle等)を用いたものであるか?

  • Yes

  • No

Noの場合、利用する技術を備考欄に記載。

 

R.7

(自社開発又は個別開発を実施する場合のみ回答)ベンダーは業界での評判がよく、製薬業界での経験を有しているか?

  • Yes

  • No

Noの場合、リスク軽減策を備考欄に記載。

 

ビジネスリスクの要約

 

設問1〜7の回答から、当該システムのビジネスリスクを判定すること

  • 深刻(Critical)

  • 重大(High)

  • 普通(Moderate)

  • 軽微(Low)

 

5) システムの特質判定
(1) システムの規模

質問

質問

回答

理由/コメント

S.1

当該システムは、グローバルで使用されるか?

  • Yes

  • No

 

S.2

想定ユーザ

  • ユーザ・グループ(システム管理者、オペレータ等)

  • 内部/外部ユーザ

 

S.3

当該システムは、何個のコンポーネント(モジュール)で構成されているか?

  • 5個以上

  • 2 〜3個

  • 1個

 

S.4

当該システムと他接続システムとのインターフェースはどうなっているか?

  • 当該システムと同じ

  • 異なるが簡潔

  • 複雑

 

S.5

データベースの規模

 

システムの規模の要約

 

設問1〜5の回答から、当該システムの規模を判定すること

 

(2) システムの複雑度

質問

質問

回答

理由/コメント

C.1

当該システムは、バリデーションが要求される他のシステムと接続しているか?

  • Yes

  • No

 

C.2

当該システムは、2カ国以上の5つ以上の規制要件を遵守しなければならないか

  • Yes

  • No

 

C.3

当該システムは、5つ以上の国内サイトまたは2つ以上のグローバルサイトに導入しなければならないか?

  • Yes

  • No

 

C.4

当該システムは、外国語のインターフェースを持つか?

  • Yes

  • No

 

システムの複雑度の要約

 

設問1〜4の回答から、当該システムの複雑度を判定すること

 

6) ソフトウェアカテゴリ

質問

質問

回答

理由/コメント

K.1

当該システムのソフトウェアは、CSVガイドラインではどのカテゴリに当てはまるか?

  • カテゴリ1

  • カテゴリ2

  • カテゴリ3

  • カテゴリ4

  • カテゴリ5

 

3. バリデーション計画書とは

リスク評価報告書によって規制要件対応と決定したコンピュータシステムは、必要に応じてバリデーションマネージャを指名し、VMPを作成する。
コンピュータシステムの重要性、複雑性、規模に応じて、妥当な程度でCSVを実施しなければならない。
リスク評価で抽出され、検討されたすべてのリスクについて、それらの回避方法や、万が一の際の対処方法は、VMPにおいて十分に検討されなければならない。
これらリスクの回避方法や対処方法を、事前にQA担当者がレビュし、プロジェクトオーナーが承認することによって、CSVの各タスクが開始される。
VMPの目的は、システムが運用フェーズへ移行するまで、プロジェクト品質をどのようにして達成、管理、維持するかを定義することである。
バリデーション管理は、プロジェクトの規模に応じて適切に実施すること。また、各業務、技術、規制要求事項を考慮に入れること。

VMPには、以下のような当該コンピュータシステム導入プロジェクト全体の品質保証計画を記載する。

  1. バリデーションに携わる組織、人員構成
  2. 期間
  3. バリデーション管理の実施程度
  4. 必要な成果物類等の定義
  5. 除外する成果物の種類
  6. レーサビリティマトリックスの対象となるもの
  7. リスクの回避方法

VMPに記載する品質管理計画は、あらゆるプロジェクト作業が当該組織の情報化戦略、コンピュータと技術的な構成、ユーザサポート要求に沿っていることを保証しなければならない。
VMPは、プロジェクトの早い段階では直近の2フェーズまでの重要な詳細事項を記載し、その後のフェーズに関しては、概要を記載するに留めておく。その場合はバリデーション計画書の改訂により、その後のフェーズの改善点や詳細を記載すること。
VMPは、計画、要求、設計、導入の各フェーズにおいてはシステム開発に対するプロジェクト品質を管理し、システムが運用フェーズ移行した際には(つまりバリデーション報告書が作成された後は)サポート品質計画書に引き継がれる。

4. バリデーション計画書の内容

VMPは、下記の内容を含めて記載すること。

  1. イントロダクション
    1-1 プロジェクトの背景
    1-2 背景
  2. 範囲
    2-1 プロジェクトの定義
           プロジェクトの簡単な記述を行う。
    1. 主要機能の詳細事項
      システムの主要機能についての詳細事項
    2. 関連ドキュメント
      システムを構成するH/W、S/W、インターフェースの概要。
      機能詳細を記載した関連ドキュメントの一覧。
    3. 追加機能
      バージョンアッププロジェクトの場合、追加機能を含めて要約すること。
    2-2 適用されるフェーズ
           当該バージョンのVMPが適用されるフェーズ(システムのライフタイム)に関する記述
    2-3 除外する事項
           本VMPから除外する事項の定義
  3. リスク分析
    リスク評価の要約を記載すること。
    3-1 リスク
           システムの品質に影響を及ぼすかもしれない根本的なリスクと、そのリスクを最小化する活動計画の記述。
    3-2 方法論
           プロジェクトのリスクと、リスクを回避するための方法論を記述。
  4. プロジェクトアプローチ
    システムが運用フェーズに移行するまでのプロジェクトの品質管理に対して取るべきアプローチについて討議する。
    4-1 アプローチ
    4-2 外部業者の利用
  5. フェーズと実施作業
    5-1 フェーズと実施作業
           「CSVガイドライン」に定義されているフェーズと実施作業のうち、本プロジェクト内で着手されるものを特定すること。
           実施作業の順序、依存関係、重複を明らかにする。
           必要に応じて理由を記載すること
    5-2 S/Wのカテゴリとタイプ
           「CSVガイドライン」で定義されているとおり、S/Wのカテゴリとタイプを記載すること
  6. 成果物と作成順序
    プロジェクトのキーとなる成果物の作成マイルストーンを記載すること。
    6-1 最小限のセット
           「CSVガイドライン」に従って、開発するシステムのタイプに応じた最小限のセットと、成果物の合成・分割。
    6-2 除外する成果物
           最小限のセットから除外する成果物とその正当性
    6-3 著者、共著者、レビュ担当者、承認者
           著者、共著者、レビュ担当者、承認者の役割と責任を記載する。
    6-4 トレーサビリティマトリックス
           トレーサビリティマトリックスの対象とする成果物
  7. プロジェクトの終了
    このセクションでは、品質保証とバリデーションの観点から、プロジェクトが成功裏に完了するために必要な事項を記載する。
    7-1 ユーザによるシステムの受諾条件の記述
    1. ユーザによるシステム品質の定義
    2. 受諾条件により、結果を分析する方法論の記述
    3. 受諾条件からの逸脱の評価方法
5. おわりに

プロジェクトの性質や規模によっては、自社のCSVガイドラインやSOPの通りに バリデーションの計画ができない場合がある。例えば作成すべき文書の種類などである。なぜならばSOPは、標準的な業務を記述しているからである。ものごとに例外はつきものである。
プロジェクトにおけるCSV活動が、SOP(標準)どおりに計画できない際には、その「正当化できる理由」をVMPに記載し、「SOPからの変更」を事前にQA担当者がレビュし、プロジェクトオーナーが承認するという手続きを取っておかなければならない。
次回は、「パッケージ調査計画書」および「ベンダーオーディット報告書」の書き方について解説する。

参考