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

                                                                                             23
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
c) ソフトウェアリスクマネジメントプロセスの使用
d) 医療機器ソフトウェアのリリース後に発生した問題を分析及び解決するためのソフトウェア問題解決
    プロセスの使用
e) 既存ソフトウェアシステムの修正を管理するための,ソフトウェア構成管理プロセス(箇条8参照)
    の使用
f)  SOUPについて,次の事項を評価し実行する手順
  − アップグレード
  − バグ修正
  − パッチ
  − 陳腐化の確認

6.2 *問題及び修正の分析

6.2.1  フィードバックの文書化及び評価
6.2.1.1  フィードバックの監視
  製造業者は,意図する使用のためにリリースした医療機器ソフトウェアについてのフィードバックを監
視する(クラスA,B,C)。
6.2.1.2  フィードバックの文書化及び評価
  フィードバックを文書化するとともにそれを評価し,リリースした医療機器ソフトウェアに問題がない
かを判断する。問題があった場合は,問題報告として記録する(箇条9参照)。問題報告には,実際に悪
影響を及ぼす又はその可能性のある事象,及び仕様から逸脱した事象を含める(クラスA,B,C)。
6.2.1.3  安全性に影響する問題報告の評価
  問題報告は,個々に評価を実施し,意図する使用のためにリリースした医療機器ソフトウェアの安全性
にどのような影響があるかを判断するとともに(9.2参照),問題に対処するためにそのソフトウェアに変
更を加える必要があるかを判断する(クラスA,B,C)。
6.2.2  ソフトウェア問題解決プロセスの使用
  製造業者は,問題報告の対処に当たり,ソフトウェア問題解決プロセス(箇条9参照)を使用する(ク
ラスA,B,C)。
    注記 問題を調べると,ソフトウェアシステム又はソフトウェアアイテムが,正しいソフトウェア安
          全クラスに分類されていないことが分かることがある。問題解決プロセスでは,ソフトウェア
          安全クラスの変更が示唆されることがある。その場合は,プロセスが完了した時点で,ソフト
          ウェアシステム又はそのソフトウェアアイテムの安全クラスの変更を明らかにし,文書化して
          いることが望ましい。
6.2.3  変更要求の分析
  製造業者は,箇条9で要求している分析を実施するほか,各変更要求が,組織,意図する使用のために
リリースした医療機器ソフトウェア及び連携するシステムに及ぼす影響について分析を行う(クラスA,
B,C)。
6.2.4  変更要求の承認
  製造業者は,リリースした医療機器ソフトウェアに修正が生じる変更要求を評価し,承認する(クラス
A,B,C)。
6.2.5  ユーザ及び規制当局への通知
  製造業者は,リリースした医療機器ソフトウェアに影響がある,承認済みの変更要求を明らかにする。

――――― [JIS T 2304 pdf 26] ―――――

24
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
  地域の法令の要求に応じて,製造業者は,ユーザ及び規制当局に対して次の事項を通知する(クラスA,
B,C)。
a) リリースした医療機器ソフトウェアについての全ての問題及び変更せずに継続使用した場合の結果。
b) リリースした医療機器ソフトウェアに対して利用可能な変更の本質(nature),並びにそれらの変更の
    入手及びインストールの方法。

6.3 *修正の実装

6.3.1  確立したプロセスを使用した修正の実装
  製造業者は,修正を行った結果,再度実施する必要性がある箇条5のアクティビティを特定し,実施す
る(クラスA,B,C)。
    注記 ソフトウェア変更のリスクマネジメントに関わる要求事項については,7.4参照。
6.3.2  修正ソフトウェアシステムの再リリース
  製造業者は,5.8に従って,作成した修正版をリリースする(クラスA,B,C)。
    注記 修正版は,ソフトウェアシステムの完全再リリース版の一部としてリリースすることもできる
          し,変更したソフトウェアアイテム及び修正版の変更内容を既存のソフトウェアシステムにイ
          ンストールするために必要なツールから成る修正キットとしてリリースすることもできる。

7 *ソフトウェアリスクマネジメントプロセス

7.1 *危険状態を引き起こすソフトウェアの分析

7.1.1  危険状態の一因となるソフトウェアアイテムの特定
  製造業者は,JIS T 14971に規定した医療機器のリスク分析を行い,危険状態及び危険状態を引き起こす
可能性のあるソフトウェアアイテムを特定する(4.2参照)(クラスB,C)。
    注記 危険状態は,ソフトウェアの故障が直接の原因となる場合,又はソフトウェアに実装したリス
          クコントロール手段の故障が原因となる場合が考えられる。
7.1.2  危険状態の一因となるソフトウェアアイテムの潜在的原因の特定
  製造業者は,7.1.1で特定した危険状態の一因となるソフトウェアアイテムの,潜在的原因を特定する。
  製造業者は,必要に応じて,次に挙げるような潜在的原因を検討する(クラスB,C)。
a) 誤った又は不完全な機能仕様
b) 特定したソフトウェアアイテムの,機能におけるソフトウェア不具合
c)   OUPに起因する,故障又は予期せぬ結果
d) 予測できないソフトウェア動作を引き起こす可能性のある,ハードウェアの故障又は他のソフトウェ
    アの欠陥
e) 合理的に予見可能な誤使用
7.1.3  公開されたSOUP異常リストの評価
  SOUPに起因する故障又は予期せぬ結果が,危険状態の一因となるソフトウェアアイテムの潜在的原因
になっている場合,製造業者は,当該医療機器に使用しているSOUPアイテムのバージョンに関係する,
SOUPアイテムの供給者が公開している異常リストを最低限度として評価し,既知の異常のいずれかによ
って,危険状態の原因となる可能性がある一連の事象が生じるかを判断する(クラスB,C)。
7.1.4  潜在的原因の文書化
  製造業者は,危険状態の一因となるソフトウェアアイテムの潜在的原因を,リスクマネジメントファイ
ルに文書化する(JIS T 14971参照)(クラスB,C)。

――――― [JIS T 2304 pdf 27] ―――――

                                                                                             25
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
7.1.5  (対応国際規格で削除されている。)

7.2 リスクコントロール手段

7.2.1  リスクコントロール手段の選択
  製造業者は,リスクマネジメントファイルに文書化した,ソフトウェアアイテムが危険状態の一因とな
るケースのそれぞれについて,JIS T 14971に従ってリスクコントロール手段を選択し,文書化する(クラ
スB,C)。
    注記 リスクコントロール手段は,ハードウェア,ソフトウェア若しくは動作環境において実施する
          か,又は取扱説明書への記載による。
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.2  (対応国際規格で削除されている。)
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)。

――――― [JIS T 2304 pdf 28] ―――――

26
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
7.4.3  分析に基づくリスクマネジメントアクティビティの実行
  製造業者は,これらの分析に基づき,7.17.3で規定した当該リスクマネジメントアクティビティを実
行する(クラスB,C)。

8 *ソフトウェア構成管理プロセス

8.1 *構成識別

8.1.1  構成アイテム識別手段の確立
  製造業者は,5.1に規定した開発及び構成管理計画に従って管理することが望ましい構成アイテム及び
そのバージョンを,一意に識別するための仕組みを確立する(クラスA,B,C)。
8.1.2  SOUPの特定
  現在使用中のSOUP構成アイテム(標準ライブラリを含む。)のそれぞれについて,製造業者は,次を
文書化する(クラスA,B,C)。
a) 名称
b) 製造業者
c)   OUPを特定する識別子
    注記 SOUPを特定する識別子の例として,バージョン,リリース年月日,パッチ番号,アップグレ
          ードの識別子などが考えられる。
8.1.3  システム構成文書の特定
  製造業者は,ソフトウェアシステムの構成要素である構成アイテム及びそのバージョン一式を文書化す
る(クラスA,B,C)。

8.2 *変更管理

8.2.1  変更要求の承認
  製造業者は,承認した変更要求に応じる場合に限り,8.1に従って識別する構成アイテムを変更する(ク
ラスA,B,C)。
    注記1 変更要求承認の決定が,変更管理プロセス又は他のプロセスの一部に不可欠となる場合があ
            る。この細分箇条が要求するのは,変更の実装の前に変更の承認が必要ということだけであ
            る。
    注記2 ライフサイクルの様々な段階で受け取る変更要求に対して,様々な受入れプロセスを使用で
            きる[5.1.1 d)及び6.1 e)参照]。
8.2.2  変更の実装
  製造業者は,変更要求で指定されているとおりに変更を実装する。製造業者は,変更の結果やり直しが
必要な全てのアクティビティ(ソフトウェアシステム及びソフトウェアアイテムのソフトウェア安全クラ
ス分類の変更を含む。)を特定し,実装する(クラスA,B,C)。
    注記 この細分箇条では,十分な変更管理を達成するために,どのように変更を実装するのが望まし
          いかということを明記している。これは,変更の実装が,変更管理プロセスに不可欠であると
          いうことを意味するものではない。実装には,計画したプロセスを使用することが望ましい
          [5.1.1 e)及び6.1 e)参照]。
8.2.3  変更の検証
  製造業者は,5.7.3及び9.7を考慮しながら,変更によって無効になった検証のやり直しも含めて,変更
を検証する(クラスA,B,C)。

――――― [JIS T 2304 pdf 29] ―――――

                                                                                             27
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
    注記 この細分箇条が要求するのは,変更を検証することだけであり,検証が変更管理プロセスに不
          可欠であるということを意味するものではない。検証には,計画したプロセスを使用すること
          が望ましい[5.1.1 e)及び6.1 e)参照]。
8.2.4  変更のトレーサビリティを実現する手段の提示
  製造業者は,次の事項の間の関連性及び依存関係の記録を維持する(クラスA,B,C)。
a) 変更要求
b) 当該問題報告
c) 変更要求の承認

8.3 *構成状態の記録

  製造業者は,システム構成を含む,管理している構成アイテムについて,検索可能な履歴記録を保存す
る(クラスA,B,C)。

9 *ソフトウェア問題解決プロセス

9.1 問題報告の作成

  製造業者は,発見した医療機器ソフトウェアの問題ごとに問題報告を作成する。問題報告には,重大性
に関する記載(例えば,性能,安全又はセキュリティへの影響)のほか,問題解決に役立ちそうな他の情
報(例えば,影響を受ける機器,影響を受けるサポート対象附属品)を含める(クラスA,B,C)。
    注記 問題は,リリースの前後及び製造業者の組織内外を問わず発見される可能性がある。

9.2 問題の調査

  製造業者は,次を実施する(クラスA,B,C)。
a) 問題を調査し,可能であれば原因を特定する。
b) ソフトウェアリスクマネジメントプロセス(箇条7参照)を用いて,その問題の安全性への関わりを
    評価する。
c) 調査及び評価の結果を文書化する。
d) 問題の是正に必要な処置のための変更要求を作成する,又は処置を行わない場合の正当な根拠を文書
    化する。
    注記 問題が安全性に関連がない場合,製造業者は,ソフトウェア問題解決プロセスに従って問題を
          解決する必要はない。

9.3 関係者への通知

  製造業者は,問題の存在を関係者に適宜通知する(クラスA,B,C)。
    注記 問題は,リリースの前後及び製造業者の組織内外を問わず発見される可能性がある。製造業者
          は,状況に応じて通知先関係者を決定する。

9.4 変更管理プロセスの使用

  製造業者は,変更管理プロセスの要求事項を遵守した上で,全ての変更要求を承認し,実行する(8.2
参照)(クラスA,B,C)。

9.5 記録の保持

  製造業者は,問題報告の記録及びその検証も含めた解決についての記録を保持する。
  製造業者は,リスクマネジメントファイルを適宜更新する(クラスA,B,C)。

9.6 問題の傾向分析

  製造業者は,問題報告を分析してその傾向を把握する(クラスA,B,C)。

――――― [JIS T 2304 pdf 30] ―――――

次のページ PDF 31