Платежи, ДМС, ОМС и фискализация по 54-ФЗ

Автор: Николай СапуновОбновлено: август 202617 мин чтения
Содержание статьи +

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

Кратко

Деньги приходят в телемед-продукт по трём контурам, и путать их – классическая ошибка. Пациент платит сам картой «Мир» или через СБП, страховщик ДМС оплачивает консультации застрахованных по реестру клиники, ОМС – по отдельному тарифу на телемедицину из тарифного соглашения региона. Главное архитектурное решение – вывести платёжный путь за пределы контура медданных: карта вводится в форме провайдера (ЮKassa, CloudPayments, Т-Касса, Robokassa), ваш сервер видит только токен и сумму, а в назначение платежа и кассовый чек не попадают ни диагноз, ни специальность врача, ведь врачебной тайной является уже сам факт обращения. При онлайн-оплате нужен электронный чек по 54-ФЗ, а предоплату, возвраты и неявки проектируют заранее, вместе с дистанционным договором по ПП 659 (с 01.09.2026). Покрытие ДМС проверяйте до визита. В ОМС действуют отдельные тарифы на «врач – врач» и «врач – пациент» (средние нормативы стоимости единицы на 2026 год – 379,9 и 336,3 ₽); они меняются каждый год, поэтому храните их в настройках, а не в коде.

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

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

Три источника денег – три разных контура

Прежде чем выбирать API, разберитесь, как устроена задача. Деньги приходят в телемед-продукт по трём отдельным каналам. Они похожи, но регулируются разными сводами правил.

Первый канал – оплата пациентом: консультация, второе мнение, подписка на наблюдение, оплаченные картой или через Систему быстрых платежей (СБП). Юридически это платная медицинская услуга: договор с пациентом, расчёт через платёжного провайдера и кассовый чек по 54-ФЗ. Помимо правил платных медицинских услуг, здесь действуют стандарт безопасности карточных данных и закон о кассах.

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

Третий канал – ОМС: консультации оплачиваются по отдельным тарифам из тарифных соглашений субъекта, а сведения уходят в систему ОМС через медицинскую информационную систему (МИС) клиники. Пациент не платит вовсе. Отдельный случай – консультация «врач – врач»: её оплачивает медорганизация, которая её запросила.

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

Рисунок 1. Три контура денег. Оплата пациентом идёт через провайдера и кассу и может оставаться вне контура медданных; расчёты по ДМС и ОМС содержат сведения о пациенте и услугах и проходят внутри него. Разделить их – ключевое решение.

Карта – вне ваших серверов: форма провайдера и PCI DSS

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

Так устроены платёжные виджеты и страницы оплаты российских провайдеров – ЮKassa, CloudPayments, Т-Касса (бывшая «Тинькофф Касса»), Robokassa; карты «Мир» и СБП поддерживают все. Выигрыш виден по объёму требований. Безопасность карточных данных регулирует PCI DSS – международный стандарт индустрии платёжных карт. Это не закон: его требования распространяются на вас через договор с провайдером или банком-эквайером. Стандарт делит продавцов по тому, насколько они соприкасаются с карточными данными. Продавец, чья страница участвует в приёме карты, заполняет анкету самооценки SAQ A-EP – около 140 требований; продавец, полностью передавший приём карты стороннему провайдеру, – SAQ A, около 24 [1]. Посчитаем разницу:

SAQ A-EP (ваша страница участвует в приёме карты):  ~140 требований
SAQ A    (форма провайдера, токен):                  ~24 требования
Избегаете, отдав форму провайдеру:                   ~116 требований

Около 116 требований, от которых вы избавляетесь, – это сканирование уязвимостей, тесты на проникновение и управление изменениями в собственном коде, работающем с картами [1]. Для небольшой команды это разница между настройкой виджета и кварталом работы инженера. Действует PCI DSS версии 4.x; какое подтверждение соответствия потребуется именно от вас, определяет договор с провайдером, – уточните это до выбора способа интеграции.

Назначение платежа: как оплата становится медданными

Эта ошибка удивляет команды, потому что выглядит как аккуратный учёт. Вы принимаете оплату через провайдера и, чтобы в выписке всё было понятно, пишете в описании: «Онлайн-консультация психиатра, Иванова А. С., повторный приём». Проблема уже создана.

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

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

Есть и второй канал той же утечки – кассовый чек. В чеке указывается наименование услуги; электронный чек уходит пациенту на email или телефон, а фискальные данные – оператору фискальных данных (ОФД) и дальше в налоговую. Строка «Консультация врача-онколога (онлайн)» сообщает о факте обращения всем, кто видит почту пациента или бухгалтерские выгрузки. Наименование берётся из прейскуранта и договора, поэтому решать нужно не «скрытием» услуги, а формулировками позиций прейскуранта. Насколько обобщёнными они могут быть, определите с юристом и бухгалтером до запуска.

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

Рисунок 2. Две границы. Граница карточных данных не пускает номер карты на ваши серверы; граница медданных не выпускает факт обращения и диагноз к платёжному провайдеру и в чек. Утечка – это клиническая деталь в назначении платежа или в наименовании услуги.

Чек по 54-ФЗ: облачная касса, предоплата и возвраты

Принимать оплату в России – значит выдавать чеки. При онлайн-оплате продавец применяет контрольно-кассовую технику, а при расчётах в интернете чек направляется покупателю в электронной форме (ст. 1.2 54-ФЗ) [4]. Держать кассу в серверной не нужно, есть два рабочих варианта. Первый – касса платёжного провайдера: провайдер формирует чек по данным, которые вы передаёте вместе с платежом. Второй – облачная касса (АТОЛ Онлайн, КОМТЕТ Касса, Orange Data) с подключённым ОФД: после подтверждения оплаты ваш бэкенд отправляет в неё данные чека [5].

Для разработчика чек – ещё одно событие в жизненном цикле платежа, со своими состояниями и ошибками. Минимальная последовательность:

1. Пациент принимает договор и оплачивает  → провайдер: платёж проведён
2. Вебхук провайдера → бэкенд              → оплата привязана к ID визита
3. Чек «приход» → касса → ОФД              → email или телефон пациента
4. Консультация состоялась                 → закрыть предоплату, если нужно
5. Отмена или сбой                         → возврат + чек «возврат прихода»

Телемедицина почти всегда продаёт услугу заранее: пациент платит при записи, а консультация проходит позже. В данных чека это отражается признаком способа расчёта, например «полная предоплата» до оказания услуги и «полный расчёт» после [5]. Как закрывается предоплата в вашем сценарии (отдельным чеком при оказании услуги или иначе), определяет связка «провайдер – касса – бухгалтерия». Решите это до запуска: переделывать фискальную схему на живых платежах болезненно.

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

Наконец, сам договор. С 01.09.2026 действуют новые Правила предоставления платных медицинских услуг, утверждённые ПП № 659, и они прямо разрешают заключать дистанционный договор на сайте или в мобильном приложении медорганизации [6][7]. До подписания пациенту сообщают ОГРН, ИНН, сведения о лицензии, условия и способы оплаты и адрес для претензий; смета может быть твёрдой или приблизительной (п. 25) [7]. Порядок телемедицины добавляет свои требования к раскрытию: на сайте или в приложении указывается в том числе стоимость консультации (п. 37 193н) [8]. Для экрана оплаты это значит: договор, реквизиты и цена показываются до кнопки «Оплатить», акцепт фиксируется с временем и версией документа, а согласие на обработку персональных данных оформляется отдельным документом, не внутри оферты (ст. 9 ч. 1 152-ФЗ в редакции, действующей с 01.09.2025) [9].

ДМС: как страховщики продают телемедицину и что проверить до визита

ДМС – один из главных каналов, по которым телемедицина доходит до пациента: по опросу страхового брокера Remind среди 11 страховщиков, в 2025 году телемедициной пользовались 25% застрахованных по ДМС против 12% в 2022-м [10]. Ренессанс, Ингосстрах и РЕСО сообщали о росте онлайн-приёмов в 2025 году. В полисах телемедицина покрывает то, что разрешено делать дистанционно: профилактику, консультации психологов, второе мнение, расшифровку анализов. Ограничение одно, но принципиальное: первичный приём остаётся очным [10]. Это прямое следствие порядка телемедицины: без очного приёма заключение может содержать только рекомендации по обследованию, а диагноз дистанционно не ставится (п. 40 193н) [8].

Страховщики продают такие программы и как отдельные продукты (например, «Телемедицина РЕСО» [11]), и как часть корпоративных полисов, а некоторые строят собственные виртуальные клиники: Лучи (бывший BestDoctor) с сентября 2024 года работает как онлайн-страховщик с виртуальной клиникой [12]. Каналы B2B2C через ДМС разобраны в статье о ландшафте телемед-продуктов. Отдельного регулирования телемедицины в ДМС нет: всё определяют договор страхования, программа полиса и общие правила платных услуг.

Хуже всего узнать уже после консультации, что программа пациента не включает онлайн-консультацию или что в полисе есть франшиза. Поэтому нужна проверка покрытия до визита: полис действует, программа включает услугу в дистанционном формате, понятна доля пациента. Механика зависит от страховщика: гарантийное письмо, сверка со списками застрахованных или запрос через интеграцию. Часть этой работы берут на себя интеграционные шины: МедФлекс соединяет МИС клиник со страховщиками и, в частности, записывает пациентов по ДМС Ингосстраха и СОГАЗа [13]. Формат запроса и ответа задаёт страховщик или шина – берите его из документации партнёра, а не придумывайте «по аналогии».

Ответ о покрытии позволяет взять верную сумму при записи, а не присылать неожиданный счёт через неделю. Условный пример:

Цена консультации по прейскуранту:           2 500 ₽
Программа ДМС: онлайн-консультация терапевта  покрывается
Франшиза по полису: 10%                       → 10% × 2 500 ₽ = 250 ₽
Взять с пациента при записи:                  250 ₽
Включить в реестр для страховщика:            2 500 − 250 = 2 250 ₽

Ошибка в одну сторону – и вы недоберёте с пациента и будете просить доплату позже; в другую – возьмёте лишнее и будете оформлять возврат с чеком. Проверка покрытия – дешёвая страховка от обоих исходов.

Рисунок 3. От полиса к доле пациента. Проверка покрытия до визита возвращает статус полиса, программу и франшизу: долю пациента берут при записи, а остаток идёт в реестр страховщику.

Реестр и счёт: как деньги приходят от страховщика

После визита клиника получает деньги от страховщика не сразу и не автоматически. Общая схема по ДМС такая: клиника за период формирует реестр услуг, оказанных застрахованным, и счёт; страховщик проверяет их (соответствие программе полиса, гарантийное письмо, обоснованность услуг), оплачивает принятое и сообщает о снятых позициях, а клиника разбирает снятия. Формат реестра, сроки и порядок проверки задаёт договор со страховщиком или интеграционная шина.

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

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

В ОМС контур другой, но устроен похоже: консультации по программе попадают в реестры счетов, которые медорганизация через свою МИС передаёт в систему ОМС – территориальному фонду и страховым медицинским организациям (СМО); СМО, в частности, контролируют сроки консультаций [14]. Детали обмена задают нормативы ОМС и регион. Для платформы важно одно: данные о консультациях должны доходить до МИС клиники без ручной перепечатки – об этом статья об интеграции с МИС.

Рисунок 4. Цикл расчёта. По ДМС реестр и счёт уходят страховщику напрямую или через шину, по ОМС – через МИС клиники в ТФОМС и СМО; обратно приходят оплата и снятия, которые нужно разбирать как данные.
«Типичная ошибка – один провайдер без запасного. Платёжный путь – критическая инфраструктура. Если провайдер или облачная касса недоступны, запись останавливается, а по оплаченным визитам без чеков копятся расхождения. Отправляйте чеки через очередь с повторами и сверкой «платёж – чек», предусмотрите переключение на второго провайдера и ежедневно сверяйте поступления с состоявшимися визитами.»

Тарифы ОМС и правила, которые меняются каждый год

Счёт за телемедицину по ОМС – обычный счёт с особыми условиями, и ошибки в них – частая причина того, что консультацию не оплачивают. Программа госгарантий на 2026–2028 годы (ПП № 2188 от 29.12.2025) требует устанавливать в тарифных соглашениях отдельный тариф на телемедицину – для консультаций «врач – врач» и «врач – пациент» в пределах целей ч. 2 ст. 36.2 323-ФЗ [14][15]. Средние нормативы на 2026 год:

Вид помощиНорматив объёма на 1 застрахованногоСредний норматив стоимости единицы
Телемедицина «врач – врач»0,080667379,9 ₽
Телемедицина «врач – пациент»0,030555336,3 ₽
Дистанционное наблюдение, всего0,018057 комплексных посещений1 108,4 ₽
– при сахарном диабете–3 651,7 ₽
– при артериальной гипертензии–964 ₽

Это средние ориентиры федеральной программы; конкретные тарифы устанавливают тарифные соглашения субъекта, поэтому в разных регионах цифры различаются [14]. Консультацию «врач – врач» оплачивает медорганизация, которая её запросила [14]. Для B2B-платформы консультаций между клиниками это означает учёт «кто запросил, кто консультировал, по какому тарифу»: на нём строятся расчёты между организациями. Дистанционное наблюдение за пациентами с артериальной гипертензией и сахарным диабетом входит в базовую программу ОМС, а медизделия для него можно оплатить из бюджета или за счёт пациента [14]. Участники экспериментального правового режима (ЭПР) по телемедицине работают вне ОМС: финансирование из ОМС в рамках ЭПР запрещено (ч. 2.1 ст. 36.2 323-ФЗ) [15].

Любую дорожную карту стоит строить с учётом простого факта: оплата телемедицины зависит от региона, привязана к датам и меняется каждый год. Тарифы пересматриваются ежегодно, правила платных услуг сменились 1 сентября 2026 года, а трёхлетний срок ЭПР по ПП № 1164, отсчитанный с 01.08.2023, истекал в начале августа 2026 года; сведений о его продлении на момент написания мы не нашли [16]. Поэтому не зашивайте правила оплаты в код. Тарифы, перечень услуг, доступных дистанционно, позиции прейскуранта и сроки их действия – это настройки, которые специалист по расчётам обновляет без релиза.

Денежный стек: кто какие данные получает

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

УчастникПримерыРольМедданные?Что передавать
Платёжный провайдерЮKassa, CloudPayments, Т-Касса, RobokassaПриём карт «Мир» и СБП, токенНетID визита, сумма, контакт для чека
Касса и ОФДкасса провайдера; АТОЛ Онлайн, КОМТЕТ Касса, Orange DataЧек по 54-ФЗНет – только наименование из прейскурантаНаименование, сумма, признак расчёта, контакт
Страховщик ДМС, шинастраховые компании; МедФлексПокрытие, гарантийные письма, реестрыДа – при наличии основания (согласие или закон) и по договоруПолис, услуги, при необходимости диагноз
Система ОМСТФОМС и СМО через МИС клиникиРеестры счетов по тарифамДа – в рамках ОМСЧерез МИС, в форматах ОМС

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

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

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

Главное

  • Три контура денег: оплата пациентом (провайдер и чек), ДМС (покрытие, реестр, оплата), ОМС (отдельный тариф через МИС). Держите их раздельно.
  • Данные карты вводятся в форме провайдера (ЮKassa, CloudPayments, Т-Касса, Robokassa): это PCI DSS SAQ A (~24 требования) вместо SAQ A-EP (~140).
  • Оплата не становится медданными, пока вы не добавили к ней диагноз или специальность: провайдер получает ID визита и сумму, чек – согласованное наименование услуги.
  • Онлайн-оплата требует электронного чека через кассу и ОФД; предоплату, возвраты и неявки проектируйте заранее; договор – дистанционный по ПП 659.
  • По ДМС проверяйте покрытие и долю пациента до визита; реестр для страховщика – медданные, для его передачи нужно ясное правовое основание.
  • ОМС: отдельные тарифы на «врач – врач» и «врач – пациент» (средние нормативы стоимости единицы на 2026 год – 379,9 и 336,3 ₽), «врач – врач» оплачивает запросившая организация; тарифы меняются ежегодно – храните их в настройках.

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.