Игорь Иванов – Проектирование медицинских изделий (страница 15)
Этот процесс проверки гарантирует, что любые проблемы будут обнаружены на раннем этапе и устранены с помощью планирования, реализации и окончательных проверок, работающих должным образом. Но что еще более важно, он включает в себя обучение на ошибках и улучшения процедур проектирования, чтобы гарантировать, что это не повторится.
Однако ежегодный аудит играет более стратегическую роль в обеспечении качества и рассматривает процедуры проектирования в целом:
– работают ли они?
– есть ли повторяющиеся проблемы?
– есть ли области для улучшения?
Глядя на год в целом, формируется более широкая картина. Кроме того, этот ежегодный аудит предоставляет группе управления качеством (и любым внешним аудиторам) доказательства того, что контроль конструкции, предусмотренный в рекомендациях ISO 13485, осуществляется. Он также предоставляет общие доказательства, требуемые ежегодными внешними аудиторами, которые будут проверять, может ли компания сохранить свой статус производителя медицинского оборудования.
Цель процессов аудита и проверки:
1. Предоставить доказательства того, что команда разработчиков соблюдает процедуры, которые установили, чтобы изделия были разработаны в соответствии с правилами и обеспечить наличие необходимых документальных доказательств.
2. Чтобы команда управления дизайном могла постоянно улучшать качество дизайна продукта.
3. Выявить любые проблемы несоответствия и исправить их как можно скорее, прежде чем они смогут нанести какой-либо долгосрочный ущерб.
Необходимо разработать план аудита. Этот план лучше всего определяется ежегодным аудитом проекта на следующий год. План аудита – это буквально, список всех процедурных моментов, на которые аудитор должен обратить внимание, чтобы подтвердить наличие доказательств того, что была соблюдена правильная процедура. Аудитор не обязан смотреть на все подряд: он выбирает случайным образом из целого. Не каждый аудит должен охватывать все процедуры, но к концу года все процедуры должны быть охвачены.
Следует отметить, что аудит процедур проектирования будет контролироваться, в основном Управлением качеством. Однако процесс аудита должен работать, поэтому он должен быть «разработан» в соответствии с конкретными потребностями, а не просто скопирован откуда-то.
4.7 Процесс проектирования
4.7.1 Процесс проектирования нового продукта
На рисунке 4.7 показана типичная процедура последовательного проектирования.
Безусловно, все зависит от определения потребности, как показано на рис. 4.1. Во-первых, необходимо назначить ответственного за проект или руководителя проекта. В обязанности этого человека будет входить контроль и отслеживание того, чтобы проект выполнялся в соответствии с графиком, чтобы были соблюдены все процедуры, и документация была завершена. Процедура теперь расширяет потребность, разрабатывая полную спецификацию продукта в процедуре уточнения. Процедуры следуют друг за другом до окончательного утверждения выпуска. В документированной процедуре трудно представить что-либо, кроме последовательного, каскадного потока активности.
Ценно, что после каждого процедурного шага есть возможность просмотреть результаты и подтвердить, являются ли они подходящими, правильными и соответствующими ожиданиям. Ясно, что, если все хорошо, они одобрены, это делается официально с подписью и датой. Также стоит воспользоваться возможностью просмотреть файл истории проектирования после каждой процедуры. Это позволяет увидеть, не было ли что-то упущено или какие- либо процедуры были применены неправильно. Гораздо эффективнее поддерживать этот файл в актуальном состоянии по мере продвижения по пути проектирования. Кроме того, это возможность просмотреть любой анализ рисков. Он для проекта актуален и изменяется по мере разработки проекта. Поэтому рекомендуется проводить обзор анализа рисков как часть каждого этапа утверждения. Это будет способствовать получению обратной связи.
Например, конструкция медицинского термометра может не совсем соответствовать требованию измерять температуру до 42°C; на самом деле она измеряется до 39,95°C. По критериям это неудачный проект и должен быть отвергнут. Тем не менее рекомендуется проводить анализ рисков, который на самом деле предполагает, что это приемлемо и не представляет риска, поэтому дизайн может быть продолжен.
В качестве альтернативы может быть автоматизированная система инъекций инсулина, которая не может привести к передозировке пациента, но при определенных обстоятельствах она обеспечивает дозу 110 %. Здесь анализ рисков указывает, что риск неприемлем, и, следовательно, проект отклоняется с приложенной обратной связью.
Следовательно, хороший анализ рисков является ценным инструментом для руководителя проекта. Если все не так, информация о несоответствии и основная причина должны быть возвращены соответствующему источнику. Выявление первопричины очень важно – в этом помогает анализ рисков.
После выполнения каждой отдельной подпроцедуры конечный продукт должен быть готов к выпуску. В этот момент файл истории дизайна/файл дизайна/технический файл закрывается как новый продукт.
4.7.2 Процедура спецификации продукта
Как отмечалось выше, когда продукт проектируется, его требования и спецификации документируются, чтобы группы разработчиков могли понять, каким будет продукт, как он будет выглядеть и какие функции он будет выполнять. Этот проект, включающий детали продукта, воспринимается как технические характеристики продукта. Он также называется, как уже было указано выше, «спецификации продукта» или «спецификация дизайна продукта» (product design specifcation, PDS) и информирует группы разработчиков об особенностях продукта, потенциальных пользователях, пользовательских историях и других важных деталях, чтобы они могли принимать наилучшие решения при разработке продукта. Спецификация продукта – это процесс перечисления всех аспектов и функций, которые стратегически должны присутствовать в продукте. По сути, это документ, который содержит все требования, которые должны быть в продукте. Эта процедура важна, поскольку она отвечает всем требованиям, связанным с входными данными, в рекомендациях ISO 13485.
Задача дизайнера – определить элементы, оказывающие влияние на проектирование изделия и воплотить их в жизнь. Некоторые источники всегда будут иметь влияние (например, стандарты), некоторые не будут (например, литература). Очень важным источником для спецификации будет первоначальный анализ рисков. Этот первоначальный анализ поможет понять всю область, в которой будет проектирование. Понимание риска – это большой шаг к пониманию реальности ситуации.
Конечной целью этой процедуры является демонстрация связи между разработчиком спецификации продукта и источниками. В эту процедуру должна быть встроена непрерывная обратная связь, чтобы первичные источники, т. е. конечные пользователи, пациенты и заказчики, могли оказывать существенное влияние на саму спецификацию. Это позволит разработать надежную спецификацию. Каждый шаг зафиксирован, создан черновик для комментариев, каждая итерация прописана. Важно, чтобы все было задокументировано и сохранено в истории проектирования. Как только команда будет удовлетворена спецификацией продукта, она может быть передана на окончательное утверждение перед началом следующего этапа. Как уже отмечалось, входными данными являются заявление о потребности и данные из источников; следовательно, спецификация продукта (выход) должна соответствовать требованиям потребности и отражать требования источников.
Кроме того, спецификация должна относиться не только к самому изделию, но и к любой сопроводительной документации и т. д. Например, все изделия должны иметь маркировку, и спецификация должна удовлетворять эту потребность. Еще одним примером является то, что потребуются инструкции по использованию изделия; спецификация должна учитывать и это.
4.7.3 Процедура верификации/валидации/оценки проекта
Чтобы соответствовать требованиям, указанным в пунктах 4.2.4 и 7.3.4 стандарта ISO 13485 проект необходимо верифицировать и валидировать. Верификация связана с тем, чтобы убедиться, что выходные данные проекта соответствуют входным данным. Если предусмотренное применение содержит требование, чтобы медицинское изделие было подключено или имело интерфейс для соединения с другим(и) медицинским(и) изделием(ями), верификация должна включать проверку того, что выходные данные проекта соответствуют входным данным при таком подключении или соединении через интерфейс.
Валидация связана с проверкой того, что выходные данные работают в клинической среде. Валидация должна быть проведена на типовом (репрезентативном) изделии. Типовое изделие может представлять собой первые образцы продукции, партии или их эквиваленты. Обоснование выбора таких продуктов для валидации должно быть документировано. Как часть валидации проектирования и разработки разработчики должны выполнять клинические оценки или оценивание функциональных характеристик медицинского изделия в соответствии с применимыми нормативными требованиями. Важно помнить, что медицинское изделие, используемое для клинической оценки или оценивания функциональных характеристик, не рассматривается как выпущенное для использования потребителем.