Що HIPAA насправді каже про відстеження

Сам HIPAA не згадує файли cookie, пікселі або відстеження в інтернеті — закон був написаний у 1996 році та змінений через HITECH Act у 2009 році. Відповідні правила щодо онлайн-відстеження походять з двох місць: визначення PHI у Правилі конфіденційності та вимог Правила безпеки щодо захисту електронного PHI (ePHI). Разом вони говорять, що будь-яка індивідуально ідентифікована медична інформація, яку зберігає охоплена організація або діловий партнер, повинна бути захищена, і що розкриття третім особам без дозволу або Угоди про ділове партнерство є недозволеним використанням.

Бюлетень OCR щодо технологій відстеження

Ключовим нормативним документом для видавців є бюлетень OCR під назвою Використання технологій онлайн-відстеження суб'єктами, охопленими HIPAA, та Діловими партнерами. Оригінальна версія від грудня 2022 року зайняла агресивну позицію — що будь-яка IP-адреса, зібрана на веб-сторінці, є потенційно PHI, якщо сторінка стосувалася конкретного стану здоров'я. Після рішення федерального суду 2024 року, що скасував частини бюлетеня як перевищення повноважень OCR, OCR переглянуло документ, щоб провести чіткішу межу між неавтентифікованими маркетинговими сторінками та автентифікованими сторінками порталу пацієнта. Редакція 2024 року є контрольним текстом у 2026 році, і це документ, який юридичні команди видавців повинні тримати відкритим на другому моніторі під час налаштування CMP.

Що вважається PHI у контексті відстеження

OCR розглядає комбінацію ідентифікатора (IP-адреса, ID пристрою, відбиток пальця браузера, хешований email) з інформацією про здоров'я конкретної особи (пошук за станом здоров'я, натискання на сторінку лікування, надсилання форми із симптомами) як PHI, коли комбінація стосується відомого пацієнта або особи, яку можна ідентифікувати. Ідентифікатор сам по собі не є PHI; медична інформація сама по собі не є PHI; комбінація є PHI. Це аналітичний хід, який застає видавців зненацька, оскільки стандартний піксель рекламних технологій розроблений саме для передачі цієї комбінації третій стороні з метою вимірювання та персоналізації.

Відмінність між автентифікованими та неавтентифікованими сторінками

Єдиним найважливішим поняттям у бюлетені OCR є межа між автентифікованою сторінкою — яку користувач досягає, увійшовши на портал пацієнта, систему запису на прийом з підключенням до EHR, консоль виставлення рахунків — та неавтентифікованою сторінкою — публічні маркетингові сторінки, інформаційні статті про стани здоров'я, пошук лікаря. Позиція відповідності різко відрізняється між ними.

Автентифіковані сторінки

Автентифіковані сторінки — це поверхня з високим ризиком. Після того, як користувач увійшов у систему, охоплена організація знає, хто він такий, і будь-яка технологія відстеження, що спрацьовує на цих сторінках, потенційно розкриває PHI будь-якому постачальнику, який отримує запит. Сторонні пікселі, маркетингові пікселі та будь-який аналітичний тег, що працює поза Угодою про ділове партнерство, взагалі не повинні працювати на автентифікованих сторінках. Позиція OCR тут однозначна, а врегулювання справ були суттєвими.

Неавтентифіковані сторінки

Неавтентифіковані сторінки більш нюансовані. Редакція OCR 2024 року визнала, що не кожне відвідування публічної маркетингової сторінки породжує PHI — користувач, який читає загальну статтю про діабет, не обов'язково розкриває, що хворіє на діабет. Але межа зміщується, коли сторінка поєднує ідентифікатор з чітким контекстом охорони здоров'я: засіб перевірки симптомів, що отримує вільний текст і запускає піксель з доданим введенням, цільова сторінка, специфічна для певного стану, що використовує URL як параметр відстеження, інструмент пошуку фахівця, що передає спеціалізацію та поштовий індекс аналітичному постачальнику. Ці потоки перетворюють неавтентифіковану сторінку на поверхню PHI.

Практичний тест

Практичний тест, який видавці проводять у 2026 році, — це тест розумних очікувань. Чи очікувала б розумна людина, яка відвідує цю сторінку, що її відвідування вказує на конкретну проблему зі здоров'ям? Якщо так, сторінка розглядається як така, що містить PHI для цілей відстеження, незалежно від стану автентифікації. Тест є консервативним за задумом — помилка в сторону дозвільності створює ризик примусового виконання, тоді як помилка в сторону обмежень призводить лише до втрати рекламного доходу.

Угоди про ділове партнерство та стек постачальників

HIPAA дозволяє охопленій організації передавати PHI постачальнику лише тоді, коли постачальник підписав Угоду про ділове партнерство (BAA), беручи на себе зобов'язання щодо захисту, еквівалентного HIPAA. Серед основних постачальників рекламних технологій та аналітики ситуація з BAA нерівномірна і має наслідки.

Постачальники, що підписують BAA

Google пропонує HIPAA BAA для Google Workspace, Google Cloud Platform та обмеженої підмножини розгортань GA4 за певних конфігурацій. Microsoft підписує BAA для Azure та обмеженого налаштування Microsoft Clarity. Кілька аналітичних платформ, спеціалізованих на охороні здоров'я, — Freshpaint, Heap з доповненням HIPAA, медична конфігурація FullStory — підписують BAA. Саме ці постачальники можуть бути використані видавцем, охопленим HIPAA, на автентифікованих або PHI-вмісних поверхнях.

Постачальники, що не підписують BAA

Meta не підписує BAA для Meta Pixel або Conversions API в жодній стандартній конфігурації. TikTok не підписує BAA для TikTok Pixel. Більшість програматичних SSP та DSP не підписують BAA. Стандартний Google Analytics, стандартні шаблони Google Tag Manager та теги конверсій Google Ads за замовчуванням не охоплені BAA від Google. Запуск будь-якого з цих на PHI-вмісній поверхні є порушенням HIPAA незалежно від налаштування банера згоди — згода не замінює BAA, коли йдеться про PHI.

Стек «Згода плюс BAA»

Відповідний шаблон для маркетингових сторінок видавця у сфері охорони здоров'я — стек «Згода плюс BAA». Неавтентифіковані маркетингові сторінки запускають CMP з вентилями згоди для будь-якого несуттєвого відстеження, аналітичний рівень налаштований відповідно до BAA із постачальником, обізнаним з HIPAA, а маркетинговий піксельний рівень або працює лише на сторінках, що проходять тест розумних очікувань, або маршрутизується через серверний API конверсій, що видаляє ідентифікаційну інформацію перед пересиланням постачальникам без BAA.

Архітектура CMP для видавців охорони здоров'я

CMP для видавця, охопленого HIPAA, робить більше, ніж збирає згоди. Вона забезпечує дотримання відмінності класів сторінок, фільтрує постачальників за статусом BAA та створює журнал аудиту, що задовольняє вимоги документації Правила безпеки HIPAA і будь-який закон про конфіденційність штату, що застосовується поверх.

Визначення класу сторінки

CMP повинна знати, на якому класі сторінок вона відображається. Найчистіший шаблон — це ін'єктована CSP змінна JavaScript — встановлена сервером на основі шаблону URL, стану автентифікації та метаданих типу контенту — яку CMP зчитує під час ініціалізації. Змінна виробляє три стани: публічна-низького-ризику (немає контексту охорони здоров'я), публічна-PHI-вмісна (контекст охорони здоров'я, немає автентифікації) або автентифікована. Список постачальників CMP і стандартні налаштування згоди змінюються залежно від трьох станів.

Фільтрація постачальників за статусом BAA

Кожен постачальник у списку постачальників CMP повинен бути позначений статусом BAA та умовами, за яких BAA застосовується. Постачальник без BAA жорстко блокується на PHI-вмісних та автентифікованих поверхнях незалежно від стану згоди. Постачальник з умовним BAA — яке вимагає конкретних конфігураційних рішень — дозволяється лише при підтвердженні цих умов. Журнал аудиту фіксує кожне рішення щодо постачальника з класом сторінки, станом згоди та рішенням BAA, формуючи захисний запис для запиту регулятора.

Рівень законів штатів

HIPAA є федеральним мінімумом; закони штатів — CMIA Каліфорнії, Закон штату Вашингтон «Мої дані про здоров'я» та положення про конфіденційність споживачів у сфері охорони здоров'я в Коннектикуті та Неваді — розташовані поверх з більш суворими вимогами у своїх конкретних сферах застосування. Архітектура CMP повинна розглядати HIPAA як базовий рівень і застосовувати найсуворіше застосовне правило штату поверх щоразу, коли географічний сигнал користувача вказує на штат із жорсткішим режимом охорони здоров'я споживача.

Поширені помилки відстеження HIPAA, що призводять до врегулювань

Заходи примусового виконання HIPAA щодо відстеження протягом 2024 і 2025 років дали чіткий список шаблонів, що призводять до розслідувань OCR. Meta Pixel, що спрацьовує на порталах пацієнтів, тому що хтось додав його для маркетингової аналітики без консультації з відповідальними за відповідність. Google Analytics, що працює на інструменті перевірки симптомів, де симптом передається як користувацький вимір. Сторінка пошуку лікаря, що передає спеціалізацію як параметр URL, який аналітичний тег перехоплює та пересилає. Потік адаптації telehealth із встановленим TikTok Pixel для платного залучення, який не було видалено, коли користувач перейшов до автентифікованого порталу. A/B-тест маркетингової команди, що запустив засіб запису теплових карт на кожній сторінці, включно з формами, орієнтованими на пацієнтів. Кожен із цих випадків призвів до публічного врегулювання або плану коригувальних дій у вікні виконання після 2022 року.

Підсумок

HIPAA у 2026 році більше не є режимом відповідності для бек-офісу, який маркетингова команда може ігнорувати. Бюлетень OCR, публічні врегулювання та лінія виконання, що зміцнюється проти використання пікселів на автентифікованих сторінках, перетворили онлайн-відстеження на питання рівня ради директорів для будь-якої охопленої організації з цифровим відбитком. Позиція відповідності не є неможливою — це CMP, яка знає клас сторінки, стек постачальників, що поважає межу BAA, рівень згоди, що обробляє накладку закону штату, та задокументована архітектура, яку слідчий OCR може прочитати за годину та піти переконаним. Видавці, які інвестують в цю архітектуру у 2026 році, тримають свої цифрові канали відкритими та свою аудиторію монетизованою; видавці, які продовжують ставитися до медичних сторінок як до сторінок електронної комерції, витрачають наступні два роки на складання угод про врегулювання з федеральним урядом.