STERLINGTECH と KLOCWORK | ホワイトペーパー | 2009 年 11 月 医療機器用の有効な ソフトウェア検証 静的解析によるコンプライアンス遵守と 生産性目標の達成 今日の医療機器メーカーは、他の組み込みプログラミング業界と比べて格段に少ないエ ンジニアリング リソースで極めて複雑なコードを開発しているだけでなく、非常に厳格な 規制要件の遵守が義務付けられています。新しい規制では、メーカーに対して、医療シス テム向けソフトウェアの開発時に特定のベスト プラクティスに従うように定めています。こ れらの規制は国によってさまざまであり、定期的に発表、見直し、更新が行われることから、 必要な規則を全て守ることは容易ではありません。 このホワイトペーパーでは、医療機器ソフトウェアの現在の規制要件を明らかにし、自動 静的コード解析（SCA）技術によってもたらされるコンプライアンスと生産性のメリットに ついて説明していきます。また、ソフトウェア検証のベスト プラクティスについても取り上 げています。これらのベスト プラクティスを開発プロセスに取り入れることで、機器メー カーは信頼性と安全性を兼ね備えた多機能なソフトウェア コードの開発を進めながら、コ ンプライアンスと生産性に関する目標を達成することが可能です。 規制環境 – 概要 欧州共同体（EC 指令による）と米国食品医薬品局（FDA）では医療機器に関する規制を制定し、 機器の使用に向けた分類と承認の前にそれらを満たすことを義務付けています。これらの 2 団体で は、医療機器のマーケティング、ラベリング、モニタリングの要件を定めているのに加え、製品に組 み込まれるソフトウェア コンポーネントの妥当性の確認を機器メーカーに求めています。 FDA 要件 米国内で販売される医療機器に対しては、米連邦食品・医薬品・化粧品法（FD&C 法）の一般統制 と米国連邦規則 21 条第 800-1200 章（21 CFR Parts 800 – 1299）の最終手続規制の両方に準拠 することが義務付けられています。特に重要なのが 21 CFR Part 820 であり、ここには品質システム フレームワークの制定に必要な企業ポリシー、業務手順、ガイドライン、目標を設定するための標 準が示されています。 さらに FDA では『General Principles of Software Validation（ソフトウェア バリデーションの一般原 則）』の資料を作成しており、その中で「医療機器ソフトウェアの妥当性確認または医療機器の設計、 開発、製造に使用されるソフトウェアの妥当性確認に適用可能であると食品医薬品局（FDA）が考え る、バリデーションに関する一般原則」の概要を示しています。1 これらの原則は以下のソフトウェアに適用されます。 » 医療機器のコンポーネント、部品、付属品として使用されるソフトウェア » それ自体が医療機器であるソフトウェア（血液事業者向けソフトウェアなど） » 機器の製造に使用されるソフトウェア（製造装置のプログラム可能なロジック コントローラ など） 1 General Principles of Software Validation, FDA, January 11, 2002, Section 1. http://www.fda.gov/RegulatoryInformation/Guidances/ucm126954.htm » 機器メーカーの品質システムの実行に使用されるソフトウェア（機器の履歴を記録・保持するソフトウェアなど） 最後に、テストの水準――および 1 件のプロジェクトで提出する必要があるテスト資料の数――については、FDA の『Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices（医療機器に含まれるソフトウェアの 市販前提出物の内容に関するガイダンス）』2 で定められています。これらの要件はソフトウェアの「問題のレベル」によって 変わってきますが、このレベルは患者と施術者のリスクの深刻度に応じて重度、中程度、軽度に分類されます。 米国および世界の医療機器に関する規制 21CFR 820 Quality System Regulation, Food and Drug Administration, April 1st, 2008 Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 11th, 2005 General Principles of Software Validation、Final Guidance for Industry and FDA Staff, January 11th, 2002 Guidance for Industry, FDA Reviews and Compliance on Off-the-Shelf Software Use in Medical Devices, September 9th, 1999 ISO 13485 Medical devices:Quality management systems – Requirements for regulatory purposes, 2003 EN 62304 Medical device software:Software life cycle processes, 2006 ISO 14971 Medical devices:Application of Risk Management to Medical Devices, 2007 MDD 93/42/EEC:Council Directive 93/42/ EEC of 14 June 1993 concerning medical devices; last amended September 5th, 2007 医療機器が規定に準拠しているかどうかを評価する際、FDA では機器のソフト ウェアの開発で構造化プロセスが使用されていることの客観的証拠を探します。 したがって、企業に対してはソフトウェア検証を含む階層型のソフトウェア バリ デーション アプローチの使用が推奨されます。FDA は次のように述べています。 「計画、検証、テスト、トレーサビリティ、構成管理など、優れたソフトウェア エンジニアリングが持つさまざまな側面は、ソフトウェアが妥当であるという最 終結果を導き出すための重要なアクティビティである」3 医療機器の評価において FDA は、ソフトウェア開発ライフサイクルの特定の フェーズのデザイン アウトプットがそのフェーズの指定要件を全て満たしている ことの証拠もあわせて探します。その際、ソフトウェア開発のアウトプットがイ ンプット要件を満たしていることを確認するために、ソフトウェアのテスティング と検証のアクティビティ――静的 / 動的な各種解析、コード検査、ドキュメント 検査、ウォークスルーを含む――が利用されているかどうかがチェックされます。 さらに FDA では、全てのソフトウェアの妥当性確認・検証作業が 21 CFR Part 820 に示された「Quality System Regulation（品質システム規制）」に 従い実施されることを求めています。FDA Quality System Regulation（QSR） は、品質管理システムの構築で使用するための基本要件のフレームワークを、 完成医療機器のメーカーに提供しています。『General Principles of Software Validation』の要件と同様、QSR でも、開発プロセス――およびそこから生ま れる製品――が指定要件を満たしていることの証拠を検証活動によって示すよ うに求めています。 国際要件 医療機器メーカーは、欧州共同体（EC）など他の規制機関から出される指令 にも注意を払う必要があります。政府当局はそれぞれ独自のコンプライアンス 指令を制定している一方で、重複点も少なからずあります。 FDA の Quality System Regulation と同じような内容をカバーしている ISO 13485 では、ソフトウェア開発品質システムが導入・保守されていることの 実証をメーカーに求めています。さらに、EN 62304 標準（ （CEN（欧州 標準化委員会） 、CENELEC（欧州電気標準化委員） 、ETSI（欧州電気通信 標準化機構）により発行）では、FDA の『General Principles of Software Validation』で示されているのと同様の活動を、ソフトウェアのクラスに従い実 施し文書化することを求めています。これらのソフトウェア クラスは、FDA で使用されているものとほぼ一致しています。以 下の表は FDA のソフトウェア クラスを分かりやすくまとめたものです。 患者や施術者のリスク FDA が定める問題のレベル EN 62304分類 損傷を引き起こす可能性の 低い不具合 軽度の損傷を引き起こす 可能性のある不具合 死や深刻な損傷を 引き起こす可能性のある 不具合 軽度 中程度 重度 A B C 医療機器ソフトウェアを対象とした世界の規制環境は一見複雑に見えますが、規制機関が求める証拠は基本的に全て同じです。 2 http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm089543.htm 3 General Principles of Software Validation, FDA, January 11, 2002, Section 2. http://www.fda.gov/RegulatoryInformation/Guidances/ucm126954.htm Effective Software Verification for Medical Devices | Klocwork White Paper | 2 1. 2. 品質システムのフレームワーク内でソフトウェア開発が行われたことを裏付ける証拠 ソフトウェアの検証と妥当性確認が行われたことを裏付ける証拠 医療機器企業が適切な品質システムを導入するには、ISO 13485 ガイドラインを参考にし、品質システムを評価して問題個所 を特定するために、独立した第三者機関の専門家の雇用を検討する必要があります。機器のソフトウェアの検証と妥当性確認 を実施する際、メーカーはいくつもの選択肢の中から方法や技術を選ぶことが可能です。 ソフトウェアの検証と妥当性確認 あらゆる医療機器のコンプライアンス戦略の重要要素となるのが、ソフトウェアの検証と妥当性確認のための適切な方法です。 FDA の考えるソフトウェアの妥当性確認とは、「ソフトウェア仕様がユーザのニーズと使用意図に合致しており、ソフトウェアを 介して遂行される特定の要件が一貫して満たされることを裏付ける客観的証拠を検証・提供する」4 というものです。 ソフトウェアの妥当性確認の活動には、以下のことが求められます。 » ソフトウェア開発ライフサイクルのあらゆる段階で実施する。 » 全てのソフトウェア要件が正しくかつ完全に遂行され、システム要件とのトレーサビリティが確保されていることを 実証する。 妥当性確認の全ての課題を 1 つの方法で解決することはできません。しかし、複数のアプローチとテクノロジを組み合わせる ことで、医療機器メーカーが最高品質のソフトウェアを開発できるよう支援することが可能です。妥当性の確認とあわせて、ソ フトウェアが正しく構築されていることを検証する必要があります。妥当性確認と検証の違いを簡単に説明すると、以下のよう になります。 » 妥当性の確認では「正しいものを構築しているか」どうかに着目する。 » 検証では「構築が正しく行えているか」どうかに着目する。 「正しいものを構築」するには、ユーザの視点から仕様をチェックし、外部顧客のニーズに合った製品であることを確認する必 要があります。これに対して「構築を正しく行う」には、内部に目をやり、全ての仕様が正しく実装され、インプットとアウトプッ トが事前に決められた規制や標準に準拠していることを確認する必要があります。 ソフトウェア検証を行う際には、手動によるピア コード レビュー、コーディング標準の適用、プログラミング エラーの発見の ためのソース コード解析などの各種静的技術だけでなく、ユニット テストやメモリ プロファイリングといったさまざまな動的 解析技術の中から、検証に使用する技術を選択するようにします。動的技術は効果的で必要不可欠なものですが、一方で効 率性と拡張性が十分でないものが多々あります。動的技術ではコードを実行する必要があり、そのせいでコストがかさむこと になりかねません。さらには、コード カバレッジの目標を達成するのに必要なテスト ケースの構築を試みる際に、拡張性の 制約という問題に直面することも考えられます。大規模なコードベースでは、解析を実行するためにメモリ プロファイラのよう なツールを数日間稼動させなければならない場合もあります。多くの組織がさまざまな静的技術によって動的解析戦略を補完 している背景には、このような事情もあるのです。2 種類の技術を組み合わせることで、静的解析を使って問題をコスト効率よ く検出して、動的解析の前にそれらをコードから排除することができ、時間と手間の削減につながります。 利用可能な静的検証技術は多数あり、どのツールとプロセスを組み合わせればいいのか見極めるのは容易ではありません。 たとえば、医療機器で高品質のソフトウェアのみが採用されるようにするためにピア コード レビューが使われるというのはよ くあることですが、これらのレビューに伴うスケジューリングやオーバーヘッドはコストの増大を招いてしまいます。それでも、 ピア コード レビューがほとんどの検証戦略の中核を担っていることに変わりはなく、多くの組織がレビューのリモート実行が可 能な、ツールを使ったアプローチを採用しています。この場合、多機能なコード検査インターフェイスが提供され、それを使っ てレビューを実行することが可能です。 たとえコラボレーティブ環境でツールによるレビューがサポートされていたとしても、手動でチェックできるコードの数には常 に上限があります。FDA も手動レビューだけでは不十分なことを認め、 こう述べています。 「たとえ小さなソフトウェア アプリケー ションであっても、手作業での障害解析が不可能な複雑なケースも考えられる」5。手動のコードレビューは拡張性に制限があ るだけでなく、多くの場合、上級開発者が他の作業を行えなくなることから、コストの増加を招いてしまいます。設計と要件の 問題にフォーカスしたレビューが必要なのはそのためです。 ソースコード解析 これらの問題に対処するために、多くの医療機器メーカーがコード検査プロセスの自動化を図ろうと静的ソースコード解析 （SCA）ツールに注目しています。SCA ツールを使うことで、ポインターの誤った利用法やオーバーフロー、漏えいといった フィールド不具合の原因となる構造的欠陥を検出・特定することができます。特に大規模なプロジェクトでは、ターゲット デバ イス上で実行可能な適切に統合されたシステムが完成する前に、開発者はコードの大半を記述しなければならないため、こ のような SCA ツールが役立ちます。さらには、静的解析ツールを使えば、ソフトウェア開発プロセスの早い段階――通常は 4 General Principles of Software Validation, FDA, January 11, 2002, Section 3.1.2 http://www.fda.gov/RegulatoryInformation/Guidances/ucm126954.htm 5 www.msse.umn.edu/system/files/Brian09.ppt.Slide 5 Effective Software Verification for Medical Devices | Klocwork White Paper | 3 統合ビルドの実行が可能になるずっと前の時点――でソフトウェアの「バグ」を発見することができます。バグの発見が早け れば早いほど、修正にかかる時間とコストが少なくてすむことから、問題の解消率が大きく向上することになります。 優れた SCA ツールは、高度な解析機能を開発者に直接届けることで他のソフトウェア検証ツールを補完し、ソフトウェア開発 時にコーディングの脆弱性を特定・修正できるようにします。このアプローチを採用することで、コード ストリームでの不具合 の発生数が減り、コード品質の向上と、作業の効率化、ピア コード レビューとテスティングの改善につながります。 導入の課題 医療機器メーカーは特定の業界や分野 の規制要件を理解するだけでなく、現在 のソフトウェア プロセスとツールを評価 して、それらが業界規制を満たしている かどうかを見極める必要があります。 知識と経験のある第三者機関の専門家に 依頼して、以下の作業の支援をあおぐこ とで、このような評価作業の実施が可能 になります。 » 品質システム監査 » IEC 62304 コンプライアンス評価 » Good Manufacturing Process （GMP）バリデーション » Installation Qualification（IQ）、 Operational Qualification（OQ）、 Performance Qualification（PQ） » ツールの選択を含む「ベストプラ クティス」の推奨事項 「医療機器開発メーカーである弊社のソ フトウェアは、人々の生命に重大な影響を 与える可能性があります。 したがって、ISO 公認の品質システムを利用したり、出来る かぎり最先端のツールを採用するなど、 最高品質の製品作りに向けてありとあら ゆることを実践しています。Klocwork は 弊社が所有するツールの中でもっとも重 要なものの 1 つです」 – SterlingTech Software プレジデント、 ダン・スターリング氏 コンプライアンスの徹底 静的解析は、ソフトウェア開発プロセスの途中でコンプライアンスの証拠を規制 機関に提示し、システムの使用が開始された後に医療機器の問題の根本原因を 発見するのに有効なツールです。規制機関は特定のツールやプロセスを指定し てはいないものの、医療システム用ソフトウェアの開発時に企業がベスト プラク ティスを採用することを想定しています。 開発プロセスで静的解析を利用することによって、医療機器メーカーは実証済 みの正確なツールを用いてコードの検証と妥当性確認を行い、ベスト プラクティ スを実践していることを容易に実証できます。また自動ツールを使うことにより、 開発者は単純なバグ修正に時間をかけずにすみ、コンプライアンスに関する別 の問題（設計仕様への準拠など）にフォーカスすることができます。開発者の 時間を生産的に利用することで、医療機器メーカーはコンプライアンス準拠に まつわるコストの削減を促進することが可能です。 規制機関では、企業がソフトウェア開発時の不具合の発生を防止しようと取り組 んでいることの証拠もあわせて探します。メーカーがソフトウェア コードの記述 後に「品質テスト」を行うことは推奨されていません。静的ソースコード解析技 術によって、開発チームはテストの前にさまざまなタイプの不具合を発見するこ とができ、ソフトウェアが使用意図に合ったものであることを確認することが可 能です。さらには、静的解析ツールを使うことで、より信頼できる高品質なコー ドの開発が可能になることから、最終製品が意図どおりに機能し、適切な規制 に準拠したものとなる可能性が高まります。 生産性の向上 ソフトウェア開発プロセスの早い段階でコードを安定させることで、開発者は 下流工程で次々に報告される問題への対応から解放されます。たとえば、静的 解析を利用することで、ピア レビューアーはバグの修正やコーディング標準へ の準拠といった単純なタスクではなく、重要な設計や要件に集中的に取り組め ることから、ピア レビューの生産性が向上します。ツールを使ったコラボレー ティブなコードレビュー プロセスと静的解析を組み合わせることにより、開発 プロセスにおける検証作業の合理化を図りつつ、信頼性に関する目標を達成 することが可能です。 静的解析は個々の開発者の生産性を高めるだけでなく、医療機器の信頼性の 向上にも貢献します。SCA なしでは発見が不可能なコーディング エラーを排 除し、問題を早期に発見することで、設計段階やフィールドで製品の不具合が 発生するリスクが緩和されます。 SCA には、医療機器の製品化までの時間を短縮する効果も期待できます。 SCA を利用することで開発プロセスの早い段階でバグを排除できることから、 不具合の修正にかかるコストが抑えられ、ソフトウェア エラーが原因の開発の遅延や、FDA をはじめとする規制承認の遅れを 緩和することができます。顧客調査の結果から、 ソフトウェア開発プロセスの標準要素として SCA を組み込んだ場合、 ソフトウェ アのライフサイクルのさまざまな段階で製品品質が一定程度上昇することが分かっています。 また市販の SCA ツールが提供するのは、多くの場合、バグやセキュリティ脆弱性の検出だけに留まりません。コラボレーティ ブなコードレビュー、ソフトウェア メトリクス、コーディング基準、アーキテクチャ解析機能を提供する SCA ベンダーを選べば、 生産性、コンプライアンス、ソフトウェア品質の目標を達成するのに必要なツールの数が少なくてすみます。またこれらのツー ルにはコードの保守と更新が容易に行えるという利点もあります。クリーンなコードによって製品の更新やテストの拡張にかか る時間が短縮されることから、製品のライフサイクル全般で大幅なコスト削減が可能になります。 Effective Software Verification for Medical Devices | Klocwork White Paper | 4 まとめ 医療機器メーカーは競争の激しい市場で事業を展開しており、またより多くの機能と利便性を求めるエンドユーザの需要は高 まる一方です。それに加えて、これらの企業の事業環境には多くの規制が存在します。規制機関は、構造化された品質重視の 開発プロセスのもと医療機器の開発が行われていることの証拠を探そうとします。ソフトウェアの妥当性確認と検証のベスト プ ラクティスに従うことで、コンプライアンスの目標を達成できる確率が高まるだけでなく、開発者の生産性の強化も可能になり ます。 医療機器メーカーが導入できるもっとも重要な検証ツールの 1 つにソース コード解析技術があります。ソース コード解析ツー ルを使えば、コードがテスティング チームに送られる前の開発プロセスの早い段階で、大量のソフトウェア バグやセキュリティ 脆弱性を自動で検出することができます。 Klocwork® は静的ソース コード解析とコラボレーティブ コードレビューのための幅広い製品群を機器メーカーに提供し、正 確でタイムリーなソフトウェア コード検証を可能にします。Klocwork の SCA 製品を使えば、高品質なソースコード解析を開 発者のデスクトップ上に移行し、開発サイクルの最初の段階で解析を実行できることから、規制機関が要求するソフトウェアの 妥当性確認・検証活動をタイムリーかつ生産的な方法で実施することが可能です。 ソフトウェアの検証・妥当性確認に加えて、医療機器メーカーは適切な品質システムのもと製品開発が行われるようにする必 要があります。SterlingTech Software は、製品テスト、品質システムの評価、GMP プロセス バリデーションをはじめとす る、開発サービスや独立型の検証・妥当性確認サービスを医療機器メーカーに向けて提供しています。同社はソフトウェア バリデーション プロセスの基幹技術として Klocwork ツールを利用しています。世界各地の医療機器メーカーが SterlingTech Software にバリデーションを委託することにより、コンプライアンス目標を達成し、規制機関による却下のリスクを緩和してい ます。 Klocwork について Klocwork® はデベロッパーがより安全で信頼性の高いソフトウェアを作成するのに役立ちます。弊社のツールはソースコー ドを オンザフライで解析し、ピアコードレビューを簡素化し、複雑なソフトウェアの寿命を延ばします。モバイル機器、家庭 用電化製品、医療技術、通信、自動車、軍事、航空宇宙部門の最大ブランドを含む 1100 社を超えるカスタマーが、既に Klocwork を自社のソフトウェア開発プロセスの一部に組み込んでいます。数多くのソフトウェア開発者、設計者、そして開発 マネージャーが弊社ツールを日々活用して、生産性を高めると同時によりよいソフトウェアの開発を行っています。詳細に関し ては、www.klocwork.com または info@klocwork.com にて Klocwork までお問い合わせください。 SterlingTech Software について 1998 年創業の SterlingTech Software（STS）は、医療機器業界に特化したフルライフサイクル ソフトウェア開発、テスティ ング、バリデーション サービスを提供する、ISO 13485:2003 公認プロバイダーです。医療機器メーカーの依頼を受け、品質 システム評価や GMP プロセス バリデーションを含む医療ソフトウェア開発プロセスの独立型検証・妥当性確認を行っていま す。これまでに STS では、数々の医療機器プロジェクトで、FDA 510(k)、PMA、CE の申請を成功させてきました。同社はあ らゆる医療機器を対象とした詳細なソフトウェア解析とプロジェクト プランを含む無料のコンサルティングを行っています。お 問い合わせは www.sterlingtechsoftware.com もしくは info@sterlingtechsoftware.com で受け付けています。 HQ & LAB: 17 Legion Place Rochelle Park, NJ 07662 201.227.7569 HOUSTON: 116 Spanish Moss Lake Jackson, TX 77566 713.893.4223 BOSTON: 38 River Ridge Wellesley Hills, MA 02481 WWW.STERLINGTECHSOFTWARE.COM © Copyright SterlingTech Software 2010 · All Rights Reserved 米国： 15 New England Executive Park Burlington, MA 01803 © Klocwork Inc. All rights reserved. カナダ： 30 Edgewater Street, Suite 114 Ottawa, ON K2L 1V t: 1.866.556.2967 f: 613.836.9088 www.klocwork.com
© Copyright 2024 Paperzz
