ウェブ解析のためのHIPAAコンプライアンスチェックリスト

症状チェッカー、患者ポータル、「医師を探す」検索、あるいは簡単な予約リクエストフォームなど、貴社のウェブサイトが何らかの形で患者、会員、または医療保険の受給者と接点を持つ場合、貴社の解析基盤は多くのチームが認識している以上にHIPAAの問題に近い状態にあります。セッションリプレイツールやイベントトラッカー、さらには一般的なページビュー解析でさえ、そもそもEコマース向けに設計されたものであり、ヘルスケア向けではありません。そのため、まさにHIPAAが問題視する種類の詳細情報をデフォルトで収集してしまいます。

これは貴社が「covered entity（対象事業体）」であるかどうかの問題ではありません。問題は、貴社の解析ツールが収集するデータによって、特定の個人とその健康情報を識別できるかどうかです。これは多くのチームが想定するよりもはるかに低いハードルであり、たいていの場合、自動補完フィールドやURLパラメータ、フォームのラベルといった偶発的な要因によって超えてしまうものであり、誰かが意図的に患者データを第三者に送信しているわけではありません。

本ガイドでは次の3点を扱います。データをそもそもPHIにしてしまう18の識別子と、それらが解析データに漏洩する典型的な経路。Business Associate Agreement（BAA）が実際にカバーする範囲としない範囲、および署名前に確認すべき事項。そして、現在の解析基盤を監査する際や新しいベンダーを評価する際に使えるチェックリストです。

HIPAAの18の識別子と、それらが解析データに潜む場所

HIPAAのセーフハーバー方式（45 CFR § 164.514(b)(2)）は、健康情報と組み合わさることで通常のデータをProtected Health Information（PHI）に変える18のカテゴリーの識別子を列挙しています。この一覧に関する多くの解説は、「PHIとは何か」を説明するだけで終わっています。ウェブサイト運営者にとってより実用的な問いは、自社の解析ツールがこれらのうちどれを実際に収集しており、どのように収集しているのか、という点です。

#	識別子	解析データへの典型的な漏洩経路
1	氏名	問い合わせフォーム、予約フォーム、チャットウィジェットに入力され、フィールドがマスクされていない場合はセッションリプレイで記録される。
2	州よりも小さい地理的区分	配送先/請求先住所フィールド、郵便番号フィールド、または住所をイベントプロパティとして送信する「近くの店舗を探す」ツール。
3	個人に関連する日付（生年月日、入院日、退院日、死亡日）。年を除く	登録フォームの生年月日ピッカー。カスタムイベントプロパティとして記録される予約日時。
4	電話番号	問い合わせ/予約フォームの電話番号フィールド。ブラウザの自動入力で埋められ、マスクされていないセッションリプレイで記録されることが多い。
5	FAX番号	FAX欄がいまだに残っている古い紹介状フォームや受付フォーム。
6	メールアドレス	ログインフォーム、ニュースレター登録、「結果をメールで受け取る」ボタン。マーケティングのアトリビューション用にイベントプロパティとして送信されることが多い。
7	社会保障番号	保険確認フォームや請求フォーム。捕捉される頻度は低いが、記録されればどこにも記録されるべきでない情報だけに深刻な事態となる。
8	医療記録番号	URLパス（/patient/MRN12345）やクエリ文字列で渡される、または解析へ送信されるデータレイヤーオブジェクトに埋め込まれる。
9	医療保険の受給者番号	適格性確認ページや請求ページの保険/会員IDフィールド。
10	口座番号	画面に表示され、マスクされていないセッションリプレイで記録される患者ポータルの口座番号。
11	証明書/免許番号	「担当者を確認する」ページの医療従事者免許番号。リスクは比較的低いが、リストには含まれる。
12	車両識別子（ナンバープレートを含む）	ほとんどのヘルスケアサイトでは稀。バレーパーキングや送迎サービスとの連携で関係することがある。
13	機器識別子とシリアル番号	UI上に機器のシリアル番号を表示する、接続機器やDME（耐久性医療機器）のポータル。
14	ウェブURL	パスやクエリ文字列が患者固有の情報をエンコードしている場合のページ自体のURL（#8参照）。
15	IPアドレス	ほぼすべての解析プラットフォームがデフォルトで収集しているが、匿名化やハッシュ化が必要だと認識されていないことが多い。
16	生体認証識別子	患者の認証フローで得られる声紋や指紋データ。多くのウェブ解析の範囲外だが、ヘルスケアアプリでは関係する。
17	顔全体が写った写真および類似の画像	プロフィール写真のアップロード、本人確認フロー、またはスクリーンショットベースの解析ツールで記録される遠隔診療動画のサムネイル。
18	その他の一意の識別番号、特徴、またはコード	最も見落とされがちなもの。特定の患者記録に結びつけられうるセッション/デバイスCookie、永続的な訪問者ID、内部ユーザーID。

実務でこれが問題になる際には、次の2つのパターンが繰り返し現れます。

• セッションリプレイが最大の露出面です。 構造化されたフィールドを記録するだけではありません。DOMそのものを記録するため、開発者が送信するつもりのなかったテキストまで捕捉してしまいます。自動入力された値、ツールチップ、ユーザーの入力内容をそのまま返すエラーメッセージ（例：「John Smithの検索結果はありません」）などです。
• URLとカスタムイベントが2番目に大きい露出面です。 チームはフォームフィールドのマスクには入念に取り組む一方で、URL自体や善意で実装したカスタムイベント（patient_search、appointment_bookedなど、氏名や医療記録番号をプロパティとして持つもの）が、そのマスキングをすり抜けて同じ識別子を運んでしまうことを見落としがちです。

識別子18番は特に注意が必要です。チームが最も陥りやすい誤った推論、「氏名を収集していないから大丈夫」の対象になりやすいためです。特定の個人に紐付けられうる永続的なデバイスIDやセッションIDは、それが間接的であっても、たとえ医療記録にアクセスできる別の人物を介したものであっても、セーフハーバーの下ではそれ自体が識別子となります。まさにこうした判断のために、BAAと文書化されたデプロイ設定が存在しています。

Business Associate Agreementが実際にカバーする内容

BAAは単純な「持っているか、持っていないか」というチェック項目として扱われがちですが、その存在自体よりも契約の中身の方が重要です。2つのベンダーがともに「BAAを提供している」と言っていても、その意味するところはまったく異なる場合があります。

BAAの目的。 HIPAAの下では、ベンダーがcovered entity（対象事業体）に代わってPHIを作成、受領、保持、または送信する場合、そのベンダーは「business associate」となり、両者の関係はBAAによって規定される必要があります。この契約は、ベンダーが保持するあらゆるPHIに対する保護措置、侵害発生時の通知期限、データの使用に関する制限、そして請求や契約終了時にデータがどう扱われるかといった、ベンダー側の義務を定めるものです。

実際に必要となるケース。 PHIがベンダーのシステムに到達する現実的な可能性がある場合、その解析ベンダーとの間でBAAが必要です。上記の漏洩経路を踏まえると、これは医療記録の保管を目的として設計されたポータルに限らず、何らかの形で患者とのやり取りを持つほとんどのヘルスケアサイトに当てはまります。患者固有のフォームやログイン、ポータルを持たないマーケティングサイトであれば、一般的にBAAは不要です。ただし、「PHIを送信していないと思う」という立場は、「ツールをPHIが送信されないように設定し、それを検証済みである」という立場よりも弱いものです。

署名前に確認すべきこと。 以下のいくつかの問いによって、実質的に貴社を保護するBAAと、形式だけのBAAとを見分けることができます。

• そのツールが実際に行っていることと一致しているか、それとも定型文にすぎないか。 セッションリプレイやイベントトラッキングといった具体的な製品への言及がない、汎用的なBAAテンプレートは、そのベンダーがPHIの侵入経路について十分に検討していないことを示すシグナルです。
• PHIを誤って受領した場合の削除期限はどうなっているか。 「速やかに」や「実行可能な限り早く」といった表現ではなく、具体的な時間数や日数を確認してください。
• サービス提供以外の目的でPHIを使用しないと明記されているか。 自社解析のためのPHI分析や、モデルの学習、二次利用などがないこと。これは暗黙の了解ではなく、明示的に記載されているべきです。
• 委託先事業者への義務の引き継ぎはあるか。 ベンダーがクラウドインフラや再委託先を利用している場合、BAA上の義務がそれらの委託先にも法的に及ぶ必要があります（45 CFR 164.502(e)(1)(ii)）。
• 侵害発生時の通知期限はどうなっているか。 HIPAAは上限として60日を定めていますが（45 CFR 164.410）、ベンダーのBAAがこの法定上限をそのまま自社の基準として掲げているだけであってはいけません。より短い期間が望ましく、上限に加えて「不当な遅延なく」という表現があることも良い兆候です。
• BAAはベンダーのデフォルトの挙動を実際に変えるものか、それとも仮定の話を説明しているだけか。 最も強いシグナルは、BAAを結んだ顧客に対して、より厳格なデフォルト設定（例：セッションリプレイにおけるテキストの全面的な難読化）を有効にするベンダーです。単に責任範囲を説明するだけで製品自体は変わらないBAAとは対照的です。
• BAAへの署名が、このツールをPHIの保管場所として使ってよいことを意味してしまっていないか。 そうであってはいけません。BAAは偶発的な送信をカバーするために存在するのであり、解析ツールを意図的な患者データの保管場所として利用することを認めるものではありません。ベンダーのBAAがそのように読める場合、それはデータ最小化についてどれだけ真剣に検討しているかを示す危険信号です。

Air360独自のBusiness Associate Agreementは、まさにこの最後の点を軸に構築されています。PHIが偶発的に送信された場合の両当事者の義務を規定するものであり、Air360を患者データの保管場所として利用することを認めるものではありません。

ベンダーチェックリスト：確認すべきこと、そしてAir360が実施していること

現在の解析基盤を監査する際、あるいは新しいベンダーを評価する際に、以下を活用してください。各項目は、鵜呑みにするのではなく、具体的に確認できるものです。

確認項目	どのベンダーに対しても確認すべきこと	Air360が実施していること
BAAの提供有無	汎用テンプレートではなく、利用する製品に固有のBAAをベンダーが提供しているか。	対象となる医療機関のお客様に対してBAAを提供しており、Air360の行動分析およびセッションリプレイサービスをカバーします。
セッションリプレイにおけるテキストマスキング	ユーザーが入力したテキストがオプトインではなくデフォルトでマスクされているか。	すべてのお客様に対して、入力フィールドのユーザー入力テキストをデフォルトでマスクします。BAAを締結したお客様には、フォームフィールドだけでなくページ全体のテキスト難読化がデフォルトで有効になります。
要素/ページの除外設定	患者ポータル、請求フォーム、医療記録画面など、特定のページ要素を完全にキャプチャ対象から除外できるか。	機密性の高いページ要素、カスタムイベント、メタデータに対する設定可能な除外コントロールを提供します。
デフォルトでのデータ最小化	顧客側の設定に全面的に依存するのではなく、ツールのデフォルト設定自体が機密データの収集を回避しているか。	データ最小化の原則に基づいて設計されており、顧客固有の設定を行う前の段階からPHIを収集しないように意図されています。
IPアドレスの取り扱い	IPアドレスが匿名化・ハッシュ化されているか、識別可能な形式で保持されていないか。	国の推定にのみ使用され、Air360のサーバーには保存されません。
データのホスティング場所とセキュリティ認証	データがどこで処理・保存されているか、インフラがどの認証を取得しているかを把握しているか。	お客様データは、ISO 27001/27017/27018、SOC 1/2/3、PCI DSSの認証範囲に含まれるデータセンターで処理・保存されます。（HIPAA自体は米国内でのホスティングを要求しておらず、適切な保護措置とBAAの締結を求めています。貴社自身のポリシーと整合しているかご確認ください。）
暗号化	データが転送時および保存時に暗号化されているか。	全製品において、転送中および保存中のデータに最先端の暗号化を使用しています。
アクセス制御	ベンダー自身のシステムにおいて、多要素認証とアクセスログが導入されているか。	Air360アプリケーションへアクセスするすべてのユーザーに多要素認証（MFA）を必須としています。
第三者による監査	自己申告だけでなく、独立した第三者によるセキュリティ審査を受けているか。	主要リリースに先立ち、侵入テストや脆弱性スキャンを含む第三者によるセキュリティ監査を定期的に実施しています。
侵害/インシデントの報告	「法令に従って」というだけでなく、具体的な通知期限が契約上定められているか。	BAAにおいて報告義務を定めており、45 CFR 164.410に基づき上限は60日です。
請求に基づく削除	誤って受領したPHIを、定められた期間内に削除することをベンダーが約束しているか。	お客様からの請求があった場合は24時間以内に、また削除依頼の有無にかかわらず発見後は不当な遅延なく削除します。
PHIの二次利用の禁止	PHIがベンダー自身の解析やモデルの学習、マーケティングに利用されていないか。	Air360は、広告、プロファイリング、マーケティング、またはモデルの学習を目的としてPHIを利用することはありません。

5分でできるセルフチェック

ベンダーを評価する前に、まずは自社の実装を確認することをお勧めします。PHIの露出のほとんどは、解析ツール自体ではなく設定に起因するためです。

1. 患者向けページにおける実際のユーザー行動のセッションリプレイ記録を開き、第三者の目線で確認してください。氏名、メールアドレス、電話番号、IDなど、読み取り可能な情報が画面上に表示されていませんか。
2. 解析ツールが取得しているURLを確認してください。パスやクエリ文字列に、患者名、医療記録番号、口座番号が含まれていませんか。
3. カスタムイベントのプロパティを確認してください。組織外の人物がそれを見た場合に、実在する患者について具体的な何かがわかってしまうものはありませんか。
4. パスワードフィールド、医療記録フォーム、請求/保険フォームが、汎用的な入力マスキングだけに頼るのではなく、明示的にキャプチャ対象から除外されていることを確認してください。
5. BAAを締結している場合は、顧客の責任事項に関するセクションを読み直し、現在の設定がその内容を実際に満たしているかを確認してください。

ヘルスケア領域でのAir360導入をご検討の場合は、HIPAAステートメントおよびHIPAA導入ガイドにて、セッションリプレイ、イベント、カスタムプロパティを、PHIが決してプラットフォームに到達しないように設定する具体的な方法を解説しています。