そもそも，IEC 62304 は医療機器製品のライフサイクルプロセスに適用し，医療機器のソフトウェアに起因する危害（特に患者に対する危害）を医療機器のライフサイクルプロセスを管理することで低減することを目的に作られている。
ライフサイクルプロセス規格といっても，医療機器製品の Intended Use（意図する使用）や使用目的，使用環境が定まっていることを前提にしている。
また，箇条3 によって，医療機器リスクマネジメント規格である ISO 14971 が引用規格になっており，対象となる医療機器のリスク分析が必須となっている。
したがって，何の医療機器に使うのか特定されていない汎用のソフトウェア製品では，どんな医療機器に搭載されるのかが定まっていないため，危害を想定することができない。
その点を頭に入れながら，IEC 62304 の箇条7 を見ていく。
7 ソフトウェアリスクマネジメントプロセス
7.1 危険状態を引き起こすソフトウェアの分析
7.1.1 危険状態の一因となるソフトウェアアイテムの特定
製造業者は，JIS T 14971に規定した医療機器のリスク分析を行い，危険状態及び危険状態を引き起こす可能性のあるソフトウェアアイテムを特定する（4.2参照）。（クラスB，C）
注記 危険状態は，ソフトウェアの故障が直接の原因となる場合，又はソフトウェアに実装したリスクコントロール手段の故障が原因となる場合が考えられる。
→医療機器の Intended Use（意図する使用）や使用環境，医療機器の基本機能，基本性能が定まれば，リスク分析を行うことができ，想定される危害や危険状態を想定することができる。そして，危険状態を引き起こす可能性のあるソフトウェアの障害や，その障害の原因となるソフトウェアアイテムが特定できる。
7.1.2 危険状態の一因となるソフトウェアアイテムの潜在的原因の特定
製造業者は，7.1.1で特定した危険状態の一因となるソフトウェアアイテムの，潜在的原因を特定する。
→医療機器のリスク分析がないと，危険状態の一因が特定できない。そのため，危険状態の一因となるソフトウェアアイテムが特定できない。汎用で重要なソフトウェアなのでソフトウェアアイテムすべてが危険状態の一因となりますとか，潜在的要因はあらゆることを考えていますといったスタンスをとろうとするなら，それは規格の前提条件である「完璧なソフトウェアなどあるはずがない。したがって，その医療機器の使用において想定される危害とリスクを重要度の高いところから優先的に低減する」という概念が理解されていないことになる。
製造業者は，必要に応じて，次に挙げるような潜在的原因を検討する。（クラスB，C）
a) 誤った又は不完全な機能仕様
b) 特定したソフトウェアアイテムの，機能におけるソフトウェア不具合
c) SOUPに起因する，故障又は予期せぬ結果
d) 予測できないソフトウェア動作を引き起こす可能性のある，ハードウェアの故障又は他のソフトウェアの欠陥
e) 合理的に予見可能な誤使用
7.1.3 公開されたSOUP異常リストの評価
SOUPに起因する故障又は予期せぬ結果が，危険状態の一因となるソフトウェアアイテムの潜在的原因になっている場合，製造業者は，当該医療機器に使用しているSOUPアイテムのバージョンに関係する，SOUPアイテムの供給者が公開している異常リストを最低限度として評価し，既知の異常のいずれかによって，危険状態の原因となる可能性がある一連の事象が生じるかを判断する。（クラスB，C）
7.1.4 潜在的原因の文書化
製造業者は，危険状態の一因となるソフトウェアアイテムの潜在的原因を，リスクマネジメントファイルに文書化する（JIS T 14971参照）。（クラスB，C）
→リスクマネジメントファイルは医療機器製造業者が作成するものであるから，汎用のソフトウェア製品の製造業者が「潜在的原因の文書化」をしても意味がない。
7.2 リスクコントロール手段
7.2.1 リスクコントロール手段の選択
製造業者は，リスクマネジメントファイルに文書化した，ソフトウェアアイテムが危険状態の一因となるケースのそれぞれについて，JIS T 14971に従ってリスクコントロール手段を選択し，文書化する。（クラスB，C）
注記 リスクコントロール手段は，ハードウェア，ソフトウェア，動作環境又は取扱説明書において実施できる。
→医療機器と Intended Use（意図する使用）を特定しなければ，危害や危険状態を推定できないため，リスクコントロールしようがない。医療機器によっては，障害が発生したときに，すぐに停止した方がよい場合もあれば，停止せずに最低限の機能で機器を動かし続けなければいけない場合もある。例えば，リスクコントロール手段として，メモリ保護があるとか，エラーが発生したときにリセットがかかるといった一見，何にでも有効そうなリスクコントロール手段は，搭載する機器の Intended Use によってはリスク低減に有効ではないこともある。
7.2.2 ソフトウェアに実装するリスクコントロール手段
リスクコントロール手段をソフトウェアアイテムの機能の一部として実装する場合，製造業者は，次の事項を実施する。（クラスB，C）
a) リスクコントロール手段をソフトウェア要求事項に含める。
b) リスクコントロール手段の実施に寄与する各ソフトウェアアイテムに対して，そのリスクコントロール手段によってコントロールしているリスクに基づいて，ソフトウェア安全クラスの分類を行う（4.3 a）参照）。
c) 箇条5に従ってソフトウェアアイテムを開発する。
注記 この要求事項は，JIS T 14971のリスクコントロールの要求事項を詳細にしたものである。
7.3 リスクコントロール手段の検証
7.3.1 リスクコントロール手段の実施の検証
7.2で文書化したリスクコントロール手段を全て実施していることを検証し，その検証結果を文書化する。製造業者は，リスクコントロール手段をレビューし，それによって新たな危険状態に至ることがないか判断する。（クラスB，C）
7.3.3 トレーサビリティの文書化
製造業者は，次のソフトウェアに関連するハザードのトレーサビリティについて，適宜文書化する。
（クラスB，C）
a) 危険状態からソフトウェアアイテムまで
b) ソフトウェアアイテムから特定のソフトウェアの原因まで
c) ソフトウェアの原因からリスクコントロール手段まで
d) リスクコントロール手段からリスクコントロール手段の検証まで
注記 JIS T 14971参照。
7.4 ソフトウェア変更のリスクマネジメント
7.4.1 医療機器ソフトウェアの安全性に関わる変更の分析
製造業者は，医療機器ソフトウェア（SOUPを含む。）の変更内容を分析して，次を確認する。（クラスA，B，C）
a) 危険状態の一因となる潜在的原因が新たに生じていないか。
b) 新たなソフトウェアリスクコントロール手段が必要でないか。
7.4.2 ソフトウェア変更が既存のリスクコントロール手段に与える影響の分析
製造業者は，ソフトウェアの変更（SOUPの変更を含む。）を分析して，ソフトウェアの修正が既存のリスクコントロール手段の妨げとなる危険性がないかを確定する。（クラスB，C）
7.4.3 分析に基づくリスクマネジメントアクティビティの実行
製造業者は，これらの分析に基づき，7.1，7.2及び7.3で定義した当該リスクマネジメントアクティビティを実行する。（クラスB，C）
→汎用のソフトウェア製品の製造業者は，医療機器の Intended Use を知らないので，ソフトウェアの変更がどのような危険状態の一因となるのか想定ができない。
このように，IEC 62304 の箇条7 を見れば，汎用のソフトウェア製品の開発プロセスに IEC 62304 が適合できない（適合する意味がない）ことが分かる。
0 件のコメント:
コメントを投稿