臨床開発におけるコンピュータバリデーション


ウェブセミナー CSV関連

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

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

臨床開発におけるコンピュータバリデーション

1. はじめに

世界的な競争が激化している製薬業界において、新薬開発に要する時間と申請準備期間の短縮は至上命題といえる。また新薬の審査を行う規制当局においても、審査期間の短縮、情報の正確な把握と対応にせまられている。これらの状況によってICHにおいては、電子的な申請の形式である、eCTDが議論されてきた。医薬開発における、データおよびドキュメントの電子化は、作業の効率化、品質向上、情報再利用の促進をもたらす。その結果として企業内、企業と当局間、また当局内において時間とコストの効率化を図ることができる。
このように電子化のメリットは言うまでもないが、手作業による紙の記録に比べて、電子化されたデータは改竄(証拠を残さない変更)が容易かつ改竄の発見が困難になるため、不正改竄から守る特別な管理が必要とされる。また医薬開発で扱うデータは、安全性、有効性、品質に関するものであり、人の健康に幅広く関係するもので最高の品質と完全性がなければならない。従って、業務プロセスがコンピュータ化された際に、その品質がコンピュータ化以前と同等またはそれ以上である事を保障しなければならないことは言うまでもない。つまり製薬企業は、コンピュータシステムの完全性、正確さ、信頼性および一貫したパフォーマンスに対する要求事項に適合していることを保証し、文書化しておく必要がある。FDAによると、医薬におけるバリデーションとは、「文書化された証拠を確立してゆく作業であり、これはあらかじめ定めた仕様や品質にあった製品を継続的に生産するプロセスに対して,高度の保証を与えるものである。」とある。FDAが重視するのは、臨床開発のプロセスおよびその結果である。「プロセスを無視した結果の達成はありえない」のである。プロセスには開発および運用段階の作業管理を含んでいる。
筆者は長年にわたり、臨床試験管理システムや臨床データ管理システム等のアプリケーション・システムを開発、サポートしてきた経験を持つ。その際にある製薬企業の情報システム部員から、「パッケージシステムをカスタマイズしないで導入するのだから、バリデーションは不要ではないか」という指摘を受けたことがある。つまり彼は、バリデーションとはコンピュータシステムの導入テストあるいはソフトウェアの不具合(バグ)の発見のことであると考えているのである。これは言うまでもなく間違いであり、その理由を解説することを試みたのが本稿である。

2. 臨床開発におけるコンピュータバリデーションの根拠

臨床開発において、コンピュータシステムバリデーションを行わなければならない、法的な根拠は何かについて述べてみたい。まず日本においては、平成9年に発行された、厚生省令第28号「医薬品の臨床試験の実施の基準」の中には、バリデーションという用語の記述が見当たらない。しかしながら中央薬事審議会答申第40号「医薬品の臨床試験の基準」(いわゆる答申GCP)の8-1-11-1 1)に「電子データ処理システムが、完全性、正確性、信頼性及び意図された性能についての治験依頼者の要件を満たしていることを保証し、文書化すること(すなわちバリデーションされること)。」とある。この記述が唯一であり、それ以外に関して、バリデーションに関するガイドラインは出されていないのが現状である。

8-1-11 データの取扱い
8-1-11-1 治験依頼者は、データの処理に当たって、電子データ処理システム(遠隔操作電子データシステムを含む)を用いる場合には、次の事項を実施しなければならない。
  1. 電子データ処理システムが、完全性、正確性、信頼性及び意図された性能についての治験依頼者の要件を満たしていることを保証し、文書化すること(すなわちバリデーションされること)。
  2. 当該システムを使用するための標準業務手順書を整備すること。
  3. 当該システムが、入力済みのデータを消去することなしに修正が可能で、データ修正の記録をデータ入力者及び修正者が識別されるログとして残せる(すなわち監査証跡、データ入力証跡、修正証跡が残る)ようにデザインされていることを保証すること(6-2-9-5参照)。
  4. データのセキュリティ・システムを保持すること。
  5. データのバックアップを適切に行うこと。
  6. データの修正を行う権限を与えられた者の名簿を作成し、管理すること(6-1-8及び8-1-11-4参照)。
  7. 盲検化が行われている場合には、盲検性が保持されるようにすること。
8-1-11-2 治験依頼者は、処理中にデータの変換を行う場合には、処理前のデータと処理後のデータを常に対比し得ることを保証しなければならない。

表 1 答申GCP 8-1 治験依頼者の責務 より抜粋

3. Computerized System Validation
3.1 Computerized System Validationとは

ガイダンスのイントロダクションには、「Persons using the data from computerized systems should have confidence that the data are no less reliable than data in paper form.」とある。注目すべきことは、”Computer System”ではなく、”Computerized System”と記述されていることである。”Computerized System”とは、”Computer System”と業務プロセスを統合したものである。(図1参照)さらに”Computer System”はハードウェアソフトウェアから構成され、業務プロセスは、人、標準業務手順書(SOP)と、設備(例えば測定機器、CRF、筆記具など)から構成される。
つまりFDAは単にコンピュータシステムにバグや不具合のないことを要求しているのではないのである。紙ベースのオペレーションがコンピュータ化された際に、申請に関係するデータの品質および品質保証が、劣化しないという保証を求めているのである。FDAにとってみると、製薬企業がコンピュータシステムを使用しようがしまいが問題にはしていないのである。ましてや、何処の何という製品を利用しているかということは関心がないのである。業務をコンピュータ化することによって、何らかの問題が発生しないかという懸念を払拭することが重要であるといえる。つまり”Computerized System Validation”(以下、CSVと略す)を要求しているのである。
ソフトウェア自体のバリデーションは外部企業やベンダーによって実施されるものが多いが、そのソフトウェアの業務への適合性についての最終的な責任は製薬企業にある。またそのバリデーションの適合性を評価できる記録は、製薬企業で保管する義務がある。FDAは、システムの開発期間中と、リタイアまでの稼動期間中の両方についてそのライフサイクルを管理することを求めている。


図 1Computerized System Validation

3.2 CSVの対象範囲

前項に解説したことからわかるように、CSVは自社開発、外部委託開発、外部購入ソフトウェアのいずれを問わず対象となる。ただしその主旨から扱うデータが安全性、有効性、品質に何ら関係しないシステム(例えば施設との契約管理システム、モニターの旅費精算システム等)である場合は、CSVから除外してもよいと考えられる。適用するべきシステムは、あらかじめCSVプランに記述しておくべきである。またコンピュータ・メーカ開発のOSやDatabase等のシステム系ソフトウェア自体は対象外として扱ってよい。

4. CSVのライフサイクル
4.1 ソフトウェア開発とCSVのライフサイクル

多くの製薬企業の情報システム部門には、いわゆる「開発標準」という規約文書が存在している。多くの場合この中には、ソフトウェア開発のライフサイクルが記述されている。しかしながら、CSVの観点で全ライフサイクルが網羅的に記載されているかどうかは疑問が残る。

4.2 CSVのライフサイクルにおけるドキュメンテーション

一般的に、CSVのライフサイクルおよびそれらの段階におけるドキュメンテーションは、下記のようなものが考えられる。

4.2.1 プランニング (Validation Plan)
このステップでは、バリデーション計画書を作成する。バリデーションに携わる組織、人員構成、期間、必要な文書類等の定義をはじめ、当該システム導入プロジェクト全体の品質保証計画(Quality Plan)を明らかにする。またプロジェクトの各段階で発生する変更要求に対する処理基準および手順を記載したChange Management Planも作成が必要である。

4.2.2 リクワイアメント (Requirements Documentation)
User Requirements SpecificationURS)を作成する。URSには、ユーザの要求事項を記載し、実際の業務で必要とする機能や、データ、操作環境を定義づける。このなかには、Functional Risk Assessmentと呼ばれる、要求される各機能が正常に動作しない場合や、導入が実現できない場合の業務に対するインパクトの程度やリスクの記述を含める場合がある。

4.2.3 ベンダー選定 (Vendor Audit Report)
URSにもとづき、Request for ProposalRFP)を作成する。RFPは、ソフトウェアベンダーへの要求仕様書である。またベンダーからの提案を受け、そのベンダーを査察(Vendor Audit)する場合がある。Vendor Auditの目的は、そのベンダーが要求に合致した品質ソフトウェアの開発を行うことができるのかどうかを、調査することである。この際に事前にVendor Audit Check Listを作成する必要がある。また実施後のVendor Audit Reportおよびベンダー選定の報告書が作成される。

4.2.4 設計 (Design Specifications and Reviews/DQ)
ハードウェアソフトウェア、必要に応じてネットワークのハイレベルな仕様を記載したDesign Specificationを作成する。またURSシステム上で実現するソフトウェアの機能仕様を記述したSystem Specification(またはFunctional Specificationという場合もある)と、ハードウェアおよびネットワークの仕様を記述したTechnical Specificationも作成される。
システムのインストール計画書、インストール手順書(クライアントおよびサーバー)、バックアップ/リカバリー手順書もこの段階までに準備しておく必要がある。
URSに対して、設計の妥当性を評価・検証することをDesign Qualification(DQ)と呼ぶ。またDQの報告書も作成されなければならない。

4.2.5 構築、システムテスト (Build, Code Reviews, System Testing)
コーディング(プログラミング)を実施する場合は、詳細設計書、プログラム設計書等が作成されるのが一般的である。
パッケージ導入の場合は、カスタマイズまたはコンフィギュレーションを行う。コンフィギュレーションとは、パッケージをカスタマイズするのではなく、パラメータ等によって、そのアプリケーションの設定を変更できる機能である。コンフィギュレーションによって設定の変更が可能なソフトウェアを、コンフィギュアラブル・アプリケーション(Configurable Application)と呼ぶ。
さらにテスト仕様書が作成された後、テストを実施し、テスト結果報告書等が作成される。

4.2.6 導入 (Installation and Configuration Documentation)

作成された手順書をもとに、ハードウェアの設置、OSデータベース等のインストレーション、ソフトウェアの導入を行い、その結果をインストレーション結果報告書として作成する。

4.2.7 クオリファイ (IQ/OQ/PQ)

この段階を説明するには、GAMPのガイドラインによる「V-Model」(図2参照)が有効である。Technical Specificationに対し、準備されたプラットフォームが正確に稼動し、その要求を満たすことを検証するテストInstallation QualificationIQ)と呼ぶ。
またSystem Specificationに対して、要求された機能が実現されていることを検証するテストOperation QualificationOQ)と呼ぶ。
さらにユーザの要求仕様であるURSに対して、要求された要件が実現され、稼動できることを検証するテストPerformance QualificationPQ)と呼ぶ。しばしばこのPQは、その名前から、コンピュータシステムやネットワークのパフォーマンス試験のことと誤解されることがあるが、そうではない。ユーザの業務プロセスが、コンピュータ化により要求に応じて滞ることなく実現できるかを検証するのがPQの目的である。従って、PQユーザが実施することになる。
これらIQOQPQに対する計画書(Scripts、テストデータを含む)および実施結果報告書がそれぞれ作成される。
また前の導入段階およびこのクオリファイの段階で発生した不具合は別途Incident Logとして記録され、Change Management Planに従って、変更管理が実施される。さらに変更はChange Logとして記録される。


図 2 QA / Validation Protocol and Reports

4.2.8 デプロイメント (Deployment)
あらかじめDeployment Planを作成し、それに従ってユーザへの展開を図る。またシステム導入後の新しい業務プロセスを記述したSOPは前もって準備されなければならない。データを入力または加工するユーザは、システムを正確に使用するための教育、訓練を受けなければならない。教育は資格のある人が、必要に応じて継続的に実施する。大切なことは、単にシステムの操作手順ではなく、新SOPに沿った教育が実施されなければならない。また特にシステムが変更された場合には、変更後のシステムに十分慣れる事が重要である。教育に関する文書として、Training Plan、カリキュラム、ユーザの教育記録等がある。
またこの段階で作成される文書として、システムをサービス(運用サポート、メンテナンス、バックアップ等)する側とサービスを受ける(つまり利用する)側(ユーザ)がその利用形態(サポート体制、稼働時間、ヘルプデスク、ユーザの責任等)について合意したService Level Agreement(SLA)がある。
さらにシステムの不慮の事故に備えて、Disaster Recovery Planを検討する必要がある。

4.2.9 廃止 (Decommission)
医薬品の開発期間に比べ、コンピュータシステムH/WおよびS/W)の寿命はあまりにも短い。一連の薬剤開発期間中にコンピュータ製品が製造中止になったり、互換性のとれない新しいシステムにバージョンアップされることも考慮すべきである。
現行のシステムをリタイアさせ、新システムに移行するためには、正確なデータの移行(Data Migration)を実施する必要がある。その際に、旧システムに蓄えられた監査証跡(操作・変更履歴)を含めて移行が行われなければならない。
データの移行に使用するプログラムは、同様にバリデーションされていなければならない。また移行作業の手順書を作成し、実施を記録したデータ移行結果報告書が作成されなければならない。

4.3 変更管理

上記のライフサイクルの中で、変更管理は非常に重要である。変更に際して、各段階にあげた多くの文書間の整合性を完全に保つことはそうたやすくはない。ガイダンスでは、ユーザによる要求事項の変更など、色々な場面におけるシステムの変更の管理を十分に行うことを要求している。そこで、文書間の整合性をトレースするためのテーブルを常に作成し、メンテナンスすることが要求される。この文書のことをTraceability Matrixと呼ぶ。これはシステムの開発または導入中に作成される各種のドキュメントに関して、1つの変更要求がどのように関係し、管理、維持されるか、またどのように変更がテストされ結果が管理されるかをまとめた文書である。たとえば、ユーザの要求仕様(URS)の何章の何番が、Functional Specificationの何章の何番に対応し記載され、テスト仕様書の何章の何番に対応し、テスト結果報告書の何章の何番に記載されているかを明らかにするのである。
多くの場合、ソフトウェア開発は成り行きに任せ、後半の文書ほど現実を現しているが、前の段階の文書がそれに呼応して変更されることは少ないようである。製薬企業各社は、現在使用しているシステム(いわゆるLegacy System)について、このTraceability Matrixを作成することが望まれる。


図 3 Traceability Matrix

4.4 CSVにおけるQA部門の役割

CSVにより作成される各文書は、各段階の適切な時点でQA担当者によるレビュが実施されることが必要である。日本におけるQAの実態は、AssuranceというよりもAuditに重点が置かれているように思われる。またCVQAComputer Validation Quality Assurance)の担当者の育成も遅れている。
各ドキュメントがタイムリーにレビュされ、その品質が保証されないまま、CSVのステップを移行することはリスクを伴う。なぜならば、たとえばCSVの最終局面において不備の指摘があった場合には、それまでの労力と時間を無駄にし、再度同様なプロセスを実行しなければならなくなるからである。
CSVに関する手順書およびドキュメントの定義は、あらかじめ用意されているべきであり、QAによるレビュも完了していなければならない。またドキュメンテーションを効率よく、品質を高める方策として、定義された各ドキュメントのテンプレートの作成も必要と思われる。

5. FDAの要求事項
5.1 FDAが要求するデータ品質に関わるメトリックス
5.2 Part 11以降のCSVの拡大

ガイドラインの特徴として、ソフトウェアの設計要素(機能要件)にも言及していることがあげられる。つまりCSVの対応範囲が拡大されたものと理解できる。特に最近の査察時の指摘事項として多くあげられるものに、下記の2点がある。

  1. セキュリティ
    多くのコンピュータシステムには、データを保護するための、基本的なセキュリティ機能が含まれている。しかし、多くの場合において、セキュリティ機能は従来からバリデーションの対象とされていなかった。
  2. オーディット・トレール
    セキュリティで守られているシステムでも、データの改竄が行われてしまう可能性がないとはいえない。そこでガイダンスでは、オーディット・トレール監査証跡)の機能を持たせることを要求している。オーディット・トレールの機能を持たないシステムは使用することができないことになる。
5.3 Part 11における問題点

Part11の要求事項は、企業内情報インフラ、市販ソフトやInternetにまで及ぶ。しかしながら、遵守要件が具体化して いないため、対応方針、新システムへの移行に不安が感じられる。eCTDをはじめ、電子申請への対応のためには、電子記録を利用しなければならない。Part 11のタスクフォース・リーダであるPaul.J.Motiseは、「プリントアウトを本質的に 信頼することはできない。なぜならプリントアウトにはデータの再構築または生データから再現するために必要なメタデータ情報を含んでいないからである。」と述べている。このことは、5.1で述べたデータの品質の観点から、もはや紙の記録は採用できないことを意味しているように思われる。また電子で記録を作成し、紙の上で承認する(つまり電子承認 は利用しない)システムをHybrid Systemと呼ぶが、これも同様に問題点を抱えている。技術的に電子記録と紙上のサ インをどうやってリンクさせるのか、また承認後の変更をどう管理するのかといった重大な対応が困難な課題がある。 このことは電子承認はいずれ導入せざるを得ないことを意味していると思われる。

5.4 FDAによる査察

コンピュータシステムハードウェアソフトウェア、物理環境の関係を全般的に記載した、システム文書を臨床試験を実施している場所で即時参照可能な状態にしておかなければならない。FDAは、ソフトウェアバリデーション結果を示す文書を調査することがある。製薬企業は、要求されればソフトウェアを使用する場所での査察時にこの種の文書を提示する責任がある。
ガイダンスによると、個々のシステムにおいて、下記のような6つの基本的なシステムSOPを準備し、使用する場所に設置しておかなければならないとしている。(図5参照)ただしその種類はこれらに限定されることはない。

  1. システムのセットアップとインストール
  2. データの収集と取り扱い
  3. システムメンテナンス
  4. データのバックアップ、リカバリー(Backup / Recovery)と事故対策(Disaster recovery)
  5. セキュリティ(Security)
  6. 変更管理Change control


図 6 First-Time FDA GCP Inspection

6. おわりに

紙面の都合から臨床開発に関するコンピュータバリデーションの概要を解説するにとどまった。実際にバリデーションを行うには、多くの人(IT/IS部門のみならず、ユーザ部門、QA部門、教育部門)の理解と協力が不可欠である。そのためには手順書の整備が急がれ、またガイドを行うためのテンプレート、サンプルの準備が必要となる。
ともするとバリデーションは、社内のQA(外資系企業の場合本社のAudit)、当局の査察に合格することが目的とされがちである。しかしながら、その本質はユーザが安心してコンピュータシステムを利用することにある。またシステム導入に当たっての対投資効果を向上させ、作業の効率化、生産性の向上を図ることが目的である。
臨床開発におけるバリデーションに関する文献やセミナーは、そう多くない。まだ製薬企業における関心も高くないように思われる。さらにより詳細な解説を行える機会を望んでいる次第である。