Сегментация пациентов без лишних персональных данных: что действительно нужно аналитике

• Опубликовано: 20 сентября 2026 г.

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

Таблица выглядит солидно. Только управленческий вопрос в ней почти утонул, а копия медицинской истории уже живёт вне МИС.

Так начинается большинство проблем с сегментацией: клиника думает, что ей нужны «все данные, чтобы потом выбрать», хотя на самом деле ей нужно принять одно конкретное решение. Чем туманнее решение, тем шире выгрузка.

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

Начните не с колонок, а с управленческого решения

Фраза «сегментировать базу» не является задачей. Это инструмент без цели. Хорошая постановка звучит иначе:

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

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

Первый документ проекта — не SQL-запрос и не макет дашборда. Это карточка решения:

1. Какое управленческое действие последует из результата?
2. Кто принимает решение?
3. Какая единица анализа нужна: визит, слот, пациент, направление или филиал?
4. За какой период?
5. Какие поля необходимы, а какие просто доступны?
6. Когда данные перестанут быть нужны?

Если на первый вопрос нет ответа, выгрузку лучше не начинать. Иначе таблица станет складом, к которому постепенно получат доступ люди с разными задачами.

Минимизация — это не запрет на аналитику

Статья 5 Федерального закона № 152-ФЗ закрепляет принципы обработки персональных данных. Среди них — соответствие содержания и объёма данных заявленным целям, недопустимость избыточности и хранение не дольше, чем этого требуют цели обработки, если иной срок не установлен законом или договором.

Для руководителя это переводится на простой язык: каждая колонка должна иметь работу. Не «может пригодиться», а влияет на конкретное решение.

Минимизация полезна не только из-за закона. Она делает аналитику точнее:

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

Парадокс в том, что отчёт с десятью нужными полями часто полезнее выгрузки из ста полей. Во второй можно построить больше графиков, но труднее объяснить, какой из них меняет решение директора.

Не называйте всё «обезличенным»: три разных слоя

В разговорах клиник слово «обезличивание» часто используют для всего: убрали ФИО, заменили телефон звёздочками, присвоили номер, сгруппировали по филиалам. Это создаёт ложное чувство безопасности.

Агрегированные данные

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

Псевдонимизированные данные

Прямые идентификаторы заменены внутренним ключом, но существует таблица соответствия или иной способ вернуть личность. Такой набор всё ещё нужно считать персональными данными и защищать соответственно. Случайный ID вместо ФИО не превращает файл в «ничей».

Обезличенные данные в юридическом смысле

Закон определяет обезличивание как действия, после которых без дополнительной информации невозможно определить принадлежность данных конкретному субъекту. В 2025 году в законодательстве появился отдельный государственный контур статьи 13.1, а Постановление Правительства РФ № 1154 установило требования, методы и правила обезличивания для предусмотренного этим контуром предоставления данных.

Важно не переносить этот специальный порядок механически на любой внутренний отчёт клиники. Он не даёт универсальной кнопки «обезличить Excel». Для собственной модели обработки клинике нужно определить цели, основания, риски повторной идентификации и технические меры вместе с ответственным за данные и юристом.

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

Почему здоровье нельзя тащить в маркетинговый отчёт «на всякий случай»

Сведения о состоянии здоровья относятся к специальным категориям персональных данных по статье 10 закона № 152-ФЗ. Для них действуют особые условия обработки. Кроме того, медицинская информация может охраняться режимом врачебной тайны.

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

Сравните две постановки:

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

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

Во второй постановке медицинский контекст остаётся там, где он нужен врачу и системе, а маркетинг получает ровно тот сигнал, который требуется для разрешённого действия.

Сначала разделите аналитику и коммуникацию

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

Аналитический слой может содержать:

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

В нём обычно не нужны:

• ФИО;
• полный телефон;
• адрес;
• текст медицинского документа;
• свободный комментарий сотрудника;
• диагноз, если решение можно принять по этапу маршрута;
• копия согласия;
• полная дата рождения, если достаточно возрастной группы;
• изображения и исследования.

После того как руководитель утвердил допустимый сегмент, отдельная уполномоченная роль запускает коммуникацию в МИС или CRM, где уже есть основания, контакты, журнал действий и ограничения. Таблица соответствия не гуляет между отделами.

Устойчивый идентификатор полезен — и всё равно опасен

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

Но постоянный ID создаёт длинную цифровую тень. Если его использовать в рекламе, аналитике сайта, МИС, колл-центре и внешней BI-системе, разные наборы становится проще связать. Поэтому идентификаторы нужно разделять по контурам и целям.

Хорошая схема предусматривает:

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

Хеширование телефона само по себе не является магией. Небольшое пространство возможных значений и одинаковый алгоритм позволяют сопоставлять записи или подбирать исходные значения. Решение требует соли, управления ключами, разделения сред и оценки угроз, а не только функции «SHA» в таблице.

Маленькие группы выдают человека без имени

Отчёт «один пациент старше 90 лет из небольшого филиала прошёл редкую процедуру во вторник» может быть фактически узнаваемым для сотрудников, даже если в нём нет имени. Чем больше редких признаков пересекаются, тем выше риск повторной идентификации.

Перед выпуском агрегата проверьте:

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

Универсального безопасного порога для всех задач нет. Клиника определяет правила подавления малых групп и укрупнения категорий по модели риска и цели. Иногда нужно объединить периоды, скрыть ячейку или показать диапазон вместо точного значения.

Проверочный вопрос звучит по-человечески: «Сможет ли получатель догадаться, о ком речь, используя то, что он уже знает?» Если да, формально удалённое ФИО не решило задачу.

Дата рождения, адрес и комментарий — три тихих источника лишнего риска

Дата рождения

Для анализа возрастных групп почти никогда не нужна полная дата. Рассчитайте группу в защищённой системе и передайте только её. Так аналитик не получает точный идентификатор, а показатель остаётся полезным.

Адрес

Для географии спроса может быть достаточно района или укрупнённой зоны. Точный адрес в маркетинговой таблице редко меняет управленческое решение, зато резко повышает чувствительность набора.

Свободный комментарий

Это самая непредсказуемая колонка. Туда попадают диагнозы, семейные обстоятельства, оценки сотрудников, просьбы пациента и фразы, которые никто не планировал анализировать. Для сегментации лучше использовать ограниченный справочник статусов, а свободный текст оставить в системе с назначенным доступом.

Каждое преобразование выполняют до выгрузки, а не после рассылки файла.

Сегмент должен иметь разрешённое действие

Аналитика и прямой контакт — разные операции. Статья 15 закона № 152-ФЗ устанавливает, что обработка персональных данных в целях продвижения товаров, работ и услуг путём прямых контактов с потенциальным потребителем допускается только при предварительном согласии; по требованию субъекта такая обработка должна быть немедленно прекращена.

Отсюда два важных вывода.

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

Второй: «полезное напоминание» не становится автоматически нейтральным только потому, что клиника считает его заботой. Медицинское, сервисное и рекламное сообщение могут иметь разные цели и основания. Квалификацию конкретного сценария следует согласовать с юристом.

В рабочей системе сегмент должен сопровождаться паспортом действия:

• цель;
• основание;
• допустимый канал;
• шаблон сообщения;
• частота;
• срок использования;
• владелец;
• механизм отказа;
• признак остановки.

Без этого аналитик создаёт аудиторию, но никто не знает, что с ней разрешено делать.

Как связать сегментацию со свободными окнами без копии медкарты

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

Сначала анализируют:

• специальность и врача;
• филиал и кабинет;
• день недели и время;
• длительность слота;
• тип записи;
• источник обращения;
• статус подтверждения;
• отмену и время до визита;
• наличие следующего шага в маршруте на уровне категории.

Затем формируют управленческое решение: изменить сетку, открыть лист ожидания, пересмотреть подтверждения, проверить маршрут повторного визита. И только если требуется разрешённый контакт, система выбирает конкретных людей по отдельному правилу.

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

Как поднять старую базу и не превратить её в массовую рассылку

Старая база кажется готовым активом: контакты уже есть, услуги известны, деньги на привлечение когда-то потрачены. Но давность записи не отменяет цели и основания обработки.

Рабочий маршрут начинается не с выгрузки телефонов:

1. Определить конкретный допустимый сценарий.
2. Проверить источник данных и основание предполагаемого контакта.
3. Исключить тех, кто отказался от соответствующей коммуникации.
4. Сформировать сегмент по минимальным признакам.
5. Утвердить нейтральный шаблон без раскрытия медицинской детали постороннему получателю сообщения.
6. Ограничить частоту и срок кампании.
7. Зафиксировать результат и остановить обработку по достижении цели.
8. Не переносить всю базу во внешний сервис ради одного запуска.

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

UTM-метки и веб-аналитика не должны становиться новым идентификатором пациента

Маркетинг хочет знать, какой канал привёл обращение и состоялся ли визит. Для этого достаточно связать рекламный источник с безопасным внутренним событием. Не нужно отправлять во внешнюю аналитику ФИО, телефон, диагноз, текст формы или внутренний номер медицинской карты.

Безопасный проект задаёт границу:

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

Материал об UTM-аналитике клиники помогает проверить источник, форму, CRM и результат без превращения метки в переносчика данных.

Составной сценарий: отчёт стал меньше, а решений — больше

Следующая сцена — иллюстративная реконструкция из типовых проектных ошибок. Она не описывает конкретную клинику и не содержит выдуманной статистики успеха.

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

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

Свободные комментарии исчезают. Полная дата рождения превращается в возрастную группу. Редкие комбинации подавляются. У каждого показателя появляется определение и владелец.

Отчёт становится короче. Это не эффектная победа «Big Data», зато совещание наконец обсуждает решения, а не спорит, чья таблица правильнее.

Архитектура из четырёх зон

Практичная схема сегментации состоит из четырёх зон.

Зона 1. Источник

МИС, CRM, телефония, сайт или расписание. Здесь живут исходные персональные данные и медицинский контекст. Доступ предоставляется по роли, действия журналируются.

Зона 2. Подготовка

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

Зона 3. Аналитика

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

Зона 4. Действие

После решения утверждённый сегмент возвращается в защищённую систему. Она проверяет основания и выполняет допустимую коммуникацию или ставит внутреннюю задачу. Аналитик не получает список телефонов как побочный продукт.

Между зонами нужны формальные интерфейсы: какие поля проходят, кто запускает, где журнал, как удаляется временный набор. Если сотрудники передают CSV вручную, архитектура существует только на презентации.

Матрица ролей: кому что действительно нужно

Роль не должна получать доступ «на всякий случай». Она получает его под конкретную функцию и срок.

Как проверить подрядчика и BI-систему

Красивый дашборд может скрывать широкую копию базы. До подключения спросите:

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

Ответ «мы всё шифруем» недостаточен. Шифрование не объясняет цель, минимизацию, доступ, срок и выход из сервиса.

Срок хранения начинается с цели, а не с размера диска

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

Для каждого набора заранее задают:

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

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

Как измерять пользу сегмента, не оценивая людей

Показатель должен относиться к процессу, а не превращать пациента в «плохого» или «невыгодного».

Полезные метрики:

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

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

Красные флаги сегментации

Остановите проект и пересмотрите схему, если:

• задача формулируется как «выгрузить всё»;
• в файле есть ФИО и диагноз, но никто не может объяснить зачем;
• псевдонимизированный набор называют полностью обезличенным;
• таблица соответствия лежит рядом с аналитикой;
• отчёт отправляют подрядчику по личной почте;
• один дашборд показывает всем ролям одинаковую детализацию;
• в URL или UTM попадает телефон либо внутренний номер карты;
• маленькие группы раскрывают редкие случаи;
• свободные комментарии используются как категория;
• отсутствует дата удаления;
• отказ от коммуникации не блокирует следующий запуск;
• доступ бывшего сотрудника сохраняется;
• тестирование проводят на копии продуктивной базы;
• выгрузка создаётся вручную и нигде не журналируется;
• никто не может перечислить все копии набора.

Это не список поводов отказаться от аналитики. Это список мест, где её нужно сделать взрослее.

Чек-лист запуска одного сегмента

1. Запишите решение. Одно предложение без слова «аналитика».
2. Определите единицу. Слот, визит, событие, направление или пациент.
3. Подтвердите цель и основание. Вместе с ответственным за данные и юристом.
4. Составьте минимальный набор полей. У каждого — назначение.
5. Уберите прямые идентификаторы из аналитического слоя. Если нужен ключ, защитите соответствие отдельно.
6. Преобразуйте точные значения. Возрастная группа вместо даты рождения, район вместо адреса, период вместо минуты.
7. Проверьте малые группы. Не выдаёт ли комбинация конкретного человека.
8. Разделите роли. Кто видит агрегат, кто может вернуть контакт, кто выполняет действие.
9. Настройте журнал. Создание, просмотр, экспорт, сопоставление и удаление.
10. Определите срок. И событие, после которого набор больше не нужен.
11. Протестируйте синтетически. Без реальных историй и контактов.
12. Утвердите действие. Канал, шаблон, частоту, отказ и остановку.
13. Измерьте процесс. Не только отклик, но и ошибки, жалобы, лишние экспорты.
14. Удалите временные копии. С подтверждением владельца.

Если хотя бы один пункт не имеет владельца, сегмент ещё не готов к работе.

FAQ

Достаточно ли удалить ФИО, чтобы данные стали обезличенными?

Нет. Человека можно узнать по телефону, дате рождения, редкой услуге, времени визита или комбинации признаков. Если личность восстанавливается с дополнительной информацией, набор следует защищать как персональные данные и не называть полностью обезличенным без обоснования.

Можно ли использовать внутренний ID пациента в дашборде?

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

Нужен ли маркетологу диагноз для сегментации?

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

Можно ли передать подрядчику обезличенную выгрузку?

Сначала нужно доказать, что она действительно обезличена с учётом доступной подрядчику дополнительной информации. Также проверяют договор, цель, состав, место обработки, субподрядчиков, удаление и запрет повторной идентификации. Наклейки «без ФИО» недостаточно.

Как работать со старыми пациентами?

Начать с конкретного сценария, проверить основание и допустимый канал, исключить отказы, минимизировать признаки и выполнять контакт внутри защищённой системы. Наличие телефона в старой базе не означает разрешения на любое продвижение.

Какой первый отчёт сделать безопаснее всего?

Начните с агрегированной загрузки расписания по филиалу, специальности, дню недели и статусу слота. Такой отчёт даёт управленческую пользу без ФИО и медицинских документов, а затем показывает, нужен ли вообще переход к индивидуальному контакту.

Что сделать завтра

Возьмите одну текущую выгрузку и закройте ладонью столбцы ФИО, телефона, даты рождения, диагноза и комментария. Спросите владельца: «Какое решение мы больше не можем принять без каждого из них?»

Если ответ не находится, поле лишнее для этого отчёта. Если находится — опишите точную функцию, основание, получателя и срок. Затем отделите агрегат от механизма контакта и проверьте, можно ли выполнить сопоставление внутри МИС или CRM без рассылки таблицы.

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

Хорошая сегментация не знает о пациенте больше. Она знает ровно столько, сколько нужно для честного решения, и умеет остановиться.

Источники и границы материала

• Федеральный закон № 152-ФЗ «О персональных данных» — определения, принципы, основания и обязанности оператора.
• Статья 5 закона № 152-ФЗ — соответствие данных цели, недопустимость избыточности и ограничение хранения.
• Статья 10 закона № 152-ФЗ — специальные категории данных, включая сведения о здоровье.
• Статья 15 закона № 152-ФЗ — прямые контакты для продвижения товаров, работ и услуг.
• Постановление Правительства РФ от 1 августа 2025 года № 1154 — специальный порядок обезличивания в контуре статьи 13.1 закона № 152‑ФЗ; его нельзя автоматически считать универсальной инструкцией для любого внутреннего отчёта.

Материал не является юридическим заключением и не описывает обработку данных конкретной клиники. Цели, основания, состав, меры защиты и допустимость коммуникаций нужно определять по актуальным документам вместе с ответственным за персональные данные, юристом и медицинским руководством.