Buch lesen: «Проектирование медицинских изделий», Seite 6

4.5.2 Определение потребностей в BioDesign

Рассмотрим, как построен процесс определение потребностей в инновационном процессе биодизайна (Stanford Biodesign), который основан на убеждении, что инновации – это процесс, который можно изучить, практиковать и совершенствовать. Согласно этому подходу, хорошо построенные формулировки потребностей состоят из трех основных компонентов: (1) проблема, (2) целевая группа и (3) целевой результат.

Проблема сообщает о дилемме, связанной со здоровьем, которая требует внимания. Целевая группа населения уточняет группу людей, которая сталкивается с этой проблемой. Результат определяет цель, по которому будут оцениваться решения проблемы. Результаты должны быть сформулированы объективно, чтобы их можно было легко и эффективно измерить. В таблице 4.2 приведены примеры некоторых желаемых результатов, связанных с заявлениями о медицинских показаниях, и рекомендации по их оценке.

Таблица 4.2 – Примеры желаемых результатов

Следует иметь в виду, что первая версия необязательно должна быть идеальной. Одна из стратегий – относиться к определению потребностей как в игре Mad Libs⁵. В этом случае команда или инноватор будет использовать шаблон заявления о потребности «способ решения [указать проблемы] у [указать группу населения], который дает следующий [результат]» и попытаться заменить различные слова, связанные с наблюдениями, которые они сделали, чтобы создать связную картину. Можно попробовать различные варианты, используя, например, стикеры или доску, поэтому легко вносить изменения и экспериментировать с различными сочетаниями слов. Поначалу говорить на «языке» заявлений о потребностях может показаться неудобным, но с практикой это станет легче.

В итоге команда может выбрать версию формулировки потребности, которая наиболее точно и убедительно отражает потребность на основе текущих знаний. Затем по мере углубления знаний в области потребностей посредством действий они могут изменять и уточнять каждое утверждение о потребностях. После того, как новаторы прототипируют свои предварительные формулировки потребностей, следующим шагом будет их активное тестирование и уточнение с помощью упражнения, называемого определением потребности. Определение потребности позволяет дополнительно изучить проблему, совокупность и желаемый результат, а также взаимодействие между этими тремя компонентами с помощью серии мысленных экспериментов, которые приведут к описанию каждого из компонентов, которое является «правильным». Суть определения объема состоит в том, чтобы систематически пробовать различные уровни фокуса или специфичности для каждого из компонентов заявления о потребности, оставаясь при этом сосредоточенным на общей области потребности. Начиная с черновика заявления о потребностях, новаторы задают себе такие вопросы, как:

– Является ли проблема только той, что обозначена в черновике заявления или ее можно расширить?

– Действительно ли эта проблема актуальна для большей группы населения, чем было описано изначально?

– И наоборот, действительно ли эта потребность является наиболее актуальной и важной, когда применяется к меньшей подгруппе населения?

– Является ли результат, описанный в заявлении о потребностях, действительно самым важным или есть другой, более убедительный результат?

– Соответствует ли потребность в ее объеме стратегической направленности команды?

Этот тип определения масштаба позволяет новаторам методично пересматривать предположения, которые они сделали при разработке заявления о потребностях, таким образом, чтобы получить оптимальное определение потребности, поэтому оно является подробным и действенным, но не слишком ограничивающим.

Помимо ловушек, связанных со слишком широким или слишком узким формулированием потребностей, следует упомянуть еще несколько проблем, связанных с этим (рисунок 4.4). Самым сложным из них для начинающих новаторов является желание внедрить решение в потребности. На самом фундаментальном уровне формулировка потребности должна указывать на то, какие изменения в результате требуются для решения заявленной проблемы, а не на то, как эта проблема будет решаться. Слишком часто новаторы включают элементы решения в свои заявления о потребностях, потому что они быстро находят идеи для решения проблем. Это особенно заманчиво, когда уважаемая фигура, например ключевой лидер мнений, предлагает решение того, как он подошел бы к рассматриваемой области потребностей. Иногда это происходит явно, иногда незаметно. В любом случае включение решения в формулировку потребности серьезно сужает диапазон возможных изучаемых возможностей, ограничивает творческий потенциал команды и накладывает ненужные границы на потенциальный рынок. Ещё важно, что это может привести к заявлению о потребности, которое не отражает реальной клинической проблемы, и таким образом способствовать решениям, которые не удовлетворяют потребности эффективно.

Рисунок 4.4 – Ловушки при проектировании

Например, одна молодая компания сосредоточилась на проблеме со стентами (сетчатые трубчатые каркасы, которые размещают в кровеносных сосудах для расширения суженной области). Было отмечено, что, хотя стенты полезны для удержания открытых артерий, во время развертывания они могут вызвать поток эмболов (обломки, которые смещаются, перемещаются по кровотоку и потенциально создают закупорки, застревая в других более мелких кровеносных сосудах). Сосредоточившись на этой проблеме, компания сформулировала потребность в коронарном стенте, который мог бы предотвратить эмболизацию материала стенки сосуда (подразумеваемым результатом этой потребности является минимизация риска инсульта). Члены группы разработчиков предположили, что относительно большие промежутки между стойками стента могут позволить фрагментам атеросклеротической бляшки или тромба сместиться со стенки сосуда и пройти через него, что приведет к дистальной эмболизации. Они решили разработать «покрытый» стент из материала, который растягивался бы над отверстиями и предотвращал разрыв эмболов (рисунок 4.5). Однако после разработки и тестирования они обнаружили, что покрытие препятствует преобразованию (адаптация) поверхности естественного кровеносного сосуда вокруг стента после процедуры, что может привести к другим серьезным осложнениям, включая эмболизацию. В итоге команде не удалось доставить продукт на рынок, а компания была закрыта.

Рисунок 4.5 – Пример размещения сетчатых трубчатых каркасов

Исходя из вышеизложенного видно, что требуются две новые процедуры: процедура создания нового продукта и процедура изменения конструкции. Обе процедуры включают в себя большую часть процесса проектирования. Однако правила гласят, что выходные данные проектирования и разработки должны соответствовать входным данным. Две процедуры сделают это, но нужно зафиксировать этот момент. Отсюда и окончательное одобрение.

4.6 Процедура аудита/обзора

Несколько важных аспектов скрыты в требованиях к проектированию. Во-первых, это необходимость проведения запланированных работ по проектированию и следовательно, требуются формальные обзоры процесса проектирования, например еженедельные совещания по проекту. Тем не менее большинство людей забывают о том, что процесс проектирования действительно работает, а процедуры соблюдаются и документируются.

Во-вторых, в стандарте ISO 13485, которому должна соответствовать система менеджмента качества компании, производящей медицинские изделия, указано, что организация должна проводить внутренние аудиты через запланированные интервалы. То есть система качества имеет процедуру аудита, чтобы гарантировать, что то, что должно произойти, действительно происходит, что любые опасения или неудачи полностью расследуются для выявления первопричины и предпринимаются необходимые корректирующие действия без излишней отсрочки для устранения обнаруженных несоответствий и их причин. В правилах не указано, как часто это должно быть, но не реже одного раза в год, а результаты должны быть официально представлены на собрании руководства (обычно Совету по управлению качеством). Вероятно, имеет смысл проводить аудит процедур более регулярно, иначе все может пойти не так, прежде чем кто-либо заметит. На рисунке 4.6 делается попытка показать, как это может работать.

Главное, что показано на рисунке, это то, что процедура аудита/обзора является постоянной. Это часть цикла непрерывного улучшения качества. Следует запланировать ряд обзоров проекта в течение года, год должен завершаться общим ежегодным аудитом процедур проектирования. Эти обзоры не заменяют регулярных совещаний по дизайну, которые сопровождают каждый проект; они видят все проекты в целом и отслеживают, как они функционируют. Например, в обзоре проекта подчеркивается, что один человек постоянно забывает обновлять номера редакций на чертежах деталей (поэтому никто не знает, какой чертеж является самым последним). Это явно проблема, решение которой не может ждать конца года. Вопрос поднимается как несоответствие (это означает, что он не соответствует процедурам), и разрабатывается план его устранения. План реализуется, а затем оценивается результат. После подтверждения того, что номера редакций теперь обновлены, несоответствие закрывается.

Рисунок 4.6 – Возможный цикл обзора проекта и его аудита (см. пояснения в тексте)

Этот процесс проверки гарантирует, что любые проблемы будут обнаружены на раннем этапе и устранены с помощью планирования, реализации и окончательных проверок, работающих должным образом. Но что еще более важно, он включает в себя обучение на ошибках и улучшения процедур проектирования, чтобы гарантировать, что это не повторится.

Однако ежегодный аудит играет более стратегическую роль в обеспечении качества и рассматривает процедуры проектирования в целом:

– работают ли они?

– есть ли повторяющиеся проблемы?

– есть ли области для улучшения?

Глядя на год в целом, формируется более широкая картина. Кроме того, этот ежегодный аудит предоставляет группе управления качеством (и любым внешним аудиторам) доказательства того, что контроль конструкции, предусмотренный в рекомендациях ISO 13485, осуществляется. Он также предоставляет общие доказательства, требуемые ежегодными внешними аудиторами, которые будут проверять, может ли компания сохранить свой статус производителя медицинского оборудования.

Цель процессов аудита и проверки:

1. Предоставить доказательства того, что команда разработчиков соблюдает процедуры, которые установили, чтобы изделия были разработаны в соответствии с правилами и обеспечить наличие необходимых документальных доказательств.

2. Чтобы команда управления дизайном могла постоянно улучшать качество дизайна продукта.

3. Выявить любые проблемы несоответствия и исправить их как можно скорее, прежде чем они смогут нанести какой-либо долгосрочный ущерб.

Необходимо разработать план аудита. Этот план лучше всего определяется ежегодным аудитом проекта на следующий год. План аудита – это буквально, список всех процедурных моментов, на которые аудитор должен обратить внимание, чтобы подтвердить наличие доказательств того, что была соблюдена правильная процедура. Аудитор не обязан смотреть на все подряд: он выбирает случайным образом из целого. Не каждый аудит должен охватывать все процедуры, но к концу года все процедуры должны быть охвачены.

Следует отметить, что аудит процедур проектирования будет контролироваться, в основном Управлением качеством. Однако процесс аудита должен работать, поэтому он должен быть «разработан» в соответствии с конкретными потребностями, а не просто скопирован откуда-то.

4.7 Процесс проектирования
4.7.1 Процесс проектирования нового продукта

На рисунке 4.7 показана типичная процедура последовательного проектирования.

Рисунок 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 проект необходимо верифицировать и валидировать. Верификация связана с тем, чтобы убедиться, что выходные данные проекта соответствуют входным данным. Если предусмотренное применение содержит требование, чтобы медицинское изделие было подключено или имело интерфейс для соединения с другим(и) медицинским(и) изделием(ями), верификация должна включать проверку того, что выходные данные проекта соответствуют входным данным при таком подключении или соединении через интерфейс.

Валидация связана с проверкой того, что выходные данные работают в клинической среде. Валидация должна быть проведена на типовом (репрезентативном) изделии. Типовое изделие может представлять собой первые образцы продукции, партии или их эквиваленты. Обоснование выбора таких продуктов для валидации должно быть документировано. Как часть валидации проектирования и разработки разработчики должны выполнять клинические оценки или оценивание функциональных характеристик медицинского изделия в соответствии с применимыми нормативными требованиями. Важно помнить, что медицинское изделие, используемое для клинической оценки или оценивания функциональных характеристик, не рассматривается как выпущенное для использования потребителем.

Обе процедуры очень похожи по концепции и используются в качестве основы для оценки проекта (рисунок 4.8).

Рисунок 4.8 – Процедура оценки проекта

Важным аспектом здесь является тот факт, что изделие необходимо будет верифицировать или валидировать по некоторым критериям. Необходимо выбрать эти критерии, а также разработать и утвердить протокол оценки. В процессе проектирования эта процедура будет использоваться и тестироваться много раз, так как она является основой проверки соответствия проекта. Кстати, под эту процедуру подпадают клинические испытания и т. д. Также стоит отметить, что окончательная оценка, верификации и валидация будут указаны в исходной спецификации дизайна продукта.

4.7.4 Изменения дизайна

Эта процедура требуется для соответствия ISO 13485 7.3.9. По сути, у него две основные цели: во-первых, чтобы убедиться, что изменения дизайна значимы для функциональных, эксплуатационных требований, требований удобства пользования, безопасности и применимых нормативных требований в отношении изделия и его предусмотренного применения, во-вторых, чтобы гарантировать, что любые изменения осуществляются правильно, то есть включают оценку влияния изменений на составные части, полуфабрикаты или уже поставленную продукцию, на входные или выходные данные менеджмента риска и процессы жизненного цикла продукции.

Неудивительно, что изменение дизайна похоже на полностью новый дизайн продукта. Однако есть два основных отличия. Во-первых, эта процедура всегда будет относиться к существующему файлу проекта, поэтому первым шагом является открытие существующего файла. Эта процедура предназначена только для документации – она предназначена для правильного внесения изменений. Следовательно, приняв изменение, нужно убедиться, что оценены риски, связанные с указанным изменением. Конец (выход) процедуры отличается; здесь нужно убедиться, что изменение (или изменения) полностью задокументировано в файле, а старые документы сохранены в репозитории (рисунок 4.9).

Рисунок 4.9 – Процедура изменения дизайна

Отметим, что некоторые изменения в проекте можно отслеживать внутри; в отношении других необходимо будет информировать регулирующие органы.