Что такое валидация требований
7.2.2 Валидация методов
7.2.2.1 Лаборатория должна проводить валидацию нестандартных методов, методов, разработанных лабораторией, и стандартных методов, используемых за пределами их области применения или каким-либо иным образом модифицированных. Валидация должна быть настолько полной, насколько это необходимо, чтобы отвечать потребностям данного применения или области применения.
a) калибровка или оценивание смещения и прецизионности с использованием эталонов или стандартных образцов;
b) систематическая оценка факторов, влияющих на результат;
c) проверка устойчивости метода посредством изменения управляемых параметров, таких как температура в термостате, дозируемый объем;
d) сравнение с результатами, полученными с помощью других валидированных методов;
e) межлабораторные сличения;
f) оценивание неопределенности измерений, связанной с результатами измерений, на основании понимания теоретических принципов метода и опыта его реализации при отборе образцов или проведении испытаний.
7.2.2.2 При внесении изменений в валидированный метод их влияние должно быть определено и, в случае если было установлено, что они оказывают влияние на первоначальную валидацию, должна быть выполнена новая валидация метода.
7.2.2.3 Характеристики валидированных методов, оцененные для предполагаемого использования, должны соответствовать потребностям заказчиков и установленным требованиям.
7.2.2.4 Лаборатория должна сохранять следующие записи о валидации:
a) использованную процедуру валидации;
b) перечень требований;
c) определение характеристик метода;
d) полученные результаты;
e) заключение о пригодности метода вместе с подробным описанием его соответствия в отношении предполагаемого использования.
Валидация и верификация требований к системе
Очень часто путают два понятия валидация и верификация. Кроме того, часто путают валидацию требований к системе с валидацией самой системы. Я предлагаю разобраться в этом вопросе.
В статье «Моделирование объекта как целого и как композиции» я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.
Пусть у нас есть проектируемый функциональный объект. Пусть этот объект рассматривается нами как часть конструкции другого функционального Объекта. Пусть есть описание конструкции Объекта, такое, что в нем присутствует описание объекта. В таком описании объект имеет описание как целого, то есть, описаны его интерфейсы взаимодействия с другими объектами в рамках конструкции Объекта. Пусть дано описание объекта как конструкции. Пусть есть информационный объект, содержащий требования к оформлению описания объекта как конструкции. Пусть есть свод знаний, который содержит правила вывода, на основании которых из описания объекта как целого получается описание объекта как конструкции. Свод знаний – это то, чему учат конструкторов в институтах – много, очень много знаний. Они позволяют на основе знанию об объекте спроектировать его конструкцию.
Итак, можно начинать. Мы можем утверждать, что если правильно описан объект как целое, если свод знаний верен, и если правила вывода были соблюдены, то полученное описание конструкции объекта, будет верным. То есть, на основе этого описания будет построен функциональный объект, соответствующий реальным условиям эксплуатации. Какие могут возникнуть риски:
1. Использование неправильных знаний об Объекте. Модель Объекта в головах у людей может не соответствовать реальности. Не знали реальной опасности землетрясений, например. Соответственно, могут быть неправильно сформулированы требования к объекту.
2. Неполная запись знаний об Объекте – что-то пропущено, сделаны ошибки. Например, знали о ветрах, но забыли упомянуть. Это может привести к недостаточно полному описанию требований к объекту.
3. Неверный свод знаний. Нас учили приоритету массы над остальными параметрами, а оказалось, что надо было наращивать скорость.
4. Неправильное применение правил вывода к описанию объекта. Логические ошибки, что-то пропущено в требованиях к конструкции объекта, нарушена трассировка требований.
5. Неполная запись полученных выводов о конструкции системы. Все учли, все рассчитали, но забыли написать.
6. Созданная система не соответствует описанию.
Понятно, что все артефакты проекта появляются, как правило, в завершенном своем виде только к концу проекта и то не всегда. Но, если предположить, что разработка водопадная, то риски такие, как я описал. Проверка каждого риска – это определенная операция, которой можно дать название. Если кому интересно, можно попытаться придумать и озвучить эти термины.
Что такое верификация? По-русски, верификация – это проверка на соответствие правилам. Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации. Если документация соответствует требованиям этого документа, то она прошла верификацию.
Что есть валидация? По-русски валидация – это проверка правильности выводов. То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте. Проверка правильности применения этих выводов – есть валидация. Валидация — это в том числе проверка описания на непротиворечивость, полноту и понятность.
Часто валидацию требований путают с валидацией продукта, построенного на основе этих требований. Так делать не стоит.
Валидация
Валидация — это проверка значений, указанных пользователем, и отображение найденных ошибок.
Описанное здесь поведение валидаций и отображение ошибок реализовано в библиотеке «React UI Validations», по возможности используйте эту библиотеку в продукте.
Принципы
Валидация на только что открытой пустой форме запрещена. Исключение — черновики, когда пользователь уже заполнял эту форму, через какое-то время вернулся к ней, а она заполнена с ошибками.
Виды валидации
Существует три вида валидаций: мгновенная, по потере фокуса и по отправке формы.
Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.
Самый быстрый способ сообщить об ошибке — мгновенная валидация. Но она возможна только в тех случаях, когда в процессе ввода понятно, что значение некорректное. Обычно такие ошибки связаны с неправильной раскладкой клавиатуры (кириллица вместо латиницы) или вводом букв в цифровое поле (ИНН, КПП и др.) Для этих случаев мы используем поля с масками: ввод неподходящих символов в них заблокирован. Поэтому в наших интерфейсах есть только два вида валидации:
Валидация по потере фокуса
Когда использовать
Этот вид валидации подходит для большинства случаев.
Как работает
Не валидируйте поля на пустоту по потере фокуса — не показывайте ошибку если поле не заполнено, возможно пользователь вернется и заполнит поле чуть позже. Показывать ошибку в таких случаях можно только после отправки формы.
Валидация срабатывает сразу после потери фокуса, если значение в поле заполнено. Если найдена ошибка, поле подсвечивается красным. Фокус в это поле автоматически не возвращается:
Текст ошибки появляется в тултипе, когда поле получает наведение или фокус:
Поле с ошибкой должно остаться подсвеченным, если оно получило фокус, его значение не исправляли, а затем оно потеряло фокус.
Красная подсветка снимается с поля, как только пользователь начал исправлять ошибочное значение.
Валидация при отправке формы
Когда использовать
Используйте этот вид валидации, когда нельзя проверить поля по потере фокуса. Например, для проверки заполнения обязательных полей.
Как работает
Проверка происходит после того, как пользователь нажал кнопку отправки данных: все поля с ошибками на форме подсвечиваются, страница прокручивается к первому полю с ошибкой, фокус перемещается в это поле, курсор встает в конец строки, рядом с полем появляется тултип с подсказкой.
При прокрутке к первому полю от верхней границы окна до ошибочного поля остается отступ 48px — шесть модулей.
Блокирование кнопки отправки
В небольших формах вместо проверки заполнения обязательных полей можно блокировать кнопку отправки формы. Используйте это поведение, когда очевидно, почему кнопка отправки формы неактивна. Например, на форме входа:
Как только заполнены все обязательные поля — кнопка становится активной. Если после этого пользователь стер значение в одном из полей — кнопка снова должна стать не активной.
Сообщения об ошибках
Об ошибках можно сообщать двумя способами:
Из этих двух способов мы рекомендуем использовать тултипы. Они идут отдельным слоем, поэтому не раздвигают форму и легко размещаются, даже если поля на форме расположены плотно.
Тултипы
Как работают
Тултип с подсказкой появляется в двух случаях:
Если значение в поле с ошибкой было изменено, потеряло фокус, а потом заново оказалось в фокусе — тултип с текстом старой ошибки уже не возникает. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.
Тултип исчезает, когда:
Тултип по наведению перекрывает тултип по фокусу.
Тултип может появляться сверху или справа от контрола с ошибкой, так чтобы он не перекрывал полезную информацию:
Единообразие поведения и внешнего вида
Показывайте тултипы справа от полей. Eсли в этом случае они перекрывают важное содержимое на странице, выводите тултипы сверху. Придерживайтесь единообразия, но помните, что контент важнее него.
Красные тексты на странице
Как работают
Красный текст ошибки появляется сразу, как только произошла валидация и ошибочное поле подсветилось.
Как только пользователь начал исправлять значение, красная подсветка поля исчезает, и цвет текста ошибки меняется на черный — #333.
Текст ошибки пропадает по потере фокуса и больше не появляется, если поле заново получает фокус. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.
Выводите текст ошибки справа, если на форме есть место, а само сообщение короткое. Так форму не придется раздвигать, чтобы показать ошибку.
Если справа от поля нет места для текста, раздвигайте форму и выводите сообщение под полем.
На более сложных формах выводите сообщение об ошибке в тултипе.
Валидация зависимых полей
Зависимые поля — это поля, значение которых зависит друг от друга.
Ошибки, которые связаны с нарушением зависимости полей, мы показываем после сабмита формы. Например, ИНН и КПП. Если пользователь указал ИНН из 10 цифр, а поле с КПП оставил пустым, после отправки формы пустое поле с КПП будет подсвечено.
ИНН может быть двух видов:
Если пользователь указал ИНН из 12 цифр, значит организация — индивидуальный предприниматель, и у нее нет КПП, значит поле КПП заполнять не нужно. И наоборот, если заполнено КПП, а ИНН указан 12-значный, возможно неверно указан ИНН.
Подсветка зависимых полей пропадает, как только пользователь начал исправлять значение в одном из этих полей.
Если при заполнении зависимого поля нарушен формат значения, сообщайте о такой ошибке при потере фокуса. Например, пользователь ввел 3 цифры в поле ИНН и убрал фокус. Такое поле должно подсветиться сразу же.
Пример
Есть форма из 5 полей:
Пользователь пропустил поле с названием организации, заполнил ИНН значением из 10 цифр, перешел в поле почты, указал некорректный адрес, перешел в поле с телефоном и указал некорректный номер, но из поля пока не ушел:
Пользователь навел курсор на поле с почтой, появился тултип. Но исправлять значение пользователь не стал:
Пользователь нажал кнопку «Отправить» — фокус перешел в поле «Название организации», так как оно обязательное и незаполненное:
Поле с телефоном также подсветилось красным, так как заполнено некорректно. ИНН и КПП подсветились, так как ИНН состоит из 10 цифр, значит должен быть заполнен и КПП — валидация зависимых полей произошла только после отправки формы.
Пользователь начинает вводить название организации, подсветка поля гаснет, а текст подсказки остается:
Заполнил название организации, перешел в поле ИНН:
Понял, что ИНН правильный, и нужно заполнить КПП:
Начал заполнять поле КПП. Красная рамка у ИНН и КПП исчезла — пользователь изменил значение в одном из зависимых полей:
Заполнил КПП, перешел в следующее поле:
Исправил почту, перешел в следующее поле:
Исправил телефон, кликнул за пределами поля:
Теперь по нажатию кнопки «Отправить» все будет хорошо.
Реализованный пример этой формы можно посмотреть в библиотеке валидаций.
Что такое валидация требований
ГОСТ Р ИСО 11064-7-2016
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ЭРГОНОМИЧЕСКОЕ ПРОЕКТИРОВАНИЕ ЦЕНТРОВ УПРАВЛЕНИЯ
Принципы верификации и валидации
Ergonomic design of control centres. Part 7. Principles for verification and validation
Дата введения 2017-12-01
Предисловие
1 ПОДГОТОВЛЕН Открытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (АО «НИЦ КД») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 201 «Эргономика, психология труда и инженерная психология»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 2 ноября 2016 г. N 1583-ст
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 3.5).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
5 ВЗАМЕН ГОСТ Р ИСО 11064-7-2010
6 ПЕРЕИЗДАНИЕ. Август 2019 г.
Введение
В настоящем стандарте установлены основные принципы, эргономические требования и рекомендации по проверке их выполнения для центров управления.
ISO 11064-1:2000 Эргономическое проектирование центров управления. Часть 1. Принципы проектирования центров управления (ISO 11064-1:2000 Ergonomic design of control centres. Part 1: Principles for the design of control centres).
ISO 11064-2:2000 Эргономическое проектирование центров управления. Часть 2. Принципы организации центров управления (ISO 11064-2:2000 Ergonomic design of control centres. Part 2: Principles for the arrangement of control suites).
ISO 11064-3:1999 Эргономическое проектирование центров управления. Часть 3. Расположение зала управления (ISO 11064-3:1999 Ergonomic design of control centres. Part 3: Control room layout).
Все стандарты серии ИСО 11064 обеспечивают выполнение общих принципов эргономического проектирования при изготовлении и обслуживании центров управления.
Настоящий стандарт будет полезен руководителям проектов, инженерам службы приемки, потребителям, поставщикам и регулирующим органам.
Пользователями настоящего стандарта являются также операторы центров управления и некоторые другие заинтересованные группы пользователей, потребности которых составляют основу эргономических требований, используемых разработчиками международных и национальных стандартов. Применение настоящего стандарта позволяет обеспечить пользователю условия работы, которые в наибольшей степени соответствуют его требованиям. Это способствует снижению количества ошибок и повышению производительности труда.
Применение настоящего стандарта особенно важно при выполнении проектов в области инжиниринга, поскольку способствует оптимальному применению верификации и валидации в процессе реализации проекта. Эффективная проверка выполнения основных эргономических требований и оперативная корректировка проекта позволяют сократить сроки разработки и внедрения нового проекта.
Общие рекомендации по инжинирингу центров управления приведены в приложении ДБ.
Международный стандарт, на основе которого подготовлен настоящий стандарт, разработан Техническим комитетом ISO/TC 159 «Эргономика».
1 Область применения
Применение требований настоящего стандарта очень важно при выполнении инжиниринговых разработок, связанных с созданием или модернизацией центров управления. Проверка эргономических принципов на ранних этапах разработки проекта позволяет сократить время проектирования и внедрения проекта.
Настоящий стандарт может быть применен ко всем типам центров управления, включая центры управления промышленными процессами, транспортными системами и диспетчерскими пунктами аварийных служб. Несмотря на то, что в настоящем стандарте рассмотрены в основном стационарные центры управления, многие приведенные принципы могут быть применены для мобильных центров управления, расположенных, например, на кораблях или на самолетах.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ISO 11064-1:2000, Ergonomic design of control centres: Part 1: Principles for the design of control centres (Эргономическое проектирование центров управления. Часть 1. Принципы проектирования центров управления)
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 процесс проверки (evaluation process): Действия всех видов верификации и валидации проекта, в том числе выбранные методы и регистрация полученных результатов.
3.2 индивидуальная модификация, HED (human engineering discrepancy, HED): Изменение некоторой общепринятой конструкции системы, учитывающее особенности действий или возможностей оператора и/или пользователя.
3.3 резолюция (заключение, выводы) (resolution): Решения по устранению несоответствий, выявленных в процессе проведения верификации и валидации.
3.4 осведомленность ситуации (situation awareness): Понимание оператором/пользователем фактического состояния управляемой системы и/или процесса в каждый момент времени.
3.5 достоверность (validity): Степень, с которой средство или методика измерений могут продемонстрировать способность измерять предназначенную величину.
3.6 валидация (validation): Подтверждение на основе объективных данных, что установленные требования в условиях намеченного использования или применения выполнены.
3.7 верификация (verification): Подтверждение на основе объективных данных, что установленные требования выполнены.
3.8 план верификации и валидации (V&V план) (verification and validation plan): План, специально разработанный для выполнения процедур проверки.
3.9 рабочая нагрузка (workload): Установленные требования к физической и ментальной нагрузке пользователей системы и/или обслуживающего персонала.
4 Требования и рекомендации по организации процесса верификации и валидации
В подразделах 4.1-4.10 представлены общие требования и рекомендации по проведению проверки эргономических требований. В приложении А приведен контрольный лист для проверки выполнения этих требований.
4.1 Основные требования к верификации и валидации
a) Верификация и валидация должны быть частью общего процесса проектирования в соответствии с ИСО 9241-210 и ИСО 11064-1 (см. рисунок 2).
b) Верификацию и валидацию следует проводить на всех этапах жизненного цикла проекта.
c) Испытания должны быть проведены на возможно более ранних этапах проектирования, чтобы можно было выполнить необходимые корректирующие действия.
Результаты предыдущих верификации и валидации могут быть повторно использованы в некоторых случаях. Окончательное решение о приемлемой форме проведения верификации и валидации должно быть индивидуальным в каждом конкретном случае. Дополнительная информация приведена в приложении В.
4.2 План верификации и валидации
a) План верификации и валидации должен быть подготовлен на ранних этапах проектирования до проведения верификации и валидации.
Что такое валидация требований
ГОСТ Р 56431-2015/
GHTF/SG3/N99-10:2004
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМА МЕНЕДЖМЕНТА КАЧЕСТВА
Руководство по валидации процессов
Quality management system. Medical devices. Process validation guidance
Дата введения 2016-07-01
Предисловие
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «МЕДИТЕСТ» (ООО «МЕДИТЕСТ») на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 436 «Управление качеством медицинских изделий»
6 ПЕРЕИЗДАНИЕ. Март 2020 г.
Введение
«Системы менеджмента качества. Руководящие указания по валидации процессов» первоначально завершены в 1999 г. и переизданы под названием «GHTF/SG3/N99-10:2004 (издание 2)» после пересмотра из-за изменений в ИСО 13485, который применяют в некоторых регулирующих системах. Руководящие указания по валидации процессов были пересмотрены начиная с раздела 0 по 3.4, рисунок 1 и приложение В. Выполненный пересмотр можно разделить на две части: 1) редакционный пересмотр терминологии в соответствии с ИСО 13485 (т.е. термин «система качества» изменена на термин «система менеджмента качества», «управление проектированием» изменено на «управление проектированием и разработкой»); 2) изменения на рисунке 1 и далее по тексту для отражения новых требований по валидации процессов, установленных в 7.5.2 ИСО 13485.
Настоящий стандарт оказывает помощь изготовителям в понимании требований системы менеджмента качества в отношении валидации процессов и имеет общее отношение к процессам производства медицинских изделий (включая монтаж и обслуживание). В настоящем стандарте приведены общие предложения в отношении того, как изготовители могут подготовить и выполнить валидацию процессов.
Термин «валидация процесса» использован в области медицинских изделий для обозначения того, что процесс был подвергнут такому тщательному рассмотрению, что на практике обеспечен результат процесса (продукции, услуги или иного). Это существенно необходимо, если соблюдение предварительно установленных требований к продукции можно проверить только путем разрушающего контроля.
Несоответствия в процессах могут стать очевидными только после последующей обработки полуфабриката продукта или применения готовой продукции. Валидация процесса демонстрирует, что если процесс выполняют в установленных границах, то процесс производства продукции будет стабильным в соответствии с предварительно определенными требованиями (при проектировании и разработке).
Медицинская промышленность связана с широким спектром технологий и областей применения: начиная от простых инструментов до сложных хирургических установок с компьютерным управлением, от имплантируемых винтов до искусственных органов, от тест-полосок на наличие сахара в крови до диагностических систем и лабораторного испытательного оборудования. Эти изделия изготавливают в компаниях разного размера, структуры, объема производства, с использованием различных технологий и методов менеджмента. Эти факторы, особенно объем производства и количество технологических операций на единицу (например, этапов пайки или сварки), существенно влияют на то, как фактически применяется процесс валидации. С учетом такого разнообразия настоящий стандарт не предлагает подробных методов внедрения и поэтому не должен быть использован для оценки соответствия требованиям системы менеджмента качества. Настоящий стандарт предназначен для пояснения требований системы менеджмента качества посредством практических объяснений и примеров принципов валидации процессов. Изготовители могут и должны использовать настоящий стандарт по применению процессов валидации с учетом специфики технологии применительно к конкретной ситуации.
Настоящий стандарт дает общие предложения по тому, как изготовители могут подготовиться к валидации процессов и ее осуществлению. Отдельные регулирующие требования определяют ответственность изготовителей в отношении процессов, требующих валидации, и квалификации работников, задействованных в валидируемых процессах. Независимо от метода, используемого для валидации процесса, записи по всей деятельности при валидации и окончательный результат должны быть документированы.
Кроме того, что осуществление процесса валидации является обязательным требованием, изготовитель может валидировать процесс для улучшения качества в целом, устранения отходов, уменьшения затрат, повышения удовлетворенности потребителей или по другим причинам. В сочетании с должным управлением деятельности по проектированию и разработке валидированный процесс может привести к сокращению времени выпуска на рынок новой продукции.
Для управления многими процессами используют компьютеры. Несмотря на то что программные средства компьютеров могут считаться составной частью процесса, настоящий стандарт не охватывают валидацию программных средств.
Некоторые обязательные требования констатируют, что каждый процесс, который не может быть верифицирован последующим мониторингом или измерениями, должен быть валидирован. Настоящий стандарт предназначен для поддержки решений в отношении необходимости валидации.
1 Назначение и область применения
1.1 Назначение
Настоящий стандарт предназначен для содействия изготовителям в понимании требований системы менеджмента качества в отношении валидации процессов.
1.2 Область применения
Настоящий стандарт имеет общее отношение к производственным процессам (включая процессы монтажа и технического обслуживания) медицинских изделий. Специальные рекомендации для верификации выходных данных проектирования и валидации проекта включены в документы GHTF, касающиеся управления проектами.
2 Определения
В настоящем стандарте применимы следующие термины с соответствующими определениями. В отдельных стандартах могут встречаться термины, отличающиеся от приведенных.
2.1 установочная квалификация (installation qualification, IQ): Предоставление объективных свидетельств того, что все ключевые аспекты установки оборудования для процессов и вспомогательных систем соответствуют техническим требованиям изготовителя и что рекомендации поставщика оборудования должным образом учтены.
2.2 операционная квалификация (operational qualification, OQ): Предоставление объективных свидетельств того, что границы управления процессом и пределы выполняемых действий приводят к созданию продукции, удовлетворяющей всем установленным требованиям.
2.3 эксплуатационная квалификация (performance qualification, PQ): Предоставление объективных свидетельств того, что процесс при возможных условиях стабильно производит продукцию, которая удовлетворяет всем установленным требованиям.
2.4 валидация процесса (process validation): Предоставление объективных свидетельств того, что на выходе процесса стабильно получается результат или продукция, удовлетворяющие установленным требованиям.
2.5 протокол валидации процесса (process validation protocol): Документ, определяющий, как валидацию будут проводить, включая параметры испытаний, характеристики продукции, технологическое оборудование и контрольные точки, которые устанавливают приемлемые результаты испытаний.
2.6 верификация (verification:): Подтверждение на основании проверки и представления объективных свидетельств того, что установленные требования были выполнены.
3 Валидация процессов в рамках системы менеджмента качества
Валидация процессов является частью интегрированных требований системы менеджмента качества. Валидацию осуществляют в рамках системы, включающей управление проектированием и разработкой, управление процессами и корректирующие и предупреждающие действия.
Взаимосвязь управления проектированием и процесса разработки может быть очень тесной для некоторых технологий. Для других видов деятельности взаимосвязь может быть косвенной. Продукцию следует спроектировать продуманно, чтобы она выдерживала изменения технологического процесса, и применять воспроизводимый и стабильный технологический процесс для постоянного обеспечения безопасности продукции и функционирования надлежащим образом. Часто это приводит к интерактивным разработкам продукции и деятельности по процессам.
Ежедневную деятельность по мониторингу и измерению проводят в соответствии с планом управления процессом, который часто разрабатывают при валидации процесса.
Корректирующие действия часто выявляют недостаточную валидацию процесса/процессов. Во все корректирующие действия следует включать рассмотрение выполнения валидации и/или повторной валидации процессов.
3.1 Решение по валидации процессов
Модель, представленная на рисунке 1, может быть полезна для определения того, следует или нет валидировать процесс.
Приведенная модель описывает дерево принятия решения, которому изготовитель может следовать для принятия решения о необходимости валидации процесса. В этой модели рассмотрен самый простой процесс, однако многие реальные процессы могут быть более масштабными и/или состоять из совокупности подпроцессов.
Для каждого процесса следует установить технические требования, описывающие параметры процесса и требуемый результат. Изготовителю необходимо принять во внимание возможность верификации последующим мониторингом или измерениями результатов процесса А. При положительном ответе нужно убедиться, достаточна ли только верификация для исключения недопустимого риска и является ли решение рентабельным В. Если проведение верификации достаточно, то результат процесса следует верифицировать, а процессом следует управлять соответствующим образом С.
Если результат процесса нельзя верифицировать, то следует принять решение о валидации процесса D; альтернативой может стать перепроектирование продукции или процесса для уменьшения отклонений и улучшения продукции либо процесса Е. Изменение технологического процесса, кроме прочего, может привести к необходимости валидации процесса, даже если ранее для этого требовались только верификация и управление.
Риск или затраты могут быть также снижены путем изменения проекта (перепроектирование) продукции или процесса таким образом, что простая верификация окажется приемлемым решением Е.
3.2 Примеры
1 Процессы, которые следует валидировать:
— процессы, связанные с обеспечением чистоты помещений;
— процессы асептической расфасовки;
— процессы герметизации стерильных упаковок;
— процессы нанесения покрытий;
— процессы опрессовки пластмасс под давлением.
2 Процессы, которые могут быть удовлетворительно охвачены верификацией:
— процессы ручной резки;
— процессы проверки цвета, мутности, показателя рН для растворов;
— визуальный контроль печатных плат;
— процессы изготовления и испытания электропроводки.
3 Процессы, которые можно верифицировать, но для которых по коммерческим соображениям выбрана валидация:
— некоторые процессы очистки;
— некоторые процессы ручной сборки;
— процессы резки с программным управлением;
— некоторые процессы расфасовки.
Несмотря на то, что результат процесса может быть верифицирован, используемые компьютерные программные средства должны быть валидированы в отношении предназначенного применения.