Нужно ли делать валидацию LIMS ?

Вопрос о необходимости валидации, верификации или каких-то единоразовых или периодических других видах проверок LIMS возникает не просто так. Если в GMP вроде бы как вопрос достаточно очевиден и понятен — да валидация нужна без каких-либо «НО», то в ISO/IEC 17025 (далее — Стандарт) в п.7.11.2 есть фраза сеющая сомнения:

Примечание 2 — Доступное на рынке коммерческое программное обеспечение при обычном его использовании в области, для которой оно предназначено, может считаться в достаточной степени валидированным.

LIMS — это «доступное на рынке коммерческое ПО»? Да. Планируете его использовать, для того, для чего оно предназначено? Ну вроде как да — для лабораторной деятельности.

Значит ли это, что LIMS не нужно валидировать или каким-то иным образом проверять его работоспособность?

Нет, не значит. Проверки должны быть и у этого есть две основные причины.

1. Первичная верификация

В соответствии с п. 6.4.1 Стандарта программное обеспечение (далее — ПО) — это вид Оборудования:

6.4.1 Лаборатория должна иметь доступ к оборудованию (включая, но не ограничиваясь, средства
измерения, программное обеспечение, эталоны, стандартные образцы, справочные данные, реактивы, расходные материалы или вспомогательные устройства), которое необходимо для надлежащего осуществления лабораторной деятельности и которое может повлиять на ее результаты.

В соответствии с п.6.4.4 Стандарта оборудование (которым является и ПО) перед вводом эксплуатацию должно пройти верификацию на соответствие требованиям:

6.4.4 Лаборатория должна подтвердить соответствие оборудования установленным требованиям перед вводом его в эксплуатацию или после возврата в эксплуатацию.

Каким требованиям? Как минимум требованиям Стандарта к информации и информационным системам, а также требованиям самого пользователя (и других «заинтересованных лиц») исходя из планируемого будущего назначения.

У этого требования Стандарта вполне логичное объяснение: то что ПО коммерческое и возможно даже полноценно протестированное самим разработчиком, не отменяет тот факт, что оно могло быть разработано НЕ с учетом требований стандарта ISO/IEC 17025 и тем более не учитывая конкретно ваше назначение. Разработчик не может проверить работоспособность того функционала, которого нет. ПО может быть вполне рабочим в объеме тех функций, которые заложил разработчик, но если разработчик не заложил или плохо заложил функции прослеживаемости действий в системе, не предусмотрел правильное разделение прав доступа или не выполнил другие требования Стандарта — он не сможет протестировать на их наличие, т.к. это функция конкретного пользователя.

Также, если вы купили LIMS для испытательных лабораторий, а планируете использовать для поверки, а оказалось, что там нет нужных функций для поверки — значит ПО опять же не соответствует требованиям. Только в данном случае не требованиям Стандарта, а требованиям вашего Назначения. Это грубый пример, но суть вы уловили.

2. Валидация изменений конфигураций

В отличии от GMP, Стандарт ISO/IEC 17025 очень расплывчато написан и поэтому часто специалисты не имеющие опыта работы с регуляторикой по компьютеризированным системам, не могут понять «что имел в виду автор» Стандарта.

Если мы вернемся к пункту 7.11.2, откуда из Примечания 2 мы узнали, что ПО валидировать не нужно, то поднявшись немного вверх, мы найдем какую-то очень абстрактную фразу (первое предложение пункта):

7.11.2 Правильность функционирования систем(ы) управления информацией лаборатории, используемых(ой) для сбора, обработки, записи, представления результатов, хранения или поиска данных, в том числе правильность функционирования интерфейсов систем(ы) управления информацией лаборатории, должна(ы) быть проверена лабораторией перед внедрением в работу.

Кажется, что это та же фраза, что и мы рассматривали в предыдущий раз про первичную верификацию, но это не так. В пункте 6.4.4 речь идет о проверке на соответствие ТРЕБОВАНИЯМ, а в первой части п.7.11.2 речь идет о проверке работоспособности ФУНКЦИОНАЛА программного обеспечения. Именно по этому здесь есть фраза в Примечании 2 про отсутствии необходимости делать повторную самостоятельную проверку, если LIMS коммерческий, т.к. ФУНКЦИОНАЛ уже должен был быть проверен Разработчиком. Но соответствие ТРЕБОВАНИЯМ не может быть проверено Разработчиком по умолчанию, поэтому первичная верификация ТРЕБОВАНИЯМ должна делаться для любого LIMS — коммерческого или разработанного самостоятельно, а тестирование ФУНКЦИОНАЛА — только для самостоятельно разработанного LIMS.

Вторая часть пункта:

При любых изменениях, включая изменения конфигурации программного обеспечения лаборатории или модификации коммерческого программного обеспечения, они должны быть утверждены, документированы и валидированы до введения их в действие.

Эта часть пункта говорит про ту часть LIMS, которая настраивается под конкретного пользователя: алгоритмы в методах, расчетные формулы, печатные формы для вывода на печать, другие КОНФИГУРАЦИИ, которые настраиваются при внедрении LIMS.

То есть данный пункт следует понимать так: ДА, функционал, который используется без изменений — тестировать НЕ надо, т.к. его уже проверил Разработчик, но функции, которые настроены под конкретно вас — тестировать (валидировать) надо, т.к. по сути эта часть ПО в каком-то смысле является вашей самостоятельной разработкой и соответственно в процессе этой «разработки» могли быть допущены любые ошибки. Эта часть ПО, которая является вашей «самостоятельной разработкой» и требует обязательной ее валидации, т.к. является ИЗМЕНЕНИЕМ КОНФИГУРАЦИИ или МОДИФИКАЦИЕЙ КОММЕРЧЕСКОГО ПО.

Соответственно, что можно НЕ подтверждать (но вы можете подтверждать, если считаете нужным) ?:

правильность математических расчетов в неизменяемых алгоритмах (например, правильность математических действий при списании реактивов);
корректность реакции системы при нажатии на те либо иные кнопки, переходы в те либо иные окна и списки;
корректность календарей, таймеров, планировщиков;
корректность отображения информации;
работоспособность полей, поддержка разных форматов данных;

и любые иные ФУНКЦИИ, которые не связаны с ТРЕБОВАНИЯМИ Стандарта и назначения и которые не меняются при внедрении LIMS.

Нужно ли далее периодически делать проверки (ревалидацию) LIMS?

Пункт 6.4.10 Стандарта говорит следующее:

6.4.10 Если промежуточные проверки необходимы для поддержания уверенности в исправности
оборудования, то эти проверки должны проводиться в соответствии с установленной процедурой

Главное здесь «если … необходимы». Общей принятой практикой в регулировании ПО, является то, что если ПО было валидировано и подтверждено соответствие нормативным требованиям и своему назначению, то ПРИ ОТСУТСТВИИ ИЗМЕНЕНИЙ оно продолжает оставаться в валидном состоянии неограничено долго. Это исходит из допущения, что ПО не имеет естественного износа как оборудование или срока годности как материалы, а значит ничего произойти с ПО, валидность которого уже доказали единожды, не может.

Повторная валидация (полная или частичная) производится только тогда, когда были совершены критические изменения в системе:

система была обновлена;
в системе были изменены те либо иные конфигурации;
изменилось назначение системы или нормативные требования к подобным системам.

Единственный пункт, который наводит «смуту» и ломает всю логику управления ПО является пункт 7.11.6:

7.11.6 Расчеты и передачи данных должны подвергаться надлежащим систематическим проверкам.

который задумывался для иных целей (расчетов, производимых вручную), но который невозможен в своей реализации в случае с LIMS. Данный пункт явно должен будет убран или конкретизирован в ближайших изменениях Стандарта.

Исходя из практики, хочется дополнить вопрос отсутствия необходимости делать повторную валидацию случаями, для которых все-таки на практике принято делать периодические проверки даже если каких-либо изменений не происходило, т.е. это напрямую не требуется в Стандарте:

проверка результативности проведения резервного копирования, а также возможности восстанавливать делаемые резервные копии;
проверка читаемости ранее сделанных заархивированных данных в период срока их хранения;
проверка логов в системе на наличие подозрительных действий.