L-Doc - МІС для лікарів інтегрована з додатком пацієнта

Літа-доктор - це кабінет сімейного лікаря та онколога, який дозволяє вести профілактику пацієнтів (поки що тільки за схемами ВООЗ тестів онкології, але в майбутньому будуть впроваджені й інші). Ця система є продовженням додатку і третім продуктом компанії ТОВ Літа Хелз. Старт цього софту був даний на хакатоні від Гарварда у квітні 2024 року.

Як ми зібрали medical MVP за 3 дні на хакатоні Harvard

Це був не просто хакатон з невеликим недосипом =). Це був Harvard Health Systems Innovation Lab Hackathon 2024 — міжнародна healthtech-подія, де команди за лічені дні мали придумати, спроєктувати, зібрати і захистити новий продукт для медицини.

Наша команда пішла в трек онкології і за 3 дні зібрала не просто красиву ідею, а робочий вертикальний зріз продукту (тобто не макет заради макета, а живий шматок системи від інтерфейсу до логіки й даних). Ми встигли пройти продуктологію, аналітику, медичну доменну експертизу, UX/UI-дизайн, фронтенд, бекенд, базу даних, інфраструктуру і пакування проєкту в презентацію та англійський пітч. Для хакатону це вже не sprint, а маленька хірургічна операція над хаосом =).

Сам хакатон був справді масштабним. Глобально він проходив як частина ініціативи Harvard HSIL, а український хаб працював у Києві разом з міжнародною програмою. У залі були медики, founders, розробники, дослідники, ментори, представники health-середовища і люди, які вміють ставити дуже неприємні, але дуже корисні запитання. І це прекрасно: саме так хороші ідеї перестають бути милими фантазіями і починають бути схожими на продукт.

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

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

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

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

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

Нижче — кілька відео з хакатону і живої атмосфери події.

Що саме ми зробили

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

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

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

Як працює кабінет лікаря

Лікар на своєму робочому місці бачить список пацієнтів — але тільки тих, які самі передали йому доступ через додаток. Це важливий момент: ми одразу будували систему не за принципом лікар бачить усе, тому що він лікар, а за принципом consent-based access (доступ за дозволом пацієнта). Для медицини це не декоративна фіча, а фундамент довіри і юридичної акуратності.

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

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

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

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

Для кожного тесту лікар бачить зліва запитання і відповіді пацієнта. Самі тести побудовані на основі медичних алгоритмів і логічних гілок — по суті це rule engine (движок правил, який вибирає наступне запитання і підсумкові висновки за набором умов). Такі схеми легко виглядають простими ззовні і напрочуд підступними всередині: одна відповідь змінює не тільки поточний екран, а й усю логіку наступного маршруту користувача.

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

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

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

Вхід без зайвого болю

У кабінет лікаря можна увійти класичним способом через логін і пароль, а можна через Google або Facebook. Це вже стандартний OAuth-вхід (механізм, коли частину перевірки особи бере на себе зовнішній провайдер), який знижує тертя при авторизації і зменшує кількість покинутих входів.

Як пацієнт додає лікаря

Зв'язка між пацієнтським застосунком і кабінетом лікаря реалізована через розділ Додати лікаря. Пацієнт вводить ідентифікатор лікаря і самостійно вирішує, кому саме відкрити доступ. Це той випадок, коли UX напряму обслуговує privacy-by-design (підхід, за якого приватність вбудовується в продукт із самого початку, а не прикручується потім на скотч).

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

Як пацієнт бачить свої результати

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

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

Що показує цей кейс

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

Саме тому судді й відреагували на наш пітч як на щось надто доросле для звичайного хакатону. Коли команда вміє поєднувати доменну експертизу, системний аналіз і software architecture (архітектуру ПЗ — тобто заздалегідь продуману конструкцію системи, а не хаотичний набір екранів і таблиць), результат починає виглядати як бізнес, а не як студентська самодіяльність.

А якщо у вас уже є ідея медичного продукту, кабінету лікаря, patient app, MIS, B2B-платформи для клінік або складного healthtech-сервісу, подивіться наш підхід до проєктування і запуску таких систем. Там є про компанію, принципи роботи, етапи, відгуки і можливість залишити заявку на безкоштовну консультацію. Без магії, зате з аналітикою, архітектурою і дорослими питаннями на старті =).