Медичний стартап і перша клініка: що перевірити перед пілотом із даними пацієнтів

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

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

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

Що перевірити в договорі medtech-стартапу з клінікою перед пілотом?

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

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

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

Саме ця невизначеність і привела до наступного питання — де фактично зберігатимуться дані та хто відповідатиме за інфраструктуру.

У цьому контексті буде корисним матеріал: Налаштування договірної роботи: система замість одного шаблону договору

Чи можна зберігати медичні дані пацієнтів за кордоном?

Спочатку Клієнт розглядав зберігання медичних даних у Німеччині, з доступом для пацієнтів і лікарів в Україні. Ми проаналізували цей маршрут та пов’язані з ним договірні вимоги. Згодом для пілоту Клієнт обрав іншу модель: залучити окремого українського інфраструктурного підрядника, а за собою залишити програмний сервіс і його адміністрування.

Сам факт розміщення сервера за кордоном не означає автоматичної заборони. Стаття 29 Закону України “Про захист персональних даних” регулює передачу даних іноземним суб’єктам, а правова оцінка залежить від учасників і всього маршруту доступу. Водночас українська адреса провайдера ще не підтверджує місце зберігання основних і резервних копій. Це потрібно встановлювати для конкретної замовленої послуги.

У нашому кейсі після зміни моделі довелося повторно зіставити пакет клініки з умовами нового підрядника. Вибір української інфраструктури спростив задуманий маршрут, але залишив питання до дозволених даних, доступу персоналу, резервування та завершення обробки.

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

Для medtech-продуктів, які планують працювати з клініками або користувачами в ЄС, також буде корисним матеріал: Українська компанія без офісу в ЄС: коли застосовується GDPR і що перевірити до першого європейського клієнта

Потрібна професійна допомога з цим питанням?

Залишіть заявку – ми підберемо оптимальне рішення для вашої ситуації.

Замовити послугу

Що перевірити в договорі з хмарним провайдером для медичних даних?

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

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

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

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

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

Цікаво: Що перевіряє Омбудсман у бізнесу щодо персональних даних 

Як оформити обробку даних між клінікою та medtech-стартапом?

У розглянутій моделі клініка визначає мету обробки медичних даних, а стартап виконує погоджені операції за її дорученням. Закон називає ці ролі володільцем та розпорядником персональних даних. Частини 4 і 5 статті 4 Закону України “Про захист персональних даних” передбачають письмовий договір і дозволяють розпоряднику обробляти дані лише з метою та в обсязі, визначених у ньому.

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

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

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

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

Як визначити строки зберігання та видалення медичних даних після пілоту?

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

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

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

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

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

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

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

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

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

Схожа перевірка буде доречною, якщо ваш продукт працює з медичною інформацією і ви:

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

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

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

Готуєте medtech-пілот із клінікою? Залиште електронну заявку на сайті або зателефонуйте за безоплатним номером телефону.