医療 PHI/PII コンプライアンスパターン

医療アプリケーションにおける患者データ、臨床医データ、財務データを保護するためのパターンです。HIPAA（米国）、DISHA（インド）、GDPR（EU）、および一般的な医療データ保護に適用できます。

使用時期

• 患者記録に関わる機能を構築する場合
• 臨床システムにアクセス制御または認証を実装する場合
• 医療データのデータベーススキーマを設計する場合
• 患者または臨床医データを返す API を構築する場合
• 監査証跡またはログ記録を実装する場合
• コード内のデータ漏洩脆弱性を検査する場合
• マルチテナント医療システムの行レベルセキュリティ（RLS）を設定する場合

仕組み

医療データ保護は 3 つのレベルで動作します：分類（何が機密データか）、アクセス制御（誰が閲覧できるか）、および監査（誰がデータを閲覧したか）。

データ分類

PHI（保護された健康情報） — 患者を識別でき、その健康に関連するあらゆるデータ：患者名、生年月日、住所、電話番号、メールアドレス、国家識別番号（SSN、Aadhaar、NHS番号）、医療記録番号、診断、薬物、検査結果、画像、保険ポリシーと請求詳細、予約と入院記録、またはこれらの任意の組み合わせ。

医療システムにおける PII（患者以外の機密データ）：臨床医/従業員の個人詳細情報、医師の料金体系と支払金額、従業員給与と銀行情報、ベンダー支払い情報。

アクセス制御：行レベルセキュリティ

ALTER TABLE patients ENABLE ROW LEVEL SECURITY;

-- Scope access by facility
CREATE POLICY "staff_read_own_facility"
  ON patients FOR SELECT TO authenticated
  USING (facility_id IN (
    SELECT facility_id FROM staff_assignments
    WHERE user_id = auth.uid() AND role IN ('doctor','nurse','lab_tech','admin')
  ));

-- Audit log: insert-only (tamper-proof)
CREATE POLICY "audit_insert_only" ON audit_log FOR INSERT
  TO authenticated WITH CHECK (user_id = auth.uid());
CREATE POLICY "audit_no_modify" ON audit_log FOR UPDATE USING (false);
CREATE POLICY "audit_no_delete" ON audit_log FOR DELETE USING (false);

監査証跡

PHI へのアクセスまたは変更のたびに記録する必要があります：

interface AuditEntry {
  timestamp: string;
  user_id: string;
  patient_id: string;
  action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';
  resource_type: string;
  resource_id: string;
  changes?: { before: object; after: object };
  ip_address: string;
  session_id: string;
}

一般的な漏洩経路

エラーメッセージ： クライアントに送信されるエラーメッセージに患者識別データを含めないでください。詳細情報はサーバー側でのみ記録してください。

コンソール出力： 完全な患者オブジェクトをログに出力しないでください。非透過的な内部記録 ID（UUID）を使用してください——医療記録番号、国家識別番号、または名前の代わりに。

URL パラメータ： ログまたはブラウザ履歴に表示される可能性があるクエリ文字列またはパスセグメントに患者識別データを含めないでください。非透過的な UUID のみを使用してください。

ブラウザストレージ： localStorage または sessionStorage に PHI を保存しないでください。PHI はメモリ内にのみ保持し、必要に応じて取得してください。

サービスロールキー： クライアントコードで service_role キーを使用しないでください。常に匿名/公開可能キーを使用し、RLS にアクセス制御を強制させてください。

ログとモニタリング： 完全な患者記録をログに出力しないでください。非透過的な記録 ID（医療記録番号ではなく）のみを使用してください。エラー追跡サービスに送信する前にスタックトレースをサニタイズしてください。

データベーススキーマアノテーション

スキーマレベルで PHI/PII 列にマークを付けます：

COMMENT ON COLUMN patients.name IS 'PHI: patient_name';
COMMENT ON COLUMN patients.dob IS 'PHI: date_of_birth';
COMMENT ON COLUMN patients.aadhaar IS 'PHI: national_id';
COMMENT ON COLUMN doctor_payouts.amount IS 'PII: financial';

デプロイチェックリスト

デプロイ前に以下を確認します：

• エラーメッセージまたはスタックトレースに PHI がない
• console.log/console.error に PHI がない
• URL パラメータに PHI がない
• ブラウザストレージに PHI がない
• クライアントコードに service_role キーがない
• すべての PHI/PII テーブルで RLS が有効
• すべてのデータ変更に監査証跡がある
• セッションタイムアウトが設定されている
• すべての PHI エンドポイントで API 認証が必要
• 機関間データ隔離が検証されている

例

例 1：セキュアと非セキュアなエラーハンドリング

// BAD — leaks PHI in error
throw new Error(`Patient ${patient.name} not found in ${patient.facility}`);

// GOOD — generic error, details logged server-side with opaque IDs only
logger.error('Patient lookup failed', { recordId: patient.id, facilityId });
throw new Error('Record not found');

例 2：マルチ機関隔離の RLS ポリシー

-- Doctor at Facility A cannot see Facility B patients
CREATE POLICY "facility_isolation"
  ON patients FOR SELECT TO authenticated
  USING (facility_id IN (
    SELECT facility_id FROM staff_assignments WHERE user_id = auth.uid()
  ));

-- Test: login as doctor-facility-a, query facility-b patients
-- Expected: 0 rows returned

例 3：セキュアなログ記録

// BAD — logs identifiable patient data
console.log('Processing patient:', patient);

// GOOD — logs only opaque internal record ID
console.log('Processing record:', patient.id);
// Note: even patient.id should be an opaque UUID, not a medical record number