Объём работ и оценка телемед-проекта

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

Кратко

Оценка телемед-проекта – не одно число из прайса. Это базовый объём функций, умноженный на два коэффициента, которые команды забывают заложить: насколько чувствительны данные пациента и сколько внешних систем придётся подключить. Сначала выпишите функции и отнесите каждую к малому, среднему или крупному объёму. Затем примените множитель по уровню комплаенса – защита медданных по 152-ФЗ и 323-ФЗ: меры по ПП 1119 и приказу ФСТЭК № 21, базы в России, поручения подрядчикам – и множитель интеграций: каждое подключение к МИС, ЕГИСЗ, ЕСИА, лаборатории, электронному рецепту или кассе добавляет работу уровня средней функции. Без интеграций телемедконсультация в России не обходится: идентификация через ЕСИА и обмен с ЕГИСЗ обязательны. Реалистичная первая версия с защитой медданных – это шесть–девять месяцев разработки, а не MVP за выходные: сроки определяют защита данных и интеграции, а не видеозвонок. В статье – карта «функция → объём», оба множителя, пример расчёта в рублях и одностраничный лист, который поможет превратить идею в обоснованный объём работ до утверждения бюджета.

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

Большинство телемед-проектов, вышедших за бюджет, ошиблись не в видеозвонке, а во всём, что его окружает. Основатель оценивает «приложение для видеосвязи врача с пациентом», подрядчик считает видео, а через четыре месяца выясняется, что видео было лёгкими 20%, а защита медданных, ЕСИА, подпись врача и обмен с МИС и ЕГИСЗ – теми 80%, которые никто не включил в объём работ. Статья – для основателя, продакт-менеджера или руководителя медорганизации, которым нужно превратить идею в объём работ и реалистичную оценку: число для совета директоров, инвестора или подрядчика. Точность до рубля здесь не нужна. Важно заложить два множителя, которые незаметно удваивают наивную оценку, чтобы число, под которым вы подписываетесь, совпало с реальной стоимостью проекта.

Сначала объём работ, потом оценка

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

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

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

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

Уравнение оценки

Весь метод умещается в одну строку, дальше разберём каждую часть:

Оценка = (базовый объём функций) × (множитель комплаенса) × (множитель интеграций)

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

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

Шаг первый: карта «функция → объём»

Выпишите все функции простым языком и отнесите каждую к одной из трёх категорий объёма. Часы пока не считайте: задача – определить относительный вес, чтобы было честно видно, где основная работа. Удобная шкала – малый (S), средний (M) и крупный (L) объём, где каждая следующая ступень примерно в три-четыре раза тяжелее предыдущей.

Таблица ниже раскладывает функции типичного телемед-продукта по категориям. Это шаблон для старта, а не прайс: в вашем продукте одни строки добавятся, другие уйдут.

Две строки нужно выделить особо: их регулярно недооценивают. Запись – крупная, а не средняя функция: записанная сессия – это медданные, которые нужно хранить в России и в зашифрованном виде, держать установленный срок (сопутствующие материалы телемедконсультации – один год по п. 49–51 приказа 193н [3]), выдавать под контролем доступа и сверять с согласием пациента; сама камера – лёгкая часть. Платежи и ДМС – тоже крупная: «принять карту и пробить чек» – средняя функция, а работа со страховщиком ДМС – гарантийные письма, реестры, счета и сверки по договору – крупная, со своими договорами и форматами обмена.

Сложите объёмы – получится базовый объём функций, первый сомножитель уравнения. Два множителя превращают эту базу в реальную оценку.

Шаг второй: множитель по уровню комплаенса

Этот множитель команды обнаруживают слишком поздно. Правовая основа у всех телемед-продуктов в России, работающих с данными пациента, одна: сведения о здоровье – специальная категория персональных данных (ст. 10 152-ФЗ), а факт обращения, состояние здоровья и диагноз – врачебная тайна (ст. 13 323-ФЗ) [1]. Защиту медданных нельзя добавить в конце как отдельную функцию: это надбавка к каждой функции, которая касается медданных. Каждую такую функцию нужно закрыть управлением доступом, журналировать и защитить мерами, которые ПП 1119 и приказ ФСТЭК № 21 задают для вашего уровня защищённости [4][5], а каждому внешнему сервису, который видит данные, нужны поручение и размещение в России (ст. 6 и ст. 18 ч. 5 152-ФЗ). Телемедицина добавляет свои обязательные требования: идентификацию участников через ЕСИА и документирование с УКЭП медработника (ч. 6–7 ст. 36.2 323-ФЗ) [2]. Всё это обязательно, и всё это – инженерная работа.

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

Уровень 1 – видео поверх МИС клиники (множитель ≈ 1,3×). Продукт проводит консультацию и почти ничего не хранит сам: заключение с УКЭП врача и материалы уходят в МИС клиники, видео не записывается, рецептов нет. Работа есть, но её объём ограничен: ЕСИА, согласие на обработку отдельным документом (с 1 сентября 2025 года) [14], базы в России, модель угроз и меры для вашего уровня защищённости, журналы событий, поручение видеовендору.

Уровень 2 – стандартная клиника (множитель ≈ 1,6×). Продукт сам хранит протоколы и заключения, записи консультаций и историю пациента. Мер становится больше: сроки хранения материалов, электронные медицинские документы по правилам приказа 209н, обмен с ЕГИСЗ (запрос на консультацию и протокол – в течение одного рабочего дня) [7], управление согласиями, обезличивание для аналитики, поручение каждому подрядчику в потоке данных. Сюда попадает большинство реальных телемед-продуктов.

Уровень 3 – рецепты, особые данные или государственный заказчик (множитель ≈ 2,0× и выше). Продукт выписывает электронные рецепты – по приказу 1094н, с УКЭП и подключением организации к ГИС субъекта [8], а после телемедконсультации только в рамках коррекции лечения, назначенного на очном приёме (п. 38–39 193н); для наркотических и психотропных препаратов – особые правила. Или работает с психиатрией и наркологией, где цена ошибки выше. Или продаётся государственным клиникам, где МИС защищаются по приказу ФСТЭК № 117 (с 1 марта 2026 года) [6], а здравоохранение относится к сферам критической информационной инфраструктуры. Каждый из этих факторов добавляет инженерную, документальную и юридическую работу сверх уровня 2.

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

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

Уровень, а с ним и объём работ, может измениться и без роста чувствительности данных – из-за ИИ-функций, которые интерпретируют клинические данные. Подсказка врачу – одно дело; программа, которая сама анализирует данные для диагностики, может оказаться медицинским изделием с регистрацией в Росздравнадзоре по ПП 1684, а ПО с ИИ по классификации приказа Минздрава 4н от 06.06.2012 относится к классу риска 3 [9]. В отложенных телемедконсультациях системы поддержки принятия врачебных решений на основе ИИ допускаются, только если они зарегистрированы как медизделия (п. 15–17 193н). А одна граница проходит не по объёму работ, а по закону: поставить диагноз дистанционно без очного приёма нельзя (п. 40 193н), так что функция «ИИ ставит пациенту диагноз онлайн» в российский продукт не входит. Где проходит эта граница, разбирает статья о том, где ИИ встраивается в телемед-продукт.

Шаг третий: множитель числа интеграций

Второй множитель удивляет даже опытные команды: каждая внешняя система добавляет работу примерно уровня средней функции, и эта работа накапливается. Телемед-продукт редко работает сам по себе. Он подключается к МИС клиники, чтобы визиты попадали в медкарту; к ЕГИСЗ – напрямую, через МИС, региональную систему или интеграционную платформу, – чтобы запросы, протоколы и документы регистрировались в федеральных подсистемах; к ЕСИА для идентификации; к лабораториям за результатами; к региональной системе для электронных рецептов; к эквайрингу и онлайн-кассе, чтобы оплата шла с чеком по 54-ФЗ. Главная особенность российских проектов: телемедконсультации без интеграций не бывает. ЕСИА обязательна по закону, а частные медорганизации – поставщики сведений в ЕГИСЗ наравне с государственными (п. 44 «к» Положения о ЕГИСЗ) [7].

Каждое подключение – отдельный небольшой проект. Даже когда есть стандарт – структурированные электронные медицинские документы ЕГИСЗ (СЭМД) описаны в XML на базе HL7 CDA R2, интеграционные платформы вроде N3.Health работают по HL7 FHIR [10], – вам всё равно нужно сопоставить свои данные с форматом, получить доступ у владельца системы, пройти тестирование и учесть особенности. Стандарт сокращает работу, но не отменяет её. Кроме того, интеграции накапливаются: каждой нужны поддержка, мониторинг и договорённость об обмене данными, поэтому три интеграции обходятся заметно дороже, чем одна, умноженная на три.

Простое правило для оценки: посчитайте обязательные интеграции, добавьте по средней функции за каждую, а за каждую сверх второй – чуть больше, с учётом накапливающейся поддержки и координации. Велнес-приложение без медпомощи и внешних систем имеет множитель 1,0×; телемедконсультация с минимальным набором – ЕСИА и обмен с ЕГИСЗ через МИС клиники – плюс оплата с кассой даёт около 1,4–1,6×; больничная платформа с полудюжиной систем – 2,0× и выше.

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

Множитель зависит и от способа подключения. Прямая интеграция с каждой системой – самый трудоёмкий путь. Подключение через МИС клиники или интеграционную платформу, уже связанную с ЕГИСЗ и множеством МИС (N3.Health, МедФлекс) [10], заменяет собственную разработку подпиской, но и контроля у вас становится меньше. Это решение заметно влияет на объём работ: гид по решению об интеграции разбирает варианты, чтобы вы выбрали подходящий для своего числа интеграций.

Пример расчёта

Разберём метод на круглых плановых числах. Важно соотношение, а реальные цифры вы подставите свои.

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

Теперь множитель комплаенса. Продукт сам хранит протоколы и ведёт документацию визита – значит, уровень 2, множитель ≈ 1,6×. Умножаем: 9 × 1,6 = 14,4 инженер-месяца. Разница в 5,4 месяца – не бюрократия, а меры защиты, журналы, согласия, сроки хранения, подпись УКЭП и поручения подрядчикам, которых требуют хранимые медданные.

Теперь множитель интеграций. Продукт идентифицирует пациентов через ЕСИА, передаёт визиты в МИС клиники (а через неё – в ЕГИСЗ) и принимает оплату с онлайн-кассой – три интеграции, множитель около 1,5×. Умножаем: 14,4 × 1,5 ≈ 22 инженер-месяца. Это и есть реальный объём вместо 9 месяцев, с которых начали: два множителя увеличили наивную оценку почти в два с половиной раза. Проекты, которые назвали 9 и обнаружили 22 посреди разработки, – ровно та история, ради которой написана эта статья.

Чтобы увидеть порядок в деньгах, возьмём ориентир из модели стоимости: средняя ставка подрядчика по команде ≈ 4 700 ₽ в час и 160 часов в инженер-месяце, то есть около 750 тыс. ₽ за инженер-месяц [15]. Наивная оценка: 9 × 160 × 4 700 ≈ 6,8 млн ₽. Реальная: 22 × 160 × 4 700 ≈ 16,5 млн ₽ – и это ещё без внешних расходов на защиту (средства защиты информации, оценка эффективности мер, пентест), которые модель стоимости считает отдельной строкой. Ставка – ориентир модели, а не рыночная статистика: подставьте ставку своего подрядчика или стоимость своей команды, а лист в конце статьи поможет провести собственный расчёт.

Почему на это уходит шесть–девять месяцев

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

Разработка проходит узнаваемые фазы. Первой идёт анализ и определение объёма работ (то, чему посвящена эта статья): превратить идею в карту функций, уровень и число интеграций. Следом – основная разработка: функции и арендованный видеослой. Защита ПДн и обязательные интеграции идут параллельно с ней и продолжаются после: модель угроз и уровень защищённости, организационно-распорядительные документы, поручения и согласия, оценка эффективности мер, подключение к ЕСИА и ЕГИСЗ по процедурам владельцев этих систем. Это календарное время, которое не сократить числом инженеров, и именно эту фазу команды чаще всего забывают поставить в план. Одновременно клиника готовит свою часть: телемедицина оказывается только по работам и услугам из её лицензии (п. 4 193н), врачи должны быть в ФРМР, организация – в ФРМО (п. 9), у врачей должны быть сертификаты УКЭП [3]. Это не ваш код, но ваш календарь: без этого пилот не начнётся. Затем – пилот с реальными врачами и небольшой группой пациентов: технический запуск – лёгкая половина, а сюрпризы в работе врача всплывают только при реальном использовании. И только потом – запуск.

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

Ещё один фактор нужно учитывать в любом телемед-проекте, потому что он определяет, что вообще стоит строить: правила оплаты. Программа госгарантий на 2026–2028 годы (ПП № 2188) предусматривает в тарифных соглашениях отдельный тариф на телемедицину «врач – врач» и «врач – пациент», а дистанционное наблюдение за пациентами с артериальной гипертензией и сахарным диабетом входит в базовую программу ОМС [11]. С 1 сентября 2026 года действуют новые правила платных медуслуг (ПП № 659), прямо разрешающие заключать договор дистанционно на сайте или в приложении клиники [12]. А экспериментальный правовой режим по телемедицине (ПП № 1164), где участникам разрешено больше, установлен на три года с 1 августа 2023 года, и его продление после августа 2026 года в открытых источниках не подтверждено [13]. От правил оплаты зависит, какие функции приносят деньги, поэтому объём работ, построенный вокруг режима, который может закончиться посреди проекта, находится под риском. Указывайте год, отмечайте сроки действия и пересматривайте план; как правила оплаты влияют на продукт, разбирает статья об оплате телемедицины: ОМС, ДМС и платные услуги.

Частая ошибка: оценить функции и забыть о множителях

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

Смежная ловушка – считать, что «зашифровано» значит «соответствует». Шифрование необходимо, но недостаточно. Если в плане стоит бесплатный зарубежный сервис аналитики или рассылок, потому что он «безопасный», этот сервис придётся исключить: хранить медданные в зарубежных базах запрещено, а отправка туда – трансграничная передача специальной категории (ст. 12 152-ФЗ). Российская замена с поручением меняет архитектуру и в любом случае меняет оценку. Закладывайте в объём работ цепочку поручений и размещение данных, а не только шифрование.

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

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

Главное

• Оценка = базовый объём функций × множитель комплаенса × множитель интеграций; называть только базу – классическая ошибка.
• Сначала разметьте функции по S/M/L; запись и работа со страховщиками ДМС – крупные, а не средние.
• Множитель комплаенса – от ≈ 1,3× (видео поверх МИС клиники) до 2,0×+ (рецепты, особые данные, госзаказчик).
• Каждая интеграция добавляет примерно одну среднюю функцию, а после второй затраты накапливаются; ЕСИА и ЕГИСЗ для телемедконсультации – обязательный минимум.
• Пример расчёта: 9 инженер-месяцев превращаются в 22, а ≈ 6,8 млн ₽ – в ≈ 16,5 млн ₽ по ставке-ориентиру.
• Реалистичная первая версия – шесть–девять месяцев; защита ПДн с интеграциями и пилот с врачами – полноценные фазы, а «добавим потом» предшествует большинству переделок.

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

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