VALIDATION OF COMPUTERISED SYSTEMS — ANNEX 2: VALIDATION OF DATABASES (DB), LABORATORY INFORMATION MANAGEMENT SYSTEMS (LIMS) AND ELECTRONIC LABORATORY NOTEBOOKS (ELN)
Содержание
ВВЕДЕНИЕ
Настоящий документ представляет собой 2-е приложение к основному документу “Валидация Компьютеризированных Систем” и должен использоваться в сочетании с ним при планировании, проведении и документировании шагов валидации компьютеризированных систем.
Основной документ содержит Введение, Область применения и общие требования к валидации различных типов компьютеризированных систем.
Данное приложение содержит дополнительные рекомендации, которые будут использоваться в сочетании с общими рекомендациями, приведенными в основном документе.
Этот документ следует рассматривать как руководство для OMCLs для планирования, проведения и документирования валидации их компьютеризированных систем. Его не следует воспринимать как перечень обязательных требований. Каждой OMCL предоставляется персональное право принимать профессиональное решение об использовании наиболее подходящих процедур, которые будут выполнены для обеспечения доказательства того, что их компьютерные системы работают правильно и соответствуют своему предназначению.
ОБЩИЙ ПОДХОД
Масштабируемый подход на основании степени валидации
Уровень риска влияет на степень валидации. В этом случае требуется оценка рисков. Оценка риска включает анализ возможного влияния компьютеризированной системы на качество и целостность данных.
Уровень и степень валидации в дополнение к риску, зависит от категории программного обеспечения.
Компьютеризированная система может чаще всего рассматриваться следующим образом:
- Инфраструктурное программное обеспечение, например, операционные системы или менеджер баз данных
- Ненастраиваемое программное обеспечение (части), например приложение-прошивка
- Настраиваемое программное обеспечение (части), например, интерфейсы к устройствам или другое программное обеспечение
- Специализированное программное обеспечение (части), например, Excel с макросами, настроенные по своему усмотрению диалоговые окна
Инфраструктурное программное обеспечение требует документирования версий программного обеспечения и конфигурации, а также выполнения квалификации установки. Валидация специализированного программного обеспечения содержит описание спецификаций требований пользователей, анализ кода и дизайна, документацию версий и конфигурации, квалификацию установки, тесты функций на основе рисков и предопределенное управление данными.
При таком подходе нет необходимости осуществлять подобные действия для всей системы. Валидация будет описана индивидуально для каждой части системы.
Использование работы поставщика
Валидация документов и результаты испытаний, проведенные поставщиком программного обеспечения, могут быть перенесены в собственную валидацию. Эта работа и испытания не должны повторяться заказчиком. Поставщик должен быть предварительно квалифицирован (например с помощью анкетирования или аудита).
План валидации
Для обеспечения проведения корректной валидации необходим план валидации. План валидации описывает все действия, такие как анализ СТП, анализ схемы разработки (дизайна), алгоритм тестирования, верификаци переносимых данных, анализ валидации документов и приемо-сдаточных испытаний системы в целом.
План содержит дату, данные ответственного лица и критерии приемки для каждого анализа или теста, или как минимум ссылки на эти тесты.
План валидации должен быть разрешен ответственным лицом перед началом валидации.
Контрольные примеры и описания могут быть описаны позже, если используется итерационный процесс.
ВАЛИДАЦИЯ БАЗ ДАННЫХ
Уровень I. Выбор программного обеспечения и компьютерного оборудования
Это первый шаг валидации. Спецификация требований пользователей (СТП) описывает функциональные, технические и организационные требования к системе определяемой заказчиком. Реализации и верификация проводятся в соответствии с этими СТП.
(1) Описание используемого программного обеспечения, в том числе версии (например Excel, Access, Oracle)
(2) Требования к компонентам оборудования и операционной системе
(3) Описание функций
(4) Описание атрибутов данных
(5) Терминология (например, важно для унифицированной записи масок ввода/полей)
(6) Проектирование базы данных, включая маски и поля, а также карты взаимосвязи данных
(7) Спецификации макросов, формул и команд управления
(8) Спецификации вводимых данных (например, формат, число десятичных знаков, единицы измерения)
(9) Спецификация обязательных полей для данных
(10) Спецификации масок защиты, рабочих листов или всего приложения
(11) Планирование переноса данных, если применяется
(12) Спецификации интерфейсов к другими компонентами системы, если применяется
В случае простой базы данных, достаточно схемы управляемого потока данных, как дизайна базы данных. Спецификации (СТП), должны быть разрешены ответственным лицом. Возможны изменения по требованиям. Изменения должны прослеживаться, а СТП в этом случае получает новый номер версии. Новые или измененные требования должны быть донесенны до всех заинтересованных лиц.
Уровень II. Установка и выпуск для использования
Правильная установка системы в ИТ-среде с определенным аппаратным и программным обеспечением, документируется и тестируется. В большинстве случаев, БД, ЛИМС или ЭЛЖ встраиваются в компьютерную сеть с интерфейсами к другому программному и аппаратному обеспечению. Должна быть обеспечена правильная интеграция системы, а также функционирование всех компонентов.
Установка
(1) Проверка необходимых для системы ресурсов (например, производительность процессора, количество свободного места на жестком диске, доступ для установки)
(2) Документация к компонентам системы (как минимум описание компонента и версии соответствующих компонентов с датой внедрения)
(3) Список пользователей или групп пользователей, имеющих доступ к приложению, в том числе тип доступа
(4) Тест интеграции и/или подключения (например, хранение набора известных данных в базе данных и обработка данных, если запрограммирован процесс расчета или другой процесс, восстановление и печать данных и сравнение с критериями приемлемости)
Частота установки поддерживается поставщиком и внутренним ИТ-отделом.
Выпуск для использования
(1) Анализ проекта
(2) Тесты функций (например, каждая функция базы данных проверяется на наборе данных)
(3) Отрицательные испытания или испытания с предельной нагрузкой (например, ввод значений вне указанного диапазона)
(4) Тестирование предупреждающих сообщений, если применимо (например, отображение результата за пределами спецификации)
(5) Несанкционированный ввод данных и доступ к приложению
(6) Тесты неверного ввода (например, ввод данных в неправильном формате данных)
(7) Тест системы резервного копирования и восстановления
(8) Верификация переноса данных, если применяется
(9) Соответствие требованиям защиты информации, если применяется
(10) Тест “черный ящик”, как приемо-сдаточное тестирование системы в целом
На этом участке должно быть проверено соответствие СТП.
Число наборов данных, используемых для функциональных испытаний, зависит от оцененного класса риска. Должны применяться, как минимум, два значения в пределах нормы.
В качестве теста на предельную нагрузку или отрицательного теста, должно использоваться, как минимум, одно значение ниже и одно значение выше предела. Такой же алгоритм тестирования может быть использован для проверки функции предупреждающих сообщений.
В случае базы данных с большим количеством функций, возможно уменьшение размера теста до ключевых функций. Это решение основывается на оценке риска и должно документально прослеживаться. Также возможно выполнять тесты “черного ящика” для наиболее важных вариантов использования базы данных вместо тестирования отдельных функций.
Чтобы показать надежность базы данных, выполняется несанкционированный и неправильный ввод данных.
Верификация переноса данных следует с шести записей вплоть до 100% переносимых данных. Случайная выборка зависит от оцененного класса риска. Данные целевой системы, сравниваются с данными исходной системы. Для таких видов верификации доступны автоматизированные инструменты.
Уровень III. Периодические и целенаправленные проверки функциональности программного обеспечения
Периодические проверки (тест “черного ящика”), особенно после серьезных изменений и с регулярной периодичностью, выполняются для обеспечения корректной работы всей системы в течение срока эксплуатации.
Документация
В дополнение к списку программной документации, в соответствии с базовым документом валидации компьютеризированных систем, некоторые специальные аспекты должны быть в описании.
(1) Системное описание базы данных (например, диаграмма системы, программный процесс, взаимосвязи ячеек и таблиц, макросы, формулы)
(2) Скриншоты соответствующих рабочих листов и масок
(3) Спецификация требований пользователя, как минимум последняя актуальная версия СТП
(4) Отчеты квалификации установки, включая конфигурацию
(5) Описания теста, записи и результаты верификации
(6) Отчет по валидации, если применяется
(7) Уникальный идентификатор версии базы данных
(8) Обучающие планы и записи, если применяется
(9) Руководство пользователя, если применяется
(10) Сопроводительная документация, если применяется
Документация должна позволять прослеживать валидацию, а также техническое обслуживание и разработку базы данных в любой момент её жизненного цикла, третьей стороной. Каждое изменение в документах должно быть прослеживаемым.
Администрирование
Эта часть не является типичным этапом процесса валидации, но она содержит информацию, которая имеет отношение к спецификации и валидации системы.
База данных является валидной в течение всего времени использования, если гарантируется поддержание её работоспособности.
(1) Управление конфигурацией (конфигурация компьютерной системы, которая содержит базу данных, должна прослеживаться в любой момент времени, включая дату интеграции новых компонентов или версий)
(2) Управление изменениями (все изменения в дизайне базы данных должны прослеживаться, а для серьезных изменений требуется предварительное разрешение ответственного лица)
(3) Управление патчами и обновлениями операционной системы (как минимум, документируются осуществлявшиеся патчи и обновления, правила применения патчей/обновлений, например, в ночное время или на выходных, тест “черного ящика” после установки патча/обновления в случае необходимости)
(4) Управление постоянством и сбоями (сбор списка отклонений сбоев, например, корректирующее действие и предупреждающее действие/КДПД(CAPA))
(5) Организация службы технического сопровождения, если применяется
(6) Безопасное копирование приложения
(7) Защита данных (Логин, пароль, права доступа)
(8) Стратегия резервного копирования (например, промежуточное, инкрементное или полное резервное копирование, интервал времени)
(9) Понятие аварийного восстановления, если применяется
(10) Концепция обучения, если применяется
В случае простой базы данных, требования по её администрированию сокращаются. Вышеприведенный список справедлив в основном для сложных баз данных.
Должна быть прописана ответственность за управление конфигурацией между внутренним ИТ-подразделением и OMCL. Также это важно для управления патчами и обновлениями, а также для резервного копирования.
ВАЛИДАЦИЯ ЛИМС/ЭЛЖ
Фоновым компонентом ЛИМС или ЭЛЖ является работающая база данных. Все требования, которые перечислены в главе “Валидация баз данных”, справедливы и для ЛИМС или ЭЛЖ. Аспекты, которые отмечены как “если применяется” в предыдущей главе, в особенности актуальны для ЛИМС.
Специальные указания и дополнительные требования описаны в следующих разделах.
Уровень I. Выбор программного обеспечения и компьютерного оборудования
Спецификация требований пользователей должна содержать все соответствующие функциональные, технические и организационные спецификации. Она должна охватывать также аспекты информационной безопасности и защиты данных.
Каждое требование должно быть описано в СТП отдельной строкой. Каждая строка должна быть обозначена уникальным номером. Этот номер позволяет обращаться к требованию в процессе разработки, а также в процессе валидации.
Уровень II. Установка и выпуск для использования
Должны быть доступны подробные процедуры установки. Установка должна выполняться только хорошо обученным персоналом.
Контрольные списки с предопределенными шагами установки и критериями приемлемости обеспечивают правильную установку системы и прослеживаемость квалификации установки.
Важно, принять во внимание, следующие аспекты процесса валидации:
(1) ИТ сеть (проверка требуемой спецификации системы и технических данных)
(2) Клиенты (должна быть известна конфигурация клиентов)
(3) ЛИМС или ЭЛЖ-сервер (см. пункт ИТ сеть)
(4) Периферийные компоненты и интерфейсы (функция каждого компонента и интерфейса должна быть проверена)
(5) Исходный код программного обеспечения (исходный код, правила кодирования и средства кодирования должны быть известны, а доступ к ним гарантирован)
(6) Данные (целостность данных должна быть показана путем сравнения исходных данных с переобработанными данными, а также использование ограничения доступа и процесса аудита)
(7) Руководства и процедуры (должны быть доступны все соответствующие документы, такие как: процедура установки, описание программного обеспечения, процедуры валидации, обучающие руководства и руководства пользователя, руководство по обслуживанию, процедура резервного копирования и восстановления данных, порядок управления изменениями и документация по разработке)
(8) Поставщик (поставщик должен быть квалифицирован)
(9) Персонал (сотрудники должны быть обучены и квалифицированы, должны быть в наличии стратегия и план обучения конечных пользователей)
Уровень III. Периодические и целенаправленные проверки функциональности программного обеспечения
Периодические проверки (тест “черного ящика”) основных функций, по одному контрольному примеру на каждую.
ВАЛИДАЦИЯ ИМЕЮЩЕГОСЯ В НАЛИЧИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Предыдущие требования применимы для новых баз данных и ЛИМС/ЭЛЖ.
Для ретроспективной валидации имеющегося в наличии программного обеспечения, в частности, должны быть рассмотрены следующие пункты.
(1) Выполнение оценки рисков
(2) Инвентаризация всех имеющихся документов (например, описания системы, представления)
(3) Верификация правильности установки (например, требования к операционной системе)
(4) Создание отчета об опыте работы (резюме опыта работы с программным обеспечением: Как долго это программное обеспечение работает? Неисправности?
(5) Добавление недостающих документов (как минимум функциональное описание, в виде обзора или базовых спецификаций)
(6) Комплексный тест (типичное применение с сравнением результата с ожидаемым значением)
(7) Формальный выпуск для использования
ПРИМЕРЫ
Карта связей между данными (база данных Access)
Эта карта может быть использована на этапе спецификации базы данных (структура базы данных), а также для оценки проекта и как документация для её верификации.
Скриншот маски ввода с обязательными для заполнения полями
Этот скриншот можно использовать в качестве документации для соответствующих форм с указанием обязательных полей, а также для проверки этих полей.
Скриншот несанкционированного доступа или неверного ввода с сообщением об ошибке
Этот скриншот можно использовать в качестве документации для верификации преднамеренного несанкционированного доступа или неверного ввода.
Скриншоты сравнения вводимых данных с выходными данных
Эти скриншоты могут быть использованы в качестве документации для теста интеграции или подключения.
Валидация простой базы данных
Например база данных используется только для создания предварительно заполненных отчетов (верхний и нижний колонтитулы, данные – это название продукта, номер серии или ID образца). Результаты будут заполнены от руки, без расчетов.
Тест:
Отчет печатается и сравнивается с известными данными (ID образца и т.д.). Это сравнение выполняется один раз. Другие действия не требуются.
Тесты по спецификации
Функциональная спецификация (часть СТП):
| ID | Описание |
| 100.1 | Введите значение рН и сравните с спецификацией. Значения выходящие за пределы спецификации отображаются красным цветом. |
рН спецификация продукта XY: рН от 6,0 до 8,0
Тесты:
1. Введите рН 7,2 → правильное значение, в рамках спецификации
2. Введите рН 6,1 → правильное значение, в рамках спецификации
3. Введите рН 5,9 → правильное значение, за пределами спецификации → результат отображается красным цветом
4. Введите рН 15,2 → ложное значение → сообщение об ошибке
Пояснение
Сравнение со спецификацией имеет решающее значение.
Риск: ложная оценка образцов как результат некорректного сравнения со спецификацией.
