By：Anil Kumar

医療機器はますます高度になり、ソフトウェア制御のアプリケーションが多用されているが、それらは正確に機能しないと、治療を受けている患者を死にいたらしめたり、大怪我につながる危険性がある。それにも関わらず、医療用ソフトウェア規格は、低リスクアプリケーションに対する厳格さだけを反映しているようにもみえる。

これまで医療機器の欠陥の多くは、製品アップグレードに起因していた。1992年から1998年にかけて米国食品医薬品庁(FDA)が実施した3140件の医療機器リコールの分析によると、その内の242件(全体の7.7%)がソフトウェア障害に起因しているという。またソフトウェアのリコールの内、192件(全体の79%)がソフトウェアのアップグレード後にもたらされたソフトウェアの欠陥によって引き起こされていることが判明している。

今も続く製品アップグレードの管理不能に対し、FDAは最近 Baxter Healthcare 社とその輸液ポンプに対して処罰を課し、リコールを強制した。2010 年4月27日、FDAは Cardiac Science社製の除細動器の欠陥部品についてもユーザに警告を発している。ソフトウェアパッチで問題を改善できなかったため、Cardiac Science社には2万4000台の除細動器の交換が強制され、その結果、Cardiac Science社の株は暴落、1850万米ドルの純損失が計上され、最終的にはOpto Circuits社に買収された。

これらのリコールは、多くの医療機器メーカーに発想の転換をもたらしたている。現在多くの企業が、ソフトウェア処理の改良、および最近ヨーロッパ連合と米国によって承認された医療製品の設計に関する規格 IEC 62304の採用にシフトしてきている。IEC 62304は、クラスAからクラスCまでのリスクに基づいたコンプライアンス構造を導入しており、その内クラスCソフトウェアの欠陥は、死亡または重大な怪我につながる可能性があるもので、医療アプリケーションがそれらのリスク評価に適した規格を満たすことを確約している。この規格は、開発ライフサイクルの各段階の要件について概説すると同時に、信頼性が高く安全なソフトウェア製品を生産することができる方法でソフトウェアが開発されているという確約を提供するために最低限実行されなければならない活動とタスクを定義している。

図1に示すように、IEC 62304 はソフトウェア開発プロセスに重点を置き、ソフトウェア開発と検証活動の多くを定義している。このプロセスには、ソフトウェア開発計画や要件分析、アーキテクチャ設計、ソフトウェア設計、ユニット実装と検証、ソフトウェア統合と統合試験、システムテスト、そして最後にソフトウェアリリースなどの活動が含まれる。

 

規格によると、メーカーは危険な状況とそれらの潜在的原因に寄与する可能性があるソフトウェア製品を識別する必要がある。そしてこれらの潜在的原因は、危険な状況を引き起こす可能性があると判定された一連の出来事を含めたリスク管理ファイルに記録しなければならない。

記録されたそれぞれの潜在的原因について、リスク管理対策を定義して記録する必要がある。IEC 62304は、次にこのリスク管理対策が実施され、検証され、記録されることを要求している。危険な状況とソフトウェア製品、ソフトウェアの原因、リスク管理対策、リスク管理対策の検証の間にトレーサビリティが示されなければならない。このようにリスク管理は、ソフトウェア保守プロセスで大きな役割を果たしている。

当然ながら、IEC 62304は医療機器のソフトウェア開発計画から始まっている。ここで、要求されるタスクは開発中の機器の安全分類に直接関連している。障害時に死亡または重大な怪我を引き起こす可能性がある(レベルC)機器は、より厳格な適合性が課せられ、かつほかのレベルに対して要求されるものより上の活動を含むことが求められる。

ソフトウェア文書		クラスA	クラスB	クラス C
条項	補助条項
ソフトウエア開発計画	5.1.1, 5.1.2, 5.1.3, 5.1.6, 5.1.7, 5.1.8, 5.1.9	X	X	X
	5.1.5, 5.1.10, 5.1.11		X	X
	5.1.4			X
ソフトウェア要件規格	5.2.1, 5.2.2, 5.2.4, 5.2.5, 5.2.6	X	X	X
	5.2.3		X	X
ソフトウェア　アーキテクチャ	5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.6	X	X	X
	5.3.5			X
ソフトウェア詳細設計	5.4.1		X	X
	5.4.2, 5.4.3, 5.4.4			X
ソフトウェア　ユニット実装と検証	5.5.1	X	X	X
	5.5.2, 5.5.3, 5.5.5		X	X
	5.5.4			X
ソフトウェア統合と統合試験	全要件		X	X
ソフトウェア　システム試験	全要件		X	X
ソフトウェア販売	5.8.4	X	X	X
	5.8.1, 5.8.2, 5.8.3, 5.8.5, 5.8.6, 5.8.7, 5.8.8		X	X
ソフトウェア保守プロセス	6.1, 6.2.1, 6.2.2, 6.2.4, 6.2.5	X	X	X
	6.2.3		X	X
ソフトウェア　リスク管理プロセス	7.1, 7.2, 7.3, 7.4.2, 7.4.3		X	X
	7.4.1	X	X	X
図 2: IEC 62304 はソフトウェア開発ライフサイクルに関わるプロセスと活動を定義している。本表はどのソフトウェア安全性クラスにどの要件が割り当てられているかをまとめたものである。クラス A 機器は、ソフトウェア設計の達成に最小限の活動のみを必要とするが、より高リスクのクラス C 機器はすべての活動の実行が要求されている。

表から分かるように、ソフトウェア開発に含まれる活動を決定する際に機器の安全分類が大きな役割を果たす。クラスA機器は、ソフトウェア設計の達成に最小限の活動のみを必要とするが、クラスC機器はすべての活動の実行が要求されている。

すべての医療機器ソフトウェアは、ソフトウェア開発ライフサイクル全体を通して要件管理とトレーサビリティ分析を行う必要がある。何が構築されるのかを定義するため、その医療機器ソフトウェアが許容可能な挙動を示すことを判定するため、そして完成した医療機器ソフトウェアの使用準備が整っていることを示すために、確立された検証可能な要件が不可欠である。

IEC 63204は、要件とソフトウェアシステムテスト間のトレーサビリティを示すことができるような方法で、すべてのソフトウェア要件が特定されることを要求している。また、これによって開発者がリスク管理対策をソフトウェア要件にさかのぼることが可能になる。

要件のトレーサビリティが重要な理由

要件のトレーサビリティは、すべての要件が満たされており、かつすべての開発物が1つ以上の要件にさかのぼることができることを確約する、開発のベストプラクティスとして広く認められている。

従来のソフトウェア開発の視点は、各フェーズがそのフェーズに至る以前のフェーズへフィードバック機能と、構成管理及びプロセス周辺の枠組みと共に、次のフェーズへ流すことを重視していた。つまりトレーサビリティは、フェーズ間の関係の一部であると考えられている。しかしながら、トレースの関係性が記録されるメカニズムについてはほとんど説明されていない。

しかし実際には、個別のフェーズそれぞれが最新のツール技術への投資のおかげで効率的に行われるであろう一方で、これらのツールは開発の各段階間のいかなるトレーサビリティにもほとんど自動的に寄与することはない。その結果、それらの間の関係性はプロジェクトの期間中ますます維持が不十分になる。そして最終的には、要件と実施の間の照合が存在しない、または小手先だけのものとなり、結果的に得られるシステムの不備につながる。

真に自動化されたトレーサビリティを獲得するには、RTM(要件トレーサビリティマトリクス)が必要となる。RTMは各プロジェクトの中心に位置づけられ、またそれは多くの開発規格内の主要な成果物である。

 

図3は、プロジェクトマネージャがどのようにプロジェクト要件をとらえ、それらを形成し、かつ強化要求として一次資料にさかのぼることができるかを示している。開発者はソフトウェアを設計している間、要件を見直す(かつ、あれば事例を使用する)ことができる。試験担当者は、直接自分のテスト管理環境からプロジェクト要件を確認することで、テスト活動に活用することができる。管理者は、プロジェクトの基礎を作成する際に、要件を含めることができる。上層部はプロジェクトの状況に関する「ダッシュボード」ビューを受け取り、進捗に関する情報を一目で取得することができる。

IEC 62304の5.1.1項セクションCは、トレーサビリティがシステム要件、ソフトウェア要件、ソフトウェアシステムテスト、ソフトウェアで実施されるリスク管理対策の間で確立されることを明確に求めている。ここで RTMはソフトウェア開発ライフサイクルの様々な段階をリンクすることにより、大きな役割を果たす。RTMはソフトウェアアーキテクチャに高レベルと低レベルの要件間のトレーサビリティを提供する。また、IEC 62304の5.3.6項に従ったリスク管理に関連するものを含め、設計に要件からの逸脱がないかを確認するためにも役立つ。

RTMはソフトウェアアーキテクチャと、ソフトウェアアーキテクチャがソフトウェアユニットへと精製されるソフトウェアの詳細設計の間にも更なるトレーサビリティを提供する。RTMは、ソフトウェアユニットがソフトウェアアーキテクチャと矛盾しないことを検証するのに役立つ。

コード化は各ソフトウェアユニットが設計要件に従って実装されるユニット実装中に開始される。RTMは、コード検証中に実行される様々な静的検証活動に加え、ソフトウェアユニットと共に実装されるユニットを追跡し、また、検証プランをユニットテスト、統合、システムテストの間に行われる動態分析(ホストまたはターゲットシステムのいずれかで行われる)とマップする。

RTMを使用してプロジェクトマネージャは要件変更の影響(インパクト解析)と、それがどのようにシステムに影響するかを予測することができる。図から分かるように、RTMが開発過程の中心に据えられると、高レベルの要件から目標に基づいた展開まで、設計の全段階に影響を与える。

要件管理とほかのツールの統合で、時間を節約し、やり直しを回避することができる。活動を活性化させて、チームの各役割にエンドユーザのニーズへのダイレクトな窓を提供するために、要件は欠陥追跡、ビジュアル展開、テストツールと統合される。

IEC 62304及び保守性

メーカーの責任は、ソフトウェア製品を発売して完結するものではない。IEC 62304は製品保守にも重点を置いている。

医療機器産業における多くの事例が、不適切なソフトウェア更新及びアップグレードを含む医療機器システムのサービスまたは保守に関連しているため、ソフトウェアの保守プロセスはソフトウェア開発プロセスと同様に重要であると考えられている。 IEC 62304規格は、製品の発売後(つまりソフトウェア保守中)にもたらされる医療機器ソフトウェアの欠陥の高い確率を抑制することを目指している。

健全なソフトウェア保守プロセスは、確固としたソフトウェア開発プロセスと非常に類似しており、問題及び修正分析と修正実施活動が加わる。保守プロセスは、メーカーが組織内とユーザの両方からの発売された製品に対するフィードバックを監視することが必要である。このフィードバックは問題が存在するかどうかを判断するために記録・分析されなければならない。問題が見つかったときは、問題報告書を作成する必要がある。

IEC 62304リスク管理ガイドラインによると、問題報告書では問題がどのように発売された製品の安全性に影響するかを判定し、アップグレードまたはパッチが必要であるかを決定するために評価される。メーカーは、アップグレードまたはパッチが何ら危険のなかったソフトウェアに危険を引き起こしたり、リスクを生み出したりすることがないことを確認する必要もある。

自動化された要件のトレーサビリティを備えた良い RTMによって、メーカーは修正を実施するために既存のソフトウェア開発プロセスを採用することが可能になる。徹底的な回帰分析によって、修正がいかなる新たな危険ももたらさず、既存の機器に組み込まれたリスク管理対策に悪影響を及ぼさないことが確約される。

医療機器の一部として、ソフトウェア保守プロセスは、安全に関する問題報告書に対応し、それを適切な監督機関及び影響を受けるユーザに報告することを保証する必要がある。ソフトウェア製品は、問題の修正と更なる問題の回避を保証する正式な審査で、修正後に再度検証し、再リリースされなければならない。

IEC 62304のように、リスク管理は医療機器向けのソフトウェア開発ライフサイクル全体における不可欠の部分である。安全性リスクに直接寄与するソフトウェア更新に関する特有の問題のため、規格にかかわるプロセスと活動は、ソフトウェア開発計画から、要件管理、アーキテクチャ設計、コード化、検証、そして保守まで、大部分がリスク管理についてのものである。

この規格は ISO 14971に準拠したリスク管理プロセスの使用を要求している。ISO 14971で規定されるリスク管理は、医療機器の使用に関連するリスクの効果的な管理の枠組みを特に扱っている。

結論： IEC 62304の出現によって、医療産業向けのシステム及びソフトウェア開発に関わる企業は、航空宇宙や鉄道分野の企業と同じようなプロセスに取り組むことにならざるをえなくなった。それぞれの企業が現在、厳格な規格への適合性を満たすための取り組みに直面している。

そのような適合性のニーズによって、ビジネスに強制的な進化がもたらされ、要件に関連するプロセスと計画案が記録され、要件が取得され、実施と検証が行われると共に、すべての開発物が構成管理システムで完全に管理されるようになってきている。

医療機器ソフトウェア開発のプロセスとして IEC 62304を採用することは、その規格に規定されたプロセス、活動、タスクに適合することが要求される。メーカーによっては、割り当てられた機器の安全分類は、ソフトウェアの開発に必要とされる取り組みを決定する際に大きな役割を果たす。基本的に、IEC 62304はリスク管理対策に対するトレーサビリティと共に、要件のトレーサビリティがソフトウェア開発プロセスの全段階で満たされることを要求している。

適切で、うまく統合されているツールにより、開発者はより簡単かつ効率的にプロセスを自動化することができるようになる。これには当面のコストと現在の慣行の潜在的変化を伴うが、IEC 62304への適合性はより高い品質を生み出す。安全な製品は高コストのリコールを回避でき、同じ開発プロセスで保守とアップグレードプロセスを支援できるようになる。製造のROIは向上された信頼性と評判で迅速に達成できる。

著者： Anil Kumar は、インド LDRA の技術コンサルタント。ミッションクリティカル及びセイフティクリティカルなシステムの開発、統合、認証を専門としている。開発ツールとリアルタイム操作システムに造詣が深く、リアルタイム組み込みシステムの選択、統合、サポートにおける開発から認証までのオペレーションについての助言をしている。

本記事の初出は2011年1月18日付けEuropean Medical Device Technology。