Медицинский ИИ с автоматической передачей данных: как разработчику организовать мониторинг Росздравнадзора

Опубликовано: 04.10.2026 Обновлено: 04.10.2026 Время чтения: 19 мин

Автор и издатель: редакция «Пятого фактора».

Практическое руководство по приказу Росздравнадзора № 123: применимость, состав сведений, архитектура передачи и контрольный журнал обмена

Кого касается и почему нельзя «подключать всех»

Материал написан для производителей программных медицинских изделий с ИИ, их уполномоченных представителей и команд сопровождения. Здесь не разбирается, как рентгенолог работает с ИИ-ассистентом, и не описывается отдельное сообщение о неблагоприятном событии. Тема статьи — системный обмен техническими сведениями между продуктом и регулятором.

Приказ № 123 зарегистрирован в Минюсте 8 мая 2026 г. (№ 86377) и действует до 31 декабря 2027 г. [2]. Он заменил порядок 2025 года, который действовал до конца 2025-го. В новой редакции подробно прописана работа электронного кабинета и появился отдельный параметр «тип решения» [6].

Порядок не обязывает встраивать передачу в любую медицинскую нейросеть. Формулировка условная: производитель обеспечивает передачу, если у изделия есть встроенная функция [2]. Правила регистрации тоже рассматривают этот признак как бинарный. В заявлении указываются сведения о наличии или отсутствии функции [4], и от ответа зависит, по какой процедуре потом вносятся изменения в досье [7].

На практике встречаются три ошибки:

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

Важное ограничение. Условие о встроенной функции здесь ключевое. Состав передаваемых сведений и режим передачи каждый раз нужно сверять с действующей редакцией Порядка [2] и с актуальными техническими требованиями регулятора [5]. Инструкция и схема сообщений обновляются отдельно от приказа.

Шаг 1. Как определить применимость порядка к конкретному изделию

Решение принимается по документам, а не по архитектуре продукта. Удобно оформить его коротким чек-листом, который подписывает ответственный за регуляторные вопросы.

Изделие зарегистрировано как медицинское изделие, и в реестре есть запись с номером и датой. Порядок относится к ПО, «являющемуся медицинским изделием, подлежащим обращению» в РФ [2].
В регистрационных документах изделие отнесено к ПО с применением технологий ИИ. Этот признак заявитель указывает отдельно [4].
В заявлении о регистрации указано, что встроенная функция автоматической передачи есть [4].
Функция описана в технической и эксплуатационной документации. Росздравнадзор рекомендует написать во введении к обоим документам, что в ПО реализована функция передачи сведений в АИС Росздравнадзора, и привести перечень передаваемых сведений [8].
Функция действительно работает в той версии, которая установлена у медорганизаций.

Если пункты 1–4 выполнены, порядок применяется, а пятый пункт становится обязанностью производителя. Если в досье указано, что функции нет, приказ № 123 к изделию не применяется. Изменения в досье в этом случае вносятся по общим процедурам, без упрощённого порядка для номера версии [7].

Для бизнеса это значит, что решение о встроенной функции принимается на этапе регистрации, а затем влияет на стоимость каждого релиза.

Шаг 2. Как связать регистрационную запись, наименование, версию и учётную запись производителя

Для каждого МИ с ТИИ в АИС предоставляется отдельный электронный кабинет заявителя, вход в него идёт через ЕСИА [2]. По инструкции регулятора [5] связка выстраивается так:

Вход в личный кабинет заявителя через ЕСИА от имени организации. Наименование, ИНН и ОГРН подтягиваются из учётной записи организации.
Подача заявления типа «Тестирование». Зарегистрированное изделие выбирается из реестра, после чего автоматически заполняются наименование модели, наименование МИ, номер и дата РУ. Для незарегистрированного изделия наименование, номер версии ПО и области применения вводятся вручную.
В заявлении указываются тип размещения («Инфраструктура заказчика», «Облачное решение производителя» или оба варианта) и способ подачи данных («Ручной» или «Автоматический»).
По итогам тестирования производитель получает 8-значный код модели и с ним подаёт заявление типа «Передача данных».
Когда заявление на автоматическую передачу согласовано, в нём появляется client_id, а пара client_id/client_secret приходит на электронную почту, указанную в заявлении. После валидной отправки к заявлению прикрепляется сертификат о прохождении тестирования, подписанный электронной подписью Росздравнадзора.

Заявление можно вернуть на доработку только один раз, и на исправления даётся 5 рабочих дней [5].

Что из этого следует для системы:

Нужен реестр регуляторных идентификаторов: одна строка на одно изделие. В ней наименование строго как в РУ, номер и дата РУ, версия из реестровой записи, код модели, номер заявления, client_id, тип размещения, ответственный сотрудник и владелец учётной записи ЕСИА.
client_secret хранится в хранилище секретов (vault, KMS), а не в конфигурации у заказчика. Если изделие размещено в контуре медорганизации, нужно отдельно продумать, как не отдать секрет производителя заказчику в открытом виде.
Одно изделие соответствует одному кабинету и одному набору учётных данных. Если изделий несколько, общий ключ на всё портфолио не годится.
Наименование и версию в отчёт подставляют из реестра, а не из package.json или тега сборки. Сервер сверяет зарегистрированное изделие по номеру и дате РУ [5].

Шаг 3. Какие технические показатели собирать

Перечень сведений в п. 5 Порядка закрытый [2]. Ниже каждая позиция сопоставлена с полем SOAP-сообщения из инструкции регулятора [5].

Наименование, номер и дата РУ (номер реестровой записи).Поля: DeviceRegistrationInfo/DeviceName, RegistrationNumber, RegistrationDate.
Источник значения: реестр регуляторных идентификаторов.
При тестировании незарегистрированного изделия используется поле DeviceNameNotRegistered.
Версия МИ с ТИИ.Поле: DeviceVersion.
Источник значения: реестр, сверенный со сборкой, которая фактически работает у медорганизаций (подробнее в шаге 5).
Область применения.Поле: ApplicationArea, одно или несколько значений.
Источник значения: конфигурация развёртывания.
Значения берутся из справочника, в примерах встречаются коды вида radiology_oncology_breast.
Тип решения.В инструкции он объединён с ApplicationArea под названием «область применения (тип решения)».
В приказе № 123 это отдельная позиция, а справочник значений «будет уточнён позднее», поэтому её нужно уточнить у регулятора.
Количество обработанных исследований или объектов.Поле: ProcessedCount.
Источник значения: агрегатор событий инференса.
Единица подсчёта (исследование, серия или объект) должна совпадать с эксплуатационной документацией.
Данные о результатах действия.Поле: Results.
Источник значения: агрегатор.
По инструкции это число успешно обработанных исследований.
Количество ошибок: сетевых, связанных с качеством данных и связанных с работой изделия.Поля: ErrorStatistics/TotalErrors и Errors (пары Code–Value).
Источник значения: агрегатор с классификатором ошибок.
Сумма значений Errors не должна превышать TotalErrors, иначе сервер вернёт статус INVALID_STATS_ERROR.
ИНН медорганизации, использующей изделие.Поле: OrganizationIdentifier/INN или OID.
Источник значения: справочник клиентов и инсталляций.
Можно указать несколько организаций.

Кроме того, сообщение содержит ReportingPeriod (StartDate, EndDate), атрибут schemaVersion и, для тестов, IsTest="true" [5].

Поле Results не означает «процент правильных диагнозов». По инструкции это количество успешно обработанных исследований [5]. Клиническая точность модели в этот отчёт не входит, поэтому AUC, чувствительность или распределение классов сюда не добавляют.

Как отличить ошибку алгоритма от сбоя связи и проблем с входными данными

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

Отнесение кодов к группам п. 5 «ж» — наша интерпретация.

Получение входа.DataExchangeFailure: нарушен обмен данными при получении входных данных. Группа: сетевые ошибки. Признаки: таймаут или обрыв при запросе к PACS/МИС, ошибка DICOM C-MOVE/C-GET, ответ 5xx от источника.
Проверка входа.IntendedUseMismatch: входные данные не соответствуют назначению изделия. Группа: качество и соответствие данных. Признаки: неверная модальность, анатомическая область или возраст пациента вне назначения.
DataQualityIssues: качество или полнота входных данных не соответствуют техусловиям. Группа: качество данных. Признаки: не хватает срезов, есть артефакты, неподдерживаемые параметры реконструкции, нет нужных DICOM-тегов.
Приём и сохранение.DataTransferError: ошибка обработки и сохранения входных данных. Пограничный случай, группу нужно определить в своей методике. Признаки: не удалось записать во временное хранилище, ошибка декодирования.
Инференс.InternalDeviceFailure: внутренний сбой изделия. Группа: работа изделия. Признаки: исключение в модели, нехватка памяти на GPU, сбой постобработки.
HighConcurrencyOverload: сбой из-за высокой одновременной нагрузки. Группа: работа изделия. Признаки: переполнена очередь, отказ по лимиту параллельности.
Выдача результата.ProcessingTransferResultError: ошибка передачи результатов. Группа: сетевые ошибки. Признаки: не удалось вернуть SR или отчёт в PACS/МИС.

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

Правила, которые стоит закрепить в коде и в регламенте

Одно событие отказа получает один код и относится к одной стадии. Код определяется первой стадией, на которой произошёл отказ. Если некачественный вход привёл к падению модели, это DataQualityIssues, а не InternalDeviceFailure — при условии, что проверка качества стоит перед инференсом.
Техническая ошибка и клиническая ошибка алгоритма — разные вещи. Ложноположительное или ложноотрицательное заключение технически считается успешной обработкой, и кода в этой телеметрии для него нет. Если клинический результат привёл к вреду или мог привести, это вопрос мониторинга безопасности и сообщений о неблагоприятных событиях, у которых свой порядок [9]. Смешивать эти потоки не нужно.
Повторы на транспорте не считаются ошибками. Если запрос к PACS упал, а повтор через 2 секунды прошёл, исследование засчитывается как обработанное. Учитываются ли промежуточные сбои, решает методика подсчёта, и применять её нужно одинаково во всех периодах.
Инварианты проверяются до отправки. Сумма Errors не больше TotalErrors — это проверяет и сервер [5]. Кроме того, Results и TotalErrors должны быть согласованы с ProcessedCount по вашей методике. Прямого правила для соотношения этих трёх чисел в инструкции нет, хотя в примерах выполняется равенство 1450 + 50 = 1500. Это стоит уточнить у регулятора.

Шаг 4. Как согласовать формат и периодичность с официальной документацией

Формат задан регулятором [5]:

аутентификация: POST на сервер авторизации АИС (OpenID Connect) с grant_type=client_credentials; токен действует 5 часов и передаётся в заголовке Authorization: Bearer …;
отправка: SOAP-метод sendreport по адресу https://elk.roszdravnadzor.gov.ru/public-gateway/medicaldeviceai/api/v1/sendreport;
синхронный ответ: идентификатор (Id) и статус. REQUEST_ACCEPTED означает, что сообщение принято; VALIDATION_ERROR — ошибку проверки по схеме, с текстом от XSD-валидатора;
асинхронная проверка: метод getreportstatus по Id возвращает итоговый статус, например DONE или INVALID_STATS_ERROR;
детальная схема описана в WSDL-файле, на который ссылается инструкция.

Клиент генерируйте по WSDL, а каждое сообщение проверяйте по XSD до отправки. Собирать XML вручную по образцу из PDF не стоит.

Периодичность и отчётный период. Порядок не устанавливает частоту передачи [2]. В сообщении есть явные StartDate и EndDate [5], а в примерах период равен месяцу. Одного примера недостаточно, чтобы считать месячную отчётность требованием. Рабочий подход:

запросить у Росздравнадзора через ЛК или официальным письмом ожидаемую периодичность и правила для пересекающихся и пропущенных периодов;
до ответа выбрать один фиксированный календарный период (сутки или месяц), не допускать пересечений и пропусков и закрепить выбор в эксплуатационной документации;
считать агрегаты по закрытым периодам в одном и том же часовом поясе (UTC+3 или UTC) и указать его в методике.

Чего делать не стоит: строить регуляторный отчёт на продуктовой аналитике (Яндекс Метрике, Amplitude, ClickHouse с событиями интерфейса). У аналитики другие единицы учёта, неполные данные из-за сэмплирования и блокировщиков, свои правила хранения. Регуляторные метрики должны считаться из отдельного журнала событий обработки, в котором записи не теряются и не меняются задним числом.

Шаг 5. Как хранить подтверждения, обрабатывать повторы и контролировать версии

Что хранить как подтверждение

Каждую передачу подтверждают три уровня записей:

Факт отправки: точное тело запроса (или его хеш плюс архивная копия), время и HTTP-статус.
Факт приёма: Id и статус REQUEST_ACCEPTED либо VALIDATION_ERROR с текстом ошибки [5].
Результат обработки: итоговый статус из getreportstatus. Кроме того, сотрудник регулятора может отметить данные в карточке ЛК как «Корректные», «Неполные» или «Недостоверные» [5]. Этот статус стоит регулярно сверять вручную и переносить в журнал.

По Порядку переданная информация доступна производителю для просмотра в электронном кабинете [2]. Это удобная точка для ежемесячной сверки: всё ли, что есть в вашем журнале, отражено в кабинете.

Отдельно храните сертификат о прохождении тестирования, который прикрепляется к заявлению [5]. Он подтверждает, что заявленная в досье функция действительно работает.

Повторы и дубли

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

таймаут без ответа не повод сразу отправлять заново. Если Id не пришёл, сначала проверьте реестр передачи данных в ЛК и только потом решайте, нужна ли повторная отправка;
после VALIDATION_ERROR повтор без исправления бесполезен: это ошибка данных, а не транспорта;
автоматические повторы допустимы при транспортных ошибках до получения ответа (DNS, TLS, 502/503/504) — с экспоненциальной задержкой и ограниченным числом попыток;
локальный ключ передачи (изделие + версия + период + набор ИНН) защищает от дублей хотя бы на вашей стороне: второй отчёт за тот же период уходит только по явному решению оператора;
как исправить уже принятый отчёт, нужно уточнить у регулятора: механизм корректировки в инструкции не описан.

Контроль версий

Версия в отчёте должна совпадать с версией в реестровой записи. Для ПО с ИИ со встроенной функцией передачи есть упрощённая процедура изменения номера версии, если изменение не затрагивает функциональное назначение и принцип действия. Заявление подаётся через ЕЛК заявителя. Регистрирующий орган проверяет его в течение 5 рабочих дней и ещё в течение 5 рабочих дней принимает решение и вносит изменения в реестровую запись [7]. Изменения, затрагивающие назначение или принцип действия, проходят по общим процедурам с экспертизой [4][7].

Для команды из этого вытекает release gate:

Каждый релиз классифицируется: меняет ли он функциональное назначение или принцип действия (переобучение модели, новые классы, новая модальность)? Решение принимает регуляторная служба, а не только тимлид.
Новый номер версии попадает в продуктив у медорганизаций только после внесения в реестр. Исключение возможно, если регуляторная служба письменно определила порядок действий на переходный период.
Агрегатор группирует метрики по версии. Если за период у клиентов работали две версии, это две отдельные передачи. Ожидания регулятора для таких «смешанных» периодов тоже лучше уточнить.
Номер версии для АИС читается из конфигурации, подписанной при релизе, и сверяется с реестром. Ручного ввода быть не должно.

Шаг 6. Как минимизировать передаваемые данные

Регуляторная передача по своему устройству агрегатная. Перечень п. 5 включает только счётчики и идентификаторы изделия и организации [2], а в схеме сообщения нет полей для изображений, диагнозов или данных пациента [5]. Риск появляется в обвязке вокруг канала.

Сведения о факте обращения за медицинской помощью, состоянии здоровья и диагнозе составляют врачебную тайну. Раскрывать их можно с согласия пациента или в случаях, прямо перечисленных в законе [10]. Приказ № 123 не даёт основания передавать медицинские данные пациентов: он требует технических сведений.

Практические правила:

Подсчёт выполняется там же, где обработка. Если изделие размещено в инфраструктуре заказчика, агрегатор работает в его контуре, и наружу уходит только итоговое сообщение. Сырой журнал событий остаётся в медорганизации.
В журнале событий только минимум полей: псевдонимизированный ключ исследования (например, HMAC от Study Instance UID с ключом, хранящимся у заказчика), время, стадия, код ошибки, версия. ФИО, полиса, даты рождения и текстов заключений там нет.
В регуляторном канале нет свободного текста. Сообщения из исключений (stack trace, пути к файлам с ФИО в имени) не попадают ни в отчёт, ни в журнал передачи.
ИНН медорганизации передаётся обязательно и законно [2]: это сведения об организации, а не о пациенте.
Неблагоприятные события — отдельный поток. С 1 сентября 2026 г. в мониторинг безопасности входят и сведения, которые ПО с ИИ со встроенной функцией передаёт по порядку сообщения о неблагоприятных событиях [9]. Объём данных там другой, и проектировать этот поток нужно отдельно, не расширяя «под него» телеметрию по приказу № 123.

Практический результат: схема регуляторной телеметрии

Схема состоит из десяти звеньев. Первые пять работают в контуре эксплуатации: в инфраструктуре заказчика или в облаке производителя, в зависимости от типа размещения. Остальные пять отвечают за проверку, отправку и контроль передачи в АИС «Росздравнадзор».

Журнал событий обработки. Каждая стадия конвейера (приём входа из PACS или МИС, проверка входа, инференс, выдача результата обратно в PACS или МИС) записывает исход обработки исследования. Журнал работает только на добавление: записи не удаляются и не правятся задним числом. В записи хранится минимум полей: псевдонимизированный ключ исследования (HMAC), время, стадия, исход, код ошибки, версия изделия и ИНН медорганизации.
Закрытие отчётного периода. По окончании периода события за него фиксируются, и поздние записи уже не меняют закрытый период.
Агрегатор. Считает ProcessedCount, Results, TotalErrors и значения Errors по кодам. Группирует результаты по изделию, версии, периоду и ИНН медорганизации.
Граница контура. Наружу выходят только агрегированные значения. Сырой журнал событий остаётся там, где проходила обработка.
Реестр регуляторных идентификаторов. Подставляет в отчёт наименование изделия, номер и дату РУ, версию из реестровой записи и код модели. Ничего не вводится вручную и не берётся из сборки.
Валидатор. Проверяет сообщение по XSD-схеме из WSDL регулятора, проверяет инварианты (сумма Errors не больше TotalErrors, согласованность с ProcessedCount) и сверяет РУ и версию с реестром. Сообщение с ошибкой дальше не уходит.
Отправщик. Получает токен по схеме client_credentials, кэширует его меньше чем на 5 часов, вызывает SOAP-метод sendreport и сохраняет полученные Id и статус.
Поллер статусов. По Id запрашивает итоговый статус методом getreportstatus и ждёт DONE или статуса ошибки. Передача не считается выполненной, пока итоговый статус не получен.
Контрольный журнал обмена и архив сообщений. Фиксирует каждую попытку отправки: тело сообщения или его хеш, время, ответы сервера, итоговый статус, статус в карточке ЛК и решения о повторной отправке.
Алерты. Сообщают ответственным о пропущенном периоде, ошибке валидации (VALIDATION_ERROR), отсутствии ответа от АИС, росте доли ошибок и расхождении версии в отчёте с версией в реестре.

Чем эта схема отличается от обычной «отправки метрик»:

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

Практический результат: контрольный журнал обмена

Журнал должен отвечать на три вопроса проверяющего или внутреннего аудитора: что отправили, приняли ли и на чём основаны цифры.

Журнал состоит из трёх разделов.

1. Журнал передач (одна запись на одну попытку отправки)

Идентификация передачи:

локальный ключ local_report_id, например MI-07 / 2.4.1 / 2026-09 / 7701234567, защищает от дублей;
отметка, тестовая ли это передача (IsTest).

Изделие:

наименование по РУ для сверки с реестром;
номер и дата РУ;
код модели и номер заявления в ЛК — связь с кабинетом;
версия в отчёте и версия в реестре, чтобы видеть расхождения.

Содержание отчёта:

отчётный период с часовым поясом, например 2026-09-01 … 2026-09-30;
список ИНН или OID медорганизаций;
итоговые значения ProcessedCount, Results, TotalErrors, например 1500 / 1450 / 50;
значения Errors по кодам, например DataExchangeFailure: 20;
ссылка на снимок агрегата, из которого получены цифры, чтобы их можно было воспроизвести;
хеш SHA-256 тела сообщения и ссылка на архивную копию как доказательство содержания.

Отправка и приём:

время отправки и номер попытки;
HTTP-код, Id и синхронный статус, например 200 и REQUEST_ACCEPTED, как подтверждение приёма.

Результат обработки:

итоговый статус из getreportstatus (например, DONE) и время его получения;
статус в карточке ЛК: «Корректные», «Неполные» или «Недостоверные»;
текст ошибки, если она была.

Решение о повторной отправке или корректировке и кто его принял.

2. Журнал версий и изменений (одна запись на релиз)

Номер версии, дата сборки, хеш артефакта.
Классификация изменения: меняется только номер версии или функциональность. От этого зависит процедура [7].
Номер и дата решения регулятора, дата изменения реестровой записи — основание для выката.
Дата выката в каждой медорганизации, чтобы группировать метрики по версиям.
Подтверждение тестовой передачи для этой версии.

3. Журнал доступа

Владелец учётной записи ЕСИА и кабинета.
client_id, место хранения client_secret, дата последней ротации секрета.
Кто и когда получал доступ к секрету.

Срок хранения журнала стоит связать как минимум со сроком действия порядка (до 31.12.2027) [2] и с внутренней системой менеджмента качества. В изученных регуляторных документах конкретный срок хранения не установлен.

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

Подключить телеметрию «на всякий случай» изделию, у которого в досье указано отсутствие функции, или продукту, который не является медизделием. Так возникает расхождение с документами.
Брать наименование и версию из сборки, а не из реестра, хотя сервер сверяет изделие по номеру и дате РУ [5].
Считать регуляторные метрики по продуктовой аналитике, из-за чего цифры потом невозможно воспроизвести.
Записывать все отказы в InternalDeviceFailure без разделения на сетевые сбои, плохой вход и отказы модели. Такой отчёт бесполезен для мониторинга [2].
Слепо повторять отправку при таймауте и плодить дубли.
Выкатывать новую версию раньше, чем изменена реестровая запись.
Смешивать технический отчёт с сообщением о неблагоприятном событии [9].
Хранить client_secret у заказчика в конфигурационном файле.

Когда хватит настройки, а когда нужна доработка

Хватит организационных мер и настройки, если:

изделие работает в облаке производителя, журнал событий и классификация ошибок уже есть, а клиентов немного;
можно временно подавать файл вручную через ЛК, если такой способ согласован в заявлении [5]. Это переходный вариант, потому что приказ говорит об автоматической передаче [2].

Нужна разработка, если:

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

Вывод

Приказ № 123 не обязывает каждую медицинскую нейросеть отчитываться перед регулятором. Он регулирует обмен для тех зарегистрированных изделий с ИИ, у которых встроенная функция автоматической передачи заявлена и реализована [2][4]. Для таких изделий передача данных становится частью продукта: со своей моделью данных, классификатором ошибок, контролем версий и журналом.

Последовательность действий:

проверить применимость по досье;
завести реестр регуляторных идентификаторов;
внедрить журнал обработки по стадиям и коды ошибок из инструкции [5];
пройти тестовую передачу;
согласовать с регулятором периодичность и правила корректировки;
запустить автоматическую отправку с проверкой статусов и вести контрольный журнал.

Перечень сведений и режим передачи стоит пересверять с Порядком и технической документацией регулятора при каждом их обновлении [2][5].

Источники

[1] roszdravnadzor.gov.ru — Приказ Росздравнадзора от 10.02.2026 № 123 (карточка документа) — https://www.roszdravnadzor.gov.ru/medproducts/monitoring/documents/90395

[2] roszdravnadzor.gov.ru — Приказ Росздравнадзора от 10.02.2026 № 123 и Порядок автоматической передачи (PDF) — https://www.roszdravnadzor.gov.ru/i/upload/images/2026/6/9/1780999381.11329-1-632563.pdf

[3] garant.ru — Приказ Федеральной службы по надзору в сфере здравоохранения от 10 февраля 2026 г. № 123 — https://www.garant.ru/products/ipo/prime/doc/414102657/

[4] promedizd.com — Постановление Правительства РФ от 30.11.2024 № 1684 (ред. от 03.08.2026) «Об утверждении Правил государственной регистрации медицинских изделий» — https://promedizd.com/pravilaregistraciimedizdeliy2025-1684/

[5] roszdravnadzor.gov.ru — Инструкция о передаче данных о функционировании медицинских изделий с технологией искусственного интеллекта через Личный кабинет заявителя Росздравнадзора (PDF, опубл. 10.12.2025; файл размещён на странице) — https://www.roszdravnadzor.gov.ru/medproducts/changesregdoc/features

[6] medvestnik.ru — Обновлён порядок передачи данных о медизделиях с ИИ в АИС — https://medvestnik.ru/content/news/obnovlen-poryadok-peredachi-dannyh-o-medizdeliyah-s-ii-v-ais.html

[7] roszdravnadzor.gov.ru — Особенности внесения изменений в документы, содержащиеся в регистрационном досье на ПО с применением технологий ИИ, являющееся медицинским изделием — https://www.roszdravnadzor.gov.ru/medproducts/changesregdoc/features

[8] roszdravnadzor.gov.ru — Для заявителей государственной регистрации медицинских изделий (новость от 06.02.2026) — https://roszdravnadzor.gov.ru/medproducts/registration/news/46398

[9] roszdravnadzor.gov.ru — Приказ Минздрава России от 26.05.2026 № 540н «Об утверждении Порядка осуществления мониторинга безопасности медицинских изделий…» (PDF) — https://roszdravnadzor.gov.ru/i/upload/images/2026/6/9/1781004568.34084-1-1036488.pdf

[10] consultant.ru — Статья 13. Соблюдение врачебной тайны. Федеральный закон от 21.11.2011 № 323-ФЗ — https://www.consultant.ru/document/cons_doc_LAW_121895/9f906d460f9454a8a0d290738d9fc2798c1e865a/