CSV：#9　CSV活動で作る文書⑤ OQ

こんにちは、木村です。

CSV活動で作る文書シリーズは前回から検証段階のお話に入りました。今回は運転時適格性評価（OQ; Operational Qualification）で作成する文書について説明します。

1. 運転時適格性評価（OQ）とは

運転時適格性評価（OQ）は、コンピュータ化システムが運転時において、機能仕様書等に示された機能および性能を発揮することを確認して記録する活動です。

• 規制上はカテゴリ分類4および5のソフトウェアの開発で実施します。カテゴリ分類4はシステムアセスメント(*1)の結果によっては実施しないこともあります。例えば、他のテストで網羅されたり機能が単純・軽微で他のテストと一緒に行ったりすることで、運転時適格性評価（OQ）を省略できる場合がありますが、実施するか否かは各社の判断基準に従って都度判断します。
• マスタデータの設定やバックアップ機能、停電時におけるシステムのリカバリ機能等コンピュータ化システム固有の機能がある場合は、これらの機能も検証する必要があります。
  
• 基本的には運用時と同じ設置場所・環境で実施します。しかし、運用時の環境でテストを実施することが適切ではない場合は、テスト環境（運用時の模擬的な環境）を用いて行うこともあります。

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

既定の全動作範囲において、特定のビジネスプロセスをサポートする機能が正しく動作することを実証するための仕様に対応したシステムのテスト、あるいはその他の検証

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

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

2. 運転時適格性評価（OQ）で作成する文書

いつ作るのか？

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

誰が作るのか？

一般的に運転時適格性評価（OQ）は供給者（製薬会社のIT部門やベンダー等）が作成し、規制対象組織（製薬会社のビジネス部門またはIT部門等）が承認します。

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

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

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

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

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

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

(4) スケジュール

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

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

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

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

どのように作るのか？

• 受入試験(*2)で同等のテストを行っている機能については、計画書にその旨を明記した上で運転時適格性評価（OQ）のテストを省略することも可能です。
• 正常ケース（ポジティブケース）だけではなく、無効ケース（ネガディブケース）のパターンもテストします。
  
• 検証ケース毎にIDを振ります。1つのIDに複数の検証事項を含めないようにしましょう。このIDは他の検証活動と併せて、要求仕様を全て満たすことを確認する際に使用します。また、1つのIDに複数の検証事項を盛り込むと、検証や要求仕様との紐付けで漏れてしまう恐れがあるので、1つのIDに1つの検証事項を記載します。
  
• 項目書には「操作手順」「期待される結果」「判定基準」を記載します。
  
• 記録書には、操作手順に従って実施した結果を記載します。項目書に加えて「実施日」「実施者」「判定結果」を記載します。

運転時適格性評価（OQ）は機能仕様書（FS）や設計仕様書（DS）に記されている機能や性能が実装されていることを確認する活動です。要求された機能・性能が搭載されたことを目に見えて確認できると「設備やシステムが出来上がった！」と実感しやすいのではないでしょうか。

次回は性能時適格性評価の予定です。

*1　システムアセスメント：CSV活動の1つ。システム構築方法や製品に由来するリスク、供給者に依存するリスクなどを評価し、後続活動の作成文書や検証内容を決める。適正管理ガイドラインでは実施する事項として「ソフトウェアカテゴリ分類」「製品品質に対するリスクアセスメント」「供給者アセスメント」が挙げられている。

*2　受入試験：プログラム開発・テスト後に行う検証。供給者の工場集荷前に機能および性能を確認する工場出荷試験（FAT）と、システム設置場所等における受け入れ時に機能および性能を確認する現地受入試験（SAT）がある。