Медицинская карточка содержит одни из самых чувствительных данных, но в реальной клинике к CRM имеют доступ многие: врачи, администраторы, аналитики, а теперь ещё и голосовой робот. Если все видят всё, утечка или ошибка вопрос времени, а закон о персональных данных прямо требует ограничивать доступ необходимым. Разграничение ролей решает это: каждый видит ровно то, что нужно для работы. Разбираем, как устроены роли, что должен и не должен видеть робот и как это соотносится с 152-ФЗ.
Разграничение ролей — это модель, при которой доступ к данным пациентов определяется должностью: врач видит медицинскую информацию, администратор — контакты и расписание, аналитик — обезличенные сводки, робот — только необходимое для записи. Каждая роль ограничена своим набором прав. Так реализуется принцип минимальных привилегий, которого требует работа с ПДн.
Смысл прост: чем меньше людей и систем видят чувствительные данные, тем ниже риск утечки и ошибки. Доступ — это не удобство, а зона ответственности.
Разберём, зачем нужны роли, что видит каждая из них и как встроить в эту модель робота.
Когда у всех сотрудников полный доступ к карточкам, растут сразу два риска: утечка данных и случайная порча информации. По статистике инцидентов, от 20% до 30% утечек персональных данных связаны не с внешними взломами, а с избыточными правами внутри организации. Чем шире доступ, тем больше поверхность риска.
Полный доступ ещё и мешает разобраться в инцидентах: если карточку мог изменить кто угодно, найти причину ошибки невозможно. Ролевая модель сужает круг.
Закон о персональных данных прямо требует ограничивать доступ необходимым для выполнения задач, а не выдавать всем всё «на всякий случай».
Принцип минимальных привилегий означает, что каждой роли выдаётся только тот доступ, без которого она не может работать, и ни каплей больше. Администратору не нужен доступ к диагнозам, аналитику — к именам пациентов, роботу — к медицинской истории. Урезание прав до необходимого минимума — базовое правило безопасности данных.
Это не про недоверие к людям, а про снижение последствий ошибки или компрометации учётной записи: взломанный аккаунт с узкими правами наносит меньше вреда.
Минимальные привилегии проще поддерживать, чем кажется: роль описывается один раз, а дальше применяется ко всем, кто в ней.
Врачу нужен доступ к медицинской части карточки своих пациентов: история обращений, назначения, результаты, записи на приём. При этом врачу не обязательно видеть данные пациентов других специалистов или коммерческую аналитику клиники. Доступ ограничивается его пациентами и его профессиональной зоной.
В деликатных направлениях доступ сужают ещё сильнее: к записям психотерапии или наркологии допускают только лечащего специалиста. Это и требование приватности, и вопрос доверия пациента.
Границы врачебного доступа задают по специализации и прикреплению пациентов, а не выдают «всё обо всех».
Администратору для работы нужны контакты, расписание и статусы записей, но не медицинское содержание карточек. Он записывает, переносит, подтверждает визиты — и для этого достаточно имени, телефона и слота. Диагнозы и врачебные записи в его зону не входят, что и снижает риск при широком круге администраторов.
Такое разграничение логично: администраторов обычно много и текучесть выше, поэтому их доступ к чувствительным данным особенно опасно расширять.
Робот, ведущий запись, работает примерно в границах администратора — об этом ниже.
Роботу для записи нужен минимум: контакт пациента, услуга, врач, свободные слоты, история его обращений в клинику. Ему не нужны и не выдаются медицинские диагнозы и врачебные заключения — он не ставит диагнозы и не даёт рекомендаций. Робот собирает только те данные, что необходимы для его задачи, и не больше.
Это соответствует и принципу минимизации данных: система не должна запрашивать и хранить лишнее. Робот фиксирует жалобу со слов пациента для маршрутизации, но не ведёт медкарту.
Границу «что робот решает сам, а что отдаёт человеку» задают заранее — сложные и медицинские вопросы он эскалирует.
Аналитику для его работы нужны цифры и тренды, а не персональные данные конкретных пациентов. Поэтому ему дают обезличенные или псевдонимизированные сводки: доли тем, конверсии, загрузку — без имён и телефонов. Так аналитика возможна, а персональные данные при этом не покидают защищённый контур.
Псевдонимизация — ключ: она позволяет считать метрики и строить отчёты, не раскрывая, о ком именно идёт речь. Для аналитики важна статистика, а не личность.
Разделение «работа с данными» и «работа с метриками» снимает лишний доступ к ПДн у тех, кому нужны только агрегаты.
Робот — это отдельная роль в системе, а не «суперпользователь». Ему выдают собственный набор прав: создавать записи и сделки, читать расписание, писать результат звонка — и не более. Он не должен иметь доступа туда, куда не должен, только потому что он автоматизирован. Учётная запись робота ограничивается так же строго, как человеческая.
Отдельная роль робота важна ещё и для аудита: по логам видно, что сделал именно робот, а что человек. Это невозможно, если робот работает под общей учёткой.
Как связка робота с CRM устроена технически, показано в материале про двустороннюю синхронизацию записей.
Разграничение ролей работает вместе с аудит-логом — записью того, кто и когда обращался к карточке и что менял. Лог показывает, робот проставил статус или человек, и позволяет разобрать любой инцидент. Требования к доступу к медданным прямо предполагают ведение таких журналов.
Без аудит-лога роли — это половина решения: права ограничены, но нельзя проверить, как ими пользовались. Лог замыкает контроль.
Отдельная роль робота делает лог осмысленным: его действия выделены и отличимы от действий сотрудников.
В сети клиник роли дополняются измерением филиала: администратор одного филиала не видит пациентов другого, а управляющая роль видит сводку по всем. Это сочетает единую базу с изоляцией данных между точками. Одна платформа обслуживает всю сеть, но доступ каждого ограничен его зоной.
Такое разграничение по филиалам — частая потребность сетей: общая аналитика наверху, но операционный доступ строго локальный.
Как устроена работа сети клиник на единой платформе, разобрано в материале про автоматизацию сети медцентров.
Закон о персональных данных требует обрабатывать данные для конкретных целей и в минимальном объёме, а доступ к ним ограничивать. Ролевая модель — прямой способ выполнить это требование: она документирует, кто и зачем видит данные, и не даёт лишнего доступа. Это снижает и юридический риск, и вероятность инцидента.
Разграничение ролей — не бюрократия, а выполнение закона на практике: регулятор ожидает именно ограниченного и обоснованного доступа.
Юридические рамки работы с данными пациентов в звонках разобраны в материале про 152-ФЗ и голосовые боты.
Частые ошибки — общая учётная запись на всех, робот с избыточными правами, отсутствие аудит-лога и «временные» широкие доступы, которые забывают снять. Каждая из них расширяет поверхность риска и мешает разбирать инциденты. Ролевая модель работает, только если её поддерживают, а не настраивают один раз и забывают.
Отдельная беда — не пересматривать доступы при увольнении и смене должности: у бывших сотрудников остаются права, которых быть не должно.
Регулярная ревизия ролей — такая же гигиена, как смена паролей: её стоит проводить хотя бы раз в 3 месяца.
Начните с инвентаризации: кто и какой доступ имеет сейчас и зачем. Чаще всего обнаруживается, что доступ шире необходимого. Опишите базовые роли — врач, администратор, робот, аналитик — и урежьте права каждой до нужного минимума. Затем включите аудит-лог, чтобы видеть использование доступа.
Отдельно заведите роль для робота с собственными ограниченными правами — не давайте ему работать под общей учёткой администратора.
Протестировать работу робота в границах ограниченной роли можно бесплатно 7 дней без карты и убедиться, что для записи ему хватает минимума данных.
7 дней бесплатно, без карты. Подключение к вашему номеру за 15 минут.