ar-net.ru 11.4.2Стандартные операционные процедуры, разработанные для создания стандартных операционных процедур (СОП для СОП)
Описывается, как должны быть спроектированы СОП, включая конкретные требуемые рубрики и типы информации, кто и за что является ответственным и систему нумерации для всех корпоративных СОП.
11.4.3Валидация компьютерной системы
Имеется корпоративный уровень СОП, который описывает входы и выходы, включенные в разработку плана валидации для компьютеризированной системы. Эти СОП должны быть предназначены для конкретного класса компьютерных систем.
11.4.4Обучение
Обучение охватывает следующие вопросы: как и кто должен обучать, кто должен обучаться, что охватывается обучением, контроль версий учебного материала. Сюда включается информация о том, чьими обязанностями является информирование преподавателей и проходящих обучение лиц. Степень обучения зависит от того, какой доступ к системе необходим для данного лица. Изменения в доступе и/или обязанностях могут потребовать большего объема обучения. Обучение должно включать теоретическое и практическое использование системы, способ документирования учебных записей и т.д.
11.4.5Резервирование и восстановление
Включает процедуры резервирования, использование журнала регистрации, копии с сайта, правила по хранению более ранних версий базы данных (для пропущенных ошибок) и процедуры восстановления.
11.4.6Аварийное восстановление
Данные СОП охватывают те процедуры, которым необходимо следовать в большинстве случаев аварий, таких как пожар, наводнение, саботаж и отказ главной системы или оборудования. Эти процедуры включают определение временных (промежуточных) лабораторных операций, для того чтобы понять, как будет осуществляться деловая активность в течение потери ЛИМС. Данные СОП должны охватывать возможность возобновления деловой активности, как только ЛИМС вновь становится доступной для эксплуатации.
11.4.7Безопасность
Включает системную политику, корпоративную политику и исполнительную политику. Минимальные правила в отношении пароля должны быть конкретизированы и установлены: максимальный срок действия пароля; избегание тривиальных паролей; кто назначает пароли; сроки годности; максимальное количество попыток перед блокировкой и регистрация доступов. Политика безопасности должна включать следующее: когда проводятся просмотры систем безопасности; кто их осуществляет; кто рассматривает результаты, как осуществляются пересмотры политики безопасности и кто назначает обязанности и права. Необходимость для безопасного физического доступа к системе также должна быть включена в СОП. Могут существовать другие процедуры, такие как блокировка клавиатуры, биологическая идентификация и т.д. В данных СОП они должны рассматриваться по мере необходимости.
11.4.8Контроль изменений
Включает идентификацию версии, обслуживание статистических данных, требуемых для документирования старых результатов, правил изменения, требуемых подписей, необходимых повторных испытаний и валидации, необходимых документов. Должно быть рассмотрено влияние изменений на более общую информацию, такую как научные исследования, спецификации материалов или формулировки, методы анализа, параметры методов. Контроль изменений необходим в любое время, чтобы можно было оказывать влияние на работу ЛИМС, например, используя изменения в операционной системе, местной сети, процессоре базы данных, аппаратных средствах или программном обеспечении сервера, программном обеспечении ЛИМС, любых интерфейсах, а также оказывать влияние на все важнейшие исправления, ремонт и многие незначительные исправления.
11.4.9Функционирование (эксплуатация) ЛИМС
Эти СОП должны включать политику в отношении эксплуатации, обязанностей каждого пользователя, распределенных менеджером ЛИМС для конечных пользователей. Если ЛИМС функционирует в локальной или глобальной сети, эти функции могут находиться под различным управлением. Менеджер ЛИМС и организация должны гарантировать, что СОП принимают во внимание данные проблемы, чтобы обеспечить надлежащую поддержку ЛИМС. СОП должны принимать во внимание и другие проблемы ЛИМС, такие как процедуры запуска и выключения, право собственности на поставки, решение обычных (рутинных) проблем и т.д. У некоторых организаций есть конкретные описания работы для персонала. Также на эти описания работы можно сослаться в соответствующих СОП.
11.4.10Обслуживание
Данный пункт включает информацию о том, кто осуществлял обслуживание, когда оно было выполнено, что было сделано и какая документация должна быть создана. Эта информация должна относиться к обоим типам обслуживания - рутинному (обычному) и незапланированному. Документация также требуется для регистрации информации о том, кто утверждал завершение обслуживания, какие повторные испытания были совершены, в случае необходимости - на каком уровне были осуществлены повторная валидация и требуемое документирование. В некоторых отраслях промышленности ремонт должен следовать установленным организацией процедурам контроля изменения.
11.4.11Использование ЛИМС
В данном пункте подчеркиваются уровни ответственности. Можно ссылаться на руководство(а) (инструкции), если они существуют, но руководства или справочники пользователя не должны быть прописаны в СОП. Следует учитывать, что те, кто использует эти СОП, должны быть обучены и знают, как использовать ЛИМС. Необязательно переписывать СОП, если проявляются системные изменения, например, если вместо "log the samples by batch" появляется "log - highlight "by batch" and ".
11.4.12Обработка ошибок
В данном пункте проводится рассмотрение того, как обрабатываются ошибки в ЛИМС. Могут быть разработаны отдельные СОП, или СОП могут быть включены в "Эксплуатационные СОП" ЛИМС. В любом случае ошибки ЛИМС должны быть документированы. СОП должны описать направление действий, которые должны быть предприняты пользователями ЛИМС, когда они сталкиваются с некоей проблемой.
11.4.13Построение шаблонов статических данных
Данный пункт включает спецификации, которые используются в построении различных статических таблиц. Например, СОП могут установить, что все методы испытания будут кодироваться в ЛИМС с использованием определенной системы нумерации метода или что во всех шаблонах результатов испытания будут прослеживаться конкретные элементы данных (наименование испытания, серийный номер лабораторного портативного компьютера испытателя и т.д.).
11.4.14Установка интерфейсов инструментов
Должно быть описано, как новые инструменты соединяются с ЛИМС, как они испытываются, как они валидируются, как они должны использоваться.
11.5Документ, содержащий функциональные требования
11.5.1Документ, содержащий функциональные требования, является ключевым документом в процессе валидации ЛИМС. Этот документ используется для того, чтобы гарантировать, что ЛИМС осуществляет то, что ей предписано делать, и продолжит эти действия, будучи валидированной. Этот документ должен обрисовать в общих чертах бизнес-процессы и регулирующие требования и определить их политику. Поскольку разработка документа с функциональными требованиями является обязанностью команды, работающей над проектом ЛИМС, существенно, чтобы команда по валидации ЛИМС знала и понимала, что должно содержаться в этом документе.
11.5.2Документ, содержащий функциональные требования, должен доступным языком представить требуемые функциональности ЛИМС и проблемы эксплуатации ЛИМС. Этот документ является тем "коммуникационным устройством", которое предназначено для передачи требований продавцу ЛИМС. Кроме того, документ по функциональным требованиям помогает в разработке квалификационных документов и связанных с ними протоколов испытаний. Когда протоколы испытаний будут выполнены, они будут сравниваться с требованиями, детально описанными в этом документе.
11.5.3Данный документ должен содержать подробную информацию, которая охватывает описание системы, ограничения системы, требования, имеющие отношение к продавцу, детализированную системную информацию, общие требования к работе систем, внедрение системы и другие эксплуатационные требования, а также другую документацию для сделанного на заказ программного обеспечения.
11.5.3.1Описание системы должно включать, но не ограничиваться ими, следующие пункты: основная цель, необходимые характеристики окружающей среды системы и связанные интерфейсы, критические для работы системы, а также спроектированный график завершения. Дополнительные пункты также включают словарь терминов, акронимов и сокращений, специфических для ЛИМС, и ссылки на другие корпоративные стандарты.
11.5.3.2Ограничения системы должны включать, но не ограничиваться ими, привилегированные (предпочтительные) платформы для аппаратных средств и программного обеспечения, системные интерфейсы для других систем [лабораторных приборов, локальной сети (Local Area Network, LAN), глобальной сети (Wide Area Network, WAN)] и т.д., будущие требования к расширяемой системе, требования к окружающей среде, среднюю продолжительность эксплуатации системы, планирование требований, доступность исходного кода и требования по обслуживанию.
11.5.3.3Требования, относящиеся к продавцу, должны включать, но не ограничиваться ими, требования к аудиту продавца, компоненты системы продавца (аппаратные средства, исходный код и т.д.), пользовательские руководства, учебные руководства, средства продавца для обслуживания ошибок, обслуживание и обучение.
11.5.3.4Общие требования к целям и задачам обрисовываются в общих чертах в подробном информационном документе системы. Функциональности систем должны быть разделены на три основных блока: требования к входу в систему, обработке данных и выходу из системы. Каждый блок должен описывать субфункциональности, специфические для каждой области. Например, субфункциональность входа должна была бы включать требования для перемещения данных от существующей системы к новой системе ЛИМС.
11.5.3.5Общие требования к работе системы должны охватывать ожидаемое время ответа для конкретных задач с использованием системы, ожидаемое время простоя при обслуживании, требования к обработке ошибок в процессе запуска и отключения системы, требования к резервированию и восстановлению.
11.5.3.6Внедрение системы и другие требования, связанные с функционированием ЛИМС, должны охватывать потребности по поддержке и обслуживанию, вспомогательную документацию, такую как руководство пользователя, руководство администратора, а также требования к архивным и сохраненным данным.
11.5.3.7Для настроенной ЛИМС документ с функциональными требованиями должен включать программы развития систем жизненного цикла, используемые в фазе развития систем жизненного цикла (Systems Development Life Cycle, SDLC), и требуемые элементы для каждой фазы, план по проверке качества, документацию для создания прототипа, требования к управлению конфигурацией и включенных в нее элементов, требования для контроля изменений, требуемые испытания и документацию, которая была создана в процессе испытания разработки, и требования к любой дополнительной документации для действий, осуществляемых после внедрения ЛИМС.
12 Организация (подразделение) по обеспечению качества (QAU)
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО/МЭК 14764*, ГОСТ Р ИСО/МЭК ТО 15271*, ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9001, ГОСТ Р ИСО 9004)
12.1Организация (подразделение) по обеспечению качества (QAU) проводит или помогает в деятельности по интерпретации различных нормативных требований. Эта деятельность распространяется на проблемы, касающиеся валидации компьютерных систем, таких как ЛИМС. Дополнительные функции, имеющиеся у уполномоченных представителей подразделения по обеспечению качества, используются для того, чтобы оказывать воздействие на ЛИМС и валидацию системы ЛИМС, а также включают аудиты продавца, рассмотрение и подписание окончательного плана валидации ЛИМС, заключительный отчет по валидации, текущий мониторинг ЛИМС путем аудитов и запросов относительно контроля изменений и помощь в разработке и обслуживании СОП, относящихся к ЛИМС.
12.2Уполномоченный персонал подразделения по обеспечению качества, который ответствен за валидацию компьютерных систем, должен иметь надежное техническое понимание как нормативов, так и компьютерной технологии. Уполномоченные лица подразделения по обеспечению качества могут использовать внутренний или промышленный курс обучения, читать техническую литературу по этому предмету или работать в связке с опытным экспертом подразделения по обеспечению качества в области валидации компьютерных систем, чтобы получить требуемый уровень знаний в области экспертизы. Крайне необходимым является, чтобы персонал подразделения по обеспечению качества был в курсе изменений технологии.
12.3Команда по валидации должна иметь в своем составе уполномоченного члена подразделения по обеспечению качества (QAU) в самом начале проекта. Ранняя причастность этих лиц к проведению валидации поможет ее реализации различными способами. Во-первых, уполномоченные представители подразделения по обеспечению качества могут получить большее понимание сущности проекта ЛИМС. Во-вторых, они могут указать, какие нормативные требования необходимы при проведении работы команды. Это предоставляет команде по валидации вполне достаточное время, чтобы включить эти требования в проект плана по валидации, вместо того чтобы переделывать проект в связи с проблемами, которые могут возникнуть позже. В-третьих, как только план валидации будет создан, представитель подразделения по обеспечению качества может рассмотреть и предложить исправления к документу. Когда представители подразделения по обеспечению качества (QAU) включаются в работу при запуске проекта, команде по валидации удается лучше приспособиться к принятию календарных графиков проекта.
12.4Также представители подразделения по обеспечению качества ответственны за текущую оценку ЛИМС. Они должны периодически рассматривать процедуры по эксплуатации ЛИМС. Цель состоит в том, чтобы гарантировать надлежащий контроль. Менеджер ЛИМС и другие специалисты должны быть осведомлены о необходимости следовать намеченным процедурам. Областями, которые привлекают наибольшее внимание представителей подразделения по контролю качества, являются те, которые непосредственно затрагивают целостность данных, их точность и безопасность. Представители подразделения по обеспечению качества должны проверять предписанные процедуры по контролю изменений и документацию после любых изменений. Регистрация ошибки и эксплуатационная регистрация должны сохраняться в данных. Требуются значительные дополнительные усилия, если обязанности по обслуживанию ЛИМС распространяются среди нескольких организационных групп (лаборатория, менеджер информационной системы для функционирования сервера, менеджер информационной системы базы данных и т.д.).
12.5Представители подразделения по обеспечению качества (QAU) могут быть включены в следующие этапы проекта ЛИМС:
12.5.1Определение проекта.
12.5.2Функциональные требования.
12.5.3Исследование продавца
Представители подразделения по обеспечению качества могут выполнить аудит продавца, чтобы гарантировать, что при разработке ЛИМС следовали надлежащим методам программного обеспечения. Они должны, по крайней мере, рассмотреть отчет об аудите продавца, если они не принимали непосредственного (фактического) участия в аудите.
12.5.4Переговоры с продавцом
Представители подразделения по обеспечению качества могут быть привлечены к работе в том случае, когда функциональные требования добавляются, снижаются или пересматриваются. Это происходит достаточно часто, для того чтобы устранить разницу между идеальными требованиями и характеристиками, имеющимися в коммерческих ("коробочных") системах.