ГОСТ Р 70478-2022. Национальный стандарт Российской Федерации. Программное обеспечение как медицинское изделие. Применение системы менеджмента качества

(утв. и введен в действие Приказом Росстандарта от 15.11.2022 № 1291-ст)

1 сентября 2023 года

Предисловие

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

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

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

4 Настоящий стандарт является модифицированным по отношению к документу Международного форума регуляторов медицинских изделий (IMDRF) «Программное обеспечение как медицинское изделие. Применение системы менеджмента качества» (IMDRF/SaMD WG/N23 FINAL:2015 «Software as a Medical Device (SaMD): Application of Quality Management System», MOD) путем изменения его структуры.

Измененные структурные элементы в тексте стандарта выделены курсивом.

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

Сопоставление структуры настоящего стандарта со структурой примененного в нем документа приведено в дополнительном приложении ДБ

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

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

Введение

Программные средства становятся все более важными и широко распространенными в сфере предоставления медицинских услуг. Международный форум регуляторов медицинских изделий (IMDRF) стремится установить общие согласованные подходы к идентификации, пониманию и регулированию такого подтипа программного обеспечения, которое предназначено для функционирования в качестве медицинского изделия. Данный подтип определен в ГОСТ Р 59765 «Программное обеспечение как медицинское изделие. Основные термины и определения», являющийся основой для разработки общей терминологии как для изготовителей, так и для регуляторов.

Рабочая группа IMDRF по вопросу регулирования программного обеспечения как медицинского изделия также разработала соответствующий документ (см. ГОСТ Р 59766), в котором представлены критерии для категоризации программного обеспечения как медицинского изделия (ПОкМИ) на основе комбинирования значимости информации, предоставляемой ПОкМИ.

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

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

Основными целями настоящего стандарта являются:

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 59765 Программное обеспечение как медицинское изделие. Основные термины и определения

ГОСТ Р 59766 Программное обеспечение как медицинское изделие. Основные подходы к категорированию риска

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

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

Настоящий стандарт не устанавливает новых терминов и использует терминологию, принятую в национальных стандартах, связанных с СМК и менеджментом риска медицинских изделий. Определение ПОкМИ приведено в ГОСТ Р 59765.

При использовании настоящего стандарта следует руководствоваться терминами и определениями, установленными в решениях Евразийской экономической комиссии (ЕЭК) и нормативно-правовых актах Российской Федерации в отношении медицинских изделий. Это особенно важно при использовании таких понятий, как «медицинское изделие», «медицинские изделия для диагностики in vitro», «изготовитель (производитель)», «выпуск в обращение», «уполномоченный представитель», «дистрибьютор» и «импортер».

4 Принципы менеджмента качества программного обеспечения как медицинского изделия

4.1 Концепции, представленные в данном разделе, относятся к требованиям, установленным в разделах 4 и 5 ГОСТ ISO 13485-2017.

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

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

4.3 Результативная СМК для ПОкМИ должна включать следующие принципы:

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

Данные принципы не следует рассматривать независимо друг от друга как отдельные серии процессов в организации. Наоборот, результативная СМК должна устанавливать четко определенные связи между представленными на рисунке 1 тремя принципами, а именно:

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

5 Принципы руководства и организационной поддержки

5.1 Руководство и ответственность в организации

5.1.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в разделе 5 и пункте 8.2.4 ГОСТ ISO 13485-2017.

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

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

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

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

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

5.2 Управление ресурсами и инфраструктурой

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

Концепции, представленные в данном подразделе, относятся к требованиям, установленным в разделе 6 ГОСТ ISO 13485-2017.

5.2.1 Персонал

5.2.1.1 Концепции, представленные в данном пункте, относятся к требованиям, установленным в 6.1 и 6.2 ГОСТ ISO 13485-2017.

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

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

5.2.2 Инфраструктура и производственная среда

5.2.2.1 Концепции, представленные в данном пункте, относятся к требованиям, установленным в 6.3 и 6.4 ГОСТ ISO 13485-2017.

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

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

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

6 Процессы поддержки жизненного цикла

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

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

6.1 Планирование процессов жизненного цикла продукта

6.1.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 5.4, 7.1 и 7.3.2 ГОСТ ISO 13485-2017.

6.1.2 Цель планирования состоит в предоставлении дорожной карты, которой нужно следовать в течение стадий разработки жизненного цикла продукта. Это вытекает из принципа менеджмента качества, согласно которому наиболее оптимальные результаты достигаются при следовании плану управления проектами, например с использованием подхода «планируй-делай-проверяй-действуй». Планирование продукта включает определение этапов, видов деятельности, ответственности и ресурсов, необходимых для разработки ПОкМИ. Важно понимать, что планирование не является статичным. Результаты планирования (планы) должны обновляться по мере появления новой информации или выполнения основных этапов.

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

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

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

6.2 Менеджмент риска: процесс, сконцентрированный на безопасности пациента

6.2.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 7.1 ГОСТ ISO 13485-2017.

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

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

• со стороны пользователей:

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

• со стороны приложений:

должно ли приложение ПОкМИ быть доступным на любом устройстве или оно должно быть ограничено определенными устройствами с целью снижения рисков для пользователей?

• со стороны устройств:

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

• со стороны среды применения:

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

• со стороны защищенности:

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

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

6.3 Управление документацией и записями

6.3.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в подразделе 4.2 ГОСТ ISO 13485-2017.

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

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

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

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

6.4 Управление и менеджмент конфигурации

6.4.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 4.2.4, 4.2.5, 7.3.9, 7.5.1, 7.5.8 и 7.5.9 ГОСТ ISO 13485-2017.

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

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

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

6.5 Измерение, анализ и улучшение процессов и продуктов

6.5.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 7.2.3, 7.3.9 и 7.5.1, 8.1, 8.2, 8.3, 8.4 ГОСТ ISO 13485-2017.

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

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

Пример - Компании Magna и Parva разрабатывают новую усовершенствованную версию их ПОкМИ. У компании Magna есть специальный независимый отдел, взаимодействующий с отделами продаж, маркетинга и разработкой продуктов, с целью официального исследования крупной базы ее заказчика и получения подробной информации о функционировании продукта. Компания Parva приглашает несколько первых потребителей и заказчиков ПОкМИ в офис для проведения обсуждения и получения обратной связи. Обе компании также используют встроенные аналитические средства для получения данных о восприятии потребителями соответствующих продуктов. Они также регулярно рассматривают и анализируют претензии потребителей с целью определения тенденций и потенциальных зон для усовершенствования. На основе изучения данных различных источников обе компании решают общие вопросы, полученные по обратной связи с потребителями, включая новые/обновленные клинические данные.

6.6 Управление процессами, деятельностью и продуктами, переданными на аутсорсинг

6.6.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 7.4, 7.4.1, 7.4.3, 7.4.2 и 8.5.1 ГОСТ ISO 13485-2017.

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

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

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

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

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

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

7 Процессы создания и применения

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

7.1 Управление требованиями

7.1.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 4.2, 7.2.1, 7.2.2, 7.2.3 и 7.1, перечисление d) ГОСТ ISO 13485-2017.

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

7.1.3 Вопросы безопасности пациента и условия среды применения

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

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

7.1.4 Вопросы технологического и системного окружения

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

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

7.2 Проектирование (дизайн)

7.2.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 7.3, 7.3.3, 7.3.4, 7.3.5, 7.3.9 и 7.3.2, перечисление b) ГОСТ ISO 13485-2017.

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

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

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

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

7.2.3 Вопросы безопасности пациента и условия среды применения

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

7.2.4 Вопросы технологического и системного окружения

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

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

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

7.3 Разработка

7.3.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 7.3, 7.3.3, 7.3.4, 7.3.5, 7.3.9 и 7.3.2 перечисление b) ГОСТ ISO 13485-2017.

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

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

Кроме того, деятельность по разработке может включать:

• выявление, анализ и оценку критических областей (например, использование и распределение памяти, зависимость от связи, скорость работы и расстановка приоритетов задач);
• оценку методов верификации данных (для ПОкМИ с функцией ввода данных) в зависимости от влияния на потребителя;
• учет требований разработчика базовой платформы.

Пример - Как для компании Magna, так и для компании Parva кодирование занимает центральное место в создании продукта (ПОкМИ). Компания Magna проводит экспертные анализы кода своего продукта, планируя периодическое проведение экспертной оценки у нескольких программистов, которые непосредственно не связаны с проверяемым кодом. У компании Parva есть только один разработчик, который является экспертом в выбранной им операционной системе. Компания использует методику «Дизайн для удобства чтения кода», тем самым позволяя проводить проверку кода с членом команды, который не является экспертом. Таким образом обе компании достигают выполнения требований к должному проведению анализа программного кода и обеспечению независимости.

7.4 Верификация и валидация

7.4.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 7.3.6, 7.3.7 и 7.4.3 ГОСТ ISO 13485-2017.

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

7.4.3 Различные виды деятельности по верификации и валидации могут включать или состоять:

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

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

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

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

7.5 Внедрение

7.5.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 7.2.3, 7.5, 7.5.2, 7.5.3, 7.5.4 и 7.5.11 ГОСТ ISO 13485-2017.

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

7.5.3 Деятельность по внедрению ПОкМИ в клиническую среду может включать:

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

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

7.6 Техническая поддержка (обслуживание)

7.6.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 7.2.3, 7.5, 7.5.4, 7.5.10, 7.6 и 8.2.1 ГОСТ ISO 13485-2017.

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

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

7.6.4 Деятельность по проведению технического обслуживания ПОкМИ может включать:

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

Пример - Процесс управления изменениями в компании Magna предусматривает мониторинг изменений в ПОкМИ, выполняемый внутренней службой по управлению изменениями. Внутренняя служба по управлению изменениями представляет собой многопрофильную группу сотрудников, осуществляющих с установленной периодичностью анализ запросов об изменениях и разрабатывающих рекомендации о возможности их выполнения с целью включения в следующую версию ПОкМИ. В компании Parva назначен руководитель проекта, уполномоченный действовать в качестве представителя потребителя. К функциональным обязанностям руководителя проекта относится обеспечение получения обратной связи от потребителя, анализ полученных замечаний/рекомендаций и определение задач по реализации принятых изменений в следующей версии ПОкМИ. Обе компании уделяют приоритетное внимание запросам на изменения и обеспечивают своевременное решение любых существенных проблем.

7.7 Вывод из эксплуатации (деактивация или завершение жизненного цикла)

7.7.1 Концепции, представленные в данном подразделе, относятся к требованиям, установленным в 4.2 и 7.5.1 ГОСТ ISO 13485-2017.

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

a) реализацию действий по завершении активной поддержки ПОкМИ, дезактивации и/или удалению ПОкМИ и его вспомогательных данных;

b) обеспечение доведения до сведения потребителей информации о прекращении технического обслуживания, поддержки ПОкМИ и, если применимо, порядка действий по выводу ПОкМИ из эксплуатации со стороны потребителя;

c) доведение до сведения потребителей следующей информации:

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

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

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

e) согласование с потребителем порядка архивирования среды пользователя ПОкМИ, включая вопросы защищенности и целостности информации и/или систем.

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

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

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

Приложение ДА (справочное)

СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ НАЦИОНАЛЬНЫХ И МЕЖГОСУДАРСТВЕННЫХ СТАНДАРТОВ МЕЖДУНАРОДНЫМ СТАНДАРТАМ, ИСПОЛЬЗОВАННЫМ В КАЧЕСТВЕ ССЫЛОЧНЫХ В ПРИМЕНЕННОМ ДОКУМЕНТЕ

Таблица ДА.1

Обозначение ссылочного национального и межгосударственного стандарта	Степень соответствия	Обозначение и наименование ссылочного международного стандарта
ГОСТ ISO 13485-2017	IDT	ISO 13485:2003 «Изделия медицинские. Системы менеджмента качества. Требования для целей регулирования»
ГОСТ ISO 14971-2021	IDT	ISO 14971:2019 «Изделия медицинские. Применение менеджмента риска к медицинским изделиям»
ГОСТ Р 59765-2021	MOD	IMDRF/SaMD WG/N10 FINAL:2013 «Программное обеспечение как медицинское изделие. Основные определения»
ГОСТ Р 59766-2021	MOD	IMDRF/SaMD WG/N12 FINAL:2014 «Программное обеспечение как медицинское изделие. Основные подходы к категорированию риска»
Примечание — В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов: - IDT — идентичные стандарты; - MOD — модифицированные стандарты.

Приложение ДБ

Структура настоящего стандарта	Структура документа IMDRF IMDRF/SaMD WG/N23
Введение	1.0 Введение
1 Область применения (раздел 2.0)	2.0 Область применения
2 Нормативные ссылки (раздел 3.0)	3.0 Ссылки
3 Термины и определения (раздел 4.0)	4.0 Термины и определения
4 Принципы менеджмента качества программного обеспечения как медицинского изделия (раздел 5.0)	5.0 Принципы менеджмента качества программного обеспечения как медицинского изделия
5 Принципы руководства и организационной поддержки (раздел 6.0)	6.0 Руководство и организационное обеспечение программного обеспечения как медицинского изделия
6 Процессы поддержки жизненного цикла (раздел 7.0)	7.0 Процессы обеспечения жизненного цикла программного обеспечения как медицинского изделия
7 Процессы создания и применения (раздел 8.0)	8.0 Процессы создания и применения программного обеспечения как медицинского изделия
<*>	Приложение А Структура регулирования медицинских изделий в соответствии с документом IMDRF/SaMD WG/N23
Приложение ДА Сведения о соответствии ссылочных национальных и межгосударственных стандартов международным стандартам, использованным в качестве ссылочных в примененном документе
Приложение ДБ Сопоставление структуры настоящего стандарта со структурой примененного в нем документа
<*> Данный раздел исключен.

УДК 006.88:006.354	ОКС 11.040.01
Ключевые слова: изделия медицинские, программное обеспечение, система менеджмента качества

---