Обеспечение соответствия FDA:основные стратегии разработки программного обеспечения для стартапов в сфере здравоохранения

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

Данные отрасли являются тревожным звонком. Согласно последним тенденциям подачи заявок FDA 510(k), более 65 % заявок первоначально отклоняются или приостанавливаются из-за отсутствия документации или несоответствия требованиям. Это не крайние случаи; они являются результатом быстро меняющейся команды разработчиков кода без плана регулирования.

Стартапы, которые относятся к соблюдению требований FDA как к чему-то, что нужно «исправить позже», на самом деле замедляются. И наоборот, команды, которые с первого дня внедряют соблюдение требований в процесс разработки, снижают риски, избегают «ловушки повторной работы» и сохраняют темп.

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

Давайте начнем.

Понимание соответствия FDA при разработке программного обеспечения

1. Что на самом деле означает соответствие FDA для программного обеспечения (а не оборудования)

Когда вы думаете о соблюдении требований FDA, возникают два аспекта. Один аспект относится к медицинским устройствам с физическими компонентами, а другой — к программному обеспечению; Соблюдение требований включает в себя и то, и другое, поскольку они влияют на здоровье пациентов.

Есть две широкие категории, и мы рассмотрим их.

• Программное обеспечение как медицинское устройство (SaMD)

В этом контексте под эту категорию подпадает программное обеспечение, способное самостоятельно выполнять медицинские функции, например приложение Apple Watch ECG, которое может обнаруживать фибрилляцию предсердий.

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

• Программное обеспечение в медицинском устройстве (SiMD)

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

Например, прошивка инсулиновой помпы.

FDA фокусируется на трех основных приоритетах:

• Безопасность :Избегает ли программное обеспечение причинения вреда?
• Эффективность :Когда дело доходит до медицинского назначения, надежно ли оно работает?
• Управление рисками :Выявляются ли, уменьшаются ли и отслеживаются ли потенциальные опасности?

2. Основатели часто упускают из виду четыре уровня соответствия

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

Вот четыре области, которые стартапы чаще всего недооценивают.

a) Нормативная классификация (класс I–III)

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

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

Цифровая терапия, определяющая решения о лечении, часто попадает в Класс II. , к которому предъявляются дополнительные нормативные требования.

Полностью автономные диагностические системы искусственного интеллекта высшего класса обычно относятся к классу III. , где FDA уделяет самое пристальное внимание.

Правильная классификация на раннем этапе определяет все последующее.

б) Документация по контролю проектирования

Соответствие требованиям FDA касается не только того, что делает ваше программное обеспечение. Речь также идет о том, чтобы доказать, как он был построен.

Это означает наличие четкой и организованной документации, подтверждающей, что ваш продукт был разработан с использованием контролируемых и проверенных процессов. Это включает в себя документирование каждой функции и этапа разработки, от спецификации требований к программному обеспечению (SRS) до архитектурных диаграмм и записей анализа рисков.

Хорошая документация упрощает демонстрацию соответствия требованиям и делает их менее болезненными во время проверок.

c) Система менеджмента качества (СМК)

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

Например, стартап в области цифрового здравоохранения может внедрить систему управления качеством, соответствующую стандарту ISO 13485, которая включает в себя документированные проверки кода, контролируемые процессы выпуска и журналы аудита для каждого обновления программного обеспечения.

Такая система укрепляет доверие со стороны регулирующих органов и снижает риски по мере ускорения развития.

d) Обязанности после продажи

Обязательства FDA не прекращаются после запуска вашего продукта.

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

Например, диагностическое приложение с искусственным интеллектом может отслеживать ложные срабатывания, выпускать корректирующие обновления при возникновении проблем и отправлять необходимые отчеты через систему отчетности о медицинских устройствах (MDR) FDA. Постоянный надзор – это часть долгосрочного соблюдения требований.

💡 По словам Пита Перанзо, соучредителя Imaginovation Самый глубоко укоренившийся миф стартапов о соблюдении требований FDA заключается в том, что соблюдение требований приходит позже, после разработки.

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

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

Ключевой вывод

Требования FDA к программному обеспечению такие же строгие, как и к традиционным медицинским устройствам, особенно к инструментам диагностики и лечения на основе искусственного интеллекта.

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

Нужно ли вам вообще соответствие требованиям FDA?

Многие новые основатели часто неправильно оценивают, подпадает ли их продукт под надзор FDA.

Это интересное наблюдение:хотя некоторые переоценивают необходимость соблюдения требований и тратят месяцы (и тысячи) на ненужную документацию.

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

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

1. Схема принятия решений

Вот краткий обзор, который поможет вам понять, нужно ли вам соответствие требованиям FDA.

Таблица 1. Какое приложение требует контроля FDA?

Тип приложения Функция Регулируется FDA? Пример Счетчик шагов Отслеживает только шаги ❌ Нет Fitbit (базовый режим отслеживания шагов) Трекер сна Регистрирует закономерности, без диагноза ❌ Нет Oura (только стадии сна) Приложение для ведения журнала симптомов Самостоятельный ввод пользователя, без клинических заявлений ❌ Нет дневника мигрени Отслеживание глюкозы с использованием данных датчиков Измеряет реальные показатели здоровья ✅ Да Приложение Dexcom корректирует дозировку инсулина Предоставляет рекомендации по лечению ✅ Да (высокий риск) Калькулятор дозировки инсулина AI анализатор повреждений кожи Дает диагностические рекомендации ✅ Да (высокий риск) Проверка родинок ИИ

2. Как заранее оценить риск

Чтобы заранее оценить риск FDA, вы можете изучить, что на самом деле делает ваше программное обеспечение.

Тест FDA «Предназначенное использование» основан на функциональных возможностях программного обеспечения в отношении того, как оно измеряет, анализирует или влияет на решения в отношении здоровья.

Если ваше программное обеспечение обрабатывает:

• Физиологические сигналы
• Интерпретирует данные датчиков.
• Вызывает клинические оповещения.
• Предлагает рекомендации по диагностике и лечению.
• Взаимодействует с медицинским устройством.

Скорее всего, он квалифицируется как SaMD и потребует надзора FDA.

Однако если это просто:

• Отслеживает привычки.
• Записывает введенные пользователем данные
• Визуализирует информацию без интерпретации.
• Предлагает общие рекомендации по оздоровлению.

Обычно он остается нерегулируемым.

Иногда лучше всего проконсультироваться со специалистом по нормативным требованиям, прежде чем принимать технические решения, которые могут увеличить риск или могут потребовать доработки требований в дальнейшем.

Консультирование жизненно важно, особенно если программное обеспечение будет:

• Интеграция с медицинскими датчиками.
• Используйте искусственный интеллект и машинное обучение, чтобы определить состояние здоровья.
• Оказание поддержки в принятии клинических решений.
• Проводить терапевтические действия.
• Интерфейс с регулируемыми устройствами или системами EHR

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

Основной вывод

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

Дорожная карта соответствия FDA для стартапов

Шаг 1. Раскрытие информации о нормативных требованиях

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

Затем, основываясь на знаниях классификации, составьте предварительное обоснование классификации, которое поможет понять пути регулирования.

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

Шаг 2. Обеспечьте соответствие требованиям

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

Не забывайте сохранять DHF и матрицы прослеживаемости, даже для MVP. Будет отличной идеей провести проверочные спринты, которые проверят функции на соответствие профилям риска.

Пример:при создании функции дозирования инсулина обеспечьте прослеживаемость от требований до кода и тестов.

Шаг 3. Документация, проверка и отправка

После завершения проектирования настало время подготовить основные результаты для сценариев 510(k), De Novo или PMA. Одновременно с написанием кода вы можете создавать готовую к проверке документацию.

Настало также время сосредоточиться на использовании структурированного досье проекта для аудита и проверки со стороны регулирующих органов.

Пример:досье на проект, содержащее код, тесты, оценку рисков и клиническое обоснование подачи заявки 510(k).

Шаг 4. Постмаркетинговая бдительность

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

Помните, что контроль версий и управление обновлениями являются обязательными. Вы также можете внедрить соответствие требованиям в конвейеры DevOps и CI/CD.

Пример:сбой в приложении для мониторинга сердечного ритма может вызвать событие, о котором необходимо сообщить; конвейеры CI/CD отслеживают версии и исправления.

💡 В этом контексте Пит Перанцо, соучредитель Imaginovation считает, что лучший подход — рассматривать соблюдение требований FDA как легкую основу.

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

Ключевой вывод

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

Цена ошибки

Давайте рассмотрим места, где вы можете допустить ошибку. Раннее обнаружение может помочь обнаружить такие ловушки и упредить их устранение.

Распространенные ловушки регулирования

1. Запускаем «оздоровительное» приложение с диагностическими заявлениями.

Пример:приложение для сна с надписью «отслеживает апноэ во сне» мгновенно попадает на территорию регулирования и вызывает проверку FDA.

2. Игнорирование проектной документации до запуска.

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

3. Использование непроверенных моделей AI/ML.

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

Скрытые волновые эффекты

1. Если основатель стартапа не может объяснить, как его продукт будет регулироваться FDA, инвесторы могут отступить. из-за этой нормативной неопределенности.

Пример:венчурный капиталист задерживает составление списка условий, потому что команда не может четко сформулировать путь регулирования или классификацию.

2. Рассмотрите возможность исключения из магазина приложений. или обязательный отзыв.

Пример:после жалобы потребителя Apple удаляет приложение за «непроверенную медицинскую консультацию», вынуждая его срочно перезапустить.

3. Некоторые основатели могут сжечь взлетно-посадочную полосу, что приведет к потере доверия к бренду.

Пример:модернизация системы отслеживания или переработка алгоритма обеспечения соответствия требованиям требуют 4–6 месяцев разработки, что команды ранних стадий не могут себе позволить.

Быстрые меры профилактики

1. Хорошая идея — проводить аудит соответствия каждый спринт. . Например, даже 10-минутная проверка претензий снижает вероятность случайного отклонения нормативных требований.

2. Еще один аспект, который следует учитывать, — это сохранение «живого» файла управления рисками. . Проще говоря, файл или документ постоянно обновляется.

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

3. Крайне важно раньше участвовать в программах предварительной подачи FDA . Например, короткое предварительное обсуждение может исправить неправильные предположения о классификации или требованиях к данным.

Ключевой вывод

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

Выбор подходящего партнера по развитию, соответствующего требованиям FDA

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

Они редко работают с элементами управления проектированием, DHF, файлами рисков или протоколами проверки. Этот фон неосознанно подталкивает стартапы к скрытой задолженности по соблюдению требований.

Как выглядит настоящий партнер, готовый к соблюдению требований

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

Почему?

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

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

Они также могут запускать безопасные конвейеры DevOps с журналами аудита, поэтому каждая сборка автоматически отслеживается и готова к проверке.

Настороженные сигналы при оценке партнеров

Вот некоторые сценарии, с которыми вы могли столкнуться:

• «О соблюдении требований мы позаботимся позже».
• Нет шаблонов документации, структуры DHF или процессов проверки.
• Отсутствие опыта работы в цифровом здравоохранении или регулируемых отраслях.

Это признаки того, что партнер может быстро предоставить вам MVP, но может стоить вам месяцев редизайна позже.

Как Imagaginovation поддерживает стартапы

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

Их гибкая платформа, основанная на проверке, объединяет элементы управления проектированием, тестированием и документацией в каждом спринте, поэтому стартапы могут быстро выпускаться без каких-либо нормативных отклонений.

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

💡 Недавний пример — их сотрудничество с компанией Everflex. , специализированная платформа здравоохранения, созданная для растущей сети физиотерапии. Основателям нужно было быстро, но безопасно масштабироваться.

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

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

Ключевой вывод

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

Будущее программного обеспечения, соответствующего требованиям FDA

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

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

• Мониторинг производительности как непрерывный процесс, позволяющий отслеживать поведение в реальном мире.
• Определены границы допустимых обновлений модели.
• Четко определенные и понятные процессы управления качеством данных, способные справляться с отклонениями моделей и возникающими рисками.

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

Новый «Заранее определенный план управления изменениями» (PCCP) – что он означает для стартапов

PCCP представляет собой фундаментальный сдвиг в мышлении регулирования. Это позволяет компаниям заранее установить:

• Какие модификации модели они планируют внести?
• Протоколы тестирования и проверки этих изменений.
• Их подход к мониторингу реальной производительности.

Для стартапов тщательно продуманный PCCP становится конкурентным активом.

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

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

Регулирование на основе жизненного цикла требует масштабируемой инфраструктуры соответствия. Новое поколение инструментов автоматизации помогает стартапам управлять:

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

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

Подведение итогов

Соответствие требованиям FDA не является препятствием. Благодаря этому стартапы в области цифрового здравоохранения развиваются быстрее и уверенно масштабируются.

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

Imaginovation помогает стартапам в области цифрового здравоохранения и благополучия создавать программное обеспечение, соответствующее требованиям FDA, с нуля, от архитектурных решений до подачи нормативных документов. Мы поддерживаем команды в сложных областях, включая стратегии PCCP, выдерживающие тщательную проверку.

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