Seminar IT Комп Системи

Семинар
Семинар
Валидация компьютеризированных систем
Лекторы: Мирошниченко Станислав, Трунов Ян

E-mail: info@it-validator.com
Осень 2016
Стр.1
Определения
Компьютерная система — аппаратные компьютерные компоненты в сочетании с
набором программного обеспечения, которые вместе предназначены для
выполнения определенной функции или группы функций.
Компьютеризированная система — компьютерная система, плюс контролируемая
функция, которую она выполняет. Включает в себя оборудование, программное
обеспечение, периферийные устройства, персонал и документацию, например,
руководства и стандартные операционные процедуры (СОП).
Стр.2
Программное обеспечение Операционные процедуры и персонал
Аппаратное обеспечение Оборудование
Прошивка контроллеров
Компьютерная система Контролируемая функция или бизнес-процесс
Компьютеризированная система
Окружение (включает другие компьютерные сети, отдельные самостоятельные компьютеризированные

системы, медиа-контент, персонал, оборудование и др.)
Стр.3
Валидация — создание документального основания, обеспечивающего высокий
уровень уверенности, что каждый конкретный процесс будет постоянно приводить к
производству продукта, отвечающего заранее определенной спецификации и
показателям качества
Программное обеспечение (ПО) — это программа установленная на определенную
платформу/компьютерное оборудование, выполняющие определенные функции.
Владелец системы — лицо, ответственное за работоспособность и обслуживание
компьютеризированной системы и безопасность данных, находящихся в этой системе
Тест-кейс — это операция, описывающая совокупность шагов, конкретных условий и
параметров, необходимых для проверки реализации тестируемой функции или ее
части. Под тест-кейсом понимается структура вида: Действие → Ожидаемый
результат → Результат теста
СОП (стандартная операционная процедура) — это подробная письменная
инструкция, касающаяся стандартных действий и/или операций, выполняемых на
предприятии, и составленная по унифицированной форме.
Стр.4
Спецификация — набор требований и параметров, которым удовлетворяет
некоторый технический объект (wiki).
Квалификация — стадия валидации, основанная на какой-либо методике.
Стр.5
Нормативные документы
Нормативные документы
1. Лікарські засоби. Належна виробнича практика. СТ-Н МОЗУ 42-4.0:2015
2. Лікарські засоби. Належна практика дистрибуції. СТ-Н МОЗУ 42-5.0:2014
3. 21 CFR PART 11 ELECTRONIC RECORDS; ELECTRONIC SIGNATURES
4. The Rules Governing Medicinal Products in the European Union Volume 4 Good
Manufacturing Practice Medicinal Products for Human and Veterinary Use Annex 11:
Computerized Systems
5. General Principles of Software Validation; Final Guidance for Industry and FDA Staf
6. ISPE GAMP 5
7. Стандарт ISO/IEC 17025
8. "Efective and Practical Risk Management Options for Computerised System
Validation" R.D.McDowall, McDowall Consulting, 73 Murray Avenue, Bromley, Kent, BR1
3DJ, UK
Стр.6
Виды компьютеризированных систем
Виды компьютеризированных систем
WMS — warehouse managment system, система управления складом

BMS — система управления зданием
ERP — система управления предприятием
SCADA — программный пакет, предназначенный для разработки или обеспечения
работы в реальном времени систем сбора, обработки, отображения и архивирования
информации об объекте мониторинга или управления.
LIMS (сокр. от англ.Laboratory Information Management System) — система управления
лабораторной информацией
MES (от англ. Manufacturing Execution System) — система управления
производственными процессами
Стр.7
Архитектура компьютеризированных систем
Однозвенная технология (файловый доступ)
Клиент Данные
Стр.8
Двухзвенная технология
Стр.9
Достоинства и недостатки двухзвенной технологии
Достоинства
― Простота установки и настройки
― Умеренные требования к системным ресурсам сервера
Недостатки
― Трудности поддержки актуальной версии клиента
― Бизнес-логика почти полностью находится на клиенте
― Повышенные требования к пропускной способности сети
― В случае плохой архитектуры системы существуют проблемы с безопасностью
Стр.10
Трехзвенная технология (тонкие и обычные клиенты)
Стр.11
Достоинства и недостатки трехзвенной технологии

― Гибкое и расширяемое решение
― Возможность одновременного подключения дополнительных серверов СУБД
― Равномерное распределение нагрузки на инфраструктуру
― Улучшенное управление безопасностью системы
― Бизнес-логика сосредоточена на сервере
― Требует высокой квалификации отдела поддержки
― Сложности при установке и запуске
― Повышенные требования к аппаратному обеспечению
Стр.12
Примеры компьютеризированных систем
Управляющие WMS
Сервер БД Oracle (или MS SQL Сервер), клиентские приложения — различные
отдельные модули с распределенным функционалом.
― Наличие складских заданий для работников склада (перемещение, отбор
продукции, размещенение т.д)
― Наличие складских ячеек
― Различные статусы каждого документа в зависимости от текущей стадии
процесса
― Система сама рассчитывает размещение продукции исходя из исходных данных
Стр.13
Регистрирующие системы для дистрибуции

1С:Предприятие в базовой поставке
― Может работать по 1,2,3 -х звенной технологии.
― Склад может быть разбит на ячейки, но нет заданий для складских работников
― Документы практически не имеют статус обработки
SCADA системы
В основном построены на базе контроллеров Siemens. Клиентские приложения
разрабатываются в спец. cреде от производителя.
Для настройки и взаимодействия с оборудованием используют OPC сервер.
Стр.14
Управляющие производственные системы

На производственной линии устанавливается панель оператора, которая сама или с
помощью удаленного контроллера управляет процессом производства по заданным
рецептам.
Отдельно устанавливается компьютер для хранения данных о произведенных
сериях, настройки рецептов.
Регистрирующие производственные системы

Система построена по принципу: производственная линия отдельно, отдел
планирования и управления отдельно.
Предназначены для закрытых производственных процессов.
Стр.15
Применение виртуализации
Стр.16
Системы виртуализации
Hyper-V — аппаратная виртуализация от Microsoft. Существует как отдельный продукт

(операционная система Microsoft Hyper-V Server, так и в виде роли для семейства ОС
Windows Server). Стоит денег
KVM — аппаратная виртуализация для Linux. Имеет различные интерфейсы
управления гостевыми ОС (Proxmox, Virt-Manager, Cli console). Свободное ПО
Vmware ESX — высокопроизводительная система виртуализации для DOS, Windows,
Linux, FreeBSD, Netware, Solaris, Virtual Appliances. Существуют бесплатные и платные
версии.
Стр.17
Руководство GAMP
ISPE GAMP 5 — A Risk-Based Approach to Compliant GxP Computerized Systems
GAMP позволяет :
 помочь поставщикам автоматизированных систем для фармацевтической
промышленности следовать надлежащей практике и обеспечивать
соответствующее документальное сопровождение систем в соответствии с
согласованными спецификациями.
 дать возможность компаниям соответствовать требованиям GMP/GDP.
GAMP основывается на регуляторных (нормативных) документах: GMP, GCP,
GLP, GDP, Good Quality Practice (GQP), Good Pharmacovigilance Practice,
нормативные акты для медицинских устройств.
Стр.18
Системы, для которых предназначен GAMP

― Управление данными клинических исследований;
― Планирование производственных ресурсов;
― Управление лабораторной информацией;
― Процессный контроль и процессный анализ;
― Производственный процесс;
― Склад и дистрибьюция;
― Системы обработки крови;
― Управление аварийными ситуациями;
― Документооборот
Стр.19
Структура GAMP
Структура GAMP
Введение
Жизненный цикл ПО
Фазы жизненного цикла
Управление рисками
Взаимодействие с регуляторными актами
Взаимодействие с поставщиками
Повышение эффективности
Приложения М — Процесс управления (Managment)
Приложения D — Процесс разработки (Development)
Приложения O — Процесс функционирования (Operation)
Приложения S — Специализированные процессы (Special)
Приложения G — Приложения к самому руководству GAMP
Стр.20
Жизненный цикл по GAMP
Основной процесс жизненного цикла
Знания о продукте Спецификация и

Требования Верификация
дизайн
Знания о бизнес-
процессе
Нормативные Эксплуатация и
Согласование и
требования дальнейшая
запуск
модернизация
Стандарты
компании
Управление рисками
Дизайн
Управление изменениями
Стр.21
Этапы жизненного цикла для компьютеризированных систем

― Концепт (желание автоматизировать бизнес-процессы — первичные требования
к системе и наброски бизнес процессов. Обязательно выяснить возможные
затраты на реализацию и полученную выгоду);
― Проект (планирование общее, выбор поставщика, разработка спецификаций,
приемочная проверка);
― Функционирование (доступ к системе обученного персонала, контроль
функционирования (включая аспекты безопасности), снижение рисковых
ситуаций)
― «Отправка на пенсию» (консервирование или удаление данных, миграция
данных в иные области)
Стр.22
Фазы жизненного цикла
Планирование Отчетность
Спецификация Верификация
Конфигурирование
и/или кодирование
Стр.23
Распределение фаз жизненного цикла по этапам
Стр.24
Этапы фазы функционирования
― передача системы от разработчика группе поддержки

― управление производительностью системы
― управление инцидентами
― управление изменениями
― периодический аудит системы
― управление процессом бесперебойной работы
― безопасность и администрирование системы
― record managment (управление документами организации с момента их создания
до окончательного уничтожения)
Стр.25
Другие модели жизненного цикла

Каскадная модель или «Водопад» (Waterfall)
Стр.26
Подразумевает последовательное прохождение стадий, каждая из которых должна
завершиться полностью до начала следующей.
В модели Waterfall легко управлять проектом
Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее
определены
Модель будет давать отличный результат только в проектах с четко и заранее
определенными требованиями и способами их реализации
Нет возможности сделать шаг назад, тестирование начинается только после того, как
разработка завершена или почти завершена
Стр.27
Инкрементальная модель (и разновидность «Спиральная модель»)
Стр.28
В инкрементной модели полные требования к системе делятся на различные сборки.
Терминология часто используется для описания поэтапной сборки ПО.
Имеют место несколько циклов разработки, и вместе они составляют жизненный
цикл «мульти-водопад».
Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль
проходит через фазы определения требований, проектирования, кодирования,
внедрения и тестирования. Процедура разработки по инкрементной модели
предполагает выпуск на первом большом этапе продукта в базовой
функциональности, а затем уже последовательное добавление новых функций, так
называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана
полная система.
Стр.29
«RAD Model» (быстрая разработка приложений)
Стр.30
RAD-модель — разновидность инкрементной модели.
В RAD-модели компоненты или функции разрабатываются несколькими
высококвалифицированными командами параллельно, будто несколько мини-
проектов.
Временные рамки одного цикла жестко ограничены.
Созданные модули затем интегрируются в один рабочий прототип.
Сотрудничество команд позволяет очень быстро предоставить клиенту для
обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Стр.31
GAMP 5. Классификация ПО
GAMP. Категория 1 — ПО высокого уровня (инфраструктурное ПО)
Средства конфигурируемого управления ПО высокого уровня не является предметом
валидации, однако его функциональность проверяется косвенно при тестировании
приложения.
Необходимо задокументировать версию ПО и операционной системы и проверить
при установке.
Инфраструктурные программные средства обычно очень надежные и не несут риска
для потребителя. Все инфраструктурные программные средства должны
контролироваться и управляться.
К первой категории относятся:
― Операционные системы
― Сервера управления базами данных
― Языки программирования
Стр.32
― Межплатформенное ПО (middleware)
― Средства стат. обработки (statistical programming tools)
― Пакет электронных таблиц (spreadsheet package)
― Инфраструктурные программные средства (Infrastructure software tools)
― ПО мониторинга сети
― Службы обновления ПО
― ПО по обеспечению безопасности
― Антивирусы
Стр.33
GAMP. Категория 2 — Встроенное программное обеспечение (firmware)
Эта категория ПО устарела и более не используется в GAMP 5.

В основном встроенное программное обеспечение попадает в третью категорию.
Стр.34
GAMP. Категория 3 — Неконфигурируемые программы

Доступны в торговой сети, свободно продаются как стандартные решения различных
процессов. Конфигурация ограничена выбором среды и интерфейса (принтер, сеть и
т.п.).
Нет необходимости выполнять комплексную валидацию стандартных пакетов ПО, но
следует соблюдать определенную осторожность при инсталляции новых версий.
Стр.35
Фазы жизненного цикла для неконфигурируемого ПО
Требования
Тестирование требований
пользователей (URS)
Неконфигурируемый
продукт
Стр.36
Необходимо разработать СОПы и программу по обучению и подготовке персонала.
В ходе IQ следует проверить правильность имени и версии пакета установленного
ПО.
В ходе OQ следует задокументировать, рассмотреть и протестировать требования
пользователя, такие, как:
― защита
― операции при сигналах тревоги
― алгоритмы и расчеты
Стр.37
GAMP. Категория 4 — Конфигурируемые пакеты программ

Только в случае если система и платформа достаточно известные, можно отнести ПО
к данной категории.
Если же речь идет о новых приложениях или впервые используемых программах, то
их следует отнести к категории 5.
Данные системы предоставляют стандартный интерфейс и функции, которые дают
возможность пользователям разрабатывать собственные прикладные программы с
помощью конфигурации и включения предустановленных модулей, но также и
разработку совершенно новых прикладных модулей заказчика.
Каждая прикладная программа или конфигурация данного стандартного продукта
являются специфическими для конкретного процесса пользователя, а поддержание
системы становится ключевым моментом пользования, особенно в случае если
разрабатываются новые версии стандартного продукта или конфигурации.
В случае наличия кастомизации или добавочным кодам следует выполнить
программную проверку модифицированного кода (в том числе и алгоритмов).
Стр.38
Как правило проводится аудит поставщика с целью определения уровня качества
продукта. В случае отсутствия документированной системы качества поставщики
должны использовать руководство GAMP в качестве базы для формирования
соответствующей системы качества, данная система должна быть отнесена к 5
категории.
Примеры:
― контроллер с программируемой логикой (PLC),
― распределенная система управления (Distributed Control System, DCS),
― диспетчерское управление и сбор данных, (Supervisory Control and Data
Acquisition, SCADA)
Системы управления производством: Material Requirement Planning (MRP),
Manufacturing Execution System (MES), Enterprise Resources Planning (ERP), Laboratory
Information Management System (LIMS)
Стр.39
Фазы жизненного цикла для конфигурируемого ПО
Требования
Тестирование
пользователе
требований
й (URS)
Функцион. Функциональ
спецификация ное
(FS) тестирование
Конфигур.
спецификация Верификация
(DS)
Конфигурируе
мый продукт
Стр.40
Стадия IQ:
― Проверка правильность установки, версии ПО
― Проверка конфигурации
― При необходимости анализ программного кода
― Тесты основанные на оценке рисков и аудите поставщика
Стадия OQ:
― Проверка функциональности
― Обучение персонала
― СОП
Стадия PQ:
― Проверка соответствия требованиям URS
Стр.41
GAMP. Категория 5 — Заказное программное обеспечение

Такие системы используются для выполнения индивидуальных требований
заказчика. С целью проверки системы качества поставщика необходимо провести
аудит. Аудит поставщика должен подтвердить наличие адекватных систем качества
для контроля разработки прикладных программ и их текущей поддержки. В случае
отсутствия документальной системы качества поставщики должны
руководствоваться GAMP.
Следует отметить, что сложная система, которая разрабатывается под заказ, часто
состоит из многослойной программ, а одна система может характеризоваться
свойствами нескольких категорий.
Стадия IQ:
― Проверка правильность установки, версии ПО
― Проверка конфигурации
― Проверка модулей ПО
Стр.42
― При необходимости анализ программного кода
Стадия OQ:
― Проверка функциональности
― Обучение персонала
― СОП
― Тестирование сборки модулей программы
Стадия PQ:
― Проверка соответствия требованиям URS
Стр.43
Отнесение к категориям GAMP популярных программ

№ Наименование системы Категория Статус валидации
GAMP
1 1С Бухгалтерия 4 Не подлежит валидации
2 1С Предприятие 4,5 Подлежит валидации
3 Система электронного 4 Валидировано, если нет критической
документооборота (EDMS) документации
4 Система управления 3,4,5 Отдельные модули подлежат валидации
предприятием (ERP)
Стр.44
Необходимость валидации по GAMP в зависимости от категории внедряемой

компьютеризированной системы
Категория GAMP Аудит DQ IQ OQ PQ

поставщика
Системное программное обеспечение - - + - -
(ПО)
ПО, готовое для использования +/- +/- + +/- +/-
Конфигурируемое ПО +/- + + + +/-
Самостоятельно разработанное + + + + +
специальное ПО
Стр.45
GAMP. Классификация аппаратного обеспечения и его валидация
Стандартное аппаратное обеспечение (Standard Hardware)
― Должно быть документировано.
― Должна быть в наличии документация от поставщика или производителя.
― Должен быть обеспечен контроль моделей, версий, серийных номеров, доп.
оборудования.
― Корректность и установки и подсоединение должно быть валидированно.
― Необходимо использовать процесс упр. Конфигурацией.
― Необходимо использовать процесс упр. Изменениями.
Стр.46
Аппаратное обеспечение разработанное по заказу клиента (Custom Built Hardware

Components)
― Должно иметь DS
― Должно быть объектом приемочных испытаний
― Необходимо провести анализ рисков и на его основе
― Провести оценку поставщика (99% необходимо проводить)
― Необходимо провести тест совместимости соединения аппаратного обеспечения
с другими компонентами
― Аппаратная конфигурация должна быть определена проектом и
провалидирована
― Необходимо использовать процесс упр. конфигурацией
― Необходимо использовать процесс упр. изменениями
Стр.47
V-модель организации работ по валидации (GAMP)
V-модель организации работ по валидации (GAMP)
Стр.48
GAMP и система качества
Разделы GAMP, относящиеся к системе качества на этапе функционирования
Приложе
Группа процессов Процессы
ние GAMP
Передача (Handover) Процесс передачи между стадиями O1
Обслуживание и мониторинг эксплуатации Организация и управление службой поддержки O2

(Service Management and Performance Monitoring) Процесс мониторинга эксплуатации системы O3
Управление инцидентами (Incident Management Процесс управления инцидентами O4

and CAPA (Corrective and Preventive Action)) CAPA O5
Управление изменениями (Change Management) Управление изменениями O6

Управление конфигурацией системы O6
Процедуры по восстановлению системы O7
Аудиты и обзоры системы (Audits and Review) Периодический осмотр системы O8
Стр.49
Приложе
Группа процессов Процессы
ние GAMP
Управление непрерывностью процесса (Continuity Создание резервных копий и восстановление O9
Management) Планирование непрерывности процесса O10
Восстановление системы после катастроф O10
(Disaster Recovery Planning)
Безопасность и системное администрирование Управление безопасностью O11

(Security and System Administration) Системное администрирование O12
Управление записями (Records Management) Хранение записей O13

Архивирование и получение записей
Стр.50
Взаимодействие с поставщиком
Следует не доходить до взаимодействия с проблемным поставщиком. Поэтому
обычной практикой в обеспечении качества, кстати, обязательной в стандарте GMP,
является аудит системы качества поставщика.
Аудит – это проверка всех аспектов работы поставщика, которые могут повлиять на
качество поставляемой нам продукции и услуг. Как принято в обеспечении качества,
речь идет о проверке процессов. Обычно проверяются основные процессы - контроль
и обеспечение качества, производство, организация хранения и поставок продукции
и т. д.
Оценка поставщика
Важный решающий шаг во взаимодействии с поставщиками – это их периодическая
оценка. Та самая, на основе которой принимается решение:
― «Хвалить» поставщика и продолжать с ним сотрудничество
― «Ругать» и требовать улучшения на основе результатов контроля качества товара и аудитов
― Прекращать с ним сотрудничество
Стр.51
Поставщик и категории ПО GAMP
Неконфигурируемое ПО (GAMP категория 3)

Поставщик обычно предоставляет описание системы, при необходимости проводит
обучение персонала и инсталяцию.
Конфигурирумое ПО (GAMP категория 4)

Поставщик предоставляет спецификации на систему (FS, DS), обычно участвует в
процессе разработке верификации системы и в процессе функционирования.
Все взаимоотношения с поставщиком должны быть документированы по
разработанному плану.
URS желателен, но не обязателен.
Сам продукт должен быть разработан поставщиком с использованием Надлежащей
практики (таблица «Надлежащая практика взаимодействия с поставщиком»).
Стр.52
Заказное ПО (GAMP категория 5)

Продукт разрабатывается на основании требований пользователя (URS). Поставщик
принимает участие на всех этапах жизненного цикла.
Все взаимоотношения с поставщиком должны быть документированы по
разработанному плану.
Сам продукт должен быть разработан поставщиком с использованием Надлежащей
практики (таблица «Надлежащая практика взаимодействия с поставщиком»).
Стр.53
Надлежащая практика взаимодействия с поставщиком
Шаг Практика Описание

1. Создание системы Система качества должна:
качества с поставщиком 1. Предоставить документированный набор процедур и стандартов
2. Описать систему обучения персонала
3. Ввести проверку соответствия для процедур и стандартов
4. Обеспечить систему непрерывного улучшения взаимоотношений
2. Создание требований Поставщик должен убедиться, что утверждены понятные требования от

заказчика
3. Планирование качества Поставщик должен определить, каким образом его система качества должна
быть реализована для производимого ПО (или услуги)
4. Оценка суб-поставщиков Поставщик должен оценить своих суб-поставщиков как часть процесса
планирования отбора и качества
5. Создание спецификаций Поставщик должен указать, как и каким образом будут реализовываться
требования заказчика (URS)
Стр.54
6. Архитектура системы должна быть рассмотрена в разрезе требований,
Осуществление обзора стандартов и найденных рисков чтобы убедиться в том, что система
системы (Design Review) соответствует своему назначению и способна контролировать риски
7. Производство ПО / Продукт должен быть разработан в соответствии с определенными

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

тестирование планом
9. Коммерческий выпуск Релиз системы для Заказчика должен быть произведен в соответствии с
системы формальным процессом (например, акт приемо-передачи)
10. Предоставление Поставщик должен предоставить документацию по управлению,

пользовательской функционированию системой, а также документацию по обучению
документации и обучения пользователей в соответствии с договором.
Стр.55
11. Установка и поддержка Поставщик должен установить и поддерживать систему в соответствии с
системы договором. Процесс управления и документирования должен быть
полностью описан.
12. Замена и списание Поставщик должен разработать план по замене системы и ее списанию по
системы согласованным процедурам Заказчика
Стр.56
Элементы валидации компьютеризированных систем
Элементы валидации компьютеризированных систем
Документальные доказательства: Валидационный (Мастер)План, Требования
пользователей системы (URS), Спецификация на систему (FS, DS, TS), Валидационные
протоколы, документы о тестировании, СОПы, руководство, контроль измерений,
результаты аудита)
Используются: Функциональное и структурное тестирование, позитивные и
негативные тест-кейсы, тест на отклик системы, сценарий наихудшей ситуации,
тренинг пользователей
Стр.57
Принципы валидации
Принципы валидации
― «Владелец системы» отвечает за валидацию
― Оценка рисков
― Командный подход
― Валидационный план
― Документирование требований
― Аудит поставщика (вендора) с целью оценки качества программного обеспечения
― Согласованные заранее результаты тестов и критерии приемлемости
― Документирование операций (СОПы)
― Организованный архив документов
― Обучение
― Управление изменениями
― Система определения доступа
― Поддержка системы в валидированном состоянии
Стр.58
Виды валидации
Виды валидации
Перспективная валидация — валидация, которая проводится до начала серийного
производства продукции (GMP) или до начала дистрибьюторской деятельности (GDP).
Сопутствующая валидация — валидация, которая проводится в ходе серийного

производства продукции для продажи (GMP), или в процессе дистрибьюторской
деятельности (GDP).
Ретроспективная валидация — валидация процесса для препаратов, которые уже
присутствуют на рынке (GMP) или в процессе дистрибьюторской деятельности (GDP).
Ревалидация — повторная валидация процесса для обеспечения гарантии того, что

изменения в процессе/оборудовании, внесенные в в соответствии с процедурой
контроля изменений, не повлияли на характеристики процесса или качество
продукции.
Стр.59
Роли и распределение ответственности
Роли и распределение ответственности
Отдел обеспечения качества
― Помогает интерпретировать регуляторные документы для
компьютеризированных систем, осуществляет проверку ключевых документов во
время работ по валидации, мониторинг тестирования и валидационных процедур
― Может участвовать в разработке СОПов, принимает участие в аудите вендоров
IT-служба
― Помогает при заказе, инсталляции и организации работы системы в сети, следит
за работой компьютерной техники и ПО, осуществляет резервное копирование и
восстановление данных, устраняет проблемы, осуществляет контроль изменений,
доработку системы и ее дальнейшее развитие
Вендор (поставщик)
― Дает рекомендации по выбору соответствующего компьютерного оборудования,
содействует в проведении аудита вендора, помогает в квалификации системы (IQ
и OQ)
Стр.60
Заблуждения относительно процесса валидации
Заблуждения относительно процесса валидации
― Возможна частичная валидация системы
― Длительное использование равно валидации
― Валидация — разовое мероприятие
― Валидация не требует документирования
― Валидация равна тестированию ПО
― Валидация — работа для IT- отдела или отдела обеспечения качества
Стр.61
Квалификация vs Валидация
Квалификация vs Валидация
Стр.62
Этапы квалификации проекта DQ, IQ, OQ, PQ
Квалификация проекта (DQ)
Документированная проверка того, что представленный проект (ПО и оборудование)
соответствует запланированному назначению.
В руководствах GAMP используется термин проверка проекта (DesignReview).
Стр.63
Квалификация монтажа (IQ)

Документированная проверка того, что инсталляция системы выполнена в
соответствии с утвержденными спецификациями.
Испытания на стадии IQ:
― инспекция аппаратных средств
― контроль цепи передачи данных
― конфигурация данных управляющего оборудования
― калибровка измерительных приборов
― контроль соответствия со спецификациями оборудования
― тесты на функциональность оборудования
― проверка укомплектованности системных блоков
― тесты кабельного соединения с периферийными устройствами
― тесты датчиков, пультов управления и подсистем
Стр.64
― тесты питания, заземления, резервирования, кабельных соединений,
экранирования, устройств вне системы
― тесты коммуникаций
― контроль запасных частей
― проверка инсталляции программного обеспечения
― проверка условий окружающей среды (температура, влажность, запыленность)
Стр.65
Подготовка тестирования монтажа ПО и аппаратного обеспечения:
― Пользовательские и технические инструкции, СОПы
― Расписание обучения пользователей
― Договоры с обслуживающими компаниями
― Процедуры, связанные с работой по безопасности системы
― Журнал аудита
― Список и/или инвентаризация оборудования
― Инструментарий для тестирования
― Спецификации на оборудованием
― Сертификаты, калибровка приборов
― Исходный код ПО
― Программы установки (инсталяции ПО)
Стр.66
Основные точки тестирования стадии монтажа для всех систем:
― Тест на отключение питания
― Тест на доступ к системе и функций безопасности
― Тестирование логгирования и журнала аудита
― Тест корректности ручного ввода данных
― Тест электронных подписей
― Тестирование тревог и предупреждений
― Тестирование критических вычислений
― Тестирование критических транзакций
― Тестирование передачи критических данных в системе
― Тестирование интерфейсов
Стр.67
Квалификация функционирования (OQ)

Документированная верификация того, что система работает в соответствии с
утвержденными спецификациями во всех интервалах допустимых пределов по
операциям.
Квалификация функционирования полностью базируется на функциональной
спецификации системы (FS).
Для системы управления это означает предоставить доказательство того, что все
функции, каждая в отдельности и как целое, работают в соответствии со
спецификацией. Завершением OQ является так называемый «холостой ход», в
режиме которого функции КС проходят испытание в рамках нормальных заданных
допустимых пределов по операции и в чрезвычайных ситуациях.
Испытания на стадии OQ
― тест функциональности аппаратного обеспечения
― тесты коммуникации
Стр.68
― тесты работы функций управления
― функциональные тесты режима работы
― функциональные тесты приложения высшего уровня управления
― тесты сигналов тревоги системы
― тесты с нагрузкой и тесты защищенности системы
• запуск
• выключение
• система ошибок и отказов
• резервированное
• переключение на резервные системы
• обесточивание и т.п.
― тесты защищенности доступа
― проверка „ холостого хода”
Стр.69
― тестирование модулей
Стр.70
Квалификация эксплуатации (PQ)

Документированная верификация того, что система способна выполнять или
контролировать необходимые действия в соответствии с утвержденными
спецификациями, если она работает в своей операционной среде по спецификации.
Цель РQ – проверить, что КС работает воспроизводимо в соответствии с заранее
принятыми требованиями и обеспечивает соответствующие результаты.
Стр.71
Отчет по валидации
Когда закончен проект по валидации, собственник системы обязан составить отчет по
валидации. Этот отчет является результатом проекта по валидации и должен
содержать такие пункты :
― Краткое описание системы
― Идентификатор системы и всех программных компонентов, которые проходили
тестирование
― Описание используемого аппаратного обеспечения
― Основные направления деятельности в проекте
― Содержание тестовых протоколов, результаты тестов и выводы
― Список всех основных или критических замечаний с оценкой рисков и возможные
способы их решения.
― Утверждение, что все задачи Валидационного Плана были выполнены в
соответствии с предоставленной документацией
Стр.72
― Окончательное решение о корректности валидации
Отчет проверяется, принимается и подписывается Валидатором и Владельцем
Системы.
Стр.73
Бонусы после валидации компьютеризированных систем
Бонусы после валидации компьютеризированных систем
Очевидные
― Соответствие стандартам — престижно
― Уменьшение рисков для пациентов
― Расширение круга контрагентов
― Продлевается лицензия
Неочевидные
― Генеральная уборка системы и процессов
― Улучшение ПО и системы в целом
― Повышение эффективности работы с системой
― Разработка эффективных СОПов
― В процессе валидации система приводится к виду «незаменимых людей нет»
Стр.74
Список документов, необходимых для проведения валидации
Подготовительный этап
― Спецификация требований пользователей (URS)
― Функциональная спецификация (FS)
― Конфигурационная спецификация (DS)
― Техническая спецификация (TS)
― Матрица безопасности (может быть частью конфигурационной спецификации)
Квалификационный этап
― Анализ рисков (может быть частью Валидационного плана)
― Матрица прослеживаемости (может быть частью Валидационного плана)
Стр.75
Требования польз.
(URS)
Поставщик
Заказчик Функциональная Инструкции

спецификация (FS) Спецификации
Конфигурац.
Техническая
СОПы спецификация
спецификация (TS)
(DS)
Валидационный
план
Валидационная
команда
Протокол IQ Протокол OQ Протокол PQ
Стр.76
Спецификация требований пользователей (URS)
― Описывает то, что ожидается от системы (что будет делать система). Обычно
составляется Заказчиком;
― Первичная версия URS может быть включена в задание, которое отправляется
потенциальным поставщикам. Данная версия должна включать все необходимые
требования, но также и другие требования.
― Окончательная редакция URS может быть разработана после выбора поставщика.
― Требования должны быть связаны с PQ, в ходе которой проводится тестирование
системы в ее рабочей среде, включая также смежные процессы.
Стр.77
Содержание URS
1. Введение
― автор документа
― используемые нормативные документы
― ссылки на иные документы
2. Общие требования
― общая стратегия, состояние на сегодняшний день
― ключевые цели
― главные функции и интерфейс
― требования GxP и других нормативных документов
3. Требования к работе системы
3.1 Функции
Востребованные функции.
Стр.78
Сюда следует отнести информацию о процессе или существующей ручной системе:
― Описания процесса, блок-схемы процесса
― Расчеты, включая критические алгоритмы работы
― Операционные режимы (запуск, выключение, тестирование, аварийные
ситуации)
― Требования к производительности
― Действия, необходимые на случай сбоя
― Безопасность и защита
3.2 Данные
― Определение данных, включая идентификацию критических параметров,
диапазона данных
― Требования к производительности и скорости доступа
― Требования к архивации
Стр.79
― Защита и целостность данных.
3.3 Интерфейс
― Пользовательский интерфейс. Определение должно быть выражено в
категориях штатного расписания (например, оператор, кладовщик, менеджер по
закупок) или в категориях функций;
― Интерфейс – граница раздела с остальными системами;
― Средства сопряжения с оборудованием (например, датчики или функциональные
элементы). Сюда же относится и список вводов-выводов систем управления
процессами.
3.4 Среда
― размещение, т.е., физическую организацию помещения или других рабочих мест,
которые могу повлиять на систему (например, соединение на большом
расстоянии, ограничение пространства);
― физические условия (грязная, пыльная или стерильная среда и т. д.).
Стр.80
4. Ограничения КС
― временной масштаб, контрольные точки
― совместимость. Необходимо принимать в расчет все существующие системы,
стратегию компании
― доступность. Следует привести требования к надежности и максимально
допустимым периодам для техобслуживания и другие временные перерывы.
― Процедурные ограничения (например, обязательства, предусмотренные по
закону, методы работы и уровень навыков пользователя)
― Техобслуживание (например, простота техобслуживания, возможность
расширения, вероятное улучшение, предполагаемый срок службы, долгосрочная
поддержка).
5. Жизненный цикл
Разработка (например, методы управления проектом, обеспечения качества
разработки ПО)
Стр.81
― Тестирование (например, специальные требования по тестированию,
тестирование данных, тестирование нагрузки, моделирование).
Поставка
― как должна выглядеть идентификация поставленных позиций
― в каком виде должны быть позиции поставлены документы
― данные, которые должны быть подготовлены или конвертированы
― инструменты
― курсы по обучению персонала
― устройства хранения данных
― поддержка, необходимая после приемки.
6. Список терминов
Стр.82
Функциональная спецификация (FS)
Обычно составляется поставщиком и подробно описывает функции оборудования
или системы (т.е., что будет система делать). Однако, если КС находится в
эксплуатации, то FS должен быть составлен IT-отделом компании.
Первичная версия FS может быть разработана как часть ответа на задание.
Следующие редакции FS подготавливаются в сотрудничестве с пользователем.
FS связана с OQ, которая тестирует все предусмотренные по спецификации функции.
― Обычно составляется поставщиком и подробно описывает функции
оборудования или системы.
― Если FS составляется поставщиком, необходимо, чтобы ее проверял и утверждал
пользователь
― FS связана с квалификацией функционирования, в ходе которой тестируются все
предусмотренные в спецификации функции.
― FS должна подробно описывать то, что должна делать система, но не то, как это
Стр.83
должно выполняться в технологических категориях, что записано в URS.
― Должна быть создана матрица отслеживания требований между URS и FS.
― FS должна обновляться в ходе проекта
Стр.84
Содержание FS
1. Введение
― кто создает документ, в соответствии с какими нормативными документами и с
какой целью
― договорной характер документа
― ссылки на другие документы
2. Обзор системы
― главные интерфейсы системы
― требования, имеющие отношение к проекту или реализации (например,
стандартные пакеты, Операционная Система, аппаратное обеспечение);
― Расхождения с URS. Должны быть прописаны различия между FS и URS.
3. Функции
― Назначение функции или оборудования и детали по его применению, в том числе
Стр.85
и интерфейсы с остальными частями системы;
― Производительность
― Безопасность и защита. Действия в случае отказа выбранного программного
обеспечения и IT-инфраструктуры, самоконтроль, первичную валидацию,
дублирование данных, ограничения по доступу, предела по времени и
восстановления данных
― Конфигурируемые функции и любые пределы, в интервале которых
конфигурация может находиться
― Отслеживаемость до специфических требований URS.
4. Данные
― модель БД, типы данных
― тип, структура файлов данных
― Доступ (например, какие подсистемы нуждаются в доступе для чтения или записи
по каждой позиции данного, метод доступа, скорость и время актуализации,
Стр.86
блокирование для чтения и записи)
― Информационная емкость, период сохранения и детали по архивированию
данных
― Целостность и защита данных
5. Интерфейс
Пользовательский интерфейс
― Оборудование с которым будет проходить обмен данными, типы периферии,
общие форматы изображения и сообщений
― Средства сопряжения с оборудованием (например, датчики или функциональные
элементы).
Интерфейсы с другими системами:
― отсылаемые и принимаемые данные
― тип и формат данных, интервалы и значение величин
― установка времени
Стр.87
― скорость передачи
― коммуникационный протокол
― разделение данных, их создание, дублирование,использование, сохранение или
стирание
― коммуникация через параметры и общие области
― действия в случае ошибок
6. Нерабочие свойства и ограничения
― Применимость (например, надежность, резервирование, контроль ошибок,
операции в случае аварии)
― Поддерживаемость (например, возможности расширения и улучшения,
свободная емкость, вероятные изменения в среде, срок службы)
8. Приложения
Стр.88
Конфигурационная спецификация (DS)
Обычно состоит из Software Design Specification (Спецификация программного
обеспечения), Hardware Design Specification (Спецификация аппаратного
обеспечения).
В терминах GAMP называется «Configuration and Design Specification».
Полное описание оборудование или системы, которое требуется для создания КС, а
так же настроек системы.
Так же, как FS, она является выходом проектной документации.
Спецификация проекта связана с IQ, которая контролирует правильность поставки
оборудования или системы в соответствии с требуемыми стандартами и
правильность инсталляции (монтажа).
DS – это собственно детальный проект всех частей системы, т. е. как система
настроена.
На стадии разработки DS начинается работа над:
Стр.89
― руководствами пользователей по обслуживанию и эксплуатации технических
требований;
― стандартными операционными процедурами (СОП),
― составлении графика обучения персонала,
― деталями договоров сервисного обслуживания,
― безопасностью компьютеризированной системы
Стр.90
Содержание DS
1. Введение
― кто создает документ,
― в соответствии с какими нормативными документами и с какой целью
― договорной характер документа
― ссылки на другие документы
2. Краткое описание разработанного проекта
3. IT – инфраструктура
― Спецификация главного сервера
― Спецификация вспомогательных серверов
― Спецификация ПК
― Спецификация сетевого оборудования
Взаимное соединение.
Стр.91
Взаимное соединение всех компонентов и любые взаимные соединения с другим
оборудованием. В описание должны быть включены следующие элементы:
― спецификация кабелей
― спецификация разъемов
― требования по экранированию и защите
― схемы компоновки
― сетевое и наружное соединение
4. Вводы и выводы. Измерительные приборы на вводе и выходе.
К ним могут относиться:
― цифровые вводы
― цифровые выводы
― аналоговые вводы
― аналоговые выводы
Стр.92
― счетчики импульсов
Для каждого измерительного прибора необходимо специфицировать:
― точность
― изоляция
― разброс тока и напряжения
― тип и число интерфейсных карт
― хронометраж
5. Описание модулей
Для каждого модуля должно быть описано следующее:
― Работа модуля
― Интерфейс с другими модулями. Если создана схема системы, то достаточно в
форме ссылки на схему
― любые специфические факторы хронометража, которые не указаны в описании
Стр.93
системы.
― обращение с ошибками и валидация данных
― к каким системным данным разрешен доступ модуля.
6. Среда
― температура
― влажность
― внешние воздействия
― физическая защита
― влияние электромагнитного излучения
7. Энергоснабжение
― фильтрование
― нагрузка
― защита заземлением
Стр.94
― источники бесперебойного питания (UPS)
Стр.95
Техническая спецификация (TS)
Техническая спецификация (TS)
Перечень технических устройств и оборудования компьютеризированной системы,
которое установлено и готово к эксплуатации (или уже эксплуатируется).
В терминах GAMP называется Hardware List.
Обязательно должен присутствовать СОП по контролю изменений аппаратного
обеспечения.
Стр.96
Матрица прослеживаемости (трассируемости)
Предназначена для отслеживания связи между различными процессами.
Матрица позволяет убедиться в том, что
― Все требования пользователей соблюдены
― Каждому требованию соответствует определенный тест
Требование URS Функциональная Конфигурационная Номер теста

спецификация (FS) спецификация (DS)
U1.1.1 F2.4.1, F11.3 D2.5 IQ-1.3
U1.1.2 F2.4.5 D2.4 IQ-1.4, IQ-1.5
U1.2.1 F3.1 D1.1 OQ-5.1
U1.2.2 F3.2 D1.2 OQ-5.2
U1.2.3 F3.3 D4.3 PQ-3.3
Стр.97
Возможное расширение матрицы:
― Колонка с описанием требования
― Колонка с номером журнала контроля изменений (tracking system)
― Колонка, которая указывает уровень критичности требования и порядок
обработки
― Колонка, расширяющая данные о тестировании: дата, условие тестирования,
место тестирования и т. д.
― Колонка с указанием ссылки на тестирование калибровки оборудования,
используемое в тесте
Стр.98
Матрица безопасности (Security Matrix)
Обычно является частью Конфигурационной Спецификации (DS), но может
оформляться отдельно.
Объект/Роль Действие Администр Уполн. лицо Менеджер Нач. Отд. Продажник
атор по поставке закупок
Справочник Создание х х х
«Контрагенты» Чтение х х х х
Изменение х х х
Удаление х х
….
Док. «Расходная Создание х х
накладная» Чтение х х х
Изменение х х
Удаление х х
Проведение х х
….
Отчет «Остатки» Чтение х х х х х
Стр.99
Пример 2
Таблица Администр Уполн. лицо Менеджер Начальник Продажник
атор по поставке отд.
закупок
GOODS_ACC CRUD CRUD UR CRU R
GOODS_MESURES CRUD CR UR CRU R
….
DOC_INVOICE_HEADER CRUD R CRU CRU
DOC_INVOCE_ACC CRUD R CRU CRU
C — создание, R — чтение, U — изменение, D — удаление
Стр.100
Требования к оформлению документации
Необходимо определение формата документации (структура, стиль,нумерация и т.п.),
утвержден контроль версий документов.
Документ должен сохраняться вместе с изменениями и дополнениями.
В колонтитуле документа должно быть приведено
― название
― статус выпуска в обращение
Документация должна храниться в безопасном месте с защитой согласно СОП, быть
защищена от случайного или намеренного повреждения, быть отслеживаемой в
течение всего периода хранения.
Документ до принятия и выпуска в обращение должен быть обозначен грифом
«Проект»
Отчет о пересмотре и копия пересмотренного документа также сохраняются.
Утверждение должно быть выполнено с подписью и датой. Утвержденные
Стр.101
документы должны быть защищены, т е. существует недопустимость использования
неутвержденных или изъятых из обращения документов.
Должна быть обеспечена доступность для использования изменения в утвержденных
документах.
Следует проходить проверку, которую выполняют те же должности или организации,
которые выполнили проверку и утверждение оригинала.
Должны быть зарегистрированы с приведением описания изменения и
идентификации связанных документов
Изъятые из обращения документы следует архивировать с особым обозначением
Оформление тестов в документах, которые сохраняются:
― тесты должны охватывать все области систем
― планирование и проведение тестов должно проводится подготовленными,
квалифицированными персоналом
― персонал, проводящий тестирование, должен быть независимым и не должен
Стр.102
быть разработчиком тестов
― контролирующие лица должны быть независимыми и не должны быть
разработчиками тестов или выполняющими тесты
Документация по тестированию должна содержать:
― ФИО, занимаемую должность и даты для авторов, лиц, выполняющих
тестирование, и лиц, контролирующих тестирование
― метод проведения теста должен быть достаточно подробным, чтобы можно
было его воспроизвести;
― он должен ссылаться на релевантную спецификацию
― документация по тесу должна содержать дату и подпись лиц, проводящих и
контролирующих
― должны быть определены критерии для принятия результата по каждому тесту в
ходе проведения теста
― результаты должны записываться или следует приводить ссылки на распечатки
Стр.103
или на файлы по проведению теста
― сопроводительная документация должна быть подписана, датирована и
обозначена ссылкой на релевантный тест
― документация по тестированию и результаты должны сохраняться, в том числе
первичные наблюдения и действия, которые необходимы для оценки результатов
Стр.104
При проведении тестирования записи могут выполняться вручную. Записи должны
быть разборчивыми и не должны содержать стенографические записи и
перечеркивания.
Знаки повторения или стрелки исправления должны быть выполнены
перечеркиванием первоначального текста линией, которая оставит этот текст
разборчивым; завизированы и датированы с краткой пояснительной запиской.
Каждый тест должен быть завершен заявлением о том, было ли достигнуто
соответствие с критерием приемлемости.
Отклонения должны фиксироваться и контролироваться.
Стр.105
Примеры оформления протокола
Цель испытания
Подготовка
Проведение испытания
Критерий приемлемости
Действие Ожидаемый результат Полученный результат Оценка
 Да
 Нет
Примечание:
Заключение по испытанию: Приложение:

 Соответствует
 Не соответствует
 Соответствует с оговоркой
Стр.106
Пример № 2
Шаг Действие Ожидаемый результат Оценка
1.
 Да
 Нет
Примечание:
Заключение по испытанию: Приложение:

 Соответствует
 Не соответствует
 Соответствует с оговоркой
Стр.107
Валидационный мастер-план (VMP)
Используется как общий план для крупных проектов и/или нескольких систем.
VPM обычно затрагивает:
• Описание систем, оборудования или процессов (в общем);
• Текущий статус этих систем/оборудования;
• Принципы управления изменениями для этих объектов;
• Планирование и расписание (в т.ч. и для новых систем)
Стр.108
Содержание VMP
1. Описание;
2. Ссылки на политики компании;
3. Организационная структура;
4. Сводный список объектов, систем, оборудования и процессов;
5. Формат документации, используемый в для оформления протоколов и
отчетов;
6. Планирование работ и расписание;
7. Управление изменениями;
8. Ссылки на другие документы
Стр.109
Иерархия валидационых планов
Стр.110
Валидационный план (VP)
Валидационный план - документ, который описывает философию, стратегию и
методологию предприятия по проведению валидации.
Всю деятельность по валидации следует планировать. Ключевые элементы
программы валидации следует четко определить и задокументировать в плане
валидации или соответствующих документах.
План валидации должен быть обобщающим документом, лаконичным, точным и
четким.
Каждый шаг валидации должен быть записан в общий валидационный план и
содержать следующие пункты:
1. Цели и задачи валидации (политика предприятия в отношении проведения
валидации).
2. Распределение ответственности за проведение валидации/квалификации,
написание и утверждение валидационных протоколов и др.
Стр.111
3. Термины и определения.
4. Нормативные ссылки.
5. Организационная структура (сценарий) валидации, включая:
5.1. Вид, стадии и этапы валидации/квалификации.
5.2. Место и время проведения работ. Привлекаемые сторонние
организации и/или эксперты.
5.3. Формы валидационных протоколов, отчетов, сводных таблиц и др.
5.4. Проверка средств измерений.
5.5. Перечень работ по валидации процессов и квалификации условий
производства (технологическое и лабораторное оборудование, инженерные
системы). При этом обосновывается исключение отдельных объектов/процедур
валидации.
5.6. Требования к персоналу, участвующему в проведении
валидации/квалификации.
Стр.112
5.7. Условия периодической корректировки валидационного плана.
6. Описание предприятия, производства/участка, процесса, оборудования,
инженерных систем, продукта и др. (в т.ч. даются ссылки на другие документы).
7. Перечень методик проведения испытаний (измерений, тестов и др.). Критерии
оценки результатов, критические условия/параметры.
8. График проведения работ (рекомендуется оформить в виде таблицы) с
указанием: наименования объекта валидации/квалификации, стадии/этапов,
валидаторов, ответственных за согласование/утверждение протоколов, времени и
места, идентификации СОПов, и т.п.
9. Необходимые приложения (чертежи, схемы и др.).
Стр.113
Особенности валидации различного программного обеспечения
Валидация SCADA систем
― Контроль срабатывания тревог
― Контроль журнала тревог
― Монтаж датчиков и линий связи
― Контроль OPC сервера и конфигурации датчиков
Валидация RDP доступа

― Количество лицензий RDP сервера
― Расчет оперативной памяти на максимальное количество пользователей
Валидация заказного ПО на примере Oracle forms

― В конфигурационной спецификации (DS) должны быть указаны наименования
Стр.114
основных таблиц
― В DS или в матрице безопасности следует перечислить права доступа к таблицам.
По ним должен быть сделан тест на соответствие в протоколе OQ.
Стр.115
Особенности валидации систем различной аппаратной архитектуры
Особенности валидации систем различной аппаратной архитектуры
― Для виртуальным машин требуется проверка выделямых ресурсов (можно как из

гипервизора, так и внутри виртуальной машины);
― Необходима документация с системными требованиями, применямыми к
виртуальным машинам;
― Если внедряется новая система — обратите внимание на «просаживание»
ресурсов виртуальной машины по сравнению к физическому оборудованию
Стр.116
Анализ рисков для валидации компьютеризированных систем
Компьютеризированные системы (КС), задействованные при производстве или
реализации лекарственных средств, требуют валидации, которая должна
подтвердить их надежность.
GMP не требует проведения полной валидации, но допускает проведение валидации
только для их критических частей, компонентов и функций. Для оценки критичности
используется анализ рисков.
GMP требует, чтобы пользователи поняли риски, связанные с внедрением и
эксплуатацией КС.
Стр.117
Процесс анализа рисков обычно рассматривает следующие вопросы:
― Требуется ли валидация КС?
― Какой объем валидации востребован для данной КС?
― Какие аспекты КС или процесса являются критическими для продукта или
безопасности пациента?
― Какие аспекты КС или процесса являются критическими?
Стр.118
Цель анализа рисков

Цель анализа рисков – рассмотреть и оценить риски, связанные с эксплуатацией КС,
идентифицировать и свести к минимуму последствия неблагоприятных ситуаций, а
также определить и обосновать валидационные действия.
Проект подготовки и создания КС динамичен, что означает, что в ходе его реализации
происходят изменения.
В этой связи риски конкретной КС могут на протяжении проекта меняться, поэтому
необходимо, чтобы анализы рисков проводились на разных стадиях проекта. Их
число и время проведения должны быть указаны в валидационном МастерПлане.
Обычно анализы рисков проводятся при:
― разработке спецификации требований пользователя (URS)
― оценке поставщика и разработке функциональной спецификации (FS)
― проверке проекта перед валидационным тестированием
― введением критических и значительных изменений в КС
Стр.119
Если на протяжении проекта КС проводится несколько анализов рисков, необходимо
проверять заключения предыдущих анализов рисков в более поздних фазах проекта.
Причина такой необходимости заключается в подтверждении актуальности
предпосылок и заключений проведенных ранее анализов.
Если на протяжении проекта КС произошли критические или значительные
изменения, то предпосылки и заключения предыдущего анализа рисков могут также
измениться.
Подтверждение предыдущих заключений или их изменений следует всегда
последовательно записывать.
Анализ рисков должен выполняться специальной проектной группой, которая
располагает информацией о состоянии проекта и валидационных действиях. Состав
такой группы будет зависеть от сложности и специфики КС. По результатам анализа
рисков группа должна составить отчет, который должен быть согласован владельцем
и пользователями системы.
Заключения анализа рисков могут также согласовываться/утверждаться и другими
лицам: сторонние специалисты, поставщики и др.
Стр.120
Идентификация рисков
Идентификация рисков – операция по определению рисков, способных повлиять на
качество продукта.
Идентификация риска – это систематическое использование информации, для
установления опасности относительно аспекта риска или для описания проблемы.
Информация должна включать исторические данные, теоретический анализ, выводы
на основе информации, а также интересы участников.
Идентификация риска связана с вопросом «Что может происходить неправильно?», а
также с определением возможных последствий. Это обеспечивает основу для
дальнейших этапов процесса управления риском для качества.
Качество готовой продукции и образцов для клинических исследований:
― неправильный состав
― ошибки в исходных и упаковочных материалах
― неправильный статус серии
Стр.121
― отзыв серии
― отслеживаемость серии
― ошибки в маркировке и т.п.
Безопасность пациента:
― побочная реакция на применение препарата
― смешение образцов продукции
― неадекватное обращение
― жалобы
Данные регистрационного досье :
― сохранность результатов разработки
― неточная статистическая обработка
― неадекватная структура досье
Стр.122
Различные подходы к анализу рисков
«От бизнес-процесса»
Пример
URS FS Риск № теста
Документ прихода Документ «Приходная накладная» Поступление от
контрагента без лицензии;
Приход не на склад
карантина
Проблема: в URS должны быть учтены все требования GDP, а значит необходим этап
DQ
Стр.123
«От риска»
Риск FS № теста
Поступление от контрагента без лицензии; Документ «Приходная накладная»
Приход не на склад карантина
Не критический риск Печать реестра документов прихода
Требуется: отдельно матрица прослеживаемости
Стр.124
Оценка риска методом FMEA (Failure Mode and Effects Analysis)

Значение (Удельный вес) риска (MR) - общий риск от возможного дефекта или его
следствия выражается с помощью величины MR (степень риска дефекта или
приоритет дефекта).
MR = V * P * K
V - последствия риска
P - вероятность риска
K - вероятность обнаружения дефекта
MR – это общая степень риска каждой возможной причины дефекта. Чем больше MR,
тем первоочереднее потребность снижения соответствующего риска.
В зависимости от рассчитанного значения MR следует разделить дефекты:
Стр.125
MR Степень риска
28 - 125 высокая
9 - 27 средняя
1-8 низкая
Для определения последствия риска (V) необходимо понять, насколько

серьезными могут быть последствия рисковой ситуации можно дать оценку с
помощью приведенной ниже шкалы:
― низкие – небольшие негативные последствия, без долгосрочного воздействия
― средние – умеренные последствия, которые оказывают среднесрочное вредное
воздействие
― высокие – значительные негативные последствия с долгосрочным воздействием
или краткосрочным катастрофическим воздействием.
После оценки вероятности риска и определения уровня значимости общего
Стр.126
последствия можно определить категорию риска от 1 до 5.
Стр.127
Вычисление P (вероятность риска)

Требует выделить отрезок времени или количество операций, в ходе которых может
произойти рисковая ситуация.
В многих случаях рисковые ситуации могут быть следствием систематических
ошибок программного обеспечения. Если вероятность такой ошибки неизвестна, то
присваивается высокая вероятность появления дефекта.
Вероятность появления дефекта % Бальная оценка

ничтожная < 0.01 1
малая 0,01 – 0,3 2
средняя 0,3 – 5,0 3
предупреждающая 5,0 - 15 4
высокая > 15 5
Стр.128
Вероятность обнаружения дефекта (K)
Назначение данного шага – идентифицировать, можно ли распознать или выявить
рисковую ситуацию.
При наличии высокой вероятности выявления рисковой ситуации такая ситуация
может перестать быть серьезной угрозой, потому что она будет быстро выявлена и
можно предпринять корректирующие действия для смягчения ее последствий.
Наоборот, при низкой вероятности выявления рисковой ситуации следует подумать о
пересмотре проекта или о проведении альтернативных методов.
Для оценки вероятности выявления рисковой ситуации можно воспользоваться
следующей классификацией:
Стр.129
Вероятность обнаружения Вероятность Бальная оценка
дефекта обраружения
Большая > 99,7% 1
Удовлетворительная > 99% 2
Средняя > 95% 3
Малая > 90% 4
Ничтожно малая < 90% 5
Стр.130
Метод экспертных оценок
В случаях чрезвычайной сложности проблемы, ее новизны, недостаточности
имеющейся информации, невозможности математической формализации процесса
решения приходится обращаться к рекомендациям компетентных специалистов,
прекрасно знающих проблему, - к экспертам. Их решение задачи, аргументация,
формирование количественных оценок, обработка последних формальными
методами получили название метода экспертных оценок.
Метод экспертных оценок включает в себя три составляющие.
1. Интуитивно-логический анализ задачи. Строится на логическом мышлении и
интуиции экспертов, основан на их знании и опыте. Этим объясняется высокий
уровень требований, предъявляемых к экспертам.
2. Решение и выдача количественных или качественных оценок. Эта процедура
представляет собой завершающую часть работы эксперта. Им формируется решение
по рассматриваемой проблеме и дается оценка ожидаемых результатов.
3. Обработка результатов решения. Полученные от экспертов оценки должны быть
Стр.131
обработаны с целью получения итоговой оценки проблемы. В зависимости от
поставленной задачи изменяется количество выполняемых на этом этапе расчетных
и логических процедур. Для обеспечения оперативности и минимизации ошибок на
данном этапе целесообразно использование вычислительной техники.
Для решения подобных задач могут использоваться различные формы проведения
экспертизы:
― дискуссия;
― анкетирование;
― интервьюирование;
― «мозговой штурм»;
― совещание;
― деловая игра и др.
Иногда различные формы используются в комплексе.
Одной из наиболее перспективных форм проведения экспертного оценивания
Стр.132
считается метод Дельфы.
Стр.133
Метод Дельфы
Метод Дельфы - это набор процедур, выполняемых в определенной последовательности с
целью формирования группового мнения о проблеме, характеризующейся
недостаточностью информации для использования других методов.
Метод Дельфы - это метод группового анкетирования. Используемые процедуры
характеризуются тремя основными чертами: анонимностью, регулируемой обратной связью
и групповым ответом. Обратная связь осуществляется за счет проведения нескольких туров
опроса, причем результаты каждого тура обрабатываются статистическими методами и
сообщаются экспертам. Во втором и последующих турах эксперты аргументируют свои
ответы. Таким образом, в последующих турах эксперты могут пересмотреть свои
первоначальные ответы. От тура к туру ответы экспертов носят все более устойчивый
характер и, в конце концов, перестают изменяться, что служит основанием для прекращения
опросов.
Практика показывает, что обычно проводится три-четыре тура опросов, так как в
дальнейшем оценки перестают изменяться.
Стр.134
Способы снижения риска
Исходя из установленного приоритета риска можно определить и документировать
меры по смягчению рисковой ситуации.
Существует ряд стратегий для смягчения риска:
― модификация элементов процесса или системы
― включение инструментов независимого контроля в процесс (например,
дополнительная верификация данных при их вводе)
― внедрение испытанных методов, инструментов и компонентов КС (дублирование
компонентов, резервированная система)
― модификация стратегии проекта
― изменение персонала (опыт, квалификация, обучение)
― изменение утвержденной документации
― модификация валидационного подхода
Стр.135
― расширение тестирования
― снижение объема тестирования в связи с низким риском
― исключение риска
― новый способ производства, потому что риск слишком высокий
Стр.136
Принятие риска
Принятие риска - формализованное решение принять остаточный риск. Даже самая
лучшая практика по управлению рисками не может полностью исключить риски.
При таких обстоятельствах может быть установлен приемлемый уровень риска.
Специфицированный таким образом уровень будет зависеть от множества
параметров и должен определяться индивидуально.
Стр.137
Проблематика валидации ПО
и типичные ошибки
Стр.138
Оценка ресурсов компании
Области знаний в валидации ПО
Ресурсы:
• Время
• Квалификация
• Персонал
Стр.139
Типичные ошибки при формирование команды по валидации
― Формирование специалистами одного

профиля
― Желание обойтись малыми силами
Стр.140
Типичные ошибки при подготовке сотрудников к валидации

Обеспечение лояльности персонала к процессу
― Валидация — не проверка!
― Компетентность сотрудников не ставится под сомнение
― Подготовка сотрудников к пониманию процесса валидации — экономит Ваше

время
Стр.141
Формальный подход к процессу
Избегайте формального подхода к валидации, чтобы улучшить систему и

работу с ней в дальнейшем.
Стр.142
При разработке документации «под валидацию»
― Избегайте спешки, добивайтесь

качества
― Не создавайте ненужной
документации
― Документация пишется под процесс
или функцию, а не под валидацию
― Избыточность - не является нормой
― Пишите документацию для
пользователя!
Стр.143
При написании тестов
― Написание абстрактных тестов
― Каждый тест должен быть

повторяем
― Значения полученные в результате

тестов, должны фиксироваться в
протоколе, в т.ч. промежуточные
Стр.144
Надлежащая практика на практике
Нам несоответствий не надо!
Все выявленные отклонения и

несоответствия в процессе
должны быть устранены в
соответствии с принципами
жизненного цикла системы
(контроль изменений)
Стр.145
Общие принципы валидации компьютеризированных систем OMCL в
соответствии с ISO/IEC 17025
Аппаратная часть
Используемое аппаратное обеспечение, должно отвечает техническим требованиям
настолько, чтобы поставленная работа была выполнена. Такие требования включают,
например, минимальные системные требования, указанные заводом-изготовителем
оборудования. Эти требования должны быть заранее определены в соответствии с
предполагаемым использованием.
Аппаратные компоненты должны быть установлены квалифицированным
персоналом (например, сотрудниками отдела Информационных Технологий (ИТ),
техническим сотрудником производителя оборудования или другим
квалифицированным персоналом), а также должна быть проверена их
функциональность в сравнении с установленными требованиями.
Компьютеризированные системы, которые являются частью аналитического
оборудования должны иметь однозначную маркировку.
Стр.146
Для компьютеризированных систем, которые являются компонентами
аналитического оборудования, записи должны вестись от конфигурации
оборудования, монтажа и внесения изменений. Эти записи могут быть внесены в
журнал протоколирования аналитического оборудования.
Общие требования к программному обеспечению

Реестр
Должен быть доступен реестр или список всех компьютеризированных систем.
Следующая минимальная информация должна быть включена в реестр
компьютеризированных систем:
― уникальный идентификатор
― применение
― валидация статуса
― физическое или место хранения (диск и пути к файлам) местонахождение
Стр.147
программного обеспечения и сопутствующей документации
― ответственное или контактное лицо
В случае локальной установки (рабочая станция), каждая копия программного
обеспечения должна иметь свой собственный уникальный идентификатор.
В случае программного обеспечения, связанного с научным оборудованием
(например, ВЭЖХ) его идентификатор (например, номер лицензии или серийный
номер и номер версии) должен быть по возможности независимыми от
идентификатора оборудования.
Валидация программного обеспечения
Перед обычным использованием, программное обеспечение должно быть
валидировано.
Валидация заключается в подтверждении путем проверки и предоставлении
объективных доказательств того, что спецификации программного обеспечения
соответствуют потребностям пользователей и предполагаемому использованию, а
также, что специальные требования реализуемые с помощью программного
Стр.148
обеспечения могут последовательно выполняться.
Контроль за изменениями
В случае внесения изменений в программное обеспечение, должна быть проведена
валидация состояния системы. Если необходим перепроверяющий анализ, то он
должен быть проведен не только для проверки отдельных изменений, но также и
для определения масштаба и последствия этого изменения для всей
компьютеризированной системы.
Таким же образом, изменения в аппаратной среде могут повлиять на работающее
программное обеспечение. В этом случае может потребоваться ревалидация. В обоих
случаях объем ревалидации, будет зависеть от характера изменений.
Характер изменений должен быть задокументирован.
Автоматические обновления, в идеале, должны находиться под контролем ИТ
департамента или системного администратора и устанавливаться в предварительно
заданные даты, чтобы минимизировать как разрушение так и неожиданное
поведение системы. После установки обновлений, должна быть проведена
Стр.149
валидация, степень которой будет зависеть от степени обновления.
Каждое обновление должно быть задокументировано (это не обязательно относится
к сервисным обновлениям коммерческого офисного программного обеспечения).
Верификация программного обеспечения
Коммерческое программное обеспечение должно быть проверено во время
установки.
Что касается программного обеспечения собственной разработки, то оно должно
проверяться не только во время установки, но и в целом регулярно, чтобы избежать
любых ошибок и гарантировать хорошие результаты. Регулярность верификации
зависит от безопасности программного обеспечения, частоты использования и
возможных последствий в случае неудачи.
Защита программного обеспечения
Программное обеспечение должно быть защищено от любого вторжения, которое
может вызвать искажение научных результатов. Одним из способов защиты
программного обеспечения или компьютеров/систем является доступ с помощью
Стр.150
пароля. Он также должен быть защищен от любых внешних вмешательств, которые
могут изменить данные, и повлиять на окончательные результаты.
Резервное копирование
Прослеживаемость данных должна быть обеспечена от исходных данных к
результатам. Если все или часть отслеживаемых параметров, которые важны для
качества результатов, доступны только в электронном виде, то должен быть
реализован процесс резервного копирования для обеспечения восстановления
системы после любых неполадок, которые подвергают опасности её целостность.
Частота резервного копирования зависит от критичности данных, объем хранимых
данных и частоты их создания.
Должны иметь стратегию и установленные процедуры для обеспечения целостности
резервных копий (безопасное место хранения, достаточную удаленность от
основного места хранения, и т.д.) - эти мероприятия могут быть частью более общего
"плана аварийного восстановления".
В наличии также должны присутствовать процедуры по регулярному тестированию
резервных данных (тест восстановления), проверке надлежащей целостности и
Стр.151
точности данных.
Архив заменены версий программного обеспечения
Замененные версии программного обеспечения следует архивировать (если
требуется доступ к данным за прошлые года) на срок как минимум 5 лет, в
электронном формате, который можно легко восстановить и прочитать.
Данное требование не распространяется на коммерческие готовое к использованию
офисное программное обеспечение (включая сервисные обновления), программное
обеспечение, которое архивировано квалифицированным субподрядчиком или когда
данные за предыдущие периоды (исходные данные и результаты) документированы
в бумажном формате.
Определение версии программного обеспечения
Версия и название программы должны отображаться пользователю на
соответствующей стадии эксплуатации программного обеспечения (например, на
экране при открытии приложения), также они должны отражаться в любых отчетах,
генерируемых данным программным обеспечением.
Стр.152
Для лабораторного программного обеспечения на компьютерах в составе
аналитического оборудования, обновление программного обеспечения, включая
номер версии должны быть отражены в журнале оборудования.
Обзор компьютеризированных систем
Для компьютеризированных систем должны регулярно проводится действия по
управлению рисками и/или аудит.
Подготовка операторов программного обеспечения
Должна быть обеспечена корректная работа программного обеспечения. Это может
быть выполнено либо путем соответствующей и документированной подготовки или
путем изложения детальной информации в соответствующих СОП.
Стр.153
Список рисков GDP
№ Риск
1 Условия хранения и перемещения продукции
2 Система управления изменениями аппаратного обеспечения
3 Система управления изменениями программного обеспечения
4 Обслуживание аппаратного обеспечения
5 Обслуживание программного обеспечения
6 Охраняемая площадка для хранения серверного оборудования
7 Резервное копирование и восстановление данных
8 Ответственный по восстановлению данных
9 Авторизованный доступ
10 Архивирование данных
11 Процедура на случай поломки системы
12 Наличие инструкций для ключевых сотрудников
13 Наличие приказа на доступ к системе для пользователей
14 Наличие соответствующих прав в системе для пользователей
15 Наличие разрешения уполномоченного лица на отгрузку продукции
Стр.154
№ Риск
16 Наличие лицензии на торговлю при отгрузке
17 Наличие лицензии на торговлю при поставке
18 Наличие лицензии на импорт
19 Наличие регистрационного свидетельства на продукцию
20 Наличие остаточного срока годности при отгрузке
21 Запрет на отгрузку просроченной серии продукции
22 Запрет на отгрузку заблокированной серии
23 Запрет на отгрузку заблокированной продукции
24 Запрет на отгрузку продукции из карантина
25 Принцип FEFO при возврате
26 Принцип FEFO при отгрузке
27 Наличие инвентаризации (при необходимости)
28 Регулярный аудит компьютеризированной системы
29 Журнал аудита
30 Проверка полномочий уполномоченного лица в компьютеризированной системе
31 Карантин при поставке продукции от поставщика
32 Карантин при возврате продукции от покупателя
Стр.155
№ Риск
33 Обучение персонала
34 Прослеживаемость
35 Печать протоколов по поставке/отгрузке/возврате/списанию продукции
36 Аудит поставщика системы
37 Спецификация на аппаратное обеспечение
38 Спецификация на программное обеспечение
39 Функциональные требования
Стр.156
Объекты контроля по стадии IQ

1. Контроль документации по аппаратному обеспечению сервера
2. Контроль документации по обслуживанию серверов
3. Контроль спецификаций на физический сервер
4. Контроль документации на резервное копирование и восстановление данных
5. Контроль договоров на обслуживание КС
6. Контроль сопроводительной документации на КС
7. Контроль аппаратного обеспечения физического сервера в соответствии со
спецификацией
8. Контроль установки виртуализированного сервера приложений КС
9. Контроль установки виртуализированного сервера терминального доступа
10. Контроль установки виртуализированного сервера СУБД
11. Контроль ограничения доступа к физическому серверу
12. Контроль физических характеристик сети
13. Контроль пропускной способности канала к физическому серверу приложений
14. Контроль установки рабочих станций и периферийных устройств
Стр.157
15. Контроль характеристик принтеров
16. Контроль программного обеспечения физического сервера
17. Контроль наличия программ для резервного копирования информации
18. Контроль работы установленного сервера приложений КС
19. Контроль работы серверов терминалов
20. Контроль работы СУБД
21. Контроль установки рабочей базы данных КС
22. Контроль запуска клиентской части КС
23. Контроль критических параметров базы данных
24. Контроль установки программного обеспечения на рабочих станциях
Стр.158
Объекты контроля по стадии OQ

1. Контроль документации по управлению изменениями
2. Контроль документации по действиям в случае поломки системы
3. Контроль документации по регулярному аудиту системы
4. Контроль процедуры создания пользователя в системе и присвоения ему роли
доступа
5. Контроль процедуры аутентификации пользователя
6. Контроль журнала регистрации
7. Контроль интерфейсов меню и ролей пользователей
8. Контроль автоматизированных рабочих мест
9. Контроль процедуры изменения статуса склада
10. Контроль процедуры изменения статуса продукции
11. Контроль процедуры изменения условий хранения на складе
12. Контроль процедуры изменения блокировки покупателя
13. Контроль процедуры изменения блокировки продукции
14. Контроль процедуры изменения статуса серии продукции
Стр.159
15. Контроль процедуры изменения данных лицензии контрагента
16. Контроль прав доступа к ключевым объектам системы (продукция, серия,
контрагент, склад)
Стр.160
Объекты контроля по стадии PQ

1. Контроль квалификации пользователей системы
2. Контроль разрешения на доступ пользователей в систему
3. Контроль назначения ролей для пользователей
4. Контроль наличия у пользователей паролей для доступа
5. Контроль наличия инструкций по работе с системой для ключевых сотрудников
6. Контроль наличия резервной копии данных системы
7. Контроль наличия авторизованного доступа к резервным данным системы
8. Контроль даты последнего резервирования данных системы
9. Контроль срока хранения резервных данных системы
10. Контроль содержимого архивной копии
11. Контроль содержимого резервной копии
12. Контроль лицензии поставщика при поступлении продукции
13. Контроль регистрационного свидетельства продукции при поступлении на
рынок Украины
14. Контроль лицензии на импорт при поставке продукции от нерезидента
Стр.161
15. Контроль наличия в протоколе по поставке даты, поставщика, получателя,
наименования продукции, номера серии, количества
16. Контроль карантина при поступлении товаров
17. Контроль запрета на размещение товара в недопустимой температурной зоне
18. Контроль разрешения на отгрузку продукции
19. Контроль лицензии покупателя при отгрузке
20. Контроль точки активности контрагента
21. Контроль запрета на отпуск серий товаров с истекшим сроком годности
22. Контроль запрета на отпуск товаров с незаполненной серией
23. Контроль запрета на отпуск товаров с заблокированной серией
24. Контроль запрета на отпуск товаров с заблокированной продукцией
25. Контроль принципа FEFO при отгрузке товаров покупателю
26. Контроль процедуры сборки заказа
27. Контроль наличия в протоколе по отгрузке даты, поставщика, получателя,
наименования продукции, номер серии, количества
28. Контроль наличия в протоколе по отгрузке: даты, названия лекарственного
средства и лекарственной формы, номер серии, количества; название и адрес
Стр.162
поставщика, название грузополучателя и фактический адрес доставки,
необходимый транспорт и условия хранения
29. Контроль блокировки отгрузки продукции при недостаточности количества по
серии
30. Контроль отгрузки с учетом срока доставки
31. Контроль FEFO при возврате продукции от покупателя
32. Контроль карантина при возврате продукции
33. Контроль процедуры вызова печатных форм документа возврата продукции от
покупателя
34. Контроль наличия в протоколе по возврату поставщику даты, поставщика,
получателя, наименования продукции, номер серии, количества
35. Контроль условий хранения при перемещении продукции
36. Контроль процедуры инвентаризации продукции
37. Контроль соблюдения условий хранения при оприходовании продукции
38. Контроль прослеживаемости при списании продукции
39. Контроль движения продукции по складам с расшифровкой движений
40. Контроль движения серий продукции по складам с расшифровкой движений
Стр.163
41. Контроль отчета остатков серий по срокам годности
42. Контроль формирования отчета по срокам регистрации товаров
43. Контроль формирования реестров документов
44. Контроль требований согласно URS
Стр.164
Список рисков GMP
№ Риск
1 Обучение персонала
2 Наличие СОП и инструкций к системе
3 Печать и хранение протокола производства
4 Проверка полномочий уполномоченного лица в КС
5 Договор с поставщиком
6 Контроль роли начальника производственного отдела
7 Документация на рецепт и технологические инструкции
8 Содержимое протокола производства
9 Печать и хранение протокола упаковки серии
10 Протокол дистрибуции продукции
11 Наличие лицензии контрагента при поставке сырья
12 Наличие идентификатора серии
13 Условия хранения и перемещения продукции
14 Журнал аудита (данные)
15 Система управления изменениями аппаратного обеспечения
Стр.165
16 Система управления изменениями программного обеспечения
17 Обслуживание аппаратного обеспечения
18 Обслуживание программного обеспечения
19 Резервное копирование и восстановление данных
20 Архивирование данных
21 Авторизованный доступ
22 Спецификация на аппаратное обеспечение
23 Спецификация на программное обеспечение
24 Функциональные требования
25 Требования пользователей
26 Прослеживаемость серии продукции
27 Дополнительная проверка ввода/изменения данных
28 Протокол лабораторного контроля
29 Аудит поставщика
30 Журнал аудита (безопасность)
31 Электронная подпись
32 Утверждение произведенной серии продукции Уполномоченным Лицом
33 Внутренние самоинспекции
Стр.166
34 Контроль критических параметров системы
35 Разрешение на выпуск серии продукции Уполномоченным Лицом
36 Наличие инструкций по ручному управлению системой
Стр.167

Seminar IT Комп Системи

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Seminar IT Комп Системи

Uploaded by

Copyright:

Available Formats

Семинар

Валидация компьютеризированных систем

Лекторы: Мирошниченко Станислав, Трунов Ян

Программное обеспечение Операционные процедуры и персонал

Аппаратное обеспечение Оборудование

Компьютерная система Контролируемая функция или бизнес-процесс

Окружение (включает другие компьютерные сети, отдельные самостоятельные компьютеризированные

WMS — warehouse managment system, система управления складом

Достоинства и недостатки двухзвенной технологии

Трехзвенная технология (тонкие и обычные клиенты)

Достоинства и недостатки трехзвенной технологии

Регистрирующие системы для дистрибуции

Управляющие производственные системы

Регистрирующие производственные системы

Hyper-V — аппаратная виртуализация от Microsoft. Существует как отдельный продукт

Системы, для которых предназначен GAMP

Знания о продукте Спецификация и

Этапы жизненного цикла для компьютеризированных систем

Фазы жизненного цикла

― передача системы от разработчика группе поддержки

Другие модели жизненного цикла

GAMP. Категория 2 — Встроенное программное обеспечение (firmware)

Эта категория ПО устарела и более не используется в GAMP 5.

GAMP. Категория 3 — Неконфигурируемые программы

GAMP. Категория 4 — Конфигурируемые пакеты программ

GAMP. Категория 5 — Заказное программное обеспечение

Отнесение к категориям GAMP популярных программ

Необходимость валидации по GAMP в зависимости от категории внедряемой

Категория GAMP Аудит DQ IQ OQ PQ

Аппаратное обеспечение разработанное по заказу клиента (Custom Built Hardware

Обслуживание и мониторинг эксплуатации Организация и управление службой поддержки O2

Управление инцидентами (Incident Management Процесс управления инцидентами O4

Управление изменениями (Change Management) Управление изменениями O6

Аудиты и обзоры системы (Audits and Review) Периодический осмотр системы O8

Безопасность и системное администрирование Управление безопасностью O11

Управление записями (Records Management) Хранение записей O13

Поставщик и категории ПО GAMP

Неконфигурируемое ПО (GAMP категория 3)

Конфигурирумое ПО (GAMP категория 4)

Заказное ПО (GAMP категория 5)

Надлежащая практика взаимодействия с поставщиком

Шаг Практика Описание

2. Создание требований Поставщик должен убедиться, что утверждены понятные требования от

7. Производство ПО / Продукт должен быть разработан в соответствии с определенными

8. Эксплуатационное Поставщик должен протестировать систему в соответствии с разработанным

10. Предоставление Поставщик должен предоставить документацию по управлению,

Сопутствующая валидация — валидация, которая проводится в ходе серийного

Ревалидация — повторная валидация процесса для обеспечения гарантии того, что

Квалификация монтажа (IQ)

Квалификация функционирования (OQ)

Квалификация эксплуатации (PQ)

Заказчик Функциональная Инструкции

Требование URS Функциональная Конфигурационная Номер теста

C — создание, R — чтение, U — изменение, D — удаление

Заключение по испытанию: Приложение:

Заключение по испытанию: Приложение:

Иерархия валидационых планов

Валидация RDP доступа

Валидация заказного ПО на примере Oracle forms

― Для виртуальным машин требуется проверка выделямых ресурсов (можно как из

Цель анализа рисков

Требуется: отдельно матрица прослеживаемости

Оценка риска методом FMEA (Failure Mode and Effects Analysis)

Для определения последствия риска (V) необходимо понять, насколько