JIS T 2304:2017 医療機器ソフトウェア―ソフトウェアライフサイクルプロセス | ページ 7

28
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)

9.7 ソフトウェア問題解決の検証

  製造業者は,問題の解決を検証し,次の事項を判断する(クラスA,B,C)。
a) 問題を解決し,問題報告を完了した。
b) 好ましくない傾向を改善した。
c) 変更要求を,適切な医療機器ソフトウェア及びアクティビティに実装した。
d) 新たな問題が発生していない。

9.8 試験文書の内容

  製造業者は,変更の後に実施する,ソフトウェアアイテム及びシステムの試験,再試験又は回帰テスト
に当たって,試験文書の中に次を含める(クラスA,B,C)。
a) 試験結果
b) 発見した異常
c) 試験したソフトウェアのバージョン
d) 関連するハードウェア及びソフトウェアテスト構成
e) 関連試験ツール
f)  試験実施日
g) 試験者の識別

――――― [JIS T 2304 pdf 31] ―――――

                                                                                             29
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
                                          附属書A
                                          (参考)
                               この規格の要求事項の根拠
  この規格の各箇条の根拠を,この附属書に記載する。
A.1 根拠
  この規格が第一に求めているのは,医療機器ソフトウェアの開発及び保守が,一連のプロセスに従うと
ともに,患者及びその他の人へのリスクに対して適切なプロセスを選択することである。これは,ソフト
ウェアの試験を実施しただけでは,その使用が安全であると判断するには十分ではないという信念に基づ
いている。
  この規格が要求するプロセスは,次の2種類のカテゴリに分類できる。
− ソフトウェアの各ソフトウェアアイテムの動作に起因するリスクを評価するために必要となるプロセ
    ス
− 評価したリスクに基づいて選択される,各ソフトウェアアイテムにソフトウェアの故障が発生する確
    率を低い水準に抑えるために必要となるプロセス
  この規格は,最初のカテゴリは全ての医療機器ソフトウェアに対して実施し,2番目のカテゴリは選択
したソフトウェアアイテムに対して実施することを要求している。
  したがって,この規格への適合性を示す場合は,ソフトウェアを含む危険状態を引き起こす可能性のあ
る,予見可能な一連の事象の特定を行うリスク分析を文書化して盛り込むことが望ましい(JIS T 14971参
照)。ソフトウェアに起因する危険状態(例えば,不適切な治療行為につながる可能性のある,誤解を招
く情報の提供に起因する危険状態)も,このリスク分析に記載するのがよい。
  プロセスの最初のカテゴリの一部として要求する全てのアクティビティは,本文では“(クラスA,B,
C)”と記載し,ソフトウェアの分類に関係なく必要であることを示している。
  次の場合,アクティビティをクラスA,B,Cのいずれにも要求している。
− アクティビティが,リスクマネジメント又はソフトウェア安全クラス分類に関係する計画を策定する。
− アクティビティのアウトプットが,リスクマネジメント又はソフトウェア安全クラス分類のインプッ
    トとなる。
− アクティビティが,リスクマネジメント又はソフトウェア安全クラス分類の一部である。
− アクティビティが,管理システム,文書化システム又は記録管理システムを確立して,リスクマネジ
    メント又はソフトウェア安全クラス分類を支援する。
− アクティビティは,関係するソフトウェアのクラス分類が不明なときに通常実施する。
− アクティビティが,関連するソフトウェアの現在のソフトウェア安全クラス分類を無効にするような
    変更をもたらす。これには,リリース後の安全性に関わる問題の検出及び分析が含まれる。
  その他のプロセスは,ソフトウェア安全クラスB又はCに分類されるソフトウェアシステム又はソフト
ウェアアイテムだけに要求している。これらのプロセスの一部として要求するアクティビティは,本文で
は“(クラスB,C)”又は“(クラスC)”と記載し,適用されるソフトウェアのクラス分類に応じて選択的
に要求することを示している。
  次の場合,アクティビティは,クラスB及びCのソフトウェアに選択的に要求される。

――――― [JIS T 2304 pdf 32] ―――――

30
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
− アクティビティが,設計,試験又はその他の検証を,より詳細に又はより厳密にすることを要求し,
    ソフトウェアの信頼性を高める。
− アクティビティが,クラスB又はCに要求される別のアクティビティを支援する管理アクティビティ
    である。
− アクティビティが,安全性に関わる問題の是正を支援する。
− アクティビティが,安全性に関わるソフトウェアの設計,実装,検証及びリリースの記録を作成する。
  次の場合,アクティビティは,クラスCのソフトウェアに選択的に要求される。
− アクティビティが,設計,試験又はその他の検証を,より詳細に又はより厳密にすること若しくは特
    定の問題点に注意を払うことを要求し,ソフトウェアの信頼性を更に高める。
  なお,この規格で定義している全てのプロセス及びアクティビティは,高品質ソフトウェアの開発及び
保守を確実に行うために有益なものとみなされていることに留意する。クラスAのソフトウェアの要求事
項に,これらのプロセス及びアクティビティの多くが含まれていないが,それらに価値がない,又はそれ
らを推奨しないということを意味するものではない。危険状態1) の発生の可能性がないソフトウェアの場
合,主には医療機器の設計中に行う総合的な妥当性確認アクティビティによって,又はソフトウェアライ
フサイクルの管理項目の幾つかを単純に実施することで,その安全性及び有効性が保証できるということ
を考慮した結果,これらのアクティビティを省略している(医療機器全体の妥当性確認は,この規格の適
用範囲外である。)。
    注記 注1) は,序文の注1) を参照。
A.2 ソフトウェア安全クラス別要求事項のまとめ
  表A.1は,個々の要求事項がどのソフトウェア安全クラスを指定しているかをまとめている。
  この表は,参考であり,便宜上示すにとどめる。個々の要求事項のためのソフトウェア安全クラスは,
本文で規定している。

――――― [JIS T 2304 pdf 33] ―――――

                                                                                             31
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
                        表A.1−ソフトウェア安全クラス別要求事項のまとめ
                         箇条及び細分箇条            クラスA   クラスB   クラスC
              箇条4    全ての要求事項                   ○        ○        ○
              5.1      5.1.15.1.3,5.1.65.1.9           ○        ○        ○
                       5.1.5,5.1.105.1.12              −        ○        ○
                       5.1.4                            −        −        ○
              5.2      5.2.1,5.2.2,5.2.45.2.6         ○        ○        ○
                       5.2.3                            −        ○        ○
              5.3      5.3.15.3.4,5.3.6                −        ○        ○
                       5.3.5                            −        −        ○
              5.4      5.4.1                            −        ○        ○
                       5.4.25.4.4                       −        −        ○
              5.5      5.5.1                            ○        ○        ○
                       5.5.2,5.5.3,5.5.5              −        ○        ○
                       5.5.4                            −        −        ○
              5.6      全ての要求事項                   −        ○        ○
              5.7      全ての要求事項                   ○        ○        ○
              5.8      5.8.1,5.8.2,5.8.4,5.8.7,5.8.8○        ○        ○
                       5.8.3,5.8.5,5.8.6              −        ○        ○
              箇条6    全ての要求事項                   ○        ○        ○
              7.1      全ての要求事項                   −        ○        ○
              7.2      全ての要求事項                   −        ○        ○
              7.3      全ての要求事項                   −        ○        ○
              7.4      7.4.1                            ○        ○        ○
                       7.4.2,7.4.3                     −        ○        ○
              箇条8    全ての要求事項                   ○        ○        ○
              箇条9    全ての要求事項                   ○        ○        ○
                                                                      ○ : 該当する
                                                                    − : 該当しない

――――― [JIS T 2304 pdf 34] ―――――

32
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
                                          附属書B
                                          (参考)
                            この規格の適用についての指針
B.1   適用範囲
B.1.1 目的
  この規格は,高品質で安全な医療機器ソフトウェアを,常に製造する開発プロセスを示すことを目的と
している。この目的を達成するために,この規格では,信頼性の高い安全なソフトウェアを生産できる方
法でソフトウェア開発が行われたということを確実にするために,最低限実施すべきアクティビティ及び
タスクを特定している。
  この附属書は,この規格の要求事項の適用についての指針を記載したものであり,この規格の要求事項
に追加又は変更を加えるものではない。この附属書は,規格の要求事項をより明確に理解する目的で使用
できる。
  ここで注意することは,この規格において,アクティビティは,プロセスの中で定義している細分箇条
であり,タスクは,アクティビティの範囲内で定義している。例えば,ソフトウェア開発プロセスで定義
しているアクティビティは,ソフトウェア開発計画,ソフトウェア要求事項分析,ソフトウェアアーキテ
クチャ設計,ソフトウェア詳細設計,ソフトウェアユニットの実装及び検証,ソフトウェア結合及び結合
試験,ソフトウェアシステム試験並びにソフトウェアリリースである。これらのアクティビティに含まれ
るタスクは,個別の要求事項である。
  この規格は,特定のソフトウェア開発ライフサイクルモデルを要求するものではない。しかし,あるプ
ロセスへのインプットは,別のプロセスによって生じるため,この規格に適合することは,プロセス間の
依存性があるということを意味する。例えば,ソフトウェアシステムの故障からどんな危害が生じるかを
リスク分析プロセスで確立した後に,ソフトウェアシステムのソフトウェア安全クラス分類を完了するこ
とが望ましい。
  このようにプロセス間に論理的依存性があるため,この規格のプロセスは,“ウォータフォール”又は
“ワンススルー(once-through)”ライフサイクルモデルを示唆するシーケンスで説明するのが最も容易で
ある。しかし,他のライフサイクルモデルも使用可能である。JIS X 0160 [7]で定義している開発モデルに
は,次のようなものがある(表B.1も参照)。
− ウォータフォール : “ウォータフォール”ともいわれる“ワンススルー(once-through)”モデルでは,
    開発プロセスを一度実施する。簡単にいえば,顧客ニーズの決定,要求事項の定義,システムの設計,
    システムの実装,試験,修理及び出荷から成るモデルである。
− 繰返し(Incremental) : “繰返し”モデルでは,顧客ニーズの決定及びシステム要求事項の定義付けを
    行い,その後,残りの開発を一連の版(build)ごとに行う。計画した仕様の一部を最初の版(build)
    で組み込み,次の版(build)で更に仕様を追加し,システム完成に至るまでこれを続ける。
− 進展的(Evolutionary) : “進展的”モデルもまた,版(build)でのシステム開発であるが,ユーザの要
    求が完全には理解されておらず,全ての要求事項を前もって定義することが不可能であるとの認識が
    ある点で,繰返しモデルとは異なる。このモデルでは,顧客ニーズ及びシステム要求事項の定義を前
    もって部分的に行い,次の版(build)で改良(refine)する。

――――― [JIS T 2304 pdf 35] ―――――

次のページ PDF 36