Если бизнес принимает решение, что при слёте контроллера он согласен всё восстанавливать с нуля (остановив работу на неопределенное время), то, по сути, это его право при условии сохранения всех ретроспективных распечаток.

Мое мнение "бизнеса" должен брать в расчет все варианты. Если мы про PLC проекты то шансов найти на рынке контролер с такой же прошивкой как у "7-летнего контролера" практически равен нулю, а все что выше необходимо подымать версии(применительно не только к TIA...) среды разработки, для этого необходимы исходники "рабочие проекты"+ желательно "сертифицированный" инженер:)... или обратится к производителю(если он еще в "адеквате" и получить ценник на все это с 4 а то и 5 нулями:)))

Опубликовано: @messer

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

Чтобы это работало на 99,9% при закупке оборудования необходимо по моему мнению покупать еще два контролера и две панели оператора:)... один комплект для оперативной замены (с установленными  и протестированными на заводе прошивками), и один комплект электроникам поиграться:)... но никак не меньше... бо второй комплект будет через пару лет бесследно утерян:)

Опубликовано: @messer

все существенные данные

:) вот и вы Александр понимаете что само определение "данные" требует уточнения применительно к конкретному случаю... спасибо за развернутый ответ.

Это связано с тем, что не все результаты анализов, документы разные, есть в печатном виде. Ведь в 21 столетии живем, зачем держать все на бумаге, когда есть различные комп системы?

А бэкап системы нужен для того, чтобы можно было корректно отобразить и прочесть данные. (Это как раз ответ, почему часть данных может стать бесполезной: ведь не всегда структура «одной» записи в какой то системе, является одним полем в таблице баз данных, в большинстве случаев, то что можно увидеть на мониторе, например результаты анализов в LIMS по какойто партии, запись о каком то несоответствии в системе по управлении изменениями и отклонениями и т.д., будет подтягиваться из разных таблиц базы данных, в некоторых случаях из разных баз или даже с разных серверов. Хотел бы я посмотреть, как кто то будет делать восстановление таких данных (GxP related)  и собирать по все по кусочку (требование о архивации данных никто не отменял), если резервная копия будет сделана не синхронно со всей системой или же даже без бэкапа самой системы. Это будет больно.)

Без этого, всегда есть риск простоя бизнеса и соответственно поставок ЛС на рынок. А так, восстановления данных из бэкапа, и восстановление системы с нуля уже протестировано, ответственный персонал с IT Infra I BA уже знает как чинить ту или иную систему (GAMP хорошо описывает ети процессы). Все процессы и персонал который ответственный за ту или иную систему, задокументированы. Все по фен Шую)

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

   Вопрос вызывает понятие "данные". Требует уточнения вопрос о каких данных в данном документе идет речь. Вики трактует:

Понятие "данные" вопросов не вызывает - и Вики-трактовки тут избыточны - есть отраслевое определение MHRA "GxP" Data Integrity Guidance and Definitions:

Вызывает вопрос только их GxP-релевантность. В определении MHRA (которое охотно подхватывают руководства ISPE GAMP) GxP-релевантные данные - это те данные, которые позволяют реконструировать GxP-деятельность.

А вот теперь уже интерпретация этих определений на примере. Но прежде чем в это влезть ещё одно определение из MHRA - что такое целостность данных:

Обращаю Ваше самое пристальное внимание на оборот "is the degree to which data are" - т.е. степень, в которой данные <полны, последовательны, точны и т.п.> - у меня пару лет назад была очень жесткая заруба с американскими SME Pfizer на эту тему - формулировки MHRA пришлись весьма кстати - там речь шла о contemporaneous, т.е. о своевременности регистрации данных для восстановления GxP-активности. По итогу реконструировать цикл стерилизации удалось, причем отбив именно параметр своевременности.

Дам свежий пример как раз по стерилизации (на этой неделе). Откровенно говоря, возьмем банальную распечатку со стерилизатора BMT Unisteri (серийный номер стерилизатора намеренно обрезан): 

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

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

В случае epic-fail мы в общем то можем заменить контроллер и если у нет резервной копии его прошивки, то данные рецептур можно восстановить с нуля. Но тут нужно быть внимательным. Вот данные по циклу - которые видит оператор:

А вот данные в сервисном меню (фрагмент):

С одной стороны данные параметров рецептур не так важны именно для реконструирования GxP-деятельности - тут важна сама распечатка с регистрацией параметров прошедшего цикла (а также табличные данные по таким циклам, графики и т.п.). Но если слетела прошивка контроллера, то тут вопрос не реконструкции, а продолжения дальнейшей деятельности - т.е. о непрерывности бизнеса.

Вот на данном примере и показан вариант "всамделишнего" анализа рисков и оценки согласно Приложения 11 GMP "необходимых данных" для резервного копирования.

Если бизнес принимает решение, что при слёте контроллера он согласен всё восстанавливать с нуля (остановив работу на неопределенное время), то, по сути, это его право при условии сохранения всех ретроспективных распечаток.

Если все ретроспективные распечатки не сохранены (так или иначе - в бумажном виде, в специализированном ПО BMT Print Archive, на SD-карте) - то нет возможности реконструировать GxP-деятельность.

Повторюсь, курсивом выделен пример и моя частная, субъективная интерпретация. Выше, с ссылками на MHRA - регуляторные требования.

Качественной интерпретации способствуют в т.ч. тексты некоторых FDA Warning Letters в части data integrity :))

Например что то случилось с системой и она стала не работоспособной,

И что мы тут хотим валидировать???? :)

Опубликовано: @volodymyrkoval

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

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

Опубликовано: @volodymyrkoval

но для бизнеса все наоборот – ему нужна бесперебойная работа всех ИТ систем.     

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

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

А если уж говорить о таких системах как LIMS, EMPOWER, TrackWise, DrugTrack & DocuBridge, SAP, SAP S/4HANA, прочих ERP или Т&T системах, та даже и систем поменьше, так отсутствие бэкапа системы может очень болеть в критический момент.   

Но так же с вами соглашусь, для большинства аудиторов важна резервная копия самих данных (результаты анализов, контрольный след…), но для бизнеса все наоборот – ему нужна бесперебойная работа всех ИТ систем.     

Оптимальный вариант – иметь синхронный срез данных и системы. Тогда с большой долей вероятности восстановление будет быстрым и не таким болезненным для бизнеса. А вот что нужно бэкапить, с какой переодичностю, типы бэкапов - это уже целая история :)        

Тот факт, что резервные копии делать нужно - вопросов не вызывает.

   Вопрос вызывает понятие "данные". Требует уточнения вопрос о каких данных в данном документе идет речь. Вики трактует: Данные — зарегистрированная информация представление фактов, понятий или инструкций в форме, приемлемой для общения, интерпретации, или обработки человеком или с помощью автоматических средств (ISO/IEC/IEEE 24765-2010). Мое мнение "акцент" Приложения 11 GMP на данные формируемые системами, это могут быть логи, протокола, база данных SCADA и т.д. но не как не исходный код(автоматических средств) в котором может быть и интеллектуальная со́бственность и т.д. Поправьте если не прав.

Рискнувших её выполнить "просто так"

Запоздавшая валидация и невозможность оценить работоспособность копии - замечательное сочетание).

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

Заметьте, речь о данных стерилизации не идёт. Это другой случай.