ГОСТ Р 58976-2020/ISO/TR 80002-2:2017. Национальный стандарт Российской Федерации. Изделия медицинские. Программное обеспечение. Часть 2. Валидация программного обеспечения, используемого в системах качества медицинских изделий
Приложение B
(справочное)
МЕНЕДЖМЕНТ РИСКА И РИСК-ОРИЕНТИРОВАННЫЙ ПОДХОД
B.1 Введение
В основной части настоящего стандарта было упомянуто, что масштаб усилий и уровень строгости проведения валидации определяются риском, связанным с программным обеспечением.
Более детальная информация приведена в ИСО 14971. ИСО 14971 описывает процесс менеджмента риска, который должен применяться к медицинским изделиям. Базовые принципы и терминология могут также применяться к программному обеспечению, подпадающему под область применения ИСО 14971.
B.2 Терминология
Перечисленные ниже определения заимствованы из ИСО 14971 или основаны на определениях из ИСО 14971:
- опасность: потенциальный источник вреда;
- опасная ситуация: обстоятельства, при которых люди, имущество или окружающая среда подвергаются одной или нескольким опасностям;
- риск: сочетание вероятности причинения вреда и тяжести этого вреда;
- вред: физическая травма или ущерб здоровью людей, ущерб имуществу или окружающей среде;
- тяжесть: мера возможных последствий опасности;
- мера по управлению риском: меры, с помощью которых риски снижаются или поддерживаются в пределах установленных уровней.
B.3 Основные принципы
Основным принципом является снижение до допустимого уровня рисков, связанных с программным обеспечением. Для этого изготовителю необходимо идентифицировать возможные опасные ситуации, связанные с применением программного обеспечения, оценить связанные риски и их соответствие критериям допустимости, которые устанавливаются изготовителем (если не установлены регулирующими требованиями).
Само по себе программное обеспечение не может нанести вред самостоятельно, следовательно, менеджменту риска должен быть подвергнут весь процесс, который управляется программным обеспечением.
B.4 Идентификация опасных ситуаций и определение рисков
В соответствии с подходом ИСО 14971, после установления предусмотренного применения следует идентифицировать возможные опасности и опасные ситуации, а также определить соответствующие риски. Однако возможный вред, который следует принимать во внимание, весьма отличается от вреда, рассматриваемого в ИСО 14971.
Отказ в системе производства и системе качества редко приводит к прямому вреду пациенту или пользователю медицинского изделия, производство или качество которого находится под управлением программного обеспечения. Вред в этом контексте почти всегда косвенный. Наносимый самому медицинскому изделию вред в конечном счете становится источником вреда для пациента или пользователя медицинского изделия. Это не означает, что косвенный вред менее серьезен. Фактически в некотором смысле тяжесть отказа производственных систем и системы качества можно считать более серьезной просто потому, что один их отказ может привести к сбоям во множестве изделий, что в конечном итоге может причинить вред многим пациентам до того, как он будет обнаружен. Отказ программного обеспечения на одном медицинском изделии может нанести вред только одному пациенту за раз.
Как прямой, так и косвенный многократный вред может быть причинен в результате отказа систем производства или системы качества. Следует отметить, что приведенный в нижеследующем списке вред не является взаимоисключающим. Каждый вред из списка может стать источником косвенного вреда для пациентов или пользователей медицинского изделия. Примеры включают, но не ограничиваются следующим:
- вред в отношении медицинского изделия:
- производственное оборудование не отслеживает критически важные
допуски;
- система калибровки неправильно калибрует медицинское изделие для
введения лекарственных средств;
- вследствие отказа контроллера стерилизатора производятся
нестерильные компоненты;
- вследствие отказа системы финального тестирования не
обнаруживаются скрытые дефекты изделия;
- вред в отношении производственного процесса:
- сбой процесса, управляемого программным обеспечением, снижает
производительность, поскольку операции приходится выполнять вручную;
- сбой процессов, управляемых программным обеспечением, приводит к
значительному увеличению количества брака;
- вред в отношении соответствия регулирующим требованиям:
- система обработки жалоб искажает статистику отказов, оставляя
незамеченными дефекты, обнаруженные при эксплуатации;
- система обслуживания или ремонта медицинских изделий не в
состоянии выявить тенденции в отношении проблем, которые могут
указывать на ранее необнаруженные дефекты;
- потеря целостности базы данных имплантированных медицинских
изделий;
- потеря записей по управлению качеством, связанных с проверками
безопасности изготовляемых сборочных элементов/частей;
- потеря данных о соответствии;
- потеря данных по валидации изделий;
- потеря возможности управления и регистрации конфигурации
программного обеспечения в изготовленных изделиях;
- отказ системы обеспечения прослеживаемости (MRP) приводит к
невозможности уведомления потенциальных пользователей этой системы об
отзыве изделий в рамках обеспечения безопасности;
- вред в отношении производственного персонала или окружающей среды:
- оператор травмируется;
- выделяются токсичные химические вещества.
При анализе рисков должны учитываться все категории вреда, связанные с применением программного обеспечения для автоматизации производства и систем качества.
Определение риска включает определение тяжести возможного вреда и вероятности возникновения этого вреда.
Определение тяжести обычно выполняется с помощью классификации (см., например, ИСО 14971:2007, приложение D или G.4), которая связана с уровнем допустимости (см. B.5).
Можно столкнуться с трудностями в определении вероятности вреда, особенно если рассматривать вероятность отказов программного обеспечения, способствующих возникновению вреда. В этом случае следует учитывать, что программный сбой является лишь одним из факторов (другие факторы вне программного обеспечения могут быть частью в последовательности событий), приводящих к причинению вреда. Будет целесообразно предположить наихудший случай в отношении как неизвестной вероятности событий, так и вероятности причинения вреда.
Аналогичный подход используется в МЭК 62304:2006 (включая изменение 1:2015). В качестве основы для принятия решения об уровне строгости при управлении процессом предполагают наиболее неблагоприятную вероятность отказов программного обеспечения, но учитывают более низкую вероятность вреда, связанного с событиями за рамками программного обеспечения (см. также МЭК/ТО 80002-1).
B.5 Оценивание риска
После определения рисков необходимо выполнить их оценивание с целью определения того, являются ли они допустимыми или нет. Если риски недопустимы, изготовитель должен идентифицировать и реализовать меры по управлению риском, которые он разработал для снижения риска допустимого уровня.
Деятельность по установлению допустимого уровня риска, возможно, является самой сложной в рамках всего менеджмента риска и во многом зависит от уровня тяжести возможного вреда. Каждый изготовитель должен установить критерии: для определения и документирования допустимости риска; для идентификации всех рисков в формате, который позволит выполнить их оценивание в соответствии с этими критериями. В целом если допустимый риск снижен до уровня, который можно обосновать коллегам, высшему руководству или аудиторам, то, возможно, этот риск установлен на соответствующем уровне.
Рекомендации о пороговых значениях допустимости риска не входят в область применения настоящего стандарта. Тем не менее некоторые рекомендации по их установлению являются целесообразными:
- конкретность. Критерии допустимости, такие как "как можно ниже" или "настолько безопасно, как и любой другой продукт", являются бесполезными. Критерии должны представлять собой проверяемую спецификацию, чтобы можно было объективно установить выполнение критериев допустимости риска;
- в ситуациях, где трудно определить вероятность причинения вреда, критерии допустимости могут основываться только на тяжести;
- критерии допустимости могут относиться к предварительно выбранным и установленным программным средствам управления процессами (например, к выбору инструментов, перечисленных в таблицах A.1 - A.5);
- идентифицируйте критерии допустимости на начальном этапе. Как только будет идентифицирован возможный риск причинения вреда, следует установить дальнейшую задачу или создать спецификацию на риск. Важно установить дальнейшую задачу в свете допустимости риска, прежде чем пытаться управлять рассматриваемым риском.
Восприятие допустимости риска часто смещается к более высоким уровням после предпринятых попыток управлять риском. Предварительное документирование критериев допустимости предотвращает смещение процесса оценивания риска;
- документирование обоснования по установлению допустимости рисков. Такая документация необходима для последующего поддержания процесса, а также для разъяснения принятых решений инспекторам, действующим от имени регулирующих органов.
B.6 Управление рисками
B.6.1 Недопустимый риск
Если в результате оценивания риск был сочтен недопустимым, изготовитель должен идентифицировать и внедрить меры по управлению риском с целью его снижения до допустимого уровня. Такие меры по управлению риском могут повлиять на программное обеспечение или другие части процесса.
B.6.2 Меры по управлению риском, не влияющие на программное обеспечение
Примерами мер по управлению риском, не влияющих на программное обеспечение, являются процедурные изменения, аппаратное резервирование, системы резервного копирования, системы мониторинга, верификация выходных данных (последующая верификация) или проверки поставщиков.
Доступ к встроенному программному обеспечению производственного процесса может быть затруднен, и его изготовитель может предоставлять недостаточно информации. Типичным примером является встроенное в производственное оборудование программное обеспечение, которое используется при изготовлении медицинского изделия. Валидация этого типа программного обеспечения на предмет его предусмотренного применения может быть затруднена, если программное обеспечение валидируется обособленно.
Мерой по управлению риском, которая особенно хорошо работает в таких ситуациях, является последующая верификация выходов программного обеспечения или выходов устройства, управляемого программным обеспечением. Другими словами, можно непосредственно установить пригодность программного обеспечения для его предусмотренного применения посредством мониторинга выходов процесса, управляемого программным обеспечением, на наличие любых потенциально вредных дефектов. Этот подход мог бы заменить вывод о пригодности программного обеспечения для его предусмотренного применения путем применения методологий управления жизненным циклом программного обеспечения в системе менеджмента качества. Такая методология применима только для процессов с небольшим количеством критических операций, которые можно проверить для каждой детали или для статистически установленной выборки. Инженер по валидации должен подробно изложить обоснование необходимости использования верификации выходов вместо непрерывной верификации, а также обосновать все допущения, связанные с используемой заменой. В этом случае последующим этапом является проверка сделанных допущений.
Верификация выходов должна быть задокументирована так же, как и любая другая мера по управлению риском. В частности, важно задокументировать этот процесс верификации как меру по управлению риском, чтобы впоследствии он не был устранен в рамках мероприятий по сокращению расходов на проект. Кроме того, результаты верификации выходов должны быть задокументированы, поскольку определение валидации требует "предоставления объективных свидетельств" валидации, и этот этап верификации заменяет большую часть валидации. По мере развития продукции предусмотренное применение процесса, управляемого программным обеспечением, также может развиваться. В качестве примера можно рассмотреть управляемое программным обеспечением производственное оборудование, которое первоначально выполняло одну критическую операцию на одном компоненте медицинского изделия. Позднее проект медицинского изделия был изменен таким образом, что на этом программируемом оборудовании стали выполняться две критические операции. Предусмотренное применение такого производственного оборудования изменилось (две критически важные для безопасности операции против одной), следовательно, должна быть изменена верификация выходов для проверки двух операций.
Верификация выходов может быть выполнена с помощью операций, выполняемых вручную, или других выполняемых человеком операций. Примерами могут быть визуальный осмотр неровных краев или механическое выравнивание, а также измерения вручную физических допусков или электрической целостности. Независимо от характера теста, если он является верификацией выхода процесса, управляемого программным обеспечением, а также если он используется в качестве меры по управлению риском для этого процесса, то такой верификационный тест должен быть задокументирован. Процедура тестирования для выполняющего этот тест человека должна быть детализированной и содержать четко определенные критерии принятия и отклонения результатов для каждого тестируемого параметра. Проводящие тестирование люди также должны предоставить документированные свидетельства того, что они выполнили процедуры по тестированию выходов процесса.
B.6.3 Меры по управлению риском, влияющие на программное обеспечение
Мерами по управлению риском, влияющими на программное обеспечение, являются либо изменение проекта, либо выбор средств управления процессом.
В контексте настоящего стандарта выбор средств управления процессом также относится к уровню строгости проведения валидации и предполагает выбор инструментов, определенных в таблицах A.1 - A.5.
Предпочтительно, чтобы хорошо понятные меры по управлению риском, используемые вне программного обеспечения, например "верификация выходов", а также изменения в проекте программного обеспечения были реализованы раньше, чем средства управления процессом.
Тем не менее следует применить минимальный набор средств управления процессом, особенно для обеспечения уверенности в надлежащем внедрении изменений в проект программного обеспечения в качестве мер по управлению риском.
B.6.4 Верификация мер по управлению риском и оценивание остаточного риска
Выполнение мер по управлению риском должно быть верифицировано. Меры по управлению риском, выходящие за рамки управления процессом, должны быть верифицированы на результативность. В этом случае остаточный риск должен быть оценен по критериям допустимости.
Подписаться на обновления