Computerized System Validation(CSV)について研究するページ


ウェブセミナー

Computerized System Validationについて研究するページです。

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

Computerized System Validation講座

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

最近になって、多くのコンピュータバリデーションに関する書籍が発刊されるよう になった。しかしながら、ほとんどの書物は概念的であり、具体性にかけるものとなっているようである。
製薬各社にとっては、実践的でかつ実用に供する具体例のあるバリデーションドキュメントの作成方法が望まれているであろう。ともすると、目的を間違ってしまい、また何のために行っているのかわからないままドキュメントを作成しているケース が多く見受けられる。これでは、作成する人も何をどのようにどこまで行って良いのかが全く分からなくなってしまう。このような作業は苦痛の極みである。 一方、厳重にバリデーションを行おうとするあまり、いわゆる青天井的にとめどなく作業とドキュメンテーションを行っている企業もある。これでは本末転倒であり、バリデーション作業が十分に納得(安心)できないために、システムの稼動が遅れ遅れになってしまうケースが見受けられる。そういった事態を改善し、効率的で最 大の効果を出すためにも、まずはSOPを整備しなければならない。SOPはPractical(実践的)でなければならない。せっかく作成したSOPも、社員にとって難解であっ たり、実践向きでなかったりしたら、結局は見向きされなくなってしまうことになる。
そんな状況を鑑み、本書を発刊することとした。
本書は、コンピュータバリデーションの本質と目的をつぶさに記述し、実践のため の方法論を解説したものである。最初にお断りしておかなければならないことは、 本書で記述したCSVの方法論(メソドロジー)は、その多くが筆者の経験に基づいたものであり、これだけが唯一正しいというものではない。製薬各社においては、全く別のやり方、方法論を用いていることと思う。そんな場合においても、ぜひ本書を参考にしていただければ幸いである。

まずはCSVに関する5つの質問に答えていただきたい。

コンピュータシステム使用によるユーザのメリットは言うまでもない。

  1. 操作手順さえ覚えれば誰にでも使用できる
  2. データを簡単に修正できる
  3. 作業手順の変更が容易である
  4. 大量のデータを迅速に処理し、かつ容易に保存できる

これに対して、利点が逆に問題になる。

  1. 作成されたプログラムの内容は、容易には確認できない
  2. 紙の記録、手書きの署名と比べて、「電子記録」「電子署名」は、改ざん(証拠を残さない変更)が容易かつ改ざんの発見が困難になる。

例えば紙の記録を変更する際は、通常オリジナルのデータが読めるように二重線で打ち消し、新しいデータを書き添え、また同時に署名も行う。
一方ネットワークに接続されたコンピュータ上の電子データは、誰にも気づかれないうちに、遠隔地から証拠を残さず変更をすることが可能な場合がある。FDAセキュリティ(アクセスコントロール)に関して繰り返し要求事項を記述している所以である。作成時に意図しなかった作業を追加した場合、不測の問題が生じることがあるシステムが複雑になるほど管理、保守の面も含めてコンピュータの信頼性、安全性に多くの問題を含むことになる。
ソフトウェアValidationは外部企業やベンダーによって実施されるものが多いが、そのソフトウェアの業務への適合性についての最終的な責任は医薬品メーカにある。
Validationの適合性を評価できる記録は、医薬品メーカで保管する義務がある。規制当局は、システムの開発期間中と、リタイアまでの稼動期間中の両方についてそのライフサイクルを管理することを求めている。

1. そもそも何故CSVが必要か

コンピュータシステムの本来の複雑性により、網羅的なテストだけではシステムが正しく稼動しているとか、エラーを起こしていないとかの確証はもてない。 そこで、コンピュータシステム開発の全ライフサイクルに渡って欠陥を最小限に抑えるような健全な工学的で高品質プロジェクト管理のプラクティスを行うことが重要である。
現在CSVを担当している人々や、これからCSVを実施しようとする人たちにとって、一番大切なことは、なぜCSVが重要であり、必要なのかを理解することである。 CSVの重要性について、規制当局の視点、経営者の視点、システムのユーザの視点から解説をしてみたい。

1.1 規制当局の懸念とは

規制当局(主にFDA)の懸念は「Principle: Data quality and quality assurance should not decrease when a computerized system replaces a paper operation.」(原則:データの品質および品質保証 は、紙ベースのオペレーションがコンピュータ化された際に劣化してはならない)ということである。 規制当局にしてみれば、製薬会社がコンピュータシステムを利用しようがしまいが、そんなことはお構いなしである。ましてや、どこの何とい うソフトウェアを利用しているかなんかは、ほとんど関心が無いのである。よく「うちの会社は、どこもが使っている○○というソフトウェアを利用しているから、大丈夫だ。」といったような意見を聞く。FDAにとっては「So what ?」である。

FDAの関心ごとは、上記の原則にあるように、当局へ提出されるデータの 品質品質保証が、紙ベースのオペレーションがコンピュータ化された 際に劣化していないかどうかということである。いいかえれば「システムの業務への適合性の保証」を求めているのである。つまり、このことがFDAなどの規制当局のCSVへの期待である。 この「システムの業務への適合性の保証」というフレーズは、本書において後ほど何度か出てくるので、ぜひ念頭においていただきたい。

1.2 経営者の関心とは

コンピュータシステムの導入は、当然のことながら投資である。
企業の経営者にとって、いわゆるROI(Return on Investment)が関心事となる。つまり「投資に見合った業務品質とデータ品質が得られるのか」ということである。
GXPシステムのROIとしては、下記の2通りが上げられる。

  1. 効率性、経済性、信頼性があがること。
  2. 人的なミスが削減され、やり直し作業が軽減されること。

また、紙での記録同様「重要なデータが保護されているか」という ことには特に気を払わなければならない。さらに、コンピュータにお ける最大のリスクとして「何らかの災害の際に、復旧が可能である か」ということである。
当然のことながら「社内の監査や、当局の査察に合格することができるのか」ということも一般に高い関心ごとである。

1.3 ユーザの視点とは

コンピュータシステムを利用するユーザにとって「安心して業務が 遂行できるか」ということが最大の関心ごとであると思われる。 せっかく作成した申請資料が消えてしまっては困るし、研究会などの前日にシステムが停止されては大変である。

1.4 CSVの必要性

上述したように、規制当局の視点、経営者の視点、システムのユーザの視点それぞれにおいて、コンピュータシステムへの各種の懸念を払拭することが大切である。
このようなことから、CSVが必要になってくるのである。 ともすると、当局の査察に備えるためにCSVを実施しようとする企業があるが、これでは本末転倒である。 CSVの必要性は、業務をコンピュータ化することによって何らかの問題 が発生しないかという懸念を払拭することにある。例えば、

  1. 電子データは信頼できるものであるか
  2. コンピュータ化された業務がきちんと管理できているか

ということも関心事としてあげられる。

2. CSVの実施対象
2.1 CSVの実施対象期間

コンピュータシステムを導入するということは、ペットを飼う(買う)ことと似ている。
例えば、「犬を飼おう」と考えたとする。まずは、「どんな犬にしようか?」と検討することになる。とりあえず数件のペットショップを見て回ることにするが、「どのペットショップにしようかな?」と悩むことになる。ペットショップを選ぶ方法として、他のペット愛好家に相談してみることも有効である。思案の末、飼育状態も良さそうだし、詳しい店員もいる、またアフターケアも充実しているといった、より信頼できるペットショップを選択することになる。
後日犬を飼ってみて、「意外と手間とお金がかかる」事に気がつく。
つまり、家の中でカーッペットを汚されたら困るので、躾をしないといけない。つまり「行儀良く」してもらわなければならないのである。

また病気になったら、獣医に診てもらわなければならない。万が一のために近所の獣医を探しておき、診察時間を記憶しておくことも重要である。
しかしながら、動物はいずれ死んでしまう。丁重に埋葬することも忘れてはならない。
さて、ペットを飼うということと、CSVがよく似ていることがお分かりいただけるだろうか。
まず「犬を飼おう」という要求は、「ユーザ要求」に相当する。 「どんな犬にしようか?」は、「パッケージ調査」。 「ペットショップを見て回る」は、「ベンダーオーディット」。 「他のペット愛好家に相談」は、「リファレンスコール」つまり同業他社を訪問して当該ベンダー(またはパッケージ)の評価を得る。
「躾」は、トレーニング。トレーニングの対象はユーザのみならず、サポートするIT部門も対象となる。
「獣医に診てもらう」は、定期メンテナンス(バックアップなど)や障害時のベンダーサービスに相当する。
「死んでしまう」は、「廃棄」に相当する。廃棄は慎重に行わなければならない。つまり大切なGXPデータを保持しているからである。当局による査察が予想される場合は、特別な配慮が大切である。通常、システムの導入は、廃棄の検討から開始することになる。

以上のようにペットを買う(飼う)ということは、そのLifetimeに責任を持つということでもある。コンピュータシステムを導入する際も、導入計画から要求検討、設計、構築、導入、テスト、また利用期間中の継続した変更管理や再テスト、メンテナンス、バックアップとシステム監査等が必要なのである。
つまりCSVはシステムのサービスインまでのみを対象とするのではなく、システムの稼動中および廃棄までを対象とするのである。

2.2 規制要件が適用されるGxPデータとアプリケーション

CSVを計画するに当たって、まずは規制要件が適用されバリデーションが要求される、データおよびシステムを特定する必要がある。

  1. GXP Data: 規制当局に対して安全性(Safety)有効性(Efficacy)品質(Quality)を証明するために使用される全てのデータ
  2. GXP Application System: 上記GXP Dataを扱い、またはGXP規制要件に従った業務をコントロールする全てのソフトウェアアプリケーション
2.3 CSVの対象範囲

CSVは自社開発、外部委託開発、外部購入ソフトウェアのいずれを問わず対象となる。ソフトウェアCSVの焦点が当たる理由は、一般的にソフトウェアは変更が容易と考えられ、また不具合がおきやすいためである。ただしその主旨から扱うデータが安全性、有効性、品質に何ら関係しないシステム(例えば旅費精算システム等)である場合は、CSVから除外してもよいと考えられる。またコンピュータ・メーカ開発のOSDatabase等のシステム系ソフトウェア自体は対象外として扱ってよい。

3.SDLC(Software Development Life Cycle)概要
3.1 SDLC(Software Development Life Cycle)とは

FDAは、ソフトウェア・アプリケーションの開発とバリデーションに対してライフサイクル・アプローチを実施することを求めている。 このライフサイクルは、一般にSDLC(Software Development Life Cycle)と呼ばれるMethodology(方法論)である。SDLCの"S"はSoftwareをあてるのが一般的であり、Systemではない。何故ならば、開発を行うのはSystemではなくSoftwareだからである。 ライフサイクルの例として、計画(Planning)→要求(Requirement)→設計(Design)→製造(Build)→テスト(Test)→移行(Deployment)→利用(Use)→廃棄(Retire)といったフェーズがあげられる。
SDLCは通常Water Fall Modelと呼ばれ、水が滝を流れるように後戻りは原則として出来ない。

多くの製薬企業の情報システム部門には、いわゆる「開発標準」という規約文書が存在している。多くの場合開発標準は、ソフトウェア開発のライフサイクルに基づいて記述されている。しかしながらCSVの観点で全ライフサイクルが網羅的に記載されているかどうかは疑問が残る。FDAでは、査察官自体がこのSDLCのメソドロジーに基づいて教育を受けている。今後の査察においては、このSDLCに則ったドキュメントの整備と整合性がチェックされるものと思われる。

SDLCにおける活動は、手順書定め実施しなければならない。CSV活動の証拠として、またどのような選択や決定をしたかを伝えるために、SDLC活動の適切な記録を、各フェーズについて保持しなければならない。
原則として記録は、技術面、管理面、そして品質面からのレビュ承認を受けなければならない。これらの記録をどの程度詳細にするかは、当該システムの複雑さや、どの程度の正確な機能の確証が必要かによって違ってくる。作成された文書は、SOPsで定義する役割の者がレビュ承認を行わなければならない。レビュおよび承認は、署名の形式をとるのが普通である。

一般的に、SDLCおよび各フェーズにおけるドキュメンテーションは、下記のようなものが考えられる。

3.2 プランニング (Planning)

本フェーズでは、下記の事項を行う。

  1. 業務プロセスとシステム化に対する要求事項の文書化
  2. バリデーションの必要性の評価
  3. バリデーション計画の策定
  4. ベンダーオーディットおよびパッケージ調査

3.2.1 URSVMPの作成順序
企業によっては、VMPを作成した後URSを作成する場合がある。URSも重要なバリデーションドキュメントであるからVMPによって計画されないといけないからである。しかしながら筆者は本章で解説したとおり、URSがSDLCにおける最初のドキュメントと位置づけている。URSによってバリデーションの必要性や程度が決定されるからである。GAMPガイドラインでもURSVMPの作成順序は特に指定していないようである。

3.3 リクワイアメント フェーズ(Requirements Phase)

本フェーズでは、URSにて概説した要求事項を、コンピュータシステムのための詳細要件へと更に洗練する。
本フェーズでは、下記の項目を行う。

  1. 詳細要求の策定
3.4 設計 フェーズ(Design Phase)

本フェーズでは、システムに対する要求を「Design Specification」(設計仕様書DS)に詳細化する。設計にはソフトウェアハードウェア、必要に応じてネットワークを含む。またインフラの変更に関しても完全な文書化をおこなうこと。
URSに対して、設計の妥当性を評価・検証することをDesign Qualification (DQ) と呼ぶ。すなわち設計は適切にレビュし、その結果を「DQ Report」(DQ報告書)に文書化すること。

本フェーズでは、下記の項目を行う。

  1. コンピュータシステムに対する要求の詳細化
  2. 設計の確からしさの検証
3.5 構築フェーズ

構築フェーズでは、主にベンダー側でコーディングとソースコードレビュを実施する。その際、詳細設計書、プログラム設計書等を作成するのが一般的である。また既成パッケージを導入する場合、パッケージのカスタマイズを行う。現行のシステムを廃棄し、新システムに移行する為には、正確なデータの移行(Data Migration)を実施する必要がある。その際に、旧システムに蓄えられた監査証跡(操作・変更履歴)を含めて移行が行われなければならない。その際、データの移行に使用するプログラムは、同様にバリデーションしなければならない。また、移行作業のテストスクリプト(手順書)を作成し、実施を記録したデータ移行テストログおよびデータ移行結果報告書を作成しなければならない。上記の作業は、ほとんどをベンダーに委託するのが一般的である。その間、テストフェーズにおけるテスト実施のためのテスト計画書、移行フェーズにおける新規システムへの移行計画書、利用フェーズにおけるサービス実施計画書等を準備しておくこと。

本フェーズでは、下記の項目を行う。

  1. ベンダーによるコーディングとソースコードのレビュ
  2. テストのための計画策定
  3. 正確なデータの移行のための計画策定
  4. 本稼動のための移行計画策定
3.6 テストフェーズTest Phase

全てのテストは重要である。不十分なテストはBugを発生させることになり、メンテナンスコストが高くなり、データの悪化を解決するのが難しくなる。不十分な受入れテストユーザの混乱や不満を発生させることになる。
一般的にテストが不十分な場合、仕様が十分であることの確認が出来ないため、仕様の変更を発生させることになる。多くのシステム要求・仕様は特定の設定によってのみ効果的にテストできるものである。
(単体テストで行われるもの、システムレベルで行われるもの)

テストフェーズにおける活動は、一般にIQ、OQ、PQとして知られている。またGAMPのガイドラインによる「V-Model」が有名である。設計仕様書Design Specification=DS)に対し、設計されたとおり設置し、設置されたプラットフォームが正確に稼動し、その要求を満たすことを検証するテストInstallation QualificationIQ)と呼ぶ。つまりIQDSに対して実施される。

また機能仕様書(Functional Specification=FS)に対して、要求された機能が実現されていることを検証するテストをOperation Qualification(OQ)と呼ぶ。つまりOQはFSに対して実施される。
さらにユーザ要求仕様書User Requirements Specification=URS)に対して、要求された要件が実現され、稼動できることを検証するテストをPerformance Qualification(PQ)と呼ぶ。つまりPQはURSに対して実施される。しばしばこのPQは、その名前から、コンピュータシステムやネットワークのパフォーマンス試験のことと誤解されることがあるが、そうではない。ユーザの業務プロセスが、コンピュータ化により要求に応じて滞ることなく実現できるかを検証するのがPQの目的である。従って、PQはユーザが実施することになる。

これらIQ、OQ、PQに対する計画書、実施のためのスクリプト、実施の記録であるログ、および実施結果報告書をそれぞれ作成しなければならない。またテストで発生した不具合は別途障害記録(Incident Log)として記録し、変更管理計画書Change Control Plan)に従って、変更管理を実施することとなる。

本フェーズでは、下記の項目を行う。

  1. コンピュータシステムの導入
  2. 包括的なテストの特定と全ての正式なテストの実施
  3. テスト結果の記録とレビュ
  4. 運用環境の安定性の保証
  5. コンプライアンスリスクの重要なプロセスの評価
3.7 移行フェーズDeployment Phase

移行フェーズは、テストフェーズと並行して実施すること。

移行フェーズでは、下記の事項を行う。

  1. サービス部門(ベンダーを含む)とユーザとのサービス合意
  2. データ移行に関する要約
  3. 実稼動後における災害対策の策定
  4. 十分にテストしたコンピュータシステムにおける、本稼働への準備
  5. システムアクセス計画の策定
  6. バリデーション活動に関する総括と利用開始宣言
  7. 利用フェーズにおけるバリデーション維持活動の計画策定
3.7.1 サービス部門とユーザとのサービス合意(サービスレベル合意書

サービスレベル合意書(Service Level Agreement=SLA)は、サービス (運用サポート、メンテナンス、バックアップ等)する側とサービス を受ける側(ユーザ)が、その利用形態(サポート体制、稼働時間、 ヘルプデスク、ユーザの責任等)について合意した文書である。

サービスレベル合意書の目的は、下記の通りである。

  1. ユーザサポート組織との間において合意された基準の相互理解を 文書化すること
  2. サービス施行の評価基準を定義すること
  3. サービス管理方法を記述すること

サービスレベル合意書は、ユーザ要求仕様書等に記載されたユーザサービスに対する要求事項をもとに作成すること。また、現行のサービスレベル合意書(存在する場合)を考慮に入れること。

3.7.2 データ移行に関する報告の要約(データ移行報告書

データ移行報告書承認されたデータ移行計画書に従って作成し、その目的は、データ移行の実行と検証の記録を文書化することである。データ移行報告書移行フェーズ中に作成すること。データ移行報告書には、データ移行の作業の要約と、その結果を記載 すること。また必要に応じて、それから先に進むための要件を記載す ること。
作業はシステムサポートサービス組織へ移行するために必要である。データ移行報告書を対象システムに対して作成することで、データの 最終的な受け入れとする。

データ移行の前後には下記の項目を実施する。

  1. データ移行仕様書は、データ移行プロセスを計画するためのデータタイプとデータの具体的関係の特定及びデータ移行に利用するツールとプロセスを定義する
  2. データ移行テスト計画書は、データ移行が成功したこと検証する ために、計画したさまざまな段階でどのようにテストや検証を実施す るかを定義する
  3. データ移行テスト報告書は、データ移行テスト計画に対して作成 する
3.7.3 実稼動後における災害対策の策定(災害対策計画書

災害対策計画の目的は、会社に莫大な損害やリスクを強いるような万が一の状況に対して備えを確実にすることである。これが業務上重大な影響を及ぼすこともあり得る。災害対策計画書バリデーション計画書に基づいて作成し、機能仕様書の承認時又はそれ以前に着手し、移行フェーズの期間内に完成させ る。システムの運用が、社内ではなくベンダーに委託されている場合には、 本要件は「サービスレベル合意書」で記述される外部サービス要求事項 の一部として検討する。災害対策計画書は、重要な業務プロセスを支援する情報システムのコンポーネントの修復や復元作業を管理するために使われる。したがって、本計画には予想できる事象(例、電力低下、サーバの移設など)や予想外の事故(例、自然災害、コンピュータウィルス、停電など) によって影響を受けるデータの修復対策も含まれる。

3.7.4 本稼働への準備(システム利用手順書、ユーザサポート資料)

システム利用手順書及びユーザサポート資料は、設計フェーズにおい て作成しなければならないが、必要に応じて移行フェーズの間に作成 しても構わない。そして、運用フェーズに入るまでに承認すること。
システム利用手順書ではビジネスプロセスのステップを定義し、それらがどのように行われるべきかを説明する。また、ビジネスプロセス をサポートするためにシステムを使用する場合について説明する。
システムの操作に関する説明や画面説明などの詳細情報はユーザサポ ート資料に記載し、システム利用手順書には記載しない。

システム利用手順書を作成する際は、必要に応じて下記の者から意見 を聴取してもよい。

  1. 業務を実行しているユーザ
  2. 業務を監査するQA
  3. 業務をサポートしている組織又はグループ

ユーザサポート資料は、業務をサポートするシステムの操作方法につ いて段階的な手順を示すものである。
ユーザサポート資料の主な利用者は、システムを操作するユーザであ る。
ユーザサポート資料には、必要に応じてユーザマニュアル、クイック リファレンス、コンピュータトレーニング、オンラインヘルプ、教育 資料、技術マニュアル、システムの画面ハードコピーを含めること。
トレーニング資料としての使用を意図したユーザサポート資料はトレ ーニング計画書にて説明している方法に従って作成する。

3.7.5 システムアクセス計画の策定(システムアクセス計画書

システムアクセス計画書の目的は、システムのアクセス管理のプロセス(アクセスの開始、アクセス権の承認、許可、改訂、破棄、及び記録と調査)を文書化することである。
システムアクセス計画書は、設計、移行フェーズ中に作成し、PQを実 施する前に承認すること。
システムアクセス計画書は、承認済みのバリデーション計画書、設計 仕様書及び移行計画書をもとに作成すること。

3.7.6 バリデーション活動に関する総括と利用開始宣言(バリデーション報告書システムリリース通知書)

バリデーション報告書の目的は、実行されたバリデーション活動を要 約し、バリデーション計画書からの逸脱を記述することである。バリデーション計画書によって要求されているようにプロジェクトのフェーズとその活動が管理されており、再現可能であること(トレーサビリティの保証)を示すこと。また、コンピュータシステムの受諾や、 運用フェーズへ進めることができる根拠を示すこと。バリデーション報告書には、作成した成果物と日付、非作成ドキュメ ントとそれを正当化できる理由を記載すること。バリデーション報告書バリデーション計画書をもとに作成し、移行フェーズ中に執筆を完了すること。システムリリース通知書は、コンピュータシステムが実際の使用に移行することを承諾する際に作成し、バリデーション報告書の執筆が完了した後に作成すること。システムリリース通知書の目的は、システムの利用開始を正式に承認 することである。

3.7.7 利用フェーズにおけるバリデーション維持活動の計画策定(サポート品質計画書)

サポート品質計画書の目的は、システムやサービスサポートプロセスと、品質と必要な場合はバリデーションを利用フェーズ中にどのように管理、維持するかを文書化することである。サポート品質計画書は、開発の初期段階で作成し始めることが望ましいが、新しいプロジェクトでは、設計、導入フェーズ中に完成、あるいは更新を行う。サポート品質計画書は、バリデーション報告書承認する前に承認すること。また、システムリリース通知書承認し、システムが利用フ ェーズに入ったときから有効となり、その時点でバリデーション計画書を引き継ぐものである。サポート品質計画書は、すべての新しいシステムやサービスのために 作成し、システムサポートマネージャがその責任を持つ。品質バリデーション管理活動は、ビジネス、組織、技術、規制リスクと要件を特に考慮したシステムやサービスに適切であること。
サポートを担当する従業員は、品質への取り組みを理解し、文中で特定されたサポートプロセスを遵守するためにサポート品質計画書を読 むこと。

3.10 共通フェーズ(Cross Phase)

共通フェーズはSDLCの全フェーズを通して実施するか、または複数のフェーズに共通のプロセスを定義する。

共通フェーズでは、下記の事項を行う。

  1. 変更管理
  2. 障害管理
  3. ドキュメント管理
  4. トレーニング管理
  5. トレーサビリティマトリックスの作成
3.10.1 変更管理変更管理計画書変更要求書、変更一覧)

プロジェクトの各フェーズで、発生する変更要求に対する処理基準及び手順を記載した変更管理計画を作成する必要がある。変更管理計画は、バリデーションマスター計画書に含めても良いし、別途複数システムを対象としたドキュメントとして作成しても良い。変更管理計画書では、ビジネス利益の変更のみを承認、スケジュール、及び移行することを保証するための変更管理実施作業及びそのプロセスを管理する役割と責任を記述すること。

3.10.2 障害管理(障害管理計画書、障害報告書、障害管理記録)

SDLCの各フェーズ中で発生した不具合は、別途障害記録(Incident Log)として記録され、変更管理計画に従って、変更管理が実施される。さらに変更は変更記録(Change Log)として記録すること。障害管理計画書の目的は、システムのライフサイクル全体の障害を管理するための要求事項を記述することである。また、コンピュータシステムに関連して発生した障害を記録し、解決するために従うべきプロセスを記載する。障害管理計画書は、システムのライフサイクルのあらゆるフェーズで更新することができる。障害管理計画書内には、障害記録及び障害ログの要求事項を明記しなければならない。障害記録の目的は、障害についての詳細だけでなく、障害に関連した分析、解決策、及び終了活動の説明も明記することである。障害報告書の目的は、障害記録を集積することである。障害報告書には、記載した障害記録を要約するインデックスを含めても良い。

3.10.3 ドキュメント管理(ドキュメント管理計画書ドキュメントインデックス

ドキュメント管理計画書の目的は、システムまたはサービスに関するドキュメントをどのように作成、管理、保管するべきかを定義することである。ドキュメント管理計画書は、システム、サービス、または組織の計画及び利用中は維持し、要求事項の変更に合わせて改定すること。また、すべてのプロジェクトチームのメンバーはシステムやドキュメント管理のサービスアプローチを完全に理解し、それらの要件を遵守するためにドキュメント管理計画書を読み、理解しなければならない。

3.10.4 トレーニング管理(トレーニング計画書、トレーニング記録)

トレーニング計画書は、トレーニングの手順を記述し、すべてのユーザに対して、任命された責任を実施するのに十分な訓練が行われることを保証するものである。またトレーニング計画書は、必要に応じてそのライフサイクルの過程で修正する。また必要に応じて複数のトレーニング実施作業を実施する。トレーニング計画書とトレーニング資料は、システムやサービスが変更した場合には変更管理を通じてレビュを実施し、必要であればアップデートすること。トレーニングの計画で最も重要なことは、システムの影響を受ける個々のグループと、その役割に要求されるスキルと知識を特定するトレーニングニーズ分析である。ドキュメントインデックスの目的は、プロジェクトの進捗に伴って作成される各種ドキュメントのステータスを管理することである。

3.10.5 トレーサビリティマトリックスの作成(トレーサビリティマトリックス)

変更に際して、各フェーズにあげた多くのドキュメント間の整合性を完全に保つことはそうたやすくはない。規制当局は、ユーザによる要求事項の変更等、いろいろな場面におけるシステムの変更管理を十分に行うことを要求している。そこで、ドキュメント間の整合性をトレースするためのテーブルであるトレーサビリティマトリックスを常に作成し、メンテナンスすることが要求される。これはシステムの開発(または導入)中に作成される各種のドキュメントに関して、1つの変更要求がどのように関係し、管理、維持されるか、またどのように変更がテストされ、結果が管理されるかをまとめたドキュメントである。例えば、ユーザの要求仕様(URS)の何章の何番が、機能仕様書(FS)の何章の何番に対応し記載され、テスト仕様書の何章の何番に対応し、テスト結果報告書の何章の何番に記載されているかを明らかにするのである。多くの場合、ソフトウェア開発は成り行きに任せ、後半のドキュメントほど現実を現しているが、前の段階のドキュメントがそれに呼応して変更されることは少ないようである。

トレーサビリティマトリックスの目的は、各種ドキュメント間の整合性を取り、システムやサービスに対する要求事項または変更事項が漏れなく対処され、文書化されたことを保証することである。
トレーサビリティマトリックス作成にあたっては、計画フェーズにおけるバリデーション計画書において、作成される成果物のうち対象となるものを事前に定義しておく必要がある。



【関連記事】
リスクマネジメント
CAPA
21 CFR Part 11
FDA関連情報
CSV関連情報
Part11関連情報
ER/ES指針関連情報
EDC関連情報
ドキュメント管理システム導入の考え方

用語集


QMS構築支援

FDA査察対応