Массажист ведёт карточки клиентов: медданные и почему им не место в блокноте

MAATRIX

Карточка клиента у массажиста — это не просто телефон и удобное время сеанса. Это противопоказания, перенесённые травмы, хронические состояния, иногда прямые слова врача о том, что можно и что нельзя трогать. Такие сведения многие годами ведут в бумажном блокноте на стойке или в общей гугл-таблице с коллегами по кабинету — и обе привычки держатся на честном слове, а не на защите. Ниже — почему это проблема именно с медданными, а не с абстрактной «приватностью», и как собрать вместо блокнота и таблицы свою базу карточек на сервере, доступную только вам.

Почему карточка клиента массажиста — это медданные, а не просто контакты

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

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

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

Бумажный блокнот: удобно, пока не потерялся

Блокнот работает, пока клиентов немного и вы помните контекст каждого без подсказок. Проблема не в самом бумажном формате — она в том, что бумага физически не защищена ничем, кроме привычки не оставлять её на виду.

Три конкретные вещи, которые ломаются:

• Блокнот можно потерять или забыть. Оставили в такси, в сумке, которую разбирал кто-то другой, — и вся история противопоказаний и травм клиентов оказалась в чужих руках без вашего ведома и без возможности что-то с этим сделать постфактум.
• Блокнот видят посторонние. Если вы работаете в общем кабинете или на выезде, блокнот на столе рядом с кушеткой читает не только клиент, чья это карточка, — его видит следующий клиент, коллега, администратор. Никакой перелистываемой странице нельзя объяснить, что дальше нельзя.
• Ничего не ищется и не резервируется. Если блокнот залился водой, сгорел в машине летом или просто истрепался за пару лет — вся история наблюдений по каждому клиенту исчезает без следа, и восстановить её нечем, кроме памяти.

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

Общая таблица в облаке — тоже самое, только в цифре

Следующий шаг, который делают многие, — переезд с блокнота в общую гугл-таблицу или заметки в телефоне, которые синхронизируются между устройствами. Это решает проблему «залил водой», но не решает проблему приватности, а иногда даже усугубляет её.

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

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

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

Своя база на сервере: что меняется на практике

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

Что именно меняется:

• Доступ только у вас. Вместо ссылки «может редактировать кто угодно» — логин и пароль, которые знаете только вы (и, если есть ассистент или второй мастер, — отдельный логин с собственными правами, а не общий на всех).
• Структура вместо простыни текста. У каждого клиента одинаковый набор полей: контакты, противопоказания, история сеансов, заметки по зонам — и по этой структуре можно фильтровать и искать, а не перечитывать всё вручную.
• Данные физически там, где решили вы. Сервер можно арендовать в конкретной стране и дата-центре осознанно, а не полагаться на то, где решил хранить данные владелец облачного сервиса общего назначения.
• Резервные копии по расписанию, а не по случаю. Вместо «блокнот, который жалко потерять» — автоматический бэкап базы каждую ночь, о котором не нужно вспоминать вручную.

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

Собираем базу: NocoDB поверх PostgreSQL

Для одного массажиста или небольшого кабинета из двух-трёх мастеров не нужна тяжёлая медицинская информационная система с десятками модулей — достаточно лёгкой надстройки с веб-интерфейсом над обычной базой данных. NocoDB берёт таблицы в PostgreSQL и превращает их в интерфейс с фильтрами, карточным видом и формами — без программирования с вашей стороны. Подробный разбор установки есть в отдельной статье про установку NocoDB на VPS; здесь — минимальный рабочий стек именно под карточки клиентов.

Понадобится небольшой VPS: 2 vCPU, 4 ГБ RAM, диск от 40 ГБ (если планируете хранить в карточках ещё и фотофиксацию зон работы или сканы направлений от врача — берите диск с запасом, фото растут в объёме быстрее текста). На сервере с Ubuntu 24.04 ставим Docker и Docker Compose, дальше — docker-compose.yml:

version: "3.8"

services:
  cards-db:
    image: postgres:16-alpine
    container_name: cards-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: client_cards
      POSTGRES_USER: cards_admin
      POSTGRES_PASSWORD: замените_на_свой_пароль
    volumes:
      - cards_db_data:/var/lib/postgresql/data

  nocodb:
    image: nocodb/nocodb:latest
    container_name: nocodb
    restart: unless-stopped
    depends_on:
      - cards-db
    environment:
      NC_DB: "pg://cards-db:5432?u=cards_admin&p=замените_на_свой_пароль&d=client_cards"
      NC_PUBLIC_URL: "https://cards.вашдомен.ru"
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - nocodb_data:/usr/app/data

volumes:
  cards_db_data:
  nocodb_data:

Порт NocoDB намеренно проброшен только на 127.0.0.1 — наружу его отдаёт обратный прокси с TLS, а не голый HTTP-порт напрямую в интернет. Для этого подойдёт Caddy, который сам получает и продлевает сертификат Let's Encrypt:

cards.вашдомен.ru {
    reverse_proxy 127.0.0.1:8080
}

После docker compose up -d и настройки Caddy база доступна по вашему домену с рабочим HTTPS. На файрволе закройте всё лишнее — на UFW это ufw allow 22/tcp, ufw allow 443/tcp, ufw allow 80/tcp (нужен только для выпуска сертификата) и ufw enable; порт самой базы данных наружу открывать не нужно вовсе, изнутри контейнерной сети Docker он и так виден только NocoDB.

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

Структура карточки, доступ на выезде и резервные копии

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

Клиенты (clients): имя, телефон, дата рождения (важно для некоторых противопоказаний, связанных с возрастом), источник (откуда пришёл), общий статус (активный / разовый / давно не был).

Медкарточка (health_notes), связана с клиентом: противопоказания (текстом, свободно — грыжи, тромбозы, беременность, кожные состояния, недавние операции), зоны с ограничениями («поясница — только лёгкая проработка», «плечо после травмы — без глубокой разминки»), направление от врача, если есть (текст или скан документа), дата последнего обновления сведений — противопоказания и состояния со временем меняются, и важно видеть, когда карточку смотрели в последний раз.

Журнал сеансов (sessions), связана с клиентом: дата, вид массажа, зоны работы, реакция клиента после сеанса (короткий комментарий своими словами — не для отчётности, а чтобы через месяц вспомнить контекст), интенсивность, которая сработала или, наоборот, была избыточной.

Пример того, как это выглядит в интерфейсе NocoDB после пары месяцев работы:

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

Массажист много работает не в одном фиксированном кабинете, а на выезде или в разных студиях, поэтому доступ с телефона — не опция, а обязательное условие. NocoDB — обычное веб-приложение, открывается в браузере телефона по вашему домену без установки отдельного приложения; через «Добавить на главный экран» в браузере на iOS и Android страница визуально не отличается от нативного приложения. Если хочется дополнительно закрыть форму входа от открытого интернета — на этом же сервере разумно поднять WireGuard и заходить в базу карточек только через VPN-туннель, тогда сервис снаружи попросту не виден для перебора пароля.

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

#!/bin/bash
docker exec cards-db pg_dump -U cards_admin client_cards | gzip > /backups/cards-$(date +%F).sql.gz
find /backups -name "cards-*.sql.gz" -mtime +14 -delete

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

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

Частые вопросы