Идентификация через ЕСИА, SSO и регистры ФРМР/ФРМО

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

Кратко

Прежде чем консультация состоится, телемед-платформа должна ответить на три вопроса об идентификации: тот ли это пациент, действительно ли перед ним врач, имеющий право консультировать, и каких врачей платформа вообще «знает». Первые два вопроса закон отчасти решил за вас. Участников телемедицинской консультации идентифицируют через ЕСИА – единую систему идентификации и аутентификации, знакомую пациентам как «вход через Госуслуги» (ч. 6 ст. 36.2 323-ФЗ, п. 7 приказа Минздрава 193н), а документы врач подписывает усиленной квалифицированной электронной подписью (УКЭП). Sber ID и VK ID удобны для быстрого входа, но ЕСИА не заменяют. Персоналу клиники не нужен ещё один пароль на вашей платформе: врачи входят через единый вход (SSO) клиники по SAML 2.0 или OpenID Connect, часто через Keycloak, а учётные записи создаются и отключаются автоматически. На третий вопрос отвечают регистры ЕГИСЗ: врач должен быть в Федеральном регистре медицинских работников (ФРМР), организация – в Федеральном реестре медицинских организаций (ФРМО) (п. 9 193н). Ваш справочник врачей – постоянно обновляемая копия этих сведений плюс лицензия и аккредитация, и именно от него зависит, предложит ли расписание только тех врачей, которые сейчас вправе консультировать.

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

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

Три вопроса об идентификации

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

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

Не смешивайте эти вопросы: у них разные инструменты, и ломаются они по-разному. Личность пациента и врача подтверждают ЕСИА, аутентификация, единый вход и электронная подпись. Справочник – задача данных: ФРМР и ФРМО, лицензия, аккредитация и стандарты медданных (FHIR). Статья идёт в этом порядке.

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

Личность пациента: ЕСИА и лестница доверия

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

Для телемедицинской консультации ответ задан законом: участников идентифицируют через ЕСИА (ч. 6 ст. 36.2 323-ФЗ, п. 7 193н) [1][2]. Ценность ЕСИА в том, что за учётной записью стоит личность, подтверждённая государственной системой. Уровни доверия удобно представить лестницей:

• Без проверки – телефон или email. Подходит для каталога врачей, статей, записи без медицинской части.
• Удобный вход – Sber ID, VK ID. Упрощает регистрацию и оплату, но ЕСИА не заменяет [3][4].
• ЕСИА – обязательная ступень для участников телемедицинской консультации.
• УКЭП – юридически значимая подпись; на этой ступени стоит врач, подписывающий протокол и документы.

Отступать от этой лестницы могли только участники экспериментального правового режима (ЭПР) по ПП № 1164: им разрешили альтернативную идентификацию – по данным мобильного оператора или банковскому идентификатору [5]. ЭПР охватывал 28 частных организаций и был установлен на три года с 01.08.2023, то есть примерно до августа 2026 года. Продление в открытых источниках на момент написания не подтверждено, поэтому не стройте продукт на этом исключении, не проверив его статус.

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

Технически подключение коммерческой системы к ЕСИА – это регистрация вашей информационной системы и интеграция по регламенту Минцифры: поток авторизации в духе OAuth 2.0 / OpenID Connect с подписью запросов по российским криптографическим алгоритмам. Точный протокол, состав передаваемых сведений и порядок подключения берите из актуальных методических рекомендаций по ЕСИА, а не из чужих примеров кода. И помните о границе с биометрией: видеосвязь сама по себе не биометрическая идентификация, а распознавать пациента по лицу можно только через Единую биометрическую систему или аккредитованную систему (572-ФЗ) [6].

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

Аутентификация: второй фактор и что не класть в токен

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

Для персонала планка выше: врач и администратор видят данные многих пациентов. Меры защиты медданных задают ПП 1119 и приказ ФСТЭК № 21; в приказе есть группа мер «идентификация и аутентификация» (ИАФ), но готового ответа на вопрос, сколько факторов нужно врачу телемед-платформы, он не даёт [7]. Поэтому решение инженерное: считайте многофакторную аутентификацию (пароль плюс одноразовый код или подтверждение на телефоне) минимумом для любого доступа к медданным, а аппаратные ключи выдавайте самым привилегированным учётным записям, например администраторам, которые видят всех пациентов. Требования 2026 года подробно разобраны в статье о защите ПДн.

Самая частая ошибка аутентификации незаметна: медданные в токене входа. После входа система выдаёт токен, часто JSON Web Token (JWT), который передаётся с каждым запросом. Команды иногда кладут в него удобные поля: ФИО пациента, диагноз, номер карты. Но JWT закодирован в base64, а не зашифрован: любой, кто его перехватит, прочитает каждое поле. Токен с «diagnosis: depression» – это сведения о здоровье в открытом виде в хранилище браузера и в логах серверов. Держите в токенах только непрозрачные идентификаторы и области доступа (scopes), никаких клинических деталей.

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

Вход врача: никто не хочет ещё один пароль

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

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

• SAML 2.0 – более старый, на XML, по-прежнему распространён в корпоративном SSO. IdP передаёт приложению подписанное XML-утверждение о пользователе [8].
• OpenID Connect (OIDC) – современный стандарт поверх OAuth 2.0. IdP возвращает подписанный токен (id_token) с описанием пользователя [9].

Если у клиники нет своего IdP или их несколько, роль посредника (брокера) часто берёт на себя Keycloak – open-source сервер идентификации, который разворачивается в вашем российском контуре, поддерживает SAML и OIDC и умеет подключать внешние каталоги пользователей и провайдеры [10]. Подключение ЕСИА через брокер потребует доработки под её регламент – закладывайте это в оценку.

Порядок телемедицины добавляет два требования к врачу. Первое: идентификация участников консультации через ЕСИА (п. 7 193н) касается и медработника [2]. Практичная схема – один раз при онбординге связать учётную запись врача в SSO клиники с его личностью, подтверждённой через ЕСИА; периодичность повторного подтверждения согласуйте с юристом. Второе: консультация документируется с УКЭП медработника (ч. 7 ст. 36.2 323-ФЗ, п. 48 193н), а электронные медицинские документы с 1 сентября 2026 года подписываются только УКЭП (приказ 209н) [1][11]. Подпись и вход – разные вещи: SSO отвечает на вопрос, кто открыл рабочее место, УКЭП – кто юридически отвечает за документ, и для неё нужны сертифицированные средства криптографической защиты информации (СКЗИ). Подпись рецептов разобрана в статье об электронных рецептах.

Внутри МИС есть своя разновидность входа – запуск вашего приложения из карты пациента. Международный стандарт для этого – SMART App Launch (SMART on FHIR): медицинская система открывает приложение и передаёт контекст пациента, а приложение обменивает его на токен доступа без повторного входа [12]. Поддержку стандарта российскими МИС проверяйте у каждого вендора; на практике встраивание часто делают по договорённости с вендором: МИС открывает ваш адрес с подписанным одноразовым токеном контекста. Выбор пути разобран в гиде по решению об интеграции.

У SSO есть парная задача, о которой вспоминают только после первого инцидента: создание и отключение учётных записей (provisioning и deprovisioning). Врач пришёл – учётная запись появилась; уволился – она должна исчезнуть везде и быстро. Автоматизирует это стандарт SCIM (System for Cross-domain Identity Management): IdP отправляет вашей платформе события «создать», «обновить», «деактивировать» [13]. Без него увольнение превращается в ручной чек-лист, а по ручному чек-листу какую-нибудь систему обязательно пропустят.

Этот риск невидим, поэтому его стоит посчитать. Допустим, у платформы 200 врачей, текучесть – 15% в год, и каждое отключение закрывается ручной заявкой, которую в загруженную неделю выполняют за три дня:

200 врачей × 15% текучести = 30 увольнений в год
30 увольнений × 3 дня      = 90 врачо-дней в год,
  когда учётная запись должна быть отключена, но работает

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

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

Регистры ФРМР и ФРМО: справочник врачей платформы

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

Государственная опора для этого справочника – регистры единой государственной информационной системы в сфере здравоохранения (ЕГИСЗ): ФРМР и ФРМО – её подсистемы [14]. Порядок телемедицины требует, чтобы консультирующий врач был в ФРМР, а организация – в ФРМО (п. 9 193н) [2]; те же условия действуют для электронного рецепта по приказу 1094н [15], а внесение сведений в ФРМО и ФРМР – лицензионное требование к медорганизации (п. 5 «ж» ПП 852) [16]. Сведения в регистры вносит сама медорганизация; ваша платформа их не заменяет, а хранит связь с ними и сверяет статус.

Запись в ФРМР доказывает только то, что врач учтён. Чтобы она стала доверенной записью справочника, нужны ещё два факта. Лицензия организации должна покрывать работы и услуги, оказываемые дистанционно: телемедицина оказывается только в их пределах, отдельной «телемедицинской» лицензии нет (п. 4 193н), а лицензия действует на всей территории России, так что привязывать врача к региону пациента не нужно [2][16]. Аккредитация специалиста должна быть действующей: работники медорганизации обязаны её иметь (п. 5 «в» ПП 852) [16]. Положение об аккредитации утверждено приказом Минздрава № 709н; периодическая аккредитация проходит не реже раза в пять лет, документы подаются через ФРМР. Справочник, проверенный один раз при онбординге, через несколько лет уже неверен: аккредитация истекает, врачи меняют место работы.

Изобретать формат данных не нужно. FHIR описывает врача ресурсом Practitioner, а его работу – ресурсом PractitionerRole, который связывает врача с организацией, специальностью и услугами [17]. Сообщество HL7 FHIR Россия развивает российский профиль RuCore на FHIR R5 [18], а специальности и должности стоит кодировать по справочникам НСИ Минздрава, у которых есть REST API [19]. Справочник на PractitionerRole и кодах НСИ сможет и принимать данные из МИС, и отдавать их наружу без переделок.

Есть и внешняя причина поддерживать справочник в актуальном состоянии. На сайте или в приложении пациенту сообщают ФИО, образование, стаж и категорию консультанта (п. 37 193н) [2]. Данные для карточки врача берутся из того же справочника, и устаревшая запись превращается в недостоверную информацию для пациента. Данные устаревают быстрее, чем ожидают команды. Условный расчёт:

Записи о врачах устаревают ~2,5% в месяц (место работы, должность, аккредитация)
12 месяцев × 2,5% ≈ 30% записей в год
Справочник, проверенный только при онбординге, через год неверен примерно на треть

Поэтому справочник должен непрерывно обновляться из кадровых данных клиники, МИС и сверки с ФРМР, а не импортироваться однажды в виде таблицы. Здесь он смыкается с расписанием: проверка «врач вправе консультировать по этой услуге», которую интеграция расписания выполняет до того, как слот показан пациенту, надёжна ровно настолько, насколько свеж справочник. Лицензия и аккредитация подробно разобраны в статье о лицензировании и аккредитации.

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

Выбор слоя идентификации: где лежат учётные записи

Аутентификацию редко строят с нуля: многофакторный вход, управление сессиями и федерация SSO – отдельная специальность, а самописный вход – то место, где начинаются утечки. Реальный выбор – на какую платформу опереться, и главный критерий здесь тот же, что для любого подрядчика в этом разделе: где физически лежат учётные записи и по какому договору их обрабатывают. С 01.07.2025 вести базы с персональными данными граждан России за рубежом прямо запрещено (ст. 18 ч. 5 152-ФЗ); штраф по ч. 8 ст. 13.11 КоАП – до 6 млн ₽, повторно – до 18 млн ₽ [20]. Если учётные записи пациентов связаны с консультациями, это уже контур медданных, и подрядчик, у которого они хранятся, работает по поручению обработки.

За таблицей стоят два компромисса. Готовый провайдер даёт быстрый вход с первого дня, но размещает данные идентификации на чужой инфраструктуре – значит, нужны договор, поручение и размещение в России. Self-hosted Keycloak держит всё внутри вашего контура, но тогда вы отвечаете за обновления, доступность и каждую меру защиты. Ни то ни другое не ошибка; выбор зависит от опыта и ресурсов команды. Логика «свой или готовый» повторяет решение о видеослое из статьи «Свой или CPaaS», а требования к размещению описаны в статье о локализации медданных.

Аутентификация – это не авторизация

Одна концептуальная ошибка порождает больше уязвимостей, чем любая ошибка в протоколе. Аутентификация отвечает на вопрос «кто вы», авторизация – «что вам можно видеть». ЕСИА, SSO и SMART App Launch решают первую задачу и не решают вторую. Врач, подтвердивший личность через IdP клиники, не получает права открыть карту любого пациента – только своих пациентов, в своей организации и по законной причине.

Это разделение следует из закона. Врачебную тайну нельзя разглашать (ст. 13 323-ФЗ), обрабатывать можно только данные, нужные для цели (ст. 5 152-ФЗ), а приказ ФСТЭК № 21 выделяет управление доступом в отдельную группу мер (УПД) [21][22][7]. Для электронных медицинских документов приказ 209н требует журналировать доступ [11]. Поэтому даже идеально аутентифицированный врач проходит проверку авторизации: ролевой доступ, проверка отношения к пациенту и журнал, в котором видно, кто открыл какую карту; об этом статья о журналах аудита и контроле доступа. Стройте идентификацию и доступ как два отдельных слоя: если их смешать, аутентифицированный сотрудник сможет незаметно просматривать карты пациентов, к которым не имеет отношения.

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

Фора Софт разрабатывает видеосвязь реального времени и софт для клиник с 2005 года. В телемедицине на слое идентификации сходятся два противоположных риска: слишком слабый вход, который ведёт к утечке, и устаревший справочник, из-за которого на консультацию попадает врач, не вправе её проводить. Мы проектируем этот слой от требований: идентификация пациента через ЕСИА в нужный момент, Sber ID или VK ID – только для удобства, вход врачей через IdP клиники по SAML или OpenID Connect (при необходимости через Keycloak в российском контуре), второй фактор для всего персонала и УКЭП для подписи документов. В справочнике связываем каждого врача с записями ФРМР и ФРМО, моделируем данные на FHIR PractitionerRole с кодами НСИ и подключаем сверку лицензии и аккредитации к расписанию, а аутентификацию и авторизацию держим в двух разных слоях.

Главное

• Идентификация отвечает на три вопроса: кто пациент, кто врач и какие врачи вправе консультировать.
• Участников телемедконсультации идентифицируют через ЕСИА (ч. 6 ст. 36.2 323-ФЗ, п. 7 193н); Sber ID и VK ID – удобный вход, но не замена ЕСИА.
• Документы врач подписывает УКЭП; подпись означает юридическую ответственность за документ и не заменяет вход.
• Врачи входят через IdP клиники (SAML 2.0 или OIDC, часто через Keycloak); учётные записи создаёт и отключает SCIM.
• Справочник врачей опирается на ФРМР и ФРМО, лицензию организации и действующую аккредитацию; из него берут данные расписание и карточки врачей.
• Учётные записи с ПДн россиян – только в России; аутентификация и авторизация – два разных слоя.

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

• Кто в кабинете: роли, идентификация и согласие
• Аутентификация и идентификация пациентов и врачей
• Интеграция расписания и календаря