Приложение 11 Том 4 GMP – Компьютеризированные системы (Рус.)

Сегодня я хочу представить на суд широкой общественности, вариант своего перевода Приложения 11 Тома 4 GMP. Это приложение описывает требования к компьютеризированным системам, которые все чаще и чаще применяются для автоматизации процессов в фармацевтической отрасли.
Само Приложение, как и все GMP руководства, описывает сами системы и связанные с ними вопросы достаточно поверхностно и лишь дает направление, но не пути и методы реализации, как любят говорить сами авторы GMP.Более детальные инструкции по разработке, внедрению, установке, сертификации и другим аспектам, можно найти в руководстве GAMP. За перевод которого я планирую взяться в будущем.
К слову самого документа. Контроль компьютеризированных систем не менее важен на современном этапе развития техники, чем любого другого оборудования, поэтому стоит отнестись к этому вопросу серьезно, будь-то система документооборота фарм. предприятия, или же программное обеспечения технологической установки. Малейшая ошибка в любой из систем приведет к серьезным последствиям и убыткам.

Итак, перейдем непосредственно к самому переводу (оригинал можно найти здесь)
(дополнения и правки – приветствуются, пишите пожалуйста их в комментариях):

Перевод приложения перенесен в Библиотеку.

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

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

7 коментарів до “Приложение 11 Том 4 GMP – Компьютеризированные системы (Рус.)”

  1. Приветствую Александр, спасибо за комментарии и правки!

    Действительно упустил эти моменты, бывает при прочтении “внимание замыливается от перевода” и упускаешь некоторые моменты + текст как бы компьютерной тематики и забываешь, что там что-то может идти про серию… 🙂

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

    Ваши правки уже внес. Ссылку на настанову киньте, где есть информация о её выходе, я что-то пропустил.

  2. Сейчас готовлюсь к аудиту по КС – небольшие ремарки к Вашему переводу. С учётом трактовок CoP GAMP, проблемных статей по поводу, оригинала Приложения и официального перевода на укр. язык в Настанове (на самом деле, в Настанове тоже есть местами не вполне адекватный оригиналу перевод, затрудняющий понимание):

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

    “Аудит информации” – не совсем то, что требуется. Требуется скорее “информация по аудиту поставщика”. Аудит следует проводить либо в соответствии с Приложением М2 GAMP5 либо PDA TR32. Эта информация, равно как и информация по системе качества поставщика, должна быть предоставлена поставщиком при инспекции заказчика, т.е. инспектора, могут напрямую обращаться к поставщику и желательно оговаривать таковую возможность в договорах с поставщиком (последнее уже есть в трактовке CoP GAMP).

    4.3 Должен быть доступен список обновления всех соответствующих систем и их GMP функциональности (опись). 

    Всё-таки речь не об обновлениях, а об актуальности перечня (описи) систем (up to date listing/inventory).

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

    Там же, по той же логике, не “детальное описание обновления системы”, а скорее “детальное актуальное описание системы”.

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

    Тут, наверное, речь идет не о месте, которое обеспечивает формальную оценку, а о том, что должен иметь место процесс этой самой формальной оценки и т.п.

    6. Правильность проверки 

    Скорее, проверка правильности (Accuracy checks), хотя сильно суть не меняется.

    15. Пакетное извлечение данных 

    Наверное, речь всё же идёт о выпуске серии (batch release). По аналогии:

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

    Тут, скорее всего, тоже речь идет о разрешении на выпуск серии

    В целом же что касается IT-терминологии, то у Вас более адекватный перевод, чем в официальной Настанове.

    А вот сомнительные места в официальной Настанове по отношению к оригиналу:

    2. Персонал
    System Owner, Process Owner в укр. прочтении стали “системним оператором”, “оператором процессу”. У Вас более адекватный перевод. А определения и различия в терминах владельца процесса и системы четко даны в GAMP. Настанова тут адресует немного не в те степи при том, что данный пункт и так из числа максимально размытых :)))

    4.5. Регламентований користувач – это кто? Regulated user – дословно, это пользователь, подверженный регулированию (инспектированию). У Вас в принципе указано “ответственный пользователь”, что хоть и не вполне точно, но не заставляет задумываться, где искать информацию о том, кем пользователь регламентирован 🙂

    Это всё мелочи, о которых вспоминаешь только тогда, когда собираешься идти на аудит в конкретное подразделение и задавать людям вопросы, смысл которых поначалу не до конца понятен самому :))) Вот, разбираюсь на досуге :)))

  3. Я тоже не был ни на летнем, ни на декабрьском семинаре Фабриса Жансена – на летнем были коллеги + есть краткое описание в сети. Лично я знакомился с материалами семинара – были изложены общие принципы с ссылками на нормативные документы ISPE GAMP, PIC/S, 21CFR Part 11, GMP Annex 11, а вторая часть была посвящена практическому примеру системы электронного документооборота.

    По поводу верификации ПО – конкретно в Приложении 11 нет столь четкого разграничения на верификацию кода и собственно валидацию КС в целом. Документ EDQM OMCL уже даёт такое разграничение, усиленное Вашим переводом с расставлением акцентов. Со своей стороны могу сказать, что собственно валидация ПО в значительной мере происходит в ходе “обычной” квалификации помещений, оборудования и систем (OQ) при проверке органов функционирования, контроля установленных параметров и версии ПО, доступа по паролям, реакции системы на аварийные ситуации и т.п. Часто-густо с систем визуализации осуществляется распечатка скринов и непосредственно на них галочками отмечается надлежащее функционирование тех или иных элементов интерфейса в соответствии с описаниями, приведёнными в технической документации производителя. Мне это так представляется исходя из имеющейся у меня информации. Верификация кода – это качественно совершенно иная и, согласен с Вами, порой более важная задача, в т.ч. и в плане своевременности её выполнения (вместе с исполнителем/интегратором на этапе внедрения КС). Вопрос – обязательна ли эта самая верификация, скажем, в случае ПО линии упаковки? В том смысле, не достаточно ли просто декларации от поставщика / производителя оборудования, что ПО на панель управления и контроллер разработано в соответствии с требованиями GAMP? Самостоятельно ведь конечный пользователь даже при наличии исходного кода не сможет оценить наличие “мертвых строк”, или провести анализ кода не его невырожденность, NP-полноту (последние две позиции приведены оценочно – нигде не встречал с точки зрения регуляторов в фарм. промышленности, что это требуется, зато вполне обычные вещи с точки зрения ИТ)? Аналогично можно сказать и в отношении более сложных и критических систем – систем визуализации водоподготовки, систем кондиционирования чистых помещений и т.п.? Конечный пользователь осуществляет валидацию, которая по существу является “реакцией системы на щелчки”. Этот аспект пока-что для меня остается размытым, хотя я только приступил к изучению документа GAMP 5. Возможно у Вас знания по данному вопросу более глубокие и структурированные.

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

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

    Опять же повторюсь, что без доступа к исходному коду приложения валидация это не более чем набор тест-кейсов: открыть то-то, нажать на то-то, сформируется такой-то документ; или автоматизированных юнит-тестов. Большую часть в данном процессе занимает описание самих процессов, сущностей ПО… Если исходный код содержит ошибки и на этапе верификации они не были обнаружены и вся последующая документация будет написана без обнаруженной ошибки, то валидация по сути – мыльный пузырь, который лопнет при первой же серьезной проблеме.

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

    По опыту работы с автоматизированными валидационными пакетами ПО могу сказать, что валидация закрытых систем – это не более чем курам на смех. Суть: пакет запускает целевое ПО и прогоняет заданные юнит-тесты. К примеру в одном из них вылетает ошибка. Как я могу понять с чем связана ошибка? С неправильным юнит-тестом или ошибкой в ПО? Выход один обращаться к вендору ПО с указанием данной ошибки. В итоге оказывается, что неправильно составлен юнит-тест, потому что ПО в ручном режиме с аналогичным набором данных выдает правильные результаты. Кто накосячил? Правильно – разработчик, он и должен устранять ошибку, потому что сам не удосужился верифицировать свои же юнит-тесты. Почему я не должен проводить верификацию/валидацию (откинем в сторону тот факт, что я полез внутрь теста и разобрался с его логикой)? Потому что я не разработчик данного ПО, у меня нет доступа к его исходной логике (коду) соответственно я не могу сделать правильный вывод о том, на каком этапе возникает ошибка. Рядовой пользователь этого не сделает и подавно. Разработчик обязан был предоставить мне все документы по верификации и валидации всего цикла работы его ПО, а также проверить корректность юнит-тестов и системы их запуска, чего сделано не было. Как в таком случае я могу проводить свою валидацию? На основании чего? 2 + 2 = 4 && 2 + 2 = 4

  5. Уважаемый Антон,
    с недавнего времени занимаюсь валидацией КС – все указанные документы у меня в наличии – однако приятно порадовали Ваши публикации и суждения на форуме по рассматриваемому вопросу. Я, можно сказать, пока только в самом начале пути (правда, с более чем 7-летним опытом квалификации помещений, оборудования и систем). В частности хотел бы задать вопрос по Вашим публикациям по EDQM OCML – всё-таки в руководстве достаточно четко ограничена сфера применения, равно как и в случае ISO 17025 – это лаборатории. При этом навскидку подходы во многом созвучны с таковыми у GAMP 5. Есть мнение, что GAMP 5 целиком и полностью достаточно для осуществления валидации КС (как раз на летнем семинаре эту мысль высказывал французский товарищ), т.е. для всестороннего применения (не только для лабораторий) в качестве базовых документов следует использовать Приложение 11 GMP (как базовое требование, пусть и слишком общее) и GAMP’ы во всём многообразии, как хоть и рекомендательные руководства, но собственно объяняющие, что требует GMP и как это реализовать на практике с главенствующими концептами жизненного цикла и анализа рисков.

  6. Действительно слишком обще всё описано в оригинальном документе, в этой связи вовсе не лишним является документ GAMP CoP Annex 11 Interpretation. Интерпретации Приложения 11 приведены на 16 страницах и дают уже более внятные указания, прямо адресуясь к терминологии и подходам, изложенным в GAMP Good Practice Guide – A Risk Based Approach to Operation of GxP Computerized Systems

Залишити коментар до Александр Белинский Скасувати коментар