1 バリデーション（妥当性確認）あどばる経営研究所／A.V.MANAGEMENT 2 １．バリデーション概説本テキストにおいては製品の PL リスクと品質マネジメントシステム自体の有効性の本質に関わる問題を論議する。通常この話題は、第三者審査登録機関による審査においても触れられることはほとんど無い。つまり「システム監査」の名の下に行われる監査(審査を含む)では通常「手順の遵守度」に最大の力点が置かれ、「手順の有効性」、「設計の妥当性」(「設計のアウトプットの一」,「上市するはずの製品の一」といいかえても同義)については踏み込んだ監査はされないのが普通である。理由は二つあると考えられる。（１）システムの有効性に踏み込むことが監査側、被監査側によって「監査の目的」として設定されていない(意図されていない) （２）よしんば設定されていたとして、そこに踏み込むだけの力量が監査側にない「設計のバリデーション」が十分であるかどうかは、製品の「事故」及び「使用上の不具合」のうち □製造不良によるもの □使用者の無謀な使い方によるもの (禁止された使用法を敢えて実行する、指定外の使用者による取り扱い等) を除いたものがどの程度あるかを見れば一目瞭然である。医療機器の製品回収のホームページを見ると、どの程度の重篤な事故がどの程度起こっているかが分かる。このような状況を改善するためにはどうしてもこの点に言及する必要がある。昨今「システム監査」の言葉ばかりが一人歩きし、あたかも「システムが維持されていれば事足れり」とする風潮が過ぎるのではないか。製品による事故を防げてこその「設計手順」、製造による不良品の流出を妨げられてこその「製造の管理」「製品の監視・測定」ではないのか。PDCA を回せば良いとばかりに、「是正」を前提とし、「是正すれば赦される」とするのは、そもそも「品質保証」の根幹を揺るがすことになる。QMS の真髄は「全く新しい製品であるが、致命的な事故を起こすことがない」「初回生産品であるが製造不良が全く起こらない」を確信できることではないのか。このような観点に立って、本テキストは構成されている。２．設計バリデーション医療機器の設計バリデーション(7.3.6 設計・開発の妥当性確認)の意味を考えよう。そもそも設計バリデーションとは何であろうか? □法的要求事項を満たしていることの確認? □顧客の要求事項を満たしていることの確認? □必要な機能を発揮しているかの確認? □設計図通りできあがっているかの確認? □安全とされている材質で出来ているかの確認? 全て違う!! これらは本来設計の検証において行われるべきものである。そもそも設計検証は、設計のインプットと設計のアウトプットを比較するところにその本質がある。従って、設計のインプットに規定したことは設計検証において全て確認されうるはずである(少なくとも理論的には)。あどばる経営研究所／A.V.MANAGEMENT 3 同じ様なことが検査にも言える(製品の監視・測定)。検査は、結局のところ、設計のアウトプット通りに製品が出来ているかを確認する作業である。したがって、「設計のインプット等に定められた内容をこなせることを確認できれば、設計のバリデーションは終了する」と捉えると、永久に設計バリデーションを理解することは出来ない。図の「設計のインプット」をよく見ると、「市場、顧客、使用環境、ユーザ、ニーズ、意図・・・」が、暖昧としながらも設計インプットに取り込まれていることが分かる。これは何を意味しているのか。そもそも設計インプットの内容の網羅性、完全性がどこでも保証されていないのである。全ては設計インプットが開始点となっており、設計インプット＝設計アウトプット＝製品の等式を、設計検証、製品検査(監視・測定)という「等号 2 つに対応して、検証活動 2 態」を割り付けていることに注意する必要がある。ところで、製品は最終的に市場に投入され、実ユーザによって使用される。そこで、設計インプットの前に「市場、意図されたユーザ、意図された使用者、意図されない使用者、保管者等の周辺利害関係者、保管環境、使用環境、輸送等」の状況がそもそもあって、そこに対して「市場、ユーザ等」と「設計インプット」との検証が必要になってくる。ところがそれは現実には実施不可能である。設計インプットとは高度に抽象化されたイメージであるから、実世界そのものと直接対比させて検証することは出来ない。設計アウトプットも通常難しい。(回路図及びプログラムコードを読んで、実際の動きを実感し使い易さについてコメントすることは、神業であろうし、ごく一部にそのようなことを出来る人も存在するだろうが、そのプログラムと実体の機械構造物との関連、及び周囲の温度湿度、振動までの影響をリアルタイムで、想像し、かつ検証できる人間は多くない(殆どいないと思われる) 実世界に対応した検証を行うためには、実世界と、比較検証の対象の次元をあわせてやる必要がある。一般には次の 2 つのタイプがあり得る。 □実世界の状況をコンピュータ上に構築する □実世界に実製品を持ち込む設計バリデーションの活動は「実世界、実使用状況、起こりうるかも知れない事故」をどの程度想定できるかが鍵である。このような内容を想定するやり方として □過酷試験 □意地悪テスト □生き残りテストが知られている。もちろん FTA,ETA,FMEA 等も有効な方法である。あどばる経営研究所／A.V.MANAGEMENT 4 プロセスバリデーション設計移管設計バリデーションあどばる経営研究所／A.V.MANAGEMENT 5 ３．プロセスバリデーション（工程の妥当性確認）プロセスバリデーションとは、ある工程が、意図された製品を意図された品質で常に作り続けることを証明する、文書化されたプロセス(活動)」と定義されている。 IS09001:2000 においては、「該当する場合には行う」とされた活動だが、その品質が人間の健康に重大な影響を及ぼす(及ぼしかねない)製品又はその部品(医療機器、医薬品、高圧圧カ容器等)においてはそれぞれ該当する法規制において許可要件化されていることも周知の事実である。(米国では、無菌食品(乳幼児用殺菌済ベビーフード等も含む)もその対象となっている。) そしてこれは GMP の基本概念でもある。本テキストでプロセスバリデーションの全てを解説するものではないが、その活動の骨子は承知する必要がある。そうでなければ、自社のプロセスバリデーションの適切性、正当性を見極めることが出来ず、結果として不適切な(妥当性を欠いた!)プロセスバリデーションとその結果により、自社製品の致命的な製造不良を招きかねず(心臓カテーテルの先端チップの接着不良に起因する脱落により引き起こされうる死亡事故等)企業の PL リスクが発現することになる。(もちろん、主要な観点は企業の存続でなく、人間の健康被害を第一に意識するべき事は言うまでもないが) ここで主要な着目点を考えてみる。検査無し：原理上、妥当性が確認されたプロセス(バリデートされたプロセス)では、無検査で製品を出荷する能力がある。(IS09001:2000 の場合には、「プロセス後の製品の検証が出来ないプロセスは・・・」となっている。「検査」不可能な品質特性は、それを作り込むプロセスの妥当性確認をしなければ品質保証できない、ということであり、どちらを先に考えるかの違いで、実質的には同じ事を言っているわけである。 (優先させたいものは逆転してはいるが)) ワーストケース: 製造工程で許容されうる(原材料の受け入れ基準の下限ぎりぎりの場合等を含む)品質保証上もっとも不利な条件の組み合わせ(複数の組み合わせがあり得る)が起こった場合においても、製品の品質特性は常に維持されなければならない、つまり、チャレンジテストとよばれる工程管理限界で製造された製品の品質特性が維持されることを確認することを言っている。(滅菌の温度、時間が工程管理値の下限ぎりぎりであった場合にも、滅菌の効果は確実に保証されうるか、ということ) あどばる経営研究所／A.V.MANAGEMENT