Уважаемые коллеги,
Сейчас работаю над интересным заданием, разработать подход для валидации ПО 5й категории в разрезе постоянной разработки и постоянного апдейта систем для пользователей.
Итак, тема довольно не новая, Agile тоже известен давно, но изначальное отсутствие формальности и документации сделало его несовместимым с регулируемой средой и фармой.
Сейчас, у нас увеличивается количество ПО 5й категории и собственных разработок для бизнеса, которые попадаю под сферу влияния GxP, соответственно требуют валидации.
Но вот в чем вопрос, стандартный подход по валидации абсолютно не приспособлен к новым реалиям – если делать пакет необходимых документов на каждую итерацию обновления, это потребует целого отдела валидации и тестировщиков. Ну и много формальных процедур вдогонку – контроль изменений никто не отменял.
Сейчас я пришел к тому, что нужно использовать возможности отслеживания изменений кода, описать корректно этапы разработки и чек поинты, когда код может переходить из одного этапа (разработка в Dev среде, в Qual и затем в Prod) и какие действия нужно выполнить для каждого этапа. С этим немножко разобрался, но остались открытие вопросы:
- Валидация среды разработки, нужно ли? Я пока думаю что нет, считаю что достаточно иметь задокументированную процедуру разработки и следовать ей, инструменты здесь второстепенные. Но вопрос по-прежнему открыт.
- Как бить с документацией? Будет ли применимо держать все в этой же среде или нужно все переносить на бумагу? Сразу скажу, возможности пока утверждать документы, как это описано в ISPE Records & Data Integrity пока нет. Формально отсутствуют электронные подписи, но есть простой этап утверждения чего-либо вторым лицом.
- Тестирование изменений – как лучше или как верно описать применение автоматического тестирования и для каких модулей/функций его можно применять? Здесь стоит отметить, что делать постоянною оценку рисков что можно тестировать автоматически, что нет просто нереально, большинство случаев уникальны. Так же группировка объектов не сильно применима – большинство «объектов» нужно рассматривать индивидуально так как у все разная критичность.
Коллеги, если у вас есть опыт в этой теме, буду рад вашим комментариям и наставлениям.
Так же, если тема интересна, вот здесь можете немного почитать об этом:
https://www.trialgrid.com/blog/continuous_validation_2019.html
Очень рад вашему ответу, так как уже начал думать что пишу непонятно о чем ещё и мимо кассы).
По поводу TrialGrid, это только пример реализации, я не работаю внутри компании разработчиков софта, напротив, я потребитель, штатный «ИТ валидатор» и заинтересован в полном соответствии ИТ требованиям GxP/GAMP и понятно всего софта, который попадает под мой контроль.
Сперва попробую прокомментировать реальные кейсы, которые вы упомянули.
Например, при учете движения сырья, материалов и готовой продукции требования GMP не меняются годами, а иные - и десятилетиями. Скажем, согласно п. 4.23 GMP записи по приёмке сырья должны включать в себя совершенно конкретные позиции. Так в чём возникает необходимость частой доработки программных решений, реализующий подобный учёт?
К счастью, таких кейсов у меня не было. Все это уже есть на рынке и не нуждается в разработке кем-либо. Мы всегда стараемся найти готовое решение (3 и 4я категории по гампу) и практически всегда они есть (стоит только упомянуть продукты TrackWise, DrugTrack, DocuBridge, SAP, Amplexor с их модулями). Можно покрыть все производство от закупки сырья до реализации ГП. К тому же, доработка такого софта разработчиками практически невозможна, еще ни разу не слышал что бы хоть один поставщик софта был заинтересован создать какой-то особый пакет инсталляции для компании и потом отдельно работать над его обновлениями. Им такая головная боль не нужна это точно.
Но когда уже совсем нет другого пути, и нужно что то автоматизировать, но такого продукта на ринке нет или все не то, приходиться просить чтобы кто-то что-то написал для нас иле же чтобы наши разработчики что то набросали и сделали бизнес немножко счастливее.
Как раз частично в этом и прячется моя «беда», так как изменения не очень быстро могут бить реализованы и зачастую требуют много работы для всех. И это прямое последствие устаревших доктрин ИТ в фарм индустрии.
Я немного продвинулся с момента написания поста здесь и вот к чему я пришел:
Я разделил валидацию софта 5й категории на два больших этапа:
1. Разработка (development) – осуществляется в большинстве случаев сторонней организацией, и реже внутри компании.
2. Операционное функционирования (operational) – здесь все согласно SLA. Но пока бытует мнение, что такой софт на поддержку лучше забирать себе, если это возможно, так как иногда время реакции и исправления ошибок в системе может занимать значительное время, что не всегда уместно. Если компания разработчик достаточно ответственная и професиональная, то можно оставить поддержу им. Здесь мы работаем от случая к случаю.
1. В первом этапе мы будем использовать "обычный" подход, который написан в GAMP5 (HLRA-URS-VP-FS-DS-CS-IP/IQ-FAT/SAT-UAT-TM-VR), когда нам по сути "без разницы" как будет пилиться софт. Нам главное что бы когда мы его отвалидируем, все изменения были под контролем и их можно было быстро имплементировать. Я вижу, что в моем случае это будет более эффективно, нежели мониторить разработку каждого модуля и его тестирование до полной готовности и передаче нам, как заказчику. При чем, никто не запрещает так делать ?
2. Вот именно на втором этапе и выходит Agile подход, мы переходим от части бумажных документов к электронным и среда разработки у нас уже является единственным источником первичной информации (SSOT).
Как я вижу часть изменений в системе и их валидацию: когда есть необходимость, бизнес, все же делает официальный запрос на изменение в софте. Это точка входа. Чтобы бизнес бил осторожен со своими желаниями, он должен предоставить подписанный и согласованный (с внутренними разработчиками) URS (внешняя разработка сейчас не входит в этот пост и тему, так как это уже полная ответственность поставщика софта и мы не можем контролировать его среду разработки).
Далее разработчик, имея URS и официальный зелёный свет от валидаторов и ОКК (у нас отдельный отдел валидации для комп. систем и отдельный человек в ОКК ответственные за ИТ системы), заводит этот URS к себе в среду разработки. Там весь URS имеет свой код (master ID), также все требования из этого URS имеют свой код (slave ID по отношению к Master ID). В зависимости от изменений, к этим требованиям может быть додана часть информации про то как требования будет реализовано (что то типа аналога спецификации дизайна и функциональной спецификации). Затем разработчик, реализует все это, разворачивает изменения в песочнице (DEV env) и просит бизнес протестировать без всяких официальных тестов. Если бизнес реализация устраивает, изменения проходит дальше и код разворачивается в тестовой среде (QUAL env). На этом этапе, сперва происходит пересмотр кода вторым разработчиком. Если все ок, то далее начинают создаваться уже официальные тестовые документы для этого изменения. Тестируем, возвращаем разработчику результаты тестов и он делает запрос на обновления системы в продуктиве (PROD env). Второй, условно говоря, независимый разработчик, который владеет тем же языком разработки и делает утверждения кода в продуктив.
В результате, у нас есть вся информация в среде разработки касательно того, что нужно было сделать и как это будет реализовано, у нас есть пересмотр кода с его утверждением, у нас есть документы с тестированием. Так же, информация из среди разработки может быть напечатана по запросу.
Может что упустил, но вроде как то так ?
Буду рад конструктивной критике и замечаниям.
Есть предложение, может сделаем маленькую встречу в скайпе или MS Teams или что там у кого есть?
Позовём всех кто в теме, поделимся опытом, подумаем как лучше действовать, может кто то сможет увидеть скрытые камни, которых раньше не замечали и потом сделаем апдейт здесь или отдельной новостью на портале?
Так и самим подумать прийдеться и может другим пригодится.
- Валидация среды разработки, нужно ли? Я пока думаю что нет, считаю что достаточно иметь задокументированную процедуру разработки и следовать ей, инструменты здесь второстепенные. Но вопрос по-прежнему открыт.
Владимир, благодарю, что затронули топовую тему! Сейчас я в некотором цейтноте, но немного освобожусь и обязательно отвечу обстоятельно. А пока только по цитате выше - в достаточно давнем документе - интерпретации CoP GAMP 11-го Приложения GMP - сообщество практиков GAMP заключает, что валидировать тестовые инструменты и тестовые среды обычно не следует:
Почему-то сейчас этот документ ISPE сделали платным, хотя он лет 5 болтался на сайте у них в открытом доступе - ну или сейчас я не могу его найти у них поиском и пользуюсь скачанной давней версией 🙂 Впрочем, поиском гуглятся множественные его пересказы.
Вместе с тем достаточно просто и самому обосновать, почему такое тестирование избыточно. Просто немаловажно, что сообщество практиков GAMP пришло к такому же выводу.
Владимир, вы на самом деле подняли тему, которая потихоньку выходит на передний план, в т.ч. и в виду ужесточения требований в части data integrity - т.е. "изменения втихаря" уже сейчас санкционируются в полный рост, причем с самыми драматическими последствиями.
Я ознакомился в первом приближении и ссылками - весьма изящные подходы, впрочем, предусматривающие довольно высокую степень зрелости разработчика - скажем, действия TrialGrid с использованием GitLab - это хороший уровень - ведь в наших широтах, увы, достаточно большое количество разработчиков используют понятие "Agile" просто чтобы оправдать своё бездействие и "мнимый гибкий подход."
Для желающих действительно разобраться в вопросе я же предложу попробовать совместными усилиями разобрать тему на составляющие с самых азов.
Мой первый встречный "вопрос дилетанта" в отношении возможности применения подходов Agile таков: "Фарма - очень консервативная и зарегулированная отрасль. Например, при учете движения сырья, материалов и готовой продукции требования GMP не меняются годами, а иные - и десятилетиями. Скажем, согласно п. 4.23 GMP записи по приёмке сырья должны включать в себя совершенно конкретные позиции. Так в чём возникает необходимость частой доработки программных решений, реализующий подобный учёт? Уж не "кривая" ли изначальная реализация "на бегу", без URS, на авось?"
Разовью пример с п. 4.23 (формулировки на примере Решения № 77 ЕЭК, но, понятное, дело что может быть взяты и региональные варианты или сам оригинал GMP EU, chapter 4):
По хорошему эти требования должны попасть сразу в URS, процесс приемки сырья и материалов смоделирован на бумаге, "проигран", "покритикован", "обстрелян" в тестовой среде. В период разработки и тестирования может быть множество итераций. GitHub, GitLab, JIRA могут использоваться разработчиками на этапе разработки и тестирования, но, строго говоря, GMP позволяет вести разработку произвольно. GAMP рекомендует придерживаться хороших ИТ-практик, но GMP кроме URS (п. 4.4. Приложения 11) и актуализированного (текущего) описания системы (п. 4.3 Приложения 11) ограничений не накладывает. И, предположим, мы вышли в продуктив.
Вот тут уже да, GMP накладывает в фазе (стадии) эксплуатации ограничения в виде п. 10 в Приложении 11:
Аналогично по инцидентам. Вопрос, что должно быть с процессами не так, чтобы мы их "пилили в продуктиве" через день? Сами требования к процессам не меняются. Основной сектор поиска - процессы изначально были спроектированы "мимо кассы"? Ну тогда это не за счёт Agile решается, точнее вовсе не в нём причина 🙂
Было бы здорово постараться совместными усилиями развить эту тему за счет конкретных примеров (можно обезличенных), тогда может удастся приблизиться к пониманию вопроса.
P.S.: валидационный портал у TrialGrid крутой, но, боюсь, что создание подобной шутки ещё более ресурсоёмкое, нежели чем выделение ресурсов (временных и персонала) внутри организации для "ручной реализации" п. 10 Приложения 11 GMP. Хотя идея очень классная и со стороны разработчика, действительно закрывает целый комплекс вопросов и увеличивает их селективные преимущества на рынке. Но у TrialGrid есть миссия компании. В наших широтах в терминах миссии и визии разговаривать серьёзно, с сущностным наполнением терминов, пока могут "не только лишь все" (с) 🙂
Как и обещал, небольшой follow up.
Процедуру, костяк которой выше в теме, разработчики приняли и одобрили. Так же данный процесс оброс двумя приложениями – требованиями к разработке бизнес приложений и требованиями к веб разработки сайтов. Там уже чисто технические требования сделанные под наши потребности и среды разработки.
В ближайшем будущем «обкатаем» СОП в реальной обстановке. Надеюсь все пройдет гладко без отклонений от процедуры 🙂
