Розробка мобільного застосунку для електронної медичної картки
Ми розробляємо мобільні застосунки для електронних медичних карток (ЕМК), які вирішують фундаментальну суперечність: дані мають бути миттєво доступні лікарю, але при цьому захищені на рівні строгих регуляторних вимог. Завдання — не просто відобразити історію візитів, а забезпечити безпечний доступ до персональних медичних даних з максимальним класом захисту (HIPAA, 152-ФЗ) та UX, який дозволяє відкрити потрібний запис за 10 секунд в умовах кабінету. Спираючись на досвід десятків проєктів у медичній сфері, ми гарантуємо відповідність вимогам юрисдикції та інтеграцію з існуючими MIS. Наше рішення економить до 40% бюджету порівняно з купівлею готової ЕМК.
Регуляторні рамки — фундамент архітектури
Вибір юрисдикції визначає: де хостинг, які шифрування та логування обов'язкові, чи можна використовувати Firebase Analytics, які сповіщення потрібно показувати користувачеві.
- Росія. Наказ МОЗ №947н (структура ЕМД), ФЗ-323 «Про основи охорони здоров'я», ФЗ-152 про персональні дані. Дані — спеціальна категорія ПДн, обробка тільки з явної згоди. Сервер — тільки в РФ.
- Європа. GDPR (особливі категорії даних ст.9), національні імплементації (наприклад, DSGVO в Німеччині). Right to access, right to erasure.
- США. HIPAA: Protected Health Information (PHI), Business Associate Agreement з кожним підрядником, згідно з HIPAA Privacy Rule, audit log для кожного доступу до даних пацієнта.
Як ролі лікаря та пацієнта впливають на архітектуру доступу?
Щонайменше два зовсім різних користувачі:
Пацієнт. Бачить свої дані: анамнез, діагнози, результати аналізів, призначення, алергії. Може показати QR для екстреного доступу (без автентифікації — тільки критичні дані: група крові, алергії, хронічні захворювання). Керує згодами на обробку даних конкретними клініками.
Лікар / медперсонал. Бачить дані пацієнта тільки в рамках активного звернення. Доступ до записів з іншої клініки — тільки якщо пацієнт дав згоду. Кожен перегляд — запис в audit log (WHO accessed WHAT at WHEN).
Audit log — не опціональна фіча при HIPAA, це обов'язкова вимога. Структура запису: userId, resourceType, resourceId, action (view/edit/export), timestamp, ipAddress, deviceId. Зберігається мінімум 6 років (HIPAA) або 3 роки (Росія за 152-ФЗ).
Шифрування та зберігання
Дані ЕМК ніколи не зберігаються у відкритому вигляді на пристрої. Сценарій кешування для офлайн-роботи лікаря:
iOS: Core Data з шифруванням через NSPersistentStoreDescription + NSFileProtectionCompleteUnlessOpen. Ключ шифрування в Secure Enclave з біометричним захистом.
Android: Room + EncryptedSharedPreferences + SQLCipher. Ключ в Android KeyStore з setUserAuthenticationRequired(true).
Передача даних: TLS 1.3 обов'язковий, TLS 1.2 допустимий з обмеженнями. Certificate pinning. Для обміну між організаціями — HL7 FHIR R4 як стандарт інтероперабельності.
Приклад з практики: інтеграція з лабораторною системою
Після аудиту вимог замовника ми спроектували FHIR-модель, що включила ресурси Observation, DiagnosticReport та Specimen. Реалізували REST-клієнт на Flutter з офлайн-кешем. Тестування покрило сценарії: одночасно 200 лікарів, швидкість відповіді < 2 секунд. Проєкт виконано за 2.5 місяці.Типові загрози та їх нейтралізація
| Загроза | Захід захисту |
|---|---|
| Несанкціонований доступ до пристрою | Біометрія + шифрування |
| Перехоплення даних у мережі | TLS 1.3 + certificate pinning |
| Витік через синхронізацію | Локальне шифрування, заборона хмарних бекапів |
| Неавторизований доступ до API | OAuth 2.0 + JWT, rate limiting |
| Реверс-інжиніринг застосунку | ProGuard/R8 (Android), code obfuscation (iOS) |
Чому FHIR R4 — стандарт для інтеграції?
Якщо ЕМК має інтегруватися з іншими MIS, HL7 FHIR R4 — де-факто стандарт. Ресурси: Patient, Observation, Condition, MedicationRequest, DiagnosticReport, Encounter. Наші рішення інтегруються з FHIR у 2 рази швидше типових інтеграцій завдяки досвіду команди.
На мобільному — REST API до FHIR-сервера (HAPI FHIR, Azure Health Data Services, Google Cloud Healthcare API). iOS: немає офіційної FHIR SDK, використовуємо Alamofire + кастомні Codable-моделі. Android: Google's android-fhir SDK (офіційна, підтримує offline sync через FHIR Structured Data Capture).
Приклад запиту спостережень пацієнта:
GET /fhir/Observation?patient=Patient/123&category=vital-signs&_sort=-date&_count=20 Медичні дані в UI
Деякі речі специфічні для медицини:
Норми референсних значень. Результат аналізу «Глюкоза: 7.2 ммоль/л» потрібно показати з контекстом: норма 3.9–6.1, останнє значення 6.8, тренд зростає. Charts/MPAndroidChart для графіків динаміки.
Лікарські взаємодії. Якщо застосунок показує призначення, потрібна перевірка DDI (drug-drug interactions) — через API DrugBank або RxNorm. Це окремий scope.
Екстрений QR. Офлайн-доступний QR без автентифікації, що містить тільки критичні дані в стандарті Smart Health Cards або FHIR Patient Summary. Генерується та кешується при останньому онлайн-сеансі.
Як забезпечити безпеку медичних даних?
- Реалізувати шифрування даних на пристрої (SQLCipher, Core Data з NSFileProtection).
- Використовувати біометричну автентифікацію для доступу.
- Налаштувати certificate pinning та TLS 1.3 для передачі.
- Застосувати ProGuard/R8 на Android та code obfuscation на iOS.
- Організувати remote wipe через MDM при втраті пристрою.
Що входить в роботу
- Аудит регуляторних вимог та узгодження із замовником
- Проєктування архітектури (FHIR-модель, схема доступу, audit log)
- Розробка мобільного застосунку (iOS/Android/cross-platform)
- Реалізація шифрування та безпечного зберігання
- Інтеграція з FHIR-сервером та зовнішніми системами
- QA та penetration testing
- Документація та інструкції для користувачів
- Підтримка при релізі в App Store / Google Play
Які сценарії тестувати окремо?
Сценарій «лікар втратив телефон»: дані пацієнтів на пристрої мають бути знищені через remote wipe (MDM) або недоступні без біометрії після N хвилин неактивності.
Сценарій «пацієнт помер»: що відбувається з доступом довірених осіб? Це не технічне питання — це юридичне, але від нього залежить архітектура згод.
Процес
| Етап | Зміст | Термін |
|---|---|---|
| Аудит вимог | Юрисдикція, ролі, інтеграції (MIS, лабораторії) | 1 тиждень |
| Проєктування | FHIR-ресурси, модель даних, схема доступу, audit log | 1–2 тижні |
| Розробка core | Автентифікація, профіль пацієнта, медкарта, призначення | 4–6 тижнів |
| Шифрування та security | Офлайн-зберігання, SE/StrongBox, certificate pinning | 1–2 тижні |
| Інтеграції | FHIR-сервер, лабораторні системи, push | 2–3 тижні |
| QA + security audit | Penetration testing, перевірка audit log | 1–2 тижні |
Повний MVP — 2–3 місяці. Застосунок з повною FHIR-інтеграцією, підтримкою лікаря та пацієнта, HIPAA-сумісним audit log — ближче до трьох. Терміни та вартість кожного проєкту оцінюються індивідуально після аналізу вимог та обраної юрисдикції. Замовте попередню консультацію для оцінки вашого проєкту. Отримайте фіксований кошторис на основі вимог.