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

Роль IEC 62304 в программном обеспечении медицинских устройств

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

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

Справочная информация и цель МЭК 62304

До широкого внедрения МЭК 62304 программное обеспечение для медицинских устройств часто разрабатывалось с использованием специальных процессов, которые широко варьировались между производителями. По мере роста сложности программного обеспечения регулирующие органы признали необходимость согласованной международно признанной структуры, которая могла бы учитывать уникальные риски программного обеспечения в медицинских устройствах. Стандарт был разработан Техническим комитетом МЭК 62/SC 62A в сотрудничестве с Международной организацией по стандартизации (ISO) и Ассоциацией по улучшению медицинского оборудования (AAMI). Он предназначен для согласования с существующими стандартами управления качеством и управления рисками, такими как ISO 13485 (системы управления качеством) и ISO 14971 (управление рисками для медицинских устройств).

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

Требуя всеобъемлющей документации, интеграции управления рисками и прослеживаемости требований к проектированию и тестированию артефактов, IEC 62304 создает аудиторскую запись, которая демонстрирует соответствие. Эта запись имеет важное значение для получения регулирующих утверждений от таких органов, как Управление по контролю за продуктами и лекарствами США (FDA), европейские нотифицированные органы в соответствии с Регламентом о медицинских устройствах (MDR), Министерство здравоохранения Канады и Японское агентство по фармацевтическим препаратам и медицинским устройствам (PMDA). Стандарт был признан гармонизированным стандартом в Европейском союзе и широко принят FDA в качестве консенсусного стандарта, что означает, что соответствие может использоваться для поддержки предварительных заявок, включая 510 (k) клиренсы и заявки на предварительное одобрение (PMA).

Основные требования IEC 62304

IEC 62304 структурирован вокруг пяти основных процессов: разработка программного обеспечения, техническое обслуживание программного обеспечения, управление рисками программного обеспечения, управление конфигурацией программного обеспечения и решение проблем программного обеспечения. Каждый процесс разбит на конкретные действия, которые должны быть выполнены и документированы. Стандарт также вводит систему классификации безопасности программного обеспечения (класс A, B и C), которая определяет строгость, необходимую для каждого компонента программного обеспечения, на основе потенциального вреда, вызванного сбоем.

Процесс разработки программного обеспечения

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

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

Классификация безопасности программного обеспечения

IEC 62304 классифицирует программные компоненты на три класса безопасности, основываясь на тяжести вреда, который может возникнуть в результате сбоя:

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

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

Класс C: Возможна смерть или серьёзная травма. Пример: программное обеспечение в имплантируемом кардиовертер-дефибрилляторе или инфузионном насосе.

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

Интеграция риск-менеджмента

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

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

Управление конфигурацией и контроль изменений

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

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

Обслуживание программного обеспечения и решение проблем

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

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

Влияние на индустрию медицинских устройств

Принятие МЭК 62304 коренным образом изменило подход производителей медицинских устройств к разработке программного обеспечения. Его влияние охватывает организационные структуры, инженерные практики, стратегии регулирования и качество продукции. Ниже мы рассмотрим влияние с разных точек зрения.

Влияние на производителей

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

Кроме того, соблюдение МЭК 62304 упрощает представление нормативных документов. Многие регулирующие органы, включая FDA, принимают МЭК 62304 в качестве консенсусного стандарта, а это означает, что декларация о соответствии производителя может уменьшить количество дополнительной документации, требуемой во время рассмотрения. Это облегчает более быстрое оформление или утверждение, что является конкурентным преимуществом. Для европейских рынков соблюдение МЭК 62304 по существу является обязательным для маркировки СЕ в соответствии с МДР, как это ожидается уполномоченными органами. Производители, которые не соблюдают, сталкиваются с задержками, запросами дополнительной информации или прямым отказом.

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

Влияние на регулирующие органы и гармонизацию

IEC 62304 был ключевым драйвером глобальной гармонизации регулирования для программного обеспечения медицинских устройств. До его широкого принятия в разных регионах были совершенно разные ожидания в отношении документации программного обеспечения и доказательств безопасности. Стандарт обеспечивает общий язык и набор ожиданий, которые регуляторы в США, Европе, Японии, Канаде, Австралии и других странах приняли или ссылались. Это снижает нагрузку на производителей, которые должны запрашивать одобрение в нескольких юрисдикциях, поскольку они могут подготовить единый набор документации, который соответствует базовому уровню, признанному повсюду.

Например, руководство FDA по использованию готового программного обеспечения и руководство FDA по валидации программного обеспечения соответствуют принципам IEC 62304. Аналогичным образом, европейский MDR явно ссылается на IEC 62304 в качестве согласованного стандарта. Это выравнивание означает, что производитель, который соответствует IEC 62304, имеет хорошие позиции для удовлетворения требований, связанных с программным обеспечением, этих различных нормативных рамок. Регуляторы также выигрывают, потому что они могут полагаться на последовательный, международно разработанный стандарт при рассмотрении представлений, что повышает эффективность и снижает риск недопонимания.

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

Влияние на пациентов и поставщиков медицинских услуг

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

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

Проблемы внедрения МЭК 62304

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

Интенсивность ресурсов

Соблюдение IEC 62304 требует значительных инвестиций в обучение, инструменты и персонал. Производители должны нанимать или обучать инженеров-программистов, которые понимают критически важные для безопасности разработки, специалистов по управлению документами и аудиторов по обеспечению качества. Стоимость внедрения совместимого жизненного цикла может быть непомерно высокой для стартапов или очень небольших компаний. Например, опрос 2020 года Ассоциацией по улучшению медицинского оборудования (FLT:0) AAMI ] обнаружил, что МСП часто тратят 10-20% своего общего бюджета на разработку документации и технологических мероприятий, непосредственно связанных с IEC 62304. Хотя эти инвестиции окупаются в уменьшенных сбоях и более быстрых утверждениях, это может быть препятствием для входа.

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

Интеграция с Agile-развитием

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

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

Системы наследия и обновления продуктов

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

Быстрые технологические изменения

Темпы внедрения программных инноваций, особенно в таких областях, как машинное обучение, облачные вычисления и непрерывное развертывание, часто опережают процесс установления стандартов. IEC 62304 обновляется примерно каждые 10 лет, что может оставлять пробелы. Например, в текущем издании (2015) не в полной мере рассматриваются уникальные проблемы искусственного интеллекта или адаптивных алгоритмов, которые учатся на основе пострыночных данных. Производители, разрабатывающие такие технологии, должны полагаться на дополнительные рекомендации, такие как предлагаемая FDA структура для SaMD и AI / ML или руководство IMDRF по программному обеспечению в качестве медицинского устройства. Этот фрагментарный подход может привести к неопределенности и непоследовательности.

Будущие направления для IEC 62304

Признавая необходимость оставаться актуальным, МЭК работает над вторым изданием МЭК 62304, ожидаемым в середине 2020-х годов. Ключевые области эволюции включают:

SaMD и Non-Embedded Software: Новое издание предоставит более четкие определения и требования к программному обеспечению, которое не встроено в аппаратное устройство, такое как мобильные приложения для здоровья, облачные диагностические алгоритмы и программное обеспечение, используемое в цифровой терапии.

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

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

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

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

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

Заключение

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