Модели облачных вычислений в настоящее время хорошо зарекомендовали себя во многих отраслях бизнеса, тем самым повысив надежность защиты данных и сократив связанные с этим расходы. Фармацевтические компании и производители медицинского оборудования начали использовать данную технологическую модель, хотя и с некоторой задержкой в отношении других областей бизнеса. данная статья ориентирована на определение нормативных ожиданий для GxP записей, управляемых с помощью облачных сервисов, и мер контроля, которые должны быть реализованы для обеспечения целостности данных. Основное внимание уделяется требованию валидации компьютеризированных систем, которое является ключевым требованием для обеспечения надежности и конфиденциальности записей для данного типа систем. данный подход позволяет снизить риски, возникающие в результате внедрения облачных решений, в которых данные хранятся в центрах обработки данных, управляемых поставщиком под его полную ответственность, без видимости со стороны GxP компании.
ПРЕДПОСЫЛКИ
Индустрия GxP всегда была более консервативной с внедрением новых технологий, и облачные системы не являются исключением. В целях обеспечения безопасности пациентов, регулируемые компании (компании, занимающиеся производством фармацевтической продукции и медицинских изделий) подвергаются тщательному нормативному надзору и обязаны тщательно проанализировать все риски, прежде чем внедрять какие-либо новые технологии. Тем не менее, отрасли вынуждены упростить свои бизнес-процессы и сократить расходы. Одним из способов оптимизации сложных процессов стало внедрение облачных вычислительных сервисов.
Согласно Национальному институту стандартов и технологий [01], облачные вычисления определяются как «модель для обеспечения повсеместного, удобного сетевого доступа “по требованию” к общему пулу настраиваемых вычислительных ресурсов (на-пример, сетей, серверов, хранилищ, приложений, услуг), которые могут быть быстро предоставлены и реализованы с минимальными усилиями руководства или взаимодействия с поставщиком услуг». Обычно услуги облачных вычислений предоставляются сторонним поставщиком, который владеет инфраструктурой. В последнее время облачные вычисления стали одной из самых обсуждаемых технологий и привлекли большое внимание средств массовой информации, а также аналитиков из-за возможностей, которые они предлагают.
Потенциальные преимущества, которые применимы практически ко всем типам облачных вычислений, включают:
– Экономию средств, поскольку компании могут минимизировать свои капитальные затраты, заменяя их эксплуатационными расходами;
– Адаптивность облачных вычислений позволяет компаниям наращивать ИТ-возможности в пиковые периоды времени, чтобы они могли удовлетворить запросы потребителей;
– Сервисы, использующие несколько резервных площадок, могут поддерживать непрерывность бизнеса и аварийное восстановление;
– Поставщики облачных услуг выполняют обслуживание системы, которое не требует установки приложений на ПК, сводя к минимуму нагрузку на внутренний ИТ-отдел;
– Мобильные работники повысили производительность благодаря системам, доступным в инфраструктуре, доступной из любой точки мира, даже с мобильного устройства;
– Высокая доступность, поскольку дополнительные серверы могут быть добавлены к предоставленной услуге без прерывания службы или необходимости перенастройки решения для поставки приложений;
– Меньше потребности в ИТ-знаниях и ИТ-инвестициях.
Когда подобные электронные услуги используются для обработки регулируемых данных в фармацевтической компании, также вводятся новые риски. Эти риски включают в себя:
– Системы и данные, внедренные в ИТ-инфраструктуру вне зоны контроля компании;
– Отсутствие контроля над обслуживанием программного обеспечения (например, внедрение изменений) и управлением центром обработки данных (например, контроль безопасности);
– Совместную работу различных поставщиков, чтобы обеспечить приложение программного обеспечения в ИТ- инфраструктуре;
– Риски кибербезопасности;
– Требования индивидуального подхода к валидации и квалификации. Риски должны быть снижены, чтобы обеспечить целостность GxP данных, которая всегда находится в ведении регулируемой компании; как следствие, компания должна установить надлежащие и специальные средства контроля для обеспечения целостности управляемых данных. Недостаточная целостность данных и уязвимость подрывают качество записей и могут в конечном итоге подорвать качество лекарственных средств.
Документ ориентирован на определение нормативных ожиданий для регулируемых записей, управляемых через облачные сервисы, и основных тем, которые необходимо учитывать для обеспечения целостности данных, с учетом требований валидации компьютеризированных систем, что является ключевым требованием для обеспечения надежности и конфиденциальности записей.
ТИПЫ ОБЛАЧНЫХ РЕШЕНИЙ И МОДЕЛИ ОТВЕТСТВЕННОСТИ
В настоящее время регулируемым компаниям предоставляются следующие виды услуг:
Программное обеспечение как услуга (SaaS) – регулируемые компании используют приложения, работающие на инфраструктуре, принадлежащей поставщику ИТ-услуг. Регулируемые компании не управляют и не контролируют базовую инфраструктуру, но у них есть возможности регулирования пользовательских настроек приложений через конфигурацию и кастомизацию этих приложений.
Платформа как услуга (PaaS) – регулируемые компании используют ИТ-инфраструктуру, размещенную у поставщика ИТ-услуг, для запуска приложений, созданных с использованием операционных систем, языков программирования и инструментов, поддерживаемых поставщиком ИТ-услуг. Регулируемые компании не управляют и не контролируют базовую облачную инфраструктуру, включая сеть, серверы, операционные системы или хранилище, но по прежнему контролируют развернутые приложения и, возможно, конфигурации среды размещения приложений.
Инфраструктура как услуга (IaaS) – Владелец использует основные вычислительные ресурсы, такие как обработка, хранение, сети, где клиент может запускать произвольное программное обеспечение, которое может включать в себя операционные системы и приложения. Клиент не управляет и не контролирует базовую облачную инфраструктуру, но контролирует операционные системы, хранилище, открытые приложения и, возможно, ограниченный контроль над отдельными сетевыми компонентами (например, межсетевые экраны хоста).
На рисунке 1 показаны виды ответственности трех типов услуг по отношению к традиционной ИТ-инфраструктуре с учетом рекомендаций GAMP [02]:
Согласно соответствующему руководству NIST [03], облачные системы могут быть запущены в соответствии с четырьмя различными моделями (частное облако, облачное сообщество, публичное облако и гибридное облако).
НОРМАТИВНЫЕ ОЖИДАНИЯ
Использование облачных систем в настоящее время разрешено основными регулирующими агентствами при условии адекватного снижения связанных с ними дополнительных рисков. Ожидания, установленные регулирующими органами, перечислены ниже.
US FDA
С 1997 года в соответствии с 21 CFR Part 11 [03], FDA США определило требования к открытым системам. Для данных систем, в § 11.30 FDA рекомендует: «Люди должны использовать процедуры и средства контроля, предназначенные для обеспечения подлинности, целостности и, где это уместно, конфиденциальности электронных документов с момента их создания до момента получения». Эти процедуры и средства контроля включают в себя те, которые определены в пункте § 11.10, и, при необходимости, дополнительные меры, такие как шифрование документов и использование стандартов цифровой подписи, для обеспечения, в зависимости от обстоятельств, подлинности, целостности и конфиденциальности записей.
В проекте руководства, выпущенном в июне 2017 г. [06] FDA признает, что спонсоры и другие регулируемые организации могут принять решение об аутсорсинге электронных услуг. Примерами таких видов электронных услуг являются услуги управления данными, включая услуги облачных вычислений. В руководстве FDA подробно изложены конкретные требования к облачной системе, используемой в клинических исследованиях.
ВОЗ
В соответствии с соглашением о субподряде, в руководстве ВОЗ [04] подчеркивается необходимость установления и надежного поддержания определенных ролей и обязанностей для обеспечения полных и точных данных и записей по всем этим отношениям. Аутсорсинговая организация несет ответственность за достоверность всех полученных результатов. Эта ответственность распространяется на всех поставщиков соответствующих вычислительных услуг, такие как контрактные ИТ-центры обработки данных, контрактные ИТ-системы, персонал поддержки баз данных и поставщики решений облачных вычислений. Аутсорсинговым организациям следует проверять на соответствие системы управления получателя кон-тракта посредством аудита или других подходящих средств. Ожидаемые стратегии контроля целостности данных должны быть включены в соглашения о качестве, в кон-тракты и технические соглашения, в зависимости от случая и необходимости, между лицом, предоставляющим контракт и лицом, принимающим контракт.
MHRA
В своем руководстве [07] MHRA утверждает, что следует уделить внимание пониманию предоставляемых услуг, владению, поиску, хранению и безопасности данных. Физическое/ географическое расположение данных должно вызывать обеспокоенность, учитывая влияние применимости любого закона. Обязанности подрядчика и заказчика контракта должны быть определены в техническом соглашении или контракте. Это должно обеспечить своевременный доступ к данным (включая метаданные и контрольный след) владельцу данных и национальным компетентным органам по запросу. Контракты с поставщиками должны определять ответственность за архивирование и постоянную читаемость данных в течение всего срока хранения. Должны существовать соответствующие меры для восстановления программного обеспечения/системы в соответствии с их первоначальным валидированным состоянием, включая информацию о валидации и управлении изменениями, чтобы разрешить данное восстановление. Механизмы обеспечения непрерывности бизнеса должны быть включены в контракт и проверены. Необходимость проведения аудита поставщика услуг должна основываться на риске.
ISPE
В различных руководствах ISPE обсуждаются аспекты, связанные с услугами облачных вычислений. Руководство по инфраструктуре GAMP [02] содержит специальные разделы об элементах ИТ и облачной инфраструктуры, рисках и конкретных аспектах соответствия и контроля, связанных с аутсорсингом инфраструктуры, виртуализацией и внедрением облачных технологий. Специальное приложение GAMP «Записи и целостность данных» [05] сфокусировано на проблемах целостности данных, связанных с архитектурой системы: в частности, выделены риски для управления изменениями, аварийного восстановления и управления инцидентами для различных типов облаков – SaaS, IaaS и PaaS.
МЕРЫ ПО ОБЕСПЕЧЕНИЮ ЦЕЛОСТНОСТИ ДАННЫХ
В соответствии с вышеуказанными нормативными ожиданиями, регулируемая компания несет основную ответственность за обеспечение надежности регулируемых данных, создаваемых и поддерживаемых с помощью облачных ИТ-решений. Данное нормативное ожидание должно быть выполнено по средствам процесса валидации компьютеризированных систем, основанного на строгой квалификации поставщика и заранее установленном соглашении об уровне обслуживания, заключен-ном с поставщиком. Они являются критическими факторами, которые необходимо учитывать, и должны быть ориентированы на снижение рисков для целостности данных, возникающих в результате использования облачных решений.
КВАЛИФИКАЦИЯ ПОСТАВЩИКА И СОГЛАШЕНИЕ ОБ УРОВНЕ ОБСЛУЖИВАНИЯ
Квалификация поставщика должна быть ориентирована на оценку мер контроля, применяемых поставщиком для жизненного цикла разработки ПО и для обслуживания регулируемых данных, которыми планируется управлять через облачную систему. Для управляющих записями систем, которые могут оказать непосредственное влияние на безопасность пациентов и качество продукта, рекомендуется провести локальный аудит поставщика; для менее критичных систем (например, управление записями обучения) возможно провести удаленный аудит.
Проверки, подлежащие проведению, должны быть сосредоточены на элементах, таких как:
– Спецификация и тестовая документация, связанная со стандартными функциональными возможностями, предоставляемыми поставщиком;
– Авторизация безопасности и разделение служебных обязанностей;
– Контрольный след и мониторинг журнала событий;
– Механизм контроля доступа;
– Механизм идентификации и аутентификации;
– Операции управления изменениями (включая любые методы выгрузки периодических исправлений), временные рамки и связанное с ними регрессионное тестирование;
– Возможности хранения данных;
– Как поставщик уведомляет регулируемую компанию о проблемах, которые влияют на целостность данных, включая, помимо прочего, технические и хостинговые решения, связанные с ними нарушения безопасности, ошибки в программном обеспечении, проблемы резервного копирования и восстановления и/или выполнение плана аварийного восстановления;
– Квалификация инфраструктуры или эквивалентные меры контроля (также в тех случаях, когда инфраструктура управляется третьей стороной);– Управление поставщиками и соответствующие соглашения об уровне обслуживания;
– Меры контроля для обеспечения кибербезопасности;
– Наличие доступных сертификатов (например, SSAE 16, ISO 27001, SOC 1/2FedRAMP, HITRUST), которые могут помочь продемонстрировать соответствие передовым ИТ-практикам.
В случае, если одна или несколько существующих мер контроля признаны неадекватными, результирующие воздействия на процесс валидации должны быть должным образом оценены, и поставщик должен принять меры по смягчению выявленных результатов с помощью плана корректирующих действий. Процессы, находящиеся под ответственностью поставщика и необходимые для обеспечения целостности регулируемых данных, должны быть установлены в заранее утвержден-ном соглашении об уровне обслуживания, которое отражено в договорных обязательствах с поставщиком, включая штрафы за любое несоответствие.Эти процессы могут быть определены в специальном разделе документа с требованиями пользователя, который должен соответствовать соглашению об уровне обслуживания, касающемся следующих факторов:
– Управление и уведомление о любых изменениях, которые могут повлиять на предполагаемое использование вычислительной среды и связанных с ними сроков, включая обязательство обеспечить адекватное регрессионное тестирование;
– Системные среды, доступные для выполнения любых тестовых операций;
– Управление инцидентами и уведомление фармацевтической компании о проблемах, влияющих на целостность данных;
– Ведение валидационной документации под ответственность поставщика;
– Меры безопасности, реализуемые поставщиком;
– Операции резервного копирования и восстановления;
– Планирование аварийного восстановления, тестирование и требования к уведомлениям;– Соглашение о технической поддержке, определяющее временные ограничения для обработки запросов об инцидентах и изменениях;
– Соглашения о конфиденциальности;
– Право на аудит системы, ИТ-инфраструктуры и данных;
– Субподрядные ограничения
– Соглашения об условном депонировании.
Процесс валидации должен быть разработан в соответствии с общими директивами, изложенными в руководящих принципах (GAMP5 [08], PIC/S [09]) и адаптирован к конкретным рискам, связанным с моделью облачного сервиса, планируемого к использованию.
ЖИЗНЕННЫЙ ЦИКЛ ВАЛИДАЦИИ SAAS
Жизненный цикл валидации должен быть выполнен таким образом, чтобы компьютеризированная система была надлежащим образом испытана/ валидирована с помощью следующих конкретных мер:
– Оценка поставщика выполняется на площадке, до определения стратегии по валидации в соответствующем плане валидации.
– План валидации учитывает итоги этапа оценки поставщика и риски, возникающие в результате отклонений, обнаруженных в ходе аудита.
– Валидационная документация использует документацию по квалификации монтажа (IQ) и квалификацию функциональности (OQ), предоставленную поставщиком, в случае, если эти документы признаны компетентными в ходе оценки поставщика, в случае, если поставщик не имеет компетентной и отслеживаемой документации для квалификации функциональности проверка должна выполняться регулируемой компанией.– Необходимые вспомогательные процессы (например, управление изменениями, управление инцидентами) решаются с помощью специализированных процедур, согласованных с практиками поставщика.
– На этапе тестирования проверки конфигурации (также называемой квалификацией монтажа) проверяется действующий статус соглашения об уровне обслуживания (т. е. проверки того, что утвержденный SLA имеется) и необходимых вспомогательных процедур.– Проверка функциональности (также называемая квалификацией функциональности) ограничена теми функциональными возможностями, на которые сильно влияет конкретная конфигурация и настраиваемыми компонентами (например, интерфейсами с внешними системами).
– Фаза проверки требований (также называемая квалификацией эксплуатации – PQ или тестом приемлемости пользователя – UAT) выполняется регулируемой компанией, проверяющей использование системы по назначению (на основе соответствующих спецификаций требований пользователя) во всех предполагаемых рабочих диапазонах. Типичная взаимная ответственность (которая должна быть подтверждена в соглашении об уровне обслуживания) приведена в следующей Таблице 1.
В соответствии с классификацией системы, определенной руководством GAMP5 [08], для облачных приложений должны рассматриваться только категории 4 и 5 по GAMP. С точки зрения регулируемой организации, конфигурация облачных приложений должна рассматриваться как категория 4, в то время как любая пользовательская разработка для значимых GxP интерфейсов или источника данных, который взаимодействует с облачным приложением, должна рассматриваться как категория 5 и протестирована соответствующим образом.
В процессе валидации SaaS (рис. 2) фаза тестирования является ключевой, поскольку она обеспечивает доказательство того, что предполагаемое использование, определенное регулируемой компанией, выполнено; оно должно быть сосредоточено на следующих мероприятиях:
– Тестирование поставщиком стандартного пакета предоставляется при условии, что он предварительно был оценен как приемлемый для фармацевтической компании.
– Валидационное тестирование регулируемой компании – дополнительные мероприятия по тестированию, которые в основном сосредоточены на конкретном предполагаемом использовании компании, с учетом индивидуальных конфигурациях и/или настройках компании.
– Поскольку данные (в электронном виде) размещаются в сторон-ней компьютерной среде, должны быть приняты дополнительные меры безопасности для облачной системы, такие как шифрование данных и использование соответствующих стандартов электронной подписи для обеспечения подлинности, целостности и конфиденциальности записей. Это означает, что данные должны быть зашифрованы при передаче (например, с использованием зашифрованного/защищен-ного соединения, такого как VPN) и в состоянии покоя (например, через зашифрованную базу данных), и что функции утверждения должны обеспечивать идентичность подписывающих сторон (с использованием цифровых подписей, механизмов хеширования для обеспечения соблюдения неизменности записей, заверенных электронной подписью).– План тестирования системы SaaS должен включать раздел о регрессионном тестировании: все GxP критические или бизнес-критические процессы должны учитываться при регрессионном тестировании. – Регрессионные тесты должны выполняться поставщиком SaaS для каждой новой версии, в соответст-вии с заранее определенной оценкой воздействия. После завершения фазы тестирования система может быть запущена для ее успешного использования: выполнение регулируемых процессов через SaaS требует более высокого уровня мониторинга по сравнению с традиционными системами, проверки эффективности процедур и рабочих инструкций, установленных для поддержания валидированного статуса системы.
ЖИЗНЕННЫЙ ЦИКЛ ВАЛИДАЦИИ ДЛЯ СИСТЕМ, ВКЛЮЧАЮЩИХ IAAS ИЛИ PAAS
В случае, если планируется внедрить систему на основе облачной инфраструктуры (IaaS) или платформы (PaaS), традиционный процесс валидации должен включать меры контроля, ориентированные на обеспечение надежности и мониторинга инфраструктуры ИТ.
Требования для подробной оценки поставщика (включая проверку управления конфигурацией и контр-оля изменений компонентов инфраструктуры) и заранее определенного уровня обслуживания применяются также в этом случае и должны быть сосредоточены на ИТ-компонентах, находящихся под управлением и ответственностью поставщика.
В соответствии со следующей диаграммой (рис.3), все результаты валидации должны быть созданы регулируемой компанией, за исключением квалификационной документации базовых компонентов ИТ-инфраструктуры, которые должны предоставляться поставщиком:
Документация поставщика должна гарантировать, что ИТ-компоненты находятся под надлежащим контролем в случае IaaS (серверы, сеть, питание и охлаждение) и PaaS (база данных, промежуточное ПО, ОС и компоненты инфраструктуры): эти документы должны использоваться регулируемой компанией и упоминаться в пакете документации по валидации системы.
ЗАКЛЮЧЕНИЕ
Облачные решения, с точки зрения технологий, в настоящее время являются развитыми, обеспечивая преимущество снижения затрат, безопасности и динамического расширения возможностей. Производители фармацевтической продукции и медицинских изделий могут принять данные услуги при условии соблюдения ожиданий соответствия, недавно установленных большинством регулирующих органов. Для выполнения данной задачи регулируемые компании не должны принимать решения вслепую: поставщики решений на основе облака должны выбираться посредством эффективного процесса отбора, включая надлежащую оценку меры контроля, применяемой поставщиком до начала предоставления услуг. Ожидается, что такого рода мера, встроенная в процесс валидации, обеспечит целостность GxP данных, созданных и поддерживаемых регулируемыми компаниями с помощью облачных решений.
Контакты:
Адрес: 127015, Москва, ул. Новодмитровская 2к2 БЦ Савёловский Сити, башня Davis
Телефон: +7 (495) 133 98 36
E-mail: ru.info@pqegroup.ru
Web: www.pqegroup.ru
