Для программного медицинского изделия клинические данные — это не просто большой массив медицинской информации и не отчет о точности алгоритма на тестовой выборке. Производителю нужно показать, что данные относятся к заявленному назначению, отражают будущую целевую популяцию и условия применения, получены и размечены контролируемым способом, а результаты относятся именно к той версии программного изделия, которая заявляется к регистрации или исследованию.
Для систем с искусственным интеллектом требования к доказательной базе особенно чувствительны к происхождению данных, независимости клинической выборки от разработки, выбору референтного метода, настройке порогов, анализу ошибок и возможности воспроизвести расчет заявленных показателей. Большой объем данных сам по себе не компенсирует методологические дефекты.
| Важно на дату актуализации. С 1 сентября 2026 года действует приказ Минздрава России от 13.05.2026 № 421н, заменивший приказ № 885н. В новом порядке для программного обеспечения с применением технологий искусственного интеллекта прямо предусмотрена оценка достоверности клинической связи, аналитической и клинической валидации, а также анализ эффективности, безопасности и качества использования систем ИИ. Для заявлений на испытания, поданных до 1 сентября 2026 года, действует переходное правило. |
Что относится к клиническим данным
Источник клинических данных зависит от назначения изделия и регистрационной ситуации. В доказательную базу могут входить результаты анализа научной литературы и клинического опыта, данные об аналогах при наличии обоснованной сопоставимости, результаты ретроспективных или проспективных исследований, данные медицинских организаций, результаты клинических испытаний и сведения, полученные после начала применения изделия. Ключевой вопрос не в происхождении данных как таковом, а в том, позволяют ли они надежно подтвердить конкретные заявленные клинические характеристики.
- Литературные данные полезны для подтверждения клинической связи, обоснования медицинской значимости показателя, выбора референтного метода и ожидаемого диапазона характеристик, но не всегда заменяют собственную клиническую валидацию конкретной версии ПО.
- Ретроспективные медицинские данные могут быть пригодны для клинической валидации, если заранее определены критерии отбора, референтный метод, правила исключения, статистический план и обеспечена независимость от разработки алгоритма.
- Проспективные данные необходимы, когда вопрос безопасности или эффективности нельзя надежно закрыть анализом уже имеющихся данных, либо когда требуется оценить реальное взаимодействие пользователя с изделием и влияние результата ПО на клинический процесс.
- Данные реальной эксплуатации после регистрации важны для мониторинга качества, безопасности, смещения характеристик и появления новых рисков, но их нельзя автоматически использовать как замену исходному клиническому доказательству без анализа качества и пригодности.
Три уровня доказательства для ПО с ИИ
Практически доказательную базу удобно строить как последовательность из трех связанных уровней. Они отвечают на разные вопросы и не должны подменять друг друга.
| Уровень | На какой вопрос отвечает | Что должен показать производитель |
|---|---|---|
| Клиническая связь | Имеет ли рассчитываемый показатель медицинский смысл для заявленного назначения? | Связь входных данных, выходного показателя и клинического состояния/решения подтверждена литературой, практикой и принятой медицинской логикой. |
| Аналитическая валидация | Корректно ли ПО вычисляет или формирует заявленный результат на определенных входных данных? | Показатели алгоритма рассчитаны на контролируемом наборе данных; определены правила подготовки данных, пороги, метрики и пределы применимости. |
| Клиническая валидация | Работает ли результат ПО с достаточной эффективностью и безопасностью в целевой популяции и реальных условиях применения? | Независимые клинические данные подтверждают заявленные характеристики и позволяют оценить ошибки, риски и применимость результата к будущим пользователям и пациентам. |
Как производителю выстроить работу с клиническими данными
1. Начните с назначения изделия и клинического сценария
Зафиксируйте, для кого предназначено изделие, кто является пользователем, какие входные данные оно получает, какой результат формирует и какое действие предполагается после получения результата. Для ПО поддержки принятия решений отдельно определите, является ли результат самостоятельным основанием для решения, вторым мнением, триажем, приоритизацией или вспомогательным сигналом.
2. Разложите назначение на проверяемые клинические утверждения
Не ограничивайтесь формулировкой «повышает качество диагностики». Для каждого утверждения укажите измеримый показатель: например, чувствительность и специфичность выявления состояния, точность количественного измерения, долю корректно классифицированных случаев, время до принятия решения, число пропущенных критических состояний или иной клинически значимый результат.
3. Зафиксируйте исследуемую версию ПО и модели
В клинических данных должны однозначно прослеживаться номер версии, сборка, модель/алгоритм, конфигурация, пороги, используемые справочники и иные элементы, влияющие на результат. Для воспроизводимости желательно фиксировать хэш сборки или иной неизменяемый идентификатор. Изменение алгоритма после начала исследования требует документированной оценки влияния и не должно смешиваться с результатами предыдущей версии.
4. Определите целевую популяцию
Клиническая выборка должна соответствовать будущему применению изделия по возрасту, полу, заболеванию, тяжести состояния, сопутствующей патологии и другим клинически значимым признакам. Если изделие заявляется для нескольких популяций или условий применения, заранее определите, нужны ли отдельные оценки по подгруппам.
5. Опишите происхождение каждого набора данных
Зафиксируйте медицинскую организацию или источник, период сбора, критерии отбора, тип исследования, оборудование/модальность, правила выгрузки, степень ретроспективности, наличие повторных исследований одного пациента, способ обезличивания и правовое основание доступа. Не используйте наборы с неясным происхождением и невозможностью проверить первичные данные или метод разметки.
6. Разделите данные разработки и клинической оценки
Обучающая, настроечная/валидационная и независимая клиническая выборки должны быть логически и фактически разделены. Один и тот же пациент, исследование или почти идентичные производные данные не должны попадать в разные части набора. Клиническая выборка перестает быть независимой, если по ее результатам подбирали пороги, меняли признаки, дообучали модель или выбирали лучшую версию.
7. Проверьте репрезентативность и отсутствие систематических перекосов
Сравните распределение классов, возрастов, пола, тяжести заболевания, оборудования, медицинских организаций и других значимых факторов с заявленной областью применения. Если данные собраны только в одном центре, на одном типе оборудования или на специально отобранных «чистых» случаях, необходимо оценить ограничение переносимости результата.
8. Установите критерии включения и исключения до анализа результатов
Критерии должны быть клинически и методологически обоснованы. Исключение сложных, пограничных или технически неудобных случаев после просмотра результатов алгоритма создает риск искусственного улучшения метрик. Все исключения должны быть прослеживаемы и объяснимы.
9. Проверьте качество входных данных
Определите минимально допустимое качество изображения, сигнала, лабораторного результата или иной информации. Зафиксируйте правила обработки поврежденных, неполных и нестандартных данных. Если ПО само оценивает качество входа и отказывает в анализе, частота и причины таких отказов также должны быть частью клинической оценки.
10. Выберите независимый референтный метод
Референтный метод должен соответствовать клинической задаче и быть максимально независимым от исследуемого ПО. Это может быть результат морфологии, лабораторного подтверждения, экспертного консенсуса, длительного наблюдения, валидированного измерительного метода или иного принятого стандарта. Нельзя считать корректным референтом решение, которое уже было сформировано с использованием исследуемого алгоритма.
11. Формализуйте разметку и разрешение разногласий
Если референт формируют эксперты, задайте требования к квалификации, количество экспертов, порядок независимой оценки, правила консенсуса и разрешения расхождений. Для многоклассовых задач нужен словарь категорий и правила пограничных случаев. История разметки должна сохраняться.
12. Заранее определите метрики
Метрики выбирают по клинической задаче. Для классификации это могут быть чувствительность, специфичность, прогностические значения, AUC и другие показатели; для сегментации — Dice/IoU и клинически значимые ошибки границ; для количественных показателей — смещение, абсолютная ошибка, пределы согласия. Не используйте одну агрегированную метрику, если она скрывает клинически опасные ошибки.
13. Зафиксируйте пороги и критерии успеха до открытия клинической выборки
Порог классификации, допустимая ошибка и критерий успешности должны быть определены заранее. Настройка порога по итогам независимой клинической выборки превращает ее в часть разработки. Если порог изменен, для подтверждения результата требуется новая независимая оценка.
14. Обоснуйте размер выборки и статистический план
Размер набора должен быть связан с основной конечной точкой, ожидаемой частотой события, требуемой точностью доверительных интервалов и анализом подгрупп. Для редких состояний важно заранее оценить, будет ли достаточно положительных случаев для устойчивой оценки чувствительности.
15. Анализируйте не только средние показатели, но и ошибки
Отдельно оцените ложноположительные, ложноотрицательные и отказные результаты, ошибки по подгруппам, случаи низкого качества данных, причины расхождения с референтом и потенциальные последствия для пациента. Риск редкой, но клинически критичной ошибки может быть важнее высокого среднего показателя.
16. Проверьте внешнюю переносимость
По возможности клиническая валидация должна включать данные, отличающиеся от среды разработки: другие медицинские организации, оборудование, популяции, временные периоды. Это снижает риск того, что алгоритм фактически запомнил особенности локального потока данных.
17. Для вероятностных результатов оцените калибровку
Если ПО выдает вероятность, риск или балл, проверьте не только ранжирование, но и соответствие числовой оценки реальной частоте события. Неверно откалиброванные вероятности могут приводить к ошибочным клиническим решениям даже при хорошем AUC.
18. Оцените взаимодействие с пользователем, если оно влияет на клинический эффект
Если заявленный эффект достигается через врача или иного специалиста, может потребоваться оценка результата в реальном сценарии: понятность вывода, интерпретация, влияние на время и качество решения, реакция на предупреждения и риск чрезмерного доверия к алгоритму.
19. Обеспечьте воспроизводимость расчета
Сохраните неизменяемую версию набора данных, идентификаторы записей, правила предобработки, скрипты или формализованный алгоритм расчета метрик, версии библиотек, значения порогов и правила исключений. Независимый проверяющий должен иметь возможность повторить расчет ключевых показателей.
20. Свяжите результаты с менеджментом риска и документацией
Клинические ошибки должны быть отражены в файле менеджмента риска, а ограничения — в эксплуатационной документации и, при необходимости, в интерфейсе. Если клинические данные показывают ограничение для определенной популяции, оборудования или качества входа, это нельзя оставлять только в отчете исследования.
Отдельно для систем с искусственным интеллектом
- Нельзя смешивать обучение и клиническую проверку. Если данные использовались для обучения, выбора архитектуры, настройки гиперпараметров, порога или отбора версии, они не должны одновременно выступать независимым клиническим подтверждением этой же версии.
- Защищайте выборку от утечки по пациентам. Повторные исследования одного пациента, серии одного исследования, кадры одной видеозаписи и производные одного исходного объекта должны попадать только в одну часть набора.
- Фиксируйте модель и все параметры, влияющие на результат. Для генеративных или стохастических компонентов дополнительно задавайте условия воспроизводимости, ограничения использования и способ контроля вариативности результатов.
- Не допускайте неконтролируемого дообучения во время клинической оценки. Если система способна непрерывно обучаться, режим исследования должен обеспечивать управляемость изменений и возможность установить, какой вариант алгоритма сформировал каждый результат.
- Проверяйте подгруппы и редкие сценарии. Высокая общая метрика может скрывать существенное ухудшение для отдельных возрастных групп, патологий, типов оборудования или условий получения данных.
- Отдельно учитывайте дрейф данных после внедрения. Изменение оборудования, протоколов исследования, популяции пациентов или форматов данных может снижать характеристики модели без изменения ее кода.
- Для ИИ, предназначенного для анализа медицинских изображений, учитывайте специальные требования действующих правил регистрации и актуальные технические требования Росздравнадзора к передаче информации о функционировании ПО с ИИ, если они применимы к конкретному изделию и регистрационному маршруту.
Правовой режим клинических данных
Медицинские данные часто одновременно относятся к персональным данным и сведениям, составляющим врачебную тайну. Производителю следует заранее определить вместе с медицинской организацией правовое основание обработки и передачи данных, роли сторон, объем передаваемой информации, порядок обезличивания или псевдонимизации, сроки хранения, доступы и меры защиты. Само удаление ФИО не гарантирует, что набор перестал быть персональными данными, если пациента можно идентифицировать по совокупности оставшихся признаков.
В клиническом досье важно сохранять не персональные идентификаторы пациента, а доказательство законности получения данных, правила их обработки и прослеживаемость до первичного источника в той мере, в которой это допускается законодательством и организацией исследования.
Практический инструмент 1. Минимальный паспорт клинического набора данных
| Параметр | Что фиксировать |
|---|---|
| Назначение набора | Для какой клинической задачи и какого этапа используется: обучение, настройка, аналитическая валидация, клиническая валидация, пострегистрационный контроль. |
| Источник | Медицинская организация/реестр/исследование, период сбора, способ получения данных. |
| Популяция | Критерии включения и исключения, возраст, пол, диагноз, тяжесть, сопутствующие факторы и иные значимые признаки. |
| Объем и структура | Число пациентов и исследований, количество положительных/отрицательных случаев, классы, подгруппы. |
| Оборудование и условия | Типы аппаратов, производители, протоколы получения данных, версии форматов, настройки, клинические условия. |
| Повторные наблюдения | Правила учета повторных исследований одного пациента и предотвращения пересечения между выборками. |
| Референтный метод | Что считается истинным результатом, кем и как подтверждено, порядок разрешения расхождений. |
| Разметка | Инструкция, квалификация разметчиков, число экспертов, слепая оценка, версии аннотаций. |
| Качество данных | Критерии качества, доля исключений, пропуски, артефакты, некорректные форматы. |
| Предобработка | Нормализация, ресайзинг, фильтрация, преобразования, ручные этапы и используемые инструменты. |
| Разделение выборок | Правила train/validation/test/clinical; доказательство отсутствия утечки по пациентам и производным данным. |
| Версия ПО/ИИ | Версия приложения, модель/веса, пороги, конфигурация, хэш или иной идентификатор. |
| Статистический план | Основные и дополнительные метрики, критерии успеха, доверительные интервалы, подгруппы, работа с пропусками. |
| Правовой режим | Основание использования данных, роли сторон, обезличивание/псевдонимизация, доступ и хранение. |
| Заморозка и контроль | Дата фиксации набора, контрольная сумма/версия, журнал изменений и ответственный. |
Практический инструмент 2. Чек-лист производителя по клиническим данным ПО и ИИ
| № | Контрольный вопрос | Статус | Комментарий |
|---|---|---|---|
| 1 | Назначение ПО сформулировано однозначно и совпадает во всех документах. | ☐ Да ☐ Нет ☐ Н/П | |
| 2 | Определены пользователь, целевая популяция и клинический сценарий применения. | ☐ Да ☐ Нет ☐ Н/П | |
| 3 | Составлен перечень клинических утверждений, требующих подтверждения. | ☐ Да ☐ Нет ☐ Н/П | |
| 4 | Для каждого утверждения определена измеримая конечная точка или метрика. | ☐ Да ☐ Нет ☐ Н/П | |
| 5 | Зафиксирована версия ПО, сборка и конфигурация исследуемого изделия. | ☐ Да ☐ Нет ☐ Н/П | |
| 6 | Для ИИ зафиксированы модель/веса, пороги и иные параметры, влияющие на результат. | ☐ Да ☐ Нет ☐ Н/П | |
| 7 | Определено назначение каждого набора данных: обучение, настройка, техническая/аналитическая или клиническая оценка. | ☐ Да ☐ Нет ☐ Н/П | |
| 8 | Обучающие, настроечные и клинические данные разделены. | ☐ Да ☐ Нет ☐ Н/П | |
| 9 | Исключено пересечение пациентов и производных одного исходного объекта между выборками. | ☐ Да ☐ Нет ☐ Н/П | |
| 10 | Клиническая выборка не использовалась для выбора версии, порогов или дообучения. | ☐ Да ☐ Нет ☐ Н/П | |
| 11 | Документировано происхождение каждого набора данных. | ☐ Да ☐ Нет ☐ Н/П | |
| 12 | Зафиксированы период и медицинские организации, из которых получены данные. | ☐ Да ☐ Нет ☐ Н/П | |
| 13 | Критерии включения и исключения определены до анализа результатов алгоритма. | ☐ Да ☐ Нет ☐ Н/П | |
| 14 | Популяция клинического набора соответствует заявленной области применения. | ☐ Да ☐ Нет ☐ Н/П | |
| 15 | Оценена представленность клинически значимых подгрупп. | ☐ Да ☐ Нет ☐ Н/П | |
| 16 | Оценено разнообразие оборудования, протоколов и условий получения данных. | ☐ Да ☐ Нет ☐ Н/П | |
| 17 | Определены минимальные требования к качеству входных данных. | ☐ Да ☐ Нет ☐ Н/П | |
| 18 | Зафиксированы правила работы с пропусками, поврежденными и нестандартными данными. | ☐ Да ☐ Нет ☐ Н/П | |
| 19 | Определен независимый референтный метод. | ☐ Да ☐ Нет ☐ Н/П | |
| 20 | Референтный результат не формировался с использованием исследуемого ПО. | ☐ Да ☐ Нет ☐ Н/П | |
| 21 | Документирована квалификация экспертов/разметчиков и правила консенсуса. | ☐ Да ☐ Нет ☐ Н/П | |
| 22 | Сохранены версии разметки и история исправлений. | ☐ Да ☐ Нет ☐ Н/П | |
| 23 | Основные и вторичные метрики определены заранее. | ☐ Да ☐ Нет ☐ Н/П | |
| 24 | Критерии успешности и пороги зафиксированы до открытия независимой клинической выборки. | ☐ Да ☐ Нет ☐ Н/П | |
| 25 | Размер выборки статистически обоснован. | ☐ Да ☐ Нет ☐ Н/П | |
| 26 | Предусмотрены доверительные интервалы и анализ неопределенности. | ☐ Да ☐ Нет ☐ Н/П | |
| 27 | Проведен отдельный анализ ложноположительных результатов. | ☐ Да ☐ Нет ☐ Н/П | |
| 28 | Проведен отдельный анализ ложноотрицательных результатов. | ☐ Да ☐ Нет ☐ Н/П | |
| 29 | Проведен анализ отказов алгоритма и случаев непригодного входа. | ☐ Да ☐ Нет ☐ Н/П | |
| 30 | Проведен анализ показателей по ключевым подгруппам. | ☐ Да ☐ Нет ☐ Н/П | |
| 31 | Оценена внешняя переносимость на данные, отличающиеся от среды разработки. | ☐ Да ☐ Нет ☐ Н/П | |
| 32 | Для вероятностных выходов оценена калибровка, если применимо. | ☐ Да ☐ Нет ☐ Н/П | |
| 33 | Для решений с участием пользователя оценено влияние интерфейса и интерпретации результата, если применимо. | ☐ Да ☐ Нет ☐ Н/П | |
| 34 | Сохранены версия клинического набора и контрольная сумма/иной идентификатор. | ☐ Да ☐ Нет ☐ Н/П | |
| 35 | Сохранены скрипты или формализованные правила расчета метрик. | ☐ Да ☐ Нет ☐ Н/П | |
| 36 | Расчет ключевых показателей может быть воспроизведен независимым проверяющим. | ☐ Да ☐ Нет ☐ Н/П | |
| 37 | Клинические ошибки и ограничения отражены в менеджменте риска. | ☐ Да ☐ Нет ☐ Н/П | |
| 38 | Ограничения и условия применимости перенесены в эксплуатационную документацию. | ☐ Да ☐ Нет ☐ Н/П | |
| 39 | Правовое основание получения и обработки медицинских данных документировано. | ☐ Да ☐ Нет ☐ Н/П | |
| 40 | Определены правила обезличивания/псевдонимизации, доступа и хранения данных. | ☐ Да ☐ Нет ☐ Н/П | |
| 41 | Есть процедура оценки влияния обновлений ПО/модели на клинические доказательства. | ☐ Да ☐ Нет ☐ Н/П |
Типичные ошибки производителя
- клиническая выборка фактически использовалась для настройки модели или порога;
- обучение и клиническая оценка содержат исследования одного и того же пациента;
- в набор попали только удобные или качественные случаи, не соответствующие реальной практике;
- референтный метод не определен либо зависит от вывода исследуемого алгоритма;
- метрики выбраны после просмотра результатов и не были предусмотрены программой;
- показана только общая точность без анализа ложноположительных и ложноотрицательных ошибок;
- не проведен анализ значимых подгрупп и типов оборудования;
- не зафиксирована версия модели, поэтому невозможно доказать, какой алгоритм был испытан;
- изменение модели после клинической оценки считается «технической правкой» без анализа влияния на доказательную базу;
- источник и правовой режим данных не позволяют подтвердить законность их использования или проследить метод разметки;
- расчет метрик невозможно повторить из-за отсутствия замороженного набора, кода расчета или правил исключения.
Практический итог
Хорошая клиническая доказательная база для программного медицинского изделия строится вокруг прослеживаемой цепочки: назначение → клиническое утверждение → целевая популяция → независимые данные → референтный метод → заранее определенная метрика → критерий успеха → анализ ошибок → конкретная версия ПО. Для ИИ к этой цепочке добавляются строгая изоляция данных разработки от клинической проверки, управление изменениями модели и подтверждаемая воспроизводимость расчета. Если производитель не может восстановить эту цепочку по документам, объем набора данных сам по себе не делает клиническое доказательство надежным.
Нормативная база
Материал актуализирован по состоянию на 10 сентября 2026 года. При подготовке клинических данных для программных медицинских изделий и систем с ИИ следует учитывать применимость следующих документов и источников:
- Приказ Минздрава России от 13.05.2026 № 421н «Об утверждении Порядка проведения оценки соответствия медицинских изделий в форме технических испытаний, токсикологических исследований, клинических испытаний в целях государственной регистрации медицинских изделий» — действует с 01.09.2026 до 01.09.2032. Официальный/справочный источник
- Постановление Правительства РФ от 30.11.2024 № 1684 «Об утверждении Правил государственной регистрации медицинских изделий» — действующие правила государственной регистрации, включая специальные положения для ПО с применением технологий искусственного интеллекта. Официальный/справочный источник
- Федеральный закон от 21.11.2011 № 323-ФЗ «Об основах охраны здоровья граждан в Российской Федерации», включая требования к обращению медицинских изделий и защите сведений о состоянии здоровья. Официальный/справочный источник
- Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» — применим к обработке персональных медицинских данных при формировании и использовании клинических наборов. Официальный/справочный источник
- Методические рекомендации Росздравнадзора от 07.05.2024 по экспертизе качества, эффективности и безопасности медицинских изделий в части программного обеспечения для государственной регистрации в национальной системе. Официальный/справочный источник
- Росздравнадзор: особенности внесения изменений в регистрационное досье ПО с применением технологий искусственного интеллекта, являющегося медицинским изделием. Официальный/справочный источник
- ГОСТ Р ИСО 14155-2022 «Клинические исследования медицинских изделий, проводимые с участием человека в качестве субъекта. Надлежащая клиническая практика». Официальный/справочный источник
- ГОСТ IEC 62304-2022 «Изделия медицинские. Программное обеспечение. Процессы жизненного цикла». Официальный/справочный источник
- ГОСТ ISO 14971-2021 «Изделия медицинские. Применение менеджмента риска к медицинским изделиям». Официальный/справочный источник
- ГОСТ Р 59921.5-2022 «Системы искусственного интеллекта в клинической медицине. Часть 5. Требования к структуре и порядку применения набора данных для обучения и тестирования алгоритмов». Официальный/справочный источник
- ГОСТ Р 59921.11-2025 «Системы искусственного интеллекта в клинической медицине. Наборы данных для тестирования алгоритмов. Методы контроля набора данных на универсальность и структурированность». Официальный/справочный источник
Переходное правило по приказу № 885н. Приказ Минздрава России от 30.08.2021 № 885н признан утратившим силу с 1 сентября 2026 года. Если заявление о проведении соответствующих испытаний или исследований было подано до этой даты, оценка соответствия проводится по порядку, действовавшему до вступления в силу приказа № 421н.
Связанные материалы
- «Клинические испытания медицинских изделий: какие бывают и когда они нужны»;
- «Как подготовить медицинское изделие к клиническим испытаниям: пошаговый чек-лист»;
- «Программа клинических испытаний медицинского изделия: структура, обязательные разделы и типичные ошибки»;
- «Как выбрать медицинскую организацию для проведения клинических испытаний медицинского изделия»;
- «Менеджмент риска медицинского изделия: как связать риски, испытания и клинические доказательства»;
- «Программное обеспечение как медицинское изделие: когда ПО подпадает под регулирование и что готовить к регистрации».
Практические документы и чек-листы
- «Минимальный паспорт клинического набора данных» — включен в материал;
- «Чек-лист производителя по клиническим данным ПО и ИИ» — включен в материал;
- рекомендуемый рабочий документ «Матрица клинических утверждений» (утверждение → популяция → источник данных → референтный метод → метрика → критерий успеха → версия ПО);
- рекомендуемый «Журнал наборов данных» (источник → назначение → версия → дата заморозки → контрольная сумма → права доступа → изменения);
- для ИИ — «Лист фиксации версии модели» (версия ПО → версия модели/весов → порог → библиотеки/окружение → дата развертывания → хэш → ответственный).
Актуальность материала
Актуализировано 10 сентября 2026 года. Материал учитывает вступление в силу приказа Минздрава России № 421н с 1 сентября 2026 года, действующие Правила государственной регистрации медицинских изделий по постановлению Правительства РФ № 1684, методические материалы Росздравнадзора по программному обеспечению и действующие стандарты по клиническим исследованиям, жизненному циклу медицинского ПО, менеджменту риска и наборам данных для систем ИИ. Перед началом конкретного проекта производителю следует повторно проверить актуальные редакции нормативных документов и применимость специальных требований к конкретному назначению, классу риска, типу данных и регистрационному маршруту.