ГОСТ Р 58976-2020/ISO/TR 80002-2:2017. Национальный стандарт Российской Федерации. Изделия медицинские. Программное обеспечение. Часть 2. Валидация программного обеспечения, используемого в системах качества медицинских изделий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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