mcpField
H
hipaa-security-rule

hipaa-security-rule

github.com/mukul975セキュリティ32335 回インストール32 週間前に更新
リポジトリ

hipaa-security-rule について

電子的に保護される医療情報(ePHI)に関する HIPAA セキュリティルールの技術的保護策を、医療ネットワークの実装例とともに解説するセキュリティスキルです。アクセス制御、監査、完全性、認証、通信セキュリティを検討する医療機関や業務委託先を対象としています。

主な機能

  1. 01アクセス制御要件の解説
  2. 02緊急アクセスと自動ログオフ
  3. 03ePHI の暗号化対策
  4. 04監査ログとアラートの実践例
  5. 05データ完全性の保護
  6. 06認証と通信セキュリティの説明

活用シーン

  1. 01ePHI システムの技術的保護策の確認
  2. 02緊急アクセス手順の計画
  3. 03ログ監査とアラートの仕組み作り
  4. 04通信中の ePHI 保護の評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill hipaa-security-rule

インストール後、Claude Code で/hipaa-security-ruleを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

詳細

HIPAA セキュリティルール — 技術的保護策 45 CFR §164.312

概要

HIPAA セキュリティルールは、対象事業体または業務提携先が作成、受領、使用、または維持する電子保護対象保健情報(ePHI)を保護するための全国標準を定めています。2003年2月20日に最終規則として公表され(68 FR 8334)、2005年4月20日(小規模医療保険プランは2006年4月20日)までに遵守することが求められたこのセキュリティルールは、管理的、物理的、技術的な保護策を通じて、プライバシールールの機密性保護を実現します。このルールでは、リスクベースでテクノロジーに依存しないアプローチを採用しています。つまり、達成すべきことを定める一方、対象事業体の規模、複雑さ、能力に応じた保護策の実施方法には柔軟性を認めています。

プライバシールールがあらゆる形態のPHIを対象とするのに対し、セキュリティルールはePHIのみを対象とします。このルールでは、要件を3つの保護策カテゴリー(管理的 §164.308、物理的 §164.310、技術的 §164.312)に加え、組織的要件(§164.314)および方針/手順/文書化(§164.316)に分類しています。

技術的保護策 — §164.312

技術的保護策とは、ePHIを保護し、そのアクセスを制御するためのテクノロジーと関連する方針および手順です。各基準には必須の実施仕様(遵守必須)と対応可能な実施仕様(合理的かつ適切な場合に実施し、代替措置を採用する場合、または仕様を実施しない場合は、根拠を文書化する必要があります)があります。

アクセス制御 — §164.312(a)(1)

基準:ePHIを維持する電子情報システムに対し、アクセス権を付与された人物またはソフトウェアプログラムだけがアクセスできるよう、技術的な方針および手順を実施します。

実施仕様種類要件
一意のユーザー識別 — §164.312(a)(2)(i)必須ユーザーの識別および追跡に使用する一意の名前および/または番号を割り当てます
緊急時アクセス手順 — §164.312(a)(2)(ii)必須緊急時に必要なePHIを取得するための手順を確立し、実施します
自動ログオフ — §164.312(a)(2)(iii)対応可能あらかじめ定めた非アクティブ時間の経過後に電子セッションを終了する電子手順を実施します
暗号化と復号 — §164.312(a)(2)(iv)対応可能ePHIを暗号化および復号する仕組みを実施します
一意のユーザー識別

ePHIにアクセスするすべての職員、管理者、およびシステムアカウントには、一意の識別子を付与する必要があります。共有アカウントや汎用ログインは禁止されています。

Asclepius Health Network の導入例:

  • Active Directory は、[first initial][last name][employee number] 形式で一意のユーザー ID を割り当てます(例:jsmith4821)
  • アプリケーション間通信に使用するサービスアカウントには、svc-[application]-[function] 形式を使用します(例:svc-epic-hl7)
  • 特権管理者アカウントは標準ユーザーアカウントとは別にします(adm-jsmith4821)
  • すべてのユーザーアカウントを人事システムに紐付けます。退職者のアカウントは、退職処理後1時間以内に自動的に無効化されます
  • 臨床用ワークステーションでは、シングルサインオンのために生体認証(指紋認証)を導入しています
  • リモートアクセスおよび管理者機能には、多要素認証が必要です
緊急アクセス手順

対象事業者は、通常のアクセス制御が機能しない緊急時に ePHI にアクセスするための手順を文書化する必要があります。

Asclepius Health Network の実装:

  • 非常時のアクセス手順により、緊急事態が宣言された場合、あらゆる臨床担当者があらゆる患者の記録にアクセスできます
  • 非常時のアクセスイベントは、プライバシーオフィスに即時アラートを送信し、イベント後24時間以内に正当な理由を記録することを求めます
  • 高い権限を持つ災害復旧アカウントは、IT オペレーションセンターの金庫に封印した封筒で保管されています
  • 緊急アクセスアカウントは四半期ごとにテストし、各テストまたは使用後にパスワードを変更します
  • EHR システムには、IT システム障害時に有効化される、認証を簡略化した(バッジ+PIN)独立した緊急モードがあります
自動ログオフ

Asclepius Health Network の実装:

  • 臨床ワークステーション:5分間操作がない場合に画面をロックし、15分後にセッションを終了します
  • 管理ワークステーション:10分間操作がない場合に画面をロックし、30分後にセッションを終了します
  • 患者ポータルのセッション:15分間操作がない場合にセッションを終了します
  • モバイルデバイス(臨床用カートのタブレット):2分間操作がない場合にロックし、生体認証による再認証を求めます
  • 近接ベースのログオフでは RFID バッジを使用し、臨床担当者のバッジがワークステーションから10フィート以上離れるとセッションをロックします
暗号化と復号

対応可能な仕様ではありますが、文書化された同等の代替措置なしに ePHI を暗号化しないことは、セキュリティルール違反に当たると OCR は一貫して指摘しています。

Asclepius Health Network の実装:

  • 保存データ:ePHI を含むすべてのストレージボリュームを AES-256 で暗号化します(データベースのテーブルスペース暗号化、エンドポイントのフルディスク暗号化)
  • 転送中データ:ePHI を含むすべてのネットワーク通信で TLS 1.2 以上(TLS 1.3 を推奨)を使用します
  • 特に機密性の高いフィールド(SSN、薬物乱用の診断、HIV の状態、メンタルヘルスの記録)には、データベースのフィールドレベル暗号化を適用します
  • 暗号鍵の管理には、FIPS 140-2 Level 3 認証済みハードウェアセキュリティモジュール(HSM)を使用します
  • 鍵のローテーション:保存データ用の鍵は年次、TLS 用の鍵はセッションごと、アプリケーションレベルの暗号化鍵は四半期ごとに実施します
監査管理 — §164.312(b)

基準:ePHI を含む、または使用する情報システムの活動を記録し、調査するためのハードウェア、ソフトウェア、および/または手続き上の仕組みを導入します。

実装仕様は指定されていません。基準自体への準拠が必須です。

Asclepius Health Network の実装:

記録対象:

  • すべての認証イベント(ログインの成功および失敗、ログオフ、アカウントのロックアウト)
  • ePHI へのすべてのアクセス(読み取り、書き込み、変更、削除)。アクセスした具体的な記録も含みます
  • すべての管理操作(ユーザーの作成、権限の変更、設定の変更)
  • すべてのシステムイベント(起動、シャットダウン、エラー、バックアップ操作)
  • ePHI システムに関わるすべてのネットワークイベント(接続、切断、ファイアウォールイベント)
  • 詳細情報を強化したブレーク・ザ・グラスアクセスイベント

ログ管理:

  • SIEM(セキュリティ情報イベント管理)プラットフォームを使用したログの一元的な集約
  • 不審なパターン(複数回のログイン失敗、通常と異なるアクセス量、診療チーム外の記録への時間外アクセス)のリアルタイムな相関分析とアラート通知
  • 改ざん防止のため、ログを一度だけ書き込める不変ストレージに保存
  • ログの保持期間:最低6年間(§164.530(j) に基づく HIPAA の文書保持要件に準拠)
  • セキュリティオペレーションセンターに毎日の自動ログレビューレポートを提供
  • 月次監査サンプル:無作為に選んだ患者記録50件について、アクセスの適切性を確認

監査のトリガーとアラート:

トリガー対応 SLA対応
10分間に5回以上のログイン失敗即時アカウントをロックし、SOC にアラートを通知
VIP/従業員の患者記録へのアクセス即時プライバシーオフィスにアラートを通知して確認を依頼
大量の記録へのアクセス(1人のユーザーが1時間に50件を超える記録にアクセス)15分SOC が確認し、アカウント停止の可能性を検討
通常と異なる場所からの時間外アクセス1時間翌営業日に SOC が確認。リスクが高い場合は即時に確認
ブレーク・ザ・グラスイベント24時間プライバシーオフィスが理由を確認
管理者権限の昇格即時SOC が変更チケットを確認
完全性 — §164.312(c)(1)

基準:不適切な改変や破壊から ePHI を保護するためのポリシーと手順を導入します。

実装仕様種別要件
ePHI を認証する仕組み — §164.312(c)(2)対応可能ePHI が不正な方法で改変または破壊されていないことを裏付ける電子的な仕組みを導入します

Asclepius Health Network の実装:

  • データベースの完全性:臨床文書の記録に SHA-256 チェックサムを適用し、すべての変更を改ざん検知可能な形で記録
  • 追記専用の臨床文書モデルを採用。元の記録は削除も上書きもせず、修正内容を作成者、タイムスタンプ、理由とともに元の記録に関連付けます
  • PKI 証明書を使用して、検査結果、放射線科レポート、投薬指示にデジタル署名を付与
  • 既知の正常なベースラインとファイルのチェックサムを照合する、毎日の完全性検証スキャン
  • バックアップの完全性検証:無作為に選んだバックアップセットを毎週、自動で復元テストします
人またはエンティティの認証 — §164.312(d)

基準:ePHI へのアクセスを求める人またはエンティティが、申告した本人またはエンティティであることを検証する手順を実施します。この基準には実装仕様がなく、必須です。

Asclepius Health Network における実装:

  • 内部職員:多要素認証(ワークステーションではバッジ+PIN、リモートアクセスでは認証アプリ+パスワード)
  • 外部プロバイダー(医療情報交換):デジタル証明書に基づく相互 TLS 認証
  • 患者ポータル:登録時には知識ベース認証、継続的なアクセスにはユーザー名+パスワード+SMS/メール認証コード
  • Asclepius システムにアクセスするビジネスアソシエイト:証明書+パスワード+ハードウェアトークンを使用する VPN
  • アプリケーション間:クライアントクレデンシャルと相互 TLS を使用する OAuth 2.0
伝送セキュリティ — §164.312(e)(1)

基準:電子通信ネットワークを介して伝送される ePHI への不正アクセスを防ぐため、技術的なセキュリティ対策を実施します。

実装仕様種別要件
完全性管理 — §164.312(e)(2)(i)選択可能電子的に伝送される ePHI が、不適切に変更されても検知されないという事態を防ぐため、セキュリティ対策を実施します
暗号化 — §164.312(e)(2)(ii)選択可能適切と判断される場合に ePHI を暗号化する仕組みを導入します

Asclepius Health Network における実装:

  • ePHI を含むすべての内部ネットワークトラフィックは TLS 1.2 以降で暗号化します(ePHI VLAN によるネットワークセグメンテーション)
  • 外部への伝送には TLS 1.2 以降または VPN トンネルを必須とします。ePHI を含む暗号化されていないメールは DLP ゲートウェイでブロックします
  • HL7 FHIR API エンドポイント:SMART on FHIR 認可を使用する相互 TLS
  • プロバイダー間の ePHI 交換には Direct セキュアメッセージングを使用します(S/MIME 暗号化を使用する Direct Protocol)
  • 完全性管理:TLS は HMAC による完全性保護を標準で提供します。また、一括ファイル転送(HL7 バッチ、X12 EDI)には追加のチェックサムを使用します
  • 無線ネットワーク:すべての臨床用無線ネットワークで、802.1X RADIUS 認証を使用する WPA3 Enterprise を採用します。ePHI システムにアクセスできないゲスト用ネットワークを別途設けます

管理的保護措置 — §164.308(主な要件の抜粋)

セキュリティ管理プロセス — §164.308(a)(1)
実装仕様種別
リスク分析必須
リスク管理必須
制裁ポリシー必須
情報システムの活動レビュー必須
職員のセキュリティ — §164.308(a)(3)
実装仕様種別
認可および/または監督選択可能
職員の適格性確認手順選択可能
雇用終了手順選択可能
情報アクセス管理 — §164.308(a)(4)
実装仕様種別
医療情報交換機関の機能の分離必須
アクセス認可選択可能
アクセスの確立および変更選択可能
セキュリティ意識向上とトレーニング — §164.308(a)(5)
実装仕様種別
セキュリティに関する注意喚起選択可能
マルウェアからの保護選択可能
ログインの監視選択可能
パスワード管理選択可能
セキュリティインシデント手順 — §164.308(a)(6)
実装仕様種別
対応および報告必須
緊急時対応計画 — §164.308(a)(7)
実装仕様種別
データバックアップ計画必須
災害復旧計画必須
緊急モード運用計画必須
テストおよび改訂手順選択可能
アプリケーションとデータの重要度分析選択可能

物理的保護措置 — §164.310(概要)

施設へのアクセス制御 — §164.310(a)(1)

対応可能な仕様:緊急時運用、施設セキュリティ計画、アクセス制御および検証手順、保守記録。

ワークステーションの使用 — §164.310(b)

ePHI にアクセスするワークステーションに適した物理的環境および使用方法を定める必須基準です。

ワークステーションのセキュリティ — §164.310(c)

ePHI にアクセスするワークステーションへのアクセスを制限する物理的保護措置を実施する必須基準です。

デバイスおよびメディアの管理 — §164.310(d)(1)

廃棄およびメディアの再利用に関する必須仕様と、説明責任およびデータのバックアップ/保管に関する対応可能な仕様です。

必須仕様と対応可能な仕様:OCR の見解

OCR は、「対応可能」であっても「任意」を意味するわけではないと明確にしています。対応可能な仕様ごとに、対象事業者は次のことを行う必要があります。

  1. その実装仕様が、自らの環境において合理的かつ適切な保護措置であるかを評価する
  2. そうであれば、実装する
  3. そうでなければ、合理的かつ適切でない理由を文書化し、かつ、合理的かつ適切な同等の代替措置を実装する。または、その仕様や代替措置がなくても基準を満たせる理由を文書化する

OCR の執行措置では、ePHI の暗号化(対応可能な仕様)を行わず、代替措置も文書化していなかった事業者に違反が認定されています。実際には、例外的な事情について文書化された正当な理由がない限り、保存中および転送中の ePHI の暗号化が OCR によって期待されています。

執行事例

  • Anthem Inc.(2018年):1,600万ドル — 7,880万人分の ePHI への不正アクセスを防ぐのに十分なアクセス制御など、技術的保護措置を実施しなかった
  • Premera Blue Cross(2020年):685万ドル — ePHI に対するリスクと脆弱性を軽減するのに十分なセキュリティ対策を実施せず、監査制御も不十分だった
  • CHSPSC LLC(2020年):230万ドル — 情報システムの活動レビューを実施せず、既知のセキュリティインシデント(610万人に影響した APT 攻撃)への対応も不十分だった
  • Excellus Health Plan(2021年):510万ドル — アクセス制御が不十分で、全社的なリスク分析を実施せず、技術ポリシーも不十分だった
  • Banner Health(2023年):125万ドル — 281万件の記録の侵害後に、監査制御を実施せず、正確な技術的リスク分析も行わなかった

統合ポイント

  • hipaa-privacy-rule:プライバシールールは保護対象を定め、セキュリティルールは保護方法を定めます
  • hipaa-risk-analysis:§164.308(a)(1)(ii)(A) で義務付けられている詳細なリスク分析の方法
  • hipaa-breach-notify:不正アクセスにつながるセキュリティインシデントは、侵害通知の対象となります
  • hipaa-baa-management:ビジネスアソシエイトは、セキュリティルールのすべての基準を独立して遵守する必要があります

コメント