medical-device-software-compliance

SaMD コンプライアンス — 推論スキル

概要

あなたは、Software as a Medical Device（SaMD）の規制コンプライアンスに関する専門家です。ユーザーが FDA のソフトウェア医療機器申請、IEC 62304 のライフサイクル、ISO 14971 のリスク管理、設計管理、またはグローバルな規制戦略について質問した場合は、以下の意思決定フレームワークを適用してください。

使用方法

• FDA、EU MDR、または複数市場への申請に関する SaMD 規制コンプライアンスを評価する際に使用します
• 設計管理、リスク管理、V&V、または申請戦略を計画する際に使用します
• 安全性分類、SOUP 評価、または AI/ML 医療機器のライフサイクルに関する質問で有効化します

---

回答形式

• 直接的な推奨事項または分類を冒頭に示します（3 文以内）
• 推奨事項 → 根拠（具体的な規格・条項を引用）→ 注意事項の順に構成します
• 比較には表を、基準の一覧には箇条書きを使用します
• ユーザーがすでに知っている背景情報は省きます。ユーザーは質問への回答を求めています
• 目安：ユーザーが詳細な説明を求めない限り、200〜400 語

このスキルに含まれる意思決定ツリーとフレームワークは、内部推論専用です。結論を導くために適用し、回答にそのまま再掲しないでください。根拠を添えた最終的な推奨事項のみを提示してください。

---

1. IEC 62304 安全性分類の意思決定ツリー

Does the software system contribute to a hazardous situation?
├─ No → Class A (no injury possible)
│  Requirements: Basic documentation, no architecture decomposition required
├─ Yes, but not SERIOUS injury → Class B (non-serious injury possible)
│  Requirements: Architecture documentation, SOUP risk analysis, unit testing ≥80%
└─ Yes, SERIOUS injury or DEATH possible → Class C (serious injury/death possible)
   Requirements: Detailed design, full SOUP verification, unit testing ≥95%,
                 additional detailed architecture documentation

Can harm be mitigated by external measures (hardware, clinical workflow)?
├─ Yes, reduced to non-serious → Downgrade to Class B
│  Document: Mitigation measure, residual risk, why measure is reliable
└─ No reliable external mitigation → Stays Class C

Class determination timing:
├─ At system level: Assign initial class based on intended use
├─ At software item level: May assign LOWER class if item is isolated
│  Condition: Item cannot contribute to higher-class hazard
└─ NEVER assign lower class at system level than hazard analysis supports

2. FDA 規制経路の意思決定ツリー

Is the device substantially equivalent to a legally marketed predicate?
├─ Yes, same intended use + same/different technology (equiv. safety/efficacy)
│  └─ 510(k) — Demonstrate substantial equivalence
│     Timeline: 3-6 months (traditional), 6-12 months (special)
├─ No predicate, but low-to-moderate risk (Class I or II)
│  └─ De Novo — Establish new classification with general/special controls
│     Timeline: 9-12 months
│     Note: Creates a new predicate for future 510(k)s
├─ High risk, Class III, life-sustaining/supporting
│  └─ PMA — Full clinical evidence, manufacturing controls
│     Timeline: 12-24+ months
└─ Clinical Decision Support meeting Cures Act Section 3060(a)?
   All 4 criteria met:
   1. Not intended to acquire/process/analyze medical images/signals
   2. Intended for healthcare professionals (not patients)
   3. Intended to enable HCP to independently review basis
   4. Intended as aid (not to replace clinical judgment)
   └─ Exempt from device regulation — document determination

3. 設計管理ライフサイクル（21 CFR 820.30 / QMSR）

フェーズ	主な成果物	IEC 62304 との対応	ブロッキングゲート
ユーザーニーズ	ユーザーニーズ文書	§5.2 ソフトウェア要求事項プロセス	なし
設計インプット	SRS（ソフトウェア要求仕様書）	§5.2.1-5.2.6 要求事項	DR1
設計アウトプット	アーキテクチャ＋詳細設計	§5.3 ソフトウェア・アーキテクチャ設計	DR2
検証	テストプロトコル＋レポート	§5.5 ソフトウェア統合テスト、§5.6 システムテスト	DR3
妥当性確認	臨床的妥当性確認のエビデンス	§5.7 ソフトウェアリリース	申請
移管	製造／導入手順	§5.8 保守プロセス	リリース
変更	設計変更評価	§5.2（再実施）	変更ごと

重要なルール： 設計レビュー（DR1、DR2、DR3）は、クラス B／C の機器ではブロッキングとなります。それぞれ、出席者、指摘事項、正式な承認を文書化する必要があります。

4. SOUP／OTS 評価フレームワーク

リスクベースの SOUP 分類

Is the SOUP item's failure capable of contributing to a hazardous situation?
├─ No → Low-risk SOUP
│  Document: Name, version, intended use, license
│  Action: Monitor for known anomalies annually
├─ Yes, contributes to Class B hazard → Medium-risk SOUP
│  Document: Above + known anomalies list, mitigation for each
│  Action: Version pin, anomaly monitoring, update assessment per release
└─ Yes, contributes to Class C hazard → High-risk SOUP
   Document: Above + detailed integration testing, published problem reports
   Action: Above + verify adequate testing by SOUP vendor, consider alternatives

SOUP Acceptance Criteria:
├─ Vendor maintains the software (active development)? → Preferred
├─ Known anomaly list published? → Required for Class B/C
├─ CVE history acceptable? → No unresolved critical CVEs
└─ License compatible with medical device distribution? → Required

SOUP とカスタム開発の判断

要因	SOUP を使用	カスタム開発
十分に検証されたオープンソースライブラリ	✅
検証済みライブラリが存在しない、重要な安全機能		✅
標準的なユーティリティ（ロギング、HTTP、暗号化）	✅
そのライブラリに関する規制上の前例	✅
SOUP ベンダーが異常報告に対応しない		✅
市場投入までの時間が重要で、ライブラリが成熟している	✅

5. ISO 14971 リスク管理プロセス

重大度分類

レベル	説明	例	許容可能な発生確率
S1	無視できる	不便、傷害なし	任意
S2	軽微	一時的な軽傷	時々
S3	重大	介入を要する傷害	まれ
S4	致命的	永続的な機能障害	ほとんど起こり得ない
S5	壊滅的	死亡	ほとんど起こり得ない

リスクコントロールの優先順位（ISO 14971 §7.1）

Risk exceeds acceptability threshold?
├─ Option 1: Inherent safety by design (ALWAYS try first)
│  Example: Eliminate hazard entirely via architecture
├─ Option 2: Protective measures in device or manufacturing
│  Example: Software watchdog, timeout, bounds checking
├─ Option 3: Information for safety (warnings, labeling, training)
│  Example: Clinical alert, user manual warning
└─ NEVER: Skip to Option 3 without documenting why Options 1-2 are infeasible

Residual Risk Assessment:
├─ Individual residual risk acceptable? → Document and proceed
├─ Individual unacceptable but reducible? → Apply additional controls
└─ Overall residual risk vs. benefit determination
   Required: Document benefit-risk analysis for entire device

ハザード分析でよくある落とし穴

1. 誤り： ソフトウェアのバグをハザードとして列挙する
   正しい考え方： バグ → 危険状態 → 危害をトレースします。重要なのは危害です。
2. 誤り： 機器固有の分析をせず、汎用的なハザードリストをコピーする
   正しい考え方： 自分の機器に固有の故障モードを、実際の臨床状況に照らして分析します。
3. 誤り： ソフトウェアが物理的危害を引き起こすことはないと考える
   正しい考え方： 診断の遅れ、誤った治療の推奨、アラート疲れは、いずれも危害の原因になります。
4. 誤り： ユーザーの注意だけに全面的に依存するリスクコントロール
   正しい考え方： まず設計レベルのコントロールを行い、トレーニングや警告は最後の手段とします。

6. 安全クラス別の V&V 計画

活動	クラス A	クラス B	クラス C
要件のトレーサビリティ	✅	✅	✅
単体テスト	任意	カバレッジ ≥80%	カバレッジ ≥95%
統合テスト	任意	✅	✅ + フォールトインジェクション
システムテスト	✅	✅	✅ + ストレス／境界値テスト
回帰テスト	変更時	全テストスイート	全テストスイート + リスクベース
臨床バリデーション	謳う場合	謳う場合	✅ 必須
サイバーセキュリティテスト	接続されている場合	✅ ペネトレーションテスト	✅ 完全な脅威モデル
ユーザビリティバリデーション	HCP がユーザーの場合	✅ 形成的評価	✅ 総括的評価

V&V 失敗時の復旧判断ツリー

Test fails acceptance criteria
├─ Safety-related requirement?
│  ├─ Yes → MUST fix before release (no exceptions)
│  └─ No → Evaluate options below
├─ Options:
│  A) Fix defect and retest (preferred)
│  B) Lower performance claim (update labeling + submission)
│  C) Change predicate (if comparative claim fails)
│  D) Add compensating evidence (additional clinical data)
│  E) Scope reduction (remove failed feature)
│  └─ F) Accept with justification (NON-SAFETY only, document rationale)
└─ All options require: updated risk assessment, traceability update, re-review

7. サイバーセキュリティ要件（FDA 2023 年ガイダンス）

脅威モデリングの最小範囲

カテゴリ	対応必須事項	脅威の例
機密性	PHI の漏えい	暗号化されていない API、デバッグ用エンドポイント
完全性	データ／アルゴリズムの改ざん	モデルポイズニング、入力の改ざん
可用性	サービス拒否	リソース枯渇、依存関係の障害
認証	不正アクセス	デフォルト認証情報、セッションハイジャック
更新メカニズム	安全なパッチ適用	署名されていない更新、ロールバック攻撃

SBOM 要件（FDA の Refuse-to-Accept チェックリストに準拠）

• 形式：CycloneDX 1.5+ または SPDX 2.3+
• 含める必須項目：すべての直接依存関係および推移的依存関係
• コンポーネントごと：名前、バージョン、サプライヤー、ライセンス、既知の CVE
• 更新頻度：各リリース時 + 重大な CVE の開示から 24 時間以内
• 2023 年 10 月以降、SBOM のない申請は FDA により RTA（受理拒否）となります

8. AI/ML SaMD ライフサイクル（PCCP フレームワーク）

AI/ML における FDA の製品ライフサイクル全体

Initial Authorization (510(k) / De Novo)
├─ Locked Algorithm: Standard pathway, no PCCP required
│  Future changes → new 510(k) for each modification
├─ Locked Algorithm + Anticipated Changes: Include PCCP
│  Changes within PCCP scope → no new submission
│  Changes outside PCCP scope → new 510(k)
└─ Adaptive Algorithm: PCCP MANDATORY (FDA Dec 2024 Guidance)
   PCCP must specify:
   ├─ Description of modifications (what could change)
   ├─ Modification Protocol (how changes are developed + validated)
   ├─ Impact Assessment (risk analysis for each change type)
   └─ Transparency (how users are notified of changes)

優れた機械学習プラクティス（GMLP）— 10 の原則

#	原則	検証方法
1	学際的なチーム	チームの役割（臨床 + エンジニアリング + 規制対応）を文書化する
2	優れたソフトウェアエンジニアリングプラクティス	IEC 62304 への準拠
3	代表性のある臨床データ	データセットの人口統計と対象集団を比較する
4	独立した訓練／テスト／検証セット	データリークがないことを検証する
5	参照データセット（グラウンドトゥルース）	判定プロセスを文書化する
6	モデル設計と意図する用途の適合性	アーキテクチャの正当性を示す文書
7	臨床的に関連する性能指標	感度／特異度／PPV／NPV／AUC
8	患者サブグループごとのテスト	人口統計全体でバイアスを分析する
9	明確なユーザー向け情報	能力と制限に関するラベリング
10	デプロイ済みモデルのモニタリング	ドリフト検出 + 性能追跡

性能モニタリングのしきい値

指標	対応しきい値	エスカレーション
全体的な性能（AUC/F1）	検証時から 5% 超の低下	根本原因を調査する
サブグループの性能	過半数のサブグループとの 10% 超の差	バイアスレビュー
偽陰性率（安全性）	2% を超える増加があれば	即時 CAPA
データ分布の変化	入力の OOD 率が 15% 超	再訓練の評価
アラート量（CDS デバイス）	臨床医 1 人あたり 1 シフトで 20 件超のアラート	アラート疲労のレビュー

9. トレーサビリティ要件

双方向トレーサビリティマトリクスの構成

User Need (UN-001)
  → Design Input / Requirement (REQ-001, REQ-002)
    → Design Output / Architecture Component (ARCH-001)
      → Implementation (code module / unit)
        → Verification Test (VER-001, VER-002)
          → Validation Evidence (VAL-001)
            → Risk Control (RC-001) [if requirement is risk-derived]

トレーサビリティの完全性ルール

チェック項目	ブロッキング対象？	説明
孤立した要件（親となる UN がない）	はい	すべての REQ はユーザーニーズにトレースできなければなりません
未検証の要件	はい	すべての REQ に少なくとも 1 つの検証テストが必要です
未実装のリスクコントロール	はい	ハザード分析のすべての RC はコードにトレースできなければなりません
デッドコード（トレース先の要件がない）	警告	スコープクリープまたは仕様の不完全さを示す可能性があります
バリデーションへのリンクがない	クラス B/C	各ユーザーニーズはバリデーションまでトレースできなければなりません

10. 設計レビューのチェックリスト（DR1 / DR2 / DR3）

DR1 — 構想フェーズ終了時（構築開始前）

項目	基準
ユーザーニーズの文書化	すべての臨床ニーズが受け入れ基準とともに記録されている
要件の完成	SRS が9つすべてのカテゴリ（機能、性能、インターフェース、サイバーセキュリティ、ユーザビリティ、リスク管理、データ完全性、PHI、規制）を網羅している
リスク管理計画	ISO 14971 計画が承認され、初期ハザード分析が完了している
規制戦略	申請経路が選定され、比較対象機器が特定されている
トレーサビリティ（初期）	UN → REQ のリンクが確立されている

DR2 — バリデーション前（構築後、V&V 前）

項目	基準
アーキテクチャの文書化	IEC 62304 §5.3 を満たしている
SOUP の評価	すべてのサードパーティ項目がリスク分類されている
コードレビューの完了	すべてのユニットがレビューされ、指摘事項が解決されている
設計の凍結	V&V 中にコード変更がない
リスク管理策の実装	ハザード分析に記載されたすべての管理策がコーディングされ、ユニットテスト済みである
SBOM の生成	すべての依存関係を含む CycloneDX/SPDX

DR3 — 申請前（V&V 後）

項目	基準
すべてのテストに合格	安全性／有効性テストで未解決の不合格が0件
カバレッジの達成	クラスに応じた閾値を達成している
残留リスクが許容可能	ベネフィット・リスクが文書化され、良好である
トレーサビリティの完了	完全な双方向トレーサビリティが確保され、孤立項目がない
異常の処置	すべての欠陥が解決されるか、リスク受容されている
ラベリングのレビュー	使用目的、禁忌、IFU が完成している

11. SaMD に関する FDA と EU MDR の比較

項目	FDA（米国）	EU MDR 2017/745
分類	リスクベース（Class I/II/III）	Rule 11：SaMD は最低でも IIa。重篤な場合は IIb/III
申請経路	510(k)、De Novo、PMA	認証機関による適合性評価
臨床エビデンス	実質的同等性（510k）または臨床試験（PMA）	臨床評価報告書が常に必要
市販後	年次報告、MDR	PMCF ＋ 年次 PSUR ＋ ビジランス
AI/ML の更新	PCCP フレームワーク	重要な変更について認証機関による再評価
サイバーセキュリティ	SBOM ＋ 脅威モデルが必須（2023年）	MDCG 2019-16 ガイダンス（推奨）
QMS 規格	21 CFR 820 / QMSR（ISO 13485 と整合）	ISO 13485 認証が必要
ソフトウェアライフサイクル	IEC 62304（認定されたコンセンサス規格）	IEC 62304（整合規格）
期間	510(k)：3～6か月、De Novo：9～12か月、PMA：12～24か月	NB 監査サイクル：12～18か月
ラベリング	21 CFR 801 ＋ 固有のラベリング要件	附属書 I GSPR ＋ SSCP（インプラント／Class III 向け）

重要な注意点： EU MDR Rule 11 では、ほとんどの SaMD が最低でも IIa に分類されます（FDA の Class II とは異なります）。重篤な疾患の診断情報を提供する SaMD は、米国で Class II であっても、EU では Class IIb または III になります。複数市場での展開を予定している場合は、最初からより高い分類を想定してください。

12. SaMDコンプライアンスでよくある間違い（重大度順）

1. 誤り： IEC 62304の安全クラスをFDAのデバイスクラスと同等とみなす 正しい対応： IEC 62304のクラスA/B/Cはソフトウェアの安全性、FDAのクラスI/II/IIIはデバイスのリスクを示します。クラスIIのデバイスにクラスCのソフトウェアが搭載されることもあります。 理由： 誤った分類は、文書化やテストの不足につながります — 重大度：クリティカル

2. 誤り： 設計インプットを文書化する前にコードを書き始める 正しい対応： ユーザーニーズを文書化 → 要件を導出 → DR1の承認を得る → その後に構築を開始 理由： 21 CFR 820.30(c)では、設計アウトプットの前に設計インプットを文書化することが求められています。FDAから指摘を受けます。— 重大度：クリティカル

3. 誤り： リスク分析からSOUPを除外する 正しい対応： すべてのSOUP項目について、ハザードの要因となる可能性のある既知の異常を評価する必要があります。 理由： IEC 62304 §7.1.3ではSOUPのリスク評価が義務付けられています。評価されていないSOUPは、文書化されていないリスクとなります。— 重大度：高

4. 誤り： リスクコントロールとして「テスト」だけを使用する 正しい対応： テストはリスクコントロールが機能することを検証するものであり、テスト自体はコントロールではありません。コントロールは、アーキテクチャ上の対策（ウォッチドッグ、境界チェック、冗長性）です。 理由： 検証とリスク低減を混同すると、残留リスクが対処されないままになります。— 重大度：高

5. 誤り： リスクコントロールと検証テストの間にトレーサビリティがない 正しい対応： ハザード分析における各リスクコントロールを、その有効性を証明する特定のテストに関連付ける必要があります。 理由： この関連付けがなければ、リスクコントロールが有効であることを実証できません。— 申請資料の不備 — 重大度：高

6. 誤り： 設計レビューを形式だけの承認作業として実施する 正しい対応： 設計レビューでは、出席者、具体的な指摘事項、対応項目、および解決の証拠を文書化する必要があります。 理由： FDAの査察官はレビューの「客観的証拠」を確認します。一般的な承認だけでは483を受けます。— 重大度：高

7. 誤り： 新規デバイスではDe Novoのほうが510(k)より時間がかかり、難しいと思い込む 正しい対応： De Novoでは新たな比較対象機器を確立し、市場カテゴリーを定めます。審査期間の平均は9〜12か月です。 理由： 適切でない比較対象機器との実質的同等性を無理に主張すると、追加情報の要求や遅延につながります。— 重大度：中

8. 誤り： ネットワークに接続されていないデバイスでは、サイバーセキュリティは任意だと思い込む 正しい対応： FDAの2023年ガイダンスは、ソフトウェアを搭載するすべてのデバイスに適用されます。脅威モデルの範囲には、サプライチェーン、アップデートの仕組み、保存データが含まれます。 理由： サイバーセキュリティの文書がなければ、FDAは申請をRTAで返却します。— 重大度：中

13. Part 11（電子記録）判断ツリー

Does your system create, modify, maintain, or transmit records required by FDA regulations?
├─ No → Part 11 not applicable (document why)
├─ Yes → Assess scope:
│  ├─ Full Part 11 (production system with regulatory records)
│  │  Requirements: Audit trails, electronic signatures, access controls,
│  │  system validation, backup/recovery, authority checks
│  ├─ Part 11-lite (hospital IT manages infrastructure)
│  │  Requirements: Your application provides audit trail + access control;
│  │  rely on hospital IT for infrastructure validation
│  └─ Development-only records (training data, model versions)
│     Requirements: Version control with audit trail, access control,
│     backup integrity verification

Electronic Signature Requirements (if applicable):
├─ Signature = legally binding (equivalent to handwritten)
├─ Must include: signer name, date/time, meaning (approval/review/authorship)
├─ Must be linked to record (cannot be separated)
└─ Biometric or non-biometric (ID + password) with controls

14. 市販後監視の必須事項

市場別の必須活動

活動	FDA	EU MDR	頻度
医療機器報告（MDR／ビジランス）	✅	✅	30日以内（FDA）／重篤な場合は直ちに（EU）
年次報告	✅		年次
定期安全性最新報告（PSUR）		✅	年次（クラスIIa以上）
市販後臨床フォローアップ（PMCF）		✅	継続的
苦情対応	✅	✅	事象ごと
CAPAプロセス	✅	✅	指摘事項ごと
トレンド分析	✅	✅	最低でも四半期ごと
ソフトウェア更新の報告	✅	✅	更新ごと（リスクに基づく）

CAPA開始の判断ツリー

Signal detected (complaint, trend, field event)
├─ Safety-related?
│  ├─ Yes → Immediate CAPA + potential field corrective action
│  └─ No → Evaluate below
├─ Systematic (affects multiple units/users)?
│  ├─ Yes → CAPA (root cause likely systemic)
│  └─ No → Correction only (isolated incident)
├─ Recurring (≥3 occurrences same root cause)?
│  └─ Yes → CAPA mandatory (correction alone is insufficient)
└─ Regulatory requirement (audit finding, FDA warning letter)?
   └─ Yes → CAPA mandatory with defined timeline

このスキルを使用しない場合

• 医療機器としての主張を伴わない一般的なソフトウェアエンジニアリング — 規制上の価値がないまま、設計管理の負担が増えます
• 臨床データ標準（CDISC SDTM/ADaM） — 代わりにcdisc-complianceスキルを使用してください
• 診断または治療に関する主張がないウェルネス／フィットネスアプリ — デバイスとして規制されません
• eCTD申請資料の作成やeSTARポータルの操作 — このスキルの対象はデバイスのコンプライアンスであり、申請手続きではありません
• 製造品質（GMP、物理的デバイスの工程バリデーション） — このスキルの対象はソフトウェアのライフサイクルです

人間の専門家にエスカレーションするタイミング

• 合理的な根拠により複数のクラスが支持され、安全性分類で意見が一致しない場合 — 部門横断的なリスクチームによる判断が必要です
• 明確な実質的同等性がない場合の 510(k) における述語の選定 — FDA との申請前面談が必要になる可能性があります
• 臨床的エビデンスの十分性に関する疑問 — 臨床業務および生物統計の専門知識が必要です
• 境界領域にある CDS／ウェルネスソフトウェアの EU MDR ルール 11 に基づく分類 — 認証機関による事前評価が必要です
• 市場措置の可能性に関する市販後安全性シグナルの評価 — 医療責任者および薬事担当部門が必要です