こんにちは、イーソル エンジニアリング本部 Medical課のY.Sです。
イーソルは医療機器や顕微鏡・研究向け製品をはじめとした医療・科学分野のエンジニアリングサービスを提供しており、Medical課は医療系のソフトウェア開発に携わっています。
このブログシリーズでは、イーソルで定期的に開催しているIEC 62304理解のための社内勉強会で得た見識について紹介しています。
第1回では、IEC 62304とは何か、また規格について基本的な知識や読み方について紹介しました。第2回では、IEC 62304の基礎となるソフトウェア安全クラス分類、また医療機器ソフトウェアのリスクマネジメントプロセスについて取り上げます。
| 目次 1. ソフトウェア安全クラス分類とは？ 2. リスクマネジメントプロセス ・医療機器のリスクマネジメントプロセス ・医療機器ソフトウェアのリスクマネジメントプロセス ・危険状態を引き起こすソフトウェアの分析 ・リスクコントロール手段 ・リスクコントロール手段の検証 ・ソフトウェア変更時のリスクマネジメント 3. 最後に |
1. ソフトウェア安全クラス分類とは？
IEC 62304ではソフトウェア安全クラス分類というものが定義されています。
この分類は、薬機法で定められている医療機器そのもののクラス分類(クラスⅠ、Ⅱ、Ⅲ)とは別のものです。医療機器ソフトウェアシステムは、それが起因となって危害を与えるリスクの低い順に、クラスA、B、Cと分類されます。
適用されるソフトウェア開発プロセスは、ソフトウェア安全クラスにより決定されます。そのため、最初にソフトウェア安全クラス分類を行う必要があります。
|
ソフトウェア安全クラス分類 |
説明 |
| クラスA | 当該SWが危険状態 (人身に対する傷害・健康障害、財産・環境への害) の原因とならない、または、受容不能なリスクを生じない。 |
| クラスB | 死亡または重傷 (生命の危険、永久的障害、永久的障害回避のために 内科的/外科的な処置を必要とする障害) の可能性なし。 |
| クラスC | 死亡または重傷の可能性あり。 |
表1 ソフトウェア安全クラス
JIS T2304:2017「4.3 ソフトウェア安全クラス分類」より引用
身体に直接影響を及ぼすような医療機器でなくとも、その使われ方が最終的に医療関係者だけではなく、患者やその周囲の方々に及ぼす影響まで含めリスクを分析した上で、クラス分類することが重要です。
例えば、病気の診断・検査に用いる医療機器が故障した場合、誤診により患者に危害を与えるリスクがあります。
ソフトウェアシステムは1つのソフトウェア安全クラスに分類されますが、以下の図 のように、ソフトウェアシステムの中でもリスクの低いソフトウェアアイテムに関しては、分割の根拠を示し切り出すことで、下位のソフトウェア安全クラスに分類することが可能です(※)。
課員が経験したプロジェクトの中で、内視鏡のシステムを例にとると、 患者の体内に入る内視鏡の光源のソフトウェアはクラスC、それ以外のリスクの低いソフトウェアはクラスBと使い分けている例がありました。
図1 下位のソフトウェアアイテムの安全クラス分類例
(※)用語
- ソフトウェアアイテム：コンピュータプログラムの識別可能な部分
- ソフトウェアシステム：複数のソフトウェアアイテムを結合した集合体
- ソフトウェアユニット：他のアイテムに分割できないソフトウェアアイテム
2. リスクマネジメントプロセス
・医療機器のリスクマネジメントプロセス医療機器ソフトウェアのリスクマネジメントプロセスを行う上で、まずISO 14971(対応するJIS規格：JIS T14971)で定義されている医療機器のリスクマネジメントプロセスについて知る必要があります。
リスクマネジメントプロセスは、リスクを分析・評価し、リスクコントロール手段を通じてリスクを受容可能なレベルまで下げる活動です。
規格ではリスクの受容可能なレベルの判断基準を規定していないため、製造業者の中で基準を確立する必要があります。
リスクマネジメントは医療機器の開発時だけでなく、製造後も継続します。ユーザーからの情報や最新の技術情報を収集し、必要に応じて処置を行います。例えばユーザーからの苦情およびそれに対する対応、サードパーティーからのバグレポートに対する対処の決定を含みます。
・医療機器ソフトウェアのリスクマネジメントプロセス
医療機器ソフトウェアのリスクマネジメントプロセスは、ISO 14971を基にして、IEC 62304に規定されています。このプロセスはソフトウェアに特化した内容となっており、クラスB、Cで必要です。
医療機器ソフトウェアのリスクマネジメントプロセスを以下に示します。
図 2 リスクマネジメントプロセス
・危険状態を引き起こすソフトウェアの分析
危険状態の一因となるソフトウェアアイテム及び、その潜在的原因を特定します。以下のような潜在的原因を検討する必要があります。
| 危険状態の一因となるソフトウェアアイテムの潜在的原因 | |
| a) | 誤ったまたは不完全な機能仕様 |
| b) | 特定したソフトウェアアイテムの、機能におけるソフトウェア不具合 |
| c) | SOUPに起因する、故障又は予期せぬ結果 |
| d) | 予測できないソフトウェア動作を引き起こす可能性のある、ハードウェアの故障又は他のソフトウェアの欠陥 |
| e) | 合理的に予見可能な誤使用 |
表2 危険状態の一因となるソフトウェアアイテムの潜在的原因
JIS T2304:2017「7.1.2 危険状態の一因となるソフトウェアアイテムの潜在的原因の特定」より引用
リスク分析には、危害の重大性と危害の発生確率の分析を含み、以下の式で表されます。
(リスク)=(危害の重大性)×(危害の発生確率)
ソフトウェアが起因となる危害の場合、危害の発生確率を推定することが難しいため、最悪の場合を想定し、発生確率を1とすることが推奨されています。
ソフトウェアアーキテクチャの設計時、ソフトウェアに実装するリスクコントロール手段を考慮して設計する必要がありますが、設計が完了するまでは各ソフトウェアアイテムの責務は完全には明らかになっておらず、この時点で全ての危険状態を確定することは困難です。
そのため、アーキテクチャの設計が完了した時点で再度リスク分析を行うのが望ましいとされています。
・リスクコントロール手段
ソフトウェアアイテムが危険状態の一因となる各ケースについて、リスクコントロール手段を選択します。
選択したリスクコントロール手段はソフトウェア要求事項に含めます。また、関連するソフトウェアアイテムのソフトウェア安全クラスを判定します。
・リスクコントロール手段の検証
リスクコントロール手段をすべて実施していることを検証します。
また、リスクコントロール手段を実施することによって新たな危険状態が発生しないかを判断します。
・ソフトウェア変更時のリスクマネジメント
バグ修正や仕様変更などによりソフトウェアを変更する場合、その変更によって新たな危険状態が発生しないか、新たなリスクコントロール手段が必要でないかを分析します。また、既存リスクコントロール手段の妨げとなる危険性がないかを分析します。
例えば、システム試験の中でバグを発見し、その修正を行う場合、以下の内容を検討する必要があります。
- V字開発プロセスのどの時点でバグの混入が発生したか
- バグ修正のために実施すべき V字開発プロセスはどれか
- バグ修正の影響を受けるソフトウェアアイテムがどれか
3. 最後に
いかがでしたでしょうか。
今回学んだリスクマネジメントプロセスは、医療機器ソフトウェアが起因となる事故の発生を防止するために非常に重要なプロセスです。
次回は、IEC 62304で必要となる開発プロセスについて紹介します。
また冒頭でご紹介した通り、イーソルは医療分野のエンジニアリングサービスを提供しており、豊富な実績があります。医療分野のみならず、車載・産業などの幅広い領域における開発実績で身に着けた安全性の高い開発プロセスなどの知見や技術力は、お客様の求めるお客様が目指す高性能で高品質な開発を強力に支援します。
医療分野の製品開発で課題がある、IEC 62304をはじめとした規格に準拠した開発を実施したい、エンジニアリングサービスについて詳しく知りたい、という方はぜひお気軽にイーソルにご相談ください。
Medical課 Y.S
参考：
・JIS T2304:2017 / 医療機器ソフトウェア－ソフトウェアライフサイクルプロセス
