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, команде разработчиков нужно:

• Работайте вместе с сотрудниками на передовой, чтобы сопоставить клинические особенности с существующими клиническими протоколами
• Понимайте и основывайте функции на медицинских рекомендациях или доказательствах
• Создавайте пользовательский интерфейс в соответствии с лучшими практиками доступности (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
• Внутреннее использование в сотрудничестве с клиническими консультантами
• Используй тестовые среды с пробными версиями электронных медицинских карт или систем других компаний.

Цены на разработку MVP на рынке здравоохранения зависят от проекта и особенностей приложения, процесса регулирования и технологий. Поэтому мы всегда советуем получить бесплатную оценку от компании-разработчика, чтобы заранее составить реалистичное представление о сумме.

Пример распределения затрат

Исходя из нашего проекта по платформе удаленного мониторинга пациентов, вот подробная разбивка затрат (оценка 50 долларов в час):

Если мы что-то и поняли за 15 лет на рынке, так это то, что проекты по разработке программного обеспечения для здравоохранения — это очень сложная история, в которой много разных факторов.

Начинайте с конкретной, актуальной проблемы (а не с крутых технологий)

Компании не должны пытаться сразу все изменить в версии 1. Начните с чего-то небольшого (насколько это возможно), например, с оцифровки ручного рабочего процесса или конкретной области клинической боли, это поможет продукту завоевать первую популярность и доверие. Пример: Teladoc не начинал как полноценная виртуальная медицинская модель. Сначала это было простое решение, которое давало пациентам круглосуточный доступ к лицензированным врачам в неэкстренных случаях.

Вкладывай в документацию как часть продукта

Хотя компании, которые собираются работать по правилам, часто уже все это имеют, те, кто разрабатывают сначала нерегулируемое решение, часто пропускают этот шаг.

Дизайн с учетом нормативных ограничений

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

Знайте свою классификацию SaMD

Если ваше решение для здравоохранения имеет одно или несколько медицинских применений, которые осуществляются без использования аппаратного медицинского оборудования, оно, скорее всего, подпадает под категорию Программное обеспечение как медицинское устройство.

Недостаточно просто сказать, что их ИИ точен на 99%, нужно это доказать

В сфере здравоохранения компания не может просто так заявлять, что её алгоритмы самые лучшие. Регулирующие органы, такие как FDA (и врачи, кстати), хотят конкретных, реальных доказательств того, что ваш инструмент выполняет обещания.

Скорость никогда не бывает дешевой в инновациях в здравоохранении

Не стоит слишком увлекаться быстрым созданием важных функций, если это вредит безопасности, соответствию требованиям и доверию пользователей. MVP в здравоохранении не значит создать самый маленький продукт. Речь идет о том, чтобы сделать самую безопасную версию вашей идеи, которая все равно будет иметь влияние на реальный мир. Если с самого начала думать о нормах, параллельно проводить клинические испытания и делать структуру модульной, чтобы потом можно было расширяться, то можно быстрее выйти на рынок — и не придется что-то урезать, что потом может аукнуться.