ГОСТ Р 54360—2011
повторной валидации после имевших место изменений. Модернизация программного обеспечения, так
же как изменения порядка использования системы, могут потребовать проведения повторной валида
ции. Комитет по контролю изменений может определить те изменения системы, которые требуются для
повторной валидации. Все изменения должны быть документированы, так же как оценка необходимости
валидации изменений и объем ревалидации. Уровень детализации для процесса ревалидации зависит от
типа изменения. Может понадобиться новая команда по валидации. Эта команда может потребовать
включить некоторые протоколы испытаний, полученные при первоначальном процессе валидации.
Объем повторной валидации в значительной степени зависит от воздействия идентифицируемых изме
нений. Требования к изменениям и проблемам должны быть документированы (приложение Х6).
5.13 Выведение из эксплуатации или замена ЛИМС
(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 14764, ГОСТ Р ИСО/МЭК ТО 15271,
ГОСТ Р ИСО 9000. ГОСТ Р 53798)
Процесс начинается с момента создания новой команды по валидации.
6 Оценка и аудит продавца ЛИМС
(ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК ТО 15271, ГОСТ Р ИСО 9000)
6.1 Промышленные инспекторы требуют от лабораторий гарантий того, что такие компьютерные
приложения, как ЛИМС, валидированы. Владельцы лаборатории несут ответственность задемонстра
цию того, что определенные приложения разрабатываются, испытываются, эксплуатируются и обслу
живаются согласно общепринятой практике в области качества.
6.2 Уполномоченные лица, представляющие регулирующие органы, ожидают, что организацион
ный персонал будет следовать формальной политике управляющих операций, а таюко выполнять на
надлежащем уровне контроль и документирование. Они ожидают, что продавцы используют тот же
уровень контроля качества и политику в области качества, что и заказчик, которому они осуществляют
поставку. Владелец системы является ответственным за то. чтобы следить за работой сотрудников
продавца и проверять, что они используют общепринятые методы для работы на участке заказчика.
Владелец системы может использовать аудит продавца для того, чтобы инспектировать и оценивать
программы, методы и процедуры документирования, предлагаемые продавцом в области обеспече
ния качества.
6.3 Организация может изъявить желание провести процедуры аудита продавца силами третьей
стороны (аутсорсинг), когда она нуждается в организационной экспертизе, рассматривая этот вариант
как более эффективный с точки зрения затрат, или когда организация нуждается в более объективном
или всестороннем аудите. Результаты аудита, полученные от третьей стороны, не связанной с органи
зацией пользователя, или выполненные другой корпорацией, не могут быть использованы в качестве
замены аудита продавца. Альтернативно аудит, который проводится совместно консорциумом корпо
раций. рассматривает конкретные приложения продавца, которые использовались в прошлом с одоб
рения уполномоченного органа.
6.4 Оценка продавца должна происходить в течение фазы «оценки и выбора» жизненного цикла
ЛИМС и перед окончательным выбором продавца. Если организация уже создала команду по аудиту
продавца, эта группа должна рассмотреть требования к функциональностям системы вместе с коман дой
по валидации ЛИМС. Если организация не имеет созданной подобной команды, она может изъя вить
желание, чтобы члены команды по валидации ЛИМС выполняли аудит продавца. Команда по аудиту
должна состоять из опытного аудитора программного обеспечения, внутреннего или внешнего по
отношению к компании, и одного или более лиц из команды ЛИМС. Как правило, ответственным за
долгосрочное взаимодействие с продавцом должен быть кто-то из команды по аудиту. Обычно это
лицо является владельцем системы или приложения.
6.5 Первичная цель аудита состоит в том, чтобы гарантировать, что программное обеспечение и
процедуры управления продавца соответствуют общепринятым методам, то есть тем, которые под
держивают прослеживаемость вплоть до контрольной точки и которые придерживаются этих методов.
Это означает, что команда по аудиту должна оценить, какие меры предпринимает продавец в отноше
нии качества, которое влияет на продаваемый продукт, и поддержки качества, которую он будет обес
печивать вдальнейшем. Команда по аудиту можетстолкнуться сэтой задачей при сборе свидетельств,
которые демонстрируют, что продавец ЛИМС придерживается вполне определенной и документиро
ванной практики разработки программного обеспечения и стандартов или методов обслуживания.
8