fda-consultant-specialist

FDA コンサルタントスペシャリスト

医療機器メーカー向けの FDA 規制コンサルティングです。申請経路、品質システム規則（QSR）、HIPAA への準拠、医療機器のサイバーセキュリティ要件を対象としています。

目次

• FDA 申請経路の選択
• 510(k) 申請プロセス
• QSR への準拠
• 医療機器における HIPAA
• 医療機器のサイバーセキュリティ
• リソース

---

まず確認すること

申請経路を選択したり、準拠状況を評価したりする前に、以下の入力情報を確認してください。情報が欠けている、または曖昧で、その違いによって結果が変わる場合は質問してください。結果が変わらない場合は、妥当なデフォルトを使用し、使用した内容を明記してください。

• 医療機器のクラスと述語機器： クラス I／II／III、および述語機器が存在するかどうか（510(k)、De Novo、PMA のいずれになるかを左右します）。
• 使用目的／適応： 医療機器が主張する内容と使用環境（実質的同等性の論拠および必要な臨床エビデンスを決定します）。
• ソフトウェア／AI の性質： SaMD、PCCP が必要な適応型 AI、または接続型医療機器（サイバーセキュリティ／SBOM）（必要な文書一式が変わります）。

一覧全体ではなく、この依頼に最も重要な 2、3 項目について質問してください。ユーザーがすぐに結果を求めている場合は、結果を提示し、冒頭に前提条件を明記してください。

FDA 申請経路の選択

医療機器の分類と述語機器の有無に基づいて、適切な FDA 規制申請経路を決定します。

判断フレームワーク

Predicate device exists?
├── YES → Substantially equivalent?
│   ├── YES → 510(k) Pathway
│   │   ├── No design changes → Abbreviated 510(k)
│   │   ├── Manufacturing only → Special 510(k)
│   │   └── Design/performance → Traditional 510(k)
│   └── NO → PMA or De Novo
└── NO → Novel device?
    ├── Low-to-moderate risk → De Novo
    └── High risk (Class III) → PMA

申請経路の比較

申請経路	使用する場合	期間	費用
510(k) Traditional	述語機器が存在し、設計変更がある場合	90 日	$21,760
510(k) Special	製造上の変更のみの場合	30 日	$21,760
510(k) Abbreviated	ガイダンス／規格への適合を示す場合	30 日	$21,760
De Novo	新規性があり、リスクが低度から中程度の場合	150 日	$134,676
PMA	クラス III で、述語機器が存在しない場合	180 日以上	$425,000+

事前申請戦略

1. 製品コードと分類を特定する
2. 510(k) データベースで述語機器を検索する
3. 実質的同等性を示せるか評価する
4. FDA 向けの Q-Sub 質問を準備する
5. 必要に応じて Pre-Sub ミーティングを設定する

参考： 申請経路の判断マトリックスと申請要件については、fda_submission_guide.md を参照してください。

---

510(k) 申請プロセス

ワークフロー

Phase 1: Planning
├── Step 1: Identify predicate device(s)
├── Step 2: Compare intended use and technology
├── Step 3: Determine testing requirements
└── Checkpoint: SE argument feasible?

Phase 2: Preparation
├── Step 4: Complete performance testing
├── Step 5: Prepare device description
├── Step 6: Document SE comparison
├── Step 7: Finalize labeling
└── Checkpoint: All required sections complete?

Phase 3: Submission
├── Step 8: Assemble submission package
├── Step 9: Submit via eSTAR
├── Step 10: Track acknowledgment
└── Checkpoint: Submission accepted?

Phase 4: Review
├── Step 11: Monitor review status
├── Step 12: Respond to AI requests
├── Step 13: Receive decision
└── Verification: SE letter received?

必須セクション（21 CFR 807.87）

セクション	内容
カバーレター	申請の種類、医療機器 ID、連絡先情報
Form 3514	CDRH 市販前審査カバーシート
医療機器の説明	物理的な説明、動作原理
使用適応	Form 3881、患者集団、使用環境
SE 比較	述語機器との並列比較
性能試験	ベンチ試験、生体適合性、電気安全性
ソフトウェア文書	懸念レベル、ハザード分析（IEC 62304）
表示	IFU、包装ラベル、警告
510(k) サマリー	申請内容の公開サマリー

よくある RTA の問題

問題	防止策
ユーザー手数料の不足	申請前に支払いを確認する
Form 3514 の記入漏れ	すべての項目を確認し、署名があることを確認する
述語機器が特定されていない	FDA データベースで K 番号を確認する
SE 比較が不十分	すべての技術的特性に対応する

---

QSR への準拠

医療機器メーカーに対する品質システム規則（21 CFR Part 820）の要件です。

主なサブシステム

セクション	タイトル	焦点
820.20	経営者の責任	品質方針、組織構成、マネジメントレビュー
820.30	設計管理	インプット、アウトプット、レビュー、検証、妥当性確認
820.40	文書管理	承認、配布、変更管理
820.50	購買管理	サプライヤーの適格性確認、購買データ
820.70	製造管理	プロセスバリデーション、環境管理
820.100	CAPA	根本原因分析、是正措置
820.181	機器マスターレコード	仕様、手順、合格基準

設計管理ワークフロー（820.30）

Step 1: Design Input
└── Capture user needs, intended use, regulatory requirements
    Verification: Inputs reviewed and approved?

Step 2: Design Output
└── Create specifications, drawings, software architecture
    Verification: Outputs traceable to inputs?

Step 3: Design Review
└── Conduct reviews at each phase milestone
    Verification: Review records with signatures?

Step 4: Design Verification
└── Perform testing against specifications
    Verification: All tests pass acceptance criteria?

Step 5: Design Validation
└── Confirm device meets user needs in actual use conditions
    Verification: Validation report approved?

Step 6: Design Transfer
└── Release to production with DMR complete
    Verification: Transfer checklist complete?

CAPA プロセス（820.100）

1. 特定：不適合または潜在的な問題を文書化します
2. 調査：根本原因分析を実施します（5 Whys、フィッシュボーン図）
3. 計画：是正措置／予防措置を定義します
4. 実施：措置を実行し、文書を更新します
5. 検証：実施が完了したことを確認します
6. 有効性確認：再発がないか監視します（30～90 日間）
7. クローズ：経営陣の承認を得て終了します

参考： 詳細な QSR 実装ガイダンスについては、qsr_compliance_requirements.md を参照してください。

---

医療機器に関する HIPAA

保護対象保健情報（PHI）を作成、保存、送信、またはアクセスする機器に関する HIPAA 要件です。

適用範囲

機器の種類	HIPAA の適用
スタンドアロン診断機器（データ送信なし）	いいえ
患者データを送信する接続型機器	はい
EHR 統合機能を備えた機器	はい
患者情報を保存する SaMD	はい
ウェルネスアプリ（診断なし）	PHI を保存する場合のみ

必要な安全対策

Administrative (§164.308)
├── Security officer designation
├── Risk analysis and management
├── Workforce training
├── Incident response procedures
└── Business associate agreements

Physical (§164.310)
├── Facility access controls
├── Workstation security
└── Device disposal procedures

Technical (§164.312)
├── Access control (unique IDs, auto-logoff)
├── Audit controls (logging)
├── Integrity controls (checksums, hashes)
├── Authentication (MFA recommended)
└── Transmission security (TLS 1.2+)

リスク評価の手順

1. ePHI を扱うすべてのシステムを棚卸しします
2. データフロー（収集、保存、送信）を文書化します
3. 脅威と脆弱性を特定します
4. 発生可能性と影響を評価します
5. リスクレベルを判定します
6. 管理策を実装します
7. 残存リスクを文書化します

参考： 実装チェックリストと BAA テンプレートについては、hipaa_compliance_framework.md を参照してください。

---

機器のサイバーセキュリティ

接続型医療機器に関する FDA のサイバーセキュリティ要件です。

市販前の要件

要素	説明
脅威モデル	STRIDE 分析、攻撃ツリー、信頼境界
セキュリティ管理策	認証、暗号化、アクセス制御
SBOM	ソフトウェア部品表（CycloneDX または SPDX）
セキュリティテスト	ペネトレーションテスト、脆弱性スキャン
脆弱性対応計画	開示プロセス、パッチ管理

機器のティア分類

ティア 1（高リスク）：

• ネットワーク／インターネットに接続します
• サイバーセキュリティインシデントによって患者に危害が及ぶ可能性があります

ティア 2（標準リスク）：

• その他すべての接続型機器

市販後の義務

1. NVD と ICS-CERT で脆弱性を監視します
2. 機器のコンポーネントへの該当性を評価します
3. パッチを開発し、テストします
4. 顧客と連絡を取ります
5. ガイダンスに従って FDA に報告します

脆弱性の協調開示

Researcher Report
    ↓
Acknowledgment (48 hours)
    ↓
Initial Assessment (5 days)
    ↓
Fix Development
    ↓
Coordinated Public Disclosure

参考： SBOM 形式の例と脅威モデリングのテンプレートについては、device_cybersecurity_guidance.md を参照してください。

---

リソース

scripts/

スクリプト	目的
fda_submission_tracker.py	510(k)／PMA／De Novo 申請のマイルストーンとスケジュールを追跡します
qsr_compliance_checker.py	プロジェクト文書に基づいて 21 CFR 820 への準拠状況を評価します
hipaa_risk_assessment.py	医療機器ソフトウェアにおける HIPAA の安全対策を評価します

references/

ファイル	内容
fda_submission_guide.md	510(k)、De Novo、PMA の申請要件とチェックリスト
qsr_compliance_requirements.md	テンプレート付きの 21 CFR 820 実施ガイド
hipaa_compliance_framework.md	HIPAA セキュリティルールの安全対策と BAA 要件
device_cybersecurity_guidance.md	FDA のサイバーセキュリティ要件、SBOM、脅威モデリング
fda_capa_requirements.md	CAPA プロセス、根本原因分析、有効性検証

使用例

# Track FDA submission status
python scripts/fda_submission_tracker.py /path/to/project --type 510k

# Assess QSR compliance
python scripts/qsr_compliance_checker.py /path/to/project --section 820.30

# Run HIPAA risk assessment
python scripts/hipaa_risk_assessment.py /path/to/project --category technical

---

FDA QMSR — 品質マネジメントシステム規制

QSR（21 CFR 820）から QMSR への移行

FDA は 2024 年 1 月に品質マネジメントシステム規制（QMSR）を最終決定し、従来の品質システム規制（QSR）を ISO 13485:2016 に準拠する規制に置き換えました。この規則は 2026 年 2 月 2 日 に施行されました。

項目	従来の QSR（21 CFR 820）	QMSR（2026 年 2 月施行）
フレームワーク	FDA 固有の規範的要件	ISO 13485:2016 を参照により組み込み
設計管理	820.30（FDA 固有）	ISO 13485 条項 7.3
CAPA	820.100	ISO 13485 条項 8.5
文書管理	820.40	ISO 13485 条項 4.2
経営者の責任	820.20	ISO 13485 条項 5
購買管理	820.50	ISO 13485 条項 7.4

QMSR における主な違い：

• ISO 13485:2016 が主要な QMS 規格として参照により組み込まれています
• FDA は、ISO 13485 でカバーされない一部の医療機器固有要件（例：21 CFR 820.198 に基づく苦情処理）を引き続き適用します
• すでに ISO 13485 認証を取得している組織は、大きな先行優位性があります
• QMS に関する FDA の個別登録は不要です。単一のシステムで ISO と FDA の両方に対応します

QMSR 移行チェックリスト

• ISO 13485:2016 と現在の QSR 遵守状況のギャップ分析
• ISO 13485 の条項構成を参照するよう品質マニュアルを更新
• 既存の SOP を ISO 13485 の条項に対応付け
• FDA 固有の継続適用要件（苦情処理、MDR 報告）に対応
• ISO 13485 の用語と構成についてスタッフをトレーニング
• 新しい規制の枠組みを参照するようサプライヤー契約を更新
• QMSR 要件に照らした内部監査を実施
• ISO 13485 条項 7.3 の形式に設計履歴ファイルを更新

---

AI/ML ベースの医療機器ソフトウェア（SaMD）

FDA AI/ML SaMD フレームワーク

カテゴリ	説明	FDA の申請経路
固定アルゴリズム	アルゴリズムは導入後に変更されません	標準的な 510(k)/De Novo/PMA
適応型アルゴリズム（PCCP）	アルゴリズムは使用に伴って学習し、変化します	事前規定変更管理計画
継続学習型	新しいデータからリアルタイムに適応します	ケースバイケース。PCCP が必要

AI/ML SaMD の申請要件

AI/ML SaMD Submission Package
├── Algorithm description and architecture
├── Training data characterization
│   ├── Data sources and collection methods
│   ├── Demographics and representativeness
│   ├── Data quality and labeling methodology
│   └── Training/validation/test split rationale
├── Performance evaluation
│   ├── Pre-specified performance goals
│   ├── Standalone performance metrics (sensitivity, specificity, AUC)
│   ├── Subgroup analysis (age, sex, race, site)
│   └── Real-world performance data (if available)
├── Reference standard justification
├── Predetermined Change Control Plan (if adaptive)
├── Human factors / user interface
├── Cybersecurity documentation
└── Software documentation per IEC 62304

優れた機械学習実践（GMLP）の原則

1. 製品ライフサイクル全体を通じた学際的な専門知識
2. 優れたソフトウェアエンジニアリングとセキュリティの実践
3. 代表性のあるトレーニングデータセットとテストデータセット
4. トレーニングデータとは別の独立したテストデータセット
5. 利用可能な最善の手法に基づく参照データセット
6. 利用可能なデータと意図する用途に合わせたモデル設計
7. 人間と AI のチームとしてのパフォーマンスを重視
8. 臨床試験による実環境でのパフォーマンスの実証
9. ユーザーに明確で不可欠な情報を提供
10. 導入したモデルのパフォーマンスを監視し、再トレーニングを管理

---

AI/ML 医療機器向け事前規定変更管理計画（PCCP）

PCCP の構成

セクション	内容	根拠
変更内容の説明	アルゴリズムが実施する変更の種類	変更仕様書
変更プロトコル	変更の開発方法およびテスト方法	検証プロトコル
影響評価	各変更の種類が安全性と有効性に与える影響	変更の種類ごとのリスク分析
性能モニタリング	実環境での継続的な性能追跡	指標を含むモニタリング計画
更新の検証	各更新を展開前に検証する方法	検証および妥当性確認計画
透明性	変更についてユーザーに通知する方法	コミュニケーション計画

PCCP の変更カテゴリ

カテゴリ	例	検証レベル
性能向上	追加データで再トレーニングしたモデル	自動テスト＋臨床的検証
入力の適応	新しい画像診断モダリティへの対応	完全な V&V サイクル
出力の変更	新たなリスクカテゴリまたは信頼度レベル	臨床研究
アーキテクチャの変更	モデルアーキテクチャの更新	新規申請（510(k)/PMA supplement）

---

サイバーセキュリティ要件の強化（PATCH Act）

PATCH Act（2023 年 3 月施行、FD&C Act §524B に成文化）では、次の事項が求められます。

要件	詳細	根拠
サイバーセキュリティ計画	脆弱性の監視、特定、対処に関する計画を提出する	市販前申請のセクション
SBOM	商用、オープンソース、市販コンポーネントを含むソフトウェア部品表	CycloneDX または SPDX 形式
パッチ／更新機能	ライフサイクル全体を通じてパッチ適用可能なデバイスを設計する	アーキテクチャ文書
脆弱性の協調的開示	CVD プロセスを確立し、維持する	公開済みセキュリティポリシー
市販後の更新	合理的に正当化されたサイクルでパッチと更新を提供する	パッチ管理計画

市販前申請向けサイバーセキュリティ文書

Cybersecurity Premarket Package
├── Security risk assessment
│   ├── Threat model (STRIDE or equivalent)
│   ├── Security risk analysis per AAMI TIR57
│   └── Attack surface analysis
├── Security architecture
│   ├── Security controls implementation
│   ├── Cryptographic architecture
│   └── Network architecture and trust boundaries
├── SBOM (Software Bill of Materials)
│   ├── All software components (commercial, open-source, custom)
│   ├── Version information
│   └── Known vulnerability status
├── Security testing
│   ├── Static analysis (SAST)
│   ├── Dynamic analysis (DAST)
│   ├── Penetration testing report
│   ├── Fuzz testing results
│   └── Vulnerability scanning results
├── Lifecycle security plan
│   ├── Patch management process
│   ├── End-of-life/end-of-support plan
│   └── Customer communication plan
└── Coordinated vulnerability disclosure policy

---

相互参照：AI 医療機器に関する EU AI Act

AI 搭載医療機器を両法域で販売する場合、FDA の要件と EU AI Act の両方を遵守する必要があります。

項目	FDA のアプローチ	EU AI Act のアプローチ	調和戦略
リスク分類	SaMD リスクフレームワーク（IMDRF）	附属書 III の高リスク（医療機器）	両方のフレームワークに対応付け、より厳格な基準を適用する
透明性	ラベリング要件	第 13 条の透明性義務	統一された透明性文書
データガバナンス	GMLP の原則	第 10 条のデータおよびデータガバナンス	包括的なデータ品質プログラム
人間による監視	IEC 62366 に基づくヒューマンファクター	第 14 条の人間による監視	ヒューマンファクターと監視を統合した設計
市販後	実環境での性能モニタリング	第 72 条の市販後モニタリング	両方に対応する単一のモニタリングシステム
技術文書	FDA の市販前申請	附属書 IV の技術文書	統一された技術ファイル

関連項目： AI/ML 医療機器の EU MDR 分類については ../mdr-745-specialist/SKILL.md を、AI 機器の ISO 14971 リスク管理については ../risk-management-specialist/SKILL.md を参照してください。

---

510(k) の電子申請要件の更新（eSTAR）

eSTAR の義務化

2023 年 10 月 1 日以降、FDA はすべての 510(k) 申請で eSTAR テンプレート形式を使用することを義務付けています。紙での申請は受け付けられなくなりました。

eSTAR の要件	詳細
テンプレート	FDA eSTAR テンプレート（入力可能な PDF）
形式	構造化データフィールド＋添付ファイル
添付ファイル	PDF/A 形式、ブックマーク付き、OCR 検索可能
ファイル名	FDA の命名規則に準拠する必要があります
申請ポータル	CDRH Customer Collaboration Portal または FDA ESG
最大ファイルサイズ	個々のファイルにつき 100MB。合計サイズの上限なし

eSTAR セクションの対応表

eSTAR セクション	内容	よくある不備
管理関連	カバーレター、ユーザーフィー、真実性・正確性に関する声明	署名漏れ、手数料の誤り
デバイスの説明	画像・図を含むデバイスの完全な説明	詳細不足、付属品の記載漏れ
実質的同等性	比較対象デバイスとの比較表	比較基準が不完全
性能試験	要約を含むすべての試験報告書	合格基準の記載漏れ、プロトコルの不備
ソフトウェア	懸念レベル、ハザード分析、アーキテクチャ	IEC 62304への準拠状況が古い
生体適合性	ISO 10993 に基づく評価または試験	リスク評価の記載漏れ、接触分析の不備
滅菌	滅菌バリデーションの概要	再処理手順の記載漏れ（再使用可能なデバイス）
表示	デバイスのラベル、IFU、患者向け資料	21 CFR 801 への不適合
EMC／電気安全	IEC 60601-1 への適合	個別規格への適合状況の記載漏れ
臨床	臨床データの概要（該当する場合）	新たな適応症に対する臨床エビデンスの不足

---

フレームワーク間の対応関係：FDA ↔ MDR ↔ ISO 13485

プロセス領域	FDA (QMSR/QSR)	EU MDR 2017/745	ISO 13485:2016
品質マネジメントシステム	21 CFR 820 / QMSR	Annex IX, Annex XI	Clause 4
経営者の責任	820.20 / ISO 13485 Cl. 5	Annex IX §2.2	Clause 5
設計管理	820.30 / ISO 13485 Cl. 7.3	Annex II §6.1, GSPR	Clause 7.3
文書管理	820.40 / ISO 13485 Cl. 4.2	Annex IX §2.3	Clause 4.2
購買	820.50 / ISO 13485 Cl. 7.4	Annex IX §2.4	Clause 7.4
製造	820.70 / ISO 13485 Cl. 7.5	Annex IX §2.5	Clause 7.5
CAPA	820.100 / ISO 13485 Cl. 8.5	Art. 83 (PMS), Art. 89 (FSCA)	Clause 8.5
リスクマネジメント	820.30(g) / ISO 14971	Annex I (GSPR), ISO 14971	Clause 7.1
臨床エビデンス	820.30(f) / 臨床データ	Annex XIV (臨床評価)	N/A (別途対応)
市販後	820.198 / MDR/MedWatch	Art. 83-86 (PMS), Art. 87-92 (ビジランス)	Clause 8.2.1-8.2.3
表示	21 CFR 801	Art. 10-13, Annex I Ch. III	N/A (別途対応)
UDI	21 CFR 830 (FDA UDI)	Art. 27-29 (UDI-DI/PI)	N/A (別途対応)
サイバーセキュリティ	§524B FD&C (PATCH Act)	MDCG 2019-16	N/A (別途対応)
AI/ML デバイス	AI/ML SaMD フレームワーク + PCCP	EU AI Act + MDR	ISO 13485 + ISO 42001

相互参照： QMSR に準拠した ISO 13485 の実装については ../quality-manager-qms-iso13485/SKILL.md を、EU MDR の技術文書要件については ../mdr-745-specialist/SKILL.md を参照してください。

---

FDA 規制の最新情報とフレームワーク間の統合

FDA QMSR — 品質マネジメントシステム規則

FDA は、2026 年 2 月 2 日に発効する品質マネジメントシステム規則（QMSR）を通じて、21 CFR Part 820 を ISO 13485:2016 に整合させています。

• 主な変更点： QSR（21 CFR 820）に代わり、ISO 13485 が認められた品質システム規格になります
• 影響： 製造業者は、QSR 固有の要件ではなく ISO 13485:2016 に準拠する必要があります
• 設計管理： ISO 13485 Clause 7.3 が 820.30 に代わります
• CAPA： ISO 13485 Clause 8.5 が 820.90/820.100 に代わります
• 移行： FDA は移行期間中、QSR と QMSR の両方を受け入れます

AI/ML ベースの医療機器ソフトウェア（SaMD）

• 事前規定変更管理計画（PCCP）： 学習・適応する AI/ML デバイスに必要です
• 適正機械学習プラクティス（GMLP）： 医療機器における AI/ML に関する FDA の 10 の指針
• 透明性： AI/ML ベースの機能と制限事項を明確に表示します
• 実環境での性能： 市販後に AI モデルの性能ドリフトを監視します
• 相互参照： AI 医療機器に関する EU AI Act の要件については eu-ai-act-specialist を参照してください

強化されたサイバーセキュリティ要件（PATCH Act）

• 市販前申請： すべてのネットワーク接続機器について、サイバーセキュリティ文書が必要です
• ソフトウェア部品表（SBOM）： すべての市販前申請で必須です
• 協調的な脆弱性開示： すべてのネットワーク接続機器メーカーにポリシーの策定が求められます
• 市販後のパッチ： サイバーセキュリティパッチは510(k)要件の適用対象外です
• 相互参照： 技術的なサイバーセキュリティチェックについては、infrastructure-compliance-auditorを参照してください

フレームワーク間の対応関係（FDA ↔ MDR ↔ ISO 13485）

領域	FDA（QSR/QMSR）	EU MDR 2017/745	ISO 13485:2016
設計管理	820.30 / QMSR	Annex II	Clause 7.3
リスクマネジメント	820.30(g)	Annex I GSPR	ISO 14971
臨床エビデンス	820.30(f)	Annex XIV	Clause 7.3.7
CAPA	820.90/100	Art. 83, 89	Clause 8.5
市販後	822, MDR	Chapter VII	Clause 8.2.1
サイバーセキュリティ	FDA Guidance	MDCG 2019-16	IEC 62443
AI/ML	PCCP Framework	EU AI Act	ISO 42001

---

トラブルシューティング

問題	考えられる原因	解決方法
510(k)申請がRTA（受理拒否）として返却された	ユーザー料金の未払い、Form 3514の未記入、比較対象機器が特定されていない、またはSE比較が不十分	FDAガイダンスに基づいてRTAチェックリストを確認してください。支払いを確認し、eSTARのすべてのフィールドに記入し、FDAデータベースでK番号を確認して、SE比較ですべての技術的特性に対応してください
QSRコンプライアンスチェッカーで設計管理（820.30）に不足が表示される	設計履歴ファイルが未完成、またはQMSRに基づくISO 13485 Clause 7.3との整合性がない	既存のDHFをISO 13485 Clause 7.3の構成に対応付けてください。設計入力、出力、レビュー、検証、妥当性確認がトレーサビリティを伴って文書化されていることを確認してください
HIPAAリスク評価で技術的保護措置のスコアが低い	保存時／転送時の暗号化がない、MFAが実装されていない、または監査ログが有効になっていない	保存時にはAES-256暗号化、転送時にはTLS 1.2+、ePHIにアクセスするすべてのユーザーにMFAを導入し、包括的な監査ログを有効にしてください。hipaa_risk_assessment.pyを--category technical付きで実行して検証してください
510(k)審査中にFDAからAIに関する追加情報要求を受けた	性能試験が不十分、SEの論拠が不完全、またはソフトウェア文書に不足がある	180日以内に回答してください。各質問に具体的に対応し、IEC 62304に従って、追加の試験データ、臨床エビデンス、またはソフトウェア文書を提出してください
QMSR移行のギャップ分析で大きな差異が明らかになった	組織のQMSがISO 13485ではなく旧版の21 CFR 820を中心に構成されている	820の各小項をISO 13485の各条項に対応付ける体系的なギャップ分析を実施してください。苦情処理（FDAの要件として維持）、すべてのプロセスにわたるリスクベースのエビデンス、品質マニュアルの更新を優先してください
市販前申請のサイバーセキュリティ文書が却下された	SBOMが不完全、脅威モデルがない、または協調的な脆弱性開示ポリシーが公開されていない	CycloneDXまたはSPDX形式で包括的なSBOMを作成し、AAMI TIR57に従ってSTRIDE脅威モデルを完成させ、CVDポリシーを公開し、パッチ管理ライフサイクル計画を文書化してください
AI/ML SaMD申請に事前規定変更管理計画がない	PCCPの枠組みなしで適応型アルゴリズムが導入されている	変更の種類、検証プロトコル、影響評価、性能監視、ユーザーへの通知計画を網羅するPCCPを策定してください。適切な検証レベルとともに、4つすべての変更カテゴリを含めてください

---

成功基準

• 510(k)申請を初回で受理 -- RTA指摘事項がゼロで、eSTARの全セクションが完了し、ユーザーフィーが確認済みで、比較対象機器が特定され、すべての技術的特性に対処したSE比較が含まれていること
• QSR/QMSR準拠スコアが85％超 -- qsr_compliance_checker.pyによる測定で、重要な小項目（設計管理、CAPA、文書管理）すべてに実施の証拠が示されていること
• HIPAAの技術的保護措置を完全に実装 -- 保存データのAES-256暗号化、転送中データのTLS 1.2以上、MFAの適用、監査管理の稼働、およびePHIを扱うすべてのシステムでの自動ログオフ設定
• FDA申請の目標スケジュールを達成 -- 従来型510(k)は90日以内、De Novoは150日以内、PMAは180日以内とし、fda_submission_tracker.pyのマイルストーンで追跡すること
• QMSRへの移行を完了 -- 品質マニュアルがISO 13485の条項構成を参照し、すべてのSOPが対応付けられ、FDA固有の継続要件に対処し、QMSR要件に照らした内部監査が実施されていること
• すべてのネットワーク接続機器についてサイバーセキュリティ文書を完成 -- 市販前申請にSBOM、脅威モデル、セキュリティ試験報告書、脆弱性開示ポリシー、パッチ管理計画が含まれていること

---

対象範囲と制限事項

対象範囲：

• FDA規制経路の選択（510(k)、De Novo、PMA）：意思決定フレームワークと比較を含む
• eSTAR要件、SE比較、RTA防止を含む510(k)申請プロセス
• 品質システム規則（21 CFR 820）およびQMSR（ISO 13485:2016との整合）への準拠評価
• 医療機器ソフトウェアに対するHIPAAセキュリティ規則の保護措置の評価
• SBOM、脅威モデリング、PATCH Actへの準拠を含む、機器のサイバーセキュリティ要件
• PCCP、GMLPの原則、トレーニングデータの特性評価を含むAI/ML SaMDフレームワーク
• FDA、EU MDR、ISO 13485間のフレームワーク対応付け

対象範囲外：

• 実際のFDA申請文書の作成または執筆 -- このスキルが提供するのはフレームワークとギャップ分析であり、文書の作成ではありません
• PMA臨床データに関する臨床試験の設計、実施、または統計解析
• FDA施設登録、機器リスティング、またはUDIシステムの実装
• プロセスに関するガイダンスを超える市販後監視の報告（MDR、MedWatch）
• De Novo分類申請に関する科学的審査の準備
• FDA審査担当者との直接のやり取り、またはPre-Submission（Q-Sub）会議の進行支援

重要な注意事項：

• QMSRは2026年2月2日に発効しました -- すべての製造業者は、参照により組み込まれたISO 13485:2016と、FDA固有の継続要件に準拠する必要があります
• 品質システム検査手法（QSIT）は廃止され、Compliance Program 7382.850に基づく更新された検査手順に置き換えられました
• QMSRでは、設計管理だけでなく、すべてのQMSプロセスにおいてリスクベースの考え方が求められます

---

統合ポイント

スキル	統合内容	使用する場面
quality-manager-qms-iso13485	QMSRに準拠したISO 13485 QMSの実装、プロセス管理およびサプライヤーの適格性確認	ISO 13485認証とFDA QMSR要件の両方を満たすQMSを実装する場合
mdr-745-specialist	米国・EU両市場への申請に向けたフレームワーク間のマッピング、技術文書の整合	医療機器にFDAの認可／承認とEU MDRのCEマーキングの両方が必要な場合
capa-officer	ISO 13485第8.5項に基づくCAPAプロセス管理（QMSRにより従来の820.100に代わるもの）	FDA品質システム内で是正措置および予防措置を管理する場合
risk-management-specialist	設計管理およびサイバーセキュリティリスク評価に統合されたISO 14971リスク管理	820.30(g)およびAAMI TIR57に基づく市販前申請のリスク分析を実施する場合
eu-ai-act-specialist	米国とEUの両方で販売される機器を対象とした、管轄区域をまたぐAI/MLコンプライアンス	AI対応医療機器にFDA PCCPフレームワークとEU AI Act適合性評価の両方が必要な場合
infrastructure-compliance-auditor	コネクテッドデバイスのセキュリティ管理策に関する技術的なサイバーセキュリティ検証	市販前申請に向けてサイバーセキュリティアーキテクチャとSBOMを文書化する場合

---

ツールリファレンス

fda_submission_tracker.py

FDA申請のマイルストーンを追跡し、510(k)、De Novo、PMAの各申請経路の規制上のタイムラインを算出します。

フラグ	必須	説明
<project_dir>	はい	申請書類を含むプロジェクトディレクトリのパス
--type <pathway>	いいえ	申請の種類：510k（デフォルト）、de_novo、pma、pma_supplement
--json	いいえ	結果をJSON形式で出力します

出力： 完了状況を含むマイルストーンの追跡、FDA審査目標に対するタイムラインの算出、フェーズの進捗状況（計画、準備、申請、審査、決定）、および期限超過マイルストーンのアラート。

qsr_compliance_checker.py

プロジェクトの文書を分析して実装の証拠を確認し、21 CFR Part 820／QMSRへの準拠状況を評価します。

フラグ	必須	説明
<project_dir>	はい	QMS文書を含むプロジェクトディレクトリのパス
--section <section>	いいえ	特定のQSRセクションを確認します（例：設計管理の場合は820.30、CAPAの場合は820.100）
--json	いいえ	結果をJSON形式で出力します

出力： セクションごとの準拠状況、確認された証拠（文書のパターンとキーワードの一致）、準拠率、必要な証拠の説明を伴うギャップの特定。

hipaa_risk_assessment.py

医療機器ソフトウェアおよびコネクテッドデバイスについて、HIPAAセキュリティルールの保護策を評価します。

フラグ	必須	説明
<project_dir>	はい	評価対象のプロジェクトディレクトリのパス
--category <cat>	いいえ	特定のカテゴリを評価します：administrative、physical、technical、またはすべて（デフォルト）
--json	いいえ	結果をJSON形式で出力します

出力： 管理的（第164.308項）、物理的（第164.310項）、技術的（第164.312項）カテゴリにおける保護策ごとの準拠状況に加え、重み付けスコア、証拠の検出、是正の推奨事項。