Валидация компьютеризированных систем
ВАЛИДАЦИЯ КОМПЬЮТЕРИЗИРОВАННЫХ СИСТЕМ
ВАЛИДАЦИЯ КОМПЬЮТЕРИЗИРОВАННЫХ СИСТЕМ
БАЗОВЫЙ ДОКУМЕНТ
В данном руководстве описаны основные принципы валидации компьютеризированных систем, используемых в официальных лабораториях по контролю качества лекарственных средств (OMCL) и влияющих на качество результатов, контроль документов и хранение данных. Цель такой валидации — гарантировать достоверность лабораторных данных, которые собраны, обработаны, включены в отчетность или хранятся компьютеризированными системами. Прошедшая валидацию система обеспечивает точность результатов и снижает риск нарушения целостности данных.
Данный документ распространяется на все типы компьютеризированных систем, которые используются в OMCL. Однако в зависимости от сложности системы меняется объем испытаний и документации. Компьютеризированные системы можно разделить на три типа: освобожденные от валидации, простые и сложные (см. таблицу 1 в разделе 3). Здесь описан подход к валидации простых и сложных компьютеризированных систем, который можно подстраивать под необходимый масштаб.
В данном руководстве излагаются общие принципы валидации компьютеризированных систем OMCL в соответствии с ISO/IEC 17025. Здесь представлены общие требования и перечислено минимально необходимое для валидации различных типов компьютеризированных систем. Поскольку таких систем существует очень много, невозможно включить в один документ все применимые элементы валидации.
Данное руководство предназначено для OMCL, работающих с системой менеджмента качества на основе стандарта ISO/IEC 17025 и использующих компьютеризованные системы для выполнения части или всех процессов, имеющих отношение к контролю качества лекарственных средств. Оно не адресовано производителям, работающим в соответствии с требованиями GMP, или лабораториям медицинской диагностики, в которых компьютеризированные системы используются в соответствии с директивой о медицинских приборах 93/42/EEC.
В целях упрощения данного руководства, документ содержит общее введение и основные требования к различным типам компьютеризированных систем. Этот базовый документ дополнен посвященными системам приложениями, содержащими дополнительные требования и/или практические примеры документов по валидации, которые следует использовать вместе с общими рекомендациями, представленными в данном документе.
Его следует рассматривать как руководство для OMCL по планированию, проведению и документированию валидации их компьютеризированных систем. Не следует воспринимать его как список обязательных требований. Решение о том, какие процедуры наиболее актуальны для подтверждения, что компьютеризированные системы работают должным образом и подходят для предполагаемого использования, принимается в каждой OMCL на основании профессиональной оценки и накопленного опыта.
Компьютерная система — система, включающая один или несколько компьютеров и соответствующее программное обеспечение [1].
Компьютеризированная система — целый комплекс систем, включающий, помимо прочего, автоматизированное производственное оборудование, автоматизированное лабораторное оборудование, контроль над процессом и его аналитическое, производственное воплощение, управление лабораторной информацией, материально-производственное планирование, управление данными клинических исследований, системы надзора и управления документацией. Компьютеризированные системы составляют аппаратные, программные и сетевые компоненты, а также контролируемые функции и соответствующая документация [1].
Коммерческая (готовая, настраиваемая) компьютеризированная система — программное обеспечение, определяемое потребностями рынка и доступное для покупки. Его пригодность к использованию доказана большим количеством конечных пользователей коммерческой продукции. Также называется COTS (серийно выпускаемое изделие) [1].
Разработанная внутри организации (по индивидуальному заказу или заказная) компьютеризированная система — система, произведенная для покупателя по индивидуальному заказу так, чтобы она отвечала определенным требованиям пользователя.
Спецификация требований пользователя (URS) — описание того, что должна делать система [1]. Требования пользователя описывают различные аспекты будущей системы, связанные с наукой, ведением дел, законом, регуляторными требованиями, безопасностью, производительностью и качеством. Они служат основой для квалификации эксплуатации (PQ).
DQ (квалификация проекта) — документально подтвержденная проверка, что предлагаемый проект объектов, систем и оборудования подходит для предполагаемой цели [1].
IQ (квалификация монтажа) — документально подтвержденная проверка, что система установлена в соответствии с заранее согласованными спецификациями в письменном виде [1].
OQ (квалификация функционирования) — документально подтвержденная проверка, что система работает в соответствии с заранее согласованными спецификациями в письменном виде, а также с указанными эксплуатационными диапазонами [1].
PQ (квалификация эксплуатации) или проводимое пользователем приемочное тестирование (UAT) — документально подтвержденная проверка, что система способна выполнять действия в рамках процессов, которые она должна выполнять, в соответствии с заранее согласованными спецификациями в письменном виде и в рамках технологических процессов и условий эксплуатации [1].
Валидация по стратегии «черного ящика» — проверка на основании того факта, что пользователю незнаком исходный код или проект конкретной компьютеризированной системы. Валидация проводится с точки зрения пользователя компьютеризированной или компьютерной системы.
Тестирование по стратегии «черного ящика» — периодическая проверка компьютера, компьютеризированной системы или компьютеризированной системы на основании валидации по стратегии «черного ящика».
Таблица 1: Классификация компьютеризированных систем (на основании [6])
Определение | Примеры | Действие | |
Освобожденные от валидации системы | Нет функции калибровки Фреймворк / уровневое программное обеспечение | Калькулятор, микроскоп, фото или видеокамера, стандартный офисный компьютер, СВЧ и т.д. Операционная система (например, Windows, Linux, Unix), сетевое ПО, ПО системы безопасности (антивирус, брандмауэр), офисное ПО (Word, Excel), системы управления базами данных (например, Oracle, SQL, Access), и т.д. | Нет |
Простые системы | Малая часть программного обеспечения Ограниченная возможность настройки | Измерители pH, окислители, инкубатор, титратор, колориметр, термогигрограф/гигрометр, весы, измеритель частиц, спектрометр в УФ и видимой областях спектра, жидкостный сцинтилляционный счетчик, анализатор ТСХ, ААС, микропланшетный счетчик, анализатор изображений, поляриметр, CombiStats и т.д. | Калибровка Испытание для контроля функционирования |
Сложные системы | ПО с дополнительным объемом функций Расширенные возможности настройки | ЛИМС (лабораторная информационная менеджмент-система), ERP (планирование ресурсов предприятия), СЭД (система электронного документооборота), ЭЛЖ (электронные лабораторные журналы), созданная пользователем в программе Excel таблица, созданное пользователем в программе Access приложение, системы автоматизированной подготовки образцов, жидкостный хроматограф (ЖХ, ВЭЖХ), газовый хроматограф (ГХ), включая автодозатор и системы детектирования (устройства для мониторинга по УФ, видимой области спектра, ИК, МС, ЯМР, радиоактивности или флуоресценции и т.д.), анализатор биопрепаратов, ЭКГ и т.д. | Валидация |
Примечание: Не следует валидировать операционные системы, офисные приложения, базы данных и платформы (например, Windows, Excel, Oracle, SAS). Однако пользовательские приложения, написанные в этих программных пакетах или с их помощью, такие как процедуры SAS, приложения ORACLE и листы Excel (включая сложные расчеты и макросы) следует валидировать.
Должен иметься в наличии инвентарный перечень или список всех компьютеризированных систем.
В него следует включить нижеуказанный минимум информации:
В случае локальной установки (на рабочую станцию) каждой лицензии компьютеризированной системы нужны уникальные идентификационные данные.
Перед использованием в установленном порядке компьютеризированную систему следует валидировать.
Цель валидации — подтвердить путем проверки и предоставления объективных доказательств, что спецификации компьютеризированной системы соответствуют потребностям пользователей и предполагаемому использованию системы и что система способна стабильно справляться с определенными требованиями.
Объем валидации будет зависеть от сложности и предполагаемого использования компьютеризированной системы. Его можно подстраивать и адаптировать в соответствии с типом системы, при условии обоснования с помощью документально подтвержденной оценки рисков. Категории, перечисленные в данном руководстве (см. таблицу 1 в разделе 3), могут использоваться для оценки риска в OMCL.
Использование услуг поставщика
Документы по валидации и результаты испытаний, проведенных поставщиком программного обеспечения, следует прикладывать к файлу OMCL по валидации. Покупателю нет необходимости повторять эти действия. Поставщик должен пройти предварительную квалификацию (например, с помощью заполнения анкеты или проведения аудита).
План валидации
Чтобы гарантировать правильность выполнения валидации, необходим план. В нем описывают все действия, такие как проверка спецификаций требований пользователя, проверка плана разработки (проекта), стратегия проведения испытаний, поверка миграции данных, проверка документов по валидации и приемочные испытания всей системы.
В этом плане указывают дату, ответственное лицо и критерии приемлемости для каждой проверки или испытания, или, по крайней мере, дают ссылки на такие испытания.
План валидации должен быть одобрен ответственным лицом до начала валидации. Показательные примеры и описания испытаний можно добавить позже, если процесс повторяющийся.
Валидация по стратегии «черный ящик» должна быть подходом к проведению испытаний, достаточным для установления того, что компьютеризированная система отвечает нуждам пользователя и пригодна для использования по назначению. Такая валидация может включать:
и/или
и/или
и/или
При валидации компьютеризированной системы, которая не принадлежит OMCL (например, она принадлежит регуляторному агентству/органу), OMCL может провести упрощенную валидацию, учитывая специализированные функции для OMCL, чтобы проверить систему на соответствие требованиям ISO 17025 и руководствам OMCL.
Если между компьютеризированными системами есть интерфейс, например, если ERP и ЛИМС обмениваются информацией, нужно рассмотреть возможность валидации такого интерфейса.
Валидация простых компьютеризированных систем, то есть ненастраиваемых систем или систем с ограниченными возможностями настройки, обычно опирается на калибровку прибора и/или испытание функционирования системы, в зависимости от типа системы.
Считается, что для аналитических приборов, при использовании которых пользователь не может изменять необработанные данные (например, автономные весы, измеритель pH), достаточно калибровки, если с ее помощью можно установить, что система соответствует своему назначению.
Соответствие работы готовых, коммерческих или предоставляемых государственными агентствами/органами приложений в условиях OMCL покажут испытания на соответствие заданным техническим условиям, которые проводятся пользователем. Образец такого подхода дается ниже для CombiStats.
Соответствие и правильность расчетов, выполненных с помощью CombiStats, предварительно проверяются и демонстрируются производителем (в основном, путем сравнения с данными, опубликованными в книге Д.Дж.Финни [7], стандартном справочном материале для статистики в биологических пробах). В результате компьютеризированную систему можно считать пригодной для использования по назначению (т. е., она отвечает требованиям пользователя). Тем не менее, OMCL следует проверить, что после скачивания с сайта EDQM CombiStats работает должным образом на аппаратной конфигурации. Это можно сделать, сравнив результаты по одному и тому же образцу, представленные как в руководстве пользователя (в формате .pdf, послужит «стандартом») так и в «каталоге примеров» (в формате .epa), который автоматически загружается на жесткий диск ПК каждого из пользователей. Статус, присваиваемый по результатам валидации, следует указывать, исходя из этого сравнения.
Шаблоны и листы данных CombiStats должны быть защищены от случайных ошибок и редактирования. Доступно четыре уровня защиты (каждый из них допускает использование пароля). Более подробную информацию сотрудники OMCL могут получить из руководства пользователя, а затем выбрать стратегию валидации в зависимости от внутренних правил и принятых решений.
Валидация сложных компьютеризированных систем начинается с определения спецификации требований пользователя (URS), которая послужит основой для установления требований валидации. Необходим план валидации, в котором будут описаны различные валидационные действия, запланированные для системы и основанные на оценке рисков, а также обязанности различных лиц, задействованных в проведении валидации. Затем с учетом требований пользователя и критериев приемлемости подготавливают протоколы испытаний для IQ, OQ и PQ. Если имеются протоколы испытаний или контрольные списки, предоставленные продавцом, можно использовать для IQ и OQ их. Процесс завершается после составления различных отчетов об испытаниях и окончательного отчета о валидации с утверждением, что компьютеризированная система пригодна к использованию по назначению. Если в ходе валидации обнаруживаются отклонения, следует заняться ими и оценить их влияние на адекватную работу системы.
В случае если компьютеризированная система предназначена для процедур анализа, например, для количественного определения, программное обеспечение представляет собой неотъемлемую часть процедуры. Процедура количественного анализа состоит из образца, стандартного образца, реактивов, использования прибора и его компьютеризированной системы как целого, выстраивания калибровочной кривой с помощью инструмента компьютеризированной системы, использования расчетных формул и т.д. Вся процедура количественного определения подлежит валидации согласно ICH Q2(R1).
Примеры валидации сложных систем даются для электронных таблиц Excel (приложение 1) и ЛИМС/ЭЛЖ/ERP/CDS1 (приложение 2).
Следует регистрировать обнаруженные пользователями проблемы (например, по обращениям в службу технической поддержки) и действия, которые были предприняты в связи с ними.
В случае внесения изменений в компьютеризированную систему, в том числе в случае обновления версий, было бы хорошо вначале проверять все в тестовом режиме, а уже после этой проверки обновлять статус, присваиваемый по результатам валидации. При необходимости повторной валидации ее следует проводить не просто для каждого отдельного изменения, но также чтобы определить его объем и влияние на компьютеризированную систему в целом.
Объем повторной валидации будет зависеть от природы изменения (изменений), которую следует указывать в документации. Одним из возможных подходов может быть использование журналов, как это делается для оборудования, и/или документированной процедуры контроля изменений.
В идеальных условиях автоматические обновления системы должны контролироваться сотрудниками отдела IT или системным администратором и устанавливаться в заранее определенные дни, чтобы свести к минимуму как перебои в работе системы, так и непредвиденные изменения. Может быть необходимо проверять, как компьютеризированная система работает после любых обновлений системы.
В OMCL следует установить порядок периодических проверок компьютеризированной системы, чтобы избежать каких-либо ошибок и гарантировать, что статус, присваиваемый системе по результатам валидации, остается неизменным. Частоту проверок можно устанавливать, руководствуясь подходом, основанным на рисках.
Для компьютеризированных систем следует регулярно проводить внутренние аудиты.
Компьютеризированные системы должны быть защищены от любого несанкционированного доступа, в результате которого могут быть изменены данные и пострадать окончательные результаты.
Следует ограничить доступ в серверные и обеспечить там условия, гарантирующие правильную работу оборудования (контроль температуры, средства пожаротушения, система бесперебойного электроснабжения и т. д.).
Доступ к системам должен быть только у уполномоченных сотрудников, которые будут использовать персональные учетные записи и пароли или аналогичный метод подтверждения личности. Следует избегать использования общих или универсальных учетных записей, чтобы действия, фиксируемые в компьютеризированных системах, можно было соотнести с определенным человеком. Если персональные учетные записи невозможно создать или нецелесообразно заводить, следует регистрировать данные как в электронном, так и в бумажном формате, чтобы проследить действия до совершившего их сотрудника.
Права администратора, позволяющие осуществлять какие-либо обновления компьютеризированной системы и/или устанавливать что-либо, менять критические параметры системы (т. е., контрольный журнал (audit trail), время/дату) и управлять разрешениями для других пользователей, должны иметь только ответственное лицо (ответственные лица) или уполномоченные сотрудники IT отдела. Все штатные задачи, такие как анализ, должны выполняться под учетной записью и паролем без прав администратора.
Права администратора следует предоставлять только сотрудникам, обеспечивающим техническую поддержку (например, из отдела IT), которые никак не связаны с персоналом, ответственным за содержание записей (например, с аналитиками, руководителями лаборатории). Если нет возможности такого независимого распределения ролей безопасности, следует использовать другие стратегии контроля, чтобы сократить риски нарушения целостности данных.
Компьютеры следует блокировать после использования, а пользователи не должны иметь возможности изменять настройки даты и времени.
Используемое аппаратное обеспечение должно отвечать техническим требованиям, так чтобы можно было выполнить предстоящую работу. Такие требования включают, например, минимальные системные требования, указанные производителем оборудования. Эти требования следует заранее определить в соответствии с запланированным назначением системы.
Аппаратные компоненты должны устанавливаться обученными людьми (например, сотрудниками отдела информационных технологий (IT), техническими специалистами производителя оборудования или другими подготовленными работниками), проверяться на предмет функциональных характеристик и сравниваться с требованиями.
Компьютеризированные системы, которые являются частью испытательного оборудования, должны быть снабжены очевидными ярлыками. Следует вести записи о конфигурации, установке и изменениях аппаратного обеспечения. Эти записи можно вести в журнале/формуляре испытательного оборудования.
Компьютеризированная система должна фиксировать любые важные действия, например, кто и когда получал к ней доступ, удалялись ли или изменялись ли данные и т.д. Если компьютеризированная система не ведет контрольный журнал автоматически, сотрудникам OMCL следует фиксировать эту информацию как-то иначе.
У пользователей не должно быть разрешения изменять или отключать контрольные журналы или обходить альтернативные способы обеспечения прослеживаемости их действий.
Необходимость внедрения соответствующих функций ведения контрольных журналов следует рассматривать для всех новых компьютеризированных систем. Если имеющаяся компьютеризированная система не оснащена электронным созданием контрольного журнала, сотрудники могут использовать альтернативные методы, такие как проверяемое в соответствии с процедурой ведение журналов учета, контроль над изменениями, контроль над версиями записей или другие комбинации бумажной и электронной регистрации данных, чтобы отвечать требованиям к прослеживаемости для документирования того, что, кто, когда и зачем сделал.
Если используются электронные подписи, должно иметься постановление об эквивалентности электронной и собственноручной подписи или аналогичный правомерный документ.
Должна обеспечиваться прослеживаемость от необработанных данных до результатов. Если все или некоторые из параметров, имеющих отношение к качеству результатов, прослеживаются только в электронной форме, должен выполняться процесс резервного копирования, чтобы иметь возможность восстановить систему после любого сбоя, который ставит под угрозу полноту прослеживаемости. Частота резервного копирования зависит от важности, количества и частоты формирования данных.
В OMCL следует иметь основные принципы и процедуру, которые гарантируют целостность резервных копий (безопасное место хранения, отделенное соответствующим образом от изначального места хранения, срок хранения и т.д.) и могут быть частью более общего Плана аварийного восстановления.
Также должна иметься процедура для регулярного тестирования резервных копий данных (тестирование восстановления) с целью проверки надлежащей целостности и читаемости электронных записей, а также точности данных. Такое тестирование восстановления может проводиться в рамках периодической проверки системы.
Согласно руководству для OMCL «Управление документами и записями» замененные версии программного обеспечения следует архивировать в восстанавливаемой форме, если они требуются, чтобы обращаться к данным прошлых лет.
Следует гарантировать, что компьютеризированные системы правильно используются и проходят валидацию. Это можно сделать либо путем соответствующего и задокументированного обучения, или путем предоставления подробной информации об этом в соответствующей СОП.
Обучение следует проводить перед первым использованием и после каждого серьезного изменения ПО (например, после обновления версии). Все пользователи, ответственные за валидацию, должны быть обучены процессу проведения валидации.
Таблица 2: Документация компьютеризированной системы
Информация/документация, которая должна быть в наличии | Освобож-денная | Простая | Сложная |
Инвентарный перечень, название, версия и уникальный идентификатор компьютеризированной системы | X | X | X |
Оригинальные файлы (CD-ROM…) или место их хранения для установки компьютеризированной системы, компьютеризированная система для управления вычислительной средой | X | X | |
Дата ввода компьютеризированной системы в эксплуатацию | X | X | |
Лицо, отвечающее за компьютеризированную систему | X | X | |
Наименование производителя, лицензионный или серийный номер или другой уникальный идентификатор, в соответствующих случаях | X | X | |
Условия, в которых работает компьютеризированная система, в соответствующих случаях (аппаратное обеспечение, операционная система, ...) | X | X | |
Сертификат валидации от производителя, если есть | X | X | |
Инструкции производителя, если есть, или ссылка на место их хранения | X | X | |
Документы о валидации конфигураций/модификаций, выполненных пользователем, которые могут повлиять на результаты | X | ||
Имя лица, которое разработало компьютеризированную систему и провело ее валидацию, и дата валидации | X | ||
Исходный код, если доступен | X | ||
Правила работы (СОП) | X | X | |
Документация по периодическим проверкам компьютеризированной системы и результатам аудитов | X | ||
Документы по валидации компьютеризированной системы | X | ||
Действия по итогам обнаруженных сбоев, техническая поддержка процесса, изменения, обновленные версии и, в соответствующих случаях, управление конфигурацией | X | X | |
Досье по обучению | X | X | |
Записи о регулярном тестировании резервных копий (тестирование восстановления) | X | X |
[1] Good Automated Manufacturing Practices (GAMP).
[2] Good Practices for Computerized Systems in regulated “GXP” environments. Pharmaceutical Inspection Convention/Pharmaceutical Inspections Co-operation Scheme (PIC/S).
[3] EU Guidelines to Good Manufacturing Practice (GMP). Annex 11. Computerized Systems.
[4] OECD Series on Principles of Good Laboratory Practices and Compliance Monitoring. Number 17. The Application of the Principles of GLP to Computerized Systems. Environment Monograph no. 13 (2016).
[5] U.S. Food and Drug Agency (FDA) General Principles of Computerized system Validation; FDA Glossary of computerized system and computerized system development terminology
[6] AGIT - Validation of Computerised Systems, V 2.0 (2007)
[7] D. J. Finney - “Statistical Method in Biological Assay”, 3rd Edition, Griffin, London (1978)
[8] WHO TRS 996 Annex 5 - Guidance on good data and record management practices (2016)
К последняя версия применяется к:
Системы сбора и обработки хроматографических данных.