Author name: ecompliance

Pharmaceutical

品質リスクマネジメントについて

/

GMP施行通知の施行（2013年8月30日）から5年が経過し、2019年度にはGMP省令が改正されることになった。今回の改正は大改正となる。いわゆるグローバリゼーション化（規制の国際整合）が目的であろう。 その中において、品質リスクマネジメント（ICH-Q9）への適格な対応も求められることとなる。これまでICH-Q9 「品質リスクマネジメントに関するガイドライン」は課長通知として発出されてきた。 しかし、改正GMP省令においては、適切に品質リスクマネジメントが活用されるよう、ICHQ9の原則に則して手順書の作成と実施が求められる。 しかしである。日本の製薬企業で品質リスクマネジメントについて正しく理解している企業はどれくらいあるだろうか。 PMDAのホームページには、以下のような概念図が示されている。 品質リスクマネジメントがあたかもPDCAによる改善プロセスの一部のように解説されている。これは明らかに間違いである。品質リスクマネジメントプロセスもPDCAサイクルを持っており、品質管理・品質保証と並行して実施されなければならない。 また品質リスクマネジメントの手順書サンプルも公開されている。これも間違いである。そもそも、品質リスクマネジメントは、特定の部署が特定の手順書を参照して活動するものではないのである。すべてのプロセスにおいて、現存する手順書にリスクマネジメントの概念を入れ込まなければならない。つまり品質リスクマネジメントに特化した部署を設ける訳ではないし、品質リスクマネジメントに特化したSOPを作成するのでもないのである。 ちなみに上記の図において、品質マネジメントレビュは（ISO-9001では）ActionではなくPlanである。ActionにはCAPA等の改善プロセスが位置しなければならない。 FDAは2006年9月に、国際規格である品質マネジメント規格のISO-9001を参考にした「医薬品cGMPにおける品質システムからのアプローチ（Quality Systems Approach to Pharmaceutical CGMP Regulations）と題するガイダンスを発行している。グローバリゼーションが避けて通れないなか、日本の規制要件においても、国際規格、FDA、PIC/S等の真の要求事項の理解と適切なプロセス構築が望まれる。 ]]>

GMP, Pharmaceutical, 法・省令関連

規制要件のあり方について

/

PIC/S GMPをはじめ、FDAやMHRAなどは先進的な規制要件を発出している。内容を読んでいると現状ではどの企業でも遵守できていないような内容や遵守困難な内容が含まれていることがある。これは、欧米の規制要件が期待を述べているためである。規制要件のあるべき姿は、業界を指導し理想的な状態に引っ張っていくことである。したがって、現状では遵守できていなくとも、2～3年後にはそうなっていて欲しいという期待値が記載されているのである。つまり規制要件が改定されたからといって、即座に不遵守が指摘され行政処分を受けることはまずないのである。ただし、何年も旧態依然とした体制やQMSの状態で放置していればいずれ指摘を受けることになるだろう。 一方で、日本の規制要件は多くの場合、後追いである。現状で多くの企業が遵守できていそうな内容や遵守するために困難ではない内容を記載しているように見受けられる。したがって、欧米の規制要件に比べて数年遅れた内容になっていることが多い。しかも、日本の規制要件の構成は実に複雑である、GMP省令、施行通知、課長通知、Q&A、事例集など多岐にわたる。いったいどれが規制要件としての必須事項であろうか。ともするとQ&Aに大事なことが記載されている場合がある。また、本邦においてはPIC/S GMPは課長通知の扱いであり、省令ではない。 話は変わるが、PIC/S は規制当局の集まりである、したがって、PIC/S GMPは規制当局の査察官に対して発出されている。つまり、査察官が査察時にチェックしなければならない事項が記載されているのである。製薬企業が手順書に落とす場合はその点を理解（査察官向けであるということ）しながら作業しなければならない。 ]]>

Design Control

医療機器設計管理の重要性

/

医薬品において、回収の原因のほとんどが製造所の問題である。一方で医療機器の場合、たとえ製造所で適切に製造したとしてもそもそも設計が間違っていては安全な医療機器にはならない。したがって医療機器の設計管理は非常に重要である。 FDAは1980年代から医療機器の設計管理について厳密な管理を求めてきた、設計管理手順書を完全に文書化することを求めている。 1985年から1987年にかけて、Therac-25と呼ばれる放射線治療装置のソフトウェアのバグにより米国内で6名もの死亡者を出した事故が発生した。当初は機器の故障であると思われていたが、調査するうちにソフトウェアの問題であることが判明した。当該医療機器企業が付焼刃的な調査しか行わなかったため3年間にわたり多くの犠牲者を出してしまった経緯がある。この事故は世界10大ソフトウェア事故の一つに数えられている。 そもそも医療機器の事故は「ユーザの意図した利用」と「設計者の設計思想」とのギャップによって発生するといわれている。したがって要求仕様を適切かつ詳細に文書化することが極めて重要である。 例えば手術を行う際にメスがなかったとしよう、そのため近所の最高級刃物店で最高品質のナイフを買ってきた。しかしながら例え最高級ナイフであったとしても手術といった「ユーザの意図した利用」には適さないことは自明である。これでは事故が起きてしまう。 また当該医療機器の設計がユーザ要求を完全に満たしたとしよう。しかしながら、そもそもユーザ要求が間違っていることもあるのである。そこで医療機器における設計管理に関する規制要件や国際規格（ISO-13485）では、設計バリデーションの実施を要求している。設計バリデーションでは、量産初期ロットを使用して、ユーザ環境またはユーザ環境を模擬した環境でユーザまたは同等者がテストを実施しなければならない。 多くの場合、ユーザの要求には安全性に関するものが含まれていない。そのため要求仕様書にはリスク分析の結果やユーザビリティの報告が引用されていなければならない。 最新の国際規格では、予見できるユーザの誤使用も製造メーカの責任となった。そのためユーザビリティに関しては特段の注意を払う必要がある。例えば、駅のコンコースで雑踏の中で取説も読まずに初めて使用するAED、救急車の中で使用する心電図計、家庭で子供が使用する注射器など「誰が」「どのような場で」「そのように使用するか」は重要である。 ユーザビリティというと使いやすさを想像するがそうではない、使いにくくすることもユーザビリティである。例えば、最近の使い捨てライターはノックが重く火がつけにくい。これは子供がいたずらで火事を起こさないための方策である。これもユーザビリティに含まれる。 規制要件や国際規格はいわば先人の轍を踏まないためにあるといえる。規制要件や国際規格を遵守しなければ安全な医療機器は設計製造することができない、けっしてないがしろにしてはならないのである。 ]]>

CSV, Pharmaceutical

ソフトウェアのカテゴリ分類について

/

バリデーションの目的は、完成したソフトウェアが要求事項を満たしたことを客観的な証拠の基づき検証することである。つまり、ソフトウェアバリデーションは、ユーザー要求仕様を満たせばゴールとなるのである。 GAMPでは、ソフトウェアのカテゴリを以下のように分類している。 パッケージの標準機能がそのままユーザ要件を満たしている場合GAMPではカテゴリ3と呼ぶ例えば、分析機器、構造設備など パッケージの標準機能を構成設定（コンフィギュレーション）して、ユーザ要件に適合させる方法GAMPではカテゴリ4と呼ぶ例えば、ドキュメント管理システム パッケージの標準機能をカスタマイズして、ユーザ要件に適合させる方法GAMPではカテゴリ5と呼ぶ ここで注意が必要なことは、すべてユーザ要求を満たすようにソフトウェアを構築することがゴールであり、カテゴリを分類することがゴールではないということである。 筆者はしばしば、「このソフトウェアはカテゴリ何番でしょうか？」や「何とかカテゴリ4とできないでしょうか？」といった質問を受けることがある。これでは本末転倒である。 厚労省の「コンピュータ化システム適正管理ガイドライン」では、カテゴリ分類を強調しているが、世界の規制要件でカテゴリ分類を掲載しているのは日本のみである。FDAにもPIC/Sにもカテゴリ分類という発想はない。 MS-Excelで考えてみよう。 Excelをインストールしただけの場合、カテゴリは1となる。Excelをワープロ（文字、罫線など作成）として使用した場合は、カテゴリ3となる。Excelに計算式を使用した場合（例：請求書）は、カテゴリ4となる。ExcelにマクロやVBAなどのプログラムを書いた場合、カテゴリ5となる。 すなわちである。こういう質問はナンセンスである。「Excelはカテゴリ何ですか？」正しくは「Excelのこういった使用方法はカテゴリ何ですか？」である。 また、Excelの1つのブックには、複数のシートが作成できる。1シート目を表紙とした場合、ワープロとして使用するためカテゴリ3となる。2シート目に計算式を入れたら、カテゴリ4となる。3シート目にマクロを書いたらカテゴリ5となる。 つまり、ITアプリケーションにおいて、カテゴリーは混在するのである。したがって、カテゴリ分類は意味をなさない。カテゴリ分類が有効なのは、構造設備や分析機器なのである。 ソフトウェアのバリデーションを実施する際に重要なことは、カテゴリ分類ではなく、リスクベースドアプローチをとることである。カテゴリ3であっても、抗がん剤や向精神薬などのリスクの高い医薬品を製造するならば、それなりのバリデーション活動を要する。カテゴリ5であっても、ビタミン剤や栄養剤を製造するならば、バリデーションの程度は低くて済むであろう。 読者諸氏もカテゴリ分類の呪縛から解かれることを願ってやまない。 昨今では、ソフトウェアを個別開発する事例は少ない。多くの場合、ユーザニーズに合った市販のパッケージソフトウェア（COTS: Commercial Off the Shelf）を購入し、構成設定やカスタマイズを行うことによって、ユーザ要求に適合させることになる。市販パッケージを導入する場合、一般にユーザとサプライヤが要件定義において、ユーザの要求する機能要件が以下のいずれであるかを決定する。1)　パッケージの機能のまま利用する機能2)　構成設定（パラメータの設定）により変更する機能3)　カスタマイズ（又は外部開発）により変更する機能4)　利用しない機能

Quality Risk Management, Risk Management

リスクについて

/

リスクとは 2005年11月に発行されたICH Q9「品質リスクマネジメントに関するガイドライン」のイントロダクションに、「一般に、リスクとは危害の発生する確率とそれが顕在化した場合の重大性の組み合わせであると認識されている。」と記載されている。ここで、危害の発生する確率であって、欠陥の発生する確率ではないことに注意が必要である。 つまり、企業の製品に瑕疵が生じることがリスクではなくて、何らかの危害が発生する事象をリスクという。一般に、問題点は解決しなければならず、リスクは回避・軽減しなければならない。なぜならば、問題点はすでに発生しているからであり、リスクはまだ発生していないからである。「リスク」という用語の反対語は「確実」である。つまり、リスクとは不確実なことを呼ぶ。経済学では、予想に反して景気が悪くても、逆に良くなってもリスクと呼ぶそうである。 次のような事例を考えてみよう。「ある零細企業が、今日中に1000万円を用意しないと倒産に至るところまで追い込まれた。万策を尽くしてかき集めた手元資金が500万円しかない。」一見すると、倒産というかなり大きなリスクがあるように思える。しかし、当該企業にとっては、倒産は決定であり、もはやリスクではない。 ヘルスケア業界におけるリスクとは 製薬・医療機器業界における「リスク」は、「患者・ユーザへの健康被害」のことである。ヘルスケア業界においては、「リスクマネージメント（RM）」ではなく、「品質リスクマネージメント（QRM）」と呼ぶ。つまり、品質に問題が発生した場合の患者・ユーザに対する健康被害を推定し、あらかじめ回避または受容可能なまで低減しなければならない。 医薬品業界における品質リスク管理 信じられないことではあるが、リスクの高い医薬品業界において、20世紀までは、リスクマネージメントに関するガイドライン等の標準がなかった。2005年になって、やっと「品質リスクマネジメントに関するガイドライン」がICHQ9において合意された。ICH Q9における品質リスクマネジメントの2つの主要原則は以下のとおりである。１．品質に対するリスクの評価は、科学的知見に基づき、かつ最終的に患者保護に帰結されるべきである。２．品質リスクマネジメントプロセスにおける労力、形式、文書化の程度は当該リスクの程度に相応すべきである。 １．は、患者目線（規制当局）の原則であり、２．は、製薬企業目線の原則である。このようにICH Q9は、規制当局と製薬業界の利害関係が一致して合意に至った。 医療機器業界における品質リスク管理 医療機器業界においては、1993年にEU 医療機器指令（MDD）において、リスク分析が必須となった。その後、1998年に国際規格として、ISO14971が制定された。現在の最新版のISO14971は、2007年に改定された。ISO13485規格及び医療機器QMS省令においては、リスクマネジメントの適用・活動が必須となっている。ただし、米国FDAにおける21 CFR Part 820 「Quality System

Medical Device, Pharmaceutical, ユーザビリティ

ユーザビリティとは

/

医療機器において、ユーザビリティに関する国際規格や規制要件が強化されている。FDAは、2016年2月3日に「Applying Human Factors and Usability Engineering to Medical Devices」と呼ばれるガイダンスを発行した。このガイダンスは、2000年7月18日付「Medical Device Use-Safety: Incorporating Human Factors Engineering into Risk Management」を置き換えるものである。 実はFDAは以前からユーザビリティという用語を使用せず、ヒューマンファクターという用語を使用してきた。なぜならば、ユーザビリティという用語は「使いやすさ」を想像させるためである。FDAが要求するのは「使いやすさ」ではなく「安全性」である。わざと使いにくくすることもユーザビリティにとっては重要である。例えば、最近の使い捨てライターはノックが重くなっている。これは想像の通り、小さな子供たちが火をつけて火事を起こさないためのユーザビリティである。 医療機器の事故は、ユーザの意図した利用（Intended

GDP関連, Pharmaceutical

GDP：Good Distribution Practiceについて

/

GDP：Good Distribution Practice（実践流通規範）は、輸送・保管過程における医薬品の品質を確保することを目的とした基準（適正な物流に関する基準）のことである。 これまでは医薬品の品質に関してはGMPのみが運用されてきた。しかしながら、出荷判定後、医薬品に対する品質確認が実施されていない。本来製薬企業の使命として、製造したままの品質で患者に医薬品を供給する必要がある。流通過程では、患者に医薬品が届くまで多くの業者や人が関与している、つまり、GMPだけでは品質保証は困難なのである。 医薬品は輸送・保管の過程で主に温度の変動により変質する可能性がある。そこで、物流過程には様々な問題があり、医薬品の品質を維持する為には、適正に管理することが、重要になってきている。しかしながら、医薬品は航空輸送、海上輸送、陸 運、各国の保税倉庫など、生産地から末端の患者まで多くの組織が関わる。 また医薬品は輸送・保管の過程で、主に温度の変動により変質する可能性がある。医薬品によっては温度管理範囲を逸脱すると変質により使用不可になるものがある。（温度感受性、厳格な温度管理）特に夏季配送時における積み下ろし時の温度上昇の影響などが懸念される。 GDPとは、製造業者から薬局、または医薬品を公共に供給する承認（資格）を有している個人に至るまでのサプライチェーン全段階で医薬品の品質が維持されることを保証する実践規範のことであり、医薬品品質保証の一環である。現状では各国ごとに医薬品の流通に関する事情が異なり、GDPは各国間で整合していない。30ヶ国以上がGDPを採択している。 WHO：WHO Good Distribution Practice for Human Use 米国：Good Storage & Shipping Practices（GSP）

CSV, J-CSV, Pharmaceutical

コンピュータ化システム適正管理ガイドラインについて

/

コンピュータ化システム適正管理ガイドラインについて 厚生労働省薬務局監視指導麻薬対策課は平成22年10月21日にコンピュータ化システム適正管理ガイドラインを発出し、平成24年4月1日から施行した。 結論から述べよう。本ガイドラインは、医薬品のGMPにおける構造設備（医薬品の製造装置）のバリデーションにしか使用できない。 よくある間違いとして、本ガイドラインを医療機器企業が参照していることがあるが、そもそもその対象範囲には入っていない。また非臨床試験、臨床試験（GCP）、製造販売後（GPSP、GVP）などにおいても利用または参照している企業も少なくはない。しかしである、非臨床試験、臨床試験（GCP）、製造販売後（GPSP、GVP）などのビジネス分野では、構造設備が使用されることはなく、もっぱらITアプリケーションが中心である。 コンピュータ化システムの種類は「GMPで使用するコンピュータ化システムは4つのカテゴリに分類される」で解説した通りであるが構造設備、分析機器、ITアプリケーション、インフラストラクチャに分類される。 構造設備は、大きなハードウェアに対して比較的小さなソフトウェア（PLC、ファームウェア等）を搭載していることが多い。従って、ソフトウェアのバグを検出することは比較的少ない。構造設備のCSVの目的は、マニュアルベースの製造がコンピュータ化（すなわち自動化）された際に、医薬品の品質、品質保証が劣化しないことである。また全般的なリスクが増えてもいけない、従って、CSVよりもプロセスバリデーションの重要性が高いといえる。 一方で、ITアプリケーションは、ハードウェアの制御を行わず、大きなソフトウェアのみで構成されていることが多い。ITアプリケーションのCSVにおいては、主にパッケージシステムを導入し、構成設定し、テストを繰り返し実施する。それでもバグは残ってしまうのが常である。 それではなぜ本ガイドラインが構造設備にしか利用できないのか根拠を述べたい。 ITアプリケーションで必要となる構成設定仕様書の記述がない。 設計仕様書に比べて機能仕様書に関しての記載がお粗末である。全般にカテゴリ4に関する記載に乏しい。 設計仕様書の記載がH/Wを前提として書かれている。 テストの記載がなく、DQ、IQ、OQ、PQといったプロセスバリデーションの用語を使用している。 必要に応じて詳細なリスクマネジメントを要求しているものの、その実施方法に関しては記載が全くない。用語の定義もない。 また、筆者が考える本ガイドラインの問題点は以下のとおりである。 規制要件であるにもかかわらず、GAMPといった業界の自主基準を参照して作成されている。これは本末転倒である。通常は規制要件に従って業界自主基準が決まるのである。 FDA、PIC/S GMP Annex11、GAMP 5などで使用されていないDQ、IQ、OQ、PQという用語を使用している。 CSVとプロセスバリデーションを混同している。CSVとプロセスバリデーションの相違についてはこちらを参照されたい。

CSV, GMP, Pharmaceutical

GMPで使用するコンピュータ化システムは4つのカテゴリに分類される

/

GMPで使用されるコンピュータかシステムは、大きく分類して以下の4 種類のカテゴリに分けられる。 プロセスコントロール（構造設備） ラボ ITアプリケーション インフラストラクチャ 上記4 種類のシステムは、それぞれバリデーションの実施 方法が異なる。しかしながら、どのカテゴリにも精通した専門家はほとんどいないのが現状である。 構造設備のバリデーション 構造設備とは、原薬工場における反応槽や発酵槽、製剤工場における造粒機、打錠機、凍結乾燥機、秤量機、高圧蒸気滅菌器、コーティング機、PTP分包機などである。 構造設備の特徴は、その品質が直感的に把握できることにある。すなわちプロセスバリデーションを実施し、実際に生産された製品の品質を確認することによって検証ができるのである。多くの構造設備はカテゴリ3（使用目的が限定され、そのためのプログラムがハードウェアの提供業者によって汎用機能として固定され、パラメーターを設定することによって機能が実現されるシステム）である。また構造設備では、ハードウェアをPLC、ファームウェアなどの比較的小さなプログラムで制御していることが多い。したがって、ほとんどの場合、供給者にIQ、OQ （IOQ）を実施させることになる。ただし、複雑またはユーザが変更したPLC は、カテゴリ5に分類されるが、カテゴリ3 と5 の境界は曖昧である。昨今は、SCADA やDCS のように、ITアプリケーションにより中央で集中管理されている構造設備も利用されている。一般に構造設備では、適格性検証（Qualification：DQ、IQ、OQ、PQ）を行う。一般に１つの構造設備は、1 つの機能しかもたない。例えば、造粒機は造粒する機能、打錠機は打錠する機能である。つまり1システム=1機能=1プロセスとなる。したがって、そのような構造設備では、機能仕様書は作成しない。（というよりも作成できない。） 厚労省のコンピュータかシステム適正管理ガイドラインでも、機能仕様書に関して詳細に記載がない所以である。筆者はこれまで多くのサプライヤと仕事をしてきたが、機能仕様書の書き方を知らない業者がほとんどであった。一般に機能仕様書は、IT アプリケーションのような比較的複雑な機能を持つシステムに関して作成する。

Quality Risk Management, Risk Management

FTAとは？

/

医薬品業界や医療機器業界では、リスクマネジメントにおいて各種のリスクマネジメント手法を持ちいる。リスクマネジメント手法は著名なものだけでも以下のようなものがある。 製造設備のリスクマネジメントにおいては、欠陥モード影響解析（FMEA）が多く用いられる。一方で、故障の木解析（FTA）は意外とその利用方法が理解されていないことが多い。 FMEAは、「もしこのような故障が発生したら、その結果どのような影響を受けるか」というような質問を体系的に設定する帰納的な手法である。つまりボトムアップ的な手法である。それに対してFTAは、FMEAとは対称的に、想定した「好ましくない結果」 （危害発生の事故等）から出発する演繹的な方法である。つまりトップダウン的な手法である。FTAは、その事象（事故等）をもたらす可能性のある原因や事象を、それ以上分解できない基本事象まで遡って分析する原因解析型手法である。論理記号（AND、OR等）を用いて図式化することで、複雑な因果関係を把握できるため、想定しにくい事故原因・ハザードの網羅的・早期対策（FMEAの確認・水平展開）や、特定の事故の再発防止対策を講じるための分析手法として有効である。 今、ガスが爆発したという事象（事故）について、FTAを使用して原因分析を試みてみよう。（下図参照） まずガスが爆発するためには、「点火源」と「空気」と「可燃性ガス」が同時に存在しなければならない。ここで空気をなくすことはできないので「空気」は除外する。「可燃性ガス」が存在するということは、タンクから漏えいしたこと以外に考えられない。図においてこの「タンクからの漏えい」はもうこれ以上原因を展開するできないため非展開事象と呼ぶ。非展開事象はひし形で表す。次に「点火源」であるが、「熱源」か「電気火花」か「直火」が原因であると考えられる。「熱源」と「直火」は非展開事象である。「電気火花」の原因は「断線」または「ショート」である。「断線」や「ショート」も非展開事象である。 お分かりであろうか。ガス爆発の再発を防ぐためには、「熱源」や「直火」を遠ざけ、「断線」や「ショート」や「タンクからの漏えい」を防止すれば良いのである。 FTAはこのように事故の原因を究明するのに有効である。FMEAとFTAを組合せたならば、より確実なリスク分析が実施できる。 一般にFTAは、事故が発生し、その再発防止の目的でCAPAを実行する際などに使用する。CAPAにおいては「なぜなぜ分析」（5Whys）を実施することがあるが、FTAはそれを上記のように論理記号等を用いてロジカルに根本的原因を究明する。医療機器の設計変更時などに有効である。 ]]>

Scroll to Top