Краткий ответ: когда программное обеспечение имеет медицинское предназначение (диагностика, профилактика, мониторинг, прогнозирование, лечение), оно считается медицинским изделием согласно Регламенту ЕС по медицинским изделиям (MDR, 2017/745) и получает класс риска: I, IIa, IIb или III, в основном по Правилу 11 Приложения VIII. Класс определяет, можете ли вы самостоятельно сертифицировать изделие (только класс I) или вам потребуется уведомленный орган, насколько глубокой должна быть клиническая оценка и как будет осуществляться постпродажный надзор. Отдельно, инженерный стандарт IEC 62304 присваивает программному обеспечению класс безопасности: A (невозможно причинение вреда), B (возможно причинение несерьезного вреда) или C (возможно причинение смерти или серьезного вреда), что определяет объем документации, проектирования и тестирования, требуемых для жизненного цикла. Эти две классификации связаны, но независимы, и обе определяются потенциальным вредом, который может причинить программное обеспечение, а не его сложностью.
Шаг 1: Является ли это вообще устройством?
Программное обеспечение считается медицинским изделием согласно Регламенту ЕС по медицинским изделиям (MDR), если его предполагаемое назначение является медицинским: диагностика, профилактика, мониторинг, прогнозирование, предсказание или лечение (Статья 2(1)). Программное обеспечение, которое только хранит, архивирует, передает, отображает или ищет данные, не является медицинским изделием; программное обеспечение, которое создает или изменяет медицинскую информацию для поддержки решения о диагностике или лечении, является таковым, согласно MDCG 2019-11.
Определение MDR (Статья 2(1)) основано на предполагаемом назначении. Программное обеспечение, которое хранит, архивирует, передает, отображает или выполняет простые поиски данных, не является устройством (MDCG 2019-11 указывает на это). Программное обеспечение, которое создает или изменяет медицинскую информацию для поддержки принятия решений о диагностике или лечении, является. Запись, показывающая лабораторное значение с референсным диапазоном лаборатории, не является устройством; программное обеспечение, которое сообщает пользователю, что значение указывает на состояние, или рекомендует дозировку, является. См. Является ли приложение для здоровья медицинским устройством? для подробного описания этапа квалификации.
Шаг 2: Класс риска MDR, Правило 11
Правило 11 MDR классифицирует программное обеспечение медицинских изделий по степени вреда, который может вызвать неправильное решение. Программное обеспечение, предоставляющее информацию для диагностических или терапевтических решений, по умолчанию относится к классу IIa, к классу IIb, если такие решения могут привести к серьезному ухудшению состояния или необходимости хирургического вмешательства, и к классу III, если они могут привести к смерти или необратимому ухудшению состояния. Программное обеспечение для мониторинга относится к классу IIa, а для жизненно важных параметров — к классу IIb.
| Программное обеспечение, предназначенное для… | Класс MDR |
|---|---|
| предоставления информации, используемой для принятия решений в диагностических или терапевтических целях (по умолчанию) | IIa |
| …где такие решения могут привести к смерти или необратимому ухудшению здоровья | III |
| …где такие решения могут привести к серьезному ухудшению здоровья или хирургическому вмешательству | IIb |
| мониторинга физиологических процессов (по умолчанию) | IIa |
| …мониторинга жизненно важных физиологических параметров, где отклонения могут привести к непосредственной опасности для пациента | IIb |
| все остальное (программное обеспечение, являющееся устройством, но не подпадающее под вышеперечисленное) | I |
Правило 11 перевело большую часть ранее относившегося к классу I программного обеспечения в классы IIa или выше, что является основной причиной, по которой MDR ощущался как шаг вперед для цифрового здравоохранения. MDCG 2019-11 и структура оценки рисков IMDRF (значимость информации × состояние ситуации в здравоохранении) помогают разместить пограничные случаи. Программное обеспечение, которое управляет аппаратным устройством или влияет на него, принимает класс этого устройства (Правило 3.3 имплементационных правил).
Последствия по классам: класс I — самодекларация с техническим файлом и регистрацией, без уведомленного органа (кроме Im, Is, Ir); IIa — требуется оценка системы качества уведомленным органом и образец технической документации; IIb — то же самое с более тщательным рассмотрением документации; III — полный обзор технической документации и, где применимо, консультация с группой экспертов. Все классы требуют системы менеджмента качества, клинической оценки, пропорциональной классу, лица, ответственного за соответствие нормативным требованиям, UDI, регистрации в EUDAMED, постпродажного надзора и бдительности.
Шаг 3: Класс безопасности программного обеспечения IEC 62304
Класс безопасности программного обеспечения по стандарту IEC 62304 оценивает программное обеспечение медицинских изделий по степени наихудшего вреда, к которому оно может привести, после применения внешних мер контроля рисков: класс A, когда травма невозможна; класс B, когда возможна несерьезная травма; класс C, когда возможна смерть или серьезная травма. Класс определяет объем проектирования, верификации и документации, требуемых для жизненного цикла программного обеспечения.
IEC 62304 (2006, с поправкой 2015) — это гармонизированный стандарт для процессов жизненного цикла программного обеспечения медицинских изделий. Его класс безопасности определяется наихудшей опасной ситуацией, к которой программное обеспечение может привести, после рассмотрения мер контроля рисков, внешних по отношению к программному обеспечению:
| Класс | Опасная ситуация может привести к… | Что требуется для жизненного цикла |
|---|---|---|
| A | отсутствию травм или вреда здоровью | План разработки программного обеспечения, требования, выпуск; решение проблем; управление конфигурацией |
| B | несерьезному вреду здоровью | A: плюс архитектурное проектирование, проверка интеграции и системных тестов, документированная проверка модулей |
| C | смерти или серьезному вреду здоровью | B: плюс детальное проектирование каждого модуля, дополнительная архитектурная сегрегация, более строгая проверка |
Классы присваиваются для каждой программной системы и могут быть присвоены для каждого элемента программного обеспечения после декомпозиции, так что только рискованные части требуют строгости класса C; стандарт объясняет аргументацию сегрегации, которая для этого требуется. ISO 14971 (управление рисками) используется для классификации; IEC 82304-1 добавляет требования на уровне продукта для программного обеспечения для здоровья, работающего на платформах общего назначения (телефоны, облако).
Как они взаимодействуют
Класс риска MDR и класс безопасности IEC 62304 являются независимыми: класс MDR (от I до III) определяет регуляторный путь и участие уполномоченного органа, в то время как класс IEC 62304 (от A до C) определяет строгость инженерного процесса. Приложение класса IIa может относиться к классу 62304 B или C в зависимости от вреда, который может причинить неправильный вывод.
Класс MDR касается регуляторного пути; класс IEC 62304 касается инженерного процесса. Приложение класса IIa по Правилу 11 может быть классом IEC 62304 B (неверная информация может привести к несерьезной задержке в лечении) или классом C (если предложение неправильной дозировки может привести к смерти). Устройство класса I обычно относится к классу 62304 A, но не обязательно. Уведомленные органы ожидают, что технический файл будет демонстрировать класс 62304 с его обоснованием, документы жизненного цикла на этом уровне и связь с файлом управления рисками. Кибербезопасность (MDCG 2019-16, IEC 81001-5-1) оценивается параллельно.
Рабочий пример
Рабочий пример программного обеспечения как медицинского изделия (SaMD): приложение для отслеживания симптомов, которое регистрирует, отображает и передает информацию о симптомах, не является медицинским изделием. Добавление функции, которая оценивает симптомы по валидированной шкале и указывает пользователю, когда следует обратиться за медицинской помощью, делает его медицинским изделием, по умолчанию относящимся к классу IIa по Правилу 11 MDR, с классом IEC 62304 B или классом C для случая использования, связанного с сердечно-сосудистой системой.
Приложение для отслеживания симптомов, которое позволяет пользователям регистрировать симптомы, просматривать тенденции и делиться ими с врачом: не является устройством (хранение, отображение, передача). То же приложение добавляет функцию, которая оценивает зарегистрированные симптомы по валидированной шкале и сообщает пользователю, когда оценка предполагает необходимость обратиться за медицинской помощью: теперь является устройством, по умолчанию по Правилу 11 класс IIa (информация для диагностического решения; ошибочное "нет необходимости обращаться за помощью" может привести к задержке лечения, серьезной, но обычно не необратимой, поэтому не IIb или III, если только целевое состояние не делает его таковым). IEC 62304: ложное заверение может привести к задержке лечения, от несерьезного до серьезного в зависимости от состояния, поэтому класс B, возможно C для случая использования, связанного с сердечно-сосудистыми заболеваниями. Путь: ISO 13485 QMS, уведомленный орган, клиническая оценка шкалы, инженерия удобства использования (IEC 62366-1), постпродажный надзор.
Соединенные Штаты, кратко
В Соединенных Штатах FDA регулирует программное обеспечение как медицинское изделие в зависимости от предполагаемого использования, с классами I, II и III, а также путями 510(k), De Novo и PMA. Закон о реформах здравоохранения 21-го века исключает из статуса медицинского изделия административное программное обеспечение, продукты для общего оздоровления, электронные медицинские карты и определенные системы поддержки принятия клинических решений. FDA признает IEC 62304 в качестве консенсусного стандарта.
FDA регулирует программное обеспечение как медицинское изделие по той же логике предполагаемого использования, с классами I, II и III и путями 510(k), De Novo и PMA. Закон 21st Century Cures Act (раздел 3060) исключил несколько категорий из статуса устройств: административное программное обеспечение, программы общего оздоровления, электронные медицинские записи и системы поддержки принятия клинических решений, которые позволяют клиницисту независимо проверять основу рекомендации (руководство FDA 2022 года по CDS интерпретирует это узко). FDA признает IEC 62304 как консенсусный стандарт и с 2023 года требует документацию по кибербезопасности для "киберустройств". ISO 13485 стал основой американского регулирования системы качества (QMSR) в 2026 году.
В Anpheros
Anpheros Daily хранит, отображает и передает; он не оценивает, не интерпретирует и не рекомендует, и его предполагаемое назначение это подтверждает. Поэтому он не является медицинским изделием согласно Правилу 11 или исключениям Закона Cures, и команда применяет безопасность в стиле ISO 27001 и документированную практику разработки программного обеспечения без пути устройства. Если бы когда-либо была добавлена функция с медицинским назначением, она была бы классифицирована согласно Правилу 11 и разработана в соответствии с IEC 62304 перед выпуском. См. Прозрачность здравоохранения.
Эта страница объясняет регулирование для команд по продуктам и инженерии. Это не юридическая консультация; тексты, на которые ссылаются в разделе "Источники", являются авторитетными, и ваш специалист по защите данных, уведомленный орган или юрист принимают решение в вашем конкретном случае. Последний обзор: октябрь 2026 г.
Связанные страницы
- Является ли приложение для здоровья медицинским устройством? Правило 11 MDR ЕС
- MDR против IVDR
- Объяснение CDS Hooks
- Карта регулирования медицинских данных
- Закон ЕС об ИИ и ИИ в здравоохранении
Источники
- Регламент (ЕС) 2017/745 (MDR), Приложение VIII, EUR-Lex
- MDCG 2019-11: Квалификация и классификация программного обеспечения
- IEC 62304:2006+AMD1:2015, Процессы жизненного цикла программного обеспечения медицинских изделий
- IEC 82304-1:2016, Безопасность продуктов программного обеспечения для здоровья
- FDA: Руководство по программному обеспечению для поддержки принятия клинических решений (2022)
- FDA: Программное обеспечение как медицинское изделие
Частые вопросы
Может ли программное обеспечение быть классом I по MDR?
Да, но редко: только программное обеспечение с медицинским назначением, которое не участвует в принятии диагностических или терапевтических решений и не мониторит физиологические процессы. Большинство приложений, которые квалифицируются как устройства, попадают в класс IIa.
Требуется ли устройству класса IIa клинические испытания?
Требуется клиническая оценка, которая может опираться на литературу, эквивалентность и данные о производительности; клиническое исследование требуется, когда существующие доказательства недостаточны. Программное обеспечение, заявляющее о диагностической производительности, обычно требует собственного исследования производительности.
Является ли IEC 62304 обязательным?
Это гармонизированный стандарт, поэтому его соблюдение является презумпцией соответствия требованиям MDR к программному обеспечению (Приложение I, 17). Вы можете использовать другой подход, но тогда вам придется доказать эквивалентность, что на практике никто не делает.
Что насчет функций ИИ?
Применяются те же правила, плюс Закон ЕС об ИИ: устройство с оценкой уведомленного органа является системой ИИ высокого риска согласно Приложение X, с требованиями к данным, журналированию, прозрачности и человеческому надзору, оцениваемыми совместно с MDR.
Попробуйте бесплатно в песочнице
Первый запрос FHIR за 5 минут. API HL7 FHIR R4 с встроенным согласием пациента: попробуйте в песочнице, затем подключите свое приложение или систему клиники.
Бесплатно · 30 синтетических пациентов · без карты
Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.
О Anpheros →