IEC62304とは。IEC62304認証を取得するには。
2017年11月25日以降に製造販売される医療機器ソフトウェアはより国内薬機法において、IEC62304(JIS T 2304)への適合が求められることになります。 IEC62304(JIS T 2304 医療機器ソフトウェアーソフトウェアライフサイクルプロセス)は医療機器ソフトウェアの安全性の向上を目的として、ソフトウェア開発及び保守に関する要求項目を規定した規格です。 医療機器ソフトウェアの開発及び保守プロセスにおいてIEC62304(JIS T 2304)の要求事項に適合させる必要があります。
特徴としては
・リスク分析の結果を考慮してソフトウェアのアーキテクチャを設計を行い、検証はリスク評価に基づき実施する「リスクアプローチ」で行います。
・ライフサイクルの設計変更に伴う安全性の劣化を見逃さないために、「リスクマネジメントの繰り返し適用」を行います。
「ソフトウェアの安全性分類」 ソフトウェアシステムが起因となって患者、操作者またはその他の人たちにもたらす危害のリスクに応じて、ソフトウェアシステムをソフトウェア安全クラスに分類します。 ソフトウェア安全クラスが高くなるほど、要求されるプロセス、アクティビティが多くなります。
リベルワークスは、製薬会社様、医療機器メーカー様、医療機器サプライヤー様向けのIEC62304(JIS T 2304 医療機器ソフトウェアーソフトウェアライフサイクルプロセス)に準拠した、IEC62304のソフトウェア開発、IEC62304のソフトウェア試験およびIEC62304のソフトウェア規格取得サポートを行っています。
IEC62304における安全性クラスと要求される実施項目との関係
| 4 一般要求事項 | |||||
|---|---|---|---|---|---|
| プロセス | 項番号 | アクティビティ | 要求項目 | ||
| 4.1 品質マネジメントシステム | ○ | ||||
| 4.2 リスクマネジメントシステム | ○ | ||||
| 4.3 ソフトウェア安全クラス分類 | ○ | ||||
| 4.4 レガシーソフトウェア | ○ | ||||
| 5 ソフトウェア開発プロセス | |||||
| プロセス | 項番号 | アクティビティ | 安全性クラス | ||
| A | B | C | |||
| 5.1 ソフトウェア開発計画 | 5.1.1 | ソフトウェア開発計画 | ○ | ○ | ○ |
| 5.1.2 | ソフトウェア開発計画の継続更新 | ○ | ○ | ○ | |
| 5.1.3 | ソフトウェア開発計画におけるシステム設計及びシステム開発の引用 | ○ | ○ | ○ | |
| 5.1.4 | ソフトウェア開発規格，方法及びツールの計画 | ○ | |||
| 5.1.5 | ソフトウェア結合及び結合試験計画 | ○ | ○ | ||
| 5.1.6 | ソフトウェア検証計画 | ○ | ○ | ○ | |
| 5.1.7 | ソフトウェアリスクマネジメント計画 | ○ | ○ | ○ | |
| 5.1.8 | 文書化計画 | ○ | ○ | ○ | |
| 5.1.9 | ソフトウェア構成管理計画 | ○ | ○ | ○ | |
| 5.1.10 | 管理が必要な支援アイテム | ○ | ○ | ||
| 5.1.11 | 検証前のソフトウェア構成アイテムのコントロール | ○ | ○ | ||
| 5.2 ソフトウェア要求事項分析 | 5.2.1 | システム要求事項からのソフトウェア要求事項の定義及び文書化 | ○ | ○ | ○ |
| 5.2.2 | ソフトウェア要求事項の内容 | ○ | ○ | ○ | |
| 5.2.3 | リスクコントロール手段のソフトウェア要求事項への包含 | ○ | ○ | ||
| 5.2.4 | 医療機器のリスク分析の再評価 | ○ | ○ | ○ | |
| 5.2.5 | システム要求事項の更新 | ○ | ○ | ○ | |
| 5.2.6 | ソフトウェア要求事項の検証 | ○ | ○ | ○ | |
| 5.3 ソフトウェアアーキテクチャの設計 | 5.3.1 | ソフトウェア要求事項のアーキテクチャへの変換 | ○ | ○ | |
| 5.3.2 | ソフトウェアアイテムのインタフェース用アーキテクチャの開発 | ○ | ○ | ||
| 5.3.3 | SOUPアイテムの機能及び性能要求事項の指定 | ○ | ○ | ||
| 5.3.4 | SOUPアイテムが要求するシステムハードウェア及びシステムソフトウェアの指定 | ○ | ○ | ||
| 5.3.5 | リスクコントロールに必要な分離の特定 | ○ | |||
| 5.3.6 | ソフトウェアアーキテクチャの検証 | ○ | ○ | ||
| 5.4 ソフトウェア詳細設計 | 5.4.1 | ソフトウェアアーキテクチャのソフトウェアユニットへの分解 | ○ | ○ | |
| 5.4.2 | ソフトウェアユニットごとの詳細設計の開発 | ○ | |||
| 5.4.3 | インタフェース用詳細設計の開発 | ○ | |||
| 5.4.4 | 詳細設計の検証 | ○ | |||
| 5.5 ソフトウェアユニットの実装及び検証 | 5.5.1 | 各ソフトウェアユニットの実装 | ○ | ○ | ○ |
| 5.5.2 | ソフトウェアユニット検証プロセスの確立 | ○ | ○ | ||
| 5.5.3 | ソフトウェアユニットの合否判定基準 | ○ | ○ | ||
| 5.5.4 | 追加のソフトウェアユニット合否判定基準 | ○ | |||
| 5.5.5 | ソフトウェアユニットの検証 | ○ | ○ | ||
| 5.6 ソフトウェア結合及び結合試験 | 5.6.1 | ソフトウェアユニットの結合 | ○ | ○ | |
| 5.6.2 | ソフトウェア結合の検証 | ○ | ○ | ||
| 5.6.3 | 結合したソフトウェアの試験 | ○ | ○ | ||
| 5.6.4 | 結合試験の内容 | ○ | ○ | ||
| 5.6.5 | 結合試験手順の検証 | ○ | ○ | ||
| 5.6.6 | レグレッションテストの実施 | ○ | ○ | ||
| 5.6.7 | 結合試験記録の内容 | ○ | ○ | ||
| 5.6.8 | ソフトウェア問題解決プロセスの使用 | ○ | ○ | ||
| 5.7 ソフトウェアシステム試験 | 5.7.1 | ソフトウェア要求事項についての試験の確立 | ○ | ○ | |
| 5.7.2 | ソフトウェア問題解決プロセスの使用 | ○ | ○ | ||
| 5.7.3 | 変更後の再試験 | ○ | ○ | ||
| 5.7.4 | ソフトウェアシステム試験の検証 | ○ | ○ | ||
| 5.7.5 | ソフトウェアシステム試験記録の内容 | ○ | ○ | ||
| 5.8 ソフトウェアリリース | 5.8.1 | ソフトウェア検証の完了確認 | ○ | ○ | |
| 5.8.2 | 既知の残留異常の文書化 | ○ | ○ | ||
| 5.8.3 | 既知の残留異常の評価 | ○ | ○ | ||
| 5.8.4 | リリースしているバージョンの文書化 | ○ | ○ | ○ | |
| 5.8.5 | リリースしたソフトウェアの作成方法の文書化 | ○ | ○ | ||
| 5.8.6 | アクティビティ及びタスクの完了確認 | ○ | ○ | ||
| 5.8.7 | アクティビティ及びタスクの完了確認 | ○ | ○ | ||
| 5.8.8 | ソフトウェアリリースの反復性の確保 | ○ | ○ | ||
| 6 ソフトウェア保守プロセス | |||||
| 6.1 ソフトウェア保守計画の確立 | ○ | ○ | ○ | ||
| 6.2 問題及び修正の分析 | 6.2.1 | フィードバックの文書化及び評価 | ○ | ○ | ○ |
| 6.2.2 | ソフトウェア問題解決プロセスの使用 | ○ | ○ | ||
| 6.2.3 | 変更要求の分析 | ○ | ○ | ○ | |
| 6.2.4 | 変更要求の承認 | ○ | ○ | ○ | |
| 6.2.5 | ユーザ及び規制当局への通知 | ○ | ○ | ○ | |
| 6.3 修正の実装 | 6.3.1 | 確立したプロセスを使用した修正の実装 | ○ | ○ | ○ |
| 6.3.2 | 修正ソフトウェアシステムの再リリース | ○ | ○ | ○ | |
| 7 ソフトウェアリスクマネジメントプロセス | |||||
| プロセス | 項番号 | アクティビティ | 安全性クラス | ||
| A | B | C | |||
| 7.1 危険状態を引き起こすソフトウェアの分析 | 7.1.1 | 危険状態の一因となるソフトウェアアイテムの特定 | ○ | ○ | |
| 7.1.2 | 危険状態の一因となるソフトウェアアイテムの潜在的原因の特定 | ○ | ○ | ||
| 7.1.3 | 公開された SOUP 異常リストの評価 | ○ | ○ | ||
| 7.1.4 | 潜在的原因の文書化 | ○ | ○ | ||
| 7.1.5 | イベントシーケンスの文書化 | ○ | ○ | ||
| 7.2 リスクコントロール手段 | 7.2.1 | リスクコントロール手段の選択 | ○ | ○ | |
| 7.2.2 | ソフトウェアに実装するリスクコントロール手段 | ○ | ○ | ||
| 7.3 リスクコントロール手段の検証 | 7.3.1 | リスクコントロール手段の実装の検証 | ○ | ○ | |
| 7.3.2 | 新しいイベントシーケンスの文書化 | ○ | ○ | ||
| 7.3.3 | トレーサビリティの文書化 | ○ | ○ | ||
| 7.4 ソフトウェア変更のリスクマネジメント | 7.4.1 | 医療機器ソフトウェアの安全性に関わる変更の分析 | ○ | ○ | ○ |
| 7.4.2 | ソフトウェア変更が既存のリスクコントロール手段に与える影響の分析 | ○ | ○ | ||
| 7.4.3 | 分析に基づくリスクマネジメントアクティビティの実行 | ○ | ○ | ||
| 8 ソフトウェア構成管理プロセス | |||||
| 8.1 構成識別 | 8.1.1 | 構成アイテム識別手段の確立 | ○ | ○ | ○ |
| 8.1.2 | SOUPの特定 | ○ | ○ | ○ | |
| 8.1.3 | システム構成文書の特定 | ○ | ○ | ○ | |
| 8.2 変更管理 | 8.2.1 | 変更要求の承認 | ○ | ○ | ○ |
| 8.2.2 | 変更の実装 | ○ | ○ | ○ | |
| 8.2.3 | 変更の検証 | ○ | ○ | ○ | |
| 8.2.4 | 変更のトレーサビリティを実現する手段の提示 | ○ | ○ | ○ | |
| 8.3 構成状態の記録 | ○ | ○ | ○ | ||
| 9 ソフトウェア問題解決プロセス | |||||
| 9.1 問題報告の作成 | ○ | ○ | ○ | ||
| 9.2 問題の調査 | ○ | ○ | ○ | ||
| 9.3 関係者への通知 | ○ | ○ | ○ | ||
| 9.4 変更管理プロセスの使用 | ○ | ○ | ○ | ||
| 9.5 記録の保持 | ○ | ○ | ○ | ||
| 9.6 問題の傾向分析 | ○ | ○ | ○ | ||
| 9.7 ソフトウェア問題解決の検証 | ○ | ○ | ○ | ||
| 9.8 試験文書の内容 | ○ | ○ | ○ | ||