Додаток 11 – Комп’ютеризовані системи (GMP ЄС)

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

Оновлено у жовтні 2025 р. • Належна виробнича практика ЄС, електронні записи та підписи, валідація, цілісність даних • Фармацевтика, біологічні препарати, АТМП, медичні вироби, косметика, харчові добавки

Додаток 11 до GMP ЄС встановлює стандарти для того, як виробники медичної продукції визначають, перевіряють, експлуатують та виводять з експлуатації комп'ютеризовані системи, що впливають на якість продукції та безпеку пацієнтів. Якщо система може змінити результат партії або рішення про її випуск, Додаток 11 підпадає під її дію. Очікування просте та невблаганне: довести придатність до використання за призначенням, контролювати її та зберігати достовірні записи стільки, скільки вони мають значення . Додаток спирається на ризик-орієнтоване мислення ( QRM ), валідацію життєвого циклу ( CSV ) та цілісність даних (ALCOA+), щоб забезпечити повноту, узгодженість та можливість перегляду електронних записів, включаючи eBMR та DHR .

«Якщо це впливає на якість, то це Додаток 11. Покажіть свою логіку, свої засоби контролю та свої докази — або будьте готові зупинити лінію».

1) Сфера застосування — що входить до складу та чому це важливо

Додаток 11 виходить за рамки очевидного стеку MES/LIMS/QMS. Він включає системи маркування ( перевірка етикеток , UDI ), WMS , інтерфейси обладнання ( SCADA , ваги, контрольні ваги) та електронні таблиці, що використовуються для прийняття рішень про випуск. Якщо розрахунок, сканування або підписання впливають на ідентифікацію, міцність, якість, чистоту, простежуваність або статус випуску, це територія Додатку 11. Сфера застосування відповідає 21 CFR Part 11 , але є ширшою щодо життєвого циклу та експлуатації — проектування для обох, якщо ви постачаєте до ЄС та США.

2) Життєвий цикл та валідація — на основі ризиків та доказів

Почніть з плану управління продуктом (VMP) найвищого рівня та захищеного URS . Розробіть функціональні та проектні специфікації, а потім протестуйте їх там, де цього вимагає ризик. Інфраструктура (сервери, хмара, мережі) кваліфікується; конфігурації додатків (рецепти, форми, шаблони етикеток) перевіряються так само, як і код — тому що вони є кодом. Використовуйте QRM для цільового тестування режимів збоїв, які загрожують безпеці пацієнтів, якості продукту або цілісності даних. Ведіть матрицю «живого» трасування: вимога → ризик → контроль → тестування → примітка до випуску. Перевіряйте самі процеси змін та розгортання, а не лише додаток, щоб майбутні оновлення непомітно не порушували відповідність вимогам.

Документація постачальника допомагає, але вона не замінює перевірку користувачами. Відшліфована брошура не є тестовим доказом. Підтвердьте передбачуване використання у вашому середовищі за допомогою обсягів даних, інтеграцій ( ISA‑95 ) та рольової моделі. Для хмарних та багатокористувацьких SaaS встановіть, як постачальник кваліфікує оновлення інфраструктури, надає примітки до випуску та підтримує вашу частоту повторної перевірки без несподіваних простоїв.

3) Ролі, обов'язки та гарантії постачальників

Кожній системі потрібен власник бізнесу (відповідальний за використання та дані), нагляд за якістю та підтримка ІТ-операцій. Визначте, хто може затверджувати зміни, хто переглядає журнали аудиту, хто надає доступ і хто підписує релізи. Для зовнішніх сторін укладіть угоди про якість , які визначають час реагування, маршрутизацію інцидентів, доступ до даних та сповіщення про зміни, порушення та NOC . Проводьте аудит постачальників пропорційно ризику; якщо ваш пакетний реліз залежить від їхнього додатка, вам потрібно розуміти їхній SDLC, тестування та стан безпеки, а не здогадуватися.

4) Цілісність даних — ALCOA+ задумом, а не гаслом

Записи повинні бути такими, що відповідають дійсності, бути розбірливими, сучасними, оригінальними та точними ( ALCOA ) з урахуванням повноти, узгодженості, довговічності та доступності. Налаштуйте журнали аудиту для кожного об'єкта GxP: створення/зміна/видалення, ідентифікація виконавця, причина змін, позначки часу, старі та нові значення. Зробіть їх переглядаємими у визначеній частоті; «журнал аудиту ввімкнено» не має сенсу, якщо ніхто не дивиться. Забороніть неконтрольоване редагування в автономному режимі, експорт/повторний імпорт «виправлень» та тіньові електронні таблиці. Електронні підписи повинні бути однозначно пов'язані з ідентифікатором користувача, точним підписаним вмістом (а не просто хешем у вакуумі) та значенням дії (перегляд/затвердження/перевірка).

Дані пристрою мають значення. Якщо ви знімаєте ваги з ваг або машинний зір позначає дефект, збережіть ідентифікатор джерела, час та стан перевірки. Стан калібрування має бути відомий у момент збору даних; якщо прилад виходить за межі допуску, ваша система повинна автоматично блокувати або поміщати в карантин відповідні партії ( Карантин/Утримання ).

5) Контроль доступу — найменші привілеї або обмеження

Впроваджуйте UAM на основі ролей з унікальними користувачами, багатофакторну автентифікацію (MFA), де це практично, та обмеження в часі підвищення привілеїв. Регулярно перевіряйте доступ та під час змін у персоналі. Жорстке правило: ніхто не схвалює власну роботу. Розділіть розробку, тестування та виробництво. Якщо ваш постачальник пропонує «спільні облікові записи адміністраторів», заперечуйте. Зараз 2025 рік; спільні облікові дані неприйнятні в середовищі GxP.

6) Конфігурація, контент та контроль змін

Ставтеся до конфігурації як до коду: рецепти, шаблони етикеток, посилання на стандартні операційні процедури (SOP) , контрольні списки, обмеження SPC та логіка робочого процесу повинні бути версіоновані, перевірені, протестовані та випущені в рамках контролю змін . Документуйте наміри проектування та ризики, які ви зменшуєте; включіть регресійні тести для критичних шляхів. Виконуйте періодичні перевірки , щоб підтвердити, що перевірений стан, рівень безпеки та дані про інциденти все ще актуальні. У разі сумнівів, повторно перевірте за допомогою цілеспрямованої оцінки впливу, а не кидайте кістки на думці «ймовірно, все гаразд».

7) Інтерфейси та автоматизація — де множаться помилки

Додаток 11 очікує, що ви розумітимете та контролюватимете потоки даних від початку до кінця ( ISA‑95 ): ERP ↔ MES ↔ LIMS ↔ QMS ↔ WMS ↔ маркування/серіалізація. Вказуйте формати повідомлень ( EDI , EPCIS), час, повторні спроби та обробку помилок; перевіряйте на реальних обсягах, а не на іграшкових наборах даних. Для автоматизації — баланси ( гравіметричні ), мікродозування , візуалізація , серіалізація — демонструйте точність, затримку та захист від несанкціонованого втручання. Доведіть логіку маркування за допомогою перевірок етикеток у робочому процесі очищення лінії ( Очищення лінії ).

8) Записи про виконання — eBMR/eDHR без прогалин

Електронні записи історії партій та пристроїв повинні забезпечувати дотримання етапів, фіксувати матеріали та генеалогію партій , застосовувати обмеження специфікацій та вимагати підписів у потрібних точках. Використовуйте подвійну перевірку для дій з високим ризиком. Забороніть випуск, якщо відсутні будь-які необхідні дані, огляд або підпис. Інтегруйте дані про навколишнє середовище та комунальні послуги ( електромеханіку , картографування температури ) та переконайтеся, що журнал аудиту є частиною пакета записів, а не необов'язковим експортом під час перевірки. Для контрольованої повторної обробки чітко пов'язуйте з оцінками відхилень та ризиків.

9) Інциденти, відхилення, CAPA — візьміть на себе відповідальність за першопричину

Системні інциденти та проблеми з цілісністю даних передаються в Deviation/NC . Проведіть розслідування за допомогою RCA , виправте дефект та впровадьте CAPA , яка запобігає повторенню (не просто «перенавчання користувача»). Якщо вплив торкнеться випущеного продукту, оцініть готовність до відкликання та докази балансу маси . Незручна правда: якщо журнал аудиту показує редагування зі слабкими причинами та без перевірки від другої особи, ви будете писати зобов'язання перед інспекторами. Виробіть звичку до аудиту.

10) Безперервність бізнесу — резервні копії, які ви дійсно можете відновити

Резервні копії не мають сенсу, доки ви не доведете можливість відновлення. Переконайтеся, що ви можете реконструювати цілі записи — дані, метадані, підписи, пов’язані вкладення та журнал аудиту — всередині пісочниці в реалістичні терміни (RTO/RPO). Для хмари, обов’язки постачальника документів та ваші тести. Включіть сценарії відновлення після збою DR та відпрацюйте їх. Якщо ваше перше повне відновлення відбувається під час перевірки, ви вже програли.

11) Зберігання та архівування — читабельність протягом усього життєвого циклу

Зберігання відбувається відповідно до продуктових та нормативних вимог. Архівні записи повинні залишатися читабельними, доступними для пошуку та надійними протягом багатьох років. Використовуйте контрольоване архівування з перевірками цілісності (контрольні суми, перевірка підписів) та перевіреними планами міграції, коли формати або платформи змінюються. Не зберігайте PDF-файли eBMR у спільному файловому сховищі та не вважайте це завершеним; доведіть, що ви можете відтворити повний запис із збереженням контексту та журналу аудиту.

12) Електронні таблиці та локальні інструменти — перевірка або заміна

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

13) Практичний пакет Додатку 11 — Як виглядає добро

• Інвентаризація системи: Критичність GxP, власники, класифікація даних, інтерфейси та модель хостингу.
• Вимоги та ризики: URS з рейтингом ризику, зіставленим з контролями та тестами (реєстр ризиків).
• Підтвердження підтвердження: IQ/OQ/PQ з реалістичними сценаріями (PPQ аналогії), тести міграції даних та результати продуктивності/обсягу.
• Операційний контроль: Стандартні операційні процедури (СОП) для управління доступом, змін, обробки інцидентів, перевірки журналу аудиту, періодичного перегляду та тренувань з резервного копіювання/відновлення.
• Конфігурації під контролем: версії рецептів, шаблони етикеток, рамки, з погодженнями в Документ контрольний.
• Готовність до випуску: підписаний пакет випуску з матрицею трасування, закриттями відхилень та оновленнями навчання (Матриця навчання).
• Метрики: охоплення перевірок журналів аудиту, видалення застарілих прав доступу, коефіцієнта успішного проходження тестування відновлення та змін дефектів у кожному релізі.

14) Як це поєднується з V5 від SG Systems Global

Життєвий цикл та CSV. Платформа V5 реалізована за документованим підходом CSV з тестовими пакетами на основі ризиків та підписаними релізами. Вимоги відстежуються в даних тестування та в журналі аудиту розгорнутої версії. Конфігурації, специфічні для клієнта, — формули, керування версіями рецептів , правила упаковки/відвантаження — контролюються таким самим чином.

Контроль виконання. V5 забезпечує жорстке керування ( електронний контроль успішності/неуспішності ) для критичних кроків, перевіряє стан калібрування перед прийняттям даних пристрою та блокує випуск, коли відсутні підписи або дані. Шаблони етикеток та серіалізації є перевіреними об'єктами з історією затверджень.

Відстеження. Кожен рух матеріалу пов'язаний з партіями та генеалогією ; у WMS застосовуються правила FEFO / FIFO ; статус «Затримка» запобігає випадковому відправленню до утилізації з контролю якості.

Цілісність даних. Журнали аудиту фіксують значення "до/після", причини, користувачів та позначки часу; звіти беруться з виконаних даних, а не з перерахованих електронних таблиць. Доступ базується на ролях з періодичним переглядом та опціями багатофакторної автентифікації (MFA ).

Безперервність. Резервне копіювання/відновлення тестується для повного відновлення записів та слідів; плани архівування зберігають читабельність з часом. Підсумок: V5 впроваджує Додаток 11, тому виконання, дані та перегляд залишаються узгодженими.

15) Лабораторні дослідження, методи та дані — поєднання Додатку 11 з 17025

Там, де Додаток 11 зустрічається з лабораторіями, очікуйте перетину з ISO/IEC 17025 та TMV . Інтерфейси LIMS та приладів повинні підтримувати ланцюг зберігання, безпечні журнали аудиту та відстежувані калібрування. Плани відбору проб ( відбір GMP ) та рішення щодо утилізації повертаються до MES/QMS з повним контекстом. Якщо ваша активність, ідентифікатор або мікродані призводять до випуску, Додаток 11 очікує, що електронний зв'язок буде надійним та таким, що підлягає перегляду.

16) Складування та логістика — якість не зупиняється на пристані

Стан запасів, упаковка та відправка , а також ідентифікатори одиниць/ящиків/піддонів входять до сфери застосування, коли вони впливають на випуск. Перевірте етикетки перевізників, алгоритми ящиків ( GS1‑128 ) та документи на відвантаження ( BOL ). Переконайтеся, що WMS не може відправляти товари, що зберігаються , і що готовність до відкликання може швидко відстежувати замовлення з повною генеалогією.

17) Продуктивність, CPV та постійна фізична форма

Після запуску продовжуйте доводити придатність за допомогою моніторингу в стилі CPV : коефіцієнти транзакцій, коефіцієнти помилок, аномалії журналу аудиту, події безпеки, пройдені тести відновлення та відхилення часу до закриття. Для процесів зі статистичним контролем ( SPC ) відстежуйте Cp/Cpk для критичних потоків даних. Коли виникають відхилення продуктивності або моделі інцидентів, розцінюйте це як сигнал для посилення контролю або повторної перевірки частин стеку.

18) Поширені помилки та способи їх вирішення

• «Конфігурація — це не код». Неправильно. Керуйте рецептами, мітками, обмеженнями та робочими процесами як перевіреними об'єктами з версіями в розділі Документ контрольний.
• Аудиторський журнал увімкнено, але не прочитано. Плануйте огляди, навчайте оглядачів та відбирайте зразки об'єктів високого ризику. Відсутність огляду = відсутність контролю.
• Паперові роздруківки як основні. Якщо не обґрунтовано інше, електронні записи є первинними. Друк не зберігає метадані та контекст.
• Слабкий вплив змін. Використовуйте оцінки ризиків, пов'язані з конкретними потоками даних та режимами збоїв. Перевірте, що насправді може вам зашкодити.
• Одноразова перевірка. Періодичний огляд дозволяє вам залишатися чесними після оновлень, інцидентів або змін постачальників.
• Тіньові електронні таблиці. Замініть перевіреними функціями або переведіть їх у повний V&V.
• Некваліфіковані прилади, що живлять MES. Блокування даних з пристроїв з невідомими статус.
• Відсутність розподілу обов'язків. Забезпечте, щоб творці не могли самостійно затверджувати зміни; реєструйте та переглядайте будь-які екстрені зміни.
• Неконтрольовані інтеграції. Розглядайте інтерфейси як перевірені об'єкти за допомогою версіонних та регресійних тестів.

19) Показники, що переконують інспекторів

• Підтверджене державне покриття: % систем GxP з поточною URS, оцінкою ризиків та нещодавнім періодичним оглядом.
• Гігієна доступу: закриті недійсні облікові записи; обмежений за часом привілейований доступ; покриття багатосторонньої авансової плати.
• Стан журналу аудиту: % об'єктів високого ризику, перевірених за графіком; аномалії вирішені в рамках SLA.
• Якість змін: зміни з аналізом впливу та пройдені регресійні тести; уникнуті дефекти для кожного релізу.
• Забезпечення безперервності: коефіцієнт успішного проходження тесту на відновлення; середній час відновлення порівняно з RTO; повнота відновлених записів.
• Інциденти цілісності даних: тенденція до зниження та закриття з ефективним CAPA, а не шаблонним підходом «перенавченого користувача».

20) Контрольний список швидкого старту (використайте його завтра)

• Перелічіть 10 найкращих систем GxP та позначте ті, які з них генерують або зберігають первинні записи.
• Підтвердіть наявність журналів аудиту увімкнено та перевірено для цих записів; задокументуйте останній огляд.
• Виконати перевірку доступу; закрити застарілі облікові записи; забезпечити мінімальний рівень привілеїв у UAM.
• Виберіть одну систему та виконайте повне тестування відновлення репрезентативного набору записів.
• Визначте одну тіньову електронну таблицю, яка є рушійною силою рішення про випуск; або перевірте її, або замініть.
• Плануйте періодичні огляди з урахуванням ризиків; пов’язуйте висновки з КАПА.
• Задокументуйте версії інтерфейсу та налаштуйте регресійні тести до наступного вікна випуску.

21) Покрокове керівництво по пунктах (практичний огляд)

Управління ризиками. Використовуйте QRM для ранжування функцій за впливом; зосередьте тестування та контроль там, де шкода реальна. Пов’яжіть ризики з контролем та обсягом аудиторського журналу. Підтримуйте реєстр в актуальному стані, коли змінюються процеси або постачальники.

Персонал та навчання. Зіставте компетенції з ролями та системами за допомогою оновленої Матриці навчання . Завершення навчання не дорівнює компетентності — оцінюйте ефективність там, де ризик високий.

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

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

Дані. Визначте власників даних, класифікації та умови зберігання. Контролюйте основні дані (рецепти, специфікації, заяви на етикетки) в розділі «Контроль документів» за допомогою ефективного датування.

Перевірки точності. Створіть автоматизовану перевірку для критичних розрахунків (коригування потенції, перетворення) з подвійною перевіркою там, де залишається ручне введення.

Зберігання даних. Забезпечте надійне сховище за допомогою перевірок цілісності; захист від прихованого пошкодження; регулярне тестування відновлення.

Роздруківки. Якщо ви друкуєте, захопіть контекст і метадані або вбудуйте перевірений ідентифікатор запису. Електронний запис залишається основним, якщо інше не обґрунтовано.

Журнали аудиту. Увімкніть, визначте обсяг, перегляньте та захистіть їх. Зберігайте їх невіддільними від основного запису та захищайте від змін.

Електронні підписи. Унікальні, пов'язані зі змістом та підкріплені системою управління ідентифікацією; запобігають делегуванню без сліду.

Партія/Випуск. Електронне підписання має відображати повний, узгоджений запис; блоковий випуск у разі відсутніх даних або відкритих відхилень.

Безперервність бізнесу. Письмові, перевірені плани; задокументовані результати; дії з покращення, що відстежуються до закриття.

Архівування. Зберігайте читабельність та довіру; плануйте зміни формату та платформи; періодично тестуйте пошук.

22) Робочі приклади (що подобається інспекторам)

Приклад A — Коригування потенції у рецептурі. Валідоване правило збільшує заряд активного фармацевтичного інгредієнта (API), коли аналіз нижчий за цільовий. Докази включають: контрольовану версію рецептури, TMV для розрахункового шляху, подвійну перевірку вхідних даних аналізу, журнал аудиту спрацьовування правила та результат партії в межах специфікації. Посилання за темою: Коригування потенції , V&V.

Приклад B — Контроль чистого вмісту з використанням захисних смуг. Контрольні ваги інтегруються з MES; цілі та ліміти SPC є контрольованими об'єктами; ризик суб-TNE контролюється; заявки на етикетки витягують виконані сітки. Докази: ідентифікатори та стан пристроїв, таблиці тарування в розділі «Контроль документів» та журнал аудиту будь-яких змін цільових показників. Посилання за темою: TNE , Ліміти контролю.

Приклад C — Затвердження електронної етикетки. Шаблони етикеток мають версії та перевірені; перевірена символіка штрих-коду; застосовуються правила UDI та GTIN; випуск блокується, якщо шаблон не набув чинності для партії. Посилання за темою: Перевірка етикетки , GS1 GTIN.

23) Запитання, які ставлять інспектори (підготуйте відповіді зараз)

• Покажіть мені матрицю трасування для цієї системи — вимога тестування перед випуском. Де оцінка ризиків?
• Продемонструйте перевірку журналу аудиту критичного об'єкта. Яка частота перевірки та хто її підписує?
• Відновіть цей пакетний запис, включаючи журнал аудиту, в пісочниці. Скільки часу це зайняло і який ваш RTO?
• Проведіть мене через зміни X — аналіз впливу, виконані тести та перевірку робочого процесу.
• Як ви гарантуєте, що користувачі не зможуть схвалити власну роботу? Покажіть мені зразок для наслідування та останній перегляд доступу.
• Що станеться, якщо цей прилад не відкалібрований? Перевірте блокування та потік утилізації.

24) FAQ

Q1. Чи є Додаток 11 тим самим, що й 21 CFR Part 11?
Ні. Вони перетинаються в питаннях електронних записів/підписів, але Додаток 11 ширше стосується життєвого циклу, управління ризиками та операцій. Якщо ви продаєте як у ЄС, так і в США, розробляйте для обидва з першого дня.

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

Q3. Чи прийнятні паперові роздруківки як первинні записи?
Тільки за наявності вагомого обґрунтування. Додаток 11 загалом розглядає електронні записи як первинні; друк не зберігає метадані, підписи чи контекст журналу аудиту.

Q4. Чи підпадають електронні таблиці під дію Додатку 11?
Якщо вони впливають на рішення GxP, так — контролюйте та перевіряйте їх або переносьте логіку у перевірену системну функцію.

Q5. Як часто нам слід перевіряти доступ та журнали аудиту?
З визначеною, ризикоорієнтованою періодичністю (часто щомісяця/щокварталу), а також спеціально після інцидентів або суттєвих змін. Перевірки мають бути задокументовані та проводитися вибірково для оцінки ефективності.

Q6. Який найшвидший спосіб показати перевірений стан?
Ведіть матрицю слідів у реальному часі, поточну оцінку ризиків, останній періодичний огляд, докази відновлювальних випробувань та підписаний пакет документів на дозвіл — готові до передачі інспектору.