Разработка мобильного приложения для электронной медицинской карты
Мы разрабатываем мобильные приложения для электронных медицинских карт (ЭМК), которые решают фундаментальное противоречие: данные должны быть мгновенно доступны врачу, но при этом защищены на уровне строгих регуляторных требований. Задача — не просто отобразить историю визитов, а обеспечить безопасный доступ к персональным медицинским данным с максимальным классом защиты (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 — ближе к трём. Сроки и стоимость каждого проекта оцениваются индивидуально после анализа требований и выбранной юрисдикции. Закажите предварительную консультацию для оценки вашего проекта. Получите фиксированную смету на основе требований.