GAMP 5

Эта тема является частью SG Systems Global Библиотека руководств по нормативным требованиям и операционной деятельности.

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

Обновлено в январе 2026 г. • gamp 5, csv, тестирование на основе рисков, участие поставщиков, валидация жизненного цикла, часть 11, приложение 11 • Межотраслевое взаимодействие

GAMP 5 (Good Automated Manufacturing Practice, 5th edition) — это наиболее часто используемая в отрасли система для применения риск-ориентированного подхода к валидации компьютерных систем (CSV) . Проще говоря, это способ, с помощью которого регулируемые организации доказывают пригодность компьютерной системы для предполагаемого использования , не тратя месяцы на «тестирование всего подряд», и как они обеспечивают достоверность доказательств во время аудитов, расследований, отклонений и событий, связанных с качеством продукции.

Стандарт GAMP 5 важен, потому что современное производство работает на основе программного обеспечения. Основной рецепт — это объект конфигурации. «Отчет» может определять решение о выпуске продукта. Рабочий процесс определяет, будет ли исключение перехвачено или незаметно проигнорировано. Роль доступа может определять, может ли человек самостоятельно утверждать изменения. Если эти механизмы контроля слабы — или если они изменяются без контроля изменений — вы рискуете не только простоем, но и принятием ненадежных решений по продукту и созданием ненадежных записей.

Именно поэтому GAMP 5 неотделим от целостности данных . Главное преимущество проверенной системы заключается не в том, что «система никогда не подводит». Суть в том, что при использовании системы по назначению она выдает надежные результаты и достоверные доказательства, подкрепленные журналами аудита , контролируемым доступом и заслуживающими доверия, подлежащими проверке записями.

«Проверка — это не доказательство совершенства программного обеспечения. Это доказательство того, что использование вами этого программного обеспечения контролируется».

1) Что на самом деле означает GAMP 5

По своей сути, GAMP 5 — это практическое решение практической проблемы: компьютерные системы слишком сложны для проверки методом перебора. Правильный вопрос не в том, «проверили ли мы каждую функцию?», а в том, «проверили ли мы то, на что полагаемся, и доказали ли мы эффективность средств контроля, обеспечивающих качество и достоверность доказательств?»

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

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

Наконец, стандарт признает, что вы редко создаете все самостоятельно. Поставщики и интеграторы имеют значение. GAMP 5 призывает вас использовать документацию и тесты поставщиков там, где это уместно, — при этом гарантируя, что вы сохраняете ответственность за предполагаемое использование, принятие решений по рискам и приемку системы в вашей среде.

2) Почему GAMP 5 не подлежит обсуждению

GAMP 5 популярен не потому, что он академический. Он популярен потому, что соответствует тому, как на самом деле осуществляется регулируемая работа: системы меняются, интеграция развивается неравномерно, люди импровизируют, а доказательства анализируются постфактум. Система может «работать» в операционном плане и при этом не соответствовать нормативным требованиям, потому что ее записи неполны, не поддаются идентификации или не могут быть восстановлены.

Четыре форсирующие функции делают неизбежным подход в стиле GAMP:

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

3) GAMP 5 против CSV против Части 11 / Приложения 11

Эти термины часто путают, и эта путаница отнимает время. Вот удобная схема:

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

4) Основные принципы, лежащие в основе подхода

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

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

5) Категоризация систем и то, что она меняет.

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

Простой способ представления информации о категориях — это таблица с типами систем, примерами и типичными условиями проверки:

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

6) Результаты жизненного цикла и отслеживаемость

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

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

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

Формулировки квалификаций часто помогают структурировать доказательства. Многие команды соотносят проверки с IQ (правильная установка) и OQ (работает как положено), а затем подтверждают предполагаемое использование с помощью UAT или тестов, ориентированных на процесс. Название менее важно, чем цель: доказать правильную сборку, доказать правильную функцию и доказать правильное использование в вашем процессе.

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

7) Тестирование на основе оценки рисков: что тестировать и почему.

Тестирование на основе оценки рисков — это то, где GAMP 5 экономит время и повышает качество. Цель состоит не в сокращении количества тестов, а в проведении правильных тестов: тех, которые доказывают, что система контролирует процесс и защищает доказательства.

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

Чтобы сделать «оценку на основе рисков» реальной (а не просто лозунгом), свяжите оценку с процессом. Начните с регулируемых решений, которые поддерживает система: выпуск, задержка, утилизация, расчеты и создание или изменение контролируемых записей. Затем задайте три прямых вопроса: (1) если это не удастся, каково будет влияние на качество продукции или безопасность пациента/клиента, (2) обнаружим ли мы сбой до того, как продукция покинет контроль, и (3) можем ли мы восстановить произошедшее, основываясь только на записях системы? Ответы на эти вопросы значительно улучшат глубину тестирования, чем предположения, основанные на названиях модулей.

Когда у команд возникают трудности, это обычно происходит из-за того, что оценка рисков оторвана от контроля за доказательствами. Простая таблица «контроль-цель» помогает сохранить связь с реальностью и наглядно показывает, какие тесты нельзя пропускать:

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

8) Вовлечение поставщика без потери контроля.

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

Практические рычаги влияния поставщиков включают в себя:

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

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

9) Управление исправлениями, обновлениями и расхождениями в конфигурации.

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

Три параметра обеспечивают стабильность проверенного состояния:

• Смени управление: Перед внедрением изменения оцениваются, утверждаются, тестируются и документируются.
• Ревизионный контроль: Базовые конфигурации, скрипты и ключевые спецификации имеют версии и доступны для восстановления.
• Стратегия регрессионного анализа: Каждое изменение имеет определенную область регрессии; «мы не думали, что это повлияет на это» — это не оправдание.

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

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

10) Целостность данных, журналы аудита и электронные подписи

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

К числу наиболее важных проверок целостности относятся:

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

Эти меры контроля соответствуют ожиданиям, обычно связанным с 21 CFR Часть 11 и Приложением 11 , но суть не ограничивается лишь соблюдением требований. Суть в том, что когда что-то идет не так, вы можете восстановить истину, не полагаясь на память или неформальные электронные таблицы.

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

11) Гибкие, облачные, SaaS и современные модели предоставления услуг.

GAMP 5 иногда ошибочно называют «каскадной валидацией». Это недоразумение. Данная методология совместима с гибкими и современными подходами к разработке, если сохранять основные принципы: четко определенные требования, тестирование на основе рисков, контролируемые релизы и отслеживаемые доказательства.

Практические решения, которые работают:

• Итеративный URS: Определите предполагаемое применение на раннем этапе и уточняйте его с помощью контролируемых изменений; поддерживайте базовый уровень ниже определенного значения. контроль версий.
• Доказательства непрерывного тестирования: Используйте автоматизированные средства проверки там, где они надежны, но убедитесь, что они поддаются проверке и связаны с требованиями.
• Валидация на основе релизов: Рассматривайте каждый релиз как контролируемое изменение; перед продвижением по службе проведите регрессионный анализ на основе оценки рисков.
• Карта ответственности за облачные технологии: Определите, что контролирует поставщик, а что — вы; проверьте те компоненты, от которых вы зависите.

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

12) Риски, связанные с интерфейсами и интеграцией

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

К числу распространенных интеграций с высоким риском относятся:

• ERP: заказы, подтверждения, движение товаров на складе, статус партии и финансовые проводки.
• LIMS: Результаты, технические характеристики, ссылки на COA и факторы, определяющие дальнейшую судьбу продукта.
• система управления качеством: отклонения, расследования, согласования, задачи корректирующих и предупредительных действий (CAPA) и рабочие процессы внесения изменений.
• Взаимодействие между MES-системой и производственным цехом: интеграционные шлюзы, каналы связи ПЛК и брокеры сообщений, определяющие поведение при выполнении.

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

13) Выход на пенсию, миграция и удержание кадров

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

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

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

14) Ключевые показатели эффективности и оперативный ритм

Программа GAMP 5 должна быть измеримой. Если она не поддается измерению, то, как правило, скатывается либо к бюрократии, либо к пренебрежению. Небольшой набор ключевых показателей эффективности помогает обеспечить честность программы.

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

15) Контрольный список «блочного теста» GAMP 5

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

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

16) Типичные модели отказов

• Тестирование пользовательского интерфейса вместо элементов управления: Проведено сотни проверок экрана, но отсутствует журнал аудита или тестирование ролей.
• URS, записанный после настройки: Требования становятся документом, обосновывающим необходимость их выполнения, а не базовым требованием.
• Данные поставщика игнорируются: Команды повторно тестируют функции с низким уровнем риска, но у них не хватает времени на функции с высоким уровнем риска.
• Доказательства от поставщиков пользуются огромным уважением: Команды принимают тестирование от поставщика без проверки предполагаемого использования и конфигурации.
• Система управления изменениями работает слабо: «Небольшие корректировки» накапливаются до тех пор, пока подтвержденный базовый уровень не станет вымыслом.
• Интерфейсы рассматриваются как своего рода ИТ-инфраструктура: Сбои интеграции приводят к повреждению записей и сбоям в процессе сверки.
• Пенсия не управляется: Системы отключаются, и доступ к записям исчезает.

17) Примеры из разных отраслей

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

• Фармацевтическое производство: Системы MES/EBR и лабораторные системы должны сохранять журналы аудита и предоставлять подтверждающие данные; валидация должна выдерживать частые изменения и расследования (см. Надлежащей производственной практики и ИКН Q10 контекст).
• Медицинское оборудование: Системы производства и контроля качества обеспечивают отслеживаемость на протяжении всего жизненного цикла таких объектов, как DMR и DHRизменения пересекаются с ДХФ и системы контроля качества, таких как стандартами качества ISO 13485 Согласование практик и управления рисками.
• Продукты питания и потребительские товары: Для операций с большим объемом данных необходимы быстрые изменения; проверка на основе оценки рисков предотвращает превращение «скорости» в неконтролируемый дрейф (см. HACCP (где это применимо)
• Высокоавтоматизированные заводы: Интеграционные слои и логика выполнения должны проверяться в рамках предполагаемого использования, а не как нечто второстепенное; это включает в себя потоки данных, которые определяют решения и статус блокировки/разблокировки.

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

18) Расширенные часто задаваемые вопросы

В1. Что такое GAMP 5?
GAMP 5 — это основанная на оценке рисков система валидации компьютерных систем на протяжении всего их жизненного цикла, обычно используемая для выполнения различных задач. CSV эффективно и оборонительно.

В2. Является ли GAMP 5 нормативным актом?
Нет. Это отраслевые рекомендации. Регуляторы ожидают наличия проверенных систем; GAMP 5 — это практический метод, который многие организации используют для выполнения этих требований с применением строгого подхода, основанного на оценке рисков.

В3. Что означает «на основе оценки рисков» в контексте валидации?
Это означает, что вы сосредотачиваете свои технические требования и тестирование на функциях, отказ которых может нанести вред качеству продукции, безопасности пациентов/клиентов или целостности документации. Функции с низким риском получают менее убедительные доказательства; функции с высоким риском требуют более глубокого тестирования и анализа.

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

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

Вопрос 6. Как GAMP 5 соотносится с Частью 11 и Приложением 11?
GAMP 5 — это метод проверки; Часть 11 и Приложение 11 Ожидания в отношении электронных записей весьма высоки. Надежный подход GAMP 5 включает в себя проверку журналов аудита, контроль доступа, электронные подписи и хранение записей для защиты доверия к электронным доказательствам.

В7. Какой самый распространенный вид отказа в рамках GAMP 5?
Рассматривайте валидацию как набор документов, а не как контрольный механизм. Если управление изменениями слабое, конфигурация отклоняется от заданного значения, а средства контроля доказательств не проверяются, «валидированное состояние» становится фикцией.

Связанные Чтение
• Ядро валидации: CSV | ВМП | УРС | IQ | OQ | UAT
• Управление: Управление изменениями | MOC | Документ контрольный | Контроль версий
• Добросовестность + Доказательства: Целостность данных | Алкоа | Аудиторский след (GxP) | Электронные подписи
• Контекст электронных записей: 21 CFR Часть 11 | Приложение 11 | Правило предиката
• Системный контекст: МЧС | EBR | LIMS | система управления качеством