Мобільний додаток для стоматології: запис, карта лікування, лояльність
Клініки втрачають до 30% пацієнтів через складний запис і відсутність нагадувань. Впровадження мобільного додатку вирішує цю проблему: онлайн-запис із синхронізацією МІС, push-повідомлення за 24 та 2 години, що знижують неявку на 40%. Згідно з дослідженням Journal of Medical Internet Research, такі нагадування скорочують кількість пропусків на 40% і економлять клінікам до 2 млн ₽ на рік. Але розробка медичного додатку — не просто черговий інтерфейс: потрібна обробка персональних даних (152-ФЗ), інтеграція з DICOM-знімками та сертифікація для App Store (Section 4.2/5.1). Наш досвід — 5+ років, понад 20 реалізованих проєктів для клінік різного масштабу.
Типові проблеми, які ми вирішуємо
Типова ситуація: пацієнт телефонує в клініку, адміністратор шукає вільний час, передзвонює. У підсумку 30% не записуються. Наш додаток з онлайн-записом і синхронізацією МІС автоматизує цей процес — пацієнт обирає лікаря та час, отримує нагадування. Щоб це працювало коректно, необхідна глибока інтеграція з МІС, обробка push-повідомлень (APNs/FCM) та налаштування deep linking (Universal Links / App Links) для повернення в додаток.
Як ми вирішуємо проблему інтеграції з МІС?
Інтеграція з медичною інформаційною системою (МІС) — ключовий етап. В українських та російських клініках популярні Dental4Windows, 1С:Стоматологія, Medesk, CleverMed. У кожної МІС свій API або обмежений набір методів. Якщо прямої інтеграції немає, ми розробляємо власний слот-менеджер: адміністратор вручну вивантажує розклад, а додаток парсить експорт (CSV/XML) і синхронізується через webhook. Для надійності використовуємо чергу задач (RabbitMQ) і фонові задачі (WorkManager на Android, Background Tasks на iOS). Push-повідомлення надсилаються через Firebase Cloud Messaging (FCM) та Apple Push Notification service (APNs) з використанням дата-повідомлень для пріоритетної доставки.
Карта лікування та знімки
Інтерактивна схема зубів (зубна формула ВОЗ 2-значна або Віола) — реалізується через SVG на Canvas API або кастомний CustomPainter у Flutter. Прикріплення фотографій та рентгенівських знімків — файли зберігаються на сервері, у додатку — viewer з zoom (InteractiveViewer у Flutter, react-native-image-zoom-viewer у RN). Передача DICOM-знімків: якщо клініка використовує цифровий рентген, розглядаємо легкий DICOM viewer або конвертацію в JPEG на сервері. Для економії трафіку та місця стискаємо зображення (JPEG 80% якості) і кешуємо їх локально.
Програма лояльності та бонуси
Бонусні бали за візити, реферальна програма — проста логіка, але вимагає синхронізації з касовою системою (наприклад, АТОЛ). Ми реалізуємо REST API для нарахування/списання балів, а також інтеграцію з push-повідомленнями для інформування про нові бонуси.
Flutter чи React Native: як обрати?
| Критерій | Flutter | React Native |
|---|---|---|
| Продуктивність анімацій | Відмінна (SKIA) | Хороша, але залежить від мосту |
| Кастомні UI-компоненти | Легко (CustomPainter) | Складніше (нативні модулі) |
| Інтеграція з нативними бібліотеками | Через плагіни | Прямий доступ до нативних API |
| Розмір додатку | Більший (близько 10 МБ) | Менший (близько 5 МБ) |
| Спільнота та вакансії | Активно зростає | Велика, багато спеціалістів |
Для стоматології, де потрібен кастомний UI (схема зубів, анімації), Flutter дає перевагу в швидкості розробки та продуктивності. Flutter перевершує React Native за продуктивністю анімацій у 2 рази і скорочує час розробки на 20%. React Native підійде, якщо в клініці вже є нативні модулі або команда знайома з JavaScript. У наших проєктах ми частіше використовуємо Flutter, але вибір завжди за замовником.
Чому безпека даних — пріоритет?
Безпека даних — особлива категорія персональних даних (152-ФЗ у Росії, GDPR у Європі). Мінімальні вимоги: шифрування на рівні транспорту (TLS 1.2+), зберігання на українських/російських серверах (якщо проєкт під РФ), згода на обробку при реєстрації, можливість видалення акаунта та даних. Ми також допомагаємо з сертифікацією та документацією. Для Android налаштування ProGuard / R8 критичне — неправильна конфігурація вирізає класи, необхідні для Hilt DI або Room. На iOS використовуємо App Store Review Guidelines Section 5.1 для обробки даних здоров'я. При налаштуванні ProGuard / R8 важливо зберегти класи, які використовуються Hilt або Room. Додайте в proguard-rules.pro рядки:
-keep class * extends androidx.room.RoomDatabase -keep @dagger.hilt.* class * Інакше після shrink-режиму додаток впаде при запуску.
Етапи та терміни розробки
| Етап | Тривалість | Результат |
|---|---|---|
| Аналітика та проектування | 1–2 тижні | Прототип, user flow, ТЗ |
| Розробка функціоналу | 4–6 тижнів | Робочий прототип з онлайн-записом |
| Інтеграція з МІС | 2–4 тижні | Синхронізовані дані |
| Тестування та налагодження | 1–2 тижні | QA, unit-тести, UI-тести |
| Публікація в сторах | 1–2 тижні | Розміщення в App Store та Google Play |
Базовий додаток з онлайн-записом — від 8 до 12 тижнів. Повноцінний кабінет з картою лікування та знімками — від 4 до 6 місяців. Вартість розраховується індивідуально, але ми готові оцінити ваш проєкт за один день.
Що входить у роботу?
- Документація: ТЗ, user flow, API-специфікація.
- Вихідний код з коментарями та README.
- Навчання адміністраторів роботі з панеллю керування.
- Технічна підтримка протягом 3 місяців після запуску.
- Допомога з публікацією в сторах та сертифікацією.
Типові помилки та як їх уникнути
- Ігнорування вимог App Store Review (Section 4.2 / 5.1): медичні додатки потребують підтвердження від Apple. Ми заздалегідь готуємо документацію.
- Відсутність offline-режиму: пацієнти можуть не мати інтернету в клініці. Реалізуємо кешування даних та фонову синхронізацію.
- Неправильне налаштування ProGuard / R8 на Android: вирізаються потрібні класи для DI. Використовуємо keep-правила та перевіряємо shrink-режим.
Отримайте консультацію — ми проаналізуємо ваші процеси та запропонуємо оптимальне рішення. Зв'яжіться з нами для оцінки проєкту.