Медицинское программное обеспечение · архитектура стандартов · доказательства по замыслу
Стандарты ISO и IEC для медицинского программного обеспечения
Соответствие требованиям не добавляют после последнего спринта. Оно компилируется в каждый релиз.
Стандарты образуют единую систему сборки. Качество управляет организацией, риск-менеджмент объясняет необходимость мер контроля, жизненный цикл программного обеспечения делает работу прослеживаемой, эксплуатационная пригодность снижает риски ошибок использования, кибербезопасность защищает продукт во враждебной среде, а требования к продукту превращают код в медицинское изделие, готовое к выпуску.
Запустить сборку по стандартам ↓Назначение · архитектура · код · данные · интерфейс
Доказательства связаны на всём жизненном цикле
Главная идея
Стандарты существуют не рядом с кодом
Они определяют, как принимаются, документируются, проверяются и пересматриваются решения, связанные с кодом.
Поэтому соответствующий требованиям релиз — не просто работающий бинарный файл. Это работающий продукт с последовательной историей и контролируемым будущим.
01
Стандарты работают как система, а не как список покупок #
Стандарты ISO и IEC охватывают разные уровни одного продукта. Их области применения намеренно пересекаются, потому что отказ программного обеспечения редко относится только к одной дисциплине. Непонятное предупреждение может одновременно оказаться проблемой эксплуатационной пригодности, дефектом требования к ПО, отказом меры контроля риска и пострыночным сигналом.
Практическая задача состоит не в том, чтобы собрать шесть сертификатов или шесть отдельных папок. Нужно определить применимые стандарты, понять вклад каждого и выстроить прослеживаемость на их стыках.
Система качества, управление проектированием, поставщики, изменения и CAPA
Опасности, оценивание риска, меры контроля, польза и риск, производственные данные
Разработка, сопровождение, конфигурация, решение проблем и классификация безопасности
Безопасность продукта, валидация, информация и обязанности на жизненном цикле
Риски применения и ориентированное на безопасность проектирование эксплуатационной пригодности
Безопасная разработка и сопровождение на протяжении жизненного цикла
Если меняется мера контроля риска, может ли команда определить затронутые требования к ПО, элементы архитектуры, верификацию, работы по эксплуатационной пригодности, анализ кибербезопасности, запись о выпуске и пострыночный мониторинг?
02
До выбора стандартов определите границы продукта #
Не каждое приложение для здоровья является программным обеспечением, представляющим собой медицинское изделие. Предусмотренное назначение, медицинские заявления, пользователи, популяция пациентов, входные данные и значимость результата определяют, подпадает ли ПО под MDR, IVDR или иную нормативную систему.
Та же граница определяет состав программного продукта. Мобильное приложение может зависеть от облачного сервиса, обученной модели, базы данных, веб-портала, сторонней библиотеки, сценария развёртывания и внешнего интерфейса. Исключение компонента из схемы не исключает его из обоснования безопасности.
Медицинское назначение, заявления, применимый регламент и обоснование классификации
Приложения, сервисы, модели, хранилища данных, интерфейсы, платформы и принадлежности
Производитель, поставщики, облачные провайдеры, специалисты по развёртыванию, пользователи и медицинские организации
Что требуется верифицировать, валидировать, отслеживать и удерживать под управлением изменениями
Здесь важно руководство MDCG по квалификации и классификации программного обеспечения, но оно не заменяет обоснование для конкретного продукта. Архитектура стандартов должна следовать за реальным продуктом, а не за присвоенным ему маркетинговым ярлыком.
03
ISO 13485 создаёт организацию вокруг кода #
ISO 13485 не предписывает архитектуру, язык программирования или среду тестирования. Он управляет организацией, которая делает этот выбор.
Планы, входные и выходные данные, анализ, верификация, валидация и передача
Облако, библиотеки, инструменты разработки, внешние команды и критические сервисы
Оценка влияния, одобрение, реализация, верификация и выпуск
Жалобы, несоответствия, CAPA, аудиты и пострыночные данные
Для гибкой команды стандарт не запрещает короткие итерации или автоматизированную поставку. Он требует, чтобы рабочий процесс сохранял одобрение, прослеживаемость, объективные доказательства и контроль. Быстрый конвейер может соответствовать требованиям, невидимый — нет.
04
ISO 14971 объясняет, зачем нужны меры контроля программного обеспечения #
Программное обеспечение обычно причиняет вред пациенту не потому, что состоит из опасного материала. Оно может способствовать причинению вреда из-за неверной информации, задержки действия, потери доступности, непредусмотренных команд, запутанного взаимодействия либо нарушения целостности данных и функций.
ISO 14971 задаёт логику, которая связывает предсказуемые последовательности событий с опасными ситуациями и вредом, а затем позволяет оценить риски, выбрать меры контроля и проверить их результативность. IEC 62304 задаёт программные процессы для реализации и сопровождения многих из этих мер.
Отказ, ошибочное применение, проблема данных, сбой зависимости или атака
Обнаружение, расчёт, отображение, передача или управление работают непредусмотренно
Человек или среда подвергаются воздействию источника вреда
Тяжесть и вероятность определяют решение о риске
Конструкция, защитная мера, информация, мониторинг или операционная мера
Уязвимость не является автоматически риском для безопасности пациента. Но если её эксплуатация способна повлиять на медицинскую функцию, доступность, целостность или клиническое решение, анализ кибербезопасности должен быть связан с файлом менеджмента риска по ISO 14971.
05
IEC 62304 — основа жизненного цикла программного обеспечения #
IEC 62304 устанавливает общую структуру разработки и сопровождения медицинского программного обеспечения независимо от того, является ли ПО самостоятельным медицинским изделием, встроено в него или составляет его неотъемлемую часть.
Сила стандарта — в дисциплинированной непрерывности. Требования ведут к архитектуре и детальному проектированию, реализация — к верификации, версии выпуска остаются идентифицируемыми, проблемы расследуются, а изменения вновь проходят через ту же управляемую систему.
Модель жизненного цикла, работы, ответственность, результаты и интерфейсы
Системные и программные требования, связанные с мерами контроля риска
Программные элементы, сегрегация, интерфейсы и зависимости SOUP
Модули, интеграция и объективные доказательства верификации
Известные аномалии, идентификация версии, записи и контролируемая поставка
Обратная связь, решение проблем, анализ влияния и модификация
IEC 62304 не охватывает окончательную валидацию и выпуск медицинского изделия в целом, даже если изделие полностью состоит из программного обеспечения. Этот пробел должны закрыть доказательства уровня продукта.
06
Классы безопасности IEC 62304 — не классы риска MDR #
Эти две системы классификации отвечают на разные вопросы. Использование их как таблицы пересчёта — один из самых быстрых способов получить слабый план разработки программного обеспечения.
Классифицирует медицинское изделие и определяет маршрут оценки соответствия и уровень регуляторной проверки.
Масштабирует строгость процессов жизненного цикла с учётом возможной травмы в результате отказа программной системы.
Стандарт требует наименее обширного набора процессов жизненного цикла
Применяются дополнительные меры управления архитектурой, проектированием и верификацией
Применяются наиболее обширные меры управления жизненным циклом и доказательствами
Обоснование классификации должно учитывать программную систему, опасные ситуации и внешние меры контроля риска согласно применимой редакции стандарта. Его следует подготовить достаточно рано, чтобы оно влияло на планирование и архитектуру, а затем пересматривать при изменении рисков, интерфейсов или мер контроля.
07
IEC 82304-1 помогает превратить ПО в законченный программный продукт для здравоохранения #
IEC 82304-1 применяется к безопасности и защищённости программных продуктов для здравоохранения, предназначенных для работы на универсальных вычислительных платформах и выпускаемых на рынок без специализированного оборудования. Это точнее, чем утверждение, будто стандарт распространяется на всё автономное программное обеспечение.
Стандарт выходит за рамки процессов разработки и рассматривает продукт целиком. Он охватывает требования к продукту, валидацию, идентификацию, сопроводительную информацию, установку, сопровождение и вывод из эксплуатации на протяжении жизненного цикла.
Как программное обеспечение разрабатывалось и сопровождалось
Предусмотренное применение, системные требования и среда эксплуатации
Программный продукт для здравоохранения в целом соответствует предусмотренному применению
Идентификация, инструкции, ограничения и сопроводительные документы
Установка, сопровождение, обновления и вывод из эксплуатации
Поэтому для программного обеспечения, являющегося медицинским изделием, IEC 62304 и IEC 82304-1 дополняют друг друга. Первый управляет жизненным циклом ПО, второй помогает завершить обоснование уровня продукта.
08
IEC 62366-1 рассматривает интерфейс как часть системы безопасности #
Экран может пройти все функциональные испытания и всё же подтолкнуть пользователя к неверному действию. IEC 62366-1 устанавливает процесс проектирования эксплуатационной пригодности, сосредоточенный на связанных с безопасностью характеристиках пользовательского интерфейса.
Возможности, ограничения, обучение, язык и среда применения
Сценарии применения, задачи, ошибки и связанные с безопасностью характеристики интерфейса
Формирующее оценивание улучшает интерфейс, пока его ещё можно изменить
Итоговое оценивание испытывает окончательный интерфейс в репрезентативных условиях применения
Цель процесса — не общая удовлетворённость клиента. Он предназначен для оценки и снижения рисков, связанных с правильным применением и ошибками использования при нормальном применении. Процесс может выявлять ненормальное применение, но не оценивает и не снижает связанные с ним риски.
09
IEC 81001-5-1 добавляет защищённый жизненный цикл продукта #
IEC 81001-5-1 определяет процессы жизненного цикла для защищённой разработки и сопровождения программного обеспечения для здравоохранения. Он адаптирует принципы безопасной разработки к особому балансу безопасности, результативности и защищённости, необходимому в медицинском ПО.
Роли, компетенции, планирование, политики и среда разработки
Активы, границы доверия, пути атак, последствия и обработка риска
Меры контроля, архитектура, реализация и верификация
Остаточный риск, защищённая поставка, конфигурация и документация
Новые сведения, координированное раскрытие и влияние на продукт
Оценка, устранение, коммуникация и контролируемое развёртывание
Тест на проникновение не может заменить этот жизненный цикл. Это лишь один источник доказательств внутри гораздо более широкой системы. Аналогично сертификат системы менеджмента информационной безопасности на уровне организации сам по себе не доказывает кибербезопасность продукта.
10
Контекст продукта определяет, что ещё войдёт в систему #
Шесть основных стандартов не образуют универсальный закрытый перечень. Аппаратное обеспечение, сети, искусственный интеллект, защита данных, электрическая безопасность и среда развёртывания могут потребовать дополнительных стандартов и руководств.
Может регулировать основную безопасность, существенные эксплуатационные характеристики и дополнительные требования, когда ПО входит в состав медицинского электрооборудования.
Может поддерживать риск-менеджмент при работе медицинских изделий в медицинских ИТ-сетях с распределённой ответственностью.
Может поддерживать систему менеджмента информационной безопасности, но не заменяет проектирование кибербезопасности конкретного продукта.
Предлагает концепции баланса безопасности, результативности и защищённости программного обеспечения и ИТ-систем здравоохранения.
Стандарт включают в план соответствия потому, что его область применения и контекст продукта делают его релевантным, а не потому, что он встретился в контрольном списке другого производителя.
11
Номер стандарта ещё не является заявлением о юридическом соответствии #
Стандарты и регламенты выполняют разные задачи. MDR и IVDR устанавливают юридические обязанности. Стандарты предлагают технические процессы и решения, способные помочь продемонстрировать соответствие.
Устанавливает обязательные юридические требования к продукту и производителю
Стандарт, ссылка на который опубликована, может обеспечивать презумпцию соответствия требованиям в пределах охвата этой ссылки
Может сохранять высокую ценность, даже если он не гармонизирован или ссылка на его последнюю редакцию ещё не опубликована
Следует документировать область применения, редакцию, отклонения, доказательства и связи с юридическими требованиями
Применение гармонизированных стандартов остаётся добровольным. Преимущество зависит от конкретной европейской редакции, поправки, даты и требований, охваченных опубликованной ссылкой. Последняя международная редакция и актуальная гармонизированная европейская редакция могут быть разными документами.
Перед крупным выпуском или подачей досье проверяйте актуальные редакции, поправки, исправления, листы толкования, статус гармонизации и переходные положения. Перечень стандартов двухлетней давности — это не управление конфигурацией.
12
Скомпилируйте единую архитектуру доказательств #
Наиболее эффективная реализация повторно использует доказательства, не смешивая зоны ответственности. Одно одобренное требование к ПО может одновременно быть входным проектным требованием, реализовывать меру контроля риска, поддерживать требование к кибербезопасности и определять критическую задачу эксплуатационной пригодности. Его не следует копировать в четыре неуправляемых документа.
Регуляторика · продукт · клиника · риск
Мы разрабатываем и валидируем один и тот же продукт?Управление проектированием · риск · кибербезопасность · эксплуатационная пригодность
Можно ли проследить каждое критическое требование до его источника и верификации?IEC 62304 · кибербезопасность · SOUP · сегрегация
Видны ли допущения безопасности и защищённости на границах системы?ПО · продукт · эксплуатационная пригодность · клиника
Охватывают ли доказательства код, поведение системы и предусмотренное применение?Конфигурация · риск · продукт · коммуникация
Идентифицируется ли выпущенное состояние и приемлемы ли нерешённые проблемы?PMS · сопровождение · CAPA · кибербезопасность
Могут ли реальные сигналы изменить правильные управляемые записи?Ошибки сборки, которые замечают эксперты
Производитель не может объяснить, почему стандарт применяется, исключён или используется лишь частично.
Два разных вопроса классификации рассматриваются как взаимозаменяемые.
Реализованные меры контроля, требования и верификация больше не описывают один выпуск.
Сценарии кибератак с возможными клиническими последствиями не достигают файла ISO 14971.
Критические задачи и опасные сценарии применения теряются за общими мнениями об интерфейсе.
Для SOUP, унаследованных модулей и предыдущих выпусков отсутствует надлежащее управляемое обоснование.
- Определите предусмотренное назначение, регуляторный статус и полную границу продукта
- Создайте реестр стандартов с областями применения, редакциями и обоснованиями применимости
- Сопоставьте юридические требования со стандартами, процессами и планируемыми доказательствами
- Согласуйте планы СМК, управления рисками, ПО, эксплуатационной пригодности и кибербезопасности до начала реализации
- Встройте общие идентификаторы и прослеживаемость в процесс разработки
- Валидируйте продукт целиком, не останавливаясь на верификации программного обеспечения
- Выпустите управляемую конфигурацию с оценёнными аномалиями и остаточными рисками
- Возвращайте сопровождение, PMS, уязвимости и изменения в ту же систему
Официальные источники
- Обзор ISO 13485 для систем менеджмента качества медицинских изделий
- ISO 14971 — редакция 2019 года по управлению рисками медицинских изделий
- IEC 62304 — редакция 2006 года с Поправкой 1 от 2015 года по процессам жизненного цикла ПО
- IEC 82304-1 — редакция 2016 года по безопасности программных продуктов для здравоохранения
- IEC 62366-1 — редакция 2015 года с Поправкой 1 от 2020 года по проектированию эксплуатационной пригодности
- IEC 81001-5-1 — редакция 2021 года по процессам защищённого жизненного цикла медицинского ПО
- Обзор гармонизированных стандартов для медицинских изделий Европейской комиссии
- Собрание руководств MDCG Европейской комиссии по программному обеспечению и кибербезопасности
Решение о выпуске
Стандарты должны сходиться в одной правде о продукте
ISO 13485 управляет организацией. ISO 14971 — логикой риска. IEC 62304 — жизненным циклом программного обеспечения. IEC 62366-1 — связанным с безопасностью взаимодействием. IEC 81001-5-1 — защищённым жизненным циклом. IEC 82304-1 помогает завершить обоснование уровня продукта.
Ни один из них не спасёт продукт, в котором назначение, архитектура, доказательства и выпущенная конфигурация противоречат друг другу.
Настоящий результат — не полка файлов по отдельным стандартам. Это выпуск, безопасность, характеристики, защищённость и историю которого можно восстановить без догадок.
Архитектура соответствия медицинского ПО
Нужно превратить пересекающиеся стандарты в единую рабочую систему разработки и доказательств?
Обсудить маршрут вашего программного обеспечения ↗Из центра знаний
