Национальный Фармацевтический журнал

ВОПРОСЫ ОБЕСПЕЧЕНИЯ GMP-СООТВЕТСТВИЯ СИСТЕМ МОНИТОРИНГА ДВИЖЕНИЯ ЛЕКАРСТВЕННЫХ ПРЕПАРАТОВ

ВОПРОСЫ ОБЕСПЕЧЕНИЯ  GMP-СООТВЕТСТВИЯ СИСТЕМ МОНИТОРИНГА ДВИЖЕНИЯ ЛЕКАРСТВЕННЫХ ПРЕПАРАТОВ

ЧАСТЬ 1. РЕАЛИЗАЦИЯ РИСК-ОРИЕНТИРОВАННОГО ПОДХОДА


АВТОРЫ: Т.М. ВЯЗЬМИНА2, И.В. ФАЛЬКОВСКИЙ1,  В.В. НЕМИТКИНА2, В.И. ВАСИЛЬЕВ2, С.В. ОРЛОВ1.


1ФБУ «ГИЛС и НП» Минпромторга России
2Группа компаний «Р-Фарм»

Уже совсем скоро маркировка лекарственных препаратов контрольными идентификационными знаками с целью обеспечения прослеживаемости всей цепочки перемещений лекарственных средств от производителя до конечного потребителя станет обязательным условием обращения всех лекарств на российском рынке. Для реализации такой амбициозной цели необходима действующая многоуровневая система Track&Trace, включающая как федеральную государственную информационную систему мониторинга движения лекарственных препаратов, так и компьютеризированные системы субъектов фармацевтического рынка, непосредственно обеспечивающих оборот лекарственных препаратов [1–6]. В целях оказания производителям лекарственных средств информационной поддержки в вопросах квалификации оборудования и валидации систем маркировки, мы провели глубинное интервью с экспертами, согласившимися поделиться своим опытом, знаниями и мнением о главных аспектах жизненного цикла систем Track&Trace.

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

В процессе эксперимента система T&T неоднократно изменялась как структурно, так и организационно. Изменялись требования к наносимым средствам идентификации и способы передачи информации между системами производителя и государства. Упрощенно систему Track&Trace можно представить в виде схемы на рис. 1.


Рис 1. Схема функционирования Track&Trace. 

Синим цветом выделены элементы системы, принадлежащие производителям ЛС, оранжевым – элементы централизации.
Регистратор эмиссии (РЭ) – устройство автоматизированной Системы криптографической защиты кодов маркировки (СКЗКМ), предназначенное для заказа кодов маркировки и регистрации сведений о выпуске маркированных товаров.
Регистратор выбытия (РВ) – предназначен для отправки в национальную систему МДЛП информации о выводе лекарственных препаратов из оборота при отпуске по льготным рецептам со 100% льготой (без оплаты получателем) и при отпуске ЛП в медицинских организациях для оказания медицинской помощи.
СУЗ – станция управления заказами кодов маркировки.
КИЗ – контрольный идентификационный знак.
ERP (enterprise resource planning) – система планирования ресурсов предприятия
WMS (warehouse management system) – система управления складом
Уровни системы Т&T:
L1 – технологическое оборудование нижнего уровня, такое как принтеры, сканеры, камеры машинного зрения.
L2 – ПО (программное обеспечение) управления линией;
L3 – ПО управления процессами сериализации и агрегации;
L4 – корпоративные системы управления и контроля процессами маркировки, реализованные как отдельные КС или как отдельные модули ERP/WMS.
L5 – государственная система мониторинга движения лекарственных препаратов (МДЛП)

В данной статье обсуждается реализация риск-ориентированного подхода к обеспечению GMP-соответствия компьютеризированной системы (КС) на различных уровнях Т&T, находящихся в зоне ответственности субъектов фармацевтического рынка [7]. Согласно Проекту ФБУ «ГИЛС и НП» [8], КС считается состоящей из всего аппаратного обеспечения прошивки (микропрограммного обеспечения), установленных устройств и программного обеспечения, а также включает все другие субъекты, которые могут повлиять на GMP-критичные процессы, выполняемые системой, такие как связанные инструменты, IT-инфраструктуру, персонал.

Можно рассматривать всю совокупность элементов Т&T предприятия как единый аппаратно-программный комплекс, проходящий единовременную валидацию в рамках одного протокола. Однако на практике более приемлемым является подход с валидацией/квалификацией данных элементов по отдельности. Таким образом можно обеспечить гибкость и оптимизацию затрат при внесении изменений и последующей ревалидации.

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

Техническое задание, помимо специфичных бизнес-требований площадки, должно содержать перечень применимых требований нормативной документации по маркировке [1–6]. Хорошей практикой является прямое включение в ТЗ или URS требований GMP [7], в особенности приведенных в Приложении № 11, например, в виде следующего перечня:

  1. При наличии электронного обмена данными с другими системами, должны быть включены соответствующие встроенные средства контроля правильного и безопасного ввода и обработки данных с целью минимизации рисков.
  2. Для критических данных, вводимых вручную, необходимо предусмотреть дополнительный контроль точности ввода данных.
  3. Данные должны быть защищены от повреждений как физическими, так и электронными мерами. Сохраненные данные должны проверяться на доступность, читаемость и точность. Доступ к данным должен быть обеспечен на протяжении всего периода их хранения.
  4. Необходимо выполнять регулярное резервное копирование всех необходимых данных. Сохранность и точность резервных копий, а также возможность восстановления данных должны быть проверены в процессе валидации и периодически контролироваться.
  5. Необходимо иметь возможность получения четких печатных копий данных, хранящихся в электронном виде.
  6. Для записей, сопровождающих разрешение на выпуск серии, должна быть предусмотрена возможность получения распечаток, указывающих изменялись ли какие-либо данные с момента их первоначального ввода.
  7. Должна быть предусмотрена возможность создания записей всех существенных изменений и удалений, связанных с областью действия настоящих Правил (система, создающая «контрольные следы»), базирующаяся на оценке рисков. Записи должны содержать атрибуты даты и времени, идентификацию инициатора изменения/удаления, старую и новую информацию и, если применимо, причину изменения или удаления.
  8. Любые изменения в компьютеризированной системе, включая конфигурацию системы, должны проводиться только контролируемым способом в соответствии с установленной процедурой.
  9. Для обеспечения доступа к компьютеризированной системе только лицам, имеющим на это право, необходимо использовать физические и (или) логические элементы контроля.
  10. Создание, изменение и аннулирование прав доступа должно быть зарегистрировано.
  11. С целью обеспечения работоспособности компьютеризированных систем, сопровождающих критические процессы, необходимо принять меры предосторожности для гарантии непрерывности поддержки этих процессов в случае выхода системы из строя (например, с использованием ручной или альтернативной системы).

Рекомендуется также включать требования по целостности данных согласно методологии ALCOA+, которые распространяются и на бумажные и на электронные данные [8–12]:

  1. Соотносимость записей (прослеживаемость до конкретного физического лица);
  2. Постоянство и читаемость записей;
  3. Своевременность регистрации записей;
  4. Поддержание оригинальности записей;
  5. Точность записей;
  6. Полнота;
  7. Последовательность;
  8. Устойчивость;
  9. Доступность данных.

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

На основе ТЗ/URS поставщик проектирует КС и предоставляет заказчику проектную документацию. Рекомендуется включать в договор на поставку системы прямые требования по оформлению документации согласно GAMP5 [13], а именно в составе следующих документов:

  • Функциональная спецификация (FS), содержащая описание функций КС;
  • Техническая спецификация (DS), содержащая описание системной архитектуры, программных и аппаратных компонент;
  • Конфигурационная спецификация (CS), содержащая описание конфигурационных параметров, в том числе матрицу распределения ролей и полномочий.

Хорошей практикой является предоставление поставщиком КС матрицы прослеживаемости (tracebility matrix –  TM), содержащей сопоставление требований пользователя и фактически реализованного функционала.

Для реализации риск-ориентированного подхода и определения глубины и охвата валидационных действий необходимо оценить каждый из элементов системы T&T. Оценку целесообразно проводить в несколько этапов, отражающих многоуровневость структуры КС.

На первом этапе проводится оценка критичности КС в целом. Это необходимо для обоснованного выделения отдельных КС предприятия, влияющих на принятие решений и качество продукции [8]. Для элементов системы T&T критичность обусловлена управлением информацией для маркировки ЛП.

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

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

Рассмотрим основные риски, связанные с системами Track&Trace:

  • Риски на этапе проектирования, связанные с полнотой проекта и точностью учета регуляторных требований.

Например, периодически встречается предоставление поставщиком в качестве проектной документации только пользовательских инструкций. Отсутствие спецификаций (FS, DS) не позволяет корректно провести анализ рисков функций и валидацию. Также поставщики ввиду небольшого опыта ведения проектов для фармацевтической промышленности предлагают «формальную» реализацию регуляторных требований, не обеспечивающую требуемый уровень качества. Например, в качестве журнала контрольных следов (audit trail) предлагается текстовый файл, который может быть отредактирован обычным пользователем в обход системы.

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

Часто встречается несоответствие между фактическими и заявленными параметрами аппаратных компонент или различие между номером версии, отображаемым в интерфейсе системы и указанном в сопроводительной документации. Для уровней L1, L2 критически важным является качество установки механических исполнительных устройств.

  • Риски некорректного ввода критических данных, связанные, как правило, с отсутствием в системе функций контроля точности ввода посредством проверки вторым оператором или логическими ограничениями в ПО.

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

  • Риски целостности данных.

Основные риски для целостности данных связаны с доступом к данным и с неизменностью данных при передаче. К первой группе рисков относятся отсутствие ограничения доступа к данным и возможность несанкционированного доступа к данным, некорректное распределение ролей и полномочий в системе, а также отсутствие контроля действий пользователя при работе с критичными данными. Стоит учитывать и риски полной потери критических данных из-за отсутствия, непригодности или неполноты их резервных копий. Ко второй группе рисков целостности данных относится искажение или потеря данных при изменении формата или передаче из одной системы в другую. Эти риски в равной степени характерны как для передачи данных между внутренними системами производителя ЛП, например, между уровнями L3 и L4, так и для обмена данными между системой производителя ЛП и МДЛП.

  • Риски ошибок при выполнении этапов маркировки.

Системы с одинаковым способом нанесения маркировки могут кардинально отличаться друг от друга на уровнях L2-L4 по структуре, масштабу, архитектуре и степени автоматизации. Соответственно и риски, связанные с функционированием таких систем, будут сильно отличаться. Базово можно определить лишь общие риски, связанные с целевым назначением отдельных элементов системы.

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

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

Ключевой особенностью валидации систем T&T, очевидно, является подтверждение корректного обмена данными между уровнями L3 и L4 производителя с оборудованием сериализации, агрегации, и, что особенно важно, с системой МДЛП.

Отдельные риски систем L3, L4 предприятий связаны с тем, что в независимости от конфигурации уровней все они являются открытыми системами, то есть передают и получают данные из сторонней системы, которой в данном случае является ФГИС МДЛП. Эти риски заключаются в том, что некорректная информация и системные сбои МДЛП вероятно скажутся на работе локальных систем предприятия и общем качестве работы системы T&T. Обмен критичной информацией с системой МДЛП особо остро ставит вопрос разграничения ответственности при валидации и обслуживании системы предприятий. Данный аспект довольно важен и требует глубокой проработки со стороны оператора системы МДЛП и субъектов фармацевтического рынка при контроле и поддержке регулятора.

В целях оказания производителям ЛС информационной поддержки в вопросах квалификации оборудования и валидации систем маркировки, ФБУ «ГИЛС и НП» совместно со специалистами АО «Р-Фарм» планирует подготовить публикации, в которых будут рассмотрены такие аспекты жизненного цикла систем T&T как:

  • Квалификация технологического оборудования уровней L1, L2;
  • Валидация программного обеспечения уровней L3, L4.
Мнение экспертов может не совпадать с официальной позицией ФБУ «ГИЛС и НП» Минпромторга России.

СКАЧАТЬ СТАТЬЮ PDF


СПИСОК ЛИТЕРАТУРЫ:
  1. Федеральный закон «Об обращении лекарственных средств» от 12.04.2010 N 61-ФЗ;
  2. Постановление Правительства РФ от 14 декабря 2018 г. N 1556 «Об утверждении Положения о системе мониторинга движения лекарственных препаратов для медицинского применения» (совместно с изменениями Постановления Правительства РФ от 30 августа 2019 г. N 1118);
  3. Постановление Правительства РФ от 14 декабря 2018 г. N 1557 «Об особенностях внедрения системы мониторинга движения лекарственных препаратов для медицинского применения»;
  4. Постановление Правительства РФ от 14 декабря 2018 г. N 1558 “Об утверждении Правил размещения общедоступной информации, содержащейся в системе мониторинга движения лекарственных препаратов для медицинского применения, в информационно-телекоммуникационной сети «Интернет» (в том числе в форме открытых данных);
  5. ГОСТ Р ИСО/МЭК 15415–2012. Информационные технологии. Технологии автоматической идентификации и сбора данных. Спецификация испытаний символов штрихового кода для оценки качества печати. Двумерные символы.
  6. Рекомендации для участников Эксперимента по маркировке средствами идентификации и мониторингу за оборотом отдельных видов лекарственных препаратов для медицинского применения от «02» октября 2019 года
  7. Приказ Минпромторга России от 14.06.2013 N 916 (ред. 18.12.2015) «Об утверждении Правил надлежащей производственной практики» (Зарегистрировано в Минюсте России 10.09.2013 N 29938);
  8. Проект руководства ФБУ «ГИЛС и НП» «Целостность данных и валидация компьютеризированных систем»;
  9. Руководство PIC/S «Руководство PIC/S по надлежащей практике для компьютеризированных систем в регулируемых GxP средах» (сентябрь 2007 года);
  10. Руководство ВОЗ по надлежащей практике управления данными и записями (Приложение № 5 к Серии технических докладов ВОЗ № 996);
  11. Руководство ЕМА «Целостность данных» от августа 2016 года (в вопросно-ответной форме);
  12. Проект Руководства PIC/S «Надлежащая практика по управлению данными и целостности данных в регулируемых по GMP/GDP средах» (проект 3 от 30 ноября 2018 года);
  13. ISPE GAMP5 A Risk-Based Approach to Compliant GxP Computerized Systems