Валидация компьютерных систем: жизненный цикл

Валидация компьютерных систем: жизненный цикл

Е.М. Сорокина, менеджер по качеству МПБП «ФГУП НПО «Микроген» МЗ РФ

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

В последние годы по теме валидации компьютерных систем появились многочисленные стандарты, руководства, руководящие документы, опубликованные статьи и даже правила, большинство из которых полагаются на стандарты Института Инженеров Электрики и Электроники (Institute of Electrical and Electronics Engineers – IEEE) в той части, которая касается программного обеспечения. Одним из самых ранних документов, относящимся именно к фармацевтической промышленности, была Голубая книга (The Bluebook) авторов Rick Garwood и Paul Motise, опубликованная в 1983 году. В Голубой книге особое значение придавалось валидации программного обеспечения и качеству программного обеспечения, вопросам, которым уделялось большое внимание в большинстве последующих руководящих документов по валидации компьютерных систем (Computer-Related System Validation – CRSV).

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

  По вопросу GXP

Почти каждый документ, касающийся валидации, включает стандартный подход Аттестации Установки (Installation Qualification IQ), Аттестации в Рабочем Состоянии (Operational Qualification OQ) и Аттестации в Процессе (Performance Qualification PQ). Этот подход первоначально был описан в фармацевтических GMP и применим   для валидации процесса, очистки, оборудования и других типов валидации, а также валидации компьютерной системы, когда автоматизированные системы используются для контроля производственных процессов и валидируются в более широком контексте автоматизированной системы в целом.

В процессе валидации компьютерных систем возникают дополнительные осложнения, если эти информационные системы были разработаны, целиком или частично, внутри компании, а не приобретены. Кроме того, многие пакеты коммерческого программного обеспечения требуют значительной конфигурации под конкретные цели. Для того чтобы учесть фактор внутренней разработки и конфигурации, некоторые компании используют подход из области производства медицинских устройств, включая в свою методологию валидации компьютерной системы аттестацию проекта (Design Qualification DQ) или Верификацию и Проверку Проекта (Design Verification and Review – DVR). Наконец, поскольку использование информационных систем в большинстве случаев не является частью повторяемых производственных процессов, раздел PQ стандартной методологии часто оказывается неприменим.

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

  Подход жизненного цикла

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

  Валидационный мастер-план

Валидационный мастер-план (VMP), свой для каждой системы – это основной документ, с которого начинается любой проект валидации компьютерной системы. Хотя VMP и упоминается в большинстве современных проектов и утвержденных руководств по валидации, понимание этого термина запутано в связи с существованием двух основных определений. Одно определение считает VMP ориентированным на проект, а другое описывает более глобальный документ, охватывающий всю философию валидации фирмы.

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

Аудит производителя программного обеспечения

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

  Жизненные циклы: водопад и V

В 1986 году, взяв пример с IEEE, Ассоциация Фармацевтических Производителей (Pharmaceutical Manufacturer Association – PMA) приняла жизненный цикл «водопада» для описания валидации компьютерных систем в своих «Концепциях валидации компьютерных систем, используемых в производстве лекарственных продуктов» (Validation Concepts for Computer Systems Used in the Manufacture of Drug Products) 3. Девять лет спустя Ассоциация Парентеральных Лекарственных Препаратов (Parenteral Drug Association – PDA) включила расширенный жизненный цикл «водопада» в свой Технический отчет № 18 4.

Жизненный цикл «водопада» включает следующие фазы:

1.       Запланировать валидационные действия.

2.       Определить требования к компьютерной системе.

3.       Выбрать поставщика компьютерной системы.

4.       Разработать компьютерную систему.

5.       Сконструировать компьютерную систему.

6.       Интегрировать и установить компьютерную систему.

7.       Аттестовать компьютерную систему.

8.       Оценить компьютерную систему в ее рабочей среде.

В 1997 году Форум GAMP опубликовал «Руководство по GAMP для поставщика» (GAMP Supplier Guide), версия 2.0 5, в котором к версиям «водопада» добавлен V-образный жизненный цикл. V-образный жизненный цикл добавляет мощную деталь соединения тестовых планов непосредственно с функциональными спецификациями при разработке этих спецификаций (см. Схему 1). Схема 2 представляет связь действий поставщика с действиями пользователя в валидационном процессе.

«Руководство GAMP по валидации автоматических систем в фармацевтическом производстве» (The GAMP Guide for Validation of Automated Systems in Pharmaceutical Manufacture), версия 3.0 6, выпущенное в 1998 году, предлагает расширенный V-образный жизненный цикл (см. Схему 3).

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

Фазы Жизненного Цикла

Жизненный цикл системы (System Lifecycle SLC) состоит из фаз, во время которых компьютерная система концептуализируется, разрабатывается, внедряется, эксплуатируется и, наконец, изымается из обращения. Каждая фаза дает ключевые выходы. В рамках проекта может происходить частичное перекрытие, объединение или повторение фаз, иногда приводящее к получению спиральной модели. Однако базовые требования к SLC не должны меняться.

1. Спецификация требований пользователя

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

Ключевые выходы из фазы планирования: рабочий план проекта и план качества проекта. Фаза не может быть закончена до тех пор, пока полностью не определены требования пользователя к системе.

  2. Функциональная спецификация

Эта фаза включает как функциональные требования к системе со стороны пользователей, так и технические требования со стороны разработчиков и исполнителей. Функциональные требования определяют ожидаемые возможности системы, включая то, ЧТО система будет делать без определения, как именно она будет это делать. Технические требования определяют технические условия, необходимые для надлежащей работы системы.

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

  3. Спецификация проекта

Цель фазы проектирования – определить, КАК именно будет достигнуто соответствие требованиям. Функциональные и технические требования, определенные во время предыдущей фазы, переводятся в такую форму, чтобы предлагаемая система была описана в терминах физических компонентов, таких как таблицы базы данных и компоненты программы (окна, кнопки и т.д.). Проектируются все подсказки, события, ограничения и действия. Проектируются все отчеты и формы. Проектируются программные модули, сообщения и интерфейсы. В системе клиент-сервер определяется разделение введения данных. Требования к данным, определенные в фазу функциональной спецификации, трансформируются в логические и физические структуры, используемые разработчиками и администраторами базы данных, которые включают таблицы базы данных, представления и описания ограничений. Физическое проектирование базы данных включает, кроме прочего, back-up и стратегии восстановления.

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

Ключевые выходы из фазы проектирования: детальные проектные спецификации.

  4. Создание системы

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

Ключевые выходы из фазы создания системы – система, конфигурированная в соответствии с параметрами фирмы-пользователя.

  5. Тестирование (Аттестация)

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

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

  6. Выполнение

Фаза выполнения включает в себя действия, требуемые для того, чтобы координировать и успешно работать с системой в предполагаемых производственных окружающих условиях. Для персонала технической поддержки, а также пользователей системы проводят обучение. С персоналом технической инфраструктуры устанавливают соглашения по обслуживанию в соответствии с доступностью системы, back-up, восстановлению и т.д. Разрабатывают планы миграции/перевода данных. Проводят пробный запуск с последующей проверкой.

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

  7. Эксплуатация

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

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

  8. Изъятие из обращения

Фаза изъятия из обращения имеет в виду изъятие фирмой системы из активного использования. Когда систему изымают из обращения, следует предусмотреть, как могут быть изменены данные, если это будет признано нужным, как они будут храниться и как возможно будет их восстановить при необходимости.

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

  Матрица отслеживания

Должна быть корреляция между элементами выходов различных фаз и валидационными документами; например, корреляция между функциональными требованиями и тестированием на соответствие этим требованиям. Эта корреляция может быть продемонстрирована путем использования матрицы отслеживания 7, которая способствует поддержанию перекрестных ссылок между требованиями и обеспечивает соответствие элементов проекта и тестов этих элементов. Во время фазы проектирования матрица отслеживания может помочь оценке проекта, по корреляции между требованиями к проекту и его элементами может выявить несоответствия и упущения. Кроме того, формирование матрицы отслеживания может помочь обеспечить адекватное покрытие теста в фазе тестирования. В фазе эксплуатации системы, если какие-либо требования или элементы проекта должны быть модернизированы в связи с изменениями, легко определить, какие другие документы затрагиваются и/или какие тесты должны быть заново проведены при внесении данного изменения. Другими словами, польза матрицы отслеживания не может быть преувеличена.

  Квалификация и контроль изменений архитектуры компьютерной системы

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

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

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

Литература:

1.       Институт Комитета Стандартов Технологии Валидации. Предлагаемый стандарт валидации VS-2 «Валидация систем, связанных с компьютерами». Журнал технологии валидации. Том 7, № 3. Май 2001. Стр. 190-210.

2.       Материалы Конференции ISPE «GAMP 4 – Принципы и Применение» 20-23 сентября 2004 г .

3.       Ассоциация Фармацевтических Производителей. «Концепции валидации компьютерных систем, используемых в производстве лекарственных продуктов». Фармацевтическая технология. Том 10 (5), 1987, стр. 24-34.

4.       Ассоциация Парентеральных Лекарственных Препаратов. «Валидация систем, связанных с компьютером: технический отчет № 18». Журнал Фармацевтической Технологии. Том 49 (S1).

5.       Форум GAMP. «Руководство по GAMP для поставщика: версия 2.0». Май 1996.

6.       Международное Общество Фармацевтической Инженерии. «Руководство GAMP по валидации автоматизированных систем в фармацевтическом производстве: версия 3.0». Тома 1-2. Март 1998.

7.       FDA. «Руководство для отрасли – общие принципы валидации программного обеспечения». Проект Руководства версия 11. 9 июня 1997