Скачиваний:   6
Пользователь:   andrey
Добавлен:   14.01.2015
Размер:   1.1 МБ
СКАЧАТЬ

МІНІСТЕРСТВО ОХОРОНИ ЗДОРОВ'Я УКРАЇНИ

НАЦІОНАЛЬНИЙ ФАРМАЦЕВТИЧНИЙ УНІВЕРСИТЕТ

Кафедра управління якістю

 

"Допущено до захисту"

Протокол № ___

від "___" ______________ 2008 р.

Завідувач кафедри

проф. С.М. Коваленко ___________

 

 

 

 

Магістерська робота

 

Розробка ПРОЦЕДУР ВАЛІДАЦІЇ КОМП’ЮТЕРИЗОВАНИХ СИСТЕМ НА фармацевтичних підприємствАХ

 

 

Виконав: студент 1 гр. 7-го курсу

промислового факультету

спеціальності 8.000001 "Якість,

стандартизація та сертифікація"

Ковбасюк Олександр Вікторович

_____________________

                        (підпис)

Науковий керівник:

Лебединець Вячеслав Олександрович

кандидат фармацевтичних наук,

доцент кафедри управління якістю

______________________

                       (підпис)

 

 

 

 

 

Харків-2009


Зміст

 

 

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ……..………………………...

5

 

ВСТУП…………..……………………….……………...……………

7

РОЗДІЛ 1

ВалІдацІя ЯК НЕВІД'ЄМНА ЧАСТИНА СИСТЕМИ ЗАБЕЗПЕЧЕННЯ ЯКОСТІ……………...…………………………...

 

9

1.1

Історія введення валідації………………………..…………...…...

9

1.2

Законодавча основа валідації…………………………………..…

11

1.3

Історія створення та впровадження керівництва GAMP……….

12

РОЗДІЛ 2

ОСНОВНІ ЕТАПИ ПРОВЕДЕННЯ ВАЛІДАЦІЇ КОМП’ЮТЕРИЗОВАНИХ СИСТЕМ……..………………………..

 

16

2.1

Загальні принципи валідації компю’теризованих систем у відповідності з GAMP……………………………………………..

 

16

2.1.1

Огляд валідації компю’теризованих систем………..……….

16

2.1.2

Життєвий цикл валідації автоматизованих систем...………..

17

2.1.3

Система керування для постачальників систем IT………….

21

2.1.4

Валідація системи керування (технологічними) процесами (PCS)……………………………………………………………

 

22

2.1.5

Користь від валідації комп’ютеризованих систем…………..

24

2.1.6

Вимоги належних практик щодо валідації комп’ютеризованих систем…………………………………...

 

25

2.1.6.1

Належна практика по документації……………………..

25

2.1.6.2

Належна практика по тестуванню………………………

26

2.1.6.3

Належна інженерна практика…………………………...

28

2.2

Аналіз ризиків для валідації автоматизованих систем………….

29

2.2.1

Проект, аналіз ризиків і валідація АС………………………..

30

2.2.2

Порядок проведення аналізу ризиків………………………...

31

2.2.2.1

Ідентифікація процесу…………………………………...

32

2.2.2.2

Ризик для GxР…………………………………………….

32

2.2.2.3

Ризик для продажів………………………………………

33

2.2.2.4

Ризикові ситуації…………………………………………

34

2.2.2.5

Імовірність ризику……………………………………….

34

2.2.2.6

Наслідки ризику………………………………………….

35

2.2.2.7

Категорія ризику…………………………………………

36

2.2.2.8

Виявлення ризику………………………………………..

36

2.2.2.9

Пріоритет ризику………………………………………...

36

2.2.2.10

Стратегія пом'якшення ризику………………………….

37

2.3

Аналіз ризиків системи керування……………………………….

38

2.3.1

Вихідна оцінка ризику………………………………………...

38

2.3.2

Визначення критичності компонентів……………………….

39

2.3.3

Визначення критичності SW………………………………….

40

2.4

Аналіз ризиків змін………………………………………………..

41

2.5

Специфікації на комп'ютеризовані системи……………………..

41

2.5.1

Специфікація вимог користувача…………………………….

43

2.5.1.1

Розробка URS…………………………………………….

44

2.5.1.2

Зміст URS…………………………………………………

45

2.5.2

Функціональна специфікація…………………………………

49

2.5.2.1

Створення FS……………………………………………..

49

2.5.2.2

Зміст FS…………………………………………………...

50

2.5.3

Специфікація проекту (DS)…………………………………...

53

2.5.4

Специфікація проекту апаратного забезпечення……………

54

2.5.4.1

Зміст DS — HW…………………………………………..

55

2.5.5

Специфікація проекту програмного забезпечення (SDS)…..

58

2.5.5.1

Зміст DS — SW…………………………………………..

59

2.5.6

Зміст специфікації модуля……………………………………

60

2.6

Категорія софтвера й хардвера…………………………………...

62

2.6.1

Категоризація систем………………………………………….

62

2.6.2

Категорії SW…………………………………………………...

63

2.6.2.1

Категорія 1. Операційні системи………………………..

63

2.6.2.2

Категорія 2. Firmware – програмно-апаратні засоби; вбудовані програми; «зашиті програми» (у ПЗУ)……..

 

64

2.6.2.3

Категорія 3. Стандартні пакети програм……………….

65

2.6.2.4

Категорія 4. Конфігуруємі пакети програм…………….

66

2.6.2.5

Категорія 5. Системи, сформовані замовником, або виготовлені під замовлення……………………………..

 

67

2.6.3

Стратегія валідації для різних категорій…………………….

68

2.6.4

Табличні процесори…………………………………………...

69

2.6.5

Інструменти розробки й діагностики………………………...

70

2.6.6

Категорії хардвера (апаратних засобів)……………………...

70

2.6.6.1

Категорія 1. Стандартні компоненти HW………………

70

2.6.6.2

Категорія 2. Компоненти HW під замовлення…………

71

2.6.7

Оцінка ризику………………………………………………….

71

2.6.8

Приклади категоризації систем………………………………

72

2.6.8.1

Розподілена система керування…………………………

72

2.6.8.2

Незалежна система PLC/SCADA (standalone system – ізольована система)………………………………………

 

72

2.6.8.3

Пакувальне устаткування (Packaging equipment) — вбудована система (embedded system)………………….

 

74

2.6.8.4

Використання персональних комп'ютерів (Personal computers, PC)…………………………………………….

 

75

2.7

Життєвий цикл і перспективна валідація систем керування…...

76

2.7.1

Перспективна валідація систем керування…………………..

77

2.7.1.1

Автоматизована система й керуючий SW (Automated Production System and Control System Software)………..

 

77

2.7.1.2

 «V»-образна модель перспективної валідації (The V Model ofProspective Validation)………………………….

 

78

2.7.2

Виконання проекту (Project Execution)………………………

80

2.7.2.1

Опис процесу – Специфікація вимог користувача (Process Oriented Description – User Requirement Specification)……………………………………………...

 

 

80

2.7.2.2

Попереднє технічне планування (Preliminary Engineering)……………………………………………….

 

82

2.7.2.3

Базовий інжиніринг (Basic Engineering)………………..

83

7.2.2.4

Робочі креслення (Detail Engineering)…………………..

87

7.2.2.5

Фаза впровадження (Implementation Phase)…………….

91

7.2.2.6

Здавання – прийняття (Commissioning)………………...

94

7.2.2.7

Завершення проекту (Project Completion)………………

97

2.8

Система валідаційної документації………………………………

98

2.8.1

Валідаційний Майстер План………………………………….

99

2.8.2

Валідаційні протоколи………………………………………...

101

2.8.3

Валідаційний звіт……………………………………………...

101

РОЗДІЛ 3

РОЗРОБКА ВАЛІДАЦІЙНОГО МАЙСТЕР ПЛАНУ……………..

103

3.1

Предмет валідації………………………………………………….

103

3.2

Склад валідаційної комісії………………………………………...

104

3.3

Склад рабочої групи……………………………………………….

104

3.4

Опис обладнання…………………………………………………..

104

3.4.1

Призначення…………………………………………………...

104

3.4.2

Опис конструкції………………………………………………

104

3.4.3

Принцип роботи……………………………………………….

105

3.4.4

Керування роботою автомата………………………………...

106

3.5

Оформлення результатів тестування……………………………..

107

3.6

Технічне завдання користувача / User Requirements Specification………………………………………………………...

 

107

3.6.1

Ключові завдання системи……………………………………

107

3.6.2

Розміщення системи…………………………………………..

107

3.6.3

Необхідні функції системи……………………………………

107

3.6.4

Експлуатаційні вимоги до системи…………………………..

108

3.7

Функціональний опис системи / Functional Specification……….

110

3.7.1

Принцип роботи……………………………………………….

110

3.7.2

Характеристики Harlequin…………………………………….

111

3.7.3

Логічне керування……………………………………………..

114

3.7.4

Інтерфейс користувача………………………………………..

116

3.8

Технічний опис системи / Design Specifications…………………

117

3.9

Кваліфікація інсталяції (IQ)……………………………………..

118

3.9.1

Перелік тестів, які будуть проведені…………………………

119

3.9.2

Протоколи (IQ)………………………………………………...

119

3.10

Кваліфікація функціонування (OQ) та експлуаційних якостей (PQ)…………………………………………………………………

 

119

3.10.1

Перелік тестів, які будуть проведені…………………………

119

3.10.2

Протоколи (ОQ / PQ)……...…………………………………..

119

 

ВИСНОВКИ…………………………………………………………..

121

 

СПИСОК ВИКОРИСТАНОЇ ЛІтературИ……………………….

123


ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ

АС

Автоматизовані системи

АФИ

Активний фармацевтичний інградієнт

ВОЗ

Всесвітна організація охорони здоров’я

ДФУ

Державна Фармакопея України

ЄС

Європейський Союз

СОП

Стандартна операційна процедура

DQ

Design Qualification

(Кваліфікація проекту)

DS

Design Specifications

(Специфікація проекту)

ЕР

European Pharmacopoeia

(Європейська Фармакопея)

FDA

Food and Drug Administration

(Управління по контролю за харчовими продуктами та лікарськими засобами (США))

FS

Functional Specification

(Функціональна специфікація)

GAMP

(НПАВ)

Good Automated Manufacturing Practice

(Належна практика автоматизованого виробництва)

GEP

Good Engineering Practice

(Належна інженерна практика)

GMP (НВП)

Good manufacturing practice

(належна виробнича практика)

GxP

Загальноприйняте скорочене позначення всіх належних практик GMP, GLP, GDP і т.д.

HW

Hardware

(Апаратне забезпечення)

ICH

International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use

(Міжнародна конференція по гармонізації технічних вимог до регістрації лікарських препаратів для людини)

IEEE

Institute of Electrical and Electronics Engineers

(Інститут Інженерів Електрики та Електроніки)

IQ

Installation Qualification

(Кваліфікація інсталяції)

ISPE

International Society for Pharmaceutical Engineering

(Міжнародна організація по фармацевтичному інжинірингу)

IT

Information Technologies

(Інформаційні технології)

ITT

Invitation То Tender

(Запрошення на участь у тендері)

OQ

Operational Qualification

(Кваліфікація функціонування)

PC

Personal computers

(Персональний комп'ютер)

PCS

Process Control Systems

(Система керування (технологічними) процесами)

PIC – PIC/S

Pharmaceutical Inspection Cooperation Scheme

(Система співпраці фармацевтичних інспекцій)

PLC

Programmable Logic Controller

(Контролер із програмувальною логікою)

PQ

Performance Qualification

(Кваліфікація експлуатаційних якостей)

QA

Quality Assurance

(Проведення аудитів)

SW

Software

(Програмне забезпечення)

URS

User Requirements Specification

(Специфікація вимог користувача)

VMP

(ВМП)

Validation Master Plan

Валідаційний Майстер План

 


ВСТУП

У зв'язку з інтеграцією України в ЄС, підприємства фармацевтичної галузі зорієнтовані на випуск продукції високої якості, що досягається в першу чергу дотриманням при виробництві лікарських препаратів правил належної виробничої практики (GMP).

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

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

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

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

Зі зростанням широти застосування й складності автоматизованих систем у фармацевтичному виробництві виникла необхідність у розробці таких керівництв. Отже, виникла необхідність у правильному розумінні й інтерпретації провідних вказівок не тільки виробниками фармацевтичної продукції, але і постачальниками обладнання та систем. Внаслідок цього виникла промислова група – Форум GAMP, яка займалась поліпшенням взаємної комунікації між постачальниками, фармацевтичними виробниками та державними вповноваженими компетентними органами. В результаті роботи даної групи було розроблено керівництво GAMP – Належна практика автоматизованого виробництва.

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

Ціль даної магістерської роботи являється розробка основних процедур валідації комп’ютеризованих систем, пов'язаних з її проведенням. А також розгляд основних видів документації, яка повинна бути надана продавцем обладнання або розроблена на підприємстві при проведенні валідації, як підготовча процедура для сертифікації виробництва на виконання вимог належної виробничої практики.

У результаті ознайомлення з існуючою нормативною документацією та доступною рекомендаційною літературою були вивчені закономірності й правила проведення валідації комп’ютеризованих систем. У практичній частині даної роботи наведена розробка майстер плану проведення валідації комп’ютеризованої системи, на прикладі блістерного автомата Marchesini MB421.

 


РОЗДІЛ 1

ВалІдацІя ЯК НЕВІД'ЄМНА ЧАСТИНА СИСТЕМИ ЗАБЕЗПЕЧЕННЯ ЯКОСТІ

1.1 Історія введення валідації

Історія валідації у фармацевтичній промисловості бере свій початок, імовірно, в 1972 році в США. У той час відзначається пік ряду рекламацій при виробництві внутрішньовенних розчинів і багатооб’ємних парентеральних розчинів (Large Volume Parenteral solutions – LVP) у більшості провідних виробників. Більша частина рекламацій підтверджувала не стерильність препаратів.

У період з 1972 по 1976 р. FDA призначила спеціальну групу («LVP Team»), що займалася проблематикою інспекції виробництва багатооб’ємних парентеральних препаратів. Група констатувала наявність безлічі погрішностей у ході виробничих процесів, встановленні обладнання, системах підготовки повітря і т.п. Практично жодна з фірм не проводила контроль на відповідність роботи обладнання очікуваному ефекту. На підставі подібного досвіду була розроблена інструкція «LVP Regulations FDA», у якій знаходились ряд рекомендацій з питання забезпечення стерильності виробництва. Дана інструкція в багатьох відносинах носила суперечливий характер, і американська промисловість довго відмовлялася її визнати.

У період з 1976 по 1978 р. FDA ввела так званий «Self Inspection Concept». Останній зобов'язував довести за допомогою внутрішнього аудита й інспекцій самих виробників правильність інформації про застосування обладнання для стерильного виробництва. Даний крок виявився досить проблематичним, оскільки не було в наявності єдиної методики порівняння процесів й інформації.

У період з 1978 по 1979 р. FDA розробила так званий «Concept of Validation». У даному документі приводяться методики контролю різних частин стерильного виробництва. Введення даних правил у дію внесло жах у ряди виробників, проектантів і постачальників обладнання та компонентів. У багатьох випадках на превеликий подив виявилося, що процеси і зовсім непідконтрольні і не гарантують стерильність продукції по різних причинах. Паралельно були повністю перероблені правила GMP.

Роки 1979 – 1981 характерні масованим наступом знань, починаючи від конструкторів і проектантів, і закінчуючи виробничим персоналом. Характерним для даного періоду часу була «знання критеріїв прийнятності».

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

Розробка методики валідації в цілому і її прийняття всіма сторонами в США тривали практично 20 років!

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

Тому доцільно пояснити, що нового приносить валідація в порівнянні зі звичайними методами контролю. Традиційні методи контролю при тестуванні готової продукції включають три основних кроки:

1. Визначення специфіки й характеристик процесу.

2. Вибір методології, виробничого обладнання та приладів.

3. Тестування готової продукції з використаннями валідованих аналітичних методів, які гарантують, що готова продукція буде відповідати специфікації.

Концепція валідації виробничих процесів вводить ще чотири наступні кроки:

4. Атестація та валідація виробничого обладнання.

5. Атестація та валідація виробничого процесу.

6. Проведення аудитів, моніторингу, відбору зразків або перевірка ключових кроків технологічного процесу на відповідність із робочими специфікаціями на процеси і специфікаціями на готову продукцію.

7. Реаттестація і ревалідація в тих випадках, коли відбуваються значні зміни продукту, або процесу [1, 4].

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

1.2 Законодавча основа валідації

Розробка стандартів і керівних документів, необхідних на сучасному етапі для забезпечення якості фармацевтичної продукції, проходить при високому рівні прозорості, що багато в чому досягається за рахунок публікацій їхніх проектів й обговорення на конференціях. Варто згадати конференції ICH (International Conference on Harmonisation), а також Європейські конференції по GMP. Прийнято вважати, що основним документом для виробника є посібник з GMP – основний документ для забезпечення якості лікарських засобів при їхньому виробництві. Однак очевидно, що всі елементи керування якістю й забезпечення якості так само значимі (критичні) для всієї системи в цілому; вони взаємно проникають і залежать один від одного.

На сьогоднішній день розділи «Фармацевтична розробка й валідація процесу» та «Виробництво готових лікарських форм» має законодавчу основу – Законодавчі положення ЄС – Директиву 75/318/ЕЕС із виправленнями.

Документи, що відносяться безпосередньо до GMP – це дві директиви Комісії ЄС – GMP лікарських засобів для людини (91/356/ЕЕС) і ветеринарії (91/412/ЕЕС), а також посібник з GMP з 18 додатками.

На 3-й Європейської конференції по GMP було відзначено, що в області GMP лікарських засобів у ЄС відбуваються певні зміни внаслідок діяльності по взаємному визнанню й гармонізації, а також у рамках стратегії перегляду фармацевтичного законодавства ЄС.

На конференції були обговорені чотири нові додатки до посібника з GMP ЄС, які в цей час введені в дію:

1. Додаток 15. Кваліфікація та валідація.

2. Додаток 16. Сертифікація Уповноваженою особою та випуск серії.

3. Додаток 17. Випуск за параметрами.

4. Додаток 18. Посібник з виробництва АФИ [8, 13, 15].

В Україні створюється законодавча база, що регламентує виробництво лікарських засобів й інспектування виробників, гармонізована з вимогами ЄС, ICH та PIC – PIC/S.

В Україні затверджене та введено в дію з 14.12.2001 Керівництво 42-01-2001 «Лікарські засоби. Належна виробнича практика», що відповідає документу «Посібник з належної виробничої практики лікарських засобів» Правил керування лікарськими засобами в ЄС, том 4. Дане керівництво містить Додатки, зокрема Додаток М «Кваліфікація та валідація».

У також введено в дію з 31.12.2003 Керівництво 42-3.5:2004. «Лікарські засоби. Валідація процесу», що описує вимоги до інформації з валідації процесу які необхідно надавати в реєстраційному досьє.

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

1.3 Історія створення та впровадження керівництва GAMP

Основні вимоги до належної практики комп'ютеризованих систем були наведені в Додатку № 11 Європейських правил GMP («Computerised Systems»). Незважаючи на це нагляд над комп'ютеризованими системами був менш жорстким, чим в інших областях GMP, a тлумачення понять часто нечітке, та викликало обговорення. У зв'язку з даною проблемою була заснована промислова група – Форум GAMP – GAMP Forum (Good Automated Manufacturing Practice Forum), метою якої було поліпшення взаємної комунікації між постачальниками, фармацевтичними виробниками й державними вповноваженими компетентними органами. Загальні правила GAMP включають три ключових елементи:

• керівництва GAMP – визначають міру та об’єм валідації для різних комп'ютерних систем, а також приводять зразкові методи та провідні вказівки;

• правила GxP – надають основні вимоги по специфічним темам (валідація комп'ютеризованих систем, керування калібруванням, структура IT);

• навчальні матеріали – створюють підтримку для курсів і семінарів ISPE.

«The Association of the British Pharmaceutical Industry» (ABPI) і «Pharmaceutical Quality Group» (PQG) спільними зусиллями підготували документ «GAMP Guide for Validation of Automated Systems» (GAMP Guide, Керівництво GAMP пo валідації автоматизованих систем). Керівництва призначені для постачальників і користувачів всіх автоматизованих систем (АС, синонім комп'ютеризованої системи), які можуть вплинути на якість продукції [23].

Міжнародна організація по фармацевтичному інжинірингу – ISPE допомагає організувати обговорення названих вище керівництв серед широкої професійної громадськості в рамках фармацевтичної промисловості та займається фінансуванням підготовки й публікації керівництв. У такий спосіб Керівництва GAMP пройшли вже кілька бурхливих етапів еволюції:

1-й проект 02/94 обговорення й висловлення зауважень у промисловості Великобританії;

2-й проект 01/95 враховані та задіяні зауваження від 31 фірми;

Версія 1.0 03/95 тільки в електронній версії, як 2-й проект, але із включеним Додатком HECnoGMP;

Версія 2.0 05/96 перегляд, враховані та задіяні інші зауваження з Європи й США;

Версія 3.0 03/98 перегляд, поділ на «Керівництво для користувача» та «Керівництво для постачальника», додавання Тома 2;

Версія 4.012/01  перероблена редакція.

Остання версія керівництва GAMP являє собою значний прогрес у порівнянні з попередніми версіями. Документ був повністю переглянутий й організований таким чином, щоб він одночасно відображав регуляторні вимоги всіх належних практик (GxР, тобто, GMP,GCP,GLP й GDP) [6].

Призначення керівництва GAMP – допомагати компаніям з медичної промисловості (фармація, біотехнологія, предмети медичного призначення) у досягненні валідованих і сумісних АС. У документі також приводяться рекомендації для постачальників АС із питань розробки й підтримки таких систем відповідно до вимог GxР і створення необхідної документації, яка необхідна для валідації, тобто «Надання документованого доказу, який надає високий ступінь упевненості в тому, що специфічний процес послідовно виготовляє продукцію, яка відповідає заздалегідь складеним специфікаціям і реквізитам якості» (FDA, 1987) [5].

AС складається з HW, SW і компонентів мережі, включаючи всі функції й відповідну документацію. Керівництва GAMP можна використати для автоматизованого технологічного обладнання, автоматизованого лабораторного устаткування, контролю процесу, керування виробництвом (MES), керування лабораторною інформацією (LIMS), планування виробничих ресурсів (MRP II), керування даних із клінічних випробувань і систем керування документацією.

Не всі дії, наведені в керівництвах GAMP, можна застосовувати до всіх систем. Фармацевтичний виробник повинен специфікувати необхідні дії, стандарти й обов'язки в плані валідації, але також забезпечити те, щоб вимоги відображалися в проектах, погоджених між користувачем і постачальником. Визнано, що існують й інші прийнятні методи, чим ті, які описані в керівництвах GAMP, і які, у свою чергу, здатні домогтися відповідної валідованої АС.

Користь від керівництва GAMP полягає в першу чергу:

• у впровадженні єдиної термінології;

• у зниженні витрат і витрат часу на одержання відповідних систем;

• у визначенні моделі життєвого циклу;

• у відмові від ретроспективної валідації;

• у розподілі обов'язків і відповідальності між користувачем і постачальником;

• у впровадженні методів для невпинного поліпшення з урахуванням підвищення вимог нормативних документів;

• у поліпшенні організації проектів;

• у порівнянні існуючих стандартів, схем (ISO 9000, TickIT) і допомоги постачальникам у розумінні GxР;

• у впровадженні керівництв і зразкових методів;

• у впровадженні ефективних систем [7].

 

 

 


РОЗДІЛ 2

ОСНОВНІ ЕТАПИ ПРОВЕДЕННЯ ВАЛІДАЦІЇ КОМП’ЮТЕРИЗОВАНИХ СИСТЕМ

2.1 Загальні принципи валідації компю’теризованих систем у відповідності з GAMP

2.1.1 Огляд валідації компю’теризованих систем.

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

Ковбасюк - Валідація

Рис. 1. Схема валідаційних дій при валідації АС

• Специфікація вимог користувача (URS) – описує те, що очікується від системи (що буде робити система), і звичайно складається користувачем. Первинна версія URS може бути включена в завдання, що відправляється потенційним постачальникам. Дана версія повинна включати всі необхідні вимоги (що повинна забезпечувати система), але також й інші вимоги (що могла б забезпечувати система). Остаточна редакція URS може бути розроблена після вибору постачальника. Вимоги повинні бути пов'язані з PQ, у ході якої проводиться тестування системи в її робочому середовищі, включаючи також суміжні процеси.

• Функціональна специфікація (FS) – звичайно складається постачальником і докладно описує функції обладнання або системи (тобто, що буде система робити). Первинна версія FS може бути розроблена як частина відповіді на завдання. Наступні редакції FS підготовлюються в співробітництві з користувачем. FS пов'язана з OQ, що тестує всі передбачені по Специфікації функції.

• Специфікація проекту (DS) – повний опис обладнання або системи, що дозволить їхнє створення. Так само, як FS, вона є виходом з проекту. Специфікація проекту пов'язана з IQ, що контролює правильність поставки обладнання або системи відповідно до необхідних стандартів і правильність інсталяції (монтажу).

• Кваліфікація проекту (DQ) – документована перевірка того, що представлений проект (цеху, систем або обладнання) відповідає запланованому призначенню. У керівництвах GAMP рекомендований термін перевірки проекту (Design Review).

• Кваліфікація інсталяції (IQ) – документована перевірка того, що інсталяція системи виконана відповідно до затверджених специфікацій.

• Кваліфікація функціонування (OQ) – документована верифікація того, що система працює відповідно до затверджених специфікацій у всіх інтервалах припустимих меж по операціям.

• Кваліфікація експлуатаційних якостей (PQ) – документована верифікація того, що система здатна виконувати або контролювати необхідні дії відповідно до затверджених специфікацій, якщо вона працює у своєму операційному середовищі по специфікації [9, 14, 20].

2.1.2 Життєвий цикл валідації автоматизованих систем.

Загальна концепція валідації пов'язана з діями по розробці та валідації і, таким чином, створює основу життєвого циклу АС:

 


Ковбасюк - Валідація

Рис. 2. Модель життєвого циклу АС

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

•        ідентифікацію системи – всі АС повинні бути описані (список), а також повинні бути ідентифіковані системи, що регулюються GxР;

•        розробка URS – зрозуміле та точне визначення необхідних дій із приведенням всіх обмежень, а також регуляторних вимог нормативної документації;

•        прийняття валідаційної стратегії:

-        аналіз ризиків – первинний аналіз ризиків виконується після складання специфікацій;

-        оцінка компонентів системи – категоризація компонентів (HW, SW) для визначення методу валідації;

-        оцінка постачальника – формальна оцінка всіх постачальників (сертифікат якості), яка може передбачати і аудит постачальника (див. PDA, TR No. 32).

•        розробка планів:

-        план валідації – розробляє користувач для визначення валідаційних дій, обов'язків і методів;

-        план якості – узгоджений між користувачем і постачальником, що визначає дії, позиції, обов'язки й методи;

-        план проекту – узгоджений між користувачем і постачальником; приводить у детальному проекті дії й важливі віхи.

• перевірка та затвердження специфікацій – користувач повинен перевірити й затвердити FS і DS, розроблені постачальником;

• моніторинг розробки системи – користувач повинен давати оцінку діям, пов'язаним з розробкою й конфігуруванням АС у порівнянні із затвердженим планом, тобто, він дає оцінку:

-        методам й інструментам;

-        принципам і послідовності дій;

-        правилам програмування й угодам;

-        методам перевірки;

-        тестуванню й верифікації;

-        захисту й конфіденційності.

• перевірка вихідного коду – користувач повинен переконатися в тому, що вихідний код у ході розробки системи підлягає адекватному перегляду;

• перевірка й затвердження специфікації тестів – перед тестуванням користувач повинен перевірити й затвердити специфікацію тестів для:

-        тестування модуля SW;

-        тестування інтеграції SW;

-        тестування прийнятності HW;

-        тестування прийнятності системи.

• проведення тестування – користувач повинен бути присутнім в процесі тестування щонайменше як свідок або як перевіряючий результати;

• розробка звіту про проведенні валідації – приводиться підсумовування всіх позицій, дій і надання доказів про проведення валідації АС;

• перевірка й затвердження звіту про тестування – користувач повинен перевірити та затвердити звіти про тестування й результати тестів;

• підтримка системи – користувач повинен прийняти адекватні методи по:

-        експлуатації системи (процедури, плани, протоколи);

-        навчанню персоналу;

-        рішенню збоїв й аварій системи;

-        технічному обслуговуванню й сервісу;

-        керуванню системою (контроль, тестування, калібрування);

-        резервуванню й обновленню;

-        керуванню конфігурацією;

-        контролю змін;

-        захисту;

-        моніторингу роботи;

-        резервуванню, архівації й відновленню даних;

-        планам прийнятності системи;

-        періодичній перевірці й оцінці.

•        вилучення системи з обігу – користувач повинен управляти:

-        процесом вилучення з обігу;

-        документальним відображенням дій;

-        збереженням протоколів GxР протягом усього періоду зберігання;

-        конверсія протоколів у нову АС (верифікація, пошук).

-        збереження HW і SW (зберігання, пошук, роздрукування);

-        переміщення в конвертовані формати файлів;

-        архівація (носії, приміщення, позначення й цілісність)

-        збереження документації про вилучену з обігу системи [2, 3].

2.1.3 Система керування для постачальників систем IT.

До систем IT відносяться MRPII (планування ресурсів виробника), LIMS (лабораторна інформаційна система керування), системи для керування виробництвом і системи баз даних. Для створення систем, які підлягають валідації рекомендується, щоб постачальники діяли відповідно до системи керування, що опирається на стандарти ISO 9000 (у першу чергу на концепцію життєвого циклу для розробки й підтримки АС) або на інструкції TickIT.

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

Життєвий цикл повинен охоплювати валідацію конфігурованих систем IT, систем IT замовника або комбінованих рішень систем IT

 

Модель життєвого циклу включає планування, специфікації, проектування, конструювання, тестування, інсталяцію, тестування прийнятності й експлуатацію:


Ковбасюк - Валідація

Рис. 3. Модель життєвого циклу IT

Для систем IT можна використати методи створення прототипів для з'ясування вимог користувача або для оцінки ризиків. Мета й призначення створення прототипів повинні бути визначені в плані якості й плані проекту. Як правило, прототип використовується для оцінки прийнятності інтерфейсу користувача, ходу процесу критичних алгоритмів, відповідності рішення в цілому або аспекту експлуатації системи (ємкість, швидкість). Такі методи вимагають послідовного контролю версій, а також сегрегації прототипу й фінального SW [7, 10].

2.1.4 Валідація системи керування (технологічними) процесами (PCS).

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

•        вбудована (embedded) PCS – частина обладнання (машини наповнення й упаковування, HPLC і т.п.):

-        програмувальна інтегральна схема (IС);

-        контролер із програмувальною логікою (PLC);

-        персональний комп'ютер (PC).

•        ізольована (standalone) PCS – замовлені/конфігуровані системи, ізольовані від обладнання (HVAC, система водопідготовки і т.п.):

-        пристрій керування багаторазових контурів або керуюча частина PLC;

-        диспетчерське керування й збір даних, система SCADА (назва класу систем для комплексної автоматизації промислового виробництва);

-        розподілена система керування (DCS);

-        система керування підприємством (BMS).

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

•        постачальник повинен відповідно до життєвого циклу надати документацію, яку можна використати для фаз кваліфікації;

• вимоги по специфікаціях повинні проходити тестування;

• протоколи тестів прийнятності повинні бути розглянуті або також і використані в ході кваліфікації (зменшення до мінімуму дублювання тестів).

Валідація вбудованого PCS звичайно вимагає співробітництва між постачальником і користувачем, але проте ряд дій звичайно стандартно виконуються постачальником. Валідаційні дії життєвого циклу незалежного PCS бувають більш масштабними в порівнянні з вбудованими PCS і звичайно вимагають комплексних інженерних робіт, що охоплюють специфікації, тестування й здавання-прийняття, причому координацією проекту займається, як правило, користувач або постачальник за контрактом [6, 18].

Модель життєвого циклу для PCS двох названих вище типів звичайно включає наступні дії:

 

Ковбасюк - Валідація

Рис. 4. Модель життєвого циклу для PCS

2.1.5 Користь від валідації комп’ютеризованих систем.

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

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

• розуміння процесу – інформація при переносі процесу та інформація постачальників надають можливість глибше зрозуміти процес;

• поліпшення ефективності виробництва – більш глибоке розуміння процесу поліпшує початкову стартову ефективність, дозволяє постійно поліпшувати процес і підвищувати ефективність виробництва в більш короткий відрізок часу;

• зниження ризику відмови – ідентифікація критичних частин процесу дозволить почати відповідні дії по запобіганню їхньої відмови;

• підтримка стандартів якості – результати й тенденції PCS надають попередження про зміни процесу, а разом із глибоким розумінням критичних параметрів процесу стають інструментом для керування діями в ході процесу для підтримки відповідності [6, 7].

2.1.6 Вимоги належних практик щодо валідації комп’ютеризованих систем.

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

2.1.6.1 Належна практика по документації.

Даний документ вимагає забезпечення наступних аспектів та принципів:

•        визначення формату документації (структура, стиль, нумерація);

•        контроль версій документів;

• документ повинен зберігатися разом зі змінами й доповненнями;

• у регістрі документа повинні бути наведені посилання, назви, статус випуску в обіг;

•        документація й інформація повинні:

- зберігатися в безпечному місці із захистом згідно СОП;

- бути захищені від випадкового або навмисного ушкодження;

- бути відслідкованими на протязі всього періоду збереження.

• документ до прийняття й випуску в обіг повинен бути позначений грифом «проект»;

• перегляд документів:

- приведення типу перегляду;

- документування проблем або проектів;

- верифікація дій;

- звіт про перегляд і копія переглянутого документа зберігаються.

•        затвердження повинне бути:

- виконано підписом із проставлянням дати;

- підтверджено заявою про те, що містить затвердження;

- у колонтитулах кожного документа.

•        затверджені документи повинні бути захищені, тобто:

- доступність для використання;

- неприпустимість використання незатверджених або вилучених з обігу документів;

- видача контрольованих копій;

- позначення неконтрольованих копій;

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

•        зміни в затверджених документах:

- повинні проходити перевірку, яку проводять ті ж посадвці або організації, які виконали перевірку й затвердження оригіналу;

- повинні бути зареєстровані із приведенням опису зміни й ідентифікації пов'язаних документів.

•        вилучені з обігу документи варто архівувати з особливим позначенням.

2.1.6.2 Належна практика по тестуванню.

Даний документ вимагає забезпечення дотримання наступних аспектів і принципів:

• проведення тестів по заздалегідь визначеним і затвердженим методам або протоколам;

• опис тестів у документах, які зберігаються залежно від контролю версії відповідно до належної практики по документації;

• початок тестів тільки після затвердження методів;

• тести повинні охоплювати всі області обладнання або системи;

• планування й проведення тестів підготовленими, кваліфікованими спеціалістами;

• спеціалісти, що проводять тестування, повинні бути незалежними й не повинні бути авторами тестів;

• контролюючі спеціалісти повинні бути незалежними й не повинні бути розробниками тестів або виконавцями тестів;

• документація по тестуванню повинна містити ПІБ, займану посаду й дату для авторів, спеціалістів, що виконують тестування, і спеціалістів, що контролюють тестування;

• метод проведення тесту повинен бути досить докладним, щоб можна було тест повторити, він повинен посилатися на релевантну специфікацію;

• документація по тестуванню повинна містити дату й підпис особи, що проводить тестування, а також свідка або контролюючого;

• повинні бути в наявності заздалегідь прийняті критерії приємності або опису очікуваного результату по кожному тесту;

• у ході проведення тесту результати повинні записуватися або варто приводити посилання на роздруківки або на файли по проведенню тестування;

• супровідна документація повинна бути підписана, датована й позначена посиланням на релевантний тест;

• документація по тестуванню й результати повинні зберігатися, у тому числі первинні спостереження й дії, які необхідні для реконструкції й оцінки тесту;

• запис тесту, виконаний вручну, повинен бути розбірливий й не повинен містити стенографічних записів, перекреслювань, знаків повторення або стрілок;

• виправлення повинні бути виконані перекреслюванням первинного тексту лінією, що залишить цей текст розбірливим, завізовані й датовані з короткою пояснювальною запискою;

• кожен текст повинен бути завершений висновком про те, чи була досягнута відповідність із критерієм прийнятності;

• відхилення повинні фіксуватися й контролюватися;

•        критичні входи в прилади й обладнання повинні бути калібровані:

- документоване підтвердження калібрування, в порівнянні з відповідним стандартом;

- каліброване обладнання повинне бути сертифікованим.

• результати повинні перевірятися на правильність і комплектність;

• проведене тестування підлягає аудитові (QA).

2.1.6.3 Належна інженерна практика.

GEP вимагає забезпечення дотримання наступних аспектів і принципів:

•        застосування інженерних методів і стандартів протягом життєвого циклу (перевірка контрактів, планування, специфікація, проект, створення, тестування, приймання, кваліфікація й валідація, підтримка, виведення системи з робочого статусу й вилучення з обігу);

•        типові підтримуючі дії по окремим фазам життєвого циклу:

- перевірка й інспектування проекту;

- контроль документів;

- контроль інвентаризації;

- керування конфігурацією;

- контроль змін;

- контроль і відпуск SW включаючи контроль версій;

- контроль субпідрядників і роботи по контракту;

- контроль задіяного матеріалу, у тому числі й матеріалу, що поставляється під замовлення;

- рекламації замовника в постачальника, у тому числі надання звітів про проблеми й інциденти навчання персоналу і його кваліфікація.

•        система керування якістю повинна:

- виражати роль керування й відповідальності;

- приводити принципи по якості в даній компанії;

- забезпечувати проведення й протоколювання дій відповідно до прийнятої методики.

•        проекти виконуються відповідно до планів по якості, які:

- визначають вимоги до якості й спосіб відповідності нормативним документам;

- повинні бути у відповідності із системою постачальника;

- повинні дозволяти перевірку проекту, інспекцію і тестування;

- включають належну практику по документації й тестуванню.

•        GEP повинна забезпечувати:

- проект й інсталяцію, що опираються на вимоги GxР, безпеки здоров'я, навколишнього середовища, ергономії, експлуатації, підтримки, промислові директиви й статутарні вимоги;

- керування проектом, інжинірингом, закупівлею, конструкцією, інсталяцією й здаванням-прийняттям;

- відповідну документацію, у тому числі концепцію, проект схем і креслень, креслень дійсного стану, протоколів тестування, керівництв по обслуговуванню й експлуатації, керівництв по технічному обслуговуванню й ремонту та статутарних сертифікатів [7, 10].

Керівництва GAMP створили фундамент у першу чергу для роз'яснення взаємин між постачальниками й користувачами АС у системі охорони здоров'я. Впровадження моделі життєвого циклу (включаючи валідацію) і дотримання вимог GxР приведе до уточнення та підвищення прозорості всіх дій. За рахунок цього також досягається значний ріст ефективності контролю над АС у цілому, що є основною умовою для дотримання принципів GAMP.

2.2 Аналіз ризиків для валідації автоматизованих систем

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

GMP вимагає, щоб користувачі АС зрозуміли ризики, пов'язані із впровадженням й експлуатацією АС. Тому процес аналізу ризиків звичайно розглядає наступні питання:

•        Чи потрібна валідація АС?

• Який обсяг валідації потрібен для даної АС?

• Які аспекти АС або процесу є критичними для продукту або безпеки пацієнта?

• Які аспекти АС або процесу є критичними для продажів?

Ціль аналізу ризиків – розглянути й оцінити ризики, пов'язані з експлуатацією АС, ідентифікувати й звести до мінімуму наслідки несприятливих ситуацій, а також обґрунтувати валідаційні дії [5, 6].

2.2.1 Проект, аналіз ризиків і валідація АС.

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

Звичайно аналізи ризиків проводяться при:

• розробці специфікації вимог користувача (URS);

• оцінці постачальника й розробці функціональної специфікації (FS);

• перевірці проекту перед валідаційним тестуванням;

• введенні критичних і значних змін в АС.

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

Підтвердження попередніх висновків або їхніх змін варто завжди послідовно записувати.

Приведена нижче схема показує звичайні дії реалізації проекту АС із прив'язкою до звичайних валідаційних дій. На схемі також показане місце аналізів ризиків:

Ковбасюк - Валідація

Рис. 5. Схема реалізації проекту АС із прив'язкою до валідаційних дій

Аналіз ризиків повинен виконуватися спеціальною проектною групою, що має інформацію про стан проекту АС і валідаційні дії. Склад такої групи буде залежати від складності й способу створення АС. Після проведення аналізу ризиків група повинна скласти відповідний звіт, що повинен бути затверджений власником і користувачем системи, а також QA. Залежно від фази проекту висновки аналізів ризиків можуть також затверджуватися й іншими особами (сторонні фахівці, постачальники) [6].

2.2.2 Порядок проведення аналізу ризиків.

Порядок проведення аналізу ризиків звичайно відповідає наведеній нижче схемі [7]:


Ковбасюк - Валідація

Рис. 6. Схема порядку проведення аналізу ризиків

2.2.2.1 Ідентифікація процесу.

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

2.2.2.2 Ризик для GxР.

Важливим кроком аналізу ризиків є оцінка того, чи представляє довільна функція або підфункція АС ризик з урахуванням вимог GxР. Даний крок можуть виконувати тільки ті експерти, які досконально знають проблематику GxР і здатні визначити вплив даної функції на вимоги GxР. Тому що вимоги GxР носять масштабний характер, нижче наведені тільки деякі приклади можливих ризиків:

•        якість готової продукції (у тому числі й зразків для клінічних досліджень):

-   неправильний склад;

-   помилки у вихідних і пакувальних матеріалах;

-   цілісність результатів QC;

-   неправильний статус серії;

-   відкликання серії;

-   відслідкованість серії;

-   помилки в маркуванні й т.п.

•        безпека пацієнта:

-   несприятлива реакція;

-   змішання зразків продукції;

-   неадекватний обіг;

-   скарги на моніторинг.

•        зареєстрована інформація:

-   схоронність результатів розробки;

-   неточна статистична обробка;

-   неадекватна структура досьє.

Проектна група повинна поступово розглянути кожну функцію або підфункцію й скласти висновок про вплив на GxР (бланк-форма для аналізу ризиків).

У випадку якщо група визначить, що відсутній який-небудь ризик з погляду GxР, то такий обґрунтований висновок повинен бути записаний в бланк-форму аналізу ризиків для майбутнього роз'яснення валідаційного підходу (державному компетентному органу, третій стороні).

2.2.2.3 Ризик для продажів.

Наступний крок процесу аналізу ризиків – розгляд і оцінка того, чи представляє функція або підфункція АС ризик для продажів. До типових ризиків, пов'язаних з торгівлею, відносяться:

•        репутація компанії:

-   несприятливий розголос;

-   вплив на прибуток;

-   втрата конкурентних переваг.

•        визнання торговельної марки:

-   лояльність замовників;

-   лояльність ланцюжка постачальників.

•        ризик для технологічного обладнання:

-   простій;

-   ушкодження;

-   витрати на заміну вузлів і деталей;

-   можливість травмування (безпека).

У випадку якщо функція або підфункція не представляє ніякого комерційного ризику, то цей факт варто відбити в бланку-формі по аналізу.

2.2.2.4 Ризикові ситуації.

У випадку якщо дана функція або підфункція одержали оцінку ризикових для GxР або продажів, варто ідентифікувати різні ситуації, що описують передбачувані ризики АС. Для кожної ризикової ситуації корисно описати й загальні ймовірні наслідки. Наприклад:

Таблиця 1. Приклад імовірних ризикових ситуацій

"Ковбасюк - Валідація

 

2.2.2.5 Імовірність ризику.

Наступний крок – розгляд імовірності або періодичності, з якою відбуваються ризикові ситуації. Такий розгляд вимагає виділити відрізок часу або кількість операцій (дій), у ході яких може відбутися ризикова ситуація, наприклад:

• низька періодичність - 1 ризик на 10 000 дій;

• середня періодичність - 1 ризик на 1 000 дій;

• висока періодичність -1 ризик на 100 дій;

У багатьох випадках ризикові ситуації можуть бути наслідком систематичних помилок програмного забезпечення – SW і можливо, що група не зуміє вгадати ймовірність такої ситуації. У таких випадках варто присвоїти «високе» значення ймовірності, якщо відсутній який-небудь документований доказ високої надійності і якості SW.

2.2.2.6 Наслідки ризику.

Аналіз ризиків вимагає не тільки визначити безпосередній вплив передбачуваного ризику (GxР, продаж), але також дати оцінку довгостроковим або розширеним наслідкам. Для подібної оцінки необхідно прийняти до уваги широкий спектр можливостей, у тому числі й наслідки для реєстрації або репутації компанії у замовників і постачальників.

Приклад: Безпосередній вплив проблем з вінчестером (жорстким диском) може означати втрату деяких даних, збережених на цьому диску. Комерційні наслідки знищених даних по дистриб’юції можуть привести до серйозних проблем у випадку необхідності відкликання продукції з ринку або критична невідповідність із регуляторними вимогами, що може вилитися в регуляторні санкції (наприклад, вилучення ліцензії на виробництво).

Наскільки серйозними можуть бути наслідки ризикової ситуації можна дати оцінку за допомогою наведеної нижче шкали:

• низькі – невеликі негативні наслідки, без довгострокового впливу;

• середні – помірні наслідки, які вносять середньостроковий шкідливий вплив;

• високі – значні негативні наслідки з довгостроковим впливом або короткостроковим катастрофічним впливом.

2.2.2.7 Категорія ризику.

Після оцінки ймовірності ризику й визначення рівня значимості загального наслідку можна визначити категорію ризику (1 - висока, 2 - середня, 3 - низька) по наступній таблиці:

Таблиця 2. Визначення категорії ризику

Ковбасюк - Валідація

2.2.2.8 Виявлення ризику.

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

Для оцінки ймовірності виявлення ризикової ситуації можна скористатися наступною класифікацією:

• низьке детектування – імовірність виявлення відсутня (менше, ніж 1:3);

• середнє детектування – адекватне виявлення (наприклад, 1:2);

• високе детектування – відмінне виявлення (наприклад, 1:1).

2.2.2.9 Пріоритет ризику.

Комбінація встановленої категорії ризику й передбачуваної ймовірності детектування ризику дозволить присвоїти ризику його пріоритет (1 – низький пріоритет, 2 – середній пріоритет, 3 – високий пріоритет).


Таблиця 3. Визначення пріоритету ризику

Ковбасюк - Валідація

Область із високим пріоритетом буде означати серйозну проблему для експлуатації й використання АС.

Приклад: Умова з категорією ризику 1, але низьким рівнем детектування, перебуває в області високого пріоритету ризику. При проектуванні АС можна направити увагу на цю область і вмонтувати поліпшені засоби виявлення, що приведе до зниження пріоритету ризикової ситуації.

2.2.2.10 Стратегія пом'якшення ризику.

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

•        модифікація елементів процесу або системи:

-        включення інструментів незалежного контролю в процес, прив'язаний до АС (наприклад, додаткова верифікація даних при введенні даних);

-        введення зовнішнього методу (подвійний контроль);

-        впровадження випробуваних методів, інструментів і компонентів АС (дублювання компонентів, резервна система, контроль операційного середовища й т.п.).

•        модифікація стратегії проекту:

-        зміна персоналу (досвід, кваліфікація, навчання);

-        зміна затвердженої й контрольованої документації, впровадження/скасування аналізу ризиків.

•        модифікація валідаційного підходу:

-        розширення тестування (особливо для помилок певних функцій);

-        зниження обсягу тестування у зв'язку з екстремально низьким ризиком;

• виключення ризику – новий спосіб виробництва, тому що ризик занадто високий [6, 7].

Приклад бланка-форми для аналізу ризиків:

Ковбасюк - Валідація

2.3 Аналіз ризиків системи керування

Аналіз ризиків для системи керування описаний у керівництвах GAMP «Валідація систем керування» (Validation of Process Control Systems). Мова йде про специфічний вид діяльності, при якій необхідно приймати до уваги не тільки власне систему керування, але і його прив'язку до виробничих, допоміжних й обслуговуючих систем. З урахуванням даного факту аналіз ризиків розділений на три фази:

• вихідна оцінка ризику;

• визначення критичності компонентів;

•        визначення критичності SW.

Так як в кожній фазі звичайно задіяна інша методологія для оцінки ризику, нижче буде показаний типовий підхід для кожної фази аналізу ризиків [6, 7].

2.3.1 Вихідна оцінка ризику.

Первинна оцінка проводиться на підставі впливу розглянутої системи на якість випускаємої продукції. Для подібної оцінки використовується методика, описана в керівництві ISPE «Прийомка й кваліфікація» (Commissioning and Qualification), яку можна схематично зобразити:

Ковбасюк - Валідація

Рис. 7. Схема проведення прийомка й кваліфікації системи керування

•        перший крок – ідентифікація всіх систем і визначення границь для виробничих систем й устаткування (обслуговуючих систем, допоміжних систем);

•        другий крок – оцінка прямого впливу на якість продукції, тобто, система:

-        вступає в контакт із продуктом (HVAC, N2, повітря і т.п.);

-        надає компонент продукту або середовище для виробництва (PW, WFI, розчинники і т.п.);

-        використовується для очищення/стерилізації (PW, CIP, чистий пар);

-        захищає продукт (N2, стерильне повітря і т.п.);

-        надає інформацію для видачі дозволу на реалізацію готової продукції (DCS – розподілена система керування і т.п.);

-        управляє процесом без незалежного контролю (PLC-контролер із програмувальною логікою, DCS-розподілена система керування і т.п.).

•        третій крок – визначення прив'язки (впливу) до системи прямого впливу.

2.3.2 Визначення критичності компонентів.

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

• Чи використається компонент для зареєстрованого процесу?

• Чи має компонент прямий вплив на якість?

• Чи зробить відмова/аларм компонента прямий вплив на якість?

• Чи надає компонент інформацію, що відноситься до протоколу виробництва серії?

• Чи вступає компонент у контакт із продуктом або його складовими?

• Чи керує компонент  частиною  процесу без незалежної верифікації?

• Чи використовується компонент для захисту критичної системи?

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

•        система прямого впливу включає:

-        критичні компоненти – регулюються GEP і підлягають кваліфікації;

-        некритичні компоненти – регулюються GEP.

•        система непрямого впливу/без впливу:

-        не містить критичних компонентів;

-        включає некритичні компоненти – регулюється GEP

2.3.3 Визначення критичності SW.

Системи керування із прямим впливом на якість продукції вимагають ще й третьої фази аналізу ризиків. У цій фазі проводиться докладна оцінка SW з погляду функціональності системи й впливи на параметри процесу. Для подібної оцінки повністю використовуються рекомендації GAMP (див. попередній опис), причому оцінка критичності спрямована в першу чергу на:

• ідентифікацію критичних параметрів, що керуються від системи;

• категоризацію системи керування (SW);

• вплив на GxР, безпеку або середовище.

Результатом аналізу стає вибір критичних параметрів процесу, критичних для GxР, безпеки або середовища, у тому числі й опис способу керування ними й моніторинг самої, котрий виконує сама система керування [6, 7].

2.4 Аналіз ризиків змін

Оцінка ризиків повинна зберігатися протягом усього життєвого циклу АС. Після повної валідації АС буде перебувати в так називаному провалідованому стані. Проте у ході застосування АС відбуваються зміни. Звичайно АС мають схильність до збоїв у початковій фазі після реалізації зміни, тому що вводяться всі неправильні або недостатньо вивчені зміни і їхні можливі наслідки для АС. Використання методу аналізу ризиків у рамках процесу керування змінами дозволить впровадження належної стратегії для пом'якшення, ідентифікації, верифікації й повторного тестування змін перед впровадженням останніх у рутинних операціях.

Аналіз ризиків – метод, що у цей час використовується досить часто з метою оцінки складних систем з погляду передбачуваного ризику для пацієнта й виробника лікарських засобів. На підставі такого підходу можна потім обґрунтувати скорочення валідаційних дій і направити зусилля валідаційних груп і виконавчих груп на проблемні області системи. Аналіз ризиків у такий спосіб допомагає заощадити значну частину засобів і прискорює процес впровадження АС у виробництво лікарських засобів [6].

2.5 Специфікації на комп'ютеризовані системи

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

Крім рекомендацій з базового керівництва GAMP й уточнення окремих специфікацій у його додатках, інші коментарі, у тому числі й відношення до життєвого циклу комп'ютеризованих систем, наведені в главі 11 додатка до керівництва GAMP — Валідація систем керування процесом. Нижче наведено кілька рекомендацій, що стосуються специфікацій і проектів, як основних інструментів для розробки системи й, у свою чергу, головних передумов для валідації:

•        чітко донести URS до постачальника;

•        визначити обсяг поставки;

• надати користувачеві можливість зрозуміти бізнес-план постачальника;

• створити платформу для проведення тестування до власне поставки й кваліфікації;

• підтримувати роботу прикладної програми протягом життєвого циклу;

• підтримувати будь-який подальший розвиток системи;

• для цілей розробки системи збирати допоміжну інформацію:

-   опис процесів;

-   баланс матеріалів у процесах;

-   схеми інженерних мереж;

-   стратегія виробництва;

-   умови навколишнього середовища.

Ковбасюк - Валідація

Рис. 8. V-модель /V-образний життєвий цикл/ специфікації й валідації комп'ютеризованих систем

На рисунку 8 показано, як можуть бути прив'язані три основних складових валідації, тобто, кваліфікація установки, функціонування й експлуатації, до трьох основних рівнів специфікацій на розроблювальну, інстальовану систему, яка підлягає валідації (так звана V-образна схема життєвого циклу – V-model).

Дана модель відповідає опису циклу розробки по стандартах ISO, у якому вихідна специфікація на одному щаблі розробки є вхідною специфікацією для наступної ступені [16, 21].

Першою складається специфікація вимог користувача (User Requirements Specification, (URS)), що також називають специфікацією користувача, причому звичайно складання такої специфікації розділено на два етапи. URS – вихідний документ для складання функціональної специфікації (Functional Specification, (FS)), яку уже звичайно складають фахівці із систем керування. На підставі URS й FS розробляється в якості останньої специфікація проекту або технічні вимоги до проектування (Design Specification, (DS)), у більшості випадків окремо для хардвера (DS-HW) і софтвера (DS-SW). Якщо система складна, то розробляється окремий проект для кожного рівня (модуля).

У випадку якщо в ході проектування, створення або валідації системи відбудуться зміни (керована зміна у відповідності зі стандартною процедурою), зміни повинні відображатися у відповідній специфікації таким чином, щоб до початку валідації специфікації були в актуальному стані [12].

2.5.1 Специфікація вимог користувача.

URS звичайно складається користувачем й описує, які передбачувані питання буде система вирішувати, що буде виконувати. Вихідна версія URS може бути включена в завдання по тендеру (запрошення на участь у тендері Invitation То Tender — ITT), що направляється потенційним постачальникам системи. Перша версія URS повинна містити всі необхідні (обов'язкові) позиції й, по можливості, пріоритетний набір вимог користувача до системи.

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

URS – ключова частина специфікацій на комп'ютерну систему, вона також є основою для складання контракту (див. також стандарт ISO 9001 — Контроль контракту) з постачальником. У випадку якщо URS не є безпосередньо невід'ємною частиною контракту, то кінцевий користувач повинен, щонайменше, взяти на себе обов'язки по затвердженню даного документа [3, 16].

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

2.5.1.1 Розробка URS.

Специфікація користувача повинна чітко і ясно визначати, що користувач (замовник) очікує від системи.

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

У ході розробки URS варто дотримуватися наведених нижче вказівок:

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

• Дані у вимогах не повинні повторюватися, але також не повинні суперечити один одному:

- URS повинна виражати вимоги, а не пропонувати рішення;

- Будь-яка вимога повинна бути тестуємою;

- URS повинна бути зрозуміла як замовникові, так і постачальникові, без двозначності й жаргону.

- По можливості URS повинна розрізняти серйозні або обов'язкові вимоги й затребувані характеристики.

- Якщо буде потреба варто перевірити, що URS була однаково зрозуміла замовником і виконавцем, а пізніше – були (або не були) вимоги описані в FS [5, 16].

2.5.1.2 Зміст URS.

GAMP визначає розділи й частини, які повинні бути включені в URS. Всі частини повинні обов'язково знаходитись в URS. У випадку якщо вимога не була визначена, то треба у відповідному розділі (підрозділі) зробити ремарку «Неможна використовувати».

Вступ

Повинен містити наведену нижче інформацію:

• хто створює документ, відповідно до яких нормативних документів і з якою метою;

• договірний характер документа;

• прив'язка до інших документів.

Огляд

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

• закулісну сторону питання (тобто, загальну стратегію, попередні дослідження);

• ключові цілі й вигоди;

•        головні функції й інтерфейс;

• задіяні вимоги GxР;

• інші нормативні документи.

Вимоги до роботи системи

У цій главі варто привести вимоги до роботи системи (операційні вимоги) – функції системи, дані й інтерфейси. Необхідно також визначитися по середовищу, у якій система повинна працювати. Критичні вимоги повинні бути зазначені. Може бути включений опис процесу, блок-схеми процесу. Особлива увагу варто приділяти вимогам GxР, у тому числі й посиланням на нормативні документи.

Функції

В даній частині повинні бути визначені затребувані функції системи, робочі режими й поведінка системи. Повинно бути описане наступне:

• Затребувані функції. Сюди варто віднести інформацію про процес або існуючу ручну систему, якщо останні не описані адекватно в іншому місці;

• Розрахунки включаючи критичні алгоритми;

• Операційні режими (запуск, вимикання, тестування, аварійні ситуації);

• Вимоги до продуктивності й хронометражу (кількісний, однозначний);

• Збої, тобто, дії, необхідні на випадок збою певного софтвера або хардвера;

• Безпека й захист.

Дані

Ця частина повинна містити вимоги по поводженню з даними. Варто звернути увагу на наступне:

• Визначення даних, включаючи ідентифікацію критичних параметрів, діапазону дії даних і меж;

• Вимоги до продуктивності;

• Вимоги до швидкості доступу;

• Вимоги до пересилання на зберігання (архівації);

• Захист і цілісність даних (21CFR11).

Інтерфейс

Дана частина повинна визначити інтерфейси системи. Вона повинна містити наступне:

• Інтерфейс користувача. Визначення повинне бути виражене в категоріях штатного розкладу (наприклад, виробничий оператор, комірник, менеджер системи і т.д.) або в категоріях функцій;

• Інтерфейс – границя розділу з іншими системами;

• Засоби сполучення з обладнанням (наприклад, датчики або функціональні елементи). Сюди ж відноситься й список входів-виходів систем керування процесами.

Середовище

Ця частина повинна визначити середовище, у якій система буде працювати. Вона повинна містити наступне:

•        Розміщення, тобто, фізичну організацію цеху або інших робочих місць, які можуть вплинути на систему (наприклад, з'єднання на великій відстані, обмеження простору);

•        Фізичні умови (брудне, пильне або стерильне середовище і т.д.).

Обмеження

Дана частина повинна визначити обмеження в специфікації системи. Вона повинна містити наступне:

• Часовий масштаб, контрольні точки;

• Сумісність. Необхідно приймати в розрахунок всі існуючі системи, хардвер і будь-яку стратегію фірми (internet і т.п.);

• Доступність. Варто привести вимоги до надійності й максимально припустимим періодам для техобслуговування й інші тимчасові перерви;

• Процедурні обмеження (наприклад, зобов'язання, передбачені законом, юридичні питання, методи роботи й рівень навичок користувача);

• Техобслуговування (наприклад, простота техобслуговування, можливість розширення, імовірне поліпшення, передбачуваний термін служби, довгострокова підтримка).

Життєвий цикл

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

• Розробка (наприклад, методи керування проектом і забезпечення якості, обов'язкові методи проектування);

• Тестування (наприклад, спеціальні вимоги по тестуванню, тестування даних, тестування навантаження, моделювання);

• Поставка. У даній частині визначаються затребувані позиції. Повинне бути наведене наступне:

-        як повинна виглядати ідентифікація поставлених позицій;

-        у якому виді повинні бути позиції поставлені (формат і носії);

-        документи (функціональна специфікація, методи тестування, специфікація проекту і т.д.);

-        дані, які повинні бути підготовлені або конвертовані;

-        інструменти;

-        курси по навчанню персоналу;

-        пристрій збереження даних.

•        Підтримка, необхідна після приймання.

Словник термінів

Дана частина повинна містити визначення понять, які можуть бути невідомими для користувача URS.

URS повинна охоплювати наступні області:

•        вимоги до хардверу;

- аспекти архітектури системи;

- експлуатаційне середовище;

- регулююче встаткування;

- інтерфейс оператора;

- фізичний захист.

•        вимоги до софтверу:

-        необхідна функціональність прикладної програми;

-        обіг з аварійними сигналами;

-        рівні доступу;

-        візуальне зображення;

-        логічний захист.

•        інтерфейс системи:

- зовнішнє підключення;

- обслуговуючі системи (утиліти);

- інші системи.

•        дані:

- критичні параметри;

- швидкість доступу;

- збереження(архівація);

- цілісність і захист даних [16, 27].

2.5.2 Функціональна специфікація.

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

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

FS – вихідна специфікація проекту, що описує функції системи (див. також стандарт ISO 9001 — Вихід проекту).

FS повинна докладно описувати те, що повинна робити система, але не те, як це повинне виконуватися в технологічних категоріях, що записано в URS. Повинна бути створена матриця відстеження вимог між URS та FS.

Паралельно з уточненням FS можуть проводитися роботи по планам тестування й специфікаціям проектів. Остаточна версія FS по всіх функціях може бути створена навіть у ході розробки робочого проекту [16].

2.5.2.1 Створення FS.

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

FS повинна визначити адекватні компоненти програмного забезпечення, пов'язані з послугами, затребуваними в URS.

При створенні FS варто керуватися наведеними нижче вказівками:

• кожне обмеження повинне бути чітко визначене;

• двозначність, дублювання й протиріччя потрібно повністю виключити;

• повинні бути послідовно задіяні тільки прийняті позначення;

• всі функції й пристрої повинні бути тестуємими;

• ясне вираження всіх функцій, щоб можна було продовжувати роботу без частих консультацій з користувачем [10, 16].

2.5.2.2 Зміст FS.

GAMP визначає, які розділи повинні знаходитися в специфікації. Всі частини повинні обов'язково мати місце. У випадку якщо вимога не була визначена, то треба у відповідному розділі зробити ремарку «Неможна використовувати».

Вступ

Даний розділ повинна містити наступну інформацію:

• хто створює документ, відповідно до яких нормативних документів і з якою метою;

• договірний характер документа;

• прив'язка до інших документів.

Огляд

Даний розділ повинен привести необхідні функції системи і інтерфейси з периферією. У розділі повинно бути наведене наступне:

• Ключові цілі й вигоди;

• Посилання на відповідні правила GxР;

• Опис рівня вищого порядку. Тут повинно бути зазначено поділ на основні підсистеми;

• Головні інтерфейси системи з периферією;

• Передумови. У даній частині повинні бути перераховані всі вимоги, що мають відношення до проекту або реалізації (наприклад, стандартні пакети, OS, HW);

• Розбіжності з URS. Повинні бути прописані розходження між РЗ і ШЗ.

Функції

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

Опис функцій повинен включати наступні аспекти:

• Призначення функції або обладнання й деталі по його застосуванню, у тому числі й інтерфейси з іншими частинами системи. Необхідно підкреслити критичні розрахунки й алгоритми;

• Продуктивність — реакція, точність і пропускна здатність програми. Ці дані повинні бути представлені в кількісному вираженні й бути повністю чіткими;

• Безпека й захист. Теми повинні містити: дії у випадку відмови обраного програмного забезпечення й хардвера, самоконтроль, первинну валідацію, дублювання даних, обмеження по доступі, перевищення межі за часом і відновлення даних;

• Функції, які підлягають конфігурації й будь-які межі, в інтервалі яких конфігурація може перебувати.

• Відслідкованність до специфічних вимог URS.

Дані

В даному розділі повинні бути визначені дані, з якими система буде працювати. Необхідно відзначити наступні аспекти:

• Визначення. Дані повинні бути визначені по ієрархії, шляхом створення складних об'єктів із простих (наприклад, файли протоколів; складні знаки, певні за допомогою простих знаків). Повинні бути підкреслені критичні параметри;

• Доступ (наприклад, які підсистеми мають потребу в доступі для читання або запису по кожній позиції даних, метод доступу, швидкість і час актуалізації, блокування для читання й запису);

• Інформаційна ємність, період збереження й деталі по архівуванню даних;

•        Цілісність і захист даних;

Інтерфейс

Даний розділ повинен визначати будь-які інтерфейси системи.

Вона повинна містити наступні частини:

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

• Засоби сполучення з обладнанням (наприклад, датчики або функціональні елементи);

• Інтерфейси з іншими системами, включаючи й характер взаємодії;

Дана частина повинна включати:

-        відсіяні й прийняті дані;

-        тип і формат даних, інтервали й значення величин;

-        установка часу;

-        швидкість передачі;

-        комунікаційний протокол — початок і послідовність виконання;

-        поділ даних, їхнє створення, дублювання, використання, збереження або стирання;

-        механізми про виклик або переривання;

-        комунікація через параметри й загальні області;

-        прямий доступ до внутрішніх даних;

-        обіг з помилками;

-        захист інтерфейсу.

Неробочі властивості

В даному розділі повинно бути визначено, як система буде виконувати вимоги неробочого характеру. Вона повинна містити наступні частини:

• Застосовність (наприклад, надійність, резервування, контроль помилок, операції у випадку аварії);

• Підтримка (наприклад, можливості розширення й поліпшення, вільна ємність, імовірні зміни в середовищі, термін служби).

Словник термінів

Дана частина повинна містити визначення понять, які можуть бути невідомими для користувача FS.

Додатки

В тих випадках, де це має сенс (наприклад, для невеликих систем), можуть додаватися додатки з метою визначення специфікацій HW й SW [16].

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

2.5.3 Специфікація проекту (DS).

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

DS – це власне детальний проект всіх частин системи, причому як HW, так SW. На стадії розробки DS починається також робота над:

• керівництвами користувачів по обслуговуванню й експлуатації технічних вимог;

• стандартними операційними процедурами (СОП);

• складанні графіка навчання персоналу;

• деталями договорів сервісного обслуговування;

• безпекою комп'ютеризованої системи і т.п.

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

Для DS використовуються наступні типові документи:

• план цеху або компонування обладнання (Plant or Equipment Layout) спрощує ідентифікацію й розміщення головних компонентів обладнання й системи;

• схема процесу й приладів (Process and Instrument Diagram, P&ID) описує хід технологічного процесу й розміщення контрольно-вимірювальних приладів;

• таблиця контурів і приладів (Loop and Instrument Schedule) ідентифікує (звичайно у формі таблиць) кожну окрему позицію контрольних і вимірювальних контурів. Проводить індикацію попереджувальних сигналів, обладнання входів-виходів, критичних параметрів, вимірювального інтервалу й допусків, точок відключення при аварії, помилкових дій, деталей прив'язки процесу, взаємне об'єднане блокування;

• послідовність технологічних операцій/логіка/взаємне блокування (Process Sequences/Logic/Interlocks) приводить необхідні контрольовані операції процесу, у тому числі й всі автоматичні ланцюжки й блокування. Використовуються форми матричні схеми або блок-схеми;

•        креслення взаємного з'єднання (Inteconnection Drawings) використовуються головним чином для зовнішніх приладів і містять деталі всієї електропроводки, пневматичного розведення, включаючи кінцеві елементи, кольори, нумерацію, номінальну потужність і полярність. Креслення повинні бути досить докладними для монтажу, інсталяції й діагностики помилок [5, 16].

2.5.4 Специфікація проекту апаратного забезпечення.

DS — HW (HDS) виходить із відповідної FS. Визначає окремі частини HW, які утворять весь HW системи, а також інтерфейси з іншими HW системами.

Зміст DS буде залежати від складності конкретної системи. У простих систем можна включити дану специфікацію в FS. Рекомендується, щоб в DS для наочності використовували графіки й схеми. Якщо такі діаграми створюються в іншій частині документації, то в DS варто привести перехресне посилання на них.

Зазначений нижче процес створення DS відповідає рекомендаціям із Плану якості й проекту [7, 16].

2.5.4.1 Зміст DS — HW.

GAMP визначає, які розділи повинні знаходитися в DS— HW. Всі частини повинні обов'язково мати місце. У випадку якщо вимога не була визначена, то треба у відповідній главі зробити ремарку «Неможна використовувати».

Вступ

Повинен містити наступну інформацію:

• хто створює документ, відповідно до яких нормативних документів і з якою метою;

• привязка до інших документів.

Огляд

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

Комп'ютерна система

Даний розділ повинен описувати загальну конфігурацію системи хардвера. Це можна продемонструвати за допомогою блок-схем з пояснювальними зауваженнями. Повинні міститися  наступні частини:

•        Система головного комп'ютера

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

•        Завантаження в пам’ять

Даний підрозділ описує всі запропоновані проектом засоби завантаження в пам’ять із максимальною ємністю, наприклад, жорсткий диск, дискета, стрічка, CD-ROM.

•        Периферія

У даному підрозділі повинні бути описані периферійні пристрої, що поставляються. Будь-які спеціальні кришки або монтаж повинні бути також описані.

•        Взаємне з'єднання

Даний підрозділ описує взаємне з'єднання всіх компонентів хардвера й будь-які взаємні з'єднання з іншим устаткуванням. В опис повинні бути включені наступні елементи:

-   специфікація кабелів;

-   специфікація роз’ємів;

-   вимоги по екрануванню й захисту;

-   схеми компонування;

-  мережне й зовнішнє з'єднання.

•        Конфігурація

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

Входи й виходи

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

- цифрові входи;

- цифрові виходи;

- аналогові входи;

- аналогові виходи;

- лічильники імпульсів.

Для кожного вимірювального приладу або групи вимірювальних приладів варто брати до уваги наступні елементи:

-    точність;

-    ізоляція;

-    інтервали струму й напруги;

-    тип і число інтерфейсних карт;

-    хронометраж.

Середовище

Даний розділ повинен описувати операційне середовище хардвера. Варто охопити перераховані нижче області:

-    температура;

-    вологість;

-    зовнішні впливи;

-    фізичний захист;

-    вплив електромагнітного випромінювання (HF, NF, UV).

Енергопостачання

В даному розділі повинні бути описані вимоги по енергопостачанню (електроенергія) для конфігурованої системи хардвера. Мова йтиме про наступні елементи:

-    фільтрування;

-    навантаження;

-    захист заземленням;

-    джерела безперебійного питания, ИБП (UPS).

Словник термінів

Дана частина повинна містити визначення понять, які можуть бути невідомими для користувача URS.

У випадку якщо DS — HW визначає вбудовані (вкладені) системи, то у відповідних секціях варто привести наступну інформацію:

• Схема розверстки деталей панелі керування, а також внутрішньої й зовнішньої конфігурації;

• Діаграми розміщення датчиків й інших пристроїв на обладнанні;

• Переліки  всіх  компонентів, що  утворять систему керування;

• Схема електромереж;

• Креслення P&ID;

• Посилання на задіяні стандарти [3, 16].

2.5.5 Специфікація проекту програмного забезпечення (SDS).

Наголос робиться головним чином на те, як буде функціональна специфікація перенесена в SW для обраного HW. Специфікація повинна визначати логічну й фізичну структуру, стандарти, використані для найменування файлів, розміщення етикеток з найменуваннями й назва модуля. Для розуміння й тестування необхідно коментувати і код програми, а також всі нестандартні вимоги. Для невеликих систем можна включити дану специфікацію в FS.

SW повинен бути визначений разом з підсистемами, з яких буде складатися вся система програмного забезпечення (software), але також й інтерфейси між такими підсистемами. Визначення повинні бути чіткими й точними. Можна також всі системні дані (перемінні) визначити окремо (наприклад, у словнику даних). У випадку якщо дані визначені окремо, необхідно даний факт пояснити й задокументувати.

Далі можна з однієї FS створити більш, ніж одну DS — SW. У таких випадках на кожну подібну специфікацію повинно приводитися чітке посилання з можливістю відстеження лінії аж до відповідної функції (функцій) в FS.

Схема для наочності системи, системні файли й інші структури даних не носять обов'язковий характер, але, повинні бути створені. Якщо такі схеми створюються десь в іншому місці, то повинно бути наведено перехресне посилання на них.

У випадку якщо визначені вкладені системи, то варто привести зазначену нижче інформацію:

• структурна схема або інше зображення того, як досягаються необхідні функції;

• докладний опис задіяних алгоритмів;

•        розклад всіх повідомлень;

•        схематичний опис всіх дисплеїв блоків візуалізації [7, 16].

2.5.5.1 Зміст DS — SW.

GAMP визначає, які розділи повинні знаходитися в DS — SW. Всі частини повинні обов'язково мати місце. У випадку якщо вимога не була визначена, то треба у відповідному розділі зробити ремарку «Неможна використовувати».

Вступ

Повинен містити наступну інформацію:

• хто створює документ, відповідно до яких нормативних документів і з якою метою;

• прив’язка до інших документів.

Огляд

Даний розділ повинен коротко описувати в документі розроблений проект. Вона повинна служити скоріше як вступ в проект, чим містити докладну інформацію про систему.

Повинно бути показано, як система ділиться на підсистеми, тобто, детальні рівні проекту.

Опис системи

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

Системні дані

Даний розділ повинен виділити системні дані й визначити основні об'єкти даних. Дані повинні бути визначені ієрархічним способом, створенням складних об'єктів із простих об'єктів. Об'єкти повинні включати:

-    базу даних і збір файлів;

-    файли;

-    протоколи;

-    типи даних.

Кожен файл і структура даних повинні бути чітко ідентифіковані. Варто взяти до уваги використання моделей (типу) об'єкт – відношення, модель (типу) сутність – зв'язок (у реляційних базах даних) («Entity RelationshipModels») або подібних.

Опис модуля

Для кожного модуля повинно бути описане наступне:

• Робота модуля. Опис може бути у формі псевдокоду;

• Інтерфейс із іншими модулями. Якщо створено схему системи, то достатньо у формі посилання на схему;

• Будь-які специфічні фактори хронометражу, які не зазначені в описі системи;

• Обіг з помилками й валідація даних;

• До яких системних даних дозволений доступ модуля.

Словник термінів

Дана частина повинна містити визначення понять, які можуть бути невідомими для специфікації проекту програмного забезпечення [3,16].

2.5.6 Зміст специфікації модуля.

Дана частина повинна докладно описувати кожен модуль. Формально вона організована подібно, як DS — SW. Призначення – ідентифікувати дані модуля у відповідності з наступними рекомендаціями для підпрограм:

•        робота підпрограми (і псевдокод);

•        параметри, повинен бути ідентифікований кожен:

-   вхідний параметр;

-   вихідний параметр;

-   вхідний і вихідний параметр.

•        кожен параметр повинен бути визначений, як минулим значенням так і минулим посиланням;

•        всі побічні дії підпрограми;

•        мова, у тому числі й версія;

•        посилання на всі стандарти програмування.

DS – це фактично (de facto) комплексний проект системи в цілому, відповідно до якого система може бути створена незалежно від автора. Обсяг проекту буде дуже різним, для категорій 1 й 2, як правило, не буде містити ні софтвер, ні окремих робочих креслень. Навпаки, для вищих категорій буде дана документація досить об'ємна й може включати (у складних випадках) також наступні області:

• виробничі схеми (Process and Instrument Diagrams, Piping and Instrumentation Diagrams, P&ID);

• механічні креслення (Mechanical drawings);

• електричні креслення (Electrical drawings).

Структурований проект (structured design) також містить оцінку ризиків і детальне планування подальших етапів життєвого циклу системи, головним чином для фази створення, тестування й пуску в експлуатацію. DS – основний документ для валідації системи – повинен також служити й для навчання персоналу [3, 7].

Специфікації на прості компоненти, підсистеми або всю комп'ютеризовану систему, причому як HW, так й SW, необхідні не тільки для цілей створення системи, але також і для валідації. Внаслідок причини «економії часу на підготовку й впровадження» постачальники іноді змушені створювати систему без специфікацій, але такий підхід завжди приводить до неконтрольованих змін, поганій роботі системи, продовженню часу на створення, неможливості валідації й, нарешті, до необхідності заміни системи.

2.6 Категорія софтвера й хардвера

Посібник з Належної автоматизованої виробничої практики GAMP 4 (додаток М4), подібно до попередньої версії GAMPa, розподіляє програмне забезпечення (Софтвер – Software, SW), задіяне в автоматизованих системах при виробництві й контролі лікарських засобів, по п'ятьох базових категоріях. Як новинка введені також дві категорії по апаратних засобах комп'ютеризованих систем (Хардвер – Hardware, HW). Залежно від включення системи в одну з таких категорій і визначається потім відповідний підхід до валідації системи.

При визначенні категорії варто чітко визначитися по призначенню й рівню системи керування, але також обґрунтувати запропоноване рішення. Розподіл по категоріях виходить із ризику відмови системи. Часто також приймається до уваги попереднє використання подібних прикладних систем. У випадку складних систем не можна, як правило, віднести систему як ціле до однієї категорії, тому що частини системи містять різні рівні й, тим самим, відносяться до різних категорій. У такому випадку до відповідних категорій відносять окремі частини системи й використовують подібну схему при розробці підходу до валідації [25, 28].

2.6.1 Категоризація систем.

Автоматизовані (комп'ютерні, керуючі,комп'ютеризовані) системи охоплюють широкий діапазон прикладних комп'ютерних операцій:

· технологічне устаткування;

· контрольне устаткування;

· лабораторні прилади;

· системи керування виробництвом;

· системи керування лабораторією;

· склади;

· видача дозволу на реалізацію;

· дистрибуція [21].

2.6.2 Категорії SW.

SW можна віднести до наступних категорій:

2.6.2.1 Категорія 1. Операційні системи.

По операційній системі (OS) використовуються два, досить різні, визначення:

• OS – це набір програм, які дозволяють комунікацію між HW і прикладними програмами;

• OS – це SW, що управляє виконанням програм.

Забезпечує такі послуги, як:

· розподіл ресурсів;

· призначення ресурсу (resource allocation);

· розподіл планування (scheduling);

· керування входом-виходом (input/output control);

· керування даними (що включає в себе збір, аналіз, зберігання, пошук, обробку й розподіл даних) (data management).

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

OS як така звичайно не проходить специфічне тестування або як складова певних прикладних систем, які в ній працюють. Варто користуватися добре відомими й перевіреними операційними системами, а точна назва й версія повинні бути записані в ході кваліфікації встановленого устаткування /IQ/ SW (або ж у ході тестів прийнятності при кваліфікації функціонування /OQ/ HW устаткування).

Нові версії операційних систем необхідно перед інсталяцією перевірити, причому варто дати оцінку можливого впливу нових, доданих або усунутих властивостей на прикладні системи. Це значить, що у випадку проведення вагомої зміни OS, необхідно виконати повторне тестування прикладних систем в обсязі OQ [7].

Приклади OS: (BIOS), MS DOS, DrDOS, OS/2, Windows, Linux, UNIX, MacOs, VMS.

2.6.2.2 Категорія 2. Firmware – програмно-апаратні засоби; вбудовані програми; «зашиті програми» (у ПЗУ).

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

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

Несанкціоновану, без документального відображення, інсталяцію нових версій FW у ході техобслуговування або сервісного обслуговування варто повністю виключити. До будь-якої зміни, причому навіть до повторної інсталяції тієї ж версії, варто додавати суворий режим керування змінами. Варто розглянути можливість впливу нових версій на силу дії висновків IQ та іншої документації й почати відповідні дії, як, наприклад, повторна валідація устаткування або розширений моніторинг.

FW, розроблену під замовлення, варто віднести до категорії 5 [7].

Приклади firmware (у більшості випадків вони не мають самостійного тривіального імені, поставляються як складова устаткування): ваги, пристрій зчитування штрих-коду, PID (пропорційний інтегрально-диференціальний регулятор), аналітичні прилади (титратор, рН-метр, хроматограф, лічильник колоній і т.п.).

2.6.2.3 Категорія 3. Стандартні пакети програм.

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

Параметри процесу задаються у випадку введення.

Немає необхідності виконувати комплексну валідацію стандартних пакетів SW, але слід дотримуватися певної обережності при інсталяції нових версій. У ході IQ варто перевірити правильність імені та версії пакета. У ході OQ варто задокументувати, розглянути й протестувати вимоги користувача, такі, як:

-   захист;

-   операції при сигналах тривоги;

-   алгоритми й розрахунки.

Варто ретельно ознайомитися з документацією постачальника (посібника з обслуговування й експлуатації), а в деяких випадках може бути корисним такий інструмент, як аудит постачальника. Необхідно розробити СОПи й програму по навчанню й підготовці персоналу. Інші рекомендації з даної категорії SW можна знайти, наприклад, у стандарті ISO/IEC 12119 "Інформаційні технології — Пакети програм — Вимоги до якості й оцінка якості".

Так само, як для інших категорій, і в цьому випадку варто використовувати суворий контроль керування змінами, тому що зміна даних прикладних програм (наприклад, інсталяція версії вищого порядку) часто здійснюється дуже легко й швидко, але може мати небезпечні наслідки [7].

Приклади стандартних пакетів SW: Adobe Acrobat, Statgraphics, аналітичні SW (HPLC й ін.).

2.6.2.4 Категорія 4. Конфігуруємі пакети програм.

Тільки у випадку якщо система й платформа досить відомі, можна віднести SW до даної категорії. Якщо ж мова йде про нові додатки або вперше використовуваних програмах, то їх варто віднести до категорії 5.

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

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

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

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

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

Валідація повинна бути спрямована на шари задіяного програмного забезпечення – SW та їх можливі категорії. У валідаційному плані повинна відбитися оцінка постачальника й всі спостереження, зроблені в ході аудита в останнього, критичність, довжина й складність прикладних програм. Варто визначитися по стратегії зниження наявності яких-небудь слабких ланок у процесі розробки програм у постачальника [7].

Приклади: контролер із програмувальною логікою – тип контролерів, які використовуються для автоматизації промислових процесів (Programmable Logical Controller, PLC), розподілена система керування (Distributed Control System, DCS), диспетчерське керування й збір даних, система SCADA (Supervisory Control and Data Acquisition, SCADА), системи керування виробництвом (Manufacturing Resource Planning, MRP, Material Requirement Planning, MRP II, Manufacturing Execution System, MES, Enterprise Resources Planning, ERP), лабораторна інформаційна й керуюча система (Laboratory Information Management System, LIMS).

2.6.2.5 Категорія 5. Системи, сформовані замовником, або виготовлені під замовлення.

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

З метою перевірки системи якості постачальника необхідно провести в останнього аудит. Аудит постачальника повинен підтвердити наявність адекватних систем якості для контролю розробки прикладних програм та їхньої поточної підтримки. У випадку відсутності документальної системи якості постачальники повинні керуватися положеннями GAMP.

У плані валідації варто передбачити перевірку всього життєвого циклу. Валідація повинна бути спрямована на вкладені шари SW та їхньої категорії. План повинен відображати висновки аудита, критичність, довжину й складність прикладних програм. У плані повинна бути визначена стратегія за рішенням будь-яких слабких ланок, виявлених у процесі розробки програм постачальника.

Слід зазначити, що складна система, яка розробляється під замовлення, часто складається з багатошарової програми – SW, а одна система може характеризуватися властивостями декількох або навіть всіх перерахованих вище категорій (див. приклади категоризації) [7].

2.6.3 Стратегія валідації для різних категорій.

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

У наведеній нижче таблиці показаний загальний принцип підходу до валідації по окремих категоріях, які описані вище [7]:

Таблиця 4. Загальні принципи підходу до валідації по окремих категоріях

№ п/п

Категорія SW

Підхід до валідаиії

1

операційні системи

запис версії

2

firmware

запис конфігурації, калібрування, перевірка роботи

3

стандартні пакети

запис версії, перевірка роботи

4

конфігуруємі пакети

запис версії й конфігурації, перевірка роботи, аудит постачальника валідація (верифікація) процесу виробництва

5

пакети замовника

аудит постачальника й валідація укомплектованої системи

2.6.4 Табличні процесори

Особливу групу SW являють собою табличні процесори, які надають можливість обробляти дані від простого запису в таблицю до складних розрахунків, статистичної обробки й графічного зображення. Раніше такі системи відносили до 3-ї категорії, необхідно, однак, розрізняти категоризацію залежно від функцій і рівня роботи з даними. У простих випадках вигідно користуватися з виводом даних з табличного процесора скоріше як з документом, чим як із прикладною програмою. Розрахунки й використання формул варто перевіряти.

У випадку якщо в кінцевій фазі не створюється друкований документ, то табличні процесори також повинні відповідати правилам, які регулюють електронні документи, як, наприклад, 21CFR11. При використанні табличних процесорів існують, проте, спірні питання по керуванню або збереженню даних у пам'яті згідно GxР, тому що відсутні внутрішні контрольні інструменти, необхідні для забезпечення цілісності даних (сервіс контролю доступу, що гарантує, що прийняті по мережі дані не були змінені при пересиланні). Необхідно приймати до уваги ряд ускладнень, що створюють певні труднощі:

· одне або кілька робочих місць (ідентична версія);

· контроль доступу до прикладної програми й даних (користувачі, розроблювачі);

· конфігурація прикладної програми;

· один або кілька модулів;

· введення даних тільки через клавіатуру;

· висновок зберігається у файлі або роздруковується;

· використання логічних функцій і пошуку макрокоманди.

Підводячи підсумок можна сказати, що табличні процесори відносяться до категорії 3, 4 або 5. Використання пакета програм табличного процесора виключно для генерування паперового документа варто вважати категорією 3. Включення більш складної прикладної програми, наприклад, шаблона, варто віднести до категорії 4. Програма табличного процесора з використанням макрокоманд або логічних і пошукових функцій повинна бути віднесена до категорії 5 [6, 27].

2.6.5 Інструменти розробки й діагностики.

Наступна особлива група SW – інструменти для розробки прикладних програм та їх діагностики. Такі інструменти варто відрізняти від SW, які безпосередньо беруть участь у виробництві, контролі, складському зберіганні і т.п.

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

Інструменти, що підтримують скоріше розробку системи й керування процесом програмування, не відносяться до області, яка регулюється GxР, і не вимагають формальної валідації. Цей факт, однак, ніяким чином не впливає на необхідність ретельно вибирати інструменти, адекватно ними користуватися й брати до уваги наступні фактори:

· визначення вимог, по яких можна буде дати оцінку SW і постачальникам;

· оцінка надійності інструмента і його постачальника;

· вимоги й обмеження або контроль використання, що випливають із правил;

· перевірка функціональності.

Прикладами таких інструментів є: регулююча програма, статичні аналізатори коду, модулі керування конфігурацією, моделювання процесу, програмування й діагностика PLC та автоматизовані інструменти для тестування. У випадку якщо використовується інструмент, виконаний під замовлення або дороблений під замовника, то потрібна особливо ретельна, докладна й документально відображена перевірка [7].

2.6.6 Категорії хардвера (апаратних засобів).

2.6.6.1 Категорія 1. Стандартні компоненти HW.

Стандартні компоненти хардвера варто описати в документах разом з докладною інформацією про виробника або постачальника й номер версії. У ході приймання хардвера або IQ перевіряється інсталяція й з'єднання компонентів. По готовому хардверу необхідно записати модель, номер версії й номер серії. Заздалегідь змонтований HW із установленою пломбою не можна розбирати, якщо це може привести до втрати гарантії. У таких випадках докладну інформацію можна одержати з документації постачальника HW. Застосовується керування конфігурацією й контроль змін [7].

2.6.6.2 Категорія 2. Компоненти HW під замовлення.

Крім вимог по категорії 1, по позиціях, виконаним під замовлення, необхідна наявність специфікації на проект; у ході приймання таких позицій повинне бути передбачене контрольне тестування. Для розробки хардвера під замовлення необхідно провести аудит постачальника.

Складені системи, у яких задіяний виконаний під замовлення HW з різних джерел, вимагають перевірки на сумісність взаємно з'єднаних компонентів. Будь-яка конфігурація HW повинна бути перевірена в ході IQ. Застосовується керування конфігурацією й контроль змін [7].

2.6.7 Оцінка ризику.

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

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

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

2.6.8 Приклади категоризації систем.

2.6.8.1 Розподілена система керування.

DCS звичайно містить кілька різних категорій SW. Операційна система й мережний SW можуть бути віднесені до категорії 1. Операції керування блоками для установки циклів і керуючих функцій можуть бути віднесені до категорії 3. Застосування мови керування завданнями (Task Control Language) для роботи із циклами SW може бути віднесене до категорії 4. Специфічна конфігурація процесу може бути віднесена навіть до категорії 5. Якщо буде потреба визначити категорію системи як цілого, береться вища категорія складових прикладних програм (4 або 5) [6, 7].

2.6.8.2 Незалежна система PLC/SCADA (standalone system – ізольована система).

PLC використовуються для керування роботою автоматизованого устаткування або (частини) технологічного виробництва. Тип проекту (design) устаткування або процесу й використання PLC необхідно приймати до уваги при визначенні стратегії валідації.

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

У тих випадках, коли нова прикладна програма опирається на діючу систему, необхідно виконати оцінку впливу нової прикладної програми або зміни дійсного пакета SW на валідний стан PLC. Така оцінка повинна включати історію використання й кількість (планованих) модифікацій. Варто також взяти до уваги розмаїтість набору команд PLC. Остаточною класифікацією системи може бути або категорія 4 або (у випадку нового проекту) прикладна програма може бути віднесена до категорії 5.

SCADA, як підказує назва, не представляє повністю автоматизоване виробництво, але систему, зосереджену на певній комплексній проблемі. Система, як правило, взаємодіє з декількома PLC й іншими модулями HW. Типовим для такої системи є наявність приблизно від тисячі до декількох десятків тисяч I/O каналів.

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

Таблиця 5. Приклад розділення системи на підсистеми – PLC/SCADA

Ковбасюк - Валідація

Ковбасюк - Валідація

2.6.8.3 Пакувальне устаткування (Packaging equipment) — вбудована система (embedded system).

Валідація повинна бути спрямована на ті частини устаткування, які впливають на якість продукції. З контрольних систем, крім базового PLC з відповідним забезпеченням (OS, ladder, COTS), до це групі можна віднести контрольні ваги (weight scale), принтери етикеток (label printer), пристрої які зчитують штрих-код (bar code reader) і інші пристрої індикації (identification, ID), механізми відбраковування (reject unit), регулятори температури (temperature controlling) і часу (timer), необхідні для нагрівання й зварювання в ході процесу пакування в термоусадочну плівку, автоматичний on-line детектор (check) і мережне з'єднання (network cabling).

Окремі компоненти системи керування варто розглядати залежно від функції й рівня втручання оператора або програміста. Перераховані нижче частини системи можуть бути віднесені до категорій 2-5 [6]:


Таблиця 6. Приклад розділення системи на підсистеми – пакувальне устаткування

Ковбасюк - Валідація

2.6.8.4 Використання персональних комп'ютерів (Personal computers, PC).

Типи прикладних програм, які будуть працювати на персональному комп'ютері, визначають стратегію валідації. PC широко використовуються зі стандартними пакетами програм і табличних процесорів, наприклад, Lotus 1-2-3 або Microsoft Office (Word, Excel). Звичайно їх відносять до категорії 3.

На сьогоднішній день, PC усе більше використовуються для більш спеціалізованих додатків, таких як, наприклад, моніторинг часток, зважування, збір даних або навіть керування виробництвом. Деякі з подібних прикладних програм можуть працювати зі стандартними компонентами (категорія 4), або можуть бути розроблені під замовлення (категорія 5).

У певних випадках автоматизоване обладнання може відправляти інформацію за допомогою лінії передачі даних на комп'ютер, призначений для аналізу даних і генерування звітів. PC більшою мірою використовуються для керування процесами автоматизованого обладнання (комунікація PC-PLC). Цілісність подібних з'єднань є критичним параметром й у програмі валідації варто приділити її оцінці належну увагу.

При використанні PC завжди необхідно приділяти підвищену увагу доступу, захисту й цілісності даних, тому що стандартне виконання PC, які працюють у середовищі Windows з дискетами (CD, DVD) і підключенням до internet, створює ряд можливостей для відмови системи (комп'ютерні віруси, переповнення системи паралельно оброблюваною інформацією у форматі МРЗ та ін.) [6, 7].

Вибір стратегії валідації прямо залежить від типу задіяних компонентів SW та HW. У цьому випадку є практичний сенс віднести систему до рекомендованої категорії або розділити систему керування на частини, які можна класифікувати подібним способом. У такому випадку роботи по валідації будуть зосереджені на категорії 5 або ж 4 (SW) і 2 (HW), а інше забезпечення валідуєтся тільки в обмеженому обсязі або перевіряється як складова валідації прикладних програм, віднесених до вищих категорій.

2.7 Життєвий цикл і перспективна валідація систем керування

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

Такий метод значно відрізняється від рутинного виробництва типових компонентів (технічні засоби/програмне забезпечення – HW/SW), які можна ретельно перевірити на можливості й надійність. По типових компонентах, які пройшли такі випробування, виконується потім тільки поточний і вихідний контроль у рамках серійного виробництва.

Комплексні АС, які створюються для фармацевтичної промисловості, звичайно являють собою унікальну розробку, причому або частини, або системи в цілому. Така система звичайно створюється в єдиному екземплярі (оригінал), тому основна вимога полягає в тому, щоб система почала працювати відразу, з першої спроби. У цьому випадку не представляється ефективним контроль такої АС після її реалізації, але рекомендується внести такі операції прямо в проект, починаючи з ранніх його стадій. Одночасно представляється корисним розділити весь проект на послідовні етапи, які по завершенні (або в ході реалізації) завжди перевіряються як комплекс. Подібна перевірка окремих етапів проекту одержала назву валідації. Весь же процес реалізації АС із убудованими контрольними операціями й роботами по валідації називають "життєвим циклом" системи [16, 17].

Проект створення комплексної АС, що буде також містити й створення системи керування типу PLC/ SCADA (Programmable Logic Controller/Supervisory Control and Data Acquisition) або DCS (Distributed Control System), прив'язку цієї системи до керованих систем й устаткування, а також відповідної проектної роботи й роботи з валідації, був досить наочно розроблений організаціями GMA й NAMUR у рекомендації «Виконання проекту системи керування, що підлягає валідації» (GMA/NAMUR, NE 58 – Execution of process control projects subject to validation). Дана рекомендація була пізніше перероблена й опублікована як складова частина керівництва GAMP «Валідація систем керування процесом» (Validation of Process Control Systems).

Нижче буде розглянутий найбільший за обсягом робіт проект як ціле (тобто, планування, розробка, впровадження й валідація) незалежної (автономної – standalone) системи керування в рамках його життєвого циклу. Зрозуміло, що обсяг робіт по перерахованих етапах для вбудованих (embedded) і конфігуруємих (cofigurable) систем керування буде значно менший [12, 7].

2.7.1 Перспективна валідація систем керування.

2.7.1.1 Автоматизована система й керуючий SW (Automated Production System and Control System Software).

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

Ковбасюк - Валідація

Рис. 9. Схема автоматизованої системи

Програмне забезпечення – SW, що використовується в даній АС, віднесено відповідно до керівництва GAMP до категорії 4, якщо SW можна параметризувати, або до категорії 5, якщо необхідно розробити спеціальне програмне забезпечення – SW або адаптувати стандартне програмне забезпечення – SW. GMP вимагає проведення валідації АС у випадку, якщо АС може вплинути на властивості і якість продукції або створює документацію по виробництву й контролю продукції [25, 26].

2.7.1.2 «V»-образна модель перспективної валідації (The V Model ofProspective Validation).

Валідаціоні дії, які необхідно виконати при перспективній валідації, діляться на перевірку проекту (DR, Design Review або кваліфікацію проекту – DQ, DesignQualification), кваліфікацію установки (IQ, Installation Qualification), кваліфікацію функціонування (OQ, Operational Qualification) і кваліфікацію в процесі експлуатації (PQ, Performance Qualification). Окремі щаблі валідації виконуються в прив'язці до специфікації проекту (DS, Design Specification або Detail Engineering), функціональної специфікації (FS, Functional Specification або Basic Engineering) і специфікації вимог користувача (URS, User Requirement Specification). Наступна схема наочно зображує так звану «V»-образну модель валідації АС, що приводить послідовність і взаємозв'язок між окремими діями, а також документи, у тому числі й ідентифікацію окремих етапів виконання проекту в цілому, які будуть описані нижче.

Ковбасюк - Валідація

Рис. 10. Схема «V»-образної моделі валідації АС

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

IQ – виконання й документальне оформлення перевірок з метою доказу того, що інсталяція АС відповідає своєму призначенню. Це значить, що всі аспекти інсталяції відповідають нормативним документам і затвердженій проектній документації, а також, що враховано рекомендації постачальників. Формально до IQ відноситься:

•        інспекція апаратних засобів (HW):

-   контроль ланцюга передачі даних;

-   конфігурація даних керуючого обладнання;

-   калібрування вимірювальних приладів.

• контроль відповідності із специфікаціями HW;

• тести на функціональність HW:

-   перевірка укомплектованості системних блоків;

-   тести кабельного з'єднання з периферійними пристроями;

-   тести датчиків, пультів керування й підсистем;

-   перевірка заземлення й електромагнітного екранування.

•        перевірка інсталяції SW.

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

PQ, у свою чергу, являє собою документально оформлену перевірку АС у режимі рутинної роботи при випуску фактичної продукції. Ціль PQ – перевірити, що АС працює відтворено відповідно до заздалегідь прийнятих вимог і виробляє відповідну продукцію [16, 28].

2.7.2 Виконання проекту (Project Execution).

Основу концепції «життєвого циклу» становить стандартний план структури проекту (робіт із проекту), що формально доповнений за рахунок робіт з валідації. Стики між окремими фазами проекту утворені вхідними й вихідними документами, які гарантують виконання вимог з попередньої фази. Валідаційні дії, у свою чергу, забезпечують комплектність і правильність виконання всіх фаз проекту [6].

2.7.2.1 Опис процесу – Специфікація вимог користувача (Process Oriented Description – User Requirement Specification).

Проектні дії

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

• опис технологічного процесу;

• попередня схема технологічного процесу;

• запланована продуктивність;

• «ноу-хау» діючих виробництв і факти з літератури;

• визначення завдань і вимог по АС (альтернативи);

• виділення систем й одиниць устаткування, від яких залежить якість продукції;

•        визначення умов середовища:

- розміщення й прив'язка до інших систем;

- вимоги до площі (габарити);

- технічні умови.

•        вимоги по операціях (вплив на продукцію);

•        поводження системи в різних станах (запуск, вимикання, помилки);

•        вимоги по безпеці;

•        вимоги до персоналу.

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

Наведена вище інформація буде оброблена й представлена у формі URS, у якій звичайно приводиться наступна інформація:

• опис розміщення й інфраструктура АС;

• визначення завдань АС;

• докладний опис і схема процесу;

• опис виробничого цеху;

• схема технологічного процесу;

• обсяг автоматизації;

• функціональне керування виробництвом;

•        матеріали, габарити, середовище;

• аналітичні методи й прилади;

• необхідна витрата енергії;

• вимоги по доступності;

• вимоги по безпеці;

•        нормативні документи по АС.

Валідаційні дії

В рамках робіт з валідації необхідно перевірити проект URS й іншу проектну документацію на відповідність вимогам GMP, а також розподіл обов'язків і відповідальності з проектом, реалізацію й валідацію. Необхідність такої перевірки випливає із загальної концепції валідації, описаної у Валідаційному Майстер-Плані (ВМП – VMP, Validation Master Plan) [7].

2.7.2.2 Попереднє технічне планування (Preliminary Engineering).

Проектні дії

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

• ідентифікація змінних (tags);

• опис процесу:

- якість продукції;

- операційні режими;

- взаємне поєднання;

- методи оптимізації;

- специфічні умови.

•        вимоги до операцій процесу:

-        доступність;

-        безпека;

-        гнучкість (наприклад, зміна продукту);

-        якість продуктів;

-        структура інформації (протоколи, збереження(архівація),  обмін даними із системами вищого рівня, і т.п.);

-        цех і його візуалізація.

•        робоче середовище:

- допоміжні енергоносії;

- умови зовнішнього середовища;

- техобслуговування.

• майбутнє розширення

• інженерне рішення:

- кімната з пультами керування;

- кімната із системою керування;

- обладнання поза системою (цех).

Валідаційні дії

В даній фазі проекту АС як цілого повинен бути розроблений план валідації системи керування, що повинен охоплювати перераховані нижче області:

• обсяг валідації;

• посилання на документи, загальні нормативні документи, СОПи;

• обов'язки, організація;

• контроль змін, документація по кожній зміні;

• обіг (заміна) документів (особливо схеми трубопроводів і контрольних систем – P&ID);

Роботи з валідації повинні також включати визначення основних вимог по:

• захисту доступу до системи керування;

• відмові й відновленню системи [7].

2.7.2.3 Базовий інжиніринг (Basic Engineering).

Визначення функцій керування (Specifying Control Functions)

Проектні дії

В даній фазі проектування  автоматизації виробництва до відповідних схем P&ID додаються вимоги по способу автоматизації, регулювання й безпеки. По даних вимогах потім складається перелік всіх контурів керування й одночасно виконується класифікація таких контурів залежно від впливу на якість продукції й безпека. Для кожного контуру керування потім складається таблиця (перелік) окремих типових елементів, з яких даний контур складається. У таблиці приводиться:

• ідентифікація виробничої одиниці, контуру;

• референтні документи;

• взаємне з'єднання;

• категорія контуру;

• дата складання;

• стан по змінах (індекс).

Найважливішим завданням проектування в даній фазі є визначення функцій системи керування (із прив'язкою до URS), підготовка функціональних схем (блок-схем) для окремих функцій (типове або специфічні) і створення функціональної специфікації (FS) системи керування, що повинна описувати:

• умови цеху;

• P&ID з відповідними контурами:

-        устаткування й системи керування;

-        типові й специфічні компоненти (HW й SW);

-        інтерфейси;

-        електропроводку.

•        функціональний опис процесу керування:

-        керування зворотним зв'язком;

-        керування логікою;

-        взаємне блокування;

-        технологічний процес і спосіб візуалізації;

-        як створена система керування;

-        блок-схеми функцій.

• контури, прив'язані до якості продукції або безпеки;

• вимоги нормативних документів.

Валідаційні дії

Важливим завданням валідації є в першу чергу проведення аналізу ризиків АС (наприклад, за допомогою методу FMEA). Такий аналіз повинен включати:

•        визначення контурів і функцій, пов'язаних з якістю;

•        опис й оцінку ризиків;

• оцінку дій у надзвичайних ситуаціях;

• визначення змісту тестів і порядку їхнього документального відображення;

• специфічні вимоги по тестуванню контурів і функцій.

Після проведення аналізу ризиків або паралельно з ним варто розробити класифікацію компонентів HW й SW. Така класифікація служить у першу чергу для ідентифікації наступних позицій:

• затвердження й тестування типових компонентів;

• типові компоненти з доведенням під проект (будуть підлягати тестуванню);

• специфічні компоненти під проект (будуть підлягати тестуванню).

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

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

Встановлення даних, пов'язаних із процесом (Procuring Process-related Data.)

Проектні дії

Дані, пов'язані із  процесом, треба проаналізувати й ввести в перелік контурів, призначених для регулювання АС. Нижче перераховані такі дані:

•        інформація із процесу:

-        ідентифікація й позначення носія;

-        якість, в'язкість, провідність, щільність, температура кипіння і т.п.;

-        вибухозахист;

-        категорія безпеки.

•        вимоги до вимірів:

-        вимірювальний інтервал і помилка виміру;

-        змінна процесу (припустимі межі, сигнали тривоги).

Валідаційні дії

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

Визначення технічного виконання (Determining Technical Implementation).

Проектні дії

При визначенні технічного виконання необхідно у першу чергу визначитися по наступних технічних деталях:

• метод рішення кожної функції системи керування;

• визначення одиниць устаткування і їхніх функцій;

• визначення вимог до центрального блоку й інфраструктури;

• порядок компіляції окремих частин у єдине ціле;

У результаті розгляду можливостей технічного виконання конкретного способу керування АС створюється ряд документів:

•        актуалізовані переліки контурів;

•        перелік електроприладів;

• допоміжні енергоносії для системи керування;

• відомість позицій системи керування;

• концепція цеху;

• кількісна структура обладнання й матеріалів;

• вимоги до центральної установки;

• габаритні вимоги;

• витрати на інфраструктуру, монтаж, інженерні послуги.

Валідаційні дії

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

Найважливішим завданням, однак, є складання плану тестування для OQ, що дає визначення мети, предмета, методу, визначає допоміжні пристрої й прилади, але, у першу чергу, приводить критерії прийнятності (загального призначення або пов'язані із проектом). План тестування для OQ повинен описувати наступні кроки валідації:

•        тест функціональності HW;

• тести комунікації;

• тести роботи функцій керування;

• функціональні тести режиму роботи;

• функціональні тести додатка вищого рівня керування;

• тести сигналів тривоги системи;

• тести з навантаженням і тести захищеності системи:

-        запуск;

-        вимикання;

-        система помилок і відмов;

-        резервоване перемикання;

-        знеструмлення і т.п.

•        тести захищеності доступу;

•        перевірка «холостого ходу» [7].

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

2.7.2.4 Робочі креслення (Detail Engineering)

Визначення обладнання (Determining Equipment).

Проектні дії

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

До типових документів даної фази проектування відносяться:

- остаточні переліки контурів;

- перелік устаткування;

- специфікація на устаткування;

- кількість окремих одиниць устаткування.

Валідаційні дії

В рамках валідації звичайно проводиться розширений або новий аналіз ризиків. Одночасно варто провести перевірку наступних документів:

-        переліки контурів;

-        нормативні  документи  по тестуванню контурів;

-        специфікації на обладнання.

Визначення центральної установки (Determining Central Equipment).

Проектні дії

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

•        технічна специфікація:

- вимоги по електроенергії;

- повітря для регулювання (control air);

- компоненти пристроїв керування.

• кількісна структура;

• плани будівель і виробничих одиниць.

Дані документи призначені для тендера постачальників.

Валідаційні дії

Якщо специфічні функції системи керування для центральної установки не визначені, досить тільки проконтролювати перелік по центральній установці.

Специфікація на систему керування (Specifying Control System).

Проектні дії

Для системи керування варто визначити остаточну локалізацію й структуру (на підставі інформації з переліків контурів, концепції керування, FS). Специфікації на окремі компоненти й кількісну структуру служать для тендера й вибору постачальників.

Вихідним документом з даної фази проекту є докладна FS системи керування, доповнена за рахунок інформації про програмування й конфігурацію системи.

Валідаційні дії

В рамках валідації можна розширити аналіз ризиків для актуалізованої системи керування. Одночасно варто визначити або актуалізувати наступні документи:

• структура дозволів на допуск до системи;

• концепція тестування системи;

• перелік компонентів системи;

• концепція резервування інформації;

• СОПи, необхідні для підтримки валідованого стану.

Створення схем контурів (Generating Loop Diagrams).

Проектні дії

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

Валідаційні дії

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

Створення функціональних схем контурів (Generating Loop Function Diagrams).

Проектні дії

Функціональні  схеми (блок-схеми)  контурів являють собою опис функцій керування (реалізованих за допомогою SW) за допомогою графічних символів. Схеми включають:

•        прив'язку до блоків програми:

• I/O (входи/виходи) з перехресними посиланнями на сигнали (контур);

• з'єднання;

• перехресні посилання на адреси SW;

• кінцеві крапки;

• ідентифікація функцій, що мають відношення до якості.

Валідаційні дії

Функціональні схеми (блок-схеми) контурів мають важливе значення для опису функцій системи керування, тому в рамках валідації проводиться:

• контроль функціональних схем контурів на комплектність і призначення;

• перевірка плану тестування OQ;

•        контроль функціональних схем контурів, що мають відношення до якості.

Підготовка документів по монтажу (Preparing Assembly Documents).

Проектні дії

Завершальна фаза проектування – підготовка планів інсталяції й комплектації АС. Складовою частиною таких планів є також проведення тендера й вибір монтажних фірм.

Для монтажу окремих частин АС розробляються документи по монтажу, до яких відносяться:

• плани комплектації;

• переліки розподілів;

• схеми включення;

•        схеми кабельних з'єднань;

• креслення по інсталяції;

• переліки устаткування й матеріалів;

• плани кімнат для системи керування й пультів керування;

• плани фіксованої інсталяції.

Валідаційні дії

В рамках валідації проводиться контроль комплектності монтажних документів, вихід з якого – перелік таких документів.

Основне завдання в даній фазі проекту – розробка плану тестування для IQ, у якому повинно бути описано:

• візуальна інспекція HW і документація;

• перевірка умов навколишнього середовища (температура, вологість, запиленість);

• тести підведення електроенергії, заземлення, резервування, кабельних з'єднань, екранування, пристрої поза системою;

•        тестування I/O процесу;

• тестування типових програм (операційна система, програмно-апаратні засоби –firmware);

• тести стандартизованих захисних функцій;

• тести HW і SW, які не входять у систему керування;

• тести комунікацій;

• тести відновлення;

• контроль запасних частин [7].

2.7.2.5 Фаза впровадження (Implementation Phase).

Придбання устаткування і послуг (Procurement of Equipment and Services).

Проектні дії

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

Валідаційні дії

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

Підтвердження поставки (Confirming Delivery).

Проектні дії

Після поставки окремих частин проводиться їхній контроль і доставка по місцю інсталяції.

Валідаційні дії

В рамках валідації проводиться налагодження й контроль системи керування, перевірка функцій і документації компонентів HW/SW. У результаті складаються контрольні списки HW або також звіти з IQ/OQ по типових компонентах.

Конфігурування SW (Configuring Software).

Проектні дії

Якщо це можливо, то конфігурування SW потрібно проводити до інсталяції на місці (по можливості на цільовому HW). Звичайно цей процес включає:

• підготовку специфічних функціональних схем (блок-схем);

• конфігурацію функцій керування;

• конфігурацію функцій зображення й експлуатації;

• конфігурацію рецептур.

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

Валідаційні дії

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

• структурування SW;

• кодування типових компонентів:

• проект і розробка специфічних типових компонентів (спеціальні функції);

• тестування спеціальних функцій («тест білого ящика»);

• тестування модулів;

• тестування вбудованих частин.

Вихідними документами з даної фази валідації є валідаційні протоколи (плани) і звіти по валідації окремих тестів.

Підготовка монтажу (Preparing Assembly).

Проектні дії

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

Валідаційні дії

В даній фазі звичайно не передбачені валідаційні дії.

Моніторинг монтажу – Кваліфікація установки (Monitoring Assembly – I Q).

Проектні дії

В ході монтажу проводиться моніторинг установки окремих компонентів АС, контроль з'єднань, перевірка на місці, виправлення в документації й координація всіх постачальників й одиниць, задіяних у створенні АС.

У цій фазі потрібні сертифікати постачальників. Вихідна документація – це, у першу чергу, проектна документація дійсного стану.

Валідаційні дії

В цій фазі проводиться IQ у повному обсязі. Рекомендується підключити до валідаціцних робіт персонал цеху (операторів) і ремонтного підрозділу. Вихідна документація - звіт по валідації.

Функціональне тестування – Кваліфікація функціонування (Fractional Tests – OQ).

Проектні дії

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

Вихідна документація – це, у першу чергу, актуалізована документація системи керування й протоколи тестування.

Валідаційні дії

В цій фазі проводиться калібрування контурів, які впливають на якість, і OQ у повному обсязі. Рекомендується задіяти для цього операторів і ремонтників. На виході одержуємо звіт по валідації [7].

2.7.2.6 Здавання – прийняття (Commissioning).

Навчання персоналу (Training Personnel).

Проектні дії

В рамках здавання-прийняття АС необхідно навчити персонал і підготувати його до виконання окремих операцій.

Розробляється програма навчання, що повинна включати як загальну філософію керування, так і роз'яснення всіх робочих станів. Після первинного навчання повинне бути передбачене індивідуальне навчання по окремим модулям або функціям системи керування.

Валідаційні дії

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

Допомога при здаванню-прийняттю (Assisting Commissioning).

Проектні дії

При здаванню-прийняттю АС проводиться остання оптимізація заданих параметрів і функцій (на підставі результатів OQ) системи керування. Виходом є актуалізована документація.

Валідаційні дії

В ході валідації необхідно підготувати робочі журнали для системи керування й повністю задокументувати кроки по оптимізації. Результатом є додатки до прикладного SW, резервна версія SW й актуалізований звіт по валідації OQ.

Перегляд документації (Reviewing Documentation).

Проектні дії

В рамках здавання-прийняття АС проводиться комплектація документації побудованого стану (так звана документація дійсного стану), до якої відноситься:

•        документація вищого рівня:

-        P&ID;

-        вимоги до системи керування/ FS;

-        переліки контурів з ідентифікацією перевірки;

-        специфікації на устаткування;

-        схеми контурів;

-        функціональні схеми контурів;

-        установочні плани для двигунів, електроприладів, коробок контакторів, розподільників поза системою, перемикачів і т.п.;

-        перелік локалізації електричних контурів;

-        документація пакетів програм;

-        документація для устаткування поза системою й пультами керування;

-        перелік кабелів;

-        сертифікати безпеки (струм, напруга, пожежа, вибух, і т.п.).

•        документація по HW і SW:

-        структура системи керування процесом;

-        документація по стандартному SW (операційна система, інструменти конфігурації, прикладне програмне забезпечення – SW);

-        опис системи (кількісна структура, розміщення, резерви і т.п.);

-        документація компонентів HW (карти I/O, система шин, пульт керування оператора і т.п.);

-        станції й розподіл модулів I/O;

-        посібник з обслуговування для користувача;

-        електросистема з оглядом схем контурів;

-        енергопостачання (для системи керування) і системи UPS (для резервного джерела);

-        схема кімнат із системою керування із планами й переліками по інсталяції й складанню, переліки кодування й розподілу, перелік контурів, підготовка сигналів.

•        документація прикладного SW:

-        план структури SW;

-        документація по основним функціональним елементам і модулям;

-        ієрархія операцій і візуалізації;

-        контроль керування зв'язками й блокуваннями;

-        послідовне керування;

-        опис керування рецептурою;

-        протоколи (у тому числі й протоколи виробництва серії);

-        реалізація рівнів доступу;

-        реалізація концепції архівування;

-        інтерфейси з іншими системами й технічним оснащенням;

-        план тестування для HW і SW (модулі й загальна система);

-        протоколи результатів тестування SW.

•        загальні протоколи тестів:

- протоколи механічних й електричних тестів;

- звіт про IQ;

- звіт про OQ.

Валідаційні дії

В ході валідації проводиться контроль документації на  комплектність й актуальний стан. У рамках контролю перевіряють:

-        паперову документацію;

-        резервований SW;

-        актуальність версії (дійсної).

Документація про пуск системи в експлуатацію (Releasing Documentation).

Проектні дії

Здавання-прийняття AS проходить на підставі контракту. Після здавання-прийняття варто скласти акт про пуск системи в штатну експлуатацію.

Валідаційні дії

В ході валідації проводиться актуалізація звіту про валідації по IQ і комплектація всіх паперових документів і носіїв інформації. Не можна забувати про розробку списку документів з інформацією про місце їхнього знаходження [7].

2.7.2.7 Завершення проекту (Project Completion).

Проектні дії

Остаточна фаза проектування АС полягає в розробці заключного звіту, що містить:

• визначення всіх частин проекту;

• порядок розширення або звуження проекту;

• документальне відбиття пропозицій по поліпшенню;

• пояснення розходжень між завданням і фактичним станом

Валідаційні дії

Остаточна фаза валідації полягає в розробці заключного звіту по кваліфікації АС, у якій приводиться обсяг валідації, критерії прийнятності й отримані результати.

Після проведення валідації в повному обсязі необхідне визначення й проведення робіт, які пов'язані з підтримкою валідованого стану АС, що включає наступне:

-        забезпечення безпеки доступу в систему;

-        аварійний план;

-        резервування інформації;

-        контроль цеху;

-        сервісне обслуговування й ремонт;

-        навчання;

-        контроль змін, актуалізація звіту по валідації;

- актуалізація SW користувача;

-  збереження запасних частин

Робота АС у повну потужність є предметом кваліфікації в експлуатації (процесі) (PQ), у ході якої дається оцінка наведених вище аспектів [7].

Наведений приклад життєвого циклу АС демонструє скоріше ідеальний стан створення та валідації такої системи. На практиці, проте, дуже часто з'являється перепригування через деякі фази проектування або їхня повна відсутність. Цей факт, нажаль, значно ускладнює валідаційні дії, а в деяких випадках робить їх повністю неможливими.

Реальна валідація АС – це в більшості випадків компроміс. Обов'язок користувача АС (фармацевтичного виробника) полягає в тому, щоб він зумів довести функціональність, безпеку й надійність такої системи й обґрунтував свій метод валідації державному компетентному органу.

2.8 Система валідаційної документації

Система валідаційної документації складається з наступних частин:

1. Валідаційний Майстер План (ВМП) (VMP, Validation Master Plan);

2. Валідаційні протоколи по окремих операціях (VP, validation protocols);

3. Валідаційні звіти по окремих операціях (VR, validation reports);

4. Зведений валідаційний звіт (SVR, summary validation reports) [1].

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

У протоколі валідації варто вказати критичні стадії процесу й критерії прийнятності, а також вид проведеної валідації (первинна валідація, ревалідація, планова ревалідація та позапланова ревалідація) .

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

Будь-які відхилення від протоколу валідації повинні бути задокументовані з відповідним обґрунтуванням [4].

2.8.1 Валідаційний Майстер План.

Валідаційний Майстер План (ВМП) – один з головних документів для проведення валідації, у якому повинна бути описана загальна політика виробника відносно намірів і підходу до валідації комп'ютеризованих систем, і відносно осіб, відповідальних за розробку, перевірку, затвердження й документування кожного етапу валідації.

Основний план валідації повинен містити як мінімум наступну інформацію:

- предмет валідації;

- організаційна структура діяльності по валідації (визначити персонал, відповідальний за основний план валідації, протоколи окремих проектів по валідації, роботу з валідації, підготовку звіту по валідації, затвердження протоколів і звітів, необхідне навчання по валідації);

- опис устаткування, призначення, опис конструкції, принцип роботи та ін;

- технічне завдання користувача / User Requirements Specification;

- функціональний опис системи / Functional Specification;

- технічний опис системи / Design Specifications;

- основні критерії прийнятності;

- форма документації, форма, яку варто використати для протоколів і звітів;

- планування й складання графіка;

- контроль змін;

- посилання на існуючі документи [6].

Критичні параметри/характеристики, як правило, варто визначати на стадії розробки або на підставі даних попереднього досвіду роботи.

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

Детально розроблений ВМП – одна з головних передумов послідовного проведення всіх валідаційних операцій і контролю за ними, він повинен бути узагальнюючим документом і бути лаконічним, точним і чітким.

ВМП має статус одного з керівних документів фірми, оскільки допомагає:

- керівництву підприємства ознайомитися з обсягом програми валідації (час, персонал, устаткування, гроші) і зрозуміти його значення;

- членам валідаційної комісії – розподілити завдання й відповідальності;

- керівництву проекту здійснювати контроль за процесом;

- інспекторам GMP розібратися з організацією валідації

ВМП розробляється для загальних операцій по валідації АС і тому повинен у всіх випадках зв'язуватися з виробничими й невиробничими процесами. Оскільки поняття процесу валідації АС не завжди розуміється однозначно, для цілей валідації необхідно пояснити, що воно завжди стосується не менше трьох областей, оцінка яких повинна бути виконана у взаємозв'язку (тобто в рамках процесу валідації АС). Маються на увазі наступні області:

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

2. Устаткування (устаткування, допоміжні системи й системи забезпечення, необхідні для проведення процесу валідації АС),

3. Процедури (всі процедури й операції, проведені в рамках процесу валідації АС) [1, 6].

Для розробки ВМП важливо вже в початковій фазі підготовки виробничої одиниці призначити валідаційну комісію. Членами комісії повинні бути фахівці різних областей: проектанти, валідатори, техніки, технологи та ін. Крім розробки ВМП, комісія повинна організувати всі валідаційні операції й виконувати оцінку отриманих результатів. Рекомендується прийняти головні правила по роботі валідаційної комісії й оформити їх у формі СОП [1].

2.8.2 Валідаційні протоколи.

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

Протокол валідації містить:

- Опис операції;

- Опис експерименту;

- Одиниці устаткування/технічних засобів, які будуть використані (включаючи вимірювальне й устаткування, що реєструє), із вказівкою статусу калібрування;

- Величини, що підлягають контролю;

- Критерії прийнятності;

- Подробиці методів проведення валідації й оцінки результатів;

- Інші рекомендації [1].

2.8.3 Валідаційний звіт.

Звіт по валідації – це документ, у якому зібрані всі дані, результати й оцінка всієї валідаційної програми. Він може містити й пропозиції по удосконаленню устаткування або/і процесів (виробничих і не тільки).

Звіт по валідації містить:

- опис процесу валідації АС із вказівкою критичних етапів;

- опис проведених випробувань;

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

- огляд і порівняння отриманих результатів з тими, що очікувалися;

- висновки; необхідність додаткової валідації;

- відхилення; (причини й заходи);

- підпис під час валідації (підпис того, хто проводив експерименти й той, хто особисто був присутній і підтверджує отримані результати, краще якщо цією людиною, буде представник виробника);

- затвердження звіту [1].


РОЗДІЛ 3

РОЗРОБКА ВАЛІДАЦІЙНОГО МАЙСТЕР ПЛАНУ

Усе вище наведене буде використане при розробці Валідаційного Майстер Плану для проведення валідації АС блістерного автомата Marchesini MB421.

Перед валідацією даної АС ми не будемо проводити аналіз ризиків, тому що валідації будуть підлягати всі функції АС.

Софтвер і хардвер блістерного автомата Marchesini MB421 відноситься до 3 категорії, тому що софтвер являється стандартним пакетом програм відповідно і хардвер буде стандартним.

3.1 Предмет валідації

Предмет валідації – первинна кваліфікація автоматизованої системи блістерного автомата Marchesini MB421.

Серійний номер технологічного обладнання – 400000ХХХ.

Виробник технологічного обладнання – Marchesini Group (Italy).

Автоматизована система – Harlequin.

Виробник автоматизованої системи – Sea Vision S.r.l. (Italy).

Місце розміщення обладнання – Дільниця виробництва таблеточних форм. Чисте приміщення №6, клас чистоти – D.

Документи, які будуть використовуватися при проведенні валідаціних робіт:

• Руководство 42-01-2001. Лекарственные средства. Надлежащая производственная практика. Киев, Министерство здравоохранения Украины, 2001.

• EU GMP (Guide to Good Manufacturing Practice for Medicinal Products, 1992).

• Надлежащая производственная практика лекарственных средств, 1999, Киев, Морион.

• Pharmaceutical Process Validation, Second Edition, Revised and Expanded, edited by Ira R. Berry, Robert A. Nash.

• ISPE. Pharmaceutical Engineering Guide, Volume 2, Oral Solid Dosage Forms – 1998.

• FDA. General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 2002.

• 21 CFR Part 11. Electronic Records; Electronic Signatures; Final Rule, March 1997.

• GAMP 4. Good automated manufacturing practice pharmaceutical industry supplier guide for validation of automated systems in pharmaceutical manufacture.

Перераховані вище документи є також керівництвами, у відповідності, з якими буде проводитися тестування.

3.2 Склад валідаційної комісії:

п/п

П.І.Б. члена валідаційної комісії

Посада

1

 

 

2

 

 

3

 

 

3.3 Склад робочої групи:

п/п

П.І.Б. члена робочої групи

Посада

1

 

 

2

 

 

3

 

 

Сертифікати, які підтверджують кваліфікацію членів робочої групи представлені в Додатку.

3.4 Опис обладнання.

3.4.1 Призначення.

Блістерный автомат Marchesini MB421 призначений для упакування таблеток в однобічні контурні упаковки (блістери). Продуктивність автомата – 40...200 блістерів/хвилину.

3.4.2 Опис конструкції.

Загальний вид блістерного автомата Marchesini MB421 представлений у Додатку.

До складу автомата входять наступні основні вузли:

• Електрична шафа,

• Вузол термосклеювання,

• Вузол формування,

• Вузол нанесення коду (тиснення),

• Вузол вирубки,

• Вузол розміщення бобіни фольги,

• Вузол розміщення бобіни плівки ПВХ,

• Терморегулятори термосклеювання та формування,

• Бункер зберігання таблеток,

• Вузол подачі таблеток,

• Ємність відбракованої продукції,

• Вихідний конвеєр блістерів,

• Охолоджувач,

• Пилосос видалення пилу з таблеток,

• Пилосос видалення обрізків фольги,

• Інтерфейс оператора,

• Відеокамера,

3.4.3 Принцип роботи.

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

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

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

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

3.4.4 Керування роботою автомата.

Керування роботою автомата відбувається з інтерфейсу оператора.

На інтерфейсі оператора розміщені:

• Технологічна панель керування, що включає:

- ключ програмування;

- клавіші керування;

- роз’єм для кнопкової панелі програмування;

- дисплей для візуалізації даних.

• Дисплей автоматизованої системи Harlequin.

• Вказуючий пристрій типу «миша».

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

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

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

Інтерфейсний роз’єм на панелі програмування використовується для з'єднання з персональним комп'ютером на етапі налагодження автомата, а також для програмування й внесення в автомат проектних даних.

Призначення дисплея автоматизованої системи Harlequin полягає у візуалізації контрольних технологічних параметрів роботи, аварійних повідомлень, керуванні

3.5 Оформлення результатів тестування

У даному розділі необхідно дати вказівки по оформленню результатів тестування, в залежності від того яка форма оформлення результатів тестування буде обрана.

3.6 Технічне завдання користувача / User Requirements Specification

3.6.1 Ключові завдання системи.

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

3.6.2 Розміщення системи.

Блістерный автомат розміщений в чистому приміщенні класу чистоти D.

Параметри повітряного середовища приміщення: температура повітря – 18...23оС; відносна вологість – 40...60%

Сторонні фактори не будуть здійснювати якого-небудь впливу на автомат.

3.6.3 Необхідні функції системи:

• Керування роботою устаткування в автоматичному режимі й ручному режимі.

• Відображення на екрані дисплея всіх технологічних параметрів й їхньої зміни в часі.

• Зручність користування.

• Постійний контроль технологічного процесу.

• Постійний контроль функціонування установки.

• Можливість втручання й внесення коректив у хід автоматичного процесу.

• Збереження даних.

• Статистичний аналіз даних.

• Занесення даних в пам’ять автомата.

• Роздруківка даних.

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

• Обмеження доступу роботи із системою.

• Постійне контрольне відстеження некондиційних блістерів за допомогою камери, яка не потребує ручного регулювання.

• Автоматичне відбракування всіх некондиційних блістерів.

• Можливість роботи з будь-якою основою (алюміній, непрозора ПВХ, прозора ПВХ, поліпропіленом і т.д.) при тій же системі освітлення.

• Можливість виміру наступних параметрів для кожного об'єкта:

- зони об'єкта в чарунці;

- параметрів, що описують форму;

- довжини;

- кута;

- колірного рівня й розсіювання колірних рівнів;

- колірного відтінку, насичення.

• Регулювання процесу контролю некондиційних блістерів на підставі заданих робочих параметрів.

3.6.4 Експлуатаційні вимоги до системи:

• Автоматизація процесу контролю некондиційних блістерів.

• Автоматизація процесу відбракування некондиційних блістерів.

• Автоматичне регулювання процесу на підставі заданих робочих параметрів. Підтримка технологічних параметрів у заданих межах.

• Автоматичне регулювання при зміні світлових умов роботи.

• Відображення робочих параметрів контролю.

• Постійне відстеження технологічних параметрів.

• Можливість графічного відображення зміни технологічних параметрів контролю протягом процесу.

• Відображення технологічних параметрів контролю роботи автомата різними кльорами (наприклад, зелений – нормальна робота, червоний – значення параметра за припустимими межами).

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

• Можливість оператора в будь-який час вмішатися в хід автоматичного процесу й внести корективи у виконувану програму.

• Можливість складання нових технологічних програм роботи.

• Можливість коректування вже наявних технологічних програм роботи.

• Можливість статистичного аналізу даних.

• Можливість збереження технологічних програм роботи на жорсткому диску й на магнітному носії.

• Можливість виводу переліку всіх збережених даних.

• Можливість роздруківки робочих параметрів процесу (з магнітного носія).

• Можливість роздруківки статистичних даних (з магнітного носія).

• Можливість поновлення роботи в нормальному режимі у випадку аварійного відключення електричного живлення.

• Обмеження доступу до роботи із системою: система рівневих паролів, неможливість несанкціонованого введення даних, неможливість несанкціонованого внесення змін у програмне забезпечення.

• Можливість зміни файлу конфігурації системи.

• Можливість вибору мови інтерфейсу.

• Можливість з'єднання з розробником системи (виробником устаткування) по мережі INTERNET.

• Зміни в систему або в комп'ютеризовану програму повинні вноситися тільки відповідно до встановленої методики. Такі зміни необхідно протоколювати й затверджувати. Після здійснення модифікації необхідне повторне тестування системи або програми.

3.7 Функціональний опис системи / Functional Specification

Автоматизована система Harlequin контролює упаковані продукти на блістерній машині.

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

 

 

Ковбасюк - Валідація
 


Ковбасюк - ВалідаціяКовбасюк - Валідація

Ковбасюк - ВалідаціяКовбасюк - Валідація                                                              КАРТА ЗОБРАЖЕННЯ            МОНИТОР

Ковбасюк - ВалідаціяКовбасюк - Валідація                         ТВ                                         ПРОЦЕСА

Ковбасюк - Валідація
 


Ковбасюк - Валідація

Ковбасюк - ВалідаціяКовбасюк - Валідація                                               ПРОГРАМНЕ

                                               ЗАБЕЗПЕЧЕННЯ

Ковбасюк - ВалідаціяКовбасюк - ВалідаціяКовбасюк - Валідація

Ковбасюк - ВалідаціяСИСТЕМА ОСВІТЛЕННЯ                                                         КОМП’ЮТЕР

 

Ковбасюк - Валідація Ковбасюк - Валідація
 

 


Ковбасюк - Валідація

Ковбасюк - ВалідаціяКовбасюк - ВалідаціяКовбасюк - ВалідаціяБЛІСТЕРНА

Ковбасюк - ВалідаціяКовбасюк - ВалідаціяМАШИНА                                      PLC               I/O КАРТА                   МИША

 

 

Рис. 11. Схема основних модулів операційної системи машини

 

Автоматизована система Harlequin містить наступні модулі:

• комп'ютер;

• камеру й лінзи;

• систему освітлення;

• карту захвата зображення;

• монітор;

• електричні з'єднання;

• миша (або будь-який інший вказуючий пристрій);

• програмне забезпечення.

3.7.1 Принцип роботи.

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

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

У доповненні до чарунок, контролюється стрічка ПВХ і якщо система Harlequin виявляє дефект, принаймні, в одній контрольованій зоні, то всі блістери, виявлені з відповідним дефектом стрічки, відбраковуються.

Ланцюжок проходження зображення є концепцією, яка допомагає в розумінні того, як працює система контролю. Ланцюжок зроблений за допомогою послідовності операцій, остання з яких містить на виході подвійний результат: гарний блістер або бракований блістер.

3.7.2 Характеристики Harlequin.

• Програма розроблена в оболонці WINDOWS для полегшення програмування, безпосереднього виконання системи й інтуїтивності користування. Для цього Harlequin був спроектований так, щоб користувач використовував безпосередньо монітор і мишу (направляючу кулю).

• Для камери не потребується ручне регулювання, вона встановлена в герметично захищеному корпусі й контролюється безпосередньо програмним забезпеченням.

• Harlequin може працювати з будь-якою основою (алюміній, непрозорий ПВХ, прозорий ПВХ, поліпропілен і т.д.) з однаковою системою освітлення.

• Harlequin може перевіряти різні продукти в одному блістері (багатопродуктовий блістер).

• Harlequin може вимірювати наступні значення кожного об'єкта:

- зону об'єкта в чарунці;

- параметри, які описують форму (округлість, подовження, симетричність);

- довжину;

- кут;

- колірний рівень і дисперсію колірних рівнів для кожного із трьох базових кольорів (червоний, зелений, синій);

- колірний відтінок, насичення й величину; для двоколірних об'єктів ці параметри розраховуються окремо для кожного із кольорів.

• Повнота вимірів гарантує визначення дефектів, які звичайно не можуть бути визначені системами, основаними на вимірі області об'єкта. Зокрема, параметри, що описують форму, які є чутливими до асиметрії, гарантують те що визначаться маленькі відколи й дефекти.

• Harlequin також визначає:

- подвійний продукт в алюмінієвому осередку;

- маленькі фрагменти біля продукту;

- порожні чарунки: повністю порожні блістери можуть бути викинуті в контейнер, відмінний від контейнера з дефектними блістерами.

• Harlequin здатний розрізнити дефекти відповідно до їх ступеня небезпеки й діючих процедур безпеки, якщо визначені критичні дефекти.

• Harlequin обладнаний функціями контролю для визначення стиків стрічки, відсутності продуктів в чарунках, крапок.

• Harlequin здійснює автоматичне відбракування/виштовхування неповних або повністю порожніх блістерів.

• Harlequin здійснює автоматичне відділення, що відноситься до блістерів, на яких існує з'єднання (місце склейки) з оброблюваною плівкою.

• Автоматизована система Harlequin передбачає автоматичну зупинку у випадку:

- Недостатнього тиску повітря.

- Закінчення оброблюваної плівки.

- Перевантаження двигуна.

- Високої температури охолоджувальної рідини.

- Виходу значення температури однієї з нагрівальних станцій із заданого діапазону

- Наявності сторонніх предметів на формувальній плівці.

- Виявлення послідовності некондиційних блістерів.

- Самоконтролю, викликана неправильними фазами, датчиками (сенсорами), фотоелементами.

- Відсутності охолодження рециркулюючою рідиною.

- Неправильного розміщення петлі плівки.

- Пропущених і не вилучених неправильних блістерів.

• Harlequin може перевіряти різні продукти, розміщені в той же самий час у том ж самому блістері.

• Harlequin автоматично адаптується до змін світлового потоку в робочих умовах.

• Harlequin має пристрій безпеки, що контролює вихідні сигнали.

• Harlequin забезпечується інструментом самопрограмування для робочих виробів, що дозволяє некваліфікованому користувачеві створити нову робочу програму.

• Harlequin управляє випуском готової серії й представляє детальний звіт для кожної серії.

• Harlequin може управляти допоміжними сигналами, викликаними зовнішніми подіями.

• Harlequin може управляти регістрами змін для роботи зовнішніх пристроїв.

• Harlequin може застосовувати свій екран для показу повідомлень зовнішніх пристроїв.

• Harlequin має програмне забезпечення, необхідне для здійснення керування робочими функціями PLC.

• Harlequin може приймати дистанційні команди через СОМ (серійний) порт.

• Harlequin може бути підключений прямо до виробника устаткування через Інтернет або за допомогою прямого модемного з'єднання.

• Harlequin напряму програмує з'єднаний з ним пристрій штрих-коду.

• Harlequin відповідає вимогам правил FDA 21 CFR розділ 11:

- допуск в Harlequin регулюється системою ідентифікації;

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

• Harlequin записує всі версії параметрів робочої програми.

3.7.3 Логічне керування.

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

Хід машинних процесів:

 


 

 

 

Ковбасюк - Валідація
 

 

 

 

 

 

 

 

 

 

 

 

 

 


Рис. 12. Схема ходу машинних процесів


 

Хід контролю апаратних засобів:

Ковбасюк - Валідація
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Рис. 13. Схема ходу контролю апаратних засобів

3.7.4 Інтерфейс користувача.

Користувач використовує спеціально організоване меню команд з допомогою яких він може управляти всіма функціями машини.

Для взаємодії з програмою користувач використовує вказуючий пристрій типу миша. Такий пристрій використовується для переміщення курсора, показаного на экрані в виді стрілки.

Так як традиційна клавіатура відсутня, то при необхідності введення літер або цифр використовується екранна клавіатура, яка відображає функції реальної клавіатури.

 

3.8 Технічний опис системи / Design Specifications

 

Параметр

Значення параметра

Назва обладнання

Блістерний автомат

Марка обладнання

Marchesini МВ421

Виробник

Marchesini Group (Italy)

Заводський/серійний номер

400000ХХХ

Інвентарний номер обладнання

ХХХ

Місце знаходження обладнання

Дільниця виробництва таблеточних форм.

Чисте приміщення №6.

Клас чистоти – D.

Рік випуску обладнання

2006

Дата введення в експлуатацію

03.2007

Операційна система (ОС)

Microsoft Windows

Версія ОС

2000  5.02295 Service Pack 2

Рік випуску ОС

2000

Мова ОС

Англійська

Загрузочна система (BIOS)

Award Modular

Виробник

Award Software Inc.

Версія

6.00 PG

Рік випуску

2000

Мова системи

Англійська

Операційна базова програма

Harlequin

Версія

V01.00.000 (originale)

Рік випуску

02.10.2001

Мовний модуль програми

Російський

Промромисловий комп’ютер

Sea Vision 1 TV Mono

Виробник

Sea Vision

Тип

Blister Vision Harlequin

Серійний номер

BVHQ1M0090590105

Рік випуску

2001

Тип процесора (CPU)

AMD Duron

Робоча частота

800 MHz

L2 Cache

64 Kb

Об’єм оперативної пам’яті (RAM)

256 Mb

Жорсткий диск (HDD)

Об’єм жорсткого диску (HDD)

Тип

Maxtor

20 Gb, ATA 100

2B020H1 WAH21PBO

Дисковод для гнучких дисків

1.44 Mb

Відеокарта

Тип чіпа

Тип DAC

Відеопам’ять

ATI Technologic Inc.

Rage XL AGP 2x

ATI Internal DAC

8 Mb RAM

Монітор

Тип

Область екрана

Кількість кольорів

Частота

VGA Monitor 15”

SVGA

Min 640 x 480 pixels; Max 1600 х 1200 pixels

Min 256 Color; Max True Type Color (32 bit)

Min 47 Hz; Max 200 Hz

Миша

HID-compliant mouse

Модем

Виробник

Win Modem PCI V90 L

Digicom S.p.A.

Карта відеозахвата

Виробник

Meteor_II PCI grabber

Matrox Electronic System Ltd.-Imaging

Програма PLC

510232s3

Програмуємий логічний контроллер

SIEMENS S7

Тип монтажу

Горизонтальный

ОЗУ для програм і даних

48 KByte / близько 16 K команд (1 команда = 3 Byte)

Час виконання 1K подвійних команд

0.3 ms

Маркери

2235

Лічильник

64

Таймер

128

Цифрові входи / виходи, максимум / встроєні

1024/0

Аналогові входи / виходи, максимум

128

Інтерфейс

MPI

Годинник реального часу

Встроєний

Профіль шин

6RN3 280-2EE30-1BN1

Тип процесора

CPU 315

Тип ПЛК

СP680

Модель ПЛК

150-3SD01-2VB1

Версія

4.0

Рік випуску

12-05-2002

Інтегрований інтерфейс

RS232C

Тип

Інтерфейс напруги

Сигнали RS 232C

TXD, RXD, RTS, CTS, DTR, DSR, RI, DCD,

GND

Максимальна швидкість передачі даних

19.2 Kbaud (3964 (R) procedure)

9.6 Kbaud (ASCII driver, printer driver)

Максимальна довжина кабеля

15 метрів

Стандарти

DIN 66020, DIN 66259, EIA-RS 232C, CCITT V.24/V.28

Ступінь захисту

IP 00

Коментарії:

Дата проведення ідентифікації

 

П.І.Б., посада контролера

 

 

3.9 Кваліфікація інсталяції (IQ)

Призначеня кваліфікації – перевірка відповідності системи технічному опису системи / Design Specifications; перевірка відповідності системи загальним вимогам нормативної документації до автоматизованих систем для фармацевтичного обладнання; перевірка правильності інсталляції системи; перевірка відповідності встановленним специфікаціям і вимогам виробника; ідентифікація всіх елементів системи; перевірка наявності необхідної документації.

3.9.1 Перелік тестів, які будуть проведені.

В цьому розділі приводиться перелік всіх тестів, які будуть проводитись в рамках IQ.

3.9.2 Протоколи (IQ).

Приклад оформлення валідаційного протоколу (IQ):


ВАЛІДАЦІЙНИЙ ПРОТОКОЛ №1

Контролюючий параметр

Склад системи

Машина обладнана пультом керування

q ТАК

q НІ

Монітор VGA Industrial Monitor IBM 15”

q ТАК

q НІ

Центральний процесор Duron 800 MHz

q ТАК

q НІ

Маніпулятор типу «миша»

q ТАК

q НІ

Коментарії:

Виконав:

 

Підпис:

 

Дата:

 

Преревірив:

 

Підпис:

 

Дата:

 

 

3.10 Кваліфікація функціонування (OQ) та експлуаційних якостей (PQ)

Призначеня кваліфікації – підтверждення здатності системи працювати у відповідності з FS (Functional Specification) / функціональним описом системи та виконувати задані процеси у відповідності з затверженим URS (User Requirements Specification) / технічним завданням користувача.

3.10.1 Перелік тестів, які будуть проведені.

В цьому розділі приводиться перелік всіх тестів, які будуть проводитись в рамках ОQ / PQ.

3.10.2 Протоколи (ОQ / PQ).

Приклад оформлення валідаційного протоколу (ОQ / PQ):


 


ВАЛІДАЦІЙНИЙ ПРОТОКОЛ №1

Контролюючий параметр

Режим запуску

Робоча методика

Включити электроживлення.

Критерій прийнятності

Подається живлення на блістерний автомат. Напротязі 1-2 хв. іде загрузка рабочої програми. На дисплеї – вікно рабочої програми.

Коментарії:

Результати тестування відповідають критеріям прийнятності

ТАК / НІ

Виконав:

 

Підпис:

 

Дата:

 

Преревірив:

 

Підпис:

 

Дата:

 

 


ВИСНОВКИ

Результатом виконання даної магістерської роботи є розробка основних процедур валідації комп’ютеризованої системи блістерного автомату, та пов'язаних з цим процесів. А також розгляд основних видів документації, яка повинна бути надана продавцем обладнання або розроблена на підприємстві при проведенні валідації, як підготовча процедура для сертифікації виробництва на виконання вимог належної виробничої практики.

У результаті ознайомлення з існуючою нормативною документацією та доступною рекомендаційною літературою мною були вивчені закономірності й правила проведення валідації комп’ютеризованих систем.

У практичній частині даної роботи був розроблений валідаційний майстер план проведення валідації комп’ютеризованої системи блістерного автомата Marchesini MB421.

У валідаційному майстер плані були розроблені наступні валідаційні документи, необхідні для якісного проведення валідації АС у відповідності з керівництвом GAMP:

1. Був визначений об’єм проведення валідації АС.

2. Приведені документи, які будуть використовуватися при проведенні валідаціних робіт.

3. Представлений детальний опис роботи обладнання.

4. Розроблене технічне завдання користувача (User Requirements Specification), в якому наведені:

- Ключові завдання системи;

- Розміщення системи;

- Необхідні функції системи;

- Експлуатаційні вимоги до системи.

5. Складений функціональній опис системи (Functional Specification), де описані:

- Основні модулі операційної системи автомата;

- Принцип роботи модулів;

- Характеристики програмного забезпечення Harlequin;

- Логічне керування (PLC) автомата;

- Інтерфейс користувача.

6. Складений детальний технічний опис системи (Design Specifications).

7. Сформульоване призначеня кваліфікації інсталяції (IQ) та розроблений приклад оформлення валідаційного протоколу IQ.

8. Сформульоване призначеня кваліфікації функціонування (OQ), експлуаційних якостей (PQ) та розроблений приклад оформлення валідаційного протоколу ОQ / PQ.


СПИСОК ВИКОРИСТАНОЇ ЛІтературИ

1.

Аладышева Ж.И., Береговых В.В., Мешковский А.П., Левин Л.М. Основные принципы проведения валидации на фармацевтическом производстве, М., 2005г., 186 стр.

2.

Ассоциация Парентеральных Лекарственных Препаратов. «Валидация систем, связанных с компьютером: технический отчет № 18». Журнал Фармацевтической Технологии. Том 49 (S1).

3.

Ассоциация Фармацевтических Производителей. «Концепции валидации компьютерных систем, используемых в производстве лекарственных продуктов». Фармацевтическая технология. Том 10 (5), 1987, 24-34 стр.

4.

Береговых В.В., Иващенко Н.В., Рудакова И.П., Пятигорская Н.В., Мешковкий А.П., Ляпунов Н.А. Управление качеством в фармацевтической промышленности, М.,2004 г., 400 стр.

5.

Институт Комитета Стандартов Технологии Валидации. Предлагаемый стандарт валидации VS-2 «Валидация систем, связанных с компьютерами». Журнал технологии валидации. Том 7, № 3. Май 2001.  190-210 стр.

6.

Курс лекций на тему: Руководство GAMP 4. Mika Parkka, Lic.Sc (Tech.); Validation Manager, STERIS Fin-Aqua.

7.

Курс UAS004-XLL-A-SK01 Лекции на тему: «Валидация компьютерныхсистем», GMProject, 31.1. -1.2.2006 г, Вильнюс, Литва.

8.

Ляпунов Н.А., Загорий В.А., Георгиевский В.П., Безуглая Е.П. Надлежащая производственная практика лекарственных средств.– К.: Морион, 1999.

9.

Материалы Конференции ISPE «GAMP 4 – Принципы и Применение» 2023 сентября 2004 г.

10.

Международное Общество Фармацевтической Инженерии. «Руководство GAMP по валидации автоматизированных систем в фармацевтическом производстве: версия 3.0». Тома 1-2. Март 1998.

11.

Наказ МОЗ України № 391 від 30.10.2002 р. «Про затвердження порядку проведення сертифікації виробництва лікарських засобів, та зміни до нього.

12.

Рекомендации профессионалов. Квалификация и валидация в свете требований GMP // Аптека online. - 28 апреля 2008. - № 17 (638).

13.

Руководство 42-01-2001. Лекарственные средства. Надлежащая производственная практика. Киев, Министерство здравоохранения Украины, 2001.

14.

Руководство 42-01-2001. Лекарственные средства. Приложение J. КОМПЬЮТЕРИЗИРОВАННЫЕ СИСТЕМЫ.

15.

Руководство 42-01-2003. Лекарственные средства. Технологический процесс. Документация.

16.

Сорокина Е.М., менеджер по качеству МПБП «ФГУП НПО «Микроген» МЗ РФ. Валидация компьютерных систем. Жизненный цикл. «Технология чистоты», 1/2005, 25-30 стр.

17.

Усенко В.А., Спасокукоцкий А.Л. Лицензирование в Европейском Союзе: фармацевтический сектор.-К.:МОРИОН Лтд, 1998.

18.

Форум GAMP. «GAMP Руководство поставщика: версия 2.0». Май 1996.

19.

EU GMP – Guide to Cood Manufacturing Practice for Medicinal Products (1992).

20.

FDA. «Руководство для отрасли – общие принципы валидации программного обеспечения». Проект Руководства версия 11. 9 июня 1997.

21.

FDA. General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 2002.

22.

ISPE. Pharmaceutical Engineering Guide, Volume 2, Oral Solid Dosage Forms – 1998.

23.

PDA Technical Report 18 (Валидация компьютеризированных систем в фармацевтической промышленности).

24.

Pharmaceutical Process Validation, Second Edition, Revised and Expanded, edited by Ira R. Berry, Robert A.Nash.

25.

Good Automated Manufacturing Practice. Надлежащая практика автоматизированного производства.

Руководство для поставщиков фармацевтической промышленности по валидации автоматизированных систем для фармацевтической промышленности.

26.

WHO Technical Report Series №863. 1996.

27.

21 CFR Part 11. Electronic Records; Electronic Signatures; Final Rule, March 1997.

28.

http://www.iso.staratel.com/GMP/Validation/CSV/index.html (Валидация компьютерной системы (Computer Systems and Software Validation)).

 

 

Наверх страницы

Внимание! Не забудьте ознакомиться с остальными документами данного пользователя!

Соседние файлы в текущем каталоге:

    На сайте уже 21970 файлов общим размером 9.9 ГБ.

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

    Не нашли нужный документ? Воспользуйтесь поиском по содержимому всех файлов сайта:



    Каждый день, проснувшись по утру, заходи на obmendoc.ru

    Товарищ, не ленись - делись файлами и новому учись!

    Яндекс.Метрика