MVP в охороні здоров'я: як швидко запустити проект без

У випадку мінімально життєздатних продуктів для охорони здоров'я ви не маєте вибору, коли ви все ще соромитеся їх випустити на ринок. Незважаючи на те, що швидкість виходу на ринок є дуже важливою в цьому висококонкурентному секторі, безпека, захищеність та відповідність нормативним вимогам продуктів для охорони здоров'я є ще важливішими. Тоді, як би виглядав ідеальний MVP у сфері охорони здоров'я, і як новатори у цій галузі можуть діяти швидко, не економлячи на клінічних або безпекових аспектах? Ми накопичили досвід більш ніж 300 проектів, щоб окреслити, як запустити MVP у сфері охорони здоров'я якомога швидше і не пропустити нічого важливого.

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

Ключові відмінності між стандартними та медичними MVP

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

Коли використовувати кожен підхід

Доказ концепції (PoC) — коли ви перебуваєте на етапі «Чи можна це взагалі безпечно реалізувати?», ваш проект у сфері охорони здоров'я потребує доказу концепції, щоб визначити, чи можна успішно реалізувати вашу технологічну ідею з високим рівнем ризику з технічної точки зору. Зазвичай PoC призначений для внутрішнього використання. Прототип — відповідь на питання «Чи будуть клініцисти та пацієнти правильно використовувати це?» — надати прототип. Прототип — це ілюстрована інтерактивна модель ідеї продукту, яка ілюструє зовнішній вигляд та дії продукту. MVP — першим реальним етапом, який дає відповідь на питання «Чи працює це і чи відповідає вимогам?», є MVP. На відміну від PoC і прототипів, MVP піддаються і можуть пройти реальне тестування в контрольованих умовах.

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

Швидкий прогрес завдяки посібнику з регулювання

У випадку компанії, яка розробляє додаток для використання в клінічній практиці, регуляторні вимоги є досить суворими, що є цілком обґрунтованим. Ці програмні продукти, через їх здатність впливати на результати лікування, спотворювати клінічні рішення і навіть призводити до шкоди здоров'ю, підпадають під дію FDA, EU MDR та інших регуляторних рамок у світі. Медичні норми зазвичай передбачають, що команди розробників повинні мати:

• Організовані процеси (Система управління якістю ISO 13485)
• Записи про дизайн та контроль ризиків (IEC 62304 Життєвий цикл програмного забезпечення та ISO 14971 Управління ризиками)
• Перевірені системи присутні, навіть якщо це лише MVP

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

• Професійні огляди з продуктом
• Тестування зручності використання
• Пілотні програми, затверджені IRB

Не кожна MVP у сфері охорони здоров'я повинна проходити ретельні клінічні випробування, проте всі вони повинні ґрунтуватися на правдоподібних наукових даних, оскільки межа між оздоровленням та медициною є дуже тонкою.

Висока ставка на довіру користувачів

Програмне забезпечення для охорони здоров'я не впроваджується для груп користувачів з високими ставками (пацієнти) та низькими ставками (постачальники медичних послуг), яких програмне забезпечення повинно задовольняти без пошуку альтернативних рішень. Щоб досягти такого рівня довіри під час розробки MVP, команда розробників повинна:

• Спільно з персоналом, який працює на передовій, розробляйте клінічні характеристики для існуючих клінічних шляхів
• Розумійте та базуйте функції на медичних рекомендаціях або доказах
• Створіть UX відповідно до найкращих практик доступності (WCAG, ADA)
• Будьте відверті щодо обмежень програми

Забезпечення безпеки даних та взаємодії

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

• Стандарти даних, включаючи HL7 або FHIR
• Стандартні словники, включаючи SNOMED CT, LOINC або ICD-10

Створення MVP в галузі охорони здоров'я займе в середньому від 2 до 6 місяців. Графік в основному залежить від складності продукту, нормативних вимог та функцій, які були включені в MVP.

Відкриття продукту

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

Планування розвитку

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

• Клінічна необхідність - Що потрібно для гарантування безпеки пацієнтів та зручності використання?
• Регуляторний ризик - Які характеристики можуть призвести до підвищення вимог до дотримання нормативних вимог?
• Бюджет і терміни - Як досягти балансу між обсягом робіт і їхньою реалістичністю?

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

Розробка та тестування MVP

Хоча MVP у сфері охорони здоров'я має унікальні особливості реалізації, етапи проектування та розробки відповідають тим самим моделям гнучкої або ітеративної розробки, що й інші проекти, хоча й вимагають більш суворої організації та вищого рівня документації. У разі, якщо команда створює додатки, призначені для збору клінічних результатів або їх подання до органів влади (FDA/CE Mark), розробники дотримуються стандартів ISO 13485 та IEC 62304. Результати: остаточна система дизайну UI/UX, функціональний MVP, вихідний код і технічна документація, звіти про тестування.

Перевірка та випуск MVP

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

• Пілотні програми з медичними працівниками
• Дослідження, затверджені IRB
• Внутрішнє використання у співпраці з клінічними консультантами
• Середовища Sandbox у поєднанні з тестовими екземплярами EHR або сторонніх систем

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

Приклад розбивки витрат

На основі нашого проекту платформи дистанційного моніторингу пацієнтів, ось детальний розрахунок витрат (орієнтовна вартість 50 доларів за годину):

Якщо ми щось і навчилися за 15 років роботи на ринку, то це те, що проекти розробки програмного забезпечення для охорони здоров'я — це дуже складна справа, яка передбачає безліч змінних.

Почніть з конкретної, правильної проблеми (а не з крутої технології)

Компанії не можуть намагатися перетворити всю турботу в v1 на фліп. Початок з невеликого (наскільки це можливо) сегмента, такого як цифровізація ручного робочого процесу або конкретна клінічна область, що зосереджена на болю, допоможе продукту здобути першу популярність і авторитет. Приклад: Teladoc не починався як комплексна модель віртуального медичного обслуговування. Спочатку продукт був спрощеним рішенням, яке надавало пацієнтам цілодобовий доступ до ліцензованих лікарів у нетермінових випадках.

Інвестуйте в документацію як частину продукту

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

Дизайн з урахуванням нормативних обмежень

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

Ознайомтеся з класифікацією SaMD

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

Недостатньо сказати, що їхня ШІ має точність 99%, потрібно це продемонструвати

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

Швидкість ніколи не буває дешевою в інноваціях у сфері охорони здоров'я

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