Свой, покупной или гибрид для телемедицины

Это инженерные рекомендации, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.

Кратко

Первое серьёзное решение в телемед-проекте касается не функций, а того, какую часть платформы строить самим: купить готовый продукт, собрать свой поверх арендованного видеослоя или написать весь стек с нуля. Вариантов на деле четыре – готовая платформа, white-label, гибрид (ваш продукт на арендованном видеослое) и полностью своя сборка, – и каждый по-своему влияет на деньги, сроки, контроль и на то, о чём часто забывают: кто отвечает за медданные. В России к этому добавляется жёсткий фильтр: базы с данными пациентов – только в стране (ст. 18 ч. 5 152-ФЗ), каждый подрядчик работает по поручению клиники-оператора (ст. 6), а консультация требует ЕСИА, УКЭП врача и обмена с ЕГИСЗ. Зарубежные платформы и видео-API этот фильтр не проходят. Для большинства команд разумный выбор по умолчанию – гибрид: самую трудную часть, клиническое видео, вы берёте у российского вендора, который держит медиа в России, а контроль над клиническим продуктом остаётся у вас. Ниже – расчёт затрат в рублях, карта ответственности за медданные и лист решения.

Зачем это читать

Почти каждый телемед-проект, у которого кончились деньги, ответил на вопрос «свой или покупной» не осознанно, а по случайности. Команда либо покупает закрытую платформу и на четвёртом месяце узнаёт, что та не умеет главного – того, ради чего задуман продукт; либо решает «просто написать своё» и тратит год и десятки миллионов рублей на видеостек, который можно было арендовать. Статья – для основателя, продакт-менеджера или ИТ-руководителя клиники, у которых есть телемед-идея и бюджет и которым до первой строки кода нужно решить, какой частью платформы владеть. От этого решения зависит, запуститесь вы за недели или будете переписывать продукт через год. А поскольку речь о медицине, есть вопрос, который нельзя обойти: каждый вариант оставляет на вас свой объём ответственности по 152-ФЗ и 323-ФЗ, и знать его нужно до подписания договоров.

Четыре точки на одной шкале

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

Первая точка – готовая платформа. Вы покупаете законченный телемед-продукт – приложение врача, приложение пациента, расписание, видео, иногда оплату, – настраиваете его, ставите логотип там, где разрешает вендор, и запускаетесь. Вы – арендатор. Вторая точка – white-label платформа: та же идея, но вендор разрешает выдавать её за свою, открывает больше настроек, а иногда и API, чтобы что-то достроить сбоку. Вы по-прежнему арендатор, только квартира получше и стены можно перекрасить.

Третья точка – гибрид, и именно здесь находится большинство успешных заказных телемед-продуктов. Вы делаете свой продукт – клинический процесс, приложения пациента и врача, модель данных, – но не строите под ним по-настоящему трудную инфраструктуру. Главное, что вы арендуете, – видеослой реального времени у вендора CPaaS (Communications Platform as a Service), который продаёт видео как API, так что медиасерверы держите не вы. Продукт ваш, инфраструктура арендована. Четвёртая точка – полностью своя сборка: вы строите и продукт, и инфраструктуру, включая собственные медиасерверы на open-source в российском облаке. Всё принадлежит вам, и за всё отвечаете вы.

Нажмите, чтобы увеличить

Четыре параметра, которые меняются вместе

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

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

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

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

Четвёртый – ответственность за медданные, и её основатели недооценивают чаще всего. Ей посвящён отдельный раздел: в медицине это половина решения.

Ответственность за медданные: неочевидный параметр

Правовая основа у всех телемед-продуктов в России одна. Сведения о здоровье – специальная категория персональных данных (ст. 10 152-ФЗ), а сведения о факте обращения, состоянии здоровья и диагнозе – врачебная тайна (ст. 13 323-ФЗ) [1]. Что это значит для продуктовой команды, подробно разобрано в статье о 152-ФЗ и врачебной тайне простым языком. Для выбора «свой или покупной» важен более узкий и острый вопрос: когда данные пациента проходят через систему вендора, кто юридически отвечает за их защиту и где они физически хранятся?

Ответ на первую часть даёт поручение на обработку персональных данных (ст. 6 ч. 3 152-ФЗ): договор, по которому клиника-оператор поручает вендору обработку и в котором перечислены данные, действия с ними и цели, обязанность соблюдать конфиденциальность, требования к защите по ст. 19 и обязанность сообщать оператору об инцидентах [2]. Перед пациентом отвечает оператор, обработчик – перед оператором (ч. 5); как выстроить цепочку – в статье о поручении обработки ПДн и договорах с подрядчиками. Ответ на вторую часть – требование локализации: с 1 июля 2025 года хранить ПДн граждан РФ в зарубежных базах прямо запрещено (ст. 18 ч. 5), а отправка медданных на сервер за рубежом – трансграничная передача спецкатегории (ст. 12) [1][3]. У вендора либо есть письменно подтверждённые поручение и размещение данных в России для вашего сценария, либо их нет, и промежуточного «наверное, нормально» не бывает. Шифрование их не заменяет: сервис может шифровать всё и при этом хранить записи за рубежом. «Зашифровано» ещё не значит «соответствует требованиям».

Посмотрим, как это распределяется по шкале. Когда вы покупаете готовую или white-label платформу, вендор держит весь стек и работает по одному поручению, которое покрывает его целиком вместе с его подрядчиками – облаком, SMS-шлюзом, почтой. За вами остаются обязанности оператора: согласия пациентов, уведомление Роскомнадзора об обработке, раскрытие пациенту – по п. 37 приказа 193н в том числе оператора информационной системы и места хранения материалов [5]. Зона вашей личной ответственности невелика. В white-label всё, что вы достроили через API вендора, – интеграции с МИС и ЕГИСЗ, свои отчёты – уже ваша зона.

Когда вы строите гибрид, ответственность делится. Видеовендор работает по поручению на видеослой. Но всё остальное в продукте – база данных, файловое хранилище, журналы, аналитика, трекер ошибок, рассылка email и SMS – ваше, и каждый сторонний сервис, который видит медданные, должен размещаться в России и входить в цепочку поручений. Как собрать всё это в архитектуру, которая выдержит проверку, – в статье об архитектуре комплаенса по 152-ФЗ и 323-ФЗ. Зона ответственности здесь средняя, и работы в ней немало.

Когда вы строите всё сами, вы отвечаете за всё, включая видеоинфраструктуру. Опереться на поручение видеовендору не получится: медиасерверы держите вы. Каждая мера, которую требуют ПП 1119 и приказ ФСТЭК № 21 для вашего уровня защищённости, – управление доступом, регистрация событий, защита каналов, резервирование – на вас: спроектировать, внедрить, задокументировать и показать на проверке [6][7]. Чужое здесь только облако: Yandex Cloud, Cloud.ru, Selectel, MWS предлагают аттестованные сегменты под УЗ-1 [9], но аттестат покрывает инфраструктуру провайдера, а не ваше приложение.

Нажмите, чтобы увеличить

Есть и требование, общее для всех четырёх вариантов, которое меняется прямо сейчас. 24 июля 2026 года ФСТЭК опубликовала проект приказа на замену № 21: показатель зрелости защиты, оценка до начала обработки, раз в три года и после каждого инцидента, меры для ИИ, контейнеров и API – и отдельные требования к обработчикам [8]. На 24 сентября 2026 года проект не подписан, то есть пока это не действующая норма; подробнее – в статье о требованиях к защите ПДн в 2026 году. Закладывайте ужесточение требований при любом решении: если покупаете – спросите вендора, как он будет их выполнять, если строите – учитывайте их сразу, чтобы не дорабатывать потом.

Посчитаем затраты

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

Начнём с покупки. Готовая или white-label платформа обычно стоит порядка 1,7–6,8 млн ₽ на настройку и лицензию, затем 43–430 тыс. ₽ в месяц в зависимости от масштаба и функций. Возьмём средний случай: 3,4 млн ₽ на старт, потом 260 тыс. ₽ в месяц. За три года одна подписка – 260 тыс. × 36 ≈ 9,4 млн ₽. Вместе с настройкой выходит около 12,8 млн ₽ за три года, при этом продукт работает с первой недели, а бо́льшую часть защиты и поддержки платформы берёт на себя вендор.

Теперь полностью своя сборка. Она обычно стоит 13–43 млн ₽ и больше и требует шести–двенадцати месяцев до запуска. Возьмём консервативный средний случай – 21 млн ₽ и девять месяцев разработки. На этом расходы не заканчиваются: живому клиническому продукту нужны поддержка, обновления безопасности, инфраструктура и дежурства – закладывайте ещё 15–25% стоимости разработки в год, то есть около 4,2 млн ₽ в год, или 350 тыс. ₽ в месяц с момента запуска. Итог за три года: 21 млн + 27 мес. × 350 тыс. ≈ 21 + 9,5 ≈ 30 млн ₽, причём первого пациента вы увидите только на девятом месяце.

На средних числах покупка обходится примерно в 12,8 млн ₽ за три года, своя сборка – примерно в 30 млн ₽, и покупка выглядит очевидным победителем. Для многих продуктов так и есть. Но есть третий параметр – контроль. За 30 млн ₽ вы получаете продукт, который делает ровно то, что нужно вашей клинической вертикали, и который можно развивать как угодно. За 12,8 млн ₽ подписки – продукт, который делает то, что решил вендор. И в тот день, когда он не сможет сделать то, на чём держится ваш бизнес, настоящей ценой окажется уже не подписка, а переписывание продукта.

Гибрид в таких расчётах обычно выигрывает: он убирает самую дорогую статью своей сборки и при этом сохраняет контроль. Поднять и поддерживать собственную видеоинфраструктуру реального времени – медиасерверы, TURN-серверы, масштабирование, постоянную настройку под клиническое видео – одна из самых тяжёлых задач при разработке с нуля. Аренда превращает эти капитальные затраты в счёт за минуты участников или пакеты минут. Публичные прайсы есть не у всех, ставку берите из коммерческого предложения. Для порядка величины: при условной ставке 0,34 ₽ за минуту-участника 5 000 консультаций по 20 минут вдвоём (200 000 минут-участников) обойдутся примерно в 68 тыс. ₽ в месяц. Гибрид может стоить, скажем, 13 млн ₽ на разработку продукта поверх арендованного видеослоя (около четырёх месяцев) плюс видеослой и базовая поддержка – в нашей модели около 130 тыс. ₽ в месяц после запуска. За три года: 13 млн + 32 мес. × 130 тыс. ≈ 13 + 4,2 ≈ 17 млн ₽. Это заметно меньше 30 млн ₽ за свою сборку, а клинический контроль остаётся у вас.

Нажмите, чтобы увеличить

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

Видеослой: отдельное решение внутри общего

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

При аренде вы вызываете API, а медиасерверы, через которые идёт звонок, держит вендор. Для телемедицины здесь важен не удобный SDK, а медиа и записи в России и готовность вендора работать по поручению. Варианты на рынке (без рейтинга): облачные видео-SDK и API – Voximplant и SaluteJazz SDK; сервер вендора в вашем контуре – TrueConf Server с VideoSDK; ВКС со ссылками через API – VK Звонки и Яндекс Телемост [10], где ЕСИА, протокол и хранение материалов остаются на вас. Где обрабатываются медиа, подпишет ли вендор поручение и сколько это стоит, уточняйте письменно: открытая документация на эти вопросы не отвечает. Зарубежные видео-API в короткий список не попадают: медиа и записи ушли бы за рубеж.

Альтернатива аренде – самим развернуть open-source медиасервер (mediasoup, Janus, LiveKit, Jitsi) в российском облаке. Это полный контроль и никакой поминутной платы, но эксплуатация и все меры защиты медиатрафика – на вас. Подробное сравнение, где на первом месте требования к данным, – в статье свой или CPaaS: видеослой, а инженерные компромиссы конкретных серверов для самостоятельного развёртывания разобраны в курсе Video Streaming, в сравнении SFU.

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

Российский фильтр для готового решения

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

1. Данные. Базы и записи – в России (ст. 18 ч. 5 152-ФЗ); вендор подписывает поручение по ст. 6 ч. 3 и раскрывает своих подрядчиков – облако, SMS, почту.
2. ЕСИА. Участники консультации идентифицируются через ЕСИА (ч. 6 ст. 36.2 323-ФЗ, п. 7 приказа 193н) [4][5]; Sber ID или VK ID удобны, но ЕСИА не заменяют.
3. Подпись и ЕГИСЗ. Документация подписывается УКЭП медработника (ч. 7 ст. 36.2); врач – в ФРМР, организация – в ФРМО (п. 9 193н); запрос на консультацию и протокол уходят в ЕГИСЗ в течение одного рабочего дня [11] – самой платформой или через вашу МИС.
4. Раскрытие и хранение. Платформа даёт разместить сведения по п. 37 193н – лицензию, данные консультанта, оператора ИС и место хранения материалов, стоимость – и хранит сопутствующие материалы (аудио, видео, сообщения) один год (п. 49–51) [5].
5. Реестр российского ПО – для госзаказчиков. В государственных и муниципальных закупках действуют ограничения на иностранное ПО, а российское происхождение подтверждается записью в едином реестре российских программ для ЭВМ и баз данных; на значимых объектах КИИ закон требует российское ПО и ПАК (58-ФЗ) [12]. Если продаёте госклиникам, проверьте платформу в реестре, если строите своё – заложите в план включение в реестр.
6. Выход. Выгрузка данных и записей в открытом формате при расторжении договора. Опыт 2022–2024 годов показателен: с 20 марта 2024 года крупнейшие зарубежные облака перестали обслуживать корпоративных клиентов из России [13], и команды, намертво привязавшие продукт к чужой платформе, переезжали в спешке.

Если платформа проходит все шесть проверок и решает вашу клиническую задачу, покупайте. Если нет – ответ тоже получен.

Сравнение вариантов

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

Стоимость, сроки и ответственность растут вместе с контролем. Варианта без компромиссов нет, вопрос лишь в том, какой компромисс подходит вашему продукту.

Три самые дорогие ошибки

Первая и самая дорогая – принять бытовой инструмент за клинический. Команда берёт знакомый мессенджер или бесплатную ВКС, потому что «там всё зашифровано», встраивает его в клинический процесс и лишь потом узнаёт: поручения нет, где лежат данные – неизвестно, идентификации через ЕСИА нет, протокола с подписью врача нет. Шифрование не означает соответствия требованиям, а видеозвонок – ещё не телемедицинская консультация. Прежде чем инструмент получит доступ к данным пациента, ответьте на вопрос: подтверждены ли письменно поручение и размещение данных в России для этого сценария? Если нет, качество продукта уже не важно.

Вторая – считать, что в гибриде одно поручение покрывает весь стек. Команда подписывает договор с видеовендором и забывает, что хостинг базы, файловое хранилище, трекер ошибок, аналитика и SMS-шлюз тоже видят медданные. Каждый такой сервис должен входить в цепочку поручений и размещаться в России. Один неучтённый инструмент – скрипт аналитики с идентификатором пациента или зарубежный сервис отчётов о сбоях со скриншотом, где видно ФИО, – это утечка, которую рано или поздно обнаружат, и заодно трансграничная передача спецкатегории ПДн. За утечку данных о здоровье юрлицу грозит 10–15 млн ₽ по ст. 13.11 КоАП, за повторную – оборотный штраф [14]. В гибриде зона ответственности – это все сервисы, которые видят медданные, а не только видеовендор.

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

Как принять решение

Ответьте на вопросы по порядку: часто решение становится ясным уже на первых из них.

Первый: решает ли готовая платформа вашу клиническую задачу и проходит ли российский фильтр? Если ваш продукт – довольно стандартная консультация «врач – пациент», а готовое решение покрывает правила вашей вертикали, ЕСИА, подпись и ЕГИСЗ, покупка – самый быстрый и дешёвый разумный выбор; изучите рынок, прежде чем строить своё. Если платформа не умеет главного, ради чего задуман продукт, покупка – ловушка, и ответ у вас уже есть.

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

Третий: какой масштаб и какие ограничения есть на старте? Свой медиастек окупается при большом предсказуемом объёме или там, где договор с заказчиком либо требования к значимому объекту КИИ вынуждают держать медиа у себя. Если ни одно из условий пока не выполняется, начните с гибрида и перенесите видеослой к себе позже: чёткая граница между продуктом и арендованным слоем сохраняет такую возможность.

Четвёртый, сквозной: какую ответственность за медданные вы потянете сегодня? Каждый шаг вправо расширяет зону ответственности по 152-ФЗ и 323-ФЗ: модель угроз, меры по ПП 1119 и приказу ФСТЭК № 21, цепочка поручений, ответственный за организацию обработки ПДн. Трезво оцените, какие юристы, специалисты по ИБ и инженеры есть у вас сейчас. Лучше купить готовое или выбрать гибрид и отвечать за небольшую, хорошо управляемую зону, чем построить всё самим и отвечать за большую, которую некому закрыть.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Фора Софт разрабатывает ПО с видео в реальном времени с 2005 года – видеоконференции, стриминг, видеонаблюдение, e-learning и телемедицину, – поэтому мы помогаем командам выбирать между своим и покупным осознанно. С учётом требований к данным наш совет неизменен: арендуйте трудную инфраструктуру там, где вендор держит медиа в России, работает по поручению и берёт на себя эксплуатацию, а бюджет тратьте на клинический продукт и интеграции – ЕСИА, МИС, ЕГИСЗ, – которые и отличают вас от конкурентов. Чаще всего мы работаем по гибридной схеме: свой клинический продукт на российском видеослое в архитектуре, которая выдерживает проверку по 152-ФЗ и 323-ФЗ. Для большинства телемед-команд это лучшее сочетание контроля и цены. Полностью своя сборка оправдана, только когда у неё есть конкретная причина, а не привычка всё делать самим.

Главное

• У выбора «свой или покупной» четыре варианта: готовая платформа, white-label, гибрид и полностью своя сборка.
• Чем ближе к своей сборке, тем больше контроля над клиническим продуктом, но и больше затрат, времени и обязанностей по 152-ФЗ.
• Ответственность за медданные – неочевидный, но решающий параметр: каждый вариант по-своему делит работу между вашими мерами защиты и поручениями вендорам.
• У вендора либо есть письменно подтверждённые поручение и хранение данных в России, либо нет; шифрование само по себе соответствия требованиям не даёт.
• Готовую платформу проверяйте российским фильтром: ЕСИА, УКЭП, ЕГИСЗ, п. 37 193н, реестр российского ПО для госзаказчиков, выход с данными.
• Гибрид на российском видеослое – разумный выбор по умолчанию; свой медиастек нужен, только если видео и есть ваш продукт или этого требуют масштаб либо заказчик.

Что читать дальше

• Модель стоимости телемед-платформы – подробный расчёт, на котором основано это решение.
• Свой или CPaaS: видеослой на mediasoup/Janus/LiveKit или готовое решение – отдельное решение по видеослою.
• Архитектура комплаенса по 152-ФЗ и 323-ФЗ – как встроить требования в то, что вы строите.