ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

58976—

2020/

ISO/TR 80002-2:2017

Изделия медицинские ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

Часть 2

Валидация программного обеспечения, используемого в системах качества медицинских изделий

(ISO/TR 80002-2:2017, Medical device software — Part 2: Validation of software for medical device quality systems, IDT)

Издание официальное

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «МЕДИТЕСТ» (ООО «МЕДИ-ТЕСТ») на основе официального перевода на русский язык англоязычной версии указанного в пункте 4 международного документа, который выполнен рабочей группой в составе представителей ООО «МЕДИТЕСТ» и Общества с ограниченной ответственностью «АУРИГА» (ООО «АУРИГА»)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 436 «Менеджмент качества и общие аспекты медицинских изделий»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 августа 2020 г. Не 566-ст

4    Настоящий стандарт идентичен международному документу ISO/TR 80002-2:2017 «Программное обеспечение медицинских изделий. Часть 2. Валидация программного обеспечения, используемого в рамках систем качества медицинских изделий (ISO/TR 80002-2:2017 «Medical device software — Part 2: Validation of software for medical device quality systems». IDT).

Наименование настоящего стандарта изменено относительно наименования указанного международного документа для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5)

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агонпютва по техническому регулированию и метрологии в сети Интернет (www.gosf.ny)

© ISO. 2017 — Все права сохраняются © Стандартинформ. оформление. 2020

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

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

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

В следующих подпунктах настоящего стандарта представлены дополнительные детали по управлению на каждой из стадий жизненного цикла программного обеспечения в системе менеджмента качества. изображенных на рисунке 1. В этих подпунктах используется изображение последовательности действий итеративного анализа рисков: валидации программного обеспечения; действий с программным обеспечением, показанных на рисунке 2. Далее приведены описание областей, в которых необходимо принятие решений; факторы, влияющие на принятие решений, которые включают в себя подход на основе критическиГи мышления.

5.2 Установление необходимости валидации программного обеспечения

5.2.1    Идентификация процесса и применяемого программного обеспечения

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

5.2.2    Оценка применимости регулирующих требований

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

a)    Могут ли отказ или скрытые недостатки программного обеспечения повлиять на безопасность или качество медицинских изделий?

b)    Рассматриваемое программное обеспечение автоматизирует или выполняет деятельность, которая установлена регулирующим требованиями (в частности, требованиями к системам менеджмента качества медицинского изделия)? Примеры могут включать сбор цифровых подписей и/или записей, поддержание прослеживаемости продукции, выполнение и сбор результатов испытаний, ведение журналов данных (например, по корректирующим и предупреждающим действиям, по несоответствиям, претензиям, калибровке и т. д.).

Ответ «да» на любой из вопросов идентифицирует программное обеспечение, которое требует проведения валидации и входит в область применения настоящего стандарта.

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

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

Если процессы или программное обеспечение содержат функциональные возможности, которые выходят за рамки действия регулирующих требований в отношении медицинских изделий, то следует проанализировать, какие компоненты программного обеспечения находятся в области применения настоящего стандарта, а какие — нет. Такие решения должны быть обоснованы исходя из степени интеграции между различными компонентами, модулями и структурами данных программного обеспечения и в соответствии с применимыми к организации требованиями соответствия. Приведение такого обоснования особенно важно в случае программного обеспечения, используемого для поддержки системы качества [например, программного обеспечения для планирования корпоративных ресурсов (ERP)]. Программное обеспечение ERP может включать функциональные возможности для процессов, не связанных с медицинским изделием, таких как бухгалтерский учет и финансы. Функциональность может иметь решающее значение для деловых операций и должна соответствовать определенным государственным требованиям (например, требованиям Закона Сарбейнса — Оксли).

5.3    Стадия разработки

5.3.1    Планирование валидации

Первая часть деятельности по планированию валидации с применением критического мышления использует результаты анализа риска процесса (см. приложение В) с целью установления масштаба усилий, которые следует применять к созданию документации, а также для выбора инструментов из раздела «Набор инструментов» блока «Определение/Идентификация» (см. таблицы А.1—А.5). Вторая часть использует результаты анализа риска программного обеспечения с целью выбора инструментов (из набора инструментов) для имплементации, тестирования и развертывания. После выполнения деятельности и установления валидированного состояния программного обеспечения свидетельства валидации документируются в отчете По Валидации.

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

5.3.2    Определение/Идентификация

5.3.2.1 Требование блока «Определение/Идентификация»

Деятельность, выполняемая в рамках блока «Определение/Идентификация» (см. рисунок 1), включает определение/идентификацию процесса, определение предусмотренного применения программного обеспечения в этом процессе, а также планирование масштаба усилий по валидации на основе рисков, идентифицированных в рассматриваемом процессе. Рисунок 3 иллюстрирует эту часть стадии разработки в рамках выбранного примера Каскадной модели.

-    риск причинения вреда людям: это включает прямой вред пациентам и пользователям, а также косвенный вред, когда происходит отказ/сбой программного обеспечения, управляющего изготовлением или качеством изделия, что приводит к неисправности самого изделия и причинению вреда;

-    регуляторный риск: риск несоблюдения регулирующих требований следует учитывать, если отказ программного обеспечения может привести к потере записей (например, корректирующих и предупреждающих действий, претензий, записей, относящихся к техническому файлу или файлу проектирования и разработки), требуемых регулирующими органами, или к отклонениям от процедур системы качества и Производственных процедур;

-    риск влияния на среду применения: риск для среды, как физической, так и виртуальной, в которой используется программное обеспечение.

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

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

5.3.2.4    Планирование валидации

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

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

5.3.2.5    Предусмотренное применение программного обеспечения

5.3.2.5.1 Элементы предусмотренного применения

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

Предусмотренное применение программного обеспечения содержит три основных элемента:

-    цель и назначение, которые связаны.

-    с использованием программного обеспечения (например, кто. что. когда, почему, где и как):

-    с соблюдением регулирующих требований при использовании программного обеспечения;

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

-    требования к использованию программного обеспечения. Поскольку с увеличением сложности, как правило, возрастает риск, этот элемент предоставляет более подробную информацию относительно применения программного обеспечения (например, варианты использования, требования к пользователю);

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

Ю

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

Поскольку валидация проводится для «предусмотренного применения», важно понимать, что полноценное проведение валидации невозможно без полноценного установления предусмотренного применения для программного обеспечения.

Далее приведены дополнительные сведения об элементах предусмотренного применения программного обеспечения.

5.3.2.5.2 Цель и назначение программного обеспечения

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

а) Использование программного обеспечения

-    При определении использования программного обеспечения необходимо учитывать следующие вопросы: «что?», «почему?», «как?», «кто?», «где?» и «когда?». Ответы помогают понять, как программное обеспечение используется для соответствия требованиям процесса. Как показано в таблице 1, такой механизм помогает выявить базовую информацию для определения предназначения программного обеспечения.

-    Ответы, которые имеют значение для описания программного обеспечения, должны быть включены В Документированное определение Предполагаемого использования.

Таблица 1 — Примеры вопросов и ответов

Вопрос Ответ На решение какой проблемы направлено программное обеспечение? Проблемы в эффективном и точном обобщении данных о дефектах продукта для анализа тенденций Почему программное обеспечение полезно? Программное обеспечение позволяет обобщать и анализировать данные из различных мест по всему миру Как программное обеспечение решает проблему? Программное обеспечение управляет процессом сбора данных и автоматически обобщает и анализирует информацию о тенденциях, или программное обеспечение не управляет процессом, но обеспечивает пассивный сбор данных, используемых для обобщения и анализа информации о тенденциях Кто использует программное обеспечение? Отделы обеспечения качества и эксплуатации Где используется программное обеспечение? Доступ к программному обеспечению осуществляется в США. Европе и Японии Когда используется программное обеспечение? Доступ к программному обеспечению осуществляется в рабочее время по всему миру (т. е. ежедневно, с понедельника по пятницу) Примечание — Данные примеры вопросов не являются исчерпывающими.

Ь) Регуляторные аспекты использования программного обеспечения

-    При оценке регуляторных аспектов использования можно дополнительно изучить ответы на вопросы, чтобы определить, входит ли программное обеспечение в область применения настоящего стандарта (см. 5.2). Следует более подробно объяснить все ответы «да» с целью определения причины таких выводов. Когда программное обеспечение определено как входящее в область применения настоящего стандарта, необходимо определить любой потенциальный вред для людей (не являющихся пользователями медицинского изделия) или для окружающей среды. Предложенные далее вопросы акцентируют внимание пользователя настоящего стандарта на элементы, которые являются частью регулирующих требований, таких как область здравоохранения, безопасность и действительность или подлинность электронных записей и подписей.

-    Как отказ или скрытые недостатки программного обеспечения могут повлиять на безопасность или качество медицинских изделий?

-    Как программное обеспечение автоматизирует или выполняет действия, установленные в регулирующих требованиях, в частности требованиях к системам менеджмента качества медицинских изделий?

-    Как программное обеспечение может причинить вред людям (не являющимся пользователями медицинского изделия) или окружающей среде?

с) Границы применения программного обеспечения

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

-    Границы программного обеспечения в процессе

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

-    Границы с другим программным обеспечением

-    При внешнем взаимодействии с другим программным обеспечением, используемым в рамках систем качества медицинских изделий, или с программным обеспечением медицинских изделий (включая случаи, когда программное обеспечение само по себе является медицинским изделием) важно идентифицировать все интерфейсы между приложениями. Хотя масштаб усилий и трудозатраты по валидации обычно включают внутренние интерфейсы как неотъемлемую часть используемого метода, внешние интерфейсы программного обеспечения не должны игнорироваться. Все интерфейсы между программными приложениями должны быть охвачены процессом критического мышления.

5.3.2.5.3    Требования к использованию программного обеспечения

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

5.3.2.5.4    Требования к программному обеспечению

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

5.3.3 Имплементация, тестирование и развертывание

5.3.3.1    Требуемая деятельность

Деятельность, выполняемая в рамках блока имплементации, тестирования и развертывания, включает:

a)    планирование уровня строгости проведения валидации в разрабатываемом проекте.

b)    разработку и конфигурирование:

c)    сборку программного обеспечения:

d)    тестирование программного обеспечения с учетом идентифицированных рисков.

5.3.3.2    Анализ рисков отказа программного обеспечения

Ключевым моментом анализа риска отказа программного обеспечения являются определение и документирование свойственных рисков, связанных с отказом программного обеспечения, а также

идентификация любых мер по его управлению (включая элементы управления в отношении процесса и программного обеспечения вне анализируемого программного обеспечения). Затем этот анализ используется для нахождения практичного и результативного подхода к валидации.

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

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

5.3.3.3    Планирование валидации

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

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

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

5.3.3.4    Имплементация программного обеспечения (проектирование и разработка, сборка и тестирование)

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

а — включает меры по управлению риском, гахис как проверка хода, таймер обеспечения безопасности и t. д, Тахже включает направление для областей тестирования и тип тестов, которые будут использоваться Рисунок 4 — Стадия жизненного цикла программного обеспечения в системе менеджмента качества: последовательность деятельности по имплементации, тестированию и развертыванию программного обеспечения

5.3.3.5    Отчет по валидации

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

5.3.3.6    Выпуск программного обеспечения

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

5.4 Стадия обслуживания

5.4.1    Переход в стадию обслуживания

Критерий входа в стадию, стадия технического обслуживания (поддержания) начинается после выпуска программного обеспечения для применения.

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

Изменения в любой валидированной системе должны находиться под управлением в соответствии с применяемыми изготовителем политиками и процедурами.

В идеальной ситуации рекомендуется валидировать вносимые изменения в тестовой среде до перезапуска производственной эксплуатации системы. Если валидация изменений в тестовой среде невозможна и тестирование изменений должно проводиться в производственной среде, то с целью минимизации нежелательного воздействия на производственную среду или на продукцию должны быть Предусмотрены соответствующие средства управления.

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

На практике, несмотря на усилия по управлению изменениями, фактически используемое программное обеспечение или его конфигурация со временем подвергаются изменениям, в связи с чем может быть целесообразным использование специфичных для данной стадии инструментов поддержки (например, периодического мониторинга фактического применения или мониторинга конфигурации программного обеспечения в режиме реального времени). Если результатом изменения в предусмотренном применении становится более высокий уровень риска, то такое изменение может потребовать более обширного набора действий по валидации, чем было выполнено первоначально (даже при отсутствии изменений в самом программном обеспечении).

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

5.4.2    Планирование обслуживания

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

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

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

Анализ прослеживаемости является полезным инструментом в отношении менеджмента деятельности по обслуживанию. Анализ прослеживаемости часто является фундаментом первоначальной валидации и часто осуществляется с помощью матрицы прослеживаемости. Такая матрица устанавливает связь между требованиями к проведению тестирования или другой деятельности по верификации с мерами по управлению риском и т. д. При разработке матрицы прослеживаемости во время первоначальной имплементации программного обеспечения анализ прослеживаемости становится ценным инструментом при

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

5.4.3    Типы обслуживания, проводимые в рамках стадии

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

-    корректирующие изменения при обслуживании для исправления ошибок и отказов в программном обеспечении;

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

-    адаптивное сопровождение для обновления операционной среды программного обеспечения (например, изменения операционной системы, системного оборудования или приложений, с которыми данное программное обеспечение взаимодействует).

5.4.4    Изменения процесса: пореход к мерам по управлению риском

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

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

Изменение процесса может повлиять на меры по управлению риском, применяемые к программному обеспечению, которые являлись частью обоснования решения о проведении валидации. Поскольку программное обеспечение является составной частью процесса, предпринимаемое последующее управляющее воздействие может быть важной мерой по управлению риском в отношении программного обеспечения. Анализ влияния предполагаемого изменения процесса упростится, если все предпринимаемые последующие действия по управлению риском правильно идентифицированы как часть обоснования валидации программного обеспечения и как часть определения (идентификации) процесса. Анализ влияния изменений важен для правильного проведения обслуживания с целью укрепления доверия как к процессу, так и к программному обеспечению.

5.4.5    Экстренные изменения

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

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

Для проведения полного оценивания всех последствий экстренных изменений могут потребоваться дополнительные действия. В зависимости от совокупного риска, вызванного отказом процесса, его результаты (данные или продукция) могут нуждаться в дополнительном управлении до тех пор. пока не будут завершены все дополнительные действия после экстренных изменений.

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

Содержание

1    Область применения..................................................................1

2    Нормативные ссылки..................................................................1

3    Термины и определения................................... 1

4    Общие аспекты и подход к валидации программного обеспечения............................1

4.1    Определение термина «валидация программного обеспечения»..........................1

4.2    Деятельность по обеспечению доверия к функционированию программного обеспечения:

инструменты из набора инструментов................................................2

4.3    Подход на основе критического мышления............................................2

5    Валидация программного обеспечения и подход на основе критического мышления.............2

5.1    Краткий обзор....................................................................2

5.2    Установление необходимости валидации программного обеспечения......................7

5.2.1    Идентификация процесса и применяемого программного обеспечения................7

5.2.2    Оценка применимости регулирующих требований..................................7

5.2.3    Процессы и программное обеспечение, не подпадающие

под регулирующие требования к медицинским изделиям............................8

5.3    Стадия разработки................................................................8

5.3.1    Планирование валидации......................................................8

5.3.2    Определение/Идентификация..................................................8

5.3.3    Имплементация, тестирование и развертывание..................................12

5.4    Стадия обслуживания................................................... 15

5.4.1    Переход в стадию обслуживания...............................................15

5.4.2    Планирование обслуживания..................................................15

5.4.3    Типы обслуживания, проводимые в рамках стадии................................16

5.4.4    Изменения процесса: переход к мерам по управлению риском......................16

5.4.5    Экстренные изменения.......................................................16

5.4.6    Поддержка предусмотренного применения......................................17

5.5    Стадия вывода из эксплуатации....................................................17

6    Документация.......................................................................18

7    Обязательные процессы..............................................................19

Приложение А (справочное) Набор инструментов...........................................20

Приложение В (справочное) Менеджмент риска и риск-ориентированный подход................26

Приложение С (справочное) Примеры........................................ 29

Библиография........................................................................74

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

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

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

5.4.6 Поддержка предусмотренного применения

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

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

При инициализации изменений в валидированном программном обеспечении должно анализироваться его предусмотренное применение с целью обеспечения того, что оно все еще согласуется с фактическим использованием программного обеспечения.

5.5 Стадия вывода из эксплуатации

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

Деятельность по выводу программного обеспечения из эксплуатации в значительной степени зависит от типа программного обеспечения, подлежащего выводу. Некоторые из них могут просто выполнять какие-либо действия и не сохранять никаких данных. Другое программное обеспечение может быть гораздо более сложным (например, система прослеживаемости или управления документами, в которых хранятся объемы данных, связанных с продукцией и с ее соответствием требованиям). В случае сохраняющего данные программного обеспечения следует составить план обработки данных. Некоторые вопросы для рассмотрения включают в себя следующее:

-    Есть ли программное обеспечение, которое замоняет устаревшее программное обеспечение?

-    Можно ли перенести имеющиеся данные в новое программное обеспечение?

-    Должны ли данные быть перенесены в специальный формат для долгосрочного хранения?

-    Каковы требования к хранению данных какого-либо типа?

-    Будут ли данные храниться на постоянных носителях?

-    Если да. каковы инструкции или процедуры хранения и могут ли быть получены целостные данные. содержащие все связанные требования к этим данным?

-    Какова процедура поддержания постоянных носителей и программного обеспечения, способного их читать?

-    Будет ли храниться аппаратное обеспечение для использования и восстановления выведенного из эксплуатации программного обеспечения?

Введение

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

Настоящий стандарт распространяется на программное обеспечение, используемое в системе менеджмента качества, на программное обеспечение, используемое при производстве и предоставлении услуг, а также на программное обеспечение, используемое для мониторинга и измерения требований. в соответствии с требованиями ИСО 13485:2016 (4.1.6. 7.5.6 и 7.6).

Настоящий стандарт является результатом усилий и консолидации опыта работников промышленности медицинских изделий, которые занимаются валидацией такого программного обеспечения и в рамках деятельности своих организаций создают подвергаемую аудиту соответствующую документацию. Настоящий стандарт был разработан с учетом определенных имеющихся вопросов и проблем, с которыми приходится сталкиваться при валидации процесса применения программного обеспечения, используемого в рамках систем качества медицинских изделий, среди которых следующие: Что должно быть сделано? Будет ли этого достаточно? Как проводить анализ рисков? После долгих обсуждений был сделан вывод, что для обеспечения уверенности в способности программного обеспечения функционировать в соответствии с его предусмотренным применением (назначением), в каждом конкретном случае должен определяться некий перечень деятельности (с применением подходящих инструментов из набора'совокупности инструментов). Этот перечень может варьироваться в зависимости от множества факторов, например от сложности программного обеспечения, от риска причинения вреда и происхождения (например, качество, стабильность) поставляемого вендор-поставщиком программного обеспечения. Цель настоящего стандарта заключается в оказании помощи заинтересованным сторонам, включая изготовителей, аудиторов и регулирующие органы, в понимании и применении требований по валидации применения программного обеспечения, установленных в ИСО 13485:2016 (4.1.6. 7.5.6 и 7.6).

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Изделия медицинские ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ Часть 2

Валидация программного обеспечения, используемого в системах качества медицинских изделий

Medical devices. Software. Part 2. Validation of software for medical device quality systems

Дата введения — 2021—08—01

1    Область применения

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

Настоящий стандарт применим:

-    к программному обеспечению, используемому в рамках системы менеджмента качества;

-    к программному обеспечению, используемому при производстве и предоставлении услуг,

-    к программному обеспечению, используемому для мониторинга и измерения требований.

Настоящий стандарт не применим;

-    к программному обеспечению, используемому в качестве компонента, части или принадлежности к медицинскому изделию:

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

2    Нормативные ссылки

Настоящий стандарт не содержит нормативных ссылок.

3    Термины и определения

В настоящем стандарте применены термины по ИСО 9000 и ИСО 13485.

ИСО и МЭК ведут терминологические базы для использования в стандартизации по следующим адресам:

-    IEC Electropedia: размещена по адресу: http://www.electropedia.org/:

-    онлайн-платформа ISO: размещена по адресу: http://www.iso.org/obp.

4    Общие аспекты и подход к валидации программного обеспечения

4.1 Определение термина «валидация программного обеспечения»

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

Издание официальное

том, что используемое программное обеспечение соответствует его предусмотренному применению, а также является надежным и заслуживающим доверия. Любая обозначенная деятельность (выбранные действия/мероприятия) должна обеспечивать соответствие программного обеспечения предъявляемым к нему требованиям и его предусмотренному применению.

4.2    Деятельность по обеспечению доверия к функционированию программного

обеспечения: инструменты из набора инструментов

Применение подходящих инструментов из набора инструментов (см. таблицы А.1—А.5) включает деятельность, выполняемую в течение жизненного цикла программного обеспечения в системе менеджмента качества, снижающую риск и обеспечивающую доверие к его функционированию.

4.3    Подход на основе критического мышления

Настоящий стандарт стимулирует применение подхода на основе метода критического мышления в целях идентификации деятельности, которую необходимо выполнить для адекватной валидации конкретного программного обеспечения. Применение метода критического мышления заключается в использовании процесса анализа и оценивания различных аспектов программного обеспечения, а также предполагаемой среды его применения с целью определения наиболее значимого набора деятельности по обеспечению доверия к программному обеспечению для их применения при валидации. Критическое мышление помогает избежать применения подхода, именуемого как «опе-size-fits-all» («всех под одну гребенку»), в котором принимается универсальное решение по валидации без тщательного оценивания свидетельств того, что валидируемый процесс действительно приводит к нужному результату. Использование критического мышления предполагает, что решения по валидации могут сильно различаться от одного программного обеспечения к другому, а также позволяет применять различные решения по валидации к одному и тому же программному обеспечению в аналогичной ситуации. Критическое мышление подвергает оценке предлагаемые решения по валидации с целью обеспечения их соответствия требованиям системы менеджмента качества и учитывает все ключевые заинтересованные стороны и их потребности. Критическое мышление также может быть использовано для пересмотра ранее принятого решения по проведению валидации в случае изменения характеристик и предусмотренного применения программного обеспечения или в случае появления новой подходящей информации.

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

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

5 Валидация программного обеспечения и подход на основе критического мышления

5.1 Краткий обзор

Для программного обеспечения, используемого в рамках систем менеджмента качества медицинских изделий, должны быть предусмотрены соответствующие средства управления, обеспечивающие правильную работу на протяжении всего жизненного цикла программного обеспечения в системе менеджмента качества. Применение критического мышления и реализация выбранных действий по укреплению доверия приводят к созданию и поддержанию валидированного состояния (статуса валидации) программного обеспечения. На рисунке 1 приведено концептуальное представление типовых видов деятельности и соответствующего управления, которые являются частью жизненного цикла программного обеспечения в системе менеджмента качества с момента принятия решения об автоматизации процесса и до тех пор, пока программное обеспечение не устареет или больше не будет использоваться в 2

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

С целью сбора информации и принятия решений на стадии разработки жизненного цикла программного обеспечения в системе менеджмента качества выполняются задачи по менеджменту риска и планированию валидации в следующих четырех областях:

-    уровень прилагаемых усилий, а также экспертиза документации и результатов работ и отчетных материалов:

-    объем содержания результатов работ и отчетных материалов:

-    выбор инструментов (из набора инструментов) и методов применения этих инструментов;

-    уровень трудозатрат и усилий при применении этих инструментов.

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

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

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

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

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

На рисунке 1 показана основная деятельность по управлению жизненным циклом программного обеспечения в системе менеджмента качества. Прочие последовательности действий, не отраженные на рисунке 1, включают менеджмент проекта, разработку процессов, управление вендор-поставщиками (если применимо), а также другую деятельность в зависимости от рассматриваемого программного обеспечения.

Рисунок 2 отображает деятельность по управлению жизненным циклом программного обеспечения в системе менеджмента качества с учетом критического мышления и в контексте последовательности действий, не включенных в рисунок 1. Подход на основе критического мышления представлен на рисунке 2 в колонке «Итеративный анализ риска», а также в последовательности действий по валидации. Важно иметь четкие и документированные определения последовательности таких действий в рамках бизнес-модели организации с целью обеспечения правильного менеджмента программного обеспечения как с точки зрения бизнеса, так и с точки зрения регулирования.