Аспекты валидации автоматизированных систем контроля состояния грузов

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

Для налаживания эффективного и бесперебойного использования всех элементов складской инфраструктуры требуется слаженная работа специалистов различных подразделений, четкое распределение ролей и ответственности в части обслуживания, настройки и надлежащей эксплуатации. Необходимо внедрение системного подхода при управлении процессами, в чем значительную роль играет система менеджмента качества.
Как и многие другие, фармацевтическая отрасль движется в сторону освоения облачных решений. Однако при переходе необходимо учитывать потенциальные риски и нормативные ограничения, актуальные для GxP.

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

Трекеры представляют собой логгеры, которые помимо/вместо встроенного накопителя данных взаимодействуют с различными внешними средами хранения, управления и извлечения информации, как облачными, так и гибридными. Например, когда данные и системы управления базами данных (СУБД) размещаются на серверах облачных провайдеров (Amazon Web Services, Microsoft Azure, Google Cloud Platform, Yandex Cloud), а пользовательский интерфейс развернут локально (on-premises) или является облачной платформой, предоставляемой по принципу Software as a Service (SaaS, программное обеспечение (ПО) как услуга).

Annex сообщает – если компьютеризированная система заменяет ручную операцию, то не должно быть никаких снижений показателей на уровне свойств продукции, контроля над процессами или обеспечения качества. Не должно быть и увеличения общих рисков.

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

Для определения подходов к валидации в одном из аспектов полезно разобрать IT-инфраструктуру системы мониторинга с применением онлайн-трекеров температуры с точки зрения Good Automated Manufacturing Practice (GAMP 5).

GAMP 5 выделяет следующие категории ПО в зависимости от сложности и уровня настройки:

1. Коммерчески доступное «коробочное» ПО (COTS):  
   • готовое ПО от поставщиков, не требующее настройки или изменения,
   • примеры – офисные приложения, бухгалтерские программы,
   • валидация минимальная, так как поставщик отвечает за качество и соблюдение стандартов.
2. ПО с ограниченной настройкой: 
   • настраиваемое ПО с ограниченными возможностями изменения функциональности,
   • примеры – программы управления документами, ERP-системы (например, привычный формат 1С,
   • при валидации требуется документирование изменений и конфигураций.
3. ПО с расширенным функционалом настройки:  
   • ПО допускает значительные изменения в функциональности, но базируется на стандартных платформах.
   • Примеры – адаптированные системы управления производственными процессами, системы управления качеством, частный пример – проекты на SCADA.
   • валидация требует точной и корректной документации и тестирования, так как изменения могут влиять на работу системы.
4. Разработанное на заказ ПО:
   • ПО, созданное специально для конкретного клиента или проекта,
   • пример – специализированные решения для автоматизации процессов в фармацевтике,
   • валидация требует наиболее тщательной проверки, включающей полный цикл разработки, тестирования и документации для обеспечения качества.
5. Программные компоненты:  
   • программные модули или компоненты, которые не используются в других приложениях или системах,
   • примеры – библиотеки, API, протоколы,
   • эффективность валидации зависит от интеграции с другими системами, может требовать отдельного специфического подхода.
6. Firmware – ПО, встроенное в аппаратное обеспечение и управляющее его функциями (так называемая прошивка). Может быть отнесено к одному или нескольким вышеперечисленным классам. Валидируется соразмерно степени интеграции с инфраструктурой КС и влиянием на ее функции или не валидируется.

Если через призму GAMP 5 посмотреть на один из возможных вариантов архитектуры системы мониторинга с использованием онлайн-трекеров температуры, то инфраструктурное ПО может включать следующие категории для планирования валидации:

• операционная система – основная платформа, на которой работают приложение и система. Примеры: Windows Server, Linux, Unix,
• виртуализация – ПО, позволяющее создавать виртуальные машины и управлять ресурсами (VMware, Microsoft Hyper-V, KVM),
• СУБД – ПО для хранения, управления и обработки данных (Oracle, Microsoft SQL Server, MySQL),
• сетевое ПО – обеспечивает сетевое взаимодействие, безопасность и управление трафиком (Cisco IOS, pfSense, Mikrotik),
• системы резервного копирования и восстановления – инструменты для защиты данных и восстановления после сбоев (Veeam, Acronis, Commvault),
• мониторинг и управление производительностью – ПО для отслеживания состояния и производительности инфраструктуры (Zabbix, Prometheus, Grafana),
• управление конфигурациями и автоматизация – решения для управления конфигурациями серверов и автоматизации процессов (Ansible, Puppet, Chef, Terraform),
• облачные платформы – инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и ПО как услуга (SaaS).

Остановимся на облачных платформах как очевидном и распространенном компоненте системы мониторинга состояния грузов с применением онлайн-трекеров температуры. Поставщик услуги облачной платформы (Cloud Service Provider, CSP) может предлагать различные модели обслуживания, решающие задачи на разных уровнях.

IaaS. CSP предоставляет только инфраструктуру, настройкой и работой всех остальных уровней занимается клиент.

PaaS. CSP предоставляет инфраструктуру и устанавливает операционную систему, а само приложение конфигурирует клиент. Поскольку операционные системы относятся к категории ПО GAMP 1, и риски считаются невысокими, в качестве контроля риска следует указывать и проверять конфигурацию операционной системы. При этом клиент должен понимать, каким образом и как часто CSP обновляет ее, а также когда и как уведомляет об этом клиента. Процедура обновления должна быть определена в соглашении об уровне предоставления услуги (Service Level Agreement, SLA).

SaaS. CSP предоставляет инфраструктуру, операционную систему и приложение (например, приложение системы мониторинга состояния грузов). Здесь CSP необходимо указать и проверить приложение в соответствии с требованиями и стандартами самого пользователя (клиента). Более того, некоторые аспекты управления конфигурацией остаются за CSP. Эта модель может допускать оценку CSP на основе рисков, включая аудит. Общий риск, а также объем оценки можно уменьшить, если CSP обеспечит соответствующую документацию, например, сертификаты. Риски, выявленные в результате оценки, должны быть снижены соответствующими мерами контроля вроде SLA. Стратегия обновления CSP более важна для SaaS, чем для PaaS, поскольку изменения и обновления могут иметь более широкое влияние и нести больший риск. Поэтому понимание стратегии обновления CSP и получение уведомлений о любых запланированных и предстоящих изменениях еще более актуальны и должны быть отражены в SLA.

Независимо от модели обслуживания (IaaS, PaaS или SaaS), роли и обязанности CSP и клиента должны быть четко определены, а любые процедуры обновлений и контроля изменений – согласованы в SLA.

Как правило, проверка SaaS следует тем же принципам, что и проверка традиционной компьютеризированной системы. Однако SaaS привносит новые риски и смещает фокус на деятельность CSP, которая играет более важную роль, что требует особого внимания к аудиту поставщика и SLA. Например, необходима стратегия выхода, так как  CSP не только управляет приложением, но и хранит и управляет данными, это важно учитывать на случай смены поставщика SaaS.

Для SaaS-приложений, предлагаемых поставщиками облачных сервисов для GMP, обычно подразумевается полная валидация базовой системы. В этом случае CSP сам выполняет все необходимые этапы валидации (от URS до UAT (User Acceptance Testing)) и документирует их. Клиент (пользователь) может ссылаться на эти документы по валидации для стандартной системы, но должен выполнять все шаги по адаптации (настройке) системы также и самостоятельно без делегирования CSP.

По мере проникновения облачных сервисов в отрасль фармацевтической логистики деятельность будет смещаться от клиента (компании-пользователя) к поставщику SaaS-услуг. Однако, следуя духу GxP, ответственность за проверку и работу приложений, а также за все связанные с ней разделы (целостность, конфиденциальность, безопасность данных и так далее) пользователь должен оставлять за собой.

Источник – Сборник GDP Review 5 VI Конференции «Логистика лекарственных средств»