ГОСТ Р 58976-2020/ISO/TR 80002-2:2017. Национальный стандарт Российской Федерации. Изделия медицинские. Программное обеспечение. Часть 2. Валидация программного обеспечения, используемого в системах качества медицинских изделий
5.3 Стадия разработки
5.3.1 Планирование валидации
Первая часть деятельности по планированию валидации с применением критического мышления использует результаты анализа риска процесса (см. приложение B) с целью установления масштаба усилий, которые следует применять к созданию документации, а также для выбора инструментов из раздела "Набор инструментов" блока "Определение/Идентификация" (см. таблицы A.1 - A.5). Вторая часть использует результаты анализа риска программного обеспечения с целью выбора инструментов (из набора инструментов) для имплементации, тестирования и развертывания. После выполнения деятельности и установления валидированного состояния программного обеспечения свидетельства валидации документируются в отчете по валидации.
На данной стадии могут применяться различные модели разработки жизненного цикла программного обеспечения в системе менеджмента качества. Настоящий стандарт не рекомендует какую-либо модель, однако предполагает использование методологии управления разработкой. Такая методология будет основана на концепции определения требований (включая предусмотренное применение) перед имплементацией, тестированием и развертыванием, которые имеют основополагающее значение при установлении валидированного состояния программного обеспечения для его предусмотренного применения.
5.3.2 Определение/Идентификация
5.3.2.1 Требование блока "Определение/Идентификация"
Деятельность, выполняемая в рамках блока "Определение/Идентификация" (см. рисунок 1), включает определение/идентификацию процесса, определение предусмотренного применения программного обеспечения в этом процессе, а также планирование масштаба усилий по валидации на основе рисков, идентифицированных в рассматриваемом процессе. Рисунок 3 иллюстрирует эту часть стадии разработки в рамках выбранного примера Каскадной модели.
Рисунок 3 - Стадия жизненного цикла программного обеспечения
в системе менеджмента качества: последовательность действий
блока "Определение/Идентификация"
5.3.2.2 Требования к процессу
Первым шагом в применении средств управления жизненным циклом программного обеспечения в системе менеджмента качества является определение цели и функции всего процесса, особенно частей, управляемых программным обеспечением. Эту задачу лучше всего выполнять с привлечением соответствующих экспертов, включая все аспекты и связанную с ними деятельность независимо от того, все ли они будут управляться программным обеспечением. Преимущества такого подхода обосновываются следующим:
- могут быть четко определены регулирующие требования;
- может быть четко определено предусмотренное применение конкретного программного обеспечения в контексте процесса;
- элементы процесса и деятельность, которые не управляются конкретным программным обеспечением, могут быть четко идентифицированы и учтены в процедурах или другими способами;
- предшествующие программному обеспечению и последующие элементы процесса идентифицированы и могут учитываться при оценке рисков отказа программного обеспечения, а также при разработке мер по управлению риском отказа программного обеспечения.
Деятельность по определению процесса закладывает основу для решений, принимаемых на более поздних стадиях жизненного цикла программного обеспечения в системе менеджмента качества, и имеет важное значение для ориентации усилий на деятельность с добавленной стоимостью с учетом риск-ориентированного подхода.
5.3.2.3 Анализ риска отказа процесса
Связь программного обеспечения с итоговой безопасностью и результативностью медицинской продукции рассматривается в рамках процесса анализа риска. Следует также учитывать следующее:
- риск причинения вреда людям: это включает прямой вред пациентам и пользователям, а также косвенный вред, когда происходит отказ/сбой программного обеспечения, управляющего изготовлением или качеством изделия, что приводит к неисправности самого изделия и причинению вреда;
- регуляторный риск: риск несоблюдения регулирующих требований следует учитывать, если отказ программного обеспечения может привести к потере записей (например, корректирующих и предупреждающих действий, претензий, записей, относящихся к техническому файлу или файлу проектирования и разработки), требуемых регулирующими органами, или к отклонениям от процедур системы качества и производственных процедур;
- риск влияния на среду применения: риск для среды, как физической, так и виртуальной, в которой используется программное обеспечение.
В данную модель могут быть включены и другие типы рисков, однако область применения настоящего стандарта, как и рассматриваемые инструменты для снижения риска, их не учитывают. Настоящий стандарт фокусируется на определении рисков нарушения безопасности человека, регуляторных рисков и рисков воздействия на среду применения, связанных с отказом программного обеспечения в контексте отказа процесса.
Результаты анализа риска должны быть четко документированы, поскольку они являются важными факторами, влияющими на выбор инструментов из набора инструментов, а также на масштаб усилий, прилагаемых к деятельности по валидации.
5.3.2.4 Планирование валидации
Степень подтверждения и объем объективных свидетельств, необходимых для обеспечения последовательного выполнения требований к программному обеспечению, зависят от критической значимости программного обеспечения в рамках всего процесса. Таким образом, первое действие по планированию валидации, касающееся масштаба прилагаемых усилий и тщательности рассмотрения практических результатов, должно быть основано исключительно на выходных данных анализа риска отказа процесса.
Завершение первого действия по планированию валидации приводит к первой итерации документации по планированию валидации. Такое планирование включает как выбор "масштаба прилагаемых усилий" (т.е. решений), так и обоснование данного выбора (т.е. факторов принятия решений). Обоснование должно базироваться на риске причинения вреда в результате отказа процесса. План валидации должен предоставить объективные свидетельства применения подхода на основе критического мышления к процессу планирования валидации.
5.3.2.5 Предусмотренное применение программного обеспечения
5.3.2.5.1 Элементы предусмотренного применения
Предусмотренное применение программного обеспечения является основой для составления полной картины функциональности программного обеспечения и цели его использования в рамках процесса. В частности, предусмотренное применение программного обеспечения предназначено для описания и объяснения того, как программное обеспечение вписывается в общий процесс, который оно автоматизирует; что делает программное обеспечение; что можно ожидать от программного обеспечения; насколько можно полагаться на программное обеспечение для проектирования, производства и обслуживания медицинских изделий с точки зрения безопасности. Предусмотренное применение является ключевым инструментом в понимании того, какие потенциальные риски связаны с использованием программного обеспечения.
Предусмотренное применение программного обеспечения содержит три основных элемента:
- цель и назначение, которые связаны:
- с использованием программного обеспечения (например, кто, что, когда, почему, где и как);
- с соблюдением регулирующих требований при использовании программного обеспечения;
- с границами применения программного обеспечения в рамках процесса или с другим программным обеспечением и/или пользователями;
- требования к использованию программного обеспечения. Поскольку с увеличением сложности, как правило, возрастает риск, этот элемент предоставляет более подробную информацию относительно применения программного обеспечения (например, варианты использования, требования к пользователю);
- требования к программному обеспечению. По мере того как сложность и риск возрастают до такой степени, что разработчикам программного обеспечения необходимы четкие предписания, этот элемент предоставляет более конкретную и подробную информацию относительно ожиданий от программного обеспечения.
Предусмотренное применение программного обеспечения должно быть официально одобрено и находиться под управлением квалифицированного и опытного персонала в области регулирующих требований, требований системы качества, а также связанного с программным обеспечением процесса.
Поскольку валидация проводится для "предусмотренного применения", важно понимать, что полноценное проведение валидации невозможно без полноценного установления предусмотренного применения для программного обеспечения.
Далее приведены дополнительные сведения об элементах предусмотренного применения программного обеспечения.
5.3.2.5.2 Цель и назначение программного обеспечения
Описание цели и назначения программного обеспечения содержит информацию, охватывающую три аспекта: использование программного обеспечения, регуляторные аспекты использования и границы применения программного обеспечения.
a) Использование программного обеспечения
- При определении использования программного обеспечения необходимо учитывать следующие вопросы: "что?", "почему?", "как?", "кто?", "где?" и "когда?". Ответы помогают понять, как программное обеспечение используется для соответствия требованиям процесса. Как показано в таблице 1, такой механизм помогает выявить базовую информацию для определения предназначения программного обеспечения.
- Ответы, которые имеют значение для описания программного обеспечения, должны быть включены в документированное определение предполагаемого использования.
Таблица 1
Примеры вопросов и ответов
Вопрос | Ответ |
На решение какой проблемы направлено программное обеспечение? | Проблемы в эффективном и точном обобщении данных о дефектах продукта для анализа тенденций |
Почему программное обеспечение полезно? | Программное обеспечение позволяет обобщать и анализировать данные из различных мест по всему миру |
Как программное обеспечение решает проблему? | Программное обеспечение управляет процессом сбора данных и автоматически обобщает и анализирует информацию о тенденциях, или программное обеспечение не управляет процессом, но обеспечивает пассивный сбор данных, используемых для обобщения и анализа информации о тенденциях |
Кто использует программное обеспечение? | Отделы обеспечения качества и эксплуатации |
Где используется программное обеспечение? | Доступ к программному обеспечению осуществляется в США, Европе и Японии |
Когда используется программное обеспечение? | Доступ к программному обеспечению осуществляется в рабочее время по всему миру (т.е. ежедневно, с понедельника по пятницу) |
Примечание - Данные примеры вопросов не являются исчерпывающими. | |
b) Регуляторные аспекты использования программного обеспечения
- При оценке регуляторных аспектов использования можно дополнительно изучить ответы на вопросы, чтобы определить, входит ли программное обеспечение в область применения настоящего стандарта (см. 5.2). Следует более подробно объяснить все ответы "да" с целью определения причины таких выводов. Когда программное обеспечение определено как входящее в область применения настоящего стандарта, необходимо определить любой потенциальный вред для людей (не являющихся пользователями медицинского изделия) или для окружающей среды. Предложенные далее вопросы акцентируют внимание пользователя настоящего стандарта на элементы, которые являются частью регулирующих требований, таких как область здравоохранения, безопасность и действительность или подлинность электронных записей и подписей.
- Как отказ или скрытые недостатки программного обеспечения могут повлиять на безопасность или качество медицинских изделий?
- Как программное обеспечение автоматизирует или выполняет действия, установленные в регулирующих требованиях, в частности требованиях к системам менеджмента качества медицинских изделий?
- Как программное обеспечение может причинить вред людям (не являющимся пользователями медицинского изделия) или окружающей среде?
c) Границы применения программного обеспечения
- Определение частей процесса, которые должны управляться с помощью программного обеспечения (границы внутри процесса), и областей, где существуют программные интерфейсы (границы с другим программным обеспечением), способствует результативности и эффективности усилий по валидации. Например, часто бывает более эффективно валидировать несколько программных продуктов как группу, а не проводить их валидацию по отдельности. Также следует рассмотреть различные стратегии группирования, которые могут влиять на эффективность текущих действий в последующей стадии обслуживания.
- Границы программного обеспечения в процессе
- Идентификация границ программного обеспечения в рамках процесса
четко устанавливает аспекты, которые должны быть включены в
предусмотренное применение. Программное обеспечение может
автоматизировать только часть или весь процесс, а также может служить
хранилищем данных для процесса. Понимание роли, которую программное
обеспечение играет в этом процессе, помогает определить риски,
связанные с возможным отказом программного обеспечения.
- Границы с другим программным обеспечением
- При внешнем взаимодействии с другим программным обеспечением,
используемым в рамках систем качества медицинских изделий, или с
программным обеспечением медицинских изделий (включая случаи, когда
программное обеспечение само по себе является медицинским изделием)
важно идентифицировать все интерфейсы между приложениями. Хотя масштаб
усилий и трудозатраты по валидации обычно включают внутренние
интерфейсы как неотъемлемую часть используемого метода, внешние
интерфейсы программного обеспечения не должны игнорироваться. Все
интерфейсы между программными приложениями должны быть охвачены
процессом критического мышления.
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 Анализ рисков отказа программного обеспечения
Ключевым моментом анализа риска отказа программного обеспечения являются определение и документирование свойственных рисков, связанных с отказом программного обеспечения, а также идентификация любых мер по его управлению (включая элементы управления в отношении процесса и программного обеспечения вне анализируемого программного обеспечения). Затем этот анализ используется для нахождения практичного и результативного подхода к валидации.
При анализе рисков, связанных с отказом программного обеспечения, учитываются любые элементы управления процессом вне анализируемого программного обеспечения, которые представляют собой меры по управлению риском этого процесса. Эти меры по управлению риском процесса способствуют уменьшению критичности отказа, тем самым снижая зависимость от программного обеспечения, что, в свою очередь, снижает зависимость от тестирования (экспертизы) и документирования (сбора объективных свидетельств), проводимых в целях обеспечения безопасности функционирования программного обеспечения. Включение в анализ таких аспектов способствует обеспечению уверенности в том, что программное обеспечение рассматривается в рамках всего процесса в целом.
Модель, представленная в приложении B, не является всеобъемлющей формулой. Проведенный анализ предоставляет входные данные для выбора инструментов из набора инструментов, которые будут использоваться для валидации программного обеспечения.
5.3.3.3 Планирование валидации
Планирование валидации использует выходные данные деятельности по определению предусмотренного применения и анализа риска программного обеспечения в качестве входных данных для идентификации мер по управлению риском и выбора инструментов из набора инструментов, которые будут использоваться для валидации программного обеспечения.
Важно обеспечить участие в процессе выбора инструмента квалифицированных специалистов, понимающих влияние отказов программного обеспечение на автоматизируемый процесс, а также связанные с ними риски, хотя эти специалисты не обязательно должны быть экспертами в области программного обеспечения. В процесс планирования сложного программного обеспечения или программного обеспечения, имеющего высокий риск, связанный с его отказом, должны быть вовлечены специалисты из разных областей (например, по вопросам регулирования, качества, клинических аспектов и т.п.).
Результатом планирования валидации является документированный план, в котором описываются принятые решения и причины их принятия. Планирование валидации предоставляет документированные свидетельства, обосновывающие выбор уместных дополнительных мероприятий по укреплению доверия к программному обеспечению и его функционированию, как предусмотрено.
5.3.3.4 Имплементация программного обеспечения (проектирование и разработка, сборка и тестирование)
Этот блок диаграммы включает применение многих инструментов из набора инструментов. Инструментарий (необходимая деятельность или действия, установленные в плане валидации) осуществляется на этапах проектирования, разработки, сборки и тестирования (см. рисунок 4).
a - включает меры по управлению риском, такие как проверка
кода, таймер обеспечения безопасности и т.д. Также включает
направление для областей тестирования и тип тестов, которые
будут использоваться
Рисунок 4 - Стадия жизненного цикла программного обеспечения
в системе менеджмента качества: последовательность
деятельности по имплементации, тестированию
и развертыванию программного обеспечения
5.3.3.5 Отчет по валидации
Вся деятельность, а в некоторых случаях и результаты этой деятельности должны быть указаны в окончательном отчете по валидации, когда завершены необходимые мероприятия в отношении укрепления доверия, включая выбор инструментов из набора инструментов, для обеспечения надлежащего функционирования программного обеспечения. Официальные анализ и одобрение отчета представляют собой краткое описание ссылок на все документированные объективные свидетельства, подтверждающие сделанный вывод о том, что программное обеспечение было валидировано на предмет его предусмотренного применения.
5.3.3.6 Выпуск программного обеспечения
По завершении валидации должен быть реализован официально установленный метод выпуска программного обеспечения. Установленный способ управления выпуском программного обеспечения должен обеспечивать и подтверждать, что введенное в эксплуатацию программное обеспечение соответствует тому, которое оценивалось в ходе деятельности по достижению доверия к программному обеспечению, что указывается в отчете по валидации. В противном случае обоснования и используемые средства управления выпуском должны обеспечивать и подтверждать тот факт, что выпущенное программное обеспечение является в достаточной степени работоспособным в предназначенной среде применения.
Подписаться на обновления