ГОСТ Р 54360-2011. Национальный стандарт Российской Федерации. Лабораторные информационные менеджмент-системы (ЛИМС). Стандартное руководство по валидации ЛИМС

(утв. и введен в действие Приказом Росстандарта от 20.07.2011 № 190-ст)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЛАБОРАТОРНЫЕ ИНФОРМАЦИОННЫЕ МЕНЕДЖМЕНТ-СИСТЕМЫ (ЛИМС)

СТАНДАРТНОЕ РУКОВОДСТВО ПО ВАЛИДАЦИИ ЛИМС

Laboratory information management systems (LIMS). Standard guide for validation of LIMS

ASTM E 2066:2007 Standard Guide for Validation of Laboratory Information Management Systems (MOD)

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения».

1. Подготовлен ФГУП «Всероссийский научно-исследовательский центр стандартизации, информации и сертификации сырья, материалов и веществ» на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4.

2. Внесен Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент».

3. Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 20 июля 2011 г. № 190-ст.

4. Настоящий стандарт является модифицированным по отношению к международному стандарту АСТМ Е 2066:2007 «Стандартное руководство по валидации лабораторных информационных менеджмент-систем» (ASTM E 2066:2007 «Standard Guide for Validation of Laboratory Information Management Systems»). При этом:

1. разделы 1, 3 - 13 и Приложения X1 - X6 полностью идентичны, а Приложение ДА дополняет их с учетом потребностей национальной экономики Российской Федерации и/или особенностей российской национальной стандартизации;

2. в раздел 2 не включены отдельные отмененные без замены нормативные ссылки применяемого международного стандарта. Указанные нормативные ссылки, не включенные в основную часть настоящего стандарта, приведены в дополнительном Приложении ДБ. Также исключены ссылки на международные стандарты и другие документы, носящие справочный характер и не действующие в Российской Федерации, а вместо ссылок на международные стандарты используются ссылки на стандарты Российской Федерации;

3. дополнительные нормативные ссылки, включенные в текст настоящего стандарта и заменяющие ранее отмененные ссылки применяемого международного стандарта, выделены курсивом.

Наименование настоящего стандарта изменено относительно наименования указанного стандарта ASTM для приведения в соответствие с ГОСТ Р 1.5-2004 (пункт 3.5).

5. Введен впервые.

Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет.

1.1. Настоящий стандарт описывает подходы к осуществлению процесса валидации лабораторных информационных менеджмент-систем (ЛИМС).

1.2. Настоящий стандарт используется для валидации коммерческих ЛИМС, приобретенных у продавца. Процедуры могут быть применены для других типов компьютерных информационных систем, однако настоящий стандарт не претендует на рассмотрение всех проблем других типов систем. Настоящий стандарт может быть использован для ЛИМС собственного производства, то есть для тех ЛИМС, которые разработаны специально для данной организации внутренним персоналом программистов или программистами, не входящими в штат данной организации («внутренние» и «внешние» программисты). Необходимо отметить, что имеется множество взаимосвязанных проблем при разработке программного обеспечения, которые не рассматриваются в этом стандарте. Пользователи, которые подключают к разработке ЛИМС «внутренних» или «внешних» программистов, должны также использовать в работе соответствующие нормативные документы и стандарты ASTM (American Society for Testing and Materials), ISO (International Organization for Standardization) и IEEE (Institute of Electrical and Electronics Engineers) по разработке программного обеспечения.

1.3. Данный стандарт предназначается для того, чтобы обучить заинтересованных лиц процессу валидации ЛИМС, предоставить стандартную терминологию, используемую при обсуждениях с независимыми консультантами по валидации, а также обеспечить руководство при разработке планов валидации, планов испытаний, требуемых стандартных операционных процедур и заключительного отчета по валидации.

2.1 В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р ИСО/МЭК 12207-1999 Информационная технология. Процессы жизненного цикла программных средств (ИСО/МЭК 12207:1995, IDT)

ГОСТ Р ИСО/МЭК 14764-2002 Информационная технология. Сопровождение программных средств (ИСО/МЭК 14764:1999, IDT)

ГОСТ Р ИСО/МЭК ТО 15271-2002 Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств) (ИСО/МЭК ТО 15271:1998, IDT)

ГОСТ Р ИСО 9000-2008 Системы менеджмента качества. Основные положения и словарь (ИСО 9000:2005, IDT)

ГОСТ Р ИСО 9001-2008 Системы менеджмента качества. Требования (ИСО 9001:2008, IDT)

ГОСТ Р ИСО 9004-2001 Системы менеджмента качества. Рекомендации по улучшению деятельности (ИСО 9004-2000, IDT)

ГОСТ Р ИСО 10005-2007 Менеджмент организации. Руководящие указания по планированию качества (ИСО 10005:2005, IDT)

ГОСТ Р ИСО 10006-2005 Системы менеджмента качества. Руководство по менеджменту качества при проектировании (ИСО 10006:2003, IDT)

ГОСТ Р ИСО 10007-2007 Менеджмент организации. Руководящие указания по управлению конфигурацией (ИСО 10007:2003, IDT)

ГОСТ Р ИСО 19011-2003 Руководящие указания по аудиту систем менеджмента качества и/или систем экологического менеджмента (ИСО 19011:2002, IDT)

ГОСТ Р 53798-2010 Стандартное руководство по лабораторным информационным менеджмент-системам (ЛИМС) (АСТМ 1578:2006)

Примечание. При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодно издаваемому информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по соответствующим ежемесячно издаваемым информационным указателям, опубликованным в текущем году. Если ссылочный стандарт заменен (изменен), то при пользовании настоящим стандартом следует руководствоваться заменяющим (измененным) стандартом. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3.1 Определения

В настоящем стандарте применена терминология, используемая при валидации компьютерных систем. Стандарты, перечисленные в разделе 2, предоставляют дополнительные определения, с которыми читатель может ознакомиться перед началом процесса валидации.

3.1.1. Критерий приемки (acceptance criteria): спецификация, используемая для того, чтобы принимать или браковать компьютерную систему, приложение, функцию или проведение испытания.

3.1.2. Контроль изменений (change control): процесс, устанавливающий права авторизации, и процедуры, которые используются, чтобы управлять изменениями, совершенными в отношении компьютерной системы или системных данных, или того и другого. Контроль изменений является жизненно важной функцией программы по контролю и обеспечению качества (Quality Assurance, QA) в пределах учреждения и должен быть четко описан в стандартных операционных процедурах данного учреждения СОП (Standard Operation Procedure, SOP).

3.1.3. Управление конфигурацией (configuration management): порядок, применяющийся для технического и административного руководства и надзора за идентификацией и документированием функциональных и физических характеристик конфигурируемого пункта, для контроля изменений этих характеристик, для записи и отчета об изменениях статуса при внедрении, а также для верификации соответствия специфическим требованиям.

3.1.4. Настройка (customization): процесс добавления нового программного обеспечения или изменения ЛИМС таким образом, чтобы было возможно оперировать функциями, не запланированными в исходном проекте системы. Настройка принуждает к созданию нового программного обеспечения, соответствующего программным и связанным модулям для того, чтобы произвести новые исполнительные программы. Если действия предприняты продавцом, они могут быть утверждены и валидированы как часть системы продавца.

3.1.5. Поставляемая система (delivered system): поставляемая система — это ЛИМС, изначально доставленная продавцом до момента добавления каких-либо статических конфигурационных данных. В некоторых случаях продавец может заключить контракт с лабораторией на ввод некоторых конфигурационных данных по поручению лаборатории, и в таком случае поставленная система будет рассматриваться как стандартная до тех пор, пока не будет добавлена специфическая для заказчика информация. В то время когда продавец выполняет эту работу, уполномоченные лица лаборатории и заказчик должны рассмотреть, соответствует ли данная работа локальным требованиям к валидации, приведенным в разделе 7.

3.1.6. Динамическое испытание (dynamic testing): реальное испытание различных функций и процедур с использованием программного обеспечения ЛИМС в процессе эксплуатации.

3.1.7. Квалификация монтажа (Installation Qualification, IQ): документированное подтверждение (верификация) того, что все ключевые аспекты монтажа полностью соответствуют утвержденным концепциям проекта, как это определено в спецификациях системы, и что рекомендации производителей рассмотрены соответствующим образом.

3.1.8. ЛИМС (Laboratory Information Management System, LIMS): лабораторная информационная менеджмент-система относится к классу программных продуктов, предназначенных для того, чтобы собирать, анализировать, создавать отчеты, хранить данные, управлять данными и обрабатывать информацию, полученную в лаборатории.

3.1.9. Загрузка данных в ЛИМС (конфигурирование) [LIMS data loading (configuration)]: процесс ввода статистических данных в соответствующие структуры данных, типа записей в таблицы или базу данных, чтобы сделать ЛИМС подходящей для эксплуатации в конкретной лаборатории. Эта информация может включать такие пункты, как наименования и адреса лабораторий заказчиков, сведения о лабораторном персонале, описание испытаний, выполняемых в лаборатории, спецификации, вычисления, шаблоны или описание отчетов ЛИМС и т.д. В течение этого процесса не добавляются какие-либо новые функциональности, которые не были изначально запланированы проектировщиком системы. Добавление конфигурационных данных может повлиять на поведение системы.

3.1.10. Адаптация ЛИМС для решения определенных задач (LIMS tailoring): см. загрузка данных в ЛИМС (конфигурирование).

3.1.11. Квалификация функционирования (Operational Qualification, OQ): документированное подтверждение того, что каждая единица или вся система работает так, как предназначено на протяжении всего времени функционирования.

3.1.12. Подразделение по обеспечению качества (Quality Assurance Unit, QAU): организация (подразделение), включающая уполномоченных лиц, ответственных за проект и интерпретацию стандартов по качеству, таких как процедуры и процессы валидации (но не за испытание продукта).

3.1.13. Исходный код (source code): компьютерная программа, выраженная в удобной для восприятия человеком форме (язык программирования), которая переводится в машиночитаемую форму (объектный код) перед тем, как она может быть испытана с использованием компьютера.

3.1.14. Статическое испытание (static testing): структурированное рассмотрение исходного кода.

3.1.15. Тестирование в предельных режимах, стресс-тестирование (stress testing): проверка протоколов испытаний, созданных для испытаний ЛИМС в условиях предельных, критических режимов.

3.1.16 План испытания (test plan): см. протокол испытания.

3.1.17. Протокол испытания (test protocol): процедура, в процессе которой проводят запись и описание ряда действий и ожидаемых результатов и которая, когда завершено выполнение испытания, обеспечивает документальное свидетельство того, что специфические функциональные требования ЛИМС реализуются так, как предписано.

3.1.18. Валидация (validation): процесс учреждения документированного подтверждения на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены, декларируемые свойства и характеристики подтверждаются, а поставленная цель (предназначение системы, комплекса, устройства и т.д.) достигнута.

3.1.19. План валидации (validation plan): документ, который определяет все системы и подсистемы, включенные в объем работ по конкретной валидации, а также подходы, с помощью которых они квалифицируются и валидируются, включая определение обязательств и предположений.

3.1.20. Команда по валидации (validation team): группа лиц, ответственных за процесс валидации. Эта команда может состоять из представителей лаборатории, подразделения по обеспечению качества (QAU), организаций в области систем по управлению информацией (Management Information System, MIS) или других сторонних консультантов.

3.1.21. Аудит продавца (vendor audit): независимое рассмотрение и экспертиза системы отчетов и действий, для того чтобы проверить адекватность и эффективность процедур по обеспечению безопасности и целостности данных, гарантировать соответствие установленным методам и эксплуатационным процедурам и рекомендовать любые необходимые изменения.

3.1.22. Команда по аудиту продавца (vendor audit team): команда, состоящая из лиц, которые обладают знаниями, пригодными для проектирования компьютерных систем, а также в области методов аудита, методов квалификации компьютерной системы, соблюдения нормативных требований, методов валидации, методов и процедур в области деловой и правовой активности (применимы только для приобретения компьютерных аппаратных средств и программного обеспечения и связаны с их обслуживанием).

3.1.23. Контроль версий (version control): контроль всех связанных версий программного обеспечения и документов. Он также включает все документы, связанные с внедрением, валидацией или эксплуатацией ЛИМС.

4.1. Валидация является важной и обязательной деятельностью для лабораторий, которые подпадают под пристальное внимание регулирующих агентств. Такие лаборатории производят данные, от которых зависит управление действиями для проведения в жизнь законов и принятия решений в интересах общества. Примерами могут служить данные, используемые для того, чтобы поддерживать утверждение новых лекарственных средств, доказывать, что продаваемые лекарственные средства соответствуют спецификациям, проводить в жизнь экологические законы и разрабатывать свидетельства для судебных процессов. Это также распространяется на ЛИМС, используемые в экологических лабораториях. В некоторых случаях эти системы могут понадобиться для того, чтобы имелась возможность взаимодействия клинической ЛИМС (clinical LIMS) с системой компьютерного учета пациентов (Clinical Patient Records, CPR) для сообщения о влиянии окружающей среды и проведения клинико-лабораторных испытаний для биологических измерений влияния стресс-факторов. Огромное финансовое, юридическое и социальное воздействие этих решений требует государственной и общественной уверенности в лабораторных данных. Чтобы гарантировать эту уверенность, государственные агентства регулярно проводят экспертизу лабораторий, работающих в соответствии с их правилами для подтверждения того, что они производят действительно достоверные данные. Валидация компьютерной системы является частью этой экспертизы. Данный стандарт создан для помощи пользователям при валидации ЛИМС и включения процесса валидации в жизненный цикл ЛИМС.

4.2. Валидация должна предоставить свидетельство о процессах испытания, обучения, аудита и рассмотрения, об административной ответственности, управлении проектом и документами в процессе развертывания системы и на протяжении ее эксплуатации.

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 10005, ГОСТ Р ИСО 10006, ГОСТ Р ИСО 10007, ГОСТ Р ИСО 19011, ГОСТ Р 53798)

5.1. Процесс валидации должен запускаться на начальной стадии жизненного цикла ЛИМС, как это определено в ГОСТ Р 53798. Проведение валидации в конце внедрения ЛИМС могло бы добавить от 3 до 12 месяцев ко времени проектирования ЛИМС. Добавление валидации в конце процесса внедрения ЛИМС препятствовало бы организации использовать ЛИМС в течение валидации. На рисунке 1 представлены пункты, где валидация может воздействовать на приобретение ЛИМС. Валидация не должна воздействовать на весь жизненный цикл ЛИМС, и количество взаимодействий с командой по валидации будет варьироваться в течение каждой фазы жизненного цикла.

5.1.1 Фаза формирования команды по валидации

Эта фаза обычно не является отдельной фазой жизненного цикла ЛИМС, однако является критической частью процесса валидации. Типичная команда состоит из представителей лаборатории, групп специалистов от организаций по системам управления информацией (MIS) и подразделений по обеспечению качества (QAU). Могут быть и другие члены команды, в зависимости от объема проекта и ресурсов организации. Если потребуется, определенные члены команды по валидации должны начать в это время организацию учебных курсов по валидации компьютерных систем. Никакого обучения не должно проводиться до тех пор, пока те, кто был отобран для команды валидации, не получат от своего руководства полного согласия на участие в этой деятельности. Эти курсы могут быть разработаны или внутренними, или внешними специалистами. Команда по аудиту продавца может состоять только из команды по валидации или это может быть специальная группа в пределах организации. Рекомендуется, чтобы команда по аудиту продавца включала организационных участников из структур по обеспечению качества (QAU), систем управления информацией (MIS) и лаборатории.

5.2 Фаза определения требований к бизнес-процессам

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9004, ГОСТ Р ИСО 10005, ГОСТ Р 53798)

Организационная единица, а именно лаборатория, должна связаться со специалистами по обеспечению качества (QAU), чтобы определить текущую надлежащую производственную практику (current Good Manufacturing Practices, cGMPs), надлежащую производственную практику (Good Manufacturing Practices, GMPs), надлежащую автоматизированную лабораторную практику (Good Automated Laboratory Practices, GALPs) и другие требования, которые будут рассматриваться в связи с проектом. Первоначальный выбор членов команды по валидации осуществляется в это же самое время.

5.3 Фаза подготовки проекта

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9001, ГОСТ Р ИСО 10005, ГОСТ Р ИСО 10006, ГОСТ Р 53798)

Со всеми членами команды по валидации администрация должна заключить соглашение о проведении валидации. Поскольку валидация является весьма сложным процессом и для нее может потребоваться достаточно длительное время, каждый член команды должен получить полную поддержку от своего руководства. Одним из критических факторов является необходимость в том, чтобы администрация понимала и соглашалась с обязательствами этих лиц. Без соглашения от каждого члена управленческой цепочки вероятность успешной разработки и валидации ЛИМС будет уменьшаться. После формирования команда по валидации может начать работу с рассмотрения проблем верхнего уровня, таких как создание корпоративных стандартных операционных процедур (СОП), необходимых для валидации. Ограничивающими факторами в процессе валидации могут являться временные (календарные) ограничения и неопытность членов команды. Они могут также проявиться, когда команда должна определить внешних консультантов, которые могут быть необходимы для валидации и начала разработки плана валидации. Соответствующее обучение членов команды по валидации также должно быть выполнено в течение этой фазы жизненного цикла ЛИМС.

5.4 Модель текущего состояния лабораторной практики

Обычно команда по валидации не принимает участия в этом процессе.

5.5 Модель будущего состояния лабораторной практики

Обычно команда по валидации не принимает участия в этом процессе.

5.6 Фаза разработки функциональных требований

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК ТО 15271)

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

5.7 Фаза запроса предложений (Request For Proposal, RFP)

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9001, ГОСТ Р 53798)

Команда по валидации должна гарантировать, что запрос предложений будет включать как запрос аудита продавца, так и требования к валидации. Лица, использующие этот документ для приемочных испытаний, но работающие в нерегулируемых отраслях промышленности, могут не требовать проведения процесса аудита. Кроме того, команда по валидации должна требовать, чтобы процессы и приложение ЛИМС, разработанные продавцом, были подвергнуты независимой оценке и валидации. Если другая компания, которой может являться консультационная третья сторона или иная организация, валидировала проводимые продавцом операции и процесс развертывания ЛИМС, это не означает, что потенциальный покупатель может предположить, что программное обеспечение валидировано. В течение этого времени команда по валидации должна определить, какие действия предпринимаются, если продавец ЛИМС отказывает им в праве на проведение аудита. Команда по валидации должна рассмотреть запрос предложений (RFP) до его подачи продавцу.

5.8 Фаза оценки и выбора

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9001, ГОСТ Р 53798)

Команда по валидации должна определить тех лиц, которые будут принимать участие в экспертизе продавца. Так как для этого процесса может понадобиться от одного до нескольких дней, должны будут посещаться только те производители ЛИМС, которые определяются командой ЛИМС в качестве целевых объектов. Приоритетный выбор ЛИМС должен базироваться на ответах продавца по запросу предложения (Request for Proposal, RFP). В ответах на запрос предложения обычно придается особое значение установленным функциональным требованиям. Необходимо выполнить аудит продавца, чтобы найти встроенную функцию ЛИМС по обеспечению качества. Следует продолжить аудиты продавцов, пока подходящий продавец не будет найден по обоим критериям — функции обеспечения качества и функциональным возможностям. Результаты аудита полезны для оценки того, подвергается ли покупатель риску, когда набор функциональных возможностей системы может влиять на качество развертывания системы. См. раздел 6 для более детального рассмотрения проведения аудитов продавца ЛИМС.

5.9 Приобретение ЛИМС

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9001, ГОСТ Р 53798)

Члены команды по валидации должны рассмотреть и принять участие в утверждении заказа на покупку ЛИМС, чтобы гарантировать соответствие как вопросам валидации, так и критериям, выделенным в 5.8, чтобы начать на ранних стадиях управление конфигурированием.

5.10 Фаза внедрения

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО 9001, ГОСТ Р 53798)

Команда по внедрению должна завершить подготовку плана валидации и другой документации, которые должны быть одобрены владельцем системы и уполномоченными лицами по обеспечению качества (QAU) прежде, чем план будет выполняться. Разрабатывается календарный график действий. Протоколы испытаний должны выполняться, а результаты — документироваться. Когда все протоколы испытаний будут выполнены и документированы, разрабатывается окончательный отчет по валидации, а затем получают необходимые подписи, требуемые для утверждения данного отчета. Заключительное утверждение будет получено от владельца системы, авторизованного специалистами по обеспечению качества (QAU).

5.11 Фаза эксплуатации (функционирования)

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 14764, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9004, ГОСТ Р ИСО 10007, ГОСТ Р 53798)

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

5.11.1 Текущее обучение новых пользователей.

5.11.2. Модификация стандартных операционных процедур (СОП) в случае необходимых изменений ЛИМС или среды функционирования системы.

5.11.3. Рассмотрение процедур и их строгое соблюдение в рамках существующих СОП, документирование соответствия СОП.

5.11.4. Обслуживание процедур контроля изменений для существующей системы.

5.11.5 Сопровождение системы.

5.11.6. Модернизация аппаратных средств и программного обеспечения ЛИМС. Она также включает все взаимосвязанные аппаратные средства или программное обеспечение в среде функционирования ЛИМС, к которым относятся локальная сеть (Local Area Network, LAN), компьютерная операционная система и т.п. См. фазу контроля изменений в 5.12.

5.12 Контроль изменений

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 14764, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9000, ГОСТ Р 53798)

Часто в процессе функционирования ЛИМС в обычном режиме перед менеджером ЛИМС встают проблемы контроля изменений. Менеджер ЛИМС должен понимать, что все несущественные и существенные изменения системы будут являться субъектами контроля изменений, оценки последствий и повторной валидации после имевших место изменений. Модернизация программного обеспечения, так же как изменения порядка использования системы, могут потребовать проведения повторной валидации. Комитет по контролю изменений может определить те изменения системы, которые требуются для повторной валидации. Все изменения должны быть документированы, так же как оценка необходимости валидации изменений и объем ревалидации. Уровень детализации для процесса ревалидации зависит от типа изменения. Может понадобиться новая команда по валидации. Эта команда может потребовать включить некоторые протоколы испытаний, полученные при первоначальном процессе валидации. Объем повторной валидации в значительной степени зависит от воздействия идентифицируемых изменений. Требования к изменениям и проблемам должны быть документированы (Приложение X6).

5.13 Выведение из эксплуатации или замена ЛИМС

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 14764, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9000, ГОСТ Р 53798)

Процесс начинается с момента создания новой команды по валидации.

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9000)

6.1. Промышленные инспекторы требуют от лабораторий гарантий того, что такие компьютерные приложения, как ЛИМС, валидированы. Владельцы лаборатории несут ответственность за демонстрацию того, что определенные приложения разрабатываются, испытываются, эксплуатируются и обслуживаются согласно общепринятой практике в области качества.

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

6.3. Организация может изъявить желание провести процедуры аудита продавца силами третьей стороны (аутсорсинг), когда она нуждается в организационной экспертизе, рассматривая этот вариант как более эффективный с точки зрения затрат, или когда организация нуждается в более объективном или всестороннем аудите. Результаты аудита, полученные от третьей стороны, не связанной с организацией пользователя, или выполненные другой корпорацией, не могут быть использованы в качестве замены аудита продавца. Альтернативно аудит, который проводится совместно консорциумом корпораций, рассматривает конкретные приложения продавца, которые использовались в прошлом с одобрения уполномоченного органа.

6.4. Оценка продавца должна происходить в течение фазы «оценки и выбора» жизненного цикла ЛИМС и перед окончательным выбором продавца. Если организация уже создала команду по аудиту продавца, эта группа должна рассмотреть требования к функциональностям системы вместе с командой по валидации ЛИМС. Если организация не имеет созданной подобной команды, она может изъявить желание, чтобы члены команды по валидации ЛИМС выполняли аудит продавца. Команда по аудиту должна состоять из опытного аудитора программного обеспечения, внутреннего или внешнего по отношению к компании, и одного или более лиц из команды ЛИМС. Как правило, ответственным за долгосрочное взаимодействие с продавцом должен быть кто-то из команды по аудиту. Обычно это лицо является владельцем системы или приложения.

6.5. Первичная цель аудита состоит в том, чтобы гарантировать, что программное обеспечение и процедуры управления продавца соответствуют общепринятым методам, то есть тем, которые поддерживают прослеживаемость вплоть до контрольной точки и которые придерживаются этих методов. Это означает, что команда по аудиту должна оценить, какие меры предпринимает продавец в отношении качества, которое влияет на продаваемый продукт, и поддержки качества, которую он будет обеспечивать в дальнейшем. Команда по аудиту может столкнуться с этой задачей при сборе свидетельств, которые демонстрируют, что продавец ЛИМС придерживается вполне определенной и документированной практики разработки программного обеспечения и стандартов или методов обслуживания.

6.6. В дополнение к этим задачам организация, проводящая аудит, должна оценить финансовое состояние и стабильность продавца. Следует отметить, что даже если организация продавца ЛИМС зарегистрирована в соответствии с национальными или международными требованиями, например ГОСТ Р ИСО 9001, продавец не освобождается от проведения аудита заказчиками. По-прежнему закупочная организация ответственна за проведение аудита предполагаемого продавца ЛИМС. См. рисунок 2, основанный на Руководстве GAMP 96, в котором описывается схема процесса аудита.

6.7. Оценка продавца должна охватывать развертывание программного обеспечения, обслуживание программного обеспечения и проблемы качества и контроля. Ключевые области, которые должны быть отмечены для инспектирования, включают документацию, которая поддерживает испытание системы, профилактическое обслуживание, инструкции (руководства) по эксплуатации и обслуживанию и административные процедуры. Процесс обзора исходного кода должен быть ограничен случайной выборкой из модулей исходного кода, который выбирает заказчик. Каждый пункт должен оцениваться согласно способности продавца соответствовать конкретным пунктам аудита. Например, значительное расхождение с отмеченными требованиями к аудиту указывает на то, что продавец не соответствует вообще или соответствует в небольшой степени некоторым пунктам или областям аудита. Незначительное расхождение с отмеченными требованиями указывает на то, что продавец имеет некоторое соответствие пунктам аудита. Как стандарты серии ИСО 9000, так и стандарты серии IEEE детализированы и могут быть использованы для создания индивидуализированных контрольных списков. Важно помнить, что имеется много различных способов достигнуть соответствия, и аудитор должен заботиться о том, чтобы понять, как работает компания, подвергаемая аудиту, и сравнивать ее со стандартом, вместо того чтобы сравнивать с собственной системой качества. См. Приложение X1 для краткого просмотра пунктов программного обеспечения, которые должны быть исследованы.

6.8. Организация должна иметь установленные корпоративные аудиторские руководства, описывающие в деталях процедуры, которых должна придерживаться команда по аудиту продавца. Эти процедуры должны охватывать все действия от первоначального контакта до заключительной встречи с продавцом. Полный цикл проведения аудита может быть разделен в целом на четыре стадии: предварительный аудит, детальный аудит, последующие аудиты и надзорный аудит. Каждая из этих стадий имеет свое место в полном процессе аудита (ГОСТ Р ИСО 9001, ГОСТ Р ИСО 19011).

6.8.1 Предварительный аудит (действия по предварительному аудиту)

Целью этой стадии является сбор достаточного числа документированных свидетельств, чтобы определить, требуется ли детальный аудит. Инструментом, используемым для проведения данной стадии аудита, является типичный опросный лист (анкета). Опросный лист может быть подразделен на основные проблемные области, такие как общая корпоративная справочная информация, информация о продажах приложений ЛИМС (конкретных версий), процедуры при разработке и развертывании программного обеспечения продавца (жизненный цикл программного обеспечения — Software Development Life Cycle, SDLC) и история разработки продукта. Существенным является то, что покупатель должен запросить заранее, чтобы продавец поставлял те стандарты, процедуры и планы, которые связаны с исследуемым приложением ЛИМС. Команда по аудиту должна обратить внимание на технические стандарты, инструкции или руководства, охватывающие следующее: методологии разработки; методы проверки ПО по обеспечению качества; процедуры контроля изменений; процедуры по управлению конфигурацией; процедуры по обучению персонала; пользовательская документация по поддержке; процедуры при проведении испытаний; технические методы просмотра; процедуры безопасности.

6.8.2 Детальный аудит

При проведении подобных аудитов организация должна учитывать все аспекты преимуществ, относящиеся к приложению ЛИМС. Команда по валидации должна планировать аудит до его фактического проведения. В плане должны быть установлены: область аудита; кто будет проводить аудит; временные (календарные) границы, согласованные с продавцом ЛИМС. В уведомлении об аудите должны быть определены цель, временные границы, целевая система, области и критерии оценки аудита. Сам процесс аудита может быть разделен на три основные стадии: вводное совещание по проведению аудита; обзор и инспекция; заключительное совещание по результатам проведенного аудита.

6.8.2.1 Вводное совещание по проведению аудита

При проведении вводного совещания устанавливаются основные правила аудита. Они могут быть перечислены в следующих пунктах, но не ограничиваются ими: представление каждого лица, привлеченного к аудиторской деятельности; область, цель, программа работы; календарный график; местоположение совещательной комнаты команды по валидации; меры, предпринимаемые для доступа к определенным документам; подписание любых конфиденциальных соглашений продавцом ЛИМС или членами команды по валидации.

6.8.2.2 Обзор и инспекция

Аудиторская команда проверяет записи продавца ЛИМС и его методы в соответствии с этими документами. Целью является установление документированных свидетельств того, что в процессе своей деятельности продавец ЛИМС придерживается процедур по обеспечению качества в течение разработки ЛИМС. Аудиторская команда может проводить аудит, используя контрольный список, основанный на выделенных областях аудита. Успешный аудитор должен использовать при проведении аудита подход «Покажите мне». Требуемая глубина охвата каждого пункта аудита варьируется, но вообще команда по аудиту должна идентифицировать один или два пункта, которые она может охватить с наибольшей детализацией. Аудиторская команда может изъявить желание проводить ежедневные сессии по сводкам, полученным при сборе сведений о ее деятельности в течение рабочего дня. В это время должны обсуждаться любые полученные наблюдения и их влияние на проблемы качества. Аудиторская команда должна также начать разработку списка для прослеживания последующих действий. Настоящий стандарт должен помочь в создании заключительного аудиторского отчета.

6.8.2.3 Заключительное совещание по результатам проведенного аудита

Ведущий член аудиторской команды должен перечислить все данные наблюдений, которые команда отметила в процессе аудита. Они должны включать как положительные результаты, так и вопросы, вызывающие озабоченность. Разъяснения продавца по данным наблюдений должны быть включены в документацию, используемую для разработки аудиторского отчета. Аудиторский отчет чрезвычайно важен, поскольку он служит документированным свидетельством аудита и полученных данных, а также принимается в качестве основания для определения корректирующих действий, которые должны быть предприняты продавцом. Также отчет должен представлять данные точно и объективно. Поскольку он относится к разряду засекреченных документов, аудиторский отчет должен быть разработан как конфиденциальный документ. Аудиторская команда должна заканчивать аудит в процессе следующих стадий:

1. ведущий аудитор составляет и представляет аудиторский отчет;

2. аудиторский отчет рассматривается аудиторской командой и руководством, а именно теми, кто будет продумывать ряд корректирующих действий;

3. продавец ЛИМС должен связаться с ведущим аудитором и продумать план для внедрения определенных корректирующих действий.

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

6.8.3 Последующие аудиты

В процессе последующих аудитов рассматриваются улучшения, достигнутые продавцом в отношении тех пунктов, которые во время предыдущего аудита были определены в качестве проблемных. Представители организации, выбирающие ЛИМС для покупки, могут рассмотреть несколько следующих вариантов, основанных на результатах аудиторского отчета:

6.8.3.1 Безусловно, следует использовать поставщика ЛИМС.

6.8.3.2. Следует использовать поставщика ЛИМС только для определенных ЛИМС-продуктов, например, конкретных версий.

6.8.3.3. Следует использовать поставщика ЛИМС только после того, как будут выполнены конкретные корректирующие действия.

6.8.3.4 Следует запретить использование продавца ЛИМС.

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

6.8.5 Надзорный аудит

Данный тип аудита сосредоточивается на недостатках, найденных в течение предыдущих аудитов, и на любых новых характеристиках или продуктах ЛИМС, например на новом модуле для исследования стабильности. Эти аудиты должны следовать тем же самым общим руководящим принципам, которых придерживались при проведении первоначального аудита. Частота проведения этих аудитов будет зависеть от результатов предыдущих аудитов и критичности проблем, которые необходимо рассмотреть.

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

6.9.1. Организация принимает на себя бизнес-риски и выполняет валидацию ЛИМС намного большего уровня и большей глубины.

6.9.2. Организация отвергает продавца ЛИМС и проводит процесс выбора альтернативного продавца ЛИМС.

(ГОСТ Р ИСО 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.

(ГОСТ Р ИСО 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 приведен в Приложении X2.

(ГОСТ Р ИСО 19011, [1 - 2])

9.1. Каждая организация должна определить, какие характеристики ЛИМС могут привлечь наибольшее внимание аудиторских агентств. Организация должна определить, какой уровень риска она готова взять на себя. Валидация каждой характеристики является слишком дорогостоящим процессом как с точки зрения ресурсов, так и времени. МакДоуэлл [2] предложил, чтобы организация подразделяла функции ЛИМС на следующие три категории: функции ЛИМС должны быть валидированы; функции ЛИМС следовало бы валидировать; функции ЛИМС могут быть валидированы.

9.1.1. Протоколы валидационных испытаний необходимы для того, чтобы определить критические функции ЛИМС, которые будут испытываться. Критические функции ЛИМС должны базироваться на основных функциях и на намеченном для использования приложении ЛИМС. Должно быть предусмотрено разумное объяснение для того, чтобы не проводить тестирование каких-либо частей ЛИМС.

9.2. Разработка и выполнение протоколов испытаний (Test Protocol, TP) в процессе валидации требуют большого количества времени. Этот факт часто игнорируется, когда разрабатывается проект плана валидации. На разработку протоколов испытаний и их выполнение влияют многие факторы. Во-первых, существенным является хорошая осведомленность о новой ЛИМС и о том, как она работает. Слабое ознакомление пользователя с ЛИМС приводит к более длительной разработке детальных протоколов испытаний. Команда по валидации должна выделить достаточное количество времени в календарном графике проектирования для персонала, разрабатывающего протоколы испытаний, чтобы он ознакомился с новой системой. Вторым фактором, влияющим на разработку протоколов испытаний, является то, насколько долго разработчик протоколов испытаний должен сосредоточиваться на проекте валидации. Недостаточная концентрация усилий по разработке протоколов испытаний добавит значительное количество дополнительных месяцев на проектирование валидации. На выполнение протоколов испытаний также существенно влияет сосредоточение внимания испытателя на выполнении протоколов испытаний. Третьим фактором, влияющим на разработку протоколов испытаний, является количество ресурсов, доступных для работы по протоколам испытаний. И последнее — уровень опыта лиц, пишущих и выполняющих протоколы испытаний, будет влиять на то, сколько времени понадобится для осуществления этих действий. По возможности в организации должен быть по крайней мере один опытный сотрудник, взаимодействующий с теми, кто разрабатывает и выполняет протоколы испытаний.

9.3. Число протоколов испытаний, необходимых для валидации ЛИМС, зависит от сложности ЛИМС и уровня деталей, требуемых для адекватного испытания ключевых характеристик. Протоколы испытаний могут быть как простыми — один или два типа инструкций для выполнения, так и сложными — несколько сотен типов инструкций. Уровень сложности будет зависеть от направления, которого придерживается организация в проекте этих протоколов испытаний. Каждая организация должна иметь организационные СОП, которые описывают, как должны разрабатываться протоколы испытаний. Проект и основные инструкции, согласно которым должны действовать испытатели и чего они должны ожидать в качестве критерия приемки, могут быть как простыми, так и очень высокого уровня. Протоколы испытаний, созданные подобным образом, обычно требуют, чтобы испытатели описали в деталях, что именно они делали. На противоположной стороне спектра находятся те протоколы испытаний, которые инструктируют испытателей шаг за шагом о том, что именно им следует делать. Протоколы испытаний, разработанные подобным способом, обычно требуют от испытателей ответить: да/нет или истинный/ложный — относительно критериев приемки. В любом случае для выполнения и документирования сложных протоколов испытаний может потребоваться несколько дней. Детали, полученные испытателем относительно каждого протокола испытания, должны быть достаточными для того, чтобы гарантировать, что функции или процессы ЛИМС, которые испытываются, находятся под контролем (Приложение X3).

9.4. В дополнение к выполнению протокола испытания команда по валидации должна предусмотреть достаточное количество времени, необходимого для рассмотрения результатов протокола испытания и решения любых конкретных проблем. Процесс рассмотрения может продолжаться почти так же долго, как выполнение протокола испытания, если испытание является чрезвычайно сложным. Количество времени, необходимое для того, чтобы выполнить этот этап валидации, часто недооценивается (занижается). Рассмотрение каждого протокола испытания необходимо для того, чтобы гарантировать, что его содержание обосновано, а протокол испытаний придерживается требований к документации в соответствии с GMP. В особенности должны быть предприняты единообразные действия относительно ошибок; испытатель должен подписать документ, поставить дату и привести причину, почему слово или группа слов были вычеркнуты. В некоторых случаях за принятие решения может быть ответственным рецензент, если протокол испытания успешно соответствует критериям приемки и, соответственно, принимается или отклоняется.

9.5. Команда по валидации должна обратиться к валидационному плану относительно того, как она будет управлять протоколами несостоятельных (ошибочных) испытаний. Это должно быть сделано перед началом испытаний. Команда по валидации также должна сначала рассмотреть то, как будут вноситься изменения в протоколы испытаний после их утверждения уполномоченными специалистами по качеству. Возникают моменты, когда испытателям необходимо произвести изменения в протоколах испытаний в период фазы выполнения протоколов испытаний. Испытателями должен быть предусмотрен способ для включения этих изменений в существующий протокол испытаний. Процедура должна быть утверждена уполномоченными лицами по качеству и включена в план валидации. Является существенным, чтобы дающаяся испытателю свобода была использована для дальнейшего проектирования и следования этапам дополнительных испытаний в период выполнения протоколов испытаний. Эта свобода позволяет им исследовать, почему конкретный этап или ряд этапов не соответствует критериям приемки. Без этой свободы может быть отсрочен весь проект валидации.

9.6. Все протоколы испытаний должны быть разработаны для испытания установленных в ЛИМС характеристик или функций. Фактический проект протоколов испытаний будет изменяться в зависимости от организации. Разработчик проекта протокола испытания может изъявить желание включить некоторые или все из следующих ниже характеристик в проекте протокола испытания.

9.6.1 Информация в заголовке протокола испытания

Эта секция содержит название корпорации, использующей ЛИМС, наименование отдела владельца ЛИМС, дату разработки протокола испытания, мотивировку, если протокол испытания предназначен для уполномоченных лиц по квалификации монтажа или функционирования, номер пересмотра протокола испытания и информацию о том, какая система испытывается (например, «ABC» ЛИМС, версия 7.1).

9.6.2 Идентификационный номер протокола испытания

Каждый протокол испытания должен иметь уникальный идентификационный номер. Этот номер является уникальным лишь для связанного с планом валидации протокола испытания.

9.6.3 Цель

Протоколы испытаний разработаны для того, чтобы проводить различные испытания. Например, цель состоит в том, чтобы подтвердить, что информация о новых пользователях может быть добавлена, модифицирована или удалена из ЛИМС.

9.6.4 Требования при проведении испытаний

Имеются функциональные требования, которые испытываются по протоколу испытания. Протокол испытания может быть разработан для более чем одного функционального требования. Любое функциональное требование, которое не было включено в план валидации, не должно быть включено в разработку протоколов испытаний.

9.6.5 Специальные потребности или требования

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

9.6.6 Процедуры этапов испытания

Каждый этап испытания должен включать номер этапа, процедуру испытания и критерии приемки для этого этапа. Каждый этап испытания должен быть градуирован в соответствии с одной из трех категорий: испытание в обычных условиях (normal testing); испытание в предельных режимах (stress testing); испытание надежности (robustness testing). На этапах испытания в обычных условиях проверяется функция ЛИМС с использованием всех общих пользовательских команд. Этапы испытаний, которые проверяют функцию в ее границах, являются испытаниями в предельных режимах (нагрузочными испытаниями). Примером может являться введение 20 символов в 20 символьных полей. Испытание надежности (устойчивости) представляет собой испытание характеристик за пределами их границ. Например, пароль пользователя может принимать только текстовые знаки или числа, однако испытатель отдает распоряжение для введения специальных знаков или знаков пунктуации для недавно созданного пароля пользователя. Испытатели должны определить, прошел ли этап испытания критерии приемки. Обычно это выражается простым утверждением: да/нет.

9.6.7 Раздел комментариев

Данный раздел используется испытателями для введения их комментариев по поводу любых неожиданных результатов, полученных в процессе выполнения протокола испытания. Пользователи также могут отмечать, как эти неожиданные результаты объясняются.

9.6.8 Завершение работы испытателя

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

9.6.9 Завершение работы рецензента

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

9.6.10 Приложения

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

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

9.8. Члены команды по валидации могут использовать несколько подходов для решения задач по проектированию и испытанию внедрения ЛИМС. Команда по испытаниям может выразить желание включить следующие дополнительные варианты подходов в проект протоколов испытаний:

9.8.1. Управление поставляемыми продавцом диагностическими тестами (поставляемый комплект компонентов/тестов нуждается в валидации перед их использованием).

9.8.2. Управление автоматизированными средствами испытания, если они доступны, конкретной ЛИМС (поставляемый комплект компонентов/тестов нуждается в валидации перед их использованием).

9.8.3. Регистрация результатов вручную, наряду с ЛИМС, для данного периода времени и сравнение результатов.

9.8.4. Если у ЛИМС имеется телефонный доступ, основательно проверяются меры безопасности, связанные с телефонной связью.

9.8.5. Следует ввести ошибки преднамеренно и определить, идентифицирует ли их система должным образом или отклонит их.

9.8.6. Следует нагрузить систему искусственно и полностью заполнить ее данными или работать с многими действиями сразу.

9.8.7. Если функционирование происходит в среде Windows, то, например, следует открыть все окна сразу.

9.8.8 Следует запланировать загрузки больших массивов информации.

9.8.9. Следует испытать безопасность путем попытки прерывания или использования запрещенных функций. Следует рассмотреть скрытые алгоритмы входа.

9.8.10. Следует попытаться прервать вход, чтобы посмотреть, будет ли система вести себя особым образом.

9.8.11. Следует визуально осмотреть интерфейсы и другие компоненты системы, которые производят существенные действия.

9.8.12. Следует изменять последовательность загрузки автоматизированных инструментов.

9.8.13. Для полноты исследования следует рассмотреть каждый выводящий экран, исправить данные в каждом поле и четко следовать спецификации.

9.8.14. Следует использовать технику захвата экрана или технику одновременного нажатия клавиш, чтобы рассмотреть работу системы.

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

9.8.16. Следует отключить источник питания от инструментов, связанных интерфейсами, от серверов и других частей системы.

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

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

(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 14764, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 10006, ГОСТ Р ИСО 10007, ГОСТ Р ИСО 9001, ГОСТ Р 53798)

10.1. После того как ЛИМС будет валидирована, начинается эксплуатационное обслуживание системы. На этом этапе члены команды по валидации могут быть распущены. С этого момента лица, ответственные за ежедневную работу системы, должны быть ответственны за поддержание ее в валидированном состоянии. К критическим проблемам, с которыми сталкиваются организация и, что еще более важно, менеджер ЛИМС, относятся следующие:

10.1.1 Управление конфигурацией ЛИМС (ГОСТ Р ИСО 10006, ГОСТ Р ИСО 10007)

Цель управления конфигурацией состоит в том, чтобы гарантировать, что определяются и контролируются любые изменения в компьютерном оборудовании, программном обеспечении, сетевых характеристиках, кодах ЛИМС или в любом другом компоненте, который был частью системы при проведении первоначального процесса валидации ЛИМС. Все приложения ЛИМС и платформы аппаратных средств, на которых они размещаются, со временем будут изменяться. Чрезвычайно важно, чтобы организация контролировала и документировала эти изменения. Процедуры по управлению этими изменениями подпадают под управление конфигурацией. Управление конфигурацией начинается в процессе разработки и выполнения операций по квалификации монтажа и функционирования (IQs, OQs) аппаратных средств и программного обеспечения ЛИМС. В это же время валидационная команда создает список всех аппаратных средств и программного обеспечения при монтаже (установке) и конфигурировании ЛИМС, включая номера партий, номера выпуска, серийные (регистрационные) номера и номера версии программного обеспечения. Все эти элементы составляют первоначальную конфигурацию ЛИМС. Они являются базовой совокупностью для управления конфигурацией. Дополнительными элементами, которые должны быть рассмотрены, являются DLLs (Dynamic-Link Library, динамически подсоединяемая или компонуемая библиотека, динамическая библиотека), используемые приложением ЛИМС и любым связанным с ней программным обеспечением. В этом случае пользователь должен прослеживать названия динамической библиотеки, даты установки/написания и версии. Крайне важно гарантировать, чтобы никакое другое программное обеспечение не могло изменить динамические библиотеки, используемые ЛИМС. Цель состоит в том, чтобы показать, что организация управляет ЛИМС; что, как только устанавливается первоначальная конфигурация, все изменения к ней санкционированы, проверены и зарегистрированы. В случае если ответственность за различные элементы конфигурации ЛИМС разделена с другими организационными группами, например по информационным услугам, которые поддерживают инфраструктуру сети, они должны знать, что не могут произвести изменения в своей области ответственности без первоначальной проверки менеджером ЛИМС и руководством организации.

10.1.2 Контроль изменений

То, что ЛИМС изменяются, является естественным процессом. Однако в обязательном порядке все осуществленные изменения должны пройти контроль изменений. Контроль изменений включает несколько этапов: запрос на изменение; анализ воздействия; рассмотрение/утверждение; внедрение; валидирование. Организация должна иметь СОП, описывающие процедуры, которыми сопровождаются запросы на изменения. Кроме того, организация должна иметь орган управления, контролирующий изменения, который рассматривает все предложенные средства для контроля изменений. Членство в этом органе управления изменяется в зависимости от организации. К ключевым фигурам относятся персонал подразделения по обеспечению качества (QAU), знакомый с валидацией компьютерных систем, и персонал, относящийся к различным областям бизнеса. Роль органа управления состоит в том, чтобы рассмотреть все предложенные изменения и определить, придерживается ли применяемый подход организационных или нормативных требований. Кроме того, орган управления рассматривает и оценивает воздействия изменения на функционирование ЛИМС. Готовясь принимать решение относительно требований к изменению ЛИМС, следует рассмотреть следующее: будут ли изменения обеспечивать достаточно большие преимущества, чтобы возместить время и ресурсы, необходимые для повторной валидации ЛИМС; на какие другие системы будет воздействовать изменение; сколько времени потребуется для успешного внедрения изменения; какие ресурсы должны быть доступны, чтобы осуществить изменение; какие воздействия не будут приводить к изменениям как в лаборатории, так и в организации. Кроме того, приложениями ЛИМС, которые размещены на сервере, на базе персонального компьютера (ПК), нужно управлять предусмотрительно, потому что пользователь ПК может использовать различные динамически подсоединяемые библиотеки и обновлять их версии в ЛИМС неконтролируемым способом.

10.1.3 СОП

См. 11.4 относительно деталей СОП.

10.1.4 Эксплуатационные регистрационные отчеты

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

10.1.4.1 Резервирование регистрационных данных

Этот документ обеспечивает свидетельство того, что приложение ЛИМС поддерживается в соответствии со стандартными операционными процедурами (СОП) организации. Данная регистрация должна содержать следующие пункты, но не ограничиваться ими: кто выполнил резервное копирование; время резервного копирования; уровень поддержки ЛИМС (например, полное резервирование системы, включая ЛИМС и операционную систему, постоянно хранящую ее, или частичное резервирование, где поддерживаются только справочники данных ЛИМС); где хранятся твердые копии и было ли резервирование успешным.

10.1.4.2 Регистрация ошибки и ошибочного решения

Организация должна обслуживать регистрацию ошибки и ошибочного решения. Эта регистрация помогает определять, имеются ли тенденции к ошибкам, а также обеспечивает свидетельство того, что к ошибкам обращаются сразу же после их фиксирования. Организация должна определить, может ли она справиться с ошибкой самостоятельно. Если есть способы зафиксировать ее в собственной организации, в дальнейшем организация должна связаться с продавцом ЛИМС. В любом случае организация должна сообщить о предпринятых мерах по исправлению ошибки. Когда ошибки идентифицированы как сбои (дефекты программы), организация должна получить обязательство от продавца по срокам для исправления ошибки. Эти данные должны быть зарегистрированы. Если продавец ЛИМС устанавливает, что ошибка была зафиксирована при модернизации программного обеспечения, организация должна зарегистрировать эти данные. Повторная валидация зафиксированного сбоя должна быть ключевой областью, на которую обращают внимание при проведении повторной валидации после завершения модернизации.

10.1.4.3 Регистрации при обслуживании аппаратных средств

Эти процедуры регистрации разрешают вопросы, конкретно связанные с компонентами аппаратных средств ЛИМС, включая любую связанную сетевую периферию. Пользователь должен отслеживать: номер серии/партии компонента, подлежащего замене; наименование продавца замененной платы; если известно, номер серии/партии новой части; производителя новой платы; имя наладчика в напечатанном виде и его подпись; дату, когда имела место замена; причину, по которой компонент был заменен; другие данные, которые будут полезны, чтобы устранить неполадки позже.

10.1.5 Повторная валидация

Все изменения должны быть оценены относительно их воздействия на валидацию ЛИМС. Если происходят изменения, которые воздействуют на целостность или точность данных в ЛИМС, требуется, чтобы ЛИМС была повторно валидирована. Усилия при повторной валидации не должны быть настолько же значительными, как усилия при первоначальной валидации, при условии, что изменения по своему характеру являются незначительными.

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

10.1.6 Периодические аудиты

Организация должна проводить периодические аудиты ЛИМС, имеющейся в их распоряжении. С помощью данных аудитов проверяется (верифицируется), соблюдается ли при функционировании ЛИМС соответствие установленным принципам и процедурам. Данные аудиты обычно не выполняются персоналом ЛИМС или лаборатории. Как правило, они осуществляются уполномоченным персоналом подразделений по обеспечению качества (QAU). Поскольку эти аудиты не являются частью прямых обязанностей менеджера ЛИМС, это лицо не должно быть ответственным за поддержание ЛИМС в валидированном состоянии. К самым большим проблемам при проведении аудита данного типа относятся: процедуры безопасности; журналы регистрации ошибок и обслуживания; процедуры контроля изменений; записи при проведении обучения; журналы по эксплуатации, если таковые используются; процедуры резервирования и восстановления; процедуры аварийного восстановления и процедуры управления документацией.

(ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9004, ГОСТ Р ИСО 10005, ГОСТ Р ИСО/МЭК 14764)

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

11.2 Документация по валидации должна включать следующие документы, но не ограничиваться ими:

11.2.1 План валидации (см. Приложение X2)

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

11.2.2 Функциональные требования

Требования, которым, как ожидается, будет соответствовать ЛИМС. Это ключевой, наиболее существенный документ, используемый в процессе валидации ЛИМС (см. 11.5 для ознакомления с деталями).

11.2.3 Документы приемочного испытания систем предварительной валидации

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

11.2.4. Полные спецификации системы (схемы базы данных, схемы интерфейса пользователя, монтажные схемы и т.д.).

11.2.5 Документы протоколов квалификации монтажа и функционирования (см. Приложение X2)

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

11.2.6 Протоколы испытаний (см. Приложение X3)

Протоколы испытаний являются частью документа по квалификации монтажа и функционирования (IQ/OQ). Согласно каждому протоколу испытания будут проверяться одно или более функциональных требований. Все приложения протокола испытания, т.е. твердые копии изображения на экране дисплея, отчеты в бумажном виде и т.д., становятся частью пакета документов IQ/OQ.

11.2.7. Стандартные операционные процедуры (СОП) — см. 11.4.

11.2.8 Руководство по системе ЛИМС.

11.2.9 Заключительный отчет по валидации — квалификационный отчет (см. Приложение X4)

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

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. СОП должны быть установлены для того, чтобы гарантировать, что организация имеет достоверно определенные процедуры. Количество, проект и фокус СОП будут значительно изменяться в зависимости от организаций и приложений ЛИМС. В зависимости от того, работает ЛИМС на сервере или на автономном персональном компьютере, организации понадобятся различные СОП для каждого варианта. Следующий список дает представление об основных СОП, которые организации могут пожелать разработать. Пользователь данного стандарта должен иметь в виду, что список, представленный ниже, не является окончательным или обязательным.

11.4.2 Стандартные операционные процедуры, разработанные для создания стандартных операционных процедур (СОП для СОП)

Описывается, как должны быть спроектированы СОП, включая конкретные требуемые рубрики и типы информации, кто и за что является ответственным и систему нумерации для всех корпоративных СОП.

11.4.3 Валидация компьютерной системы

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

11.4.4 Обучение

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

11.4.5 Резервирование и восстановление

Включает процедуры резервирования, использование журнала регистрации, копии с сайта, правила по хранению более ранних версий базы данных (для пропущенных ошибок) и процедуры восстановления.

11.4.6 Аварийное восстановление

Данные СОП охватывают те процедуры, которым необходимо следовать в большинстве случаев аварий, таких как пожар, наводнение, саботаж и отказ главной системы или оборудования. Эти процедуры включают определение временных (промежуточных) лабораторных операций, для того чтобы понять, как будет осуществляться деловая активность в течение потери ЛИМС. Данные СОП должны охватывать возможность возобновления деловой активности, как только ЛИМС вновь становится доступной для эксплуатации.

11.4.7 Безопасность

Включает системную политику, корпоративную политику и исполнительную политику. Минимальные правила в отношении пароля должны быть конкретизированы и установлены: максимальный срок действия пароля; избегание тривиальных паролей; кто назначает пароли; сроки годности; максимальное количество попыток перед блокировкой и регистрация доступов. Политика безопасности должна включать следующее: когда проводятся просмотры систем безопасности; кто их осуществляет; кто рассматривает результаты, как осуществляются пересмотры политики безопасности и кто назначает обязанности и права. Необходимость для безопасного физического доступа к системе также должна быть включена в СОП. Могут существовать другие процедуры, такие как блокировка клавиатуры, биологическая идентификация и т.д. В данных СОП они должны рассматриваться по мере необходимости.

11.4.8 Контроль изменений

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

11.4.9 Функционирование (эксплуатация) ЛИМС

Эти СОП должны включать политику в отношении эксплуатации, обязанностей каждого пользователя, распределенных менеджером ЛИМС для конечных пользователей. Если ЛИМС функционирует в локальной или глобальной сети, эти функции могут находиться под различным управлением. Менеджер ЛИМС и организация должны гарантировать, что СОП принимают во внимание данные проблемы, чтобы обеспечить надлежащую поддержку ЛИМС. СОП должны принимать во внимание и другие проблемы ЛИМС, такие как процедуры запуска и выключения, право собственности на поставки, решение обычных (рутинных) проблем и т.д. У некоторых организаций есть конкретные описания работы для персонала. Также на эти описания работы можно сослаться в соответствующих СОП.

11.4.10 Обслуживание

Данный пункт включает информацию о том, кто осуществлял обслуживание, когда оно было выполнено, что было сделано и какая документация должна быть создана. Эта информация должна относиться к обоим типам обслуживания — рутинному (обычному) и незапланированному. Документация также требуется для регистрации информации о том, кто утверждал завершение обслуживания, какие повторные испытания были совершены, в случае необходимости — на каком уровне были осуществлены повторная валидация и требуемое документирование. В некоторых отраслях промышленности ремонт должен следовать установленным организацией процедурам контроля изменения.

11.4.11 Использование ЛИМС

В данном пункте подчеркиваются уровни ответственности. Можно ссылаться на руководство(а) (инструкции), если они существуют, но руководства или справочники пользователя не должны быть прописаны в СОП. Следует учитывать, что те, кто использует эти СОП, должны быть обучены и знают, как использовать ЛИМС. Необязательно переписывать СОП, если проявляются системные изменения, например, если вместо «log the samples by batch» появляется «log - highlight „by batch“ and ».

11.4.12 Обработка ошибок

В данном пункте проводится рассмотрение того, как обрабатываются ошибки в ЛИМС. Могут быть разработаны отдельные СОП, или СОП могут быть включены в «Эксплуатационные СОП» ЛИМС. В любом случае ошибки ЛИМС должны быть документированы. СОП должны описать направление действий, которые должны быть предприняты пользователями ЛИМС, когда они сталкиваются с некоей проблемой.

11.4.13 Построение шаблонов статических данных

Данный пункт включает спецификации, которые используются в построении различных статических таблиц. Например, СОП могут установить, что все методы испытания будут кодироваться в ЛИМС с использованием определенной системы нумерации метода или что во всех шаблонах результатов испытания будут прослеживаться конкретные элементы данных (наименование испытания, серийный номер лабораторного портативного компьютера испытателя и т.д.).

11.4.14 Установка интерфейсов инструментов

Должно быть описано, как новые инструменты соединяются с ЛИМС, как они испытываются, как они валидируются, как они должны использоваться.

11.5 Документ, содержащий функциональные требования

11.5.1. Документ, содержащий функциональные требования, является ключевым документом в процессе валидации ЛИМС. Этот документ используется для того, чтобы гарантировать, что ЛИМС осуществляет то, что ей предписано делать, и продолжит эти действия, будучи валидированной. Этот документ должен обрисовать в общих чертах бизнес-процессы и регулирующие требования и определить их политику. Поскольку разработка документа с функциональными требованиями является обязанностью команды, работающей над проектом ЛИМС, существенно, чтобы команда по валидации ЛИМС знала и понимала, что должно содержаться в этом документе.

11.5.2. Документ, содержащий функциональные требования, должен доступным языком представить требуемые функциональности ЛИМС и проблемы эксплуатации ЛИМС. Этот документ является тем «коммуникационным устройством», которое предназначено для передачи требований продавцу ЛИМС. Кроме того, документ по функциональным требованиям помогает в разработке квалификационных документов и связанных с ними протоколов испытаний. Когда протоколы испытаний будут выполнены, они будут сравниваться с требованиями, детально описанными в этом документе.

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

11.5.3.1. Описание системы должно включать, но не ограничиваться ими, следующие пункты: основная цель, необходимые характеристики окружающей среды системы и связанные интерфейсы, критические для работы системы, а также спроектированный график завершения. Дополнительные пункты также включают словарь терминов, акронимов и сокращений, специфических для ЛИМС, и ссылки на другие корпоративные стандарты.

11.5.3.2. Ограничения системы должны включать, но не ограничиваться ими, привилегированные (предпочтительные) платформы для аппаратных средств и программного обеспечения, системные интерфейсы для других систем [лабораторных приборов, локальной сети (Local Area Network, LAN), глобальной сети (Wide Area Network, WAN)] и т.д., будущие требования к расширяемой системе, требования к окружающей среде, среднюю продолжительность эксплуатации системы, планирование требований, доступность исходного кода и требования по обслуживанию.

11.5.3.3. Требования, относящиеся к продавцу, должны включать, но не ограничиваться ими, требования к аудиту продавца, компоненты системы продавца (аппаратные средства, исходный код и т.д.), пользовательские руководства, учебные руководства, средства продавца для обслуживания ошибок, обслуживание и обучение.

11.5.3.4. Общие требования к целям и задачам обрисовываются в общих чертах в подробном информационном документе системы. Функциональности систем должны быть разделены на три основных блока: требования к входу в систему, обработке данных и выходу из системы. Каждый блок должен описывать субфункциональности, специфические для каждой области. Например, субфункциональность входа должна была бы включать требования для перемещения данных от существующей системы к новой системе ЛИМС.

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

11.5.3.6. Внедрение системы и другие требования, связанные с функционированием ЛИМС, должны охватывать потребности по поддержке и обслуживанию, вспомогательную документацию, такую как руководство пользователя, руководство администратора, а также требования к архивным и сохраненным данным.

11.5.3.7. Для настроенной ЛИМС документ с функциональными требованиями должен включать программы развития систем жизненного цикла, используемые в фазе развития систем жизненного цикла (Systems Development Life Cycle, SDLC), и требуемые элементы для каждой фазы, план по проверке качества, документацию для создания прототипа, требования к управлению конфигурацией и включенных в нее элементов, требования для контроля изменений, требуемые испытания и документацию, которая была создана в процессе испытания разработки, и требования к любой дополнительной документации для действий, осуществляемых после внедрения ЛИМС.

12.1. Организация (подразделение) по обеспечению качества (QAU) проводит или помогает в деятельности по интерпретации различных нормативных требований. Эта деятельность распространяется на проблемы, касающиеся валидации компьютерных систем, таких как ЛИМС. Дополнительные функции, имеющиеся у уполномоченных представителей подразделения по обеспечению качества, используются для того, чтобы оказывать воздействие на ЛИМС и валидацию системы ЛИМС, а также включают аудиты продавца, рассмотрение и подписание окончательного плана валидации ЛИМС, заключительный отчет по валидации, текущий мониторинг ЛИМС путем аудитов и запросов относительно контроля изменений и помощь в разработке и обслуживании СОП, относящихся к ЛИМС.

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

12.3. Команда по валидации должна иметь в своем составе уполномоченного члена подразделения по обеспечению качества (QAU) в самом начале проекта. Ранняя причастность этих лиц к проведению валидации поможет ее реализации различными способами. Во-первых, уполномоченные представители подразделения по обеспечению качества могут получить большее понимание сущности проекта ЛИМС. Во-вторых, они могут указать, какие нормативные требования необходимы при проведении работы команды. Это предоставляет команде по валидации вполне достаточное время, чтобы включить эти требования в проект плана по валидации, вместо того чтобы переделывать проект в связи с проблемами, которые могут возникнуть позже. В-третьих, как только план валидации будет создан, представитель подразделения по обеспечению качества может рассмотреть и предложить исправления к документу. Когда представители подразделения по обеспечению качества (QAU) включаются в работу при запуске проекта, команде по валидации удается лучше приспособиться к принятию календарных графиков проекта.

12.4. Также представители подразделения по обеспечению качества ответственны за текущую оценку ЛИМС. Они должны периодически рассматривать процедуры по эксплуатации ЛИМС. Цель состоит в том, чтобы гарантировать надлежащий контроль. Менеджер ЛИМС и другие специалисты должны быть осведомлены о необходимости следовать намеченным процедурам. Областями, которые привлекают наибольшее внимание представителей подразделения по контролю качества, являются те, которые непосредственно затрагивают целостность данных, их точность и безопасность. Представители подразделения по обеспечению качества должны проверять предписанные процедуры по контролю изменений и документацию после любых изменений. Регистрация ошибки и эксплуатационная регистрация должны сохраняться в данных. Требуются значительные дополнительные усилия, если обязанности по обслуживанию ЛИМС распространяются среди нескольких организационных групп (лаборатория, менеджер информационной системы для функционирования сервера, менеджер информационной системы базы данных и т.д.).

12.5 Представители подразделения по обеспечению качества (QAU) могут быть включены в следующие этапы проекта ЛИМС:

12.5.1 Определение проекта.

12.5.2 Функциональные требования.

12.5.3 Исследование продавца

Представители подразделения по обеспечению качества могут выполнить аудит продавца, чтобы гарантировать, что при разработке ЛИМС следовали надлежащим методам программного обеспечения. Они должны, по крайней мере, рассмотреть отчет об аудите продавца, если они не принимали непосредственного (фактического) участия в аудите.

12.5.4 Переговоры с продавцом

Представители подразделения по обеспечению качества могут быть привлечены к работе в том случае, когда функциональные требования добавляются, снижаются или пересматриваются. Это происходит достаточно часто, для того чтобы устранить разницу между идеальными требованиями и характеристиками, имеющимися в коммерческих («коробочных») системах.

12.5.5 Выбор продавца

Пересмотренный план валидации должен быть частью контракта с продавцом.

12.5.6 Фаза валидации

Уполномоченные представители подразделения по обеспечению качества (QAU) будут контролировать соответствие плану валидации, рассматривать заключения и утверждения. Эти процессы включают утверждение протокола валидации квалификаций монтажа и функционирования (IQ/OQ), включающего программу испытаний перед ее выполнением. Сюда же включается утверждение квалификационного отчета после выполнения протокола по квалификации монтажа и функционирования.

13. РОЛЬ АДМИНИСТРАЦИИ

13.1. Ключевой ролью администрации является передача и поддержка соответствующих ресурсов при проектировании валидации, которые включают как лабораторные, так и финансовые ресурсы. Кроме того, администрация должна помогать при определении уровня риска бизнес-процессов, который является приемлемым для организации. Администрация должна усиленно поддерживать уполномоченных представителей подразделения по обеспечению качества и привлечение их к работе с самого начала проекта ЛИМС, а также гарантировать, что все необходимые СОП находятся в наличии и что ответственные за проект валидации ЛИМС получили необходимое обучение для проведения ими работы.

13.2. Администрация может действовать как спонсор проекта с полной ответственностью за подписание проекта, которая включает ответственность за то, чтобы быть привлеченным ко всем основным пунктам принятия решений в течение проекта валидации. Администрация должна гарантировать, что надлежащие ресурсы, размещенные для обслуживания ЛИМС и любых связанных систем, находятся в валидированном состоянии. Администрация может быть призвана для решения проблем в границах организации, а также для того, чтобы гарантировать, что все лица, привлеченные к ежедневным операциям ЛИМС, осведомлены об организационных и регулирующих (нормативных) требованиях.

(ОБРАЗЕЦ ФОРМЫ)

E) Резюме разработки (резюме разработчика об испытаниях и результатах — относится к системам собственной разработки).

F) Основные инструкции (должны быть представлены подробные инструкции путем включения ссылок на то, как выполнять испытания по квалификации монтажа и функционирования IQ/OQ).

(II) Квалификация монтажа (IQ) (включает установленные документированные свидетельства о том, что ЛИМС устанавливается и конфигурируется в соответствии с целью проекта и требованиями пользователя. Квалификация монтажа IQ обычно не включает эксплуатацию системы).

G) Список и описание оборудования (список всех наиболее важных компонентов аппаратных средств и программного обеспечения с кратким описанием функций и структуры каждого из них. Этот список должен включать дату выпуска, модель и число пересмотров компонентов соответственно).

H) Технические спецификации

1. Спецификации (должны включать любые спецификации компонентов, необходимых для эффективной установки системы или подсистемы).

2. Список чертежей (блок-схемы, модели данных и т.д. — все то, что дает четкое представление о системе или подсистеме).

3. Требования к окружающей среде (обсуждаются элементы того, что существует вне ЛИМС, но необходимо для эффективной эксплуатации системы. Эти элементы должны включать требования к энергоснабжению, кондиционированию воздуха, другому программному обеспечению, другим аппаратным средствам, то есть всему тому, что необходимо для функционирования ЛИМС).

I) План и протокол испытания квалификации монтажа (IQ)

1. План и протокол испытания квалификации монтажа (здесь приводятся детали плана испытания для того, чтобы подтвердить, что ЛИМС установлена и конфигурирована в соответствии с проектом и требованиями пользователя. План испытания должен представить обоснованную инструкцию для оценки того, что задача выполнена корректно. Каждый план и протокол должны включать требование(я), подлежащее испытанию, процедуры испытания и критерии приемки для каждой процедуры испытания).

A) Калибровка

B) Первоначальные процедуры настройки

C) Инструменты испытания

(III) Квалификация эксплуатации (функционирования) (OQ) (должна включать установленные документированные свидетельства того, что ЛИМС функционирует в соответствии с предусмотренными диапазонами. Эта деятельность требует оценки ЛИМС в соответствии с динамическими эксплуатационными условиями. Не требуется повторять полную квалификацию эксплуатации при каждой новой установке, пока установка проводится в пределах первоначально квалифицированных эксплуатационных диапазонов и функциональных требований. Требуется, однако, проведение ограниченной квалификации функционирования).

J) Наиболее важные факторы (список наиболее важных факторов для ЛИМС, определенных в процессе проектирования и разработки на основании информации продавца или технических решений. Перечисленные критические факторы должны быть верифицированы в соответствии с планом испытаний).

K) План и протокол испытания квалификации функционирования или эксплуатации (OQ) (здесь должны быть приведены детали плана испытания для того, чтобы верифицировать, что ЛИМС установлена и конфигурирована в соответствии с проектом и требованиями пользователя. План и протокол испытания должны представить обоснованную инструкцию для оценки того, что задача выполнена корректно. План и протокол испытания должны определить ожидаемые результаты и критерии приемки для каждого критического фактора или функции. Испытание выполняется не только в ожидаемых границах вводимых значений и объемов (испытания в обычных условиях), но также проверяется, как ЛИМС будет реагировать на испытание эксплуатации в неожиданных или экстремальных диапазонах и условиях (испытание в предельных режимах), а также на испытание эксплуатации в заведомо некорректных диапазонах и условиях (испытание надежности и устойчивости).

(IV) Подписи (этот пункт должен включать информацию о том, кто представляет на рассмотрение план команды по валидации, персональные сведения о лицах, ответственных за рецензирование валидационного документа, и подтверждение того, что валидация была завершена корректно. Обычно эти подписи включают данные, полученные от уполномоченных специалистов организации по гарантии качества (QAU), сотрудников лаборатории, ответственных за ЛИМС, представителей группы управления информацией).

Приложение X3 (рекомендуемое)

ОБРАЗЕЦ ПРОЕКТА ПРОТОКОЛА ИСПЫТАНИЯ

ОТЧЕТ О КВАЛИФИКАЦИИ (ОБРАЗЕЦ) (НАИМЕНОВАНИЕ ПРОЕКТА ИЛИ ОБОРУДОВАНИЯ, ПОДЛЕЖАЩЕГО ВАЛИДАЦИИ) (ДАТА)

A. ЗАКЛЮЧЕНИЕ

B. ОБСУЖДЕНИЕ

(1) Соответствие протоколам квалификации монтажа и эксплуатации (IQ/OQ):

Следует привести ссылки на протокол и указать, следовали ли ему полностью или нет. Четко объясняются и документируются любые отклонения от протокола и их воздействие на систему.

(2) Результаты и критерии оценки:

Следует приложить окончательные «Протоколы испытания» к подписанным документам. Следует обсудить результаты, которые, возможно, не очевидны в плане испытаний. Следует определить системные ограничения и как ими руководить.

(3) Документация:

Следует подтвердить, что документация системы является полной и подготовленной для проведения валидации.

C. Подписи

Представлено на рассмотрение (кем): __________ для ______________ команды

Подписываясь ниже, мы указываем, что провели рецензирование приложенного «Отчета о квалификации», и подтверждаем, что протокол был последовательным, все требования к протоколу были выполнены и документированы и соответствовали критериям приемки, кроме особо отмеченных.

    _____________________________________   _______________________________
      (Имя, должность)       (Дата)           (Имя, должность)     (Дата)

Приложение X5 (рекомендуемое)

ОТЧЕТ ОБ ОШИБКАХ ПРИ ВАЛИДАЦИИ ЛИМС (ОБРАЗЕЦ)

Идентификационные данные пользователя:____________ Дата: ______________

Тип ошибки: Пользователь ____________ Программа ________ Другое _______

Оценка ошибки: Не терпящая отлагательств __________ Обычная ___________

Другое ________________________________________________________________

Количество ошибок (генерированных системой) ___________________________ _________________________________________________

Сообщение об ошибках: _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________

Описание ошибки и предложенные решения/действия:

(Дата) (Подпись)

Заполняется системным менеджером

Тип ошибки: __________________________________________________

Уровень серьезности: __________________________________________________

    Действия:            __________________________________________________
    Заключение:          __________________________________________________

┌─────────────────────────────────────────────────────────────────────────┐
│A. Заголовок: Идентификатор системы: ______ Наименование системы: _______│
│Версия: _________________________________________________________________│
<pre class="legal-pre">│B. Природа  запроса или  проблемы  (эксплуатационная/ошибочная, изменение│
│в  требованиях   к   бизнесу/технологии,   предварительное  обслуживание,│
│запрошенные   изменения,    повторное    назначение    коллег,  изменение│
│в документации или СОП и т.д.)                                           │</pre>
│_________________________________________________________________________│
│C. Дата запроса/дата проблем, с которыми столкнулись: ____/____/____     │
│_________________________________________________________________________│
│D. Лицо, запрашивающее изменение/лицо, сообщающее о проблеме: ___________│
│_________________________________________________________________________│
<pre class="legal-pre">│E. Полученные данные:                                                    │
│Эксперт-консультант: ___________________________ Дата ____/____/____     │</pre>
│_________________________________________________________________________│
<pre class="legal-pre">│F: Возможные решения:                                                    │
│         Решения               Проверка   Решение принято (кем)    Дата  │
│         _______               ________   _____________________    ____  │
│Отменить запрос/отсрочку     ____________ _____________________ ___/__/__│</pre>
│Отложить до следующей версии ____________ _____________________ ___/__/__│
<pre class="legal-pre">│Продолжить                   ____________ _____________________ ___/__/__│
│Другое (указать ниже)        ____________ _____________________ ___/__/__│</pre>
│_________________________________________________________________________│
<pre class="legal-pre">│G: Резолюция:                 Проверка всех действий                     │
│         Действия          Требуется сделать    Завершено (кем)    Дата  │
│         ________          _________________    _______________    ____  │
│Изменения  в   системе   и                                               │
│проведенные изменения (см.                                               │
│прикрепленные документы)   _________________    _______________ ___/__/__│
│Требования к модернизации/                                               │
│утверждению                _________________    _______________ ___/__/__│
│Проект        спецификаций                                               │
│к модернизации/утверждению _________________    _______________ ___/__/__│
│План             валидации                                               │
│модернизации/утверждения   _________________    _______________ ___/__/__│
│Повторная        валидация                                               │
│системы                    _________________    _______________ ___/__/__│
│Руководство   пользователя                                               │
│по           модернизации/                                               │
│утверждению/ распределению _________________    _______________ ___/__/__│
│Обучение пользователя      _________________    _______________ ___/__/__│
│СОП    по    модернизации/ _________________    _______________ ___/__/__│
│утверждению/распределению  _________________    _______________ ___/__/__│
│Продвижение      изменений                                               │
│в продукт                  _________________    _______________ ___/__/__│
│Уведомления пользователей  _________________    _______________ ___/__/__│
│Другое (указать ниже)      _________________    _______________ ___/__/__│</pre>
└─────────────────────────────────────────────────────────────────────────┘

H: Рассмотрено (кем): ________________________________________________ (сторона, несущая ответственность)

на //__________________________ (Дата рассмотрения)

Продолжение Приложения X6

Продолжение Приложения X6

Приложение ДА (справочное)

Приложение ДБ (обязательное)

СВЕДЕНИЯ ОБ ИСКЛЮЧЕННЫХ ИЗ ТЕКСТА НАСТОЯЩЕГО СТАНДАРТА НОРМАТИВНЫХ ССЫЛКАХ ПРИМЕНЕННОГО МЕЖДУНАРОДНОГО СТАНДАРТА

Таблица ДБ.1

БИБЛИОГРАФИЯ

1. ГОСТ Р 53434-2009 Принципы надлежащей лабораторной практики

2. McDowell RD. Operational Measures to Ensure Continued Validation of Computerized Systems in Regulated or Accredited Laboratories. Lab. Automat. Info. Manage. 31, 1995.

------------------------------------------------------------------