Уведомления
Очистить все

Валидация компьютеризированных систем.

35 Сообщения
11 Участники
1 Likes
1,095 Просмотры
0
Автор темы

Как составить Валидационный мастер план?

Здравствуйте, дамы и господа!
Может быть кто-то знает – как выглядит этот самый Validation Master Plan? Что именно в нем отражать – мне более-менее понятно, а вот как должен выглядеть документ –я не знаю.
Регламентирована ли форма документа?
Существуют ли шаблоны (примеры ) мастер-плана?

0

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

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

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

В общем удачи! Пусть семинар принесет только пользу и новые знания.

0

Кстати, по поводу:
@Nick писал(а):

семинар с возможностью задавать вопросы за 600$

Вы же сами понимаете, что бесплатный сыр только в мышеловке 🙂

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

0

Хочу возразить. Перед семинаром было несколько запросов на консалт. После семинара все сказали - все просто, справимся сами! Так что семинар по валидации КС - это не пиар, это все же семинар!

0

Nick, как прошёл семинар? Расскажите, интересно! Что полезное для себя вынесли?

0

Вообще, по изначальному вопросу в отношении ВМП по идее как раз материалов семинара Фабриса Жансена в купе с ISPE GAMP5 должно хватить. Во всяком случае в Приложениях GAMP® 5: A Risk-Based Approach to Compliant GxP Computerized Systems, включая A companion volume to... есть немало шаблонов - надо их критически просмотреть. В материалах семинара Фабрис предлагает иметь ВМП, который распадается в отдельные Валидационные планы для каждой из КС - возможно это и удобно, в любом случае, это не является догмой. Насколько я понимаю, что ежели составляются ВМП, которые охватывают квалификацию, валидацию процесса и/или очистки, валидацию аналитических методик, то отдельным разделом можно туда включить и валидацию компьютеризированных систем. Я сам пока ещё не определился для себя, как будет рациональнее. Возможно, это кто-то мог проговаривать и на семинаре - я не был его участником, но имею на руках его материалы от коллег, кто был на летнем мероприятии. Так или иначе, в ближайшем будущем я также буду решать данный вопрос (в т.ч. создание ВМП) - изучу литературу предметнее - вынесу свои мысли на обсуждение.

0

Примерно месяц собирался с мыслями, чтобы задать первый осмысленный вопрос в данной теме. Для этого потребовалась преамбула, которую в итоге перенёс в блог (по предложению администратора сайта).
Собственно основная мысль проста - вопрос даже не в том, что должно быть в ВМП и как его разработать (это пусть и важный, но частный вопрос), а в том, как организовать деятельность в компании по валидации КС, где уже проводится квалификация и валидация "обычная", т.е. процессов, очистки, аналитических методик.

0

Огромное спасибо за освящение этой темы. С нетерпением жду продолжения 😉

0

Немного дополнил блог, где вплотную подошел к созданию перечня КС с указанием их категоризации согласно GAMP5, как к первому осмысленному шагу.

0

Практический вопрос по категориям ПО согласно GAMP 5. Чаще всего на практике мы имеем дело с категорией 3 и категорией 4 - не конфигурируемым и конфигурируемым ПО соответственно. Пытаюсь соотнести эти данные с окружающей действительностью. Пример: ПЛК S7-300/400 Siemens на технологическом оборудовании - по идее с использованием среды разработки (Simatic Step 7) - это конфигурируемое ПО или нет? По идее мы используем (точнее, поставщик оборудования) среду разработки Step7 для того, чтобы именно сконфигурировать контроллер. С другой стороны, конечный пользователь после такой конфигурации ПЛК, как правило, не имеет доступа к коду (поставщик чаще всего закрывает доступ паролем даже при наличии Step7 у конечного пользователя для обеспечения гарантии невмешательства со стороны последнего). Приведём в пример конкретно блистерную машину. Или машину наполнения и запайки ампул. С учётом этого возвращаемся к исходному вопросу - для такого оборудования исполнительные файлы PLC и HMI - категория 3 или всё-таки 4. Если 4, то что тогда является третьей категорией? Я имею в виду пример из числа производственного технологического оборудования. Я склоняюсь к мысли, что это категория 3, не взирая на то, что в Приложении М4 в таблице категорий М4-3.1 к типичным примерам категории 4 отнесены системы SCADA. Развивая мысль как при этом относиться к тому факту, что указанные машины (блистерная или наполнения и запайки) позволяют работать с несколькими форматами, что предусматривает загрузку определённой конфигурации с ПО (1, 2 мл ампулы или блистера на 5 или 10 таблеток) - это ведь можно трактовать как в пользу того, что это категория 4 (конфигурируем ведь номинально!), так и в пользу того, что это категория 3 (run-time parameters may be entered and stored). Иначе у нас ПО для машины групповой упаковки (где контроллер запоминает только количество рядов и слоев пачек/стеков) будет одной категории с системой ERP только на том основании, что можно употребить термин "конфигурирование".

Далее, различие в том же GAMP5 между 4-й и 5-й категорией. Разработка в Step 7 (допустим!) - это конфигурирование, а разработка в Borland Delphi - уже индивидуальный код. Какие принципиальные отличия окошка, прорисованного в среде Borland или средствами WinCC Flexible? В Delphi я могу написать приложение Hello world! и форма у меня будет содержать одну кнопку и одно поле вывода - программа будет именно что Custom, а на WinCC Flexible я могу нарисовать всю систему водоподготовки, скажем - и это будет Configured? Окно приложения (форму) в RAD от Borland я описываю в окне кода с использованием языка Delphi (аналогично Visual Basic, C++) и это software custom designed and coded, а то что Step 7 при этом предлагает 3 основных языка (LAD, FBD, STL) и 4 дополнительных - это всё ещё конфигурирование?

Вот это первые мои сомнения при категоризации ПО. Кто что может подсказать по данному поводу?

0

И ещё вопрос в догонку, но уже по категориям "железа" согласно того же Приложения М4 GAMP 5. Есть первая категория - стандартные компоненты - вроде бы вопросов не вызывает. Вторая категория - опять-таки Custom Built Hardware Components. Помимо того, что это какое-то "кустарно-изготовленное железо" из объяснения ничего не понятно. По отношению к категории 1 добавлено магическое понятие DS (Design Specification). Тут, для комментариев, наверное нужен IT-специалист, чтобы буквально интерпретировать текст GAMP5. Имеем ПК в качестве элемента IT-инфраструктуры - ПК состоит из материнской платы, винчестера, видеокарты и т.п. - это стандартное железо. Что в подобном случае является нестандартным? Может быть пример с ПК не показателен и нужно коснуться серверов? DS по идее я могу на кард-ридер составить :), если захочу поставить кард-ридер именно какой-то особенный, который не входит в стандартную комплектацию системного блока. Кто что думает/знает по этому поводу?

Страница 2 / 4
Поделиться: