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

                                                                                             33
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
                    表B.1−JIS X 0160の定義に従った開発ライフサイクルモデル
             開発モデル      最初に全ての要求事項複数の開発サイクルか 暫定版ソフトウェアを
                                 を定義するか                            配布するか
       ウォータフォール              する              該当せず             しない
       (ワンススルー)
       繰返し(Incremental)         する              該当する           可能性あり
       (事前計画された改良)
       進展的(Evolutionary)       しない             該当する              する
  どのライフサイクルモデルを選択する場合でも,仕様書,設計書,ソフトウェアなどのプロセスアウト
プット間の論理的依存性を維持する必要がある。これは,ウォータフォールライフサイクルモデルの場合,
そのプロセスのためのインプットが完了し承認されるまで,プロセスの開始を延期することで達成する。
  他のライフサイクルモデル,特に進展的(Evolutionary)ライフサイクルモデルでは,プロセスアウトプ
ットを,当該プロセスの全てのインプットが利用可能になる前に作成できる。例えば,新しいソフトウェ
アアイテムの仕様,分類,実装及び検証は,ソフトウェアアーキテクチャ全体が完成する前でも可能であ
る。このようなライフサイクルモデルには,一つのプロセスアウトプットの変更又は開発によって,別の
プロセスアウトプットが無効になるというリスクが伴う。このため,全てのプロセスアウトプットを整合
させ依存性を維持するために,どのライフサイクルモデルにおいても包括的な構成管理システムを使用す
る。
  次の原則は,使用するソフトウェア開発ライフサイクルモデルにかかわらず重要である。
− 全てのプロセスアウトプットの整合性を維持することが望ましい。プロセスアウトプットを作成する
    又は変更するときは,関連する全てのプロセスアウトプットを直ちに更新して,相互の整合性を維持
    し,この規格が明示的又は暗示的に要求している全ての依存性を維持することが望ましい。
− プロセスアウトプットは,ソフトウェアについて更に作業するためのインプットとして必要なとき,
    全てが利用可能になっていることが望ましい。
− 医療機器ソフトウェアをリリースする前の段階で,全てのプロセスアウトプットに相互に整合性があ
    り,この規格が明示的又は暗示的に要求しているプロセスアウトプット間の依存性が,全てあること
    が望ましい。
B.1.2 適用範囲
  この規格は,医療機器ソフトウェアの開発及び保守,並びにSOUPを含む医療機器の開発及び保守に適
用する。
  この規格を使用する場合,製造業者が医療機器についてJIS T 14971に適合するリスクマネジメントを
実施することを要求している。したがって,医療機器のシステムアーキテクチャが,入手したコンポーネ
ント(購入したコンポーネント又は出所が不明なコンポーネント,例えばSOUPを含むプリンタ,プロッ
タなど)を含む場合,製造業者は,入手したコンポーネントに対する責任者となり,これを医療機器のリ
スクマネジメント対象に含めなければならない。製造業者は,医療機器のリスクマネジメントを適切に実
施することで,コンポーネントについて理解し,それにSOUPが含まれていることを認識しているとみな
される。この規格を利用する製造業者は,ソフトウェアリスクマネジメントプロセスを医療機器のリスク
マネジメントプロセスの一環として実施する。
  リリースした医療機器ソフトウェアの保守は,その生産後の技術的行為に適用する。ソフトウェア保守
は,監視行為を含めたあらゆる技術的及び管理的手段の組合せを含む。その目的は,アイテムを維持又は

――――― [JIS T 2304 pdf 36] ―――――

34
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
回復させるための行為を問題報告に基づいて実施し,リリースした医療機器ソフトウェアに関連する修正
要求だけでなく,医療機器ソフトウェアに要求されている機能を正しく実行できる状態にすることである。
例えば,問題是正,規制当局への報告,妥当性再確認,予防措置などが含まれる[JIS X 0161 [8]参照]。
B.2   引用規格
  ISO/IEC 90003 [13]は,品質マネジメントシステムをソフトウェア開発に適用するための指針を示してい
る。この規格が要求する指針ではないが,推奨する。
B.3   用語及び定義
  用語の定義には,可能な範囲で国際規格の定義を使用している。
  この規格は,ソフトウェアシステム(最上位レベル)の構造を説明する場合に,三つの用語を用いてい
る。ソフトウェアシステムは,医療機器のサブシステム(IEC 60601-1-4 [15]参照)又はそれ自体が医療機
器であり,結果としてソフトウェア医療機器になる。試験又はソフトウェア構成管理を目的にしたとき,
それ以上分割することができない最下位レベルは,ソフトウェアユニットである。最上位から最下位の構
成レベルまで,全て含めてソフトウェアアイテムといえる。このようにソフトウェアシステムは,一つ以
上のソフトウェアアイテムで構成し,各ソフトウェアアイテムは,一つ以上のソフトウェアユニット又は
分割可能なソフトウェアアイテムで構成する。ソフトウェアアイテム及びソフトウェアユニットの定義並
びに粒度を示す責任は,製造業者にある。これらの用語は,明確に定義していないため,医療機器に使用
されるソフトウェアには多種多様な開発方法及びタイプが適用できる。
B.4   一般要求事項
  いずれのソフトウェアについても,100 %の安全を保証する既知の方法はない。
  医療機器ソフトウェアの安全性を向上させる次の三つの大原則が存在する。
− リスクマネジメント
− 品質マネジメント
− ソフトウェアエンジニアリング
  安全な医療機器ソフトウェアの開発及び保守には,適切なソフトウェアエンジニアリングの方法及び技
術を適用する総合的フレームワークとして,品質マネジメントシステムに不可欠なリスクマネジメントを
確立する必要がある。上記三つのコンセプトを組み合わせれば,医療機器の製造業者の意思決定プロセス
が明確な体系をとり,首尾一貫した再現性のあるものとなり,医療機器ソフトウェアの安全性が促進され
る。
B.4.1 品質マネジメントシステム
  統制がとれ,かつ,効果的な一連のソフトウェアプロセスには,マネジメント,インフラストラクチャ,
改善,訓練などの系統的なプロセスが含まれる。重複を避け,また,この規格の焦点をソフトウェアエン
ジニアリングに絞るため,これらのプロセスは,この規格から外している。これらのプロセスは,品質マ
ネジメントシステムが対象とするところである。JIS Q 13485 [5]は,品質マネジメントのコンセプトを特
に医療機器に応用するための規格である。ただし,JIS Q 13485の品質マネジメントシステム要求事項に適
合しても,それが自動的に法の要求事項に適合することにはならない。該当する規制要求事項に適合して
いるかを確認し,適合性を確立するのは,製造業者の責任である。

――――― [JIS T 2304 pdf 37] ―――――

                                                                                             35
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
B.4.2 リスクマネジメント
  ソフトウェア開発では,リスクマネジメントアクティビティに十分に関与し,医療機器ソフトウェア関
連の合理的に予見可能なリスクを確実に考慮する。
  このソフトウェア規格は,適切なリスクマネジメントプロセスを定義するものではなく,医療機器のた
めのリスクマネジメントを明確に扱っている規格,JIS T 14971に適合するリスクマネジメントプロセスの
適用を製造業者に要求する。ソフトウェアを一因とする危険状態に対して発生する,具体的なソフトウェ
アリスクマネジメントアクティビティについては,箇条7の対象プロセスに示す。
B.4.3 ソフトウェア安全クラス分類
  医療機器の一部,医療機器の附属品又は一つの医療機器としてのソフトウェアに関連するリスクは,ソ
フトウェア安全クラス分類の仕組みに対するインプットとして使い,この仕組みによってソフトウェアの
開発及び保守を行うときに使用するプロセスを決定する。
  リスクは,危害の発生確率とその危害の重大さとの組合せと定義される。しかし,ソフトウェアの故障
が発生する確率を定量的に推定する広く認められた方法はない。危険状態の原因となる一連の事象又は事
象の組合せの中にソフトウェアが存在する場合,危険状態に対するリスクの推定においてソフトウェアの
故障の発生確率を考慮することはできない。このような場合,最悪の場合の確率を考えるのが適切であり,
ソフトウェアの故障の発生確率は,1とするのがよい。一連の事象のうち,ソフトウェア以外の事象の確
率を推定できる場合は,その確率を危険状態の発生確率として使用できる(図B.2のP1)。
  しかし,ソフトウェア以外の事象の確率を推定できないことも多く,その場合は危害の性質だけに基づ
いてリスクを評価するのがよい(危険状態の発生確率は,1とするのがよい。)。この場合のリスクの推定
は,危険状態から生じる危害の重大性に焦点を合わせるのがよい。医療従事者によって発見される可能性
が高い故障と,発見されずに危害の原因になる可能性がより高い故障を見分けるため,臨床知識に基づい
て主観的な確率ランキングを定めることもできる。
  一般的に,危険状態が危害に至る確率(図B.2のP2)を推定するには,医療現場で危害を防げる可能性
が高い危険状態と,危害の原因となる可能性がより高い危険状態とを見分けるための臨床知識が必要とな
る。

――――― [JIS T 2304 pdf 38] ―――――

36
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
                         ハザード
                                       (ハザードの顕在)P1
         一
         連
         の
                         危険状態
         事
                                                P2
         象
                           危害
                       危害の重大さ             危害の発生確率                リスク
                                                       P1×P2
       注記 P1は,危険状態の発生確率を示す。
            P2は,危険状態が危害に至る確率を示す。
    図B.2−ハザード,一連の事象,危険状態及び危害の関係の図式(JIS T 14971:2012の附属書E)
  ソフトウェアシステムをソフトウェアアイテムに分割した場合,ソフトウェアアイテムそれぞれにソフ
トウェア安全クラス分類を割り当てる。
  ソフトウェアアイテムの故障に関連したリスクの判断は,次の場合に限り可能である。
− システムアーキテクチャ及びソフトウェアアーキテクチャが,ソフトウェアアイテムの役割を,それ
    自体の目的,及び他のソフトウェア及びハードウェアアイテムとのインタフェースの観点で定義付け
    ている。
− システムの変更を管理している。
− アーキテクチャ及び指定したリスクコントロール手段についてのリスク分析が完了している。
  この規格は,全てのソフトウェアクラスについて前述の条件が整う,最低数のアクティビティを要求し
ている。
  ソフトウェアのアーキテクチャアクティビティが終了するのは,ソフトウェアアイテム群全体を定義し,
リスクマネジメントアクティビティによってソフトウェアアイテムがどのように安全に関わるかが明確
になる,開発の最初の時点である。したがって,これは,ソフトウェアアイテムの分類を安全上の役割に
応じて決定できる最初の時点である。
  この時点は,JIS T 14971においてリスクコントロールを開始する時点に対応する。
  これに先立って,リスクマネジメントプロセスによってアーキテクチャリスクコントロール手段が明確
になる。例えば,保護サブシステムの追加又は危害の原因となるソフトウェアの故障の低減である。この
段階を過ぎると,リスクマネジメントプロセスは,ソフトウェアアイテムの故障の確率を低減させること
を狙いとしたプロセスを使用する。つまり,ソフトウェアアイテムの分類が,そのアイテムに適用される
プロセスベースのリスクコントロール手段を特定する。
  この時点以前にソフトウェアの分類を行うと,例えば,調査を実施する領域に焦点を絞ることができる
という点で製造業者にとって好都合であると予想されるが,この分類は,予備的なものとして捉え,プロ
セスの省略を正当化する目的に使わないことが望ましい。

――――― [JIS T 2304 pdf 39] ―――――

                                                                                             37
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
  ソフトウェア安全クラス分類の仕組みは,JIS T 14971のリスクに合わせることを意図するものではない。
JIS T 14971の仕組みでは,重大さ及び発生確率に応じてリスクを分類しているが,ソフトウェア安全クラ
ス分類の仕組みでは,ソフトウェアシステム及びソフトウェアアイテムを,開発及び保守で適用するプロ
セスに応じて分類している。
  設計が進展するにつれ,新たなリスクが判明してくる可能性がある。そのため,リスクマネジメントを,
開発プロセスに不可欠な部分として適用することが望ましい。それによって,確実で安全に動作するため
に正確な機能が要求されるソフトウェアアイテム,及び危害を引き起こす故障を防止するソフトウェアア
イテムを含む,全てのソフトウェアアイテムを特定するアーキテクチャ設計の開発が可能になる。
  ソフトウェアアーキテクチャが,安全な動作に要求されるソフトウェアアイテムの分離を促すとともに,
そのソフトウェアアイテムを確実に効果的に分離するために使用する方法を説明付けることが望ましい。
分離は,物理的な分離(プロセッサ又はメモリの分割)に限定するものではなく,一つのソフトウェアア
イテムが他のソフトウェアアイテムに悪影響を及ぼさないようにするための,あらゆるメカニズムを含む。
分離の適切性は,関係するリスクと分離の根拠とに基づいて判断し,根拠については文書化する必要があ
る。B.3に記載したとおり,この規格では,ソフトウェアシステム(最上位レベル)の構成を説明する場
合に,三つの用語を用いる。
  図B.1は,ソフトウェアシステムの中でのソフトウェアアイテムの分割の例,及び構成内のソフトウェ
アアイテム群にどのようにソフトウェア安全クラスが割り当てられるかを示す。
                                   ソフトウェアシステム/
                                    ソフトウェアアイテム
                                        (クラスC)
                      ソフトウェアアイテム       ソフトウェアアイテム
                              X                          Y
                          (クラスA)                (クラスC)
                              ソフトウェアアイテム    ソフトウェアアイテム
                                      W                       Z
                                  (クラスB)             (クラスC)
                              図B.1−ソフトウェアアイテムの分割例
  この例では,製造業者は,開発中の医療機器ソフトウェアのタイプから,ソフトウェアシステムの予備
的なソフトウェア安全クラス分類が,ソフトウェア安全クラスCであるということを理解している。製造

――――― [JIS T 2304 pdf 40] ―――――

次のページ PDF 41