Medical Device

医療機器ソフトウェア

医療機器に搭載するソフトウェアの品質保証

筆者がコンサルテーションを実施する中で、いつも驚くのは、医療機器企業におけるソフトウェア開発の未熟さである。多くの医療機器企業では、新製品の納期に追われ、十分な検証やテストを実施せずに出荷しているケースがみられる。また、ソフトウェア開発会社(ソフトウェアベンダー)に比べて、ソフトウェア開 発に携わる人数が極端に少ない。さらにソフトウェア要員も適切な教育を受けていない場合が多く、不慣れ(未熟) なまま開発を行っている実態をよく目にする。 米国におけるFDAにかかわる年間の回収数(全品目)は9,000件前後にも上る。そのうち医療機器に関しては、2014年度は1,283件の回収イベントで2,706品目が回収されている。医療機器の場合、回収の原因のうちその過半数が設計問題である。またそのうち8割以上がソフトウェアの欠陥によるとされている。 FDAは、医療機器の回収数を如何に減少させるかという課題に立ち向かっている。また、医療機器企業においては、経営の健全化を図るためにCOPQを重要視しなければならない。COPQとは、Cost Of Poor Quality の略であり、低品質や品質不良、欠陥、エラー のために生じる無駄なコストのことのことである。例えば、設計変更、製品検査、回収、患者への補償、訴訟費用、計画変更やサイクルタイムが延びることで起こる売上機会損失、ブランド価値低下などの潜在的なものまで含めた余計な手間やコストのことである。通常、企業では日常的に売り上げの25%~30%の損失を発生させているといわれている。ソフトウェアのライフサイクルにおいて、欠陥の発見がリリースに近いほど費用がかかる。ライフサイクルの後期に発見された欠陥は、開発者による作業のやり直しが必要になることが多く、必然的にソフトウェアのリリースが遅れる。この段階でエラーを修正するコストは、開発段階の100倍にもなる場合がある。医療機器がが市場に出てからエラーを修正するコストは1000倍にもなりかねない。 品質を改善することは、余分に多大な時間と費用がかかると思いがちである。 品質活動に必要なコストは、活動人件費が大きいが、実際には費用を上回る効果が 実現出来る。欠陥をを減少させる事によりCOPQは大きく改善されるのである。 Google社は、膨大なソフトウェアを提供し、かつ日々新しい機能を開発・リリース しているが、不具合がほとんどないことで知られている。その理由は、テスト戦略にある。「テストファースト」によるエンジニアリング生 産性の向上を図っている。(参考文献:グーグルのテスト開発 日経BP社刊) FDAは、医療機器に含まれるすべてのソフトウェアの詳細なベリフィケーションとバリデーション(V&V)を実施するよう医療機器企業に要求している。一般的にソフトウェアのテストは、通常プログラムを実行させて実施するが、すべ ての条件分岐を検査することは不可能である。システムテストで見つける欠陥の60%以上が、コーディングエラーに起因しているといわれる。開発者がユーザの要件を単純に解釈してコーディングするためである。システムテストをより短期間で効率的に実施するためにどうやってコーディングエ ラーを減少させるかが問題である。従来の単体テストやソースコードレビュでは、多くの不具合が見落とされてきた。これまでは、ベリフィケーションとバリデーション(V&V)は人手によって実施されてきた。つまり、従来はプログラムのすべての条件分岐をチェックする唯一の方法は、手作業によるソースコードのレビュであった。しかしながら、手作業によるソースコードレビュでは、担当者の力量に大きく依存 […]

コンピュータシステム導入

品質イベント管理システムとは

品質イベント管理システムとは 品質イベント管理システムとは、顧客苦情管理、不適合管理、変更管理、工程変更管理(4M変更)、内部監査管理、教育管理、CAPA管理等を支援するシステムのことです。 品質イベント管理システムは、ドキュメント管理システム(EDMS)と同時に導入することによって、よりFDA査察対応能力を増強させることができます。 ドキュメント管理システムは、QMS、DHF、DMR、DHR、MDR、QSR(品質記録)等を電子的に一元管理するシステムのことです。 ドキュメント管理システムでは、電子ワークフローを構築することが一般的です。 医療機器企業各社の課題・問題 品質イベント管理システムとは 「イベント管理システム」および「ドキュメント管理システム」はFDA査察対応の要です。 品質イベント管理システム 医療機器企業のFDA規制要件に対応できるイベント管理システムとして著名なパッケージシステムには、以下の2つがあります。 1.TrackWise(Sparta Systems社) 2.MasterControl (MasterControl 社) いずれも比較的大規模なシステムで、高価です。 またシステムそのものは、電子ワークフローシステムですので、ユーザ要件に従って構築する必要があります。 両システムともドキュメント管理機能を備えていますが、イベント関連以外のドキュメントとのリンク等を考慮した場合、別途ドキュメント管理システムを導入する企業が多いです。 いずれにせよ、貴社でFDA規制要件対応要求事項を明らかにし、当該ベンダーにユーザ要求仕様書を提供する必要があります。 ドキュメント管理システム

コンピュータシステム導入

FDA対応PLM*1 構築の留意点

多くのベンダーから、PLMシステムが販売されている。どのベンダーも医療機器業界とFDA対応をうたっているようだ。しかしながら、実際にデモをみたり、プレゼンテーションを受けてみても、本当にFDA対応ができているシステムというのは、皆無のようである。またベンダーには、FDA対応のためのスキルを持った要員がいないことがほとんどで、逆に医療機器メーカからノウハウの提供を受けたいと願っているところばかりである。 ではいったいFDA対応のPLMシステムとはどういうものであろうか。 グランドデザインの重要性 FDA規制対応が必要な医療機器業界では、一般製造業と違って、CAPA、DHF、DMR、DHR、MDR、QSRの構築が必須である。 “15分ルール” 「査察官の要求に対し、15分以内に適確な資料等を提示しなければならない。」という暗黙のルールのこと。(実際に明文化されているわけではない。) もし資料の提示に15分以上かかる場合は、“査察コーディネータ”は、いつまでに(例:本日の午後、明日の朝など)資料を提示できるかを説明し、次の質問に移ってもらうように要請しなければならない。 15分以上、査察官を待たせるということは、「査察妨害」ととらえられる可能性がある。 待たされた査察官は、本来指摘に及ばない事項に関しても、言及することになりかねない。 紙ベースで査察に対応する場合、15 分以内に適切な記録を探し出すためには、すべての文書・記録を査察が行われている部屋の近くに配置しておかなければならない。その上で、各部署の担当者が即座に適切な文書・記録を探し出し、届けられなければならない。 文書・記録は、出来る限り電子化されていることが望ましいが、その場合は電子記録の信頼性も問われることになる。つまりPart11 対応が重要となるのである。 CAPA 非常に高い確率で調査されるのは、CAPA である。日本の企業では、CAPA が紙ベースやExcel などで管理されていることが多い。 また苦情管理のみ対象としている企業も多い。近年は、CAPA システムの構築がほぼ当たり前となりつつあり、FDAの指摘(483

Design Control

機器履歴簿(DHF)

DHFの原則 各機種の設計に対して設計履歴ファイル(DHF)を作成し保存すること。DHFには、計画書で定義されている設計に関するすべての記録を保持すること。設計開発は、設計計画書に基づいて実施されたことをDHFの内容により証明できること。DHFは、設計のInput、Output、Design Review、Verification、Validationの各時点での成果物を登録すること。Input、Output、Design Review、Verification、Validation結果を承認すること。 FDAのワーニングレターの事例 貴社は設計が承認された設計計画および21 CFR 820の要求に従ってなされたということを示すための必要な記録を含み、参照するための設計履歴ファイル(DHF)を確立および維持していない。 参考 21 CFR Part820 Quality System Regulation, FDA 1997Design Control Guidance For

Design Control

FDA対応設計インプットの要点

FDAが最も多く指摘しているのは、設計へのインプットを定義していないことである。設計へのインプットを誤解している企業が多い。一番多くある誤解は、設計へのインプットとはユーザ要求のことであるというものである。また仕様書類は、すべて設計からのアウトプットであるといった誤解である。設計へのインプットは、決して概念的なものではなく、あらかじめ定義した複数の資料で構成される。 設計開発計画書 要求仕様書 設計へのインプットを作成する際には、あいまいな要求をを具体的な仕様に落とし込まなければならない。例えば、「持ち運べること」といった要求のままでは、設計ができない。そこで、「重さは3Kgまでとする」「一辺が最大10㎝までとする」といったように具体的な仕様に落とし込むのである。 最終的に、設計インプットは適切にレビュ、承認しなければならない。ここでいう承認は、各資料毎の承認のことだけではなく、設計へのインプットとしての承認である。つまり、メカ、エレキ、ソフトウェアの要求仕様の組合せとして、問題ないということを承認しなければならない。 また設計へのインプットは、レビュ、承認後、DHFに維持しておかなければならない。その後に起こる全ての変更は変更管理手順に従う。 FDAのワーニングレターの事例 貴社は21 CFR 820.30(c)、すなわち「設計へのインプット」に適合してない。この設計へのインプットの要件を含む設計管理手順の改訂版がFDAへの提出を約束した期日にまだ届かないため、指摘事項(Form 483)がWarning Letterに発展した。 設計インプットとは 設計インプットは「FDA 21CRF Part820 Quality System Regulation」の「Subpart C§820.30(c)

Design Control

設計開発計画書

設計開発計画書は、設計が適切に管理されているかどうかを示す重要な文書である。計画書には、設計の各フェーズを誰が主導し、責任を負うかを記載すること。設計のアプローチは、非常に複雑で多くのチームメンバーが関わるため、計画の様々なステージで責任を明確に定義することは非常に重要である。例えば、品質保証グループまたはプロジェクトマネジメントグループがデザインレビュを主導するが、R&D、臨床、薬事、品質技術、製造およびマーケティングの全てのチームメンバーが、必要に応じて関わるべきである。インターフェースの特定には、設計プロセスに関わる組織グループ(例、マーケティング、購買、品質保証、製造およびサービス)の役割の定義および彼らに転送され、受領される情報の記載が含まれる。これは、複数の組織や外部の会社または契約者が関わる場合には、特に重要である。必要に応じてフローチャートを作成し、インターフェースを特定すること。設計開発計画は設計プロセスが適切にコントロールされ、機器の品質目標を満たしていることを保証するために必要である。計画は設計管理要求に沿っていなければならない。 一般的に設計開発計画で述べられる要素を次に掲げる。 設計開発プログラムについての目標および対象の記述 設計開発フェーズにおける、品質保証の観点での組織責任図。契約業者との関係も含めること。 実施する主要なタスク、各タスクの成果物、各タスクを遂行するための個人または組織的責任(スタッフおよびリソース)の特定 プログラム全体の時間制約を満たす、主要なタスクのスケジューリング レビュワーの選定、レビュチームの構成、レビュワーが従うべき手順 設計文書の管理 周知活動 設計開発計画書のレビュ・承認と更新 設計開発計画書をレビュし、承認したことを証明すること。設計開発計画書は、設計および開発プログラムが進展する毎に適切に更新し、レビュ、承認すること。(変更管理を適切に行うこと)レビュおよび計画書更新の頻度は、計画書内に記載すること。 設計開発計画書はDHFへ 設計開発計画書は、設計へのインプットの1つである。計画書は、承認バージョン毎に、DHFとして保持すること 。 設計開発計画書の内容 設計開発計画書作成のための手順書を作成し、以下を記載すること。 設計開発プログラムの達成目標と目的 要員計画組織の責任の定義設計開発業務の責任者、リーダー、担当者等(資格の特定)適切なスキルをもった要員(内部および委託契約者やコンサルタント)誰がどの段階でデザインレビュ・検証・バリデーションに関わるのかの定義設計開発に携わる関連部門の責任者各部門間のインターフェース 設計開発のスケジュール(製品開発のライフサイクル全体)主要なタスクのマイルストーン主要なデザインレビュおよび設計ポイントの特定検証・バリデーションのタイミング 品質システムに従った設計の各フェーズに必要な要素

CSV,ER/ES,DI, Medical Device, コンピュータシステム導入, 医療機器ソフトウェア

医療機器企業におけるソフトウェア バリデーション

医療機器企業が実施しなければならないソフトウェアバリデーション について FDAガイダンス「General Principles of Software Validation」において医療機器企業がソフトウェア のバリデーション を実施しなければならないものとして以下の4種類があげられている。 これらのうち上の2つは設計バリデーション の対象となり、下2つはCSV(Computerrized System Validation)の対象である。 医療機器企業におけるソフトウェア バリデーション 規制要件 FDAが査察を行う理由はただ一つである。それは、粗悪な医療機器の米国輸出を阻止 し、米国における患者・ユーザを保護することである。昨今の医療機器では、ソフトウェア が搭載されていることが多い。 海外では、医療機器に搭載するソフトウェア の開発には、非常に厳格な規制要件の 遵守が義務付けられている。IEC62304「Medical device software – Software life cycle

Medical Device, 医療機器ソフトウェア, 医療機器新規参入

医療機器ソフトウェアの製造・販売をするためには

2014年11月25日から、薬事法が一部改正された。これにより、現在の「薬事法」という名称から、「医薬品、医療機器等の品質、有効性および安全性の確保等に関する法律」(医薬品医療機器等法)という名称に変更される。 医薬品医療機器等法のポイントはこちら。 日本国内で医療機器となるソフトウェアを設計・製造・販売するためには 改正法では、医療機器の「機械器具等」の範疇に、「ソフトウェア(プログラム)」が追加されといった大きな変更がなされた。これまではソフトウェアはハードウェアに含められて、医療機器とみなされてきたが、改正法下では、プログラム単体でも医療機器となる可能性がある。例えば、診断等に用いる単体プログラムについて、医療機器として製造販売の承認・認証等の対象となる。 したがって、改正法下で医療機器に該当するソフトウェアを開発する企業において、医療機器の製造販売業許可の取得や、製造業の登録が必要となった。 製造販売業 製造販売業については、高度管理医療機器、管理医療機器等の種類に応じて許可を取得する必要がある。(新法第23 条の2関係) 医療機器を市場に出す事業者(製造販売業者。輸入業者も含まれる。)は、医療機器の製造販売業許可を取得することになる。医療機器を日本国内市場に出すにあたっては、医療機器の品質が保証され、ユーザーや患者、医療関係者等の安全が確保されるものでなければならない。そのため、医薬品医療機器等法では、製造販売業許可の要件として、品質保証と安全管理の体制を整えることが求められている。医療機器製造販売業許可は、「事業者」が取得する。一法人にひとつの許可。(第1種医療機器製造販売業許可と第3種医療機器製造販売業許可を同時に持つことはない。)複数の営業所がある場合は、総括製造販売責任者の常駐する事業所(本社等)がある都道府県知事に、許可を申請する。 医薬品医療機器等法施行後は、製造販売業がQMS省令の対象となる。従来のように製造所毎に別個に調査・判定をするのではなく、製造販売業者に対して、品質システム全体を包括的に調査・判定することになった。 製造販売業者の責任業務 製造販売業者は、次に掲げる業務を行わなければならない。 QMSに必要な工程の内容(当該工程により達成される結果を含む。)を明らかにするとともに、当該工程のそれぞれについて、各施設の関与の態様を明確にすること。 工程の順序および相互の関係を明確にすること。 工程の実施および管理の実効性の確保に必要な判定基準および方法を明確にすること。 工程の実施、監視および測定に必要な資源および情報が利用できるようにすること。 工程を監視し、測定し、および分析すること。 工程について、1.の結果を得るために、および実効性を維持するために所要の措置を採ること。 QMSの構築 製造販売業者は、新QMS省令にもとづき、QMSの構築を行わなければならない。

ISO-13485:2016, Medical Device

品質マネジメントシステム

【連載】ISO-13485:2016対応の要点 【第2回】品質マネジメントシステム 品質マネジメントシステムとは ISO-13485:2016の第4章では「品質マネジメントシステム」についての要求事項が記載されている。 4 品質マネジメントシステム4.1 一般要求事項4.2 文書化に関する要求事項 4.2.1 一般 4.2.2 品質マニュアル 4.2.3 医療機器ファイル 4.2.4 文書管理 4.2.5 記録の管理 ISO-13485の箇条で最も大事な要件を集めた章であると筆者は考えている。 なお品質マネジメントシステム(QMS:Quality Manegement System)は、FDAの場合品質システム(QS:Quality System)と呼んでいる。それらの意図はまったく同じである。 ISO-9000では、「品質マネジメントシステム」を次のように定義している。 (a)品質マネジメント(Quality

ISO-13485:2016, Medical Device

ISO-13485改定の要点

【連載】ISO-13485:2016対応の要点 【第1回】ISO-13485改定の要点 2016年2月25日にISO-13485:2016が発行された。 ISO13485:2003からの認証の移行期間は、ISO 9001と同じで以下とおりである。 移行期間は3年間。(改定後3年間は、旧版(ISO13485:2003)での認証が有効である。) 改定後2年間は、旧版(ISO13485:2003)での認証が可能である。 改定後2年たってから3年までの期間は新版(ISO 13485:2016)でのみ新たな認証が可能である。 従って、多くに医療機器企業はあと1年足らずの間にISO-13485:2016に移行しなければならない。 ISO-13485の改定に先んじて、2015年9月15日にISO-9001が改定された。しかしながら、ISO-13485は、ISO-9001:2015には追従せず、ISO-9001:2008に整合させている。そのため、マネジメントシステムの共通のMSS(Management System Standard)要求仕様であるAnnex SLに従わず、従来の構造のままである。ISO-9001が、今後Annex SLのMSSに従った改定を行った後に、ISO-9001に合わせる方向で、再度Annex SLに従う構造への改定を行うことになる。 ISO-13485:2016の改定の主な目的 ISO-13485改定の主な目的は、 QMS要求事項の明確化 現状の各国規制との整合

Scroll to Top