Особенности разработки и внедрения GxP-релевантных компьютеризированных систем

Особенности разработки и внедрения GxP-релевантных компьютеризированных систем

        В настоящее время словосочетание «целостность данных» является, пожалуй, одним из самых цитируемых, когда речь идёт о современных требованиях GxP. Это неудивительно, если принять во внимание решительный настрой регуляторов – FDA, MHRA, EMA и др.. Решительность эта связана с необходимостью создать условия, не допускающие манипуляций с данными и их фальсификации. Например, аудиторский (контрольный) след (в оригинале GMP EU Annex 11 – audit trail) призван предотвратить повторение хроматографических испытаний готового лекарственного средства до тех пор, пока не будет получен «нужный» результат. Здесь и далее при вводе термина будет обязательно приводиться англоязычный эквивалент, поскольку варианты перевода на русский язык специфических терминов (не только из области целостности данных) часто становится предметом нешуточных дебатов.

        Акронимам ALCOA и ALCOA+, возможно, стоит посвятить отдельную статью. Признаюсь, к этому меня побуждает недавно состоявшееся обсуждение с коллегами только одного из слагаемых указанного акронима – последнего «А»: аccuracy – это точность или правильность? Данные должны быть, помимо прочего, точными или правильными? С позиции валидации аналитических методик данные должны быть скорее правильными, с позиции ИТ – скорее точными. Например, реквизиты банковского счета, куда выводились определённые суммы, должны быть точными, а правильны ли они, - часто решает прокуратура. Приведу не столь эмоциональный, близкий к фармацевтике пример. Данные цикла стерилизации (датчиков температуры) должны быть, прежде всего, точными, но мы прекрасно понимаем, что они зависят от того, как расположены датчики в загрузке. Значит, нам необходимо также описание точного местоположения датчиков, а в этом помогут руководства уровня PDA TR No. 1, где есть соответствующие рекомендации. Но вопрос в том, что единственно правильного местоположения не существует в природе, есть только общие принципы: каждый вид элемента загрузки должен быть снабжен датчиком, в случае загрузки одинаковых элементов датчики должны быть равномерно распределены по объему и т.п.. Понятно, что данные будут немного варьировать даже при соблюдении общих принципов, а вывод об их однозначной правильности (так, чтобы их нельзя было оспорить) зачастую не может сделать никто – смещение датчиков на 15 см внутри силиконового шланга потенциально даст другой результат, пусть отличающийся лишь на сотые доли градуса Цельсия. Другое дело, если по результату виден большой запас накопленных значений эквивалентного времени летальности F₀, например, равный 50 минутам (при обычном критерии приемлемости 12-15 минут) – в таком случае возможно принять правильное управленческое решение, имея всего лишь точные данные, и нет необходимости в философски правильном значении температур и расположении датчиков.

        Важно понимать, что приведенный вывод – частное мнение автора по данному вопросу, даже при том, что это частное мнение ситуативно совпадает с мнением редколлегии соответствующего Руководства ГИЛС и НП [4]. Ведь категоричность суждений, особенно в комплексных, междисциплинарных вопросах, опасна. На одной из конференций был изложен аналогичный тезис, который был закончен фразой, что лишь в простых, ординарных вопросах можно что-то утверждать категорично (например, дважды два равно четырём). На что была озвучена реплика из зала: «Это в десятичной системе исчисления!». И действительно, 1111 в двоичной системе составит 15 в десятичной системе (1111₂ = 15₁₀). Поэтому своё представление постоянно нужно совершенствовать, и читатели, возможно, имеют на этот счет свои примеры или факты, включая регуляторные прецеденты трактовок параметров целостности данных. Для подобного рода аргументов бесценными являются документы, составленные в формате вопросов и ответов, к подобному формату часто прибегают FDA и EMA. Впрочем, мы немного отвлеклись от заявленной темы.

        Выше намеренно сделан акцент лишь на один пример по отдельно взятому параметру целостности данных. Это позволяет оценить важность момента, когда мы только приступаем к проектированию GxP-релевантной компьютеризированной системы. Если подобные тонкости мы позволим себе выискивать уже в продуктиве (в ходе промышленной эксплуатации компьютеризированной системы), то подобный «разбор полётов» способен просто перечеркнуть все усилия по созданию GxP-релевантных систем. О чём же важно не забывать, когда мы только приступаем к работе? Давайте обо всём по порядку.

        Надо, конечно, подобрать практический пример, потому что говорить абстрактно - нецелесообразно. Возьмём для примера распространённую в наших странах программу 1С. В данной статье будет дан сквозной пример системы управления движением сырья, материалов и готовой продукции на базе решения 1С: ERP.

        Сразу предлагается подход, иллюстрирующий ключевую мысль данной статьи. На практике для успешной разработки и внедрения системы – не только полезной с точки зрения реализации бизнес-процессов, но и без регуляторных уязвимостей – достаточно, по моему мнению, всего четырёх шагов, результатом которых являются четыре основных документа:

1. матрица прослеживаемости требований;
2. схема бизнес-процессов;
3. анализ рисков, выполненный по схеме бизнес-процессов;
4. ключевые сценарии, составленные по анализу рисков.

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

        Укрупнённо для такой системы можно выделить три магистральных бизнес-процесса:

1. учёт движения сырья и материалов;
2. учёт движения готовой продукции;
3. учёт движения возвращённой продукции.

        В данной статье предлагаем сосредоточить своё внимание на втором пункте – учёте движения готовой продукции и некоторых его аспектах. Методологически правильно было бы пойти с самого начала, но почему-то вспоминаются учебники программирования, которые, независимо от изучаемого языка, начинаются примерно с одной и одной же программы: кнопка, обработчик события нажатия кнопки и вывод фразы в поле метки «Hello world!». Здесь хотелось бы избежать такой шаблонности, впрочем, дав представление о том, что по всем бизнес-процессам GxP-релевантной системы реализована одна и та же логика.

        Для начала нужно объяснить, по какой причине так часто применяется термин «бизнес-процесс». Всё просто. В Руководстве ГИЛС и НП [4], в частности, есть такой пассаж, целиком взятый из Руководства по целостности данных MHRA [3]: «Примером приемлемого подхода является оценка риска целостности данных (Data Integrity Risk Assessment - DIRA), при которой процессы, производящие данные, или в результате которых получены данные, картируются, критические воздействия идентифицируются, а присущие риски документируются».

        Далее уже только в Руководстве ГИЛС и НП [4] даётся пояснение (поскольку фокус данного документа всё же несколько шире): «Оценка рисков должна быть сосредоточена на бизнес-процессе, например: производстве, контроле качества. Необходимо оценивать потоки данных и методы получения данных, а не просто учитывать функциональность или сложность компьютеризированной системы».

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

        Мы говорили о четырех шагах. Что важно не забыть на первом шаге при построении матрицы прослеживаемости требований? В многочисленных шаблонах и на различных тренингах, в т.ч. в уважаемых зарубежных компаниях, фигурирует множество примеров таких матриц, где обязательно угадывается основная идея: единожды сформулированное требование на этапе URS (User Requirements Specification – спецификация требований пользователя) должно быть «не забыто» в рамках функциональной спецификации. И это естественно, ведь разработчик должен предусмотреть в реализации то, что мы заказали. А далее реализованное требование должно быть оценено и протестировано, т.е. это чисто технический документ, который позволяет не запутаться и не «уронить» изначальные требования. Что часто забывают в таких матрицах? Собственно, регуляторные требования. Парадокс! Но если первую колонку такой матрицы озаглавить именно как требования URS, то можно упустить из виду, по сути, самый существенный момент: соответствует ли наша URS регуляторным ожиданиям?

        На рис. 1 специально показан фрагмент такой матрицы, без «воды» – только пункты Решения № 77 ЕЭК [1] (в отношении готовой продукции и её возвратов как частного случая) и далее – соответствующие им пункты FS (Functional Specification, функциональная спецификация). В матрице намеренно пропущен столбец с URS, т.к. сделан акцент на то, что планирует реализовать разработчик. Ведь URS часто носит общий характер, а FS может давать подробное описание с указанием конкретных способов реализации. В случае 1С это будут объекты системы (справочники и документы) и конкретные действия, совершаемые с ними.

        Впрочем, шаг 1 – это собственно создание матрицы, для которой в первую очередь важно выбрать все регуляторные требования, просмотрев и Решение № 77 ЕЭК (либо применимой региональной редакции Правил GMP), и, возможно, другие регуляторные и/или рекомендательные документы.

Рис. 1. Пример фрагмента матрицы прослеживаемости требований

        Шаг 2 – это создание схемы бизнес-процессов. Оптимально, если поставлена задача создания сложных, сценарных систем ещё на этапе URS. На практике чаще встречается ситуация, когда такие схемы возникают уже на этапе FS, и это далеко не худший случай. Чаще приходится выяснять реализованные сценарии уже в продуктиве. Это не запрещено регулятором – такие системы называют legacy system (давно используемые системы), – но всё же не может быть рекомендуемым подходом, поскольку часто уже на первых этапах схемы выясняется, что программа работает некорректно. Например, программа позволяет реализовать продукцию со статусом «Карантин» до проведения анализа со стороны ОКК (отдел контроля качества) и выдачи сертификата качества. Понятно, что это сразу будет признано критическим несоответствием для GxP-релевантной системы. Исправить подобный баг в уже работающей системе зачастую бывает непросто. Распространённое в подобных ситуациях оправдание звучит примерно так: «Так получилось потому, что мы начали строить дом с крыши». Впрочем, от осознания этой ошибки не становится легче.

        Легче становится, если мы создаём схему функционирования сложной, сценарной системы. В чём преимущество схемы? Объяснить достаточно просто. На рис. 1 можно увидеть, как FS отвечает тому или иному регуляторному требованию. Достаточно визуально оценить, что описание в колонке FS больше, чем само формальное требование. Если такие описания делать в форме повествования (не имея плана), можно легко запутаться на втором или третьем пункте, допустить противоречия.

        Непротиворечивую систему, напротив, можно получить, задействовав инструментарий бизнес-анализа. На рис. 2 приведена для примера схема учёта движения готовой продукции, выполненная в нотации BPMN 2.0 (программный продукт ARIS Express).

        Здесь нужно оговориться, что не обязательно использовать именно инструментарий бизнес-аналитики, можно выполнить простую неформализованную блок-схему, которая позволит разобраться сценариях значительно проще, чем «с моих слов записано верно и мною прочитано». Но важно понимать, что использование конкретных нотаций имеет свои правила построения схемы и логические нестыковки в различных программных продуктах фиксируются как синтаксические ошибки. Это очень хорошее подспорье. Кроме того, внедренцев 1С вряд ли можно удивить элементами бизнес-аналитики, поскольку сама 1С в проектной системе (СППР) использует нотацию IDEF0, согласно которой виды деятельности без выхода и без управления недопустимы. В некоторых средствах моделирования присутствует автоматизированный инструментарий проверки целостности моделей. В начале статьи упоминалось о целостности данных. Конечно, выполнить такую ревизию при помощи автоматических средств – серьёзная выгода.

        В режиме «наскальной живописи», т.е. неформализованной блок-схемы, можно нарисовать произвольный поток событий в Visio или Word, но тогда, вероятно, у пользователя или разработчика смогут возникнуть сложности на этапе реализации. Как правило, разработчик найдёт решение, но в таком случае программа будет работать не так, как запланировано, а так, как ситуативно разработчик сможет найти решение. Разработчик, как правило, не будет листать текст Правил GMP поминутно, пытаясь решить локальные коллизии. Например, при возврате он может просто объединить возвращённые экземпляры с теми, которые находятся на складе готовой продукции при совпадении номеров их серий. В таком случае единственным вариантом действий будет утилизация всей серии согласно пункту 5.70 Правил GMP. Все поймут, что этот шаг нерационален, но программа не сумеет отработать иначе, если этот сценарий не прописать подробно заранее.

        На рис. 2 также видно, что при производстве готовой продукции тоже есть как минимум один стержневой элемент логического ветвления: по результатам контроля качества готовая продукция может приобрести статус «Разрешено» или статус «Запрещено». В первом случае продукция перемещается на склад готовой продукции и доступна для реализации, во втором случае – на склад брака и подлежит утилизации.

Рис. 2. Пример схемы процесса учёта движения готовой продукции

        Соответственно, каждую операцию по схеме (рис. 2) надлежит описать подробно, что и станет основной канвой функциональной спецификации. Фрагмент такого описания для первых двух операций представлен на рис. 3. Важно отметить, что должна быть реализована ролевая модель (рис. 2). Данная модель угадывается по горизонтальным дорожкам, которые интуитивно понимаются как зоны ответственности. В IDEF0 это стрелки снизу – каждая нотация имеет свои правила, и общим является именно наличие формальных правил построения моделей.

        Ролевая модель позволяет выполнить разграничение доступа, что является также прямым требованием GхP. Каждый сотрудник должен выполнять только функции в рамках своих должностных обязанностей. Это интуитивно понятно, но для обострения интуиции можно посмотреть сформулированное требование в п. 12 Приложения 11 к Решению № 77 ЕЭК (GMP) [1] в отношении прав доступа и п. 47 Решения № 80 ЕЭК (GDP) [2]. Чтобы эти требования не потерять, их важно иметь в матрице прослеживаемости требований. Как видно, связанность четырёх предложенных шагов и соответствующих им документов довольно тесная.

        Что видно на фрагменте функциональной спецификации (рис. 3)? Прежде всего, мы указываем на роль того или иного пользователя в системе. Резонно, что при выпуске готовой продукции львиная доля участия приходится на представителя производства (в данном случае технолога). Хотя ролей немного (всего пять), процесс может быть реализован целиком только при таком коллективном участии, когда чётко прописаны причинно-следственные связи, зависимости и ограничения.

         Вторая колонка в примере отражает исходные условия, т.е. формальное стартовое событие  процесса, делающее возможным запуск той или иной операции, в принципе. В случае компьютеризированной системы этот момент трудно переоценить, поскольку при несоблюдении каких-либо стартовых условий в заполняемой форме могут быть недоступными некоторые поля или «задымлены» элементы управления (это когда «кнопочки серенькие», если не все поля заполнены). В данном примере таким стартовым событием является план производства. Он может быть интегрирован в систему или существовать вне системы, но в следующей колонке показан уже конкретный путь в меню системы для заказа на производство. Технолог в рассматриваемом примере должен заполнить форму «Заказ на производство». Степень детализации FS будет зависеть от пользователя – это может быть скриншот такой формы (см. пример на рис. 4), в которой может быть детально расписано, какие поля должны быть заполнены, в каком порядке, при каких условиях и т.п. В результате на выходе пользователь получит практически готовый СОП по работе с системой.

Рис. 3. Пример функциональной спецификации, иллюстрирующий подробное описание двух первых операций согласно схеме на рис. 2

        Для самой системы критически важна следующая колонка, показывающая, какой объект формирует система, или, говоря иначе, что происходит в результате той или иной операции. В данном примере формируемый объект системы – это заказ на производство и его регистрация в соответствующем журнале. Ведь без этого выхода не сможет быть запущен ряд последующих операций, не говоря уже о том, что задача без выхода является ошибкой любой модели в любой нотации. Нужно обратить внимание ещё раз на рис. 2: не должно быть повисших прямоугольников (в крайнем случае должны быть ссылки на смежные схемы/модели, но если какая-либо операция (точнее, её результаты) нигде более не востребована, то по правилам системного анализа такая операция лишняя).

Рис. 4. Пример заполняемой формы «Заказ на производство», интерфейс системы 1С: ERP

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

        Риски (шаг 3) не нужно специально выдумывать. Более того, выше не случайно приведены цитаты из руководств по целостности данных – риски прежде всего могут быть связаны с реализуемыми бизнес-процессами, а выдумывание рисков не имеет практической значимости.

        Соответственно, далее (шаг 4) ключевые тестовые сценарии по аналогии выдумывать не нужно – они должны быть логичным ответом на риски, идентифицированные на шаге 3. Не нужно тестировать абстракции – открыта конкретная заполняемая форма (рис. 4). На этапе анализа рисков нужно продумать, что может пойти не так, какие данные можно забыть ввести в систему или ввести их неправильно? Какие защитные механизмы имеет система или, возможно, стоит их предусмотреть? Тестовые сценарии должны дать ответы на подобные вопросы.

        Итак, мы у цели. Выполнив эти достаточно простые шаги, получаем одновременно и непротиворечивую систему (если удалось вас убедить предпринять такие шаги не постфактум, а на этапе проектирования, разработки и внедрения), и соответствие регуляторным требованиям. Потому что именно основные, магистральные требования регуляторов содержат словосочетания «целостность данных», «анализ рисков» и т. п. Важно понимать, что бὸльшая часть возможных несоответствий требованиям к целостности данных должна быть устранена ещё на этапе разработки. И они будут устранены, точнее не допущены, если моделируется бизнес-процесс целиком. Например, без входа в систему под своей учётной записью ничего не случится (это базовый функционал системы), а для учёта действий пользователя после входа под своей учётной записью реализован системный журнал – в комплексе это параметр attributable (прослеживаемость). Если заполняемая форма реализует ключевые требования GxP (это покажет матрица прослеживаемости требований), и реализованы элементы защиты (например, без заполнения обязательных полей нельзя перейти на следующий шаг) – это параметры complete (полнота), consistent (согласованность) и т.п.

        Именно такую стратегию хотелось бы предложить читателям при проектировании, создании и внедрении GxP-релевантных систем. Тактику можно выбирать самостоятельно, с учетом задач и обстоятельств. Завершить статью будет уместно высказыванием Сунь Цзы: «Тактика без стратегии – это всего лишь суета перед поражением».

Список литературных источников

1. Решение № 77 Совета Евразийской экономической комиссии «Правила надлежащей производственной практики Евразийского Экономического Союза» от 3 ноября 2016 г.
2. Решение № 80 Совета Евразийской экономической комиссии № 80 "Об утверждении Правил надлежащей дистрибьюторской практики в рамках Евразийского экономического союза" от 3 ноября 2016 г.
3. MHRA ‘GXP’ Data Integrity Guidance and Definitions, March 2018.
4. ГИЛС и НП, Целостность данных и валидация компьютеризированных систем.

Скачать статью в .pdf-формате