CSV：#10　CSV活動で作る文書⑥ PQ

こんにちは、木村です。

CSV活動で作る文書シリーズは、今回は性能適格性評価（PQ; Performance Qualification）で作成する文書について説明します。

1. 性能適格性評価（PQ）とは

性能適格性評価（PQ）は、コンピュータ化システムの稼働時の環境下において、要求仕様書に定義した要件が実現されていること、承認された業務手順に従った運転が可能であることを確認して記録する活動です。この活動は運転時適格性評価（OQ）後に実施します。

• 規制上はカテゴリ分類3、4、5のソフトウェアの開発で実施します。
• 原則として運用時と同じ環境で実施します。しかし、運用時の環境と同等だと認められる場合は、テスト環境（運用時の模擬的な環境）を用いて実施してもよいです。例えば、稼働中のシステムの停止を伴って業務に影響を及ぼす場合や、接続先システムの本番データを書き換えてしまう場合、例外フローの検証によって運用環境に影響を及ぼす場合などはテスト環境で行うこともあります。

GAMP5では要件テストとして示された箇所のガイドラインが該当します。

意図した用途への適合性を実証しかつ特定の要件に対応したシステムの受け入れを許可するテスト、あるいはその他の検証

活動の流れは据付時適格性評価（IQ）や運転時適格性評価（OQ）と同じです。改めて説明しますと、まず初めに性能適格性評価（PQ）の戦略や実施事項を計画します。次に、計画で定義されたテストケースのスクリプトを用意します。テストケースのスクリプトを用いてテストを実施し、その結果と判定を記録します。最後に、記録した結果と判定をもとに活動結果をまとめます。

従いまして、作成する文書も据付時適格性評価（IQ）や運転時適格性評価（OQ）と同様です。計画書と報告書は必須で作成し、それに加えて計画書に基づいた詳細な検証内容（テストケースのスクリプト）を記載した項目書（要領書、仕様書ともいう）や検証結果を取りまとめた記録書を作成することもあります。

運転時適格性評価（OQ）と性能適格性評価（PQ）が対象とする検証範囲の違いが分かりにくいと思う方がいるかもしれません。これについては今後、別の記事で書きたいと思います。

2. 性能適格性評価（PQ）で作成する文書

いつ作るのか？

性能適格性評価（PQ）関連の文書は、コンピュータ化システムのライフサイクルの検証段階で作成します。運転時適格性評価（OQ）が終わった後に性能適格性評価（PQ）を開始しますので、計画書はそれに間に合うように作成します。報告書は性能適格性評価（PQ）実施後、バリデーション報告書(*1)の作成前までに作成します。

誰が作るのか？

規制対象組織（製薬会社等）が主体となって作成します。テストケースのスクリプトを記す項目書の作成は、サプライヤにサポートしてもらうこともあります。

どのような目的で作るのか？

性能適格性評価（PQ）が適切に計画及び実施・報告されたことを文書化するために作成します。

どのような事を記載するのか？

適正管理ガイドラインには、計画書及び報告書について以下のように示されています。

検証責任者は、性能適格性評価の計画に関する文書（以下「性能適格性評価計画書」という。）を作成するものとする。性能適格性評価計画書には、原則として次の事項を記載するものとする。
(1) 性能適格性評価の対象となる文書名
(2) システムの稼働時における機能及び性能の確認方法

(3) 性能適格性評価における判定基準

(4) スケジュール

(5) 責任者及び担当者の氏名

また、適正管理ガイドラインではこの計画書に基づいて性能適格性評価を行った後に報告書を作成することが示されています。

検証責任者は、性能適格性評価の報告に関する文書（以下「性能適格性評価報告書」という。）を作成するものとする。性能適格性評価報告書には、原則として次の事項を記載するものとする｡
(1) 性能適格性評価の対象となる文書名
(2) 評価結果と是正措置

(3) 責任者及び担当者の氏名

どのように作るのか？

• 実際の業務を想定したシナリオを基にテストケース及びスクリプトを作成し、それを項目書に記載します。
  
• リスクに応じてシステム管理の業務（システム起動・終了、ユーザ管理、マスタ更新、バックアップ・リストア等）も検証します。
  
• リスクに応じてER/ES要件及びデータインテグリティ要件の検証も盛り込みます。
  
• 例外フロー（データ修正、承認取消、不合格製品の処理等）も検証します。
  
• 検証ケース毎にIDを振ります。1つのIDに複数の検証事項を含めないようにしましょう。このIDは他の検証活動と併せて、要求仕様を全て満たすことを確認する際に使用します。また、1つのIDに複数の検証事項を盛り込むと、検証や要求仕様との紐付けで漏れてしまう恐れがあるので、1つのIDに1つの検証事項を記載します。
• 項目書には「操作手順」「期待される結果」「判定基準」を記載します。
• 記録書には、操作手順に従って実施した結果を記載します。項目書に加えて「実施日」「実施者」「判定結果」を記載します。

性能適格性評価（PQ）はシステムが実業務で利用できることを確認する活動です。作ったシステムで「実現したいことは出来るか？」「業務に合ったプロセスになっているか？」などを確認します。この確認が完了してバリデーション報告書(*1)が承認されると、いよいよ運用段階に入ることができます。

次回はトレーサビリティマトリクスの予定です。

*1　バリデーション報告書：検証活動の全体をまとめた文書。各検証結果を踏まえて、検証活動全体の適否を総合評価する。