Снимки КТ весят гигабайты: где стоматологу держать архив исследований

MAATRIX

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

Куда на самом деле уходит место

Каждое КТ- или КЛКТ-исследование — это не один файл, а серия DICOM-снимков: срезы, из которых потом собирается 3D-модель. Даже одно исследование одного пациента — это уже приличный объём, а клиника делает такие снимки регулярно, и с каждым новым пациентом архив растёт. Точный вес одного исследования зависит от аппарата, разрешения и настроек протокола — на разном оборудовании цифры отличаются в разы, поэтому конкретные мегабайты называть смысла нет. Важнее другое: это накопительный процесс, который не останавливается. Панорамные снимки и прицельные рентгенограммы обычно весят заметно меньше, но тоже добавляются к общему объёму месяц за месяцем.

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

Почему рабочий компьютер — не решение

Типичная картина: снимки складываются в папку на компьютере администратора или в кабинете рентген-диагноста. Работает, пока клиника маленькая. Дальше начинаются проблемы:

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

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

Сервер как централизованное хранилище архива

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

Что это даёт на практике:

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

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

Как развернуть хранилище для DICOM-архива

Практически самый предсказуемый вариант — файловое хранилище с веб-доступом и синхронизацией, например Nextcloud: у него есть и обычный доступ по сети (WebDAV, SMB), и веб-интерфейс, которым может пользоваться администратор без специальных знаний. Разворачивается это на арендованном сервере через Docker.

Минимальный docker-compose.yml:

version: "3"
services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: смените_меня
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: смените_меня_тоже
    volumes:
      - db_data:/var/lib/mysql

  app:
    image: nextcloud:29-apache
    restart: unless-stopped
    ports:
      - "8443:80"
    environment:
      MYSQL_HOST: db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: смените_меня_тоже
    volumes:
      - nc_data:/var/www/html
      - /mnt/archive/dental:/var/www/html/data
    depends_on:
      - db

volumes:
  db_data:
  nc_data:

Ключевой момент — вынести директорию с данными (/mnt/archive/dental) на отдельный смонтированный диск большого объёма, а не оставлять её внутри системного раздела. Перед разворачиванием стоит создать этот раздел и проверить свободное место:

lsblk
df -h /mnt/archive

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

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

Структура архива и как в нём не потеряться

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

/archive
  /patients
    /000123_ivanov_ii
      /2024-03-14_klkt/
      /2025-01-20_klkt/
      /2025-06-02_panoramnyj/
    /000124_petrova_ss
      /2024-05-02_klkt/

Номер пациента в начале имени папки — не эстетика, а способ избежать путаницы с однофамильцами и опечатками в фамилиях. Дата исследования в формате ГГГГ-ММ-ДД сортируется в правильном порядке автоматически, что удобно, когда нужно быстро увидеть динамику по хронологии.

Для поиска по фамилии или номеру пациента, если файлов накопилось много, помогает обычный find или grep по индексному файлу:

find /archive/patients -maxdepth 1 -iname "*ivanov*"

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

Резервное копирование: архив не должен существовать в одном экземпляре

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

Рабочая схема — ежедневный инкрементальный бэкап с помощью restic на отдельное хранилище (второй диск того же сервера, отдельный сервер для бэкапов или объектное хранилище):

# инициализация репозитория (один раз)
restic init --repo /mnt/backup/dental-repo

# ежедневный бэкап
restic --repo /mnt/backup/dental-repo backup /mnt/archive/dental

# автоматическая очистка старых версий с сохранением истории
restic --repo /mnt/backup/dental-repo forget --keep-daily 14 --keep-weekly 8 --keep-monthly 24 --prune

Эти команды удобно вызывать через cron раз в сутки, например ночью, когда нагрузка на сервер минимальна:

0 3 * * * restic --repo /mnt/backup/dental-repo backup /mnt/archive/dental >> /var/log/dental-backup.log 2>&1

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

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

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