Это старый сайт. Перейдите на НОВЫЙ

 

Әрбір сөз - жақсы өмір үшін!

Дүйсенбі, 18 Сәуір 2016

Валидация компьютеризированных систем - вопрос, от которого дергается глаз у любого IT-шника

Rate this item
(2 votes)

muzykin-2Любая компания, внедрившая стандарты надлежащих фармацевтических практик, сталкивается с необходимостью валидации используемых компьютеризированных систем. Поэтому неудивительно, что для участников казахстанского фармацевтического рынка данный вопрос в последнее время приобрел особенную актуальность. В связи с чем в редакцию нашей газеты и от поставщиков, и от потребителей программного обеспечения стали поступать вопросы: Кто должен проводить валидацию? Как она проводится? Что из себя представляет данная процедура? С какой периодичностью ее следует проводить? Ответить на них мы попросили Михаила Музыкина, кандидата фармацевтических наук, старшего научного сотрудника производственной лаборатории ООО НТФФ «ПОЛИСАН» (Россия).

- Вопрос валидации компьютеризированных систем (КС) глобальный и по уровню сложности равный вопросу «что такое GMP и как им следовать?» Только в валидации КС ключевым стандартом является методология GAMP 5 (Good Automated Manufacturing Practice): A Risk-Based Approach to Compliant GxP Computerized Systems. Объем мероприятий, проводимых при валидации компьютеризированных систем, определяется категорией программного обеспечения (ПО). В соответствии с GAMP компьютеризированные системы подразделяются на 5 категорий:

- системное программное обеспечение (ПО);

- микропрограмма (ПО в аппаратных устройствах);

- ПО, готовое для использования;

- конфигурируемое ПО;

- самостоятельно разработанное специальное ПО.

Из вопроса не до конца ясно с 3, 4 или 5 категорией КС мы имеем дело. Продажа 1С относится к 3-ей категории КС. Создание форм взаимодействия, форм документов с использованием встроенного функционала, т.е. доработка ПО под конкретные задачи, - это 4 категория. Программное дополнение любого рода - 5 категория.

Валидация состоит из следующих процессов:

- квалификация проектной документации (Design Qualification - DQ) - проверка описания и разработки системы;

- квалификация инсталляции (монтажа) (Installation Qualification - IQ) - проверка способности инфраструктуры системы поддерживать работу системы;

- квалификация функционирования (Operational Qualification, OQ) - проверка способности функционировать согласно требованиям;

- квалификация эксплуатации (Performance Qualification - PQ) - проверка способности компании использовать систему.

Т.е. DQ - соответствие «что хотели, то и получили», IQ - проверка соответствия системным требованиям, OQ - заявленные функции работают, вычисления происходят корректно, PQ - процедура взаимодействия с ПО корректна и соответствует описанию.

Объем валидации для 3 категории КС включает процессы IQ, OQ, т.е. требуется доказать, что система соответствует ожиданиям, а ПО работает. Для 4 категории необходимо пройти стадии DQ, IQ, OQ, т.е. нужно показать, что сконфигурированные функции и система соответствуют ожиданиям, а ПО функционирует. Для 5 категории следует провести полный объем валидационных стадий - DQ, IQ, OQ, PQ.

Как проводится валидация? Вопрос, от которого дергается глаз любого IT-шника - проверяем ВСЕ. При этом по правилам GMP - что не записано, того не существует - т.е. необходимо наличие документа, описывающего функциональные возможности ПО - спецификации. Тут есть варианты в поименовании данного документа - в зависимости от процедуры - это может быть техническое задание (URS), спецификация разработчика (DS), или руководство пользователя (Manual). Так или иначе, необходим документ, указывающий, ЧТО ДОЛЖНО УМЕТЬ ДЕЛАТЬ ПО и какие системные требования есть для его функционирования. После этого сама валидация сводится к проверке соответствия ПО системным требованиям и функциональному тестированию.

Как это происходит в реальности? В техническом задании написано, что по кнопке «отчет» должен быть отправлен отчет на принтер. Валидационный тест заключается в том, что при нажатии на кнопку «генерация отчета», отчет отправляется на принтер и распечатывается. Это и есть критерий приемлемости. И по такой схеме проверяется КАЖДЫЙ пункт технического задания. Соответственно, совокупностью документов, сопровождающих приложение, является техническое задание (URS), отчет о разработке (включая функциональное тестирование у разработчика). Для 3 категории КС в сопроводительной документации к ПО идет сертификат на соответствие 3 категории по GAMP и проведение валидации у разработчика. Далее протокол и отчет о валидации.

Периодичность валидации - тема ущербная по своей сути. Не должно быть никакой периодичности для ревалидации ПО. Этот момент НЕОБХОДИМО заменить на процедуру УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ. Ревалидация ПО необходима ТОЛЬКО при внесении изменений, причем в объеме, определяемым самим изменением. Т.е., если вы добавили удобную кнопку, нужно отвалидировать факт того, что удобная кнопка работает. Если перешли на новую версию операционной системы, следует проверить несчастное ПО на новой операционной системе по полной программе. 

Read 5386 times

БАЙЛАНЫСТАР

«PharmReview» ЖШС.

Тел.: +7 707 738 99 70.

Директор: Ольга Баимбетова

(e-mail: baimbetova.o@mail.ru).

Scroll to top