Тільки нещодавно індустрія медичного обладнання ініціювала розробку програмних продуктів, повністю незалежних від апаратних пристроїв. Програмне забезпечення як медичний виріб (ПЗМВ), хоча й суттєво відрізняється від традиційних медичних пристроїв, має не менші перспективи у підвищенні якості життя пацієнтів у всьому світі. У сфері медичних пристроїв спостерігається значний сплеск інновацій. Поява Інтернету речей (IoT) у поєднанні з досягненнями в галузі хмарних обчислень і штучного інтелекту значно прискорила цей процес.

Знаменно, що ринок програмного забезпечення як медичного виробу (SaMD) готовий до значного зростання, яке, за прогнозами, досягне $86 451,62 млн. до 2027 року.

Прикметно, що регуляторні органи в усьому світі все ще класифікують ПМД як медичні вироби. У цьому посібнику ми розсекретимо ці пристрої та надамо вам цінну інформацію про їхнє регулювання, а також про те, що ви можете очікувати, коли ви починаєте шлях до створення такого пристрою.

Визначення програмного забезпечення як медичного виробу (SaMD)

Перш ніж розпочати розробку програмного забезпечення як медичного виробу (ПЗМВ), необхідно забезпечити повну ясність щодо того, чи дійсно медичний виріб, який ви створюєте або плануєте створити, кваліфікується як ПЗМВ. Міжнародний форум регуляторів медичних виробів (IMDRF), глобальний консорціум регуляторних органів, орієнтований на гармонізацію правил для медичних виробів, включаючи SaMD, надає нам точне визначення SaMD:

Термін "Програмне забезпечення як медичний виріб" (ПЗМВ) визначається як програмне забезпечення, призначене для однієї або декількох медичних цілей, здатне досягати цих цілей, не будучи частиною апаратного медичного виробу.

По суті, існує дві основні категорії програмного забезпечення для медичних виробів:

  • Програмне забезпечення як медичний виріб (SaMD):

    У цьому випадку програмне забезпечення функціонує як компонент більшого медичного пристрою.

  • Програмне забезпечення в медичному пристрої (SiMD):
  • Тут програмне забезпечення працює як компонент більшого медичного пристрою.

Хоча існують додаткові категорії програмного забезпечення для медичних виробів, такі як допоміжні продукти для медичних виробів, ми не будемо заглиблюватися в ці конкретні типи в даному контексті.

Ключові переваги рішень SaMD

Рішення SaMD мають дві фундаментальні переваги, які заслуговують на визнання:

  • Використання даних для покращення здоров'я пацієнтів

  • Рішення SaMD революціонізують збір даних, перевершуючи ефективність і швидкість традиційних методів покращення здоров'я. Крім того, оскільки ці рішення дотримуються суворих правил, якість зібраних даних є незмінно високою. Таким чином, SaMD дають можливість сектору охорони здоров'я розробляти рішення, орієнтовані на пацієнта, здатні значно покращити його самопочуття.

  • Універсальне розгортання програмного забезпечення на апаратному забезпеченні

  • SaMD переважно існують у хмарі, що дає суттєві переваги з точки зору швидкості та універсальності. Це стосується не лише розробки таких рішень, але й їх оновлення та адаптивності. Використовуючи передові технології, підключені медичні пристрої можна створювати, будувати та підтримувати з більшою легкістю порівняно з традиційними апаратними рішеннями для покращення здоров'я.

Ivanna

Іванна

Менеджер по роботі з клієнтами

Зв'яжіться з нами, і ми поділимося нашими кейсами, пов'язаними з розробкою програмного забезпечення для охорони здоров'я

Безкоштовна консультація

Ключові елементи SaMD

Майже в кожному рішенні SaMD присутні чотири основні елементи:

  1. Вхідні дані SaMD

  2. До них відносяться вхідні дані, необхідні для ефективної роботи SaMD. Вхідні дані можуть включати дані про пацієнта, результати лабораторних досліджень, дані зображень, фізіологічні стани, симптоми тощо.

  3. Алгоритм SaMD

    В основі кожного SaMD алгоритм відіграє ключову роль. У ньому часто міститься інтелектуальна власність (ІВ) рішення, що містить набір інструкцій і логіку, необхідну для того, щоб СППР виконувала своє завдання, генеруючи результати, пов'язані з медициною.

  4. Результати SaMD
  5. Після введення вхідних даних в СППР і обробки алгоритмом генеруються різні вихідні дані. Ці результати інформують, направляють, діагностують або лікують користувача SaMD.

  6. Клінічна оцінка
  7. Результати САМД проходять клінічну оцінку, що є складним і критичним етапом для кожної САМД. Для отримання детальної інформації про те, як успішно пройти цей етап, зверніться до нашого поглибленого блогу.

    Категоризація рішень SaMD

    Категоризація рішень SaMD відрізняється на регульованих ринках Європейського Союзу (ЄС) та Сполучених Штатів Америки (США).

    Категоризація SaMD (MDSW) в ЄС

    В ЄС офіційно використовується термін "програмне забезпечення для медичних виробів" або "ПЗМВ". Регламент ЄС щодо медичних виробів (MDR) визначає чотири класи: I, IIa, IIb і III, що значною мірою збігається з класифікацією, встановленою Міжнародним форумом регуляторних органів з медичних виробів (IMDRF). Ці класи визначаються на основі цільового призначення медичного виробу та пов'язаних з ним ризиків.

    Оцінка ризиків в ЄС базується на гармонізованому стандарті ISO 62304. Для запуску SaMD в ЄС необхідно отримати сертифікат відповідності цього стандарту від нотифікованого випробувального органу.

    Категоризація SaMD в США

    У США Управління з контролю за продуктами і ліками (FDA) визначає класи SaMD на основі контролю впливу та функціональності, необхідних для встановлення безпеки та ефективності. FDA класифікує SaMD за трьома категоріями: Клас I, Клас II та Клас III. Класифікація ризиків програмного забезпечення як медичного виробу FDA також ґрунтується на стандарті ISO 62304, хоча і з деякою відмінною термінологією.

    Як визначити, чи належить ваш продукт до категорії SaMD

    І FDA в документі "Програмне забезпечення як медичний виріб", і IMDRF надають визначення, які демонструють структурну схожість. Згідно з обома наборами визначень, програмне забезпечення має відповідати двом ключовим критеріям, щоб бути віднесеним до категорії SaMD.

    Перш за все, необхідно з'ясувати, чи можна взагалі класифікувати програмне забезпечення як медичний виріб. IMDRF стверджує, що воно повинно бути "призначене для однієї або декількох медичних цілей", тоді як FDA конкретно посилається на визначення пристрою в розділі 201(h) Закону FD&C, де зазначено, що пристрій є таким:

    Інструмент, апарат, знаряддя, машина, винахід, імплантат, реагент in vitro або інший подібний або пов'язаний з ним виріб, включаючи частину або аксесуар, який є:

    • Визнаний в офіційному Національному формулярі, Фармакопеї США або будь-якому доповненні до них.
    • Призначений для використання в діагностиці захворювань або інших станів, а також для лікування, пом'якшення, лікування або профілактики захворювань у людей або інших тварин.
    • Призначені для впливу на структуру або будь-яку функцію організму людини або інших тварин і не досягають своїх первинних цілей шляхом хімічної дії в організмі або на організм людини або інших тварин.
    • Не залежить від метаболізму для досягнення своїх первинних цілей.
    .

    Важливо правильно визначити цільове призначення та показання до застосування вашого продукту, використовуючи ці критерії:

    • Призначення - це призначення вашого пристрою, яке пояснює, для чого він буде використовуватися.
    • Призначення для використання описують захворювання або стани, які ваш пристрій діагностуватиме, лікуватиме, запобігатиме, виліковуватиме або пом'якшуватиме. Вони вказують, для кого і чому буде використовуватися ваш пристрій.
    .

    Після того, як ви з'ясували ці призначення, другий і третій пункти у визначенні SaMD, наданому FDA, допоможуть вам визначити, чи підпадає ваш виріб під регулювання щодо медичних виробів.

    Якщо ви плануєте продавати свій програмний продукт у США, ми наполегливо рекомендуємо уважно ознайомитися з настановою FDA "Політика щодо функцій програмного забезпечення пристроїв і мобільних медичних додатків". Це керівництво містить чіткі вказівки щодо функцій програмного забезпечення, які FDA вважає SaMD, тих, які не вважаються медичними пристроями, і тих, які вона не регулює як такі.

    Однак, якщо у вас все ще є сумніви щодо того, чи є ваш продукт медичним виробом, рекомендується звернутися безпосередньо до FDA для отримання подальших роз'яснень.

    Чи вважається ваше програмне забезпечення SaMD або SiMD?

    Після того, як ви встановили, що ваш продукт відповідає визначенню медичного виробу, дуже важливо заглибитися у другу частину визначень SaMD, наданих IMDRF та FDA.

    У визначенні IMDRF зазначено, що програмне забезпечення повинно виконувати свої функції, "не будучи частиною апаратного медичного виробу".

    Так само, за визначенням FDA SaMD "призначене для використання в одній або кількох медичних цілях, не будучи частиною апаратного пристрою".

    Ця відмінність значно звужує сферу застосування SaMD. Програмне забезпечення, призначене для роботи або керування апаратним медичним пристроєм, не відповідає критеріям SaMD. Натомість таке програмне забезпечення підпадає під класифікацію SiMD, або "програмне забезпечення в медичному пристрої".

    Простіше кажучи, будь-яке програмне забезпечення, яке сприяє функціонуванню апаратного медичного виробу, контролюючи його механічні аспекти або створюючи графічний інтерфейс, класифікується як програмне забезпечення в медичному виробі. Деякі приклади охоплюють:

    • Програмне забезпечення, що керує накачуванням або здуванням манжети для вимірювання артеріального тиску.
    • Програмне забезпечення, що керує механізмом подачі інсуліну в інсуліновій помпі.
    • Програмне забезпечення, що бере участь у замкненому контурі управління кардіостимулятором.

    Ці типи програмного забезпечення іноді називають "вбудованим програмним забезпеченням", "мікропрограмою" або "мікрокодом". Якщо ви зустрінете ці терміни, зрозумійте, що вони стосуються SiMD, а не SaMD.

    Щоб класифікувати продукт як SaMD, програмне забезпечення повинно працювати незалежно від апаратного забезпечення, виконуючи функції, які визначають його як медичний виріб. Настанова IMDRF щодо "Можливих рамок для категоризації ризиків та відповідних міркувань" пропонує додаткові роз'яснення щодо визначення SaMD:

    • SaMD кваліфікується як медичний виріб і включає медичні вироби для діагностики in vitro (IVD).
    • Він може працювати на обчислювальних платформах загального призначення (немедичних).
    • "Не входить до складу" означає програмне забезпечення, яке не є необхідним для того, щоб апаратний медичний виріб виконував своє медичне призначення.
    • Програмне забезпечення, призначене для управління апаратним медичним виробом, не підпадає під визначення SaMD.
    • SaMD можна використовувати в поєднанні з іншими продуктами, зокрема медичними виробами.
    • Він може взаємодіяти з різними медичними пристроями, включно з апаратними медичними пристроями, іншим програмним забезпеченням SaMD та програмним забезпеченням загального призначення.
    • Мобільні додатки, що відповідають вищезгаданим критеріям, класифікуються як SaMD.

    Примітка: Хоча розрізнення між SaMD і SiMD є важливим, обидва типи програмного забезпечення дотримуються багатьох однакових стандартів розробки, таких як IEC 62304, міжнародний стандарт, що регулює процеси життєвого циклу програмного забезпечення. Навіть якщо ваше програмне забезпечення відноситься до SiMD, у цьому посібнику ви знайдете численні керівні документи та стандарти, які залишаються актуальними та корисними.

    Регулювання SaMD (Програмне забезпечення як медичний виріб) у світі

    Глобальне регулювання SaMD відрізняється залежно від ринку, але основна увага приділяється США та ЄС як основним гравцям на ринку медичних виробів.

    SaMD класифікується як медичний виріб, що вимагає дотримання нормативних вимог. У США відповідність вимогам забезпечується Положенням про систему якості FDA (QSR), яке містить спеціальні вказівки щодо ПМД, особливо під час реєстрації на ринку. Існує два ключових керівних документи FDA. Один з них, виданий у 2005 році, класифікує SaMD на незначний, помірний і серйозний рівні занепокоєння, що впливає на вимоги до документації. У проєкті настанови від 2021 року цей поділ спрощено до базової та розширеної документації, хоча остаточна редакція настанови залишається невизначеною. До завершення роботи над новими настановами доцільно вказувати як рівень занепокоєння, так і тип документації.

    В ЄС SaMD регулюється подібно до традиційних медичних виробів відповідно до Регламенту ЄС щодо медичних виробів (MDR) або Регламенту щодо діагностики in vitro (IVDR) для пристроїв для діагностики in vitro. ЄС називає його "програмним забезпеченням для медичних виробів" або MDSW. Європейська Комісія пропонує різні керівні документи, що стосуються SaMD, включаючи класифікацію, клінічну оцінку, кібербезпеку, а також кваліфікацію та класифікацію програмного забезпечення.

    Розуміння цих нормативних актів США та ЄС є важливим для виробників ПЗ для забезпечення глобальної відповідності та доступу до ринку.

    Класифікація безпеки програмного забезпечення згідно з IEC 62304

    IEC 62304, міжнародний стандарт, що регулює процеси життєвого циклу програмного забезпечення, надає систему класифікації безпеки програмного забезпечення.

    Система класифікації IEC 62304 складається з трьох рівнів, кожен з яких визначається серйозністю шкоди, що може бути заподіяна в результаті збою програмного забезпечення:

    • Клас A - відсутність травм
    • Клас B - несерйозна травма
    • Клас С - Серйозна травма або смерть

    Вкрай важливо розуміти, що класифікація безпеки програмного забезпечення не оцінює внутрішню безпеку вашого програмного забезпечення. Натомість вона слугує основою для визначення рівня ретельності, необхідного для процесів розробки програмного забезпечення.

    Фактична безпека вашого пристрою залежить від ефективності процесів проектування та розробки, а не лише від його класифікації безпеки. Тому класифікація безпеки допомагає визначити необхідні процедури та запобіжні заходи під час розробки.

    Важливо відзначити, що ваша класифікація безпеки за стандартом IEC 62304 не має прямої відповідності один до одного з класифікацією ризиків згідно з нормативними документами США або ЄС. Однак вона тісно пов'язана з класом ризику, що є важливим фактором, який слід враховувати при орієнтації на нормативні вимоги.

    Наприклад, якщо ваша класифікація безпеки відповідає класу C, існує висока ймовірність того, що ваш пристрій потрапить до класу III (за нормативними документами США або ЄС). Тим не менш, можливі ситуації, коли пристрій має клас безпеки C, але потрапляє до класу з нижчим рівнем ризику.

    Підсумовуючи, можна сказати, що система класифікації IEC 62304 насамперед стосується міркувань безпеки під час розробки програмного забезпечення. Хоча вона надає цінні вказівки щодо ретельності розробки, вона не є абсолютним показником класифікації ризиків і не відображає безпосередньо загальну безпеку завершеного продукту SaMD.

    Наш досвід


    HospApp

    Наш клієнт прагнув розробити нову мобільну систему, призначену для полегшення безперешкодної комунікації між усіма працівниками в групах, пов'язаних з конкретними пацієнтами. Ця система уможливила індивідуалізоване спілкування, обмін файлами, управління рецептами та виконання завдань для пацієнтів у відповідних групах. При цьому особлива увага приділялася максимальній безпеці інформації про пацієнтів, що гарантувало її збереження в межах лікарні.

    Для задоволення потреб ми розробили демонстраційний додаток для Android з ключовими функціями для персоналу лікарні. Команда Stfalcon надала комплексні послуги, включаючи дизайн інтерфейсу користувача, розробку Android, ручне тестування, забезпечення якості та успішне впровадження.

    Читати кейс

    IsDocIn

    Мета проекту полягала в розробці мобільного додатку, який спрощує процес планування зустрічей з медичними працівниками. Лікарі отримали можливість створювати профілі та отримувати сповіщення, коли пацієнти записуються до них на прийом.

    Читати кейс

    Включаючи наш внесок у цей проект:

    • Створення інтуїтивно зрозумілого користувацького інтерфейсу (UI) для мобільного додатку, призначеного для використання пацієнтами.
    • Розробка версій додатку, адаптованих для платформ iOS та Android.
    • Розробка нативних додатків для iOS та Android, дотримуючись специфікацій дизайну.

    Підсумок

    Сфера програмного забезпечення як медичного виробу (ПЗМВ) є складною та постійно розвивається.

    У сфері SaMD залишаються сфери невизначеності в нормативних документах і настановах, які потребуватимуть уваги в найближчі роки. Постійні виклики, такі як кібербезпека, вимагають постійних зусиль. Крім того, перехід розробників програмного забезпечення у сферу медичних виробів і навпаки - це крута крива навчання.

    Однак дуже важливо визнати, що ця сфера пропонує безліч можливостей і цікавинок. Оснащена відповідними інструментами та експертним керівництвом, команда Stfalcon може створювати першокласні рішення SaMD, які покращують життя незліченної кількості пацієнтів. Якщо ви зацікавлені в розвитку проекту SaMD, зв'яжіться з нами, ми надамо вам безкоштовну консультацію.