Четыре простых шага при разработке и внедрении сложных сценарных GxP-релевантных систем
За длительный период активных взаимодействий с нашими клиентами в фармацевтическом секторе мы пришли к выводу что в точке, где естественным образом пересеклись два направления – разработка ИТ-продукта и фармацевтическая промышленность, логично вытекает необходимость создания некоего компромиссного, понятного представителям обоих направлений, маршрута при разработке и внедрении продуктов, автоматизирующих деятельность предприятия в соответствии с требованиями GxP. В данном случае это не пустые слова, потому что для случая сложных, сценарных систем классов LIMS/EDMS или MES/ERP нередки ситуации, когда проекты «расползаются» и внедрение так и не происходит. Или формально происходит, но с необходимостью постоянных доработок «по живому», что, конечно же, аннулирует вопрос о регуляторном соответствии – фарм отрасель является очень зарегулированной. Несмотря на это, все чаще появляются статьи и материалы о внедрении Continuous Validation vs Continuous Delivery или применение подхода Agile для фармацевтических проектов – например PHARMASEAL (альтернативная ссылка) и TrialGrid – тем не менее, в сущности такие подходы тоже предусматривают систему управления качеством (QMS), причем достаточно зрелую, с автоматизацией учета внесения изменений посредством GitLab/GitHub и прочих решений. Это очень перспективный подход, который позволяет заказчику получить именно тот функционал, который нужен ему для решения его задач, однако нужно понимать, что он требует незаурядного сочетания компетенций от представителей обоих компаний, как в фармацевтической отрасли, так и в ИТ.
Основным камнем преткновения при разработке программного обеспечения для предприятий фармацевтической отрасли является то, что GxP-решения требуют тщательной документации и валидации до внедрения, и как правило это реализуется V-моделью:
Рис. 1. V-модель при разработке и внедрении GxP-релевантных компьютеризированных систем
Со стороны разработчиков подходы могут варьировать. Может быть предложены спиральная модель разработки или водопад, может быть выбран Agile. Представители GxP-фланга должны четко понимать какие преимущества они получают в каждом из конкретных случаев так как ответственные за регуляторное соответствие именно конечные владельцы системы. До начала разработки необходимо иметь полное понимать какой сценарий и набор документов они должны получить.
Первый документ, который в общем-то у всех на слуху – это URS (User Requirements Specification), спецификация требований пользователя. В приложении 11 GMP на необходимость такого документа прямо указано в п. 4.4. Однако тут следует, по нашему мнению, предложить т.н. «нулевой документ», который следует иметь хотя бы на уровне шаблона, подлежащего последующему заполнению, допустимо по мере разработки той же URS. Этот документ – это матрица прослеживаемости требований (TM, Traceability Matrix). Попросту говоря, это может быть обычная таблица, в которой первым столбцом будут собраны как раз все релевантные требования к системе. Ведь как часто происходит? В отношении URS, как правило, на современном этапе проблем не возникают. В общем-то уже более-менее все понимают – и заказчики, и разработчики, что «окунуться в омут с головой», т.е. пуститься в разработку без URS – это заведомо войти в бесконечный цикл «проб и ошибок» - не будет формальных критериев завершения такого проекта.
Обратите внимание на рис. 2
Рис. 2. Четыре простых шага, позволяющих «не уронить» требования на пути разработки и внедрения сложных, сценарных GxP-релевантных систем
Почему так важна матрица прослеживаемости требований и именно в момент создания URS? Причина проста, мы можем сколько угодно детально описать наши требования, но обязательным этапом является проверка того, а соответствуют ли наши собственные требования требованиями регуляторным? Например, в Решении № 80 ЕЭК (GDP) к компьютеризированным системам требований совсем немного, но и их часто умудряются упустить из виду. В частности, п. 47: «Ввод данных в компьютеризированную систему или их изменение должны осуществляться только работниками, ответственными за данный вид работы». Это означает, что доступ к интерфейсу программы должен предусматривать разграничение прав. Если любой сотрудник будет работать, как это часто случается, с администраторскими правами, то он потенциально может выполнить все функции, в т.ч. смену статусов продукции, что сразу же станет критическим несоответствием при аудите. И это полбеды, если в качестве корректирующего мероприятия будут всё же такие права разграничены для различных пользователей. А что, если компьютеризированная система со старта не предусматривала разграничение по указанным процессам? Тогда проблема становится крупнее, без обращения к разработчику её уже не решить.
Именно по этой причине такого рода проблемы нужно «отстреливать» ещё на этапе создания URS, что как раз и позволяет сделать матрица прослеживаемости требований.
Вышеприведенное требование – это прямое требование к компьютеризированным системам в соответствующем разделе Решения № 80 ЕЭК (будем далее использовать пример GDP, как наиболее простой из GxP-решений, как минимум исходя из количества и вариативности бизнес-процессов по сравнению с GMP или GLP, хотя подходы будут едиными практически для любого GxP-релевантного направления). Однако, любая компьютеризированная система предназначена для выполнения конкретных функций, для реализации бизнес-процессов с целью автоматизации. В конечном счете реализацию разграничения прав доступа реализовать относительно просто, если такое требование сформулировано с самого начала. Есть множество стандартизированных способов для разработчика это реализовать. А вот каждый бизнес-процесс для каждого предприятия по-своему уникален, несмотря на то что основные требования в том же Решении № 80 ЕЭК прописаны единые. Как тут не запутаться?
На помощь могут прийти нотации моделирования бизнес-процессов – IDEF0, BPMN 2.0 - которые позволяют смоделировать основные процессы и сценарии, прежде чем начать не то, что разрабатывать в виде программного решения, а даже хотя бы описывать в повествовательном режиме требования к ним. Взгляните на рис. 3:
Рис. 3. Фрагмент описания функционального блока «Приемка лекарственных средств», выполненного в ПО Ramus 2.0 в нотации IDEF0
Требования к тому или иному процессу целесообразно консолидировать, создав схему такого процесса. В терминах нотаций бизнес-моделирования создается модель процесса, задача которой учесть все возможные сценарии, определить входы и выходы для каждой из функций, а также критерии успешного выполнения функций и их исполнителей.
Решение № 80 ЕЭК формулирует два основных процесса:
· процесс дистрибьюции лекарственных средств (Раздел 5);
· претензии, возврат, подозрения в фальсификации и отзыв лекарственных средств из обращения (Раздел 6).
На рис. 3 показано, как можно удобно отследить требования регулятора на самом простом примере – приемке лекарственных средств (п. 5.4 Решения № 80 ЕЭК). В соответствующий функциональный блок сверху подходят стрелки управления, в частности относящиеся к категории «Регуляторных требований», с их детальным описанием. Как видно, в данном примере буквально процитирован п. 73 с формулировкой основных задач по приемке. Именно при создании URS/TM уместно обсудить – будет ли «уметь» ваша система:
· регистрировать проверку соответствия принимаемых лекарственных средств товаросопроводительной документации;
· регистрировать проверку получения лекарственных средств от утверждённого поставщика
· регистрировать проверку отсутствия видимых повреждений, который могли возникнуть в процессе транспортировки.
Разумеется, что каждый из таких тезисов требует более детального рассмотрения. На языке бизнес-анализа это называется декомпозиция (разбиение общего на частные аспекты). Так «товаросопроводительная документация» в первом пункте будет нуждаться в детализации – какая именно? Если это ТТН– то, как они будут вводиться в систему? Информация с них будет переноситься вручную? Будут прикладываться отсканированные копии документов? Или вообще ничего не будет вноситься? Если опустить все эти вопросы, то тогда нужно понимать, что такая компьютеризированная система оставляет «регуляторную брешь» и часто не упрощает, а, напротив, усложняет жизнь компаниям. В таком случае аудитор потребует показать письменные процедуры и доказательства их исполнения в части проверки товаросопроводительной документации в том плане, что именно проверено и каковы критерии успешности такой проверки. Владельцам системы в таком случае невыгодно адресоваться в другой, часто бумажный контур. Ведь его тоже нужно создать и поддерживать в дополнение к «автоматизации», которая в таком случае непонятно, почему что-то «выборочно автоматизирует», но требует «бумажные артефакты».
Аналогично, проверка получения лекарственных средств от утверждённого поставщика. Естественно, данный пункт «аж просится» для автоматизации, а это означает что ещё перед разработкой системы следует предусмотреть список (справочник) утвержденных поставщиков, кто его может формировать и на каких основаниях, а также выработать критерии для автоматической оценки условий нахождения поставщика в списке утвержденных. Тогда при заполнении формы приемки лекарственных средств в компьютеризированной системе такой поставщик будет автоматически проверяться на нахождение в списке утверждённых поставщиков и, если его там нет, оператор просто не сможет довести процедуру принятия на склад до конца пока ответственный сотрудник не примет решения по автоматически созданному в программе отклонению о отсутствии поставщика в списке утвержденных, что как раз в выгодном свете представит такую компьютеризированную систему. Ведь по бумажной системе такой гарантии нет – на склад можно при желании «принять» что угодно, а тут система может направит процесс приёмки лекарственных средств по нужному маршруту.
Конечно, скептики могут сказать, что такие блокировки нежелательны, потому что «ситуации бывают разные» например авторефрижератор стоит на выгрузке, необходимо соблюдать холодовую цепь, а поставщика «почему-то» нет в списке утверждённых и нет ответственного лица на месте, кто бы мог его туда «экстренно» внести. На самом деле именно так называемые «разные ситуации», как правило и приводят к рискам, в том числе таких масштабов, которые в состоянии аннулировать всю деятельность предприятия.
Именно полностью детально проработанная матрица прослеживаемости требований, позволяет избежать подобных ситуаций, а порядок её разработки и внедрения должен обеспечить ликвидацию таких «авралов» и способствовать вашему возврату инвестиций. А вот потенциальная потеря продукта, или, что ещё хуже, отзыв или приостановка лицензии реализует как раз последний печальный сценарий. Гораздо дешевле все эти моменты проработать на этапе моделирования, в крайнем случае, на этапе тестирования, но не в продуктивной среде.
Другой пример функций GDP, который тоже часто отработан «слабо». Например, если в вашей системе не реализована обработка возврата (п. 6.3 Решения № 80 ЕЭК), в частности п. 96, где предусмотрены условия для ранее отгруженных лекарственных средств после их возврата с повторным отнесением к категории пригодных для поставки, то возвращенные лекарственные средства в такой системе никогда не смогут вернуться в категорию пригодных, даже если в действительности будут выполнены все условия:
· целостность вторичной (потребительской) упаковки не нарушена, отсутствуют следы повреждений, отсутствует маркировка, непредусмотренная производителем, срок годности не истёк, продукция не отозвана из обращения;
· получатель предоставил документы, подтверждающие соблюдение специальных условий хранения и транспортировки;
· лекарственные средства были проверены и оценены компетентным лицом, назначенным для выполнения данных действий;
· дистрибьютор располагает доказательствами того, что лекарственные средства были поставлены данному получателю (согласно приложенным копиям соответствующих сопроводительных документов): номер серии и (или) партии совпадает с указанным в документах, отсутствуют основания полагать, что данные лекарственные средства сфальсифицированы.
Если такие аспекты не попадают в фокус URS/TM – разумеется, они не появятся в программном продукте и тогда итоговый программный продукт, призванный облегчить жизнь конечным пользователям, на самом деле радикально её усложнит, причем и конечным пользователям, и, потенциально, разработчикам, на которых может лечь непредвиденная обязанность «доработки на ходу». Поэтому в качественной проработке URS/TM на самом деле заинтересованы все и с самого начала. В этом как раз и помогают нотации моделирования-бизнес-процессов, поскольку они позволяют учитывать и анализировать все функции, а также их входы, выходы, исполнителей и управление, что важно, до момента начала разработки и тестирования, таким образом, попутно ещё и сокращая число итераций при внедрении. Ведь если какой-то функционал «напрашивается» даже на этапе тестирования – то доработка программного решения и повторное регрессионное тестирование обойдётся дороже. Ниже на рис. 4 а) и 4б) представлена примерная оценка стоимости и временных затрат, которая стала как раз драйвером для разработки методологии проектирования SADT (Structured Analysis & Design Technique) ещё в 1960-е с последующей эволюцией в нотацию IDEF0 уже в 1990-е и дальнейшим развитием бизнес-аналитики именно с целью смещения акцента на этап предпроектного анализа. О реальных цифрах можно дискутировать, но общий вывод очевиден – обнаружить уязвимости и ошибки на ранних этапах сложнее (требует большей компетенции и большего времени для детальной проработки моделей), но исправлять их на более поздних – однозначно дороже.
Рис. 4а). Поиск и исправление ошибок в системах на различных этапах жизненного цикла
Рис. 4б). Время на обнаружение и устранение ошибок в системах на различных этапах жизненного цикла
Из рассмотренных нами примеров важность наличия у компании разработчика компетенций в фармацевтической отрасли и понимания требований, выдвигаемых к ней регуляторами, а у фармацевтического предприятия понимания процессов разработки и построения непротиворечивой модели ещё до утверждения URS трудно переоценить. Выполнение данных требований должно стать залогом успешного завершения внедрения компьютеризованной системы, которая охватывает ключевые процессы деятельности предприятия и может быть успешно валидирована.