医療機器ソフトウェア：#6　JIS T 2304（IEC 62304）の一般要求事項

こんにちは、西です。
JIS T 2304（IEC 62304）について、前回までは序文を読み解きながら概要を確認してきましたが、今回からいよいよ要求事項の中身について見ていきます。

ソフトウェア安全クラス

要求事項の記載は４章「一般要求事項」から始まります。
４章は最初に前々回の記事で触れたQMSとリスクマネジメントプロセスに関する記載がありますが、それに続いて「ソフトウェア安全クラス」に関する以下の記載があります。

4.3 *ソフトウェア安全クラス分類
a)製造業者は，ソフトウェアシステムに起因する危険状態が，最悪の場合に患者，操作者，又はその他の人にもたらす危害のリスクに応じて，図 3 に示すように，各ソフトウェアシステムをソフトウェア安全クラス（A，B 又は C）に分類する。

なお「リスク」の定義は

3.16
リスク（RISK）
　危害の発生確率とその危害の重大さとの組合せ。

ですので、ここで要求されているのは
ソフトウェアに起因する危険状態（人がハザード（危害の潜在的な源）にさらされる状況）が、最悪の場合に患者等の人に与える危害（身体的傷害・健康障害）について、
その発生確率と（もし発生してしまった場合の）重大さを掛け合わせた「リスク」の大小に応じて、ソフトウェアを「ソフトウェア安全クラス」というクラス（A/B/Cのいずれか）に分類せよ、ということです。
どのソフトウェア安全クラスに分類されるかによって、５章以降の各プロセスの要求事項の対応要否が変わってきます。
最もリスクの大きいソフトウェアはクラスCに分類され、対応すべき要求事項が最も多くなります。
分類の仕方は以下の通りです。

出典：じほう社（2016年）「IEC 62304　実践ガイドブック」p.74に掲載されている図をもとに筆者が作成

続いて、ソフトウェア安全クラスの定義の記載（上図の内容と同じため割愛）の後に、以下の記載が続きます。

当初，ソフトウェア安全クラスを B 又は C に分類したソフトウェアシステムについて，製造業者は，そのソフトウェアシステム以外（external to）で実施するリスクコントロール手段（そのソフトウェアシステムが含まれるシステムアーキテクチャの改善など）を追加で実施して，そのソフトウェアシステムを新しいソフトウェア安全クラスに分類することができる。
注記 1 そのソフトウェアシステム以外で実施するリスクコントロール手段は，ソフトウェアが危険状態の一因となる可能性を最小限に抑えるために，ハードウェア，独立したソフトウェアシステム，医療処置又は他の手段とすることができる。

そのソフトウェア以外で実施するリスクコントロール手段を追加で実施することにより、よりリスクの少ない（＝対応すべき要求事項が少ない）クラスとして再分類することができると書かれています。（C→B、B→A等）

なお上図を見ると、リスクの受容可能性がクラスAとB/Cの分岐点になっていますが、これについても４章に説明があります。

注記 2 リスクの受容可能性の定義は，JIS T 14971:2012 の 3.2（経営者の責任）を参照する。

JIS T 14971:2012を見ると以下の記載があります。

トップマネジメントは，次を実施する。
− リスクの受容可能性についての判断基準を決定するための方針を明確化し，文書化する。判断基準が適用できる国又は地域の規制及び関連のある国際規格に基づいており，かつ，一般的に受け入れられている最新の状況及び既知である利害関係者の懸念など，利用可能な情報を考慮に入れていることを，この方針によって確実にする。

つまり、リスクを受容可能かどうかはトップマネジメントが文書で定めた方針によって決められた判断基準に従って各製造業者で判断するものであり、標準的な判断基準があるものではないということです。

今回は以上です。
どのソフトウェア安全クラスに分類されるかによって医療機器ソフトウェア開発・保守に必要な作業工数が変わってくるため、プロジェクト計画立案等する場合はできるだけ早いタイミングで分類することをおすすめします。