Валидация компьютеризированных систем – кто о ней говорит в контексте «обычных» IQ, OQ, PQ?

В заголовок вроде бы как вынесена крамола. Но при ближайшем рассмотрении выяснится (и очень быстро при этом), что не совсем. Многочисленные семинары говорят нам «по инерции» (вызванной традиционным квалификационным подходом), мол, на стадии IQ мы проверим монтаж, на стадии OQ мы прощёлкаем такие-то кнопки/функции и т.п. Причем семинары достаточно высокопоставленные! ECA в солнечной Германии, британские CVS, FAVEA, в Руководстве ГИЛС и НП «Целостность данных и валидация компьютеризированных систем» также предложено разбиение на эти фазы. Но есть пару «но» 😊

Сразу оговорюсь, что автор не ищёт каких-то особых способов поднять «хайп» или бросить «вызов передовой общественности». Просто предлагаю ещё раз взглянуть на очевидные факты. Кроме того, подходы уважаемых вышеперечисленных контор вовсе не является несостоятельными! Речь только о том, что возможен не один путь достижения регуляторного соответствия и построения валидных систем.

Так вот об IQ, OQ, PQ. Эту терминологию упорно не желает использовать… GAMP 5. Более того, давайте вчитаемся в текст основного принципа Приложения 11 GMP:

Итак, применение компьютеризированный системы (КС) должно быть валидировано. Вы где-то встречали в рамках валидации процессов IQ, OQ, PQ, в валидации очистки, в валидации аналитических методик? 😊 Эта терминология (IQ, OQ, PQ) привязанная по своей сути к квалификации, а квалификация выполняется в отношении помещений, оборудования и систем (обеспечения производства). Да, есть указание, что ИТ-инфраструктура должна быть подвергнута квалификации. Тут в общем-то согласиться можно, т.к. схему локальной вычислительной сети (ЛВС) сделать можно и нужно, спецификацию на серверы, маршрутизаторы и коммутаторы иметь необходимо, более того, конфигурация этих элементов должна быть вполне определенной и задокументированной. Впрочем, к этому нас призывает банальный ITSM/ISMS (стандарты серии ISO 20k и 27k).

Но вернемся собственно к валидации КС и V-моделям, предложенным в GAMP 5. Давайте ещё раз актуализируем в памяти, как изложены эти модели в рамках упомянутого руководства ISPE. По правде говоря, по тексту GAMP 5 неоднократно упоминается то, что при желании специфические для тестирования КС термины можно «выровнять» с «обычной» квалификацией, но каждая компания решает этот вопрос индивидуально:


Впрочем, вот и пресловутые V-модели GAMP — на них вы не найдёте привычных глазу  IQ, OQ, PQ.

Это простенькая V-модель для категории GAMP 3.

Для 4-й категории GAMP – где мы можем сконфигурировать КС – уже добавляется функциональная и конфигурационная спецификация.

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

Ещё в приложениях GAMP 5 можно наковырять такие дивные пассажи:

Конечно, тут важен контекст, а речь в последнем случае идёт о выравнивании с ASTM E 2500. Тем не менее. Вот хорошая обзорная статья на тему современной версии ASTM E2500, которая выровнена с многочисленными документами ICH и FDA cGMP.

Автор многочисленных работ по валидации систем ERP Дэвид Стокс (David Stokes) – его основная мысль предельно проста, мол, не выламывайте руки айтишникам. Например, тот же ERP SAP будет внедряться только по методологии ASAP, разработанной  в Walldorf’e – неважно, внедряется ли этот продукт в Bayer, Deutsche Bahn, Deutsche Bank или Berliner Chemie. Solution Manager ERP SAP даст вам доступ в четыре (!) среды – DEV, QAS, PRD (четвертая – сам SLM – управление решениями). Функциональное тестирование и разработка будет только в среде DEV и никак иначе, интеграционное тестирование в среде QAS (quality assurance), опытно-промышленная эксплуатация – только в среде PRD (productive). Набор этапов будет состоять всегда из 5 шагов:

  1. Устав проекта
  2. Разработка проектных решений
  3. Функциональное тестирование
  4. Интеграционное тестирование
  5. Опытно промышленная эксплуатации

Вы можете рисовать себе любые V-модели, действия интегратора от этого не поменяются.

Аналогичная ситуация с 1С:ERP или разного рода LIMS системами. Кроме того, сама ИТ-практика включает различные возможные модели – Waterfall (водопад), спиральная модель, методология Agile – далеко не все они сводятся к V-модели, которая – вы будете смеяться – прямо GMP не регламентирована 😊

На просторах интернета удалось извлечь на свет Божий и такую схему, «выравнивающую» терминологию «квалификаторов» и ВКС (валидации компьютеризированных систем, в «девичестве» CVS = computerized system, validation):

Из этого проистекает ровно один вопрос – а какую добавочную ценность несёт в себе такое выравнивание? Разбиение по стадиям IQ, OQ, PQ прямо не регламентировано в Приложении 11 GMP, в практике ИТ принята другая терминология – то же функциональное тестирование (unit-тестирование), интеграционное тестирование (межмодульные сценарии), регрессионное тестирование. Кстати, о последнем – вот его куда отнести? С точки зрения ИТ регрессионное тестирование, точнее необходимость в онном возникает в случае, если при разработке и тестировании мы поймали баги, успешно их починили и нам нужно определить объем повторного тестирования, которые потенциально эти баги могли зацепить? Вы согласны, что тут нельзя лезть с «автоклавной логикой»? Ведь если вы поменяли уставку времени стерилизации, то вы просто повторите циклы с новой уставкой, а если вы в справочнике 1С добавили новую номенклатуру, то по-хорошему вам нужно оценить, в каких-бизнес-процессах она может быть задействована и что там следует оценить – ведется ли посерийный учёт, требуется ли входной контроль и т.п. Нет, конечно всякий раз можно начинать тестирование 1С с самого начала – возможно к пенсии управитесь 😊 Это я к тому, что во всем мире тестировщик ПО так не делают, причём несколько десятилетий как. Например, систем проектирования (СППР) 1С:ERP может содержать описание основных бизнес-процессов в нотации IDEF0 на 1000 страниц – по прежнему будем выравнивать подход с «автоклавом»?

Так вот, в практике тестирования ПО существует подход с тест-кейсами и тест-комплектами – так тестируются банковские приложения, интернет-порталы и т.п. По-русски можно их обозвать тестовыми сценариями. Это и есть зерно валидации использования ПО.

Что же касается квалификации ИТ-инфраструктуры – нет возражений – это практически прямое соответствие с IQ – выше я упоминал про схемы локальной вычислительной сети (ЛВС), которые, к слову могут автоматизированно прорисовываться специальным видом систем – т.н. NMS – network monitoring system (Nagios, Zabbix, Dude) – при этом не только визуализируются узлы ЛВС, но и различными «светофорчиками» отображается их состояние. Здесь можно попытаться разбить этапы, а можно прямо адресоваться к Приложению 15 GMP (европейскому и будущему ЕЭК, когда его переведут в редакцию 2015-го – пока смотрите текст белорусского ТКП 030-2017 на русском языке и Annex 15 на английском в оригинале) – объединить этап IOQ и не парить мозг или ещё проще – назвать соответствующей этап «Квалифиация ИТ-инфраструктуры».

Мне доводилось сталкиваться на обучениях с градацией IQ1, IQ2, PQ1, PQ2 – подразумевалась тестовая среда и среда продуктивная. Это тоже азы ИТ и на самом деле лучше так и называть, иначе вас не поймут разработчики и интеграторы программных решений. Тем более, что по тексту Приложения 11 GMP это упоминание есть, правда, как это часто случается – с «кривым переводом» — сравните русскоязычную версию и англоязычный оригинал:

Что за абстрактные «режимы работы»? Вот оригинал Annex 11:


Test environments – это и есть тестовые среды в переводе с «тарабарского наречия» 😊 Таким образом, в результате перевода стало непонятным, что делать, причем не поймёт это ни микробиолог, ни ИТ-специалист. Словосочетание в «тестовые среды» просто упустили при переводе, заменив их «режимами работы» … Что это в итоге за «режимы работы» можно определять всем Сколково в придачу с обитателями Москва-Сити.

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

Впрочем, резонный вывод очень прост. Валидация компьютеризированных систем (ВКС) – это интредисциплинарный процесс, где задействованы специалисты разных предметных областей, поэтому вопрос терминологического жонглирования нужно снять на корню, договориться о терминах и по возможности избавиться от ситуации, чтобы из-за деревьев не перестал быть видным лес. Не забывать о «Бритве Оккама», применимой часто в рамках теории систем и системного анализа – не нужно плодить сущность сверх меры. Цель ВКС (в фарма) или тестирования ПО (в любой отрасли мира) – одна – доказать, что ПО (система) работает предсказуемым образом и ровно так, как она задумывалась (согласно URS или спецификации). Как вы достигнете этой цели – вопрос вторичный. При этом есть ряд формальных требований со стороны GMP – он не обременителен и достаточно лаконичен. Если брать пп. 5 – 17 фазы эксплуатации, то они практически целиком переписаны с лучших ИТ-практик – ИТ управления услугами (ISO 20k) и информационной безопасности (ISO 27k). Все эти стандарты имплементированы в виде ГОСТ Р ИСО и существуют на русском языке. Если вы им следуете, то автоматически будете соответствовать и требованиям GMP. При этом сертификация по этим стандартам для фарма не обязательна (ISO 27k, например, обязательна для банковской сферы). Специфика фармы заключается разве что в выпуске серии (batch realize – не любой софт управляет выпуском серии даже в фарма) и упоминании об уполномоченном лице (Qualified person), пожалуй, всё. Знать состояние ИТ-инфраструктуры и быть уверенным в работоспособности бизнес-процессов, реализуемых КС, желает владелец любой системы, что в Аэрофлоте или Lufthansa, что GSK или Novonordisk.

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

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

3 комментария к “Валидация компьютеризированных систем – кто о ней говорит в контексте «обычных» IQ, OQ, PQ?”

  1. Александр, хочу задать вам вопрос относительно валидации компьютеризированной системы (1С). При проведении ретроспективной валидации, а именно валидация проводится после стадии разработки (кодирования) программного обеспечения и компьютерной системы, с целью поиска сбоя и практического поиска дефекта в компьютерной системе, рабочих станциях и в программном обеспечении.
    На стадии тестирования компьютеризированной системы стоит задача провести с установленным объёмом тестирования, который возможен в теории, и объёмом тестирования, который возможен на практике.
    Результатом планирования тестирования является тестовая документация разработанная ранее в протоколе функционирования и эксплуатации компьютеризированной системы.
    В таблицу вносим результаты тестирования компьютеризированной системы.
    При этом тестируем именно те функции которые прописаны в URS, но так как за время эксплуатации 1С в течении к примеру 1- 2-ух лет были внесены изменения и откорректированы ошибки, с уверенностью возможно проводить валидацию 1С на основании тестов.
    Остаётся вопрос какие фарм требования предъявляются к 1С?

    Ответить
  2. Я согласен с автором, что «автоклавная» традиция режет глаз тому, кто погрузился в тему всяческих ИТ-шных практик, включая соответствующую валидацию. Однако, есть небольшие соображения «напарить» тему))).
    Во-первых, эти аббревиатуры (IQ, OQ, PQ) у всех на слуху. Поэтому директору завода не надо объяснять, что проверяющие поймут эту буржуйскую тарабарщину. Он и так уверен, что поймут. Поэтому можно продать и так).
    Во-вторых. Эта практика прямо-таки извивается корнями в квалификацию автоматизированного оборудования (согласитесь, коллега, эта тема «выросла» в практике несколько быстрее, чем ВКС на пространстве СНГ). Да, тут ПО занимает работает наряду с железками. И, как бы, его удельный вес маловат. А в ВКС, наоборот, вес железяк поменьше, а ПО побольше. Но, смысл-то остался — можно и сохранить, чтоб голову не ломать по пустякам (а там есть и другие, более важные вещи для мозголомства). Ведь и у железок могут быть функциональные испытания (например, проверка распределения нагрузки на серверный кластер при использовании балансировщика, либо нагрузочное тестирование и тестирование на отказ).
    В-третьих. Так проще кодировать протоколы и отчеты, отражая в коде стадию и окружение. Быстрее и практичнее.

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

    Ответить
    • Вчера с коллегой проводили валидацию КС на базе 1С — поверьте, выписывая схему бизнес-процесса и заполняя пробелы функциональной спецификации, работая со справочниками и документами, осуществляя проводки с отслеживанием статусов «Записано», «Записано и проведено», «Помечено к удалению» — вот ни раз не вспомнили ни про OQ, ни про PQ 🙂 И «засорять» бланки этой дополнительной графой в контексте транзакций аж ни разу не захотелось. В особенности при том, что процесс сопровождал в значительной мере сам разработчик (не допиливая код, а комментируя решения и дополняя функциональную спецификацию) — вот для построения диалога с ним эти бы вещи только мешали. А вот указание на то, что все испытания проводились в тестовой среде — вот это как раз было существенным для всех участников процесса. И главное, всем понятно, оптовому отделу, системному администратору — и замысловатые IQ1, IQ1, PQ1, PQ2 в данном случае вот совсем бы не помогли, а напротив, заставили бы «переводить» нас, что имеется в виду для всех вышеуказанных ключевых пользователей системы. Системный администратор просто перекрыл бы нам RDP «до выяснения обстоятельств». 🙂 Это специфика разработки ИТ и тестирования ИТ. А так мы можем в «угоду директору» и на ТО служебного автомобиля IQ, OQ, PQ втулить, поставив в ступор всех на СТО 🙂 Утрирую, конечно. Но, кстати, ни разу не попал в этом аспекте на ситуацию, чтобы директору завода пришлось бы эти нюансы объяснять. Также ни разу не попал и на то, чтобы это пришлось объяснять проверяющему. Одной ссылки на преамбулу Приложения 11 до настоящего момента было достаточно. Предельная ситуация, где мне приходилось такое соответствие комментировать — это ВМП. Всё, в контексте SAP или LIMS я далее о квалификационных стадиях не вспоминал ни разу, с 2012-го замечаний на эту тему — ноль 🙂 Ладно, я бы сам выдумал эту хиромантию. Но ведь об этом прямо пишет GMP, GAMP 5. 🙂

      P.S.: а упомянутого David Stokes таки добавил в LinkedIN 🙂 Но с ним мотивация другая — верифицирую с ним подход с бизнес-аналитикой (IDEF0, BPMN 2.0) — он говорит, что это очень годный подход 🙂

      Ответить

Оставьте комментарий