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

Стоит задача организовать валидацию компьютеризированных систем с нуля. Однако, при организованных процессах квалификации и валидации, это вовсе не означает, что в этом направлении нулевые наработки. Например, если имеем “свечной заводик”, где есть несколько участков/подразделений/цехов, каждая субъединица имеет свой набор оборудования и систем и, соответственно, компьютеризированных систем, которые управляют ими (разной категоризации согласно 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 в какой-то мере – это просто обёртка / аранжировка, а меня интересует то, что станет сущностной основой всей деятельности по валидации КС. Далее, наверное, имеет смысл уже опираться на конкретный пример. Чтобы не пеленговать буквально свою контору :), попросту сделаю абстрактный перечень систем для абстрактного небольшого завода и с ним попробую поупражняться в расчёте на обратную связь. Все совпадения будут случайными, но фильм перечень будет основан на реальных событиях реально существующих системах. Продолжение следует…

Подписывайтесь на каналы PHARM COMMUNITY:

   
Поделитесь с коллегами:

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

  1. Статья хорошая, только относящаяся к фарм. предприятиям, а как же на счёт дистрибьюторской деятельности.
    Как правильно организовать валидацию компьютеризированных систем GDP?

    • GDP никак не должно нас смущать? Тот же GAMP 5 намеренно адресован GxP + в самом GDP куда более “хилые требования к КС”. В частности открываете Решение № 80 (ЕЭК) и находите, что там только пару пунктов по касательной касается КС. Как я уже ранее говорил, наиболее исчерпывающим документом в GxP и, вместе с тем, наиболее лаконичным являются правила OECD GLP. Мы в своё время выполнили перевод этих правил на русский язык. Именно этим документом я рекомендую пользоваться на практике.

      Кроме того, вот скрин Решения № 80 (ЕЭК) в отношении КС:

      КС в GDP

      Что здесь может смущать? Тут ведь только общие фразы.

      Куда интереснее может быть прикладная статья, как охватить все бизнес-процессы предприятия, причем вот пример именно в части GDP.

      Буду вопросы – обращайтесь (либо тут, либо в указанных темах, либо непосредственно).

  2. Благодарить пока не за что, поскольку я только пытаюсь разобраться в вопросе, причём не с позиции IT-шника.

    По поводу аутсорсера – да, вполне мог так заявить, как Вы описываете. Практически взято все с таблицы GAMP Приложения М4, где в примерах для категории 4 указаны в частности HMI, SCADA.

    Более того, есть примеры, когда аналогичной системе присвоены категории 4 и 5.

    Я так понимаю, аргументация такова, что для контроллера используется своя, индивидуально написанная программа (но в таком случае практически для любой единицы оборудования используется свой индивидуальный программный код!).

    Вместе с тем Приложение D4 п. 3.2 Руководства GAMP 5 описывает необходимость пересмотра программного кода в ходе разработки самим разработчиком при участии минимум одного независимого эксперта – как предполагается пересматривать код конечному пользователю (он к тому же не всегда доступен) – вопрос. К тому же явного отношения к категории софта необходимость его пересмотра (Source Code Review) не имеет.

    Далее, на форуме CoP (Community of Practice – сообщество практики) ISPE GAMP вопрос по категориям ПО технологического оборудования также является дискуссионным, например, для тех же паровых стерилизаторов предлагается определяться в разрезе используемых рецептур (стандартные или произвольные последовательности фаз), фиксация данных на электронном или бумажном носителе, есть ли связь с системами высшего уровня с последующей обработкой данных и т.п. При этом предлагается выбор между 3-й и 4-й категориями. При том, что программа того же контроллера для каждого парового стерилизатора, например, на базе PLC Siemens, написанная на Step 7, тоже индивидуальна.

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

    Проблема руководства GAMP 5 в том, что она написано в части категоризации неконкретно (невзирая на обилие примеров с использованием аббревиатур HMI, SCADA, LIMS, CDS etc.) – с IT-специалистом предварительно я нашёл аргументы как в пользу того, чтобы категорию 3 сделать 5-й и наоборот 🙂 Отсюда наверное дискуссии по поводу и на “родном” форуме GAMP.

    А теперь необходимо подумать, чем мы рискуем, “ошибившись” категорией.

    Для 3-й категории нам необходима только URS – это вроде как не проблема, т.к. требования пользователя как минимум изложены в договорах на поставку оборудования. Это плюс.

    Для 4-й категории GAMP предлагает иметь функциональную и конфигурационную спецификации. Уважающий себя поставщик, например, для систем водоподготовки или систем приготовления просто обязан иметь на этапе разработки функциональную спецификацию (особенно, если ПО пишет третья сторона – такое часто практикуется), иначе он просто не напишет ПО (это может быть пофазовая матрица работы клапанов, например). Более того, даже для неконфигурируемого ПО эта спецификация необходима при создании ПО – тогда не вполне понятен выигрыш в разбиении на категории. Конфигурационная спецификация – в случае создании рецептур/фиксации параметров форматов просто нужно зафиксировать созданную конфигурацию – спецификация формально будет готова при запуске – её важно зафиксировать. ПО слетело, например – его залили по-новому и установили определённую конфигурацию ПИД-параметров работы циркуляционного насоса, например.

    Для 5-й категории конфигурационная спецификация заменяется на проектную/детальную спецификацию (Design Specification) и спецификацию модулей. Опять же, код на контроллер – таблетпрессов разных моделей индивидуален – в чём опять же конкретный сенс разбиения на категории?

    Я затрагивал ПО технологического оборудования, но его доля в фарм. секторе – 90 %. Остальные 10 % оставим разного рода ERP, LIMS, системам электронного документооборота – это решения штучные и, как правило, не с нуля создаваемые (конфигурируемые).

  3. Большая благодарность автору.

    И такой каверзный вопрос: есть водоподготовка, есть валидатор-аутсорсер.

    Аутсорсер в протоколе квалификации утверждает, что на водоподготовке компоненты 1 и 4 категорий по GAMP. И в приложении даются некие сертификаты от производителя ПО. И далее в протоколе пишется, что для 1 категории делаем в соответствии с рекомендациями ISPE один объем испытаний, а для 4 категории – другой (явно больший).

    И сам вопрос: можем ли мы проверить самостоятельно категорию? Где четкая градация между ними? Самая критичная (на мой неопытный взгляд) проходит между 4 и 5. Если Win8, то 4, а вот если какой язык (или еще что-то), то уже явно 5.

    Однако, из этой 5 категории можно вычленить еще элементы 3-й и 4-й, вроде как. И как это вычленение сделать (несмышленому в программировании)?

Залишити коментар