3.1.10 адаптация ЛИМС для решения определенных задач (LIMS tailoring): см. Загрузка данных в ЛИМС (конфигурирование).
3.1.11 квалификация функционирования (Operational Qualification, OQ): Документированное подтверждение того, что каждая единица или вся система работает так, как предназначено на протяжении всего времени функционирования.
3.1.12 подразделение по обеспечению качества (Quality Assurance Unit, QAU): Организация (подразделение), включающая уполномоченных лиц, ответственных за проект и интерпретацию стандартов по качеству, таких как процедуры и процессы валидации (но не за испытание продукта).
3.1.13 исходный код (source code): Компьютерная программа, выраженная в удобной для восприятия человеком форме (язык программирования), которая переводится в машиночитаемую форму (объектный код) перед тем, как она может быть испытана с использованием компьютера.
3.1.14 статическое испытание (static testing): Структурированное рассмотрение исходного кода.
3.1.15 тестирование в предельных режимах, стресс-тестирование (stress testing): Проверка протоколов испытаний, созданных для испытаний ЛИМС в условиях предельных, критических режимов.
3.1.16 план испытания (test plan): см. Протокол испытания.
3.1.17 протокол испытания (test protocol): Процедура, в процессе которой проводят запись и описание ряда действий и ожидаемых результатов и которая, когда завершено выполнение испытания, обеспечивает документальное свидетельство того, что специфические функциональные требования ЛИМС реализуются так, как предписано.
3.1.18 валидация (validation): Процесс учреждения документированного подтверждения на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены, декларируемые свойства и характеристики подтверждаются, а поставленная цель (предназначение системы, комплекса, устройства и т.д.) достигнута.
3.1.19 план валидации (validation plan): Документ, который определяет все системы и подсистемы, включенные в объем работ по конкретной валидации, а также подходы, с помощью которых они квалифицируются и валидируются, включая определение обязательств и предположений.
3.1.20 команда по валидации (validation team): Группа лиц, ответственных за процесс валидации. Эта команда может состоять из представителей лаборатории, подразделения по обеспечению качества (QAU), организаций в области систем по управлению информацией (Management Information System, MIS) или других сторонних консультантов.
3.1.21 аудит продавца (vendor audit): Независимое рассмотрение и экспертиза системы отчетов и действий, для того чтобы проверить адекватность и эффективность процедур по обеспечению безопасности и целостности данных, гарантировать соответствие установленным методам и эксплуатационным процедурам и рекомендовать любые необходимые изменения.
3.1.22 команда по аудиту продавца (vendor audit team): Команда, состоящая из лиц, которые обладают знаниями, пригодными для проектирования компьютерных систем, а также в области методов аудита, методов квалификации компьютерной системы, соблюдения нормативных требований, методов валидации, методов и процедур в области деловой и правовой активности (применимы только для приобретения компьютерных аппаратных средств и программного обеспечения и связаны с их обслуживанием).
3.1.23 контроль версий (version control): Контроль всех связанных версий программного обеспечения и документов. Он также включает все документы, связанные с внедрением, валидацией или эксплуатацией ЛИМС.
4 Назначение и применение
4.1Валидация является важной и обязательной деятельностью для лабораторий, которые подпадают под пристальное внимание регулирующих агентств. Такие лаборатории производят данные, от которых зависит управление действиями для проведения в жизнь законов и принятия решений в интересах общества. Примерами могут служить данные, используемые для того, чтобы поддерживать утверждение новых лекарственных средств, доказывать, что продаваемые лекарственные средства соответствуют спецификациям, проводить в жизнь экологические законы и разрабатывать свидетельства для судебных процессов. Это также распространяется на ЛИМС, используемые в экологических лабораториях. В некоторых случаях эти системы могут понадобиться для того, чтобы имелась возможность взаимодействия клинической ЛИМС (clinical LIMS) с системой компьютерного учета пациентов (Clinical Patient Records, CPR) для сообщения о влиянии окружающей среды и проведения клинико-лабораторных испытаний для биологических измерений влияния стресс-факторов. Огромное финансовое, юридическое и социальное воздействие этих решений требует государственной и общественной уверенности в лабораторных данных. Чтобы гарантировать эту уверенность, государственные агентства регулярно проводят экспертизу лабораторий, работающих в соответствии с их правилами для подтверждения того, что они производят действительно достоверные данные. Валидация компьютерной системы является частью этой экспертизы. Данный стандарт создан для помощи пользователям при валидации ЛИМС и включения процесса валидации в жизненный цикл ЛИМС.
4.2Валидация должна предоставить свидетельство о процессах испытания, обучения, аудита и рассмотрения, об административной ответственности, управлении проектом и документами в процессе развертывания системы и на протяжении ее эксплуатации.
5 Жизненный цикл ЛИМС и процесс валидации
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО/МЭК ТО 15271*, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 10005, ГОСТ Р ИСО 10006*, ГОСТ Р ИСО 10007, ГОСТ Р ИСО 19011*, ГОСТ Р 53798)
5.1Процесс валидации должен запускаться на начальной стадии жизненного цикла ЛИМС, как это определено в ГОСТ Р 53798. Проведение валидации в конце внедрения ЛИМС могло бы добавить от 3 до 12 месяцев ко времени проектирования ЛИМС. Добавление валидации в конце процесса внедрения ЛИМС препятствовало бы организации использовать ЛИМС в течение валидации. На рисунке 1 представлены пункты, где валидация может воздействовать на приобретение ЛИМС. Валидация не должна воздействовать на весь жизненный цикл ЛИМС, и количество взаимодействий с командой по валидации будет варьироваться в течение каждой фазы жизненного цикла.
 | |
| 805 × 708 пикс. Открыть в новом окне | |
Рисунок 1 - Жизненный цикл ЛИМС
5.1.1Фаза формирования команды по валидации
Эта фаза обычно не является отдельной фазой жизненного цикла ЛИМС, однако является критической частью процесса валидации. Типичная команда состоит из представителей лаборатории, групп специалистов от организаций по системам управления информацией (MIS) и подразделений по обеспечению качества (QAU). Могут быть и другие члены команды, в зависимости от объема проекта и ресурсов организации. Если потребуется, определенные члены команды по валидации должны начать в это время организацию учебных курсов по валидации компьютерных систем. Никакого обучения не должно проводиться до тех пор, пока те, кто был отобран для команды валидации, не получат от своего руководства полного согласия на участие в этой деятельности. Эти курсы могут быть разработаны или внутренними, или внешними специалистами. Команда по аудиту продавца может состоять только из команды по валидации или это может быть специальная группа в пределах организации. Рекомендуется, чтобы команда по аудиту продавца включала организационных участников из структур по обеспечению качества (QAU), систем управления информацией (MIS) и лаборатории.
5.2Фаза определения требований к бизнес-процессам
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО/МЭК ТО 15271*, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9004, ГОСТ Р ИСО 10005, ГОСТ Р 53798)
Организационная единица, а именно лаборатория, должна связаться со специалистами по обеспечению качества (QAU), чтобы определить текущую надлежащую производственную практику (current Good Manufacturing Practices, cGMPs), надлежащую производственную практику (Good Manufacturing Practices, GMPs), надлежащую автоматизированную лабораторную практику (Good Automated Laboratory Practices, GALPs) и другие требования, которые будут рассматриваться в связи с проектом. Первоначальный выбор членов команды по валидации осуществляется в это же самое время.
5.3Фаза подготовки проекта
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО/МЭК ТО 15271*, ГОСТ Р ИСО 9001, ГОСТ Р ИСО 10005, ГОСТ Р ИСО 10006*, ГОСТ Р 53798)
Со всеми членами команды по валидации администрация должна заключить соглашение о проведении валидации. Поскольку валидация является весьма сложным процессом и для нее может потребоваться достаточно длительное время, каждый член команды должен получить полную поддержку от своего руководства. Одним из критических факторов является необходимость в том, чтобы администрация понимала и соглашалась с обязательствами этих лиц. Без соглашения от каждого члена управленческой цепочки вероятность успешной разработки и валидации ЛИМС будет уменьшаться. После формирования команда по валидации может начать работу с рассмотрения проблем верхнего уровня, таких как создание корпоративных стандартных операционных процедур (СОП), необходимых для валидации. Ограничивающими факторами в процессе валидации могут являться временные (календарные) ограничения и неопытность членов команды. Они могут также проявиться, когда команда должна определить внешних консультантов, которые могут быть необходимы для валидации и начала разработки плана валидации. Соответствующее обучение членов команды по валидации также должно быть выполнено в течение этой фазы жизненного цикла ЛИМС.
5.4Модель текущего состояния лабораторной практики
Обычно команда по валидации не принимает участия в этом процессе.
5.5Модель будущего состояния лабораторной практики
Обычно команда по валидации не принимает участия в этом процессе.
5.6Фаза разработки функциональных требований
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО/МЭК ТО 15271*)
Команда по валидации должна работать с группой, ответственной за разработку функциональных требований. В это же время команда может также начать разрабатывать и пересматривать, по мере необходимости, предварительный план проекта по валидации для данной организации. Команда по валидации может изъявить желание начать разработку протоколов испытаний в течение этой фазы. Эта деятельность начинается с того, что команда сосредоточивает внимание на валидации в самом начале проекта. Каждое определенное функциональное требование должно быть предметом одного или более протоколов испытаний.
5.7Фаза запроса предложений (Request For Proposal, RFP)
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО/МЭК ТО 15271*, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9001, ГОСТ Р 53798)
Команда по валидации должна гарантировать, что запрос предложений будет включать как запрос аудита продавца, так и требования к валидации. Лица, использующие этот документ для приемочных испытаний, но работающие в нерегулируемых отраслях промышленности, могут не требовать проведения процесса аудита. Кроме того, команда по валидации должна требовать, чтобы процессы и приложение ЛИМС, разработанные продавцом, были подвергнуты независимой оценке и валидации. Если другая компания, которой может являться консультационная третья сторона или иная организация, валидировала проводимые продавцом операции и процесс развертывания ЛИМС, это не означает, что потенциальный покупатель может предположить, что программное обеспечение валидировано. В течение этого времени команда по валидации должна определить, какие действия предпринимаются, если продавец ЛИМС отказывает им в праве на проведение аудита. Команда по валидации должна рассмотреть запрос предложений (RFP) до его подачи продавцу.
5.8Фаза оценки и выбора
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО/МЭК ТО 15271*, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9001, ГОСТ Р 53798)
Команда по валидации должна определить тех лиц, которые будут принимать участие в экспертизе продавца. Так как для этого процесса может понадобиться от одного до нескольких дней, должны будут посещаться только те производители ЛИМС, которые определяются командой ЛИМС в качестве целевых объектов. Приоритетный выбор ЛИМС должен базироваться на ответах продавца по запросу предложения (Request for Proposal, RFP). В ответах на запрос предложения обычно придается особое значение установленным функциональным требованиям. Необходимо выполнить аудит продавца, чтобы найти встроенную функцию ЛИМС по обеспечению качества. Следует продолжить аудиты продавцов, пока подходящий продавец не будет найден по обоим критериям - функции обеспечения качества и функциональным возможностям. Результаты аудита полезны для оценки того, подвергается ли покупатель риску, когда набор функциональных возможностей системы может влиять на качество развертывания системы. См. раздел 6 для более детального рассмотрения проведения аудитов продавца ЛИМС.
5.9Приобретение ЛИМС
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9001, ГОСТ Р 53798)
Члены команды по валидации должны рассмотреть и принять участие в утверждении заказа на покупку ЛИМС, чтобы гарантировать соответствие как вопросам валидации, так и критериям, выделенным в 5.8, чтобы начать на ранних стадиях управление конфигурированием.
5.10Фаза внедрения
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО 9001, ГОСТ Р 53798)
Команда по внедрению должна завершить подготовку плана валидации и другой документации, которые должны быть одобрены владельцем системы и уполномоченными лицами по обеспечению качества (QAU) прежде, чем план будет выполняться. Разрабатывается календарный график действий. Протоколы испытаний должны выполняться, а результаты - документироваться. Когда все протоколы испытаний будут выполнены и документированы, разрабатывается окончательный отчет по валидации, а затем получают необходимые подписи, требуемые для утверждения данного отчета. Заключительное утверждение будет получено от владельца системы, авторизованного специалистами по обеспечению качества (QAU).
5.11Фаза эксплуатации (функционирования)