Быстрое развитие и применение компьютерных технологий в современных фармацевтических процессах требует обратить соответствующее внимание на валидацию производственных компьютерных систем.
В последние годы по теме валидации компьютерных систем появились многочисленные стандарты, руководства, руководящие документы, опубликованные статьи и даже правила, большинство из которых полагаются на стандарты Института Инженеров Электрики и Электроники (Institute of Electrical and Electronics Engineers – IEEE) в части программного обеспечения.
Одним из самых ранних документов, относящимся именно к фармацевтической промышленности, была Голубая книга (The Bluebook) авторов Rick Garwood и Paul Motise, опубликованная в 1983 году. В Голубой книге особое значение придавалось валидации и качеству программного обеспечения, вопросам, которым уделялось большое внимание в большинстве последующих руководящих документов по валидации компьютерных систем (ComputerRelated System Validation – CRSV).
Обычно фармацевтические фирмы желают иметь краткие, недвусмысленные и точные правила по вопросам обеспечения качества для того, чтобы руководствоваться ими при аудите. Предпочтительно, чтобы в таких правилах содержались повелительные глаголы, такие как «следует», «будет», «должно быть», а не пассивные глаголы типа «должно бы», «может» для того, чтобы избежать дискуссий об их толковании с представителями проверяемого отдела. Стандарты, в отличие от руководящих документов, обычно удовлетворяют этим требованиям. Большинство правил в настоящее время предусматривает наличие письменных политик и процедур, касающихся каждого их аспекта.
Почти каждый документ, касающийся валидации, включает в себя стандартный подход Аттестации Установки (Installation Qualification – IQ), Аттестации в Рабочем Состоянии (Operational Qualification – OQ) и Аттестации в Процессе (Performance Qualification – PQ).
Этот подход первоначально был приведен в фармацевтических GMP и применим для валидации технологического процесса, очистки, оборудования и других типов валидации, а также валидации компьютерной системы, когда автоматизированные системы используются для контроля производственных процессов и валидируются в более широком контексте автоматизированной системы в целом.
В процессе валидации компьютерных систем возникают дополнительные осложнения, если эти информационные системы были не приобретены, а разработаны (целиком или частично) внутри компании. Кроме того, многие пакеты коммерческого программного обеспечения требуют значительной конфигурации под конкретные цели.
Для того чтобы учесть фактор внутренней разработки и конфигурации, некоторые компании используют подход из области производства медицинских устройств, включая в свою методологию валидации компьютерной системы аттестацию проекта(Design Qualification – DQ) или Верификацию и Проверку Проекта (Design Verification and Review – DVR).
Наконец, поскольку использование информационных систем в большинстве случаев не является частью повторяемых производственных процессов, раздел PQ стандартной методологии часто оказывается неприменим.
В настоящее время из правил GXP основные принципы валидации компьютерных систем и связанных с ними процессов подробнее всего установлены в области GMP, на которые обычно ориентируются как на руководство, касающееся выполнения этих основных принципов.
До появления понятия жизненного цикла валидация компьютерной системы (так же, как валидация в общем) считалась только упражнением в тестировании программного обеспечения или системы. Подход жизненного цикла помог развитию понимания того, что сам процесс разработки программного обеспечения и компьютерной системы должен также соответствовать правилам надлежащего качества, тогда как тестирование только обнаруживало проблемы и инициировало переработку, приводя в результате к «лоскутному одеялу» исправленных кодов и конфигураций.
Более того, эти правила надлежащего качества следует применять и в фазе эксплуатации системы для поддержания ее стабильного состояния и обеспечения того, чтобы система оставалась надежной и эксплуатируемой.
Валидационный Мастер-План (VMP), свой для каждой системы – это основной документ, с которого начинается любой проект валидации компьютерной системы. Хотя VMP и упоминается в большинстве современных проектов и утвержденных руководств по валидации, понимание этого термина неоднозначно в связи с существованием двух основных определений. Одно определение считает VMP ориентированным на проект, а другое описывает более глобальный документ, полностью охватывающий философию валидации фирмы.
Для уменьшения путаницы фирме следует точно определить для себя значение термина VMP, чтобы адекватно охватить как глобальное, так и связанное с проектом значение этого термина.
Отрасль программного обеспечения доказала чувствительность к функциональным нуждам своих клиентов в фармацевтической промышленности. Акцент при аудитах продавцов программного обеспечения сменился с подробного внимания к деталям разработки данной программы на внимание к самому процессу разработки поставщиком основного программного обеспечения, на оценку выполнения и системной функциональности, включая в себя надежность всех соответствующих опций конфигурации. В настоящее время (при возможности проведения) аудит производителя программного обеспечения включает в себя подтверждение того, что существует надежная практика разработки программного обеспечения (в т. ч. контроль изменений), и этой практики придерживаются.
В 1986 году, взяв пример с IEEE, Ассоциация Фармацевтических Производителей (Pharmaceutical Manufacturer Association – PMA) приняла жизненный цикл «водопада» для представления валидации компьютерных систем в своих «Концепциях валидации компьютерных систем, применяемых в производстве лекарственных продуктов» (Validation Concepts for Computer Systems Used in the Manufacture of Drug Products)3. Девять лет спустя Ассоциация Парентеральных Лекарственных Препаратов (Parenteral Drug Association – PDA) включила расширенный жизненный цикл «водопада» в свой Технический отчет № 184.
Жизненный цикл «водопада» включает в себя следующие фазы:
В 1997 году Форум GAMP опубликовал «GAMP Руководство поставщика» (GAMP Supplier Guide), версия 2.05, в котором к версиям «водопада» введен Vобразный жизненный цикл. Vобразный жизненный цикл добавляет мощную деталь соединения тестовых планов непосредственно с функциональными спецификациями при разработке этих спецификаций (схема 1).
Связь действий поставщика с действиями пользователя в валидационном процессе представлена действиями пользователя в валидационном процессе представлена на схеме 2.
«Руководство GAMP по валидации автоматических систем в фармацевтическом производстве» (The GAMP Guide for Validation of Automated Systems in Pharmaceutical Manufacture), версия 3.06, изданное в 1998 году, предлагает расширенный V-образный жизненный цикл (схема 3).
Все вышеупомянутые руководства значительно способствовали пониманию фармацевтическими фирмами и их поставщиками, как справляться с валидационными требованиями для систем, которые основаны на новой быстроразвивающейся технологии. Хотя существуют вариации, все версии жизненного цикла включают в себя одни и те же фундаментальные принципы и сравнимы друг с другом.
Жизненный цикл системы (System Lifecycle – SLC) состоит из фаз, во время которых компьютерная система концептуализируется, разрабатывается, внедряется, эксплуатируется и, наконец, изымается из обращения. Каждая фаза приводит ключевые выходы. В рамках проекта может происходить частичное перекрытие, объединение или повторение фаз, иногда приводящее к получению спиральной модели. Однако базовые требования к SLC не должны меняться.
Это начальная фаза проекта, фаза планирования. Определяются требования к системе, при этом необходимо понимание процессов, которые будут поддерживаться данной системой. Уточняются цель проекта, риски, преимущества, рассматривают альтернативные подходы и современные технологии. Разрабатывается концептуальный проект предлагаемой системы. В рабочем плане для компьютерной системы оцениваются ресурсы, требуемые для реализации проекта. Опыт всех членов команды проекта и прохождение ими обучения должны быть подтверждены. В фазу планирования должны быть внесены и валидационные действия.
Ключевые выходы из фазы планирования: рабочий план проекта и план качества проекта. Фаза не может быть закончена до тех пор, пока полностью не определены требования пользователя к системе.
Эта фаза включает в себя функциональные требования к системе со стороны пользователей и технические требования со стороны разработчиков и исполнителей. Функциональные требования определяют ожидаемые возможности системы, в т. ч. то, ЧТО система будет делать без определения, КАК именно она будет это делать. Технические требования определяют технические условия, необходимые для надлежащей работы системы.
Ключевые выходы из этой фазы: спецификации функциональных и технических требований. Недостаточно адекватное определение функциональных требований в начале проекта является самой частой причиной неудачной разработки компьютерной системы и/или ее валидации.
Цель фазы проектирования – определить, КАК именно будет достигнуто соответствие требованиям. Функциональные и технические требования, определенные во время предыдущей фазы, переводятся в такую форму, чтобы предлагаемая система была приведена в терминах физических компонентов, таких как таблицы базы данных и компоненты программы (окна, кнопки и т. д.). Проектируются все подсказки, события, ограничения и действия. Проектируются все отчеты и формы. Проектируются программные модули, сообщения и интерфейсы. В системе «клиент-сервер» определяется разделение введения данных. Требования к данным, определенные в фазу функциональной спецификации, трансформируются в логические и физические структуры, используемые разработчиками и администраторами базы данных, которые содержат таблицы базы данных, представления и перечень ограничений. Физическое проектирование базы данных включает в себя, кроме прочего, backup и стратегии восстановления.
Если выбрана система, получаемая от поставщика, детальная проектная документация может быть ограничена аспектами, сконструированными и конфигурированными фирмойпользователем, хотя полная проектная документация должна быть подтверждена во время аудита поставщика.
Ключевые выходы из фазы проектирования: детальные проектные спецификации.
В фазе создания системы происходит конструирование программного обеспечения. Полностью разрабатываются все рабочие единицы (модули, окна, отчеты и т.д.). Каждая часть продукта проверяется для того, чтобы процессные и логические ошибки, а также недействующие и неэффективные решения могли быть определены и скорректированы. Рабочие единицы интегрируются, в результате получается полностью функциональный продукт, который затем конфигурируется требованиями окружающей среды, для которой он предназначен.
Ключевые выходы из фазы создания системы – система, конфигурированная в соответствии с параметрами фирмыпользователя.
Во время фазы тестирования проводится верификация для подтверждения того, что продукт, интерфейсы системы и пользователя, контрольные операции и обработка ошибок технически правильны и выверены в соответствии с функциональными требованиями. Тестирование документируется в организованных протоколах тестов, после чего разрабатывается окончательный отчет о результатах теста. Документация тестирования подписывается и датируется лицами, проводящими тестирование.
Ключевые выходы фазы тестирования обычно содержат протоколы технических / функциональных тестов и окончательный отчет.
Фаза выполнения включает в себя действия, требуемые для того, чтобы координировать и успешно работать с системой в предполагаемых производственных окружающих условиях. Для персонала технической поддержки, а также пользователей системы проводится обучение. С персоналом технической инфраструктуры устанавливаются соглашения по обслуживанию в соответствии с доступностью системы, back-up, восстановлению и т. д. Разрабатываются планы миграции/перевода данных. Проводится пробный запуск с последующей проверкой.
Ключевыми выходами фазы выполнения обычно являются: производственная версия системы, инструкции по выполнению, обучающие материалы и записи, соглашения по обслуживанию, авторизация ввода системы в эксплуатацию и окончательные руководства пользователя и инструкции по эксплуатации.
Фаза эксплуатации охватывает время между первоначальным вводом системы в работу и изъятием системы из обращения. Во время этой фазы сохраняется валидированное состояние системы за счет тщательного отслеживания нарушений и процесса их исправления. Для системы ведется история изменений и при необходимости проводится ревалидация/переаттестация.
Ключевые выходы фазы эксплуатации: история изменения систем и связанная с ней документация, журналы системы, записи возникающих проблем, технического обслуживания и безопасности.
Фаза изъятия из обращения содержит в себе изъятие фирмой системы из активного использования. Когда систему изымают из обращения, следует предусмотреть: как могут быть изменены данные, если это будет признано нужным; как они будут храниться и какова возможность их восстановления при необходимости.
Ключевые выходы фазы изъятия из обращения: документация, содержащая требования к хранению данных, к процессу изъятия из обращения, которого необходимо придерживаться, а также документация по процессу выведения системы из рабочего статуса, в т. ч. любые действия конверсии данных вместе с планом-графиком выполнения и утверждения.
Должна быть корреляция между элементами ключевых выходов различных фаз и валидационными документами; например, корреляция между функциональными требованиями и тестированием на соответствие этим требованиям. Эта корреляция может быть продемонстрирована путем использования матрицы отслеживания, которая способствует поддержанию перекрестных ссылок между требованиями и обеспечивает соответствие элементов проекта и тестов этих элементов. Во время фазы проектирования матрица отслеживания может помочь оценке проекта; по корреляции между требованиями к проекту и его элементам может выявить несоответствия и упущения.
Кроме того, формирование матрицы отслеживания может помочь обеспечить адекватное покрытие теста в фазе тестирования. В фазе эксплуатации системы, если какиелибо требования или элементы проекта должны быть модернизированы в связи с изменениями, легко определить, какие другие документы затрагиваются и/или какие тесты должны быть заново проведены при внесении данного изменения. Другими словами, польза матрицы отслеживания не может быть преувеличена.
Другой важный аспект исчерпывающей системы валидации – это квалификация и постоянное стабильное состояние архитектуры, на которой находится система и от которой она зависит (серверы, сеть, устройства связи и т. д.). Обычно она располагается в центре данных и обслуживается персоналом по работе с инфраструктурой, однако, она является неотъемлемой частью системы в целом и поэтому должна быть включена в валидационные действия жизненного цикла. Инфраструктура часто поддерживает многие системы, поэтому вместо того, чтобы проводить квалификацию каждой системы, можно централизованно квалифицировать инфраструктуру на регулярной основе (поддерживая контролем изменений) и ссылаться на квалификацию инфраструктуры в каждом пакете валидации системы.
Необходимо, чтобы между теми, кто разрабатывает программное обеспечение и тем, кто позднее управляет им и контролирует его, была налажена хорошая связь, эффективная передача технологии и поддержка переходных мер.
Валидация компьютерной системы должна продолжаться в течение всего жизненного цикла системы вплоть до ее окончательного изъятия из обращения. Во время фазы эксплуатации системы необходимо проводить периодическую оценку, контроль изменений и ревалидацию для обеспечения стабильности системы, ее надежности и надлежащей работы.