Ниже будет приведен базовый перечень требований для валидности LIMS в лаборатории, соответствующей требованиям ISO/IEC 17025 и/или GMP. В первую очередь будут рассмотрены нормативные требования, т.к. требования к пользовательскому функционалу пользователь должен сформулировать сам.
Единственное, чтобы системно понять эти требования, нужно знать, что все нормативные требования исходят из задач, связанных с получаемой и хранимой информацией в LIMS — она должна быть достоверной (точной), должна сопровождаться достаточным количеством сведений об условиях ее получения, изменения и удаления (принцип прослеживаемости), должна быть достаточно защищена от повреждения или утери. Все разрозненные нормативные требования по сути исходят из этих задач. Эта группа требований еще в нормативной документации часто называется как «целостность данных» (data integrity).
Также важная ремарка: большую часть этих требований вы не сможете дословно найти в стандартах для лабораторий, т.к. данные стандарты оперируют высокими материями, а не конкретными требованиями: в стандартах есть небольшое количество очень общих фраз, которые мало что говорят для не профильного специалиста. Описанные ниже правила — являются выжимкой опыта, анализа специализированных международных стандартов и наблюдениями правоприменительной практики в мире. Поэтому положения ниже стоит воспринимать как краткие тезисные инструкции, позволяющие выполнить высокоуровневые требования стандартов для лабораторий.
НОРМАТИВНЫЕ ТРЕБОВАНИЯ
1. Прослеживаемость
- пользователи должны быть идентифицированы в системе уникальным образом, позволяющим однозначно соотнести кто есть кто: это могут быть логины, ФИО, другие уникальные идентификаторы;
- в системе должен быть запрет на создание нескольких пользователей с идентичными идентификаторами, т.к. это не позволит различить их и их действия. В том числе должно быть запрещено создавать пользователей с идентификаторами как у уже удаленных пользователей;
- связь между физическим сотрудником и его аккаунтом с уникальным идентификатором обеспечивается тем, что в систему он может зайти только под своим аккаунтом, т.е. должна быть система авторизации при входе в LIMS путем ввода пароля и логина, сканирования биометрических данных, считывания RFID метки или иным достаточно надежным образом;
- в системе должны быть точно настроены дата и время;
- в системе должен быть функционал, который ВСЕГДА при каждом критическом действии (создание, изменение и удаление информации) фиксирует метаданные об этом действии: кто (идентификатор пользователя), когда (дата и время), конечное значение данных. Иногда еще фиксируется дополнительно исходное значение данных и пояснение пользователя. Это так называемый Audit Trail или контрольные следы.
- Audit Trail должен фиксироваться точно;
- Audit Trail не может быть удален или изменен;
- данные не могут быть удалены бесследно из системы в течение срока их хранения.
2. Управление доступами
- сотрудники должны иметь возможность пользоваться только теми функциями, которые им нужны для работы, и у них должны быть недоступны функции, которые им не нужны для работы — это называется управлением доступами;
- получение доступов пользователями должно происходить в момент их авторизации;
- все действия с доступами пользователей (присвоение, изменение, аннулирование) должно быть прослеживаемо (Audit Trail).
3. Получение информации
- информация, попадающая в систему извне, должна достоверно отражать действительность (должна быть точной);
- критические данные, вводимые в систему вручную, должны проверяться и подтверждаться вторым лицом (правило «четырех глаз»);
- если информация попадает (мигрирует, импортируется) в систему из других электронных систем или от приборов, то при этой миграции не должно происходить никакой модификация информации;
- если информация создается вследствии осуществления алгоритмов (например, при математической обработке), то эти алгоритмы должны быть корректные и воспроизводимые.
4. Хранение информации
- информация должна храниться в течение всего установленного срока хранения аналогично информации на бумаге;
- в течение всего срока хранения информации, должна оставаться возможность открытия и чтения этой информации (принцип сохранения читаемости) даже если сама система изменяется или обновляется;
- должно проводиться резервное копирование данных с обоснованной периодичностью, в определенное время или по определенному принципу и резервные копии должны храниться обоснованное время;
- восстановление резервных копий в случае аварий должно восстанавливать не только сами данные, но и все компоненты системы, позволяющие работать с этими данными (включая лицензии, драйвера, вспомогательные библиотеки, другое);
- создание, изменение или удаления одной информации не должно приводить к непрослеживаемому изменению уже созданной информации в системе.
5. Электронная подпись
- подписание «документов» в системе должно быть очевидным, осознанным и активным действием (ввод логина и пароля, биометрическое подтверждение, иное);
- в системе должна быть возможность четко понять для подписанного «документа» кто, когда и для какой цели (ознакомление, исполнение, проверка, согласование, утверждение, иное) подписал этот “документ”;
- если в подписанный документ внесли изменение, то электронная подпись должна быть аннулирована;
6. Вывод на печать или экспорт в другие системы
- экспортироваться и печататься должна информация в полном объеме, который предполагается для этой задачи;
- экспортированная и распечатанная информация должна быть идентичный той, которая была в системе (совпадение с “интерфейсным видом”).
Надо понимать, что нормативные документы не устанавливают требования к рискам лаборатории как бизнеса. То есть риск невозможности работать из-за отключения электричества или поломки WiFi роутеров, передача коммерческой тайны конкурентам и т.п. — это вопросы, которыми лаборатория занимается по своему желанию.
ФУНКЦИОНАЛЬНЫЕ (ПОЛЬЗОВАТЕЛЬСКИЕ) ТРЕБОВАНИЯ (ОБЩИМИ СЛОВАМИ)
- в системе должен быть весь функционал, выполняющий задачи пользователя;
- осуществляемые алгоритмы и математическая обработка должны соответствовать документам (методикам, СОПам, инструкциям, др), которые автоматизируются через этот функционал;
- язык интерфейса должен однозначно пониматься всеми ее пользователями;
- должна быть актуальная документация на LIMS, достаточная для работы пользователя;
- техническая инфраструктура (сети, сервера, ПК) должны обеспечивать достаточную пропускную способность и объем хранилища для данных в течение всего срока хранения;
Но в остальном функциональные требования (критерии) формирует сам пользователь, поэтому более здесь мы их рассматривать не будем. LIMSы бывают слишком разные, в них слишком разные возможности и у пользователей есть разные соответственно ожидания от них.
ВАЛИДАЦИЯ
Если ПО соответствует обеим группам требований, то оно сможет быть валидировано. Как проводится валидация? Проводятся экспериментальные, как правило, очень простые действия, которые фактически демонстрируют, что в системе действительно есть тот либо иной функционал и он отрабатывает как надо (чек-лист по программе). Это не сложная валидация, но очень муторная и дотошная, т.к. надо проверить большое количество сценариев и функций, сымитировать разные виды действий в системе.
Вопрос о необходимости валидации описан подробно в нашей другой статье >>
Валидация делается единожды, т.к. LIMS не может “износиться” как это происходит с оборудованием или в ней по какой-то другой причине начать некорректно выполняться функционал. Если единожды было признано, что LIMS валиден, т.е. в нем выполняются нормативные требования и обеспечивается возможность применять по назначению, то LIMS остается валидным неограниченное время при следующих условиях:
- в LIMS не меняется функционал и он не обновляется;
- не меняется назначение пользователя в части применения LIMS;
- не меняется нормативная документация, устанавливающая требования к компьютеризированным системам в вашей лаборатории.
Если же хоть что-то из этого меняется — может потребоваться ревалидация LIMS в полном объеме или в части.
В ходе эксплуатации валидного LIMS:
- ведется мониторинг за совершаемыми в системе критическими действиями (Audit Trail);
- контролируются изменения (чтобы их не было или они были управляемыми);
- мониторятся сбои;
- периодически проверяется результативность резервного копирования.
Если все в норме — поводов для плановой или внеплановой валидации нет.
Reference LIMS (R-LIMS) — у вас НЕ БУДЕТ проблем с валидацией и валидностью LIMS >>
