Врач частной практики и карты пациентов: 152-ФЗ и свой сервер

MAATRIX

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

Почему карта пациента — это не просто файл

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

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

Что говорит 152-ФЗ и почему это касается именно вас

В России обработка персональных данных регулируется Федеральным законом №152-ФЗ «О персональных данных». Закон исходит из простой идеи: у любых персональных данных есть человек, которому они принадлежат, и тот, кто эти данные обрабатывает и хранит, несёт за них ответственность — независимо от размера организации. Частнопрактикующий врач, ведущий карты пациентов на бумаге, в Excel или в облачном сервисе, точно так же попадает в эту логику, как крупная клиника или сетевая лаборатория.

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

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

Готовые сервисы и облачные МИС: где именно теряется контроль

Облачные сервисы для медицинских карт (МИС, CRM для клиник, конструкторы электронных карт) решают реальную проблему — не нужно ничего настраивать самому, всё работает «из коробки». Но у этой лёгкости есть цена, и она не в деньгах, а в контроле.

Когда вы регистрируетесь в стороннем сервисе, вы, как правило, не знаете и не можете легко проверить:

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

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

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

Свой сервер: что именно это меняет

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

На своём сервере вы точно знаете:

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

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

Как выстроить хранение: практическая схема

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

1. Сам сервер. Для приёма на несколько сотен–тысяч пациентов вполне достаточно небольшого VPS: 2 vCPU, 4–8 ГБ RAM, SSD-диск от 40–80 ГБ под базу и документы, с запасом под рост. Снимки и вложения растут быстрее текста, так что диск лучше брать с запасом или подключать отдельный том под файлы.

2. Программная часть. Вариантов немного, и все реализуемы своими руками на арендованном сервере:

• открытая медицинская информационная система (например, OpenEMR или аналог) — готовый веб-интерфейс для карт, расписания и документов, разворачивается через Docker;
• собственная связка — база данных (PostgreSQL или MySQL) плюс простой веб-интерфейс или даже защищённая файловая структура, если приём небольшой и сложная МИС избыточна;
• существующая CRM для клиник, но развёрнутая не в облаке разработчика, а как self-hosted версия на вашем сервере, если разработчик такую версию предоставляет.

Пример разворачивания базы для карт через Docker Compose:

services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: patient_records
      POSTGRES_USER: clinic_admin
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - internal
    secrets:
      - db_password

networks:
  internal:
    internal: true

volumes:
  db_data:

secrets:
  db_password:
    file: ./secrets/db_password.txt

Обратите внимание на internal: true у сети — база данных не должна смотреть наружу интернета вообще, только веб-приложение, которое к ней обращается, и то через reverse-proxy с HTTPS.

3. Шифрование диска. Даже если сервер физически надёжно охраняется дата-центром, диск стоит шифровать — на случай кражи носителя при обслуживании или списании оборудования. На Linux для этого используется LUKS:

cryptsetup luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 patient_data
mkfs.ext4 /dev/mapper/patient_data
mount /dev/mapper/patient_data /var/lib/patient-records

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

4. Доступ только через VPN. Панель управления картами не должна быть доступна из открытого интернета. Разумная схема — поднять WireGuard или Tailscale, и заходить на сервер только через VPN-туннель, даже если работаете из дома или из клиники. Дополнительно стоит включить двухфакторную аутентификацию для панели администрирования и SSH-доступа — это резко снижает риск, что чужой пароль откроет доступ к картам пациентов.

Резервные копии и что делать при потере доступа

Собственный сервер снимает риск «облако само решило поменять условия», но добавляет ответственность за резервное копирование — теперь об этом заботитесь вы, а не провайдер МИС.

Рабочая схема бэкапов для карт пациентов:

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

Инструмент вроде BorgBackup позволяет делать инкрементальные зашифрованные копии автоматически по расписанию:

borg init --encryption=repokey-blake2 /mnt/backup-remote/patient-records
borg create --stats --compression zstd \
  /mnt/backup-remote/patient-records::{now:%Y-%m-%d} \
  /var/lib/patient-records /var/lib/postgresql/backups

Если хочется разобраться в теме резервного копирования с шифрованием подробнее — есть отдельный материал про частые ошибки бэкапа с шифрованием.

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

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