Синхронная, асинхронная помощь и удалённый мониторинг – три продукта, три архитектуры

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

Кратко

Приказ Минздрава 193н называет три способа оказывать помощь дистанционно: консультацию в режиме реального времени (живой видео- или аудиоразговор), отложенную консультацию (консультант изучает документы и данные позже, без прямого общения) и дистанционное наблюдение за состоянием здоровья, когда показания медицинских изделий или ручной ввод пациента поступают постоянно. Правовая рамка у всех трёх одна – ст. 36.2 323-ФЗ, приказ 193н, 152-ФЗ и врачебная тайна: данные каждого способа – сведения о здоровье, специальная категория персональных данных. Дальше сходство кончается: допустимая задержка – от миллисекунд до суток, данные идут по разным конвейерам, а ОМС оплачивает телемедицинские консультации и дистанционное наблюдение при артериальной гипертензии и сахарном диабете по разным строкам программы госгарантий. Считайте их тремя продуктами с тремя архитектурами: команды, которые видят один продукт, ошибаются в оценке всех трёх.

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

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

Три способа – три шкалы времени

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

Синхронная телемедицина – консультация в режиме реального времени: лечащий врач и (или) пациент либо его законный представитель непосредственно взаимодействуют с консультантом (193н, п. 16) [2]. Канал связи приказ не фиксирует – на практике это видео или аудио. Время здесь измеряется миллисекундами: если задержка между сторонами превышает долю секунды, разговор разваливается. Плановая видеоконсультация для оценки эффективности лечения, консилиум районной больницы с федеральным центром, консультация невролога при подозрении на инсульт – всё это синхронный формат. Бытовая аналогия: телефонный звонок, во время которого идёт клинический приём.

Асинхронная телемедицина – в терминах 193н отложенная консультация (в англоязычной литературе – store-and-forward, «сохрани и перешли») – разводит стороны во времени. Консультант изучает медицинские документы и данные о состоянии здоровья, в том числе данные дистанционного наблюдения, и оформляет заключение без прямого общения с врачом или пациентом (п. 17) [2]. Материал собирают сейчас: снимки КТ для второго мнения, фотографию кожного образования, результаты анализов. Разбирают через часы. Аналогия: заказное письмо с фотографиями к специалисту с гарантированным сроком ответа.

Дистанционное наблюдение (в англоязычной литературе – remote patient monitoring, RPM) обходится без приёма как такового. Его назначает лечащий врач после очного приёма и установления диагноза (ч. 4 ст. 36.2 323-ФЗ; 193н, п. 43) [1][2]. Тонометр, глюкометр или пульсоксиметр дома у пациента передаёт показания автоматически – или пациент вносит их вручную; врач задаёт индивидуальные предельные значения, а система следит за трендами и отклонениями (п. 45–46). Записи на приём нет; продукт – это конвейер, который работает круглосуточно. Аналогия: дымовой датчик, выведенный прямо на пульт пожарной части, вместо ежегодной проверки.

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

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

Синхронный формат: архитектура разговора

У синхронного продукта одна задача: поддерживать естественный разговор двух или более людей, хотя сеть делает всё, чтобы его сорвать. Архитектура – стек реального времени, который блок 3 курса разбирает подробно. Это браузерный стандарт WebRTC, сигнальный сервис для установления звонка, релейные серверы TURN для сетей, где прямое соединение запрещено, и медиасервер SFU, как только участников больше двух. Устройство протоколов разобрано в курсе по стримингу (разбор WebRTC); здесь важна общая схема: медиа непрерывно идёт в обе стороны, и каждый компонент должен уложиться в бюджет задержки.

Бюджет задержки жёсткий. Международная рекомендация ITU-T G.114 советует держать одностороннюю задержку до 150 мс для естественного разговора и считает 400 мс потолком планирования, за которым интерактивность деградирует [3]. На практике для телемедицинского звонка ориентир – несколько сотен миллисекунд от камеры пациента до экрана врача. Ни одному звену конвейера нельзя «задуматься»: никаких пакетных шагов, очередей и ночных заданий. Деньги здесь уходят в надёжность, а не в новые функции: сорвавшийся клинический звонок – уже клиническое событие.

Регуляторная рамка вписана прямо в архитектуру. Консультация «врач – пациент» допустима только для профилактики, сбора жалоб и анамнеза, оценки эффективности лечения и наблюдения, а также для решения, нужен ли очный приём (ч. 2 ст. 36.2) [1]. Поставить диагноз дистанционно нельзя: если очного приёма не было, заключение может содержать только рекомендации по обследованию перед ним (193н, п. 40) [2]. Скорректировать лечение и выписать электронный рецепт можно, лишь если диагноз поставлен и лечение назначено лечащим врачом на очном приёме по данному обращению (п. 38–39). Читайте это как требование к продукту: экран консультации должен знать, был ли очный приём и какой диагноз на нём поставлен, и только в этом случае включать кнопки «скорректировать лечение» и «выписать рецепт».

Вокруг разговора – обязательная обвязка. Участники идентифицируются через ЕСИА (п. 7), врач должен быть в ФРМР, медорганизация – в ФРМО (п. 9), документы подписываются усиленной квалифицированной электронной подписью медработника, УКЭП (ч. 7 ст. 36.2) [1][2]. Запрос на консультацию и её протокол передаются в подсистему ЕГИСЗ «Федеральная электронная регистратура» (ФЭР) в течение одного рабочего дня [7]. У консультаций есть и сроки: в экстренной форме – от 30 минут до 2 часов с момента запроса, в неотложной – от 3 до 24 часов, в плановой – по срокам программы госгарантий (п. 18–20) [2]. Для синхронного продукта «от 30 минут» означает дежурного консультанта, маршрутизацию и таймер, а не свободный слот в расписании. Как эти правила превращаются в деньги, разбирает статья об оплате телемедицины.

Асинхронный формат: архитектура очереди

У продукта отложенных консультаций задача другая: хорошо собрать клиническую информацию, безопасно сохранить и провести через очередь разбора в срок. Конвейер: сбор → валидация → шифрование и хранение → очередь → разбор консультантом → заключение. Ни у одного компонента нет ограничения реального времени; у каждого есть ограничение целостности. Главное смещается из сети в данные: проверка качества снимка прямо при съёмке (смазанное фото, замеченное только при разборе, стоит суток), шифрование с первого байта, пригодный для аудита журнал «кто что смотрел» и правила хранения для архива, который растёт годами.

Качество съёмки – клиническое требование. Систематический обзор и метаанализ теледерматологии 2026 года показал совпадение диагнозов с очным осмотром около 76% по кожным заболеваниям, а дермоскопия (стандартизованная насадка для макросъёмки) подняла совпадение при раке кожи с 67% до 80% [5]. Для инженеров это значит: пошаговые подсказки при съёмке, автоматические проверки резкости и экспозиции, минимальное разрешение – клинические функции, а не косметика интерфейса. Подробнее – в статье о визуальных консультациях.

Российская специфика меняет саму модель бизнеса. Схема «пришлите фото – получите диагноз и рецепт» здесь не работает: без очного приёма заключение не содержит диагноза (п. 40), а рецепт возможен только как коррекция лечения после очного приёма по тому же обращению (п. 38–39) [2]. Поэтому асинхронный продукт логично строить там, где очный этап уже был или не нужен пациенту напрямую: второе мнение и консилиумы «врач – врач», расшифровка исследований, контроль заживления после очного приёма. Здесь же 193н даёт отложенному режиму уникальную возможность: использовать системы поддержки принятия врачебных решений (СППВР), если они зарегистрированы как медицинские изделия (п. 17) [2]. ИИ-модуль в очереди разбора должен быть зарегистрирован как медизделие, а программное обеспечение с ИИ по классификации Минздрава всегда относится к классу риска 3 [10].

Сроки 193н превращаются в техническое задание. «От 3 до 24 часов с момента поступления запроса» для неотложной консультации – это SLA очереди, который система обязана измерять: момент запроса, момент, когда документация собрана полностью, момент подписи заключения. ПГГ отдельно поручает страховым медицинским организациям (СМО) контролировать сроки консультаций [4] – значит, метки времени должны быть частью модели данных, а не записями в логах.

Асинхронные продукты существуют ради экономики. Живая консультация съедает время врача фиксированными слотами расписания; очередь разбора – минутами, в удобное врачу время и без риска неявки. При 5 минутах на кейс один врач-час разбирает около 12 кейсов; тот же час вмещает две, от силы три плановые видеоконсультации. Именно эта разница в пропускной способности, а не счёт за инфраструктуру, оправдывает такой продукт. Где асинхронные модели находят покупателя – в B2B-сегменте «врач – врач», в ДМС или в платных услугах, – разбирает статья о ландшафте продуктов.

Дистанционное наблюдение: архитектура конвейера

У продукта дистанционного наблюдения третья задача: управлять парком медицинских изделий у пациентов дома и вовремя превращать их показания в клинические действия, не заваливая медицинскую команду оповещениями. Конвейер: изделие → радиоканал ближнего действия (обычно Bluetooth Low Energy) или встроенный сотовый модем → шлюз (приложение на телефоне пациента или отдельный хаб) → API приёма → хранилище временных рядов → движок правил → оповещения и дашборд команды. Стек стандартов существует, и им стоит пользоваться: семейство ISO/IEEE 11073 для персональных медицинских устройств задаёт модель данных, профили Bluetooth SIG переносят её по BLE, а руководство HL7 FHIR Personal Health Device описывает, как отображать показания в ресурсы FHIR Observation [6].

Три нормы 193н формируют весь продукт. Первая – основание: наблюдение назначает лечащий врач после очного приёма и установления диагноза, он же определяет программу и порядок наблюдения (п. 43–44) [2]. Значит, запись о включении пациента в программу должна ссылаться на очный приём и диагноз: это обязательная ссылка (внешний ключ), а не поле «комментарий». Вторая – источник данных: показания поступают автоматически с медицинских изделий, которые умеют передавать данные, либо вносятся вручную, в том числе с приборов без передачи данных (п. 45). Ручной ввод разрешён, но врачу важно видеть, откуда число: каждое показание несёт метку источника – прибор, ручной ввод, исправление. Третья – пороги и реагирование: предельные значения задаются индивидуально, а при критическом отклонении предусмотрено экстренное реагирование (п. 46). Пороги – это врачебное назначение конкретному пациенту с историей версий, а не глобальная настройка; у оповещения должен быть дежурный получатель и порядок эскалации.

Вести наблюдение можно в ЕГИСЗ, в региональной ГИС, в медицинской или иной информационной системе (п. 45) [2]. Для государственных клиник это значит соседство с региональными решениями: в ЕЦП.МИС, например, есть модуль «Дистанционный мониторинг» [13]. Вопрос «строить свой конвейер или встраиваться в региональный» решается до первой строки кода.

Деньги в этом способе тоже свои. Программа госгарантий на 2026–2028 годы (ПП 2188) включила дистанционное наблюдение за пациентами с артериальной гипертензией (АГ) и сахарным диабетом (СД) в базовую программу ОМС [4]. Средний норматив стоимости единицы на 2026 год – 1 108,4 ₽, при СД – 3 651,7 ₽, при АГ – 964 ₽; единица учёта – комплексное посещение. Медицинские изделия можно оплатить из бюджета или за счёт пациента. Как именно считаются единицы в вашем регионе, задаёт тарифное соглашение, – поэтому правила учёта держите в конфигурации, а данные для реестра счетов (кто, за какой период, какие показания пришли, как отреагировал врач) – в схеме с первой миграции.

Важно и то, что считать медизделием. Фитнес-браслет – не медицинское изделие, и страховщики ДМС почти не используют носимые устройства как раз потому, что большинство из них не зарегистрированы как медизделия [12]. Клиническая сторона наблюдения – процессы команды, дизайн оповещений – тема статьи о ведении хронических заболеваний; машинное обучение на потоке показаний – в статье об обнаружении аномалий.

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

Одна правовая рамка, три зоны риска

На все три способа распространяются одни и те же законы. Показания, фотографии и видеопоток – сведения о здоровье, специальная категория персональных данных (ст. 10 152-ФЗ), и одновременно врачебная тайна: по ст. 13 323-ФЗ её составляет уже сам факт обращения [8][9]. Базы с персональными данными граждан России должны находиться в России (ст. 18 ч. 5 152-ФЗ), меры защиты определяют ст. 19, ПП 1119 и приказ ФСТЭК № 21. Каждому подрядчику, который работает с данными, нужно поручение обработки – договор, по которому он обрабатывает данные в целях клиники и отвечает перед ней (ст. 6 ч. 3–5). Как его оформить, разбирает статья о поручении обработки, а общую рамку – 152-ФЗ и врачебная тайна простым языком.

Различается то, где сосредоточен риск. В синхронном режиме это передача и запись: медиа шифруется DTLS-SRTP, а записывать ли сессии вообще – отдельное взвешенное решение; если запись сделана, 193н требует хранить такие сопутствующие материалы один год (п. 49–51) [2]. В асинхронном – хранение: архив диагностических изображений, который копится годами, – именно то, что ценно для злоумышленников; за утечку данных о здоровье юрлицу грозит 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП) [11]. В наблюдении риск сосредоточен в цепочке поставки: изделие, приложение на телефоне, сотовый оператор и облако производителя. Если облако производителя стоит за рубежом, показания пациентов уходят туда в обход локализации – каждое звено цепочки нужно проверить до закупки парка. Рамка одна, а соблюдать её приходится в трёх разных местах.

Пример расчёта: одна клиника, три центра затрат

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

Синхронный: затраты – это медиапуть (и инженерия вокруг него). Видеоконсультация WebRTC в 720p идёт примерно на 1,2 Мбит/с в каждую сторону. 20-минутная консультация – 1 200 секунд: 1,2 Мбит/с × 1 200 с = 1 440 мегабит ≈ 180 МБ отправлено каждым участником и столько же получено. Через SFU сервер ретранслирует потоки обоих: примерно 4 × 180 МБ ≈ 0,7 ГБ серверного трафика на консультацию, около 720 ГБ на 1 000 консультаций. По типичным ценам российских облаков на исходящий трафик это порядка нескольких тысяч рублей в месяц. На готовом видео-API при ставке порядка 0,34 ₽ за минуту участника выходит 2 × 20 × 0,34 ≈ 14 ₽ за консультацию, ≈ 14 тыс. ₽ в месяц. Дёшево в обоих случаях: основные деньги в синхронном продукте уходят в надёжность (ёмкость TURN, переподключение, мониторинг), и их считает статья о модели стоимости.

Асинхронный: затраты – пропускная способность врача. 1 000 кейсов × 4 фото × 5 МБ = 20 ГБ новых изображений в месяц. Шифрованное объектное хранилище порядка 2 ₽ за ГБ в месяц – это около 40 ₽ в месяц. Сроки хранения зависят от типа материала: сопутствующие изображения 193н велит хранить год, медицинскую документацию – по срокам из справочника НСИ (209н). Возьмём с запасом 5 лет: 20 ГБ × 60 месяцев = 1,2 ТБ, около 2 400 ₽ в месяц за полностью накопленный архив. Инфраструктура почти бесплатна, узкое место – очередь разбора: при 5 минутах на кейс 1 000 кейсов = 5 000 врачебных минут ≈ 83 врач-часа в месяц.

Дистанционное наблюдение: затраты – парк изделий. Объём данных ничтожен: 1 000 пациентов × 4 показания в день × ~1 КБ ≈ 4 МБ в день, около 120 МБ в месяц. За месяц парк на тысячу пациентов передаёт меньше данных, чем один участник за 15 минут видеоконсультации. Зато у каждого пациента дома оборудование: тонометр с сотовым модулем или хаб за 4 300–8 500 ₽ с амортизацией на 24 месяца (180–350 ₽ в месяц) плюс 260–680 ₽ в месяц связи плюс логистика и замены. Выходит порядка 850–1 700 ₽ на пациента в месяц, 0,85–1,7 млн ₽ в месяц за парк – примерно на два порядка больше, чем инфраструктура двух других конвейеров. Поэтому норма ПГГ о том, что изделия может оплатить бюджет или пациент, – не сноска, а строка финансовой модели [4].

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

Типичная ошибка: построить один продукт и назвать его тремя

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

Есть и ошибки подешевле, но не менее разрушительные. Фотографии отложенных консультаций в хранилище подрядчика без поручения обработки или в зарубежном облаке. Пациенты, включённые в программу наблюдения без очного приёма и диагноза, – прямое нарушение ч. 4 ст. 36.2 [1]. Показания приборов и ручной ввод в одной колонке без метки источника. Асинхронный DTC-сценарий, который обещает диагноз по фото. Оценивайте три способа как три продукта: общее (идентификация через ЕСИА, согласия, медицинская карта, аудит) делите, а конвейеры держите раздельными.

Гибриды: где оказываются реальные продукты

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

Асинхронный сбор с эскалацией. Анкета и фотографии собирают жалобы и анамнез – это прямо разрешённая цель консультации. Случаи, на которых срабатывают клинические правила, переводят в живую консультацию, а чаще – записывают на очный приём: «решение о необходимости очного приёма» тоже законная цель телемедицины (ч. 2 ст. 36.2) [1]. Наблюдение с плановыми разговорами. Программа наблюдения передаёт показания непрерывно, а план лечения добавляет ежемесячный видеосозвон – стандартная форма ведения хронических пациентов. Очный приём с дистанционным продолжением. Диагноз и лечение назначаются очно, а коррекция лечения, электронный рецепт и контрольные фотографии идут дистанционно – это типичный российский маршрут, который 193н описывает почти дословно.

Архитектурно каждый гибрид опирается на общее ядро (идентификация, согласия, расписание, медицинская карта, аудит), а три конвейера подключены к нему как отдельные сервисы. Это ядро целиком описывает анатомия телемед-платформы – следующая статья курса.

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

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

Фора Софт с 2005 года разрабатывает системы реального времени и медиасистемы: телемедицину, видеоконференции, стриминг, OTT, e-learning, видеонаблюдение, AR/VR; на счету компании 250+ выпущенных проектов. Телемедицинские проекты регулярно охватывают все три способа в одном продукте. Мы строим синхронный слой под требования 152-ФЗ и 193н (шифрованный WebRTC в российском облаке, ЕСИА, УКЭП, переподключение, аудит), очереди отложенных консультаций, где валидация съёмки и сроки 193н считаются клиническими требованиями, и конвейеры наблюдения, где пороги врача, метка источника показаний и учёт для реестров ОМС лежат в схеме данных с первой миграции. Опыт в видеонаблюдении и стриминге напрямую переносится на постоянно работающий приём данных и оповещения. Каждый проект мы начинаем с того, что фиксируем, какие способы реально нужны продукту: от этого решения зависит стоимость всего остального.

Главное

• Три способа – три шкалы времени: консультация в реальном времени (миллисекунды), отложенная консультация (часы), дистанционное наблюдение (работает непрерывно).
• Архитектуры не переносятся: у медиапути, очереди и конвейера изделий почти нет общих компонентов.
• Диагноз дистанционно без очного приёма поставить нельзя; коррекция лечения и рецепт – только после очного приёма по тому же обращению.
• Отложенная консультация – единственный режим, где 193н прямо допускает СППВР, и только зарегистрированные как медизделия.
• Наблюдение назначает врач после очного приёма; пороги – индивидуальные, ручной ввод разрешён, но помечается; при АГ и СД оно оплачивается из ОМС.
• Гибриды стройте как раздельные конвейеры на общем ядре: ЕСИА, согласия, карта, аудит.

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

• Анатомия телемед-платформы целиком – общее ядро, к которому подключены все три конвейера.
• Ведение хронических заболеваний и удалённый мониторинг – подробный разбор продукта дистанционного наблюдения.
• Оплата телемедицины: ОМС, ДМС, платные услуги – правила оплаты за каждым способом.