Операційна кваліфікація (OQ) – підтвердження роботи систем відповідно до затвердженого наміру в умовах контрольованого випробування

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

Оновлено у жовтні 2025 р. • Перевірка та готовність до випуску • Забезпечення якості, виробництво, ІТ/ОТ

Операційна кваліфікація (OQ) – це фаза валідації, яка демонструє, що система, прилад або автоматизований процес працює належним чином у визначених робочих діапазонах та за певних умов, використовуючи затверджені сценарії тестування, результати вимірювань та попередньо встановлені критерії прийнятності. У класичній трилогії кваліфікації – Кваліфікація встановлення (IQ) , OQ та Кваліфікація продуктивності (PQ) – IQ доводить, що система встановлена ​​правильно та простежується, OQ доводить, що налаштовані елементи керування та функції працюють за нормальних та найгірших умов, а PQ доводить, що процес послідовно відповідає вимогам до продукту чи послуги за умови регулярного використання. У сучасних операціях, керованих даними, надійна OQ базується на валідації комп'ютерної системи (CSV) , підтримує 21 CFR Частина 11 та Додаток 11 , а також надає практичні докази тверджень на етикетках, блокувань безпеки обладнання, контролю рецептів та цілісності даних. Найкращі OQ імітують реальність: вони перевіряють сигналізацію, блокування, електронні підписи, журнали аудиту , дозволи ролей, перевірку штрих-кодів та допуски зважування/видачі так само, як це роблять оператори, а потім зберігають докази незмінними для перевірки.

«IQ гарантує, що це є, OQ доводить, що це працює, PQ показує, що це продовжує працювати».

1) Що охоплює OQ, а що ні

OQ перевіряє, чи налаштована система працює відповідно до специфікацій у своєму передбачуваному середовищі: функції, діапазони, послідовності, сигналізація, блокування, безпека, потоки даних та електронні записи. Для станції роздачі, підключеної до ваг, OQ перевірятиме потік живої ваги, логіку гравіметричного приймання, перевірку штрих-кодів товару/партії, подвійне перевизначення верифікації та блоки допусків. Для кроку MES перевірятиметься інструкції з датою набрання чинності з MMR / MBR , підказки щодо очищення лінії , внутрішньопроцесний контроль (IPC) , сповіщення SPC та значення підпису. OQ не доводить довгострокову здатність процесу (це робота PQ) і не повторює вміст FAT постачальника без обґрунтування; він перетворює вимоги користувачів на об'єктивні тести, що мають значення для вашого передбачуваного використання та нормативної сфери застосування.

2) Розробка протоколу оцінки якості операцій (OQ) на основі ризиків

Ефективна оцінка якості роботи (OQ) починається з карти вимог. Почніть з вимог користувача та функціональних вимог (URS/FRS) та небезпек невдачі. Там, де невдача може призвести до неправильного маркування, помилки ефективності або втрати простежуваності, пишіть складні та чіткі тестові завдання . Кожен тестовий випадок включає: мету, передумови, покрокові дії, очікувані результати з числовими критеріями та об'єктивні докази (скріншоти, необроблені дані, друковані етикетки). Пов'яжіть кожен випадок з вимогою та ризиком, щоб аудитори зрозуміли, чому тест існує. Для ідентифікації та маркування включіть сканування, які повинні зазнати невдачі (неправильна партія, прострочена партія), щоб довести, що блок перевірки етикеток працює. Для електронних записів доведіть, що журнали аудиту фіксують хто/що/коли/чому. Для безпеки покажіть, що ролі обмежують дії, а електронні підписи змістовно пов'язані з користувачами згідно з Частиною 11. Для обладнання перевіряйте діапазони керування та сигналізації; для потоків даних імітуйте мережеві збої та підтвердьте відсутність втрати даних або прихованої шкоди. Ризик-орієнтований не означає «робити менше»; це означає «ретельно протестувати те, що найважливіше».

3) Типові теми завдань OQ

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

4) Докази, що витримують аудити

Хороші докази якості контролю якості (OQ) є сучасними, такими, що можна віднести до певної ситуації, розбірливими, оригінальними та точними — дух ALCOA ( ALCOA ). Фіксуйте необроблені результати, а не лише позначки «зараховано/не зараховано»: скріншоти з позначками часу та ідентифікаторами користувачів; PDF-файли витягів журналу аудиту; експорт CSV, підписані в eBMR або звіті про валідацію; друковані етикетки з позначками вихідного завдання та версії шаблону. Створіть простежуваність: протокол → тестовий випадок → крок → докази → відхилення (якщо є) → вирішення. Зберігайте докази в розділі «Контроль документів» з історією версій та правилами зберігання (« Зберігання та архівування даних »). Коли слідчі запитують: «покажіть мені, де система блокує прострочені партії», ви повинні мати можливість відобразити точний тест OQ, докази OQ та журнал аудиту виробництва, що показують той самий контроль у звичайному використанні.

5) Ролі та обов'язки

Валідація – це командний вид спорту. Якість відповідає за методологію, незалежність перевірки та остаточне затвердження. Власник системи (виробництво, лабораторія чи склад) відповідає за цільове використання, реалістичність тестування та щоденний контроль після запуску. ІТ/ОТ відповідає за резервне копіювання/відновлення, синхронізацію часу, контроль доступу та інфраструктуру. Автори пишуть протоколи; тестувальники виконують та записують; рецензенти підтверджують повноту та об'єктивність; затверджувальні особи підписують протоколи за допомогою безпечного електронного підпису зі змістом (підготовка/виконання/перегляд/затвердження). Для регульованих функцій програмного забезпечення (електронні підписи, журнали аудиту) забезпечте розподіл обов'язків – тестувальники не повинні мати можливості затверджувати власні результати. Коли випадок не вдається, зареєструйте відхилення в розділі Відхилення/NC , оцініть вплив, і якщо він виявляє систематичний прогалину, відкрийте CAPA та формалізуйте виправлення за допомогою MOC перед повторним тестуванням.

6) OQ у виробництві, лабораторіях та на складах

Виробництво (MES). Виклики якості функціонування МНС обмеження щодо звільнення з роботи, черги відправлення, IPC, просвіт лінії, та підключення до таких пристроїв, як ваги (гравіметричне зважування) та системи зору (машинне зір). Лабораторії (LIMS/ELN). OQ перевіряє LIMS життєві цикли зразків, блокування статусів, розрахунки результатів, ВЕРХ поведінка інтерфейсу та ТОДІ електронні підписи та потоки свідків. Склади (WMS). Виклики якості функціонування WMS спрямований відбір, контейнер/місцезнаходження правила FIFO/FEFO, від док-до-складу таймери та перевірка етикетки під час пакування/відвантаження. У всіх доменах OQ підтверджує, що ідентифікація, обмеження, підписи та записи поводяться під навантаженням точно так, як задокументовано.

7) Обробка відхилень та повторне тестування

OQ — це не театр досконалості. Коли крок не вдається, призупиніть тестування, зареєструйте відхилення/NC , оцініть вплив і визначте, чи пов'язана збій з тестом, конфігурацією чи системою. Якщо він виявляє прогалину у вимогах або системний ризик, створіть CAPA , впровадьте коригувальні зміни через MOC , а потім повторно протестуйте уражену область. Підтримуйте чистий ланцюжок: оригінальні докази → відхилення → виправлення → повторне тестування доказів. Не «переписуйте» історію — регуляторні органи шукають прозорого навчання, а не бездоганних записів. Якщо багато випадків не вдаються з однієї й тієї ж першопричини, подумайте про перегляд протоколу, щоб тестування проходило ефективно після виправлення, але збережіть обидві версії в розділі Контроль документів.

8) Цілісність даних в OQ — Доведіть доказ

Оскільки OQ має засвідчити контроль, його власні дані мають бути надійними. Використовуйте контрольованих користувачів з реальними ролями — без спільних облікових записів. Синхронізуйте час клієнтів і серверів, щоб підписи, записи журналів аудиту та показники пристроїв збігалися. Переконайтеся, що тестові дані позначені відповідним чином, щоб вони ніколи не забруднювали виробничі набори даних. Там, де результати експортуються, зберігайте хеші або підписи, що підтверджують походження. Перевірте резервне копіювання/відновлення, відновивши невеликий фрагмент і перевіривши, що журнали аудиту та підписи залишаються неушкодженими. Для потоків маркування включіть сценарій анульованої мітки та доведіть, що її не можна використовувати повторно. Для підтверджень, що підтримуються EDI , змоделюйте повторне надсилання та переконайтеся, що система запобігає дублікатам відправлень або дублікатам записів. Це не театральність — це саме ті граничні випадки, про які запитують аудитори.

9) Взаємодія з навколишнім середовищем та технічним обслуговуванням

Деякі системи поводяться коректно лише в межах норм навколишнього середовища. Якщо процес залежить від температури або вологості, включіть перевірку на інтеграцію моніторингу навколишнього середовища (ЕМ) та доведіть, що система блокує або попереджає про перевищення лімітів. Якщо точність обладнання залежить від калібрування, підтвердьте перевірки перед використанням, знайдіть стан калібрування активів та блокуйте використання, коли воно прострочено. Якщо застосовується перевірка очищення , перевірте, чи стан очищення видимий та чи виконується він на початку використання або переходу. Кваліфікація роботи з обладнанням (OQ) – це слушний момент, щоб довести, що ці залежності не є племінними знаннями, а жорсткими блокуваннями, які запобігають використанню, коли навколишнє середовище або актив непридатні.

10) Від OQ до PQ — перехід до продуктивності

Коли OQ проходить кваліфікацію (OQ), система довела свою працездатність; тепер PQ має довести, що вона дійсно працює безперервно з реальними матеріалами, операторами та змінами. Розробіть OQ таким чином, щоб її дані враховувалися в плануванні PQ: які ліміти були жорсткими, де відбувалися перевищення вимог та які найгірші умови потребують розширеного моніторингу. Наприклад, якщо OQ показав, що живильник наближається до лімітів поблизу мінімальних заданих значень, PQ може планувати пробіги за цими заданими значеннями для кількох партій та операторів. Узгодьте OQ та PQ з CPV , щоб елементи контролю, перевірені під час кваліфікації, продовжували відстежуватися під час аналізу тенденцій життєвого циклу. Саме так валідація стає живою системою, а не досьє на полиці.

11) Періодичний огляд та перекваліфікація

Кваліфікація — це не одноразова подія. Зміни у версіях програмного забезпечення, архітектурі мережі, шаблонах етикеток, документах або логіці рецептів вимагають оцінки впливу та, часто, цілеспрямованої повторної кваліфікації (OQ). Встановіть періодичні огляди, які порівнюють поточну конфігурацію з перевіреним базовим рівнем, вивчають історію інцидентів/NCR та вирішують, чи виправдана часткова повторна кваліфікація. Проведіть всі зміни через MOC , додайте результати тестування та оновіть зведення валідації. Якщо система зазнала CAPA, включіть їхні верифікаційні тести до наступного огляду — саме тут або доведено, або втрачено стійку відповідність.

12) Поширені помилки в оцінці якості операційної діяльності та як їх уникнути

• Скопіюйте та вставте тести постачальників як OQ. Виправлення: перекладіть відповідно до вашого цільового використання та ризиків; включіть ідентифікаційні дані, маркування, генеалогію та підписи, що стосуються вашого потоку.
• Тільки щасливий шлях. Виправлення: написати тести на наміри невдачі (минув термін придатності, неправильна роль, вихід за межі допустимого значення) та довести, що система блокується або ескалює.
• Слабкі докази. Виправлення: захоплення необроблених екранів, міток, витягів журналу аудиту; відсутність «перевірених» пунктів без підтвердження під Документ контрольний.
• Неконтрольовані користувачі та час тестування. Виправлення: реальні ролі, синхронізовані годинники, унікальні користувачі, прив'язані до електронні підписи.
• Немає мосту до PQ. Виправлення: напишіть короткий виклад перевірки, який перетворює результати контролю якості роботи (OQ) на плани моніторингу якості виробництва (PQ) та CPV діаграми.
• Ігнорування потоків даних. Виправлення: виклик Еді, драйвери пристроїв та інтеграції; імітувати відключення та повторні спроби; довести відсутність непомітної втрати даних.
• Мітки поза контролем. Виправлення: примусове виконання контроль маркування, перевіряти версії шаблонів та сканувати кожну подію друку.

13) Метрики якості операцій (OQ) — підтвердження готовності та ретельності

Відстежуйте кількість випадків контролю якості експлуатації (OQ), коефіцієнт успішного виконання при першому виконанні, щільність відхилень (на 10 випадків), час циклу переробки та частку тестів на невдачу (вища частка вказує на краще покриття проблем). Після введення в експлуатацію відстежуйте виробничі блоки, виявлені тими ж блокуваннями, які ви тестували – прострочені партії, невідповідності етикеток, відпуск поза межами допусків – як ключові показники ефективності контролю. Пов’яжіть ретельність контролю якості експлуатації з результатами: менше неявних заявок (NCR) , коротші затримки випуску партій та покращений час від замовлення до відвантаження . Перевірка повинна відчуватися в рівнях обслуговування, а не лише в папках.

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

Огляд рішення V5. Платформа V5 розроблена для валідації. Конфігурація має версії, докази можна атрибуювати, а міжмодульні блокування (ідентифікація, статус, підписи) можна тестувати та звітувати — ідеально підходить для ретельності контролю якості роботи та життєвого циклу.

V5 MES. У V5 MES сценарії OQ покроково керують завданнями ефективного MMR / MBR , перевірки якості ліній , IPC / SPC , інтеграції пристроїв (ваги, технічне обладнання), а також журналів аудиту та підписів eBMR — саме тих елементів контролю, які ретельно перевіряють регуляторні органи.

Система управління якістю V5. У рамках системи управління якістю V5 планування якості обладнання (OQ), відхилення, CAPA та MOC узгоджуються в рамках системи контролю документації , що синхронізує протоколи, стандартні операційні процедури (SOP) та докази. Пакети періодичного перегляду генеруються з тієї ж системи записів, яка керує виробництвом.

V5 WMS. V5 WMS підтримує контроль якості (OQ) для отримання, доставки на склад , спрямованого комплектування , правил зберігання/розташування та перевірки етикеток з блокуваннями, пов'язаними зі статусом калібрування , терміном дії та карантином, тому невдалі перевірки не можуть бути порушені у виробництві.

Підсумок: V5 перетворює OQ з одноразової перешкоди на живу систему управління — кожен взаємозв'язок, який ви доведете під час кваліфікації, є тим самим взаємозв'язком, який захищає виробництво завтра.

15) FAQ

Q1. Чи завжди потрібні окремі параметри контролю якості (OQ) та контролю якості виробництва (PQ)?
Так, у регульованих контекстах. OQ підтверджує функції та елементи керування в різних діапазонах; PQ підтверджує, що реальний процес дає результати з часом з реальними матеріалами та операторами.

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

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

Q4. Де перевіряються електронні підписи та журнали аудиту?
В OQ. Доведіть значення, унікальність та синхронізацію часу підпису; покажіть журнали аудиту, що фіксують хто/що/коли/чому та є незмінними, згідно Частина 11/Додаток 11.

Q5. Що запускає повторну оцінку якості (OQ)?
Оновлення програмного забезпечення, зміни інтеграції, перегляд шаблонів етикеток, зміни логіки рецептів, переміщення середовища або виправлення, зумовлені CAPA, – оцінюються за допомогою MOC з цілеспрямованим повторним тестуванням.

Пов'язане читання
• Кваліфікація та перевірка: Кваліфікація встановлення (IQ) | Кваліфікація обладнання (IQ/OQ/PQ) | Перевірка комп'ютерної системи (CSV)
• Записи та доброчесність: 21 CFR ч. 11 | Додаток 11 | Аудиторський журнал (GxP) | цілісність даних | Документ контрольний
• Системи виконання: МНС | WMS | ТОДІ | LIMS
• Елементи керування та потік: Лінійний зазор | Внутрішньопроцесний контроль (IPC) | Контрольні межі SPC | Перевірка етикетки | Простежуваність партії
• Зміни та проблеми: Відхилення / Невідповідність | КАПА | Управління змінами (MOC) | Внутрішня ревізія