Евразийское отделение ISPE. Концепция PHARMA 4.0 ISPE. Новые подходы во второй редакции GAMP 5

Александр Белинский, главный консультант PQE CIS

Василий Васильев, эксперт ISPE ЕАЭС,
руководитель группы валидации компьютеризированных систем АО «Р-Фарм»

Авторы: Александр Белинский, главный консультант PQE CIS

Василий Васильев, эксперт ISPE ЕАЭС,
руководитель группы валидации компьютеризированных систем АО «Р-Фарм»

В июле 2022 г. вышла вторая редакция GAMP5 – сборник основных методических рекомендаций для компьютеризированных систем в фармацевтической отрасли на всех этапах жизненного цикла. Первая редакция документа увидела свет еще в 2008 г., а для методических документов в такой динамической отрасли, как ИТ, 14 лет является неприемлемо большим сроком и приводит к несоответствию между используемыми стеками технологий и методическими рекомендациями по обеспечению регуляторного соответствия.

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

Вторая версия GAMP5 предлагает изменение парадигмы мышления от «проверить систему и сохранить её статической и неизменной как можно дольше» к более динамичному и гибкому подходу, реализуемому в виде поддержания системы в валидном состоянии путем контроля на протяжении всего срока ее эксплуатации. При этом предлагается применение различного вида электронных записей с поддерживаемыми атрибутами целостности данных, что позволяет уменьшить бремя бумажной документации.

Структурные изменения GAMP заключаются в добавлении 6 новых приложений, значительном редактировании 3 приложений и удалению 3 приложений.

Добавленные приложения:

• Приложение D8 – Agile Software Development, в котором рассматривается практика использования Agile в GxP-регулируемом окружении.
• Приложение D9 – Software Tools, где рассматривается риск-ориентированный подход к использованию инструментов, поддерживающих реализацию жизненного цикла компьютеризированных систем.
• Приложение D10 – Distributed Ledger Systems (Blockchain) – рассматривает использование технологий распределенных реестров, в частности блокчейна.
• Приложение D11 – Artificial Intelligence and Machine Learning (AI/ML) – описывает использование искусственного интеллекта и машинного обучения.
• Приложение M 11 – IT Infrastructure – содержит управление ИТ-инфраструктурой. Данное приложение во многом перекликается с ранее опубликованным документом ISPE GAMP Good Practice Guide: IT Infrastructure Control and Compliance
• Приложение M 12 – Critical Thinking, где рассматривается концепция «критического мышления», позволяющая оптимизировать затраты ресурсов на обеспечение качества.
  Измененные приложения:
• Приложение D1 – Specifying Requirements, объединяющее воедино требования к URS и FS
• Приложение D5 – Testing of Computerized Systems, в котором дана достаточно обширная оценка возможностей использования подхода CSA (Computer Software Assurance), равно как и поддержка Agile-методологии со ссылкой на Приложение D8
• Приложение S2 – Electronic Production Records, где актуализированы требования с учетом возможности использования облачных решений и распределенных реестров.
• Содержание удаленных приложений в основном перераспределено между оставшимися приложениями.

Влияние на отрасль обновленного GAMP5 сложно переоценить. В нем даны методические рекомендации по использованию передовых стеков технологий, и это несомненно сыграет свою позитивную роль при их внедрении, использовании и регуляторной проверке. Возможность собирать доказательную информацию о проведении тестирования в альтернативных форматах, а не только в виде скриншотов, позволяет значительно снизить затраты на документирование процесса. Грамотное использование рекомендаций позволит реализовать процесс внедрения новых решений более гибко, без излишнего перерасхода ресурсов, что жизненно важно, учитывая поставленные перед фармацевтической отраслью ЕАЭС задачи.
Следует понимать, что в целом потребуется значительное время для внедрения предложенных рекомендаций, особенно учитывая консервативность фармацевтической отрасли. Также следует ожидать настороженного отношения к отдельным предложениям, например, тенденция к уменьшению бумажного документирования может быть расценена отдельными специалистами, как снижение прослеживаемости действий. Использование для документирования специфических инструментов управления процессом разработки и отсутствие классической бумажной документации в отдельных случаях может усложнить проведение аудитов и инспекций вследствие затрат дополнительного времени на объяснение логики работы приложений и обоснование сохранения целостности данных, хранящихся в них.

Для имплементации рекомендаций второй редакции GAMP5 в фармацевтическую отрасль ЕАЭС понадобится совместная работа всех игроков рынка: поставщиков ИТ-решений, пользователей и регулятора.

Вместе с тем, достаточно весомым аргументом в пользу внедрения современных технологий и подходов является факт обсуждения изменений приложения 1 1 GMP – в момент написания этих строк как раз завершается обсуждение концептуальной статьи PIC/S, посвященной указанному вопросу. Там и встречается описание CSA-подхода и Agile-методологии.
В чём же заключается основная суть этой новизны? Для начала уточним, что Agile-методология – это разработка (включая и тестирование), а CSA-подход – это только тестирование, хотя и тесно сопряженное с разработкой (просто самим фактом вовлечения разработчика). Выработка таких методологий и подходов связана с необходимостью обеспечения непрерывной доработки и обновления (Continuous Integration/Deployment – непрерывная интеграция/развёртывание), что характерно практически для всех современных ИТ-сервисов (ИТ-продуктов). И Agile, и CSA подразумевают ряд активностей до продуктивной эксплуатации программного обеспечения, реализующих более широкий тестовый охват без обременительного документирования. Удается это сделать за счет реализации ряда тестов без детального описания (unscripted testing), что допустимо для функций со средним и низким риском для качества и безопасности уже применительно к фармацевтической отрасли.

Детальнее остановимся на самом концепте CSA (computer software assurance). На самом, деле в рамках руководства GAMP5 во второй редакции подход CSA упоминается не впервые. В приложении D5, посвященном тестированию, идут отсылки к ранее выпущенным руководствам ISPE GAMP Good Practice Guide: Enabling Innovation (2021) и ISPE GAMP RDI Good Practice Guide: Data Integrity by Design (2020). Резюмирующей иллюстрацией является схема на рис. 1 именно в GAMP5:

Рис. 1. Иллюстрация подхода CSA с указанием тестового охвата в зависимости от оценки рисков.

Подчеркивается, что тестовая активность должна начать выполняться на этапе разработки и с широким вовлечением самого разработчика, поскольку он гораздо лучше знает свой собственный продукт и даже безотносительно фармацевтической отрасли обязан протестировать его на пригодность, прежде чем передать на оценку конечному заказчику. Q&A – распространённое понятие и в ИТ-индустрии, и разработчики высокой степени зрелости, как правило, сами предлагают тестовую стратегию, без «понукания» со стороны фармы. При этом выполнить тестирование разработчик может произвольным образом, без необходимости разработки и согласования формального протокола валидации – по сути, в обзорном (exploratory) режиме. Ведь результаты такого тестирования будут лишь входом для дальнейших шагов, включая оценку рисков и описание контрольных мероприятий для обеспечения целостности данных.
Но вернёмся к рис. 1. Детально описанное тестирование (scripted testing) предназначено для функций с высоким риском для качества продукции и безопасности пациентов. Вместе с тем, для функций со средним или низким риском могут быть применены тесты без детального описания (unscripted testing) с различным фокусом. Ниже перечислены варианты тестирования без детального описания.

• Ad-hoc («произвольное тестирование») – общий (недетальный) тип описания тестов без планирования или предварительной документации. Его целью является обнаружение дефектов настолько быстро, насколько это возможно.
• Error guessing («угадывание ошибок») – тестовая техника, предназначенная для выявления предполагаемых и потенциальных дефектов, основываясь на знаниях и экспертизе тестировщика.
• Exploratory testing («обзорное тестирование») основывается на опыте, где тестировщик спонтанно планирует и проводит тесты, исходя из знаний и экспертизы, перед исследованием тестовых областей (включая результаты предыдущих тестов); фиксируется общее поведение системы и типы ошибок или дефектов.
• Day in the life («день из жизни») – реализация обычного рабочего паттерна – дать возможность рядовым пользователям попробовать систему «на вкус», как будто бы она уже в продуктиве, что позволит выявить ошибки, на которые бы не вывело детально описанное тестирование.

Речь не идет о том, что результаты тестирования без детального описания не нужно фиксировать. В руководстве ISPE GAMP RDI Good Practice Guide: Data Integrity by Design даны примеры бланков для некоторых из перечисленных видов тестирования без детального описания. Общим же лейтмотивом является то, что суммарный охват тестирования будет шире и может привести к выявлению ошибок, уязвимостей, сбоев в работе, которые при реализации формального протокола валидации могли бы вообще не попасть в поле рассмотрения.
Если попробовать всё это уложить в традиционную V-модель, то можно сильно потерять в темпе, снизить по итогу и охват и использовать при этом избыточные человеческие и временные ресурсы ради генерации документации. Что в итоге приведет к удорожанию и задержке внедрения и/или к блокировке последующих изменений для компьютеризированных систем, даже если эти изменения оправданы с точки зрения бизнес-логики и здравого смысла. Никто не будет тяготеть реализовать изменения, позволяющие сэкономить 10 000 рублей, если для реализации такого изменения нужно затратить 20 000 рублей.

Конечно, нужно упомянуть и о потенциальных недостатках такого подхода – ведь можно злонамеренно «жонглировать» оценкой рисков, отнеся даже критические функции к среднему или низкому риску, однако именно с этой целью, в т. ч. в новой редакции GAMP5, уделено большое внимание критическому мышлению. Разумеется, что для реализации такого подхода требуются более опытные специалисты предметной области. Однако в рамках приложения М 12, посвященному критическому мышлению, указывается, в частности, что полезным инструментом для обеспечения целостности данных является построение карт бизнес-процессов (business process maps) и диаграмм потоков данных (data flow diagrams). Карты бизнес-процессов позволяют проиллюстрировать деятельность, точки принятия решений и подпроцессы, в то время как развивающие их диаграммы потоков данных идентифицируют создание, обработку, хранение и архивирование данных.

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