IEC-62304とは
IEC62304（Medical device software – software Life Cycle Processes）は、 医療機器ソフトウェアの安全性の向上を目的として、ソフトウェア開発及び保守に関する要求項目を規定した規格である。
2006年5月に発行された医療機器ソフトウェアのライフサイクルプロセスの枠組みを示した最初の国際規格である。
IEC 62304は「医療機器ソフトウェア」の開発と保守に関するプロセスを規定している。
2015年6月にAmendment 1 が加わった IEC 62304の改訂版Edition 1.1が発表された。
改訂版にはレガシーソフトウェアの扱い、一般的なソフトウェア欠陥の特定と回避等が新しく加わった。
Ed.1.1は、閲覧だけならば日本工業標準調査会ホームページ（http://www.jisc.go.jp）で参照できる。
IEC62304は
- 安全要求を実現するための、ソフトウェア開発＆保守手順標準
- 医療用ソフトウェアのみをターゲット
- ライフサイクルプロセスの規格
- ソフトウェア品質を確保するための製造者のアクティビティについて規定
- 特定の開発モデルを想定してはいない
本規格は、ソフトウェアの試験に関する要求を含んでいるが、その詳細な要求をしていない。欠陥を作らないよう適切なプロセス（＆タスク）を実施しエビデンスを文書化することを重視している。その理由は、「ソフトウェアの試験だけでは、動作時の安全性を判定する上で十分ではない」との考え方に基づく。
本規格では、医療機器ソフトウェアに内在する危険度に応じて3段階の「安全クラス」を定義し、安全性クラスに応じてライフサイクルの各プロセスにおいて最低限実施すべき一連のアクティビティと各工程で実施するタスクを規定している。
製造者は、初めにリスクマネジメントに基づきソフトウェアに起因するハザードが人に及ぼす影響を安全性クラスに分類し、リスク管理対策を定義、文書化することを求められる。
次に、適切な品質マネジメント、ソフトウェアエンジニアリングの下で、開発や検証等における一連のプロセスの中でリスクに応じた作業を実施、記録、管理することを求められる。
現状、欧米を始めとする各国の規制においてIEC62304が適用されるようになってきており、医療機器ソフトウェアの安全性確保のための国際的な規格要求はIEC62304 に集約されつつある。
規制要件としてのIEC-62304
医療機器ソフトウェア開発の現場において、IEC 62304は、国際的に重要な位置づけの規格として認識されている。
IEC 62304は、2006年5月に発行され、日本では2012年にJIS化（JIS T 2304）された。
2014年11月に施行された医薬品医療機器法第12条第2項において参照される「最新のライフサイクルモデル」である 。
2017年3月1日官報にて、IEC 62304 Ed. 1.1 （IEC 62304:2006 + Amd.1:2015）に対応した“JIS T 2304:2017が公示された。
今後3年間で、この改正へ対応することが求められる。
移行期間については、規格自体には記載はない。（IEC 62304 Amd1には記載があり、3年以内の移行を推奨している。）
本邦において、2017年11月25日より、IEC 62304（医療機器ソフトウェア ‐ ソフトウェアライフサイクルプロセス）が実質的な規制要件となった。
- プログラム（ソフトウェア）を用いた医療機器はJIS T 2304への適合の確認をする。
- 承認または認証を行う場合は、申請書添付資料において、JIS T 2304への適合を説明する。
- 一般医療機器（クラス1）も同様に確認が必要。
- 2017年11月24日までに設計が完了している医療機器であっても、 JIS T 2304等への適合を満たすための措置を講じること。
日本以外でも欧州・北米・中国などにおいて医療機器申請時にIEC 62304に基づくソフトウェア開発の証拠が必要である。
つまりIEC 62304に従って「医療機器ソフトウェア」を開発しなければ、国内外においてソフトウェアを搭載した医療機器（単体プログラムを含む）を販売することができない。
米国FDAにおいても2008年7月にRecognized Consensus Standardと認定された。
IEC62304の三大原則
IEC62304では、医療機器ソフトウェアの安全性を向上させる三つの大原則として、「リスクマネジメント、品質マネジメント、ソフトウェアエンジニアリング」を挙げている。
- リスクマネジメント：ISO14971に適合するリスクマネジメントプロセスの適用を要求
- 品質マネジメント：ISO13485 などの適切な品質マネジメントシステムの適用を要求
- ソフトウェア・エンジニアリング：この規格（IEC 62304）への適合を要求
ソフトウェアの安全性は、ソフトウェア自体が持つ特性ではなく、ソフトウェアとその外部（ハードウェアなど）とのかかわりの中で現れるものとされている。そのため、この規格は、医療機器向けのリスクマネジメントの規格であるISO 14971の力も借りて、 ソフトウェアが関わるリスクを管理しながら、安全要求に対して品質の高いソフトウェアを提供することを目指している。
IEC-62304対応課題
医療機器企業では、品質マネジメントやIEC62304等の規格適合を意識した開発の必要性を認識しているが、これらの規格に対応できる人材が不足している点、規格書だけ読んでも対応すべき内容や方法が分からない点が大きな壁となっている。
現状では、ソフトウェアに重点を置いた開発が行われておらず、ソフトウェアの設計・開発などの各フェーズでの検証が不十分となる上、設計開発記録などの技術文書構築が行われない傾向にある。
今後どのようにソフトウェアシステム（QMS）を構築していくかが問題である。
ソフトウェアを搭載した医療機器の海外展開の問題点
- IEC62304、FDAガイダンスに対応しなければ海外展開できない。
- 日本向け製品では海外規格を意識せずに開発をしている。
- これまで日本において医療機器ソフトウェア開発に関する規制がなかったため、品質マネジメントの基準や手順は企業任せになってしまい、企業によって品質のバラツキが大きくなる。
- 自社製品を海外当局へ薬事申請を行う場合、ソフトウェア設計開発記録を初めから起こしなおす、又は再編集しないと要求事項に適合しない。
- IEC62304規格の適合確認を受けていた製品に対して、FDAから適合していないとの厳しい指摘を受けた。
IEC62304対応文書構築の問題点
- 企業では、品質マネジメントやIEC62304等の規格適合を意識した開発の必要性を認識しているが、規格書だけ読んでも対応すべき内容や方法が分からない。
- 規格書を読んでも、どこまでやるべきなのかの範囲が分からない。
- 規格の詳細の内容が不明なまま、IEC62304文書構築を行っている。
医療機器企業におけるソフトウェア開発の問題点
人員不足
- ソフトウェア開発担当者が少なく、開発期間も短いことから、まともな設計資料を作っていない。
- 開発記録の作成は、ソースプログラムの構想・構築とは別工程として時間を要するため、十分な開発人材をあてがうことができない。
- 人員が慢性的に不足しており、開発手法やISO、IEC規格に基づいた教育・トレーニングを受けさせる時間的余裕がない。
- トレーナーの育成ができない。
規程・手順書の不備
- 現状、ソフトウェアについての管理手順がない。
- ISOの書類が形式的になりがちである。そもそもISOのソフトウェアの管理手順が存在していない。
- 製品の実装、期日通りの納品を優先させるために、製品の開発手法や品質の標準化は置き去りにされている。
- 開発を安全に行うには、構成管理や変更管理をしっかり行うプロジェクトマネージメント手法を取り入れる必要があるが、個々の能力と責任感、職人かたぎに頼ったプロジェクト推進が主流の日本的開発スタイルからの切替えは難しい。
設計開発記録の不備
- ソフトウェアに重点を置いた開発があまり行われず、ソフトウェアの設計・開発などの各フェーズでの検証が不十分となる上、設計開発記録などの技術文書構築が行われない傾向にある。
- ソフトウェアの実装ありきで、設計開発記録を用いた分析、エビデンスの保管というフローが存在していない。
- 連動して開発されたソフトウェアの一連の設計開発書が存在しない。存在したとしてもISOやIEC規格の要求事項とは掛け離れた記録でしかない。
- ドキュメンテーションが実際の開発フローに準じていない。
ソフトウェア設計開発の課題
- 設計ルールの明確化、プロセス管理、構成管理、変更管理を通じて、派生開発効率を向上することによる開発期間の短縮が課題。
- 品質マネジメントの前に、今後どのようにソフトウェアシステムを構築していくかが問題。
本「IEC 62304対応規程・手順書ひな形」を導入いただくことによってIEC 62304に準拠したQMSを効率的・効果的に作成することができます。
様式一覧
※ご購入いただきますと、以下の様式が付随しております。
・ SW-QMS-A1 ソフトウェア開発規程
・ SW-QMS-B1 ソフトウェア開発手順書
目次
ソフトウェア開発規程
1. 目的
2. 適用範囲
3. 用語の定義
4. ソフトウェア設計開発の原則
5. 一般
5.1 品質システム
5.2 リスクマネジメント
5.3 ユーザビリティエンジニアリング
5.4 ソフトウェア安全性クラス分類
5.5 レガシーソフトウェア
5.5.1 レガシーソフトウェアのリスクマネジメント活動
5.5.2 ギャップ分析
5.5.3 レガシーソフトウェアの使用の論拠
6. ソフトウェア開発プロセス
6.1 ソフトウェア開発計画
6.1.1 ソフトウェア開発計画（クラスA、B、C）
6.1.2 ソフトウェア開発計画の継続更新（クラスA、B、C）
6.1.3 ソフトウェア開発計画におけるシステム設計及び
システム開発の引用
6.1.4 ソフトウェア開発規格、方法及びツールの計画（クラスC）
6.1.5 ソフトウェア結合及び結合試験計画（クラスB、C）
6.1.6 ソフトウェア検証計画（クラスA、B、C）
6.1.7 ソフトウェアリスクマネジメント計画（クラスA、B、C）
6.1.8 文書化計画（クラスA、B、C）
6.1.9 ソフトウェア構成管理計画（クラスA、B、C）
6.1.10 管理が必要な支援アイテム（クラスB、C）
6.1.11 検証前のソフトウェア構成アイテムのコントロール
（クラスB、C）
6.1.12 既知のソフトウェア欠陥の特定及び回避（クラスB、C）
6.2 ソフトウェア要求事項分析
6.2.1 システム要求事項からのソフトウェア要求事項の定義及び文書化
（クラス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）
6.2.6 ソフトウェア要求事項の検証（クラスA、B、C）
6.3 ソフトウェアアーキテクチャの設計
6.3.1 ソフトウェア要求事項のアーキテクチャへの変更（クラスB、C）
6.3.2 ソフトウェアアイテムのインタフェース用アーキテクチャの開発
（クラスB、C）
6.3.3 SOUPアイテムの機能及び性能要求事項の指定（クラスB、C）
6.3.4 SOUPアイテムが要求するシステムハードウェア及びシステム
ソフトウェアの指定（クラスB、C）
6.3.5 リスクコントロールに必要な分離の特定（クラスC）
6.3.6 ソフトウェアアーキテクチャの検証（クラスB、C）
6.4 ソフトウェア詳細設計
6.4.1 ソフトウェアのソフトウェアユニットへの分解（クラスB、C）
6.4.2 ソフトウェアユニットごとの詳細設計の開発（クラスC）
6.4.3 インタフェース用詳細設計の開発（クラスC）
6.4.4 詳細設計の検証（クラスC）
6.5 ソフトウェアユニットの実装
6.5.1 各ソフトウェアユニットの実装（クラスA、B、C）
6.5.2 ソフトウェアユニット検証プロセスの確立（クラスB、C）
6.5.3 ソフトウェアユニットの合否判定基準（クラスB、C）
6.5.4 追加のソフトウェアユニット合否判定基準（クラスC）
6.5.5 ソフトウェアユニットの検証（クラスB、C）
6.6 ソフトウェア結合及び結合試験
6.6.1 ソフトウェアユニットの結合（クラスB、C）
6.6.2 ソフトウェア結合の検証（クラスB、C）
6.6.3 ソフトウェア結合試験（クラスB、C）
6.6.4 ソフトウェア結合試験の内容（クラスB、C）
6.6.5 ソフトウェア結合試験手順の評価（クラスB、C）
6.6.6 回帰テストの実施（クラスB、C）
6.6.7 結合試験記録の内容（クラスB、C）
6.6.8 ソフトウェア問題解決プロセスの使用（クラスB、C）
6.7 ソフトウェアシステム試験
6.7.1 ソフトウェア要求事項についての試験の確立（クラスA、B、C）
6.7.2 ソフトウェア問題解決プロセスの使用（クラスA、B、C）
6.7.3 変更後の再試験（クラスA、B、C）
6.7.4 ソフトウェアシステム試験の評価（クラスA、B、C）
6.7.5 ソフトウェアシステム試験記録の内容（クラスA、B、C）
6.8 システムレベルで使用するためのソフトウェアリリース
6.8.1 ソフトウェア検証の完了確認（クラスA、B、C）
6.8.2 既知の残留異常の文書化（クラスA、B、C）
6.8.3 既知の残留異常の評価（クラスB、C）
6.8.4 リリースするバージョンの文書化（クラスA、B、C）
6.8.5 リリースするソフトウェアの作成方法の文書化（クラスB、C）
6.8.6 アクティビティ及びタスクの完了確認（クラスB、C）
6.8.7 ソフトウェアのアーカイブ（クラスA、B、C）
6.8.8 ソフトウェアリリースの信頼性の確保（クラスA、B、C）
7. ソフトウェア保守プロセス
7.1 ソフトウェア保守計画の確立（クラスA、B、C）
7.2 問題及び修正の分析
7.2.1 フィードバックの文書化及び評価
7.2.2 ソフトウェア問題解決プロセスの使用（クラスA、B、C）
7.2.3 変更要求の分析（クラスA、B、C）
7.2.4 変更要求の承認（クラスA、B、C）
7.2.5 ユーザ及び規制当局への通知（クラスA、B、C）
7.3 修正の実装
7.3.1 確立したプロセスを使用した修正の実装（クラスA、B、C）
7.3.2 修正ソフトウェアシステムの再リリース（クラスA、B、C）
8. ソフトウェアリスクマネジメントプロセス
8.1 危険状態を引き起こすソフトウェアの分析
8.1.1 危険状態の一因となるソフトウェアアイテムの特定
（クラスB、C）
8.1.2 危険状態の一因となるソフトウェアアイテムの潜在的原因
（クラスB、C）
8.1.3 公開されたSOUP異常リストの評価（クラスB、C）
8.1.4 潜在的原因の文書化（クラスB、C）
8.2 リスクコントロール手段
8.2.1 リスクコントロール手段の選択（クラスB、C）
8.2.2 ソフトウェアに実装するリスクコントロール手段（クラスB、C）
8.3 リスクコントロール手段の検証
8.3.1 リスクコントロール手段の実施の検証（クラスB、C）
8.3.2 トレーサビリティの文書化
8.4 ソフトウェア変更のリスクマネジメント
8.4.1 医療機器ソフトウェアの安全性に関わる変更の分析
（クラスA、B、C）
8.4.2 ソフトウェア変更が既存のリスクコントロール手段に与える
影響の分析（クラスB、C）
8.4.3 分析に基づくリスクマネジメントアクティビティの実行
（クラスB、C）
9. ソフトウェア構成管理プロセス
9.1 構成識別
9.1.1 構成アイテム識別手段の確立（クラスA、B、C）
9.1.2 SOUPの特定（クラスA、B、C）
9.1.3 システム構成文書の特定（クラスA、B、C）
9.2 変更管理
9.2.1 変更要求の承認（クラスA、B、C）
9.2.2 変更の実装（クラスA、B、C）
9.2.3 変更の検証（クラスA、B、C）
9.2.4 変更のトレーサビリティを実現する手段の提示
（クラスA、B、C）
9.3 構成状態の記録（クラスA、B、C）
10. ソフトウェア問題解決プロセス
10.1 問題報告の作成（クラスA、B、C）
10.2 問題の調査（クラスA、B、C）
10.3 関係者への周知（クラスA、B、C）
10.4 変更管理プロセスの使用（クラスA、B、C）
10.5 記録の保持（クラスA、B、C）
10.6 問題の傾向分析
10.7 ソフトウェア問題解決の検証（クラスA、B、C）
10.8 試験文書の内容（クラスA、B、C）
11. 引用規格
12. 参考
13. 付則
ソフトウェア開発手順書
1. 目的
2. 適用範囲
3. 用語の定義
4. 役割と責任
5. 設計開発ステージとソフトウェア開発プロセスの対応
6. 成果物
7. ソフトウェア開発プロセス
7.1 システム要求仕様書・システムアーキテクチャ設計書の作成（クラスA、B、C）
7.1.1 プロセスのインプットおよびアウトプット
7.1.2 システム要求仕様書・システムアーキテクチャ設計書、製品開発計画書の作成
7.2 ソフトウェア開発計画
7.2.1 プロセスのインプットおよびアウトプット
7.2.2 ソフトウェア開発計画書の作成
7.2.3 ソフトウェア検証計画書の作成
7.2.4 リスクマネジメント計画書の作成
7.2.5 ソフトウェア文書管理計画書の作成
7.2.6 ソフトウェア構成管理計画書の作成
7.2.7 ソフトウェア結合および結合試験計画書（クラスB、C）
7.3 ソフトウェア要求分析
7.3.1 プロセスのインプットおよびアウトプット
7.3.2 システム要求事項の具体化、リスク分析、ユーザビリティエンジニアリング評価の実施
7.3.3 ソフトウェア要求仕様書（SRS）執筆準備
7.3.4 ソフトウェア要求分析シート
7.3.5 ソフトウェア要求仕様書（SRS）の作成
7.3.6 ソフトウェア開発計画書の更新
7.3.7 ソフトウェアリスク分析の再評価
7.3.8 ソフトウェア要求分析フェーズチェックリスト
7.3.9 要求事項の更新
7.3.10 ソフトウェア要求事項の検証
7.4 ソフトウェアアーキテクチャ設計
7.4.1 プロセスのインプットおよびアウトプット
7.4.2 ソフトウェアアーキテクチャ設計書の作成（クラスB、C）
7.4.3 ソフトウェアアーキテクチャの検証（クラスB、C）
7.5 ソフトウェア詳細設計（クラスB、C）
7.5.1 プロセスのインプットおよびアウトプット
7.5.2 ソフトウェア詳細設計書
7.5.3 詳細設計の検証（クラスC）
7.6 ソフトウェアユニットの実装
7.6.1 プロセスのインプットおよびアウトプット
7.6.2 ソフトウェアユニットの実装
7.7 ソフトウェアユニットテスト（クラスB、C）
7.7.1 プロセスのインプットおよびアウトプット
7.7.2 ソフトウェアユニットテスト仕様書
7.7.3 ソフトウェアユニットテスト記録
7.7.4 ソフトウェアユニットテスト報告書
7.8 ソフトウェア結合および結合試験（クラスB、C）
7.8.1 プロセスのインプットおよびアウトプット
7.8.2 ソフトウェアユニットの結合（クラスB、C）
7.8.3 ソフトウェア結合試験計画書（クラスB、C）
7.8.4 ソフトウェア結合試験仕様書（クラスB、C）
7.8.5 ソフトウェア結合試験スクリプト（クラスB、C）
7.8.6 ソフトウェア結合試験の実施及び記録（クラスB、C）
7.8.7 回帰テスト（クラスB、C）
7.8.8 ソフトウェア結合試験報告書（クラスB、C）
7.9 ソフトウェアシステム試験
7.9.1 プロセスのインプットおよびアウトプット
7.9.2 ソフトウェアシステム試験計画書
7.9.3 ソフトウェアシステム試験仕様書
7.9.4 ソフトウェアシステム試験スクリプト
7.9.5 ソフトウェアシステム試験記録
7.9.6 変更後の再試験
7.9.7 ソフトウェアシステム試験報告書
7.10 トレーサビリティ管理
7.10.1 トレーサビリティマトリックスの記入要領
7.10.2 トレーサビリティマトリックスの作成及び更新
7.11 リリース
7.11.1 プロセスのインプットおよびアウトプット
7.11.2 ソフトウェア検証の完了確認
7.11.3 既知の残留異常の文書化
7.11.4 既知の残留異常の評価（クラスB、C）
7.11.5 リリースするバージョンの文書化
7.11.6 リリースするソフトウェアの作成方法の文書化
7.11.7 ソフトウェアプロジェクト終結報告書
7.11.8 ソフトウェアプロジェクト終結チェックリスト（クラスB、C）
7.11.9 ソフトウェアリリースの信頼性の確保
7.11.10 ソフトウェアリリースノート
7.11.11 ソフトウェアのアーカイブ
8. ソフトウェア問題管理
8.1 プロセスの開始基準、インプット、終了基準およびアウトプット
8.2 手順
8.2.1 計画
8.2.2 実行
8.2.3 問題の傾向分析
8.2.4 ソフトウェア問題解決の検証
9. ソフトウェア変更管理
9.1 プロセスの開始基準、インプット、終了基準およびアウトプット
9.2 手順
9.2.1 計画
9.2.2 実行
10. ソフトウェア保守計画
10.1 プロセスのインプットおよびアウトプット
10.2 ソフトウェア保守計画書
11. 参考
12. 付則