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

Правила виноделов

  1. Правило четырех исправлений
  2. Чем больше сделаешь сегодня, тем больше завтра исправлять
  3. Поторопишься, разгневаешь бога валидации
  4. Любое шевеление должно быть произведено таким образом дабы избежать шевелений в дальнейшем

Комментарий

  1. Любой документ при любом исходном состоянии должен быть переделан 4 раза. После четвертой правки мы либо приходим к исходной версии документа, либо получаем абсолютную ересь, которую читать не будет никто и никогда.
  2. Вытекает из первого пункта. Главное найти баланс. Чтобы с одной стороны все были уверены в том, что мы в поте лица трудимся с другой стороны избежать лишних шевелений.
  3. Иррациональный момент. Успешная валидация определяется сумой двух компонентов: Фактический валидационный статус объекта, отсутствие косяков у валидаторов. Если что либо делается впервые, либо не по стандарту, либо включает в себя наладочные работы, то вероятность успешной валидации зависит только от Него.
  4. Это с годами приходит. Забейте в youtube «Порожняк фитиль»

Общие проблемы:

  1. Завышенные требования к оформлению валидационных документов при отсутствии понимания работ по существу.
  2. Очевидная бессмысленность большинства работ по причине идеологического отказа от требований GMP.
  3. Реальные работы (Проводимые по-настоящему) всегда приводят к отклонениям/несоответствиям, которые всегда приходится скрывать, что обессмысливает и убивает энтузиазм и демотивирует. Этот пункт вытекает из предыдущего, но он настолько огромен, что я вынес его отдельно.
  4. Отсутствие на предприятии по существу инженерной службы, Административно-хозяйственного отдела, отдела обеспечения качества приводит к тому, фактическая деятельность группы валидации весьма сильно отличается от ожидаемой. Списки, перечни, инструкции, договора, доставка и ремонт, обучение, работа с НД и ТД заморских стран. Как я уже сказал – отрицательные результаты никому не нужны, поэтому группа валидации становится ГДУ – «группа доведения до ума». Выявленное отклонение необходимо устранить. Если оно не устранимо, то виртуозы подгонометрии или обтекаемых формулировок…
  5. Корпоративная шизофрения. Это когда все знают как должно быть и игнорируют действительное положение вещей.
  6. Фиктивный документооборот. Система документооборота заточена под написание фитюлек задним числом. Поэтому актуальная информация отсутствует как класс, что сильно осложняет работу.

Компьютеризированные системы

Валидации на фармпроизводстве подлежат следующие компьютеризированные системы:

  1. Система мониторинга температуры и влажности.
  2. Система складского учета (1С:)
    (Далее для продвинутых)
  3. Система электронного документооборота
  4. Система контроля параметров чистых помещений.

(Далее до бесконечности по мере продвинутости)

Де било
Дано:
Система 1С:, либо система мониторинга температуры и влажности состоящая из российских датчиков, бесплатного (условно, ну 100$ не деньги) ПО и всяких вспомогательных приблуд.
Системы установлены давно (10 лет назад), есть инструкции от изготовителя, но никаких внутренних инструкций (спецификаций) нет. Системы работают нормально, т.е. нареканий и вопросов к ним нет. Нет в том смысле, что персонал нашел решения проблем далекие от GMP Compliance.
Потребность в валидации возникла тогда, когда приехал аудитор из … и сказал: «Надо!»
Диспозиция определена, приступили.
Ответственным за выполнение становится самый бесправный человек на предприятии – специалист по валидации с небольшим опытом работы. Первым делом он заходит на форум и задает вопрос … в теме.
Получив ответ подобный этому, а не приведи господь, пройдя какое-либо обучение начинает громко плакать о своей судьбе и приставать к коллегам с невыполнимыми просьбами и пожеланиями.
Специалист с бОльшИм (куда хотите ставьте ударение) опытом поступит по-другому.

  1. Нужно открыть в электронном виде 916 приказ и скопировать в отдельный файл всю необходимую информацию по КС.
    Ключевыми моментами является то, что должны быть СОП по Обслуживанию, эксплуатации, архивированию, резервному копированию. То написано прямым текстом, не отвертеться. Далее, необходим такой документ как спецификация. В этом документе должна быть вся информация, которую удастся собрать по этой системе.
  2. Провести совещание с коллегами. Им нужно рассказать про 916 приказ, показать тот файлик, который вы сделали в п.1.
    «Программа – это код. Что там обслуживать?» – это не я придумал, это наш ойтишник. Скорее всего, после этого совещания все уйдут в глухую несознанку и все СОПы и спецификации придется писать вам. Ну т.е. специалисту по валидации. Что могу сказать – пишите, как сможете, чем дибильней тем лучше. Будете получать садистское удовольствие глядя на то как вашим коллегам приходится это подписывать.
  3. Получить доступ к системе.
    – поставьте нам 1С.
    – нельзя, мы в ней зряплату считаем.
    – пустите в ней кнопки понажимать.
    – нельзя, мы заняты.
    😆
    – а систему мониторинга температуры?
    – вам она не нужна, вы ж ей пользоваться не будете. Вам ее только отвалидировать и все.
    😆
  4. Приступить к работе.
    Требование
    Для примера и что б два раза не вставать. Это определение объема работ или его можно назвать DQ при желании.
    Спецификация
    Пример спецификации. Обращаю ваше внимание на пункты “Владелец процесса” и “Владелец системы” очень у нас этого не любят, но прогресс неумолим, потому стойте на смерть.
    Протокол

Перечень и краткое описание тестов которые возможно провести. Расширять можно, при желании сотрудников (а не специалиста по валидации!!!) наводить порядок и разбираться в системе. Например удалять пользователей “Пусечка” или выяснять, почему датчик температуры показывает температуру на марсе по субботам. Вообще примитивность протокола символизирует не лень и неграмотность специалиста по валидации, а нежелание открывать ящик Пандоры. Например распечатывание графиков с температурой и влажностью ВНЕЗАПНО вызывает вопросы к работе вентсистем и к микроклимату в помещениях (там где автоклав и стерилизационный тоннель, например). И связи с тем, что сотрудники пишут в протоколах микроклимата и протоколах валидации чистых помещений 🙂 . Напомню, что компьютер отличается от человека тем, что у него совести нет.

Де факто
Дано:
Система электронного документооборота (СЭД) внедряемая в настоящее время (+-) опытными и грамотными людьми с западной бизнес моделью. (Не знаю как это правильно назвать, но суть в том, что люди делают все правильно и документы все нужные для работы у них есть).
Диспозиция определена, приступили.
Проблема в том, что компьютерщики бегло читали приказ 916 и VMP-DQ-IQ-OQ-PQ у них нет, но зато есть, техническое задание, описание системы, история изменений… короче все что нужно.
Работа сводится либо к разработке протоколов на основе их документов либо делаем протоколы со ссылками на те документы которые есть (так проще).
Работать в этом случае одно удовольствие – все как у взрослых.

Де юре
Комрад Александр Белинский пишет все правильно, читайте, спрашивайте, делайте как он скажет или наймите его на работу 🙂
PS. Все написанное является не более чем плодом воображения автора и не имеет никакого отношения к действительности.

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

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

2 коментарі до “Валидация компьютеризированных систем Де юре Де факто Де било”

  1. Kirillcheg, прочитал Ваш блог про валидацию Де юре Де факто Де билло, очень понравилось видео про порожняк.

    Вы описали Общие проблемы, как будто прямо у нас на предприятии работаете)), все точно так как написано, и вся работа сводится к тому, чтобы бы при инспекции все было ОК.

    Теперь по пунктам, прочитал Вашу URS, сравнил со своей и понял, что написал полное убожество (брал инфу вот отсюда и отсюда). Поэтому придется переписывать.

    Так что вопросы еще будут.

    Спасибо!

  2. Благодарю за рекламу 🙂 На самом деле, я бы настолько не сгущал краски (и уже тем более не переоценивал бы свои скромные познания). Давайте вспомним, что мы делаем, когда нам поручают принципиально новую задачу? Как правило, сначала читаем литературу, осваиваем базовые понятия.

    Для ВКС (валидация компьютеризированных систем – устоявшийся термин CSV = computerized system validation) есть сразу два мощных подспорья. Во-первых, в диковинку это только у нас, а во-вторых – только в фарма 🙂

    Чисто в ай-ти есть своё кью-эй и развито оно очень неплохо. Говоря о фарма мы часто с вами забываем, что ВКС имеет значение главным образом на этапе разработки, когда есть обратная связь с разработчиком и вы можете повлиять на него на основании результатов тестирования. Вот пример из “обычного ай-ти”, той же вэб-разработки. Вы открыли интернет магазин, вам важно ДО запуска вашего проекта протестировать, что клиент при выборе товара не только получает его отображение в своей корзине заказов с уведомлением на почту, но и в базу вносится соответствующая запись. Потому как если эта шутка не сработает ПОСЛЕ запуска проекта, то клиент, не сумевший приобрести товар навсегда забудет ваш адрес – в этом случае уже поздно что-то тестировать 🙂

    С обычного QA в IT и следует повзаимствовать, как формируются тест-кейсы, тест-комплекты и тестовая стратегия.

    Второй момент – есть куча англоязычных ресурсов с простыми и доступными статьями на тему уже применительно к фарма.

    Работа сводится либо к разработке протоколов на основе их документов либо делаем протоколы со ссылками на те документы которые есть (так проще).

    вы не поверите, но именно такая фраза есть в книге Дэвида Стокса (David Stokes) Validating Enterprise System – вы интуитивно пришли к тому, что логично и обоснованно – зачем переписывать тонны бумаги, если поставщик в любом случае проводит формальное тестирование продукта при сдаче его вам в соответствии с договором – вы вполне можете идти в кильватере его программы приемочного тестирования.

    И в завершении, ещё раз подчеркну своё ИМХО – Приложение 11 сGMP – это на процентов 70-80 ITSM & ISMS практики. Если ваше IT-подразделение знает, что это за аббревиатуры и уж тем более им следует, то и ваша задача по регуляторному соответствию большей частью уже выполнена. Уникальными являются только пункты в отношении уполномоченного лица или выпуска серии, потому что это уже фарма-специфика. Ни SLA, ни URS, ни даже анализ рисков не смутит специалиста, например, уровня CCNA Security (градации сетевиков от CISCO) – не отнимайте у них их хлеб, а просто взаимдействуйте с ними. Я просто совместно с ними прохожусь по требованиям GMP, они как правило сами, дают большинство ответов и делают это грамотнее, чем это сделал бы это я сам.

    Не мучайтесь, понимая под ИТ-инфраструктурой исключительно “инвентарные номера ПК и версии ОС” (утрирую) – попросите ИТ-специалиста сделать распечатку карты сети из скорее всего используемого ими ПО NMS (Network Monitoring System) – большинство админов ведь ленивые – предпочитают дистанционно наблюдать за сервисами и автоматизированном режиме (лежит сервис или нет) – это решает куча программ, включая freeware, например, тот же Dude 3.6 – у вас будет и логическая схема сети вменяемая (не нарисованная “завхозом”) и, что главное, актуальное состояние задокументировано. Проведена ли виртуализация сети (что по каким VLAN’am бегает), если да, чем проведена виртуализация (VMWare, Hyper-V). Что используется для резервного копирования (и используется ли), как тестируются резервные копии и тестируются ли. Для последнего есть такие интересные решения типа продуктов Veeam, где работоспособность резервных копий проверяется в автоматизированном режиме без необходимости их разворачивания в тестовой среде.

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

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