Медицинское ПО · регуляторная инженерия · рынок ЕС
Как получить CE-маркировку для медицинского программного обеспечения
Разработка ПО и регуляторная подготовка должны завершиться одновременно
CE-маркировка — не логотип, который добавляют после завершения разработки. Это видимый результат системы, связывающей назначение продукта, архитектуру ПО, клинические доказательства, меры управления рисками, процессы качества и пострегистрационные обязанности.
Открыть путь к выпуску ↓Один продукт, два синхронизированных контура
Надежное приложение не становится медицинским изделием, соответствующим требованиям, автоматически. Продукт и его регуляторные доказательства должны описывать одно назначение, одни риски, одну функциональность и одну выпущенную версию.
Создать функцию
Требования, архитектура, реализация, интерфейсы, верификация, удобство использования, кибербезопасность, конфигурация и контролируемый выпуск.
Создать обоснование
Квалификация, классификация, риски, GSPR, клинические доказательства или доказательства эффективности, СМК, оценка соответствия и контроль жизненного цикла.
01
Сначала определите, является ли программное обеспечение медицинским изделием #
Медицинское программное обеспечение — это ПО, предназначенное для самостоятельного или совместного применения в целях, подпадающих под определение медицинского изделия или медицинского изделия для диагностики in vitro.
Программное обеспечение может быть MDSW, если оно поддерживает диагностические или терапевтические решения, контролирует физиологические процессы, рассчитывает лечение для конкретного пациента, анализирует медицинские изображения, интерпретирует диагностические данные или прогнозирует клинически значимые исходы.
ПО не обязательно должно управлять физическим изделием или непосредственно воздействовать на организм человека. Самостоятельное приложение может быть медицинским изделием, если его назначение является медицинским.
- Поддержка диагностических или терапевтических решений
- Расчеты или прогнозы для конкретного пациента
- Анализ изображений, сигналов или физиологических данных
- Мониторинг физиологических процессов
- Интерпретация лабораторных или иных диагностических данных
Не каждый цифровой продукт в здравоохранении является MDSW. ПО, которое используется только для записи пациентов, выставления счетов, коммуникации, хранения, архивирования, передачи данных без их изменения или поддержания общего благополучия, может не подпадать под MDR и IVDR, если оно не выполняет медицинскую функцию.
Не начинайте с выбора класса риска. Сначала определите, является ли продукт медицинским изделием, IVD, принадлежностью или продуктом, не подпадающим под действие MDR и IVDR.
Актуальный европейский подход изложен в руководстве Европейской комиссии MDCG 2019-11 rev.1. Граница между категориями также рассмотрена в статье MDRC о том, когда ПО является медицинским изделием или принадлежностью.
02
Определите назначение до построения регуляторного пути #
Назначение лежит в основе оценки соответствия. Оно определяет, что обещает программное обеспечение, какое регулирование применяется, какие доказательства нужны и к чему может привести ошибочный результат.
Полезная формулировка назначения описывает медицинскую функцию, пользователей, популяцию пациентов, среду применения, входные данные, результаты и клинический контекст. Формулировка «программное обеспечение для медицинских работников» регулируемый продукт не определяет.
- Медицинская функция и клиническое заявление
- Предполагаемая популяция пациентов и пользователь
- Среда применения и рабочий процесс
- Входные данные и создаваемый результат
- Роль результата в принятии медицинского решения
Не менее важны границы продукта. Цифровая платформа может объединять регулируемую клиническую функцию с модулями коммуникации, хранения или администрирования. Эти функции не обязательно имеют одинаковый регуляторный статус. Производитель должен показать, какие компоненты относятся к медицинскому изделию, а какие остаются за его пределами.
Четкая регуляторная стратегия не позволяет маркетинговым заявлениям, технической архитектуре и пути оценки соответствия разойтись в ходе разработки.
03
Определите, применяется MDR или IVDR #
Программное обеспечение обычно подпадает под MDR, если оно предназначено для диагностики, профилактики, прогнозирования, мониторинга, лечения или облегчения заболевания, но не соответствует специальному определению IVD.
ПО может подпадать под IVDR, если оно предоставляет информацию путем исследования данных, полученных из образцов человеческого организма, и эта информация используется для одной из целей IVDR, например для определения патологического состояния, предрасположенности, прогнозирования ответа на лечение или мониторинга терапевтических мер.
Источник данных важен, но сам по себе ничего не решает. Необходимо одновременно оценить назначение, характер создаваемой информации и то, как эта информация используется.
Информация или функции с медицинским назначением, которые не относятся к специальной области исследования in vitro.
Информация, полученная при исследовании образцов человеческого организма для одной из целей IVDR.
Лабораторная информационная система, которая только хранит и передает результаты, может не быть IVD. Программное обеспечение, интерпретирующее лабораторные измерения и создающее диагностическую информацию для конкретного пациента, может им являться.
Юридические определения приведены в официальных текстах Регламента о медицинских изделиях и Регламента о медицинских изделиях для диагностики in vitro.
04
Классифицируйте ПО с учетом его клинического влияния #
Квалификация отвечает на вопрос, является ли продукт медицинским изделием. Классификация показывает, какой уровень регуляторного контроля ему необходим.
Медицинское программное обеспечение по MDR обычно классифицируется с применением правила 11 Приложения VIII. ПО, предоставляющее информацию для диагностических или терапевтических решений, как правило, относится к классу IIa. Оно переходит в класс IIb или III, если ошибочное решение может привести к более тяжелым последствиям.
ПО для мониторинга физиологических процессов обычно относится к классу IIa. Оно может перейти в класс IIb, если контролирует жизненно важные параметры, изменение которых способно создать непосредственную опасность. Программное обеспечение, не охваченное этими положениями правила 11, может остаться в классе I.
Для программного обеспечения по IVDR классификация следует из его назначения и применимых правил IVDR. Самостоятельное ПО классифицируется отдельно. Программное обеспечение, управляющее IVD или влияющее на его использование, обычно относится к классу этого изделия.
Обоснование классификации должно связывать назначение, применимое правило и прогнозируемые клинические последствия. Класс I нельзя выбирать только потому, что продукт является «всего лишь программным обеспечением».
05
Создайте систему качества, которая управляет реальным процессом разработки #
Каждому производителю нужна система менеджмента качества, соответствующая продукту, его классу риска и выполняемой деятельности. СМК должна контролировать значительно больше, чем написание программного кода.
Регуляторная стратегия, назначение, требования и контроль разработки
Риски, клиническая оценка, верификация, валидация и удобство использования
Поставщики, внешние процессы, выпуски, изменения и конфигурация
PMS, инциденты, кибербезопасность, CAPA и постоянное соответствие
EN ISO 13485 широко используется для построения такой системы и может подтверждать соответствие в пределах охватываемых им требований. Стандарт не заменяет MDR или IVDR. Производитель по-прежнему должен показать выполнение каждого применимого требования законодательства.
Для ПО, требующего участия Нотифицированной Организации, СМК обычно оценивается в рамках оценки соответствия. Хорошо оформленного набора процедур недостаточно, если записи о разработке показывают, что эти процедуры не соблюдались.
06
Создавайте доказательства жизненного цикла, а не заявление о соответствии IEC 62304 #
IEC 62304 предлагает признанную структуру процессов жизненного цикла программного обеспечения. Она охватывает планирование, требования, архитектуру, детальное проектирование, реализацию, интеграцию, тестирование, выпуск, сопровождение, управление конфигурацией и разрешение проблем.
Это важный стандарт, но не полный регуляторный ответ. Сам по себе IEC 62304 не демонстрирует соответствие всем Общим требованиям безопасности и эффективности. Он не заменяет управление рисками, проектирование удобства использования, клинические доказательства, кибербезопасность, маркировку, систему качества или пострегистрационный надзор.
Процессы жизненного цикла ПО и контролируемое сопровождение
Управление рисками медицинского изделия на протяжении жизненного цикла
Проектирование удобства использования и контроль рисков применения
Мероприятия по безопасности в жизненном цикле программного обеспечения для здравоохранения
Процессы системы качества, поддерживающие стабильное соответствие
Применение стандартов обычно является добровольным, а их выбор зависит от продукта и его рисков. Если стандарт гармонизирован и опубликована ссылка на него в Официальном журнале ЕС, его применение может создавать презумпцию соответствия только в отношении охватываемых требований. Европейская комиссия публикует актуальную информацию о гармонизированных стандартах для медицинских изделий.
Дополнительные аспекты рассмотрены на страницах MDRC о соответствии IEC 62304 и кибербезопасности медицинского программного обеспечения.
07
Техническая документация должна рассказывать одну связную историю
Технический файл — не хранилище разрозненных документов. Это прослеживаемое обоснование того, как программное обеспечение было задумано, разработано, оценено, выпущено и поставлено под контроль жизненного цикла.
Назначение ведет к требованиям. Требования ведут к рискам и мерам контроля. Меры контроля ведут к верификации, клиническим доказательствам и итоговому заключению о соотношении пользы и риска.
Она должна связывать каждое применимое требование с конкретными контролируемыми доказательствами. Общее заявление «соответствует IEC 62304» такую прослеживаемость не заменяет.
08
Докажите клиническую ценность или эффективность #
Программное обеспечение может работать точно в соответствии со спецификацией и при этом не выполнять клиническую задачу. Технически точный алгоритм не обязательно имеет клиническую значимость.
Производитель должен доказать обоснованность связи между результатом работы ПО и целевым клиническим состоянием, а также достаточную эффективность ПО в предполагаемой популяции, среде и рабочем процессе.
Обоснованная клиническая связь, техническая и клиническая эффективность поддерживают клиническую оценку.
Научная обоснованность, аналитическая и клиническая эффективность поддерживают оценку эффективности.
Доказательства могут включать литературу, аналитические исследования, ретроспективные наборы данных, проспективные исследования, данные об удобстве использования, реальные данные и пострегистрационную информацию. Клиническое исследование или исследование эффективности требуется не для каждого продукта. Объем доказательств зависит от заявлений, новизны, риска, входных данных, результатов и предполагаемой популяции.
Актуальная подборка руководств Европейской комиссии включает MDCG 2020-1 по клинической оценке и оценке эффективности MDSW. MDRC также предлагает материалы по клинической оценке медицинских технологий, основанных на ПО.
09
Определите регуляторные роли и выполните требования UDI и регистрации #
Каждый производитель должен иметь в своем распоряжении как минимум одно Лицо, ответственное за соблюдение нормативных требований, которое соответствует квалификационным требованиям статьи 15. Микро- и малые предприятия могут привлекать внешнего PRRC, но это лицо должно оставаться постоянно и непрерывно доступным.
Производитель, находящийся за пределами Европейского союза, должен назначить единственного Уполномоченного Представителя в ЕС как минимум для всех продуктов, относящихся к одной группе изделий. Отношения оформляются письменным мандатом, принятым представителем.
Регуляторный надзор с квалификацией и доступностью, предусмотренными статьей 15
Официальный контакт в ЕС для производителя, находящегося за пределами Союза
Медицинское программное обеспечение также подпадает под систему UDI. Производитель должен определить применимую структуру Basic UDI-DI и UDI-DI, соблюдать правила выбранной организации-эмитента и решить, как идентификатор будет представлен для программного обеспечения.
Новый UDI-DI может потребоваться, если изменение затрагивает исходную эффективность, безопасность, назначение или интерпретацию данных программным обеспечением. Basic UDI-DI не является идентификатором отдельной версии ПО.
Связь между этими идентификаторами объясняется в статье MDRC о UDI-DI, Basic UDI-DI, GTIN и GMN.
С 28 мая 2026 года первые четыре модуля EUDAMED обязательны к применению. Поэтому регистрация субъектов, UDI и изделий должна входить в действующий план вывода продукта на рынок. Текущий статус опубликован в обзоре EUDAMED Европейской комиссии.
10
Пройдите применимую процедуру оценки соответствия #
Путь оценки соответствия определяется применимым регламентом и классом риска. ПО класса I по MDR и класса A по IVDR в общем случае может декларироваться производителем самостоятельно. Но и для этого пути необходимы полная техническая документация, соответствующая СМК, доказательства, управление рисками, регистрация и планирование пострегистрационного надзора.
Самостоятельное декларирование не означает освобождения от требований. Оно означает, что производитель проводит оценку соответствия без обычного участия Нотифицированной Организации.
Для более высоких классов ПО Нотифицированная Организация оценивает применимую СМК и техническую документацию. Нотифицированная Организация не предоставляет CE-маркировку. После успешной оценки она выдает соответствующий сертификат. Затем производитель оформляет Декларацию соответствия ЕС и наносит CE-маркировку. Если в оценке участвует Нотифицированная Организация, рядом с маркировкой указывается ее четырехзначный идентификационный номер.
Подготовка должна начаться до подачи официальной заявки. Производителю нужна Нотифицированная Организация, область назначения которой охватывает применимый регламент и соответствующие коды медицинских изделий или IVD. При оценке будет проверено, описывают ли назначение, классификация, риски, доказательства, жизненный цикл ПО и СМК один и тот же продукт.
На странице MDRC о готовности к оценке Нотифицированной Организацией объясняется, как подготовиться к такой проверке.
11
Рассматривайте CE-маркировку как начало контролируемого жизненного цикла #
Медицинское программное обеспечение не прекращает меняться после выхода на рынок. Операционные системы развиваются. Библиотеки обновляются. Появляются уязвимости. Распределение данных меняется. Пользователи находят неожиданные способы работы, а клиническая практика движется вперед.
Жалобы, эффективность, уязвимости, тенденции и реальное применение
Клиническое влияние, риск, регуляторную значимость и необходимость действий
Исправления, обновления, коммуникации, доказательства и конфигурацию
Отчеты PMS, PSUR при необходимости, CAPA и записи об изменениях
Регрессионное тестирование, проверку безопасности и эффективности мер
Одобренную версию, обновленную информацию и продолжающееся соответствие
Исправление может быть небольшим с технической точки зрения, но клинически значимым. Обновление модели может повысить среднюю эффективность и одновременно создать новый риск для недостаточно представленной группы пациентов. Новый источник данных может изменить регуляторные границы продукта.
Каждое изменение необходимо оценивать с точки зрения его влияния на назначение, классификацию, безопасность, эффективность, кибербезопасность, клинические доказательства, UDI и статус сертификации.
Заключение
CE-маркировка означает выпуск контролируемой медицинской технологии
Получение CE-маркировки для медицинского программного обеспечения — не упражнение по созданию документов. Это процесс превращения медицинской идеи в контролируемый продукт с достаточной доказательной базой.
Самый надежный путь начинается с точного назначения, четких границ продукта и обоснованной классификации. Затем он связывает разработку ПО с рисками, удобством использования, кибербезопасностью, клиническими доказательствами, технической документацией и системой качества.
Если эти элементы создаются параллельно с продуктом, оценка соответствия становится итогом уже выстроенной системы, а не попыткой восстановить регуляторную историю после завершения разработки.
Типичные разрывы
Что производители чаще всего недооценивают
Назначение формулируется после того, как архитектура и заявления уже зафиксированы.
Класс I выбирается потому, что продукт является программным обеспечением.
Соответствие IEC 62304 принимается за полное соответствие MDR или IVDR.
Тестирование демонстрирует техническую точность, но не клиническую ценность.
Техническая документация не совпадает с фактически выпущенной версией.
Кибербезопасность, UDI, EUDAMED и PMS откладываются до конца проекта.
Регуляторный путь программного обеспечения
Нужно согласовать разработку продукта с регуляторной подготовкой?
Из центра знаний
