Транспортировка лекарственных средств является наиболее уязвимым звеном цепи поставок в плане поддержания температурных условий. Разумеется, при складировании на стационарном объекте (в зонах обычного хранения, в холодильных или морозильных камерах) риски выхода за специфицированные условия хранения ниже, чем при транспортировке и сопровождающих ее операциях погрузки/разгрузки. Ведь в стационарном складе с обычными температурными условиями хранения (от +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-сфере достаточно получить распечатку с подобных бортовых систем для подтверждения соблюдения температурных условий при транспортировке.
Что же мы должны учесть при переходе «в цифру» [6] – к вышестоящим компьютеризированным системам? Приведем ключевые требования, рекомендации и сформулируем общепринятую отраслевую дорожную карту, если мы хотим заменить бумажные распечатки постфактум, когда по завершении маршрута уже поздно принимать решения, а водитель не отследил или не сумел оперативно сориентироваться на основании текущих показаний (как правило, вывод индикации температурных значений непосредственно в кабину производится с помощью Carrier Transicold и аналогов). К тому же водитель ведь не всегда находится в кабине по ходу маршрута – есть остановки, взаимодействие с контрагентами вне кабины и тому подобное. Кроме того, у водителя в фокусе внимания в первую очередь дорожная обстановка, кто бы какие СОП ни писал в этом отношении. То есть если не реализована эффективная система оповещений, очень трудно рассчитывать на полный контроль показаний водителем. Опять-таки мы приходим к окончательному подтверждению успешности поставки только постфактум путем ручной оценки чека. Ручная оценка – еще одна рисковая позиция в плане человеческой ошибки.
Если обращение с контроллерами и принтерами (подобные показаны на рисунке 1) должно быть охвачено в рамках «обычной» квалификации ТС [7], то внедрение даже самой простой компьютеризированной системы, осуществляющей сбор экспортированных с первичных регистраторов данных, тут же ставит ряд вопросов, которые не возникают при использовании простых контроллеров и принтеров. Формально контроллеры тоже представляют собой компьютеризированную систему и имеют прошивку (firmware – бывшая категория 2 по GAMP, от которой отказались в 2008 году в GAMP 5 ввиду того, что firmware может быть какой угодно сложности). Но именно в отношении коммерчески доступных простых контроллеров функциональные риски принято считать низкими. К первичным данным доступа, как правило, нет. Следовательно, они не могут быть удалены или модифицированы, хотя допустима их перезапись по петле по истечении времени. Впрочем, на таких контроллерах вполне можно поменять периодичность на распечатках, системную дату и время, но я не сталкивался с ситуациями, когда кто-то требовал бы для подобных простых контроллеров, скажем, управление учетными записями или аудиторский след. Я уже молчу о том, что именно с контроллеров задается уставка целевой температуры в кузове, а системы мониторинга, как правило, не реализуют такой функции, они принимают данные пассивно, без обратной связи в плане автоматического регулирования исполнительных устройств. Буду признателен, если коллеги по отрасли меня поправят или дополнят мнение, имея в виду именно простые бортовые устройства, как Carrier или TheromKing – наверное, два самых распространенных варианта реализации.
Как только у нас появляется компьютеризированная система в развитии (мобильные устройства, десктопное или облачное ПО), возникают и новые передаточные звенья, соответственно, возрастают риски и пропорционально ужесточаются регуляторные требования и ожидания отраслевых игроков – участников рынка лекарственных средств. Среди таких требований первоочередными являются вопросы передачи данных, обеспечения их сохранности в неизменяемом формате, защиты от модификации и удаления, формирования настроек оповещений, их квитирования и тому подобные. Казалось бы, любая компьютеризированная система призвана облегчить жизнь и сделать нашу деятельность более эффективной, а не усложнить ее и вызвать сомнения в каждом шаге передачи данных. Вместе с тем в одной из зарубежных функциональных спецификаций мне в свое время удалось обнаружить блестящую фразу об отраслевых требованиях. Речь шла об описании американского нормативного документа 21 CFR Part 11 [8]. Фраза очень емкая, передающая физический смысл указанного документа одним абзацем:
Поскольку риск манипуляции, введения в заблуждение или изменения без прослеживаемости с электронными записями и электронными подписями выше, чем с соответствующим бумажными записями и ручными подписями или их сложнее обнаружить, следует выполнить ряд мероприятий для предотвращения таких действий.
Сам указанный нормативный документ 21 CFR Part 11 увидел свет в марте 1997 года и до сих пор актуален в исходной формулировке. Чуть позднее, в 2003-м, появилось руководство для индустрии в отношении применения этого стандарта. Это прямое требование в США, но оно считается надлежащей практикой во всем мире. В 2008-м вышла последняя редакция «магистрального» документа, носящего рекомендательный характер – ISPE GAMP 5 [9]. В 2011-м – современная редакция приложения 11 GMP [10] в отношении компьютеризированных систем. Последний документ – прямая норма в ЕС и ЕАЭС, вобравшая в себя многое из 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).
Разумеется, V-модель может выглядеть по-разному в зависимости от сложности компьютеризированной системы – различные категории ПО также изложены в руководстве GAMP 5 [12]. Но предлагаю пойти от простого к сложному.
Поскольку транспортировка – это прежде всего вотчина GDP [13], то следует первично держать в фокусе именно GDP, где, надо отметить, сформулированы только самые общие требования к компьютеризированным системам. В развитии этих требований следует держать в фокусе приложение 11 GMP [14], даром что формально это производство лекарственных средств. По моему глубокому убеждению, если занять позицию следования только требованиям GDP, абстрагировавшись от других требований и руководств, компьютеризацию вряд ли удастся не то что воплотить в жизнь – не удастся даже толком сформулировать требования к ней.
С требований URS (User requirements specification) все начинается. Причем не только в фармацевтике. Обычная ИТ-разработка по лучшим практикам также должна начинаться с требований. Причем без них практически исключена вероятность создания непротиворечивой системы даже хотя бы средней сложности: начинаются многочисленные круги и итерации, «чайка-менеджмент» в плане разрозненных требований «по скайпу», «сомнения в чатах» и тому подобное. Ни один толковый разработчик даже задание на интернет-магазин у вас не должен принять без письменной и согласованной всеми заинтересованными сторонам спецификации требований пользователя или ТЗ. Если это не студент-фрилансер или просто зрелый специалист/группа специалистов, работающих ради хобби. Фармацевтика последние ситуации прямо исключает – URS фигурирует во всех указанных выше документах в той или иной формулировке. В ISPE GAMP 5 это приложение D1, в приложении 11 GMP – это пункт 4.4.
URS должна разрабатываться, прежде всего, будущим владельцем системы. Если так получилось, что система уже начала разрабатываться, URS нужно сделать хотя бы ретроспективно (на что указывает пункт 16.6 руководства PIC/S [15]; кстати, попутно отмечу, что само определение «компьютеризированная система» то же руководство ISPE GAMP 5 берет прямо из PIC/S – я составил авторский перевод [16] этого определения на русский язык). Почему важно разработать URS хотя бы ретроспективно? Потому что важно понимать, каким ИТ-активом вы хотите обладать. И конечно, настоятельно рекомендуется эту URS разработать до самой идеи что-либо реализовывать. Ведь часто доработка продукта, изначально не учитывающего основные требования, очень трудоемкая, а иногда и нецелесообразная. Ведь разработчики в определенный момент могут прийти к тому, что начать с чистого листа гораздо проще, чем встраивать в систему дополнительные требования по ходу маршрута.
Так или иначе, следующим обязательным документом является ответ на URS – функциональная спецификация (FS, functional specification). Соответственно, она указана в ISPE GAMP 5 Appendix D2, в приложении 11 GMP (пункт 4.3), завуалированная под «актуализированное описание системы». Это и есть ответ разработчика на вопрос, как он собирается реализовывать (или уже реализовал) требования заказчика.
Если компьютеризированная система сложная, то появятся и другие спецификации в развитие (SDS – software design specification, HDS – hardware design specification, DS – design specification). Мы пока для простоты изложения не пойдем в дебри. Ведь что важно: система мониторинга параметров микроклимата (в рассматриваемом примере – только температуры) это относительно простая система. Это не WMS, не ERP, не LIMS и не EDMS.
Практика показывает, что толковая URS и ее «зеркало» FS – это бо́льшая половина успеха в реализации системы.
Все дальнейшие шаги, в том числе валидационные, это разработка и по ходу этой самой разработки – документированное подтверждение (через тестирование) того, что what you see is what you get (WYSIWYG). Тестирование уместно не после разработки системы, а именно в процессе этой самой разработки. Об этом многие забывают. Это специфика ИТ-решений. На рисунке 3 показан пример онлайн-системы мониторинга, которая уже широко используется в различных отраслях, например, при транспортировке пищевых продуктов, и имеет перспективу реализации в сфере GDP. Даже более того: для требований GDP на самом деле уже сейчас в указанном примере (AutoGRAPH Web) есть определенный overfunctioning – избыточность функционала. Например, GxP не требует от нас трек по маршруту, так как пока мы живем в мире бумажных ТТН. Я не встречал отечественных реализаций без бумажных ТТН, даже если эти ТТН потом каким-то образом вкладываются в ERP/EDMS-системы. Но все равно трек не является ультимативным требованием. Конечно, на портале ISPE в 2018 году создана SIG (Special interest group), посвященная блокчейну и перспективам его использования, но это только намерения, судить о скорости реализации которых я пока не возьмусь. Но тот же трек визуально удобен. Состояние ХОУ или самого ТС – тоже опция удобная, но не требуемая напрямую с GxP-фланга. Это все дарит удобство компаниям, эксплуатирующим такую и подобные системы, позволяет более оперативно реагировать на внештатные ситуации и в конечном итоге повышать надежность самой поставки, минимизировать риски в ее отношении в целом.
Вместе с тем у фармацевтики есть ряд своих требований, дотянуться до соответствия которым не всегда просто. Один из таких вопросов – управление учетными записями и неизменяемый аудиторский след. Сам по себе только этот аспект может стать предметом большой отдельной статьи. Здесь я пока только обозначу интригу. Если вести речь о приложении 11 GMP (пункт 9), то там говорится об аудиторском следе буквально следующее:
На основе оценки рисков следует уделить внимание встраиванию в систему возможности создания записей всех существенных изменений и удалений, связанных с областью действия Правил (система, создающая «контрольные следы»). Причины таких связанных с Правилами изменений или удалений данных должны быть оформлены документально. Контрольные следы должны быть доступными, иметь возможность их преобразования в понятную для пользователей форму, регулярно проверяться.
В одной из немецких 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 [17]. Использование рассматривается всегда во взаимосвязи с остальной ФСК (фармацевтической системой качества). При всей совокупности аргументов за и против следует согласиться, что отраслевой тренд по мере усложнения систем – это скорее наличие контроля (глубина которого обсуждаема и зависит от конкретной конфигурации), чем его отсутствие. И только для наиболее простых реализаций, например, когда конечный пользователь не может ничего, кроме формирования отчетов по временным фильтрам, а сама система – максимально простая, без интеграций с 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 [18]. Принципы, изложенные в указанных примерах, будут применимы к любой аналогичной системе.
Сам по себе адаптер-регистратор iQFreeze (рисунок 5), внесенный в российский реестр средств измерений (№ 67930-17), обеспечивает регистрацию температуры и параметров работы ХОУ с возможностью распечатки через Bluetooth-принтер или экспорта данных в формате csv. В самом адаптере-регистраторе данные сохраняются без возможности доступа к ним. Формат csv, что очевидно, является незащищенным и не может прямо рассматриваться в фармацевтике. Распечатка через Bluetooth-принтер, по сути, уравнивает решение iQFreeze с бортовыми системами Carrier & ThermoKing.
В сочетании с возможностью передачи данных в облако, что реализуется за счет бортового контроллера GSM/ГЛОНАСС, мы получаем более широкий функционал, реализуемый уже со стороны решения AutoGRAH Web, которое, по сути, является SaaS-решением (Software as a Service). Что это означает? Обратимся к формулировке руководства по целостности данных и валидации компьютеризированных систем ГИЛС и НП [19], к пункту 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-распечаткой по месту. То есть любые потенциальные шаги в сторону – это только так называемый сговор группы лиц. Это весомый аргумент в рамках оценки рисков в пользу таких решений.
Что пишет об этом руководство ГИЛС и НП [20]:
Риск ненадлежащего использования и/или фальсификации записи обычными средствами (то есть не требующими использования специальных навыков мошенничества) должен быть снижен до приемлемого уровня.
Если компания-заказчик такой облачной услуги имеет доступ только к просмотру и формированию отчетов, а все конфигурирование, включая правила оповещений и управление учетными записями пользователей, осуществляется на стороне облачного провайдера через письменные официальные запросы – можно расценивать риски, связанные с такой схемой взаимодействия, как низкие. Разумеется, при документированном доказательстве общей работоспособности системы.
Общая схема такого решения выглядит следующим образом (рисунок 6):
Как на практике подтвердить валидность подобного решения? Навскидку может быть предложен следующий набор тестов:
- проверка технической документации,
- проверка ИТ-инфраструктуры (в том числе облачной, по запросу к поставщику SaaS),
- проверка установленного прикладного ПО,
- проверка метрологического статуса измерительных каналов,
- проверка наличия и актуальности СОП по эксплуатации системы и ее техническому сопровождению (со стороны поставщика SaaS – резервное копирование, управление учетными записями и прочее),
- проверка функционирования элементов интерфейса системы (замечу, задействованного функционала),
- проверка соблюдения требований целостности данных (доступ, использование электронных подписей, временные отметки, безопасность данных, аудиторский след, формирование отчетов, распечаток, осуществление резервного копирования),
- проверка установленных параметров и конфигурации,
- проверка реализации основных сценариев оповещений (если применимо).
Данный перечень, на взгляд автора, является достаточным, но, безусловно, может быть ситуативно дополнен, модифицирован. Возможно, отраслевые гуру, знакомые с протоколами валидации таких систем, как Vaisala или Ellab в несколько сотен страниц, могут с удивлением воспринять приведенный выше лаконичный перечень. Вместе с тем сообщество отраслевых гуру немонолитно. Есть признанные специалисты, которые не одно десятилетие занимаются вопросами валидации компьютеризированных систем и призывают участников этого процесса не забывать о том, что основная цель валидации – это доказать соответствие системы ее целевому предназначению (fit for intended use) [21]. На мой взгляд, истина, как это часто случается, расположена где-то посередине, на воображаемом пересечении кривых рисков для качества и возврата инвестиций. ROI = return on investment – возврат инвестиций. Это термин, который нередко можно встретить по тексту руководств ISPE, поэтому сложившиеся практики отнюдь не игнорируют здравый смысл и целесообразность, соотнося их с рисками для качества.
На что следует обратить внимание при проведении вышеуказанных тестов? Я бы акцентировал фокус именно на соблюдении требований целостности данных. В упомянутом руководстве ГИЛС и НП [22] и, разумеется, в международных источниках, на основании которых это руководство было разработано (ISPE, MHRA, WHO), вводится аббревиатура ALCOA+. Это как раз и есть параметры, обеспечивающие целостность данных. Вот их развернутый перечень с лаконичными пояснениями того, что же следует продемонстрировать:
| Параметр ALCOA+ | Краткая интерпретация |
|---|---|
| Прослеживаемость (Attributable) | Кто собрал (ввел) данные или выполнил действие |
| Читаемость (Legible) | Можете ли вы прочитать и понять введенные данные |
| Своевременность (Contemporaneous) | Были ли записи задокументированы в моменты выполнения действия |
| Подлинность (Original) | Являлась ли запись первым наблюдением (или верифицированной, истинной копией) |
| Точность (Accurate) | Является ли результат научно значимым и безошибочным |
| Полнота (Complete) | Все данные, метаданные, включая повторные испытания или анализы, в наличии |
| Последовательность (Consistent) | Все элементы испытаний или анализов имеют временную отметку и выполнены в ожидаемой последовательности |
| Устойчивость (Enduring) | Данные записаны в постоянной, поддерживаемой форме (формате) на протяжении всего их жизненного цикла |
| Доступность (Available) | Данные доступны для обзора, аудита или инспекции в ходе всего их жизненного цикла |
Таблица 1. Параметры целостности данных и их краткая интерпретация
Например, для выполнения первого пункта – прослеживемости – необходимо реализовать доступ к индивидуальным учетным записям и, в зависимости от выполняемых действий, аудиторский след таких действий. Здесь дискуссионный момент в том, какие действия в системе на самом деле следует фиксировать. Можно, конечно, огульно декларировать фиксацию всех действий, но это как раз и будет иллюстрировать бездумный и экстенсивный подход согласно [23] так называемому one-sizes-fits-all (с английского – «один размер на все случаи»). К тому же это сильно утяжелит систему, выдвинет более мощные требования к ИТ-инфраструктуре.
Кто и когда сформировал тот или иной отчет (первичные данные или истинную копию первичных данных, которые пользователь изменить не может), наверное, вопрос второстепенный. К тому же даже без логирования можно просто на каждой распечатке вывести ее дату, время, при желании – учетную запись сформировавшего. Тогда можно принять решение о том, что дополнительно указывать эти данные в аудиторским следе излишне. Если же речь идет о смене пороговых значений по температуре для оповещений, наверное, стоит фиксировать такие шаги и фиксировать именно отдельно, вне общего потока (кто вошел в систему, кто вышел из нее) или хотя бы с возможностью фильтрации таких событий.
Опять-таки важно понимать, что пороговые значения оповещений – это дополнительный функционал по отношению к бортовым системам. Вспоминаем: там распечатка с принтера анализируется «пешком», со всеми рисками человеческой ошибки.
А вот точная передача первичных данных – критически важный аспект. Он, как правило, фиксироваться аудиторским следом не будет. Факты фиксации данных, накапливаемых автоматически, не записываются в такие следы – на это есть прямое указание в протоколах валидации той же Vaisala, и это можно без труда увидеть в аудиторских следах, формируемых, к примеру, Ellab ValSuite Pro. Вместе с тем, если эти данные переданы некорректно, это способно аннулировать все усилия. Для исключения такого риска в ходе тестирования следует в указанном примере буквально сличить данные, формируемые адаптерами-регистраторами iQFreeze (внесены в реестр средств измерений, защищенность первичных данных гарантирована и указана в описании типа, а сами средства измерений имеют актуальный, подтвержденный статус поверки или калибровки, как на рисунке 7) с теми, которые передаются в облако:
Критически важно, чтобы дата, время и сами значения температуры совпадали буквально. Важно понимать, что может этому препятствовать, какие каналы передачи данных существуют, как они сконфигурированы, какова периодичность опроса конечных устройств и так далее.
Вопрос конфигурирования сообщений на основании введенных пороговых значений также важен. Он не затрагивает напрямую первичные данные температурного мониторинга, но обусловливает GxP-значимые решения в их отношении. Например, для температурного диапазона от +2 до +8 градусов, как было указано в самом начале статьи, целесообразно установить уровни предупреждения от +2,5 до +7,5 градусов. Необходимо смоделировать срабатывание таких сообщений. Для того чтобы иметь возможность делать это корректно, нужно знать конкретную логику, зашитую в программное решение. В таблице 2 ниже представлены примеры такой логики:
| Тип сообщений | Тема сообщения | Причина возникновения | Логика уведомления |
|---|---|---|---|
| Уведомление | Температура вернулась в коридор | Возвращение температуры по датчикам T1/T2 в заданный температурный коридор | ЕСЛИ ХОУ работает И (Т1 > Нижней границы + 0.5 ИЛИ Т2 > Нижней границы + 0.5 ИЛИ Т1 |
| Критическая ошибка | С момента включения ХОУ прошло 30 минут, температура не в коридоре! | Если ХОУ включено и с момента запуска ХОУ прошло 30 минут и температурный датчик 1 или 2 вышел за пределы температурного коридора, тогда отправлять уведомление | ЕСЛИ ХОУ работает И (Т1 Верхней границы - 0.5 ИЛИ Т2 > Верхней границы - 0.5) ТОГДА отклонение температуры |
| Критическая ошибка | Сигнализация! | Открытие дверей ТС без брелка или смарт-карты | ЕСЛИ сработала сигнализация И дверь открыта И продолжительность события > 30 секунд ТОГДА сигнализация! |
Таблица 2. Примеры логики срабатывания оповещений (уведомлений)
Важным с точки зрения системы в целом является не только проверка срабатывания указанной логики. Важно также, кто сконфигурирован в качестве адресатов таких оповещений. Ведь мало зафиксировать указанные события, нужно еще корректно и своевременно на них отреагировать, поэтому в фокус тестирования попадут также настройки списков целевых получателей и регистрация получения таких оповещений по всем настроенным каналам (рисунок 8).
Таким образом, только непротиворечивая работа подобных систем позволяет рассчитывать на переход в продуктивную фазу эксплуатации. Выше описаны достаточно простые шаги, но они должны быть выполнены для обеспечения надежных поставок и с тем, чтобы техническое сопровождение таких систем было ожидаемо рутинно-скучным занятием. Игнорирование простых правил проектирования, разработки, тестирования и внедрения если и не исключит функционирование систем в 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] На самом деле переход «в цифру» выполняется уже в рамках контроллеров бортовых систем как только аналоговый сигнал с температурных датчиков преобразовывается в цифровой для обеспечения индикации и реализации обратной связи по величине невязки текущей температуры (температур) и величины температурной уставки.
[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] Title 21 CFR Part 11 Electronic Records, Electronic signatures (https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11).
[9] GAMP 5 Guide: Compliant GxP Computerized Systems.
[10] Решение № 77 Совета Евразийской экономической комиссии «Об утверждении правил надлежащей производственной практики Евразийского экономического союза» (https://docs.eaeunion.org/docs/ru-ru/01411921/cncd_21112016_77).
[11] Валидация компьютеризированных систем доступным языком — PHARM COMMUNITY (https://pharm-community.com/2017/6787/).
[12] GAMP 5 Guide: Compliant GxP Computerized Systems.
[13] Решение № 80 Совета Евразийской экономической комиссии «Об утверждении правил надлежащей дистрибьюторской практики в рамках Евразийского экономического союза» (https://docs.eaeunion.org/docs/ru-ru/01411930/cncd_21112016_80).
[14] Решение № 77 Совета Евразийской экономической комиссии «Об утверждении правил надлежащей производственной практики Евразийского экономического союза» (https://docs.eaeunion.org/docs/ru-ru/01411921/cncd_21112016_77).
[15] PI 011-3 PIC/S Guidance Good practices for computerised systems in regulated GxP environment (https://picscheme.org/docview/3444).
[16] https://lpi.by/validation/csv/.
[17] PI 041-1 PIC/S Guidance Goo practice for data management and integrity in regulated GMP/GDP environments (https://picscheme.org/docview/4234)
[18] https://www.iqfreeze.ru/.
[19] Руководство по целостности данных и валидации компьютеризированных систем ГИЛС и НП (https://gilsinp.ru/?wpfb_dl=269).
[20] Руководство по целостности данных и валидации компьютеризированных систем ГИЛС и НП (https://gilsinp.ru/?wpfb_dl=269).
[21] 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-).
[22] Руководство по целостности данных и валидации компьютеризированных систем ГИЛС и НП (https://gilsinp.ru/?wpfb_dl=269).
[23] 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-).
Источник: GDP REVIEW 2 — Сборник практических статей III Международной конференции Логистика лекарственных средств
