Презентация на тему Валидация КС вкючая квалификация IT инфраструктуру

валидации компьютизированных систем
ИТ-инфраструктура

Содержание

системы (компьютерная валидация) – это достижение и поддержание соответствия

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

Что такое компьютерная валидация?

других видов валидации, включает в себе не только процесс

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

Что такое компьютерная валидация?

проведении компьютерной валидации, на сегодняшний день является GAMP 5

(Good Automated Mаnufacturing Practice – Надлежащая Практика Автоматизированного Производства), также носящий невероятное название «Подход, основанный на оценке рисков», к КС по GxP, соответствующим требованиям.
Как и известная многотомная серия инженерных руководств ISPE, GAMP – это не нормативный документ, а только руководство, и некорректно говорить в соответствии или несоответствии чего-либо GAMP. В этом смысле GAMP служит скорее протипом, на основе которого предприятие должно создать разделы в своей системе качества, отвечающие за компьютизированные системы.

Руководство GAMP

содержщейся в названии документа, вытекает из декларируемого в GAMP

принципа масштабирования на основе проведения оценки рисков. Такое масштабирование возможно в отношении:
Количества и глубины необходимых экспертиз проекта(DR-Design Review)
Необходимости и объема анализа программного кода (Source Code Review)
Строгости оценки поставщиков
Глубины и строгости тестирования

Руководство GAMP

с учетом:
Критичности процесса для качества / безопасности продукта (оценка

рисков)
Сложности систем
Стандартности / нестандартности используемого оборудования, технологий, програмного обеспечения

Руководство GAMP

стала инвентаризация имеющейся технической документации на систему. Не смотря

на очень положительное впечатление от предприятия, валидируемых систем и уровня квалификации персонала, ряда документов все-таки не было в наличии. Это – вполне обычная ситуация при ретроспективной квалификации/ валидации, и совсем не означает, что такое оборудование не может быть квалифицировано/ валидировано. Главное, чтобы соблюдался важный принцип GMP: на любую систему в каждый момент времени должна иметься актуальная документация, позволяущая однозначно идентифицировать как саму систему, так и любой ее компонент.

Документация

(или отсутствующей) документацией, мы можем создать недостающие документы, делая

«зарисовки с натуры». Таким образом, был сформирован полноценный пакет актуальной технической документации, содержащий техническое задание (URS), функциональные и проектные спецификации, технологические схемы с КИПиА (P&ID), электрические схемы и различные перечни компонентов, элементов программы и интерфейса и т.п.

Документация

контроллера(PLC), и тестирование с компьютера. По своей сути это

очень похоже на квалификацию функционирования(OQ-Operational Qualification).
В ходе тестирования с контроллера выполнялись следующие группы тестов:
Общая работоспособность программы
Навигация между всеми индивидуальными экранами HIM системы
Индивидуальный тест каждой технологической программой последовательности
В ходе тестирования с компьютера выполнялись все те же группы тестов, кроме последней: протекание програмных последовательностей управляется программным кодом на контроллере, функционирование которого уже было проверено в ходе тестирования с контроллера.

Функциональное тестирование

требуют валидации, которая должна подтвердить их надежность.
GMP не

требует проведения полной валидации, но допускает проведение валидации только для их критических частей, компонентов и функций. Для оценки критичности используется анализ рисков.
GMP требует, чтобы пользователи поняли риски, связанные с внедрением и эксплуатацией КС.
Процесс анализа рисков обычно рассматривает следующие вопросы:
Требуется ли валидация КС?
Какой объем валидации востребован для данной КС?
Какие аспекты КС или процесса являются критическими для продукта или безопасности пациента?
Какие аспекты КС или процесса являются критическими

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

связанные с эксплуатацией КС, идентифицировать и свести к минимуму

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

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

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

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

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

располагает информацией о состоянии проекта и валидационных действиях. Состав

такой группы будет зависеть от сложности и специфики КС. По результатам анализа рисков группа должна составить отчет, который должен быть согласован владельцем и пользователем системы, а также QA. Заключения анализа рисков могут также согласовываться/утверждаться и другими лицами сторонние специалисты, поставщики и др.

Рабочая группа по анализу рисков

КС управление на участке активных фармацевтицеских субстанций (АФС) в

одном из цехов латвийского фармацевтического предприятия AS OlainFarm – ведущего производителя АФС в Балтийском регионе.
Для повышения эффективности и оптимизации расходов было предложено разделение работ между Исполнителем – ФармаГрупп Балтик ОЮ, и Заказчиком – АС ОлайнФарм.

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

были разделены на 5 категорий: работы полностью проводятся Исполнителем,

и Заказчику передается готовый документ;работы ведутся параллельно Исполнителем и Заказчиком (50/50) – горизонтальное разделение; Исполнитель выдает Заказчику шаблон документа, который Заказчик заполняет; Исполнитель выдает Заказчику перечень основных положений – тезисы документа, на основе которых Заказчик разрабатывает документ; Исполнитель выдает Заказчику задание, Заказчик выполняет работу самостоятельно. Во всех случаях Исполнитель оказывает поддержку Заказчику при проведении работ и проверяет готовые документы, составленнве Заказчиком.
Такая модель сотрудничества позволила Исполнителю значительно снизить стоимость контракта, а сотруднии Заказчика дополнительно приобрели ценные навыки.

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

коммуникационных, информационных и организационно-технологических средств обеспечения функционирования предприятия, а

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

ИТ-инфраструктура