HIPAA против Washington MHMDA для SaaS в сфере психического здоровья: где каждый закон действует и где исключение реально помогает
Самая распространённая аналитическая ошибка, которую я вижу в отношении SaaS в сфере психического здоровья, это трактовка вопроса HIPAA / MHMDA как «либо одно, либо другое». Это не так. HIPAA распространяется на Covered Entities и Business Associates и действует применительно к конкретным типам данных в рамках этих отношений. MHMDA распространяется на любого, кто обрабатывает Consumer Health Data потребителей штата Вашингтон, и также действует применительно к конкретным типам данных. Исключение в RCW 19.373.100 применяется по каждому полю данных отдельно, а не для всей организации целиком. Платформа может быть частично покрыта HIPAA по одним полям данных и полностью покрыта MHMDA по другим, часто в одной и той же базе данных.
Сфера применения: параллельное сравнение
- HIPAA: распространяется на health plans, healthcare clearinghouses, healthcare providers, передающих медицинскую информацию в электронном виде в HIPAA-транзакциях, и их Business Associates. Применяется к Protected Health Information (PHI) внутри отношений, подпадающих под HIPAA. Федеральная сфера действия.
- MHMDA: распространяется на любое юридическое лицо, которое ведёт деятельность в штате Вашингтон или ориентирует продукты или услуги на потребителей штата Вашингтон и (самостоятельно или совместно) определяет цели и средства сбора, обработки, передачи или продажи Consumer Health Data. Сфера действия штата Вашингтон, но с экстратерриториальным охватом компаний за пределами штата, которые ориентируются на потребителей штата Вашингтон.
- Сфера данных HIPAA: PHI, определённая в 45 CFR 160.103. Жёстко ограничена информацией, созданной или полученной Covered Entity или Business Associate в связи с прошлым, настоящим или будущим состоянием здоровья, оплатой или операциями здравоохранения.
- Сфера данных MHMDA: Consumer Health Data согласно RCW 19.373.010, включая статус психического здоровья, настроение, симптомы, обращение за лечением, записи в дневнике и выводы (inferences). Категория шире, чем PHI, особенно в отношении выводов и неклинических раскрытий.
Как реально работает RCW 19.373.100
Исключение MHMDA в RCW 19.373.100 исключает несколько категорий данных: PHI согласно HIPAA (вместе со связанными данными согласно Ch. 70.02 RCW и 42 CFR Part 2), финансовые данные GLBA, данные потребительских отчётов FCRA, образовательные записи FERPA, мероприятия общественного здравоохранения согласно 45 CFR 164.512, обезличенные данные, соответствующие стандарту 45 CFR Part 164, и обработку, необходимую для предотвращения, обнаружения или реагирования на инциденты безопасности и мошенничество. Бремя обоснования права на исключение лежит на лице, заявляющем его. Исключение применяется по данным, а не для всей организации в целом. Больница подпадает под HIPAA в отношении PHI при treatment, payment и healthcare operations, но рекламные пиксели на её публичном сайте на странице «найти терапевта» собирают данные, которые не являются PHI и не подпадают под исключение.
- Маркетинговые пиксели на публичном сайте. Отслеживание конверсий на лендингах «помощь при депрессии» или «найти терапевта» это Consumer Health Data, а не PHI.
- Заполнение анкеты и подбор до встречи с провайдером. Пользователь раскрывает диагноз, симптомы и предпочтения по лечению до того, как возникли какие-либо отношения с провайдером. Это ещё не PHI. Уже покрывается MHMDA.
- Самостоятельные модули и контент для потребителей внутри платформы, в которой также есть клиническая часть. Журнал настроения для самостоятельной работы внутри гибридного продукта покрыт MHMDA, даже если соседняя сессия с клиницистом является PHI.
- Выводы, полученные с помощью AI, и агрегированная аналитика, построенная поверх входных данных, покрытых BAA, когда оператор самостоятельно определяет цели и средства. Исключение для обезличенных данных помогает только если стандарт обезличивания действительно соблюдён и задокументирован.
Какие обязательства применяются где
- Notice of Privacy Practices (HIPAA) покрывает PHI внутри отношений, подпадающих под HIPAA; не удовлетворяет требованию MHMDA об отдельной Consumer Health Data Privacy Policy согласно RCW 19.373.020.
- Authorization (HIPAA) требуется для использования вне treatment-payment-operations; не удовлетворяет двухслойному согласию MHMDA согласно RCW 19.373.030 в отношении Consumer Health Data, которые не являются PHI.
- Право доступа (HIPAA, 45 CFR 164.524) сосуществует с правом MHMDA на подтверждение и доступ согласно RCW 19.373.040. Право MHMDA охватывает больше данных и включает список получателей-третьих лиц.
- Business Associate Agreement (HIPAA, BAA) регулирует отношения с обработчиками PHI; не заменяет договоры MHMDA с обработчиками согласно RCW 19.373.060 в отношении Consumer Health Data, которые не являются PHI. Обычно требуется дополнительное соглашение по штату Вашингтон или отдельный договор с обработчиком по MHMDA.
- HIPAA Security Rule сосуществует с требованием MHMDA о разумной осторожности при обеспечении безопасности согласно RCW 19.373.050. Стандарт MHMDA включает ограничение доступа, привязанное к согласию, что является более конкретным, чем обычно обеспечивают политики ролевого доступа.
- Уведомление о нарушении (HIPAA Breach Notification Rule) сосуществует со статутом штата Вашингтон об уведомлении о нарушениях в Chapter 19.255 RCW для нарушений, затрагивающих жителей штата Вашингтон.
Практическая позиция для гибридного SaaS в сфере психического здоровья
Для продуктов с любой не покрытой HIPAA поверхностью я применяю четыре шага. Во-первых, я составляю карту данных по каждому полю, в которой указываю, какие поля являются PHI внутри покрытой транзакции, а какие нет. Во-вторых, я готовлю отдельную Consumer Health Data Privacy Policy согласно RCW 19.373.020 для не-PHI поверхности, заметно размещённую со ссылкой на главной странице. В-третьих, я добавляю формулировки договора с обработчиком по MHMDA в каждое DPA с вендором, который касается не-PHI поверхности, поверх любого существующего BAA. В-четвёртых, я проектирую единый процесс обработки прав, который удовлетворяет и право доступа по HIPAA, и права на подтверждение, доступ, отзыв, удаление и обжалование по MHMDA согласно RCW 19.373.040, с задокументированными исключениями там, где правила хранения по HIPAA имеют приоритет над удалением по MHMDA для полей PHI.
Что прислать для письменного анализа
- Описание операционной модели с выделением PHI и не-PHI поверхностей.
- Инвентаризация данных по каждому полю, если она существует; если нет, описание категорий собираемых данных и места их хранения.
- Действующая Notice of Privacy Practices, политика конфиденциальности, отдельная Consumer Health Data Privacy Policy при наличии, шаблон BAA и любое дополнение по MHMDA.
- Карта вендоров и текущие DPA.
- Потоки на маркетинговом сайте, включая любую аналитику, атрибуцию, рекламные пиксели и события конверсии.
- Описание любого продукта на основе обезличенных данных и используемой методологии обезличивания.
Практическая заметка от Сергея
Самая короткая версия: HIPAA и MHMDA это не альтернативы; они применяются по каждому полю данных, а не по организации в целом. Если у вас есть любая не-PHI поверхность (маркетинговый сайт, заполнение анкеты до встречи с провайдером, самостоятельные модули, агрегированная аналитика), у вас есть работа по MHMDA, даже при чистой позиции по HIPAA. Решение носит инкрементальный, а не архитектурный характер: карта данных по каждому полю, отдельная Consumer Health Data Privacy Policy для не-PHI поверхности, формулировки по MHMDA для обработчиков поверх существующих BAA и единый процесс обработки прав, который чисто обрабатывает оба режима. Я провожу анализ в рамках лицензии Калифорнии. Это нормативно-консультационная работа, а не представительство в штате Вашингтон.
Похожее: Хаб MHMDA для SaaS в сфере психического здоровья; Соответствие требованиям MHMDA для приложений терапии; Анализ конфиденциальности SaaS в сфере поведенческого здоровья; Проверка пробелов SaaS в сфере психического здоровья по MHMDA.
Образовательный ресурс. Сергей Токмаков, адвокат из Калифорнии (CA Bar #279869), в настоящее время добивается допуска в Washington State Bar. Ничто здесь не создаёт отношений «адвокат-клиент» и не является юридической консультацией по праву штата Вашингтон.