Совершенно секретно – размышления о целостности данных в фармпромышленности

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

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

Что же представляет собой понятие целостности данных?

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

Чем может грозить нарушение целостности данных?

На наших просторах я не встречал случаев наказания за эти проступки регуляторными органами, если не сказать, что такие проступки могут и поощряться ими самими :D. Что же касается того же FDA в США, то они могут прислать вам «письмо счастья», то есть с предупреждением или даже наложить штраф, в ЕС ситуация примерно аналогичная. Но с точки зрения ответственного производителя, гораздо более страшным является не получение этих писем или штрафов, а то, что препараты, зарегистрированные на основании неправильных данных, могут представлять угрозу для жизни пациентов. Именно по этой причине любой вменяемый фармпроизводитель должен отнестись к вопросу целостности данных с максимальным вниманием.

Типичными нарушениями целостности данных являются:

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

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

Контрольные журналы – следим за всем, что происходит!

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

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

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

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

Учетная запись – быть или не быть?

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

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

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

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

А что касательно безопасности данных?

Во всех отраслях, где используются электронные системы, безопасность данных стоит на первом месте. Для фармпроизводителей безопасность данных важна потому, что потенциальная кража патентов, технологических данных и/или информации о фармразработке потянет за собой значительные убытки. И тут возникает вопрос: как фирма может обеспечить безопасность своих производственных данных?

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

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

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

В-четвертых, фирма должна проводить периодическую оценку/пересмотр компьютерных систем для подтверждения их правильного функционирования и соответствия требованиям GMP. Подобная оценка/пересмотр в соответствующих случаях должна включать рассмотрение:

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

Что в сухом остатке?

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

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

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

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

3 комментария к “Совершенно секретно – размышления о целостности данных в фармпромышленности”

  1. Тоже не заметил ни тени рекламы 🙂 На самом деле, «общесть информации» — это бич практически любого документа на эту тему. Что «конкретного» Вы хотели бы прочитать на тему, которая-то и в нормативке представлена «очень обще»? 🙂 Чем меня недавно порадовало руководство Application of GLP Principles to Computerised Systems — так это предельной конкретностью. Я ранее ссылался на него, но сейчас изучил детальнее. По сравнению с ним Annex 11 cGMP — слишком «обще и противоречиво». Что ценно в указанном руководстве — возьмем, например, операционную фазу:

    3.1. Accuracy checks
    3.2 Data and storage of data
    3.3. Printouts
    3.4. Audit trails
    3.5. Change management and configuration management
    3.6. Periodic review
    3.7. Physical, logical security and data integrity
    3.8. Incident Management
    3.9. Electronic signature
    3.10. Data approval
    3.11. Archiving
    3.12 Business continuity and disaster recovery

    Эти пункты практически дословно совпадают с сGMP Annex 11 (5-17), вот только расписаны куда детальнее и не содержат противоречий и не столь поверхностно изложены. У меня недавно был пример, когда ПО соответствовало по своим требованиям в части аудиторского следа GMP и грубо не соответствовало в этом же аспекте данному руководству и здравому смыслу заодно. Когда читаешь правило GMP в этой части — всегда есть возможность «пройти между каплями дождя». Зато в указанном руководстве GLP просто и доступно изложены конкретные требования, понятные и программисту и пользователю.

    Так что автору однозначно респект за то, что актуализировал эту тему. Между строк читается модная в последнее время аббревиатура ALCOA (attributable, legible, contemporaneous, original and accurate). Как минимум перечень основных замечаний от автора — это хорошая опорная точка. Я бы даже высказался в том ключе, что целостность данных на бумажных носителях — это «забудьте и выбросьте» — компрометировать сможет кто угодно и когда угодно, хотя бы даже ценной переписывания требуемых журналов в последнюю ночь. А вот с компьютеризированными системами такие финты уже проблематичнее организовать. Это, кстати, один из тормозов их внедрения для тех, кто «привык подтасовывать результаты». На просторах СНГ очень редко замечания инспекционного аудита идут далее «валидация компьютеризированных систем отсутствует как класс». Но это не надолго. Совершенствуются и предприятия, и аудиторы всех мастей (контракторы и регуляторы). Поэтому чем больше материалов на эту тему — тем лучше. Даже на уровне размышлений.

    Эти размышления натолкнули меня на мысль всё-таки добраться до перевода указанного руководства GLP  на русский язык, предложил бы желающим присоединиться к идее (можем разбить на части) — заодно снабдить перевод своими комментариями (если это будет уместно).

  2. А вы зачем это все написали?

    Для рекламы себя любимого?

    Так расскажите что предлагаете.

    Кто ваша целевая аудитория?

    А то после прочтения двойственные чувства. С одной стороны пишет грамотный специалист, с другой — фактической информации как в рекламном буклете.

    • Так для Вас «золотой мой» и написал 🙂 Ну, а если серьезно, то это как размышления по данной тематике. Понимаю, что информация несколько общая, буду стараться её расширить. Рекламы никакой нет. Целевая аудитория — работники фарм. предприятий, которые занимаются валидацией комп. систем и прикладного ПО.

Оставьте комментарий