>サイトトップへ >このカテゴリの一覧へ

T 2304

:2012 (IEC 62304:2006)

(1)

目  次

ページ

序文 

1

1

  目的及び適用範囲

3

1.1

  *目的

3

1.2

  *適用範囲 

3

1.3

  他の規格との関係

3

1.4

  適合性

3

2

  *引用規格 

3

3

  *用語及び定義 

4

4

  *一般要求事項 

8

4.1

  *品質マネジメントシステム

8

4.2

  *リスクマネジメント 

8

4.3

  *ソフトウェア安全クラス分類

8

5

  ソフトウェア開発プロセス 

10

5.1

  *ソフトウェア開発計画 

10

5.2

  *ソフトウェア要求事項分析

12

5.3

  *ソフトウェアアーキテクチャの設計 

13

5.4

  *ソフトウェア詳細設計 

14

5.5

  *ソフトウェアユニットの実装及び検証 

14

5.6

  *ソフトウェア結合及び結合試験

15

5.7

  *ソフトウェアシステム試験

16

5.8

  *ソフトウェアリリース 

17

6

  ソフトウェア保守プロセス 

18

6.1

  *ソフトウェア保守計画の確立

18

6.2

  *問題及び修正の分析 

18

6.3

  *修正の実装 

19

7

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

20

7.1

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

20

7.2

  リスクコントロール手段 

20

7.3

  リスクコントロール手段の検証

21

7.4

  ソフトウェア変更のリスクマネジメント 

21

8

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

21

8.1

  *構成識別 

21

8.2

  *変更管理 

22

8.3

  *構成状態の記録

22

9

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

23


T 2304

:2012 (IEC 62304:2006)  目次

(2)

ページ

9.1

  問題報告の作成

23

9.2

  問題の調査 

23

9.3

  関係者への通知

23

9.4

  変更管理プロセスの使用 

23

9.5

  記録の保持 

23

9.6

  問題の傾向分析

23

9.7

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

23

9.8

  試験文書の内容

24

附属書 A(参考)この規格の要求事項の根拠 

25

附属書 B(参考)この規格の適用についての指針 

28

附属書 C(参考)他の規格との関係

42

附属書 D(参考)実装

61

参考文献

63


T 2304

:2012 (IEC 62304:2006)

(3)

まえがき

この規格は,工業標準化法第 12 条第 1 項の規定に基づき,一般社団法人電子情報技術産業協会(JEITA)

から,工業標準原案を具して日本工業規格を制定すべきとの申出があり,日本工業標準調査会の審議を経

て,厚生労働大臣及び経済産業大臣が制定した日本工業規格である。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意

を喚起する。厚生労働大臣,経済産業大臣及び日本工業標準調査会は,このような特許権,出願公開後の

特許出願及び実用新案権に関わる確認について,責任はもたない。


日本工業規格

JIS

 T

2304

:2012

(IEC 62304

:2006

)

医療機器ソフトウェア−

ソフトウェアライフサイクルプロセス

Medical device software-Software life cycle processes

序文 

この規格は,2006 年に第 1 版として発行された IEC 62304 を基に,技術的内容及び構成を変更すること

なく作成した日本工業規格である。

なお,この規格でアスタリスク(*)印がある箇所は,指針又は根拠についての説明を

附属書 に記載

している。また,本文中の太字は,この規格で定義した用語である。この規格で定義した用語が,太字で

表記していない場合,定義は適用されず意味は文脈にそって解釈する。

この規格は,

医療機器ソフトウェアの安全設計及び保守に必要なアクティビティ及びタスクからなるラ

イフサイクル

プロセスのフレームワーク並びに各ライフサイクルプロセスに対する要求事項を規定する。

各ライフサイクル

プロセスは,一連のアクティビティで構成する。さらに,大部分のアクティビティは,

それぞれ一連の

タスクで構成する。

通常,

医療機器ソフトウェアは,品質マネジメントシステム(4.1 参照)及びリスクマネジメントシス

テム

4.2 参照)

の範囲内で開発し,

維持することを前提とする。

リスクマネジメントプロセスは,JIS T 14971

に規定している。

ソフトウェアが危険状態

1)

を引き起こす要因であるかは,

リスクマネジメントプロセスのハザードを特

定する

アクティビティで判断できる。判断する場合は,間接的にソフトウェアに起因する危険状態

1)

[例

えば,不適切な治療行為につながる可能性のある,誤解を招く情報の提供に起因する危険状態

1)

]も考慮

する必要がある。

リスクコントロール手段としてソフトウェアを使用するかは,リスクマネジメントプロ

セスのリスクコントロールアクティビティにおいて決定する。この規格が要求するリスクマネジメントプ

ロセスは,JIS T 14971 に基づいて,機器のリスクマネジメントプロセスに組み込まれなければならない。

1)

  対応国際規格のハザードを危険状態と訳した。

ソフトウェア開発

プロセスは,多くのアクティビティによって構成する。これらのアクティビティにつ

いては,

図 に示し,箇条 に記載する。現場で発生する多くの事故が,ソフトウェアの不適切なアップ

デート及びアップグレードを含む,

医療機器システムのサービス又は保守に関連するため,ソフトウェア

保守

プロセスは,ソフトウェア開発プロセスと同様に重要とみなすことができる。ソフトウェア保守プロ

セスは,ソフトウェア開発プロセスと非常に類似している。これについては,図 に示し,箇条 に記載

する。


2

T 2304

:2012 (IEC 62304:2006)

図 1−ソフトウェア開発プロセス及びアクティビティの関連図

図 2−ソフトウェア保守プロセス及びアクティビティの関連図

この規格は,安全な

医療機器ソフトウェアを開発するために不可欠な二つのプロセス,すなわちソフト

ウェア構成管理

プロセス(箇条 参照)及びソフトウェア問題解決プロセス(箇条 参照)について規定

する。

この規格は,

製造業者の組織の構成,及びプロセス,アクティビティ又はタスクを実行する組織の部門

は規定しない。この規格が要求するのは,この規格への適合性を確立するために

プロセス,アクティビテ

ィ又はタスクを完備しなければならないということだけである。

この規格は,作成する文書の名称,書式及び記載すべき内容のいずれも規定しない。この規格は,

タス

クの文書化を要求するが,文書をどのようにまとめるかは規格の利用者に任せている。

この規格は,特定のライフサイクルモデルを規定しない。この規格の利用者は,ソフトウェアプロジェ

保守要求

この規格の範囲外の

アクティビティ

要求の満足

システム保守

アクティビティ(リスクマネジメントを含む。)

箇条7  ソフトウェア

リスクマネジメント

6.1 

ソフトウェア

保守計画の確立

6.2 

問題及び

修正の分析

5.3 

ソフトウェア

アーキテクチャ

の設計

5.4

ソフトウェア

詳細設計

5.5

ソフトウェア

ユニットの実装

及び検証

5.6

ソフトウェア

結合及び 
結合試験

5.7 

ソフトウェア 
システム試験

5.8

ソフトウェア

リリース

箇条8 ソフトウェア構成管理

箇条9 ソフトウェア問題解決

6.3

  修正の実装

顧客ニーズ

顧客ニーズ

の満足

この規格の範囲外の

アクティビティ

箇条7  ソフトウェア

リスクマネジメント

箇条8 ソフトウェア構成管理

箇条9 ソフトウェア問題解決

5.3 

ソフトウェア

アーキテクチャ

の設計

5.2 

ソフトウェア 
要求事項分析

5.1 

ソフトウェア

開発計画

5.4

ソフトウェア

詳細設計

5.5

ソフトウェア

ユニットの実装

及び検証

5.6

ソフトウェア

結合及び 
結合試験

5.7 

ソフトウェア 
システム試験

5.8 

ソフトウェア

リリース

システム開発

アクティビティ(リスクマネジメントを含む。)


3

T 2304

:2012 (IEC 62304:2006)

クトのライフサイクルモデルを選択し,そのモデルにこの規格の

プロセス,アクティビティ及びタスクを

割り付けなければならない。

附属書 は,この規格の要求事項の根拠を,附属書 には,この規格の適用についての指針を記載する。

目的及び適用範囲 

1.1 

*目的 

この規格は,

医療機器ソフトウェアのライフサイクルについての要求事項を規定する。この規格に規定

する一連の

プロセス,アクティビティ及びタスクは,医療機器ソフトウェアライフサイクルプロセスに共

通のフレームワークを確立する。

1.2 

*適用範囲 

この規格は,ソフトウェアそれ自体が

医療機器である場合,又はソフトウェアが完成品である医療機器

に組み込まれている若しくは不可欠な部分となっている場合の,

医療機器ソフトウェアの開発及び保守に

ついて規定する。

この規格は,その

医療機器が全てソフトウェアで構成されている場合でも,医療機器の妥当性確認及び

最終的な出荷の合否判定は対象としない。

注記  この規格の対応国際規格及びその対応の程度を表す記号を,次に示す。

IEC 62304:2006

,Medical device software−Software life cycle processes(IDT)

なお,対応の程度を表す記号“IDT”は,ISO/IEC Guide 21-1 に基づき,

“一致している”こ

とを示す。

1.3 

他の規格との関係 

この規格は,

医療機器を開発する場合に,適切な他の規格と併せて使用するよう意図している。附属書

C

に,この規格と他の関連規格との関係を示す。

1.4 

適合性 

この規格に適合するとは,ソフトウェア安全クラス(4.3 参照)に従って,この規格で特定した全ての

ロセス,アクティビティ及びタスクを実行することをいう。

注記  各要求事項で指定するソフトウェア安全クラスは,その要求事項の末尾に記載している。

適合性の判断は,

リスクマネジメントファイルを含むこの規格が要求する全ての文書の調査,並びにソ

フトウェア安全クラスに要求する

プロセス,アクティビティ及びタスクを総合評価して行う。附属書 

照。

注記 1  この総合評価は,内部監査又は外部監査によって行うこともある。

注記 2  規定したプロセス,アクティビティ及びタスクは実行するが,これらのプロセスを実装する

方法並びにこれらの

アクティビティ及びタスクを実行する方法には,柔軟性がある。

注記 3  “適宜”という表記を含む要求事項を実施しなかった場合は,総合評価には実施しなかった

ことの正当性を説明するための文書が必要である。

*引用規格 

次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成する。この引用

規格は,その最新版(追補を含む。

)を適用する。

JIS T 14971

  医療機器−リスクマネジメントの医療機器への適用

注記  対応国際規格:ISO 14971,Medical devices−Application of risk management to medical devices


4

T 2304

:2012 (IEC 62304:2006)

(IDT)

*用語及び定義 

この規格で用いる主な用語及び定義は,次による。

3.1 

アクティビティ(ACTIVITY)

一組以上の相互関係又は相互作用のある

タスク。

3.2 

異常(ANOMALY)

要求仕様書,設計文書,規格など,又は既存の認識若しくは経験に基づいて予想した結果を逸脱する状

態。

異常は,ソフトウェア製品又は該当する文書のレビュー,試験,分析,コンパイル又は使用中に発見

されることがあるが,これには限定しない。

IEEE 1044:1993  定義 3.1 参照)

3.3 

アーキテクチャ(ARCHITECTURE)

システム又はコンポーネントの構造。

IEEE 610.12:1990 参照)

3.4 

変更要求(CHANGE REQUEST)

ソフトウェア製品に対する変更内容を文書化した仕様。

3.5 

構成アイテム(CONFIGURATION ITEM)

決められた時点で一意に特定できる“もの”

(entity)。

JIS X 0160:1996  定義 3.6 参照)

3.6 

成果物(DELIVERABLE)

アクティビティ又はタスクの要求される結果又はアウトプット(文書を含む。)。

3.7 

評価(EVALUATION)

対象とする“もの”

(entity)が,規定した基準に達していることを系統的に決定すること。

JIS X 0160:1996  定義 3.9 参照)

3.8 

危害(HARM)

人の受ける身体的傷害若しくは健康障害,又は財産若しくは環境の受ける害。

JIS T 14971:2003  定義 2.2 参照)

3.9 

ハザード(HAZARD)

危害の潜在的な源。

JIS T 14971:2003  定義 2.3 参照)


5

T 2304

:2012 (IEC 62304:2006)

3.10 

製造業者(MANUFACTURER)

医療機器の市場出荷及び/又は使用開始の前に,医療機器の設計,製造,こん(梱)包若しくはラベリ

ング又は

システムの組合せ若しくは変更に責任を負う個人又は法人。その業務がその個人若しくは法人又

は代理を受けた第三者によって行われるか否かを問わない。

JIS T 14971:2003  定義 2.6 参照)

3.11 

医療機器(MEDICAL DEVICE)

あらゆる計器,器械,用具,機械,器具,埋め込み用具,体外診断薬,検定物質,ソフトウェア,材料

又はその他の同類のもの若しくは関連する物質(article)であって,単独使用か組合せ使用かを問わず,

製造業者が人体への使用を意図し,その使用目的が次の一つ以上であり,

−  疾病の診断,予防,監視,治療又は緩和

−  負傷の診断,監視,治療,緩和又は補助

−  解剖学的又は生理学的な

プロセスの検査,代替,又は修復

−  生命支援又は維持

−  受胎調整

医療機器の殺菌

−  人体から採取される標本の体外試験法による医療目的のための情報提供

薬学,免疫学,又は新陳代謝の手段によって体内又は体表において意図したその主機能を達成すること

はないが,それらの手段によって機能の実現を補助するものである。

JIS Q 13485:2005  定義 3.7 参照)

3.12 

医療機器ソフトウェア(MEDICAL DEVICE SOFTWARE)

開発中の

医療機器に組み込むことを目的として開発した,又はそれ自体を医療機器として使用すること

を意図した

ソフトウェアシステム。

3.13 

問題報告(PROBLEM REPORT)

ユーザ又はその他の関係者が,安全でない,意図した用途に対して不適切である又は仕様に反すると判

断した,

ソフトウェア製品の実際の又は潜在的な動作の記録。

注記 1  この規格は,全ての問題報告に対してソフトウェア製品の変更を要求するものではない。製

造業者は,誤解,エラー又は軽微な事象として問題報告を処置の対象としなくてもよい。

注記 2  問題報告は,リリースしたソフトウェア製品又は開発中のソフトウェア製品に適用する。

注記 3  この規格は,リリースした製品についての問題報告の法的な対応処置を,確実に特定及び実

行できるようにするため,

製造業者に別途方針決定を行うことを要求している(箇条 参照)。

3.14 

プロセス(PROCESS)

インプットをアウトプットに変換する,相互に関連する又は相互に作用する一連の

アクティビティ。

JIS Q 9000:2006  定義 3.4.1 参照)

注記  用語“アクティビティ”は,資源を利用することも含む。


6

T 2304

:2012 (IEC 62304:2006)

3.15 

レグレッションテスト(REGRESSION TESTING)

システムコンポーネントの変更が,機能性,信頼性,性能に悪影響を与えないこと,及び更なる欠陥を

招かないことを判定するために要求される試験。

ISO/IEC 90003:2004  定義 3.11 参照)

3.16 

リスク(RISK)

危害の発生確率とその危害の重大さとの組合せ。

JIS T 14971:2003  定義 2.13 参照)

3.17 

リスク分析(RISK ANALYSIS)

利用可能な情報を体系的に用いて

ハザードを特定し,リスクを推定すること。

JIS T 14971:2003  定義 2.14 参照)

3.18 

リスクコントロール(RISK CONTROL)

規定したレベルまで

リスクを低減するか又はそのレベルでリスクを維持するという決定に到達し,かつ,

防護手段を実施する一貫した

プロセス。

JIS T 14971:2003  定義 2.16  参照)

3.19 

リスクマネジメント(RISK MANAGEMENT)

リスクの分析,評価及びコントロールに対して,管理方針,手順及び実施を体系的に適用すること。

JIS T 14971:2003  定義 2.18 参照)

3.20 

リスクマネジメントファイル(RISK MANAGEMENT FILE)

リスクマネジメントプロセスによって作成した記録及び他の文書のまとまり。必ずしも物理的に連続し

ていなくてもよい。

JIS T 14971:2003  定義 2.19 参照)

3.21 

安全(SAFETY)

受容できない

リスクがないこと。

JIS T 14971:2003  定義 2.20 参照)

3.22 

セキュリティ(SECURITY)

権限を与えられていない者,又は権限を与えられていない

システムが読み込んだり変更できないように

情報及びデータを保護すること。また,権限を与えられている者,又は権限を与えられている

システムが

アクセスを拒否されないように情報及びデータを保護すること。

JIS X 0160:1996  定義 3.25 参照)

3.23 

重傷(SERIOUS INJURY)

直接的又は間接的に次の結果を引き起こすけが又は病気。


7

T 2304

:2012 (IEC 62304:2006)

a)

生命の危険

b)

身体機能又は身体構造の永久的障害

c)

身体機能又は身体構造の永久的障害を防止するために,内科的又は外科的処置を必要とする障害

注記  永久的障害とは,軽微な障害又は損害を除く,身体構造又は機能の不可逆性の障害若しくは

損害を意味する。

3.24 

ソフトウェア開発ライフサイクルモデル(SOFTWARE DEVELOPMENT LIFE CYCLE MODEL)

ソフトウェア要求事項の定義から製造のためにリリースするまでの,ソフトウェアのライフサイクルに

関わる次のような概念上の構造。

ソフトウェア製品の開発に関与している,プロセス,アクティビティ及びタスクを明確にする。

アクティビティとタスクとの間のシーケンス及び依存性を表す。

−  規定した

成果物の完全性を検証するマイルストーンを明確にする。

3.25 

ソフトウェアアイテム(SOFTWARE ITEM)

コンピュータプログラムの識別可能な部分。

ISO/IEC 90003:2004  定義 3.14 参照)

注記  ソフトウェアの構造は,三つの用語によって識別できる。最上位のレベルは,ソフトウェアシ

ステムである。最下位のレベルは,それ以上分割できないソフトウェアユニットである。最上

位及び最下位レベルを含む構成の全てのレベルを,

ソフトウェアアイテムということができる。

ソフトウェアシステムは,一つ以上のソフトウェアアイテムで構成され,各ソフトウェアアイ

テムは,一つ以上のソフトウェアユニット又は分割可能なソフトウェアアイテムで構成される。

製造業者は,ソフトウェアアイテム及びソフトウェアユニットの定義及び粒度(granularity)を

提示する責任がある。

3.26 

ソフトウェア製品(SOFTWARE PRODUCT)

コンピュータプログラム,手続き並びに関連する文書及びデータのまとまり。

JIS X 0160:1996  定義 3.26 参照)

3.27 

ソフトウェアシステム(SOFTWARE SYSTEM)

特定の機能又は特定の機能群を達成するために組む,複数の

ソフトウェアアイテムを結合した集合体。

3.28 

ソフトウェアユニット(SOFTWARE UNIT)

他のアイテムに分割できない

ソフトウェアアイテム。

注記  ソフトウェアユニットは,ソフトウェア構成管理又は試験の目的で使用できる。

3.29 

SOUP 

開発過程が不明なソフトウェア(

“Software Of Unknown Provenance”の頭字語)

既に開発されていて一般に利用できるが,

医療機器に組み込むことを目的に開発したものではないソフ

トウェアアイテム[“市販品(off-the-shelf)”として知られているソフトウェア]又は以前開発されたソフ

トウェアでその開発

プロセスについての十分な記録が利用できないもの。


8

T 2304

:2012 (IEC 62304:2006)

3.30 

システム(SYSTEM)

一つ以上の

プロセス,ハードウェア,ソフトウェア,設備及び人を統合化して,規定のニーズ又は目的

を満たす能力を提供するまとまり。

JIS X 0160:1996  定義 3.31 参照)

3.31 

タスク(TASK)

行う必要がある一つの作業。

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:1996  定義 3.37 参照)

*一般要求事項 

4.1 

*品質マネジメントシステム 

医療機器ソフトウェアの製造業者は,顧客要求事項及び該当する規制要求事項に適合する医療機器ソフ

トウェアを提供する能力があることを実証する。

注記 1  この能力は,次のいずれかに適合する品質マネジメントシステムを使用して実証できる。

−  JIS Q 13485 [4]

−  医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令

注記 2  品質マネジメントシステム要求事項をソフトウェアに適用するための指針は,ISO/IEC 90003

[9]に規定している。

4.2 

*リスクマネジメント 

製造業者は,JIS T 14971 に規定したリスクマネジメントプロセスを適用する。

4.3 

*ソフトウェア安全クラス分類 

a)

製造業者は,ソフトウェアシステムに起因する危害

2)

が患者,操作者,又はその他の人に及ぼす影響

に応じて,各

ソフトウェアシステムをソフトウェア安全クラス(A,B 又は C)に分類する。


9

T 2304

:2012 (IEC 62304:2006)

ソフトウェア安全クラスは,最初に,

危害の程度に基づいて次のいずれかに分類する。

クラス A:負傷又は健康障害の可能性はない。

クラス B:

重傷の可能性はない。

クラス C:死亡又は

重傷の可能性がある。

ソフトウェアシステムが指定したとおり動作しない故障で危害

2)

が起こる可能性がある場合には,

その故障の発生確率を,100 %とみなす。

ソフトウェアの故障で死亡又は

重傷の可能性があるとしたリスク(クラス C)が,ハードウェアリ

スクコントロール手段によって受容可能なレベルに低減できる場合には,ソフトウェア安全クラス分

類を C から B に変更してもよい。その手段は,故障の重大性を低減させるものでも,故障に起因する

死亡又は

重傷の確率を低減させるものでもよい。またこれと同様の手法で,ソフトウェアの故障で重

傷の可能性はないとしたリスク(クラス B)を,ハードウェアリスクコントロール手段によって受容

可能なレベルに低減する場合には,ソフトウェア安全クラス分類を B から A に変更してもよい。

2)

  対応国際規格のハザードを危害と訳した。

b)

製造業者は,リスクコントロール手段でコントロールするリスク

3)

の予想される影響に基づいて,

スクコントロール手段の実装に寄与する各ソフトウェアシステムに対して,ソフトウェア安全クラス

の分類を行う。

3)

  対応国際規格のハザードをリスクと訳した。

c)

製造業者は,分類した各ソフトウェアシステムの安全クラスを,リスクマネジメントファイルに文書

化する。

d)

製造業者は,ソフトウェアシステムをソフトウェアアイテムに分割する場合,及びソフトウェアアイ

テムを更に幾つかのソフトウェアアイテムに分割する場合,それらのソフトウェアアイテムは,元の

ソフトウェアアイテム(又はソフトウェアシステム)のソフトウェア安全クラスを継承する。ただし,

別のソフトウェア安全クラスに分類することの正当な根拠を文書で示せば,変更してもよい。根拠の

文書化に当たっては,新しい

ソフトウェアアイテムをどのように分離するのかを説明して,別分類と

してもよいことを示す。

e)

分割によって作成した

ソフトウェアアイテムのソフトウェア安全クラスが,元のソフトウェアアイテ

ムのクラスと異なる場合,製造業者は,各ソフトウェアアイテムのソフトウェア安全クラスを文書化

する。

f)

ある

プロセスが特定クラスのソフトウェアアイテムのために要求され,そのプロセスがあるソフトウ

ェアアイテムのグループに必ず適用される場合に,この規格に適合するためには,製造業者は,その

グループの中で最も高い安全クラスに分類している

ソフトウェアアイテムが必要とするプロセス及び

タスクを使用する。ただし,リスクマネジメントファイルの中で根拠を示すことによって,より低い

クラスの

プロセス及びタスクを使用できる。

g)

ソフトウェア安全クラスを分類するまで,各

ソフトウェアシステムには,クラス C の要求事項を適用

する。

注記  これ以降の要求事項において,その実施が必要なソフトウェア安全クラスは,要求事項の後に

(クラス...)の形式で記載する。


10

T 2304

:2012 (IEC 62304:2006)

ソフトウェア開発プロセス 

5.1 

*ソフトウェア開発計画 

5.1.1 

ソフトウェア開発計画 

製造業者は,開発するソフトウェアシステムの適用範囲,規模及びソフトウェア安全クラス分類に適し

た,ソフトウェア開発

プロセスのアクティビティを実施するために,(一つ又は複数の)ソフトウェア開

発計画を確立する。

ソフトウェア開発ライフサイクルモデルは,その計画の中に全てを定義するか,又は

引用するかのいずれかとする。計画は,次の事項を扱った内容とする。

(クラス A,B,C)

a)

ソフトウェアシステムの開発に使用するプロセス(注記 参照)

b)

アクティビティ及びタスクの成果物(文書化を含む。)

c)

システム要求事項,ソフトウェア要求事項,ソフトウェアシステム試験及びソフトウェアに実装する

リスクコントロール手段の間のトレーサビリティ

d)  SOUP

構成アイテム及び開発支援用ソフトウェアを含む,ソフトウェア構成管理及び変更管理

e)

ライフサイクルの各段階で発見される,

ソフトウェア製品,成果物及びアクティビティの問題に対処

するためのソフトウェア問題解決

注記 1  ソフトウェア開発ライフサイクルモデルでは,ソフトウェアシステムの各ソフトウェアア

イテムの安全クラス分類に従って,異なるソフトウェアアイテムに対し,それぞれ別の要

素(

プロセス,アクティビティ,タスク及び成果物)を割り付けることができる。

注記 2  これらのアクティビティ及びタスクは,重複するものであっても相互に影響を与え合うも

のであってもよく,反復的又は循環的に実行してもよい。特定のライフサイクルモデルを

使用することが望ましいということを意図したものではない。

注記 3  この規格には,開発プロセスと区別して説明している他のプロセスがあるが,それらを別

アクティビティ及びタスクとして実装しなければならないということを意味するもので

はない。それらの

プロセスのアクティビティ及びタスクは,開発プロセスに統合できる。

注記 4  ソフトウェア開発計画では,既存のプロセスを引用しても新たにプロセスを定義してもよ

い。

注記 5  ソフトウェア開発計画は,全体のシステム開発計画に統合してもよい。

5.1.2 

ソフトウェア開発計画の継続更新 

製造業者は,開発の進捗に応じて,計画を適宜更新する。(クラス A,B,C)

5.1.3 

ソフトウェア開発計画におけるシステム設計及びシステム開発の引用 

(クラス A,B,C)

a)

ソフトウェア開発のためのインプットとなる

システム要求事項は,製造業者がソフトウェア開発計画

の中で引用する。

b)

製造業者は,ソフトウェア開発計画に,4.1 に適合するために必要な,ソフトウェア開発及び設計開発

の妥当性確認の調整を図るための手段を示すか又は引用する。

注記  ソフトウェアシステムがスタンドアロンシステム(ソフトウェア単独)の場合は,ソフトウ

ェアシステム要求事項とシステム要求事項とに差異がない場合もある。

5.1.4 

ソフトウェア開発規格,方法及びツールの計画 

製造業者は,ソフトウェア開発計画書に,クラス C のソフトウェアアイテムの開発に関連する次の項目

を示すか又は引用する。

(クラス C)

a)

規格


11

T 2304

:2012 (IEC 62304:2006)

b)

方法

c)

ツール

5.1.5 

ソフトウェア結合及び結合試験計画 

製造業者は,ソフトウェアアイテム(SOUP を含む。)を結合して,結合時に試験を実施するための計画

を,ソフトウェア開発計画書に示すか又は引用する。

(クラス B,C)

注記  結合試験及びソフトウェアシステム試験は,一つの計画及び一連のアクティビティに統合して

もよい。

5.1.6 

ソフトウェア検証計画 

製造業者は,ソフトウェア開発計画書に,次の検証情報を示すか又は引用する。(クラス A,B,C)

a)

検証が必要な成果物

b)

各ライフサイクル

アクティビティに必要な検証タスク

c)

成果物を検証するマイルストーン

d)

成果物検証の合否判定基準

5.1.7 

ソフトウェアリスクマネジメント計画 

製造業者は,ソフトウェアリスクマネジメントプロセスのアクティビティ及びタスクの実行計画(SOUP

に関連した

リスクマネジメントを含む。)を,ソフトウェア開発計画に示すか又は引用する。(クラス A,

B,C)

注記  箇条 参照。

5.1.8 

文書化計画 

製造業者は,ソフトウェア開発ライフサイクルにおいて作成する文書についての情報を,ソフトウェア

開発計画書に示すか又は引用する。記載した文書又は文書のタイプそれぞれについて,次の情報を示すか

又は引用する。

(クラス A,B,C)

a)

題名,名称又は命名規則(naming convention)

b)

目的

c)

文書が対象とする読者

d)

開発,レビュー,承認及び修正のための手順並びに責任

5.1.9 

ソフトウェア構成管理計画 

製造業者は,ソフトウェア開発計画書に,ソフトウェア構成管理情報を示すか又は引用する。記載又は

引用するソフトウェア構成管理情報とは,次をいう。

(クラス A,B,C)

a)

管理対象アイテムのクラス,タイプ,カテゴリ又はリスト

b)

ソフトウェア構成管理

アクティビティ及びタスク

c)

ソフトウェア構成管理及び

アクティビティの実行に責任を負う組織

d)

それらの組織と他の組織(例えばソフトウェア開発又は保守など)との関係

e)

アイテムを構成管理下に置く時期

f)

問題解決

プロセスを使用する時期

5.1.10 

管理が必要な支援アイテム 

管理対象のアイテムには,

医療機器ソフトウェアに影響を及ぼす可能性のある,医療機器ソフトウェア

の開発に使用するツール,アイテム又は設定を含める。

(クラス B,C)

注記  このようなアイテムの例には,コンパイラ又はアセンブラのバージョン,メイクファイル,バ

ッチファイル及び特定の環境設定を含む。


12

T 2304

:2012 (IEC 62304:2006)

5.1.11 

検証前のソフトウェア構成アイテムのコントロール 

製造業者は,ソフトウェア構成アイテムが,その検証前に,文書化された構成管理の管理下に置かれる

ように計画する。

(クラス B,C)

5.2 

*ソフトウェア要求事項分析 

5.2.1 

システム要求事項からのソフトウェア要求事項の定義及び文書化 

製造業者は,医療機器のソフトウェアシステムごとに,システムレベルの要求事項からソフトウェアシ

ステム要求事項を定義して文書化する。(クラス A,B,C)

注記  ソフトウェアシステムがスタンドアロンシステム(ソフトウェア単独の機器)の場合は,ソフ

トウェアシステム要求事項とシステム要求事項とに差異がない場合もある。

5.2.2 

ソフトウェア要求事項の内容 

製造業者は,医療機器ソフトウェアの要求事項に必要な場合は,次の事項を適宜含める。

(クラス A,B,

C)

a)

機能及び能力についての要求事項

注記 1  例は,次による。

−  性能(ソフトウェアの目的,タイミング要求事項など)

−  物理的特性(コード言語,プラットフォーム,オペレーティングシステムなど)

−  ソフトウェアの実行環境(ハードウェア,メモリサイズ,処理ユニット,時間帯の設

定,ネットワークインフラストラクチャなど)

−  アップグレード,複数の SOUP 又は他機器との互換性の必要性

b)

ソフトウェアシステムのインプット及びアウトプット

注記 2  例は,次による。

−  データの型(数字,英数字,フォーマットなど)

−  範囲

−  制限

−  既定値

c)

ソフトウェアシステムと他のシステムとの間のインタフェース

d)

ソフトウェアによる警報,警告及び操作者へのメッセージ

e)

セキュリティ要求事項

注記 3  例は,次による。

−  機密情報の漏えい(洩)に関連する事項

−  認証

−  認可

−  監査証跡(audit trail)

−  通信の完全性

f)

ヒューマンエラー及び訓練に影響を受けやすいユーザビリティエンジニアリング要求事項

注記 4  例は,次に関連するものによる。

−  手動操作の支援

−  人間と機器との相互作用

−  人員についての制約

−  人間の注意を集中する必要がある領域


13

T 2304

:2012 (IEC 62304:2006)

注記 5  ユーザビリティエンジニアリング要求事項についての情報は,IEC 60601-1-6 [12]に規定し

ている。

g)

データ定義及びデータベース要求事項

注記 6  例は,次による。

−  形式

−  整合性

−  機能

h)

納入した

医療機器ソフトウェアの,操作現場及び保守現場におけるインストール及び検収の要求事項

i)

操作及び保守の方法に関わる要求事項

j)

作成すべきユーザ向け文書

k)

ユーザ保守要求事項

l)

規制要求事項

注記 7  ソフトウェア開発の初期には,必ずしもこれらの要求事項の全てが利用できるとは限らな

い。

注記 8  JIS X 0129-1 [5]は,ソフトウェア要求事項の定義付けに有用な品質特性についての情報を

規定している。

5.2.3 

リスクコントロール手段のソフトウェア要求事項への包含 

製造業者は,ハードウェアの故障及び潜在的なソフトウェア不具合に対してソフトウェアに実装するリ

スクコントロール手段を,医療機器ソフトウェアの要求事項に含める。(クラス B,C)

注記  これらの要求事項は,ソフトウェア開発の初期には利用できないこともあり,ソフトウェアの

設計及び

リスクコントロール手段の追加定義を行うことで変更できる。

5.2.4 

医療機器のリスク分析の再評価 

製造業者は,ソフトウェア要求事項が確定した時点で医療機器のリスク分析を再評価し,適宜,更新す

る。

(クラス A,B,C)

5.2.5 

システム要求事項の更新 

製造業者は,ソフトウェア要求事項分析アクティビティの結果を受けて,適宜,システム要求事項を含

む既存の要求事項の再

評価及び更新を確実に実施する。(クラス A,B,C)

5.2.6 

ソフトウェア要求事項の検証 

製造業者は,ソフトウェア要求事項について次の点を検証し文書化する。(クラス A,B,C)

a)

システム要求事項(リスクコントロールに関わるものを含む。)を実装している。

b)

相互に矛盾しない。

c)

曖昧さを回避した用語で表現している。

d)

試験基準を確立することができる用語で表現していて,試験基準に適合するかを判断する試験が実施

できる用語で表現している。

e)

一意に識別できる。

f)

システム要求事項又は他の要求事項を追跡できる。

注記  この規格は,正式な仕様言語の使用を要求するものではない。

5.3 

*ソフトウェアアーキテクチャの設計 

5.3.1 

ソフトウェア要求事項のアーキテクチャへの変換 

製造業者は,医療機器ソフトウェアの要求事項を,文書化したアーキテクチャ(ソフトウェアの構造の


14

T 2304

:2012 (IEC 62304:2006)

説明及び

ソフトウェアアイテムの特定をしているもの)に変換する。(クラス B,C)

5.3.2 

ソフトウェアアイテムのインタフェース用アーキテクチャの開発 

製造業者は,ソフトウェアアイテムとソフトウェアアイテム外部のコンポーネント(ソフトウェア及び

ハードウェア)との間,及び

ソフトウェアアイテム間のインタフェースについて,アーキテクチャを開発

し,文書化する。

(クラス B,C)

5.3.3 SOUP

アイテムの機能及び性能要求事項の指定 

ソフトウェアアイテムを SOUP と特定している場合,製造業者は,その SOUP アイテムについて,その

意図した用途に必要な機能性能要求事項を明確にする。

(クラス B,C)

5.3.4 SOUP

アイテムが要求するシステムハードウェア及びシステムソフトウェアの指定 

ソフトウェアアイテムを SOUP と特定している場合,製造業者は,SOUP アイテムの正常な動作に必要

システムハードウェア及びシステムソフトウェアを明確にする。(クラス B,C)

注記  例としては,プロセッサのタイプ及び速度,メモリのタイプ及びサイズ,システムソフトウェ

アのタイプ,通信及び表示のソフトウェア要求事項などがある。

5.3.5 

リスクコントロールに必要な分離の特定 

製造業者は,リスクコントロールに不可欠なソフトウェアアイテム間の分離を特定し,分離が有効であ

ることを確実にする方法について明示する。

(クラス C)

注記  分離の例としては,異なるプロセッサ上でソフトウェアアイテムを実行させることがある。分

離の効果は,プロセッサ間に共有リソースをもたないことによって保証できる。

5.3.6 

ソフトウェアアーキテクチャの検証 

製造業者は,次の事項を検証し,文書化する。(クラス B,C)

a)

ソフトウェアの

アーキテクチャが,リスクコントロールに関わる要求事項を含む,システム及びソフ

トウェアの要求事項を実装している。

b)

ソフトウェア

アーキテクチャが,ソフトウェアアイテム間及びソフトウェアアイテムとハードウェア

との間のインタフェースを支援できる。

c)

医療機器アーキテクチャが,全ての SOUP アイテムの正常な動作を支援している。

5.4 

*ソフトウェア詳細設計 

5.4.1 

ソフトウェアアーキテクチャのソフトウェアユニットへの分解 

製造業者は,最小単位であるソフトウェアユニットによって表現できるまで,ソフトウェアアーキテク

チャを分解する。(クラス B,C)

5.4.2 

ソフトウェアユニットごとの詳細設計の開発 

製造業者は,ソフトウェアアイテムのソフトウェアユニットごとに詳細設計を開発し,文書化する。

(ク

ラス C)

5.4.3 

インタフェース用詳細設計の開発 

製造業者は,ソフトウェアユニットと外部コンポーネント(ハードウェア又はソフトウェア)との間,

及び

ソフトウェアユニット間の全てのインタフェースについて詳細設計を開発し,文書化する。

(クラス C)

5.4.4 

詳細設計の検証 

製造業者は,ソフトウェアの詳細設計が次によることを検証し,文書化する。(クラス C)

a)

ソフトウェア

アーキテクチャを実装している。

b)

ソフトウェア

アーキテクチャとの矛盾がない。

5.5 

*ソフトウェアユニットの実装及び検証 


15

T 2304

:2012 (IEC 62304:2006)

5.5.1 

各ソフトウェアユニットの実装 

製造業者は,各ソフトウェアユニットを実装する。(クラス A,B,C)

5.5.2 

ソフトウェアユニット検証プロセスの確立 

製造業者は,各ソフトウェアユニットを検証するための方針,方法及び手順を確立する。検証を試験に

よって実施する場合は,その試験手順の正確さについて

評価する。(クラス B,C)

注記  結合試験及びソフトウェアシステム試験は,一つの計画及び一連のアクティビティに統合して

もよい。

5.5.3 

ソフトウェアユニットの合否判定基準 

製造業者は,より大きなソフトウェアアイテムに結合する前に,必要に応じてソフトウェアユニットの

合否判定基準を確立し,

ソフトウェアユニットが合否判定基準を確実に適合するようにする。(クラス B,

C)

注記  合否判定基準の例は,次による。

−  ソフトウェアコードが,

リスクコントロール手段を含む要求事項を実装しているか。

−  ソフトウェアコードが,

ソフトウェアユニットの詳細設計で文書化しているインタフェー

スと矛盾しないか。

−  ソフトウェアコードが,プログラミング手順又はコーディング標準に従っているか。

5.5.4 

追加のソフトウェアユニット合否判定基準 

設計に当たって,

製造業者は,必要に応じて次の事項についての追加の合否判定基準を含める。

(クラス

C)

a)

適正なイベントシーケンス

b)

データ及び制御フロー

c)

計画したリソース配分

d)

異常処理(エラーの定義,特定及び復帰)

e)

変数の初期化

f)

自己診断

g)

メモリ管理及びメモリオーバーフロー

h)

境界条件

5.5.5 

ソフトウェアユニットの検証 

製造業者は,ソフトウェアユニットの検証を実行し,結果を文書化する。(クラス B,C)

5.6 

*ソフトウェア結合及び結合試験 

5.6.1 

ソフトウェアユニットの結合 

製造業者は,結合計画に従ってソフトウェアユニットを結合する(5.1.5 参照)。(クラス B,C)

5.6.2 

ソフトウェア結合の検証 

製造業者は,結合計画に従って,ソフトウェア結合の次の側面を検証し,記録する(5.1.5 参照)。

(クラス B,C)

a)

ソフトウェアユニットが,ソフトウェアアイテム及びソフトウェアシステムに結合されている。

b)

システムのハードウェアアイテム,ソフトウェアアイテム及び手動操作支援(例えば,人間と機器と

のインタフェース,オンラインヘルプメニュー,音声認識,音声制御)が,

システムに結合されてい

る。

注記  ここでは,アイテムが計画に従って結合されているかについてだけ検証し,意図したとおりに


16

T 2304

:2012 (IEC 62304:2006)

機能するかについては検証しない。

5.6.3 

結合したソフトウェアの試験 

製造業者は,結合計画(5.1.5 参照)に従って,結合したソフトウェアアイテムを試験し,結果を文書化

する。

(クラス B,C)

5.6.4 

結合試験の内容 

ソフトウェア結合試験では,

製造業者は,結合したソフトウェアアイテムが意図したとおりに機能する

かを明確にする。

(クラス B,C)

注記 1  考慮すべき事項の例は,次による。

−  ソフトウェアに要求している機能

リスクコントロール手段の実装

−  指定したタイミング及びその他の動作

−  内部及び外部インタフェースの指定した機能

−  予見可能な誤使用を含む異常な条件下での試験

注記 2  結合試験及びソフトウェアシステム試験は,一つの計画及び一連のアクティビティに統合し

てもよい。

5.6.5 

結合試験手順の検証 

製造業者は,結合試験手順の正確さを評価する。(クラス B,C)

5.6.6 

レグレッションテストの実施 

製造業者は,ソフトウェアアイテムを既存の結合済みソフトウェアに結合する場合,レグレッションテ

ストを適宜実施して,結合前にはなかった欠陥が新たに生じていないことを実証する。(クラス B,C)

5.6.7 

結合試験記録の内容 

製造業者は,次の事項を実施する。(クラス B,C)

a)

試験結果(合否及び

異常箇所のリスト)を文書化する。

b)

試験を再現できるように,十分な記録を保存する。

c)

試験者を明示する。

注記  要求事項 b)は,例えば次のものを保存することによって行うこともあり得る。

−  要求された処置及び期待された結果を示すテストケース仕様

−  装置の記録

−  試験に使用した,

(ソフトウェアツールを含む。

)試験環境の記録

5.6.8 

ソフトウェア問題解決プロセスの使用 

製造業者は,ソフトウェア結合及び結合試験中に発見した異常を,ソフトウェア問題解決プロセスで処

理する。

(クラス B,C)

注記  箇条 参照。

5.7 

*ソフトウェアシステム試験 

5.7.1 

ソフトウェア要求事項についての試験の確立 

製造業者は,ソフトウェアシステム試験の実施のために,個々のソフトウェア要求事項を対象として,

インプット内容,予想する結果,合否判定基準及び手順を規定した一連の試験を確立し,実施する。

(クラ

ス B,C)

注記 1  結合試験及びソフトウェアシステム試験は,一つの計画及び一連のアクティビティに統合し

てもよい。また,ソフトウェア要求事項は,より早い段階で試験してもよい。


17

T 2304

:2012 (IEC 62304:2006)

注記 2  特に要求事項の間に依存性が存在する場合は,要求事項ごとの個別試験だけでなく,要求事

項を組み合わせた試験も実施可能である。

5.7.2 

ソフトウェア問題解決プロセスの使用 

製造業者は,ソフトウェアシステム試験中に発見した異常を,ソフトウェア問題解決プロセスで処理す

る。

(クラス B,C)

5.7.3 

変更後の再試験 

製造業者は,ソフトウェアシステム試験の実施中に変更があった場合,次の処理をする。

(クラス B,C)

a)

必要に応じた試験のやり直し,試験の修正及び実施,又は追加試験の実施によって,変更が問題の訂

正にどの程度有効かを検証する。

b)

副作用が発生しなかったことを示すための適切な試験を実施する。

c)

7.4

で定義している,関連する

リスクマネジメントアクティビティを実行する。

5.7.4 

ソフトウェアシステム試験の検証 

製造業者は,次の事項を検証する。(クラス B,C)

a)

使用した

検証方針及び試験手順が適切である。

b)

ソフトウェアシステム試験手順が,ソフトウェア要求事項に従っている。

c)

全てのソフトウェア要求事項を対象に,試験又は

検証を実施している。

d)

試験結果が,合否基準を適合する。

5.7.5 

ソフトウェアシステム試験記録の内容 

製造業者は,次の事項を実施する。(クラス B,C)

a)

試験結果(合否及び

異常箇所のリスト)を文書化する。

b)

試験を再現できるように,十分な記録を保存する。

c)

試験者を明示する。

注記  要求事項 b)は,例えば次のものを保存することによって行うこともあり得る。

−  要求された処置及び期待された結果を示すテストケース仕様

−  装置の記録

−  試験に使用した,

(ソフトウェアツールを含む。

)試験環境の記録

5.8 

*ソフトウェアリリース 

5.8.1 

ソフトウェア検証の完了確認 

製造業者は,ソフトウェア検証が完了し,結果を評価したことを,ソフトウェアのリリース前に確認す

る。

(クラス B,C)

5.8.2 

既知の残留異常の文書化 

製造業者は,残留している既知の異常を全て文書化する。(クラス B,C)

5.8.3 

既知の残留異常の評価 

製造業者は,残留している既知の異常を全て評価したことを確認し,受容できないリスクの原因になら

ないことを確実にする。

(クラス B,C)

5.8.4 

リリースしているバージョンの文書化 

製造業者は,リリースしているソフトウェア製品のバージョンを文書化する。(クラス A,B,C)

5.8.5 

リリースしたソフトウェアの作成方法の文書化 

製造業者は,リリースしたソフトウェアの作成手順及び作成環境を文書化する。(クラス B,C)

5.8.6 

アクティビティ及びタスクの完了確認 


18

T 2304

:2012 (IEC 62304:2006)

製造業者は,全てのアクティビティ及びタスクが,全ての関連する文書化とともに完了していることを

確認する。

(クラス B,C)

5.8.7 

ソフトウェアのアーカイブ 

製造業者は,次について,製造業者自身が決定した機器の耐用期間,又は関連する規制要求事項が規定

する期間の,いずれか長い方を最低保管期間として保管する。

(クラス B,C)

a)

ソフトウェア製品及び構成アイテム

b)

文書

5.8.8 

ソフトウェアリリースの反復性の確保 

製造業者は,リリースしたソフトウェア製品が,変造又は無断で変更されることなく使用する場所に確

実に納品されるようにするための手順を確立する。具体的には

ソフトウェア製品を格納した媒体の製造及

び取扱いについての手順であり,必要に応じて次のものを含める。

(クラス B,C)

−  複製

−  媒体のラベリング

−  こん(梱)包

−  保護

−  保管

−  納品

ソフトウェア保守プロセス 

6.1 

*ソフトウェア保守計画の確立 

製造業者は,保守プロセスのアクティビティ及びタスクを実行するためのソフトウェア保守計画を確立

する。計画の内容は,次による。

(クラス A,B,C)

a)

医療機器ソフトウェアのリリース後に発生する情報をフィードバックするための,次の手順

−  取得

−  文書化

−  評価

−  解決

−  追跡

b)

フィードバックした情報に問題があるかを判断するための基準

c)

ソフトウェア

リスクマネジメントプロセスの使用

d)

医療機器ソフトウェアのリリース後に発生した問題を分析,及び解決するためのソフトウェア問題解

プロセスの使用

e)

既存

システムの修正を管理するための,ソフトウェア構成管理プロセス(箇条 参照)の使用

f)

SOUP

について,次の事項を

評価し実行する手順

−  アップグレード

−  バグ修正

−  パッチ

−  陳腐化の確認

6.2 

*問題及び修正の分析 

6.2.1 

フィードバックの文書化及び評価 


19

T 2304

:2012 (IEC 62304:2006)

6.2.1.1 

フィードバックの監視 

製造業者は,リリースしたソフトウェア製品について,自身の組織内部及びユーザからのフィードバッ

クを監視する。

(クラス A,B,C)

6.2.1.2 

フィードバックの文書化及び評価 

フィードバックを文書化するとともにそれを

評価し,リリースしたソフトウェア製品に問題がないかを

判断する。問題があった場合は,

問題報告として記録する(箇条 参照)。問題報告には,実際に悪影響

を及ぼす又はその可能性のある事象,及び仕様から逸脱した事象を含める。

(クラス A,B,C)

6.2.1.3 

安全性に影響する問題報告の評価 

問題報告は,個々に評価を実施し,リリースしたソフトウェア製品の安全性にどのような影響があるか

を判断するとともに,問題に対処するためにリリースした

ソフトウェア製品に変更を加える必要があるか

を判断する。

(クラス A,B,C)

6.2.2 

ソフトウェア問題解決プロセスの使用 

製造業者は,問題報告の対処に当たり,ソフトウェア問題解決プロセス(箇条 参照)を使用する。

(クラス A,B,C)

注記  このアクティビティが完了した時点で,ソフトウェアシステム又はそのソフトウェアアイテム

の安全クラスの変更を明らかにしていることが望ましい。

6.2.3 

変更要求の分析 

製造業者は,箇条 で要求している分析を実施するほか,各変更要求が,組織,リリースしたソフトウ

ェア製品及び連携するシステムに及ぼす影響について分析を行う。(クラス B,C)

6.2.4 

変更要求の承認 

製造業者は,リリースしたソフトウェア製品に修正が生じる変更要求を評価し,承認する。(クラス A,

B,C)

6.2.5 

ユーザ及び規制当局への通知 

製造業者は,リリースしたソフトウェア製品に影響がある,承認済みの変更要求を明らかにする。

地域の法令の要求に応じて,

製造業者は,ユーザ及び規制当局に対して次の事項を通知する(クラス A,

B,C)

a)

リリースした

ソフトウェア製品についての全ての問題,及び変更せずに継続使用した場合の結果。

b)

リリースした

ソフトウェア製品に対して利用可能な変更の本質(nature),並びにそれらの変更の入手

及びインストールの方法。

6.3 

*修正の実装 

6.3.1 

確立したプロセスを使用した修正の実装 

製造業者は,ソフトウェア開発プロセス(箇条 参照)又は確立した保守プロセスを使用して,修正を

実装する。

(クラス A,B,C)

注記  ソフトウェア変更のリスクマネジメントに関わる要求事項については,7.4 参照。

6.3.2 

修正ソフトウェアシステムの再リリース 

製造業者は,5.8 に従って,修正したソフトウェアシステムをリリースする。修正版は,ソフトウェア

システムの完全再リリース版の一部としてリリースしてもよいし,変更したソフトウェアアイテム及びイ

ンストール用ツールからなる修正キットとしてリリースして,修正版の変更内容を既存の

ソフトウェアシ

ステムにインストールしてもよい。(クラス A,B,C)


20

T 2304

:2012 (IEC 62304:2006)

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

7.1 

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

7.1.1 

危険状態の一因となるソフトウェアアイテムの特定 

製造業者は,JIS T 14971 に規定した医療機器のリスク分析を行い,危険状態及び危険状態を引き起こす

可能性のある

ソフトウェアアイテムを特定する(4.2 参照)。(クラス B,C)

注記  危険状態は,ソフトウェアの故障が直接の原因となる場合,又はソフトウェアに実装したリス

クコントロール手段の故障が原因となる場合が考えられる。

7.1.2 

危険状態の一因となるソフトウェアアイテムの潜在的原因の特定 

製造業者は,7.1.1 で特定した危険状態の一因となるソフトウェアアイテムの,潜在的原因を特定する。

製造業者は,必要に応じて,次に挙げるような潜在的原因を検討する。(クラス B,C)

a)

誤った又は不完全な機能仕様

b)

特定した

ソフトウェアアイテムの,機能におけるソフトウェア不具合

c)

SOUP

に起因する,故障又は予期せぬ結果

d)

予測できないソフトウェア動作を引き起こす可能性のある,ハードウェアの故障又は他のソフトウェ

アの欠陥

e)

合理的に予見可能な誤使用

7.1.3 

公開された SOUP 異常リストの評価 

SOUP

に起因する故障又は予期せぬ結果が,危険状態の一因となる

ソフトウェアアイテムの潜在的原因

になっている場合,

製造業者は,当該医療機器に使用している SOUP アイテムのバージョンに関係する,

SOUP

アイテムの供給者が公開している

異常リストを最低限度として評価し,既知の異常のいずれかによ

って,危険状態の原因となる可能性があるイベントシーケンスが生じるかを判断する。

(クラス B,C)

7.1.4 

潜在的原因の文書化 

製造業者は,危険状態の一因となるソフトウェアアイテムの潜在的原因を,リスクマネジメントファイ

ルに文書化する(JIS T 14971 参照)。(クラス B,C)

7.1.5 

イベントシーケンスの文書化 

製造業者は,7.1.2 で特定した危険状態を引き起こす可能性のあるイベントシーケンスを,リスクマネジ

メントファイルに文書化する。(クラス B,C)

7.2 

リスクコントロール手段 

7.2.1 

リスクコントロール手段の選択 

製造業者は,リスクマネジメントファイルに文書で示した,危険状態の一因となるソフトウェアアイテ

ムの,潜在的原因のそれぞれについて,リスクコントロール手段を選択し,文書化する。(クラス B,C)

注記  リスクコントロール手段は,ハードウェア,ソフトウェア,動作環境又は取扱い説明書に実装

できる。

7.2.2 

ソフトウェアに実装するリスクコントロール手段 

リスクコントロール手段をソフトウェアアイテムの機能の一部として実装する場合,製造業者は,次の

事項を実施する。

(クラス B,C)

a)

リスクコントロール手段をソフトウェア要求事項に含める。

b)

リスクコントロール手段によってコントロールしているリスク

4)

の影響に基づいて,当該

ソフトウェ

アアイテムのソフトウェア安全クラスを分類する。

4)

  対応国際規格のハザードをリスクと訳した。


21

T 2304

:2012 (IEC 62304:2006)

c)

箇条 に従って

ソフトウェアアイテムを開発する。

注記  この要求事項は,JIS T 14971 のリスクコントロールの要求事項を詳細にしたものである。

7.3 

リスクコントロール手段の検証 

7.3.1 

リスクコントロール手段の実装の検証 

7.2

で文書化した

リスクコントロール手段を全て実装していることを検証し,その検証結果を文書化す

る。

(クラス B,C)

7.3.2 

新しいイベントシーケンスの文書化 

リスクコントロール手段をソフトウェアアイテムとして実装した場合,製造業者は,リスクコントロー

ル手段を評価して,危険状態を引き起こす可能性のある新たなイベントシーケンスを特定し,リスクマネ

ジメントファイルに文書化する。(クラス B,C)

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)

7.4.3 

分析に基づくリスクマネジメントアクティビティの実行 

製造業者は,これらの分析に基づき,7.17.2 及び 7.3 で定義した当該リスクマネジメントアクティビ

ティを実行する。(クラス B,C)

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

8.1 

*構成識別 

8.1.1 

構成アイテム識別手段の確立 

製造業者は,プロジェクトのために管理すべき構成アイテム及びそのバージョンを,一意に識別するた

めの仕組みを確立する。この仕組みには,他の

ソフトウェア製品又は SOUP 及び文書などを含む。(クラ

ス A,B,C)

8.1.2 SOUP

の特定 

現在使用中の SOUP

構成アイテム(標準ライブラリを含む。)のそれぞれについて,製造業者は,次を

文書化する。

(クラス A,B,C)


22

T 2304

:2012 (IEC 62304:2006)

a)

名称

b)

製造業者

c)

SOUP

を特定する識別子

注記  SOUP を特定する識別子の例として,バージョン,リリース年月日,パッチ番号,アップグレ

ードの識別子などが考えられる。

8.1.3 

システム構成文書の特定 

製造業者は,ソフトウェアシステムの構成要素である構成アイテム及びそのバージョン一式を文書化す

る。

(クラス A,B,C)

8.2 

*変更管理 

8.2.1 

変更要求の承認 

製造業者は,承認した変更要求に応じる場合に限り,構成アイテムを変更する。(クラス A,B,C)

注記 1  変更要求承認の決定が,変更管理プロセス又は他のプロセスの一部に不可欠となる場合があ

る。この細分箇条が要求するのは,変更の実装の前に変更の承認が必要ということだけであ

る。

注記 2  ライフサイクルの様々な段階で受け取る変更要求に対して,様々な受け入れプロセスを使用

できる。5.1.1 e)及び 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)

注記  この細分箇条が要求するのは,変更を検証することだけであり,検証が変更管理プロセスに不

可欠であるということを意味するものではない。

検証には,計画したプロセスを使用すること

が望ましい。5.1.1 e)及び 6.1 e)参照。

8.2.4 

変更のトレーサビリティを実現する手段の提示 

製造業者は,次を追跡できる監査証跡を作成する。(クラス A,B,C)

a)

変更要求

b)

当該

問題報告

c)

変更要求の承認

8.3 

*構成状態の記録 

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

る。

(クラス A,B,C)


23

T 2304

:2012 (IEC 62304:2006)

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

9.1 

問題報告の作成 

製造業者は,発見されたソフトウェア製品の問題ごとに問題報告を作成する。問題報告は,次のように

分類する。

(クラス A,B,C)

a)

タイプ

例 1  是正,予防又は新しい環境への適応

b)

適用範囲

例 2  変更の規模,影響を受ける機器の種類,影響を受ける適用対象の附属品,関連リソース,変

更時期

c)

深刻度

例 3  性能,安全又はセキュリティへの影響

注記  問題は,リリースの前後及び製造業者の組織内外を問わず発見される可能性がある。

9.2 

問題の調査 

製造業者は,次を実施する。(クラス A,B,C)

a)

問題を調査し,可能であれば原因を特定する。

b)

ソフトウェア

リスクマネジメントプロセス(箇条 参照)を用いて,その問題の安全性への関わりを

評価する。

c)

調査及び評価の結果を文書化する。

d)

問題の是正に必要な処置のための

変更要求を作成する,又は処置を行わない場合の正当な根拠を文書

化する。

注記  問題が安全性に関連がない場合,製造業者は,ソフトウェア問題解決プロセスに従って問題を

解決する必要はない。

9.3 

関係者への通知 

製造業者は,問題の存在を関係者に適宜通知する。(クラス A,B,C)

注記  問題は,リリースの前後及び製造業者の組織内外を問わず発見される可能性がある。製造業者

は,状況に応じて通知先関係者を決定する。

9.4 

変更管理プロセスの使用 

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

参照)

(クラス A,B,C)

9.5 

記録の保持 

製造業者は,問題報告の記録,及びその検証も含めた解決についての記録を保持する。

製造業者は,リスクマネジメントファイルを適宜更新する(7.4 参照)。(クラス A,B,C)

9.6 

問題の傾向分析 

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

9.7 

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

製造業者は,問題の解決を検証し,次の事項を判断する。(クラス A,B,C)

a)

問題を解決し,

問題報告を完了した。

b)

好ましくない傾向を改善した。

c)

変更要求を,適切なソフトウェア製品及びアクティビティに実装した。

d)

新たな問題が発生していない。


24

T 2304

:2012 (IEC 62304:2006)

9.8 

試験文書の内容 

製造業者は,変更の後に実施する,ソフトウェアアイテム及びシステムの試験,再試験,レグレッショ

ンテストに当たって,試験文書の中に次を含める。(クラス A,B,C)

a)

試験結果

b)

発見された

異常

c)

試験したソフトウェアの

バージョン

d)

関連するハードウェア及びソフトウェアテスト構成

e)

関連試験ツール

f)

試験実施日

g)

試験者の識別


25

T 2304

:2012 (IEC 62304:2006)

附属書 A

(参考)

この規格の要求事項の根拠

この規格の各箇条の根拠を,この

附属書に記載する。

A.1 

根拠 

この規格が第一に求めているのは,

医療機器ソフトウェアの開発及び保守が,一連のプロセスに従うと

ともに,患者及びその他の人への

リスクに対して適切なプロセスを選択することである。これは,ソフト

ウェアの試験を実施しただけでは,その使用が安全であると判断するには十分ではないという信念に基づ

いている。

この規格が要求する

プロセスは,次の 2 種類のカテゴリに分類できる。

−  ソフトウェアの各

ソフトウェアアイテムの動作に起因するリスクを評価するために必要となるプロセ

−  評価した

リスクに基づいて選択される,各ソフトウェアアイテムにソフトウェアの故障が発生する確

率を低い水準に抑えるために必要となる

プロセス

この規格は,最初のカテゴリは全ての

医療機器ソフトウェアに対して実施し,2 番目のカテゴリは選択

した

ソフトウェアアイテムに対して実施することを要求している。

したがって,この規格への適合性を示す場合は,ソフトウェアを含む危険状態を引き起こす可能性のあ

る,予見可能なイベントシーケンスの特定を行う

リスク分析を文書化して盛り込むことが望ましい(JIS T 

14971

参照)

。ソフトウェアに起因する危険状態

5)

[例えば,不適切な治療行為につながる可能性のある,

誤解を招く情報の提供に起因する危険状態

5)

]も,この

リスク分析に記載するのがよい。

5)

  対応国際規格のハザードを危険状態と訳した。

プロセスの最初のカテゴリの一部として要求する全てのアクティビティは,本文では“(クラス A,B,

C)”と記載し,ソフトウェアの分類に関係なく必要であることを示している。

次の場合,

アクティビティをクラス A,B,C のいずれにも要求している。

アクティビティが,リスクマネジメント又はソフトウェア安全クラス分類に関係する計画を策定する。

アクティビティのアウトプットが,リスクマネジメント又はソフトウェア安全クラス分類のインプッ

トとなる。

アクティビティが,リスクマネジメント又はソフトウェア安全クラス分類の一部である。

アクティビティが,管理システム,文書化システム又は記録管理システムを確立して,リスクマネジ

メント又はソフトウェア安全クラス分類を支援する。

アクティビティは,関係するソフトウェアのクラス分類が不明なときに通常実施する。

アクティビティが,関連するソフトウェアの現在のソフトウェア安全クラス分類を無効にするような

変更をもたらす。これには,リリース後の安全性に関わる問題の検出及び分析が含まれる。

その他の

プロセスは,ソフトウェア安全クラス B 又は C に分類されるソフトウェアシステム又はソフト

ウェアアイテムだけに要求している。これらのプロセスの一部として要求するアクティビティは,本文で

は“

(クラス B,C)

”又は“

(クラス C)

”と記載し,適用されるソフトウェアのクラス分類に応じて選択的

に要求することを示している。


26

T 2304

:2012 (IEC 62304:2006)

次の場合,

アクティビティは,クラス B 及び C のソフトウェアに選択的に要求される。

アクティビティが,設計,試験又はその他の検証を,より詳細に又はより厳密にすることを要求し,

ソフトウェアの信頼性を高める。

アクティビティが,クラス B 又は C に要求される別のアクティビティを支援する管理アクティビティ

である。

アクティビティが,安全性に関わる問題の是正を支援する。

アクティビティが,安全性に関わるソフトウェアの設計,実装,検証及びリリースの記録を作成する。

次の場合,

アクティビティは,クラス C のソフトウェアに選択的に要求される。

アクティビティが,設計,試験又はその他の検証を,より詳細に又はより厳密にすること若しくは特

定の問題点に注意を払うことを要求し,ソフトウェアの信頼性を更に高める。

なお,この規格で定義している全ての

プロセス及びアクティビティは,高品質ソフトウェアの開発

及び保守を確実に行うために有益なものとみなされていることに留意する。負傷又は健康障害

6)

の発

生の可能性がないと定義しているクラス A のソフトウェアの要求事項に,これらの

プロセス及びアク

ティビティの多くが含まれていないが,それらに価値がない,又はそれらを推奨しないということを

意味するものではない。負傷又は健康障害

6)

の発生の可能性がないソフトウェアの場合,主には

医療

機器の設計中に行う総合的な妥当性確認アクティビティによって,又はソフトウェアライフサイクル

の管理項目の幾つかを単純に実施することで,その

安全性及び有効性が容易に保証できるということ

を考慮した結果,これらのアクティビティを省略している(医療機器全体の妥当性確認は,この規格

の適用範囲外である。

6)

  対応国際規格のハザードを負傷又は健康障害と訳した。

A.2 

ソフトウェア安全クラス別要求事項のまとめ 

表 A.1 は,個々の要求事項がどのソフトウェア安全クラスを指定しているかをまとめている。

この表は,参考であり,便宜上示すにとどめる。個々の要求事項のためのソフトウェア安全クラスは,

本文で規定している。


27

T 2304

:2012 (IEC 62304:2006)

表 A.1−ソフトウェア安全クラス別要求事項のまとめ 

箇条及び細分箇条

クラス A

クラス B

クラス C

箇条 4  全ての要求事項

5.1

5.1.1

5.1.25.1.35.1.65.1.75.1.85.1.9

5.1.5

5.1.105.1.11

5.1.4

5.2

5.2.1

5.2.25.2.45.2.55.2.6

5.2.3

5.3

5.3.1

5.3.25.3.35.3.45.3.6

5.3.5

5.4

5.4.1

5.4.2

5.4.35.4.4

5.5

5.5.1

5.5.2

5.5.35.5.5

5.5.4

5.6

全ての要求事項

5.7

全ての要求事項

5.8

5.8.4

5.8.1

5.8.25.8.35.8.55.8.65.8.75.8.8

6.1

6.1

6.2

6.2.1

6.2.26.2.46.2.5

6.2.3

6.3

全ての要求事項

7.1

全ての要求事項

7.2

全ての要求事項

7.3

全ての要求事項

7.4

7.4.1

7.4.2

7.4.3

箇条 8  全ての要求事項

箇条 9  全ての要求事項

○:該当する

−:該当しない


28

T 2304

:2012 (IEC 62304:2006)

附属書 B

(参考)

この規格の適用についての指針

B.1 

適用範囲 

B.1.1 

目的 

この規格は,高品質で安全な

医療機器ソフトウェアを,常に製造する開発プロセスを示すことを目的と

している。この目的を達成するために,この規格では,信頼性の高い安全な

ソフトウェア製品を生産でき

る方法でソフトウェア開発が行われたということを確実にするために,最低限実施すべき

アクティビティ

及び

タスクを特定している。

この附属書は,この規格の要求事項の適用についての指針を規定したものであり,この規格の要求事項

に追加又は変更を加えるものではない。この附属書は,規格の要求事項をより明確に理解する目的で使用

できる。

ここで注意すべきは,この規格において,

アクティビティは,プロセスの中で定義している細分箇条で

あり,

タスクは,アクティビティの範囲内で定義している。例えば,ソフトウェア開発プロセスで定義し

ている

アクティビティは,ソフトウェア開発計画,ソフトウェア要求事項分析,ソフトウェアアーキテク

チャ設計,ソフトウェア詳細設計,ソフトウェアユニットの実装及び検証,ソフトウェア結合及び結合試

験,

ソフトウェアシステム試験並びにソフトウェアリリースである。これらのアクティビティに含まれる

タスクは,個別の要求事項である。

この規格は,特定の

ソフトウェア開発ライフサイクルモデルを要求するものではない。しかし,あるプ

ロセスへのインプットは,別のプロセスによって生じるため,この規格に適合することは,プロセス間の

依存性があるということを意味する。例えば,

ソフトウェアシステムの故障からどんな危害が生じるかを

リスク分析プロセスで確立した後に,ソフトウェアシステムのソフトウェア安全クラス分類を完了するこ

とが望ましい。

このように

プロセス間に論理的依存性があるため,この規格のプロセスは,“ウォータフォール”又は

“ワンススルー(once-through)”ライフサイクルモデルを示唆するシーケンスで説明するのが最も容易で

ある。しかし,他のライフサイクルモデルも使用可能である。JIS X 0160 [6]で定義している開発モデルに

は,次のようなものがある(

表 B.1 も参照)。

−  ウォータフォール:

“ウォータフォール”ともいわれる“ワンススルー(once-through)”モデルでは,

開発

プロセスを一度実施する。簡単にいえば,顧客ニーズの決定,要求事項の定義,システムの設計,

システムの実装,試験,修理及び出荷からなるモデルである。

−  繰返し(Incremental):

“繰返し”モデルでは,顧客ニーズの決定及び

システム要求事項の定義付けを

行い,その後,残りの開発を一連の版(build)ごとに行う。計画した仕様の一部を最初の版(build)

で組み込み,次の版(build)で更に仕様を追加し,

システム完成に至るまでこれを続ける。

−  進展的(Evolutionary)

“進展的”モデルもまた,版(build)での

システム開発であるが,ユーザの要

求が完全には理解されておらず,全ての要求事項を前もって定義することが不可能であるとの認識が

ある点で,繰返しモデルとは異なる。このモデルでは,顧客ニーズ及び

システム要求事項の定義を前

もって部分的に行い,次の版(build)で改良(refine)する。


29

T 2304

:2012 (IEC 62304:2006)

表 B.1JIS X 0160 の定義に従った開発ライフサイクルモデル 

開発モデル

最初に全ての要求事項
を定義するか

複数の開発サイクルか

暫定版ソフトウェアを
配布するか

ウォータフォール 
(ワンススルー)

する

該当せず

しない

繰返し(Incremental)

(事前計画された製品改良)

する

該当する

可能性あり

進展的(Evolutionary)

しない

該当する

する

どのライフサイクルモデルを選択する場合でも,仕様書,設計書,ソフトウェアなどの

プロセスアウト

プット間の論理的依存性を維持する必要がある。

これは,

ウォータフォールライフサイクルモデルの場合,

その

プロセスのためのインプットが完了し承認されるまで,プロセスの開始を延期することで達成する。

他のライフサイクルモデル,特に進展的(Evolutionary)ライフサイクルモデルでは,

プロセスアウトプ

ットを,当該

プロセスの全てのインプットが利用可能になる前に作成できる。例えば,新しいソフトウェ

アアイテムの仕様,分類,実装及び検証は,ソフトウェアアーキテクチャ全体が完成する前でも可能であ

る。このようなライフサイクルモデルには,一つの

プロセスアウトプットの変更又は開発によって,別の

プロセスアウトプットが無効になるというリスクが伴う。このため,全てのプロセスアウトプットを整合

させ依存性を維持するために,どのライフサイクルモデルにおいても包括的な構成管理システムを使用す

る。

次の原則は,使用する

ソフトウェア開発ライフサイクルモデルにかかわらず重要である。

−  全ての

プロセスアウトプットの整合性を維持することが望ましい。プロセスアウトプットを作成する

又は変更するときは,関連する全ての

プロセスアウトプットを直ちに更新して,相互の整合性を維持

し,この規格が明示的又は暗示的に要求している全ての依存性を維持することが望ましい。

プロセスアウトプットは,ソフトウェアについて更に作業するためのインプットとして必要なとき,

全てが利用可能になっていることが望ましい。

医療機器ソフトウェアをリリースする前の段階で,全てのプロセスアウトプットに相互に整合性があ

り,この規格が明示的又は暗示的に要求している

プロセスアウトプット間の依存性が,全てあること

が望ましい。

B.1.2 

適用範囲 

この規格は,

医療機器ソフトウェアの開発及び保守,並びに SOUP を含む医療機器の開発及び保守に適

用する。

この規格を使用する場合,

製造業者が医療機器について JIS T 14971 に適合するリスクマネジメントを

実施することを要求している。したがって,

医療機器のシステムアーキテクチャが,入手したコンポーネ

ント(購入したコンポーネント又は出所が不明なコンポーネント,例えば SOUP を含むプリンタ,プロッ

タなど)を含む場合,

製造業者は,入手したコンポーネントに対する責任者となり,これを医療機器のリ

スクマネジメント対象に含めなければならない。製造業者は,医療機器のリスクマネジメントを適切に実

施することで,コンポーネントについて理解し,それに SOUP が含まれていることを認識しているとみな

される。この規格を利用する

製造業者は,ソフトウェアリスクマネジメントプロセスを医療機器のリスク

マネジメントプロセスの一環として実施する。

リリースした

医療機器ソフトウェアの保守は,その生産後の技術的行為に適用する。ソフトウェア保守

は,監視行為を含めたあらゆる技術的及び管理的手段の組合せを含む。その目的は,アイテムを維持又は


30

T 2304

:2012 (IEC 62304:2006)

回復させるための行為を

問題報告に基づいて実施し,リリースしたソフトウェア製品に関連する修正要求

だけでなく,

ソフトウェア製品に要求されている機能を正しく実行できる状態にすることである。例えば,

問題是正,規制当局への報告,妥当性再確認,予防措置などが含まれる。JIS X 0161 [7]参照。

B.2 

引用規格 

ISO/IEC 90003 [9]

は,品質マネジメントシステムをソフトウェア開発に適用するための指針を示してい

る。この規格が要求する指針ではないが,強く推奨する。

B.3 

用語及び定義 

用語の定義には,可能な範囲で国際規格の定義を使用している。

この規格は,

ソフトウェアシステム(最上位レベル)の構造を説明する場合に,三つの用語を用いてい

る。

ソフトウェアシステムは,医療機器のサブシステム(IEC 60601-1-4 [11]参照)又はそれ自体が医療機

器であることがある。試験又はソフトウェア構成管理を目的にしたとき,それ以上分割することができな

い最下位レベルは,

ソフトウェアユニットである。最上位から最下位の構成レベルまで,全て含めてソフ

トウェアアイテムといえる。このようにソフトウェアシステムは,一つ以上のソフトウェアアイテムで構

成し,各

ソフトウェアアイテムは,一つ以上のソフトウェアユニット又は分割可能なソフトウェアアイテ

ムで構成する。ソフトウェアアイテム及びソフトウェアユニットの定義並びに粒度(granularity)を示す責

任は,

製造業者にある。これらの用語は,明確に定義していないため,医療機器に使用されるソフトウェ

アには多種多様な開発方法及びタイプが適用できる。

B.4 

一般要求事項 

いずれのソフトウェアについても,100 %の

安全を保証する既知の方法はない。

医療機器ソフトウェアの安全性を向上させる次の三つの大原則が存在する。

リスクマネジメント

−  品質マネジメント

−  ソフトウェアエンジニアリング

安全な

医療機器ソフトウェアの開発及び保守には,適切なソフトウェアエンジニアリングの方法及び技

術を適用する総合的フレームワークとして,品質マネジメントシステムに不可欠な

リスクマネジメントを

確立する必要がある。上記三つのコンセプトを組み合わせれば,

医療機器の製造業者の意思決定プロセス

が明確な体系をとり,首尾一貫した再現性のあるものとなり,

医療機器ソフトウェアの安全性が促進され

る。

B.4.1 

品質マネジメントシステム 

統制がとれ,かつ効果的な一連のソフトウェア

プロセスには,マネジメント,インフラストラクチャ,

改善,訓練などの系統的な

プロセスが含まれる。重複を避け,また,この規格の焦点をソフトウェアエン

ジニアリングに絞るため,これらの

プロセスは,この規格から外している。これらのプロセスは,品質マ

ネジメントシステムが対象とするところである。JIS Q 13485 [4]は,品質マネジメントのコンセプトを特

医療機器に応用するための規格である。ただし JIS Q 13485 の品質マネジメントシステム要求事項に適

合しても,それが自動的に法の要求事項に適合することにはならない。該当する規制要求事項に適合して

いるかを確認し,適合性を確立するのは,

製造業者の責任である。

B.4.2 

リスクマネジメント 


31

T 2304

:2012 (IEC 62304:2006)

ソフトウェア開発では,

リスクマネジメントアクティビティに十分に関与し,医療機器ソフトウェア関

連の合理的に予見可能な

ハザード

7)

を確実に考慮する。

7)

  対応国際規格のリスクをハザードと訳した。

このソフトウェア規格は,適切な

リスクマネジメントプロセスを定義するものではなく,医療機器のた

めの

リスクマネジメントを明確に扱っている規格,JIS T 14971 に適合するリスクマネジメントプロセスの

適用を

製造業者に要求する。ソフトウェアを一因とする危険状態

8)

に対して発生する,具体的なソフトウ

ェア

リスクマネジメントアクティビティについては,箇条 の対象プロセスに示す。

8)

  対応国際規格のハザードを危険状態と訳した。

B.4.3 

ソフトウェア安全クラス分類 

医療機器の一部,医療機器の附属品又は一つの医療機器としてのソフトウェアに関連するリスクは,ソ

フトウェア安全クラス分類の仕組みに対するインプットとして使い,この仕組みによってソフトウェアの

開発及び保守を行うときに使用する

プロセスを決定する。

リスクは,危害の発生確率とその危害の重大さとの組合せと定義される。しかし,従来の統計的手法で

は,ソフトウェアの故障が発生する確率をどのように決定するかについて意見の一致が得られていない。

そのため,この規格では,ソフトウェアの故障が発生すると仮定して,故障に起因する

危害

9)

の程度に基

づいて

ソフトウェアシステムの分類を行う。リスクコントロール手段の実装に寄与するソフトウェアシス

テムの分類は,コントロール対象の危害

9)

の程度に基づいている。

9)

  対応国際規格のハザードを危害と訳した。

ソフトウェアシステムをソフトウェアアイテムに分割した場合,ソフトウェアアイテムそれぞれにソフ

トウェア安全クラス分類を割り当てる。

ソフトウェアアイテムの故障に関連したリスクの判断は,次の場合に限り可能である。

システムアーキテクチャ及びソフトウェアアーキテクチャが,ソフトウェアアイテムの役割を,それ

自体の目的,並びに他のソフトウェア及びハードウェアアイテムとのインタフェースの観点で定義付

けている。

システムの変更を管理している。

アーキテクチャ及び指定されたリスクコントロール手段についてのリスク分析が完了している。

この規格は,全てのソフトウェアクラスについて前述の条件が整う,最低数の

アクティビティを要求し

ている。

ソフトウェアの

アーキテクチャアクティビティが終了するのは,ソフトウェアアイテム群全体を定義し,

リスクマネジメントアクティビティによってソフトウェアアイテムがどのように安全に関わるかが明確

になる,開発の最初の時点である。したがって,これは,

ソフトウェアアイテムの分類を安全上の役割に

応じて決定できる最初の時点である。

この時点は,JIS T 14971 において

リスクコントロールを開始する時点に対応する。

これに先立って,

リスクマネジメントプロセスによってアーキテクチャリスクコントロール手段が明確

になる。例えば,保護サブシステムの追加又は

危害の原因となるソフトウェアの故障の低減である。この

段階を過ぎると,

リスクマネジメントプロセスは,ソフトウェアアイテムの故障の確率を低減させること

を狙いとした

プロセスを使用する。つまり,ソフトウェアアイテムの分類が,そのアイテムに適用される

プロセスベースのリスクコントロール手段を特定する。

この時点以前にソフトウェアの分類を行うと,例えば,調査を実施する領域に焦点を絞ることができる

という点で

製造業者にとって好都合であると予想されるが,この分類は,予備的なものとして捉え,プロ


32

T 2304

:2012 (IEC 62304:2006)

セスの省略を正当化する目的に使わないことが望ましい。

ソフトウェア安全クラス分類の仕組みは,JIS T 14971 

リスクに合わせることを意図するものではない。

JIS T 14971

の仕組みでは,重大さ及び発生確率に応じて

リスクを分類しているが,ソフトウェア安全クラ

ス分類の仕組みでは,

ソフトウェアシステム及びソフトウェアアイテムを,開発及び保守で適用するプロ

セスに応じて分類している。

設計が進展するにつれ,新たな

リスクが判明してくる可能性がある。そのため,リスクマネジメントを,

開発

プロセスに不可欠な部分として適用することが望ましい。それによって,確実で安全に動作するため

に正確な機能が要求される

ソフトウェアアイテム,及び危害を引き起こす故障を防止するソフトウェアア

イテムを含む,全てのソフトウェアアイテムを特定するアーキテクチャ設計の開発が可能になる。

ソフトウェア

アーキテクチャが,安全な動作に要求されるソフトウェアアイテムの分離を促すとともに,

その

ソフトウェアアイテムを確実に効果的に分離するために使用する方法を説明付けることが望ましい。

B.3

に規定したとおり,この規格では,

ソフトウェアシステム(最上位レベル)の構成を説明する場合

に,三つの用語を用いる。

図 B.1 は,ソフトウェアシステムの中でのソフトウェアアイテムの分割の例,及び構成内のソフトウェ

アアイテム群にどのようにソフトウェア安全クラスが割り当てられるかを示す。

図 B.1−ソフトウェアアイテムの分割例 

この例では,

製造業者は,開発中の医療機器ソフトウェアのタイプから,ソフトウェアシステムの予備

的なソフトウェア安全クラス分類が,ソフトウェア安全クラス C であるということを理解している。

製造

業者は,ソフトウェアアーキテクチャの設計時に,システムを図のように三つのソフトウェアアイテム,

ソフトウェアシステム/

ソフトウェアアイテム

(クラスC)

ソフトウェアアイテム

X

(クラスA)

ソフトウェアアイテム

Y

(クラスC)

ソフトウェアアイテム

W

クラスB

ソフトウェアアイテム

Z

(クラスC)


33

T 2304

:2012 (IEC 62304:2006)

X,W,Z に分割することを決定した。製造業者は,死亡又は重傷を引き起こす可能性のある危険状態

10)

の要因となる全ての

ソフトウェアシステムを,ソフトウェアアイテム Z に分離し,重傷の可能性のない危

険状態

10)

の要因となる,残り全ての

ソフトウェアシステムをソフトウェアアイテム W に分離できる。ソ

フトウェアアイテム W は,ソフトウェア安全クラス B に分類され,ソフトウェアアイテム Z は,ソフト

ウェア安全クラス C に分類される。したがって,

ソフトウェアアイテム Y は,4.3 d)に従い,クラス C と

して分類する。

ソフトウェアシステムもまた,この要求事項に従ってソフトウェア安全クラス C にする。

ソフトウェアアイテム X は,ソフトウェア安全クラス A に分類された。製造業者は,分離の完全性を徹底

するために,

ソフトウェアアイテム X 及び Y 並びに W 及び Z について,分離の根拠を文書化できる。分

割が不可能な場合は,

ソフトウェアアイテム X 及び Y を,ソフトウェア安全クラス C に分類する。

10)

  対応国際規格のハザードを危険状態と訳した。

B.5 

ソフトウェア開発プロセス 

B.5.1 

ソフトウェア開発計画 

この

アクティビティの目的は,ソフトウェアに起因するリスクを低減するためのソフトウェア開発タス

クを計画し,開発チームのメンバに手順及び目標を周知し,医療機器ソフトウェアのシステム品質要求事

項に確実に適合することである。

ソフトウェア開発計画

アクティビティでは,タスクを単一の計画書又は複数の計画書で文書化すること

が可能である。

製造業者によっては,医療機器ソフトウェア全ての開発に適用する方針及び手順を既に確

立している可能性がある。その場合,計画は,単純に既存の方針及び手順を引用可能である。

製造業者に

よっては,各

医療機器ソフトウェア製品の開発に限定した,単一又は複数の計画書を作成する可能性もあ

る。この場合,固有の

アクティビティの内容を詳細に明記し,他は一般手順書を引用する。このほか,単

一又は複数の計画書を,

医療機器ソフトウェア製品それぞれの開発に合わせて調整する可能性もある。計

画は,開発

プロセスを実行するために必要なレベルまで詳細に定義し,リスクに比例したものにすること

が望ましい。例えば,

リスクが高いシステム又はアイテムは,開発プロセスをより厳密にする必要があり,

タスクは,より詳細に規定することが望ましい。

計画とは,繰り返し行うべき

アクティビティであり,開発が進むにつれて,再検討及び更新することが

望ましい。

システム及びシステム開発に必要なレベルの取組みについての理解が深まるにつれて,計画は,

より多くの,より十分な情報を包含したものへと発展できる。例えば,

リスクマネジメントプロセスの実

行及びソフトウェア

アーキテクチャの開発の結果,システムの当初のソフトウェア安全クラス分類が変わ

ることがあり得る。又は

システムに SOUP を組み入れる決定がなされる可能性もある。開発プロセスを適

切に管理できるよう,

システムについての最新知識,及びシステム又はシステムにおけるアイテムに必要

なレベルの厳密さについての最新知識を反映させ,計画を更新することが重要である。

B.5.2 

ソフトウェア要求事項分析 

この

アクティビティは,製造業者が医療機器ソフトウェアのソフトウェア要求事項を確立,検証するこ

とを要求する。何を構築するべきかの判断,

医療機器ソフトウェアが受容できる動作を示しているかの判

断,及び完成した

医療機器ソフトウェアが使用可能状態にあることを実証するためには,検証可能な要求

事項の確立が不可欠である。要求事項が要求どおりに実装されていることを実証するためには,要求事項

が正確に実装されているか否かを判断する客観的基準が確立できるような方法で,各要求事項を提示する

ことが望ましい。医療機器(device)の

リスクマネジメントプロセスにおいて,特定されたリスクを管理

するためにソフトウェアに要求事項が課されている場合,それらの要求事項をソフトウェア要求事項にお


34

T 2304

:2012 (IEC 62304:2006)

いて明確にすべきである。このとき,

リスクコントロール手段を追跡すると,ソフトウェア要求事項に帰

着できるような方法で明確にする。全てのソフトウェア要求事項は,要求事項と

ソフトウェアシステム試

験との間の

トレーサビリティが実証できるように明確にすることが望ましい。規制当局の承認に特定の規

制又は規格への適合が求められる場合は,この適合要求事項をソフトウェア要求事項において文書化する

ことが望ましい。ソフトウェア要求事項が何をソフトウェアに実装するかを定義するため,要求事項分析

アクティビティが完成する前に,要求事項を評価することが要求される。

顧客ニーズ,設計インプット,ソフトウェア要求事項,ソフトウェア機能仕様書及びソフトウェア設計

仕様書の区別には,しばしば混乱が見られる。設計インプットとは,顧客ニーズを解釈して正式に文書化

した

医療機器要求事項である。ソフトウェア要求事項とは,顧客ニーズ及び設計インプットに適合するた

めにソフトウェアが果たすべき役割を正式に文書化した仕様書である。ソフトウェア機能仕様書は,ソフ

トウェア要求事項に付随することが多く,要求事項に適合する代替ソフトウェアが数多く存在する可能性

があっても,要求事項に適合するためにソフトウェアが果たすべき役割を詳細に定義する。ソフトウェア

設計仕様書は,

ソフトウェアの要求事項及び機能仕様を実装するために,

ソフトウェアをどのように設計,

分割するかを定義する。

従来,ソフトウェア要求事項,機能仕様書及び設計仕様書は,一つ以上の文書のまとまりとして書かれ

てきた。現在はこの情報を共通データベース内のデータアイテムとして捉えることが可能である。各アイ

テムには,その目的とデータベースの他のアイテムとの関連が定義される属性が一つ以上ある。この手法

によって,各対象ユーザ(

製造業者,マーケティング担当者,試験者,監査員など)に最適な,様々な情

報の提示及び印刷が可能となり,実装の適切性及びテストケースによる要求事項の試験実施範囲を実証す

るための

トレーサビリティが確保されている。この手法の支援ツールには,リンク機能を用いた HTML 文

書のように単純なものから,CASE ツール及び要求事項分析ツールのような複雑で高度なものまである。

システム要求事項プロセスは,この規格の適用範囲外である。しかし,医療機器の機能をソフトウェア

を用いて実装するかは,通常

システム設計時に決定する。一部又は全てのシステム要求事項は,ソフトウ

ェアで実装するように割り当てられる。ソフトウェア要求事項分析

アクティビティは,システム要求事項

プロセスがソフトウェアに割り当てた要求事項を分析する作業,及び割り当てた要求事項を反映した広範

囲にわたるソフトウェア要求事項を抽出する作業からなる。

システムの完全性を確実にするために,製造業者は,親システムの要求事項及びソフトウェア要求事項

における非実用性,不整合性又は曖昧性を是正するために,

システム要求事項に対する変更及び明確化の

実現を協議できる仕組みを提供することが望ましい。

システム要求事項及びソフトウェア要求事項の収集及び分析のプロセスは,繰り返し行うことが可能で

ある。この規格は,その

プロセスを厳密に二層に分離させることを要求するものではない。実際には,シ

ステムアーキテクチャ及びソフトウェアアーキテクチャを同時に設計し,それに続いてシステム要求事項

及びソフトウェア要求事項を階層化された形で文書化することが多い。

B.5.3 

ソフトウェアアーキテクチャ設計 

この

アクティビティは,製造業者がソフトウェアの主要構造コンポーネント,外部に表れるコンポーネ

ントの特性及びその間の関係について定義することを要求している。あるコンポーネントの動作が他のコ

ンポーネントに影響を与える可能性がある場合は,その動作をソフトウェア

アーキテクチャで説明するこ

とが望ましい。この説明は,ソフトウェア外部の

医療機器のコンポーネントに影響を与え得る動作につい

て特に重要である。

アーキテクチャの決定は,リスクコントロール手段の実装に非常に重要である。他の

コンポーネントに影響を与える可能性があるコンポーネントの動作を理解(及び文書化)しなければ,


35

T 2304

:2012 (IEC 62304:2006)

ステムが安全であることを証明するのは不可能に近い。ソフトウェア要求事項の正確な実装を確実にする

ためには,ソフトウェア

アーキテクチャが必要である。ソフトウェアアーキテクチャは,指定したソフト

ウェアアイテムがソフトウェア要求事項の全てを実装しない限り,完全とはいえない。ソフトウェアの設

計及び実装は,

アーキテクチャに依存するため,このアクティビティを完了するにはアーキテクチャを検

証する。アーキテクチャの検証は通常,技術評価によって実施する。

ソフトウェア

アーキテクチャアクティビティでのソフトウェアアイテムの分類は,それに続くソフトウ

ェア

プロセスを選択する基準となる。分類の記録は,リスクマネジメントファイルの一部として変更管理

する。

引き続いて起こるイベントによっては,分類が無効になる可能性があることも多い。例えば,次のよう

なイベントが該当する。

システム仕様,ソフトウェア仕様又はアーキテクチャの変更

リスク分析のエラー,特に予見できないハザードの発見

−  要求事項,特に

リスクコントロール手段の実行不可能性の発見

したがって,ソフトウェア

アーキテクチャの設計に続く全てのアクティビティで,ソフトウェアシステ

ム及びソフトウェアアイテムの分類は,再評価することが望ましく,改訂が必要となる可能性もある。結

果,

ソフトウェアアイテムの分類が上位クラスに引き上げられることによって見直しが発生し,ソフトウ

ェアアイテムに追加プロセスを適用するに至る可能性がある。ソフトウェア構成管理プロセス(箇条 8

は,全ての必要な見直しを確定し完了させることを確認するために用いる。

B.5.4 

ソフトウェア詳細設計 

この

アクティビティは,製造業者がアーキテクチャで定義したソフトウェアアイテム及びインタフェー

スをリファインし,

ソフトウェアユニット及びそのインタフェースを作成することを要求する。ソフトウ

ェアユニットは,単一の関数又はモジュールとして考えることが多いが,この考え方は,常に適切である

わけではない。この規格では,

ソフトウェアユニットを,それ以上小さなアイテムに細分化できないソフ

トウェアアイテムと定義している。ソフトウェアユニットの試験は,ユニット単独で実行できる。製造業

者は,ソフトウェアユニットの詳細レベルを定義することが望ましい。詳細設計によって,アルゴリズム,

データ表記,異なった

ソフトウェアユニット間のインタフェース,及びソフトウェアユニットとデータ構

造間のインタフェースを定義する。詳細設計は,

ソフトウェア製品のこん(梱)包も考慮する。ソフトウ

ェアユニットを正確に実装できるように,各ソフトウェアユニット及びそのインタフェースの設計を文書

化する必要がある。詳細設計が,ソフトウェアを構築するために必要な詳細を補う。詳細設計は,プログ

ラマがその場しのぎの設計を行う必要がないよう,完全であることが望ましい。

ソフトウェアアイテムは,少数の新しいソフトウェアアイテムだけが元のソフトウェアアイテムの安全

関連要求事項を実装するように分割可能である。残りの

ソフトウェアアイテムは,安全関連機能を実装す

ることがなく,下位のソフトウェア安全クラスに再分類できる。しかし,これを実行する決定そのものが

リスクマネジメントプロセスの一環であり,これは,リスクマネジメントファイルで文書化する。

実装は,詳細設計に依存するため,

アクティビティの完了前に詳細設計を検証する必要がある。詳細設

計の

検証は,通常技術評価によって実施する。5.4.4 は,製造業者が詳細設計アクティビティのアウトプッ

トを検証することを要求している。設計が,要求事項をどのように実装するかを定義する。設計に欠陥が

あれば,コードは要求事項を正確に実装できない。

製造業者は,安全性にとって重要であると思われる設計特性が設計中に存在する場合は,設計特性を検

証することが望ましい。こうした設計特性の例としては,次のようなものがある。


36

T 2304

:2012 (IEC 62304:2006)

−  意図したイベント,インプット,アウトプット,インタフェース,論理フロー,CPU 負荷の配分,メ

モリの配分,エラー及び例外の定義並びに分離,エラーからの復帰処理の実装

−  危険状態を引き起こし得る全ての故障について,イベント及びその移行を伴う既定状態の定義

−  変数の初期化,メモリ管理

リスクコントロール手段に影響し得るコールド及びウォームリセット,待機並びに他の状態変化。

B.5.5 

ソフトウェアユニットの実装及び検証 

この

アクティビティは,製造業者がソフトウェアユニットのコードを作成し,検証することを要求する。

詳細設計は,ソースコードに変換される。コーディングは,仕様の分解が終了し,実行可能なソフトウェ

アの組み立てを開始する時点を表す。望ましいコード特性を一貫して実現するために,コーディング規約

において,適切なコーディングスタイルを規定することが望ましい。コーディング規約の例としては,分

かりやすさ,言語使用法又は制限,複雑性管理に対する要求事項がある。各ユニットのコードは,詳細設

計の定義どおりに機能すること,及び規定したコーディング規約に準拠することを確実にするために

検証

される。

5.5.5

は,

製造業者がコードを検証することを要求している。コードが正確に設計を実装していない場合,

医療機器ソフトウェアは,意図したとおりに機能しない。

B.5.6 

ソフトウェア結合及び結合試験 

この

アクティビティは,製造業者が,ソフトウェアアイテムをソフトウェアアイテムの上位集合体に結

合することに加え,

ソフトウェアユニットをソフトウェアアイテムの集合体に結合することを計画及び実

施し,結合後の

ソフトウェアアイテムが意図したとおりに作動するかを検証することを要求する。

この結合方法は,非繰返し結合から,様々な繰返し結合に及ぶ。アセンブルする

ソフトウェアアイテム

の特性によって,結合方法が決定される。

ソフトウェア結合試験では,

ソフトウェアアイテム内外のインタフェースを介したデータ転送及び制御

が重点的な対象となっている。外部インタフェースとは,オペレーティングシステムのソフトウェアを含

む他のソフトウェア及び

医療機器のハードウェアとのインタフェースである。

結合試験の厳密さ及び結合試験に関連する文書の詳細レベルは,次のものに見合うことが望ましい。す

なわち,機器に関連する

リスク,潜在的な危険を生じ得る機能に対する機器のソフトウェアへの依存度,

及び高

リスク機器の機能における特定のソフトウェアアイテムの役割である。例えば,全てのソフトウェ

アアイテムについて試験を実施することが望ましいが,安全に影響を及ぼすアイテムは,より直接的,徹

底的かつ詳細な試験を実施することが望ましい。

規定どおりに,結合試験によって,インプット及びアウトプット領域の境界におけるプログラムの動作

を実証し,無効なインプット,予期せぬインプット及び特殊なインプットにプログラムが反応することを

確認する。複数のインプットの組合せ又は予期せぬインプットシーケンスが与えられたとき,若しくは規

定したタイミング要求事項の違反が生じたときに,プログラムの実際の動作が明らかになる。計画書の試

験要求事項には,適宜結合試験の一環として実施するホワイトボックス試験を含めることが望ましい。

ホワイトボックス試験は,グラスボックス,構造,クリアボックス,オープンボックス試験としても知

られ,試験対象の

ソフトウェアアイテムの内部動作についての十分な知識を使用して試験データを選択す

る試験方法である。ホワイトボックス試験は,

ソフトウェアアイテムについての特定の知識を用いてアウ

トプットを調べる試験である。試験者が

ソフトウェアアイテムの使用目的を知っている場合にだけ,正確

な試験となる。試験者は,

ソフトウェアアイテムが意図した目的から逸脱していないかを確認できる。ホ

ワイトボックス試験は,

ソフトウェアアイテムの実装の試験が中心であるため,完全な仕様が実装されて


37

T 2304

:2012 (IEC 62304:2006)

いることを保証するとは限らない。ブラックボックス試験は,動作,機能,不透明ボックス,クローズド

ボックス試験としても知られ,機能仕様の試験が中心であるため,実装のあらゆる部分について試験済み

であることを保証するとは限らない。このようにブラックボックス試験は,仕様を確認するための試験で

あり,仕様の一部が適合していないことを示すことで,仕様漏れによる不具合を検出する。ホワイトボッ

クス試験は,実装を確認するための試験であり,実装の一部に誤りがあることを示すことで,動作の不具

合を検出する。

ソフトウェア製品に対して完全な試験を実施するためには,ブラックボックス試験及びホ

ワイトボックス試験の両方が要求される可能性がある。

5.6

及び 5.7 に示す計画書及び試験文書は,特定の開発フェーズ又は進展的(Evolutionary)プロトタイプ

に関連する個別の文書になる可能性がある。これらの文書を結合させて,単独の文書又はひとまとまりの

文書で複数の細分箇条の要求事項を対象とすることも可能である。また,上位のプロジェクト文書に,文

書の全て又は一部を組み入れることも可能である。上位のプロジェクト文書とは,ソフトウェア又はプロ

ジェクトの品質保証計画書,若しくはハードウェア及びソフトウェア試験のあらゆる点に対応した包括的

な試験計画書などである。この場合,様々なプロジェクト文書がどのように各ソフトウェア結合

タスクに

関連するかを記載した相互参照表を作成することが望ましい。

ソフトウェア結合試験は,模擬環境,実際のターゲットハードウェア又は

医療機器全体のいずれにおい

ても実施可能である。

5.6.2

は,

製造業者が,ソフトウェア結合アクティビティのアウトプットを検証することを要求している。

ソフトウェア結合

アクティビティのアウトプットとは,結合したソフトウェアアイテムである。結合した

ソフトウェアアイテムは,医療機器ソフトウェア全体が正確かつ安全に機能するよう適切に機能しなけれ

ばならない。

B.5.7 

ソフトウェアシステム試験 

この

アクティビティは,製造業者が,ソフトウェアの要求事項を正しく実装していることを検証するこ

とによって,ソフトウェアの機能を検証するよう要求している。

ソフトウェアシステム試験は,定義した機能が存在することを実証する。この試験によって,ソフトウ

ェアの要求事項に従って構築したプログラムの,機能性及び性能を

検証する。

ホワイトボックス手法(B.5.6 参照)を用いて,特定の試験の遂行,負荷条件又は故障の誘発,コードの

品質試験範囲の拡大を実現することが望ましいが,

ソフトウェアシステム試験では機能試験(ブラックボ

ックス試験)が集中的に行われる。タイプ及び試験段階ごとの試験の体系には柔軟性があるが,要求事項

の網羅性,

リスクコントロール,有用性及び試験タイプ(故障,インストール,負荷など)を実証及び文

書化することが望ましい。

ソフトウェアシステム試験は,結合したソフトウェアを試験するもので,模擬環境,実際のターゲット

ハードウェア又は

医療機器全体のいずれにおいても実施可能である。

ソフトウェアシステムを変更する場合(小さな変更であっても),(個々の変更の試験だけではない)レ

グレッションテストの実施の程度を決めて,意図しない副作用が発生していないことを確実にすることが

望ましい。この

レグレッションテスト(及びソフトウェアシステム試験全体を繰り返して行わない根拠)

は,計画し,文書化することが望ましい。

ソフトウェアシステム試験に対する責任は,分散させてもよく,異なる場所及び組織で実施可能である。

しかし,

タスクの実行組織,実行場所,契約関係,コンポーネントの出所又は開発環境にかかわらず,機

製造業者には,ソフトウェアが意図した用途に対して適切に機能することを徹底する最終責任がある。

試験中に発見された

異常が繰り返し発生する可能性があっても,それを修正しないことが決定されてい


38

T 2304

:2012 (IEC 62304:2006)

る場合,

リスク分析

11)

と関連付けてこの

異常を評価し,それが機器の安全性に影響しないことを検証する

必要がある。

異常の根本的原因及び兆候を理解し,修正しない根拠を文書化することが望ましい。

5.7.4

は,期待した結果が得られたことを確認するために,

ソフトウェアシステム試験の結果を評価する

ことを要求している。

11)

  対応国際規格のハザード分析をリスク分析と訳した。

B.5.8 

ソフトウェアリリース 

この

アクティビティは,製造業者が,リリースする医療機器ソフトウェアのバージョンを文書化し,ど

のように製造したかを明確にするとともに,そのソフトウェアのリリースに当たり適切な手順を踏むこと

を要求している。

製造業者は,開発プロセスを用いて開発したソフトウェアが,リリースするソフトウェアであることを

証明できることが望ましい。また,

製造業者は,ソフトウェア及びその生成に使用したツールを,今後必

要とされる場合に備え,回収可能にしておくことが望ましく,ソフトウェアの損傷又は誤使用が最小限に

抑えられるよう,ソフトウェアを保管,こん(梱)包及び出荷することが望ましい。これらの

タスクを適

切に一貫した結果を伴って実施することを確実にするために,定義付けした手順を確立することが望まし

い。

B.6 

ソフトウェア保守プロセス 

B.6.1 

ソフトウェア保守計画の確立 

ソフトウェア保守

プロセスは,次の 2 点でソフトウェア開発プロセスと異なる。

製造業者は,緊急の問題に対処して即急に変更を実装するため,完全な形のソフトウェア開発プロセ

スより小規模のプロセスを用いることが許されている。

製造業者は,リリースした製品に関連するソフトウェア問題報告を受けて問題に対処するだけでなく,

(主に,現場から問題データを収集するために市販後監視の仕組みを施行し,問題についてユーザ及

び規制当局と連絡をとることによって)法規制に適合させる。

6.1

は,保守計画の中でこれらの

プロセスを確立することを要求している。

この

アクティビティは,製造業者が保守アクティビティ及びタスクを実行するための手順を,考案又は

明確にすることを要求している。

製造業者は,是正措置を実行し,保守時に変更を管理し,改訂されたソ

フトウェアのリリースを管理することを目的に,ユーザから報告された問題及び要請を文書化して解決す

るとともに,

医療機器ソフトウェアの修正を管理することが望ましい。このプロセスは,ある問題を理由

として,又は改善,適合の必要性があるという理由から,

医療機器ソフトウェアのコード及び関連文書が

修正される場合に有効となる。その目的は,リリースした

医療機器ソフトウェアの完全性を維持しながら

これを修正することにある。この

プロセスは,医療機器ソフトウェアのリリース時には想定していなかっ

た環境又はプラットフォームへの移行を含む。この細分箇条に示した

アクティビティは,保守プロセス固

有のものではあるが,この規格の他の

プロセスを保守プロセスで使用してもよい。

製造業者は,保守プロセスのアクティビティ及びタスクをどのように実行するかを計画する必要がある。

B.6.2 

問題及び修正分析 

この

アクティビティは,製造業者が得たフィードバックの影響について分析し,報告された問題を検証

することを要求し,修正の選択肢の実装について検討,選択及び承認を得ることを要求している。問題及

びその他の変更要請は,

医療機器の性能,安全性又は法律上の認可に影響する可能性がある。問題報告に

よる何らかの影響が存在するか,又は問題を是正したり要請内容を実装したりするための修正によって影


39

T 2304

:2012 (IEC 62304:2006)

響が生じるかを判断するため,分析が必要である。ソフトウェア保守

アクティビティの一環として実装す

るソフトウェア変更によって,機器に組み込まれた

リスクコントロール手段が誤った形で変更又は修正さ

れないことを,トレース分析又はレグレッション分析を通して検証することが非常に重要である。また,

修正前には危険状態

12)

を引き起こす又は

リスクを軽減させることのなかったソフトウェアについて,修正

が原因で危険状態

12)

が生じる又は

リスクが軽減されることがないことを検証することも重要である。ソフ

トウェア修正で危険状態

12)

が生じる又は

リスクが軽減される可能性がある場合は,ソフトウェアアイテム

のソフトウェア安全クラス分類が変わっている可能性がある。

12)

  対応国際規格のハザードを危険状態と訳した。

ソフトウェア保守(箇条 6)とソフトウェア問題解決(箇条 9)とを区別することは,重要である。

ソフトウェア保守

プロセスにおいて焦点となるのは,ソフトウェア製品リリース後のフィードバックに

適切に対処することである。ソフトウェア保守

プロセスでは,医療機器の一部として次の事項を徹底する

必要がある。

安全に関連する問題報告について対応し,担当の規制当局及び影響を受けるユーザに対して報告をす

る。

ソフトウェア製品は,問題の是正及び更なる問題の回避を確実にするために,正式な管理の下で修正

した後,再確認して再リリースされる。

製造業者は,他のどのソフトウェア製品が影響を受け得るかを考慮し,適切な処置をする。

ソフトウェア問題解決において焦点となるのは,

次のような包括的マネジメントシステムの運用である。

問題報告を分析し,問題が示唆する事柄全てを明確にする。

−  変更の数を決定し,変更による全ての副作用を明確にする。

リスクマネジメントファイルを含むソフトウェア構成アイテムの一貫性を維持した上で,変更を実装

する。

−  変更の実装を

検証する。

ソフトウェア保守

プロセスでは,ソフトウェア問題解決プロセスを使用する。ソフトウェア保守プロセ

スでは,問題報告についての上層部での決定(問題が存在するか,問題が安全性に重大な影響を与えるか,

どのような変更が必要か,及び変更をいつ実装するか)を扱うとともに,ソフトウェア問題解決

プロセス

を用いて

問題報告分析を行い,引き起こされると思われる内容を全て検出し,変更を要する全ての構成ア

イテム,及び必要な全ての検証工程を明確にする,実行可能な変更要求を作成する。

B.6.3 

修正の実装 

この

アクティビティでは,製造業者が修正を行う場合に,確立したプロセスを使用することを要求して

いる。保守

プロセスを定義していない場合は,適切な開発プロセスタスクを使用して修正できる。さらに,

製造業者は,修正によって当該医療機器ソフトウェアの他の部分に副作用が生じないことを確実にするこ

とが望ましい。

医療機器ソフトウェアが新規の開発品として扱われていない場合は,修正が医療機器ソフ

トウェア全体に与える影響を分析する必要がある。医療機器ソフトウェアの修正対象外の部分は,修正前

と同じように機能するかを

レグレッションテストで確認するが,そのテストの量について根拠付けをする。

B.7 

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

ソフトウェア

リスクマネジメントは,医療機器リスクマネジメント全体の一部であり,分離した場合,

十分に扱うことはできない。この規格は,JIS T 14971 に適合する

リスクマネジメントプロセスを使用する

ことを要求している。JIS T 14971 で定義している

リスクマネジメントは,特に医療機器の使用に関連する


40

T 2304

:2012 (IEC 62304:2006)

リスクを効果的に管理するためのフレームワークを扱う。JIS T 14971 の一部は,リスク分析で確定した各

ハザードに関連する特定のリスクの管理に関係する。この規格のソフトウェアリスクマネジメントプロセ

スは,リスク分析で危険状態の潜在的な一因とされたソフトウェア又は医療機器のリスクマネジメントに

使用するソフトウェアなどの

リスクコントロールに要求事項を追加する。次の二つの理由から,ソフトウ

ェア

リスクマネジメントプロセスがこの規格に含まれている。

a)

この規格の利用者は,ソフトウェアという責任領域における

リスクコントロール手段の最低限の要求

事項を理解する必要がある。

b)

この規格に引用規格として示している,一般的な

リスクマネジメントを扱う規格 JIS T 14971 は,ソ

フトウェアの

リスクコントロール及びソフトウェア開発ライフサイクルへのリスクコントロール導入

について特に扱うものではない。

ソフトウェア

リスクマネジメントは,医療機器リスクマネジメント全体の一部である。ソフトウェアリ

スクマネジメントアクティビティに要求する計画書,手順書及び資料は,一連の個別の文書でも単独の文

書でもよく,この規格の要求事項全てに適合する限りにおいては,

医療機器リスクマネジメントのアクテ

ィビティ及び資料と統合させてもよい。

B.7.1 

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

医療機器(device)の

リスク分析

13)

によって,危険状態及び危険状態に対応する

リスクコントロール手

段が明確化され,危険状態の確率及び/又は重大さが受容可能なレベルにまで低減されることが期待され

る。また,

リスクコントロール手段を実装することを期待するソフトウェア機能に,リスクコントロール

手段が割り当てられることを期待する。

しかし,ソフトウェア

アーキテクチャの設計完了までに,全ての機器の危険状態を確定することは期待

できない。

アーキテクチャの設計完了時点では,ソフトウェア機能をどのようにソフトウェアコンポーネ

ントの中で実装するかが明らかになり,ソフトウェア機能に割り当てた

リスクコントロール手段の実用性

評価する。その時点で,医療機器のリスク分析

13)

を改訂して,次の事項を含めることが望ましい。

13)

  対応国際規格のハザード分析をリスク分析と訳した。

−  改訂された危険状態

−  改訂された

リスクコントロール手段及びソフトウェア要求事項

−  人的要因に関係した危険状態など,ソフトウェアから生じる新たな危険状態

ソフトウェア

アーキテクチャには,ソフトウェアコンポーネント間で危険な相互作用が起きないように

ソフトウェアコンポーネントを分離する確実な方針を含むのが望ましい。

B.8 

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

ソフトウェア構成管理

プロセスは,ソフトウェアライフサイクル全般にわたって管理手順及び技術的手

順を適用する

プロセスであり,文書を含むシステムにおけるソフトウェアアイテムの識別及び定義,アイ

テムの修正及びリリースの管理,並びにアイテム及び

変更要求の状況の文書化及び報告を行う。ソフトウ

ェア構成管理は,

ソフトウェアアイテムの再製作,その構成部分の確定及び実施した変更履歴の提供に必

要である。

B.8.1 

構成の識別 

この

アクティビティは,製造業者がソフトウェア構成アイテム及びそのバージョンを一意に識別するこ

とを要求する。この識別は,

医療機器ソフトウェアに含まれるソフトウェア構成アイテム及びバージョン

の識別に必要である。


41

T 2304

:2012 (IEC 62304:2006)

B.8.2 

変更管理 

この

アクティビティは,製造業者がソフトウェア構成アイテムの変更を管理するとともに,変更要求を

明確にし,その性質を記述するための情報を文書化するよう要求している。この

アクティビティは,ソフ

トウェア

構成アイテムに許可していない又は意図しない変更を決して加えることがなく,承認した変更要

求を完全に実装し検証することを確実にするために必要である。

変更要求は,変更管理委員会,又はマネージャ若しくは技術リーダーのいずれかが,ソフトウェア構成

管理計画に基づいて承認できる。承認した

変更要求は,ソフトウェアの実際の修正及び検証に対して追跡

可能なものにする。ここでの要求事項は,実際の変更それぞれが

変更要求と関連付けられ,変更要求が承

認されたことを示す文書が存在することである。この文書は,変更管理会議議事録,承認署名又はデータ

ベース上の記録であってもよい。

B.8.3 

構成状況の記録 

この

アクティビティは,製造業者がソフトウェア構成アイテムの履歴を保持することを要求している。

この

アクティビティは,変更がいつ,なぜ行われたかを判断するために必要である。この情報の入手は,

ソフトウェア

構成アイテムが認可された修正だけを含むことを確実にするために,必要である。

B.9 

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

ソフトウェア問題解決

プロセスは,問題の性質及び原因にかかわらず,問題(不適合を含む。)を分析し

解決する

プロセスであり,問題には,開発,保守又はその他のプロセスの実行時に発見されたものも含ま

れる。その目的は,適時の,責任を伴う文書化した手段によって,発見された問題を分析,解決し,その

傾向を認識するようにすることである。この

プロセスは,ソフトウェアエンジニアリングの文献で“欠陥

追跡”といわれることもある。JIS X 0160 [6]及び IEC 60601-1-4 [11]の Amd.1 では,

“問題解決”と規定し

ている。この規格では“ソフトウェア問題解決”と規定している。

この

アクティビティは,問題又は不適合が特定されたときに,製造業者がソフトウェア問題解決プロセ

スを使用することを要求している。このアクティビティは,発見された問題を,安全との関連性について

分析及び

評価することを確実にするために必要である(JIS T 14971 の規定)。

ソフトウェア開発計画又は手順は,5.1 で要求しているように,問題又は不適合の扱い方について検討す

る。これには,ライフサイクルの各段階で,文書化する正式なソフトウェア問題解決

プロセスの各側面を

明確にするとともに,問題及び不適合点をどの時点でソフトウェア問題解決

プロセスに取り入れるかを指

定することが含まれる。


42

T 2304

:2012 (IEC 62304:2006)

附属書 C 
(参考)

他の規格との関係

C.1 

一般 

この規格は,

医療機器ソフトウェアの開発及び保守を対象としている。ソフトウェアは,医療機器のサ

ブシステム又は

医療機器自体であるとみなされる。この規格は,医療機器の開発時に,他の適切な規格と

ともに使用する。

JIS Q 13485 [4]

C.2 及び

附属書 参照),JIS T 14971C.3 参照)などの医療機器マネジメント規格は,

組織が製品を開発するための基盤となる管理環境を規定している。IEC 60601-1 [10](C.4 参照)

JIS C 

1010-1 [1]

C.5 参照)などの安全規格は,安全な

医療機器を作り出すための具体的な指示を与える。ソフ

トウェアがこれらの

医療機器の一部である場合,この規格では,安全な医療機器ソフトウェアを開発し維

持するための要求事項について,より詳細な指示を与えている。この規格の要求事項を実装するために使

用する方法,ツール及び技術の情報源として,JIS X 0160 [6](C.6 参照)

IEC 61508-3 [13](C.7 参照)

ISO/IEC 90003 [9]

など,他の多くの規格を参照できる。

図 C.1 は,これらの規格とこの規格との関係を示

している。

他の規格から箇条又は要求事項を引用している場合,引用文内の用語は,引用元の他の規格で定義して

いる用語であり,この規格で定義しているものではない。

図 C.1−主要医療機器規格とこの規格との関係 

医療機器 
マネジメント規格 
JIS T 14971 
JIS Q 13485 

医療機器 
プロセス規格 
JIS T 2304 

他の規格 
JIS X 0160

IEC 61508-3

ISO/IEC 90003

など

医療機器製品規格 
IEC 60601-1 
JIS C 1010-1 

利用可能な追加の指針,技
術などを規定している

安全な

ソフトウェアシステム

の開発及び保守の仕方に関す
る詳細な指示を規定している

医療機器開発のための 
基礎を示す

安全な医療機器製造の 
ための具体的指示を規定 
している

医療機器 

ソフトウェア 

の実装

参  考

影  響

影  響

影  響


43

T 2304

:2012 (IEC 62304:2006)

C.2 

JIS Q 13485

との関係 

この規格は,

製造業者が品質マネジメントシステムを採用することを要求している。製造業者が JIS Q 

13485 [4]

を使用する場合,

表 C.1 に示すように,この規格の要求事項が JIS Q 13485 の要求事項の一部と

直接関係する。

表 C.1JIS Q 13485:2005 との関係 

この規格の箇条及び細分箇条

JIS Q 13485:2005

の関連箇条及び細分箇条

5.1 

ソフトウェア開発計画 7.3.1 

設計・開発の計画 

5.2 

ソフトウェア要求事項分析 7.3.2 

設計・開発へのインプット 

5.3 

ソフトウェアアーキテクチャの設計 

5.4 

ソフトウェア詳細設計 

5.5 

ソフトウェアユニットの実装及び検証 

5.6 

ソフトウェア結合及び結合試験 

5.7 

ソフトウェアシステム試験 7.3.3 

設計・開発からのアウトプット 

7.3.4 

設計・開発のレビュー 

5.8 

ソフトウェアリリース 7.3.5 

設計・開発の検証 

7.3.6 

設計・開発の妥当性確認 

6.1 

ソフトウェア保守計画の確立 7.3.7 

設計・開発の変更管理 

6.2 

問題及び修正の分析 

6.3 

修正の実装 7.3.5 

設計・開発の検証 

7.3.6 

設計・開発の妥当性確認 

7.1 

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

7.2 

リスクコントロール手段 

7.3 

リスクコントロール手段の検証 

7.4 

ソフトウェア変更のリスクマネジメント 

8.1 

構成識別 7.5.3 

識別及びトレーサビリティ 

8.2 

変更管理 7.5.3 

識別及びトレーサビリティ 

8.3 

構成状態の記録 

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

C.3 JIS 

14971

との関係 

表 C.2 は,JIS T 14971 で要求するリスクマネジメントプロセスの要求事項が,この規格で規定している

分野を示している。


44

T 2304

:2012 (IEC 62304:2006)

表 C.2JIS T 14971:2003 との関係 

JIS T 14971:2003

の箇条及び細分箇条

この規格の関連箇条及び細分箇条

4.1 

リスク分析手順 

4.2 

意図する使用/意図する目的及び医療機器の安全に

関する特質の明確化 

4.3 

既知又は予見できるハザードの特定 7.1 

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

4.4 

各ハザードに関するリスクの推定 4.3 

ソフトウェア安全クラス分類 

5. 

リスク評価 

6.1 

リスクの低減 

6.2 

リスクコントロール手段の選択 7.2.1 

リスクコントロール手段の選択 

6.3 

リスクコントロール手段の実施 7.2.2 

ソフトウェアに実装するリスクコントロール手段

7.3.1 

リスクコントロール手段の実装の検証 

6.4 

残留リスクの評価 

6.5 

リスク/効用分析 

6.6 

発生したその他のハザード 7.3.2 

新しいイベントシーケンスの文書化 

6.7 

リスク評価の完了 

7. 

残留リスクの全体的評価 

8. 

リスクマネジメント報告書 7.3.3 

トレーサビリティの文書化 

9. 

製造後の情報 7.4 

ソフトウェア変更のリスクマネジメント 

C.4 IEC 

60601-1:2005

の PEMS 要求事項との関係 

C.4.1 

一般 

ソフトウェア要求事項は,プログラマブル電気医用システム(PEMS)の要求事項のサブセットである。

この規格では,PEMS についての IEC 60601-1 [10]の要求事項に矛盾しない追加のソフトウェア要求事項を

規定している。PEMS にはソフトウェア以外の要素も含まれるため,PEMS についての IEC 60601-1 の要

求事項の全てをこの規格で扱っているわけではない。

C.4.2 

ソフトウェアと PEMS 開発との関係 

PEMS 開発の内容を説明した図 C.2 の V 字形モデルから,このソフトウェア規格の要求事項が,ソフト

ウェア要求事項の指定から,結合による

ソフトウェアアイテムのソフトウェアシステム化までの,PEMS

コンポーネントレベルで適用されるということが分かる。この

ソフトウェアシステムは,プログラマブル

電子サブシステム(PESS)の一部であり,このサブシステムは,PEMS の一部である。


45

T 2304

:2012 (IEC 62304:2006)

図 C.2字形モデルの一部としてのソフトウェア 

C.4.3 

開発プロセス 

この規格のソフトウェア開発

プロセス(箇条 5)に適合するためには,ソフトウェア開発計画を定めて,

それに従うことが要求される。これに当たって,ある特定のライフサイクルモデルの使用を要求されるこ

とはないが,計画に特定の

アクティビティ及び属性を含めることが要求される。これらの要求事項は,開

発ライフサイクル,要求事項の指定,

アーキテクチャ,設計及び実装,並びに検証についての IEC 60601-1

の PEMS 要求事項に関係している。ソフトウェア開発についてのこの規格の要求事項は,IEC 60601-1 

りも詳しい内容になっている。

C.4.4 

保守プロセス 

この規格のソフトウェア保守

プロセス(箇条 6)に適合するためには,ソフトウェアを変更するときの

手順を確立し,それに従うことが要求される。これらの要求事項は,PEMS の修正についての IEC 60601-1

の要求事項に対応している。この規格のソフトウェア保守についての要求事項は,ソフトウェア保守のた

めに必ず行われなければならない事項について,IEC 60601-1 の PEMS 修正の要求事項よりも詳しい内容

になっている。

C.4.5 

その他のプロセス 

この規格のその他の

プロセスでは,IEC 60601-1 にある PEMS についての類似要求事項以外の,追加の

ソフトウェア要求事項を規定している。ほとんどの場合,PEMS についての一般要求事項が IEC 60601-1

にあり,それを発展させたのがこの規格の

プロセスである。

 
ボックスは代表的な開発ライフサイクル

アクティビティ

実線矢印は

アクティビティから又はアクティビティへ転送される代表的な成果物

破線矢印は

リスクマネジメントファイルだけへの成果物

問題解決

プロセスへのインプット

問題解決

プロセスからのアウトプット

PEMS

要求事項の把握

顧客の要求

  ス

    ク

      分 
      析

PEMS

要求仕様

PEMS

アーキテクチャ仕様

PEMS

アーキテクチャ設計

サブシステム

(PESSなど)アー

キテクチャ設計

ソフトウェア要求仕様

(コンポーネント要求事項)

PEMS

V字形

モデルで 
この規格に 
含まれる部分

ソフトウェア

アーキテクチャ設計

(コンポーネント設計)

ソフトウェア

アーキテクチャ仕様

ソフトウェア

詳細設計

(ユニット設計)

ソフトウェア 
ユニット実装

ソフトウェア 
ユニット検証

(ユニット

検証)

結果

ユニット

検証

ソフトウェア結合及び 
ソフトウェアシステム 
検証(コンポーネント

結合及び

検証)

ソフトウェア試験仕様

ソフトウェア

結合及び 
検証結果

サブシステム

(PESSなど)

結合及び

検証

サブシステム

検証結果

検証済みコード

検証済みソフトウェアサブシステム(コンポーネント)

検証済みサブシステム

PEMS

検証結果

検証済みの

PEMS

PEMS

妥当性確認

PEMS

結合・

検証

妥当性確認済みの

PEMS

PEMS

妥当性確認

結果

PEMS妥当性確認計画

PEMS試験仕様

PEMS

検証計画

サブシステム試験仕様

 P

      E

     M

    S 
    結

  合

  求

    事

      項

        分 
        割

    リ

        ロ

      |

    ル 
    検

  証


46

T 2304

:2012 (IEC 62304:2006)

この規格のソフトウェア

リスクマネジメントプロセスは,IEC 60601-1 で特定している PEMS について

の補足的

リスクマネジメント要求事項に対応している。

この規格のソフトウェア問題解決

プロセスは,IEC 60601-1 の PEMS についての問題解決要求事項に対

応している。

この規格のソフトウェア構成管理

プロセスは,IEC 60601-1 の PEMS についての要求事項にはない,追

加の要求事項(文書化は除く。

)を規定している。

C.4.6 IEC 

60601-1

の PEMS 要求事項の範囲 

表 C.3 は,IEC 60601-1 の PEMS 要求事項及びそれに対応するこの規格の要求事項である。

表 C.3IEC 60601-1 との関係

IEC 60601-1:2005

の PEMS 要求事項

    PEMS のソフトウェアサブシステムに関係する, 
    この規格の要求事項

14.1 

一般

この要求事項は,次のいずれかを除いて PEMS に適用す
る。

− PESS が基礎安全又は基本性能を備えていない場合 
−  JIS T 14971 の適用によって,PESS の故障が受容で

きない

リスクを生じないことが実証できる場合

4.3 

ソフトウェア安全クラス分類

IEC 60601-1

の PEMS 要求事項は,ソフトウェア安全ク

ラス B 及び C にだけ適用される。この規格には,ソフト

ウェア安全クラス A の要求事項が幾つか含まれる。

14.2 

文書化 

JIS T 14971

が要求する記録及び文書に加えて,箇条 14

の適用から作成した文書は,保存し,また,

リスクマネ

ジメントファイルの一部とする。

4.2 

リスクマネジメント

箇条 14 で要求する文書は,正式な文書管理手順に従っ

て,検討,承認,発行及び変更する。

5.1 

ソフトウェア開発計画

ソフトウェア開発計画

アクティビティの特定の要求事

項に加え,

リスクマネジメントファイルの一部となる文

書を保持することも JIS T 14971 によって要求される。

さらに,品質システムが要求する文書は,JIS Q 13485 [4]
によって,その管理が要求される。

14.3 

リスクマネジメント計画

JIS T 14971

の 3.5 で要求する

リスクマネジメント計画

は,PEMS 妥当性確認計画への参照も含める(14.11 

照)

特定の要求事項はない。 
ソフトウェア妥当性確認計画は含まない。PEMS 妥当性
確認計画は,

システムレベルであり,このソフトウェア

規格の適用範囲外である。この規格では,

ハザードから,

リスクコントロール手段のための特定のソフトウェア
及び

リスクコントロール手段の検証までを追跡するト

レーサビリティが要求される(7.3 参照)。

14.4 PEMS

開発ライフサイクル

PEMS 開発ライフサイクルを,文書化する。

5.1 

ソフトウェア開発計画

5.1.1 

ソフトウェア開発計画

ソフトウェア開発計画で扱う項目は,ソフトウェア開発
ライフサイクルの一部とみなす。

PEMS 開発ライフサイクルには,規定した一連の管理ポ
イントを含める。

各管理ポイントにおいて,完了が必要な活動及びこれら
の活動に適用が必要な検証方法を規定する。

5.1.6 

ソフトウェア検証計画

検証タスク,マイルストーン及び合否判定基準を計画し
なければならない。

各活動は,インプット及びアウトプットを含め,規定す
る。

5.1.1 

ソフトウェア開発計画

アクティビティは,この規格で定義している。作成すべ
き文書は,

アクティビティごとに定義している。


47

T 2304

:2012 (IEC 62304:2006)

表 C.3IEC 60601-1 との関係(続き)

IEC 60601-1:2005

の PEMS 要求事項

    PEMS のソフトウェアサブシステムに関係する, 
    この規格の要求事項

各管理ポイントは,その管理ポイントに移る前に完了し
なければならない

リスクマネジメント活動を特定する。

PEMS 開発ライフサイクルは,詳細な活動,日程及び管
理ポイントを含めた計画を作成して,指定した開発に合
わせて作成する。

5.1.1 

ソフトウェア開発計画

この規格では,開発ライフサイクルの文書化は,開発計
画において行ってもよいとしている。したがって,開発
計画は,その開発に応じた開発ライフサイクルを含む。

PEMS 開発ライフサイクルには,文書化の要求事項を含
める。

5.1.1 

ソフトウェア開発計画

5.1.8 

文書化計画

14.5 

問題解決

該当する場合は,PEMS 開発ライフサイクルにおける全

ての段階及び活動の期間内及び期間外における問題解
決システムを開発し維持する。

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

製品の種類に従って,問題解決システムでは,次を行っ
てもよい。 
− PEMS 開発ライフサイクルの一部として,文書化す

る。

−  基礎安全又は基本性能に影響する潜在的若しくは既

存の問題の報告を認める。

−  関連する

リスクに対する各問題の評価を含める。

−  問題を解決済みとして処理するために適合しなけれ

ばならない基準を特定する。

−  各問題を解決するためにとるべき活動を特定する。

5.1.1 

ソフトウェア開発計画

9.1 

問題報告の作成

14.6 

リスクマネジメントプロセス

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

14.6.1 

既知及び予測可能なハザードの特定

既知又は予見可能な

ハザードを特定してリストを作成

する場合は,

製造業者は,ネットワーク/データ結合,

第三者製造のサブシステム及び継承したサブシステム
に関連するものを含んだ PEMS のソフトウェア,並びに
ハードウェアの側面に関連したこれらの

ハザードを考

慮する。

7.1 

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

この規格では,ネットワーク/データ結合については特
に触れていない。

14.6.2 

リスクコントロール

リスクコントロール手段を実行するために,適切に検

証された手法及び手順を選択し特定する。これらの手法
及び手順は,各

リスクコントロール手段が,特定された

リスクを十分に低減するのを保証する適切なものとす
る。

5.1.4 

ソフトウェア開発規格,方法及びツールの計画

この規格は,

リスクコントロール手段ごとではなく開発

一般に使用されるツール及び方法を特定することを要求
している。

14.7 

要求仕様 

PEMS 及びそのサブシステム(例えば,PESS に対する)
については,要求仕様を文書化する。

5.2 

ソフトウェア要求事項分析

この規格は,PEMS のソフトウェアサブシステムだけを
扱っている。

システム又はサブシステムに対する要求仕様は,そのシ
ステム又はサブシステムによって実施されるいかなる
基本性能及びいかなる

リスクコントロール手段をも含

める。

5.2.1 

システム要求事項からのソフトウェア要求事項の

定義及び文書化 
5.2.2 

ソフトウェア要求事項の内容

5.2.3 

リスクコントロール手段のソフトウェア要求事項

への包含 
この規格は,重要な性能及び

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

関わる要求事項を他の要求事項と区別することは要求し
ていないが,全ての要求事項が一意に識別できることは
要求している。


48

T 2304

:2012 (IEC 62304:2006)

表 C.3IEC 60601-1 との関係(続き)

IEC 60601-1:2005

の PEMS 要求事項

    PEMS のソフトウェアサブシステムに関係する, 
    この規格の要求事項

14.8 

アーキテクチャ

アーキテクチャは,PEMS 及びそのサブシステムのそれ
ぞれについて要求仕様に適合するように規定する。

5.3 

ソフトウェアアーキテクチャの設計

該当する場合は,アーキテクチャの仕様は,

リスクを受

容可能なレベルに低減するため,次の一つ以上を使用す
る。

a)

高信頼性部品

b)

フェールセーフ機能

c)

冗長性

d)

多様性

e)

機能の分割

f)

防御設計  例えば,使用可能な出力を制限すること

によって,又はアクチュエータの動き走行を制限す
る手段の導入によって,潜在的に危険な影響を抑制
する。

5.3.5 

リスクコントロールに必要な分離の特定

分割が唯一特定されている技術である。(分割の完全性
をどのように保証するかについて説明するという要求事

項があることが,唯一の特定理由である。

アーキテクチャの仕様には,次の g)n)を考慮する。

g) PEMS

のサブシステム及びコンポーネントに対する

リスクコントロール手段の配分

h)

コンポーネントの故障モード及びそれらへの影響

i)

共通原因による故障

j)

系統的な故障

k)

試験間隔及び診断範囲

l)

保守性

m)

合理的に予見できる誤使用に対する保護。

n)

該当する場合は,ネットワーク/データ結合の仕様

この規格には含まれない。

14.9 

設計及び実装

該当する場合は,設計をサブシステムに分割し,それぞ
れは,設計仕様及び試験仕様をもつ。

5.4 

ソフトウェア詳細設計 

5.4.2 

ソフトウェアユニットごとの詳細設計の開発

この規格では,

詳細設計に試験仕様書は要求していない。

設計環境に関する説明データは,

リスクマネジメントフ

ァイルに含める。

5.4.2 

ソフトウェアユニットごとの詳細設計の開発

14.10 

検証

検証は,基礎安全,基本性能又はリスクコントロール手
段を実施する全ての機能に対して要求する。

5.1.6 

ソフトウェア検証計画

アクティビティごとに検証を要求する。

検証計画は,どのようにこれらの機能を検証するかを示
すために作成する。計画には次の事項を含める。 
−  各機能に対してどの管理ポイントで検証を実施すべ

きか

−  検証方針,活動,技法,及び検証を実行する要員の

適切な独立性のレベルの選択及び文書化

−  検証手段の選択及び活用 
−  検証に対する適用範囲基準

5.1.6 

ソフトウェア検証計画

要員の独立性は,この規格に含まれていない。JIS Q 

13485

で網羅されているとみなしている。

検証は,検証計画に従って実施する。検証活動の結果は,
文書化する。

検証の要求事項は,大部分のアクティビティに入ってい
る。

14.11 PEMS

妥当性確認

PEMS 妥当性確認計画は,基礎安全及び基本性能を含め,
PEMS の意図していない機能に対しても調査する。

この規格は,ソフトウェア妥当性確認を扱っていない。
PEMS 妥当性確認は,システムレベルのアクティビティ
であり,この規格の適用範囲外である。


49

T 2304

:2012 (IEC 62304:2006)

表 C.3IEC 60601-1 との関係(続き)

IEC 60601-1:2005

の PEMS 要求事項

    PEMS のソフトウェアサブシステムに関係する, 
    この規格の要求事項

PEMS 妥当性確認は,PEMS 妥当性確認計画に従って実
施する。PEMS 妥当性確認活動の結果は,文書化する。

この規格は,ソフトウェア妥当性確認を扱っていない。
PEMS 妥当性確認は,システムレベルのアクティビティ
であり,この規格の適用範囲外である。

PEMS 妥当性確認に対して全体的な責任をもつ者は,設
計チームから独立したものとする。

製造業者は,独立性

のレベルに関する根拠を文書化する。

この規格は,ソフトウェア妥当性確認を扱っていない。
PEMS 妥当性確認は,システムレベルのアクティビティ
であり,この規格の適用範囲外である。

設計チームのいかなる要員も,彼ら自身の設計への
PEMS 妥当性確認を担当してはならない。

この規格は,ソフトウェア妥当性確認を扱っていない。
PEMS 妥当性確認は,システムレベルのアクティビティ
であり,この規格の適用範囲外である。

PEMS 妥当性確認チームの要員と設計チームの要員との
全ての職務上の関係を,

リスクマネジメントファイルに

文書化する。

この規格は,ソフトウェア妥当性確認を扱っていない。
PEMS 妥当性確認は,システムレベルのアクティビティ
であり,この規格の適用範囲外である。

PEMS 妥当性確認の方法及び結果に対する引用は,リス
クマネジメントファイルに含める。

この規格は,ソフトウェア妥当性確認を扱っていない。
PEMS 妥当性確認は,システムレベルのアクティビティ
であり,この規格の適用範囲外である。

14.12 

変更管理

設計結果の一部又は全てが,早期の設計の改良から生じ
たものである場合は,あたかもそれが新しい設計であっ

たかのようにこの箇条の全てを適用するか,又はいかな
る以前の設計文書にある継続した有効性も,文書化され
た修正・変更手順に従って評価する。

ソフトウェア保守プロセス

この規格では,ソフトウェア保守を計画し,修正の実装
にはソフトウェア開発

プロセス又は確立されたソフトウ

ェア保守

プロセスを使うのが望ましいという方針をとっ

ている。


50

T 2304

:2012 (IEC 62304:2006)

表 C.3IEC 60601-1 との関係(続き)

IEC 60601-1:2005

の PEMS 要求事項

    PEMS のソフトウェアサブシステムに関係する, 
    この規格の要求事項

14.13 

他の機器へのネットワーク/データ結合による

PEMS

の接続

PEMS 製造業者の管理外にあるその他の機器へのネット
ワーク/データ結合によって PEMS が接続されることを
意図している場合は,次の技術解説をする。

a) PEMS

がその意図する使用を達成するために必要な

ネットワーク/データ結合の特性の指定

b)

規定した特性を提供するネットワーク/データ結合
の故障から生じる危険状態のリスト

c)

責任部門への説明

−  その他の機器を含むネットワーク/データ結合へ

の PEMS の接続が,患者,操作者又は第三者に対

して事前に特定していなかった受容できない

リス

クを生じる危険性がある。

−  責任部門は,これらの受容できないリスクを特定,

分析,評価及び管理をすることが望ましい。

−  その後,ネットワーク/データ結合を変更した場

合は,新たな受容できない

リスクを招き,追加の

分析も必要となる。

−  ネットワーク/データ結合に対する変更には,次

を含める。

−  ネットワーク/データ結合における構成の変更 
−  ネットワーク/データ結合への追加機器の接続 
−  ネットワーク/データ結合からの機器の取外し 
−  ネットワーク/データ結合に接続した機器のアッ

プデート

−  ネットワーク/データ結合に接続した機器のアッ

プグレード

ネットワーク/データ結合の要求事項は,この規格に含
まれていない。

C.4.7 IEC 

60601-1-4

の要求事項との関係 

IEC 60601-1:2005

への移行期間が終了するまでは,IEC 60601-1-4 が引き続き使用される。

表 C.4 は,IEC 60601-1-4 [11]の要求事項及びこの規格内の関連要求事項である。ただし,この規格の関

連要求事項が,IEC 60601-1-4 の要求事項を全て網羅しているわけではない。IEC 60601-1-4 の要求事項の

多くは,JIS T 14971 に適合することで補われる。IEC 60601-1-4 の要求事項には,この規格で扱っていな

いものもある。


51

T 2304

:2012 (IEC 62304:2006)

表 C.4IEC 60601-1-4 との関係 

IEC 60601-1-4:1996

及び Amd.1:1999 の PEMS 要求事項

この規格の関連要求事項

6.8 

附属文書 

6.8.201 4.2

及び 4.3 c)

52.201 

文書化 

52.201.1 4.1

52.201.2 4.1

及び 4.2

52.201.3 4.2

52.202 

リスクマネジメント計画 

52.202.1 4.2

52.202.2 5.1.1

5.1.5

52.202.3 4.1

5.1.2

52.203 

開発ライフサイクル 

52.203.1 5.1.1

52.203.2 5.1.1

52.203.3 

52.203.4 5.1.7

52.203.5 

箇条 

52.204 

リスクマネジメントプロセス 

52.204.1 4.2

52.204.2 4.2

,箇条 7

52.204.3 

52.204.3.1 

52.204.3.1.1 4.2

7.1

52.204.3.1.2 4.2

7.1.2

52.204.3.1.3 4.2

52.204.3.1.4 4.2

7.1.2 e)

52.204.3.1.5 4.2

7.1.2

52.204.3.1.6 4.2

7.1

52.204.3.1.7 4.2

52.204.3.1.8 4.2

52.204.3.1.9 4.2

52.204.3.1.10 4.2

52.204.3.2 

52.204.3.2.1 4.2

52.204.3.2.2 4.2

4.3

52.204.3.2.3 

52.204.3.2.4 

52.204.3.2.5 4.2

52.204.4 

52.204.4.1 4.2

52.204.4.2 4.2

52.204.4.3 4.2

52.204.4.4 4.2

52.204.4.5 

52.204.4.6 4.2

52.205 

実施者の適任性 4.1

52.206 

要求仕様 


52

T 2304

:2012 (IEC 62304:2006)

表 C.4IEC 60601-1-4 との関係(続き) 

IEC 60601-1-4:1996

及び Amd.1:1999 の PEMS 要求事項

この規格の関連要求事項

52.206.1 5.2

52.206.2 7.2.2

52.206.3 

52.207 

アーキテクチャ 

52.207.1 5.3.1

52.207.2 5.3

52.207.3 

52.207.4 

52.207.5 

52.208 

設計及び実装 

52.208.1 

箇条 

52.208.2 

52.209 

検証 

52.209.1 5.7.1

52.209.2 5.1.5

5.1.6

52.209.3 5.2.6

5.3.65.4.45.5.55.65.7

52.209.4 

52.210 

妥当性確認 

52.210.1 4.1

52.210.2 4.1

52.210.3 4.1

52.210.4 

52.210.5 

52.210.6 

52.210.7 

52.211 

修正 

52.211.1 

箇条 

52.211.2 4.1

,箇条 6

52.212 

総合評価 

52.212.1 4.1

C.5 

JIS C 1010-1

との関係 

JIS C 1010-1 [1]

の適用範囲は,測定,制御及び研究室用電気機器である。研究室用機器は,医療環境に

おいて又は体外診断(IVD: In Vitro Diagnostic)機器として,一部が使用されているにとどまる。

法規制又は引用規格があるため,IVD 機器は,

医療機器として分類されるが,IEC 60601-1 [10]の適用範

囲外である。これは,IVD 機器が厳密には直接患者に接触する

医療機器ではないという理由のほか,その

ような製品が,各種の研究室での多種多様な用途のために製造されているという理由もある。IVD 機器又

は IVD 機器用附属品としての使用は,まれである。

研究室用機器を IVD 機器として使用する場合,医療基準に従って測定結果を

評価する。リスクマネジメ

ントについては,JIS T 14971 の適用が要求される。ソフトウェアに起因する医療データ(測定結果)の不

要な変更を引き起こす故障など,危険状態

14)

の原因になる可能性のあるソフトウェアがそのような製品に

含まれている場合は,この規格を考慮する。

14)

  対応国際規格のハザードを危険状態と訳した。


53

T 2304

:2012 (IEC 62304:2006)

図 C.3 のフローチャートは,リスクマネジメントプロセス及びこの規格の適用について分かりやすく説

明している。

図 C.3JIS C 1010-1 とこの規格の適用 

C.6 

JIS X 0160

との関係 

この規格は,JIS X 0160 [6]の様式及びコンセプトに基づいているが,JIS X 0160 

医療機器に限定した

ものではなく,ソフトウェアライフサイクル

プロセス一般の要求事項を定義している。

この規格は,特に次の点で JIS X 0160 と異なる。

システム要求事項,システムアーキテクチャ,妥当性確認などのシステム面を除外している。

医療機器を対象とする別文書にアクティビティが記載されているとして,それと重複しているとみな

される

プロセスを省略している。

リスクマネジメントプロセス及びソフトウェアリリースプロセスを追加している。

−  文書化及び

検証の補助プロセスを,開発及び保守のプロセスに組み入れている。

プロセス実装と各プロセスの計画アクティビティとを統合し,開発及び保守のプロセスの単独アクテ

意図する目的及び

用途を定義

考えられる

ハザード

の原因の特定

医療データ取扱い

に関連する

ハザード

既知の

ハザード及び

合理的に予知可能な

ハザードの特定

関連する安全

規格に従って検証

ハザードは

関連する安全規格の

適用を受けるか

医療目的で使用する 
前に誤データが検出

されるようにする 
ために必要となる

追加の要求事項

JIS T 14971

リスクマネジメント

に使用

この規格

を使用

機器は医療

関連データを提供

するものか

ソフトウェア

は医療データに影響

があるか

手順の使用

がデータ検証に要求

されているか

はい

はい

はい

いいえ

安全規格に基づき

リスクコントロール

のための適切な

方法を選択

はい

いいえ

いいえ

いいえ


54

T 2304

:2012 (IEC 62304:2006)

ィビティになっている。

安全性要求の観点から要求事項を分類している。

−  JIS X 0160 と違って,主

プロセス,補助プロセス,グループプロセスを明確に分類していない。

これらの変更点は,当該規格を次のような方法で

医療機器分野の要求に合わせようとする意図に基づい

ている。

安全面及び医療機器リスクマネジメント規格 JIS T 14971 に重点を置く。

−  規制環境における有用かつ適切な

プロセスを選択する。

−  ソフトウェア開発が,

JIS X 0160 

プロセス及び要求事項の一部を扱う)品質システムに組み込まれ

ることを考慮する。

−  曖昧さを抑えて,使いやすくする。

この規格は,JIS X 0160 と矛盾するものではない。JIS X 0160 は,この規格の要求事項を盛り込んだ,

うまく構造化された

ソフトウェア開発ライフサイクルモデルを設定するのに有用である。

表 C.5 は,ISO/IEC JTC1/SC7 が作成したもので,この規格と JIS X 0160 との関係を示している。

注記  JIS X 0160:1996 は,ISO/IEC 12207:1995 の国際一致規格であるが,Amendment 1(2002)及び

Amendment 2(2004)については,JIS X 0160:2007(追補 1)が対応している。

表 C.5JIS X 0160 との関係 

この規格のプロセス

JIS X 0160

のプロセス

アクティビティ 

タスク 

アクティビティ 

タスク 

箇条 5

ソフトウェア開発プロセス 5.3

開発プロセス

6.1  文書化プロセス 
6.2  構成管理プロセス 
6.4  検証プロセス 
6.5  妥当性確認プロセス 
6.8  問題解決プロセス 
7.1  管理プロセス

5.1  ソフトウェア開発
計画

 5.3.1

プロセス開始の準備

5.3.3  システム方式設計 
5.3.7  ソフトウェアコード作成及び
テスト 
5.3.8  ソフトウェア結合 
5.3.9  ソフトウェア適格性確認テス
ト 
5.3.10  システム結合 
6.1.1  プロセス開始の準備 
6.2.1  プロセス開始の準備 
6.2.2  構成識別 
6.4.1  プロセス開始の準備 
6.5.1  プロセス開始の準備 
6.8.1  プロセス開始の準備 
7.1.2  計画立案 
7.1.3  実行及び管理 
7.2.2  環境の構築 
7.2.3  環境の維持


55

T 2304

:2012 (IEC 62304:2006)

表 C.5JIS X 0160 との関係(続き) 

この規格のプロセス

JIS X 0160

のプロセス

アクティビティ 

タスク 

アクティビティ 

タスク 

 5.1.1

ソフトウェア開発計画 5.3.1

プロセス開始の準備

7.1.2  計画立案

5.3.1.1 
5.3.1.3 
5.3.1.4 
7.1.2.1

5.1.2  ソフトウェア開発計画の継続
更新

7.1.3  実行及び管理 7.1.3.3

5.1.3  ソフトウェア開発計画におけ
るシステム設計及びシステム開発
の引用

5.3.3  システム方式設計 
5.3.10  システム結合 
6.5.1  プロセス開始の準備

5.3.3.1 
5.3.10.1 
6.5.1.4

5.1.4  ソフトウェア開発規格,方法
及びツールの計画

5.3.1  プロセス開始の準備 5.3.1.3

5.3.1.4

5.1.5  ソフトウェア結合及び結合試
験計画

5.3.8  ソフトウェア結合 5.3.8.1

5.1.6  ソフトウェア検証計画 6.4.1

プロセス開始の準備

5.3.7  ソフトウェアコード作成及び
テスト 
5.3.8  ソフトウェア結合 
5.3.9  ソフトウェア適格性確認テス

6.4.1.4 
6.4.1.5 
5.3.7.5 
5.3.8.5 
5.3.9.3

5.1.7  ソフトウェアリスクマネジメ
ント計画

JIS X 0160:2007 – F.3.1.5

リスク管理 

5.1.8  文書化計画 6.1.1

プロセス開始の準備 6.1.1.1

5.1.9  ソフトウェア構成管理計画 6.2.1

プロセス開始の準備

6.8.1  プロセス開始の準備

6.2.1.1 
6.8.1.1

5.1.10  管理が必要な支援アイテム 7.2.2

環境の構築

7.2.3  環境の維持

7.2.2.1 
7.2.3.1

5.1.11  検証前のソフトウェア構成
アイテムのコントロール

6.2.2  構成識別 6.2.2.1

5.2  ソフトウェア要求
事項分析

 5.3.3

システム方式設計

5.3.4  ソフトウェア要求分析 
6.4.2  検証

5.2.1  システム要求事項からのソフ
トウェア要求事項の定義及び文書

5.3.3  システム方式設計 5.3.3.1

5.2.2  ソフトウェア要求事項の内容
5.2.3  リスクコントロール手段のソ
フトウェア要求事項への包含

5.3.4  ソフトウェア要求分析 5.3.4.1

5.2.4  医療機器のリスク分析の再評

なし

5.2.5  システム要求事項の更新 5.3.4

ソフトウェア要求分析 a)

b)

5.2.6  ソフトウェア要求事項の検証 5.3.4  ソフトウェア要求分析

6.4.2  検証

5.3.4.2 
6.4.2.3


56

T 2304

:2012 (IEC 62304:2006)

表 C.5JIS X 0160 との関係(続き) 

この規格のプロセス

JIS X 0160

のプロセス

アクティビティ 

タスク 

アクティビティ 

タスク 

5.3  ソフトウェアアー
キテクチャの設計

 5.3.5

ソフトウェア方式設計

5.3.1  ソフトウェア要求事項のアー
キテクチャへの変換

5.3.5.1

5.3.2  ソフトウェアアイテムのイン
タフェース用アーキテクチャの開

5.3.5  ソフトウェア方式設計

5.3.5.2

5.3.3  SOUP アイテムの機能及び性
能要求事項の指定

なし

5.3.4  SOUP アイテムが要求するシ
ステムハードウェア及びシステム
ソフトウェアの指定

なし

5.3.5  リスクコントロールに必要な
分離の特定

なし

5.3.6  ソフトウェアアーキテクチャ
の検証

5.3.5  ソフトウェア方式設計 5.3.5.6

5.4  ソフトウェア詳細
設計

 5.3.6

ソフトウェア詳細設計

6.4.2  検証

5.4.1  ソフトウェアアーキテクチャ
のソフトウェアユニットへの分解

5.3.6.1

5.4.2  ソフトウェアユニットごとの
詳細設計の開発

5.4.3  インタフェース用詳細設計の
開発

5.3.6  ソフトウェア詳細設計

5.3.6.2

5.4.4  詳細設計の検証 6.4.2

検証 5.3.6.7

5.5  ソフトウェアユニ
ットの実装及び検証

 5.3.6

ソフトウェア詳細設計

5.3.7  ソフトウェアコード作成及び
テスト 
6.4.2  検証

5.5.1  各ソフトウェアユニットの実

5.3.7  ソフトウェアコード作成及び
テスト

5.3.7.1

5.5.2  ソフトウェアユニット検証プ
ロセスの確立

5.3.6  ソフトウェア詳細設計 
5.3.7  ソフトウェアコード作成及び
テスト

5.3.6.5 
5.3.7.5

5.5.3  ソフトウェアユニットの合否
判定基準

5.3.7  ソフトウェアコード作成及び
テスト

5.3.7.5

5.5.4  追加のソフトウェアユニット
合否判定基準

5.3.7  ソフトウェアコード作成及び
テスト 
6.4.2  検証

5.3.7.5 
6.4.2.5

5.5.5  ソフトウェアユニットの検証 5.3.7  ソフトウェアコード作成及び

テスト

5.3.7.2


57

T 2304

:2012 (IEC 62304:2006)

表 C.5JIS X 0160 との関係(続き) 

この規格のプロセス

JIS X 0160

のプロセス

アクティビティ 

タスク 

アクティビティ 

タスク 

5.6  ソフトウェア結合
及び結合試験

 5.3.8

ソフトウェア結合

5.3.9  ソフトウェア適格性確認テス
ト 
5.3.10  システム結合 
6.4.1  プロセス開始の準備 
6.4.2  検証

5.6.1  ソフトウェアユニットの結合 5.3.8  ソフトウェア結合 5.3.8.2 
5.6.2  ソフトウェア結合の検証 5.3.8

ソフトウェア結合

5.3.10  システム結合

5.3.8.2 
5.3.10.1

5.6.3  結合したソフトウェアの試験 5.3.9  ソフトウェア適格性確認テス

5.3.9.1 

5.6.4  結合試験の内容

5.3.9.3

5.6.5  結合試験手順の検証 6.4.2

検証 6.4.2.2

5.6.6  レグレッションテストの実施 5.3.8  ソフトウェア結合 5.3.8.2 
5.6.7  結合試験記録の内容 5.3.8

ソフトウェア結合 5.3.8.2

5.6.8  ソフトウェア問題解決プロセ
スの使用

6.4.1  プロセス開始の準備 6.4.1.6

5.7  ソフトウェアシス
テム試験

 5.3.8

ソフトウェア結合

5.3.9  ソフトウェア適格性確認テス
ト 
6.4.1 プロセス開始の準備 
6.4.2  検証 
6.8.1  プロセス開始の準備

5.7.1  ソフトウェア要求事項につい
ての試験の確立

5.3.8  ソフトウェア結合 
5.3.9  ソフトウェア適格性確認テス

5.3.8.4 
5.3.9.1

5.7.2  ソフトウェア問題解決プロセ
スの使用

6.4.1 プロセス開始の準備 6.4.1.6

5.7.3  変更後の再試験 6.8.1

プロセス開始の準備 6.8.1.1

5.7.4  ソフトウェアシステム試験の
検証

6.4.2  検証 
5.3.9  ソフトウェア適格性確認テス

6.4.2.2 
5.3.9.3

5.7.5  ソフトウェアシステム試験記
録の内容

5.3.9  ソフトウェア適格性確認テス

5.3.9.1


58

T 2304

:2012 (IEC 62304:2006)

表 C.5JIS X 0160 との関係(続き) 

この規格のプロセス

JIS X 0160

のプロセス

アクティビティ 

タスク 

アクティビティ 

タスク 

5.8  ソフトウェアリリ
ース

 5.3.9

ソフトウェア適格性確認テス

ト 
5.4.2  運用テスト 
6.2.5  構成評価 
6.2.6  リリース管理及び出荷

5.8.1  ソフトウェア検証の完了確認 5.4.2  運用テスト

6.2.6  リリース管理及び出荷

5.4.2.1 
5.4.2.2 
6.2.6.1

5.8.2  既知の残留異常の文書化 
5.8.3  既知の残留異常の評価

6.2.5  構成評価 
5.3.9  ソフトウェア適格性確認テス

6.2.5.1 
5.3.9.3

5.8.4  リリースしているバージョン
の文書化 
5.8.5  リリースしたソフトウェアの
作成方法の文書化 
5.8.6  アクティビティ及びタスクの
完了確認 
5.8.7  ソフトウェアのアーカイブ

5.8.8  ソフトウェアリリースの反復
性の確保

6.2.6  リリース管理及び出荷 6.2.6.1

箇条 6

ソフトウェア保守プロセス 5.5

保守プロセス

6.2  構成管理プロセス

6.1  ソフトウェア保守
計画の確立

 5.5.1

プロセス開始の準備 5.5.1.1

6.2  問題及び修正の分

 5.5.1

プロセス開始の準備

5.5.2  問題把握及び修正分析 
5.5.3  修正の実施 
5.5.5  移行

 6.2.1

フィードバックの文書化及び

評価

6.2.1.1  フィードバックの監視 5.5.1.1

5.5.1.2

6.2.1.2  フィードバックの文書化及
び評価

5.5.1  プロセス開始の準備

6.2.1.3  安全性に影響する問題報告
の評価

5.5.2  問題把握及び修正分析 5.5.2.1

5.5.2.2 
5.5.2.3 
5.5.2.4

6.2.2  ソフトウェア問題解決プロセ
スの使用

5.5.1  プロセス開始の準備 5.5.1.2

6.2.3  変更要求の分析 5.5.2

問題把握及び修正分析 5.5.2.1

6.2.4  変更要求の承認 5.5.2

問題把握及び修正分析 5.5.2.5

6.2.5  ユーザ及び規制当局への通知 5.5.3  修正の実施

5.5.5  移行

5.5.3.1 
5.5.5.3


59

T 2304

:2012 (IEC 62304:2006)

表 C.5JIS X 0160 との関係(続き) 

この規格のプロセス

JIS X 0160

のプロセス

アクティビティ 

タスク 

アクティビティ 

タスク 

6.3  修正の実装

5.5.3

修正の実施

6.2.6  リリース管理及び出荷

 6.3.1

確立したプロセスを使用した

修正の実装

5.5.3  修正の実施 5.5.3.2

 6.3.2

修正ソフトウェアシステムの

再リリース

6.2.6  リリース管理及び出荷 6.2.6.1

箇条 7

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

JIS X 0160:2007

−F.3.1.5

リスク管理

この規格のプロセスは,JIS X 0160:2007 で扱われて
いないリスク/ハザードの課題を扱う。共通性はあ

るが,分析の焦点はかなり異なっている。

箇条 8

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

保守プロセス

6.2  構成管理プロセス

8.1  構成識別

6.2.2

構成識別

 8.1.1

構成アイテム識別手段の確立

6.2.2  構成識別 6.2.2.1

8.1.2 SOUP の特定

なし

8.1.3  システム構成文書の特定 6.2.2

構成識別 6.2.2.1

8.2  変更管理

5.5.3

修正の実施

6.2.3  構成制御

8.2.1  変更要求の承認 6.2.3

構成制御 6.2.3.1

8.2.2  変更の実装 5.5.3

修正の実施

6.2.3  構成制御

5.5.3.2 
6.2.3.1

8.2.3  変更の検証

8.2.4  変更のトレーサビリティを実
現する手段の提示

6.2.3  構成制御 6.2.3.1

8.3  構成状態の記録

6.2.4

構成状況の記録 6.2.4.1

箇条 9

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

保守プロセス

6.2  構成管理プロセス 
6.8  問題解決プロセス

9.1  問題報告の作成

6.8.1

プロセス開始の準備

6.8.2  問題解決

6.8.1.1 b) 
6.8.2.1

9.2  問題の調査

6.8.2

問題解決

6.8.1  プロセス開始の準備

6.8.2.1 
6.8.1.1 b)

9.3  関係者への通知

6.8.1

プロセス開始の準備 6.8.1.1

a)

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

 6.2.3

構成制御

5.5.3  修正の実施

9.5  記録の保持

6.8.1

プロセス開始の準備 6.8.1.1

a)

9.6  問題の傾向分析

6.8.1

プロセス開始の準備

6.8.2  問題解決

6.8.1.1 b) 
6.8.2.1

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

 6.8.1

プロセス開始の準備 6.8.1.1

d)

9.8  試験文書の内容

JIS X 0160

試 験 タ ス ク 全

てで,文書化が
要求される。


60

T 2304

:2012 (IEC 62304:2006)

C.7 IEC 

61508

との関係 

安全性が重要なソフトウェアの設計に関わるため,この規格が,IEC 61508 の原則に従うのが望ましい

か否かが論点になっている。次に,この規格の立場を説明する。

IEC 61508

では,次の三つの課題を扱っている。

1)

リスクマネジメントライフサイクル及びライフサイクルプロセス

2)

安全度水準の定義

3)

ソフトウェア開発のための技術,ツール及び方法の推奨,並びに各種

タスクの実施責任者の独立性水

準の推奨

この規格は,課題 1)を JIS T 14971

リスクマネジメントについての医療機器分野の規格)の引用で補っ

ている。この引用によって,

リスクマネジメントについての JIS T 14971 の趣旨が,医療機器ソフトウェ

ア対象のソフトウェアプロセスの不可欠な要素として採用された形になっている。

課題 2)については,この規格の方が IEC 61508 よりも単純な取組みをしている。IEC 61508 においては,

ソフトウェアは,目標とする信頼性の観点で定義した四つの“安全度水準”に分類されている。目標とす

る信頼性は,

リスク分析に特定されるが,このリスク分析は,ソフトウェアの故障によって生じる危害に

ついて,重大性及び確率の両方を推定する。

この規格では,

ソフトウェアの故障確率を分類前の段階では考慮することができないようにすることで,

課題 2)を簡略化している。3 種類のソフトウェア安全クラスへの分類は,故障を原因とする

危害の重大度

だけが基準になっている。分類後,ソフトウェア安全クラスごとに,異なる

プロセスを要求する。この要

求の意図は,ソフトウェアの故障確率を更に低くすることである。

課題 3)は,この規格では扱っていない。規格の利用者に対しては,望ましいソフトウェア技法,技術及

びツールの情報源として IEC 61508 を使用することを奨励している。ただし,現存するものと今後出てく

るものを含め,別の手法でも同等の結果が得られる可能性があることも承知の上で使用することを勧めて

いる。この規格では,あるソフトウェア

アクティビティ(例えば検証)の責任者とそれ以外のアクティビ

ティ(例えば設計)の責任者の独立性について推奨はしていない。特に,独立した安全性評価者について

は JIS T 14971 で扱うものとなるため,この規格では要求事項がない。


61

T 2304

:2012 (IEC 62304:2006)

附属書 D 
(参考)

実装

D.1 

序文 

この

附属書は,この規格を製造業者のプロセスにどのように実装できるかについて概説している。また,

JIS Q 13485 [4]

のような他の規格が,この規格と同等の適切な

プロセスを要求している点も,この附属書

では考慮している。

D.2 

品質マネジメントシステム 

この規格に関連する

医療機器ソフトウェアも含めて,医療機器の製造業者は,4.1 で品質マネジメント

システム(QMS)の確立を要求されている。この規格は,QMS の認証が必ず必要であるということを要

求するものではない。

D.3 

品質管理プロセスの評価 

確立し,文書化した QMS の

プロセスが,ソフトウェアライフサイクルのプロセスに既にどの程度対応

できているかについて,

製造業者の責任の下に監査,調査又は分析することによって,評価するよう推奨

している。不足部分を確認した場合は,品質管理

プロセスを拡大して対応する,又は個別に説明して対応

できる。

製造業者が,ソフトウェアの開発,検証及び妥当性確認の統制をはかるプロセス記述を既に持ち

合わせている場合,どの程度この規格と一致するかを

評価することが望ましい。

D.4 

この規格の要求事項と製造業者の品質管理プロセスとの統合 

QMS に,既に導入しているプロセスを適応若しくは拡大させるか,又は新しいプロセスを統合させるこ

とで,この規格を実施できる。それをどのように行うべきかについては,この規格では規定していない。

したがって

製造業者は,適切な方法で自由に行うことができる。

製造業者は,文書化した独自の QMS をもたない相手先商標製品製造業者(OEM)又は外部委託契約者

にその

医療機器ソフトウェアの開発を任せた場合,規格で説明しているプロセスが適切に実行に移される

ことを確実にする責任がある。

D.5 

認証 QMS がない小規模製造業者のためのチェックリスト 

製造業者が,ソフトウェアのソフトウェア安全クラス(A,B 又は C)を分類する場合,最もリスクの

高いものに決定するのが望ましい。

表 D.1 は,この規格で説明しているアクティビティを全て列挙してい

る。JIS Q 13485 を参照すれば,QMS における位置付けを明らかにするのに役立つ。

製造業者は,要求さ

れるソフトウェア安全クラスに基づき,各要求

アクティビティを既存プロセスと突き合わせて総合評価す

るのがよい。要求事項が既に盛り込まれている場合は,該当する

プロセス記述の参照先を示すのが望まし

い。

矛盾がある場合は,

プロセス改善のための措置が必要である。

この一覧表は,改善措置実施後の

プロセスを対象とした評価にも使うことができる。


62

T 2304

:2012 (IEC 62304:2006)

表 D.1−認証 QMS がない小規模会社のためのチェックリスト 

アクティビティ JIS 

13485:2005

関連箇条

既存手順で

補われているか

補われている場合 
はその引用を記入

実施措置

5.1  ソフトウェア開発
計画

7.3.1  設計・開発の計

はい/いいえ

5.2  ソフトウェア要求
事項分析

7.3.2  設計・開発への
インプット

はい/いいえ

5.3  ソフトウェアアー
キテクチャの設計

はい/いいえ

5.4  ソフトウェア詳細
設計

はい/いいえ

5.5  ソフトウェアユニ
ットの実装及び検証

はい/いいえ

5.6  ソフトウェア結合
及び結合試験

はい/いいえ

5.7  ソフトウェアシス
テム試験

7.3.3  設計・開発から
のアウトプット 
7.3.4  設計・開発のレ
ビュー

はい/いいえ

5.8  ソフトウェアリリ
ース

7.3.5  設計・開発の検
証 
7.3.6  設計・開発の妥
当性確認

はい/いいえ

6.1  ソフトウェア保守
計画の確立

7.3.7  設計・開発の変
更管理

はい/いいえ

6.2  問題及び修正の分

はい/いいえ

6.3  修正の実装 7.3.5

設計・開発の検

証 
7.3.6  設計・開発の妥
当性確認

はい/いいえ

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

はい/いいえ

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

はい/いいえ

7.3  リスクコントロー
ル手段の検証

はい/いいえ

7.4  ソフトウェア変更
の リ ス ク マ ネ ジ メ ン

はい/いいえ

8.1  構成識別 7.5.3

識別及びトレー

サビリティ

はい/いいえ

8.2  変更管理 7.5.3

識別及びトレー

サビリティ

はい/いいえ

8.3  構成状態の記録

はい/いいえ

箇条 9

ソフトウェア

問題解決プロセス

はい/いいえ


63

T 2304

:2012 (IEC 62304:2006)

参考文献

[1]  JIS C 1010-1:2005  測定,制御及び研究室用電気機器の安全性−第 1 部:一般要求事項

注記  対応国際規格:IEC 61010-1:2001,Safety requirements for electrical equipment for measurement,

control, and laboratory use−Part 1: General requirements(MOD)

[2]  JIS Q 9000:2006  品質マネジメントシステム−基本及び用語

注記  対応国際規格:ISO 9000:2005,Quality management systems−Fundamentals and vocabulary(IDT)

[3]  JIS Q 9001:2008  品質マネジメントシステム−要求事項

注記  対応国際規格:ISO 9001:2008,Quality management systems−Requirements(IDT)

[4]  JIS Q 13485:2005  医療機器−品質マネジメントシステム−規制目的のための要求事項

注記  対応国際規格:ISO 13485:2003,Medical devices−Quality management systems−Requirements for

regulatory purposes(IDT)

[5]  JIS X 0129-1:2003  ソフトウェア製品の品質−第 1 部:品質モデル

注記  対応国際規格:ISO/IEC 9126-1:2001,Software engineering−Product quality−Part 1: Quality

model(IDT)

[6]  JIS X 0160:1996  ソフトウェアライフサイクルプロセス

注記 1  対応国際規格:ISO/IEC 12207:1995,Information technology−Software life cycle processes,

Amendment 1 (2002)及び Amendment 2 (2004)(IDT)

注記 2  JIS X 0160:2007  ソフトウェアライフサイクルプロセス(追補 1)が発行されている。

[7]  JIS X 0161:2008  ソフトウェア技術−ソフトウェアライフサイクルプロセス−保守

注記  対応国際規格:ISO/IEC 14764: 2006,Software Engineering−Software Life Cycle Processes−

Maintenance(IDT)

[8]  JIS Z 8051:2004  安全側面−規格への導入指針

注記  対応国際規格:ISO/IEC Guide 51:1999,Safety aspects−Guidelines for their inclusion in standards

(IDT)

[9]  ISO/IEC 90003:2004,Software engineering−Guidelines for the application of ISO 9001:2000 to computer

software

[10] IEC 60601-1:2005,Medical electrical equipment−Part 1: General requirements for basic safety and essential

performance

[11] IEC 60601-1-4:1996,Medical electrical equipment−Part 1: General requirements for safety−4.Collateral

standard: Programmable electrical medical systems 及び Amendment 1 (1999)

[12] IEC 60601-1-6,Medical electrical equipment−Part 1-6: General requirements for safety−Collateral standard:

Usability

[13] IEC 61508-3,Functional safety of electrical/electronic/programmable electronic safety-related systems−Part

3: Software requirements

[14] IEEE 610.12:1990,IEEE standard glossary of software engineering terminology

[15] IEEE 1044:1993,IEEE standard classification for software anomalies