- 【ビデオ・VOD】生成AIを駆使した医療機器ソフトウェア規格(IEC62304)への規制要件対応
- 価格:77,000円(税込) ～ 331,650円(税込)
▼ 商品説明の続きを見る ▼
【楽天市場店からご購入をご希望の方へ】
| 楽天市場店 |
楽天市場店でのご購入は ⇒
|
|
|---|---|---|
| 備 考 |
※システムの都合上、楽天市場からのご購入に限り、セミナービデオおよび資料はDVDでの発送となります。予めご了承ください。 ※楽天ポイントがたまります!! |
|
【講師】 株式会社イーコンプライアンス 代表取締役 村山 浩一
【主な略歴】
1986年4月
日本ディジタルイクイップメント株式会社（日本DEC） ソフトウェアサービス部 入社
GCP管理システム・症例データ管理システムの企画・開発担当（現ClinicalWorks/GCP/CDM）
改正GCP（J-GCP）に対応した標準業務手順書作成コンサルティング
製薬業界におけるドキュメント管理システム導入コンサルティング
1988年にATR（株式会社国際電気通信基礎技術研究所：京都府精華町）でニューラルネットの研究に携わる（研究補助員）
1999年2月
日本アイ・ビー・エム株式会社 コンサルティング事業部 入社
NYのTWG（The Wilkerson Group）で製薬業界に特化したコンサルタントとして研修
製薬企業におけるプロセス リエンジニアリング担当
Computerized System Validation（CSV）、21 CFR Part11 コンサルティング
2001年7月 IBM認定主幹コンサルタント
アイビーエム・ビジネスコンサルティングサービス株式会社へ出向 マネージング・コンサルタント
2004年7月 日本アイ・ビー・エム株式会社 退社
2004年8月 株式会社イーコンプライアンス 設立 代表取締役（現在に至る）
村山浩一は、長年にわたり医薬品・医療機器産業のコンプライアンス支援に携わり、500社以上の企業を支援してきた実績を持ちます。医療機器ソフトウェアの領域では、IEC 62304（JIS T 2304）に基づくソフトウェアライフサイクルプロセスの構築、基本要件基準第12条への適合説明、ソフトウェア安全性クラス分類とリスクマネジメント（ISO 14971）の統合運用、SOUPおよびレガシーソフトウェアの取扱い、設計・検証文書の整備と申請対応まで、数多くの医療機器メーカーを支援してきました。最新のAI技術への深い知見と、規制対応の実務経験を融合させ、本当に使えるAI活用方法を具体的にお伝えします。
【関連の活動など】
- 日本PDA 第9回年会併催シンポジウム 21 CFR Part 11その現状と展望
- 日本製薬工業協会 医薬品評価委員会 基礎研究部会主催（東京）
- 東京大学大学院医学系研究科 臨床試験データ管理学講座などにて多数講演。など
受講者の声
大変勉強になりました。また他の講座も受講しようと思います。（ソフトウェア開発担当）
生成AIを用いた資料作成のデモを行うところに特に興味を持ちました。JIS T 2304の資料作成に工数が非常にかかるため、工数削減の方法を模索していました。（ソフトウェア開発担当）
リスク分析やソフトウェアアイテム分割について、特に興味を持ちました。IEC62304／ISO14971／ISO13485／IEC60601-1／IEC62366に関する知識や経験が乏しかったので、理解を深めることができました。（開発職）
規制当局に提出するに値するソフトウェアドキュメントを、生成AIを駆使していかに効率的に作成していくかを学ぶために参加しました。ドキュメントをAIに作成してもらうために、どのようなプロンプトを入力するかが特に参考になりました。（通信ライブラリの設計・実装担当）
1．はじめに
・医療にかかわるソフトウェアの分類
・ヘルスソフトウェアと法規制対象（「ヘルスソフトウェア」＝規制対象外、ではない）
・医用電気機器（ME機器）とは／ME機器設計機器要求事項とリスク分析の関係
・ソフトウェア（プログラム）について／単体プログラムとは
・デジタルセラピューティクス（DTx）とは
・DTxの先駆け：「処方されるアプリ」Bluestar（WellDoc社）
・「治療のために処方される世界初のDTx」reSET（Pear Therapeutics社）
・日本におけるデジタルセラピューティクス
・米国におけるDigital Health、Digital Medicine、Digital Therapeutics、SaMDの概念
2．用語の定義
・SaMD（Software as a Medical Device）／単体プログラム
・プロセス／アクティビティ／タスク（ISO 9000）
・ソフトウェアアイテム（SOFTWARE ITEM）／ソフトウェアユニット／ソフトウェアシステム
・SOUP（Software Of Unknown Provenance：開発経路が不明なソフトウェア）
・医療機器ソフトウェア（MEDICAL DEVICE SOFTWARE）／レガシーソフトウェア
3．医療機器ソフトウェア規制の要点
・JIS T 2304:2012（IEC 62304:2006）への対応が必要となる範囲（組込みソフトウェア・単体プログラム）
・IEC 62304はプロセス規格である／IEC 62304対応のみでは認証を受けられない
・システム開発アクティビティ・リスクマネジメントアクティビティは規格の範囲外
・ISO 14971（リスクマネジメント）・ISO 13485（品質マネジメント）との関係／米国FDAの扱い
・IEC 62304で実施すべきこと（仕様書の検証記録、アーキテクチャでのアイテム分割、アイテム毎の安全性クラス分類A・B・C）
4．JIS T 2304の適用について
・基本要件基準とは？（医療機器・体外診断用医薬品が具備すべき基本的要件）
・GHTF／IMDRFと基本要件の成立経緯
・基本要件基準の構成（ISO 13485・ISO 14971・IEC 62304・IEC 62366-1・IEC 81001-5-1との関係）
・基本要件適合性チェックリスト／申請時の記載例
・JIS T 2304の適用について（JIS T 2304:2017の公示）
・“JIS T 2304”への対応が必要となった法改正の経緯
・医療機器の基本要件基準 第12条「プログラムを用いた医療機器に対する配慮」
・医療機器の基本要件基準第12条第2項の適用について（薬生機審発0517第1号）
・JIS T 2304への適合の根拠となる文書の記載例（記載事例1〜3）
・経過措置期間終了後の適合性の確認・申請書添付資料での説明方法
・医療機器の基本要件基準第12条第2項の適用に関するQ&A（業界版）
・医療機器の基本要件基準第12条第3項の追記（2023年3月31日／サイバーセキュリティ）
5．IEC 62304概要
・IEC 62304とは（Medical device software - Software life cycle processes／Edition 1.1）
・ソフトウェアの安全性はソフトウェア単体ではなく外部との関わりの中で現れる
・安全性クラス（3段階）とクラスに応じたアクティビティ・タスクの規定
・IEC 62304とキーとなる医療機器関連標準との関係（ISO 14971・ISO 13485・IEC 60601-1等）
・機器要求事項とソフトウェア要求事項の関係（PRS／SRS／リスク分析／ユーザビリティ報告書／トレーサビリティマトリックス）
・IEC 62304 目次（第4章〜第9章、附属書A〜D）
・ソフトウェア開発プロセスの概観／ソフトウェア保守プロセスの概観
6．IEC 62304逐条解説
・IEC 62304規格適合とは？（1.4 適合）
・4.1 品質システム（ISO 13485／FDA 21 CFR Part 820／薬機法・QMS省令）
・4.2 リスク管理 解説（ISO 14971との関係、リスク分類の観点の相違）
・4.3 安全性分類（Software Safety Classification）／ソフトウェアアイテムへの分解の例
・4.4 レガシーソフトウェア（一般／リスクマネジメント活動／ギャップ分析／使用の論拠）
・5.1 ソフトウェア開発プランニング（開発計画の継続更新、結合試験計画、リスクマネジメント計画、文書化・構成管理プランニング、支援アイテムの管理、共通ソフトウェア欠陥の特定及び回避）
・5.2 ソフトウェア要求事項の分析（定義・内容・リスク管理策の包含・リスク分析の再評価・検証）
・5.3 ソフトウェアアーキテクチャの設計（要求事項の変換、インタフェース、リスク管理に必要な分離の特定、検証）
・5.4 ソフトウェア詳細設計（ソフトウェアユニットへの分割、ユニットごとの詳細設計）
・5.5 ソフトウェアユニットの実行（実装、検証プロセスの確立、追加の合否判定基準）
・5.6 ソフトウェア結合及び結合試験（結合の検証、試験の内容、試験手順の検証、回帰テスト）
・5.7 ソフトウェアシステム試験（試験の確立、変更後の再試験、試験の評価、試験記録の内容）
・5.8 システムレベルで利用するためのソフトウェアリリース（検証完了確認、既知の残留異常の文書化、アーカイブ、確実な配布の確保）
・6. ソフトウェアメンテナンスプロセス（保守計画の作成、障害及び対応方法の分析、変更分の適用）
・7. ソフトウェアリスク管理プロセス（ハザードを引き起こす可能性の分析、リスクコントロール、その検証、ソフトウェア変更によるリスクの管理）
・8. ソフトウェア構成管理プロセス（構成の定義、変更履歴管理、旧バージョンの取得）
・9. ソフトウェアの問題解決プロセス
7．リスクマネジメントについて
・医療機器リスクマネジメントとは？
・リスクの定義（ISO/IEC Guide 51）／リスクとは？
・許容可能なリスク（「安全」の定義）
・リスク評価の実際（R-Map法）
・重大性と発生確率の低減／どうやって安全にするのか？
・航空機はなぜ飛ばせることができるのか？
・一般的なリスクマネジメントプロセス
・Step1 ハザードを見つける／ISO 14971:2019 表C.1 － ハザードの例
・ハザード、危害、リスク
・機器設計リスクマネジメントワークシート
・機器設計機器要求事項とリスク分析の関係
8．レビュの重要性
・ピープル・パワーとプロセス・パワー
・ソフトウェアには設計工程しかない（製造工程は存在しない）
・HP社は、ソフトウェア開発において「シックスシグマ」と「CR手法」を組み合わせた
・FDA Guidance for industry and FDA staff / General Principles of Software Validation
・レビュとは／承認とは
・要求仕様書の重要性
・3つのレビュ形態
・インスペクションの実施要領／ソフトウェアインスペクションの目的
9．ソフトウェアのテスト
・FDAガイドライン General Principles of Software Validation「5.2.5 ソフトウェア開発者によるテスト」
・ソフトウェアテスト計画書と、テストの限界（全機能のテスト＝全プログラムのテストではない）
・テストの信条（予期される結果の定義、良いテストケースの条件）
・テストスクリプトとテストデータ
・テストログ（サンプル）／テストの実施とテストログ
・スクリーンショットが必要な場合
・試験進捗および不良成長曲線／バグ成長曲線と残存欠陥数の推定
・自動静的解析ツールの使用（V&Vの効率化、生産性・開発サイクルへの効果）
・新業務プロセスの検討（BPR：People・Process・Technologyのバランス）
10．510(k)申請について
・FDA 510(k)申請のタイムフレーム
・FDAの510(k)審査のフローチャート
・FDAの厳格なレビュについて（Verification and Validationの証拠要求）
・他社事例：V&Vレポートの不備に対する追加情報要求
・他社事例：ランタイムエラー検出（使用ツール・検出エラータイプ・プロセスの明示）
・一般的なランタイムエラー（未初期化変数、タイプ不一致、メモリ・リーク、バッファオーバー／アンダーフロー、到達不能コード等）
・追加情報提出時の体裁（ページ番号・タブ付セクションの目次・各質問への明確な回答）
・確認すべきガイダンス文書・コンセンサス規格（IEC 62304、ISO 14971）
【配布資料一覧】
・講義スライド資料
・生成AIライブデモ_進行台本＆プロンプト素材.docx
・戦略的規制遵守プロンプト集.docx
・規制対応AIツール評価マトリックス（17ツール比較）.docx
・AI規制モニタリングシステム構築ガイド_2026年7月版.docx
・AI規制モニタリングシステム_セキュリティチェックシート.docx
・生成AIデモ結果.zip（生成AIで実際に作成した成果物一式）
─ ソフトウェア開発計画書_GlucoGuide_ドラフト v0.1／v0.2（Word）
─ ソフトウェア要求仕様書_GlucoGuide_ドラフト v0.1／v0.2（Word）
─ ソフトウェアアーキテクチャ仕様書_GlucoGuide_ドラフト v0.1／v0.2（Word）
─ SOP-SW-001_医療機器ソフトウェア開発手順書_IEC62304準拠／v2.0（Word）
─ トレーサビリティマトリックス_GlucoGuide_v0.1（Excel）
─ リスクマネジメントワークシート_GlucoGuide_v0.1（Excel）
─ その他デモ用サンプルファイル
・医療にかかわるソフトウェアの分類
・ヘルスソフトウェアと法規制対象（「ヘルスソフトウェア」＝規制対象外、ではない）
・医用電気機器（ME機器）とは／ME機器設計機器要求事項とリスク分析の関係
・ソフトウェア（プログラム）について／単体プログラムとは
・デジタルセラピューティクス（DTx）とは
・DTxの先駆け：「処方されるアプリ」Bluestar（WellDoc社）
・「治療のために処方される世界初のDTx」reSET（Pear Therapeutics社）
・日本におけるデジタルセラピューティクス
・米国におけるDigital Health、Digital Medicine、Digital Therapeutics、SaMDの概念
2．用語の定義
・SaMD（Software as a Medical Device）／単体プログラム
・プロセス／アクティビティ／タスク（ISO 9000）
・ソフトウェアアイテム（SOFTWARE ITEM）／ソフトウェアユニット／ソフトウェアシステム
・SOUP（Software Of Unknown Provenance：開発経路が不明なソフトウェア）
・医療機器ソフトウェア（MEDICAL DEVICE SOFTWARE）／レガシーソフトウェア
3．医療機器ソフトウェア規制の要点
・JIS T 2304:2012（IEC 62304:2006）への対応が必要となる範囲（組込みソフトウェア・単体プログラム）
・IEC 62304はプロセス規格である／IEC 62304対応のみでは認証を受けられない
・システム開発アクティビティ・リスクマネジメントアクティビティは規格の範囲外
・ISO 14971（リスクマネジメント）・ISO 13485（品質マネジメント）との関係／米国FDAの扱い
・IEC 62304で実施すべきこと（仕様書の検証記録、アーキテクチャでのアイテム分割、アイテム毎の安全性クラス分類A・B・C）
4．JIS T 2304の適用について
・基本要件基準とは？（医療機器・体外診断用医薬品が具備すべき基本的要件）
・GHTF／IMDRFと基本要件の成立経緯
・基本要件基準の構成（ISO 13485・ISO 14971・IEC 62304・IEC 62366-1・IEC 81001-5-1との関係）
・基本要件適合性チェックリスト／申請時の記載例
・JIS T 2304の適用について（JIS T 2304:2017の公示）
・“JIS T 2304”への対応が必要となった法改正の経緯
・医療機器の基本要件基準 第12条「プログラムを用いた医療機器に対する配慮」
・医療機器の基本要件基準第12条第2項の適用について（薬生機審発0517第1号）
・JIS T 2304への適合の根拠となる文書の記載例（記載事例1〜3）
・経過措置期間終了後の適合性の確認・申請書添付資料での説明方法
・医療機器の基本要件基準第12条第2項の適用に関するQ&A（業界版）
・医療機器の基本要件基準第12条第3項の追記（2023年3月31日／サイバーセキュリティ）
5．IEC 62304概要
・IEC 62304とは（Medical device software - Software life cycle processes／Edition 1.1）
・ソフトウェアの安全性はソフトウェア単体ではなく外部との関わりの中で現れる
・安全性クラス（3段階）とクラスに応じたアクティビティ・タスクの規定
・IEC 62304とキーとなる医療機器関連標準との関係（ISO 14971・ISO 13485・IEC 60601-1等）
・機器要求事項とソフトウェア要求事項の関係（PRS／SRS／リスク分析／ユーザビリティ報告書／トレーサビリティマトリックス）
・IEC 62304 目次（第4章〜第9章、附属書A〜D）
・ソフトウェア開発プロセスの概観／ソフトウェア保守プロセスの概観
6．IEC 62304逐条解説
・IEC 62304規格適合とは？（1.4 適合）
・4.1 品質システム（ISO 13485／FDA 21 CFR Part 820／薬機法・QMS省令）
・4.2 リスク管理 解説（ISO 14971との関係、リスク分類の観点の相違）
・4.3 安全性分類（Software Safety Classification）／ソフトウェアアイテムへの分解の例
・4.4 レガシーソフトウェア（一般／リスクマネジメント活動／ギャップ分析／使用の論拠）
・5.1 ソフトウェア開発プランニング（開発計画の継続更新、結合試験計画、リスクマネジメント計画、文書化・構成管理プランニング、支援アイテムの管理、共通ソフトウェア欠陥の特定及び回避）
・5.2 ソフトウェア要求事項の分析（定義・内容・リスク管理策の包含・リスク分析の再評価・検証）
・5.3 ソフトウェアアーキテクチャの設計（要求事項の変換、インタフェース、リスク管理に必要な分離の特定、検証）
・5.4 ソフトウェア詳細設計（ソフトウェアユニットへの分割、ユニットごとの詳細設計）
・5.5 ソフトウェアユニットの実行（実装、検証プロセスの確立、追加の合否判定基準）
・5.6 ソフトウェア結合及び結合試験（結合の検証、試験の内容、試験手順の検証、回帰テスト）
・5.7 ソフトウェアシステム試験（試験の確立、変更後の再試験、試験の評価、試験記録の内容）
・5.8 システムレベルで利用するためのソフトウェアリリース（検証完了確認、既知の残留異常の文書化、アーカイブ、確実な配布の確保）
・6. ソフトウェアメンテナンスプロセス（保守計画の作成、障害及び対応方法の分析、変更分の適用）
・7. ソフトウェアリスク管理プロセス（ハザードを引き起こす可能性の分析、リスクコントロール、その検証、ソフトウェア変更によるリスクの管理）
・8. ソフトウェア構成管理プロセス（構成の定義、変更履歴管理、旧バージョンの取得）
・9. ソフトウェアの問題解決プロセス
7．リスクマネジメントについて
・医療機器リスクマネジメントとは？
・リスクの定義（ISO/IEC Guide 51）／リスクとは？
・許容可能なリスク（「安全」の定義）
・リスク評価の実際（R-Map法）
・重大性と発生確率の低減／どうやって安全にするのか？
・航空機はなぜ飛ばせることができるのか？
・一般的なリスクマネジメントプロセス
・Step1 ハザードを見つける／ISO 14971:2019 表C.1 － ハザードの例
・ハザード、危害、リスク
・機器設計リスクマネジメントワークシート
・機器設計機器要求事項とリスク分析の関係
8．レビュの重要性
・ピープル・パワーとプロセス・パワー
・ソフトウェアには設計工程しかない（製造工程は存在しない）
・HP社は、ソフトウェア開発において「シックスシグマ」と「CR手法」を組み合わせた
・FDA Guidance for industry and FDA staff / General Principles of Software Validation
・レビュとは／承認とは
・要求仕様書の重要性
・3つのレビュ形態
・インスペクションの実施要領／ソフトウェアインスペクションの目的
9．ソフトウェアのテスト
・FDAガイドライン General Principles of Software Validation「5.2.5 ソフトウェア開発者によるテスト」
・ソフトウェアテスト計画書と、テストの限界（全機能のテスト＝全プログラムのテストではない）
・テストの信条（予期される結果の定義、良いテストケースの条件）
・テストスクリプトとテストデータ
・テストログ（サンプル）／テストの実施とテストログ
・スクリーンショットが必要な場合
・試験進捗および不良成長曲線／バグ成長曲線と残存欠陥数の推定
・自動静的解析ツールの使用（V&Vの効率化、生産性・開発サイクルへの効果）
・新業務プロセスの検討（BPR：People・Process・Technologyのバランス）
10．510(k)申請について
・FDA 510(k)申請のタイムフレーム
・FDAの510(k)審査のフローチャート
・FDAの厳格なレビュについて（Verification and Validationの証拠要求）
・他社事例：V&Vレポートの不備に対する追加情報要求
・他社事例：ランタイムエラー検出（使用ツール・検出エラータイプ・プロセスの明示）
・一般的なランタイムエラー（未初期化変数、タイプ不一致、メモリ・リーク、バッファオーバー／アンダーフロー、到達不能コード等）
・追加情報提出時の体裁（ページ番号・タブ付セクションの目次・各質問への明確な回答）
・確認すべきガイダンス文書・コンセンサス規格（IEC 62304、ISO 14971）
【配布資料一覧】
・講義スライド資料
・生成AIライブデモ_進行台本＆プロンプト素材.docx
・戦略的規制遵守プロンプト集.docx
・規制対応AIツール評価マトリックス（17ツール比較）.docx
・AI規制モニタリングシステム構築ガイド_2026年7月版.docx
・AI規制モニタリングシステム_セキュリティチェックシート.docx
・生成AIデモ結果.zip（生成AIで実際に作成した成果物一式）
─ ソフトウェア開発計画書_GlucoGuide_ドラフト v0.1／v0.2（Word）
─ ソフトウェア要求仕様書_GlucoGuide_ドラフト v0.1／v0.2（Word）
─ ソフトウェアアーキテクチャ仕様書_GlucoGuide_ドラフト v0.1／v0.2（Word）
─ SOP-SW-001_医療機器ソフトウェア開発手順書_IEC62304準拠／v2.0（Word）
─ トレーサビリティマトリックス_GlucoGuide_v0.1（Excel）
─ リスクマネジメントワークシート_GlucoGuide_v0.1（Excel）
─ その他デモ用サンプルファイル
価格:77,000円(税込) ～ 331,650円(税込)
[ポイント還元 3,850ポイント～]
