Стоматология: снимки КТ по 200 МБ и облако, которое считает деньги за гигабайт

MAATRIX

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

Почему архив снимков в стоматологии не может уменьшиться

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

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

Как облако с оплатой за гигабайт превращается в растущую статью расходов

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

К этому часто добавляются менее очевидные статьи расходов, которые не сразу видны в маркетинговых материалах облачных сервисов:

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

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

Прикидываем масштаб: пример расчёта (это ориентир, а не измеренная цифра)

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

Возьмём условную клинику на три кресла, где КТ или КЛКТ назначается не каждому пациенту, а выборочно — например, ортодонтам и хирургам это требуется чаще, терапевтам реже. Если условно считать, что клиника делает несколько десятков таких исследований в месяц, а каждое весит около тех самых иллюстративных 200 МБ из тарифной таблицы, за год набегает несколько десятков гигабайт только на КТ — и это без панорамных снимков, прицельных рентгенограмм и фотопротоколов, которые тоже часто складывают в тот же архив. За три-пять лет работы клиники архив может вырасти до объёма, который на старте казался нереалистичным.

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

Свой сервер: фиксированная цена вместо счёта, который растёт сам по себе

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

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

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

Как технически перенести архив снимков на сервер

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

Общая схема для клиники:

1. Хранилище на сервере. Снимки раскладываются по структуре, которая отражает логику клиники, а не логику файловой системы: обычно это папки по году, внутри — по пациенту (идентификатор, а не ФИО в открытом виде — см. следующий раздел), внутри — исследования по дате. DICOM-файлы можно хранить как есть, без пересжатия, чтобы не терять диагностическое качество.
2. Доступ для врачей и администратора. Рабочие места в кабинетах подключаются к серверу либо через защищённое соединение внутри локальной сети клиники, либо через VPN, если сервер арендован в дата-центре, а не стоит физически в клинике. Для DICOM-архивов часто используют PACS-совместимое программное обеспечение — на рынке есть как открытые, так и коммерческие решения, выбор конкретного продукта — отдельная задача, которую стоит решать исходя из того, с каким оборудованием и ПО уже работает клиника.
3. Перенос существующего архива. Если снимки уже лежат в облаке, перенос делается пакетами — экспорт партии исследований, копирование на сервер, проверка целостности (контрольные суммы файлов), и только после проверки — удаление или архивирование партии в облаке. Не стоит выключать старое хранилище, пока не убедитесь, что все данные благополучно доехали и открываются.
4. Резервное копирование. Один сервер — это не резервная копия. Даже переехав с облака, клинике нужна вторая копия архива: либо на втором сервере, либо на внешнем носителе, который регулярно обновляется и хранится отдельно от основного оборудования. Настройка регулярного бэкапа — например, ежедневного инкрементального и еженедельного полного — снимает большую часть риска потери данных при отказе диска.

Пример упрощённой структуры хранения на сервере, если ориентироваться на файловую организацию:

/archive
  /2026
    /patient_00417
      /2026-03-12_ct
        slice_001.dcm
        slice_002.dcm
        ...
      /2026-08-19_pano
        pano.dcm
  /2025
    /patient_00298
      ...

Такая структура упрощает и резервное копирование по годам, и разграничение доступа, и последующий поиск конкретного исследования вручную, если PACS-система по какой-то причине недоступна.

Что учесть отдельно: защита данных пациентов при переезде на свой сервер

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

• Разграничение доступа. У администратора на ресепшене не должно быть доступа ко всему архиву снимков — только у врачей, которые ведут конкретного пациента, и у ответственного за ИТ. На сервере это настраивается через учётные записи и права на папки, а не через общий пароль на всех.
• Шифрование диска. Если сервер стоит в дата-центре, а не в помещении клиники под замком, стоит рассмотреть шифрование данных на диске — это защищает архив в сценарии физического доступа к оборудованию, который клиника не контролирует напрямую.
• Идентификация пациентов в файловой структуре. Лучше хранить снимки под внутренним идентификатором пациента (номер карты), а не под полным ФИО в имени файла или папки — сопоставление ФИО и номера карты держится в отдельной, более защищённой части системы.
• Журнал доступа. Если ПО для просмотра снимков умеет логировать, кто и когда открывал конкретное исследование, стоит это включить — при разборе спорной ситуации такой журнал полезен для самой клиники.
• Локация сервера. Для клиники, работающей с пациентами из России, разумно ориентироваться на то, где физически размещён сервер и какому законодательству подчиняется дата-центр — это отдельный вопрос, который стоит решить до переезда архива, а не после.

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

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