カートをみる マイページへログイン ご利用案内 お問い合せ お客様の声 サイトマップ

当社コンサルテーションへのご要望・ご質問・お問合せはこちら

【GAMP 5対応】FDA、GAMP 5、ER/ES対応〜CSV対応ガイドライン

【GAMP 5対応】

FDA、GAMP 5、ER/ES対応〜CSV対応ガイドライン

2008年2月28日にGAMP 5が発表されました。また2009年3月にはGAMP 5の日本語版が発行されました。
今後、製薬企業や医療機器企業は、GAMP 5に対応したCSV SOPを作成することが求められます。

GAMP 5に対応した際のメリットとデメリットは、こちらをお読みください。

GAMP 5は、2001年のGAMP4の発表から7年を経ての改定となりました。従って大幅な変更が行われました。
GAMP 5は、現行の業界標準と最新の規制要件を満たしたとされています。
FDAやPIC/Sのドキュメントを参照しています。PIC/Sには現在33カ国が参加していますので、GAMP 5に対応すれば、事実上FDAとあわせて世界34カ国の規制要件を満たすことになります。
厚労省から2009年度中に発出されると予想される「コンピュータ化システムバリデーションガイドライン」(厚労省CSV指針)も、GAMP 5を参照し、作成されています。


これまでのGAMP 4は、システムを一から構築することを想定していました。しかしながら多くの場合は、設定変更(コンフィギュレーション)が可能な市販製品(パッケージ)を利用することが多いはずです。
またGAMP 4は、工場の自動化システムを想定しており、いわゆるコンピュータシステムが対象ではなかったようです。
GAMP 4はタイトルが「GAMP Guide for Validation of Automated Systems」でしたが、GAMP 5では「A Risk-Based Approach to Compliant GxP Computerized Systems」となりました。

大きな変更点の一つ目は、ソフトウェアカテゴリーの変更です。
カテゴリー1は、これまでOperating Systemであったのが、 Infrastructure Softwareと変更になりました。これにはOSやデータベースやミドルウェアを含みます。
カテゴリー2は、Firmwareでしたが、もう使用しません。
カテゴリー3は、これまでStandard Softwareであったのが、 Non-configured Softwareと変更になりました。これは設定変更不可であるソフトウェアや、設定変更が可能(Configurable Software)であっても、設定変更していない(工場出荷時のままの値で使用する場合)ものを含みます。
カテゴリー4は、これまでConfigurable Software Packageであったのが、Configured Softwareと変更になりました。これはビジネスプロセスに合わせて、パラメータなどを変更し、機能を変更しているものです。
カテゴリー5は、これまで通りCustom Softwareで、変更がありません。

変更点の二つ目は、V-Modelです。
これまでGAMP 4では、パッケージであろうが自社開発であろうが、同様のバリデーションを要求していました。
GAMP 5では、V-Modelをカテゴリー3、4、5ごとに検証(テスト)基準を区別しています。
IQはGAMP5でなくなり、OQ、PQという検証のための用語は、特定しないこととなりました。つまり各社が適宜SOPで定義することになります。
業界の多くは、それぞれSystem Test、User Acceptance Testと呼んでいることが多いようです。GAMP 5のV-Modelの図では、それぞれFunctional Testing、Requirements Testingと記載されています。
カテゴリー4では、コンフィギュレーションの検証が新たにV-Modelに加わりました。おそらくこれは定義し、入力した設定値の読み合わせに相当するものと理解します。
カテゴリー5では、モジュールテストとインテグレーションテストが新たにV-Modelに加わりました。これらはGAMP 4では、V-Modelの底にあったソフトウェアの構築時(つまりコーディング時)に行われていたものです。通常これらのテストはサプライヤーが行うでしょう。

変更点の三つ目は、サプライヤーの活用です。これまではサプライヤーが行ったテストなどの活動を製薬企業が繰り返していました。またサプライヤーから入手したドキュメントを自社の様式に変換するといった非生産的な活動もされてきました。本来サプライヤーが作成したドキュメントを製薬企業側で再作成する必要はないはずです。
これらを見直しサプライヤーのQMS(Quality Management System)を尊重しようということになりました。サプライヤーは、自社のきちんとしたQMS(Quality Management System)を持っているべきで、彼らのソフトウェアの製造やテストなどの活動は自社のQMSに従って実施されるべきです。今後はサプライヤーオーディットがますます重要となるでしょう。

上述の通り、大きくは3つの変更点があるように感じます。しかしながらこれらは既に多くの製薬企業では実施してきたことではないでしょうか。
GAMP 5は、GxPコンピュータシステムを対象としていますが、まだまだGMPに特化しているような感があります。非臨床、臨床開発、市販後調査分野(R&D分野)においてGAMP 5対応のSOPを作成するには、それなりの労力がかかりそうです。

【GAMP 5対応】FDA、GAMP 5、ER/ES対応〜CSV対応ガイドライン

価格:

108,000円 (税込)

[ポイント還元 10,800ポイント〜]
購入数:

在庫

在庫あり

返品期限・条件 商品種別による返品の詳細はこちら
この商品について問い合わせる
友達にメールですすめる

目次

1. 目的
2. 適用範囲
3. 用語の定義
 3.1 規制当局
 3.2 バリデーション
 3.3 GxPデータ
 3.4 GxPコンピュータシステム
 3.5 コンピュータシステム(Computerized System)
 3.6 サービス
 3.7 SLC(System Life Cycle)
 3.8 コミットメント
4. 背景
5. リスクベース・アプローチ
6. CSVの原則
7. 役割と責任
 7.1 CSV実施組織
 7.2 各システム(プロジェクト)に共通の役割
  7.2.1 役員
  7.2.2 部門の長
  7.2.3 CSV委員会
  7.2.4 情報システム部門(IS)
  7.2.5 従業員
  7.2.6 品質保証部門(CVQA)
  7.2.7 QAマネージャ(QAM)
 7.3 システム(プロジェクト)毎に定まる役割
  7.3.1 システムオーナ(SO)
  7.3.2 プロジェクトオーナ(PO)
  7.3.3 プロジェクトマネージャ(PM)
  7.3.4 プロジェクトチーム(PT)
  7.3.5 バリデーションマネージャ(VM)
  7.3.6 バリデーションチーム(VT)
  7.3.7 ユーザ
  7.3.8 サプライヤ(SPL)
  7.3.9 システム管理者(SM)
  7.3.10 システム管理チーム(ST)
  7.3.11 文書管理者(DA)
8. 変更・障害管理
 8.1 変更管理
 8.2 障害管理
9. 成果物の執筆
 9.1 著者及び共著者の責任
 9.2 テンプレートの利用
10. ソフトウェアのカテゴリ
 10.1 CATEGORY 1(基盤ソフトウェア)
 10.2 CATEGORY 2(ファームウェア)
 10.3 CATEGORY 3(コンフィギュレーションしないパッケージ製品)
 10.4 CATEGORY 4(コンフィギュレーションしたパッケージ製品)
 10.5 CATEGORY 5(当社専用開発ソフトウェア)
11. 成果物の種類と属性
 11.1 計画書
 11.2 報告書
 11.3 仕様書
 11.4 スクリプト
 11.5 ログ
12. 成果物とカテゴリ
 12.1 管理(Management)
 12.2 開発(Development)
 12.3 運用(Operation)
13. SLC各フェーズのバリデーション活動
14. SLC各フェーズの成果物とその概要
 14.1 計画フェーズ(Planning Phase)
  14.1.1 業務プロセスとシステム化に対する要求事項の文書化(ユーザ要求仕様書)
  14.1.2 バリデーションの必要性の評価(リスク評価報告書)
  14.1.3 バリデーション計画の策定(バリデーション計画書)
  14.1.4 パッケージの調査(パッケージ調査計画書、パッケージ調査報告書)
  14.1.5 サプライヤの評価(サプライヤオーディット報告書)
 14.2 要求フェーズ(Requirement Phase)
  14.2.1 詳細要求の策定(機能仕様書)
  14.2.2 コンフィギュレーションの決定(パッケージコンフィギュレーション)
  14.2.3 機能リスク評価(機能リスク評価表)
14.3 設計フェーズ(Design & Build Phase)
  14.3.1 コンピュータシステムに対する要求の詳細化(設計仕様書)
  14.3.2 設計の確からしさの検証(DR報告書)
  14.3.3 サプライヤによる詳細設計(モジュール(ユニット)仕様書)
  14.3.4 サプライヤによるコンフィギュレーション作業
  14.3.5 コンフィギュレーションテスト(コンフィギュレーションテスト計画書、コンフィギュレーションテスト報告書)
  14.3.6 サプライヤによるコーディング及びソースコードレビュ(ソースコード、プログラミングスタンダード、ソースコードレビュ計画書、ソースコードレビュ報告書)
  14.3.7 モジュール(ユニット)テスト(モジュール(ユニット)テスト計画書、ケース、報告書)
  14.3.8 インテグレーションテスト(インテグレーションテスト計画書、ケース、報告書)
  14.3.9 テストのための計画策定(テスト計画書)
  14.3.10 正確なデータの移行のための計画策定(データ移行計画書)
  14.3.11 本稼動のための移行計画策定(移行計画書)
 14.4 導入フェーズ(Test & Deployment Phase)
  14.4.1 包括的なテストの特定と全ての正式なテストの実施(ST計画書、STスクリプト)
  14.4.2 テスト結果の記録とレビュ(STログ、ST報告書)
  14.4.3 運用環境の安定性の保証(UAT計画書、UATシナリオ、UATスクリプト)
  14.4.4 コンプライアンスリスクが高い業務プロセスの評価(UATログ、UAT報告書)
  14.4.5 システムアクセス計画の策定(システムアクセス計画書)
  14.4.6 本稼働への準備(システム利用手順書、ユーザサポート資料)
  14.4.7 サービス部門とユーザとのサービス合意(サービスレベルアグリーメント)
  14.4.8 データ移行に関する報告の要約(データ移行報告書)
  14.4.9 実稼動後における災害対策の策定(災害対策計画書)
  14.4.10 バリデーション活動に関する総括と利用開始宣言(バリデーション報告書、システムリリース通知書)
  14.4.11 運用フェーズにおけるバリデーション維持活動の計画策定(サポート品質計画書)
 14.5 運用フェーズ(Operation Phase)
  14.5.1 移行に関する報告の要約(移行報告書)
  14.5.2 バリデーション維持の保証(サポート品質報告書)
  14.5.3 定期的な監査の実施(定期監査報告書)
 14.6 廃棄フェーズ(Retirement Phase)
  14.6.1 システム廃棄に関する計画と報告(システム廃棄計画書、システム廃棄報告書)
 14.7 各フェーズ共通事項
  14.7.1 変更の管理(変更管理計画書、変更要求書、変更要求一覧表)
  14.7.2 障害の管理(障害対策計画書、障害報告書、障害一覧表)
  14.7.3 ドキュメントの管理(ドキュメント管理計画書、ドキュメント進捗管理表)
  14.7.4 トレーニングの管理(トレーニング計画書)
  14.7.5 トレーサビリティマトリックスの作成(トレーサビリティマトリックス)
15. SOP
16. 参考
17. 付則

入金確認後(クレジットカードの場合は決済完了後)に、ダウンロードのためのURLを電子メールにて送信いたします。

ダウンロード後の返品はできません。
内容に関するご質問等は受け付けます。

購入前に、ご連絡いただきましたら、商品サンプルを持参し、貴社をご訪問いたします。
ご遠慮なくお申し付けください。

お見積書や領収書が必要な場合もお申し付けください。
複数文書を一括してご購入される場合は、合計金額に応じて割引をさせて頂きます。
詳しくはお問合せ下さい。

当社コンサルテーションや商品へのご要望・ご質問・お問合せはこちら



【お支払方法について】

以下のお支払方法がご利用いただけます。

1.銀行振り込み、郵便振替

銀行振込 郵便振替

ご請求書を郵送します。
貴社お支払規定に従い、お振込ください。

2.クレジットカード

クレジットカード

3.楽天ID決済

楽天ID決済

4.コンビニ決済

クレジットカード


【領収書について】

領収書が必要な場合は、ご連絡ください。上記のいずれのお支払方法でも領収書を発行させて頂きます。

ページトップへ