Особености на софтуера
Софтуерът се различава от традиционните медицински изделия по един ключов аспект: той се променя бързо. Версии, актуализации, облачни среди, интерфейси, функции на изкуствен интелект и рискове за киберсигурността са естествена част от неговия жизнен цикъл. MDR взема това предвид. За софтуера Приложение I изисква, наред с другото, съвременен подход към жизнения цикъл на разработката, управлението на риска, верификацията и валидирането, както и минимални изисквания за хардуера, ИТ мрежите и защитата срещу неоторизиран достъп. Киберсигурността следователно не е второстепенен ИТ въпрос, а по-скоро част от безопасността и ефективността на продукта.
Особено при софтуера не кодът е от значение, а медицинското предназначение. Приложение за уелнес не се квалифицира като медицински софтуер само защото е технически сложно. И обратно, на пръв поглед просто приложение може напълно да попада в обхвата на MDR, ако информацията от него се използва за диагностични или терапевтични решения. Актуалните насоки на MDCG относно квалификацията и класификацията на софтуера изясняват точно това разграничение.
Изисквания в MDR – къде могат да бъдат намерени?
Всеки, който желае да пусне софтуер на пазара съгласно MDR, трябва да прочете много внимателно съответните раздели на регламента. Най-важните раздели са:
Приложение I, което определя общите изисквания за безопасност и експлоатационни характеристики. За софтуера тук са особено важни изискванията относно процеса на разработване, управлението на риска, информационната сигурност, валидирането и ИТ-средата.
Приложения II и III уреждат техническата документация, както и изискванията за надзор след пускането на пазара. За софтуера това включва и доказателства за верификация и валидиране на софтуера като част от документацията на продукта.
Приложение VIII, и по-специално правило 11, е от централно значение за класифицирането на медицинския софтуер. В MDCG 2019-11, преразгледано през 2025 г., се обясняват трите основни принципа на правило 11: софтуер, който предоставя информация за диагностични или терапевтични решения; софтуер, който наблюдава физиологични процеси; и „всички други видове софтуер“. В зависимост от клиничната значимост класификацията може да варира от клас I до клас III.
Член 52 и приложения IX–XI описват оценката на съответствието. За изделия от клас I декларацията за съответствие обикновено се издава от самия производител; за изделия от клас IIа и по-високи се изисква участието на нотифициран орган.
Накрая,приложение XIV е основният референтен документ за клиничната оценка и клиничното проследяване след пускане на пазара (PMCF). Особено при софтуера това е област, която често се установява систематично твърде късно.
Най-важните стандарти за медицински софтуер
MDR определя регулаторните изисквания. При практическото прилагане обаче някои стандарти са от особено значение, тъй като те дефинират „състоянието на техниката“.
IEC 62304 е основният стандарт за жизнения цикъл на медицинския софтуер. Той описва процесите за разработване и поддръжка на софтуер, когато самият софтуер е медицинско изделие или неразделна част от медицинско изделие.
ISO 14971 е референтният стандарт за управление на риска при медицинските изделия, като изрично включва софтуера като медицинско изделие.
ISO 13485 е основният стандарт за управление на качеството на медицинските изделия през целия им жизнен цикъл. За производителите, които се стремят да създадат стабилна организация, отговаряща на изискванията на MDR, той служи като практическа оперативна основа.
IEC 62366-1 обхваща инженерството на използваемостта. Това е особено важно за софтуера, тъй като неправилната работа, подвеждащите указания за потребителя или неясните аларми могат да имат непосредствени последствия за безопасността.
IEC 82304-1 е особено актуален за софтуер за здравеопазване на общи ИТ платформи, т.е. за продукти без специален хардуер. Стандартът разглежда безопасността и сигурността на ниво продукт и поради това е от голямо значение за много самостоятелни софтуерни продукти или „Софтуер като медицинско изделие“ (SaMD). Особено заслужава да се отбележи, че IEC 82304-1 определя конкретни изисквания за валидирането на SaMD и е едновременно цитиран в IEC 62304, който е хармонизиран съгласно MDR.
Класификация: решаващата първа стъпка
Най-често задаваният и важен първоначален въпрос е: В какъв клас попада моят софтуер? Именно тук много проекти се провалят — не поради технологията, а поради неясна предвидена цел. Съгласно MDCG 2019-11 Rev.1, правило 11 по същество се прилага в зависимост от това дали софтуерът предоставя информация за диагностични или терапевтични решения, следи физиологични процеси или попада в остатъчната категория. Примерите в насоките показват, че софтуерът за диагностика или подпомагане на терапията може бързо да попадне в клас IIa, IIb или III, докато „всички останали софтуери“ са от клас I.
От гледна точка на нотифицирания орган следователно е ясно: класификацията не е административна стъпка в края на процеса, а основата на цялата стратегия за разрешение за пускане на пазара. Тя оказва влияние върху обхвата на клиничните доказателства, задълбочеността на техническата документация, изискванията за PMS/PMCF и, разбира се, върху въпроса дали и до каква степен трябва да бъде включен нотифициран орган.
Клинични данни: без клинични доказателства няма да се получи
За медицинския софтуер клиничните доказателства не са просто „нещо, което е хубаво да има“. В MDCG 2020-1 изрично се посочва, че медицинският софтуер със собствено предназначение и декларирана клинична полза изисква клинични доказателства като част от оценката на съответствието му. Целта е да се докаже, че софтуерът е безопасен, постига своите експлоатационни характеристики и осигурява декларираната клинична полза.
На практика това означава за софтуера: не е достатъчно просто да се покаже, че алгоритъмът работи от техническа гледна точка. Трябва също така да се оцени дали софтуерът предоставя правилната информация в клиничен контекст, как се използва тази информация и дали тя действително води до доказуема полза. Клиничната оценка не е еднократен документ, а непрекъснат процес.
Клинично проследяване след пускане на пазара (PMCF)
PMCF често се подценява в контекста на софтуера. MDR дефинира PMCF като непрекъснат процес, който актуализира клиничната оценка и трябва да бъде заложен в плана за PMS на производителя. Точно това изрично описва шаблонът на MDCG за PMCF.
PMCF е особено важно за софтуера, тъй като контекстите на употреба, операционните системи, интерфейсите, киберзаплахите и моделите на клинична употреба се променят постоянно. Затова производителите се нуждаят не само от солидна стратегия за разрешение за пускане на пазара, но и от надеждна система за събиране и оценка на данни за реалните експлоатационни характеристики и безопасността след пускането на пазара, както и за използването на тази информация за подобряване на продукта.
Как протича процесът на сертифициране от гледна точка на нотифицирания орган?
Пътят към сертифицирането може да се обобщи в шест ключови стъпки.
Първо: Предвиденото предназначение трябва да бъде точно определено. Това е единственият начин да се установи ясно дали софтуерът попада в обхвата на MDR.
Второ: Софтуерът трябва да бъде правилно класифициран — обикновено въз основа на Приложение VIII и Правило 11.
Трето: Компанията се нуждае от подходяща система за управление на качеството и от проверим, съвременен процес на разработка, обикновено въз основа на ISO 13485, IEC 62304, ISO 14971 и други стандарти в зависимост от продукта.
Четвърто: Техническата документация трябва да бъде пълна, структурирана и проследима — включително верификацията и валидирането на софтуера.
Пето: Клиничната оценка, PMS и PMCF трябва да бъдат структурирани по подходящ за продукта начин.
Шесто: Ако класификацията изисква участието на нотифициран орган, официалната оценка на съответствието се извършва съгласно процедурите, определени в MDR.
