6-месечната пътна карта: от концепцията за изкуствен интелект в здравеопазването до подаването на регулаторни документи

Повечето основатели на компании за изкуствен интелект в здравеопазването, с които разговаряме, не страдат от липса на амбиция, клинични знания или технически възможности. Това, което им липсва, е ясна последователност.

Те знаят, че се нуждаят от CE маркировка. Знаят, че се нуждаят от клинично валидиране. Знаят, че се нуждаят от система за управление на качеството (СУК). Това, което не знаят, е какво да направят първо, какво може да се изпълнява паралелно, какво ще блокира всичко останало, ако бъде пропуснато, и как изглежда реалистичният график, когато не сте производител на медицински изделия с 500 служители и специален отдел за регулаторни въпроси.

Това е пътната карта. Тя се основава на наученото от нас при изграждането на изкуствен интелект с регулаторно ниво за здравни компании – включително превръщането на сърдечната диагностика на KARDI AI от прототип до пълно техническо досие клас IIa на ЕС за шест месеца. Прегледът от нотифицирания орган и издаването на сертификат се извършват след подаването на досие и се добавят още 6–12 месеца, в зависимост от опашката на органа и циклите на вашите заявки. Тази статия е за шестте месеца, които вие контролирате.

Не е теоретично. Работи последователността.

Това е оперативното допълнение към нашите материали за класификацията на SaMD , инженерната реалност на сърдечния ИИ и бизнес аргументите за сърдечния ИИ . Ако все още не сте сигурни дали сте медицинско устройство, започнете с материала за класификация. Ако сте решили да изграждате, това е времевата линия.

Преди да започне отброяването на времето: предварителните изисквания

Шест месеца до подаване е постижимо. Не е постижимо от нулата. Преди да започне изпълнението на пътната карта, три неща трябва да са верни.

Предназначението ви е заключено. Регулаторната версия, а не версията за инвеститорско предложение. По-конкретно: какво клинично решение информира вашият софтуер? За кого? В каква клинична обстановка? Използва се от кого? Член 2(12) от EU MDR определя предназначението и всяко последващо регулаторно решение — класификация, стратегия за клинична оценка, обхват на управление на риска — следва от него. Промяната на предназначението ви по средата на процеса е скъпа и често фатална за времевата рамка.

Вашият клиничен набор от данни съществува и е подходящ. Не просто голям — подходящ. Данни на ниво пациент с валидирани етикети за достоверност. Няма пациент, който да се появява както в обучителните, така и във валидационните набори. Методология за етикетиране, която нотифициран орган ще приеме (консенсус от множество оценители, където е приложимо, оценени тестови набори, където съществуват данни за резултатите). Статистическа мощност, достатъчна за подкрепа на твърденията за ефективност, които ще направите в клиничната си оценка. Ако тези данни не съществуват, времето започва да отброява времето, когато съществуват, а не сега. Изграждането на набор от данни с регулаторно качество само по себе си обикновено е работен процес от 12 до 18 месеца и не е включен в тази пътна карта.

Ръководството е единодушно относно това, какво всъщност изисква маркировката CE. Учредителите понякога откриват по средата на процеса, че бордът им е очаквал маркировката CE да струва 50 000 евро и да отнеме четири месеца, когато реалността за клас IIa е 300 000–800 000 евро обща стойност на програмата за 12–24 месеца от сериозното начало, плюс таксите на нотифицирания орган често 100 000–300 000 евро. Това несъответствие убива проектите. Определете очакванията, преди да започне пътната карта.

Месец 1: класификация, анализ на пропуските и стратегия

Седмица 1–2: регулаторна класификация

Определете вашата MDR класификация в ЕС преди всичко друго. За софтуера, Правило 11 от Приложение VIII е съответното правило. Класификацията по подразбиране е Клас IIa . Клас IIb се прилага, ако последицата от софтуерно подкрепеното решение може да бъде сериозно влошаване на здравето или хирургическа интервенция. Клас III се прилага, ако последицата може да бъде смърт или необратимо влошаване. Повечето клинични диагностики с изкуствен интелект попадат в Клас IIa.

Документирайте обосновката си за класификация в писмен вид. Този документ става част от вашето техническо досие и аргументът трябва да бъде защитим пред нотифициран орган, който може да не е съгласен с вас. Истинските гранични случаи изискват писмено становище за класификация от нотифициран орган, препратка към гранични насоки на MDCG или консултация с компетентен орган — формални механизми, а не неформален съвет. (За по-задълбочено разглеждане на логиката на класификацията в различните юрисдикции вижте нашия материал за класификация на SaMD .)

Ако едновременно се насочвате към пазара в САЩ, съпоставете устройството си с насоките на FDA за софтуерните функции и определете дали сте 510(k) (ако съществува съществено еквивалентен предикат) или De Novo (ако не). PMA рядко е правилният път за SaMD и обикновено можете бързо да го изключите. Изискванията за доказателства се различават между ЕС и САЩ, но необходимите клинични данни често се припокриват.

Планирайте едновременно наслагването на Закона за изкуствения интелект (ИИ) . От август 2026 г. устройствата от клас IIa и по-високи на ЕС MDR, които включват системи с ИИ, автоматично се класифицират като високорискови съгласно Закона на ЕС за ИИ. Оценката на съответствието по Закона за ИИ се интегрира с MDR, но добавя документация относно управлението на данните за обучение, прозрачността за внедрителите, разпоредбите за човешки надзор и специфичното за ИИ наблюдение след пускане на пазара. Третирайте съответствието със Закона за ИИ като паралелен работен поток от първата седмица, а не като модернизация.

Седмица 2–3: избор на нотифициран орган

Не всички нотифицирани органи са еднакви за диагностика с изкуствен интелект. Екосистемата на нотифицираните органи по Регламента на ЕС за медицински изделия (MDR) има приблизително 50 нотифицирани органа, но много по-малък брой имат значителен опит в прегледа на софтуера за медицински изделия с изкуствен интелект/машинно обучение.

Поискайте информация от три до пет нотифицирани органа. Попитайте конкретно: прегледали ли са софтуер за ИИ/МО във вашата категория (рентгенология, кардиология, диагностика и др.)? Какъв е текущият им срок за преглед на техническо досие от клас IIa от подаването до сертифицирането? Предлагат ли консултации преди подаване? Какви са техните специфични очаквания за доказателствата за клинична оценка на ИИ/МО? Подготвени ли са за интеграцията на оценката на съответствието със Закона за ИИ?

Избирайте въз основа на опита и капацитета на ИИ, не само на таксата. Капацитетът на нотифицирания орган в момента е истинско пречка : някои органи чакат над 12 месеца само за да започнат оценка на съответствието. Ангажирайте се рано; ангажирането на петия месец, а не на първия, редовно струва на програмите цяло тримесечие.

Седмица 3–4: анализ на пропуските

Одит на текущото състояние спрямо шест изисквания:

Зрялост на СУК. Документирани процедури за контрол на дизайна, управление на промените, контрол на документите, управление на доставчиците, оплаквания и коригиращи действия — и записи, показващи, че ги изпълнявате, а не само че сте ги написали.

Съответствие с IEC 62304. Документация за жизнения цикъл на разработка на софтуер. Документация за архитектурата. Записи за тестове на модули, интеграции и системи. Класифициран клас за безопасност на софтуера за вашата система.

Управление на риска по ISO 14971. Систематично идентифициране и оценка на рисковете, включително специфични за ИИ режими на отказ (фалшиво положителни резултати, фалшиво отрицателни резултати, изместване на разпределението, отклонение на калибрирането, умора от тревоги).

IEC 62366-1 използваемост. Спецификация за употреба, потребителски профил и план за формиращи и обобщаващи оценки на използваемостта.

IEC 81001-5-1 Киберсигурност. Моделиране на заплахи, документиране на сигурен жизнен цикъл на разработка, управление на уязвимости и разпространение на актуализации за сигурност. Това е все по-критичен работен поток и често е подценяван от екипите, ръководени от машинно обучение.

Клинични доказателства и етикетиране. Набор от данни, отговарящ на горните изисквания; предварително определен план за статистически анализ; Инструкция за употреба (IFU), която точно описва предназначението, целевите потребители, противопоказанията и ограниченията.

Резултатът от анализа на пропуските е приоритизиран работен план за периода от втори до пети месец. Не го пропускайте. Екипите, които го пропускат, откриват през четвъртия месец, че имат шестмесечен проблем.

Месец 2: Изграждане и основаване на СУК

Системата за управление на качеството е основата, върху която се гради всичко останало. Ако вашата система за управление на качеството не е съвместима, нищо надолу по веригата няма значение.

Какво минимум трябва да обхваща СУК за стартиращ бизнес:

Контрол на документи — Процедури и записи с контролирани версии. Това не изисква скъп софтуер; изисква дисциплина и система, която всички следват.

Проектиране и разработка — Документиран файл с историята на проектирането, показващ как еволюира вашето устройство, със записи за входни и изходни данни от проектирането, както и за верификация и валидиране.

Контрол на промените в софтуера — формален процес за оценка и одобряване на промени във вашия модел на изкуствен интелект, обучителен процес и софтуерна архитектура. Особено важно за системи за машинно обучение, където преобучението представлява форма на промяна. Това е и моментът, в който решавате дали да работите като заключен модел или да планирате предварително определен план за контрол на промените (PCCP) — стратегическо решение, което си струва да се вземе рано, защото то оформя цялата история на управление на промените за целия жизнен цикъл на продукта. (FDA формализира PCCP през 2024 г.; регулаторните органи на ЕС следват примера.)

Интегриране на управлението на риска — Вашата система за управление на качеството трябва да препраща към вашия процес по ISO 14971 и да гарантира, че рисковете след пускане на пазара се включват във файла с риска.

Управление на доставчици — Облачната инфраструктура, компонентите на моделите на трети страни и инструментите за обработка на данни са доставчици съгласно вашата система за управление на качеството и изискват квалификация.

Жалби и бдителност — Система за получаване, регистриране и реагиране на жалби на място и инциденти, подлежащи на докладване.

Процеси на киберсигурност — Управление на уязвимостите, реагиране на инциденти със сигурността и разпространение на актуализации за сигурност. Все по-често фокусна област на нотифицирания орган.

До края на втория месец вашата система за управление на качеството (СУК) трябва да е оперативна, не само документирана. Одитите на нотифицираните органи търсят доказателства, че изпълнявате тези процеси, а не само че сте ги записали.

За подаване на MDR за клас IIa не е абсолютно необходимо отделно сертифициране по ISO 13485 — вашият нотифициран орган ще одитира вашата система за управление на качеството като част от оценката на съответствието. Много компании така или иначе се стремят към отделно сертифициране по ISO 13485, за да рационализират одита от нотифицирания орган, да демонстрират зрялост и да подпомогнат достъпа до пазара на САЩ. Ако поемате по този път, резервирайте сертификационния си одит за четвъртия месец. Повечето сертифициращи органи се нуждаят от предизвестие от четири до шест седмици.

Месец 3: техническо досие — фаза 1

Третият месец обхваща управление на риска, документация по IEC 62304 и документация за киберсигурност, паралелно с текущото функциониране на СУК.

Файл за управление на риска (ISO 14971)

За диагностиката на ИИ, управлението на риска надхвърля конвенционалната оценка на софтуерния риск. Опасностите, които трябва да се вземат предвид:

Процент на фалшиво отрицателни резултати и техните клинични последици. Процент на фалшиво положителни резултати и цената на ненужно проследяване. Производителност върху входни данни извън разпределението (популации или контексти на придобиване, които не са представени в данните за обучение). Калибриране на достоверността на модела — отразява ли оценката за достоверност на алгоритъма действителната му точност? Промяна в разпределението с течение на времето с развитието на клиничната практика. Умора от предупреждения от прекомерно маркиране.

Мерки за смекчаване: дизайн на потребителския интерфейс, който съобщава несигурността по подходящ начин на клиницистите; противопоказания и изключения на популацията, посочени в инструкцията за употреба; калибрирани и специфични за състоянието прагове; инфраструктура за мониторинг след пускане на пазара за откриване на влошаване на производителността; ясни пътища за ескалация за резултати с ниска достоверност.

Файлът за управление на риска е „жив“ документ — той се актуализира, когато събирате данни след пускането на пазара — но първоначалната версия трябва да е завършена за подаване.

Документация по IEC 62304

Класът за безопасност на софтуера произтича от вашата класификация на риска. Клас A , ако не е възможно нараняване. Клас B , ако е възможно несериозно нараняване. Клас C , ако е възможна смърт или сериозно нараняване. Повечето инструменти за подпомагане на диагностичните решения попадат в клас B или C — клас C е по-често срещан, отколкото основателите предполагат, защото последицата от неоткрито сериозно състояние (чрез грешка на лекар или отхвърляне на предупреждение) отговаря на условията.

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

Специфична за машинното обучение документация, която нотифицираните органи все по-често изискват: методология за разделяне на обучението/валидирането/тестването с изолиране на ниво пациент; произход на набора от данни, методология за етикетиране и стъпки за предварителна обработка; обосновка за избор на хиперпараметри; процедура за версии на модела и оценка на промените; показатели за ефективност, разбити по клинично значими подгрупи (пол, възраст, съпътстващи заболявания, оборудване за събиране на данни).

IEC 81001-5-1 киберсигурност

Документацията по киберсигурност вече е паралелен работен поток, а не нещо второстепенно. Очакваните артефакти: модел на заплахите, адресиращ средата за внедряване на устройството; сигурен жизнен цикъл на разработка, интегриран във вашата система за управление на качеството; процес на управление на уязвимостите с документирано сканиране, сортиране и отстраняване; механизъм за разпространение на актуализации за сигурността; план за реагиране при инциденти със сигурността, обвързан с докладване за бдителност на MDR.

За мрежови медицински устройства с изкуствен интелект – почти всички от тях – откритията относно киберсигурността са водещ източник на запитвания от нотифицирани органи. Изграждайте документацията заедно с техническото досие, а не след това.

Месец 4: техническо досие, фаза 2 + използваемост + одит на СУК

Клинична оценка

Клиничната оценка е пакетът от доказателства, демонстриращ безопасно и предвидено действие. За диагностика от клас IIa, AI, тя включва:

Систематичен преглед на литературата, обхващащ клинична информация, съществуващи диагностични методи и публикувани данни за ефективността на сравними системи с изкуствен интелект. Документирана методология (обикновено рамка PICO) с ясни критерии за включване/изключване. Това не е търсене на литература.

Анализ на специфични за устройството клинични данни, демонстриращ ефективност във вашата целева популация. Основните показатели (чувствителност, специфичност, AUC, PPV, NPV) са предварително определени, а не са избрани post-hoc. Все по-често се очакват подгрупови анализи за клинично значими променливи (възраст, пол, съпътстващи заболявания, оборудване за събиране на данни). Доказателства за външна валидация — ефективност върху данни, които не са представени в обучението — значително подсилват досието.

Оценка на клиничната полза спрямо остатъчния риск — заключението, което всъщност интересува регулаторните органи. Не „нашият алгоритъм се представя добре“, а „клиничната полза от внедряването на това устройство в клиничната практика надвишава остатъчните рискове, предвид наличните мерки за смекчаване“.

План за постмаркетингово клинично проследяване (PMCF) , документиращ как ще продължите да събирате клинични доказателства след пускането на продукта на пазара. PMCF е регулаторно изискване за Клас IIa по MDR, а не е по избор.

Клиничната оценка се подписва от клиничен оценител — квалифициран клиницист със съответния опит. Ако това не е някой от вашия екип, той трябва да бъде нает.

Оценка на използваемостта (IEC 62366-1)

Използваемостта е самостоятелен работен поток за оценка на съответствието. За медицинския софтуер с изкуствен интелект основните въпроси са: дали клиницистите правилно интерпретират изходните данни на устройството? Разбират ли неговите ограничения и нива на доверие? Знаят ли кога да се доверят на изходните данни и кога да ги пренебрегнат?

Типична структура: формираща оценка по време на разработката (неформално потребителско тестване за усъвършенстване на интерфейса), след това обобщаваща оценка по-близо до подаването (структурирано тестване с представителни потребители в условия, приближаващи се до реална употреба). Констатациите водят до ревизии на интерфейса и инструкциите за употреба (IFU), които се използват в техническото досие.

По-специално за изкуствения интелект, констатациите за използваемостта, свързани с комуникацията на несигурността, умората от предупреждения и доверието на клиницистите, все по-често се проверяват от нотифицирани органи. Приемайте това като съществена оценка, а не като отметка.

Одит на СУК

Независимо дали преминавате през сертифициране по ISO 13485 или директно през одит на СУК от нотифицирания орган, одитът обикновено продължава от два до три дни. Често срещани констатации, които забавят завършването му: процедурите съществуват, но записите показват, че не се спазват; записите за контрол на промените са непълни за последните актуализации на софтуера; квалификацията на доставчиците е недостатъчно документирана за ключови компоненти (облачна инфраструктура, библиотеки на трети страни, доставчици на етикетиране на данни); планът за следпродажбено наблюдение е общ шаблон, а не специфичен за вашето устройство.

Своевременно реагирайте на констатациите — повечето одитори предоставят 30-дневен срок за реагиране на незначителни несъответствия, преди да издадат сертификат или да започнат процедура.

Месец 5: предварително подаване и взаимодействие с нотифицирания орган

Среща преди подаване на документи

Преди официалното подаване, резервирайте консултация преди подаване с вашия нотифициран орган. Донесете:

Вашият документ за обосновка на класификацията. Обобщение на вашите клинични доказателства и план за анализ. Вашата проектна структура за клинична оценка. Вашият подход за съответствие със Закона за изкуствения интелект. Конкретни въпроси относно тълкуването на ИИ/ML, когато насоките на нотифицирания орган са неясни.

Резултатът е неформална обратна връзка, която можете да използвате, за да прецизирате подадената от вас заявка. Тя не е обвързваща, но значително намалява риска от неочаквани запитвания след подаването ѝ. Добре извършената предварителна ангажираност спестява 8–16 седмици от по-късни цикли на запитвания.

Преглед на техническите файлове

Преди подаване, помолете файла ви да бъде прегледан от някой, който е преминал през преглед от нотифициран орган преди това — в идеалния случай във вашата категория устройства. Често срещани проблеми, които генерират запитвания:

Твърде широко или твърде тясно формулиране на предназначението. Клинична оценка, която не разглежда специфичните въпроси относно доказателствата на нотифицирания орган. Управление на риска, което не разглежда адекватно специфичните за ИИ режими на отказ. Документация по IEC 62304, която описва процеса, но не предоставя доказателства, че е бил спазен. Документация за киберсигурност, която изброява процедури без доказателства за изпълнението им. Документация по Закона за ИИ, която е добавена, а не интегрирана. Клинична оценка, лишена от външна валидация или анализ на подгрупи.

Всеки цикъл на заявки добавя от четири до осем седмици към срока ви след подаване. Инвестицията в преглед преди подаване се изплаща със спестени месеци.

Съгласуване на защитата на данните

Потвърдете, че вашата GDPR документация (оценка на въздействието върху защитата на данните, правно основание, споразумения за обработка на данни, контрол на сигурността) е в съответствие с твърденията в техническото досие относно управлението на данните за обучение и потоците от данни след пускане на пазара. Несъответствието между GDPR и MDR документацията е ненужен източник на одиторски констатации и може да забави програмата, независимо от прегледа на медицинските изделия.

Месец 6: официално подаване и пътят след това

Подаване

Подаването на технически файл от клас IIa е структуриран пакет документи — обикновено няколкостотин страници плюс приложения, обхващащи записи за СУК, клинична оценка, управление на риска, IEC 62304, киберсигурност, използваемост, съответствие със Закона за изкуствения интелект и етикетиране. Изпратете го пълно. Не изпращайте чернова и не разчитайте на цикли на заявки, за да отстраните пропуските; тази стратегия приблизително удвоява времето за сертифициране.

Управление на заявки

Повечето нотифицирани органи работят по официален цикъл на запитване/отговор. Първоначалното ви подаване се преглежда (обикновено в рамките на 6-10 седмици за орган с капацитет), отправят се запитвания и вие отговаряте. За добре подготвено подаване до нотифициран орган с опит в областта на изкуствения интелект, един до два цикъла на запитване са нормални. Три или повече показват значителен пропуск в подаването и са водещата причина програмите да пропуснат първата си година на генериране на приходи.

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

За специфични за ИИ запитвания — все по-често срещани с натрупването на експертен опит от нотифицираните органи — съответният корпус от насоки включва MDCG 2019-11 (квалификация и класификация на софтуер), MDCG 2020-1 (клинична оценка/оценка на ефективността на софтуера на медицинските изделия), MDCG 2019-16 (киберсигурност), позиционни документи на Team-NB относно ИИ/МО и насоки на Службата за ИИ относно Закона за ИИ. Вашият рецензент работи по този корпус; и вие би трябвало.

След подаване

Подаването е началото на нов часовник, а не краят. Реалистични очаквания от подаването до сертифицирането за добре подготвено подаване за ИИ клас IIa: 6–12 месеца, включително цикли на запитвания, в зависимост от капацитета на нотифицирания орган и сложността на евентуални доказателствени спорове, специфични за ИИ. Песимистичните сценарии с органи с ограничен капацитет и множество цикли на запитвания могат да продължат 12–18 месеца.

Планирайте търговски дейности — клинични партньорства, пилотни болнични проекти по договорености за изпитвания, паралелно подаване на документи в САЩ — за да използвате този прозорец продуктивно, вместо да чакате сертификата.

Какво всъщност изисква шестмесечната цел

Постигането на шест месеца от концепцията до завършеното, добре подготвено представяне изисква:

Започвайки с пълен, валидиран, клиничен набор от данни с регулаторно ниво. Пътната карта по-горе не включва събиране на данни, тъй като самото събиране на данни отнема 12–18 месеца.

Паралелно изпълнение на изграждането на СУК, управлението на риска, документирането по IEC 62304, киберсигурността, използваемостта и съответствието със Закона за изкуствения интелект (AI Act) от втория до четвъртия месец, а не последователно.

Определен регулаторен ръководител (вътрешен или нает), който отговаря за процеса на пълен работен ден. Регулаторните ръководители на половин работен ден водят до полузавършени заявки.

Правилно класифициране още през първия месец, така че нищо да не се налага да се преработва.

Третиране на техническото досие като продукта. От регулаторна гледна точка, това е така.

Подаване на пълен, прегледан файл, а не на итеративен чернова.

Нищо от това не е невъзможно за компания от Серия А или Б. Но това изисква третиране на съответствието с регулаторните изисквания като функция на продукта, а не като последваща административна мисъл – и започване достатъчно рано, за да не се превърне времевата рамка в криза.

Къде е мястото на Vector Labs

Работим с основатели на здравни компании за изкуствен интелект и медицински технологични компании по изпълнението на регулаторни програми в три аспекта: определяне на обхвата на програмата (последователност, реалност на времевата линия, решения за изграждане/закупуване на регулаторна инфраструктура), техническа и клинична документация (създаване на техническо досие, клинична оценка, съответствие със Закона за изкуствения интелект) и взаимодействие с нотифицирания орган (предварително подаване, отговор на запитване, подготовка за одит).

Ако обмисляте регулаторна програма — вътрешно или като част от решение за изграждане/покупка — и искате да проверите графика спрямо наученото от нас при доставката на KARDI AI, свържете се с нас на vector-labs.ai .

В по-широкия контекст, наборът от четири статии: класификацията на SaMD обхваща какво да се определи, преди да се започне с тази пътна карта; инженерната реалност на сърдечния ИИ обхваща какво всъщност изисква клиничното ниво; бизнес казусът за сърдечния ИИ обхваща стратегическата рамка около регулаторната работа.