GAMP 5

Ця тема є частиною SG Systems Global бібліотека посібників з нормативних актів та операцій.

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

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

GAMP 5 (Good Automated Manufacturing Practice, 5-е видання) – це найпоширеніша галузева структура для застосування ризик-орієнтованого мислення до валідації комп’ютерних систем (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 5 можна узагальнити кількома принципами роботи. Коли команди «правильно виконують 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 повинна чітко перевіряти атрибути цілісності даних та засоби контролю електронних записів.

Важливі перевірки цілісності включають:

• Віднесення: дії пов’язані з унікальними користувачами; спільні облікові записи заборонені або жорстко контролюються.
• Повнота журналу аудиту: Система записує критичні події створення/зміни/видалення та може створювати їх на вимогу (журнали аудиту).
• Контроль часу: Позначки часу є узгодженими та захищеними; зміни часу контролюються та реєструються.
• Значення підпису: електронні підписи прив'язуються до дій та зберігають значення з часом.
• Зберігання та пошук записів: записи залишаються доступними та читабельними протягом встановлених періодів зберігання.
• Цілісність експорту даних: експортовані дані є повними та не фільтруються вибірково без можливості відстеження.

Ці засоби контролю відповідають очікуванням, які зазвичай пов'язані з 21 CFR Частина 11 та Додаток 11 , але суть ширша, ніж просто відповідність. Суть полягає в тому, що коли щось йде не так, ви можете відновити правду, не покладаючись на пам'ять чи неформальні електронні таблиці.

Більшість організацій також закріплюють мислення щодо доброчесності в таких принципах, як ALCOA . Якщо система підриває поняття «атрибутивна», «сучасна» або «оригінальна», вона може бути функціональною, але все одно не підлягати захисту.

11) Agile, хмарні, SaaS та сучасні моделі доставки

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

Практичні адаптації, які працюють:

• Ітеративний URS: визначити цільове використання на ранній стадії та уточнити його за допомогою контрольованих переглядів; підтримувати базовий рівень нижче контроль версій.
• Докази безперервного тестування: використовуйте автоматизовані тестові дані, де вони надійні, але переконайтеся, що вони доступні для перегляду та пов'язані з вимогами.
• Перевірка на основі релізу: розглядайте кожен реліз як контрольовану зміну; перед просуванням виконуйте регресійний аналіз на основі ризиків.
• Карта відповідальності за хмарні технології: визначте, що контролює постачальник, а що контролюєте ви; перевірте деталі, на які ви покладаєтеся.

Для low-code інструментів та електронних таблиць ризик полягає не в технології, а у відсутності контролю. Електронна таблиця, яка використовується для розрахунку результатів релізу, на практиці є регульованою системою, навіть якщо ІТ-відділ ніколи її не схвалював. Застосовуйте ту саму логіку GAMP: цільове використання, оцінка ризиків, контроль версій, контроль доступу та перевірка формул. Якщо ви не можете контролювати це, не слід покладатися на це для прийняття рішень.

12) Ризики інтерфейсів та інтеграції

Інтерфейси – це те місце, де перевірені системи часто непомітно дають збій. Основна програма може бути перевірена, але рівень інтеграції дублює транзакції, пропускає повідомлення або змінює порядок подій таким чином, що це спотворює істину. У пов'язаних операціях інтерфейс є частиною перевіреної функції.

До поширених інтеграцій з високим рівнем ризику належать:

• ERP: замовлення, підтвердження, рух запасів, стан партій та фінансові проводки.
• LIMS: результати, специфікації, посилання на сертифікати справжності та фактори, що впливають на утилізацію.
• еСМК: відхилення, розслідування, затвердження, завдання CAPA та зміни в робочих процесах.
• Підключення MES та виробничого цеху: шлюзи інтеграції, зв'язки PLC та брокери повідомлень, що керують поведінкою виконання.

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

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

GAMP 5 – це перевірка життєвого циклу, яка включає завершення терміну служби. Виведення з експлуатації є подією з високим ризиком, оскільки воно часто порушує доступ до записів. Якщо ви виводите систему з експлуатації, а потім не можете отримати записи для розслідування, ви постфактум створюєте порушення відповідності.

Виведення з експлуатації має регулюватися як зміна: визначте, які записи необхідно зберігати, як до них буде здійснюватися доступ і як ви будете доводити повноту. Це пов’язано з практиками архівування та зберігання даних . Правильний результат – це не «стара система вимкнена». Правильний результат – це «записи залишаються доступними, читабельними та відстежуваними протягом усього періоду зберігання, з тим самим значенням, яке вони мали під час створення».

Для міграцій слід розглядати зіставлення та трансформацію даних як частину перевіреної області застосування. Міграція — це не просто копіювання таблиць, це збереження значення. Якщо запис змінює форму, необхідно показати, що значення та можливість аудиту були збережені, а сама міграція контролювалася за допомогою управління змінами.

14) Ключові показники ефективності (KPI) та операційний ритм

Програма GAMP 5 повинна бути вимірюваною. Якщо її не можна виміряти, вона має тенденцію до бюрократії або занедбаності. Невеликий набір ключових показників ефективності (KPI) допомагає зберегти чесність програми.

Каденція має значення. Середовища з високим рівнем змін повинні перевіряти стан валідації частіше, ніж стабільні середовища. Суть полягає в тому, щоб виявити, коли валідація не відповідає реальності, тому що реальність не чекатиме на ваш наступний щорічний огляд.

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

Якщо вам потрібна швидка та безжальна перевірка справжності вашої програми, використовуйте блоковий тест. Він зосереджений на поведінці, яка спричиняє більшість збоїв валідації: неконтрольовані зміни, слабка відстежуваність та ігнорування засобів контролю доказів.

Якщо цей контрольний список не відповідає вимогам, розглядайте це як провал у корпоративному управлінні. Валідація – це контроль. Контролі, які не функціонують належним чином, є проблемами якості.

16) Типові моделі несправностей

• Тестування інтерфейсу користувача замість елементів керування: сотні перевірок екрана, але жодного журналу аудиту чи рольових тестів.
• URS, написаний після налаштування: вимоги стають обґрунтовувальним документом, а не базовим.
• Докази постачальника ігноруються: команди повторно тестують функції з низьким рівнем ризику та не мають часу на ті, що мають високий ризик.
• Докази постачальника поважаються: команди приймають тестування постачальників без перевірки цільового використання та конфігурації.
• Контроль змін слабкий: «Невеликі корективи» накопичуються, доки перевірена базова лінія не стане вигадкою.
• Інтерфейси розглядаються як ІТ-сантехніка: збої інтеграції пошкоджують записи та узгодження.
• Вихід на пенсію не є керованим: системи вимикаються, і доступ до записів зникає.

17) Міжгалузеві приклади

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

• Фармацевтичне виробництво: Системи MES/EBR та лабораторні системи повинні зберігати журнали аудиту та публікувати докази; валідація повинна витримувати часті зміни та розслідування (див. GMP та ICH Q10 контекст).
• Медичні прилади: Системи виробництва та якості підтримують відстеження артефактів життєвого циклу, таких як DMR та DHR; зміни перетинаються з DHF та системи контролю якості, такі як ISO 13485 узгодження практик та управління ризиками.
• Харчові продукти та споживчі товари: для операцій з великим обсягом роботи потрібні швидкі зміни; перевірка на основі ризиків запобігає перетворенню «швидкості» на неконтрольований дрейф (див. HACCP стиль мислення, де це можливо).
• Високоавтоматизовані установки: Інтеграційні рівні та логіка виконання повинні бути перевірені як частина цільового використання, а не як другорядна думка; це включає потоки даних, які впливають на рішення та статус утримання/вивільнення.

Спільний урок: перевірена система є настільки надійною, наскільки надійними є засоби контролю навколо неї, особливо контроль змін та цілісність доказів.

18) Розширені поширені запитання

Q1. Що таке GAMP 5?
GAMP 5 — це система, що базується на ризиках, для перевірки комп’ютеризованих систем протягом їхнього життєвого циклу, яка зазвичай використовується для виконання CSV ефективно та захищено.

Q2. Чи є GAMP 5 нормативним актом?
Ні. Це галузеві рекомендації. Регулятори очікують перевірених систем; GAMP 5 — це практичний метод, який багато організацій використовують для виконання цих очікувань із ретельністю, що базується на ризиках.

Q3. Що означає «на основі ризику» у валідації?
Це означає, що ви зосереджуєте свою специфікацію та тестування на функціях, збій яких може зашкодити якості продукту, безпеці пацієнтів/клієнтів або цілісності записів. Функції з низьким рівнем ризику отримують меншу кількість доказів; функції з високим рівнем ризику проходять глибше тестування та перегляд.

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

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

Q6. Як GAMP 5 пов'язаний з Частиною 11 та Додатком 11?
GAMP 5 — метод перевірки; Частина 11 та Додаток 11 є очікуваннями щодо електронних записів. Надійний підхід GAMP 5 включає перевірку журналів аудиту, контроль доступу, електронні підписи та зберігання записів для захисту довіри до електронних доказів.

Q7. Який найбільший режим відмови GAMP 5?
Розгляд валідації як набору документів, а не як елемента керування. Якщо контроль змін слабкий, конфігурація зміщується, а елементи керування доказами не тестуються, «валідований стан» стає фікцією.

Пов'язане читання
• Ядро валідації: CSV | ВМП | УРС | IQ | OQ | UAT
• Управління: Контроль змін | MOC | Документ контрольний | Ревізійний контроль
• Чесність + Докази: цілісність даних | АЛКОА | Аудиторський журнал (GxP) | Електронні підписи
• Контекст електронних записів: 21 CFR ч. 11 | Додаток 11 | Правило предиката
• Системний контекст: МНС | ЄБР | LIMS | еСМК