Контекст
Медицинское ПО существует в пространстве пересечения нескольких регуляторных систем, каждая из которых предъявляет конкретные требования к разработке, документированию и контролю качества. 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' — каждое решение должно быть обоснованным и подписанным