Если не у всех, то у очень многих сейчас на слуху это чарующее воображение словосочетание Data Integrity- целостность данных. Это интуитивно осознаваемое понятие стремительно ворвалось в фармацевтический обиход по мере выхода в последние годы достаточно большого количества руководств, посвященных этому вопросу:
WHO TRS 996, Annex 5, Guidance on good data and record management practices
Data Integrity and Compliance With Drug CGMP – Questions and Answers – Guidance for Industry
MHRA GxP Data Integrity Definitions and Guidance for Industry
На подходе ещё руководство от PIC/S: PI 041-1 PIC/S DRAFT GUIDANCE GOOD PRACTICES FOR DATA MANAGEMENT AND INTEGRITY IN REGULATED GMP/GDP ENVIROMENTS
В феврале 2019-го появилось русскоязычное Руководство по Целостности данных и валидации компьютеризированных систем от ГИЛС и НП, разработанное при участии специалистов PQE. Это уникальный в своём роде русскоязычный документ (ведь все остальные документы, упоминаемые в этом контексте, англоязычные и/или зарубежного происхождения). Помимо целостности данных это Руководство увязывает описанное словосочетание, собственно, с валидацией компьютеризированных систем, потому что трудно представить эти понятия в отрыве.
Нет, я, конечно, замечу, что понятие «целостность данных» в фарма касается в т.ч. и бумажных документов. Вместе с тем, позволю себе два оценочных суждения: 1) целостность данных в бумажном виде – это то, к чему нужно стремиться, но на практике это практически утопия, если подходить к этому вопросу со всей строгостью и пытаться с доказательной базой наперевес продемонстрировать следование принципам ALCOA & ALCOA+; 2) число программных решений в рамках автоматизации бизнес-процессов почти ультимативно выводит нас на обсуждение целостности данных в разрезе компьютеризированных систем и их валидации. Так что Руководство ГИЛС и НП появилось очень своевременно и сгруппировано оно весьма полезным образом. Ведь если брать зарубежные аналоги, они ведь лишь дополняют разного рода базовые руководства калибра GAMP 5, PIC/S, OECD, EDQM и т.п.
Адресуясь к этому Руководству, хочу затронуть лишь один, достаточно инновационный аспект. Принципы ALCOA & ALCOA + таковыми в нашем стремительно меняющемся мире уже не являются. Именно они как раз и понимаются интуитивно и, по сути, лишь консолидируют требования GMP на этот счет, «размазанные тонким слоем» по всему тексту GMP. Ведь Прослеживаемость (Attributable), Читаемость (Legible), Своевременность (Contemporaneous), Подлинность (Original) и Точность (Accurate)), а также (Полнота (Complete), Последовательность (Consistent), Устойчивость (Enduring) и Доступность (Available) – это и есть составляющие вышеупомянутых акронимов, смысл которых раскрыт не только в Руководстве, но и в ряде других, предшествующих ему документов.
Мне, как автору данного очерка, гораздо более серьезным показался следующий пассаж в Руководстве, возникший, впрочем, не случайно, а присутствующей в т.ч. в новейшем Руководстве по целостности данных от MHRA. Это акроним DIRA (data integrity risk assessment). В эпоху, когда только ленивый не упоминает об оценке рисков к месту и не к месту, данный пункт (6.2 Руководства ГИЛС и НП) можно воспринять, как дежурный. Однако вчитаемся в следующую фразу:
Примером приемлемого подхода является оценка риска целостности данных (data integrity risk assessment – DIRA), при которой процессы, производящие данные, или в результате которых получены данные, картируются, критические воздействия идентифицируются, а присущие риски документируются
Что же подразумевается под «картированием процессов»? Кто-то ясно себе представляет, как это будет выглядеть на практике? В MHRA изложено тоже самое практически буквально:
An example of a suitable approach is to perform a data integrity risk assessment (DIRA) where the processes that produce data or where data is obtained are mapped out and each of the formats and their controls are identified and the data criticality and inherent risks documented
Впрочем, подсказки присутствуют буквально сразу же по соседству:
Оценка рисков должна быть сосредоточена на бизнес-процессе, например: производство, контроль качества
Дело в том, что индустрия не «картирования», а моделирования бизнес-процессов развита очень хорошо примерно с 60-х годов прошлого века, а в 90-е годы уже появились программные решения, которые позволяют выполнить это моделирование «не пешком». В 1960-е годы развивался подход функционального моделирования (SADT = structured analysis and design technique), в 90-е родилось семейство стандартов IDEFx. Помимо этого, развивались другие нотации моделирования бизнес-процессов – ARIS, DFD и т.п. В настоящее время на авансцену довольно мощно вышла методология BPMN 2.0 – вот краткий очерк применительно к фарма в отношении указанных методологий. Объединяет их все одно общее свойство – это своеобразный «костыль для мозга», ведь сформулировать хотя бы на уровне требований информационную модель к будущей компьютеризированной системе без специальных инструментов практически невозможно. Точнее как, попытаться можно, но это только бумажные СМК успешно «преодолевают» нестыковки и коллизии, которые стерпит бумага. Попытка информатизировать «захламеленный» бизнес-процесс приведёт к тому, что на выходе получиться «мертворожденное» приложение, например, в части либо документооборота, либо учета лабораторной деятельности, либо статусов сырья, материалов и готовой продукции, которое будет внедряться «вечно».
Было бы очень ценно узнать мнения авторов Руководств или мнения экспертного сообщества, что подразумеваются под такими терминами, как «картирование процессов». На мой взгляд всё достаточно логично сводится к стандартной бизнес-аналитике. Ведь попытка выполнить заявленные действия как-то иначе будет сродни изобретению колеса. Вот абстрактный пример – отталкиваемся от прямой формулировки – процессы, производящие данные, картируются. Сколько процессов на среднестатистическом фармпредприятии? Понято, что зависит от уровня декомпозиции, но тем не менее? Очевидно, что эти бизнес-процессы нужно «посчитать», «инвентаризировать». Далее, речь идёт о данных. Сколько и каких данных генерирует среднестатистическое фармпредприятие? Ответ аналогичный. Если кто-либо попытается это сделать «пешком», «карандашиком в блокнотик», то неизбежно зароется в рутине. И для блокнотика или для «номинального» документа с титульным листом DIRA этого может оказаться и достаточно. Но построить работающую компьютеризированную систему таким образом, не то, чтобы не удастся – просто в процессе разработки и тестирования будут неприемлемо большие затраты на разрешение непродуманных коллизий или противоречий. Ведь если, к примеру, вы не продумали в модели системы, как будет работать 1С, то ошибка в модели приведёт к тому, что программа просто прервёт свою функцию или выполнить её неправильно. Причем логические ошибки можно искать годами. А система тем временем не сформирует бланк, не передаст выполнение функции на следующий шаг, не предоставит полномочия ответственному специалисту и т.п.
Взгляните, как выглядит пример стандартного бизнес-процесса (относительно простого) в демонстрационной версии системы BPMS CE ELMA:
Это пример улучшения бизнес-процесса. Как прочитать данную диаграмму, выполненную в нотации BPMN 2.0? Укрупнённо – есть дорожки (пулы) ответственности- Инициатор, Владелец процесса, Исполнитель. Есть ключевые этапы и виды деятельности – старт процесса (зеленый кружок), операции различных видов (пользовательская задача, оповещение и т.п.) и закономерное завершение процесса (красный кружок). Данная нотация позволяет выяснить «кто на ком стоял» (с). Ведь чем грешит бумажный документооборот? Неопределенностью. Кто заполняет журнал или бланк, в какой момент заполняет его, какие данные при этом генерируются и т.д. Нотация BPMN 2.0 в значительной степени снимет такие вопросы, поскольку модели проверяются на непротиворечивость перед их публикацией. Это и составляет ключевое отличие от «наскальной живописи», выполненной в Visio или иными графическими редакторами. Это в простом примере выше вы довольно легко «по наитию» накидаете сценарий. А если у вас таких бизнес-процессов тысячи? А если большинство сценариев – межмодульные? Впрочем, к этому образцу у читателя вполне должен сформироваться ясный ответ. Преимуществом любой нотации бизнес-моделирования являются встроенные проверки состоятельности нашей модели, прежде чем отдать её в реализацию.
Ценность данной нотации состоит в том, что она формализует комплекс всех бизнес-процессов предприятия, накладывая её на сформированную и поддерживаемую организационную структуру, а её преимущество по отношении к другим нотациям – это то, что бизнес-логика может быть автоматом транслирована в код (т.н. low code программирование) и на выходе можно получить сразу готовое решение, чья модель всех устраивает. Например, это может быть внутрифирменный портал.
Что при этом является дополнительным преимуществом, так это то, что многие вопросы в отношении целостности данных решены будут ещё на проектном этапе. Нецелостная модель просто «не взлетит». А самый распространенный вопрос – кто, в какой момент и какие данные внёс или имеет право внести – будут решены ещё на уровне проверки модели.
Я постараюсь развить данную тематику на ближайшей Российской неделе валидации. Ведь очевидно, что подобные вопросы будут приобретать только всё большую актуальность. Мне же представляется, что адресация к стандартным практикам моделирования бизнес-процессов – вполне обоснованное решение указанных вопросов.
Данная публикация создана специально для ресурса http://inopharma.ru/ и запланирована к публикации в рамках ВЭФ-2019.