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

Стоит задача организовать валидацию компьютеризированных систем с нуля. Однако, при организованных процессах квалификации и валидации, это вовсе не означает, что в этом направлении нулевые наработки. Например, если имеем “свечной заводик”, где есть несколько участков/подразделений/цехов, каждая субъединица имеет свой набор оборудования и систем и, соответственно, компьютеризированных систем, которые управляют ими (разной категоризации согласно GAMP 5), то это означает, что “по касательной” компьютеризированные системы были затронуты в ходе первичных квалификаций оборудования и систем. Например, система приготовления растворов конструктивно имеет контроллер (PLC) c прошитой конкретной программой и панель управления / управляющий компьютер (HMI), опять же с конкретной прошитой программой (исполняемым файлом). При квалификации подобной системы мы неизбежно на этапе IQ должны коснуться её Hardware, на этапе OQ проверить правильность функционирования органов управления, реакцию системы на аварийные ситуации, доступ по паролям, создание рецептур, сохранение и распечатку параметров процесса и т.п. Т.е. собственно вопрос квалификации ПО в значительной степени выполнен – далее все управляется контролем изменений и отклонений в валидированной системе. Верификация программного кода во многом ответственность поставщика системы. Например, достаточно от него получить письменное подтверждение, что ПО протестировано в соответствии с требованиями GAMP 5 и тем самым исчерпать вопрос. Самостоятельно ведь мало кто сможет ковырять Step7/WinCC (в случае платформы Сименс), да и поставщики обычно не оставляют такой возможности конечному пользователю. Максимум что могло быть сделано, это совместная верификация на этапе приемки таковых систем. Это случай уже работающего оборудования и пример, когда компьютеризированная система является частью automated manufacturing equipment, как буквально указано в Приложении М1 GAMP 5 Validation Planning (пункт 2 Scope). Там же значится для такого случая, что separate computer system validation should be avoided, т.е. отдельная валидация комп. системы не требуется. Что буквально подтверждает мою интуитивную догадку выше для подобных случаев.

Второй момент, скажем, LIMS или система электронного документооборота, или система ERP (или вообще любая другая система, включая вновь проектируемую или непроквалифицированную до этого производственную систему / оборудование). Здесь никто и ничего не начинал. Это означает, что должны быть пройдены все “7 кругов ада”, т. е. мы должны:

1. Определить систему (URS, FS, TS – если этого нет / не сохранилось, то фактически воссоздать заново в достаточном для проведения валидации объеме).
2. Определить и спланировать стратегию валидации (Валидационный план, анализ рисков)
3. Подготовить шаги валидации (DQ, IQ, OQ, PQ) и т.п.

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

Предположим, что собственно квалификацию и валидацию уже охватывают разрабатываемые на периодической основе ВМП, распределенные по подразделениям. В фокусе квалификации – имеющиеся в соотв. подразделении оборудование и системы, в фокусе валидации – имеющаяся номенклатура препаратов. По ним описаны объемы квалификации / реквалификации / валидации, сроки, критерии приемлемости, процедура управления изменениями, распределены роли и ответственности и т.п. По компьютеризированным системам (далее – КС), как уже было показано выше, в 90 % случаев ПО отдельных единиц охвачено в рамках квалификации этих единиц. Из общего числа КС выделяются (в плане критичности) системы визуализации, скажем систем получения, хранения и распределения воды очищенной, системы управления и мониторинга систем кондиционирования воздуха для чистых помещений и т.п. Формально они также были рассмотрены в рамках квалификации, но их не мешало бы ещё раз прогнать последовательно по пунктам 4-17 Приложения 11 действующего Руководства по надлежащей производственной практике (GMP) – скажем, их квалификация была выполнена до 2011 года (когда вступило в силу указанное Приложение 11) – вполне вероятно что квалификация не затрагивала вопросы миграции данных или непрерывности бизнес-процесса. Для автомата групповой упаковки вроде бы как это не обязательно и можно элементарно “отбить” анализом рисков. От водоподготовки так уже не отмахнешься.

GAMP 5 нам предлагает создать ВМП, где далее, по необходимости на каждую из КС создать индивидуальный ВП. В таком случае это получается по 2-3 таких критичных КС на подразделение/участок. Допустимо ли при этом создать один общефирменный ВМП, который не будет иметь принадлежности к подразделениям, где будут перечисленные все КС, из них выделены критические (скажем, по категориям GAMP5), далее для наиболее критических КС создать отдельные ВП (допустимо согласно Приложения М1 иметь общие планы или планы-генерики для аналогичных систем), например, системы визуализации систем кондиционирования чистых помещений в целом аналогичны, не суть важно какие именно подразделения они представляют (классы чистоты или время деконтаминации, скажем, “интересны” при квалификации, при валидации таковой КС важна способность системы хранить данные, распечатывать тренды, реагировать на выход параметров за установленные пределы и т.п.).

В п. 5.3 Приложения М1 GAMP5 описано, что должен включать в себя валидационный план (во многом перепевка того, что в первом же ответе написал AntonM) – при необходимости могу привести этот перечень буквально.

Но начинать всё же стоит, на мой взгляд, с общего, а уже потом двигаться к частному. Чтобы валидация КС не растворилась в общей валидационной деятельности видится целесообразным регламентировать её отдельным ВМП, а в этом отдельном ВМП (при предложенной вариативности и гибкости “под конкретную ситуацию”) предлагается изложить буквально следующее (п. 4.1 Приложения М1 GAMP5):

– summary of facilities, systems, equipment, or process in scope;
– current status of these facilities, systems, equipment, or processes
– change control process to be followed
– planning and scheduling (incuding activities for new systems, activities driven by change, and periodic review)

что буквально означает:

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

Вроде как от этого можно оттолкнуться.

Начать я решил “в лоб” с того, что изложено в Приложении М1 GAMP 5, называется оно Validation Planning (как уже было указано). Помимо воды (Introduction & Scope) там есть ещё три пункта – Validation Policies, VMP и VP. Validation Policies – чистейшая формальность, подразумевающая собой некую “программу партии”, методику-заявление фирмы, мол, “мы сделаем это!” (с – к/ф День выборов). Я не придумал ничего лучше, чтобы взять уже существующие методики по фирме и воткнуть туда пару общих понятий с красивыми картинками, которые нам говорят, что у нас декларируется подход, основанный на анализе рисков, что у нас реализуется концепция жизненного цикла системы, что на всех этапах жизненного цикла системы у нас им “будет уделяться” адекватное внимание в зависимости от категоризации согласно GAMP 5. Далее подводим мысль под то, что иметь дело будем главным образом с 3-мя из 4-х возможных категорий с несплошной нумерацией от 1-й до 5-й. Тут, на мой взгляд, ISPE немного перемудрили – GAMP 5 отражает все этапы эволюции мышления своих создателей, но разобраться несложно. Первая категория – это т.н. инфраструктурное ПО, проще говоря ОС, MS Office в состоянии “as is” и системные утилиты и т.п. По идее сюда сильно лезть не стоит, хотя ISPE всё-таки предлагает и их не обходить вниманием. Второй категории уже просто нет – ранее это было т.н. firmware – поскольку сейчас оно стало настолько мудрённым, что может быть отнесено к любой категории, т.е. собственно категорию два упразднили цинично нарушив непрерывность нумерации. Третья категория – неконфигурируемое ПО. Говорится в Приложении М4 GAMP 5, что для такового ПО могут вводиться, скажем, некие параметры запуска, но оно не может быть сконфигурировано под бизнес-процесс – это простенькое firmware, ПО приборов, технологического оборудования, системы визуализации рабочих параметров и т.п. Четвёртая категория – ПО конфигурируемое, например, SCADA, ERP, LIMS. Исходный код при этом не затрагивается. Что же касается пятой категории, то здесь уже критерием выступает наличие специально написанного кода – я так понимаю, что если кого-то озадачили на С++ или С# (два на чём угодно, от QBasic до RAD XE3, включая VBA скрипты в MS Excel, например) что-то “сваять под ключ” – то это и будет пятая категория, хотя интуитивно понимаю, что возникает такая острая необходимость процентах в 10 случаев – остальные 90 % потребностей на рынке, как правило, присутствуют / удовлетворены – это общее правило для ПО, средняя температура по больнице т.с.

Сам GAMP 5 предлагает два типа подхода – общесистемный или покомпонентный. Т.е., в случае, скажем, ERP системы есть ряд компонентов (модулей) с default-настройками, ряд сконфигурированных компонентов и может быть часть специально прописанных. Если для каждого из таких компонентов применять индивидуализированный подход (что представляется вполне оправданно, ведь критичность и степень влияния на качество конечного продукта различное), то можно оправданно сфокусироваться на главном. Таким образом получится пестрая палитра с категориями 3, 4 и 5.

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

Стоит сказать, что GAMP5 ещё выделяет две категории “железа”, первая – общая, вторая – некое специально изготовленное “железо”. Тут мне пока трудно привести примеры из жизни (предвижу что 99% КС будет первой категории по “железу” – на радиорынке уже вроде редко кто комплектует системы). Разберусь детальнее в этом – отредактирую абзац.

Лично я решил начать с того, чтобы выписать перечень всех возможных КС в компании – прикинуть их сферу применения и категорию (софта) согласно GAMP5. Всё-таки Validation Policies, да и VMP с VP в какой-то мере – это просто обёртка / аранжировка, а меня интересует то, что станет сущностной основой всей деятельности по валидации КС. Далее, наверное, имеет смысл уже опираться на конкретный пример. Чтобы не пеленговать буквально свою контору :), попросту сделаю абстрактный перечень систем для абстрактного небольшого завода и с ним попробую поупражняться в расчёте на обратную связь. Все совпадения будут случайными, но фильм перечень будет основан на реальных событиях реально существующих системах. Продолжение следует…

Похожие записи:

Перечень компьютеризированных систем

Валидация компьютеризированных систем – кто о ней говорит в контексте «обычных» IQ, OQ, PQ?

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

Квалификация или валидация компьютеризированных COTS-систем лаборатории

Валидация системы температурного мониторинга при перевозке лекарственных средств в соответствии с требованиями GxP. Обеспечение целостности данных

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

Использование надстройки Inquire при валидации электронных таблиц MS Excel

Облачные решения