Валидация системы температурного мониторинга при перевозке лекарственных средств в соответствии с требованиями GxP. Обеспечение целостности данных

Данная статья вошла в Сборник GDP Review 2. Вопрос систем температурного мониторинга только на первый взгляд кажется простым и хорошо отработанным. Но это если говорить о прямых измерениях по месту, осуществляемых простыми, коммерчески доступными регистраторами. Всё становится гораздо интереснее, если мы переходим в облачные сервисы и рассматриваем перспективу интеграции с системами класса ERP.

Этим шагам “на вырост” и посвящена данная статья. Рассматриваемые примеры ниже – это Legaсy System (т.е. уже существующая система в виде прототипа применительно к фарма), но при этом уже успешно используемая в других отраслях. Подобных систем на рынке ЕЭАС уже имеется немало, тем не менее, далеко не все они могут пройти сквозь “эшелонированную оборону” GxP-требований “без потерь”. В статье оценивается своего рода порог вхождения подобного класса систем в GxP-отрасль. Разумеется, можно приобрести готовые решения калибра Elpro, Testo Saveris Pharma CFR, Vaisala, но в странах ЕАЭС это пока больше диковинка, слабо коррелирующая с возвратом инвестиций (ROI = return in investment). Или?… Возврат инвестиций более вероятен при использовании давно отработанных зарубежных брендов сразу? Или целесообразнее просто печатать бумажные чеки пост-фактум? Эти вопросы пока открыты. Впрочем, данная статья только создаст бэкгрануд для решения подобных вопросов. Сделает итоговые управленческие решения более информированными, а не интуитивными.

Транспортировка лекарственных средств является наиболее уязвимым звеном цепи поставок в плане поддержания температурных условий. Разумеется, что находясь на стационарном складе (в зонах обычного хранения, в холодильных или морозильных камерах) риски выхода за специфицированные условия хранения ниже, чем при транспортировке и сопровождающих последнюю операциях погрузки/разгрузки. Ведь в стационарном складе с обычными условиями хранения по температуре (15-25 °С) и влажности (30-60 % ОВ или до 60-65 % ОВ), как правило, для поддержания требуемых значений температуры и влажности используются приточно-вытяжные системы вентиляции и кондиционирования с изрядным процентом рециркуляции воздуха, как правило, 80-90 %. Это резонно, ведь всякий раз осуществлять подготовку (подгорев/охлаждения и осушение/увлажнение) всего объема подаваемого воздуха – нерационально с инженерно-экономической точки зрения. Таким образом, достигается не только эффективная эксплуатация, но и достаточно большая надежность. Это связано с тем, что даже если внешние погодные условия не вполне благоприятны (сильный мороз зимой или проливные дожди летом), то относительно небольшой процент свежего подаваемого воздуха «растворяется» в большом количестве воздуха рециркуляционного, который уже имеет характеристики в рамках специфицированных пределов. Разумеется, всё это достижимо, если системы подготовки воздуха имеют правильный дизайн [1] – снабжены последовательно регистрами первого подогрева, охлаждения, второго подогрева (доступного круглый год) и увлажнения. Воздуховоды, а также расположение притоков и вытяжек  обеспечивают эффективное перемешивание воздуха во всем объеме хранения. Кратности воздухообмена 3-5 час-1 хватит для того, что снивелировать воздействие внешних условий. Не говоря уже о том, что наружные стены складских комплексов с точки зрения теплопотерь, как правило, надежнее кузовов авторефрижераторов, также ATP-релевантных. Особенно, «экранированные» офисным блоком и/или зонами комплектации загрузки/разгрузки (где продукция не находится длительное время).

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

По транспортным средствам (авторефрижераторам), которые укрупнённо могут быть приравнены к «холодильным камерам на колесах», снабженными холодильно-отопительными установками (ХОУ), о стабильности внешних условий говорить не приходится. Погода за бортом может изменяться в широких пределах, поэтому вопросы выбора транспортных средств, их квалификации, эксплуатации и мониторинга соблюдения температурных условий (влажность при транспортировке не регламентируется) приобретают ключевое значение.

В настоящей статье мы рассмотрим последний из упомянутых аспектов – мониторинг температурных условий транспортировки.

В виду изложенных выше «отягчающих обстоятельств» интуитивно понятно, что спрос на информацию по температуре в кузове транспортного средства (ТС) онлайн становится гораздо более актуальным, чем даже для стационарных помещений хранения (хотя системы мониторинга широко распространены и там). Причина в значительно большей чувствительности к вариабельности внешних условий и, следовательно, в гораздо более высоких рисках выхода за специфицированные диапазоны по температуре. Это означает, что регистрация температуры в кузове ТС, а также своевременное оповещение о достижении уровней предупреждения (которые, как правило, стараются установить с некоторым запасом, до достижения номинальных границ целевых диапазонов) играет очень важную роль. Ведь необходимо не только регистрировать указанные значения и события, но и иметь время на принятие ответных мер в случае нарушений условий транспортировки или если эти условия под угрозой. Например, для режима 2-8 °С или 15-25 °С уровни предупреждения можно настроить на полградуса меньше, чем граничные значения. В указанных примерах это будет диапазоны 2,5-7,5 °С или 15,5-24,5 °С соответственно. Тут догмы нет, но общий принцип очевиден.

Подобных рациональных соображений в повествовательном режиме можно сформулировать немало, но для того, чтобы заполучить исправно работающую и непротиворечивую систему мониторинга, не нужно изобретать велосипед, а по мере проектирования, разработки, внедрения и эксплуатации следовать требованиям GxP в отношении компьютеризированных систем, а также действовать согласно многочисленным руководствам, прежде всего, ISPE GAMP 5 [2].

Сейчас на рынке представлено достаточно большое количество коммерчески доступных систем мониторинга – это решения Testo Saveris Pharma [3], Elpro [4], Vaisala (viewLinc) [5] – это решения от международных признанных лидеров в плане мониторинга параметров микроклимата производств, лабораторий, складских комплексов, холодильных, морозильных и климатических камер, авторефрижераторов.

Все вышеуказанные решения разработаны с учетом всех GxP-релевантных требований. Что следует учесть другим разработчикам, если подобные системы предполагается разработать самостоятельно? Существует ряд требований к компьютеризированным системам, которые однозначно должны быть соблюдены и касаются они прежде всего защиты первичных данных (raw data).

Как правило, отправной точкой для создания подобных систем является наличие уже существующих, бортовых систем – Carrier или ThermoKing (см. пример на рис. 1). По сложившейся практике в GDP-сфере достаточно получить распечатку с подобных бортовых систем для подтверждения соблюдения температурных условий при транспортировке.

Рис. 1. Контроллер и принтер ThermoKing

Что же мы должны учесть при переходе «в цифру»[1], к вышестоящим компьютеризированным системам. Приведём ключевые требования, рекомендации и сформулируем общепринятую отраслевую дорожную карту, если мы хотим заменить бумажные распечатки постфактум, когда уже поздно принимать решения по завершению маршрута, если водитель не отследил или не сумел сориентироваться оперативно на основании текущих показаний (как правило, есть вывод индикации температурных значений непосредственно в кабину, например, Carrier Transicold). К тому же водитель ведь не всегда находится в кабине по ходу маршрута – есть ведь остановки, взаимодействие с контрагентами (вне кабины) и т.п. Кроме того, у водителя в фокусе внимания дорожная обстановка так или иначе в приоритете, кто бы какие СОП не писал в этом отношении. Т.е. если не реализована эффективная система оповещений, очень трудно рассчитывать на 100 % контроль показаний со стороны водителя. Опять-таки, мы приходим к окончательному подтверждению успешности поставки только пост-фактум, путем ручной оценки чека. Ручная оценка – ещё одна рисковая позиция в плане человеческой ошибки.

Если обращение с контроллерами и принтерами (подобными показанным на рис. 1) должно быть охвачено в рамках «обычной» квалификации транспортных средств [7], то внедрение даже самой простой компьютеризированной системы, осуществляющей сбор экспортированных с первичных регистраторов данных тут же ставит ряд вопросов, которые не возникают при использовании простых контроллеров и принтеров по месту. Формально контроллеры тоже представляют собой компьютеризированную систему и имеют прошивку (firmware – бывшая категория 2 по GAMP, от которой отказались в 2008-м в GAMP 5 в виду того, что firmware может быть какой угодно сложности). Но именно в отношении коммерчески доступных простых контроллеров функциональные риски общепризнаны, как низкие. К первичным данным доступа, как правило, нет. Следовательно они не могут быть удалены или модифицированы, хотя может быть их перезапись по петле по истечению времени. Впрочем, на таких контроллерах вполне можно поменять периодичность на распечатках, системную дату и время, но я не сталкивался с ситуациями, чтобы кто-то требовал для подобных простых контроллеров, скажем, управление учетными записями или аудиторский след. Я уже молчу о том, что именно с контроллеров задается уставка по целевой температуре в кузове, а системы мониторинга, как правило, не реализуют такой функции, они принимают данные «пассивно», без обратной связи в плане автоматического регулирования исполнительных устройств. Буду признателен, если коллеги по отрасли меня поправят или дополнят имея в виду именно простые бортовые устройства – как в примерах выше – Carrier или TheromKing – наверное два самых распространённых варианта реализации.

Вместе с тем, как только у нас появляется компьютеризированная система в развитие, т.е. появляются мобильные устройства, десктопное или облачное ПО – появляются новые передаточные звенья, соответственно, возрастают риски и пропорционально ужесточаются регуляторные требования и ожидания отраслевых игроков – участников рынка лекарственных средств. Среди таких требований первоочередными является вопросы того, как передаются данные, обеспечена ли их сохранность в неизменяемом формате, защита от модификации и удаления, как формируются настройки оповещений, кем они квитируются и т.п. Казалось бы, любая компьютеризированная система призвана нам облегчить жизнь и сделать нашу деятельность более надёжной, а не, напротив, существенно её усложнить и заставить сомневаться в каждом шаге передачи данных. Вместе с тем в одной из зарубежных функциональных спецификации мне в своё время удалось обнаружить блестящую фразу относительно отраслевых требований, в частности, речь шла об описании американского нормативного документа 21 CFR Part 11 [10]. Фраза очень ёмкая передающая физический смысл указанного документа одним абзацем:

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

Сам указанный нормативный документ – 21 CFR Part 11 – увидел свет в марте 1997-го и до сих пор актуален в исходной формулировке. Чуть позднее, в 2003-м, появилось руководство для индустрии в отношении применения этого стандарта. Это прямое требование в США, но оно считается надлежащей практике во всем мире. В 2008-м вышла последняя редакция «магистрального» документа, носящего рекомендательный характер – ISPE GAMP 5 [2]. В 2011-м – современная редакция Приложения 11 GMP [9] в отношении компьютеризированных систем. Последний документ – прямая норма в ЕС и ЕАЭС, вобравшая в себя многое из 21 CFR Part 11 в т.ч., хотя и рассматривающая вопрос шире, в комплексе – от разработки до эксплуатации компьютеризированных систем. Это далеко не всё, потому что по указному поводу высказались практически все значимые в фарма ассоциации и организации – WHO (TRS 996 Annex 5), PIC/S, PDA – в данной статье не получится охватиться всё и сделать даже краткий обзор основных руководств – это предмет отдельной статьи. Тем не менее, уже понятно, насколько «под прицелом» аспект компьютеризированных систем. И именно ёмкая фраза выше возвращает нас к главному тезису, почему это так.

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

Теперь представим распространённый кейс – перевод денежных средств с карты на карту или просто оплата через интернет посредством банковских процессинговых центров. Тут уже всё в заметной степени усложняется и виртуализируется. Вам не подойдут ситуации, при которых денежный перевод а) уйдёт не на ту карту/счёт; б) уйдёт не та сумма; в) произойдёт это несвоевременно; г) ваши данные утекут в открытый доступ.

Вот и начинается серия защитных мероприятий. В видимой вам части – это и пароль на (мобильный) интернет-банкинг, и CVV, и двойная аутентификация. Тут в принципе во всю мощь разворачиваются стандарты информационной безопасности – серия ISO 27k. Реализуется и идентификация, и аутентификация, и авторизация. Думаю, для примера достаточно.

Возвращаемся теперь к температурному мониторингу. Благо, с ним ситуация всё же несколько проще, чем с банковскими процессинговыми центрами. Аналогии уместны, но лимитировано. Укажу только, что банки обязаны быть сертифицированы по ISO 27k, а фармкомпании – не обязаны, хотя фаза эксплуатации в Приложении 11 GMP, на мой взгляд, процентов на 70-80 % заимствует содержание стандартов ISO 20k и ISO 27k [11]. Помочь консолидировать эти и другие вопросы при создании GxP-релевантных систем призвана т.н. V-модель – как магистральный маршрут создания компьютеризированных систем для фармацевтической отрасли (см. рис .2).

Рис. 2. V-модель при реализации жизненного цикла вновь разрабатываемой GxP-релевантной компьютеризированной системы

Разумеется, что V-модель (её глубина) может варьировать в зависимости от сложности компьютеризированной системы – различные категории ПО также изложены в руководстве GAMP 5 [2] – но предлагаю пойти от простого к сложному.

Поскольку транспортировка – это прежде всего вотчина GDP [8], то следует первично держать в фокусе именно GDP, где, надо отметить, сформулированы только самые общие требования к компьютеризированным системам. В развитие этих требований следует держать в фокусе Приложение 11 GMP [9], даром что формально это производство лекарственных средств. По моему глубокому убеждению, если занять позицию следования только требованиям GDP, абстрагировавшись от других требований и руководств, компьютеризированную вряд ли удастся не то, что воплотить в жизнь – не удастся даже толком сформулировать требований к ней.

С требований – URS (User requirements specification) – всё начинается. Причём не только в фарма – обычная ИТ-разработка по лучшим практикам также должна начинаться с требований. Причем без них практически исключена вероятность создания непротиворечивой системы даже хотя бы средней сложности – начинаются многочисленные круги и итерации, «чайка-менеджмент» в плане разрозненных требований «по скайпу», «сомнения в чатах» и т.п. Ни один толковый разработчик даже задание на интернет-магазин у вас не должен принять без письменной и согласованной всеми заинтересованными сторонам спецификации требований пользователя или ТЗ. Если это не студент-фрилансер или не просто зрелый специалист/группа специалистов, работающих в режиме «хобби». Фарма последние ситуации прямо исключает – URS фигурирует во всех указанных выше документах в той или иной формулировке. В ISPE GAMP 5 это приложение D1, в Приложении 11 GMP – это п. 4.4. URS должна разрабатываться, прежде всего, будущим владельцем системы. Если так получилось, что система уже начала разрабатываться – URS нужно сделать хотя бы ретроспективно (на что указывает п. 16.6 руководства PIC/S [12] – кстати, попутно отмечу, что само определение «компьютеризированная система» то же руководство ISPE GAMP 5 берёт прямо из PIC/S – вот мой авторский перевод [6] этого определения на русский язык). Почему важно разработать URS, хотя бы ретроспективно? Потому что важно понимать, каким ИТ-активом вы хотите обладать. И, конечно, настоятельно рекомендуется эту URS разработать до самой идеи что-либо реализовывать. Ведь часто доработка продукта, изначально не учитывающего основные требования – очень трудоёмкая и иногда – малоцелесообразная. Ведь разработчики в определенный момент могут прийти к тому, что начать с чистого листа – гораздо проще, чем встраивать в систему дополнительные требования по ходу маршрута.

Так или иначе следующим обязательным документом является ответ на URS – функциональная спецификация (FS, functional specification). Соответственно, она указана в ISPE GAMP 5 Appendix D2, в Приложении 11 GMP – п. 4.3, завуалированная под «актуализированное описание системы». Это собственно ответ разработчика на вопрос, как он собирается реализовывать (или уже реализовал) требования заказчика.

Если компьютеризированная система сложная, то появятся и другие спецификации в развитие (SDS, HDS, DS) – мы пока для простоты изложения не пойдём в дебри. Ведь что важно – система мониторинга параметров микроклимата (в рассматриваемом примере – только температуры) – это относительно простая система – это не WMS, не ERP, не LIMS, не EDMS.

Практика показывает, что толковая URS и её «зеркало» FS – это бОльшая половина успеха в реализации системы.

Все дальнейшие шаги, в т.ч. валидационные – это разработка и по ходу этой самой разработки – документированное подтверждение (через тестирование) того, что WYSIWYG (what you see is what you get). Тестирование уместно не после разработки системы, а именно в процессе той самой разработки. Об этом многие забывают. Это специфика ИТ-решений. На рис. 3 показан примеры онлайн-системы мониторинга, которая широко уже используется в различных отраслях, например, при транспортировке пищевых продуктов и имеет перспективу реализации в сфере GDP. Даже более того, для, собственно, требований GDP на самом деле уже сейчас в указанном примере – AutoGRAPH Web – есть определённый overfunctioning – избыточность функционала. Например, GxP-не требует от нас трек по маршруту – пока мы живём в мире бумажных ТТНок. На данный момент без бумажных ТТНок я не встречал отечественных реализаций, даже если эти ТТНки потом каким-то образом вкладываются в ERP/EDMS системы. Но всё равно трек не является ультимативным требованием. Конечно, на портале ISPE в 2018-м создана SIG (Special interest group), посвященная блокчейну и перспективам его использования, но это только намерения, судить о скорости реализации которых я пока не возьмусь. Но тот же трек визуально удобен. Состояние ХОУ или самого ТС – тоже опция удобная, но не требуемая напрямую с GxP-фланга. Это всё создаёт большее удобство компаниям, эксплуатирующих такую и подобные системы. Позволяет оперативнее реагировать на внештатные ситуации и, в конечном итоге, повысить надёжность самой поставки, минимизировать риски в её отношении в целом.

Рис. 3. Пример облачной системы мониторинга температуры AutoGRAPH Web

Вместе с тем, у фарма есть ряд своих требований, дотянуться до соответствия которым не всегда просто. Один из таких вопросов – это управление учетными записями и неизменяемый аудиторский след. Сам по себе только этот аспект – предмет большой отдельной статьи. Здесь я пока только обозначу интригу. Если вести речь о Приложении 11 (п. 9) GMP, то там говорится в отношении аудиторского следа буквально следующее:

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

В одной из немецких FS (FDS) я столкнулся буквально с такой формулировкой, мол, если первичные данные не могут быть модифицированы или удалены, то аудиторский след не требуется. Оценка рисков в этом случае привела к такому выводу. И действительно – решение, например, Testo Saveris 2 – не содержит аудиторского следа – все данные хранятся в облаке на серверах Amazon. Хотя это решение не позиционируется прямо для фарма, а только для пищевой промышленности и некоторые других, менее рисковых для здравоохранения. Но важно, что также нет аудиторского следа и в самых простых конфигурациях Testo Saveris Pharma (SBE, PROF). И только Testo Saveris Pharma CFR содержит такой аудиторский след. Аналогичная ситуация со швейцарской Elpro Cloud – базовый план, где декларируется соответствие разработки требованиям GAMP 5, содержит усеченный аудиторский след (device event – события по устройствам) и только более дорогостоящие планы – содержат полный аудиторский след. Таких примеров масса – для климаткамер и термостатов Memmert – приложения AtmoControl и AtmoControl FDA edition, для валидации процессов стерилизации – Ellab ValSuite Basic и Ellab ValSuite Pro. Причем в фармацевтической отрасли широко распространены как базовые, так и расширенные конфигурации с аудиторским следом. Его применение может быть обосновано не только в свете п. 9 Приложения 11 GMP, но и новейшего руководства PIC/S [13] и рассматривается всегда во взаимосвязи с остальной ФСК (фармацевтической системой качества). При всей совокупности аргументов «за» и «против» следует согласиться, что отраслевой тренд по мере усложнения систем – это всё же наличие контроля (глубина которого обсуждаема и зависит от конкретной конфигурации), чем его отсутствие. И только для наиболее простых реализаций – например, когда конечный пользователь не может ничего, кроме формирования отчетов по временным фильтрам, а сама система – максимальна простая, без интеграций с ERP и т.п. – может быть обосновано отсутствие аудиторского следа и «бумажный» SDLC (software development lifecycle, жизненный цикл разработки ПО). И то, последнее – «бумажный SDLC» – в наше время – редкость для разработчиков, безотносительно требований фарма. В эпоху GitLab, GitHub, наличия систем бактрекинга – «бумажный» SDLC сам по себе атавизм, не позволяющий вести эффективную разработку и сопровождение своих продуктов, управление их релизами и т.п.

С другой стороны, система может содержать классный аудиторский (контрольный) след. Будут записаны все действия пользователя, кто, когда под какой учетной записью зашёл, что выполнил. Хотя в нашем примере, очевидно, выполнена будет только печать отчетов. Потенциально со стороны администраторов облачного сервиса могут логгироваться шаги по корректировке правил оповещений (напоминаю, простые бортовые системы никаких оповещений вам в офис не вышлют), списка оповещаемых, добавление, редактирование или удаление пользователей системы, если это осуществляется на уровне прикладного ПО. Хотя, например, в Testo Saveris 2 настройки оповещений выполняет конечный пользователь безо всякого аудиторского следа. Оповещение – не является прямым регуляторным требованием! Хотя, конечно, нарушить бизнес-логику может. Прямое требование – запрет непрослеживаемой модификации и удаления критических данных. В данном примере – данных температурного мониторинга, где читается полный и безусловный запрет на модификацию и удаление.

Но, как мне написал один из коллег, занимавшийся, правда, лабораторными компьютеризированными системами. Данные могут храниться в базе и не быть доступными рядовому пользователю и даже супервайзеру системы через интерфейс прикладного ПО, управление учетными записями и аудиторский след реализованы в полной мере. Но запуск банального MS SQL Management Studio открывал базу данных и править там было можно, всё, что угодно напрямую. Естественно, нигде на уровне приложения эти изменения не фиксируются – разве что такое вмешательство могло бы быть определено на уровне логов операционной системы или СУБД.

Второй вид вмешательств – это вмешательство на уровне разработчика – собственно тут уже мы выходим на уровень SDLC – каким образом разработчик сопровождает своё решение, как управляет релизами и т.п. Этим и продиктован аудит поставщика услуг. В примере выше залезать на сервера Amazon будет проблематичнее «сторожу из районного центра». Да даже и менеджеру компании GDP, понимающему, что данные по температуре губят многомилионную поставку и в панике судорожно пытающемуся «спасти ситуацию» путем фальсификации данных в облаке. А вот если поставщик ноунейм, данные хранятся неизвестно где и как, пусть и не доступные рядовому пользователю – тут исследование потенциального конфликта интересов может быть строже. Причем речь даже часто не о регуляторе (и соблюдении прямых регуляторных требований), а о контракторах (кто может сформулировать дополнительные требования в развитие регуляторных). Ведь деньги теряет не регулятор, а контрактор. Точнее, в том числе и он.

Другой вопрос, который не будем развивать в рамках данной статьи, но только обозначим. Мы «под лупой» рассматриваем минорный сегмент – транспортировку, которая составляет доли процента во временном отношении от всего жизненного цикла лекарственных средств (хотя транспортировка и одно из наиболее уязвимых звеньев), но потом выгружаем лекарственные средства в отечественной практике «на крыльцо» лечебно-профилактического учреждения или в аптеки, где нет даже кондиционера. Это не вопрос облачных систем мониторинга, хотя, безусловно, представляет интерес как для регулятора, и уж подавно для контракторов. В их фокусе обязана быть вся холодовая цепь, а не только отдельный её сегмент, даже с учетными записями, аудиторским следом и защитой данных на уровне банковских транзакций и процессинговых центров. Это, кстати, и есть предмет всамделишней оценки рисков по всей холодовой цепи или, говоря шире, цепи поставки.

На рис. 4 а) и б) показаны примеры формируемого отчета из облачной системы – в принципе в аналогичных системах отчеты от системы к системе могут варьировать, могут быть, различные наборы статистики и формы представления данных.

Магистральным маршрутом тестирования такой системы является прямое сличение того, что вы получили на уровне бортовых систем, и что получили в облаке (или на десктопном ПО). Первая и относительно простая миссия – это подтвердить идентичность полученных данных.

А вот вторая и гораздо более ресурсоемкая задача – это доказать то, что данные хранятся надежно, с ними ничего не происходит за время хранения и что эта ситуация воспроизводима в ходе всего жизненного цикла системы.

А) сводная информация по сформированному отчёту

Б) табличные данные по температуре и параметрам работы ХОУ

А) сводная информация по сформированному отчёту
Б) табличные данные по температуре и параметрам работы ХОУ

Рис. 4. Пример отчетов по температуре с облачной системы мониторинга температуры AutoGRAPH Web

По существу, мы подошли к достаточно простому и очевидному резюме, что при создании GxP-релевантных систем, как говорил Чапаев (или это ему приписывают) – договориться нужно на берегу. Чтобы учесть все релевантные GxP-требования, следует внимательнейшим образом отнестись к разработке URS и FS, в идеале – до создания системы и перед выбором конкретного поставщика услуги. Можно и по ходу такого маршрута, но тогда ретроспективно оценив GxP-соответствие рассматриваемых решений и в случае обнаружения gap’ов (как это нонче модно щеголять новоязом – наверное, недословный перевод – рисковых позиций) – провести предпроектное обследование, аудит поставщика услуг, чтобы потом на этапе разработки и тестирования исключить или, по крайней мере, минимизировать «детективные расследования», мол, что случилось с нашими данными. Специально акцентирую ваше внимание – на этапе разработки и тестирования, т.е. до продуктивной эксплуатации. Конечно, и в GxP-деятельности, и в ИТ (ITSM & ISMS = ISO 20k & ISO 27k) существует управление инцидентами. Но инцидент инциденту рознь. В продуктивную эксплуатацию может быть запущена только система, обладающая достаточной доказанной документально надежностью. В части защиты данных, их резервирования, возможности восстановления из резервных копий и т.п. Серьезные инциденты в продуктивной эксплуатации могут просто аннулировать использование и подвесить легитимность всех (!) предшествующих поставок. В противовес, нераспечатанный или потерянный чек с бортовых систем приведёт к потере только одной конкретной поставки.

Примеры – инцидент по задержке передачи данных – в целом допустим – зависит от покрытия сети операторов мобильной связи или Wi-Fi. У того же Testo Saveris выполняется контрольная проверка (недоступная рядовому пользователю) полноты передачи данных с логгеров в облако. А вот инцидент с потерей данных или их искажением в продуктиве недопустим. Вспомните бытовой пример выше с банковскими переводами. И добавьте к этому, в рамках всамделишной оценки рисков, что лекарственные средства – далеко не частный перевод денежных средств. Точнее, не любой такой перевод.

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

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

Сам по себе адаптер-регистратор iQFreeze (см. рис. 5), внесенный в российский реестр средств измерений (№ 67930-17), обеспечивает регистрацию температуры и параметров работы ХОУ с возможностью распечатки через Bluetooth-принтер или экспорта данных в формате csv. В самом адаптере-регистраторе данные сохраняются без возможности доступа к ним. Формат csv, что очевидно, является незащищённым и не может прямо рассматриваться в фарма. Распечатка через Bluetooth-принтер, по сути, уравнивает решение iQFreeze с бортовыми системами Carrier & ThermoKing.

Рис. 5. Общий вид адаптера-регистратора температуры и параметров работы рефрижератора iQFreeze (исполнение СПС)

В сочетании с возможностью передачи данных в облако, что реализуется за счет бортового контроллера GSM / ГЛОНАСС, мы получаем более широкий функционал, реализуемый уже со стороны решения AutoGRAH Web, которое, по сути, является SaaS-решением (Software as a Service). Что это означает – обратимся к формулировке Руководства по целостности данных и валидации компьютеризированных систем ГИЛС и НП [16], п. 9.9.2:

Программное обеспечение как услуга (Software as a Service, SaaS) – регулируемые компании используют приложения, работающие на инфраструктуре, принадлежащей поставщику IT-услуг. Регулируемые компании не управляют и не контролируют базовую инфраструктуру или даже отдельные возможности приложений, за исключением ограниченных пользовательских параметров конфигурации приложений.

В рассматриваемом примере именно такой случай. С точки зрения оценки рисков – SaaS – очень хорошее решение в плане устранения конфликта интересов – вспомните пример выше GDP-менеджера, судорожно «спасающего» ситуацию путём фальсификации отчета. В системе координат SaaS это заметно усложнено, защищено пользовательским соглашением об уровне предоставляемых услуг (SLA = service level agreement) – иными словами владелец облачного сервиса принимает только определенные письменные (!) заявки от конечного пользователя (от конкретных ответственных лиц и по конкретным оговоренным каналам обращения), без предоставления доступа к облачной ИТ-инфраструктуре. Т.е. манипуляции заметно осложнены по сравнению с, опять-таки, вышеописанным примером правки «условной базы на одном пользовательском ПК через MS SQL Management Studio». С другой стороны, мы не знаем, насколько зрелым и ответственным является сам поставщик такой услуги – для этого и существует аудит поставщика, чтобы понять как у него реализована разработка и техническое сопровождение. Аудит может быть нескольких видов: анкетирование (postal audit), дистанционный, очный. Конфликт интересов и тут минимизирован, т.к. самостоятельно поставщик услуги не держит в фокусе конкретную поставку и даже если его манипулятивный манёвр шире (хотя доступа к истинным копиям (true copies) первичных данных (raw data) он точно так же не имеет), он не будет в курсе того, где происходит конкретная отгрузка товаров. А если он всё же будет злонамеренным (мотивационный аспект не рассматриваем) – то он всегда рискует быть пойманным «на горячем» за счет сравнения с Bluetooth-распечаткой по месту. Т.е. любые потенциальные «шаги в сторону» – это только «сговор группы лиц». Это весомый аргумент в рамках оценки рисков в пользу таких решений.

Что пишет об этом Руководство ГИЛС и НП [16]:

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

Если компания-заказчик такой облачной услуги имеет доступ только для просмотра и формирования отчетов, а всё конфигурирование, включая правила оповещений и управление учетными записями пользователей осуществляется на стороне облачного провайдера через письменные официальные запросы – можно расценивать риски, связанные с такой схемой взаимодействия, как низкие. Разумеется, при документированном доказательстве общей работоспособности системы.

Общая схема такого решения выглядит следующем образом (см. рис. 6):

Рис. 6. Общая схема работы iQFreeze и AutoGRAPH Web

Как на практике подтвердить валидность подобного решения? Навскидку может быть предложен следующий набор тестов:

  1. Проверка технической документации
  2. Проверка ИТ-инфраструктуры (в т.ч. облачной, по запросу к поставщику SaaS)
  3. Проверка установленного прикладного ПО
  4. Проверка метрологического статуса измерительных каналов
  5. Проверка наличия и актуальности СОП по эксплуатации системы и её техническому сопровождению (со стороны поставщика SaaS – резервное копирование, управление учетными записями и т.п.)
  6. Проверка функционирования элементов интерфейса системы (замечу, задействованного функционала)
  7. Проверка соблюдения требований целостности данных (доступ, использование электронных подписей, временные отметки, безопасность данных, аудиторский след, формирование отчетов, распечаток, осуществление резервного копирования)
  8. Проверка установленных параметров и конфигурации
  9. Проверка реализации основных сценариев оповещений (если применимо)

Данный перечень на взгляд автора является достаточным, но, безусловно, может быть ситуативно дополнен, модифицирован. Возможно, отраслевые гуру, знакомые с протоколами валидации таких систем, как Vaisala или Ellab в несколько сотен страниц могут удивленно воспринять приведённый выше лаконичный перечень. Вместе с тем, сообщество отраслевых гуру – не монолитно. Есть признанные специалисты, которые не одно десятилетие занимаются вопросами валидации компьютеризированных систем и призывают участников этого процесса не забывать, прежде всего, о том, что основная цель валидации – это доказать соответствие системы её целевому предназначению (fit for intended use) [17]. На мой взгляд, истина, как это часто случается, расположена где-то посередине, на воображаемом пересечении кривых рисков для качества и возврата инвестиций. ROI = return on investment – возврат инвестиций, это термин, который нередко можно встретить по тексту руководств ISPE, поэтому сложившиеся практики отнюдь не игнорируют здравый смысл и целесообразность, соотнося их с рисками для качества.

На что следует обратить внимание при проведении вышеуказанных тестов? Я бы акцентировал фокус именно на соблюдении требований целостности данных. В упомянутом руководстве ГИЛС и НП [16] и, разумеется, в международных источниках, на основании которых это руководство было разработано (ISPE, MHRA, WHO etc.), вводится акроним ALCOA+. Это как раз и есть параметры, обеспечивающие целостность данных. Вот их развёрнутый перечень с лаконичными пояснениями того, что же следует продемонстрировать:

Таблица 1. Параметры целостности данных и их краткая интерпретация

Параметр ALCOA+

Краткая интерпретация

Прослеживаемость

(Attributable)

Кто собрал (ввел) данные или выполнил действие

Читаемость
(Legible)

Можете ли вы прочитать и понять введенные данные

Своевременность
(Contemporaneous)

Были ли записи задокументированы в моменты выполнения действия

Подлинность
(Original)

Являлась ли запись первым наблюдением (или верифицированной, истинной копией)

Точность
(Accurate)

Является ли результат научно значимым и безошибочным

Полнота
(Complete)

Все данные, метаданные, включая повторные испытания или анализы, в наличии

Последовательность
(Consistent)

Все элементы испытаний или анализов имеют временную отметку и выполнены в ожидаемой последовательности

Устойчивость
(Enduring)

Данные записаны в постоянной, поддерживаемой форме (формате) на протяжении всего их жизненного цикла

Доступность
(Available)

Данные доступны для обзора, аудита или инспекции в ходе всего их жизненного цикла

Например, для выполнения первого пункта – прослеживемости – необходимо реализовать доступ по индивидуальным учетным записям и, в зависимости от выполняемых действий, аудиторский след таких действий. Здесь дискуссионный момент – это то, какие действия в системе действительно следует фиксировать. Можно, конечно, огульно декларировать фиксацию всех действий, но это как раз и будет иллюстрировать бездумный и экстенсивный подход согласно [17] – т.н. one-sizes- fits-all – «один размер на все случаи». К тому же это сильно утяжелит систему, выдвинет более мощные требования к ИТ-инфраструктуре и т.п. Например, кто и когда сформировал тот или иной отчет (первичные данные или истинную копию первичных данных, которые пользователь изменить не может) – наверное, вопрос второстепенный. К тому же даже без логгирования можно просто на каждой распечатке вывести её дату, время, при желании – учетную запись сформировавшего – тогда можно принять решение о том, что дополнительно указывать эти данные в аудиторским следе – избыточно. Если же речь идёт о смене пороговых значений по температуре для оповещений – да, наверное, стоит фиксировать такие шаги и фиксировать именно отдельно, вне общего потока (кто вошёл в систему, кто вышел из неё), или хотя бы с возможностью фильтра именно таких событий.

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

А вот точная передача первичных данных – критически важный аспект. Он, как правило, фиксироваться аудиторским следом не будет. Факты фиксации данных, накапливаемых автоматически, не записываются в такие следы – на это есть прямая информация в протоколах валидации той же Vaisala и это можно без труда увидеть в аудиторских следах, формируемых, к примеру Ellab ValSuite Pro. Вместе с тем, если эти данные переданы некорректно – это способно аннулировать все усилия. Для исключения такого риска в ходе тестирования следует, в указанном примере буквально сличить данные, формируемые адаптерами-регистраторами iQFreeze (которые внесены в реестр средств измерений, защищенность первичных данных гарантирована и указана в описании типа, а сами средства измерений имеют актуальный, подтверждённый статус поверки или калибровки – см. пример распечатки на рис .7) с теми, которые передаются в облако:

Рис. 7. Пример распечатки данных с устройств iQFreeze

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

Вопрос конфигурирования сообщений на основании введенных пороговых значений – также важен. Он не затрагивает напрямую первичные данные температурного мониторинга, но обуславливает GxP-значимые решения в их отношении. Например, для температурного диапазона 2-8° С, как было указано в самом начале статьи, целесообразно установить уровни предупреждения 2,5-7,5° С. Необходимо смоделировать срабатывание таких сообщений. Для того, чтобы иметь возможность корректно смоделировать срабатывание таких сообщений, нужно знать конкретную логику, зашитую в программное решение. В таблице 2 ниже представлены примеры такой логики:

Таблица 2. Примеры логики срабатывания оповещений (уведомлений)

Тип сообщений

Тема сообщения

Причина возникновения

Логика уведомления

Уведомление

Температура вернулась в коридор

Возвращение температуры по датчикам T1/T2 в заданный температурный коридор

ЕСЛИ ХОУ работает И (Т1 > Нижней границы + 0.5 ИЛИ Т2 > Нижней границы + 0.5 ИЛИ Т1 < Верхней границы – 0.5 ИЛИ Т2 < Верхней границы – 0.5) ТОГДА температура в норме

Критическая ошибка

С момента включения ХОУ прошло 30 мин, температура не в коридоре!

Если ХОУ включено и с момента запуска ХОУ прошло 30 минут и температурный датчик 1 или 2 вышел за пределы температурного коридора, тогда отправлять уведомление

ЕСЛИ ХОУ работает И (Т1 < Нижней границы + 0.5 ИЛИ Т2 < Нижней границы + 0.5 ИЛИ Т1 > Верхней границы – 0.5 ИЛИ Т2 > Верхней границы – 0.5) ТОГДА отклонение температуры

Критическая ошибка

Сигнализация!

Открытие дверей ТС без брелка или смарт-карты

ЕСЛИ сработала сигнализация И дверь открыта И продолжительность события > 30 секунд ТОГДА сигнализация!

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

Рис. 8. Пример журнала оповещений на базе решения AutoGRAPH Web

Таким образом, только непротиворечивая работа подобных систем позволяет рассчитывать на переход в продуктивную фазу эксплуатации. Выше описаны достаточно простые шаги, но они должны быть выполнены для обеспечения надежных поставок и с тем, чтобы техническое сопровождение таких систем было ожидаемо рутинно-скучным занятием. Игнорирование простых правил проектирования, разработки, тестирования и внедрения если и не исключит функционирование систем в GxP-сфере полностью, то, как минимум, может превратить их рутинную эксплуатацию в непрерывную «подстановку табуреток под сервисы».

Регуляторные требования, руководства, а также некоторые практические рекомендации, изложенные выше, позволят вам управлять вашими бизнес-процессами, а не вашим бизнес-процессам – управлять вами.

Ссылочные документы

[1]   https://www.youtube.com/watch?v=hosBW-h4p8M
[2]   GAMP 5 Guide: Compliant GxP Computerized Systems
[3]   https://www.testo.ru/ru-RU/kompleksnye-resheniya/testo_saveris_pharma
[4]   https://www.elpro.com/en/
[5]   https://www.vaisala.com/en/products/systems/indoor-monitoring-systems/viewlinc-continuous-monitoring-system
[6]   https://lpi.by/validation/csv/
[7]   WHO TRS 992 Annex 5 TS 11 – Qualification of refrigerated road vehicles (https://www.who.int/medicines/areas/quality_safety/quality_assurance/supplement_11.pdf?ua=1)
[8]   Решение № 80 Совета Евразийской экономической комиссии «Об утверждении правил надлежащей дистрибьюторской практики в рамках Евразийского экономического союза» (https://docs.eaeunion.org/docs/ru-ru/01411930/cncd_21112016_80)
[9]   Решение № 77 Совета Евразийской экономической комиссии «Об утверждении правил надлежащей производственной практики Евразийского экономического союза» (https://docs.eaeunion.org/docs/ru-ru/01411921/cncd_21112016_77)
[10]Title 21 CFR Part 11 Electronic Records, Electronic signatures (https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11)
[11] Валидация компьютеризированных систем доступным языком — PHARM COMMUNITY (https://pharm-community.com/2017/6787/)
[12] PI 011-3 PIC/S Guidance Good practices for computerised systems in regulated “GxP” environment (https://picscheme.org/docview/3444)
[13] PI 041-1 PIC/S Guidance Goo practice for data management and integrity in regulated GMP/GDP environments (https://picscheme.org/docview/4234)
[14] https://www.iqfreeze.ru/
[15] https://fgis.gost.ru/fundmetrology/api/downloadfile/24bad150-697b-4585-a9e7-d75cb85b1106
[16]  Руководство по целостности данных и валидации компьютеризированных систем ГИЛС и НП (https://gilsinp.ru/?wpfb_dl=269) [17] Does CSA Mean Complete Stupidity Assured? Bob Mc Dowall, Focus on Quality column, Spectroscopy, issue 09-2021 (https://www.spectroscopyonline.com/view/does-csa-mean-complete-stupidity-assured-)

[1] На самом деле переход «в цифру» выполняется уже в рамках контроллеров бортовых систем, как только аналоговый сигнал с температурных датчиков преобразовывается в цифровой для обеспечения индикации и реализации обратной связи по величине невязки текущей температуры (температур) и величины температурной уставки.

Подписывайтесь на каналы PHARM COMMUNITY:

   
Поделитесь с коллегами:

Залишити коментар