6.9.1Организация принимает на себя бизнес-риски и выполняет валидацию ЛИМС намного большего уровня и большей глубины.
6.9.2Организация отвергает продавца ЛИМС и проводит процесс выбора альтернативного продавца ЛИМС.
7 Валидация ЛИМС, установленной на площадке заказчика
(ГОСТ Р ИСО 9004, ГОСТ Р ИСО 19011*, ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО/МЭК 14764*, ГОСТ Р ИСО/МЭК ТО 15271*, ГОСТ Р 53798)
7.1Заказчик должен валидировать используемую им ЛИМС, независимо от любых результатов аудита продавца, в той среде функционирования, в которой будет находиться ЛИМС. Тот факт, что продавец валидировал процесс разработки ЛИМС сам или с привлечением других организаций, имеет незначительное отношение к валидации приложения ЛИМС, находящегося в организации. Тот факт, что программное обеспечение продавца ЛИМС было валидировано одним из других заказчиков продавца, не устраняет необходимость для организации валидировать внедрение их приложения.
7.2Так как ключевые функциональные требования определяются и оцениваются в процессе фазы оценки продукта, результаты данного определения должны быть зарегистрированы. Эти результаты могут быть использованы при разработке, выполнении и документировании официальных протоколов испытания ЛИМС. Любое испытание, проведенное в течение разработки протоколов испытания ЛИМС или полного плана валидации, должно далее совершенствоваться, как только будет выбрана конкретная ЛИМС. Следует отметить, что уровень испытания и анализа, достигнутого в процессе оценки и выбора, обычно не содержит достаточного количества деталей, чтобы заменить протокол испытаний, используемый в документации плана валидации.
7.3Команда по валидации ЛИМС может начать определение дополнительных ресурсов для испытания ЛИМС. Любые новые избранные лица должны быть хорошо знакомы с требованиями и деятельностью лаборатории. Кроме того, они должны иметь познания относительно cGMP, GMP, GLP, GALP [1] или других нормативных требований, которым должна следовать лаборатория.
7.4Обычно ЛИМС поставляется как некая незаполненная база данных, то есть лишенная данных, специфических для площадки заказчика. Данные конфигурации и заданная лабораторная информация должны быть введены перед тем, как система сможет быть валидирована. В этом случае организация начинает моделировать свои лабораторные методы в ЛИМС. Они включают определение испытаний и автоматизированного рабочего места, а также лабораторных и персональных данных заказчика. Следует отметить, что в течение данного этапа лаборатория может наметить дополнительные функциональные требования, которые не были включены вначале. Если организация выбирает для внедрения такие функциональности, документ с требованиями к ЛИМС должен быть пересмотрен, чтобы отразить эти изменения. На данном этапе организация может обнаружить требования, которые не могут встретиться в ЛИМС. Организация должна документировать эти факты и определить, какие действия, если таковые вообще имеются, она предпримет для решения этой проблемы. Имеется несколько стратегий, которые могут быть использованы для валидации ЛИМС. Они включают, но не ограничиваются перечисленными ниже.
7.4.1Следует конфигурировать ЛИМС специально для испытания только с достаточным количеством конфигурационных данных, чтобы проведение испытания было возможно. В этом случае испытуемая система является идентичной производственной системе, а именно: она функционирует в той же самой эксплуатационной среде, что и производственная система. Обычно это означает, что она функционирует на том же самом компьютере, на котором будет размещена производственная система. Конфигурация, используемая для испытуемой системы, должна точно соответствовать производственной системе. В особенности все сообщения, экраны ввода данных, запросы и т.д. должны быть идентичными. Кроме того, все характеристики, которые используются при производстве ЛИМС, должны быть проверены для надлежащих операций в испытуемой системе.
7.4.2Следует конфигурировать ЛИМС для регулярных операций, а затем изолировать ее от обычного обслуживания на то время, когда проводится испытание. Система, сконфигурированная для использования, называется производственной системой. Конфигурирование может быть достигнуто путем копирования производственной базы данных в испытуемую систему. Исполняемые программы ЛИМС являются частью компьютерных программ, готовых к использованию, как, например, валидационные данные могут быть частью отдельного комплекта таблиц базы данных, которые используют ту же исполняемую программу, что и производственная ЛИМС, или валидационные данные могут быть частью различных групп данных, которые используют те же таблицы базы данных и исполняются как производственная ЛИМС. Различия имеются в таблицах данных образцов. Если нет никаких проблем, такой подход позволяет сэкономить время. ЛИМС не должна конфигурироваться дважды: один раз - для испытания и вторично - для производства. Если появляются проблемы, может потребоваться частичное или полное повторное конфигурирование после выполненной работы по наладке. Должна быть обеспечена документация, верифицирующая (подтверждающая), что производственная система является эквивалентной испытуемой системе, и данные, произведенные в течение процесса валидации, должны быть сохранены и определены в качестве валидационных данных.
7.4.3Для испытания может быть использована отдельная компьютерная система.
7.4.3.1Отдельный компьютер может быть сконфигурирован специально для валидации, как указано в 7.4.1, или он может быть копией производственной системы, как указано в 7.4.2.
7.4.3.2Если используется отдельный компьютер, должны быть идентичные аппаратные средства, программное обеспечение и операционная система. Среда функционирования должна быть идентична одной из используемых для производственной системы. Интерфейсы инструментов могут быть различны для установки на такую испытуемую систему, но если они являются частью производственной системы, они должны быть также частью испытуемой системы. В конечном счете испытуемая система может обеспечить резервные аппаратные средства для производственной системы.
7.4.3.3Производственная и испытуемая системы могут существовать на одном и том же компьютере и, если достаточно энергии, могут работать независимо друг от друга. В этом случае обе программные системы могут иметь доступ к интерфейсам инструмента.
7.4.3.4Подмножество тестов необходимо, когда испытуемая система преобразуется в производственную систему. Эти испытания используются для подтверждения того, что система до сих пор функционирует в соответствии с производственным режимом. Никаких искусственных данных не должно быть загружено в активную систему. Это подмножество тестов может состоять из поставляемых продавцом диагностических процедур, до тех пор пока с их помощью надежно испытывают все части предлагаемой системы. Некоторые продавцы поставляют эти типы инструментальных средств, в то время как многие другие этого не делают. Не существует никакого стандарта для их конструирования и выполнения. Использование таких средств не должно означать, что они являются единственными средствами испытания ЛИМС, но скорее представляет собой добавление комплекта более строгих протоколов испытаний. В некоторых случаях организация может затребовать инструментальные средства, которые сами должны быть валидированы перед их использованием.
7.4.4Может использоваться параллельное испытание. При испытании новой ЛИМС одновременно с ЛИМС могут быть использованы системы с ручным управлением, а результаты сравнены. Если новая ЛИМС заменяется, обе системы - старая и новая - могут использоваться параллельно в течение некоторого периода времени, чтобы была возможность их сравнить. Сложившаяся валидированная система является производственной системой, в то время как новая ЛИМС является испытуемой системой. Валидация интерфейсов к инструментам является проблемой, с которой сталкиваются при параллельном испытании, так как обычно они не могут быть соединены с двумя системами в одно и то же время. В этом случае организация должна разработать подход, который позволяет провести испытание этих интерфейсов. Организация может пожелать соединить эти интерфейсы с системой, подвергающейся валидации, после того как все другие испытания были выполнены и непосредственно перед разработкой заключительного валидационного отчета. Другой подход состоит в том, чтобы включить эти интерфейсы в качестве собственного валидационного проекта после того, как первоначальная валидация будет завершена.
7.5Ответная реакция на ошибки
7.5.1Обработка ошибок и критерии приемки должны быть определены и описаны в валидационном протоколе, прослежены в процессе испытания и отражены в отчете о результатах. Определение должно включать критерии, которые используются для того, чтобы оценить серьезность ошибок.
7.5.2Критические ошибки, такие как сбои системы или фатальные ошибки, выделенные в течение валидационного испытания, должны быть немедленно подвергнуты коррекции или ремонту, перед тем как будет проведено дополнительное испытание. Часто корректировка таких ошибок требует, чтобы большинство или все валидационные испытания были проведены вновь. Имеются такие ошибки, для которых не существует специальных приемов для исправления. Эти ошибки серьезно угрожают целостности данных ЛИМС.
7.5.3В процессе валидационных испытаний должны быть собраны некритические ошибки. Когда испытание закончено, команда может принять решение о том, что эти ошибки не подвергают опасности целостность информации. Имеются ошибки, которые могут привести к тому, что, возможно, системой ЛИМС будут приняты недопустимые результаты. Для таких ошибок могут быть использованы специальные приемы.
7.5.4Команда по валидации может изъявить желание использовать систему для сортировки ошибок, которая помогает совершать действия для выделения ошибок. Каждая ошибка будет определена в соответствии с определенным сортом, и будет принято решение о том, что следует предпринять в дальнейшем в случае необходимости. Следующие пункты предоставляют примеры сортировки и ошибок, которые соответствуют этим сортам:
7.5.4.1Сорт 0 - типографские ошибки и другие ошибки, не относящиеся к компьютерной системе.
7.5.4.2Сорт 1 - незначительные ошибки, такие как использование прописных и строчных букв на полях, не предназначенных для них.
7.5.4.3Сорт 2 - допустимые ошибки, о которых необходимо сообщить продавцу.
7.5.4.4Сорт 3 - значительные ошибки, о которых необходимо немедленно сообщить продавцу и руководителю подразделения по обеспечению качества. Все работы по валидации должны быть приостановлены, пока уполномоченные специалисты по качеству обсуждают проблему.
7.5.4.5Сорт 4 - катастрофические ошибки, такие как реляционные ошибки в базе данных. О них сообщают таким же образом, как для сорта 3, но работа по валидации должна быть прервана. Специалисты по обеспечению качества могут, однако, принять решение о том, что работа по валидации будет продолжена после всестороннего обсуждения.
7.6Стандартные операционные процедуры (СОП)
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9001, ГОСТ Р ИСО 19011*, ГОСТ Р 53798, [1-2])
7.6.1СОП являются необходимыми для валидации и текущего функционирования ЛИМС данной организации. Эти документы касаются нескольких областей, от работы с приложением ЛИМС до аппаратных средств, на которых это приложение размещено. СОП формализуют процедуры, используемые для поддержки ЛИМС в состоянии валидации, путем описания конкретных процедур, которым необходимо следовать. Эти процедуры помогают гарантировать, что организация поддерживает операции по качеству. СОП детально описаны в 11.4.
8 Проектирование плана валидации
(ГОСТ Р ИСО 19011*, [1-2])
8.1План валидации обеспечивает общее руководство процессом валидации. К плану валидации относятся, но не ограничиваются ими, следующие пункты: общие цели; описание системы; границы или допущения при испытаниях, согласно которым команда валидации будет работать; обязанности участников и основные инструкции для выполнения испытательных протоколов по квалификации монтажа (IQ) или квалификации функционирования (эксплуатации) (OQ). План валидации должен включать перечень и описание всех компонентов программного обеспечения и аппаратных средств. Иногда программные модули, ассоциированные с ЛИМС, изменяются при установке другого программного обеспечения. Эти изменения могут появляться при модернизации операционной системы, модернизации ЛИМС или других программ. Добавление компонентов аппаратных средств, видеокарт, модемов, звуковых карт и т.д. и связанных с ними типов программного обеспечения может затронуть состояние первоначальной валидации ЛИМС. Детальный перечень компонентов программного обеспечения и аппаратных средств, связанных с ЛИМС, является существенным, так как он представляет первоначальную конфигурацию ЛИМС и описывает первоначальное состояние, на котором базируется контроль над всеми изменениями. Все протоколы испытаний для квалификации монтажа и функционирования (IQ, OQ) связанных компонентов аппаратных средств и программного обеспечения включаются в план валидации. Последней частью плана валидации является подписание его лицами, ответственными за гарантирование того, что план валидации соответствует требованиям организации и нормативным требованиям. Обычно эти подписи включают подписи руководителя процессом валидации, являющегося уполномоченным лицом подразделения по обеспечению качества (QAU), руководителя лаборатории, менеджера ЛИМС и других лиц.
8.2Испытание квалификации монтажа (IQ) должно основываться на спецификациях или рекомендациях производителя, или того и другого. Конфигурация конкретного приложения утверждается в качестве части испытания IQ, OQ.
8.3Поставленные продавцом инструменты и методы диагностики могут быть использованы как часть испытания IQ, OQ. Протоколы испытания IQ, OQ, основанные на поставленных продавцом диагностиках, должны включать пошаговую проверку диагностических процедур, регистрацию всех результатов и критерии приемки каждого результата.
8.4Документы протоколов IQ, OQ и результатов испытаний должны быть произведены для всех типов аппаратных средств и программного обеспечения, используемых ЛИМС: для операционной системы, базы данных, генератора отчета, статистических пакетов, сети, соединенных инструментов, компьютеров, включая терминалы, персональные компьютеры, клиентов, а также серверы, принтеры, плоттеры, считыватели штриховых кодов и т.д. Если приложение ЛИМС загружается в существующую компьютерную систему, может быть использована оригинальная документация квалификации монтажа (IQ) аппаратных средств.
8.5Предложенный формат протокола IQ/OQ приведен в приложении Х2.
9 Проектирование протокола испытаний
(ГОСТ Р ИСО 19011*, [1-2])
9.1Каждая организация должна определить, какие характеристики ЛИМС могут привлечь наибольшее внимание аудиторских агентств. Организация должна определить, какой уровень риска она готова взять на себя. Валидация каждой характеристики является слишком дорогостоящим процессом как с точки зрения ресурсов, так и времени. МакДоуэлл [2] предложил, чтобы организация подразделяла функции ЛИМС на следующие три категории: функции ЛИМС должны быть валидированы; функции ЛИМС следовало бы валидировать; функции ЛИМС могут быть валидированы.
9.1.1Протоколы валидационных испытаний необходимы для того, чтобы определить критические функции ЛИМС, которые будут испытываться. Критические функции ЛИМС должны базироваться на основных функциях и на намеченном для использования приложении ЛИМС. Должно быть предусмотрено разумное объяснение для того, чтобы не проводить тестирование каких-либо частей ЛИМС.
9.2Разработка и выполнение протоколов испытаний (Test Protocol, ТР) в процессе валидации требуют большого количества времени. Этот факт часто игнорируется, когда разрабатывается проект плана валидации. На разработку протоколов испытаний и их выполнение влияют многие факторы. Во-первых, существенным является хорошая осведомленность о новой ЛИМС и о том, как она работает. Слабое ознакомление пользователя с ЛИМС приводит к более длительной разработке детальных протоколов испытаний. Команда по валидации должна выделить достаточное количество времени в календарном графике проектирования для персонала, разрабатывающего протоколы испытаний, чтобы он ознакомился с новой системой. Вторым фактором, влияющим на разработку протоколов испытаний, является то, насколько долго разработчик протоколов испытаний должен сосредоточиваться на проекте валидации. Недостаточная концентрация усилий по разработке протоколов испытаний добавит значительное количество дополнительных месяцев на проектирование валидации. На выполнение протоколов испытаний также существенно влияет сосредоточение внимания испытателя на выполнении протоколов испытаний. Третьим фактором, влияющим на разработку протоколов испытаний, является количество ресурсов, доступных для работы по протоколам испытаний. И последнее - уровень опыта лиц, пишущих и выполняющих протоколы испытаний, будет влиять на то, сколько времени понадобится для осуществления этих действий. По возможности, в организации должен быть по крайней мере один опытный сотрудник, взаимодействующий с теми, кто разрабатывает и выполняет протоколы испытаний.
9.3Число протоколов испытаний, необходимых для валидации ЛИМС, зависит от сложности ЛИМС и уровня деталей, требуемых для адекватного испытания ключевых характеристик. Протоколы испытаний могут быть как простыми - один или два типа инструкций для выполнения, так и сложными - несколько сотен типов инструкций. Уровень сложности будет зависеть от направления, которого придерживается организация в проекте этих протоколов испытаний. Каждая организация должна иметь организационные СОП, которые описывают, как должны разрабатываться протоколы испытаний. Проект и основные инструкции, согласно которым должны действовать испытатели и чего они должны ожидать в качестве критерия приемки, могут быть как простыми, так и очень высокого уровня. Протоколы испытаний, созданные подобным образом, обычно требуют, чтобы испытатели описали в деталях, что именно они делали. На противоположной стороне спектра находятся те протоколы испытаний, которые инструктируют испытателей шаг за шагом о том, что именно им следует делать. Протоколы испытаний, разработанные подобным способом, обычно требуют от испытателей ответить: да/нет или истинный/ложный - относительно критериев приемки. В любом случае для выполнения и документирования сложных протоколов испытаний может потребоваться несколько дней. Детали, полученные испытателем относительно каждого протокола испытания, должны быть достаточными для того, чтобы гарантировать, что функции или процессы ЛИМС, которые испытываются, находятся под контролем (приложение Х3).
9.4В дополнение к выполнению протокола испытания команда по валидации должна предусмотреть достаточное количество времени, необходимого для рассмотрения результатов протокола испытания и решения любых конкретных проблем. Процесс рассмотрения может продолжаться почти так же долго, как выполнение протокола испытания, если испытание является чрезвычайно сложным. Количество времени, необходимое для того, чтобы выполнить этот этап валидации, часто недооценивается (занижается). Рассмотрение каждого протокола испытания необходимо для того, чтобы гарантировать, что его содержание обоснованно, а протокол испытаний придерживается требований к документации в соответствии с GMP. В особенности должны быть предприняты единообразные действия относительно ошибок; испытатель должен подписать документ, поставить дату и привести причину, почему слово или группа слов были вычеркнуты. В некоторых случаях за принятие решения может быть ответственным рецензент, если протокол испытания успешно соответствует критериям приемки и, соответственно, принимается или отклоняется.
9.5Команда по валидации должна обратиться к валидационному плану относительно того, как она будет управлять протоколами несостоятельных (ошибочных) испытаний. Это должно быть сделано перед началом испытаний. Команда по валидации также должна сначала рассмотреть то, как будут вноситься изменения в протоколы испытаний после их утверждения уполномоченными специалистами по качеству. Возникают моменты, когда испытателям необходимо произвести изменения в протоколах испытаний в период фазы выполнения протоколов испытаний. Испытателями должен быть предусмотрен способ для включения этих изменений в существующий протокол испытаний. Процедура должна быть утверждена уполномоченными лицами по качеству и включена в план валидации. Является существенным, чтобы дающаяся испытателю свобода была использована для дальнейшего проектирования и следования этапам дополнительных испытаний в период выполнения протоколов испытаний. Эта свобода позволяет им исследовать, почему конкретный этап или ряд этапов не соответствует критериям приемки. Без этой свободы может быть отсрочен весь проект валидации.
9.6Все протоколы испытаний должны быть разработаны для испытания установленных в ЛИМС характеристик или функций. Фактический проект протоколов испытаний будет изменяться в зависимости от организации. Разработчик проекта протокола испытания может изъявить желание включить некоторые или все из следующих ниже характеристик в проекте протокола испытания.
9.6.1Информация в заголовке протокола испытания
Эта секция содержит название корпорации, использующей ЛИМС, наименование отдела владельца ЛИМС, дату разработки протокола испытания, мотивировку, если протокол испытания предназначен для уполномоченных лиц по квалификации монтажа или функционирования, номер пересмотра протокола испытания и информацию о том, какая система испытывается (например, "ABC" ЛИМС, версия 7.1).
9.6.2Идентификационный номер протокола испытания
Каждый протокол испытания должен иметь уникальный идентификационный номер. Этот номер является уникальным лишь для связанного с планом валидации протокола испытания.
9.6.3Цель