Как достигается соответствие медицинского ПО требованиям ЕС и США
Медицинское программное обеспечение оценивается не только с точки зрения его технической реализации. Регуляторные требования зависят от предполагаемого назначения, клинической роли, потенциальных рисков и необходимых доказательств соответствия. MDRC помогает компаниям определить подходящий регуляторный путь и подготовить документацию и процессы, необходимые для выхода на рынок.
Является ли ваше программное обеспечение медицинским изделием?
Не всякое программное обеспечение, используемое в здравоохранении, является медицинским изделием. Регуляторный статус ПО зависит от предполагаемого назначения, выполняемых функций, клинической роли и того, как результаты работы ПО влияют на принятие медицинских решений.
Программное обеспечение медицинского изделия
Программное обеспечение может рассматриваться как медицинское изделие, если оно имеет медицинское назначение или собирает и обрабатывает информацию, используемую для диагностики, профилактики, мониторинга, прогнозирования или принятия решений о лечении.
- Системы поддержки клинических решений
- Диагностические алгоритмы
- Анализ изображений и сигналов на основе ИИ
- Программное обеспечение для мониторинга пациентов
- Замкнутые системы контроля функций организма
Программное обеспечение, не являющееся медицинским изделием
Не всё программное обеспечение, связанное со здравоохранением, является медицинским изделием. Программные продукты без медицинского назначения могут не подпадать под требования MDR или IVDR.
- Административные системы здравоохранения
- Инструменты электронной документации
- ПО для планирования и рабочих процессов
- Общие приложения для здоровья
- Инструменты коммуникации и управления данными
Регуляторный статус определяется не технологией, а целевым назначением.
Ключевые регуляторные вопросы
Чтобы определить, какова будет регуляторная процедура для вашего ПО, необходимо понять:
- Каково предполагаемое назначение?
- Кто является предполагаемым пользователем?
- Влияет ли ПО на клинические решения?
- Какие риски возникают при ошибочных результатах?
- Какие доказательства необходимы?
- Какой регуляторный путь применяется?
Классификация определяет регуляторную процедуру
Классификация медицинского программного обеспечения — одно из первых регуляторных решений, которое должна принять компания. Она определяет уровень регуляторного контроля, объём необходимых доказательств, требования к документации и дальнейший путь выхода на рынок.
Для программного обеспечения классификация зависит не от технологии, а от предполагаемого назначения, клинической роли и влияния результатов работы программы на принятие медицинских решений.
Медицинское ПО
Целевое назначение и клиническая функция
Каково предполагаемое назначение?
Какую медицинскую функцию выполняет программное обеспечение? Кто является его пользователем и как используются результаты его работы?
Отсутствует медицинская функция
ПО не является медицинским изделием
Медицинская функция
Необходима оценка клинической роли, рисков и регуляторных требований.
Классификация
Регуляторная процедура, доказательная база, управление рисками.
Предполагаемое назначение
Предполагаемое назначение определяет, является ли программное обеспечение медицинским изделием, и формирует основу для его классификации.
- Задача в сфере здравоохранения, которую выполняет программное обеспечение
- Предполагаемые пользователи
- Клинический контекст
- Заявленные функции и характеристики программного обеспечения
Клиническая функция и риски
Классификация зависит от того, как результаты работы программного обеспечения влияют на медицинские решения и какие последствия могут возникнуть при ошибочных результатах.
- Поддержка диагностики
- Рекомендации по лечению
- Мониторинг пациентов
- Риск причинения вреда
Регуляторный путь
Классификация определяет требования к документации, доказательствам соответствия и системе качества, необходимые для выхода на рынок.
- Техническая документация
- Управление рисками
- Клинические доказательства
- Участие Нотифицированной организации
Регуляторная система для медицинского программного обеспечения
Соответствие требованиям для медицинского программного обеспечения не определяется единым стандартом. Успешный выход на рынок требует согласования регуляторных требований, процессов разработки программного обеспечения, управления рисками, клинических доказательств и системы менеджмента качества.
MDRC помогает компаниям объединить эти элементы в единую регуляторную стратегию — от ранних решений на этапе разработки до подготовки технической документации и прохождения регуляторной оценки.
Разработка и контроль программного обеспечения
Процесс разработки должен быть структурированным, прослеживаемым и контролируемым на протяжении всего жизненного цикла программного обеспечения.
- IEC 62304
- Планирование разработки программного обеспечения
- Требования и архитектура
- Верификация и валидация
- Управление изменениями и сопровождение
Безопасность и эффективность
Соответствие требованиям зависит от того, как риски выявляются, контролируются и связываются с безопасным и эффективным использованием программного обеспечения.
- ISO 14971
- Аспекты кибербезопасности
- Проектирование с учетом удобства использования
- IEC 62366-1
- Обоснование соотношения польза-риск
Доказательства и качество
Программное обеспечение должно иметь необходимую доказательную базу, соответствующую документацию и поддерживаться эффективной системой менеджмента качества.
- Клиническая оценка
- Техническая документация
- ISO 13485
- Пострегистрационный надзор
- Готовность к регуляторной оценке
IEC 62304 и жизненный цикл программного обеспечения
Программное обеспечение медицинского изделия оценивается не только по его конечной функциональности. Регуляторы и Нотифицированные организации требуют доказательств того, что программное обеспечение было разработано, проверено, поддерживается и изменяется в рамках контролируемого процесса жизненного цикла.
IEC 62304 устанавливает основу для управления процессами разработки программного обеспечения и обеспечивает их планирование, документирование и прослеживаемость.
Планирование и требования
Разработка программного обеспечения начинается с определения продукта, его предполагаемого назначения, классификации по безопасности, требований и подхода к верификации.
Разработка и верификация
IEC 62304 требует применения структурированных процессов разработки программного обеспечения, включающих архитектуру, реализацию, тестирование, верификацию и обеспечение прослеживаемости.
Сопровождение и изменения
Обновления программного обеспечения, изменения, связанные с кибербезопасностью, и исправление ошибок должны контролироваться, оцениваться и документироваться для поддержания соответствия требованиям после выхода продукта на рынок.
Клинические доказательства и оценка эффективности
Соответствие требованиям для медицинского ПО требует большего, чем просто демонстрация корректной работы программы. Производитель должен предоставить доказательства того, что программное обеспечение выполняет заявленное назначение, а его результаты являются клинически значимыми, надежными и безопасными для предполагаемых пользователей.
Тип и объём необходимых доказательств зависят от предполагаемого назначения, класса риска, клинической роли программного обеспечения и заявлений производителя относительно его функций и преимуществ.
Клинические заявления
Подтвержденная клиническая ценность и заявленные преимущества
Клиническая оценка и валидация
Клиническая значимость, оценка польза-риск и обоснование заявлений производителя
Оценка эффективности
Показатели эффективности, валидационные наборы данных и оценка надежности
Техническая верификация
Тестирование программного обеспечения, верификация алгоритмов и оценка качества данных
Разработка программного обеспечения и управление рисками
Требования, процессы жизненного цикла, кибербезопасность и управление рисками
Технические характеристики
Подтверждение того, что программное обеспечение работает в соответствии с заявленными требованиями.
- Производительность алгоритмов
- Точность и надежность
- Верификация и валидация
- Оценка качества данных
- Контроль кибербезопасности
Валидация эффективности
Подтверждение того, что результаты работы программного обеспечения являются стабильными и надежными.
- Чувствительность и специфичность
- Показатели эффективности
- Сравнение с эталонным методом
- Независимые валидационные наборы данных
- Оценка моделей ИИ
Клиническая оценка
Подтверждение того, что программное обеспечение обеспечивает значимую клиническую ценность.
- Клинические заявления
- Клиническая польза
- Оценка польза-риск
- Данные литературы
- Данные клинических исследований при необходимости
Кибербезопасность и риски
Цифровые медицинские решения и технологии с использованием искусственного интеллекта связаны с дополнительными рисками, которыми необходимо управлять на протяжении всего жизненного цикла продукта.
Соответствие регуляторным требованиям обуславливает необходимость контроля данных, алгоритмов, обновлений и работы системы в целом, а не только защиты программного обеспечения от ошибок.
Кибербезопасность на протяжении жизненного цикла
Медицинское программное обеспечение должно оставаться защищенным не только на этапе выпуска, но и в процессе эксплуатации и сопровождения.
- Оценка рисков кибербезопасности
- Безопасная архитектура программного обеспечения
- Контроль доступа и аутентификация
- Управление уязвимостями
- Обновления безопасности
Особенности ИИ
Программное обеспечение с использованием ИИ связано с дополнительными рисками, касающимися данных, поведения модели и постоянной оценки эффективности.
- Качество данных для обучения и валидации
- Смещение и репрезентативность данных
- Мониторинг производительности алгоритмов
- Прозрачность и объяснимость
- Контроль со стороны человека
Пострегистрационный контроль
Программное обеспечение не остается неизменным после выхода на рынок. Изменения должны оцениваться и контролироваться.
- Мониторинг реальной эффективности
- Оценка влияния изменений
- Обновление анализа рисков
- Поддержание документации
- Постоянное обеспечение соответствия требованиям
Почему проекты разработки медицинского ПО терпят неудачу?
Проекты создания медицинского программного обеспечения часто не выдерживают регуляторную проверку не из-за недостаточного уровня технологий, а потому что регуляторные вопросы попадают в поле внимания разработчиков слишком поздно или воспринимаются ими только как задача подготовки документации, а не как часть разработки продукта.
В процессе регуляторной оценки рассматривается взаимосвязь между предполагаемым назначением, функциональностью программного обеспечения, рисками, доказательствами и процессами разработки.
Регуляторная стратегия определяется слишком поздно
Типичная проблема
Регуляторные решения принимаются уже после того, как разработка программного обеспечения значительно продвинулась.
Последствие
Ошибочная классификация, дополнительные требования к доказательствам или необходимость дорогостоящей переработки продукта.
Подход MDRC
Определение регуляторного пути до принятия критически важных решений по продукту.
Техническая документация не является просто набором документов
Типичная проблема
Техническая документация рассматривается как набор отдельных документов без единой регуляторной логики.
Последствие
Отсутствие связи между предполагаемым назначением, рисками, доказательствами и требованиями.
Подход MDRC
Формирование структурированного обоснования соответствия, поддержанного необходимыми доказательствами.
Пробелы в жизненном цикле программного обеспечения
Типичная проблема
Процессы разработки программного обеспечения не обеспечивают достаточную прослеживаемость и контроль.
Последствие
Замечания при оценке, связанные с требованиями, верификацией, валидацией или управлением изменениями.
Подход MDRC
Согласование процессов жизненного цикла программного обеспечения с требованиями IEC 62304.
Документация, созданная с помощью ИИ, требует экспертной регуляторной оценки
Типичная проблема
Документация, созданная с помощью ИИ, используется без достаточной регуляторной интерпретации и проверки.
Последствие
Ошибочные выводы относительно классификации, необходимых доказательств или мер управления рисками.
Подход MDRC
Использование ИИ как инструмента повышения эффективности при сохранении экспертной ответственности за регуляторные решения.
ИИ может ускорить регуляторную работу, но не может заменить ответственность за принятие регуляторных решений. MDRC объединяет понимание процессов разработки программного обеспечения с экспертизой в области регулирования медицинских изделий, помогая компаниям принимать обоснованные решения до того, как проблемы возникают на этапе оценки.
Готово ли ваше медицинское ПО к регуляторной проверке?
Мы помогаем компаниям определить регуляторные процедуры, применимые к продукту, установить требования к доказательной базе и документации и подготовить документы для оценки Нотифицированной организацией и FDA.
Обсудить ваш проект