10.1.4.3Регистрации при обслуживании аппаратных средств
Эти процедуры регистрации разрешают вопросы, конкретно связанные с компонентами аппаратных средств ЛИМС, включая любую связанную сетевую периферию. Пользователь должен отслеживать: номер серии/партии компонента, подлежащего замене; наименование продавца замененной платы; если известно, номер серии/партии новой части; производителя новой платы; имя наладчика в напечатанном виде и его подпись; дату, когда имела место замена; причину, по которой компонент был заменен; другие данные, которые будут полезны, чтобы устранить неполадки позже.
10.1.5Повторная валидация
Все изменения должны быть оценены относительно их воздействия на валидацию ЛИМС. Если происходят изменения, которые воздействуют на целостность или точность данных в ЛИМС, требуется, чтобы ЛИМС была повторно валидирована. Усилия при повторной валидации не должны быть настолько же значительными, как усилия при первоначальной валидации, при условии, что изменения по своему характеру являются незначительными.
Приложенные усилия могут быть облегчены путем использования некоторых из первичных протоколов испытаний, полученных в процессе успешной первоначальной валидации. Проекты и количество документации изменяются в зависимости от организации, поскольку каждая из них имеет собственные СОП для контроля изменений. Пользователь может проектировать сокращенную версию первоначального плана валидации ЛИМС.
10.1.6Периодические аудиты
Организация должна проводить периодические аудиты ЛИМС, имеющейся в их распоряжении. С помощью данных аудитов проверяется (верифицируется), соблюдается ли при функционировании ЛИМС соответствие установленным принципам и процедурам. Данные аудиты обычно не выполняются персоналом ЛИМС или лаборатории. Как правило, они осуществляются уполномоченным персоналом подразделений по обеспечению качества (QAU). Поскольку эти аудиты не являются частью прямых обязанностей менеджера ЛИМС, это лицо не должно быть ответственным за поддержание ЛИМС в валидированном состоянии. К самым большим проблемам при проведении аудита данного типа относятся: процедуры безопасности; журналы регистрации ошибок и обслуживания; процедуры контроля изменений; записи при проведении обучения; журналы по эксплуатации, если таковые используются; процедуры резервирования и восстановления; процедуры аварийного восстановления и процедуры управления документацией.
11 Документация
(ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9004, ГОСТ Р ИСО 10005, ГОСТ Р ИСО/МЭК 14764*)
11.1Имеется большое количество типов документов, связанных с валидацией. Каждый документ должен быть контролируемой версией, чтобы гарантировать, что пользователи могут определить конкретные версии, которые они использовали в процессе валидации.
11.2Документация по валидации должна включать следующие документы, но не ограничиваться ими:
11.2.1План валидации (см. приложение Х2)
Основной план, который обрисовывает в общих чертах должности, обязанности и направление деятельности, которым будет следовать команда по валидации.
11.2.2Функциональные требования
Требования, которым, как ожидается, будет соответствовать ЛИМС. Это - ключевой, наиболее существенный документ, используемый в процессе валидации ЛИМС (см. 11.5 для ознакомления с деталями).
11.2.3Документы приемочного испытания систем предварительной валидации
Эти документы могут использоваться для определения действий по валидации ЛИМС, основанных на документе с функциональными требованиями. В этом случае различие состоит в том, что функциональные требования не испытываются так же строго, как в обычной протокольной среде испытания.
11.2.4Полные спецификации системы (схемы базы данных, схемы интерфейса пользователя, монтажные схемы и т.д.).
11.2.5Документы протоколов квалификации монтажа и функционирования (см. приложение Х2)
Эти документы включают большое количество действий по валидации. В каждом случае целью является проект протокола испытания, согласно которому испытываются одно или более функциональных требований. Каждый набор тестов должен содержать то, что пользователь рассматривает в качестве критериев приемки для данного этапа испытания.
11.2.6Протоколы испытаний (см. приложение ХЗ)
Протоколы испытаний являются частью документа по квалификации монтажа и функционирования (IQ/OQ). Согласно каждому протоколу испытания будут проверяться одно или более функциональных требований. Все приложения протокола испытания, т.е. твердые копии изображения на экране дисплея, отчеты в бумажном виде и т.д., становятся частью пакета документов IQ/OQ.
11.2.7Стандартные операционные процедуры (СОП) - см. 11.4.
11.2.8Руководство по системе ЛИМС.
11.2.9Заключительный отчет по валидации - квалификационный отчет (см. приложение Х4)
Этот отчет завершает выполнение плана валидации, который был выполнен. Должны быть документированы любые ограничения системы, определенные в процессе выполнения ассоциированных протоколов испытания. Необходимо сделать запись формального решения для принятия системы с соответствующей подписью. Должны быть отмечены те случаи, когда приемка совершается для ограниченной эксплуатации из-за неудачного проведения некоторых испытаний. Необходимо документировать, каким образом нужно управлять конкретными ограничениями.
11.2.10Ниже приводится другая сопроводительная документация, которую пользователь может пожелать включить в отчет:
11.2.10.1Все заказы на поставку, связанные с приложением ЛИМС, аппаратными средствами, программным обеспечением, консультационными услугами и т.д.
11.2.10.2Сообщение о статусе аудита продавца.
11.2.10.3Соглашение об условном депонировании для исходного кода ЛИМС.
11.2.10.4Требования по обслуживанию исходного кода для любой внутренней работы по настройке.
11.2.10.5Структурная документация по испытанию исходного кода.
11.2.10.6Контракт по обслуживанию и соглашение о поддержке.
11.2.10.7Записи обучения пользователя и администратора ЛИМС.
11.2.10.8План по внедрению ЛИМС.
11.2.11У пользователя должна быть следующая дополнительная документация для работы по настройке:
11.2.11.1Разработка жизненного цикла системы.
11.2.11.2Программирование стандартов и согласующих документов.
11.2.11.3Отчеты по управлению конфигурацией, созданные в процессе разработки системы.
11.2.11.4Документированное свидетельство испытания исходного кода.
11.2.11.5Процедуры для выпуска системы от фазы разработки до фазы валидации.
11.2.11.6Документированное свидетельство, подтверждающее соответствие прописанным процедурам.
11.2.11.7Процедура для рассмотрения проблем, найденных после того, как система была внедрена.
11.3Стратегии документирования
Существует несколько схем для прослеживания протекания процесса валидации.
11.3.1Все действия должны быть документированы, в особенности те испытания, которые были проведены неудачно и должны быть впоследствии повторены.
11.3.2Может быть сохранен журнал регистрации, где все испытания зарегистрированы в хронологическом порядке по всем результатам и местоположениям. При каждом входе должна быть сделана запись: когда проведено испытание, кто его сделал, какие результаты были получены и как были решены проблемы.
11.3.3Может быть создан протокол, открывающийся, когда начинается каждое испытание. Если испытание прошло неудачно, протокол должен быть закрыт с неудовлетворительными результатами. После исправления (ремонта) может быть открыт новый протокол для этого испытания и испытание повторено.
11.4Стандартные операционные процедуры, характерные для функционирования ЛИМС
11.4.1СОП должны быть установлены для того, чтобы гарантировать, что организация имеет достоверно определенные процедуры. Количество, проект и фокус СОП будут значительно изменяться в зависимости от организаций и приложений ЛИМС. В зависимости от того, работает ЛИМС на сервере или на автономном персональном компьютере, организации понадобятся различные СОП для каждого варианта. Следующий список дает представление об основных СОП, которые организации могут пожелать разработать. Пользователь данного стандарта должен иметь в виду, что список, представленный ниже, не является окончательным или обязательным.