FDA 21 CFR Part 11, MDR и IEC 62304: что должен знать QA-инженер · 14 мин
🎯 Цель урока

Научиться ориентироваться в ключевых международных регуляторных стандартах, применимых к медицинскому ПО. Понять, как требования FDA 21 CFR Part 11, IEC 62304 и EU MDR влияют на тестовую документацию и процессы QA. Уметь связывать конкретные артефакты тестирования с регуляторными обязательствами.

Контекст

Медицинское ПО существует в пространстве пересечения нескольких регуляторных систем, каждая из которых предъявляет конкретные требования к разработке, документированию и контролю качества. FDA 21 CFR Part 11 действует в США и регулирует электронные записи и подписи — он требует, чтобы электронные документы были юридически равнозначны бумажным. IEC 62304 — международный стандарт жизненного цикла медицинского ПО, применимый вне зависимости от юрисдикции. EU MDR (Regulation 2017/745) распространил понятие медицинского изделия на автономное ПО, что существенно расширило круг продуктов, требующих регуляторного одобрения.

  • 21 CFR Part 11 требует аудит-трейла: кто создал запись, кто изменил, когда и с какой причиной
  • IEC 62304 делит ПО на классы безопасности A, B, C — от отсутствия вреда до возможности летального исхода
  • EU MDR требует клинической оценки даже для ПО, ранее не считавшегося медицинским изделием
  • QA обязан производить документы, доказывающие прослеживаемость от требований через тесты до риска
  • Несоответствие регулятору — не только штраф, но и отзыв продукта с рынка

Рабочий алгоритм

Алгоритм работы QA-инженера при подготовке к регуляторному аудиту или выпуску продукта охватывает шесть ключевых шагов.

  • Определить применимые стандарты: рынок сбыта (FDA — США, MDR — ЕС), класс устройства, класс безопасности ПО по IEC 62304
  • Запросить у команды разработки Software Development Plan (SDP) и убедиться, что процессы QA соответствуют выбранному классу
  • Составить или обновить RTM (Requirements Traceability Matrix), связав каждое требование с тест-кейсом и риском
  • Проверить настройку системы управления конфигурациями: все изменения в коде должны иметь тикет, ревью и одобрение
  • Выполнить аудит журналов (audit log): убедиться, что система фиксирует timestamp, user ID, action type и причину изменения
  • Подготовить Summary Report — сводный документ, подтверждающий завершение всех тест-активностей и закрытие дефектов

Пример из практики

Команда QA крупного вендора EMR-систем готовилась к FDA-инспекции после обнаружения CAPAи (корректирующих действий) по итогам предыдущего аудита. Инспекторы потребовали доказательства того, что все изменения ПО, внесённые после последнего релиза, прошли полный цикл верификации согласно IEC 62304 класс B. QA-команда обнаружила, что 12 хотфиксов были задеплоены без обновления RTM и без регрессионного тестирования задокументированных требований. В течение двух недель команда провела ретроспективное тестирование, восстановила трассируемость и подготовила CAPA-отчёт с описанием системных изменений в процессе управления изменениями. Инспекция была успешно пройдена, однако инцидент стал толчком к внедрению обязательной валидации RTM как gate-критерия перед любым деплоем в продакшн.

Частые ошибки

Даже опытные QA-инженеры допускают характерные ошибки при работе с медицинскими регуляциями.

  • Игнорирование класса безопасности IEC 62304: применение процессов класса A к ПО класса C создаёт критический регуляторный риск
  • Обновление RTM только перед аудитом, а не в реальном времени — это делает матрицу фиктивным документом
  • Непонимание разницы между электронной подписью (21 CFR Part 11) и обычной аутентификацией — они имеют разные технические требования
  • Тестирование только функциональности без проверки самого audit trail — регулятор проверяет именно полноту и целостность журнала
  • Отсутствие документирования причин отклонения дефектов как 'not a defect' — каждое решение должно быть обоснованным и подписанным

Самопроверка

1Какие три свойства электронных записей требует FDA 21 CFR Part 11?
Достоверность (trustworthy), надёжность (reliable) и юридическую равнозначность бумажным записям (equivalent to paper). На практике это означает защищённость от несанкционированного изменения, полноту audit trail и корректную привязку электронной подписи к конкретной записи.
2Чем IEC 62304 класс C отличается от класса A с точки зрения требований к тестированию?
Класс C предполагает максимально строгий набор процессов: полная трассируемость требований, обязательное code review, строгое управление конфигурациями, полная регрессия при любом изменении. Класс A допускает упрощённые процессы, поскольку отказ ПО не может привести к серьёзному вреду.
3Почему EU MDR важен для QA-инженеров, работающих с программным обеспечением?
EU MDR расширил категорию медицинских изделий, включив в неё автономное ПО (SaMD). Это означает, что продукты, ранее не требовавшие регуляторного одобрения, теперь обязаны проходить полный цикл оценки соответствия, включая клиническую оценку и QMS по ISO 13485, что существенно увеличивает объём документации и тестовых артефактов.