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

9–10 июля в Киеве состоялся тренинг, посвященный вопросам валидации компьютеризированных систем в соответствии с требованиями надлежащей производственной практики (Good Manufacturing Practice — GMP), который собрал представителей ведущих локальных производителей, что свидетельствует об актуальности этой темы. Автором и ведущим тренинга, организованного компанией «Стандарты Технологии Развитие», выступил Жансен Фабрис — специалист в сфере информационных технологий и валидации компьютеризованных систем в соответствии с требованиями GMP, 21CFR Part 11, методологиями надлежащей практики автоматизации производственных процессов (Good Automated Manufacturing Practices — GAMP) и библиотекой инфраструктуры информационных технологий (Information Technology Infrastructure Library — ITIL), имеющий многолетний опыт работы в мультинациональных фармацевтических компаниях.

На сегодня соблюдение требований GMP отечественными и зарубежными фармацевтическими компаниями является обязательным условием для обращения лекарственных средств в Украине. С 1 января 2011 г. Государственная служба Украины по лекарственным средствам стала членом международной Системы сотрудничества фармацевтических инспекций (Pharmaceutical Inspection Cooperation Scheme — РIC/S), что позволило оптимизировать процесс получения сертификата о соответствии требовании GMP.

Что же такое валидация компьютеризированных систем, и зачем ее проводят?

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

Однако в требованиях GMP (Vol.4 Annex 11: Computerised Systems) указано только, «что должно быть сделано», и не уточняется, «каким образом». Для решения этой проблемы, унификации и упрощения деятельности субъектов хозяйствования разработан ряд методологий, в которых в общих чертах раскрываются подходы относительно достижению описанного в GMP результата. Среди таких руководств можно выделить 21CFR Part 11, GAMP V, ITIL и другие.

Валидация компьютеризированных систем в контексте GMPФабрис Жансен во время тренинга рассказал о методологии GAMP и нюансах ее применения на практике. Согласно его мнению, она содержит исчерпывающую информацию о практических аспектах проведения валидации.

GAMP издает Международное общество фармацевтического инжиниринга (International Society for Pharmaceutical Engineering — ISPE). Положения этого документа не являются обязательными к исполнению, но он представляет собой методологию, которая помогает соответствовать требованиям GMP.

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

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

Валидация состоит из таких процессов:

  • квалификация проектной документации (Design Qualification — DQ) — проверка описания и разработки системы;
  • квалификация инсталляции (монтажа) (Installation Qualification — IQ) — проверка способности инфраструктуры системы поддерживать работу системы;
  • квалификация функционирования (Operational Qualification, OQ) — проверка способности функционировать согласно требованиям;
  • квалификация эксплуатации (Performance Qualification — PQ) — проверка способности компании использовать систему.

Объем мероприятий, проводимых при валидации компьютеризированных систем, определяется с учетом критичности процесса для качества продукта (оценка рисков), сложности системы и стандартности/нестандартности используемого оборудования, технологий, программного обеспечения. В соответствии с GAMP компьютеризированные системы подразделяются на 5 категорий:

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

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

Таблица 1 Этапы валидации по GAMP в зависимости от типа внедряемой компьютеризированной системы

GAMP

Аудит поставщика

DQ

IQ (версии)

IQ (параметры)

OQ

PQ

Системное программное обеспечение (ПО)

+

Микропрограмма (ПО в аппаратных устройствах)

+

+

±

ПО, готовое для использования

±

±

+

+

+

±

Конфигурируемое ПО

±

+

+

+

+

±

Самостоятельно разработанное специальное ПО

+

+

+

+

+

+

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

Процедури державних закупівель наближаються до завершення

Рисунок. Процедури державних закупівель наближаються до завершення

Подготовка — ключ к успеху

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

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

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

На начальном этапе при подготовке и организации процесса валидации компьютеризированных систем необходимо составить Валидационный мастер-план (Validation Master Plan) — документ, в котором будет указан перечень систем, подлежащих валидации, сроки и должностные лица, ответственные за каждый этап процесса. Для организации валидации каждой системы составляются отдельные валидационные планы. Затем проводится описание системы и ее спецификаций.

Выбор или создание системы осуществляется на основе потребностей ее будущих пользователей, а также нормативных требований, таких как GMP, 21CFR11, национальная законодательная база, ГОСТ. С помощью этой информации создается спецификация требований пользователей (User Requirements Specification — URS) (табл. 2). Это очень важный и ответственный этап работы, поскольку примерно 20–40% стоимости проекта приходится на внесение изменений вследствие изменения требований пользователей. Поэтому при формировании URS необходимо изучить потребности пользователей. При этом можно отталкиваться от таких базовых характеристик, которым должны соответствовать URS:

  • трассируемость — отслеживаемость взаимосвязи между всеми процессами в системе;
  • соблюдение требований обеспечивающих качество, безопасность;
  • интерфейс (способность взаимодействовать, обмениваться данными с другими системами);
  • нормы (требования GMP, 21CFR Part 11);
  • материальная база (серверы, принтеры, программное обеспечение и т.д.).
  • необходимость предвидеть возможность для дальнейшего развития системы.
Таблица 2 Пример составления URS

URS №

Описание требования

Приоритет

Т001

Вход в систему

Пользователь должен использовать уникальный идентификатор (login) и пароль для входа в систему

Доступ к системе должен соответствовать требования GMP (методология GАMP) и внутренним правилам компании

высокий

При составлении URS можно пользоваться шаблонами, в которых уже учтены основные нормативные требования GхP. Требования, внесенные в URS, должны быть максимально детализированы, понятны, и не должны содержать относительных характеристик. При этом URS отображают только требования к программе и не решают вопрос, каким образом это должно быть воплощено на практике. URS определяет, чем система будет управлять, с какими программами или оборудованием будет взаимодействовать (обмениваться данными), кто ею будет пользоваться и каким нормам она должна соответствовать.

На завершающем этапе составления URS документ проверяет отдел контроля качества.

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

Готовые и одобренные соответствующими структурами компании URS передаются будущему поставщику программы (если разработка системы передана на аутсорсинг) или в IТ-отдел компании, или отдел бизнес-приложений (Business Applications — IS), в случае существования последнего. На следующем этапе поставщик или IТ-отдел, или IS-отдел составляют функциональные требования к системе (Functional Specification — FS) (табл. 3). Так, если URS ставил задачи, то в FS должны быть прописаны пути их решения. При этом каждому пункту в URS должен отвечать пункт в FS. В случае если IТ-специалисты не могут обеспечить выполнения какого-либо пункта из URS, этот документ пересматривается либо принимается решение обратиться к другому поставщику. Если в рамках выбранного продукта нет возможности удовлетворить какие-либо требования, IТ-специалисты могут предложить дополнительное программное обеспечение, которое обеспечит выполнение остальных требований URS. В этом случае валидировать систему необходимо включительно с дополнительным программным обеспечением.

Таблица 3 Пример составления FS согласно URS из табл. 1

FS №

Описание функции

URS №

Вводимые данные

Результат

Ф001 Для входа в систему пользователь должен ввести:

— идентификатор;

— пароль

Т001 Идентификатор

Пароль

Доступ к системе
Ф002 После первого входа в систему необходимо изменить пароль (требования GMP (методология GАMP) Т001
Ф003 Изменение пароля ежемесячно (требования GMP (методология GАMP) Т001
Ф004 Запрещено удалять идентификатор Т001
Ф005 Каждый вход в систему и изменение пароля фиксируются в контрольном журнале (audit-trail) Т001 Доступ Данные в контрольном журнале

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

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

Готовые FS проверяет отдел контроля качества, после согласования с которым в случае, если создание системы было передано на аутсорсинг, FS направляется к поставщику, а если нет — то в IS-отдел (или IТ-отдел).

За формирование URS ответственность несет пользователь. Следует отметить, что если при приобретении системы и ее запуске не проводилось составления URS, то в дальнейшем для совершения валидации компьютеризированных систем необходимо прописать URS и/или FS, опираясь на функции, выполняемые системой, которую использует компания.

Создание URS и FS — составляющие первого этапа валидации — квалификации проектной документации (DQ), которая является формальным обзором дизайна системы, ее технической документации и качества. Цель проведения DQ — подтвердить, что жизненный цикл на этапе разработки системы пройден правильно. Это позволяет гарантировать, что пользователь и поставщик системы согласовали URS, FS, спецификации дизайна и план качества.

В рамках DQ также осуществляется оценка рисков для каждой функции в FS (табл. 4).

Таблица 4 Возможные риски на примере FS из табл. 2

FS №

Описание функции

Описание риска

Уровень риска

Вид тестирования на этапе OQ

Ф001 Для входа в систему пользователь должен ввести:

— идентификатор;

— пароль

Неизвестный пользователь может войти в систему Высокий Позитивное и негативное тестирование
Ф002 После первого входа в систему необходимо изменить пароль (требования GMP (методология GАMP)
Ф003 Изменение пароля ежемесячно (требования GMP (методология GАMP)
Ф004 Запрещено удалять идентификатор Потеря данных в контрольном журнале Высокий Позитивное и негативное тестирование
Ф005 Каждый вход в систему и изменение пароля фиксируются в контрольном журнале (audit-trail) Изменение или удаление контрольного журнала Высокий Позитивное и негативное тестирование

В ходе анализа рисков необходимо совершить такие действия:

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

При анализе рисков каждой функции присваивается та или иная степень риска, который несет ее некорректное выполнение. Так, например, функции с высоким уровнем риска можно отнести к 1-й категории, со средним — ко 2-й, с низким — к 3-й. На основе того, к какой категории принадлежит функция, составляется соответствующий набор тестов для проверки корректности ее функционирования. Для функций с высоким уровнем риска — категория 1 — необходимо проводить позитивные и негативные тесты. Под позитивными тестами подразумевается проверка корректного функционирования системы, в том случае, если пользователь следует инструкции по ее использованию. Например, для того чтобы внести правки в определенный документ, ваш персональный профиль должен иметь пометку «Создатель», тогда, если у вас есть такая пометка в профиле, должны внестись все правки. Негативное тестирование осуществляется путем нарушения инструкции. Например, в вашем профиле вместо пометки «Создатель» значится «Администратор», в этом случае при правильной работе системы ваша попытка внести правки в документ должна увенчаться неудачей.

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

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

На основе FS IТ-отдел составляет технические требования (Technical Specifications — TS), описывающие материальную и программную базу, на которой будет работать система. Так, TS может содержать информацию про IТ-инфраструктуру (серверы, сети, компьютеры, наличие систем, обеспечивающих создание резервных копий данных), необходимые программы; взаимодействие с другими системами, другое оборудование и т.д. В случае, если в состав IТ-отдела входит менеджер по контролю качества, он и проверяет TS. В противном случае такую проверку может осуществлять отдел контроля качества. Без наличия TS невозможно перейти к следующему этапу валидации — IQ.

Валидация: на старт! внимание! марш!

IQ — стадия, на которой проверяется комплектность оборудования, правильность его установки, полнота и актуальность полученной документации, соответствие используемой материальной базы заявленной в TS, соответствие внешнего вида и правильность маркировки оборудования.

Цели проведения IQ — проверить:

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

Во время проведения IQ проверяются такие элементы, как материальная база (серверы, принтеры и т.д.), компьютерные системы (Unix, Windows, DOS, система управления компьютерами), а также их настройки, компьютерное окружение (сеть, дата-центр, SAN, DRP).

В ходе валидации новой системы IQ проводится дважды — в квалификационной и производственной среде.

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

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

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

При проведении ОQ обязательно возникают сбои — система не может работать идеально. Отчеты об ошибках документируются, затем на основе критериев приемки принимается решение об их исправлении (или неисправлении). Если ошибка не критична для корректности работы системы, то ее не исправляют. Этот факт документируется, и дополнительно в обязательном порядке предоставляется объяснение причины принятия такого решения.

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

РQ — документальное подтверждение того, что система работает в соответствии с установленными требованиями. РQ состоит из 2 этапов — РQ1 (разрешение запуска системы) и РQ2 (наблюдение за процессом эксплуатации системы).

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

РQ2 проводится с использованием KPI, при этом анализируется эффективность работы системы, частота сбоев, вносимые изменения и т.д. Регуляторный орган США рекомендует проводить РQ2 1 раз в месяц в течение 3 мес.

Тестирование осуществляется только при наличии утвержденных документов, регулирующих его проведение (протоколы, тесты). Затем полученные результаты сверяются с ожидаемыми (согласно спецификациям). Результаты каждого теста необходимо сохранять, поскольку они являются доказательствами того, что валидация системы была проведена, а также потому, что в ходе проверки их может затребовать аудитор. Существуют специальные программы, которые позволяют работать с тестами и их результатами, однако перед использованием таковых их также следует валидировать, поскольку в дальнейшем они будут работать с информацией, влияющей на соответствие требованиям GхP.

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

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

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

Существует также понятие ретроспективной валидации. Ее проведение прописано в PIC/S. Ее осуществляют в случае, если системы уже работают и не валидированы. Для этого необходимо написать спецификации URS и/или FS, TS, проверить систему на соответствие требованиям GхP (для этого проводится IQ, ОQ, РQ).

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

Евгения Лукьянчук

Комментарии

Нет комментариев к этому материалу. Прокомментируйте первым

Добавить свой

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Другие статьи раздела


Последние новости и статьи