digital-health-compliance-planning について
デジタルヘルス製品のチーム向けに、特定のフレームワークに依存せず計画を支援するスキルです。プライバシー、研究、規制、ガバナンスを評価し、前提、リスク、未解決の質問、次の手順をコンプライアンス計画書にまとめます。
主な機能
- 01健康データと製品の状況を評価
- 02HIPAA、IRB、FDA、GDPR の領域を確認
- 03製品範囲に関わるリスクと判断事項を特定
- 04リポジトリ用の計画書を作成
活用シーン
- 01製品計画の早期にコンプライアンス範囲を定める
- 02IRB またはプライバシーレビューの準備
- 03データ保持、エクスポート、削除要件の整理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ stanfordspezi/ spezivibe --skill digital-health-compliance-planningインストール後、Claude Code で/digital-health-compliance-planningを入力して読み込まれたか確認します。
詳細
コンプライアンス計画
デジタルヘルス製品に関するプライバシー、研究、規制、ガバナンスの要件を、特定のフレームワークに依存せずに計画します。
使用するタイミング
次のような場合に、このスキルを使用します。
- 製品が規制対象の健康データまたは研究データを扱うかどうかを評価する
- HIPAA、IRB、FDA、GDPR、または機関による審査についての協議に備える
- 同意、保持、エクスポート、削除、監査に関する要件を定める
- 製品のスコープを早期に左右すべきコンプライアンス作業を特定する
作業方針
すぐに管理策の検討に飛びつかないでください。まず、次の点を把握します。
- 製品の目的
- ユーザーは誰か
- 製品が臨床ケア、研究、ウェルネス、運用、教育のいずれに該当するか
- どのようなデータを収集、生成、共有、エクスポートするか
- どの地域、機関、パートナーが関与するか
その後、前提、リスク、未解決の質問、推奨される次のステップをまとめた簡潔なコンプライアンス計画書を作成します。
主な質問
次の点について確認します。
- 使用目的と製品の主張
- 患者、研究参加者、臨床医、コーディネーター、介護者などのユーザーグループ
- 収集、推測、アップロードするデータ、または外部システムから連携するデータの種類
- 製品が研究、品質改善、直接的なケアのいずれを支援するか
- データの保存、処理、共有が行われる場所
- サードパーティのベンダーとサブプロセッサー
- 管理者アクセス、監査の必要性、インシデント対応に関する要件
- エクスポート、削除、訂正、保持に関する要件
審査するコンプライアンス領域
HIPAAと機関のプライバシー
製品が保護対象の医療情報、または機関が管理するデータを扱う可能性があるかを確認します。
次の点を検討します。
- どのような識別情報が含まれるか
- 対象事業体または業務提携先に該当するのは誰か
- 必要最小限のアクセスに関する要件
- 職員、管理者、サポート担当者のアクセス範囲
- ログ記録、監視、データ侵害への対応に関する要件
研究とIRB
製品が研究を支援する場合は、次の点を検討します。
- 研究の目的とプロトコルの成熟度
- 募集と同意の方法
- リスクレベルと参加者の負担
- 参加撤回の手順
- 非識別化または匿名化の方法
- データ共有と二次利用の計画
digital-health-study-planning も実行する場合、参加者向けの同意と登録のフローはそちらが担当します。このスキルは、それらのフローが満たすべき規制要件を担当します。重複を避け、連携してください。
FDAと製品の主張
製品が医療機器に関わるソフトウェアとして扱われる可能性を評価します。
次の点を確認します。
- 診断、治療の推奨、介入を目的としたモニタリング、または臨床上の判断を促す機能があるか
- 出力は情報提供、助言、またはアクションのトリガーのいずれか
- 製品に誤りがある、利用できない、または遅延した場合に何が起きるか
GDPRと国境を越えたプライバシー
EUまたは英国のユーザーが関与する可能性がある場合は、次の点を検討します。
- 適法な根拠
- 同意と撤回の仕組み
- データ主体の権利への対応
- 移転の仕組み
- 保持、削除、処理記録に関する要件
計画の成果物
次のセクションを含む計画書を作成し、プロジェクトリポジトリ内の docs/planning/compliance-brief.md に保存します。
1. スコープの概要
- 製品の目的
- ユーザーグループ
- 法域と機関
- 対象となるデータカテゴリ
2. 該当する可能性が高いコンプライアンス領域
各項目に likely、possible、または unlikely を付けます。
- HIPAAまたは機関のプライバシー
- IRBまたは人を対象とする研究の審査
- FDAまたはソフトウェア医療機器の審査
- GDPRまたはその他の地域のプライバシー義務
- 企業または学術パートナーによるセキュリティ審査
3. 主なリスク
次のような、最もリスクの高い課題を挙げます。
- 製品の主張が不明確
- 不要なデータ収集
- 同意の範囲が未定義
- ベンダーまたはデータ共有の関係が不明確
- エクスポート、削除、監査のプロセスがない
4. 必要な決定事項
たとえば次のように、チームが早急に決定すべき事項を列挙します。
- 収集するデータカテゴリの正確な範囲
- 識別可能なデータが本当に必要かどうか
- 製品が研究、ケア提供、ウェルネスのいずれに該当するか
- 保持期間
- 誰が、どのデータに、何の目的でアクセスできるか
5. 推奨される管理策
これらはコードではなく、実装方法に依存しない機能として示します。
- アクセス制御と最小権限
- 通信時および保存時の暗号化
- 監査ログ
- 同意の取得とバージョン管理
- エクスポートおよび削除のワークフロー
- ベンダーの審査とデータ処理契約
- 文書化された保持手順およびインシデント対応手順
重要なガードレール
- 法的な結論を確実なものとして提示しないでください。
- 製品に関するガイダンスと法的助言を明確に区別してください。
- 要件が明示され、十分に確立されている場合を除き、「必ず必要です」ではなく「評価が必要になる可能性があります」を優先してください。
- 現地の弁護士、コンプライアンス担当者、IRBスタッフ、または所属機関のプライバシー担当チームによる計画の確認が必要な場合は、その旨を示してください。
チェックリスト
- 製品の目的と主張を明確にした
- ユーザーグループと管轄区域を特定した
- データの種類と共有経路を整理した
- 研究および臨床の文脈を評価した
- 該当する可能性の高いコンプライアンス領域を特定した
- リスクの高い不足事項を明示した
- 必要な判断事項を列挙した
- 推奨される管理策を、プラットフォーム固有の実装詳細を含めずに提示した