Клиника: администраторы общаются с пациентами из личных аккаунтов

Короткий ответ: когда рабочая переписка идёт из личного аккаунта сотрудника, у организации нет способа ни открыть её при необходимости, ни закрыть при увольнении — и это утверждение о технике, а не о законе. Проверить состояние можно за десять минут: попробуйте открыть переписку с пятью пациентами, не обращаясь к администраторам, которые её ведут. Результат этой проверки и есть исходная точка.

Это разбор типовой ситуации, а не история конкретной организации, и он сознательно ограничен операционной частью. Правовой оценки здесь нет и быть не может. Что требуется от вашей организации при обработке данных пациентов, на каких основаниях и в каком объёме — оценивает юрист, который смотрит на ваши документы. Общие тексты такую консультацию не заменяют. Где проходит граница между операционной проверкой и правовым вопросом, разобрано отдельно, со ссылками на официальные источники: данные клиентов и 152-ФЗ.

Ситуация

Типовая картина: у клиники есть телефон и сайт, а фактическая переписка с пациентами идёт в мессенджерах через личные аккаунты администраторов. Так сложилось не по решению — просто кто-то однажды дал пациенту свой номер, потому что было удобнее, и дальше это разошлось.

Что накапливается в этих диалогах, кроме времени визита:

• уточнения о причине обращения и о том, к какому специалисту записаться;
• фотографии и файлы, которые пациент присылает «чтобы вы посмотрели заранее»;
• вопросы после приёма: что делать с назначением, можно ли перенести процедуру;
• финансовые договорённости: стоимость, рассрочка, что входит в пакет.

Три свойства этой ситуации:

• рабочее и личное лежат в одном месте — и это работает в обе стороны: организация не может открыть рабочее, не открывая личное;
• точка входа принадлежит сотруднику — номер, привязанный к аккаунту, его собственный;
• объём чувствительного содержимого больше, чем предполагалось — переписка про запись превращается в переписку про здоровье естественным ходом разговора.

Первое свойство важнее остальных, и его обычно обсуждают неправильно. Спор «дайте нам доступ к вашему аккаунту» не имеет хорошего решения: любой ответ плохой. Решается это не доступом к личному, а тем, что рабочее туда не попадает.

Где возникает риск

Организация не может открыть переписку, когда это нужно по делу. Пациент утверждает, что ему называли другую стоимость, или что он писал о переносе, или что предупреждал об особенностях. Проверить нечем: диалог у администратора, который сегодня не работает.

Организация не может закрыть переписку при увольнении. Отключить рабочую учётную запись — можно. Сделать что-либо с личным аккаунтом уходящего сотрудника — нет: он ему принадлежит. Вместе с сотрудником уходит и содержимое диалогов, и сама возможность что-то с этим сделать.

Пациенты продолжают писать по прежнему адресу. После ухода администратора обращения приходят туда же. Организация об этом не узнаёт, а пациент считает, что написал в клинику.

Неизвестно, кто и что видел. В личных аккаунтах не остаётся следов обращения к данным. Вопрос «кто открывал эту переписку» не имеет ответа даже в принципе.

Границы личного и рабочего размываются в обе стороны. Пациент пишет в одиннадцать вечера, потому что видит человека, а не организацию. Администратор отвечает, потому что неудобно не ответить. Это не только вопрос данных, но и вопрос выгорания сотрудников и ожиданий пациентов, которые организация не сможет выполнять системно.

Устройство сотрудника становится хранилищем. Телефон с рабочей перепиской теряется, ломается, переустанавливается и передаётся детям. Никакого решения об этом организация не принимала.

Отдельно стоит сказать, чего в этом списке нет: здесь нет утверждений о том, какие нарушения допущены и какие последствия наступят. Это правовая оценка, и её делает юрист по вашим документам. Список выше — только про то, что организация технически не может сделать.

План действий

Порядок построен так, чтобы первые шаги не требовали ни от кого открывать личное.

1. Проверьте доступ на пяти пациентах. Попробуйте открыть переписку по пяти предстоящим визитам, не обращаясь к администраторам. Записывайте результат по каждому: открылась, только пересказ, недоступна.
2. Составьте опись точек входа. Через что пациенты пишут реально: личные аккаунты администраторов, сообщество, номер клиники, форма на сайте, звонки. Напротив каждой — кому принадлежит и есть ли доступ у организации.
3. Заведите рабочую точку входа, зарегистрированную на организацию. С доступом у нескольких сотрудников по роли. Пока обращения в неё не пошли, это ничего не меняет и никого не задевает.
4. Переведите новые обращения, не отключая прежние. Все новые пациенты пишут в рабочую точку. Тем, кто пишет администратору, продолжают отвечать: резкое отключение канала означает неотвеченное обращение о здоровье, и это худший из возможных исходов.
5. Разграничьте доступ по роли, а не по человеку. Кто видит всю переписку, кто только своих пациентов, кто ведёт настройки. Это решение организации, и принимать его нужно один раз, а не при каждом кадровом изменении.
6. Опишите рабочие часы и правило про личные аккаунты письменно. Одна страница: где ведётся переписка с пациентами, что делать, если пациент написал сотруднику лично, в какое время отвечают. Это защищает и пациента, и сотрудника.
7. Соберите вопросы для юриста в отдельный список. Практика показывает, что во время шагов 1–2 список появляется сам. Что именно можно и нужно делать с накопленной перепиской в личных аккаунтах, на каких основаниях обрабатываются присланные пациентами файлы, какие документы должны быть у организации — всё это в список, а не в решение отдела.
8. Через месяц повторите проверку доступом. Тот же тест на пяти пациентах.

Чего делать не стоит: требовать у сотрудников доступ к личным аккаунтам или выгрузку переписки оттуда. Это и не решает задачу, и создаёт вопрос, которого до этого не было.

Как закрепить процесс

• Рабочая переписка не заходит в личные аккаунты. Правило письменное, и в нём указано, что делать сотруднику, которому написали лично: не игнорировать, а перевести разговор в рабочую точку.
• Точка входа зарегистрирована на организацию. С доступом минимум у двух человек, чтобы отсутствие одного не останавливало запись.
• Доступ выдан по роли и снимается одним действием. Это единственная часть, которую можно сделать заранее так, чтобы день увольнения перестал быть событием.
• Известно, кто обращался к данным. Наличие следов обращения не отвечает на правовые вопросы, но отвечает на операционный: можно ли вообще выяснить, кто открывал переписку.
• Список вопросов для юриста существует и обновляется. Признак того, что граница соблюдается: правовые вопросы уходят юристу, а не решаются внутри как «наверное, можно».
• Раз в квартал — проверка доступом на пяти пациентах. Десять минут, и она показывает, не вернулась ли переписка в личные каналы.

Что остаётся за организацией: правовые основания обработки и документы, решение о том, кому выдан доступ, своевременный отзыв доступа, дисциплина личных устройств и внутренний регламент. Ни один сервис не закрывает эти пункты за клиента.

Что для этой ситуации есть в LTVchat

Здесь описано только то, что реализовано в продукте. Никаких заявлений о соответствии требованиям законодательства не делается и делаться не может.

• Переписка подключённых каналов собирается в одно рабочее окно организации, поэтому диалог открывает сотрудник с подходящей ролью, а не только его автор.
• В сервисе четыре роли доступа: менеджер, администратор, владелец, супер-администратор. Роль проверяется на стороне сервера при обработке запроса, а не в интерфейсе. Данные привязаны к рабочему пространству, и запрос к данным чужого пространства отклоняется отдельной проверкой — это два независимых условия, а не одно.
• Действия пишутся в журнал: тип события, тип и идентификатор объекта, роль исполнителя, IP-адрес, время; записи привязаны к рабочему пространству. То есть на вопрос «кто и когда открывал» ответ существует.
• Учётную запись сотрудника можно отключить, а его сессии отозвать, не удаляя историю переписки. Отзыв сессии выполняется отдельно и не зависит от того, закрыта ли у сотрудника вкладка.
• Есть отдельный учёт запросов субъектов персональных данных: тип субъекта, тип запроса, статус, срок исполнения, ответственный и решение; удаление данных клиента фиксируется отдельной записью с причиной и временем. Управление этими записями доступно по административной роли и только через API — отдельного интерфейса для этого в продукте нет. Наличие таких структур не является ни соответствием требованиям, ни подтверждением того, что запрос обработан правильно: тип запроса, срок и правовую обоснованность определяет организация.
• Выгрузка чатов одним PDF-файлом доступна владельцу рабочего пространства; менеджер получает отказ в доступе.

Чего сервис не делает и о чём не заявляет: не даёт правовой оценки и не подтверждает соответствие каким-либо требованиям — сертификаций, аттестаций и внешних аудитов у сервиса нет, о чём прямо сказано на странице безопасности; не назначает ответственного за пациента, такой возможности в нём нет; не сохраняет то, что шло мимо подключённых каналов — личные чаты сотрудников, звонки, разговоры на приёме.

Стоимость — 300 ₽/канал в месяц + 50 ₽/сотрудник в месяц, владельцы подключённых каналов не оплачиваются как сотрудники. Понять исходное положение помогает аудит из десяти вопросов; рабочее окно открыто в демо без регистрации. Почему проблема личных аккаунтов структурная, а не дисциплинарная — здесь; двенадцать проверяемых пунктов для регулярной проверки — в чек-листе.