VII. Рекомендация Коллегии Евразийской экономической комиссии от 19.09.2023 N 25 "О Руководстве по обеспечению целостности данных и валидации компьютеризированных систем"

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

142. В настоящем разделе описан подход к процессу валидации компьютеризированной системы на протяжении всего жизненного цикла системы в соответствии с принципами PIC/S и GAMP, а также определены процедурные рамки, обеспечивающие выполнение требований Правил производственной практики в результате процесса валидации. Настоящий раздел определяет действия, которые следует выполнить до выпуска компьютеризированной системы в эксплуатацию, во время ее использования вплоть до момента вывода компьютеризированной системы из эксплуатации.

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

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

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

б) подготовка проекта внедрения, который основан на документированной спецификации требований пользователей (URS), ориентированной на детализацию потребностей бизнеса и пользователей (с точки зрения бизнес-процессов, соответствия требованиям, а также технических и нефункциональных стандартов), которые будут определены на начальных этапах проекта внедрения;

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

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

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

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

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

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

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

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

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

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

Таблица

Категории компьютеризированных систем

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

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

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

152. Регулируемым компаниям следует иметь перечень всех используемых компьютеризированных систем, включающий в себя следующие данные:

а) наименование и номер версии системы, наименование поставщика системы, наименование владельца системы, местоположение и основные функции системы (то есть предполагаемое использование) каждой компьютеризированной системы;

б) оценка рисков, связанных с системой и соответствующими записями, которые управляются этой системой (например, прямое воздействие на GMP, косвенное воздействие, не влияет);

в) текущий статус валидации каждой системы и ссылки на существующие валидационные документы.

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

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

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

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

157. Потенциальные и существующие поставщики GMP-критичных систем (поставщики компьютеризированных систем и поставщики услуг) оцениваются на основе бизнес-риска и влияния рассматриваемой услуги или компьютеризированной системы.

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

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

а) способность обеспечить высокое качество продукции или услуг;

б) соответствие требованиям, сформулированным заказчиком;

в) наличие адекватных процессов обеспечения качества.

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

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

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

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

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

163. Спецификация требований пользователя включает в себя следующее:

а) критически важные для качества функции;

б) идентификацию регулируемых электронных записей (ЭЗ), поддерживаемых системой и подписываемых электронной подписью (ЭП), выполняемой в системе;

в) применимые требования актов органов Союза и законодательства государств-членов к электронным записям и управлению электронными подписями ("правила ЭЗЭП");

г) список бизнес-процессов и связанных с ними потоков процессов;

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

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

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

План валидации

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

167. План валидации определяет жизненный цикл валидации и объем валидации путем определения границ системы. Результаты оценки поставщика следует рассматривать вместе с условиями использования предоставленной им документации.

168. В плане валидации должны быть идентифицированы:

а) перечень создаваемой документации;

б) распределение ответственности (например, матрица распределения ответственности RACI (ответственный, подотчетный, консультированный, информированный)) для результатов валидации;

в) общие критерии приемлемости для валидационного процесса.

169. План валидации всегда создается в случае внедрения новой системы или значительных изменений существующей.

170. В зависимости от категории и сложности компьютеризированной системы документация по спецификации может быть объединена в один документ.

Функциональная спецификация

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

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

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

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

Конфигурационные спецификации

175. Конфигурационная спецификация создается для описания:

списка компонентов аппаратного и программного обеспечения, включенных в компьютеризированную систему;

параметров системы (например, длины пароля), которые могут повлиять на одну или несколько функций в системе GMP.

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

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

178. Конфигурационная спецификация должна также описывать IT-ландшафт, на котором размещено программное обеспечение, и то, как оно должно быть подключено к любой существующей системе или оборудованию. Поэтому этот документ должен включать также (или давать ссылку на другой документ) описание системного ландшафта и спецификации всех элементов, показанных на ландшафте (например, операционной системы, промежуточного программного обеспечения, вспомогательные инструменты (программы просмотра PDF-файлов, системных сред, интерфейсов, соответствующих компонентов IT-инфраструктуры, например, серверов и т.д.).

Проектные спецификации

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

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

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

Детальная оценка рисков

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

183. Оценка функциональных рисков определяет соответствие нормативным требованиям и степень серьезности бизнес-рисков в сравнении с существующими функциональными возможностями системы и поддерживаемыми бизнес-процессами.

184. Валидационные группы вместе с владельцем бизнес-процесса или его представителями и техническими группами готовят оценку риска на основе требований пользователя и (или) функциональных, конфигурационных, проектных спецификаций.

185. Результат оценки риска должен включать результаты процессного и (или) функционального анализа риска, выполненного в соответствии с заранее определенной методологией.

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

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

188. Объем работ по валидации на этапе тестирования и объем документации по результатам валидации зависит от таких масштабирующих факторов, как уровень GMP-риска системы и результат детальной оценки риска, выявляющей процессы и (или) функции с максимальными рисками, на которых должно быть сосредоточено тестирование.

189. Стратегия испытаний определяет соответствующий подход к испытанию конкретной системы, основанный на:

а) понимании компонентов системы (категория GAMP), общей сложности и новизны системы;

б) уровне GMP-риска системы;

в) результатах оценки функциональных рисков;

г) результатах оценки поставщиков (если это применимо).

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

191. Испытания системы следует организовать на разных фазах внедрения системы в процесс непрерывного мониторинга качества. Испытания системы включают в себя:

а) испытания от поставщика (например, тестирование ввода в эксплуатацию, модульное и интеграционное тестирование), выполняемое поставщиком ПО в соответствии с его системой качества или предопределенным планом качества и проекта;

б) валидационные испытания, выполняемые в квалификационной и (или) производственной среде по заранее определенным протоколам для следующих этапов:

в) квалификацию монтажа;

г) квалификацию функционирования;

д) квалификацию эксплуатации.

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

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

193. Документация по испытаниям (например, протокол квалификации) должна описывать подход к предполагаемому тестированию, среду тестирования, перечень испытаний и соответствующие критерии приемлемости, результаты испытаний вместе с выявленными отклонениями (если таковые имеются) и критерии для различных этапов приемки. Этапы испытаний могут быть объединены (например, квалификация монтажа IQ и квалификация функционирования OQ) в случаях, когда это возможно. Результаты этапов испытаний следует документировать.

Системная среда

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

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

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

Миграция данных

197. Миграция данных в значительной степени зависит от конкретной технологии и файловой структуры переносимых электронных записей.

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

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

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

Протокол квалификации монтажа

201. Квалификация монтажа (IQ) (также называемая конфигурационным тестированием) - это деятельность по проверке установки и конфигурации аппаратных и программных компонентов системы и соответствующей документации.

202. Квалификацию монтажа следует осуществлять после "замораживания" конфигурации, которая подлежит проверке. Любые изменения, внесенные позднее в конфигурацию, проходят процедуру управления изменениями.

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

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

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

а) правильность установки аппаратного и программного обеспечения в соответствии с техническими характеристиками и базовыми показателями конфигурации системы;

б) соответствие настройки конфигурации аппаратного и программного обеспечения настройкам конфигурации указанным в конфигурационных спецификациях (если применимо);

в) наличие документации по системе.

206. Для разработки протокола квалификации монтажа стандартного программного обеспечения может быть использована документация поставщика (процедуры, руководства, инструкции).

Протокол квалификации функционирования

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

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

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

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

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

Протокол квалификации эксплуатации

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

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

а) этапы IQ - OQ завершены и соответствующие отчеты утверждены, а любое отклонение проанализировано и "закрыто";

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

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

г) доступ для каждого пользователя был создан в соответствии с его навыками и обязанностями;

д) проверка бизнес-процессов, поддерживаемых системой ("сквозные" тесты), основана на результатах детальной оценки рисков;

е) выполнимо восстановление системы и данных в рабочей среде (резервное копирование и восстановление данных).

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

Матрица прослеживаемости

215. Матрица прослеживаемости создается для подтверждения того, что:

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

б) системный функционал и бизнес-процессы были должным образом испытаны в квалификационных тестах в соответствии с результатом детальной оценки риска.

216. Решение о начале использования компьютеризированной системы в производстве должно быть одобрено по крайней мере владельцем бизнес-процесса и службой качества. Эти роли определяют валидационный статус системы перед авторизацией развертывания в рабочей среде. Это решение следует официально задокументировать в разделе валидационного отчета или в специальном документе.

Валидационный отчет

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

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

218. Валидационный отчет (краткий валидационный отчет) включает в себя:

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

б) идентификацию возможных ограничений;

в) подтверждение того, что все испытания были выполнены в соответствии с планом или утвержденным отклонением от плана;

г) измеримую оценку результатов испытаний и подтверждение соответствия критериям приемлемости системы;

д) план действий (если применимо);

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

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

Управление защитой

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

221. Следующие процессы выполняются на протяжении всего жизненного цикла компьютеризированной системы:

а) физическая безопасность, которая включает в себя все соответствующие меры предосторожности для контроля доступа и среды для защиты объектов компьютеризированных систем от кражи, разрушения, неконтролируемого изменения или нарушения;

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

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

222. Следует предусмотреть контрольные процедуры для обеспечения:

а) установления и поддержки ролей и обязанностей в области защиты, политик, стандартов и процедур;

б) выполнения мониторинга защиты и периодического тестирования (например, ручная проверка журнала доступа к системе, автоматическое уведомление о блокировках, тестирование токенов (при наличии);

в) создания и ведения списка лиц, имеющих право доступа к системе.

223. Конфигурация защиты документируется в спецификациях конфигурации системы или в специальном документе (например, матрице защиты). Доступ к системе ограничен операторами с документированным обучением.

224. Меры контроля для критически важных компонентов системы (например, серверов) включены и проверяются в процессе квалификации инфраструктуры.

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

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

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

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

Управление изменениями

228. Управление изменениями применяется к компьютеризированным системам, подлежащим валидации на протяжении всего жизненного цикла системы от этапа квалификации монтажа до вывода системы из использования.

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

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

231. Изменения осуществляются в соответствии с заранее установленной процедурой управления изменениями.

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

232. В соответствии с пунктами 118 - 120 настоящего Руководства, резервное копирование - это процесс копирования записей, данных и программного обеспечения для защиты от потери целостности или доступности оригинала. Восстановление - это последующее восстановление записей, данных или программного обеспечения (при необходимости).

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

234. Надежность процесса восстановления должна быть проверена при валидации.

Соглашение об уровне обслуживания

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

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

Непрерывность деятельности

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

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

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

б) планы управления и методы принятия решений, которые будут использоваться во время аварии (отказов) компьютеризированных систем;

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

г) испытания процедур на случай непредвиденных обстоятельств.

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

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

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

241. В случае если данные архивируются в автономном режиме (то есть не сразу доступны пользователям), процедура архивирования определяет временные периоды и условия для архивирования данных. Процесс архивирования и восстановления данных следует задокументировать. Также следует проводить тестирование процесса архивации в течение жизненного цикла.

Периодический обзор

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

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

244. Периодические обзоры осуществляются в соответствии с заранее установленной процедурой.

Обучение и процедуры по использованию системы

245. Для каждой GMP-системы следует разработать обязательные для выполнения стандартные операционные процедуры, определяющие порядок работы с системой и поэтапное выполнение операций. Кроме того, такие процедуры включают в себя раздел, посвященный специальным, а не рутинным действиям, соответствующим каждой системе, таким как:

а) добавление, изменение и удаление записей;

б) выполнение рутинных периодических задач (например, перестроение индекса базы данных);

в) подготовка (выбор и сортировка, определение последовательностей и т.д.) экранных запросов и распечатанных отчетов о системных данных;

г) запуск управляемых пользователем интерфейсов передачи данных в другие системы и из других систем;

д) выгрузка или загрузка данных на рабочую станцию или устройства удаленного сбора данных из системы;

е) проверка контрольного следа.

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

Валидация глобальных систем

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

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

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

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

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

Валидация "облачных" систем

252. При использовании "облачных" или "виртуальных" сервисов следует уделять внимание пониманию предоставляемых услуг, владению, извлечению, хранению и безопасности данных.

253. Обязанности заказчика системы (регулируемой компании) и исполнителя (поставщика IT-услуг) определяются техническим соглашением или договором. Соглашение должно обеспечивать своевременный доступ к данным (включая метаданные и контрольные журналы) владельцу данных и национальным компетентным органам по запросу. Контракты с поставщиками определяют ответственность за архивирование и непрерывную читаемость данных в течение всего периода хранения.

254. В настоящее время регулируемым компаниям представляются следующие виды услуг:

а) программное обеспечение как услуга (Software-as-a-Service, SaaS). Регулируемые компании используют приложения, работающие на инфраструктуре, принадлежащей поставщику IT-услуг. Регулируемые компании не управляют и не контролируют базовую инфраструктуру или даже отдельные возможности приложений, за исключением ограниченных пользовательских параметров конфигурации приложений;

б) платформа как услуга (Platform-as-a-Service, PaaS). Регулируемые компании используют IT-инфраструктуру, размещенную поставщиком IT-услуг, для запуска приложений, созданных с использованием операционных систем, языков программирования и инструментов, поддерживаемых поставщиком IT-услуг. Регулируемые компании не управляют и не контролируют базовую облачную инфраструктуру, включая сеть, серверы, операционные системы или хранилище, но по-прежнему контролируют развернутые приложения и, возможно, конфигурации среды размещения приложений;

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

255. Надежность компьютеризированной системы, используемой регулируемой компанией, всегда находится в зоне ответственности регулируемой компании, которой следует документировать соответствующий процесс валидации, используя документацию, представленную поставщиком системы.

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

а) оценка поставщика выполнена на месте и до определения стратегии валидации в плане валидации. Метод оценки поставщика основан на риске, связанном с системой;

б) план валидации учитывает результаты этапа оценки поставщика;

в) документация по валидации может использовать спецификации, документацию по квалификации монтажа (IQ) и функционирования (OQ), предоставленную поставщиком, если эти документы будут признаны адекватными при оценке поставщика;

г) эффективный статус соглашения об уровне обслуживания проверен на этапе тестирования IQ;

д) квалификация эксплуатации (приемочный тест пользователя (User Acceptance Test UAT)) выполняется конечным пользователем регулируемой компании, проверяющим, что система работает по назначению пользователя (на основе спецификации требований пользователей) во всех предполагаемых рабочих диапазонах.

257. Выбор систем осуществляется на основе надежной оценки поставщиков по всем аспектам предоставляемых услуг. Допускается привлекать консультантов, обладающих знаниями в области IT, для эффективного тестирования "облачного" программного обеспечения, платформы и инфраструктуры, а также для проверки соответствия и управляемости "облачного" приложения. Аудит IT-безопасности должен быть ориентирован как минимум на следующие аспекты:

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

технические ошибки и ошибки хостинга;

ошибки, связанные с нарушениями защиты;

ошибки в программном обеспечении;

проблемы резервного копирования и восстановления и (или) выполнения плана аварийного восстановления;

б) безопасность авторизации и требования по разделению обязанностей;

в) процесс управления изменениями для улучшений, исправлений, обновлений;

г) требования к хранению контрольного следа и журнала событий (Event Log);

д) механизм управления доступом;

е) механизм идентификации и аутентификации;

ж) механизм шифрования;

з) квалификация инфраструктуры (даже если инфраструктура управляется третьей стороной);

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

258. "Облачные" приложения рассматриваются только как соответствующие категориям 4 или 5 по классификации категорий компьютеризированных систем, указанной в пункте 148 настоящего Руководства. С точки зрения регулируемой организации конфигурацию "облачных" приложений, следует рассматривать как соответствующую категории 4, в то же время любую пользовательскую разработку интерфейсов или передачи данных, влияющих на GMP, связанную "облачным" приложением, следует рассматривать как соответствующую категории 5 и испытать соответствующим образом.

259. Если "облачная" инфраструктура (IaaS и PaaS) была выбрана для реализации, следует убедиться, что она соответствующим образом квалифицирована поставщиком и (или) регулируемой компанией в соответствии с пунктами 265 - 272 настоящего Руководства.

Валидация электронных таблиц

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

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

262. Категория таблицы Excel по категоризации компьютеризированных систем, приведенной в пункте 148 настоящего Руководства, зависит от типа операций, которые выполняются с GMP-данными в этой таблице и определяется следующим:

а) категория 3 (не конфигурированная) - электронная таблица просто использует собственные функции без конфигурации (например, данные валидации, условное форматирование);

б) категория 4 (конфигурированная) - электронная таблица выполняет вычисления с помощью настроенных формул, а также формул, использующих основные функции Excel (например, сложение, вычитание, деление);

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

263. Каждая система электронных таблиц используется с учетом следующих факторов:

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

б) настройка безопасности доступа и проверки авторизации (например, создание электронной таблицы Excel в выделенной папке с правами доступа, определенными для всех пользователей электронной таблицы);

в) выполнение любых вычислений, связанных с точностью, отображаемой на экране и в отчетах;

г) использование переменных электронной таблицы (в Microsoft Excel называемых "именами"), дающих возможность создания формулы (например, вместо включения в формулу ссылки на ячейку A4 определить A4 именем "количество" и включить строку "Количество" в формулу);

д) обеспечение правильности выполнения резервного копирования (для электронных таблиц, хранящихся в локальных каталогах);

е) защищенность "привязки" ко времени, включая часовой пояс;

ж) проверка того, что заполненная таблица сохраняется в нередактируемом файле (например, в формате PDF);

з) при использовании таблицы как шаблона настройка обеспечивает ее сохранение только в защищенной папке.

264. Результаты жизненного цикла валидации, описанные в пунктах 160 - 219 настоящего Руководства, создаются для каждой таблицы, при этом некоторые документы могут быть объединены вместе (например, единый документ, описывающий функциональные требования спецификации требований пользователей URS/FS).

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

266. Квалификация инфраструктуры обеспечивает документированную верификацию правильности работы и контролируемого статуса IT-инфраструктуры.

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

268. С процессом квалификации компонентов IT-инфраструктуры связаны следующие этапы:

а) планирование - для выполнения требуемых действий, обязанностей, процедур и сроков, с гарантией, что квалификационные мероприятия выполняются систематическим и контролируемым образом, на основе предопределенной стратегии;

б) разработка спецификации и создание проекта IT-инфраструктуры, который подробно описывает аппаратную и программную структуру компонентов IT-инфраструктуры, подлежащих квалификации, с гарантией, что документация, связанная с IT-инфраструктурой, организована и интегрирована, чтобы быть легкоуправляемой и контролируемой;

в) тестирование, чтобы убедиться, что IT-инфраструктура обеспечивает надежную и точную работу;

г) подготовка отчетности по результатам квалификации для подведения итогов мероприятий по квалификации;

д) функционирование IT-инфраструктуры, статус "квалифицировано".

269. Следующие виды деятельности рассматриваются как обязательные для IT-инфраструктуры, относящегося к GMP:

а) оценка влияния на GMP;

б) план квалификации и отчетность;

в) проектная спецификация;

г) испытания при квалификации монтажа (IQ) и функционирования (OQ);

д) вспомогательные процессы;

е) управление изменениями;

ж) управление конфигурацией;

з) резервное копирование и восстановление;

и) защита инфраструктуры;

к) управление инцидентами.

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

271. Процесс квалификации IT-инфраструктуры, предусмотренный Правилами GMP, следует осуществлять в соответствии со специальным планом.

272. Квалификация IT-инфраструктуры является необходимым предварительным условием валидации программного обеспечения, которая выполняется в IT-инфраструктуре.