Введение в соответствие программного обеспечения медицинских изделий требованиям безопасности
Сегодня цифровое здравоохранение в значительной степени зависит от программного обеспечения. Следовательно, соответствие программного обеспечения медицинских устройств требованиям безопасности спасает жизни. В прошлом ошибки в программном обеспечении приводили к смертельным случаям. Например, аппарат лучевой терапии Therac-25 стал причиной смерти нескольких пациентов. Поэтому регулирующие органы по всему миру вводят строгие правила для обеспечения безопасности пациентов. Таким образом, разработчики должны следовать стандарту IEC 62304.
Что представляет собой стандарт IEC 62304?
IEC 62304 — это международно признанный стандарт функциональной безопасности, определяющий процессы жизненного цикла программного обеспечения для разработки и сопровождения медицинского программного обеспечения. Он обеспечивает систематический, основанный на оценке рисков подход к разработке программного обеспечения, определяя процессы, действия и задачи от первоначального планирования концепции до послепродажного обслуживания и вывода из эксплуатации. Регулирующие органы, такие как Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA) и Европейский союз, в значительной степени полагаются на соответствие стандарту IEC 62304 как на объективное доказательство того, что программное обеспечение медицинского устройства было разработано безопасно и эффективно.
SaMD (программное обеспечение как медицинское устройство) против SiMD (программное обеспечение в медицинском устройстве)
Данный стандарт в целом применяется к двум основным категориям программного обеспечения для здравоохранения:
- SaMD (программное обеспечение как медицинское устройство): Автономное программное обеспечение для здравоохранения, работающее на оборудовании общего назначения (например, смартфоне или облачном сервере) и предназначенное для медицинских целей, например, диагностическое приложение на основе искусственного интеллекта.
- SiMD (программное обеспечение в медицинском устройстве): Встроенное программное обеспечение или микропрограмма, являющиеся неотъемлемой частью физического медицинского устройства, например, системы управления внутри инфузионного насоса или аппарата МРТ.
Понимание классификации безопасности программного обеспечения IEC 62304
Стандарт IEC 62304 предусматривает риск-ориентированный подход, что означает, что объем необходимой документации и тщательного тестирования напрямую зависит от потенциального вреда, который может причинить программное обеспечение в случае сбоя.
Разница между классами A, B и C стандарта IEC 62304
Программное обеспечение медицинских устройств подразделяется на три класса по степени безопасности в зависимости от наихудшего сценария тяжести травм, возникающих в результате программной опасности:
- Класс A: Причинение вреда здоровью исключено.
- Класс Б: Сбой в программном обеспечении может привести к несерьезной травме.
- Класс С: Сбой в программном обеспечении может привести к серьезным травмам или смерти.
Как риск определяет уровень строгости процесса разработки программного обеспечения
Присвоенный класс безопасности определяет строгость жизненного цикла разработки. Например, программное обеспечение класса C требует тщательной, подробной проектной документации и тщательного модульного тестирования, тогда как для класса A требуется меньше формальной документации. В перспективе, готовящееся ко второму изданию IEC 62304 упрощает это до двухуровневой модели «Строгость процесса разработки программного обеспечения»: Уровень I (заменяющий класс A) и Уровень II (объединяющий классы B и C для программного обеспечения с более высоким уровнем риска).
Основные процессы жизненного цикла программного обеспечения для здравоохранения
Стандарт IEC 62304 разбивает жизненный цикл разработки программного обеспечения на конкретные взаимосвязанные процессы для контроля рисков и обеспечения соответствия требованиям.
План разработки программного обеспечения (SDP) и Спецификация требований к программному обеспечению (SRS)
Разработка начинается с плана разработки программного обеспечения (ПДУ), в котором описываются объем проекта, методологии, стандарты и стратегии отслеживания. После этого создается спецификация требований к программному обеспечению (СПС). В СПС документируются все функциональные требования, требования к производительности и безопасности, включая меры контроля рисков, полученные на основе анализа опасностей.
Архитектурное и детальное проектирование программного обеспечения
Архитектура программного обеспечения разбивает систему на высокоуровневые элементы и определяет их интерфейсы. Для программного обеспечения с более высоким уровнем риска (классы B и C) разработчики должны дополнительно документировать детальную структуру каждого программного модуля, обеспечивая достаточную детализацию для руководства кодированием и обеспечения логического разделения критически важных компонентов.
Реализация модульных проектов, верификация и системное тестирование.
В процессе реализации код пишется и оценивается на соответствие детальному проекту. Мероприятия по верификации включают модульное тестирование (проверка отдельных модулей кода), интеграционное тестирование программного обеспечения (обеспечение корректного взаимодействия модулей) и комплексное тестирование программной системы (подтверждение соответствия всего программного обеспечения требованиям спецификации программного обеспечения).
Процесс сопровождения программного обеспечения и устранения неполадок
Соответствие программного обеспечения требованиям не заканчивается на этапе развертывания. Стандарт IEC 62304 требует наличия структурированного процесса сопровождения программного обеспечения и процесса устранения неполадок в программном обеспечении. Любые исправления ошибок, обновления безопасности или обновления функций после выпуска должны быть оценены с точки зрения их влияния на риски, должным образом задокументированы и систематически проверены перед выпуском.
Работа с программным обеспечением SOUP, COTS и устаревшим программным обеспечением для медицинских устройств.
Современное программное обеспечение редко существует в вакууме. Использование сторонних компонентов ускоряет разработку, но создает скрытые риски.
Как управлять SOUP (программным обеспечением неизвестного происхождения)
СУП Аббревиатура SOUP расшифровывается как Software of Unknown Provenance (программное обеспечение неизвестного происхождения) и относится к коммерческому готовому программному обеспечению (COTS), библиотекам с открытым исходным кодом или устаревшему коду, разработанному не в соответствии с требованиями стандарта IEC 62304. Для безопасного использования SOUP производители должны определить его функциональные требования, отслеживать известные аномалии и разработать внешние механизмы контроля рисков для смягчения потенциальных сбоев.
Кибербезопасность программного обеспечения медицинских устройств и спецификация материалов (SBOM).
В случае с подключенными устройствами управление программным обеспечением тесно связано с кибербезопасностью. Регулирующие органы теперь настоятельно рекомендуют использовать спецификацию программного обеспечения (SBOM) для отслеживания всех компонентов с открытым исходным кодом и компонентов сторонних производителей. Ведение спецификации программного обеспечения позволяет производителям быстро выявлять и устранять уязвимости кибербезопасности на протяжении всего жизненного цикла устройства.
Интеграция стандарта IEC 62304 с соответствующими стандартами и нормативными актами.
Стандарт IEC 62304 разработан как часть более широкой нормативно-правовой и качественной системы.
Интеграция стандартов ISO 13485 (система менеджмента качества) и ISO 14971 (управление рисками).
Стандарт IEC 62304 прямо ссылается на и требует использования стандартами качества ISO 13485 для создания системы управления качеством (СУК) и стандартами качества ISO 14971 для управления рисками, связанными с медицинскими изделиями. Стандарты работают совместно: ISO 14971 определяет опасности и вред, а IEC 62304 гарантирует, что программное обеспечение обеспечивает безопасную реализацию и проверку необходимых мер контроля рисков.
IEC 62304 против FDA CSA (Computer Software Assurance)
Хотя программное обеспечение регулируется стандартом IEC 62304, внутри В отношении медицинских изделий, структура обеспечения качества программного обеспечения (CSA) FDA фокусируется на программном обеспечении, используемом в производстве, изготовлении продукции или самой системе управления качеством. Стандарт IEC 62304 устанавливает строгие процессы жизненного цикла для клинического программного обеспечения, в то время как CSA FDA предлагает гибкий подход к валидации на основе оценки рисков для внутреннего производственного и автоматизированного программного обеспечения.
Соответствие требованиям Регламента ЕС о медицинских изделиях (MDR) № 11 и требованиям маркировки CE.
Для компаний, стремящихся получить маркировку CE, Регламент ЕС о медицинских изделиях (MDR) требует, чтобы программное обеспечение разрабатывалось в соответствии с современными стандартами. Соблюдение стандарта IEC 62304 гарантирует соответствие этим требованиям. Согласно Правилу 11 Регламента ЕС о медицинских изделиях, большинство медицинского программного обеспечения переводится в класс IIa или выше, что делает строгое соответствие стандарту IEC 62304 практически обязательным.
Гибкая методология разработки против каскадной модели в разработке программного обеспечения для медицинских устройств.
Интеграция гибких методологий с соответствием стандарту IEC 62304
Распространенное заблуждение заключается в том, что IEC 62304 требует жесткой каскадной методологии. В действительности, IEC 62304 не зависит от модели и полностью поддерживает гибкую разработку. Используя такие рекомендации, как AAMI TIR45, команды могут проводить гибкие спринты, сохраняя при этом соответствие требованиям. Ключевым моментом является обеспечение того, чтобы «Определение готовности» для каждого спринта включало обновление матрицы отслеживания требований (RTM), оценку файлов рисков и поэтапное предоставление доказательств проверки.
Преодоление проблем, связанных с соответствием стандарту IEC 62304, с помощью решений Visure.
Управление жизненным циклом программного обеспечения с помощью электронных таблиц приводит к серьезным проблемам с соблюдением нормативных требований. Например, команды легко теряют из виду механизмы контроля рисков. Поэтому вам необходима специализированная платформа управления жизненным циклом приложений (ALM) на основе требований. Решения Visure Visure предлагает идеальную платформу для организаций, работающих в сфере медицинских технологий. Во-первых, Visure предоставляет готовые шаблоны для стандартов IEC 62304 и ISO 14971. Во-вторых, он автоматизирует генерацию матрицы отслеживания требований (RTM). Кроме того, Visure напрямую связывает потребности пользователя с тестами и рисками. В конечном итоге это гарантирует готовность к аудиту и ускорение циклов разработки.
Заключение
Дефекты программного обеспечения медицинских устройств могут привести к летальному исходу. Следовательно, стандарт IEC 62304 выступает в качестве важнейшей системы безопасности. В частности, он обязывает команды систематически проектировать, тестировать и поддерживать программное обеспечение. Поэтому компании должны внедрять эти процессы жизненного цикла. Более того, интеграция дополнительных стандартов, таких как ISO 13485, предотвращает дорогостоящие отзывы продукции. В конечном итоге, этот строгий стандарт гарантирует, что пациенты получают безопасное и эффективное медицинское программное обеспечение.
Воспользуйтесь бесплатной пробной версией Visure. и убедитесь сами, как управление изменениями на основе ИИ может помочь вам управлять изменениями быстрее, безопаснее и с полной готовностью к аудиту.
