Применение принципов GLP к компьютеризированным системам

Application of GLP Principles to Computerised Systems

Содержание

1. Преамбула

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

1.1. Сфера применения и определение терминов

Определения соответствующих терминов даны в глоссарии в приложении 2.

1.1.1. Компьютеризированная система

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

1.1.2. Валидация

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

1.1.3. Квалификация

Для коммерческих доступных продуктов (Commercial Off-The-Shelf Systems, COTS), автоматизированного оборудования низкой сложности или небольших систем лучше может подойти формальная квалификация, нежели валидация. В связи с их широким использованием, встроенное программное обеспечение может считаться надежным в тех случаях, когда не было выполнено никакой заказной модификации. Допускается ссылаться на соответствующее руководство по Надлежащей производственной практике (GMP), например, приложение 15 ЕС «Руководства по Надлежащей производственной практике для лекарственных средств медицинского и ветеринарного назначения» (“Guidelines for Good Manufacturing Practice for Medicinal Products for Human and Veterinary Use”), в частности, раздел «Квалификация и валидация».
Примерами COTS низкой сложности, автоматизированного оборудования или небольших систем могут быть: аналитическое оборудование, такое как электронные пипетки, весы, фотометры и оборудование для хранения, например, холодильники, морозильные камеры и т. д.
Администрация испытательного центра должна определить и установить критерии применения к компьютеризированной системе валидационного и/или квалификационного подхода. Для определения критических параметров процесса и действий, используемых для мониторинга каждого процесса с целью обеспечения поддержания его в состоянии контроля в течение всего жизненного цикла компьютеризированной системы, должен использоваться подход на основе оценки рисков. Соответственно, он предполагает регулярное проведение обязательной калибровки и мероприятий по техническому обслуживанию, а также использование внутренних стандартов или стандартов со строго предопределенными нормами. Рекомендуется использовать статистические средства управления процессом (например, контрольные карты), а также предполагается долгосрочная прослеживаемость результатов мониторинга. Предполагается, что особое внимание и мониторинг будут уделяться контролю потока данных в местах нахождения интерфейсов взаимодействия с другими системами. В наличии должны присутствовать стандартные процедуры, точно описывающие установленный процесс и этапы контроля.
Работы по реквалификации должны выполняться через установленные интервалы времени с учетом идентифицированных рисков. Квалификационный подход должен быть подробно описан в процедурах.
Если в испытательном центре используется большое количество единиц одинакового оборудования, то можно ссылаться на уже существующие квалификационные планы и отчеты о квалификации.

1.1.4. Жизненный цикл

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

1.2. Управление рисками

Принимая во внимание необходимость обеспечения целостности данных и качества результатов исследований, управление рисками должно применяться на протяжении всего жизненного цикла компьютеризированной системы. Управление рисками состоит из идентификации, оценки, смягчения и контроля рисков. Решения касательно объема валидации и контроля целостности данных должны основываться на документированном обосновании и документированной оценке рисков. Управление рисками должно ссылаться на другие сопутствующие процедуры (например, управление изменениями и конфигурациями, процессы управления данными, риски для бизнеса и т. п.).
Оценка рисков должна использоваться для создания подходящей валидационной стратегии и для масштабирования объема валидационных работ. Объем валидационных работ должен основываться на предполагаемом использовании системы и потенциальных рисках для качества и целостности данных. На выходе процесса оценки рисков для компьютеризированной системы или функционала компьютеризированной системы должен быть подготовлен проект соответствующих валидационных работ. Надлежащее применение оценки рисков имеет первостепенное значение для формирования эффективного и действенного валидационного подхода. Если результаты оценки рисков использовать соответствующим образом, то они обеспечат администрацию испытательного центра подходящей методологией валидации как простых лабораторных систем, так и сложных лабораторных систем управления данными.
Оценка рисков компьютеризированных систем, используемых как в GLP-исследованиях, так и не в GLP-исследованиях, должна включать любое потенциальное воздействие операций, не относящихся к GLP, на операции, относящиеся к GLP. Аналогичные валидационные требования, указанные для компьютеризированных систем, применяют и к тем системам, которые используются исключительно в GLP-исследованиях. Должно соблюдаться четкое разграничение данных, относящихся к GLP, от данных, не относящихся к GLP.

1.3. Персонал, обязанности и ответственность

Принципы GLP требуют, чтобы штат испытательного центра или испытательной площадки был укомплектован квалифицированным и соответствующим образом обученным персоналом, а также наличия задокументированных программ обучения по выполнению конкретных задач, включая как обучение на рабочем месте, так и прохождение, при необходимости, учебных курсов, проводимых сторонними организациями. Записи о всех подобных курсах обучения должны сохраняться. Аналогичные требования также применяют к любому персоналу, задействованному в эксплуатации компьютеризированной системы. Для администрации испытательного центра, отдела обеспечения качества, руководителя исследования или исследовательского персонала, использующего или обслуживающего компьютеризированные системы, должны быть определены и прописаны обязанности и ответственность.
Валидация системы и эксплуатация валидированной системы по возможности должны происходить в тесном взаимодействии соответствующего персонала, например, администрации испытательного центра, руководителя исследования, сотрудников отдела обеспечения качества, сотрудников ИТ отдела и валидационного персонала. Для выполнения своих служебных обязанностей весь персонал должен обладать соответствующей квалификацией, иметь соответствующие уровни доступа и нести определенную ответственность.
Персонал, осуществляющий валидацию, эксплуатацию и обслуживание компьютеризированных систем, несет ответственность за выполнение своих операций в соответствии с принципами GLP, рекомендациями по передовым практикам и стандартами (см. «Справочные документы» в разделе 5 ниже).
В ходе валидации компьютеризированных систем и проведения GLP-исследований, обязанности и ответственность должны быть определены и контролироваться с помощью системы разграничения доступа, а также путем обучения общим требованиям GLP и их соблюдения. Записи об обучении и доступе пользователей в систему путем авторизации должны быть доступны и свидетельствовать о том, что персонал обладает необходимыми знаниями и правами доступа для выполнения их обязанностей в соответствии с требованиями GLP.
Соответствующие договора или соглашения об уровне обслуживания (Service Level Agreement, SLA) должны детально описывать требования к обучению по GLP для глобальных или корпоративных ИТ-групп или для внутренних и внешних поставщиков ИТ-услуг, которые могут осуществлять свою деятельность в соответствии с системами менеджмента качества, отличными от GLP.
Обязанности и ответственность приведены в приложении 1 (см. оригинальный документ).

1.3.1. Администрация испытательного центра

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

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

1.3.2. Руководитель исследований

Руководитель исследования несет ответственность за всецелое проведение исследований и их соответствие требованиям GLP. Руководитель исследования несет ответственность за обеспечение того, что все компьютеризированные системы, используемые в исследованиях, валидированы и используются соответствующим образом. Руководитель исследования несет одинаковую ответственность как за электронные данные, так и за данные на бумажных носителях (данные должны быть снабжены атрибутами, разборчивыми, своевременные, подлинные, правильные, полные, согласованные, стойкие/долговечные, доступные) (то есть соответствовать принципу ALCOA+ = attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available – прим. перев.). Перед началом GLP-исследования руководитель исследования должен проверить состояние валидации всех компьютеризированных систем (или системы), которые будут в нем использоваться.

1.3.3. Отдел обеспечения качества

Сотрудники отдела обеспечения качества должны быть осведомлены о наличии в их испытательном центре или на их испытательной площадке GLP-релевантных компьютеризированных систем. Обязанности отдела обеспечения качества в отношении компьютеризированных систем должны быть определены администрацией испытательного центра и описаны в документированных процедурах. Отдел обеспечения качества должен быть в состоянии проверить допустимое использование компьютеризированных систем. Программа обеспечения качества должна включать процедуры и методы, с помощью которых проверяют выполняются ли установленные нормы для всех фаз жизненного цикла системы. Задачи по проверке норм в ходе валидации, эксплуатации и обслуживания компьютеризированных систем могут быть делегированы экспертам или специалистам-аудиторам (например, системным администраторам, владельцам системы, внешним экспертам и т. п.). Сотрудники отдела обеспечения качества должны иметь соответствующий уровень подготовки и доступ, позволяющий им при необходимости инспектировать специфические компьютерные процессы (пересмотр контрольного журнала, методов анализа данных и т. п.). В ходе проведения инспекций исследований сотрудники отдела обеспечения качества должны иметь прямой доступ к данным (в режиме «только для чтения») в случае, если они доступны только в компьютеризированной системе.
Руководители исследований и сотрудники отдела обеспечения качества должны быть соответствующим образом обучены для понимания соответствующих процедур и правильного использования GLP-релевантных компьютеризированных систем.

1.4. Испытательный центр

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

1.5. Реестр

Необходимо вести и поддерживать в актуальном состоянии перечень (реестр) всех GLP-релевантных компьютеризированных систем с их функциональностью. Перечень должен включать все GLP-релевантные системы, независимо от их уровня сложности. Компьютеризированные системы, используемые в GLP-исследованиях, должны прослеживаться от плана исследования или соответствующей методики и до реестра. Реестр должен содержать информацию о состоянии валидации, изготовлении, модели или версии, в зависимости от того, что применимо, а также информацию о владельце бизнес-процесса и владельце ИТ-системы (лица, которые несут ответственность или подотчетны за систему).

1.6. Поставщик

Если поставщики (например, третьи стороны, разработчики, внутренние ИТ-подразделения, провайдеры услуг, включая хостинг-провайдеров) задействованы в поставке, установке, конфигурировании, внедрении, валидации, обслуживании, модификации, выводе из эксплуатации или поддержке компьютеризированной системы, или же участвуют в предоставлении услуг, таких как обработка, хранение данных, архивирование или облачные сервисы, то между испытательным центром и поставщиком должны быть заключены письменные соглашения (договора). Эти соглашения должны включать четкие формулировки в отношении ответственности поставщика, равно как и четкие определения в отношении собственника данных.
Компетенция и надежность поставщика должны оцениваться администрацией испытательного центра. Необходимость и степень оценки вендора должна основываться на оценке рисков с учетом сложности компьютеризированной системы и критичности бизнес-процесса, поддерживаемого компьютеризированной системой. Необходимость аудита должна основываться на задокументированной оценке рисков. Администрация испытательного центра несет ответственность за обоснование требований к аудиту и его вид на основе оценки рисков.
Если область применения оценки сфокусирована на технических аспектах и аспектах соблюдения требований, то должен быть рассмотрен вопрос привлечения специалистов из технического персонала и персонала отдела обеспечения качества. Администрация испытательного центра должна быть в состоянии предоставить инспекторам информацию о системах качества поставщиков, в зависимости от того, какие услуги они предоставляют. Поставщики не обязаны подтверждать соответствие требованиям GLP, однако должны работать в соответствии с документированной системой качества, пригодность которой подтверждена администрацией испытательного центра при участии сотрудников отдела обеспечения качества. Для систем, поставляемых вендорами, вероятно, большая часть документации, созданной в ходе разработки, будет хранится на объекте вендора. Если документация будет хранится на объекте вендора, то администрация испытательного центра должна удостовериться в безопасности её хранения. Для этого может потребоваться заключение официального договора между вендором и испытательным центром. В этом случае в испытательном центре в наличии должно быть подтверждение официальной оценки и/или аудита вендора. Испытательный центр также должен провести официальные приемочные тесты систем, поставляемых вендором.
Администрация испытательного центра должна в письменных соглашениях определить области взаимодействия между её валидационными процедурами и любыми работами, выполняемыми поставщиком. Такие области взаимодействия должны быть применимы к валидационной фазе и к эксплуатационной фазе. Например, любые процессы тестирования, выполняемые поставщиком, должны быть оценены администрацией испытательного центра.
Услуги хостинга (например, платформа, программное обеспечение, хранение данных, архивирование, резервное копирование или процессы как услуги – PaaS, process as a Service – прим. перев.) должны рассматриваться также, как и любая другая деятельность поставщика услуг и требуют письменного соглашения, описывающего обязанности и ответственность каждой из сторон. Администрация испытательного центра отвечает за оценку соответствующей услуги и оценку рисков в отношении целостности и доступности данных. Администрация испытательного центра также должна учитывать потенциальные риски, обусловленные неконтролируемым использованием хостинговых услуг.
Испытательный центр может включать ИТ-подразделение компании, как часть собственного GLP-объекта. В этих случаях сотрудники этого подразделения подотчетны администрации испытательного центра.

1.7. Коммерческое программное обеспечение (Commercial Off-The-Shelf products (COTS))

Компьютеризированная система может полностью или частично относиться к категории COTS-продуктов. COTS-продукты могут использоваться без модификации, с незначительным конфигурированием, со значительным конфигурированием или даже с индивидуальным кодированием. COTS-продукты, равно как и любое другое программное обеспечение, требует соответствующей валидации в зависимости от риска и сложности какой-либо модификации. Если приложение (например, электронная таблица) не является сложным, то достаточной может быть верификация функций относительно спецификации требований пользователя.
Спецификация требований пользователя должна быть написана для любого приложения, которое базируется на COTS-продукте. Для гарантии того, что COTS-продукт может соответствовать спецификации требований пользователя, документация, поставляемая с таким продуктом, должна быть проверена администрацией испытательного центра.
Шаблоны расчетных электронных таблиц, в которых используются предустановленные формулы, самостоятельно написанные функции или макросы, должны рассматриваться, как приложения собственной разработки. Требования в отношении валидации таких продуктов описаны в разделе 2 и 3 и зависят от риска и сложности. COTS-продукты, лежащие в основе таких приложений, требуют соответствующих форм квалификации и документирования. Квалификация лежащих в основе COTS-продуктов отдельно не является достаточной.

1.8. Контроль изменений и конфигураций

Любые изменения компьютеризированных систем должны осуществляться контролируемым образом в соответствии с документированной процедурой контроля изменений. Процедуры контроля изменений должны охватывать валидационную фазу, эксплуатационную фазу (включая архивирование) и фазу вывода системы из эксплуатации. Администрация испытательного центра должна определить обязанности и ответственность тех лиц, которые задействованы в операциях по контролю изменений. Решения в отношении требований к контролю изменений должны приниматься на основании анализа рисков и будут зависеть от сложности и критичности изменений в отношении целостности данных или в зависимости от поддерживаемого компьютеризированной системой бизнес-процесса. В оценке рисков, используемой для контроля изменений, можно использовать разбивку программного обеспечения на категории, как описано в действующем руководстве ISPE GAMP.
Контроль изменений должен охватывать любой объект, подлежащий пересмотру, утверждению и тестированию, и который имеет отношение к определенной конфигурации компьютеризированной системы. Следует удостовериться в том, что конфигурация системы всегда точно описывается и документируется. Специфические для исследования работы (например, сбор данных, расчет данных и т. п.) должны прослеживаться вплоть до конкретной конфигурации компьютеризированной системы, если эта конфигурация имеет отношение к результатам этих работ. Контроль изменений должен быть взаимосвязан с оценкой рисков, тестированием, выпуском и соответствующими документированными процедурами.

1.9. Требования к документации

Требования к документации компьютеризированных систем должны быть включены в систему менеджмента качества и должны охватывать все GLP-релевантные компьютеризированные системы. Объем необходимой документации будет варьировать в зависимости от сложности и стратегии валидации компьютеризированной системы. Документация должна быть для каждой компьютеризированной системы и обычно должна охватывать:
а) название и версию программного обеспечения компьютеризированной системы или идентификационный код, а также подробное и точное описание её целевого назначения;
b) аппаратное обеспечение, на котором функционирует программное обеспечение;
c) операционную систему и другое системное программное обеспечение (например, инструменты), используемые в сочетании с компьютеризированной системой;
d) язык (-и) программирования компьютеризированной системы и/или инструменты баз данных, используемые, когда это применимо;
e) основные функции, выполняемые компьютеризированной системой;
f) обзор типа и потока данных, связанных с компьютеризированной системой;
g) файловую структуру, сообщения об ошибках и авариях, связанных с использованием компьютеризированной системы;
h) компоненты программного обеспечения компьютеризированной системы с номерами версий; и
i) конфигурацию и коммуникационные линии связи модулей компьютеризированной системы с оборудованием, а также с другими системами
Использование компьютеризированных систем должно надлежащим образом документироваться. Такая документация обычно охватывает следующее, но не ограничивается этим:
a) процедуры эксплуатации компьютеризированных систем (аппаратного и программного обеспечения) и обязанности вовлеченного персонала;
b) процедуры по мерам безопасности для обнаружения и предотвращения несанкционированного доступа или изменения данных;
c) процедуры контроля изменений, описывающие процесс авторизации, тестирования и документирования изменений оборудования (аппаратного и программного обеспечения);
d) процедуры по проведению периодической оценки корректного функционирования всей системы или её составных частей и регистрации этих тестов;
e) процедуры, охватывающие повседневное профилактическое обслуживание и устранение неисправностей (в этих процедурах должны быть подробно описаны обязанности и ответственность вовлеченного персонала. Для COTS-систем при необходимости допускается использование собственных методик и процедур вендора для выполнения указанных работ. Это должно быть подробно описано в письменном соглашении об уровне обслуживания);
f) процедуры по разработке программного обеспечения, приемочным тестам и другим применимым тестам, а также по регистрации всех тестов;
g) процедуры по резервному копированию и непрерывности бизнес-процессов;
h) процедуры по архивированию и «извлечению из архива» всех электронных данных, версий программного обеспечения и документации по конфигурации компьютера, а также данных, подтверждающих все перечисленные работы;
i) процедуры по мониторингу и аудиту компьютеризированных систем и данных, подтверждающих все перечисленные работы;
j) процедуры и разрешение на вывод системы из эксплуатации.
При необходимости должны быть описаны дополнительные процедуры по управлению и валидации, которые могут включать следующее, но не ограничиваться этим: сбор данных; управление рисками; управление услугами; планирование валидации; спецификацию требований; спецификацию проекта; установку; выпуск системы; прослеживаемость; управление инцидентами; управление конфигурацией; управление записями; персонал; обязанности и ответственность персонала и управление документацией.
Должны быть доступны записи и процедуры, которые достаточно подробно описывают валидацию и использование компьютеризированной системы. Такие записи могут включать следующее, но не ограничиваться этим: оценку рисков; оценку поставщика; соглашение об уровне обслуживания; спецификацию требований; тестирование; выпуск; обучение персонала и пользователей; описание инцидентов и изменений; конфигурирование и эксплуатацию.
Полная документация по валидации и эксплуатации компьютеризированной системы должна быть доступна на протяжении всего периода хранения данных исследования, полученных с помощью этой системы и должна быть заархивирована в соответствии с действующим законодательством.

2. Проектная фаза

2.1. Валидация

Компьютеризированные системы должны быть спроектированы для работы в условиях GLP, также должна быть продемонстрирована их пригодность целевому назначению при работе в этих условиях, а введение в эксплуатацию должно быть предварительно запланировано. Валидация компьютеризированной системы, её документация и отчеты должны охватывать соответствующие этапы жизненного цикла, определенные администрацией испытательного центра на основании сложности системы и её предполагаемого использования. Объем валидационных работ может изменяться и адаптироваться в зависимости от типа системы на основании документированной оценки рисков. Для изменения объема валидационных работ администрация испытательного центра может опираться на рекомендации по передовым практикам. Администрация испытательного центра должна быть в состоянии на основании оценки рисков обосновать жизненный цикл, стратегию, валидационные требования, протоколы, нормы, процедуры, записи и соответствующие отчетные документы. Например, если это может быть обоснованно оценкой рисков, то выдаваемые администрацией испытательного центра отчетные документы по валидации могут ограничиваться спецификацией требований пользователя, планом валидации, пользовательским приемочным тестированием и отчетом о валидации.
В наличии должно быть подтверждение того, что перед введением в рутинную эксплуатацию система была должным образом протестирована на соответствие нормам, установленным испытательным центром. Формальное приемочное тестирование требует проведения тестов в соответствии с предварительно разработанным планом, а также сохранение документированного подтверждения всех процедур тестирования, данных, результатов тестирования, формального краткого отчета о тестировании и отчета о формальной приемке.

2.2. Контроль изменений в ходе валидационной фазы

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

2.3. Описание системы

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

2.4. Спецификация требований пользователя

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

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

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

2.6. Системы, изготовленные по индивидуальному заказу [1]

Системы, изготовленные по индивидуальному заказу, разрабатывают для специфического использования конкретным испытательным центром (например, специфические системы сбора данных для GLP-исследования, шаблоны электронных таблиц с формулами или макросами, запросы, статистические приложения или системы оценки данных и т. д.). Такие компьютеризированные системы также могут быть сконфигурированы или запрограммированы специально для одного или нескольких GLP-исследований. Поскольку для таких систем отсутствует опыт предыдущего или параллельного использования, системы, изготовленные по индивидуальному заказу, несут в себе наивысший внутренний риск. Для валидации компьютеризированной системы, изготовленной по индивидуальному заказу, в наличии должен быть процесс, обеспечивающий формальную оценку и сообщение показателей качества и эффективности для всех этапов жизненного цикла системы.
В письменном договоре между поставщиком системы, изготовленной по индивидуальному заказу, и администрацией испытательного центра должны быть прописаны обязанности и ответственность сторон в отношении системы и при необходимости её валидации. Валидационные работы, определенные администрацией испытательного центра, должны учитывать все операции поставщика, влияющие на качество, даже если они выполняются на его производственном объекте.Любые аутсорсинговые работы или работы, выполняемые на объекте поставщика, должны входить в состав жизненного цикла компьютеризированной системы.
Если приложение, расположенное на удаленном узле сети, запрограммировано или сконфигурировано по индивидуальному заказу, то такая система является как изготовленной по индивидуальному заказу, так и поставляемой вендором.

2.7. Тестирование

Тестирование (например, тестирование установки, пользовательское приемочное тестирование) должно проводиться для подтверждения того, что система отвечает предопределенным требованиям. Администрация испытательного центра несет ответственность за определение необходимости проведения тестирования, подтверждение полноты его проведения, а также за документацию по тестированию. Тесты должны основываться на знаниях о бизнес-процессах и предполагаемом использовании системы. Процедуры должны описывать порядок проведения тестов, точно определять обязанности и ответственность сторон, а также требования к документации. Администрация испытательного центра несет ответственность за определение объема и широты охвата выполняемого тестирования, основываясь на оценке рисков. Администрация испытательного центра должна удостовериться в том, что все системы, включая COTS-системы, протестированы и оценены. Процесс тестирования поставщиком и его документация могут играть вспомогательную роль для администрации испытательного центра в проведении её валидационных работ и могут дополнять или заменять тестирование, выполняемое администрацией испытательного центра. Независимо от того проводилось ли тестирование испытательным центром или поставщиком, администрация испытательного центра должна сохранить подтверждение тестирования, свидетельствующее о том, что для его выполнения были использованы подходящие методы и сценарии. В частности, должны учитываться ограничения параметров системы (процесса), ограничения данных и обработка ошибок.
Для демонстрации того, что система подходит для проведения конкретного GLP-исследования, администрация испытательного центра должна учесть пользовательское приемочное тестирование для конкретного метода (например, доказать пригодность системы для выполнения типичных аналитических задач, включая калибровку, измерения, расчеты и передачу данных в ЛИС).
В системе должен присутствовать интерфейс для процедур контроля изменений. Если после проведения тестирования необходимо внести изменения в систему, то управление ими должно осуществляться посредством контроля изменений. Подтверждение надлежащего тестирования может быть обеспечено путем ведения учета записей результатов внутреннего тестирования или записей аудита вендора.

2.8. Перенос данных

Перенос данных может осуществляться как в ходе GLP-исследования, так и после его окончания. Независимо от состояния какого-либо проекта GLP-исследования, если затрагиваются GLP-релевантные данные, то перенос данных должен быть включен в охват валидационных работ, выполняемых администрацией испытательного центра. Перенос данных может быть уместным в том случае, когда записи исследования заархивированы в электронной системе.
При переносе электронных данных из одной системы в другую процесс должен быть задокументирован. Администрация испытательного центра несет ответственность за обеспечение и демонстрацию того, что в ходе процесса переноса данные не были изменены. Преобразование данных в другой формат также должно рассматриваться как перенос данных (например, из запатентованного формата данных в PDF). При переносе данных на другой носитель информации они должны быть проверены на предмет того, что являются точной копией оригинальных данных до момента уничтожения оригинала.
Работы по переносу данных могут значительно отличаться по сложности и рискам. Например:
а) обновление версии;
b) преобразование данных (из одной базы данных в другую; в другой формат данных; обновление ПО, связанное с изменением формата);
с) перенос одной и той же системы (перенос приложения; данных с одного сервера на другой); и
d) перенос из исходной в целевую систему.
Перенесенные данные должны остаться пригодными к использованию, а также сохранить свое содержание и значимость. В процессе переноса должно быть обеспечено сохранение значения и/или значимости связей между контрольным журналом системы и электронными подписями. Администрация испытательного центра несет ответственность за поддержание связи между электронными подписями или доступным для чтения контрольным журналом и проверяемыми данными.

2.9. Обмен данными

Коммуникации, относящиеся к компьютеризированным системам, в основном разделяют на две категории: между компьютерами или между компьютерами и периферийными устройствами. GLP-релевантные данные могут передаваться автоматически в одностороннем или двухстороннем порядке из одной системы в другую систему (например, из удаленной системы сбора данных в центральную базу данных, из электронных таблиц в ЛИС, из хроматографической системы управления данными в ЛИС или из электронных таблиц в программу статистической обработки данных). Все коммуникационные каналы являются потенциальными источниками ошибок и могут привести к потере или повреждению данных. С целью безопасности и системной целостности в ходе разработки, валидации, эксплуатации и обслуживания должен быть в достаточной мере предусмотрен надлежащий контроль интерфейсов. Обмен электронными данными между системами должен включать подходящие встроенные проверки правильности, безопасного ввода и обработки данных. Сетевая инфраструктура должна быть квалифицирована. Тем не менее, это требование не подразумевает валидацию стандартной коммуникационной инфраструктуры и ее процедур (например, базового коммуникационного сетевого протокола TCP/IP (Transmission Control Protocol/Internet Protocol)).

3. Эксплуатационная фаза

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

3.1. Проверка правильности

Администрация испытательного центра должна быть осведомлена обо всех GLP-релевантных данных, которые вводятся вручную в электронные системы. Администрация испытательного центра несет ответственность за надлежащий контроль над любой системой ввода электронных данных, независимо от её сложности. Для определения возможности ошибочного ввода данных, а также для оценки критичности и последствий ошибочного или неправильного ввода данных следует применять оценку рисков. В наличии должны быть описанные и введенные в действие стратегии смягчения рисков. Это может привести к необходимости выполнения вторым оператором или электронной системой дополнительных ручных и/или электронных проверок правильности введенных данных. В случае использования автоматизированных проверок ввода данных их следует включить в валидацию компьютеризированной системы (например, автоматически применяемые валидационные скрипты при ручном вводе данных), а объем валидационных работ должен быть изменен на основании оценки рисков. Использование недействительных систем ввода данных должно быть исключено (например, неконтролируемое использование электронных таблиц). Если для ручного ввода данных применяются процедуры ручного контроля, то они должны быть подтверждены соответствующей документацией, которая будет способствовать воссозданию выполненных операций.

3.2. Данные и хранение данных

Если данные (исходные, выводимые данные или метаданные) хранятся в электронной форме, то должны быть определены требования к резервному копированию и архивированию. Резервное копирование всех необходимых данных должно выполняться для обеспечения возможности восстановления после сбоя, угрожающего целостности системы.
Хранимые данные должны быть защищены физическими и электронными средствами от потери, повреждения и/или изменения. Хранимые данные должны быть проверены на предмет возможности восстановления, доступности, считываемости и правильности. Процедуры проверки хранимых данных должны основываться на оценке рисков. Доступ к хранимым данным должен быть обеспечен на протяжении всего периода хранения.
Изменения аппаратной и программной части системы не должны препятствовать непрерывному доступу к данным и их хранению без какого-либо риска для целостности данных. При обновлении системы или программного обеспечения должна существовать возможность чтения данных, сохраненных предыдущей версией системы или должны быть доступны другие методы чтения предыдущих данных. Для вспомогательной информации (например, журналы технического обслуживания, записи калибровки, конфигурирование и т. п.), которая требуется для проверки действительности исходных данных или для реконструкции всего исследования или его частей, должно быть выполнено резервное копирование, а хранение должно осуществляться в архивах. Программное обеспечение должно храниться в архиве, чтобы в случае необходимости можно было прочитать или восстановить данные.
В отношении электронных записей администрации испытательного центра следует:
а) идентифицировать любые относящиеся к исследованию электронные записи (например, исходные данные, выводимые данные). Необходимо, чтобы исходные данные идентифицировались для каждой компьютеризированной системы независимо от того, как они связаны с ней (например, путем хранения на электронном носителе информации, в виде распечаток с компьютера или прибора и т. п.);
b) оценить критичность электронных записей для качества результатов исследования;
c) оценить потенциальные риски для электронных записей;
d) установить процедуры смягчения рисков; и
e) контролировать эффективность смягчения рисков в течение всего жизненного цикла.
В отношении процедур администрация испытательного центра должна описать как хранятся электронные данные, как обеспечивается защита целостности записей и как поддерживается читабельность записей. Для любого GLP-релевантного промежутка времени это включает, но может не ограничиваться этим:
а) контроль физического доступа к электронным носителям информации (например, меры по контролю и мониторингу доступа персонала к серверным комнатам и т. д.);
b) контроль логического (электронного) доступа к хранимым записям (например, принципы авторизации для компьютеризированных систем, как часть их валидации, которые устанавливают роли и права в любой GLP-релевантной компьютеризированной системе);
c) физическую защиту носителей информации от потери или разрушения (например, от огня, влажности, разрушительных электрических аварий или аномалий, кражи и т. д.);
d) защиту хранимых электронных записей от потери и изменения (например, валидация процедур резервного копирования, включая верификацию резервных копий и их надлежащего хранения, применение систем ведения контрольного журнала и т. д.); и
e) удостоверение в доступности и считываемости электронных записей путем обеспечения соответствующих физических и программных условий.
Вопрос хранения данных должен быть рассмотрен для каждой компьютеризированной системы, используемой для проведения GLP-исследований, как в течение фазы самого исследования, так и в период архивного хранения. Не обязательно включать оценку в документацию исследования. Однако, администрация испытательного центра должна иметь процедуру объяснения того, как хранятся данные и как удовлетворяются требования к их хранению. Эта информация должна быть частью комплекта документации по валидации системы. Если испытательный центр передает электронные данные исследования спонсору, то ответственность за эти данные несет спонсор.

3.3. Распечатки

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

3.4. Контрольный журнал

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

3.5. Управление изменениями и конфигурацией

Администрация испытательного центра должна иметь подходящие процедуры для управления конфигурацией и управления изменениями в эксплуатационной фазе. Управление изменениями и конфигурацией должно быть применимо к аппаратному и программному обеспечению. При изменении конфигурации компьютеризированной системы, меры по контролю изменений должны обеспечивать контролируемое внесение тех изменений, которые могут повлиять на состояние валидации системы. Изменение должно прослеживаться до соответствующих записей по контролю изменений и конфигурации. Процедуры должны описывать метод оценки, используемый для определения объема повторных тестов, необходимых для поддержания валидированного состояния системы.
Процедуры контроля изменений должны точно определять обязанности и ответственность за доступ к изменениям и их утверждение, а также подробно описывать процедуры оценки изменений. Независимо от происхождения изменения (система от поставщика или собственной разработки) должна быть предоставлена соответствующая информация, как часть процесса контроля изменений. Процедуры контроля изменений должны обеспечивать целостность данных.
Конфигурация компьютеризированной системы должна быть известна в любой момент её жизненного цикла, от начальных этапов разработки и до вывода из эксплуатации. Документированное соответствие конфигурации аналитического оборудования положениям валидации аналитической методики необходимо для демонстрации надлежащего использования компьютеризированной системы в GLP-исследовании, независимо от ее сложности. Любой результат GLP-исследования должен прослеживаться до соответствующей валидированной конфигурации системы для обеспечения проверки настроек в соответствии с планом исследования или соответствующей методикой.
Изменения могут потребоваться в качестве ответных мер при инцидентах или для специфичных целей испытательного центра/исследования. После изменения или восстановления системы состояние её валидации должно быть проверено и задокументировано.
Изменения, ежедневно вносимые автоматически (например, защита от вирусов или исправления операционной системы), должны быть частью формального контроля изменений или управления конфигурацией. Отсутствие управления изменениями компьютеризированной системы должно быть обосновано и основываться на оценке рисков.

3.6. Периодический пересмотр

Компьютеризированные системы должны периодически пересматриваться для подтверждения того, что они находятся в валидированном состоянии, соответствуют требованиям GLP и продолжают соответствовать установленным эксплуатационным показателям (например, в отношении надежности, отзывчивости, емкости и т. д.). При необходимости пересмотр должен включать текущий набор функций, записи отклонений, инциденты, историю обновлений, производительность, надежность и безопасность, которые могут повлиять на состояние валидации системы. Частота и глубина периодических пересмотров должны быть определены на основании оценки рисков с учетом сложности и критичности в отношении GLP. В периодический пересмотр должно быть включено любое зарегистрированное неожидаемое событие, которое могло повлиять на состояние валидации системы. Пригодность операций по пересмотру и вовлечение квалифицированного персонала, а также GLP-релевантных специалистов (например, администрации испытательного центра, сотрудников отдела обеспечения качества, ИТ поддержки, поставщика и т. д.) должны быть обоснованы. Также должны быть определены обязанности персонала, вовлеченного в периодический пересмотр состояния валидации компьютеризированной системы. Необходимость взаимодействия операций по периодическому пересмотру с системой регистрации инцидентов может быть рассмотрена на основе оценки рисков. Результаты работ по периодическому пересмотру и при необходимости корректирующих действий должны быть задокументированы.
Компьютеризированные системы меньшей важности и сложности могут быть исключены из пересмотра, если это обосновано оценкой рисков. Периодический пересмотр может быть необязательным и может быть перенесен на другое время в том случае, если незадолго до него выполнялись значительные работы по (ре-)валидации. Автоматизированные COTS-системы могут быть исключены из пересмотра в том случае, если не было зарегистрировано ни одного неожидаемого события, которое могло бы повлиять на состояние валидации. Периодический пользовательский пересмотр должен выполняться при необходимости (например, в случае организационных изменений) или по меньшей мере ежегодно, поскольку персонал и права доступа могут меняться. Пользовательский пересмотр также должен выполняться для COTS.

3.7. Физическая, логическая безопасность и целостность данных

Для защиты данных, аппаратного и программного обеспечения от несанкционированного изменения или потери в наличии должны быть документированные процедуры безопасности, утвержденные администрацией испытательного центра. зависимости от сложности и критичности системы, а также с учетом требований организации, в которой она эксплуатируется, должны быть внедрены подходящие физические и логические средства управления.
Подходящие методы контроля для предотвращения несанкционированного физического доступа к системе (аппаратному компьютерному обеспечению, коммуникационному оборудованию, периферическим компонентам и электронным носителям информации) могут включать использование ключей, карточек-пропусков, персональных кодов с паролями, биометрические методы идентификации или ограничение доступа к конкретному компьютерному оборудованию (например, в помещения хранения данных, к интерфейсам, компьютерам, в серверные помещения и т. д.). Создание, изменение и удаление авторизаций доступа должно быть зарегистрировано. вторизационные записи должны периодически пересматриваться исходя из критичности процесса, поддерживаемого компьютеризированной системой, а также в случае соответствующих организационных изменений в испытательном центре.
Поскольку поддержание целостности данных является основным аспектом принципов GLP, администрация испытательного центра должна удостовериться в том, что персонал осведомлен о важности целостности данных, процедурах и возможностях системы, доступных для обеспечения необходимой безопасности, и последствиях нарушения безопасности. Такие возможности системы могут включать в себя постоянное наблюдение за доступом в систему, внедрение методов проверки файла и сообщение об исключениях и/или тенденциях.
Для оборудования, не находящегося в специальных «компьютерных помещениях» (например, персональные компьютеры и терминалы), должны присутствовать средства управления доступом к помещению, где расположено аппаратное обеспечение (например, управление доступом к зданию, помещению лаборатории или специальному помещению). Там, где подобное оборудование размещено удаленно (например, переносные компоненты и модемные коммуникации), могут быть приняты дополнительные меры, что должно быть обосновано и основываться на оценке рисков (например, криптографический контроль).
Важно, чтобы в использовании находились только квалифицированные и утвержденные версии программного обеспечения. Всякое внесение данных или программного обеспечения из внешних источников должно контролироваться. Такой контроль может выполняться операционной системой компьютера, специфическими методами безопасности, методами, встроенными в приложения, или комбинациями вышеперечисленного. Системы хранения данных и документации должны быть спроектированы так, чтобы велась запись даты, времени и личностей операторов, вводящих, изменяющих, подтверждающих или удаляющих данные.
При необходимости должна быть рассмотрена потенциальная возможность повреждения данных вредоносным кодом или другими агентами. Для обеспечения целостности данных должны быть приняты меры безопасности, как на случай кратковременного, так и на случай долговременного отказа системы.
Права логического доступа к доменам, компьютерам, приложениям и данным должны задаваться подходящей и надлежащим образом поддерживаемой политикой авторизации. Права пользователя должны быть определены для операционных систем и приложений и должны быть адаптированы к организационным требованиям испытательного центра и сочетаться с требованиями конкретного GLP-исследования. Также должны быть определены обязанности и ответственность персонала, предоставляющего права пользователям.
Права пользователей в компьютеризированной системе не должны конфликтовать с требованиями к целостности данных. Действия любого персонала, участвующего в GLP-исследовании, должны прослеживаться вплоть до прав и действий пользователя во всех связанных компьютеризированных системах, и должны быть отражены в документации по контролю прав пользователей. Запрещено давать права администратора лицам, имеющим потенциальную заинтересованность в данных (например, лабораторная роль «аналитик» не совместима с системной ролью «администратор» в хроматографической системе управления данными). Пользователь не должен иметь вторую роль в одной системе, которая может конфликтовать с требованиями к целостности данных.

3.8. Управление инцидентами

В ходе повседневной эксплуатации системы должно проводиться обслуживание записей с целью обнаружения любых проблем или несоответствий, для устранения которых должны приниматься корректирующие действия. Руководитель исследования, администрация испытательного центра, отдел обеспечения качества и при необходимости спонсор должны быть проинформированы об инцидентах, требующих корректирующих действий. Руководитель исследования отвечает за определение критичности инцидентов и за оценку их влияния на исследование. Основная причина инцидента, требующего корректирующих действий, должна быть определена и должна служить основой для корректирующих и предупреждающих действий. Должен быть определен приоритет корректирующих и предупреждающих действий. Для всех инцидентов, зарегистрированных для компьютеризированной системы и требующих корректирующих действий, должна существовать возможность прослеживания вплоть до затрагиваемых ими GLP-исследований и наоборот.
Записи об инцидентах должны обрабатываться вместе с документацией системы и периодически архивироваться. Записи об инцидентах должны архивироваться и храниться вместе с соответствующей (валидационной) документацией системы как отчеты об инцидентах, необходимые для контроля и периодического пересмотра. В распоряжении администрации испытательного центра должна быть система управления инцидентами, связанная или объединенная с системами управления изменениями, конфигурацией, периодическими пересмотрами и обучением. Пересмотр инцидентов должен входить в состав периодической оценки системы.

3.9. Электронные подписи

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

Функция электронной подписи в компьютеризированной системе должна быть прописана в требованиях к системе, валидирована и описана в системных процедурах. Администрация испытательного центра должна определить, какие записи требуют собственноручной, а какие электронной подписи. Решение полагаться на функцию электронной подписи при наличии других способов (например, распечатка и подписание от руки) остается за администрацией испытательного центра. Применяемая процедура должна быть надлежащим образом описана.
Администрация испытательного центра должна обеспечить установление политики электронных подписей с целью обеспечения правильного использования и обслуживания функций электронной подписи компьютеризированной системы. Персонал, имеющий разрешение на использование электронной подписи, должен быть точно идентифицирован по имени и привязан по имени к политике электронных подписей. Обязанности лица в GLP-исследовании должны быть отражены в значении соответствующей электронной подписи, накладываемой компьютеризированной системой в соответствующем исследовании, и должны прослеживаться вплоть до системной политики авторизации. В некоторых исследованиях может потребоваться адаптация концепции авторизации компьютеризированной системы к специфическим требованиям исследования.
Администрация испытательного центра должна обеспечить эквивалентность электронной подписи собственноручной, а также неоспоримость её подлинности как минимум в пределах испытательного центра. Повторный ввод пароля должен рассматриваться как минимальное требование при наложении электронной подписи. Нажатие на функциональную клавишу лицом, вошедшим в систему, не должно рассматриваться как электронная подпись. Метаданные, связанные с записью, подписанной электронной подписью, должны быть точно идентифицируемы (например, параметры методики и конфигурация системы, если это применимо к аналитическим результатам, подписанным электронной подписью). Функция электронной подписи компьютеризированной системы должна обеспечивать своевременное связывание записи, подписанной электронной подписью, и вспомогательных метаданных. Пользователь не должен иметь возможности изменить наложенную электронную подпись или изменить связь с соответствующими метаданными. Если произошло изменение записи, подписанной электронной подписью, или вспомогательных метаданных, то это должно быть объяснено (в электронном виде), подписано и датировано лицом, ответственным за изменение. При изменении записи, подписанной электронной подписью или вспомогательных метаданных, такое изменение следует расценивать как аннулирующее эту электронную подпись.
Для подписания записей, распечатанных из компьютеризированной системы, администрация испытательного центра может использовать «бумажные» процедуры. Следует отметить, что бумажные распечатки электронных записей могут содержать не всю информацию, необходимую для полного воспроизведения действий или для предоставления всего содержания данных. В качестве гибридного решения некоторые вспомогательные метаданные, относящиеся к распечатанной/подписанной записи, могут храниться в электронном виде. Использование такой гибридной системы должно быть полностью объяснено в процедурах центра и обосновано оценкой рисков. Основываясь на оценке рисков, печать должна выполняться при полном понимании того, какой процесс и какая информация не будут отражены в распечатке.Гибридное решение должно быть описано точно для того, чтобы можно было определить все дополнительные электронные записи или вспомогательные метаданные, которые будут представлены в распечатанной и подписанной версии записи. Подходящая система контроля версий должна обеспечивать своевременное связывание распечатанной/подписанной записи с записями, хранимыми в электронном виде. Для отслеживания изменений и документирования недействительных результатов должна присутствовать возможность доступа к измененным или замененным записям. Тем не менее, такие записи должны быть исключены из рутинного использования. Если параллельно сохраняется полный комплект электронных записей и их печатанных аналогов, то для применения подходящей процедуры контроля администрация испытательного центра должна определить контролируемый тип записи (например, если полный комплект информации аналитической системы распечатан и параллельно храниться в электронном виде, то должно быть определено, какой из комплектов информации является контролируемым).

3.10. Утверждение данных

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

3.11. Архивирование

В отношении архивирования этот справочный документ дополняет справочный документ ОЭСР по GLP № 15 «Создание и контроль архивов, эксплуатируемых в соответствии с принципами GLP» (“Establishment and Control of Archives that Operate in Compliance with the Principles of GLP”).
Любые GLP-релевантные данные могут быть архивированы в электронном виде. Принципы GLP в отношении архивирования должны применяться одинаково как к электронным, так и к неэлектронным данным.Соответственно, важным аспектом является то, чтобы электронные данные хранились с аналогичными уровнями контроля доступа, индексации и целесообразного «извлечения», что и неэлектронные.
Просмотр электронных записей без возможности изменения или удаления архивированных электронных записей, а также дублирование внутри компьютеризированной системы или в другую компьютеризированную систему не является «извлечением» записей. Только когда существует возможность изменения или удаления архивированных записей, только тогда доступ следует рассматривать как изъятие, «извлечение» или удаление записей и материалов. С целью проверки выполнения требований к архивированным данным архивариус должен иметь возможность контролировать назначение доступа «только в режиме просмотра» к архивированным электронным данным.
В течение периода архивного хранения электронные данные должны быть доступны и читаемы, а также должна поддерживаться их целостность. Если выбрано и используется гибридное решение (то есть «бумажные» данные и электронные данные сохраняются параллельно), то администрация испытательного центра должна определить значимые для архивирования контролируемые записи.
Электронное архивирование должно рассматриваться как независимая процедура, которая должна быть надлежащим образов валидирована. При разработке и валидации процедуры архивирования должна применяться оценка рисков. Соответствующие системы хостинга и форматы данных должны быть оценены в отношении доступности, читаемости и влияния на целостность данных в течение периода архивного хранения. Может быть рассмотрена возможность архивирования электронных данных в открытом формате, который не зависит от запатентованного формата файлов, например, от формата производителя прибора. При необходимости преобразования данных применяются требования из пункта 2.8. В процессе управления электронными данными архивариус, несущий единоличную ответственность, может делегировать задачи квалифицированному персоналу или автоматизированному процессу (например, контролю доступа).Обязанности и ответственность в процессе архивирования описаны в справочном документе ОЭСР по GLP № 15.
Чтобы гарантировать, что долгосрочная целостность хранимых в электронном виде данных не будет скомпрометирована, должны быть внедрены соответствующие процедуры. Если носители данных, форматы данных, аппаратное или программное обеспечение систем архивирования (но не систем сбора данных) изменяется в течение периода архивного хранения, то администрация испытательного центра должна обеспечить отсутствие негативного влияния на доступность, читаемость и целостность архивированных данных. Постоянная возможность извлечения данных должна быть подтверждена и протестирована. В случае предполагаемых проблем с долгосрочным доступом к данным или в случае вывода компьютеризированной системы из эксплуатации должны быть установлены процедуры для обеспечения последующего считывания данных. Это, например, может включать распечатку копий, преобразование данных в другой формат или перенос данных в другую систему. Если перенос данных включает в себя преобразование в другой формат данных или необходима распечатка, то должны быть соблюдены требования настоящего руководства к переносу данных. При необходимости внесения изменений в систему архивирования оценка рисков, контроль изменений, управление конфигурацией и режим тестирования должны рассматриваться как соответствующие стандартные процедуры. Поскольку содержание и значение электронных данных должно сохраняться на протяжении всего периода архивного хранения, то должен быть идентифицирован и архивирован полный пакет информации (например, исходные данные, метаданные, необходимые для корректного понимания значения записи или для восстановления её источника, электронные подписи, контрольные журналы и т. д.).
Если подписанная электронной подписью запись архивирована электронным способом, то её целостность должна быть обеспечена в течение необходимого периода времени. В течение периода архивного хранения должна существовать возможность проверки и оценки целостности подписанной записи, вспомогательных метаданных и электронной подписи. Периодичность оценки должна быть обоснована администрацией испытательного центра на основе оценки рисков.
В отчете по исследованию руководитель исследования должен определить все GLP-релевантные электронные данные, предназначенные для архивирования в электронном виде, а также расположение электронного архива.
Любые данные, хранимые в поддержку соответствующей компьютеризированной системы, такие как исходный код, записи по разработке, валидации, эксплуатации, обслуживанию и мониторингу, должны храниться как минимум до тех пор, пока хранятся записи исследования, связанные с данной системой.
Никакие данные, хранимые в электронном виде, не могут быть уничтожены без соответствующего документирования и разрешения администрации испытательного центра и спонсора, когда это применимо.

3.12. Непрерывность бизнеса и восстановление после отказа

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

[1] Исходный код кастомизируемых систем (или все программное обеспечение компьютеризированных систем) в некоторых странах-членах OECD должен сохраняться в ходе проведения испытаний администрацией испытательного центра для предоставления доступа к мониторингу программного кода. Это может быть сделано посредством архивирования цифровой копии исходного кода, механизмами условного депонирования или письменными соглашениями.