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

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

Рекомендации
по аудиту/инспектированию использования компьютеризированных систем в организации

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

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

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

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

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

* Для автоматизированного поиска требований в текстах документов надлежащих практик GxP могут быть использованы следующие ключевые слова: документ (document), спецификация (specification), регламент (formula), процедура (procedure), запись (record), данные (data), журнал (log book), инструкция (instruction), письменно/документально (written), подписывать/утверждать (sign), согласовать (approve), письменная (writing), подпись (signature), документация (documentation), авторизация/доступ (authorisation).

Таблица А.1 - Перечень информации о компьютеризированных системах, собираемых перед проведением аудита/инспекции

1 Подробное описание организации и управления ИТ/компьютерными службами и инженерными проектами на проверяемой производственной площадке

2 Политики организации по поставкам компьютерного оборудования, ПО и систем для использования в условиях надлежащих практик GxP

3 Политики организации в отношении валидации КС, используемых в условиях надлежащих практик GxP

4 Перечень стандартов и письменных процедур (стандартных операционных процедур), используемых ИТ/компьютерными службами

5 Порядок управления проектами и процедуры, применявшиеся при разработке различных приложений

6 Выявленные работы по поддержке и обслуживанию систем, передаваемые на аутсорсинг на постоянной основе

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

8 Перечень выявленных систем, подсистем и модулей и/или программ, которые могут оказывать влияние на соответствие надлежащим практикам GxP и качестве продукта/безопасности пациентов. Необходимо сопоставить данный перечень с перечнями, указанными в пункте 6

9 Для критических с точки зрения GxP элементов и систем, выделенных в пункте 7, необходимо получить информацию, указанную в пунктах 10-17

10 Подробное описание ситуаций отказа-восстановления работы системы, резервного копирования, смены контроля, информационной безопасности и управления конфигурацией

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

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

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

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

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

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

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

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

На основании представленной перед инспекцией информации (см. таблицы А.2, А.3, А.4, А.5, А.6) аудиторы/инспектора выбирают критические с точки зрения GxP КС и изучают данные о валидации этих систем, а затем результаты текущего операционного контроля о состоянии системы и ее валидности. Учитывая распределенную ответственность за GxP-аспекты коммерческих или бизнес ИТ-систем (различных подразделений) и процессов более низких уровней контрольных систем, следует изучить преемственность и целостность ответственности и согласованность инструкций и процедур.

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

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

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

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

- квалификация эксплуатации - проверка критериев спецификации требований пользователей;

- квалификация функционирования - проверка функциональной спецификации;

- квалификация монтажа - проверка спецификации проекта или обзорного проекта;

- отчеты об аудите поставщиков;

- валидационные и "квалификационные" планы, то есть основной валидационный план или политика.

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

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

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

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

Следует проверить соблюдение всех требований надлежащих практик GxP в выбранных для проверки валидационных проектах.

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

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

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

Таблица А.2 - Опросник аудитора/инспектора по программному обеспечению

Этап жизненного цикла	Деятельность на текущем этапе	Свидетельство
1 Разработка	Разработка спецификаций требований пользователя/функциональных спецификаций/спецификаций проекта	Документация спецификаций требований пользователя/функциональных спецификаций/спецификаций проекта
	План тестирования	План тестирования и сценарии тестирования
	Документирование плана тестирования	Письменные документы, описывающие порядок проведения тестирования
2 Внедрение	Выбор языка программирования и инструментария	Документация, описывающая выбор языка программирования
	Написание/создание ПО	Документированный исходный код с комментариями; пояснение функций; входные данные и ожидаемые выходные данные для каждого структурного модуля. Описание взаимного влияния модулей. Если программа приобретена, то каким образом гарантирован доступ к исходному коду?
3 Тестирование (модули)	Обеспечение того, что каждый модуль принимает только допустимые входные данные и выдает только допустимые выходные данные. Тестирование должно выявлять некорректные данные и логические ошибки	Образцы отчетов о тестировании (при наличии). Включало ли тестирование испытания с пограничными значениями и ввод некорректных данных? Все ли тесты были задокументированы? Все ли ошибки/сбои расследованы?
Тестирование (интегрированные модули)	Те же тесты, проведенные после интеграции модулей	Те же свидетельства. Если программа была приобретена, то доказательства валидации должны быть оценены регулируемым пользователем
4 Техническое обслуживание	Исправление ошибок, обновление версий (по необходимости)	Утвержденный порядок действий и записи, относящиеся к управлению конфигурациями и управлению изменениями. Регрессивное тестирование и периодическая оценка (в процессе внесения изменений в систему на протяжении определенного отрезка времени)
5 Документация	Системная документация (в т.ч. на ПО) корректна и актуальна	Руководства пользователей, вспомогательные СОП, правильные версии
6 Повторная валидация	Повторная валидация после внесения в программу изменений	Изменения проанализированы, решения задокументированы. Существует и описан порядок действий и записи; их масштаб зависит от размера/сложности изменений
7 Прочее	На случай сбоев в системе существуют пути их обхода; это учтено при обучении	Альтернативные пути задокументированы, существуют записи об обучении

Таблица А.3 - Опросник аудитора/инспектора по валидации компьютеризированных систем

Элемент	Проверка мер контроля
1 Описание	Система описана? Каковы ее функции? Письменный валидационный план в наличии? Имеются полные спецификации? Письменные протоколы имеются? (включая критерии приемлемости)
2 Тестирование	Записи тестов показывают соответствие спецификациям входных и выходных данных?
3 Документирование результатов	Результаты полные и документально оформлены?
4 Подтверждение правильности данных	Данные и документация полные и правильные? Были ли они проверены организацией?
5 Сопоставление с критериями приемлемости	Валидацию и проверку работ проводил компетентный ответственный персонал? Документальное подтверждение этого имеется?
6 Заключения	Заключения полные, информативные и основы на результатах? Критерии приемлемости выполнены? Дополнительные заключения имеются?
7 Согласование (утверждение)	Согласование (утверждение) оформлено документально? Служба качества (отдел обеспечения качества/контроля качества) организации принимала участие в данной процедуре?
8 Постоянная оценка	Какая процедура существует для обеспечения постоянной оценки системы? Какие процедуры управления изменениями имеются?

Таблица А.4 - Опросник аудитора/инспектора по проверке требований приложения 11 надлежащей производственной практики

Номер [1]	Требование	Отметка/комментарий аудитора/инспектора
Персонал (пункт 6)	Сотрудничество между ответственным персоналом (владельцем процесса, владельцем системы, уполномоченным лицом) и ИТ-специалистами
Персонал (пункт 6)	Персонал имеет надлежащую квалификацию, при необходимости привлекают экспертов
Валидация (пункт 11)	Применение модели жизненного цикла, наличие документации и отчетов
Пункт 12	Регистрация изменений и отклонений предусмотрена
Пункт 13	Наличие актуального перечня (реестра) систем
Пункт 14	Наличие актуального описания критических КС
Пункт 15	Наличие спецификации требований пользователя, созданной на основании оценки рисков
Пункт 16	КС разработана в условиях надлежащей системы управления качества
Пункт 17	Наличие документированной процедуры оценки качества и эксплуатационных характеристик системы
Пункт 18	Проведение тестирования согласно требованиям (пределы параметров системы, границы данных и обработка ошибок)
	Оценка автоматизированных средств тестирования
Пункт 19	Проверка данных в сравнении с предыдущей системой/ручным управлением
Эксплуатация (пункт 20)	Проверка данных и расчетов, встроенных в систему
Пункт 21	Проверка ввода критических данных вторым оператором или валидированным электронным методом
Пункт 22	Физическая и электронная (логическая) защита данных
Пункт 23	Наличие процедуры резервного копирования. Проведение валидации
Пункт 24	Наличие распечаток
Пункт 25	Проверка записи процесса разрешения на выпуск серии на предмет наличия информации о вносимых изменениях, если они были сделаны
Пункт 26	Наличие и проверка контрольных следов
Пункт 27	Внесение изменений в системы и программы в соответствии с процедурой управления изменениями, включая повторную валидацию и утверждения
Пункт 28	Проведение периодической оценки, объем адекватность объема
Пункт 29	Осуществление ввода данных и изменения только авторизированным персоналом. Система управления паролями/ключами
Пункт 31	Наличие записей о создании, изменении и аннулировании прав доступа	Пункт 31
Пункт 32	Система управления данными и документами для идентификации операторов и их действий с указанием дат	Пункт 32
Пункт 33	Записи показывают анализ ошибок и предпринятые корректирующие действия. Наличие отчетов о расследовании с поиском основной причины ошибки (первопричины)	Пункт 33
Пункты 34, 35	Установлены порядок применения электронных подписей и связь подписи с записями. Наличие даты и времени проставления, в том числе на записях процесса выдачи разрешения на выпуск серии в обращение
Пункт 36	Использование альтернативных средств при сбоях предусмотрено, документально оформлено и проверено
Пункт 37	Наличие процедуры архивирования. Подтверждение надежности процедуры восстановления данных (при изменении версии)

Таблица А.5 - Общие вопросы, рассматриваемые при аудите/инспектировании компьютеризированных систем

Раздел	Ключевой вопрос
1 Персонал	В организации одно ответственное лицо за КС? (Зависимость от одного человека может стать катастрофической)
2 Организация	Руководство участвует в управлении системами?
3 Организация	КС включены в область действия системы качества?
4 Система данных	В начале инспекции изучают общую организацию систем, включая потоки данных?
5 Система данных	Использование "параллельных систем" может свидетельствовать о наличии "серых" зон и вероятности несоответствия систем требованиям
6 Валидация	Определения четко сформулированы? Их использование корректно?
7 Безопасность	Как контролируют доступ к системам? Оценка системы управления информационной безопасностью
8 Техническое обслуживание	Наличие руководства по техническому обслуживанию каждой системы с указанием периодичности обслуживания. Наличие соответствующих записей о выполнении данного руководства
9 Контроль системы	Процедуры управления конфигурацией, управление изменениями
10 Самоинспекции	Наличие процедуры самоинспекции и ее проведение

Таблица А.6 - Основные обязанности организации-пользователя (согласно руководству GAMP, см. также 4.6)

Задача	Описание
1 Идентификация системы	Должна быть оценена каждая автоматизированная система и определены системы, подпадающие под требования надлежащих практик GxP
2 Разработка спецификаций требований пользователя	В спецификациях требований пользователя должно быть четко и однозначно указано, что ожидает пользователь от системы (что она должна делать). Должны быть указаны любые ограничения, а также определены регуляторные и документальные требования
3 Определение валидационной стратегии
Оценка рисков	Исходная оценка рисков должна быть проведена на этапе планирования валидации. В дальнейшем оценки должны производить по мере разработки спецификаций
Оценка компонентов системы	Компоненты системы должны быть оценены и разбиты на категории с целью определения требуемого валидационного подхода. Выходные данные этого процесса лягут в основу плана валидации
Оценка поставщика	Поставщики должны быть формально оценены в рамках процесса выбора поставщика и планирования валидации. Необходимость проведения аудита поставщика (или исключения данным этапом) должна быть задокументирована и основана на оценке рисков и категоризации компонентов системы
4 Разработка плана валидации	В плане валидации должны быть указаны действия, процедуры, направленные на подтверждение пригодности системы, и степень ответственности. В плане обычно указывают, какие оценки рисков необходимо осуществлять
5 Анализ и утверждение спецификаций, в т.ч. описания системы	Организация должна проанализировать и утвердить спецификации, разработанные поставщиком
6 Мониторинг разработки системы	Организация должна мониторировать разработку и конфигурирование в соответствии с согласованным планом
7 Анализ исходного кода	Организация должна обеспечить адекватный анализ исходного кода в процессе разработки системы
8 Анализ и утверждение спецификаций тестирования	Организация должна проанализировать и утвердить спецификации до начала официального тестирования
9 Проведение тестирования	Организация может участвовать в тестировании в качестве наблюдателя или рецензента результатов тестирования
10 Анализ и утверждение отчетов о тестировании	Организация должна утвердить отчеты о тестировании и соответствующие результаты тестирования
11 Создание валидационного отчета	В валидационном отчете должны быть приведены все результаты и действия, а также свидетельства того, что система валидирована
12 Обслуживание системы	После принятия системы организация должна разработать надлежащие принципы системного администрирования и производственной деятельности
13 Прекращение эксплуатации	Организация должна управлять процессом замены или выведения автоматизированной системы из эксплуатации