IEC 62304 に準拠した医療機器ソフトウェアの開発

医療用ソフトウェアの設計に関する国際規格 IEC 62304 が発効された。本記事はIEC 62304が医療機器メーカーのソフトウェア開発プロセスにどのような影響を与えるかについて解説する。

By:Ken Hall KenHall_main

医療機器設計向けの規格

つい最近まで、医療機器ソフトウェア向けの安全規制は、少なくとも正式には、突出して厳しい規制とは言い難かった。またソフトウェアは、欧州の医療機器指令(Medical Devices Directive)に正式に医療製品として分類されていなかった。しかし今は違う。あらゆるクラスの機器向けの全医療機器ソフトウェア開発が準拠しなければならない新たな管理体制が確立されたのである。 以前のソフトウェア安全規格は、ソフトウェアの障害が非常に重大で結果的に死亡につながる可能性がある製品とは対照的に、リスクが低い医療機器に最も適している。より多くの電子製品が組み込みソフトウェアに依存するようになるにつれ、あらゆるレベルの用法における機器と関連リスク範囲内のソフトウェアシステムの信頼性に焦点は移行した。その結果、新しい EN/IEC62304 規格がソフトウェア開発ライフサイクル管理向けのグローバルなベンチマークとして出現したのである(図 1)。

IEC 62304がどのようにコンプライアンス・プロセスに適合するかと、その他の規格との関係。(クリックで拡大)
図1 IEC 62304がどのようにコンプライアンス・プロセスに適合するかと、その他の規格との関係

ハードウェアおよびソフトウェア設計に関するリスク分析

医療製品の設計者は、機器ハードウェアに関連するリスクを軽減するために役立つリスク管理技術を使用していた。BS/EN/ISO14971 は医療機器向けリスク管理の基本規格として従来採用されてきた。この規格の 2007 年版は旧版からかなり拡張されており、現在記載されている技術に関しては、ソフトウェアシステムとハードウェアシステムの両方に適用することが意図されている。 採るべきアプローチは、ソフトウェア/ハードウェアの分割が決定される前に、医療機器によって引き起こされるリスクを全体として検討することである。その後、ソフトウェアリスク分析と併せてハードウェアリスク分析を実行し、機器に対して要求される安全システムを定義することができる。

統一された規格

IEC62304 は欧州連合と米国によって採用された医療品のソフトウェア設計に関する統一規格である。規格が「統一」されているため、それを採用する医療機器メーカーは、ソフトウェア開発に関連する医療機器指令93/42/EEC(MDD)修正 M5(2007/47/EC)に含まれる必須条件を満たす。 これは MDD への準拠性を確約するための最も手間のかからないルートである。また、米国 FDA は医療機器ソフトウェアが許容可能な規格に沿って設計されているという証拠として ANSI/AAMI/IEC 62304:2006 も受け入れる。この規格はすべての重要な細目において EN/ISO 改良版と同じである。 IEC62304 に準拠した設計は、優良なソフトウェアがソフトウェア開発の定義かつ制御されたプロセスによって作り出されることを確約する。このプロセスは開発されているソフトウェアの安全クラスに基づく一連の要件を含む必要がある。

ソフトウェアの安全区分

初めに IEC 62304 規格はメーカーがソフトウェアシステム全体に対して一つの安全区分を割り当てることを見込んでいる。この区分はユーザ、患者、またはその他人々に対して傷害を引き起こす可能性のある危険を生じる可能性に基づいている。 ソフトウェアは次のように 3 つのシンプルなクラスに分類されている。

クラス A: 傷害または健康に対する害がない 
クラス B: 重大でない傷害を引き起こす可能性がある
クラス C: 死亡または重大な傷害を引き起こす可能性がある 

「重大な傷害」、「重大でない傷害」、「健康に対する害」の定義はこの区分を効果的に適用するために重要である。一見傷害とは何か明らかなようであるが、これは機器の状況を考慮したとき、ずっと複雑な問題となり得る。残念ながら規格は「重大な傷害」しか定義しておらず、これは次のとおりである。

重大な傷害 次に直接的または間接的に該当する傷害または疾病 a) 生命を脅かす、 b) 身体機能の永久的な障害または身体構造の永久的な損傷につながる、または c) 身体機能の永久的な障害または身体構造の永久的な損傷を防止するため、医療または外科的介入を必要とする。 注:永久的な障害とは、小さな障害または損傷を除く、身体構造または機能に対する回復不能な障害または損傷を指す。

上述を消極的にして重大でない傷害を導き出すことは比較的単純である。しかし、クラス A ソフトウェア安全区分に使用する傷害の定義は、論議をかもしだす可能性がある。この問題は、傷害または健康に対する害の定義が不足しているために複雑化している。例えば、機器そのものが引き起こす傷害と対照的に、ある疾患の治療の正常な副作用に関する判断しにくい領域があるかもしれない。 これら初期分析を実行し、適用するクラスを定義するための手順が開発されている。一部のケースでは、利用される公認機関がこの決定に影響を与えることがある。医療品に対しては、クラス A 安全性区分は十分に厳格なソフトウェア開発プロセスを主張していないため、クラス B が適用すべき最低限の規格であると推奨するところもある。 クラス A と クラス B コードの間には、費用と時間の面で開発プロセスに大きな違いがある。したがって、医療機器の開発者が最初にこれを知ることが不可欠である。また、安全区分は必要とされる文書とプロセスに対しても大きな影響がある。 

ソフトウェアアイテムおよびユニット

最初の安全区分がシステムに対して実施されると、システムをソフトウェアアイテムとソフトウェアユニットに細分することが可能である。これらは次のように定義される。

・ソフトウェアアイテム:「コンピュータプログラムの識別可能な任意の一部」[ISO/IEC 90003:2004、定義 3.14、修正]
・ソフトウェアユニット:「他のアイテムに細分類できないソフトウェアアイテム」[ISO/IEC 90003:2004、定義 3.28、修正]

ソフトウェアアイテムは、実際には、システムまたはその構成部材の任意のサブセクションとすることができる。ソフトウェアアイテムとソフトウェアユニットを示すアーキテクチャ図が必要である。ソフトウェアシステムのパーツが分離可能な場合、これらの安全区分を格下げすることが可能である。規格の 5.3.5 に関する注釈にこの分離の例が示されている。 「分離の一例は、ソフトウェアアイテムを別のプロセッサで実行することである。分離の有効性はプロセッサ間に共有リソースがないことによって確約することができる。」 実際には、これは安全上重要なソフトウェアシステムが異なるプロセッサ上で実行されるアイテムに分割可能であり、それぞれが異なる安全区分を有することができることを意味する(図 2)。システムが安全で高品質である一方、適切なコストと時間のガイドラインの範囲内で生産されるよう確約するために、最初にこの分割を正しく行うことが重要である。医療製品ソフトウェアアーキテクチャを分析し、これらのアイテムを定義するためのシステムがある。そのようなプロセスは医療機器開発のための時間スケールとコストを大いに削減できる。

 安全上重要なソフトウェアシステムは異なるプロセッサ上で実行される アイテムに分割可能であり、それぞれが異なる安全区分を有することができる。(クリックで拡大)
図2 安全上重要なソフトウェアシステムは異なるプロセッサ上で実行される アイテムに分割可能であり、それぞれが異なる安全区分を有することができる

安全区分の影響

安全区分はコード開発プロセスに対して多大な影響がある。このため、プロジェクトが進行した後に高価で時間のかかるリワークを回避するため、最初にこれを正しく行うことが医療機器メーカーにとって有益である。 表1に文書とプロセスに関する安全区分の影響の概要を示す。実際上、医療機器ソフトウェアを開発している企業は、すべてのソフトウェアクラスに関して検証、組み込み、システム試験を実施する。但し、正式な詳細文書をクラス A コードに対して作成する必要はないことが異なる。要件の相互参照および検証も正式に証明する必要はないのでソフトウェア開発の時間とお金を大幅に節約することができる。

表1 コード開発文書およびプロセスに対する安全区分の影響の概要
ソフトウェア文書 クラス A クラス B クラス C
ソフトウェア開発計画 セクション 5.1 IEC 62304:2006 に従った内容を含む必要がある。計画の内容リストはクラスが上に行くに連れて増加するが、計画は全クラスについて必要である。
ソフトウェア要件規格 5.2 IEC 62304:2006 に従ったソフトウェア要件規格。ソフトウェア要件規格の内容リストはクラスが上に行くに連れて増加するが、文書は全クラスについて必要である。
ソフトウェアアーキテクチャ 不要 5.3 IEC 62304:2006のソフトウェアアーキテクチャ。クラス C のソフトウェアユニットレベルに絞り込み。
ソフトウェア詳細設計 不要   ソフトウェアユニットの文書詳細設計。 (5.4)
ソフトウェアユニット実装 全ユニットが実装され、文書化され、ソース管理されている。 (5.5.1)  
ソフトウェアユニット検証 不要。 プロセス、テスト、検収基準を定義。 (5.5.2, 5.5.3)検証実行 (5.5.5) 追加テストと検収基準を定義。 (5.5.2, 5.5.3, 5.5.4)検証実行 (5.5.5)
ソフトウェア組み込みと組み込みテスト 不要。 5.6 IEC 62304:2006の組み込みテスト。
ソフトウェアシステム・テスト 不要。 5.7 IEC 62304:2006のシステムテスト。
ソフトウェア・リリース リリースされたソフトウェア製品のバージョンを記録 (5.8.4)。 残りのソフトウェアの変則性について、操作者の使用および人的要因を含む安全性または効果に対する影響の説明を注記して一覧に表示する。

SOUP

開発過程が不明なソフトウェア(SOUP)とは、正式な文書がない、または第三者によって開発され、かつ開発過程に対する管理について一切証拠がない、あらゆるコード(ツールまたはソースコード)である。定義上、このコードは障害を発生する可能性があるとみなされる。開発中のソフトウェアに対して提示されるあらゆる SOUP コードに関してソフトウェアリスク分析を実行し、このコードをなぜ使用すべきであるのかについての論理的根拠を形成することが重要である。 SOUP の使用はコード安全区分による影響を受ける。コードがクラス A と見なされる場合、別途正当化する必要なく SOUP コードを使用することができる。クラスが上がるにつれリスクが高まり、論理的根拠も正当化することがより困難になる。実際上、これは単純な機能で、よく知られており、幅広く適用されている SOUP コードのみがクラス C 用途に使用可能であることを意味する。 電子設計および生産サービスを専門とする技術ソリューションの提供者は、医療機器ソフトウェアにおける SOUP の使用を識別し、正当化するプロセスを開発している。そのようなプロセスは開発の時間スケールとコストを大幅に削減できることが自身の経験で証明されている。これは医療機器開発者がその設計手順に取り入れるべき方法である。

終わりに

IEC62304 は医療機器向けの安全上重要で信頼性の高いソフトウェアの開発に関する、よく検討された論理的な規格である。現在この規格が採用されたため、事実上この規格に従わずに、医療機器ソフトウェア開発者が MDD の要件を満たす任意の同等のアプローチを正当化することは非常に困難になる。これは規格がより公平な場を確立するため、患者の安全のため、そしてメーカー自身のためにも朗報である。管理されていない初歩的なソフトウェア開発プロセスの機会はもはや無くなり、全面的に品質を高められる。 加えて、IEC62304 は国際的に採用された統一規格であり、欧州と米国間の品質に対する要求を等しくする傾向がある。 しっかりと確立されたリスク管理システムを有するソフトウェア設計者は IEC62304 を満たすための基礎が既にあるため、医療機器メーカーにとってそのような設計者を選ぶことが重要である。さらに、私自身も専門家としての経験が、医療製品ソフトウェアのアーキテクチャと使用を分析する際にプロセスがどれほど貴重であり得るかを身をもって体験してきた。今回述べたようなプロセスは、医療機器開発のための時間スケールとコストを大いに削減できる。

著者紹介:Ken Hall, Technical Director, Triteq Ltd, 
3 The Courtyard, Stype, Hungerford, Berkshire RG17 0RE, UK +44 1488 684 554
ken.hall@triteq.com www.triteq.com 

※ 本記事は、European Medical Device Technology 2010 年 6 月号に英語で掲載されました。

カテゴリー: