"ПНСТ 777-2022. Предварительный национальный стандарт Российской Федерации. Системы искусственного интеллекта в клинической медицине. Часть 10. Процессы жизненного цикла"
(утв. и введен в действие Приказом Росстандарта от 08.11.2022 N 91-пнст)

1 РАЗРАБОТАН Государственным бюджетным учреждением здравоохранения города Москвы "Научно-практический клинический центр диагностики и телемедицинских технологий Департамента здравоохранения города Москвы" (ГБУЗ "НПКЦ ДиТ ДЗМ")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 164 "Искусственный интеллект"

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

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

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

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

Настоящий стандарт позволяет дополнить представленный в ГОСТ IEC 62304 набор процессов жизненного цикла программного обеспечения медицинских изделий процессом мониторинга системы искусственного интеллекта на этапе эксплуатации, а также этапами эксплуатации и вывода из эксплуатации.

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

В настоящем стандарте также приведено соотнесение установленных требований с требованиями к стадиям и этапам создания автоматизированных систем, приведенных в ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания".

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

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

Для целей настоящего стандарта:

- "должен" означает необходимость полного соответствия требованиям стандарта;

- "следует" - соответствие требованиям рекомендуется, но не является обязательным;

- "установить" - определять, документировать и осуществлять выполнение;

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

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

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

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

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов

ГОСТ 34.201 Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем

ГОСТ 34.601 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания

ГОСТ ISO 13485 Изделия медицинские. Системы менеджмента качества. Требования для целей регулирования

ГОСТ ISO 14971 Изделия медицинские. Применение менеджмента риска к медицинским изделиям

ГОСТ ISO/IEC 17025 Общие требования к компетентности испытательных и калибровочных лабораторий

ГОСТ IEC 62304 Изделия медицинские. Программное обеспечение. Процессы жизненного цикла

ГОСТ ИСО/МЭК 9126 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению

ГОСТ Р 53624 Информационные технологии. Информационно-вычислительные системы. Программное обеспечение. Системы менеджмента качества. Требования

ГОСТ Р 56044 Оценка медицинских технологий. Общие положения

ГОСТ Р 59921.1 Системы искусственного интеллекта в клинической медицине. Часть 1. Клиническая оценка

ГОСТ Р 59921.2 Системы искусственного интеллекта в клинической медицине. Часть 2. Программа и методика технических испытаний

ГОСТ Р 59921.3 Системы искусственного интеллекта в клинической медицине. Часть 3. Управление изменениями в системах искусственного интеллекта с непрерывным обучением

ГОСТ Р ИСО 9001 Системы менеджмента качества. Требования

ГОСТ Р МЭК 60601-1-6-2014 Изделия медицинские электрические. Часть 1-6. Общие требования безопасности с учетом основных функциональных характеристик. Дополнительный стандарт. Эксплуатационная пригодность

ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

ГОСТ Р 55544/IEC/TR 80002-1:2009 Программное обеспечение медицинских изделий. Часть 1. Руководство по применению ИСО 14971 к программному обеспечению медицинских изделий

ГОСТ Р 56839/IEC/TR 80001-2-1:2012 Информатизация здоровья. Менеджмент рисков в информационно-вычислительных сетях с медицинскими приборами. Часть 2-1. Пошаговый менеджмент рисков медицинских информационно-вычислительных сетей. Практическое применение и примеры

ГОСТ Р ИСО/МЭК 90003 Разработка программных продуктов. Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов

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

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1

3.2 аналитическая валидация (analytical validation): Подтверждение способности системы искусственного интеллекта точно, воспроизводимо и надежно генерировать предполагаемые технические результаты вычислений из входных данных.

Примечания

1 См. [1].

2 Аналитическая валидация является частным случаем валидации в соответствии с ГОСТ Р ИСО/МЭК 12207-2010 (пункт 4.54).

3.3

3.4 архитектура системы искусственного интеллекта (architecture of the artificial intelligence): Концептуальная структура системы искусственного интеллекта, определяющая порядок обработки информации и включающая методы преобразования информации и принципы взаимодействия элементов (программных блоков, систем) системы искусственного интеллекта.

3.5

Примечания

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

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

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

3.6

3.7

3.8

3.9

3.10

3.11

Примечания

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

2 Определение маркировки см. в ГОСТ ISO 13485-2017, определение 3.8.

3.12

3.13 клиническая валидация (clinical validation): Подтверждение способности системы искусственного интеллекта выдавать клинически значимые выходные данные, связанные с целевым использованием системы искусственного интеллекта в рамках установленного изготовителем функционального назначения.

Примечание - См. [1, пункт 7.0].

3.14

3.15

3.16 модель жизненного цикла системы искусственного интеллекта (life cycle model of an artificial intelligence system): Концептуальная структура, охватывающая существование системы искусственного интеллекта от определения требований к ней до вывода из эксплуатации, которая:

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

- описывает последовательность и взаимозависимость между деятельностью и задачами;

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

3.17

3.18 непреднамеренные последствия (unintended consequence): Нежелательный и негативный исход события, приводящий к ухудшению одной или более характеристик системы.

3.19

3.20

3.21

3.22

3.23

3.24

3.25

3.26

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

3.28

3.29

3.30 система искусственного интеллекта (artificial intelligence system): Программное обеспечение, в котором используются технологические решения искусственного интеллекта.

3.31 система менеджмента качества системы искусственного интеллекта (quality management system for artificial intelligence system): Организационная структура, функции, процедуры, процессы и ресурсы, необходимые для скоординированной деятельности по руководству и управлению производителем системы искусственного интеллекта применительно к качеству.

3.32 управление жизненным циклом (системы искусственного интеллекта) (lifecycle management of artificial intelligence system): Совокупность процессов жизненного цикла, включающих развитие системы, продукции, услуги, проекта или другой создаваемой изготовителем сущности от замысла до списания для использования изготовителем.

3.33

3.34

3.35

В настоящем стандарте применены следующие сокращения:

ЖЦ - жизненный цикл;

ПКТИ - предварительные клинико-технические испытания;

СИИ - система искусственного интеллекта.

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

Модель ЖЦ СИИ может включать следующие процессы:

- разработку плана разработки СИИ (в том числе описание применяемых наборов данных);

- анализ и разработку требований к СИИ;

- проектирование архитектуры СИИ на основании требований к СИИ;

- разработку СИИ;

- реализацию и верификацию программных блоков СИИ;

- программную интеграцию и испытания в отношении интеграции;

- испытания СИИ;

- ввод в эксплуатацию СИИ;

- эксплуатацию СИИ;

- вывод из эксплуатации СИИ.

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

Примечания

1 Демонстрация этой способности может быть осуществлена с помощью системы менеджмента качества, соответствующей следующим требованиям:

- национальному стандарту на систему менеджмента качества для медицинских изделий;

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

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

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

2 Руководство, как применить требования менеджмента качества к программному обеспечению, можно найти в ГОСТ Р ИСО 9001, ГОСТ ISO 13485, ГОСТ Р 53624, ГОСТ Р ИСО/МЭК 90003.

Изготовитель СИИ должен применять процесс менеджмента риска в соответствии с ГОСТ ISO 14971, ГОСТ Р 56839, ГОСТ Р 55544 (см. также [2], [3]). Данный процесс должен быть интегрирован на протяжении всего ЖЦ СИИ, основываться на риск-ориентированном подходе к безопасности пациентов. Деятельность по менеджменту риска, применяемого к ЖЦ СИИ, носит итеративный характер. Выполняют анализ и переоценивание риска в процессе планирования и разработки СИИ.

Изготовитель СИИ должен установить план (или планы) разработки СИИ с целью проведения всей необходимой деятельности в отношении процесса разработки СИИ, соответствующей области, важности и классу безопасности. Модель ЖЦ разработки СИИ должна либо быть полностью определена, либо ссылаться на план (или планы) [4].

План должен содержать:

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

- процессы, которые будут использованы при разработке СИИ и отражены в Техническом задании на создание СИИ (см. примечание 4);

- поставляемые результаты (включая документацию) деятельности и задач на каждом этапе создания СИИ, которые должны быть указаны в Техническом задании на создание СИИ;

- прослеживаемость между требованиями системы, требованиями СИИ, испытанием программной системы и мерами управления риском, включенными в СИИ, которую необходимо определять на каждом этапе создания СИИ (соответствие получаемых результатов Техническому заданию на создание СИИ);

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

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

Примечания

1 Модель ЖЦ разработки СИИ может определять различные элементы (процессы, деятельность, задачи и результаты) для различных программных элементов, в соответствии с классами безопасности СИИ для каждого программного элемента программной системы.

2 Деятельность и задачи могут перекрываться или взаимодействовать и выполняться итеративно или рекурсивно. Это не подразумевает того, что должна использоваться определенная модель ЖЦ.

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

4 План разработки СИИ может ссылаться на существующие процессы или определять новые.

5 План разработки СИИ может быть включен в план разработки общей системы (см. 6.1.3).

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

На каждом этапе создания СИИ может быть определен дальнейший порядок разработки с учетом полученных результатов.

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

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

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

В план разработки СИИ изготовитель должен включить обоснование или дать ссылки для применения:

- на стандарты;

- методы, в том числе математические;

- на описание наборов данных и методов их формирования;

- на метрики качества СИИ, являющиеся аналогами к разрабатываемой СИИ;

- инструменты, связанные с разработкой программных составных частей.

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

Программная интеграция является частью процесса реализации СИИ.

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

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

- о поставляемых результатах, требующих верификации;

- требуемых верификационных задачах для каждой деятельности в ЖЦ;

- контрольных точках, на которых верифицируются поставляемые результаты;

- критериях приемки для верификации поставляемых результатов;

- наборе показателей качества и допустимых отклонениях, применимых к СИИ.

При планировании верификации СИИ изготовитель должен заложить требования к наборам данных, необходимым для верификации СИИ на разных этапах ЖЦ (если применимо).

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

В план разработки СИИ изготовитель должен включить или дать ссылки на информацию о документации, которая будет создана во время ЖЦ разработки СИИ. Каждому идентифицированному документу или типу документа должна быть присвоена (или содержаться непосредственно) следующая информация:

- титульный лист, наименование или обозначение;

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

- цель;

- предусмотренные пользователи документа;

- содержание документа (в виде разделов);

- процедуры и ответственность за разработку, анализ, одобрение и модификацию документов и/или документации.

Документация может быть оформлена в соответствии с требованиями ГОСТ 34.201. Перечень документов выбирает изготовитель исходя из специфики разрабатываемой СИИ.

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

- на классы, типы, категории или списки элементов, подлежащих управлению;

- деятельность и задачи по менеджменту конфигурации СИИ;

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

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

- случаи, когда элементы должны находиться под управлением конфигурации;

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

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

Примечания

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

2 См. раздел 9.

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

Изготовитель должен включить или указать в плане разработки СИИ процедуру:

а) для определения категорий дефектов, которые могут быть введены на основе выбранной технологии программирования и имеют отношение к их программной системе;

б) документирование свидетельств, демонстрирующих неспособность этих дефектов приводить к недопустимому риску.

Примечание - Примеры категорий дефектов или причин, способствующих возникновению опасных ситуаций (см. [5]).

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

Примечание - Может не существовать различий между требованиями СИИ и требованиями системы, если СИИ является отдельной системой (например, если СИИ само по себе является изделием).

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

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

Примечание - Примеры включают в себя:

- эксплуатационные характеристики (например: цели СИИ, координация требований);

- физические характеристики (например: язык машинного кода, платформа, операционная система);

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

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

- показатели эффективности (чувствительность, специфичность и др.);

б) входные и выходные данные программной системы.

Примечание - Например:

- характеристики данных (например: цифровые, буквенно-цифровые, формат);

- диапазоны;

- пределы;

- значения по умолчанию;

в) средства взаимодействия между программной системой и другими системами;

г) программные средства управления для предупреждения и оповещения пользователя СИИ;

д) требования к защищенности.

Примечание - Например:

- требования с компромиссом относительно конфиденциальности информации;

- идентификация;

- авторизация;

- системный журнал;

- непрерывность связи;

- система безопасности/защита от взлома;

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

Примечания

1 Примеры в этой области связаны:

- с поддержкой операций, выполняемых вручную;

- взаимодействием между человеком и оборудованием;

- ограничениями в отношении пользователя;

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

2 Для информации относительно требований к разработке удобства и простоты использования (эксплуатационной пригодности) см. ГОСТ Р МЭК 60601-1-6;

ж) определение данных и требований к базе данных.

Примечание - Например:

- форма;

- размерность;

- функция;

и) установление и принятие требований к поставляемому СИИ для работ и технической поддержки веб-версии программного продукта;

к) требования, относящиеся к методам разработки и технической поддержки;

л) требования, связанные с аспектами информационных сетей.

Примечание - Примеры включают в себя аспекты, которые связаны:

- с сетевыми сигналами тревоги, предупреждения и сообщения оператора;

- сетевыми протоколами;

- обработкой недоступности сетевых услуг;

м) требования к поддержке пользователей;

н) регулирующие требования.

Примечания

1 Требования с а) до н) могут пересекаться.

2 Все эти требования могут быть не установленными на момент начала разработки.

3 ГОСТ ИСО/МЭК 9126 обеспечивает информацию о качественных характеристиках, которая может быть полезна при определении требований к СИИ.

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

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

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

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

Изготовитель должен верифицировать и документировать, что требования к СИИ:

а) выполняют требования к системе (если применимо), в том числе относящиеся к управлению риском;

б) не противоречат друг другу;

в) выражены в терминах, которые не допускают двусмысленности;

г) сформулированы в терминах, которые позволяют установить критерии тестирования и осуществить тестирование;

д) могут быть идентифицированы уникальным образом;

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

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

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

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

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

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

Изготовитель должен верифицировать и документировать, что:

а) архитектура СИИ реализует требования к системе, если применимо, и СИИ, включая требования, относящиеся к управлению риском;

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

Примечание - Для выполнения требования а) может быть использован анализ прослеживаемости архитектуры к требованиям по СИИ.

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

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

Разработку программной документации выполняют в соответствии с ГОСТ 19.101.

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

Изготовитель должен верифицировать и документировать, что детальный проект СИИ:

а) реализует архитектуру СИИ;

б) не вступает в противоречия с архитектурой СИИ.

Примечание - Для выполнения требования а) может быть использован анализ прослеживаемости архитектуры к детальному проекту СИИ.

Ключевыми особенностями этапа разработки СИИ будут являться:

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

- обучение моделей искусственного интеллекта с применением сформированного набора данных;

- клиническая оценка СИИ.

Ключевым отличием процесса разработки СИИ от традиционного программного обеспечения является применение наборов данных на всех этапах ЖЦ.

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

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

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

Изготовитель должен реализовать каждый программный блок.

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

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

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

Примечание - Примеры критериев приемки:

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

- нет ли в программном коде противоречий с проектом интерфейса программных блоков?

- соответствует ли программный код процедурам программирования или стандартам кодирования?

Если детальный проект СИИ разработан, изготовителю следует включить в проект дополнительные критерии приемки, предназначенные для:

- правильной (соответствующей) последовательности событий;

- потока данных и управления;

- планируемого распределения ресурсов;

- работы с ошибками (определение ошибки, локализация и восстановление);

- инициализации переменных;

- самодиагностики;

- управления памятью и переполнений памяти;

- граничных условий.

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

Изготовитель должен интегрировать программные блоки согласно плану интеграции (см. 6.1.5).

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

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

Изготовитель должен тестировать интегрированные программные составные части в соответствии с планом интеграции (см. 6.1.5) и документировать полученные результаты.

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

Примечания

1 Примерами могут служить:

- требуемая функциональность СИИ;

- выполнение мер по управлению риском;

- определенная синхронизация и другие режимы работы;

- определенное функционирование внутренних и внешних интерфейсов;

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

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

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

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

Изготовитель должен:

а) документировать результаты тестирования (соответствует, не соответствует и перечень аномалий);

б) сохранить существенные записи для возможного проведения повторного тестирования;

в) указать лицо, проводившее тестирование.

Примечание - Требование б) может быть выполнено путем сохранения, например:

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

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

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

Изготовитель должен вводить аномалии, обнаруженные во время интеграции СИИ и тестирования интеграции, в процесс решения проблем СИИ.

Примечание - См. раздел 10.

Тестирования (испытания) СИИ подразделяют на внутренние, проводимые изготовителем СИИ в соответствии с 6.7.2 и 6.7.3, и внешние испытания, проводимые в случае отнесения СИИ к медицинскому изделию, в рамках технических и клинических испытаний (процедура технических испытаний описана в ГОСТ Р 59921.2, процедура клинических испытаний описана в ГОСТ Р 59921.1.

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

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

Примечания

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

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

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

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

Для проведения ПКТИ СИИ изготовитель должен установить перечень проверяемых параметров, разработать программу испытаний и критерии прохождения [6].

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

По результатам оформляют отчет в соответствии с приложением В.

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

При внесении изменений в ходе тестирования СИИ изготовитель обязан:

- повторить тестирование, выполнить модифицированные или дополнительные тесты, если применимо, с целью проверки результативности вносимых изменений для исправления проблем;

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

- выполнить соответствующую деятельность по менеджменту рисков (см. 8.4).

В случае регистрации СИИ в качестве медицинского изделия выполняют испытания СИИ в соответствии с действующими нормативно-правовыми актами.

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

Изготовитель должен проверить:

- что все требования к системе искусственного интеллекта были протестированы или иным образом верифицированы;

- ведутся записи по прослеживаемости между требованиями к СИИ и тестами или другой верификацией;

- результаты тестирования соответствуют требуемым критериям приемки.

Для обеспечения повторяемости тестов изготовитель должен:

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

б) сохранить отчеты;

в) идентифицировать лицо, проводившее тестирование;

г) руководствоваться действующими нормативными правовыми актами, применимыми к проведению испытаний СИИ изготовителем.

Примечания

1 Требование б) может быть выполнено путем сохранения, например:

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

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

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

2 Содержание отчета по результатам испытаний должно соответствовать требованиям ГОСТ ISO/IEC 17025.

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

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

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

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

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

Изготовитель должен документировать процедуру и окружение (среду), которые использовались при создании выпущенной СИИ.

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

Изготовитель должен хранить в архиве в течение установленного нормативными правовыми актами срока следующее:

- СИИ и составные части конфигурации;

- документацию.

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

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

- создание копии;

- средства маркировки;

- упаковку;

- защиту;

- хранение;

- поставку.

На этапе "Эксплуатация системы искусственного интеллекта" осуществляют работы:

а) по анализу функционирования СИИ;

б) выявлению отклонений фактических эксплуатационных характеристик СИИ от проектных значений;

в) установлению причин этих отклонений;

г) устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик СИИ;

д) внесению необходимых изменений в документацию на СИИ.

Оценку технологии искусственного интеллекта в качестве технологии здравоохранения (медицинской технологии) проводят в соответствии с ГОСТ Р 56044.

Данную процедуру могут выполнять все участники процесса ЖЦ СИИ, в том числе лица, принимающие решения - изготовители, инвесторы, плательщики, медицинские организации и профильные органы исполнительной власти.

Цель процесса вывода из эксплуатации СИИ состоит в обеспечении завершения существования программного продукта в соответствии с ГОСТ Р ИСО/МЭК 12207.

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

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

В результате успешного осуществления процесса вывода из эксплуатации СИИ:

- определяется стратегия вывода из эксплуатации;

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

- системные программные элементы уничтожаются или сохраняются;

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

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

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

- планирование вывода из эксплуатации СИИ;

- выполнение вывода из эксплуатации СИИ.

Изготовитель должен установить план (или планы) технической поддержки СИИ для выполнения деятельности и задач процесса технической поддержки. Этот план должен содержать:

а) процедуры:

- для получения (установки);

- документирования;

- оценивания;

- принятия решения (исправления);

- отслеживания;

- получения обратной связи, возникающей (устанавливаемой) после ввода в эксплуатацию СИИ;

б) критерии для определения проблем с обратной связью;

в) использование процесса менеджмента риска СИИ;

г) использование процесса решения проблем СИИ для анализа и принятия решений по проблемам, возникающим при эксплуатации СИИ;

д) использование процесса менеджмента конфигурации СИИ для управления модификациями существующей программной системой (см. раздел 9);

е) процедуры по оцениванию и осуществлению:

- обновления;

- нахождения ошибок;

- исправлений, вносимых в коды ("заплатки", "патчи");

- признания СИИ устаревшей.

План технической поддержки СИИ должен содержать уровень предоставления услуг технической поддержки.

7.2.1.1 Мониторинг обратной связи

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

7.2.1.2 Документирование и оценивание обратной связи

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

7.2.1.3 Оценивание влияния отчетов о проблемах на безопасность

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

Изготовитель должен использовать процесс решения проблем СИИ (см. раздел 10) в отношении отчетов о проблемах.

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

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

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

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

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

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

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

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

а) о любых проблемах в отношении выпущенных версий СИИ и последствиях длительного использования неизмененной СИИ;

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

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

Примечание - Требования для изменений СИИ, относящиеся к менеджменту риска, - см. 8.4.

Изготовитель должен выпускать модификации СИИ согласно 6.8.

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

Изготовитель должен идентифицировать программные составные части, которые могут способствовать возникновению опасных ситуаций, идентифицированных при осуществлении деятельности по анализу риска медицинского изделия, которая должна проводиться согласно ГОСТ ISO 14971 в соответствии (см. 4.2). Схема процесса анализа риска приведена в приложении Г, составленном на основании [2].

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

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

Изготовитель должен рассматривать потенциальные причины, включая, если применимо:

- неверную или неполную спецификацию функциональности;

- дефекты СИИ, идентифицированные в определенных функциях программной составной части;

- отказы аппаратных средств или другие дефекты СИИ, которые могут привести к непредсказуемым операциям СИИ;

- обосновано прогнозируемое неправильное применение.

8.1.2.2 Примеры опасностей, применимых к СИИ (см. [2]).

а) данные:

- доступ;

- доступность;

- конфиденциальность;

- преобразование (transfer);

- интеграция;

б) передача данных:

- количество;

- скорость;

в) диагностическая информация:

- результаты исследования;

- артефакты, дефекты данных;

- характеристики данных (например, ориентация изображений, разрешение, временной интервал);

г) функциональность:

- идентификация опасности;

- критическая производительность;

- измерения.

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

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

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

Примечание - Например:

- опасность (потенциальная причина опасной ситуации): измерения (некорректная информация);

- последовательность событий: 1) ошибка измерения, 2) пропуск со стороны пользователя;

- опасная ситуация: некорректная информация передается врачу и приводит к возможности недостоверной диагностики или недостатку терапии;

- вред: прогрессирование заболевания.

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

Провести оценку риска с учетом заданных критериев допустимости риска (таблица 1).

В отношении каждой ситуации, зарегистрированной в файле менеджмента риска, которая может содействовать возникновению опасных ситуаций, изготовитель должен определить и документировать меры по управлению риском в соответствии с ГОСТ ISO 14971.

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

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

- включить меры по управлению риском в требования к СИИ;

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

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

Примечание - Это требование обеспечивает дополнительное уточнение требований по управлению риском в ISO 14971.

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

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

Изготовитель должен документировать прослеживаемость в отношении опасностей СИИ соответствующим образом. Например, если применимо:

- от опасной ситуации до программной составной части;

- от программной составной части до конкретной причины в СИИ;

- от причины в СИИ до мер по управлению риском;

- от мер по управлению риском до верификации мер по управлению риском.

Примечание - См. ГОСТ ISO 14971 отчет по менеджменту риска.

Изготовитель обязан анализировать изменения в СИИ с целью определения:

- существования не выявленных ранее причин, способствующих возникновению опасной ситуации;

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

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

Изготовитель должен осуществить деятельность по менеджменту риска, которая определена в 8.1 - 8.3, основанную на результатах проведенных анализов.

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

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

Изменения СИИ могут производить в следующих аспектах:

а) Изменения алгоритма, которые ведут за собой изменения и безопасности СИИ.

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

Примечание - Например:

- изменение времени обработки исследований (оптимизация быстродействия);

- добавление нового функционала;

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

б) Изменения, связанные с входными данными СИИ, без изменений в функциональном назначении СИИ.

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

Примечание - Например:

- изменение в СИИ для возможности обработки входных данных с аппаратов изготовителей, которые ранее не были указаны в спецификации изготовителя;

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

в) Изменения в функциональном назначении СИИ.

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

Примечание - Например:

- включение в предназначении Сервиса новой группы пациентов для исследований;

- добавление информации поиска дополнительных патологических находок в рамках одной модальности;

- добавление новых модальностей, например, СИИ, обрабатывающей КТ-изображения, изменили для анализа РГ-изображений.

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

9.2.1.1 Для определения структуры изменений СИИ изготовитель разрабатывает план управления изменениями СИИ, который включают в техническую и эксплуатационную документацию на СИИ [8].

9.2.1.2 План управления изменениями содержит:

а) описание предполагаемых изменений СИИ;

б) протокол управления изменениями алгоритма.

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

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

9.2.1.5 Обзор компонентов протокола управления изменениями СИИ представлен в таблице 2, где описана процедура изменения СИИ, при которой она остается безопасной и эффективной. В случае применения в СИИ алгоритмов непрерывного обучения необходимо следовать требованиям ГОСТ Р 59921.3.

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

Примечания

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

2 В отношении запросов на изменения на разных стадиях ЖЦ могут быть использованы различные процессы одобрения, как это установлено в планах (см. 6.1.1 и 7.1).

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

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

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

Примечание - Этот подпункт требует только того, чтобы изменения были верифицированы. Он не подразумевает того, что верификация - неотъемлемая часть процесса управления изменениями. Верификация должна использовать запланированные процессы (см. 6.1.1 и 7.1).

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

а) методику испытаний;

б) результаты испытаний;

в) обнаруженные аномалии;

г) версию испытуемой СИИ;

д) соответствующие аппаратные и программные испытуемые конфигурации;

е) вспомогательное оборудование;

ж) данные по результатам испытаний;

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

Изготовитель должен поддерживать записи о взаимосвязях и зависимостях между:

- запросами на изменение,

- соответствующими отчетами о проблемах,

- одобрениями запроса на изменение.

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

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

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

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

Изготовитель должен:

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

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

- документировать результаты исследования и оценки;

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

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

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

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

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

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

Если применимо, изготовитель должен на регулярной основе обновлять файл менеджмента риска (см. 8.4).

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

Изготовитель должен верифицировать решения с целью определения:

- была ли проблема решена и был ли завершен отчет о проблеме;

- были ли преодолены неблагоприятные тенденции;

- был ли запрос на изменения реализован в соответствующей СИИ и деятельности;

- появились ли дополнительные проблемы.

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

- результаты тестирования;

- обнаруженные аномалии;

- версию тестируемой СИИ;

- соответствующие аппаратные и тестовые конфигурации СИИ;

- соответствующие инструменты тестирования;

- дату проведения тестирования;

- идентификацию лица, проводившего тестирование.

ГОСТ ISO 14971 требует от изготовителя СИИ составить список известных и прогнозируемых опасностей, связанных с СИИ как в нормальных условиях, так и в условиях неисправности, и рассмотреть прогнозируемую последовательность событий, которые могут привести к опасным ситуациям и вреду. Согласно определениям, опасность не может привести к вреду до тех пор, пока последовательность событий или другие обстоятельства (включая нормальное использование) не приведут к опасной ситуации. На этом этапе риск можно оценить, оценив как тяжесть, так и вероятность возникновения вреда (см. рисунок Г.1). Вероятность возникновения вреда может быть выражена как комбинация отдельных вероятностей (P₁, P₂) или как единственная вероятность (P). Разложение на P₁ и P₂ не является обязательным. На рисунке Г.1 показан базовый набор основных понятий от опасности к опасной ситуации и до вреда (см. [2]).