WikiDer > Валидация (производство лекарств)

Validation (drug manufacture)

Проверка представляет собой процесс создания документальных свидетельств, демонстрирующих, что процедура, процесс или действие, выполняемые в процессе тестирования, а затем производства, поддерживают желаемый уровень соответствия на всех этапах. В фармацевтической промышленности очень важно, чтобы в дополнение к окончательному тестированию и соответствию продуктов была обеспечена уверенность в том, что процесс будет постоянно давать ожидаемые результаты.^[1] Желаемые результаты устанавливаются в виде спецификаций результата процесса. Поэтому квалификация систем и оборудования является частью процесса валидации. Валидация является требованием регулирующих органов в сфере пищевых продуктов, лекарственных препаратов и фармацевтики, таких как FDA США и их хорошая производственная практика руководящие указания. Поскольку необходимо подтвердить широкий спектр процедур, процессов и действий, область проверки разделена на несколько подразделов, включая следующие:

Валидация оборудования
Валидация объектов
Валидация системы HVAC
Проверка очистки
Проверка процесса
Валидация аналитического метода
Проверка компьютерной системы

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

Квалификация дизайна (DQ)
Квалификация компонентов (CQ)
Квалификация установки (IQ)
Операционная квалификация (OQ)
Квалификация производительности (PQ)

История

Концепция валидации была впервые предложена двумя Управление по контролю за продуктами и лекарствами (FDA), Тед Байерс и Бад Лофтус, в 1979 году в США, чтобы улучшить качество фармацевтических препаратов.^[2] Это было предложено в качестве прямого ответа на несколько проблем стерильности большого объема. парентеральный рынок. Первые действия по валидации были сосредоточены на процессах, задействованных в производстве этих продуктов, но быстро распространились на связанные процессы, включая контроль окружающей среды, наполнение сред, оборудование. дезинфекция и производство очищенной воды.

Концепция валидации была впервые разработана для оборудования и процессов и основана на инженерных практиках, используемых при поставке крупных единиц оборудования, которые будут изготовлены, испытаны, доставлены и приняты в соответствии с контрактом.^[3]Использование валидации распространилось на другие области промышленности после того, как несколько крупномасштабных проблем выявили потенциальные риски в дизайне продуктов. Наиболее примечательным является Терак-25 инцидент.^[4] Здесь программное обеспечение для большого радиотерапевтического устройства было плохо спроектировано и протестировано. При использовании несколько взаимосвязанных проблем привели к тому, что несколько устройств дали дозы радиации, в несколько тысяч раз превышающие предполагаемые, что привело к смерти трех пациентов и еще нескольким необратимым травмам.

В 2005 году человек написал стандарт, по которому процесс транспортировки может быть подтвержден для продуктов холодовой цепи.^{[нужна цитата]} Этот стандарт был написан для компании-производителя биологических продуктов, а затем был включен в Технический отчет № 39 КПК, тем самым установив отраслевой стандарт валидации холодовой цепи. Это было критически важно для промышленности из-за чувствительности лекарственных веществ, биопрепаратов и вакцин к различным температурным условиям. Управление по санитарному надзору за качеством пищевых продуктов и медикаментов (FDA) также уделяет большое внимание этой конечной области распространения и потенциальному влиянию экстремальных температур на качество лекарственных веществ.

Причины валидации

FDA или любое другое агентство по контролю за продуктами питания и лекарствами по всему миру не только запрашивает продукт, который соответствует его спецификации, но также требует, чтобы процесс, процедуры, промежуточные этапы проверок и испытаний, принятые во время производства, были разработаны таким образом, чтобы при их принятии они обеспечивают неизменно похожие, воспроизводимые, желаемые результаты, которые соответствуют стандарту качества производимой продукции и соответствуют нормативным требованиям и аспектам безопасности. Такие процедуры разрабатываются в процессе валидации. Это необходимо для поддержания и обеспечения более высокого уровня качества пищевых продуктов и лекарственных препаратов. "Валидация процесса определяется как сбор и оценкаданные, начиная со стадии проектирования процесса и заканчивая коммерческим производством, которые устанавливают научные доказательства того, что процесс способен обеспечивать стабильную поставку качественного продукта. Валидация процесса включает в себя ряд действий, выполняемых в течение жизненного цикла продукта и процесса »..^[5] Правильно спроектированная система обеспечивает высокую степень уверенности в том, что каждый шаг, процесс и изменение были должным образом оценены перед их внедрением. Тестирование образца конечного продукта не считается достаточным доказательством того, что каждый продукт в партии соответствует требуемой спецификации.

Генеральный план валидации

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

Процесс проверки

Рисунок 1: Традиционный процесс квалификации (адаптированный из типичной V-модели)

Объем валидации, границы и ответственность для каждого процесса или групп аналогичных процессов или аналогичного оборудования должны быть задокументированы и утверждены в плане валидации. Эти документы, термины и ссылки для авторов протоколов предназначены для использования при установке области применения их протоколов. Он должен быть основан на оценке риска валидации (VRA), чтобы гарантировать, что объем санкционированной валидации соответствует сложности и важности оборудования или процесса, находящегося на валидации. В пределах ссылок, приведенных в VP, авторы протокола должны гарантировать, что все аспекты процесса или оборудования проходят квалификацию; которые могут повлиять на эффективность, качество и / или записи о продукте, квалифицированы должным образом. Квалификация включает в себя следующие этапы:

Квалификация проекта (DQ) - демонстрирует, что предложенный дизайн (или существующий дизайн готового изделия) будет удовлетворять всем требованиям, которые определены и подробно описаны в Спецификации требований пользователя (URS). Удовлетворительное выполнение DQ является обязательным требованием до утверждения строительства (или закупки) нового проекта.
Квалификация установки (IQ) - демонстрирует, что процесс или оборудование соответствуют всем спецификациям, установлены правильно, и все необходимые компоненты и документация, необходимые для непрерывной работы, установлены и находятся на месте.
Операционная квалификация (OQ) - демонстрирует, что все аспекты процесса или оборудования работают правильно.
Аттестация производительности (PQ) - демонстрирует, что процесс или оборудование работают так, как задумано, со временем.
Квалификация компонентов (CQ) - относительно новый термин, разработанный в 2005 году. Этот термин относится к производству вспомогательных компонентов, чтобы гарантировать, что они производятся в соответствии с правильными критериями проектирования. Это могут быть компоненты упаковки, такие как складные картонные коробки, транспортировочные ящики, этикетки или даже материал с фазовым переходом. Все эти компоненты должны пройти случайную проверку того или иного типа, чтобы гарантировать, что процесс стороннего производителя постоянно производит компоненты, которые используются в мире GMP на производстве лекарств или биологических препаратов.

Бывают случаи, когда более целесообразно и эффективно передавать некоторые тесты или проверки из IQ в OQ или из OQ в PQ. Это разрешено нормативными актами при условии, что четкое и утвержденное обоснование задокументировано в Плане валидации (VP).

Рисунок 2: Процесс проверки OPQ (адаптированный из типичной V-модели)

Это комбинированное тестирование фаз OQ и PQ санкционировано Генеральным директоратом предприятий Европейской комиссии в рамках «Приложения 15 к Руководству ЕС по надлежащей производственной практике» (2001, стр. 6), в котором говорится, что:

"Хотя PQ описывается как отдельная деятельность, в некоторых случаях может быть целесообразно выполнять ее вместе с OQ."

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

Это требование естественным образом распространилось на компьютерные системы, используемые как для разработки, так и для производства, а также как часть фармацевтический товары, медицинское оборудование, продукты питания, учреждения крови, учреждения ткани и клинические испытания. В 1983 году FDA опубликовало руководство по проверке компьютеризированных систем в фармацевтической обработке, также известное как «синяя книга».^[6] Недавно и американское FDA, и Великобритания Агентство по регулированию лекарственных средств и товаров медицинского назначения добавили разделы в правила специально для использования компьютерных систем. В Великобритании компьютерная проверка описана в Приложении 11 к правилам GMP ЕС (EMEA 2011). FDA представило 21 CFR Part 11 для правил использования электронных записей и электронных подписей (FDA 1997). Правила FDA гармонизированы с ISO 8402: 1994,^[7] который лечит "проверка" и "Проверка«как отдельные и отдельные термины. С другой стороны, во многих статьях и учебниках журналов по программной инженерии термины« проверка »и« проверка »используются как синонимы, или в некоторых случаях относятся к программному обеспечению»проверка, проверка и тестирование (VV&T) ", как если бы это была единая концепция, без различия между тремя терминами. Общие принципы валидации программного обеспечения (FDA 2002) определяют верификацию как «Верификация программного обеспечения обеспечивает объективное свидетельство того, что результаты проектирования конкретной фазы жизненного цикла разработки программного обеспечения соответствуют всем указанным требованиям для этой фазы».^[8]Он также определяет валидацию как«Подтверждение путем изучения и предоставления объективных свидетельств того, что спецификации программного обеспечения соответствуют потребностям пользователя и предполагаемому использованию, и что конкретные требования, реализованные с помощью программного обеспечения, могут быть последовательно выполнены». В руководстве по валидации программного обеспечения говорится: «Процесс разработки программного обеспечения должен быть достаточно хорошо спланирован, контролироваться и задокументирован, чтобы обнаруживать и исправлять неожиданные результаты изменений программного обеспечения». В Приложении 11 говорится: «Документация по валидации и отчеты должны охватывать соответствующие этапы жизненного цикла. "

Вейхель (2004) недавно обнаружил, что более двадцати писем с предупреждениями, выпущенных FDA фармацевтическим компаниям, конкретно упоминают проблемы проверки компьютерных систем в период с 1997 по 2001 год.^[9]

Вероятно, наиболее известным отраслевым руководством является Руководство GAMP, теперь его пятое издание и известное как GAMP5, опубликованное ISPE (2008).^[10] Это руководство дает практические советы по соблюдению нормативных требований.

Объем компьютерной проверки

В приведенном выше определении валидации обсуждается получение свидетельства того, что система будет соответствовать своей спецификации. Это определение относится не к компьютерному приложению или компьютерной системе, а к процессу. Основные последствия этого заключаются в том, что валидация должна охватывать все аспекты процесса, включая приложение, любое оборудование, которое использует приложение, любые интерфейсы с другими системами, пользователей, обучение и документацию, а также управление системой и саму валидацию. после ввода системы в эксплуатацию. В руководстве PIC / S (PIC / S 2004) это определяется как «компьютерная система».^[11]В отрасли тратятся большие усилия на деятельность по валидации, и несколько журналов посвящены как процессу и методологии валидации, так и науке, лежащей в основе этого.^[12]^[13]^[14]^[15]

Подход к компьютерной валидации, основанный на оценке рисков

В последние годы в отрасли был принят подход, основанный на оценке рисков, при котором тестирование компьютерных систем (акцент на поиске проблем) проводится в широком масштабе и документируется, но не имеет серьезных доказательств (т.е. сотни снимков экрана не собираются во время тестирования. ). В Приложении 11 говорится: «Управление рисками следует применять на протяжении всего жизненного цикла компьютеризированной системы с учетом безопасности пациентов, целостности данных и качества продукции. В рамках системы управления рисками решения о степени валидации и контроле целостности данных должны основываться на обоснованная и задокументированная оценка рисков компьютеризированной системы ».

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

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

Определение «критического GxP-требования» для компьютерной системы является субъективным, и определение должно быть адаптировано к вовлеченной организации. Однако в целом требование «GxP» может рассматриваться как требование, которое ведет к разработке / настройке компьютерной функции, которая оказывает прямое влияние на безопасность пациента, обрабатываемый фармацевтический продукт или была разработана / настроена для удовлетворения нормативное требование. Кроме того, если функция имеет прямое влияние на данные GxP (безопасность или целостность), ее можно считать «критичной для GxP».

Подход жизненного цикла продукта при валидации

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

Смотрите также

Источники

Руководство по фармацевтической валидации

[1] Определение валидации и требования руководящих принципов FDA, регулирующих органов По состоянию на 27 февраля 2014 г.

[2] Агаллоко, Дж. (1995). «Валидация: нетрадиционный обзор и новое изобретение». Валидация: нетрадиционный обзор и новое изобретение. 49 (4): 175–179.

[3] Hoffmann, A., Kahny-Simonius, J., Plattner, M., Schmidli-Vckovski, V., & Kronseder, C. (1998), 'Валидация компьютерных систем: обзор официальных требований и стандартов', Pharmaceutica Acta Helvetiae , т. 72, нет. 6. С. 317–325.

[4] Левесон, Н. Г. и Тернер, С. С. (1993), «Расследование аварий с Therac-25», Компьютер, т. 26, вып. 7. С. 18–41.

[5] FDA (1987). «Руководство по общим принципам валидации процессов». Цитировать журнал требует | журнал = (помощь)

[6] FDA (1983). «Руководство по проверке компьютеризированных систем (Синяя книга)». Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США, Мэриленд, США.

[7] Международная организация по стандартизации, Женева, Швейцария (1994). «ISO 8402: 1994: Менеджмент качества и обеспечение качества - Словарь». Цитировать журнал требует | журнал = (помощь)CS1 maint: несколько имен: список авторов (ссылка на сайт)

[8] «Общие принципы валидации программного обеспечения; Окончательное руководство для сотрудников отрасли и FDA» (PDF). FDA США. 2002 г.. Получено 27 февраля, 2013.

[9] Вейхель, П. (2004). «Обзор опубликованных предупреждающих писем FDA с комментариями к части 11 (21 CFR Часть 11)». Журнал технологий валидации. 11 (1): 62–66.

[10] ISPE (2008). «GAMP5: Подход к соответствию компьютерам, основанный на оценке риска». Международное общество инженеров-фармацевтов, Тампа, Флорида.

[11] PIC / S (2004). «Надлежащая практика для компьютеризированных систем в регулируемой среде GXP, отчет PI 011-2». Конвенция о фармацевтическом контроле, Женева.

[12] Смит, Х. Г. (2001). «Рекомендации по улучшению проверки программного обеспечения, обеспечение большей гарантии за меньшие деньги». Журнал технологий валидации. 7 (2): 150–157.

[13] Трейси, Д. С. и Нэш, Р. А. (2002). «Подход к валидации для систем управления лабораторной информацией». Журнал технологий валидации. 9 (1): 6–14.

[14] Лукас, И. (2003). «Время тестирования компьютерной проверки». Журнал технологий валидации. 9 (2): 153–161.

[15] Балог М. и Корбин В. (2005). «Укрощение регулятора: регулирование против функционализма». Фармацевтические технологии в Европе. 17 (3): 55–58.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

Navigation