ГОСТ Р 58976-2020/ISO/TR 80002-2:2017

Группа Р20

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

Изделия медицинские

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

Часть 2

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

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

ОКС 11.040.01

         35.240.80

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

Предисловие

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

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

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

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

________________

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1 - Управление жизненным циклом программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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