Медицинское ПО · MDR и IVDR ЕС · FDA США
Регулируйте медицинскую функцию, а не формат программного обеспечения
Мобильное приложение, облачный сервис, встроенная функция или модель ИИ могут стать регулируемым медицинским изделием, если их назначение и клиническая роль соответствуют применимому определению. Правильно выбранный путь связывает назначение с классификацией, доказательствами, управлением жизненным циклом и каждым выпускаемым изменением.
Начните с регуляторной границы
Квалификация определяется функцией и ее медицинским назначением
Платформа сама по себе не дает ответа. Одна технология может одновременно содержать нерегулируемую административную функцию, функцию общего благополучия с низким риском и регулируемую функцию медицинского изделия. Для каждой функции необходимо определить входные данные, обработку, результат, пользователя и заявленное клиническое применение.
Общие, административные функции или функции для поддержания благополучия
- Планирование, выставление счетов и обычные средства коммуникации
- Общие справочные материалы без анализа данных конкретного пациента
- Функции для образа жизни и общего благополучия с низким риском без медицинского назначения
При этом могут применяться другие правовые режимы, включая требования к защите данных, правам потребителей, кибербезопасности и ИИ.
Программное обеспечение с определенной медицинской ролью
- Диагностика, прогнозирование, определение прогноза, мониторинг или поддержка лечения
- Анализ данных конкретного пациента или информации, полученной при исследовании образца
- Управление изделием или преобразование платформы общего назначения
Точные определения, исключения, классификация и политика надзора различаются в ЕС и США.
Зафиксируйте ответы до выбора регуляторного пути
- 01Какие данные поступают на вход функции?
- 02Что функция делает с этими данными?
- 03Какой результат получает пользователь?
- 04Как результат влияет на оказание помощи?
- 05Что произойдет при ошибке или недоступности?
Пути для отдельных рынков
Используйте единое определение продукта и отдельно определите путь для каждой юрисдикции
Функция ПО может регулироваться на обоих рынках, но получить разные классы и проходить разные процедуры оценки. Сохраняйте согласованность архитектуры продукта и заявлений, однако документируйте каждое регуляторное решение по применимым правилам ЕС или FDA.
Путь оценки соответствия по MDR или IVDR
Квалификация, классификация риска и маркировка CE
-
01
Квалифицируйте программное обеспечение
Подтвердите, является ли функция медицинским программным обеспечением и относит ли ее назначение к сфере MDR или IVDR.
-
02
Примените правила классификации
Примените Приложение VIII. Правило 11 MDR имеет ключевое значение для многих функций принятия решений и мониторинга. Классы A–D по IVDR зависят от назначения и применимых правил для IVD.
-
03
Постройте систему доказательств
Свяжите управление рисками, документы жизненного цикла ПО, удобство применения, кибербезопасность и клиническую оценку либо оценку эффективности.
-
04
Пройдите оценку соответствия
Создайте систему менеджмента качества и техническую документацию. Привлеките нотифицированный орган, если этого требуют класс и выбранная процедура, затем оформите декларацию и нанесите маркировку CE.
-
05
Контролируйте ПО после вывода на рынок
Поддерживайте регистрацию, PMS, систему сообщения об инцидентах, кибербезопасность, корректирующие действия и оценку каждого предлагаемого изменения.
Путь FDA для функций программного обеспечения
Статус изделия, классификация и путь вывода на рынок
-
01
Разделите функции программного обеспечения
Определите, какие функции соответствуют определению медицинского изделия и применимы ли предусмотренные законом исключения или политика правоприменения FDA.
-
02
Определите тип изделия
Определите класс, номер нормативного положения, код продукта, применимые специальные меры контроля и, при необходимости, возможные изделия-предикаты.
-
03
Выберите путь вывода на рынок
Подтвердите, освобождена ли функция от предварительного уведомления или требует 510(k), запроса De Novo, PMA либо иной процедуры для конкретного типа продукта.
-
04
Подготовьте доказательства для подачи
Согласуйте уровень документации на ПО, доказательства характеристик, человеческие факторы, кибербезопасность и маркировку с риском изделия.
-
05
Поддерживайте соответствие требованиям FDA
Применяйте процессы системы качества, отчетность, исправления и изъятия, поддержание кибербезопасности и оценку изменений.
Архитектура доказательств
Обеспечьте прослеживаемость выпущенного ПО до заявлений и мер контроля
Регуляторная подача или техническая документация являются результатом работы системы разработки. Доказательства должны позволять проследить клиническое заявление через требования, опасности, меры контроля, реализацию, верификацию, валидацию и мониторинг после вывода на рынок.
Определение продукта
Назначение, пользователи, популяция пациентов, среда применения, показания, ограничения, конфигурации и выпущенная версия.
Архитектура и жизненный цикл
Программные элементы, интерфейсы, потоки данных, сторонние компоненты, планирование разработки, управление конфигурацией и выпуском.
Риски и кибербезопасность
Опасности для безопасности, киберугрозы, меры контроля риска, безопасное проектирование, управление уязвимостями и их согласованное раскрытие.
Верификация и валидация
Испытания на основе требований, интеграционное и системное тестирование, нерешенные аномалии, совместимость и валидация в условиях применения.
Клинические доказательства или доказательства эффективности
Обоснованная клиническая связь, аналитические или технические характеристики, клиническая эффективность и подтверждение заявленной пользы.
Человеческие факторы и информация
Критические задачи, риски интерфейса, валидация удобства применения, маркировка, инструкции, предупреждения и понятное представление результатов.
Изменения программного обеспечения и ИИ
Спланируйте механизм обновления до первого регулируемого выпуска
Новая модель, набор данных, интерфейс, компонент хостинга или алгоритм могут изменить характеристики и риск без изменения названия продукта. Процесс управления изменениями должен определять, что именно меняется, как изменение будет проверено, сохраняют ли силу клинические доказательства и требуется ли новая регуляторная оценка.
Опишите границы изменения
Определите допустимые входные данные, результаты, пределы характеристик и способ внедрения.
Повторно оцените пользу и риск
Оцените затронутые опасности, пользователей, популяции и подгруппы, кибербезопасность и предвидимое неправильное применение.
Проведите верификацию и валидацию
Используйте заранее определенные критерии приемки, репрезентативные данные и доказательства контролируемого внедрения.
Примите регуляторное решение
До выпуска оцените влияние на соответствие требованиям ЕС и обязательства по подаче в FDA.
Контролируйте выпущенную версию
Отслеживайте дрейф характеристик, жалобы, инциденты, уязвимости и результаты реального применения.
Для функций на основе ИИ согласуйте управление данными, характеристики в релевантных популяциях, надзор со стороны человека, прозрачность и управление изменениями модели с путем медицинского изделия. В США определите, следует ли включать в регуляторную подачу план заранее определенных изменений. В ЕС оцените взаимодействие MDR или IVDR и Акта об искусственном интеллекте для конкретной системы и процедуры соответствия.
Первоисточники
Проверяйте путь по актуальным официальным материалам
Руководства не заменяют регламенты и оценку конкретного продукта. Перед выбором пути или плана подачи проверьте актуальную редакцию документов и требования для соответствующего типа изделия.
MDCG 2019-11 rev.1
Квалификация и классификация программного обеспечения по MDR и IVDR
Руководства Европейской комиссии по медицинскому ПО
Клинические доказательства, кибербезопасность, взаимодействие с ИИ и актуальные редакции
Функции программного обеспечения по FDA
Сфера регулирования и политика для ПО и мобильных приложений
Документация на ПО для предварительной подачи
Рекомендации FDA для подачи по функциям программного обеспечения изделия
Руководство FDA по кибербезопасности
Аспекты системы качества и содержание предварительной подачи
Планы изменений для изделий на основе ИИ
Рекомендации FDA по планам заранее определенных изменений
Часто задаваемые вопросы
Практические различия для программного обеспечения
Окончательное решение зависит от фактической функции, заявлений, пользователей, архитектуры развертывания, риска и доказательств, а не только от названия продукта.
Является ли каждое приложение для здоровья медицинским изделием?
Нет. Регуляторный статус определяется функцией ПО и установленным изготовителем назначением. Административные функции, ПО общего назначения и многие функции общего благополучия с низким риском могут не подпадать под правила для медицинских изделий. Функции для диагностики, профилактики, мониторинга, прогнозирования или лечения могут соответствовать применимому определению медицинского изделия.
Влияет ли облачное или мобильное размещение на статус изделия?
Размещение на телефоне, в браузере, на облачной платформе или локальном сервере само по себе не определяет статус. Решающими остаются функция, назначение, входные данные, результат, клиническая роль и последствия отказа. Архитектура при этом влияет на кибербезопасность, валидацию и ответственность.
Как классифицируется медицинское программное обеспечение в ЕС?
ПО по MDR классифицируется согласно Приложению VIII, при этом Правило 11 имеет ключевое значение для многих функций поддержки принятия решений и мониторинга. ПО по IVDR относится к классу A, B, C или D в соответствии с применимыми правилами. ПО, управляющее другим изделием или влияющее на его применение, может следовать его классу, а независимое ПО классифицируется самостоятельно.
От чего зависит путь FDA?
Сначала определите, соответствует ли функция определению медицинского изделия и применимо ли исключение или политика FDA. Затем установите тип изделия, класс, код продукта и специальные меры контроля. Регулируемая функция может быть освобождена от предварительного уведомления либо требовать 510(k), запроса De Novo или PMA.
Требует ли каждое изменение модели ИИ новой подачи?
Не автоматически, однако каждое изменение требует контролируемой оценки. Решение зависит от юрисдикции, сертифицированного или разрешенного изделия, влияния на назначение, характеристики и риск, а также от согласованного протокола изменений. Рассмотренный FDA план заранее определенных изменений может охватывать конкретные будущие изменения функции на основе ИИ и меры их контроля.
Достаточно ли соответствия IEC 62304 для вывода на рынок?
Нет. IEC 62304 структурирует процессы жизненного цикла ПО, но вывод на рынок также зависит от квалификации, классификации, управления рисками, клинических доказательств или доказательств эффективности, удобства применения, кибербезопасности, СМК и применимого пути оценки соответствия или подачи в FDA.