Как в США регулируется медицинское программное обеспечение: SaMD и подход FDA

В американской системе термин Software as a Medical Device (SaMD) используется, но не создает отдельного регистрационного режима. FDA регулирует программные функции через общую систему медицинских изделий: сначала определяется, подпадает ли конкретная функция под определение device, затем устанавливаются классификация, применимые controls и premarket pathway. Для искусственного интеллекта к этой базовой модели добавляются требования и рекомендации по данным, валидации, прозрачности, мониторингу и управлению будущими изменениями.

SaMD — это программное обеспечение, предназначенное для одной или нескольких медицинских целей и выполняющее эти цели без необходимости быть частью аппаратного медицинского изделия. Такое определение разработано IMDRF и используется FDA как рабочее международное понятие.

Однако в США ключевой вопрос звучит не «является ли продукт SaMD?», а «является ли конкретная software function медицинским изделием по Federal Food, Drug, and Cosmetic Act и какие требования к ней применимы?».

Если функция является device software function, дальнейший маршрут в целом такой же, как для других медицинских изделий: классификация → определение product code и regulatory controls → 510(k), De Novo, PMA или, для части низкорисковых устройств, освобождение от premarket submission → регистрация предприятия и listing → соблюдение Quality Management System Regulation и постмаркетинговых требований.

FDA отдельно подчеркивает, что программный продукт может содержать несколько функций одновременно. Одна функция может регулироваться как device, а другая — быть non-device software function.

Определение зависит прежде всего от intended use. Одно и то же техническое решение может получить разный регуляторный статус в зависимости от заявленной цели.

Section 520(o) FD&C Act, добавленный 21st Century Cures Act, исключил из определения device ряд программных функций. В их числе определенные функции для административной поддержки, поддержания здорового образа жизни, электронных медицинских записей, передачи/хранения/форматирования/отображения данных и отдельные clinical decision support functions.

Для Clinical Decision Support особенно важно не использовать упрощенную формулу «если решение принимает врач, это не device». FDA в финальном guidance 2026 года применяет четыре statutory criteria, и все они должны выполняться для исключения конкретной CDS-функции.

Практический вывод: regulatory assessment следует проводить на уровне каждой значимой software function, а не только на уровне продукта в целом.

После признания функции медицинским изделием FDA определяет применимую классификацию и regulatory controls. В американской модели устройства распределяются по классам I, II и III в зависимости от уровня контроля, необходимого для обеспечения безопасности и эффективности.

Поэтому два внешне похожих программных продукта могут идти по разным маршрутам, если различаются intended use, риск, product code или наличие predicate.

В 510(k) спонсор показывает, что новое устройство substantially equivalent подходящему predicate device. Сравниваются intended use и технологические характеристики; отличия должны быть оценены так, чтобы они не создавали новых вопросов безопасности и эффективности.

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

• описание программной архитектуры и функций;
• анализ опасностей и управление рисками;
• software requirements и design information;
• verification and validation;
• performance testing;
• clinical data — когда bench/analytical evidence недостаточно;
• human factors / usability data — если ошибки использования способны привести к вреду;
• cybersecurity documentation — для устройств с соответствующим риском;
• labeling и инструкции, отражающие ограничения и intended use.

De Novo применяется для новых типов устройств низкого или умеренного риска, для которых отсутствует legally marketed predicate. FDA оценивает риски, меры их контроля и доказательства безопасности и эффективности, после чего может создать новую классификационную регуляцию.

Для инновационного SaMD или AI-продукта De Novo часто становится ключевым путем, если технологически или клинически подходящего predicate еще нет.

После успешного De Novo это устройство или созданная классификация может стать основой для будущих 510(k) других производителей.

PMA — наиболее строгий premarket pathway. Он используется прежде всего для Class III devices и требует самостоятельной демонстрации reasonable assurance of safety and effectiveness.

Если программная функция влияет на критические терапевтические решения или встроена в высокорисковое устройство, объем clinical and performance evidence может быть существенно выше, чем в типичном 510(k).

Финальный guidance Content of Premarket Submissions for Device Software Functions (2023) установил риск-ориентированный подход к документации и заменил руководство 2005 года.

FDA использует два documentation levels — Basic и Enhanced. Уровень зависит не просто от класса изделия, а от того, может ли software failure или latent flaw привести к опасной ситуации с вероятностью смерти или серьезной травмы.

FDA не применяет универсальное правило, согласно которому каждое SaMD обязано иметь отдельное клиническое исследование. Объем evidence зависит от риска, novelty, intended use и того, можно ли подтвердить безопасность и эффективность другими видами данных.

Для структурирования клинического обоснования полезна модель IMDRF SaMD Clinical Evaluation:

Для конкретного FDA submission состав доказательств определяется применимыми regulations, special controls, device-specific guidances, recognized standards и вопросами безопасности и эффективности конкретного продукта.

Для AI-enabled software оценка должна учитывать не только агрегированную метрику. Данные должны отражать intended use population и условия реальной эксплуатации.

• происхождение и качество данных;
• независимость training, tuning и test datasets;
• репрезентативность демографических и клинических групп;
• работу на данных из разных sites, devices и workflows;
• подходящий reference standard / ground truth;
• sensitivity, specificity, ROC/AUC и другие clinically meaningful metrics;
• performance по значимым subgroups;
• ложноположительные и ложноотрицательные результаты и их клинические последствия;
• human-AI team performance, если решение принимает медицинский работник;
• устойчивость к dataset shift, drift и изменениям входных данных.

В 2025 году IMDRF выпустил финальные Good Machine Learning Practice principles, а FDA продолжает использовать total product lifecycle как основу для развития регулирования AI-enabled devices.

На дату актуализации необходимо различать финальные и draft документы.

Predetermined Change Control Plan (PCCP) — один из наиболее характерных элементов американского подхода к AI-enabled devices. Производитель может заранее включить в marketing submission план определенных будущих изменений и методологию их разработки, валидации и внедрения.

Финальный guidance 2025 года рекомендует, чтобы PCCP описывал:

• какие именно модификации планируются;
• какими методами они будут разрабатываться и валидироваться;
• как будет оцениваться их влияние на безопасность и эффективность;
• какие данные, метрики и acceptance criteria будут использоваться;
• как будет поддерживаться прозрачность для пользователей;
• как изменения будут контролироваться в рамках QMS.

Смысл PCCP в том, что FDA может оценить допустимые границы эволюции AI-функции заранее. Это не означает, что любая последующая модификация автоматически разрешена: изменение должно укладываться в одобренный план и выполняться в соответствии с предусмотренной методологией.

Регуляторно опасно описывать американскую модель как разрешение свободно самообучающегося алгоритма. Для marketed device изменения должны оставаться контролируемыми.

На практике производитель должен понимать:

• какие параметры модели могут изменяться;
• когда изменение требует новой submission;
• что покрывается одобренным PCCP;
• какие validation gates должны пройти обновления;
• как новая версия идентифицируется и отслеживается;
• как отслеживается performance после deployment;
• как пользователи информируются о значимых изменениях.

Для connected и networked medical software cybersecurity рассматривается FDA как элемент safety and effectiveness, а не как отдельная ИТ-тема.

Финальный guidance февраля 2026 года охватывает secure design, labeling и рекомендуемый состав premarket submission для устройств с cybersecurity risk. Для cyber devices дополнительно применяются statutory requirements section 524B FD&C Act.

• cybersecurity risk management;
• threat modeling;
• security architecture;
• verification and validation security controls;
• управление уязвимостями;
• software bill of materials и иная требуемая документация для применимых cyber devices;
• план мониторинга и обновлений после выхода на рынок.

С 2 февраля 2026 года в США действует Quality Management System Regulation (QMSR), изменившая 21 CFR Part 820 и включившая посредством incorporation by reference ISO 13485:2016.

Для разработчика SaMD это означает, что software lifecycle, design and development, change control, verification/validation, CAPA, supplier controls и postmarket activities должны быть встроены в действующую систему качества, а не существовать как набор документов только для FDA submission.

FDA также изменило подход к инспекциям производителей после вступления QMSR в силу.

Clinical Decision Support — зона, где ошибка классификации особенно вероятна. Финальный guidance 2026 года разъясняет четыре критерия section 520(o)(1)(E).

Для non-device CDS, среди прочего, медицинский работник должен иметь возможность независимо рассмотреть основу рекомендации, чтобы не полагаться преимущественно на software output при принятии индивидуального клинического решения.

Если software анализирует медицинское изображение или сигнал, предназначена для пациента/ухаживающего лица, выдает time-critical output либо не позволяет врачу независимо оценить основу результата, вероятность device regulation повышается.

Шаг 1. Разложить продукт на отдельные software functions и зафиксировать intended use каждой из них.

Шаг 2. Проверить, подпадает ли каждая функция под definition of device и exclusions section 520(o).

Шаг 3. Найти product classification, regulation number и product code в базах FDA.

Шаг 4. Определить class и применимые general/special controls.

Шаг 5. Определить premarket pathway: exempt, 510(k), De Novo или PMA.

Шаг 6. Для 510(k) выбрать и критически оценить predicate.

Шаг 7. Определить требования к software documentation level и содержанию submission.

Шаг 8. Сформировать risk management, software requirements, architecture, V&V и performance evidence.

Шаг 9. Определить необходимость clinical evidence и его объем.

Шаг 10. Для AI/ML проверить репрезентативность данных, subgroup performance, bias и human-AI interaction.

Шаг 11. Оценить cybersecurity requirements и section 524B, если продукт является cyber device.

Шаг 12. Определить стратегию software changes и необходимость PCCP.

Шаг 13. Встроить разработку и change control в QMSR.

Шаг 14. Подготовить labeling и пользовательскую информацию.

Шаг 15. Подать соответствующий marketing submission и отработать вопросы FDA.

Шаг 16. После authorization/clearance/approval выполнить establishment registration, device listing и применимые postmarket requirements.

Шаг 17. Поддерживать monitoring, complaint handling, reporting, cybersecurity и контроль версий на протяжении total product lifecycle.

Американский подход к медицинскому ПО строится не вокруг ярлыка SaMD, а вокруг конкретной функции, intended use, риска и доказательств безопасности и эффективности.

Упрощенная схема выглядит так:

software function → device / non-device → classification → product code → pathway → software evidence → clinical/performance evidence → cybersecurity → QMSR → postmarket monitoring → controlled changes

Для AI-enabled devices к этой цепочке добавляется еще один вопрос: как устройство будет безопасно изменяться после выхода на рынок. Именно поэтому PCCP, lifecycle monitoring и transparency занимают все более заметное место в подходе FDA.

FDA guidance documents содержат nonbinding recommendations и не заменяют применимые требования закона и 21 CFR. В конкретном submission приоритет имеют statutory requirements, regulations, классификация устройства, applicable special controls и актуальные FDA guidances.

• Чек-лист device / non-device assessment для software functions.
• Матрица «software function → product code → class → pathway → controls».
• Чек-лист premarket documentation для device software function.
• Матрица SaMD clinical evidence: clinical association → analytical validation → clinical validation.
• Чек-лист AI data and subgroup evaluation.
• Матрица управления software changes и applicability PCCP.
• Чек-лист готовности к QMSR для разработчика медицинского ПО.

Дата актуализации: 10 сентября 2026 года.

Материал учитывает FDA Digital Health guidance landscape на дату подготовки, включая финальный Clinical Decision Support Software Guidance января 2026 года, финальный Cybersecurity Guidance февраля 2026 года, вступление QMSR в силу 2 февраля 2026 года и финальный PCCP Guidance августа 2025 года.

Документ Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations на дату актуализации остается draft guidance и не должен представляться как обязательное действующее руководство.

Перед применением к конкретному продукту необходимо проверить FDA Product Classification database, актуальный product code, применимую regulation, recognized consensus standards и device-specific guidance.

Версия материала: 1.0