Разработка мобильного приложения для электронной медицинской карты
ЭМК на мобильном — это не просто «показать историю визитов». Это персональные медицинские данные, максимальный класс защиты по большинству законодательств, строгие требования к доступу, и при этом UX, при котором врач должен открыть нужную запись за 10 секунд в кабинете. Противоречие архитектурное: данные должны быть быстро доступны и при этом максимально защищены.
Регуляторные рамки — фундамент архитектуры
Россия. Приказ Минздрава №947н (структура ЭМД), ФЗ-323 «Об основах охраны здоровья», ФЗ-152 о персональных данных. Данные — специальная категория ПДн, обработка только с явного согласия. Сервер — только в РФ.
Европа. GDPR (особые категории данных ст.9), национальные имплементации (например, DSGVO в Германии). Right to access, right to erasure.
США. HIPAA: Protected Health Information (PHI), Business Associate Agreement с каждым подрядчиком, audit log для каждого доступа к данным пациента.
Выбор юрисдикции определяет: где хостинг, какие шифрование и логирование обязательны, можно ли использовать Firebase Analytics, какие уведомления нужно показывать пользователю.
Архитектура доступа: роли и разграничение
Минимум два совершенно разных пользователя:
Пациент. Видит свои данные: анамнез, диагнозы, результаты анализов, назначения, аллергии. Может показать 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 R4 — стандарт, который нельзя игнорировать
Если ЭМК должна интегрироваться с другими MIS (медицинскими информационными системами), HL7 FHIR R4 — де-факто стандарт. Ресурсы: Patient, Observation, Condition, MedicationRequest, DiagnosticReport, Encounter.
На мобильном — 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. Генерируется и кэшируется при последнем онлайн-сеансе.
Что тестировать отдельно
Сценарии «врач потерял телефон»: данные пациентов на устройстве должны быть уничтожены через 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 — ближе к трём. Стоимость рассчитывается после детального анализа требований и юрисдикции.