この規格ページの目次
8
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
ソフトウェア要求事項の定義からリリースまでの,ソフトウェアのライフサイクルに関わる次のような
概念上の構造。
− 医療機器ソフトウェアの開発に関与しているプロセス,アクティビティ及びタスクを明確にする。
− アクティビティとタスクとの間のシーケンス及び依存性を表す。
− 規定した成果物の完全性を検証するマイルストーンを明確にする。
3.25
ソフトウェアアイテム(SOFTWARE ITEM)
コンピュータプログラムの識別可能な部分(例えば,ソースコード,オブジェクトコード,制御コード,
制御データ又はこれらのアイテムの集まり)。
注記1 ソフトウェアの構造は,三つの用語によって識別できる。最上位のレベルは,ソフトウェア
システムである。最下位のレベルは,それ以上分解できないソフトウェアユニットである。
最上位及び最下位レベルを含む構成の全てのレベルを,ソフトウェアアイテムということが
できる。ソフトウェアシステムは,一つ以上のソフトウェアアイテムで構成され,各ソフト
ウェアアイテムは,一つ以上のソフトウェアユニット又は分割可能なソフトウェアアイテム
で構成される。製造業者は,ソフトウェアアイテム及びソフトウェアユニットの粒度
(granularity)を提示する責任がある。
注記2 ISO/IEC 90003:2014の3.14,JIS X 0160:2012の4.41に基づく。
3.26
(対応国際規格で削除されている。)
3.27
ソフトウェアシステム(SOFTWARE SYSTEM)
特定の機能又は特定の機能群を達成するために組む,複数のソフトウェアアイテムを結合した集合体。
3.28
ソフトウェアユニット(SOFTWARE UNIT)
他のアイテムに分割できないソフトウェアアイテム。
注記 ソフトウェアユニットの粒度は,製造業者が定義する(B.3参照)。
3.29
開発過程が不明なソフトウェア,SOUP(software of unknown provenance,SOUP)
既に開発されていて一般に利用できるが,医療機器に組み込むことを目的に開発したものではないソフ
トウェアアイテム[“OTSソフトウェア(off-the-shelf : 既製品)”として知られているソフトウェア]又は
以前開発されたソフトウェアアイテムでその開発プロセスについての十分な記録が利用できないもの。
注記 医療機器ソフトウェアシステム全体をSOUPであると主張することはできない。
3.30
システム(SYSTEM)
一つ以上のプロセス,ハードウェア,ソフトウェア,設備及び人を統合化して,規定のニーズ又は目的
を満たす能力を提供するまとまり。
3.31
タスク(TASK)
行う必要がある一つの作業。
――――― [JIS T 2304 pdf 11] ―――――
9
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
3.32
トレーサビリティ(TRACEABILITY)
開発プロセスの二つ以上の成果物間の関係を明らかにできる程度。
(IEEE 610.12:1990参照)
注記 要求事項,アーキテクチャ,リスクコントロール手段などは,開発プロセスの成果物の例であ
る。
3.33
検証(VERIFICATION)
客観的証拠を提示することによって,規定要求事項が満たされていることを確認すること。
注記1 “検証済み”という用語は,検証が済んでいる状態を示すために用いられる。
(JIS Q 9000:2006の3.8.4参照)
注記2 設計及び開発における検証は,あるアクティビティに対する要求事項に適合しているかを確
定するために,そのアクティビティの結果に対して吟味を行うプロセスである。
3.34
バージョン(VERSION)
ある構成アイテムの識別された実例。
注記 医療機器ソフトウェアのバージョンの変更を行って新しいバージョンとする場合は,ソフトウ
ェア構成管理を実施する必要がある。
(JIS X 0160:2012の4.56参照)
3.35
危険状態(HAZARDOUS SITUATION)
人,財産又は環境が,一つ又は複数のハザードにさらされる状況。
(JIS T 14971:2012の2.4参照)
3.36
レガシーソフトウェア(LEGACY SOFTWARE)
法規制に適合して市場に出荷され,現在も市販されているが,この規格の現行版に適合して開発された
という客観的な証拠が不十分な医療機器ソフトウェア。
3.37
リリース(RELEASE)
特定の目的のために用意された構成アイテムの特定のバージョン。
(JIS X 0160:2012の4.35参照)
3.38
残留リスク(RESIDUAL RISK)
リスクコントロール手段を講じた後にも残るリスク。
注記 対応国際規格の注記1及び注記2は,ISO/IEC Guide 51:2014 [14]で,“residual risk”の定義が変
更されたことによって記載不要となり,削除した。
(JIS T 14971:2012の2.15参照)
3.39
リスク推定(RISK ESTIMATION)
危害の発生確率とその危害の重大さとに対して重み付けをするために用いるプロセス。
――――― [JIS T 2304 pdf 12] ―――――
10
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
(JIS T 14971:2012の2.20参照)
3.40
リスク評価(RISK EVALUATION)
判断基準に照らして推定したリスクが受容できるかを判断するプロセス。
(JIS T 14971:2012の2.21参照)
4 *一般要求事項
4.1 *品質マネジメントシステム
医療機器ソフトウェアの製造業者は,顧客要求事項及び該当する規制要求事項に適合する医療機器ソフ
トウェアを提供する能力があることを実証する。
注記1 この能力は,次のいずれかに適合する品質マネジメントシステムを使用して実証できる。
− JIS Q 13485 [5]
− 医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令
注記2 品質マネジメントシステム要求事項をソフトウェアに適用するための指針は,ISO/IEC 90003
[13]に規定している。
4.2 *リスクマネジメント
製造業者は,JIS T 14971に規定したリスクマネジメントプロセスを適用する。
4.3 *ソフトウェア安全クラス分類
a) 製造業者は,ソフトウェアシステムに起因する危険状態が,最悪の場合に患者,操作者,又はその他
の人にもたらす危害のリスクに応じて,図3に示すように,各ソフトウェアシステムをソフトウェア
安全クラス(A,B又はC)に分類する。
――――― [JIS T 2304 pdf 13] ―――――
11
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
ソフトウェアシステムのソフトウェ
クラスC(デフォルト) ア安全クラスを決める場合には,次
による。
泰‰ フトウェアの故障の発生確
いいえ ソフトウェアは,危険状 率は1とする。
態の一因になるかa) 泰‰ フトウェアシステム以
外(external to)で実施するリス
はい クコントロール手段だけを考
慮する。
注記 そのソフトウェアシステム以
そのソフトウェア以外(external to)で実施する
外で実施するリスクコントロール手
リスクコントロール手段の有効性を評価する。 段は,ソフトウェアの故障が危害を
起こす発生確率及び/又は危害の重
大さを減少させることができる。
いいえ
ソフトウェアによって,受容で 注記 リスクコントロール手段を実
きないリスクを生じるかa) 装したソフトウェアシステムが故障
することもあり,また,この故障が
はい 危険状態の一因になるかもしれな
い。その結果として発生する危害に
は,リスクコントロール手段がリス
どのような障害の可能性
ク低減をすることを意図していた危
があるか
害のこともある[7.2.2 b) 参照]。
重傷の可能性はない 死亡又は重傷の可能性がある
クラスA クラスB クラスC
注a) 本文の記載に整合させた。
図3−ソフトウェア安全クラスの割当て
ソフトウェアシステムのソフトウェア安全クラスがAとなるのは,次のいずれかの場合である。
− ソフトウェアシステムが危険状態の一因とならない場合。
− ソフトウェアシステムが危険状態の一因となるが,そのソフトウェアシステム以外(external to)で
実施するリスクコントロール手段を考慮すれば,受容できないリスクは生じない場合。
ソフトウェアシステムのソフトウェア安全クラスがBとなるのは,次の場合である。
− ソフトウェアシステムが危険状態の一因となり,そのソフトウェアシステム以外で実施するリスク
コントロール手段を考慮しても,受容できないリスクが生じる場合で,重傷の可能性はない場合。
ソフトウェアシステムのソフトウェア安全クラスがCとなるのは,次の場合である。
− ソフトウェアシステムが危険状態の一因となり,そのソフトウェアシステム以外で実施するリスク
コントロール手段を考慮しても,受容できないリスクが生じる場合で,死亡又は重傷の可能性があ
る場合。
当初,ソフトウェア安全クラスをB又はCに分類したソフトウェアシステムについて,製造業者は,そ
のソフトウェアシステム以外(external to)で実施するリスクコントロール手段(そのソフトウェアシステ
ムが含まれるシステムアーキテクチャの改善など)を追加で実施して,そのソフトウェアシステムを新し
いソフトウェア安全クラスに分類することができる。
注記1 そのソフトウェアシステム以外で実施するリスクコントロール手段は,ソフトウェアが危険
――――― [JIS T 2304 pdf 14] ―――――
12
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
状態の一因となる可能性を最小限に抑えるために,ハードウェア,独立したソフトウェアシ
ステム,医療処置又は他の手段とすることができる。
注記2 リスクの受容可能性の定義は,JIS T 14971:2012の3.2(経営者の責任)を参照する。
b) (対応国際規格で削除されている。)
c) 製造業者は,分類した各ソフトウェアシステムの安全クラスを,リスクマネジメントファイルに文書
化する。
d) 製造業者は,ソフトウェアシステムをソフトウェアアイテムに分割する場合,及びソフトウェアアイ
テムを更に幾つかのソフトウェアアイテムに分割する場合,それらのソフトウェアアイテムは,元の
ソフトウェアアイテム(又はソフトウェアシステム)のソフトウェア安全クラスを継承する。ただし,
別のソフトウェア安全クラスに分類することの正当な根拠を文書で示せば,その分類を変更してもよ
い。根拠の文書化に当たっては,新しいソフトウェアアイテムをどのように分離するのかを説明して,
別分類としてもよいことを示す[ソフトウェア安全クラスは,4.3 a)の“ソフトウェアシステム”を“ソ
フトウェアアイテム”に読み替えて分類する。]。
e) 分割によって作成したソフトウェアアイテムのソフトウェア安全クラスが,元のソフトウェアアイテ
ムのクラスと異なる場合,製造業者は,各ソフトウェアアイテムのソフトウェア安全クラスを文書化
する。
f) この規格をあるソフトウェアアイテムのグループに適用する場合,この規格に適合するためには,製
造業者は,そのグループの中で最も高い安全クラスに分類しているソフトウェアアイテムが必要とす
るプロセス及びタスクを使用する。ただし,リスクマネジメントファイルの中で根拠を示すことによ
って,より低いクラスのプロセス及びタスクを使用できる。
g) ソフトウェア安全クラスを分類するまで,各ソフトウェアシステムには,クラスCの要求事項を適用
する。
注記 これ以降の箇条及び細分箇条において,ある特定の要求事項を適用するソフトウェア安全ク
ラスは,要求事項の後に(クラス...)の形式で記載している。
4.4 *レガシーソフトウェア
4.4.1 一般
レガシーソフトウェアの適合性は,この規格の箇条5箇条9を適用する代わりに,4.4.24.4.5に示す
方法で実証してもよい。
4.4.2 リスクマネジメントアクティビティ
この規格の4.2に従って,製造業者は,次を実施する。
a) レガシーソフトウェアに関連する事故事例及び/又はヒヤリ・ハット事例について,社内及び/又は
使用者からの,製造後情報を含むあらゆるフィードバック情報を評価する。
b) レガシーソフトウェアの継続使用に伴うリスクマネジメントアクティビティを,次の点を考慮して実
施する。
− レガシーソフトウェアの医療機器アーキテクチャ全体への統合
− レガシーソフトウェアの一部として実装したリスクコントロール手段の継続的有効性
− レガシーソフトウェアの継続使用に伴う危険状態の特定
− レガシーソフトウェアが危険状態の一因となる場合の潜在的原因の特定
− レガシーソフトウェアが危険状態の一因となる場合の潜在的原因のそれぞれに対するリスクコント
ロール手段の定義
――――― [JIS T 2304 pdf 15] ―――――
次のページ PDF 16
JIS T 2304:2017の引用国際規格 ISO 一覧
- IEC 62304:2006(IDT)
- IEC 62304:2006/AMENDMENT 1:2015(IDT)
JIS T 2304:2017の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.240 : 情報技術(IT)の応用 > 35.240.80 : ヘルスケア技術へのITの応用
JIS T 2304:2017の関連規格と引用規格一覧
- 規格番号
- 規格名称
- JIST14971:2012
- 医療機器―リスクマネジメントの医療機器への適用
- JIST14971:2020
- 医療機器―リスクマネジメントの医療機器への適用