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

Документы валидации платформы и исследования: как делается каждый, версии, кто подписывает, ZIP и TMF.

Валидационный пакет собирает все документы валидации компьютеризированной системы по GAMP 5: от плана валидации и требований пользователя до протоколов IQ и OQ, матрицы прослеживаемости, итоговых отчётов и сертификата. Большинство из них портал пишет сам из своих данных, хранит их версии и подписи и отдаёт весь пакет одним ZIP. Пакетов два: пакет платформы, который делается один раз на установку, и пакет каждого исследования.

Кто его видит

Пакет платформы находится в меню портала, раздел «Валидационный пакет», для людей, которым Владыка портала дал доступ лично или через группу (см. «Управление доступом»). Пакет исследования есть в меню исследования для участников с правом на документы исследования: чтобы скачать, достаточно чтения, чтобы делать и подписывать, нужно право редактировать документы, а чтобы утверждать — право их утверждать. Пакет исследования ведётся в его QA-среде: именно там валидируется сборка исследования. Там строится eCRF и все её версии, каждый кандидат проходит там свой UAT, и там же пакет делается и утверждается. Затем «Выпустить в продакшн» переносит провалидированного кандидата в продакшн, где он сразу становится рабочим: на проде ничего не валидируется. Пункт меню в продакшне и в учебной среде ведёт к пакету в QA. В продакшне пакет не делается и не подписывается, даже в старом исследовании, созданном до QA-сред: его страница пакета объясняет, что валидация идёт в QA, и ведёт на «Версии eCRF», где QA-среда создаётся. Документы, которые прошлые выпуски по ошибке держали в продакшне, переносятся в QA-среду исследования один раз (при установке выпуска или когда у старого исследования появляется QA-среда), с записью в журнал аудита; после этого в продакшне пакета нет.

Чек-лист

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

«Сделать» пишет документ из текущих данных. Если ничего не изменилось, новой версии не будет. «Сделать всё» пишет все документы на выбранном языке; для платформы это идёт в фоне. «ZIP» скачивает текущую версию каждого документа с описью и контрольными суммами SHA-256; ZIP исследования включает и пакет платформы. Файл 00_contents.txt в ZIP перечисляет документы с их другими названиями и называет те, что ещё не сделаны: чтобы пакет был полным, нажмите «Сделать всё» и скачайте ZIP снова.

Под названием документа видны его другие названия, принятые в СОП других компаний: FRS — это SRS (спецификация требований к программе), OQS — TSR (Test Summary Report), протоколы IQ-VM и IQ-APP — IQs, итоговые отчёты VSR-S и VSR-C — VSR, матрица TM — RTM. Поиск в верхней строке находит пакет и по этим названиям.

Версии и подписи

Новый документ получает версию 0.1, следующий черновик — 0.2, первый утверждённый — 1.0. Каждая версия хранится в PDF и Word вместе с данными, из которых она напечатана. Можно загрузить и свою версию (например, план, который ваша компания написала в своём шаблоне).

Версию подписывают e-mail и паролем по порядку: составил, проверил, утвердил. Автор не может проверить или утвердить ту же версию. Документы поставщика подписывают только люди, которых Владыка портала указал в блоке «Кто подписывает за поставщика»; документы клиента — только все остальные. Поэтому поставщик никогда не утвердит документ клиента за клиента: документ клиента считается утверждённым только после подписи самого клиента.

Протоколы и скриншоты

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

Откуда данные

Документы платформы пишутся из требований с их рисками, ручных документов валидации поставщика и результатов автотестов и проверок кода сборки, которые лежат в архиве выпуска. Если к серверу не приложен прогон тестов, страница так и говорит, а отчёты о тестах пишут, что прогона нет. Сертификат в итоговом отчёте поставщика выдаётся, только когда выполнены все критерии: все тесты пройдены, IQ и OQ выполнены без ошибок, все остальные документы поставщика утверждены.

Документы исследования пишутся из кандидата eCRF, который валидируется в QA-среде, самого нового (спецификация, проверки, прослеживаемость), прогонов UAT с их шагами и подписями и записи о выпуске каждой версии в продакшн. Спецификация кандидата показывает, какой версией продакшна он стал, с отпечатками SHA-256 обоих. Пока пакет не утверждён, форма «Выпустить в продакшн» в QA-среде предупреждает об этом (сколько документов из скольких утверждено), а выпуск с неутверждённым пакетом пишется в журнал аудита.

План сопровождения

План сопровождения системы (SMP) описывает, как система остаётся в валидированном состоянии с допуска к работе до вывода из эксплуатации, по GAMP 5 (второе издание) и Annex 11: резервное копирование и проверка восстановления, непрерывность работы и восстановление после аварии, обновления и управление изменениями, исправления безопасности, мониторинг, инциденты и CAPA, периодический обзор, пересмотр доступа пользователей, архивирование, вывод из эксплуатации, роли и график. Портал пишет его по данным установки: расписание и срок хранения резервных копий из скриптов установки, есть ли свежая копия, периодические задачи, проверку цепочки аудита, выпуски и процедуру управления изменениями, людей, подписывающих за поставщика. Если свежей копии нет, план говорит об этом красным. Чего система знать не может (сроки ответа, кто хранит ключ, частота проверки восстановления), оставлено в квадратных скобках; таблица проверок восстановления заполняется при каждой проверке.

В исследовании это план клиента для сборки исследования в эксплуатации: изменения eCRF через QA-среду и UAT, проверка доступа команды, целостность данных, периодический обзор, закрытие, архив и хранение. Его составляет и утверждает клиент; демо-исследование показывает его утверждённым.

Отправка в TMF

В исследовании с включённым eTMF кнопка «Отправить в TMF» кладёт все сделанные документы пакета исследования и пакета платформы в eTMF исследования. Каждый документ попадает в свой артефакт TMF (например, спецификация eCRF — в «Спецификацию CRF», документы платформы — в «Валидацию компьютеризированной системы») и проходит правила контроля качества eTMF. При повторной отправке новая версия появляется только у изменившихся документов; итог записывается в аудит.

Что остаётся за вами

Сгенерированный документ — черновик, пока люди не проверят и не подпишут его: портал не валидирует систему за вас. План валидации, утверждение URS клиентом, приёмочное тестирование и итоговый отчёт клиента — решения вашей компании по вашим СОП.