Практика и плоды внедрения GAMP

В связи с кризисом качественные импортные лекарственные препараты стали гораздо менее доступны для населения. Для исправления ситуации правительство активно поддерживает импортозамещающие проекты, в том числе в рамках программы «ФАРМА-2020». Зелёный свет дан, но теперь большинство отечественных фармпредприятий стоит перед серьёзной проблемой: их производство не соответствует международным критериям качества GAMP. А это, в свою очередь, отвращает от них зарубежных инвесторов и заказчиков. О положительном опыте автоматизации в соответствии с нормами GAMP 5 читайте в этой статье.

Широков Юрий

221
В ЗАКЛАДКИ

Проблемы качества в отечественной фарминдустрии  

Президент России В.В. Путин в своём указе от 7.05.2012 № 598 «О совершенствовании государственной политики в сфере здравоохранения» поставил задачу доведения объёма производства отечественных лекарственных средств по номенклатуре перечня стратегически зна­чимых лекарственных средств и перечня жизненно необходимых и важнейших лекарственных препаратов до 90 про­центов к 2018 году. С тех пор прошло уже 4 года, и назначенный срок не за горами. Что же реально делается для выполнения указа Президента РФ, и каковы шансы отечественных производителей составить достойную конкуренцию грандам мировой фармацевтики? Собственные разработки требуют колоссальных интеллектуальных и финансовых вложений, а также больших затрат времени на клинические и лабораторные исследования, поэтому пока практически весь данный прирост обеспечен за счёт выпуска так называемых дженериков – аналогов импортных препаратов. Тем не менее, надо отметить, что за прошедшее время по официальной статистике объём выпуска отечественных препаратов увеличился вдвое. Основная активность в данном направлении в России проявляется в формирующихся фармкластерах, объединяющих множество предприятий и предоставляющих им преференции в работе. Среди лидеров в фармацевтической промышленности можно назвать Подмосковье, Ярославскую и Калуж-скую области, Санкт-Петербург, Екатеринбург, ну и, может, ещё некоторые другие регионы. В развитие фармкластеров в России активно инвестируют и западные компании с мировыми именами, такие как «Байер», «Новартис», «Берлин-Хеми», «Никомед», «Сервье».

По утверждению генерального директора Ассоциации российских фармацевтических производителей Виктора Дмит­риева, Российский фармрынок сейчас входит в первую десятку стран по объёмам потребления. Будучи далеко не освоенным, он представляет несомненный интерес для инвесторов в фармтехнологии. Но построить производственную линию – это ещё не все. Лекарства должны быть не просто качественными и современными – они должны быть гарантированно качественными. А в настоящее время статистика неутешительна: по данным Роспотребнадзора, доля производственного брака в продукции отечественных фармпроизводителей достигает 10%, что совершенно неприемлемо. Данная ситуация во многом является следствием слабости и бессистемности подхода к управлению и контролю качества на производствах. Да и возможна ли вообще методология, соблюдение которой гарантирует успех масштабных проектов? Оказывается, да. Она существует и успешно применяется. Постоянно совершенствующийся свод рекомендаций, де-факто являющихся международным стандартом, носит общее название GxP – “Good x Practice”. В глазах мирового сообщества именно подтверждённое соответствие критериям GxP является гарантией качества фармацевтического производства, открывающей ему путь на международный фармрынок. Формально в России уже давно существует соответствующий ГОСТ, являющийся фактически переводом документа GMP Европейского Союза ”Good Manufacturing Practice for Medicinal Products for Human and Veterinary Use”. Он называется ГОСТ Р 52249-2009 «Правила производства и контроля качества лекарственных средств»» (а до него действовал аналогичный ГОСТ 2004 года). В силу ряда причин требования данного стандарта отечественными предприятиями фактически игнорировались, но в настоящее время в России действуют правила надлежащей производственной практики (GMP), утверждённые приказом Минпромторга России от 14.06.2013 № 916. Согласно документу, соответствие GMP является обязательным требованием для занимающихся производством и реализацией лекарственных препаратов предприятий. Таким образом, теперь отечественные производители мотивированы в наведении порядка на своих производствах не только ответственностью за недоброкачественную продукцию, но и угрозой лишения лицензии. Министерство промышленности и торговли Российской Федерации в 2009 году опубликовало оптимистичный документ, носящий название «Стратегия развития фармацевтической промышленности Российской Федерации на период до 2020 года». Согласно приведённым в нём планам, к указанному сроку доля рынка отечественных производителей должна быть доведена до 50%, при этом планируется существенно изменить пропорции, сместив центр тяжести с дженериков в сторону оригинальных препаратов отечественной разработки. Однако в настоящее время отечественная фармацевтическая промышленность, представленная более чем 600 предприятиями, не может похвастаться полным соответствием нормам GMP, без которого осуществление этих планов, равно как и указов Президента, невозможно.

Немного подробнее о GAMP  

В русскоязычной литературе GAMP (Good Automated Manufacturing Practice) принято расшифровывать как надлежащая практика автоматизированного производства. GAMP относят к обширному классу GxP-документов, охватывающему целую группу с общей тематикой “Good x Practice”, всесторонне регламентирующих деятельность в области фармацевтики. Проект создания методики GAMP был фактически запущен в 1991 году, хотя тогда ещё и не носил такого названия. Идея популяризации GAMP принадлежит техническому подкомитету международного общества фармацевтической инженерии – International Society for Pharmaceutical Engineering (ISPE). Первая официальная редакция GAMP была датирована 1994 годом. В 1996 году выпущена редакция GAMP 2, а в 1998 году – GAMP 3. Редакция GAMP 4, появившаяся в 2001 году, уже содержит много деталей, с точки зрения организации контрольных списков, шаблонов, в нём предложена знаменитая V-модель и т.д. Благодаря почти четырём годам ревизионной работы с версией GAMP 4 в феврале 2008 года появилась на свет текущая, пятая версия GAMP. Документ GAMP 5 является наиболее актуальной редакцией на сегодняшний день. В нём уделяется большое внимание вопросу управления рисками и менеджменту качества, а также популяризируется полезная практика создания и валидации IT-сервисов. Таким образом, унаследовав от GAMP 4 управление рисками, GAMP 5 охватывает весь жизненный цикл автоматизированных систем. GAMP 5 применим к широкому спектру информационных систем, лабораторного оборудования, интегрированных производственных систем и ИТ-инфраструктуры. В GAMP 5 также проведена определённая работа по снижению затратности внедрения рекомендаций в реальную жизнь за счёт упрощения и оптимизации рекомендуемых методик. Документ представляет собой свод методических указаний, призванных стандартизировать и облегчить разработку гарантированно качественных систем автоматизации. Являясь, по сути, международными нормами, GAMP выполняет важнейшую функцию глобальной стандартизации методики распределения ролей и обязанностей, а также подходов к сопровождению систем на протяжении всего их жизненного цикла.
Структура документа включает следующие основные разделы:
  • Ключевые принципы;
  • Концепция жизненного цикла системы;
  • Фазы жизненного цикла системы;
  • Управление рисками;
  • Регулирование деятельности компании;
  • Регулирование деятельности поставщика.
Базовый принцип GAMP – качество со старта разработки – говорит о том, что система гарантии качества должна быть буквально встроена в каждый технологический узел и в каждый процесс ещё на этапе проектирования и сопровождать конечный продукт на протяжении всего его жизненного цикла. Именно поэтому GAMP старается регламентировать комплексный подход, затрагивающий все аспекты, вплоть до работы с поставщиками исходного сырья, правил поведения персонала, хранения и распределе­ния готовой продукции. В его основе лежит тестирование, документирование и методическая поддержка всех стадий производства. По сути, GAMP является формализованной в виде свода рекомендаций квинтэссенцией практического опыта и здравого смысла. В общих чертах он предлагает следующий сценарий реализации проекта: всё начинается с фиксации общих требований пользователя, из которых создаются более формальные функциональные требования и спецификации проекта, которые, в свою очередь, являются основой для матрицы прослеживаемости изменений и для формальных испытаний системы. Таким образом, GAMP описывает и основные принципы тестирования (валидации) автоматизированных систем в фармпроизводстве, методически помогая обеспечению надлежащего качества фармацевтических продуктов. GAMP 5 является квинтэссенцией и наследником множества инициатив и огромного практического опыта (рис. 1).

Любой производитель лекарственных средств несёт суровую ответственность за соответствие продукта требованиям протокола клинического исследования и установленным требованиям безопасности применения. Иными словами, он обязан (и, строго говоря, должен быть заинтересован) сводить к минимуму рис­ки применения лекарственных средств, связанные с их качеством. Данная ответственность, естественно, предполагает наличие системы контроля над производственным процессом и персоналом на всех уровнях. Такую систему качества логичнее и проще всего основывать на накопленном международном опыте надлежащей производственной практики и управления рисками, коим GAMP и является. Осмысленное следование GAMP-подходу к автоматизации даёт производителю в итоге уверенность в применяемом технологическом процессе, системе менеджмента качества.

О валидации  

В этой статье мы коснёмся вопроса валидации компьютеризированных систем автоматизации производства. Согласно стандарту ГОСТ Р ИСО 9000-2008 «Системы менеджмента качества», заграничное слово «валидация» означает «подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены». Современное фармацевтическое производство использует весьма сложные технологии. Разумеется, чем сложнее технологический процесс и чем строже требования к его соблюдению, тем больше в нём оказывается потенциально опасных моментов. В связи с этим для производств, относящихся к категории регулируемых, валидация является обязательным требованием, продиктованным нормами закона. Внедряемые на них системы автоматизации должны подвергаться испытаниям и соответствовать требованиям GMP/GAMP 5, а процесс их разработки и внедрения должен проходить в соответствии с V-моделью, которой мы коснёмся позже. Результаты валидации должны быть правильно и полностью документально оформлены. Поскольку нулевой уровень риска практически недостижим, имеет смысл говорить о его приемлемом уровне. Задачей валидации и является обеспечение гарантии того, что производственный процесс отвечает названному требованию.
В пользу валидации существует по крайней мере два серьёзных аргумента:
  • валидация помогает максимально исключить вероятность ошибки там, где она может обернуться ущербом для здоровья или даже угрозой жизни людей;
  • компания с неваладированными процессами неизбежно проигрывает в рыночной борьбе своим конкурентам, поскольку валидированное производство – это ещё и прозрачность, и, как следствие, наименее затратная адаптируемость процессов к изменяющимся требованиям заказчиков. 
Процессом валидации должен руководить валидационный план – документ, описывающий методологию и планы предприятия по проведению валидации.
В результате проведения валидации рождается другой документ – протокол валидации. В нём отражаются резуль-таты валидации процессов (PV) и квалификации: проектной документации (DQ), монтажа (IQ), функционирования (OQ) и эксплуатации (PQ) оборудования, инженерных систем, «чистых» помещений, и прочее. В соответствии с «Методическими указаниями. МУ 64-04-001-2002» процесс валидации можно схематически представить на рис. 2.

Валидация компьютерных систем может проводиться на разных этапах общей валидации производственных процессов в логической связи с валидацией автоматизируемого процесса. Планируя работу по валидации и верификации, стоит придерживаться следующих общих принципов.
  • Сосредоточиться на том, что действительно влияет на качество.
  • Выделять ключевые требования к продукту в плане оценки его качества.
  • Уделять внимание риск-менеджменту, выявляющему критические моменты.
  • Для разработки формальных мероприятий по контролю качества фокусироваться на важнейших функциях, не забывая, что в общее качество должны вносить вклад все уровни процесса.
  • Помнить: различные системы и оборудование требуют разной степени внимания к себе.
  • Порождать прозрачную и легко применимую документацию.

V-модель  

Осознать необходимость системного подхода к разработке проекта – уже большое дело. Но это ещё далеко не всё: надо понять, как обеспечить эту системность. Подходящим инструментом и является V-модель (рис. 3) – основополагающий методический принцип GAMP.

Своё говорящее название она получила в соответствии с внешним видом диаграммы процесса разработки и внедрения, часто изображаемой в виде латинской буквы V. 
Концепция V-модели первоначально не имела никакого отношения к фармпроизводствам и была разработана как общий принцип управления особо критичными проектами. Вероятнее всего, истоки V-модели находятся где-то в восьмидесятых–девяностых годах прошлого века в среде военных и аэрокосмических разработок. По сути, она является усовершенствованием модели “waterfall” («водопад») – одной из старейших последовательных моделей, принятых в SDLC (Software Development Life Cycle – жизненный цикл разработки ПО). 
Несмотря на то что сама по себе идея не уникальна (существуют и другие методики схожей направленности, например, P2M, или метод PRojects IN Controlled Environments 2 – PRINCE2), эта реализация выглядит настолько понятной и эффективной, что была взята на вооружение многими разработчиками и сегодня является государственным стандартом разработки программного обеспечения и автоматизированных систем во многих странах.
Модель наглядно описывает процессы разработки и тестирования, происхо­дя­щие параллельно (левая ветвь V – это разработка, а правая – тестирование и ввод в эксплуатацию), а также горизонтальные итеративные связи, иллюстрирующие фазы верификации и валидации. Эти фазы являются связующими V-ветвей модели и обеспечивают большую, чем у модели “waterfall”, эффективность проекта.
Фаза верификации включает (по нис­ходящей) анализ требований, проектирование спецификации системы, проектирование архитектуры системы, детальную разработку её отдельных модулей.
Фаза валидации включает (по восходящей) тестирование как отдельных модулей системы, так и её связности, а также проверку на соответствие требованиям пользователя.
Поскольку V-модель хорошо ложится именно на процессы создания программного обеспечения и систем автоматизации, она и рекомендуется GAMP как шаблонная методика для подобных проектов.
С какими же типами ПО приходится иметь дело V-модели? Их условно делят на следующие категории:
  • Категория 1 – инфраструктурное ПО, используемое для управления компьютерами, коммуникациями, хранением данных, и т.п. Типичные примеры – операционные системы, СУБД, офисные пакеты. Разработка и сопровождение этих продуктов находится за рамками действия GMP, тем не менее, их надёжность также следует принимать во внимание. В общем случае требуется контроль актуальности версий ПО, контроль лицензий и корректности установки.
  • Категория 2 – микропрограммы, встроенные в устройства (ПО в аппаратных устройствах). Поставляются как есть и являются неотъемлемой частью аппаратного устройства. При наличии возможности обновления данного ПО требуется контроль актуальности версий, корректности установки. Разработка и сопровождение этих продуктов находится за рамками действия GMP.
  • Категория 3 – неконфигурируемые программные продукты из коробки. Это стандартные программные средства, продаваемые как есть, без возможности серьёзной адаптации. В общем случае требуется то же, что для категории 1, плюс тестирование на предмет соответствия требованиям процессов.
  • Категория 4 – конфигурируемые программные продукты из коробки, предоставляющие возможность настройки в соответствии с требованиями процессов пользователя. Типичные представители – SCADA, ERP, MES, CRM и другие комплексные системы. Для них требуется сопровождение в течение всего жизненного цикла. Необходимо обучение персонала работе с системой, требуется всестороннее риск-тестирование.
  • Категория 5 – ПО и системы, разрабатываемые по спецификациям пользователя. Это самая проблемная категория. Требования к ним аналогичны категории 4, плюс строгая документированность, контроль и аудит исполнителя (разработчика системы), доступ заказчика к исходным кодам и возможность их модификации на протяжении всего жизненного цикла.

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

Как уже было сказано, существуют и отечественные требования, аналогичные требованиям GxP. Они закреплены в соответствующих ГОСТах.
В частности, производство лекарственных препаратов регламентируется следующими стандартами:
  • ГОСТ Р 52249­2009 «Правила производства и контроля качества лекарственных средств». Настоящий стандарт является аутентичным переводом правил GMP Европейского Союза (GMP EU) “Good Manufacturing Practice for Medicinal Products for Human and Veterinary Use” по состоянию на 31.01.2009;
  • ГОСТ Р 52537­2006 «Производство лекарственных средств. Система обеспечения качества. Общие требования»;
  • ГОСТ Р 52550­2006 «Производство лекарственных средств. Организационно-технологическая документация»;
  • ГОСТ Р 52896­2007 «Производство лекарственных средств. Технологическое оборудование для производства твёрдых лекарственных форм. Общие требования»;
  • ГОСТ Р ИСО 15378­2009 «Производство лекарственных средств. Частные требования по применению ИСО 9000­2000 с учётом правил GMP»;
  • ГОСТ Р ЕН 12296­2009 «Биотехнология. Оборудование. Методы контроля эффективности очистки».
При разработке проектной документации на АСУ ТП применяются стандарты серии ГОСТ 34.хх.
Для удобства основные регламентирующие разработку и валидацию документы сведены в таблицу 1.

Практический опыт модернизации производства  

В этой части обзора расскажем об опыте реального внедрения системы АСУ на одном из фармпредприятий – заводе готовых лекарственных форм (рис. 4).

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

Планирование является важнейшей частью реализации этого проекта и охватывает все аспекты, включая необходимые мероприятия, обязанности и временные рамки. Работы и риск-менеджмент должны быть выполнены с учётом следующих факторов:
  • влияния проектируемой системы на качество продукции;
  • сложности системы и её новизны (архитектура и категоризация системных компонентов);
  • оценки поставщика решения (валидация поставщика).
Последующее тестирование компьютерной системы – это целый комплекс мер, состоящий из тестов в процессе разработки/внедрения, а также контроля на протяжении всего жизненного цикла. В частности, GAMP рекомендует тестирование:
  • работы пользовательского интерфейса;
  • поведения системы при сбое питания;
  • на предмет потери критически важных данных или управляющего воздействия;
  • доступа к системе и обеспечения безопасности;
  • аудита и протоколирования критических действий;
  • аварийных сигналов и сообщений об ошибках;
  • обработки и передачи критически важных данных в другие подсистемы;
  • резервного копирования и восстановления;
  • архивирования и извлечения данных;
  • способности системы справляться с высокими нагрузками.
Приведём краткую выдержку из ТЗ заказчика на проектирование системы: «Система должна обеспечить постоянный и непрерывный контроль, архивирование данных, предупреждение нештатных ситуаций и как следствие, минимизацию простоя систем и комплексов систем обеспечения производства в результате аварий, износа, технического и регламентного обслуживания. Разработка диспетчерских автоматизированных рабочих мест должна производиться с учётом необходимости реализации эргономических составляющих, максимизации информативности и обеспечения своевременной реакции диспетчерской службы на любые изменения состояния систем вентиляции и кондиционирования, а также инженерного оборудования. Необходимо предусмотреть возможность аудита накопленных данных смежными подразделениями предприятия (отделами эксплуатации, технологического контроля, контроля качества)».
Отсюда видно, что уже на абстрактном уровне была заложена необходимость следования принципам GMP в части прозрачности, документируемости и валидируемости решений.
В качестве исполнителя работ была выбрана компания «НОРВИКС-ТЕХНОЛОДЖИ», специализирующаяся на комплексных АСУ ТП в промышленности, информационно-измерительных системах технического учёта, АСУЗ (автоматизированных системах управления зданиями), а также системах диспетчеризации. Поскольку проектируемая программная система должна базироваться на конфигурируемом ПО (SCADA-пакет), она относится к категории 4 (описана ранее в статье). В соответствии с принципами GAMP поставщик такого решения должен также подвергнуться процедуре валидации. Невзирая на более чем десятилетний опыт успешной работы поставщика, его соответствие оценивали по специально разработанной формальной методике. Анализ проводился специалистами заказчика с позиций минимизации комплекса рисков, связанных с разработкой и последующей эксплуатацией программного продукта. Далее приводится упрощённый план  валидации поставщика решения.
  • Оценка риска прекращения существования поставщика до выполнения своих обязательств – финансовая состоятельность, взаимоотношения с государственными разрешительными службами, СРО и т.д.
  • Оценка риска исполнения работ с ненадлежащим качеством:
    • гарантирует ли существующая на предприятии система качества успешное выполнение проекта.
  • Наличие у поставщика сертификатов СМК 9001:
    • наличие внедрённых процедур в области специализированных методологий управления качеством для данного рода деятельности (методологии управления проектами, контроль требований к информационному обеспечению разработок и т.д.);
    • наличие системы управления компетенцией персонала (контроль знаний, формализованные процедуры обучения и пр.).
  • Обладает ли компания-поставщик достаточными ресурсами для исполнения своих обязательств:
    • достаточное количество персонала соответствующей компетенции; 
    • наличие задокументированных про­цедур и методологий;
    • наличие необходимых лицензий и разрешений для ведения работ;
    • достаточность материальных ре-сурсов;
    • имеет ли компания опыт сервис­ного обслуживания:
      • способна ли компания-поставщик обеспечить сопровождение результатов своих работ на протяжении всего жизненного цикла.
  • Имеются ли утверждённые процедуры поддержки программных продуктов и аппаратных комплексов.
Валидация проводилась в два этапа, первый из которых – контроль по подтверждающим документам, а второй – аудит по месту расположения поставщика. После успешного завершения этапа валидации компания «НОРВИКС-ТЕХНОЛОДЖИ» совместно со специалистами фармпредприятия приступила к составлению функциональной спецификации системы – документа, детально описывающего термины, определения, ключевые параметры системы, цели, задачи, средства и методы их реализации, обязательность соответствия нормативным документам и т.д. Среди множества описанных в функциональной спецификации требований присутствуют и требования к надёжности и диагностированию системы – основа для будущего плана её валидации. Приведём в сокращённой форме соответствующие разделы данного документа.

Требования надёжности системы  

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

Общее описание системы  

В качестве базовой SCADA была выбрана система GENESIS64 компании ICONICS как наиболее полно соответствующая требованиям проекта. Очевидно, что система, имея общий пул данных, должна совершенно по-разному предоставлять их различным типам пользователей, поэтому она условно разделена на две подсистемы с разными интерфейсами и функциями: служба эксплуатации/автоматизации и служба менеджмента качества.
Фактически для службы эксплуатации/автоматизации – это SCADA-система в современном понимании слова с интерактивными трёхмерными интерфейсами с экспликациями зданий и технологических установок, позволяющими получить максимально детализированное представление о контролируемой системе вплоть до разреза единиц оборудования.
Службе качества, напротив, требуется скорее не SCADA, а MES-система, позволяющая производить глубокий анализ причин и следствий отклонений и нештатных ситуаций, поэтому для них информация из SCADA предоставляется в виде событий, отчётов и отклонений. Для предоставления информации была выбрана концепция dashboard-портала. Dashboard дословно переводится как панель управления, и принцип подобного интерфейса состоит в том, что пользователь сам может скомпоновать его из многочисленных доступных окон-виджетов в соответствии с текущими задачами.
На рис. 6 показан набор экранных форм, составляющих интерфейс оператора портала.

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

Тестирование системы  

В соответствии с V-моделью разработки готовая система должна быть всесторонне протестирована. Приведём выдержки из документа «Методика тестирования», описывающие регламент тестирования лишь для одного тестового «чистого» помещения (чтобы не вдаваться в подробности архитектуры участков завода).
Проверка функционирования системы при обработке потока тестовых данных помещения  
В соответствии с принципами, изложенными в документе “MHRA GMP Data Integrity Definitions and Guidance for Industry March 2015”, критические данные в валидируемых системах должны быть:
  • однозначно идентифицируемыми,
  • разборчивыми и постоянными,
  • актуальными,
  • верифицируемыми и документируемыми,
  • точными.
Данные принципы должны соблюдаться на протяжении всего процесса, начиная от «сырых» данных, и заканчивая их интерпретациями. Если автоматизированные системы используются для сбора, обработки, создания отчётов или хранения необработанных данных в электронном виде, система всегда должна предусматривать сохранение полного аудита истории с документированием изменений и предыдущего состояния данных. Должна также быть обеспечена ассоциация всех изменений данных с лицами, инициировавшими эти изменения, а сами изменения должны иметь временные метки. Кроме того, пользователи системы не должны иметь возможности изменять или отключать контрольный журнал.
Для обеспечения проверки функционирования системы на отказоустойчивой серверной паре был реализован симулятор параметров, обеспечивающий генерацию потока тестовых данных помещения. Данное решение позволяет производить проверку системы при отсутствии данных от её среднего уровня. Проверка системы осуществляется путём определения достоверности данных, выводимых на портале при помощи инструментов «Аварии» и «Тренды» по заранее известным критериям, и определения детерминированности тестовых аварий и событий.
Результат данной проверки заносится в документ «Протокол выполнения проверки функционирования системы при обработке потока тестовых данных помещения». 
Характеристики симуляции параметров в помещении  
Тестовое помещение содержит параметры, значения которых формируются синусоидальным симулятором (рис. 7).

Формируемые значения носят периодический характер и позволяют точно определить время возникновения тех или иных аварийных событий, связанных с помещением, что позволяет оценить работоспособность системы и её компонентов.
Проверка функционирования системы при обработке потока реальных данных, получаемых от среднего уровня  
Основная цель проверки системы при обработке потока реальных данных заключается в определении соответствия системы следующим правилам:
  • данные, получаемые от среднего уровня системы, должны проходить верный путь обработки;
  • процесс обработки данных не должен вносить искажений в информационный поток;
  • получаемые системой данные должны быть доступны, в зависимости от их типа, в формах просмотра трендов, формах аварий, а также в отчётах.
Все сигналы, принимаемые и обрабатываемые системой, были внесены в специально разработанный сквозной классификатор (базу данных) имён сигналов. Для этого все они были приведены к единому виду, где в имени сигнала закодирована информация:
  • о физической величине,
  • о форме представления данных,
  • о месте/принадлежности к системе,
  • о топологическом размещении,
  • о месте фиксации/модуле обработки.

Ещё раз о необходимости GAMP-подхода  

Мы привели здесь лишь выдержки из многочисленных документов, иллюстрирующие GAMP-подход в конкретном проекте. Реализованная по данным принципам система имеет в основе тщательно подготовленную методическую и документальную базу. Полученное в результате решение является предсказуемым, воспроизводимым, сопровождаемым и валидируемым. Это позволяет с гарантированным качеством распространять его на другие производственные предприятия компании, а также (при необходимости) модифицировать для достижения соответствия изменяющимся требованиям. GAMP давно стал стандартом де-факто в мире. Активно внедряется он и в России, и не за горами время, когда фармпроизводства, не соответствующие GAMP, окажутся вне правового поля.

Итоги проекта 

На момент написания этой статьи создание аппаратной платформы уже завершено, выполнены настройки и конфигурирование ПО, обеспечиваются функции непрерывного контроля архивирования данных прогнозирования и предупреждения нештатных ситуаций. Разработаны и реализованы механизмы, позволяющие однозначно подтверждать соблюдение режимов работы инженерного оборудования в соответствии с требованиями технологических процессов. 
Часто при создании информационных систем для регулируемых производств команде внедрения трудно противостоять искушению создать собственную уникальную программную систему вместо использования возможностей и функций, заложенных в конфигурируемое ПО. В данном случае знание сотрудниками «НОРВИКС-ТЕХНОЛОДЖИ» применённого инструментария позволило удержать проект в рамках 4-й категории по классификации GAMP, реализовав всю функциональность системы только настройкой и конфигурированием. Опыт и знания специалистов «НОРВИКС-ТЕХНОЛОДЖИ» в области требований к квалификации и валидации компьютеризированных систем позволили разработать архитектуру проекта легко валидируемой – прозрачной. За время реализации данного проекта специалистами компании развита компетенция в области инструментов, добавляющих традиционным системам диспетчеризации функции предиктивного анализа собираемых данных. 
Благодаря этому появилась возможность предлагать решения ряда сложных задач: 
  • поиск причин возникновения аварийных ситуаций;
  • предупреждение развития аварийных ситуаций за счёт поиска признаков режимов, идентичных ранее возникающим при развитии аварий; 
  • организация планово-предупредительных ремонтов на основе анализа фактической наработки и диагностических показателей оборудования. 
Теперь специалисты «НОРВИКС-ТЕХНОЛОДЖИ» с полной уверенностью могут утверждать: они готовы подключиться к работе над подобными проектами на любом этапе, от анализа рисков и разработки формальных требований пользователя до помощи заказчику в работе с валидирующими организациями. ● 

E-mail: iqrater@gmail.com



ПОДПИСАТЬСЯ НА НОВОСТИ

Будьте всегда в курсе самых свежих новостей
и узнавайте первыми о содержании нового номера

Подписка на новости