ИИ способен ускорять анализ изображений, выявлять паттерны, измерять структуры и приоритизировать исследования. Но доказать ценность такой системы — значит подтвердить не только точность алгоритма, а всю цепочку от входных данных до безопасного клинического применения.
Системы искусственного интеллекта уже применяются для анализа рентгенограмм, КТ, МРТ, ультразвуковых исследований, офтальмологических изображений, цифровых гистологических препаратов и других видов медицинских изображений. Они могут помогать выявлять патологические признаки, сегментировать органы и очаги, выполнять измерения, классифицировать находки, сравнивать исследования в динамике и приоритизировать случаи для просмотра специалистом.
Однако одинаковая формулировка «алгоритм анализирует медицинские изображения» может скрывать принципиально разные функции и уровни риска. Система, которая автоматически измеряет размер образования, система, которая сортирует исследования по срочности, и система, которая формирует диагностическое заключение, требуют разных доказательств и разных способов контроля.
Ключевой принцип: оценивать нужно не абстрактный «ИИ», а конкретную медицинскую функцию конкретной версии системы в конкретной целевой популяции, на определенном типе изображений и в заявленном сценарии применения.
Короткий ответ
| Вопрос | Короткий ответ | Практический вывод |
|---|---|---|
| Что умеет ИИ | Детекция, классификация, сегментация, измерение, количественный анализ, приоритизация, сравнение в динамике, контроль качества изображений. | Нужно оценивать именно ту функцию, которая заявлена производителем. |
| Что нужно доказать | Клиническую связь, аналитическую и клиническую валидацию, эффективность, безопасность и качество использования. | Эти направления прямо отражены в приказе Минздрава № 421н для ПО с ИИ. |
| Какие данные нужны | Верифицированные, независимые от обучения, репрезентативные и достаточно разнородные медицинские данные. | Данные должны соответствовать целевой популяции, оборудованию и реальному сценарию применения. |
| Какие метрики нужны | Зависят от задачи: чувствительность/специфичность, AUC, PPV/NPV, F1, Dice/IoU, ошибки измерений, ложные срабатывания и др. | Одна «accuracy» почти никогда не описывает систему полностью. |
| Что особенно важно | Анализ ошибок, устойчивость к разным аппаратам и качеству изображений, человеческий фактор, контроль версий и мониторинг после внедрения. | Средняя метрика может скрывать клинически опасные подгруппы и режимы отказа. |
1. Что именно может делать ИИ с медицинским изображением
Перед оценкой доказательств нужно определить тип задачи. Метрики, дизайн испытаний и клинический смысл результата зависят от того, что система делает с изображением.
| Тип задачи | Что делает система | Что становится критичным при оценке |
|---|---|---|
| Детекция | Находит объект или патологический признак: узел, перелом, кровоизлияние, подозрительный участок. | Доля пропущенных значимых объектов; ложные срабатывания; локализация. |
| Классификация | Относит исследование, область или объект к классу: норма/патология, тип изменения, категория риска. | Чувствительность, специфичность, PPV/NPV, AUC, матрица ошибок. |
| Сегментация | Выделяет контуры органа, очага, структуры или зоны интереса. | Совпадение с эталонной разметкой, устойчивость границ, клиническая пригодность результата. |
| Измерение | Определяет размер, объем, плотность, площадь, расстояние или иной количественный показатель. | Систематическая ошибка, разброс, воспроизводимость, пределы согласия. |
| Приоритизация | Изменяет порядок просмотра исследований, выделяя потенциально срочные случаи. | Время до просмотра критических случаев; доля пропусков; влияние на очередь. |
| Сравнение в динамике | Сопоставляет последовательные исследования и оценивает изменение объекта. | Стабильность сопоставления, корректность измерения динамики, устойчивость к различиям протоколов. |
| Контроль качества | Определяет непригодность изображения, артефакты, неполное поле исследования, технические ошибки. | Чувствительность к дефектам и ложные отклонения пригодных исследований. |
2. Высокая точность алгоритма — еще не клиническое доказательство
Алгоритм может показывать высокий результат на тестовой выборке и при этом работать хуже в другой клинике. Причины — отличия оборудования, протоколов исследования, распространенности заболеваний, структуры пациентов, качества изображений и даже локальных правил подготовки данных.
Поэтому доказательная цепочка должна включать несколько уровней:
- клиническая связь — действительно ли анализируемый признак связан с медицинским состоянием или решением, для которого применяется система;
- аналитическая валидация — корректно ли алгоритм измеряет, выделяет, классифицирует или обнаруживает то, что должен;
- клиническая валидация — сохраняет ли система заявленные характеристики на релевантных клинических данных и в целевой популяции;
- оценка безопасности — какие ошибки возможны и к каким клиническим последствиям они приводят;
- оценка использования — как система взаимодействует с врачом и рабочим процессом и не создает ли новых рисков.
Именно такой подход отражен в действующем приказе Минздрава России № 421н: при клинических испытаниях ПО с применением ИИ оцениваются достоверность клинической связи, аналитическая и клиническая валидация, а также эффективность, безопасность и качество использования системы.
3. Набор данных — часть доказательства, а не техническая деталь
Для ИИ качество доказательства напрямую зависит от того, на каких данных система обучалась, настраивалась и проверялась. Даже корректная статистика не компенсирует нерепрезентативную или «протекающую» выборку.
| Требование к данным | Что проверить | Почему это важно |
|---|---|---|
| Независимость от обучения | Тестовые и подтверждающие данные не должны полностью или частично использоваться для обучения или калибровки системы. | Иначе результат завышает реальную способность алгоритма обобщать. |
| Разделение по пациентам | Изображения одного пациента не должны одновременно попадать в обучающую и независимую тестовую выборки. | Иначе возникает утечка информации между выборками. |
| Репрезентативность | В выборке должны быть представлены характеристики целевой популяции и клинические сценарии применения. | Нельзя автоматически переносить результат на группы, которых почти не было в испытании. |
| Разные организации | Желательны данные из нескольких медицинских организаций. | Позволяет проверить устойчивость к локальным особенностям практики. |
| Разное оборудование | Данные должны учитывать модели/производителей оборудования и параметры, которые входят в заявленную область применения. | Особенно важно для КТ, МРТ, рентгенографии, УЗИ и цифровой патологии. |
| Качество изображений | Нужны не только «идеальные» исследования, но и реалистичные вариации качества, артефакты и пограничные случаи. | В реальной практике система будет встречать неоднородные данные. |
| Документированное происхождение | Должны быть понятны источники данных, критерии включения/исключения и способ формирования выборки. | Без этого нельзя оценить смещение и применимость результатов. |
4. Эталонная разметка: с чем сравнивают алгоритм
Алгоритм нельзя оценить без корректного референсного стандарта — способа определить, какой ответ считается истинным. Для разных задач эталон может формироваться по-разному: заключением одного или нескольких профильных специалистов, консенсусом экспертов, результатами морфологической верификации, последующего наблюдения, лабораторного исследования или иным клинически обоснованным методом.
Чем сложнее и субъективнее задача, тем важнее описать процесс формирования эталона. Если два эксперта часто расходятся между собой, «ошибка алгоритма» относительно одного из них может отражать не слабость системы, а неопределенность самой клинической задачи.
- кто выполнял разметку и какова квалификация специалистов;
- сколько экспертов участвовало;
- были ли эксперты ослеплены к результату системы и дополнительным данным;
- как разрешались разногласия;
- какие правила и терминология использовались;
- как контролировалось качество разметки;
- что считалось истинным результатом в пограничных случаях.
5. Метрики нужно выбирать по клинической задаче
Универсальной метрики для медицинского ИИ нет. Accuracy может выглядеть высокой даже у слабой системы, если один класс сильно преобладает. Например, при редком заболевании алгоритм, который почти всегда отвечает «норма», может иметь высокую общую точность и одновременно быть непригодным для скрининга.
| Задача | Примеры метрик | Главный клинический вопрос |
|---|---|---|
| Классификация / диагностика | Чувствительность, специфичность, PPV, NPV, ROC-AUC, F1, матрица ошибок. | Какая ошибка клинически опаснее: пропуск или ложное подозрение? Какова распространенность состояния? |
| Детекция объектов | Чувствительность на объект/исследование, число ложных срабатываний на исследование, метрики локализации. | Не скрываются ли пропуски мелких или сложных объектов средней метрикой? |
| Сегментация | Dice, IoU и показатели расстояния между контурами. | Соответствует ли хорошее геометрическое совпадение реальной клинической задаче? |
| Измерение | MAE/ошибка, смещение, повторяемость, воспроизводимость, пределы согласия. | Допустима ли ошибка для клинического решения? |
| Приоритизация | Время до просмотра, чувствительность к критическим случаям, влияние на очередь. | Ускоряет ли система нужные случаи, не задерживая остальные опасным образом? |
| Прогноз риска | Дискриминация, калибровка, клиническая полезность порогов. | Соответствуют ли численные вероятности реальному риску и решениям врача? |
6. Порог решения — часть медицинской функции
Для многих алгоритмов итог «обнаружено / не обнаружено» зависит от выбранного порога. Изменение порога меняет баланс чувствительности и специфичности. Поэтому нельзя оценивать только AUC или усредненную метрику: нужно понимать, при каком рабочем пороге система будет использоваться и какие последствия имеют ошибки по обе стороны порога.
Рабочий порог должен быть связан с назначением. Для триажа критической патологии допустим один баланс ошибок, для подтверждающего диагностического инструмента — другой. Если пользователь может самостоятельно менять порог, это должно быть учтено в документации, управлении рисками и доказательствах.
7. Внешняя валидация: главный тест способности алгоритма обобщать
Внутренняя тестовая выборка показывает, что модель работает на данных, близких к разработке. Внешняя валидация отвечает на более важный вопрос: сохранится ли результат за пределами исходного датасета или медицинской организации.
Сильнее выглядят доказательства, в которых подтверждающая выборка отличается от обучающей хотя бы по одному значимому измерению: организация, оборудование, география, временной период или структура пациентов. Еще более информативным может быть проспективное исследование в реальном рабочем процессе, если задача требует оценки взаимодействия системы с пользователем.
8. Разнородность изображений и устойчивость системы
Медицинские изображения особенно чувствительны к технической неоднородности: разные аппараты, реконструкционные алгоритмы, разрешение, поле зрения, протоколы, уровни шума и артефакты способны менять характеристики ИИ. ГОСТ Р 59921.7-2022 отдельно предусматривает проверку способности и устойчивости системы при работе с разнородными данными и изображениями различного качества.
| Источник вариативности | Что целесообразно включить в проверку |
|---|---|
| Оборудование | Разные производители и модели диагностических устройств. |
| Протокол | Разные параметры получения и реконструкции изображения в пределах заявленного назначения. |
| Разрешение и размеры | Полный допустимый диапазон входных данных. |
| Артефакты | Движение, металл, шум, обрезанное поле, дефекты сканирования и иные реалистичные искажения. |
| Формат и передача | Корректная обработка заявленных форматов и ошибок входных данных. |
| Нетипичные случаи | Редкие, пограничные и сложные клинические ситуации. |
9. Анализ ошибок важнее одной средней цифры
Средняя чувствительность 95% не отвечает на вопрос, какие 5% случаев система пропустила. Для безопасности нужно изучать структуру ошибок: какие патологии, размеры очагов, стадии, анатомические зоны, группы пациентов, аппараты или типы изображений связаны с ухудшением результата.
Полезно формировать реестр ошибок, в котором каждая значимая ошибка классифицируется по типу, клинической причине и потенциальному последствию. Такой анализ связывает клиническую валидацию с управлением рисками.
| Тип ошибки | Пример | Потенциальное последствие |
|---|---|---|
| Ложноотрицательный результат | Система пропустила патологию. | Задержка диагностики, лечения или маршрутизации. |
| Ложноположительный результат | Система указала на патологию при ее отсутствии. | Дополнительные исследования, нагрузка на врача, тревога пациента. |
| Ошибка локализации | Правильный класс, но неверная область/контур. | Неверное измерение, планирование или интерпретация. |
| Систематическая ошибка подгруппы | Снижение качества у определенной группы или на определенном оборудовании. | Неравномерная безопасность и ограниченная применимость. |
| Необработанное исследование | Алгоритм не выдал результат. | Риск потери исследования или задержки процесса, если отказ не виден пользователю. |
10. ИИ и врач: нужно оценивать систему «человек + алгоритм»
Если ИИ используется как поддержка специалиста, итоговая эффективность зависит не только от точности модели, но и от того, как пользователь воспринимает результат. Хороший алгоритм может ухудшить процесс, если интерфейс перегружен ложными срабатываниями, предупреждения игнорируются или врач чрезмерно доверяет автоматическому выводу.
- видит ли пользователь степень уверенности и ограничения результата;
- понятно ли, когда система не смогла обработать исследование;
- отличается ли результат ИИ от окончательного медицинского заключения;
- есть ли способ быстро проверить или отклонить предложение алгоритма;
- как система влияет на время работы специалиста;
- возникает ли эффект автоматизационного смещения — склонность соглашаться с автоматическим результатом;
- что происходит при расхождении между врачом и алгоритмом.
Роль системы должна следовать ее зарегистрированному назначению. Нельзя автоматически считать любой ИИ «вторым мнением» или, наоборот, самостоятельным диагностом: это определяется конкретной функцией и документацией изделия.
11. Особый риск — утечка данных между обучением и тестированием
Для медицинских изображений утечка особенно коварна. Один пациент может иметь десятки срезов, несколько серий или повторные исследования. Если часть изображений пациента попала в обучение, а другая часть — в тест, система может фактически «узнать» пациента или особенности конкретного исследования.
Разделение выборок поэтому следует выполнять как минимум на уровне пациента, а при подтверждающей внешней валидации — по возможности также на уровне медицинской организации или временного периода. Аналогично нельзя незаметно подбирать пороги, preprocessing или настройки модели по финальному тестовому набору: такой набор перестает быть независимым.
12. Версия алгоритма должна быть зафиксирована
Клинические доказательства относятся не к названию продукта вообще, а к конкретной реализованной версии. Для воспроизводимости необходимо фиксировать версию программного обеспечения, модель или набор весов, параметры предобработки, используемые справочники и другие элементы, способные повлиять на результат.
После обновления алгоритма нужно оценивать, сохраняется ли применимость прежних доказательств. Для ПО с применением ИИ действующие Правила государственной регистрации медицинских изделий отдельно регулируют изменения версий и их связь с регистрационным досье. Конкретный регуляторный маршрут зависит от характера изменения и его влияния на функциональное назначение и принцип действия.
13. Доказательства до внедрения и мониторинг после внедрения
Даже сильная внешняя валидация не исключает изменения характеристик после внедрения. Может измениться парк оборудования, протоколы исследования, структура пациентов или поток данных. Поэтому для ИИ полезно заранее определить эксплуатационные показатели, которые будут контролироваться после запуска.
| Показатель мониторинга | Что он помогает увидеть |
|---|---|
| Доля успешно обработанных исследований | Показывает доступность и техническую применимость системы. |
| Частота ошибок/отказов | Позволяет выявить проблемы данных, инфраструктуры или версии. |
| Ложные срабатывания и клинически значимые пропуски | Основные сигналы безопасности. |
| Качество по подразделениям/аппаратам | Помогает обнаружить локальное ухудшение или domain shift. |
| Время обработки | Показывает соответствие рабочему процессу и нагрузке. |
| Доля согласия/расхождения с специалистом | Полезна как эксплуатационный индикатор, но сама по себе не заменяет клинический референс. |
| Версия системы | Необходима для связи изменения метрик с обновлениями. |
14. Какие доказательства выглядят убедительно
Для экспертной оценки сильна не одна публикация и не одна большая цифра, а согласованный пакет доказательств, в котором каждый элемент отвечает на свой вопрос.
| Элемент доказательств | Что должен подтверждать |
|---|---|
| Назначение и документация | Однозначно описывают медицинскую функцию, пользователя, входные данные, выход и ограничения. |
| Технические испытания | Подтверждают функциональность, корректность, производительность, устойчивость и заявленные технические характеристики. |
| Наборы данных | Имеют документированное происхождение, достаточный объем, независимость и репрезентативность. |
| Референсный стандарт | Клинически обоснован, воспроизводим и прозрачно сформирован. |
| Аналитическая валидация | Подтверждает корректность работы алгоритма по релевантным метрикам. |
| Клиническая валидация | Показывает результат на целевой популяции и в применимых условиях. |
| Анализ подгрупп и ошибок | Выявляет ограничения, редкие случаи и клинически опасные режимы. |
| Управление рисками | Связывает возможные ошибки алгоритма с последствиями и мерами контроля. |
| Эксплуатационная оценка | Подтверждает, что система безопасно встраивается в реальный процесс. |
15. Красные флаги при оценке медицинского ИИ
- указана только общая accuracy без чувствительности, специфичности и анализа ошибок;
- не описано, какие данные использовались для обучения и какие — для независимого тестирования;
- обучающая и тестовая выборки содержат изображения одних и тех же пациентов;
- тестирование выполнено на данных одной клиники или одного аппарата при широком заявленном назначении;
- не указана версия алгоритма, к которой относятся результаты;
- эталонная разметка сформирована без описания квалификации экспертов и разрешения разногласий;
- нет анализа редких, пограничных и низкокачественных изображений;
- нет отдельных результатов по клинически значимым подгруппам;
- метрики выбраны потому, что выглядят лучше, а не потому, что соответствуют клинической задаче;
- производитель показывает только результаты модели, но не влияние системы на пользователя и рабочий процесс;
- после обновления модели продолжают использовать результаты испытаний старой версии без обоснования сопоставимости.
Практическая схема оценки системы ИИ для анализа медицинских изображений
- Зафиксировать назначение системы и конкретную медицинскую функцию.
- Определить тип задачи: детекция, классификация, сегментация, измерение, триаж или иная функция.
- Определить целевую популяцию, типы изображений, аппараты и условия применения.
- Проверить статус медицинского изделия и соответствие фактического сценария зарегистрированному назначению.
- Определить клинически значимые риски ошибок алгоритма.
- Проверить происхождение и независимость обучающих, валидационных и тестовых данных.
- Оценить репрезентативность и разнородность подтверждающей выборки.
- Проверить способ формирования референсного стандарта и квалификацию экспертов.
- Выбрать метрики, соответствующие медицинской функции и последствиям ошибок.
- Оценить результаты в рабочей точке/порогах, а не только усредненные показатели.
- Проверить внешнюю валидацию и результаты на отдельных подгруппах.
- Изучить структуру ложноположительных, ложноотрицательных и технических отказов.
- Проверить устойчивость к разным устройствам, протоколам, качеству и артефактам изображений.
- Оценить взаимодействие пользователя с системой и влияние на рабочий процесс.
- Зафиксировать версию алгоритма и определить правила оценки последующих изменений.
- Определить показатели мониторинга после внедрения.
Чек-лист эксперта
| Контрольный вопрос | Отметка |
|---|---|
| Однозначно определена медицинская функция системы | ☐ |
| Назначение и сценарий применения соответствуют документации/регистрации | ☐ |
| Зафиксирована версия ПО и алгоритма | ☐ |
| Описаны обучающий, валидационный и тестовый наборы данных | ☐ |
| Подтверждающий набор независим от обучения и калибровки | ☐ |
| Разделение данных выполнено как минимум на уровне пациентов | ☐ |
| Выборка соответствует целевой популяции | ☐ |
| Представлены разные медицинские организации и оборудование, если это требуется заявленным назначением | ☐ |
| В набор включены реалистичные вариации качества изображений и артефакты | ☐ |
| Описан и обоснован референсный стандарт | ☐ |
| Документирована квалификация экспертов-разметчиков | ☐ |
| Метрики соответствуют типу задачи | ☐ |
| Проанализированы чувствительность/специфичность или иные релевантные показатели, а не только accuracy | ☐ |
| Оценены результаты в заявленной рабочей точке/порогах | ☐ |
| Есть анализ клинически значимых подгрупп | ☐ |
| Есть анализ типов и последствий ошибок | ☐ |
| Проверена устойчивость к разнородным данным | ☐ |
| Оценено взаимодействие с пользователем и рабочим процессом | ☐ |
| Риски ошибок связаны с мерами управления риском | ☐ |
| Определен план мониторинга после внедрения | ☐ |
Рабочая матрица доказательств
| Область | Контрольный вопрос | Ожидаемое доказательство | Вывод эксперта |
|---|---|---|---|
| Назначение/функция | Что именно делает алгоритм? | ТД/ЭД, описание назначения | |
| Клиническая связь | Почему выход алгоритма связан с медицинским состоянием/решением? | Научная литература, клиническое обоснование | |
| Данные | На каких данных доказана работа? | Описание наборов данных, критерии включения | |
| Референс | С чем сравнивали результат? | Протокол разметки/верификации | |
| Аналитическая валидация | Насколько алгоритм корректен по выбранным метрикам? | Отчет испытаний | |
| Клиническая валидация | Сохраняется ли результат в целевой популяции? | КИ/клиническая оценка | |
| Устойчивость | Что происходит при смене аппарата, протокола, качества? | Испытания на разнородных данных | |
| Безопасность | Какие ошибки опасны и как контролируются? | Файл управления рисками, анализ ошибок | |
| Использование | Как система влияет на врача и процесс? | Пилот/эксплуатационная оценка | |
| Жизненный цикл | К какой версии относятся доказательства и как контролируются изменения? | Конфигурация, управление изменениями |
Нормативная и методическая база
Приказ Минздрава России от 13.05.2026 № 421н
Устанавливает порядок оценки соответствия медицинских изделий в форме технических испытаний и клинических испытаний. С 1 сентября 2026 года применяется вместо приказа № 885н. Для ПО с ИИ пунктами 38–40 предусмотрено использование верифицированных медицинских данных и оценка клинической связи, аналитической и клинической валидации, эффективности, безопасности и качества использования.
https://deloprava.ru/prikaz-minzdrava-rossii-ot-13-05-2026-n-421n/
Постановление Правительства РФ от 30.11.2024 № 1684
Правила государственной регистрации медицинских изделий. Содержат специальные положения для программного обеспечения с применением технологий искусственного интеллекта, являющегося медицинским изделием, включая вопросы версий и регистрационного досье.
https://internet-law.ru/documents/dop_documents/67/mu_3/0/posta.html
ГОСТ Р 59921.0-2022 «Системы искусственного интеллекта в клинической медицине. Основные положения»
Содержит базовые понятия и принципы безопасности, эффективности, понятности и жизненного цикла систем ИИ в клинической медицине.
https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/21/gost_93989.html
ГОСТ Р 59921.1-2022 «Системы искусственного интеллекта в клинической медицине. Часть 1. Клиническая оценка»
Методическая база для планирования и анализа клинической оценки систем ИИ, включая требования к данным и независимости подтверждающей выборки.
https://mooml.com/d/gosty/53516/
ГОСТ Р 59921.5-2022 «Системы искусственного интеллекта в клинической медицине. Часть 5. Требования к структуре и порядку применения набора данных для обучения и тестирования алгоритмов»
Определяет подходы к формированию и использованию наборов данных для обучения и тестирования алгоритмов ИИ.
https://xn--80aaiduub8a.xn--p1acf/ru/faq/standards-it
ГОСТ Р 59921.7-2022 «Системы искусственного интеллекта в клинической медицине. Алгоритмы анализа медицинских изображений. Методы испытаний. Общие требования»
Ключевой профильный стандарт для алгоритмов анализа медицинских изображений. Описывает подходы к техническим и клиническим испытаниям, метрикам, наборам данных, устойчивости к разнородным изображениям и качеству входных данных.
https://allgosts.ru/11/040/gost_r_59921.7-2022
ГОСТ ISO 14971-2021 «Изделия медицинские. Применение менеджмента риска к медицинским изделиям»
Используется как базовая методология управления рисками медицинского изделия на протяжении жизненного цикла.
Связанные материалы
| Материал | Связь с текущей статьей | Статус |
|---|---|---|
| Как оценить медицинскую технологию перед внедрением: эффективность, безопасность и практическая ценность | Базовая многокритериальная схема оценки медицинской технологии до пилота и масштабирования. | ГОТОВО |
| От пилота к клинической практике: как понять, что медицинская технология готова к внедрению | Критерии пилота, KPI, условия масштабирования и признаки готовности к реальной эксплуатации. | ПЛАНИРУЕТСЯ |
| Клинические испытания медицинского изделия: пошаговый алгоритм | Общая последовательность подготовки и проведения клинических испытаний. | ГОТОВО |
| Программа клинических испытаний медицинского изделия: структура, обязательные разделы и типичные ошибки | Практическое руководство по проектированию программы КИ и доказательной логике исследования. | ГОТОВО |
| Качество, безопасность и эффективность медицинского изделия: в чем разница и что оценивает эксперт | Разбор трех ключевых направлений экспертной оценки медицинского изделия. | ГОТОВО |
Практические документы и чек-листы
К статье целесообразно разместить для скачивания или использования на странице:
- чек-лист эксперта по оценке ИИ для анализа медицинских изображений;
- матрицу «медицинская функция → риск ошибки → метрика → критерий приемлемости → доказательство»;
- карточку аудита набора данных: происхождение, независимость, репрезентативность, оборудование, качество изображений;
- таблицу анализа ошибок алгоритма по типам, подгруппам и клиническим последствиям;
- форму плана эксплуатационного мониторинга после внедрения.
Актуальность материала
Дата актуализации: 10 сентября 2026 года.
Материал подготовлен с учетом приказа Минздрава России от 13.05.2026 № 421н, вступившего в силу 1 сентября 2026 года, Правил государственной регистрации медицинских изделий, утвержденных постановлением Правительства РФ от 30.11.2024 № 1684, и действующих профильных национальных стандартов серии ГОСТ Р 59921 по системам искусственного интеллекта в клинической медицине.
При применении материала к конкретному продукту необходимо учитывать его зарегистрированное назначение, класс потенциального риска, конкретную медицинскую функцию, тип изображений, версию программного обеспечения, предусмотренные производителем ограничения и применимые требования законодательства и стандартов.
Версия материала: 1.0