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

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

   RSS

1
Автор темы

Добрый день коллеги!

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

В каком объеме необходимо выполнять валидацию компьютеризированных систем маркировки. URS, TS, FS, IQ, OQ, PQ (если брать стандартные стадии квалификации)

Надо ли затрагивать механическую часть оборудования при этом?

Или лучше разделить на квалификацию оборудования и валидацию компьютеризированных систем?

Квалификацию каких уровней (L1, L2, L3) необходимо проводить?

Как быть с передачей данных в ФГИС МДЛП и обратно? Входит ли это в квалификацию КС?

Подробно ли надо расписывать подключение периферии (монитор, мышь, клавиатура, принтер) к ПК?

Достаточно ли проверить связь между элементами системы с помощью команд «ipconfig» и «ping»?

На что стоит обратить внимание при валидации компьютеризированных систем?

Может ли кто-нибудь поделиться документами для ознакомления? Спасибо!

Буду рад любой помощи!

Вопрос с системой МДЛП в настоящий момент является одиозным в виду общей "дискуссионной работоспособности" системы на национальном уровне (выражаясь ИТ-шной терминологией, оператор рынка по существу не выполняет своё SLA) - поэтому мне самому интересно, какие перспективы системы в целом.

Вопрос ставится, на мой взгляд, даже не в том, какие документы предоставить и какие испытания выполнить, а в том работоспособна ли система в целом? Если вместо 500 единиц (each saleable units) система переваривает 5 - вопросы ipconfig & ping становятся глубоко второстепенными.

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

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

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

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

По поводу разделения квалификации оборудования и валидации компьютеризированных систем ответ есть в GAMP 5:

2021 05 12 14 46 16

Но на этом фоне как-то не руки вообще обсуждать валидацию системы маркировки именно в ЕЭАС: https://gxpnews.net/2021/04/arfp-v-otkrytom-pisme-pozhalovalas-na-sboi-v-rabote-sistemy-markirovki/

https://gxpnews.net/2021/04/minpromtorg-prosit-arfp-predostavit-dannye-o-sboyah-pri-rabote-s-mdlp/

https://arfp.ru/otkrytoe-pismo-ministru-promyshlennosti-i-torgovli-rossijskoj-federaczii-d-v-manturovu/

Что-то изменилось в этом отношении? Был бы признателен любой обратной связи. На линейном или заводском уровне не проблема отладить систему - это таки или иначе решаемая задачи в виду конечно производительности линий и прогнозируемого количества упаковок в соотношении с серверными мощностями и пропускной способности ЛВС. Хуже, если проблема есть на уровне национальном. Или уже все проблемы решены и я остался единственным, кто не в курсе такого ошеломительного успеха? 😉

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

3 ответа(-ов)
1

Вот уже 10+ лет эти трое ведут дискуссию на страницах этого форума. В том же самом ключе.

Один говорит как надо.

Другой как правильно.

А третий как это происходит в реальности.

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

(Валидационный пакет - полное фуфло, нет ПОЛНЕЙШЕЕ ФУФЛО, смотреть туда не надо просто)

И закрывают этот вопрос навсегда.

Намек думаю понятен. Денежные вопросы лучше обсуждать в личке.

Весьма странные инсинуации, Кирилл...

1) Я-то как раз и отношу вопрос системы маркировки в ЕАЭС - как "неденежный", т.е. я бы за такой проект как аутсорсер не брался бы в принципе (ибо всё, что можно было уронить на проекте - уронили - посоветовались бы с разработчиками Яндекс.Такси хотя бы, как делать продукты такого масштаба, чтобы они не гасли со старта - но это дело такое, по большому счёту не моё, а, скажем, структур Алишера Усманова сотоварищи). Хотя в своё время в Киеве занимался пилотным проектом маркировки, но в составе действующего сотрудника фармпредприятия и, разумеется, без криптохвоста. Опять-таки - L1, L2 - вопросов вызывает меньше, по L3 - их больше.
2) У меня всегда то, что я говорю = то, что я делаю применительно к валидационным подходам = то, что на моих проектах происходит в реальности. Другие проекты или подходы просто не рассматриваю и не участвую в них 🙂 Это получилось не столько осознанно, сколько в режиме бенчмаркинга у немцев. Если равенства выше не соблюдаются, то лучше сменить деятельность или пойти в паб/на футбол - в общем не "изображать радость" 🙂 Причем я далеко не перфекционист и не идеализирую ситуацию. Важно просто не путать главное со второстепенным. Шансы преуспеть имеет только тот шиномонтаж, которые нормально меняет шины, а не рисует их замену на авто без их остановки 🙂 "Рисователи" могут существовать, но на серьёзные рынки/зрелых контрагентов не выйдут.

Причем, кстати говоря, я являюсь последовательным противником интерпретации GMP как give more paper - считаю, что это как раз и происходит от "желания заливать пожар бензином".

По предмету обсуждения. Чтобы продукт был рабочим - изобретать велосипед не нужно - пара простых в своей основе принципов, чуть больше желания разобраться в вопросе (а не "отгавкаться от инспекторов/аудиторов" - не спорю, есть и такая тактика - мне она со временем перестала быть интересной в профессиональном отношении, во всяком случае, если реализуется только или преимущественно она), чуть меньше менторства на пустом месте. И уж точно без попыток "монополизировать реальность" - расписаться за то, что происходит "в реальности" - слишком самонадеянно и опрометчиво, ибо в реальности никто не владеет ситуацией на всех сотнях предприятий, локализованных в ЕАЭС. Я пообщался с некоторыми представителями инженерных и ИТ-отделов в РБ и РФ, с удовольствием узнал бы ситуацию на контрактных площадках международных ТНК - типа Novonordisk или Acino (к примеру). Валидационные пакеты есть разные - ни в них вопрос на самом деле, а в данном случае, прежде всего в самом решении. Сайт РЖД работает, Яндекс.Такси и интернет-банкинги тоже. МДЛП - пока нет. Значит нужно поинтересоваться в Москва-Сити "в соседней башне" как развиваются "некосячные сервисы" сопоставимого масштаба 🙂 Маленькая подсказка - SDLC. Тут собственно валидация - дело десятое, сугубо вспомогательное. Мне известны российские предприятия в провинции, внедрившие ELMA - вот их опыт интересен, а не "всепропальщиков" 🙂

Мне искренне жаль, что наши профессиональные взгляды разошлись так радикально, что моя точка зрения воспринимается как инсинуация.

Я чувствую себя предателем высоких идеалов, променявшим Божий дар на чечевичную похлебку.

Ты абсолютно прав и в свое оправдание мне сказать нечего.

Не принимай ни в коем случае на свой счёт, Кирилл! 😉 Тут дело в том числе и в трансформации некоторых моих взглядов - я стараюсь не участвовать в проектах, где меня либо вынуждают "нарисовать" результат, либо исказить. Такие попытки и такие ситуации, безусловно, существуют. Стараюсь прекратить взаимодействие. Потому что в противном случае никогда не научишься, как делать рабочий продукт или сервис 🙂 Но не осуждаю тех у кого, возможно, такого выбора нет и суровая действительность вынуждает делать gute Miene zum boesen Spiel.

Возвращаясь к теме. Коллеги, может кто-то поделится опытом внедрения подобных систем (даже безотносительно валидации)? Владимир, в Украине нет ЦРПТ/МДЛП криптохвоста - как там обстоят дела? Хотя бы укурпнённо.

У белорусов другая фишка при экспорте на РФ. Чёрный ящик от ФСБ не может быть им поставлен, как нерезидентам РФ - т.е. массивы кодов экспортируются на линии. У меня пока тоже весьма скудные сведения, как это работает. Судя по обращению АРФП основные проблемы возникли даже не на производствах, а в дистрибьютерской и аптечной розничной сети.

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

Было сложно все настроить правильно, так как интерфейс с ERP работал немножко не так как хотелось, за два дня все пофиксили. Сейчас ждем первые серии на экспорт в Россию, должно все получиться, все работает.

По времени, проект затянулся почти на год. По человеко-ресурсам оценить сложно, из CSV один человек занимался этим целый год и иногда подключали второго. По ИТ специалистам – роботы хватало всем, как и инфраструктуре так и менеджерам приложений. Так же поставщикам (их два – линия и софт) пришлось поработать не мало и они сделали все на 5+, даже FAT на удаленке и помощь в сборке линии на заводе в онлайн режиме (через карантин они могли приехать).

В Европе немного проще, там это уже на рельсах и работает как часики.

Ближайшее года в таких проектах будет много страданий и боли, пока не станет для нас всех обычным делом.

1

Многое уже написали и в целом согласен с Александр.

Поделюсь своим скучным опытом:

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

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

По софту, нужно максимально детально все описать, как написал Александр, чтобы будущим поколениям было понятно как инсталлировалось, какая конфигурация, какие порты куда и для чего открыты, что тестировали и почему. Скорее всего, софт попадает под 4ю категорию по гампу, соответственно и пакет документов для неё нужен. Единственное что лучше логически разбивать все по модулях/секциях, а не делать огромные тест скрипты или конфигурацию. Документов будет (должно быть) много и причём без "воды", описывать есть что.

Передача данных в регулятор тоже часть валидации - зачем иметь машину если она никуда вас не везёт?

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

P.s. когда читаю что кто занимается валидацией серилизации, мой мозг это читает как кто-то сейчас страдает 😀

0

Присоединюсь к обсуждению. Вернее, подкину на вентилятор.

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

Подсказки можно искать у поставщиков оборудования сериализации и на больших дистрибьюторских складах. Там уже есть небольшая практика.

Канал связи с ЦПУ в телеграмме пару месяцев назад имел печальный вид.

Поделиться: