Валидация в фармацевтике – что это, требования, этапы валидации

Что такое валидация ИТ-систем в фармацевтике

Цели валидации в фармацевтике

Обеспечение качества, безопасности и эффективности лекарственных препаратов

Это главная и приоритетная цель. Компьютеризированная система в фармацевтическом производстве, как правило, участвует в процессах, от которых зависит конечное качество продукта: управляет рецептурами и технологическими параметрами, фиксирует результаты контроля качества, формирует записи об отклонениях. Ошибка может привести к выпуску препарата, не отвечающего требованиям безопасности.

Валидация гарантирует, что программа работает именно так, как задумано, и не вносит искажений в данные, на основе которых принимаются производственные решения.

Соответствие регуляторным требованиям

При организации валидации в фармацевтической компании обычно учитывают несколько уровней требований и методических подходов.

• Правила GMP и иные применимые требования GxP, действующие в юрисдикции компании.
• GAMP 5 Second Edition как признанное на международном уровне руководство по валидации компьютеризированных систем на основе оценки рисков. Он объединил практическую интерпретацию регуляторных требований, общую терминологию, жизненный цикл системы, распределение ролей и риск-ориентированный подходе.
• ICH Q9(R1) как базовый документ по управлению рисками качества.
• Рекомендация Коллегии ЕЭК от 12.11.2018 № 25 «О Критериях отнесения продукции к медицинским изделиям в рамках Евразийского экономического союза»

Снижение рисков ошибок, потери и искажения данных

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

Повышение доверия регуляторов и аудиторов в компании

В ходе GMP-проверок аудиторы запрашивают валидационную документацию как свидетельство, что компания управляет рисками. Наличие актуального и полного валидационного пакета сокращает время инспекции, снижает вероятность критических замечаний и формирует репутацию надежного производителя и партнера

Как часто валидировать ИТ-системы

Корректнее говорить не о разовой валидации, а об управлении валидированным состоянием на протяжении жизненного цикла. Практически это означает несколько типов действий.

• Первичная валидация — при внедрении новой системы или новом использовании существующей.
• Частичная ревалидация — дпосле изменений, обновлений, новых интеграций, существенной перенастройки, миграции данных или изменения инфраструктуры.
• Периодический обзор — с частотой, установленной внутренними процедурами и основанной на риске.
• Внеплановая оценка — после серьезных инцидентов, нарушений целостности данных, повторяющихся отклонений, проблем с поставщиком, существенных замечаний аудита или длительного отсутствия поддержки.

Если система долго не обновляется, поставщик прекратил поддержку, не проводится анализ инцидентов или не выполняется пересмотр рисков, регулятор может усомниться в том, что валидированное состояние действительно поддерживается.

Какие ИТ-системы подлежат валидации

На практике под валидацию попадают самые разные классы систем:

• ERP-системы;
• MES — программы для оперативного управления производством;
• LIMS — системы управления лабораторными данными;
• WMS — решения для управления складом;
• Электронный документооборот;
• Системы управления качеством.

Валидация при переходе с зарубежных решений

После ухода западных вендоров с российского рынка многие фармпроизводители оказались перед выбором: переходить на отечественные решения или продолжать работу в привычных программах.

За годы работы с имеющейся системой компания формирует весомый актив: пройденные GMP-инспекции, накопленный пакет валидационной документации, отлаженные процедуры и обученный персонал. К старой программе у регуляторов не было претензий, а это значит, что инспекционный риск минимален. Любая замена ключевой системы означает повторный полный объём валидационных работ, новые риски при следующей инспекции и неизбежные ресурсные затраты.

При переходе на новую платформу компания обязана заново пройти полный валидационный цикл, от оценки рисков до выполнения квалификационных испытаний. Каждый этап требует времени, экспертизы и совмещения с текущими производственными задачами. Отдельная сложность — организация всех сторон: интегратора, ИТ-службы и отдела качества, который несет ответственность за соответствие GMP. Ключевые сотрудники внутренних служб на время проекта выключаются из своих основных обязанностей, поэтому что создает дополнительную нагрузку на подразделения.

Именно поэтому успешные проекты перехода в фармацевтике, как правило, начинаются задолго до планируемой даты запуска и опираются на интегратора с опытом работы в GMP-среде, способного взять на себя методологическое сопровождение валидации.

• Вендор ушел, но система работает

Валидационный статус — не константа, его необходимо поддерживать. Если разработчик ушел с рынка, продукт не обновляется, страдает информационная безопасность, растет риск нарушения целостности данных — одного из ключевых требований GMP. Если в ходе инспекции будет обнаружено, что решение не обновлялось долгий период, регулятор вправе поставить под сомнение валидность всего пакета документации.

Кроме этого, в случае возникновении инцидента (при потере данных, нарушении прослеживаемости или других проблемах) компании не к кому обратиться за официальной технической поддержкой. Это прямо влияет на способность выполнить требование об управлении инцидентами, которое проверяется в ходе аудита.

• Валидация нового решения дороже, чем сопровождение старой системы

Затраты на проверку новой программы единовременны и предсказуемы, а стоимость поддержания валидного статуса будет постоянно увеличиваться:

• Растут риски инспекционных замечаний, так как регулятор следит за жизненным циклом ИТ-систем;
• Развитие сложнее (добавление новых модулей, интеграция с другими решениями), что влияет на эффективность работы;
• Использование ПО без действующего договора поддержки может нарушать условия лицензионного соглашения.

Совокупная стоимость этих рисков нередко превышает стоимость миграции.

Как проходит процесс валидации

GAMP 5 описывает валидацию как непрерывный жизненный цикл, который начинается до старта проекта внедрения. Ниже приведены ключевые этапы.

Планирование и оценка влияния

Сначала проводится анализ влияния процессов и функций системы на качество продукта и данные GMP, определяется, кто является владельцем процесса и системы, представителем качества, ИТ-структуры, бизнеса и поставщика. Для крупных проектов валидационные работы начинаются с разработки Валидационного плана (VMP) — документа, который определяет область применения валидации, зоны ответственности команды, сроки и применяемые стандарты. В ходе оценки влияния определяется, какие функции системы критичны и почему.

Обязательно проанализировать:

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

Результат этой работы определяет глубину спецификаций и верификации.

Оценка поставщика и модели поставки

Если используется типовое решение, облачный сервис или платформа интегратора, необходимо оценить надежность поставщика. Для этого обычно рассматривают зрелость процессов разработки и сопровождения, управление изменениями и релизами, документацию на продукт, порядок обработки инцидентов и проблем, подход к информационной безопасности, резервное копирование, восстановление и непрерывность сервиса, условия уведомления о значимых изменениях.

В актуальной редакции GAMP 5 поставщики облачных сервисов и ИТ-услуг рассматриваются как важная часть доказательной базы, но ответственность за пригодность системы для предполагаемого использования всё равно остаётся у фармацевтической компании.

Оценка рисков

После определения требований проводится оценка рисков. На этом этапе определяются критические функции и блоки, потенциальные точки отказа, оценивается, насколько подробно нужно тестировать данный блок.

Критерии, указанные в ICH Q9(R1), дополнительно влияют на проекты валидации:

• Уровень формализации должен соответствовать значимости решения и масштабу риска. Не для каждой функции нужен одинаково тяжёлый пакет документов, но для критичных процессов упрощения недопустимы.
• Оценка риска должна снижать субъективность. Решения о глубине тестирования, объёме контроля и допустимости остаточного риска должны приниматься на основе заранее определенных критериев, а не личного мнения участников проекта.
• Управление рисками не заканчивается на этапе запуска. Риски необходимо пересматривать после изменений, инцидентов, отклонений, обновлений, миграции данных и результатов периодического обзора.
• Ключевым элементом является культура качества и качество принимаемых решений. Даже хорошая методика не работает, если команда формально заполняет матрицы рисков, но не обсуждает реальные сценарии отказов и влияния на данные.

Проектирование и настройка системы

Если программа требует доработки, разрабатываются технические спецификации: FDS (Functional Design Specification) описывает, как именно функция реализована, а в SDS (Software Design Specification) содержатся технические детали реализации. Для настраиваемых решений, таких как 1С, особое внимание уделяется документированию конфигурации: все отступления от типовой поставки фиксируются, чтобы при последующих обновлениях или аудите было понятно, что и зачем было изменено. Также на этом этапе настраивают интеграции с другими системами.

Тестирование и квалификация

Испытания должны подтверждать, что система реализована в соответствии с требованиями и работает корректно в реальных условиях использования. В зависимости от типа решения и принятой методологии это могут быть:

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

GAMP 5 допускает адаптацию структуры верификации, если сохраняются прослеживаемость, адекватность доказательств и контроль критичных аспектов. Также актуальная практика допускает использование испытаний поставщика, автоматизированных тестов и иных готовых доказательств при условии, что их пригодность оценена и документально подтверждена.

Управление отклонениями и выпуск в эксплуатацию

Если в ходе тестирования обнаруживаются несоответствия, они должны быть зарегистрированы, оценены по степени влияния и устранены либо формально обоснованы. До ввода системы в эксплуатацию необходимо убедиться, что критичные отклонения закрыты, остаточные риски оценены и приняты уполномоченными лицами, утверждены процедуры эксплуатации и администрирования, выполнено обучение пользователей и администраторов.

После завершения итоговой оценки готовности квалификационных испытаний составляется отчет, который подписывается ответственными со стороны ИТ, отдела качества и руководства. После утверждения этого документа система получает официальный статус «провалидирована» и допускается к работе с GMP-данными. Параллельно разрабатываются пользовательские инструкции и СОП, а персонал проходит обучение, факт обучения также документируется.

Эксплуатация и поддержание валидационного статуса

Это один из самых недооцененных этапов. После запуска система не перестает быть объектом валидации. Напротив, именно в эксплуатации чаще всего возникают реальные риски для данных и соответствия. Для поддержания статуса необходимо:

• управлять изменениями с оценкой влияния на GxP-функции;
• управлять инцидентами и проблемами;
• проводить периодические обзоры системы;
• контролировать доступы и регулярно пересматривать роли;
• совершать резервное копирование и проверку возможности восстановления;
• убедиться, что у вас действует сопровождение поставщика и контроль обновлений;
• отслеживать риски и актуальность поддерживаемой инфраструктуры;
• управлять архивированием и выводом системы из эксплуатации.

Периодический обзор нужен для подтверждения, что система по-прежнему соответствует требованиям, остаётся пригодной для предполагаемого использования и соответствует внутренним политикам компании, включая требования к целостности данных.

Как снизить сложность и стоимость валидации при переходе на новые решения

Валидация при смене системы действительно требует ресурсов, но её стоимость и сроки во многом определяются тем, насколько грамотно выстроен сам проект. Есть несколько практических подходов, которые реально сокращают нагрузку.

• Раннее вовлечение ответственных за качество и валидацию в проект внедрения.
• Четкое определение GxP-периметра и критичных функций.
• Использование документации и результатов испытаний поставщика там, где это обосновано.
• Разделение типовых и критичных сценариев, чтобы не перегружать тестирование низкорисковыми случаями.
• Встраивание требований к валидации в общее управление проектом, а не ведение их параллельно и изолированно.
• Применение повторно используемых шаблонов, библиотек тестов и проверенных процедур.
• Планирование эксплуатации еще на этапе проекта: роли поддержки, резервное копирование, обучение, периодический обзор, управление изменениями.

Именно такой подход соответствует и современной редакции GAMP 5, и принципам ICH Q9(R1): достаточный уровень формализации, обоснованность решений и фокус на реально значимых рисках.

Заключение

Валидация ИТ-систем в фармацевтике подтверждает, что данные, на основе которых принимаются производственные решения, достоверны и защищены, а решение работает предсказуемо вне зависимости от обстоятельств. В условиях, когда у российских фармпроизводителей есть необходимость замещения зарубежных решений, валидация становится одним из ключевых факторов успеха проектов. Компания Первый Бит готова помочь с переходом или внедрением ИТ-систем с прохождением процедуры валидации. Мы обладаем опытом фармацевтических проектов, доработки решений в соответствии с требованиями и отраслевой спецификой, валидации ИТ-систем, а также готовы оказывать техническую и консультационную поддержку в ходе использования продукта.