医療機器ソフトウェア開発のポイントと SRSを始めとする関連文書のまとめ方
開催日 |
13:00 ~ 16:00 締めきりました |
---|---|
主催者 | (株)R&D支援センター |
キーワード | 医療機器・医療材料技術 情報技術 |
開催エリア | 東京都 |
開催場所 | 【江東区】カメリアプラザ(商工情報センター) |
交通 | 【JR・東武】亀戸駅 |
医療機器ソフトウェアの各開発ステップにおける
検証/妥当性検証計画のポイントとは?
医療機器ソフトウェア開発のポイントとして、 ソフトウェア要求事項獲得から
機能展開と実装ソフトウェアアイテムへのマッピングについてわかりやすく詳述します
セミナー講師
テクマトリックス(株) フェロー 中島 裕生 氏
【専門】
AI、システム/ソフトウェアエンジニアリング、レギュラトリサイエンス
【経歴等】
1976年東京工業大学 修士課程修了
2008年より、IEC62304を中心にしたソフトウェア医療機器の開発プロセス構築を
コンサルティングしている。
・ システムアシュアランス協会理事
・ JIRA、JAHIS各委員
・ 一般社団法人日本医療情報学会医療情報技師育成部会
「医療情報分野の最新動向-機械学習入門」の講演よりe-Learning提供
セミナー受講料
49,500円(税込、資料付)
■ セミナー主催者からの会員登録をしていただいた場合、1名で申込の場合46,200円、
2名同時申込の場合計49,500円(2人目無料:1名あたり24,750円)で受講できます。
備考欄に「会員登録希望」と希望の案内方法【メールまたは郵送】を記入ください。
(セミナーのお申し込みと同時に会員登録をさせていただきますので、
今回の受講料から会員価格を適用いたします。)
※ 2019年10月1日以降に開催されるセミナーの受講料は、お申込みいただく時期に関わらず
消費税が10%になります。
※ 会員登録とは
ご登録いただきますと、セミナーや書籍などの商品をご案内させていただきます。
すべて無料で年会費・更新料・登録費は一切掛かりません。
セミナー趣旨
FDA、EU、国内の仕向けによらず、医療機器ソフトウェア開発のポイントとして、ソフトウェア要求事項獲得から機能展開と実装ソフトウェアアイテムへのマッピングについてわかりやすく詳述します。
また、それぞれの開発ステップにおける検証および妥当性検証を組み合わせることでソフトウェア品質保証が実現することを理解していただきます。
習得できる知識
・ IEC62304、JIS T 2304、IEC82304、JIS T 82304-1を駆使する知識
・ ソフトウェア要求仕様書作成ポイント
・ アーキテクチャ設計書作成ポイント
・ 詳細設計書作成ポイント
・ 検証/妥当性検証計画ポイント
セミナープログラム
1. はじめに
1.1 ソフトウェア関連規格と構成(ISO/IEC) 1.2 JIS T 2304の改正の扱い
1.3 JIS T 0601-1:2014(T0601-1:2012+追補1)への適合
2. “システム”を忘れないでください
2.1 IEC62304とISO13485との関連
- ソフトウェア開発プロセス
- ソフトウェア保守プロセス
- IEC62304Ed1.1とISO 13485:2003, ISO 13485:2015 との関係
2.2 IEC62304Ed1.1のプロセス・アクティビティ・タスク概観
- IEC62304:2006(JIS T 02304:2012)ソフトウェア開発プロセス
- IEC62304:2006(JIS T 02304:2012)ソフトウェア保守プロセス
- 用語御呼び定義
- IEC62304Ed1.1のプロセス・アクティビティ・タスク
- IEC62304 ED1.1改訂概要
2.3 IEC82304-1、JIS T 82304-1:2018とヘルスソフトウェア製品開発プロセス
- IEC82304-1とは
- 医療機器ソフトウェアの応用拡大とヘルスソフトウェアの形成
- 82304-1適用範囲及び適用範囲外のソフトウェアの例
2.4 IEC82304-1、JIS T 82304-1:2018要点押さえ
- ヘルスソフトウェア製品の要求事項
- ヘルスソフトウェア―ソフトウェアライフサイクルプロセス
- ヘルスソフトウェア製品の妥当性確認(バリデーション)
- ヘルスソフトウェア製品の識別情報と附属文書
- ヘルスソフトウェア製品の市販後活動
3. PoC(Proof of Concept:概念実証)からソフトウェア要求事項獲得に向けて
3.1 IEC62304で取り上げている開発モデル
- ソフトウェア開発プロセス - ソフトウェア開発プロセス上の開発モデル
- Agileの開発モデルはどうなる?
3.2 PoCは要求事項獲得のためのプロトタイピング
- 医療機器(ソフトウェア)の製品開発 - 製品開発とソフトウェア開発プロセス
- IEEE 1220 システムズエンジニアリングプロセス
3.3 システム要求仕様書-システムアーキテクチャ設計書-ソフトウェア要求仕様書
4. アーキテクチャの良し悪しがソフトウェアのライフサイクルを決める
4.1 ソフトウェア要求事項のアーキテクチャへの実現機能展開
- ソフトウェア要求事項分析
- ソフトウェア要件から機能要求への展開
4.2 アーキテクチャ設計
4.3 ソフトウェアコンポーネントの構造化設計
- ソフトウェアアーキテクチャの設計
5. 書きたくない詳細設計書、でもそれでいいの?
5.1 ソフトウェアユニットへの分解
5.2 詳細設計書を作成する
6. コーディングのお作法、仲間・後世のために
6.1 リスク分析ポイント
6.2 共通するソフトウェア不具合の特定と削除(要求事項5.1.12 IEC62304 Ed1.1:2015)
- ソフトウェア開発プロセス
- IEC 80002-1:2009 Annex B.1 ソフトウェア機能領域におけるハザードの潜在的原因の例
- IEC 80002-1:2009 Annex B.2 ハザードの潜在的ソフトウェア原因の例
- ハザードの潜在的ソフトウェア原因およびリスクコントロール手段への検証ルール
7. テストをしないで出荷!?
7.1 ソフトウェアユニットの検証
7.2 ソフトウェア結合の検証
7.3 ソフトウェアシステム試験(妥当性検証)
7.4 ソフトウェア問題解決プロセスの利用
- ソフトウェア結合及び結合試験
8. 文書間の総合インデックス
8.1 トレーサビリティマトリックス
- ソフトウェア開発プロセス
- 文書間トレーサビリティ表現
【質疑応答・名刺交換】