Ведение хронических заболеваний и удалённый мониторинг

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

Кратко

Ведение хронических больных и удалённый мониторинг – две разные вещи, которые основатели постоянно смешивают в один продукт. Первое – работа лечащего врача с пациентом, у которого уже поставлен диагноз: телемедицинские консультации «врач – пациент» для оценки эффективности лечения, наблюдения и коррекции терапии. Второе – дистанционное наблюдение за состоянием здоровья по приказу Минздрава 193н (п. 43–47): его назначают только после очного приёма и установления диагноза, данные поступают с медицинских изделий автоматически или вводятся вручную, лечащий врач задаёт пороговые значения, а система обеспечивает экстренное реагирование и ведёт личный кабинет пациента. С 2026 года дистанционное наблюдение за пациентами с артериальной гипертензией (АГ) и сахарным диабетом (СД) входит в базовую программу ОМС: средний норматив – 964 ₽ за комплексное посещение при АГ и 3 651,7 ₽ при СД. Настоящая спецификация продукта – перечень функций п. 46 193н и условия оплаты, а не список желаемых функций. Ниже разобрано, как построить платформу для ведения хронических больных, которая превращает непрерывный поток данных в безопасную и оплачиваемую помощь: тарифы, требования к устройствам и граница медданных.

Почему это важно

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

Два продукта, которые выглядят как один

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

Ведение хронического больного с телемедицинскими консультациями – это работа врача. Пациент с установленным диагнозом наблюдается у лечащего врача, и часть контактов переходит в онлайн: оценка эффективности лечения, сбор жалоб, наблюдение за состоянием, коррекция ранее назначенного лечения – ровно те цели, которые ст. 36.2 323-ФЗ разрешает для консультаций «врач – пациент». Устройство здесь не обязательно: пациента можно вести, имея лишь телефон. Оплата – по тарифу на телемедицинскую консультацию в ОМС (средний норматив 2026 года – 336,3 ₽), по договору ДМС или как платная услуга.

Дистанционное наблюдение – продукт, построенный на данных. Лечащий врач назначает его после очного приёма и установления диагноза вместе с программой и порядком наблюдения (п. 43 193н). Медицинские изделия – тонометр, глюкометр, весы, пульсоксиметр – передают показатели, или пациент вводит их вручную, команда видит непрерывный поток и вмешивается, когда значение уходит за порог. В наблюдении участвуют пациент, лечащий врач и при необходимости медработник, который ведёт наблюдение и экстренно реагирует на критические отклонения (п. 44). Вместо разового среза раз в месяц – непрерывная история показателей.

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

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

Правила и тариф – это спецификация продукта

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

Второй слой спецификации – оплата. Программа госгарантий на 2026–2028 годы (ПП 2188) включила дистанционное наблюдение за пациентами с АГ и СД в базовую программу ОМС. Средние нормативы на 2026 год такие:

• Дистанционное наблюдение в целом – 0,018057 комплексного посещения на одного застрахованного, 1 108,4 ₽ за комплексное посещение.
• При сахарном диабете – 3 651,7 ₽ за комплексное посещение.
• При артериальной гипертензии – 964 ₽ за комплексное посещение.
• Медицинские изделия для наблюдения можно оплатить из бюджета или за счёт пациента – это решение региона и клиники, а не платформы.

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

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

АГ:  300 пациентов × 964 ₽          =   289 200 ₽
СД:  200 пациентов × 3 651,7 ₽      =   730 340 ₽
                                     -----------
За одно комплексное посещение      ≈ 1,02 млн ₽

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

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

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

Устройства: что можно считать клиническими данными

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

Первое – само устройство. В России разрешено обращение медицинских изделий, прошедших государственную регистрацию (ст. 38 ч. 4 323-ФЗ). Тонометр или глюкометр с регистрационным удостоверением – медизделие; фитнес-браслет, считающий шаги и сон, – нет, и его «тренды давления» не должны становиться основанием для клинических решений. Система обязана регистрировать устройства и контролировать актуальность сведений о них – значит, у каждого замера должна быть ссылка на конкретный прибор пациента. Второе – способ передачи. Ручной ввод допустим, но это другие данные: опечатки, «округлённые» значения, пропуски. Помечайте источник каждого замера (автоматически или вручную), показывайте его врачу и учитывайте в порогах; пациент, со своей стороны, обязан пользоваться устройствами по инструкции и вводить достоверные данные (п. 47).

Третья проверка касается вашего собственного ПО. Если платформа только показывает и хранит замеры, это инфраструктура. Если она начинает трактовать их – помечать значение как опасное по собственной модели, прогнозировать ухудшение, рекомендовать смену лечения, – ваше ПО может само оказаться медицинским изделием: определение медизделия в ст. 38 прямо включает специальное ПО, а ключевой критерий – назначение, заданное производителем. Такое ПО регистрируется по ПП 1684, а ПО с искусственным интеллектом по классификации приказа Минздрава 4н от 06.06.2012 всегда относится к классу 3. Системы поддержки принятия врачебных решений в дистанционном наблюдении применять можно (п. 45 193н) – но как зарегистрированные медизделия. Безопасный подход – оставлять аналитику прозрачной подсказкой для лечащего врача, который принимает решение и задаёт пороги, а любую функцию, которая выдаёт вывод напрямую пациенту или которую врач не может проверить, отдельно оценивать на предмет регистрации. Подробно эту границу разбираем в статьях Удалённый мониторинг и детекция аномалий и Слой комплаенса и безопасности клинического ИИ; правило простое: показ данных – инфраструктура, трактовка – вопрос о медизделии.

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

Архитектура: от тонометра на кухне до записи в медкарте

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

Устройство и связь. Домашние устройства передают данные одним из двух способов. Bluetooth Low Energy (BLE) связывает прибор со смартфоном пациента, а приложение отправляет замеры в облако – дёшево, но зависит от того, что у пациента есть смартфон, приложение установлено, а Bluetooth включён. Для пожилых пациентов эта цепочка слишком хрупкая, и приверженность страдает в первую очередь из-за неё. Альтернатива – устройство со встроенным сотовым модемом (на энергоэффективных стандартах вроде LTE-M или NB-IoT), которое передаёт само, без телефона и приложения. Такие приборы дороже и требуют оплаты связи, но приверженность с ними намного выше: пациент сделал замер, и данные просто пришли. Для тех, кому наблюдение нужнее всего, принцип «телефон не нужен» часто оказывается лучшим решением.

Приём и нормализация. Замеры приходят от разных производителей в разных форматах. Хорошо спроектированная платформа сводит это разнообразие к единому виду уже на этапе приёма: нормализует всё во внутреннюю модель и сопоставляет с медицинским стандартом. Профили устройств вроде IEEE 11073 и Continua описывают структуру показателя на источнике, а HL7 FHIR передаёт его дальше: замер становится ресурсом Observation, привязанным к Device и Patient. В России FHIR использует, в частности, N3.Health, а сообщество HL7 FHIR Россия развивает профиль RuCore; документы в ЕГИСЗ при этом передаются как СЭМД на базе HL7 CDA R2. Если использовать FHIR и внутри системы, и на её границах, интеграция с каждой новой МИС перестаёт быть отдельным проектом. Подробнее – HL7 FHIR, СЭМД и реальность интеграции с МИС.

Хранение и рабочее место команды. Нормализованные замеры попадают в хранилище истории показателей и выводятся на дашборд команды: тренды по пациенту, индикатор «данные не поступают уже три дня» и рабочий список пациентов, чьи значения пересекли порог. Данные дистанционного наблюдения вносятся в электронную медкарту (п. 46, 49–50 193н), поэтому интеграция с МИС обязательна. У государственных МИС уже есть свои модули: в ЕЦП.МИС есть «Дистанционный мониторинг», в московской ЕМИАС – «Дневник здоровья» с данными умных устройств; коммерческой платформе нужно либо интегрироваться с МИС клиники, либо самой вести ЭМК. Как устроены такие интеграции – в статье Интеграция с МИС: Медиалог, 1С:Медицина, ЕЦП.МИС, ЕМИАС и другие. На каждом из этих переходов передаются медданные, и здесь мы подходим к границе медданных.

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

Комплаенс: поток – это медданные, а облако устройства – внутри вашей границы

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

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

Внутри границы работают привычные меры, но с поправкой на то, что данные идут круглосуточно: уровень защищённости и меры по ПП 1119 и приказу ФСТЭК № 21, шифрование канала с устройства и хранилища замеров, ролевой доступ и журнал, который фиксирует, кто из персонала и когда смотрел поток какого пациента. Из-за непрерывных данных журнал становится больше, но не перестаёт быть обязательным. Принцип минимизации определяет, кто в команде что видит.

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

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

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

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

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

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

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

Типичные ошибки

Ошибки в таких продуктах повторяются из проекта в проект, и каждую лучше исключить на этапе проектирования, чем исправлять потом.

• Наблюдение без очного приёма. Пациент скачал приложение, подключил тонометр – и «наблюдается». Дистанционное наблюдение назначает лечащий врач после очного приёма и установления диагноза (п. 43 193н); без этой ссылки в данных нет ни законного основания, ни основания для оплаты.
• Фитнес-браслет как клинический источник. Данные потребительских устройств без регистрационного удостоверения не должны влиять на пороги и решения. Храните велнес-данные и клинические замеры раздельно.
• Облако производителя за рубежом. Платформа аккуратно хранит данные в России, а прибор отправляет замеры в зарубежное облако производителя. Проверяйте маршрут данных каждого устройства до закупки.
• Ручной ввод без пометки источника. Значение, вписанное пациентом, выглядит в дашборде так же, как переданное прибором. Помечайте источник и учитывайте его в порогах.
• Поток тревог без владельца. Пороги срабатывают, за очередь никто не отвечает, критическое значение лежит непрочитанным ночью. Назначьте каждому пациенту ответственного и дежурного до запуска.
• Тишина вместо «данные не дошли». Прибор сломался или разрядился, пациент уверен, что его наблюдают. Фиксация факта передачи и уведомления о пропусках – требование п. 46, а не дополнительная услуга.
• Доказательства задним числом. Назначение, программа, просмотры и контакты не собираются по ходу работы – и в конце периода нечем подтвердить реестр. Стройте журнал как часть модели данных.

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

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

Главное

• Телемедицинские консультации в ведении больного и дистанционное наблюдение – два разных продукта, которые совмещаются у одного пациента; проектируйте их раздельно, потом объединяйте.
• Дистанционное наблюдение назначается после очного приёма и диагноза; п. 46 193н – готовая спецификация системы.
• С 2026 года наблюдение при АГ и СД оплачивает ОМС: средние нормативы 964 ₽ и 3 651,7 ₽ за комплексное посещение.
• Клинические данные – с зарегистрированных медизделий; ручной ввод допустим, но помечается; ПО, которое трактует данные, – вопрос о его регистрации как медизделия.
• У каждого обработчика в потоке – поручение, все базы – в России, включая облако производителя устройства.
• Пороги задаёт лечащий врач; у каждого пациента – ответственный, дежурный и путь эскалации.

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

• Удалённый мониторинг и детекция аномалий – слой детекции, который превращает поток в безопасные тревоги.
• Модель стоимости телемед-платформы: во что реально обходится разработка и эксплуатация – во что обходится платформа с подключёнными устройствами.
• HL7 FHIR, СЭМД и реальность интеграции с МИС – как данные мониторинга попадают в медкарту.