Как составить Валидационный мастер план?
Здравствуйте, дамы и господа!
Может быть кто-то знает – как выглядит этот самый Validation Master Plan? Что именно в нем отражать – мне более-менее понятно, а вот как должен выглядеть документ –я не знаю.
Регламентирована ли форма документа?
Существуют ли шаблоны (примеры ) мастер-плана?
Изучение форума ISPE GAMP COP (Community of Practice) позволило сделать заключение, что подавляющее большинство технологического оборудования - это 3-я категория по GAMP5. Есть варианты, что иногда в комплексных случаях часть элементов оборудования/систем может быть отнесено к категории 4, но как правило случаи использования конкретных конфигураций / последовательностей / рецептур / форматов - это категория 3. В фокусе рекомендуется держать не категории "сами по себе", а то, какой валидационный подход использовать, что тесно коррелирует с вероятностью возникновения риска.
Вопрос нужный и очень острый.
Но чтобы что-то думать по этому поводу, нужно обладать хотя бы элементарными познаниями в программировании и устройстве КС, управляющих не менее сложным технологическим оборудованием.
Поясню: производя при OQ тесты на разрыв цепи, ПО может не выдавать ошибку в соответствии с типом датчика (в данном случае - резистивный датчик). Датчик - элемент КС, относящийся к "железу".
Или то, что непосредственно относится к ПО. Преамбула: изготовитель оборудования строго настрого запретил изменять настройки. По тесту необходимо симулировать достижение какого-либо числового параметра (например, давления воды) выше верхнего порогового. Исполнители четко выполняют инструкцию, датчик сработал, ответ ПО не был получен. В данном случае пришлось "нарушить табу" и изменить настройку ПО по данному параметру (с значения "до бесконечности", до конкретной обоснованной величины).
То есть, мы (обычные валидаторы) присоединились к дискусу, если бы нам дали некий базовый ликбез. Вернее, ссылку на простой и достоверный талмуд.
За сим спасибо автору.
@Microb писал(а):
Вопрос нужный и очень острый.
Но чтобы что-то думать по этому поводу, нужно обладать хотя бы элементарными познаниями в программировании и устройстве КС, управляющих не менее сложным технологическим оборудованием.
Тоже так думал на первых порах. Сам не айтишник по образованию. По идее можно освоить базовые понятия и без специального образования, а касательно тонкостей программирования контроллеров, не факт что и ФИВТ КПИ спасёт. Пока увидел непосредственную необходимость в этом только в Приложении D4 Management, Development & Review of Software (GAMP 5), где пункт 3.1 , в частности содержит, требования по разработке ПО с обеспечением обслуживаемости, модульной структуры, устранения мертвых кодов / строк, наименования переменных и их инициализации и т.п. Но! Уже в п. 3.2 говорится о том, что необходимо выполнить пересмотр кода, где требуется независимый специалист / эксперт в кооперации с разработчиком. Не вижу проблемы обязать предоставить отчёт о таком пересмотре самого поставщика системы. Цель пересмотра - это подтвердить выполнение требования, изложенных в п. 3.1 Приложения D4 и доказать соответствие кода проектным спецификациям.
А вот если идти далее последовательно (Приложение D5 - Testing of Computerized Systems) - там описывается главным образом только "реакция ПО на щелчки" - в большинстве случаев не понадобится специальных знаний по программированию - понадобится по-человечески сделанная спецификация ПО / КС. 🙂 Да, наверняка есть аспекты, где без специальных знаний ай-ти-профиля справится тяжело - пока не столкнулся на практике с таковыми ситуациями.
@Microb писал(а):
Поясню: производя при OQ тесты на разрыв цепи, ПО может не выдавать ошибку в соответствии с типом датчика (в данном случае - резистивный датчик). Датчик - элемент КС, относящийся к "железу".
не очень понял пример - это Вы говорите о проверке реакции системы на аварийные ситуации, верно? Если ПО не выдаёт ошибку при разрыве цепи (нарушении целостности измерительного канала - правильно понимаю?), значит это, скорее, недоработка спецификации требований пользователя / спецификации проекта ПО. Как правило "битый" измерительный канал софт пеленгует, поскольку получает даже до АЦП артефактный сигнал. Если после аналогово-цифрового преобразования обработчик события не генерирует аварию в соответствии с написанным кодом, то он не будет этого делать и безотносительно нашего OQ - это прямой недочёт программы.
@Microb писал(а):
Или то, что непосредственно относится к ПО. Преамбула: изготовитель оборудования строго настрого запретил изменять настройки. По тесту необходимо симулировать достижение какого-либо числового параметра (например, давления воды) выше верхнего порогового. Исполнители четко выполняют инструкцию, датчик сработал, ответ ПО не был получен. В данном случае пришлось "нарушить табу" и изменить настройку ПО по данному параметру (с значения "до бесконечности", до конкретной обоснованной величины).
При проведении "обычной" квалификации оборудования и систем нам также часто приходится обращаться к специалистам разных предметных областей. Опять же, тут, судя по всему, случай проверки реакции системы на аварийные ситуации. По идее программу тестирования ещё на этапе разработки следует согласовывать со специалистами по автоматизации (КИПиА и т.п.). Разработчик может закрыть для нас возможность что-то менять в коде (и будет прав), но пороговое значение, например, давление воды - как правило, пользовательский параметр (пусть и под определённым уровнем доступа). Если мы не можем с ПУ его фиктивно, с целью тестирования, занизить/завысить, то с той же службой КИПиА можно попробовать сгенерировать аналоговый сигнал (похожий процесс выполняют метрологи при калибровке зачастую), превышающий порог и отследить реакцию системы. Если система НЕ реагирует - это свидетельствует о её неудовлетворительном функционировании - может быть адресована прямая претензия к разработчику - по идее это нужно зафиксировать ещё при приемке.
@Microb писал(а):
То есть, мы (обычные валидаторы) присоединились к дискусу, если бы нам дали некий базовый ликбез. Вернее, ссылку на простой и достоверный талмуд.
За сим спасибо автору.
Не думаю, что есть один такой простой и достоверный талмуд. Иначе все бы его прочитали и не нужно было бы ничего обсуждать. 🙂 Я думаю, что начать лучше всего с Приложения 11 GMP (4 стр. + 1 абзац) - в авторском (Антона Мымрикова) переводе на русский язык Приложение 11 представлено тут. Там абстракция (понятное дело, что обусловлено абстрактным оригиналом - переводчик тут не при чём :)), но в обсуждениях к переводу есть ссылка на интерпретацию Приложения СoP (Community of Practice) GAMP и сам GAMP. Вообще говоря, руководящим является только само Приложение 11 - всё остальное - интерпретации, носящие рекомендательный характер.
Я в ближайшее время буду делать квалификацию системы электронного документооборота - посмотрю, достаточно ли мне будет "общих представлений" и как часто я вынужден буду обращаться за помощью к ай-ти специалистам. Думаю, что помощь системного администратора мне нужна будет в большей даже степени, чем разработчика.
Ведь если проанализировать сущностную часть Приложения 11 - п.4 Валидация - сплошная абстракция, адресующаяся, главным образом, ещё к разработке/приемке новой КС. Из п. 5 - 17 вроде как все прозрачно - легко проверить и осуществить на практике даже не специалисту (если ничего при этом не поломать :)) - лично меня немного смущают только пункты "Пакетное извлечение данных" и "Непрерывность бизнес-процессов", но, думаю, разобраться можно. Всё остальное из этапа функционирования, ИМХО, вполне доступно "простым смертным". Никто не запрещает в принципе в ходе тестирования прямо указать, что в тут мы проверяем возможности распечатки данных (п. 8.1), а здесь - сохранность архива (п. 17) и в таком упрощённом варианте доказать соответствие требованиям Руководства по НПП.
Часто-густо с систем визуализации осуществляется распечатка скринов и непосредственно на них галочками отмечается надлежащее функционирование тех или иных элементов интерфейса в соответствии с описаниями, приведёнными в технической документации производителя.
То есть, в руководстве пользователя оборудованиемсистемой должны быть представлены и описаны абсолютно все скрины (окна программыконтекстные меню и т.д.) и доступные функции? Индивидуально под систему заказчика, а не схожий или "общий"?
Есть какие-либо требования, выдвигаемые к руководствам?
@Default писал(а):
То есть, в руководстве пользователя оборудованиемсистемой должны быть представлены и описаны абсолютно все скрины (окна программыконтекстные меню и т.д.) и доступные функции?
Скринов может и не быть, но каждое окно должно быть описано с учетом имеющихся в нем доступных настроек с интервалами. И высший пилотаж - лист настроек от производителя с пометкой "криворукие вмешательства могут привести к ававрии". Кроме того, в руководстве пользователя должна быть инструкция: включи то, нажми это и будет тебе счастие.
@Default писал(а):
Индивидуально под систему заказчика, а не схожий или "общий"?
это надо в договоре прописывать. Если вы не можете повлиять на договор, то вам могут подсунуть именно "общий". Тогда смело вступайте в переписку и требуйте что вам надо.
@Default писал(а):
Есть какие-либо требования, выдвигаемые к руководствам?
Приложение 15 к ДжиЭмПям:
...
Квалификация монтажа
...
12. Квалификация монтажа должна включать следующие элементы (но не ограничиваться ими):
...
b) оценку полноты и сопоставление инструкций поставщика по эксплуатации и работе, а также требований к техническому обслуживанию
Да, описание должно быть актуальным и полным. В данном контексте не совсем пойму вопрос, что значит "общим" или "схожим"? Средствами, например, WinCC Flexible создано ПО визуализации для системы, например, водоподготовки совершенно конкретной конфигурации. Там присутствуют конкретные кнопки управления, визуализация работы клапанов, страницы меню. Это отдельно написанный исполнительный файл. Какое "схожее" при этом описание может быть - для визуализации систем приготовления растворов? 😉 В остальном соглашусь с Microb.
Александр Белинский писал(а):
Да, описание должно быть актуальным и полным. В данном контексте не совсем пойму вопрос, что значит "общим" или "схожим"? Средствами, например, WinCC Flexible создано ПО визуализации для системы...
Есть недобросовестные поставщики, которые пытаются подсунуть лабуду, вместо полноценного руководства пользователя.
Под предлогом там и так все понятно, очень много описывать и персонал обучен - не считают нужным описывать все страницы меню и функции.
Александр Белинский писал(а):
Да, описание должно быть актуальным и полным. В данном контексте не совсем пойму вопрос, что значит "общим" или "схожим"? Средствами, например, WinCC Flexible создано ПО визуализации для системы...
Доброго дня, Messer!
В моей практике имеются случаи предоставления мануала на серию моделей оборудования (конкретно в данном случае - линии асептического наполнения во флаконы). То есть, между строк понимается "используйте то, что применимо к вашей модификации". Иными словами, у них один файл на несколько разных модификаций оборудования.
Александр Белинский писал(а):
Какое "схожее" при этом описание может быть - для визуализации систем приготовления растворов? 😉
Однако)))) Хороший вопрос! Опять же могли бы подсунуть все что угодно. Мы, специалисты по валидации, не совсем понимаем что может быть написано в Soft Design Specification. А потому, там может быть описано все, что угодно!
Вот нам 3 месяца назад поставили оборудование для приготовления растворов. Спецификация на софт не соответствовала действительности, плюс они сами увидели свой косяк в программе при проведении трех подряд процедур по стерилизации реакторов (оборудование куплено вместе с IQ, OQ). Мануал так же был от какой-то похожей, но не нашей модели. Представитель сказал, что это их стандартная практика - править SDS по месту у заказчика, а потом из своего офиса высылать мануал, соответствующий SDS. Так что, когда-нибудь мы дождемся от изготовителя нового мануала (да, и вообще, всего комплекта документации).
Если бы представитель изготовителя закрыл глаза на "несоответствие в бумажке" (с точки зрения инженеров, это несущественно), то известно каким был бы у нас мануал - что-то среднее между нашей моделью и какой-то еще.
Microb, сейчас во многих направлениях микроэлектроники наблюдается тренд "выпускай чаще, выпускай быстрее". Кокуренция среди производителей железа приводит к тому, что на рынок часто поставляется железяка с неоттестированным программным обеспечением и с унифицированным руководством для нескольких моделей, которое производитель потом "допиливает" по ходу работы этого железа и выпускает патчи. Хотя в высокоточных и опасных отраслях такого наблюдаться не должно, но похоже, что фарма сюда тоже косвенно попадает периодами.
Тема сейчас становится действительно актуальной, ведь уровень автоматизации производства и учета достаточно высок. В большинстве случаев, основные процессы производства автоматизированы, чтобы уменьшить вероятность ошибок. Но такие системы зачастую тоже подлежат валидации.
