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

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

Регуляторные особенности IT в фарме

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

Для того чтобы понять, для чего необходимо валидировать системы в фармпроизводстве, обратимся к истории регуляции, а именно к тому, каким образом в индустрии появились понятия «автоматизированное производство» и «валидация»:

  • 1968 — Medicines Act (Orange Book), GMP, UK. Первое появление термина GMP — Good Manufacturing Practice, или, если по‑русски, Надлежащая производственная практика.

  • 1978 — WHO, Международная программа по взаимодействию в области фармаконадзора, Центр мониторинга в Уппсале.

  • 1990 — основана ICH (The International Council for Harmonisation), гайдлайны ICH находятся в открытом доступе, например, гайдлайны по качеству, которые относятся к GMP.

  • 1991 — основание GAMP, первый гайдлайн опубликован в 1994, является частью ISPE с 2000 года. GAMP — Good Automated Manufacturing Practice — (Надлежащая практика автоматизированного производства) в текущей версии (5-е издание, 2-я ревизия) описывает подход, требования и методологию для валидации компьютеризированных систем. В версии 5.2 упор делается на Agile‑методологии и использование итеративных методик разработки и тестирования для обеспечения соответствия требованиям компьютеризированных систем.

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

Стандарты GxP

GxP (Good x Practice) — свод нормативных правил, которые знакомы всем, кто работает на фармпроизводстве. Их на самом деле достаточно большое количество, самый распространенный, пожалуй, это GMP — Good Manufacturing Practice, Надлежащая производственная практика, которая описывает требования к оборудованию, помещениям, процессам, и даже требования к квалификации и постоянному обучению персонала на производственных площадках. Есть еще GLP — это требования для лабораторий с аналогичным составом. GCP — Good Clinical Practice — Надлежащая клиническая практика, клинические исследования. GDP — Good Delivery Practice — Надлежащая дистрибьюторская практика, требования к цепи поставок, способам доставки и хранения лекарственных препаратов, и ими список не ограничивается.

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

Так что же такое валидация?

Если отвечать предельно просто, валидация — это процесс сбора требований и тестирования для обеспечения соответствия требованиям пользователя, регулятора и требований в области целостности данных. Вообще, на целостность данных в фармацевтическом производстве делается особый упор. Коллеги, которые занимаются информационной безопасностью, могут вспомнить триаду CIA: Confidentiality, Integrity, Availability — и будут правы, так как принцип целостности данных идет из требований к безопасности систем. Процессы резервного копирования и восстановления, контрольный/аудиторский след, процессы авторизации в системах — все это в том числе проверяется на валидации.

Что же такое компьютеризированная система? Это комплекс, который представляет из себя управляющее ПО, функции этого ПО, связанное оборудование и процессы. Тут стоит отметить: если ПО не функционирует без оборудования (например, является частью производственного оборудования или не имеет возможности локальной установки в виде пользовательского приложения), то по классификации GAMP такое ПО не является компьютеризированной системой и проверяется как часть оборудования (как правило, в процессе квалификации оборудования).

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

Собрались мы, например, валидировать версию SCADA‑системы. Для себя в компании мы условно разделили процесс валидации на три стадии:
1) Планирование и сбор требований;
2) Подготовка к тестированию и тестирование;
3) Отчет о тестировании.

То есть, если мы запланировали валидацию для определенной версии SCADA‑системы, пакет документов должен иметь соответствующие кодировки по СМК (привет, ISO 9001) и быть прослеживаемым от начала и до конца процесса.

Сбор требований, как пользовательских, так и функциональных, в нашем случае разделен на два документа — URS (Спецификация пользовательских требований) и FS (Функциональная спецификация), тот же подход можно найти в GAMP 5.2. Дальше нам нужно оценить риски этих требований, и тут важно упомянуть название основополагающего документа GAMP —  A Risk-Based Approach to Compliant GxP Compliant GxP Computerized System — Риск-ориентированный подход к компьютеризированным системам, соответствующим требованиям GxP. Для того чтобы правильно протестировать систему на валидации, нам необходимо оценить риски, которые связаны с тем или иным требованием, и закрыть такие риски комплексом предупреждающих мероприятий, например тестирование, написание пользовательских инструкций и/или процедур, обучение пользователей системы и так далее.

Когда требования собраны, риски оценены и тестирование запланировано, логично перейти к самому тестированию. В валидации есть три этапа тестирования:

  • IQ — Installation Qualification – Квалификация монтажа. Первый этап тестирования, на котором проверяется установка системы на необходимое окружение (тестовое, валидационное или продуктивное).

  • OQ — Operation Qualification — Квалификация функционирования. На этом этапе проверяются функциональные требования к системе, по одному функциональному требованию на один тест.

  • PQ — Performance Qualification — Квалификация эксплуатации. На данном этапе проверяется готовность системы к тому, чтобы отдать ее пользователям, например, оконечные процессы (end-to-end-тестирование) в реальных условиях, наличие инструкций/СОПов (без этого нельзя отдавать систему пользователям в GxP-окружении, привет, ISO 9001 и GAMP), а также дополнительное тестирование на соответствие регуляторным требованиям, если применимо.

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

Для чего это делается?

Тут я позволю себе воспользоваться нейросетевой поддержкой и процитирую ответ от ChatGPT:

Валидация систем в GxP-контуре (Good Practice, включает Good Manufacturing Practice, Good Clinical Practice, Good Laboratory Practice и другие) имеет ряд причин, связанных с обеспечением надежности, контроля и соответствия стандартам качества и безопасности.

Основные причины проведения валидации систем в GxP-контуре:

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

2. Соответствие регулирующим требованиям. Валидация систем является обязательным требованием для соответствия регуляторным стандартам. Это позволяет доказать контролирующим органам, что компания отвечает всем законодательным требованиям, а также обеспечивает целостность и надежность данных.

3. Снижение риска и потерь. Валидация позволяет выявить и устранить потенциальные технические, процессуальные и системные проблемы еще до их возникновения, что минимизирует возможные риски и предотвращает потери.

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

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

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

7. Укрепление доверия пациентов. Валидированные системы предприятий позволяют гарантировать высокое качество и безопасность продукции, что укрепляет доверие пациентов к предприятию и его продукции.

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

Cтатью для вас готовил Дмитрий Бережков, руководитель команды валидации обособленных решений. О развитии направления валидации, так называемых "best practice" и новых подходах к валидации компьютеризированных систем, поговорим в следующей статье.

Больше о проектах BIOCAD в нашем блоге на Habr:

Комментарии (1)


  1. novamitrey
    23.06.2023 06:59

    Можно упростить:)

    Компьютеризированная система — это не только комп (аппаратная часть) и ПО, но и приборы управляемые ПО и пользователи «нажимающие кнопочки». И надо бы потестить, что «нужный человек, нажимая на нужную кнопку, получает ожидаемый отклик от прибора».

    Схема валидации выглядит в целом повторяет обычный жизненный цикл тестирования в IT.

    НО! В отличие от обычного тестирования, есть возможность дебажить юзера методом обучения. Написать инструкцию и императивно постановить «так и никак иначе жать на кнопку».

    Зачем такие сложности?

    Создание лекарств — это многостадийный процесс, который должен контролироваться на всех этапах. В конце этого процесса можно получить лекарство, например, с какой‑нибудь непредусмотренной примесью, потому что у нас баг с отображением показателей приборов. Где для здорового человека все закончится диарей, для пациента, с заведомо сниженным иммунитетом может быть смертельно неприятненько. Но это утрировано. Как правило, из-за многостадийного контроля качества, все бракуется и производитель несёт большие убытки, в случае подобных отказов.

    Что на практике?

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

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

    По этой же самой причине если что-то имеет приставку «фармацевтический», то ценник возрастает в 10х раз. Разработчик гарантирует, что «все уже проверено, вот вам три тома подверждающих бумаг».