Медицинский стартап и первая клиника: что проверить перед пилотом с данными пациентов

К нам обратился основатель медицинского стартапа, который готовил первый пилот с клиникой. Сервис должен был обеспечивать обработку медицинских данных пациентов: хранить результаты компьютерной и магнитно-резонансной томографии — КТ и МРТ — и другие медицинские документы, чтобы пациент мог получить их и предоставить врачу доступ по ссылке.

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

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

Что проверить в договоре medtech-стартапа с клиникой перед пилотом?

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

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

Отдельно нужно было определить объем хранения. КТ и МРТ могут создавать значительную нагрузку на хранилище, а в проекте не было согласованного лимита пилота. Без такого ограничения расходы на инфраструктуру и обещанный клинике объем услуги оставались неопределенными.

Именно эта неопределенность и привела к следующему вопросу — где фактически будут храниться данные и кто будет отвечать за инфраструктуру.

В этом контексте будет полезен материал: Настройка договорной работы: система вместо одного шаблона договора

Можно ли хранить медицинские данные пациентов за границей?

Сначала Клиент рассматривал хранение медицинских данных в Германии, с доступом для пациентов и врачей в Украине. Мы проанализировали этот маршрут и связанные с ним договорные требования. Впоследствии для пилота Клиент выбрал другую модель: привлечь отдельного украинского инфраструктурного подрядчика, а за собой оставить программный сервис и его администрирование.

Сам факт размещения сервера за границей не означает автоматического запрета. Статья 29 Закона Украины “О защите персональных данных” регулирует передачу данных иностранным субъектам, а правовая оценка зависит от участников и всего маршрута доступа. В то же время украинский адрес провайдера еще не подтверждает место хранения основных и резервных копий. Это нужно устанавливать для конкретной заказанной услуги.

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

После этого следующим шагом стала проверка уже не договора с клиникой, а условий самого инфраструктурного провайдера.

Для medtech-продуктов, которые планируют работать с клиниками или пользователями в ЕС, также будет полезен материал: Украинская компания без офиса в ЕС: когда применяется GDPR и что проверить до первого европейского клиента

Нужна профессиональная помощь по этому вопросу?

Оставьте заявку – мы подберем оптимальное решение для вашей ситуации.

Заказать услугу

Что проверить в договоре с облачным провайдером для медицинских данных?

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

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

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

Важно! Документы о безопасности провайдера также оценивают относительно выбранной услуги. Для облачной обработки информации с ограниченным доступом, защита которой предусмотрена законом, постановление Кабинета Министров Украины № 154 от 11 февраля 2025 года устанавливает специальные требования, в частности к документу о соответствии и сроку договора. Наличие сертификата у провайдера не отменяет договорного запрета и не подтверждает автоматически защищенность приложения стартапа.

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

Интересно: Что проверяет Омбудсман у бизнеса относительно персональных данных

Как оформить обработку данных между клиникой и medtech-стартапом?

В рассматриваемой модели клиника определяет цель обработки медицинских данных, а стартап выполняет согласованные операции по ее поручению. Закон называет эти роли владельцем и распорядителем персональных данных. Части 4 и 5 статьи 4 Закона Украины “О защите персональных данных” предусматривают письменный договор и позволяют распорядителю обрабатывать данные только с целью и в объеме, определенных в нем.

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

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

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

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

Как определить сроки хранения и удаления медицинских данных после пилота?

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

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

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

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

Результат: понятная модель пилота и готовые правки к документам

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

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

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

Когда medtech-стартапу стоит проверить модель до запуска пилота?

Подобная проверка будет уместна, если ваш продукт работает с медицинской информацией и вы:

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

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

Для старта достаточно проекта договора с приложениями, условий инфраструктурного подрядчика и описания движения файлов в продукте; если документов еще нет, начать можно с описания задуманной модели.

Готовите medtech-пилот с клиникой? Оставьте электронную заявку на сайте или позвоните по бесплатному номеру телефона.