Разработка мобильного приложения для электронной медицинской карты

Разработка мобильного приложения для электронной медицинской карты

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

Как обеспечить безопасность медицинских данных?

1. Реализовать шифрование данных на устройстве (SQLCipher, Core Data с NSFileProtection).
2. Использовать биометрическую аутентификацию для доступа.
3. Настроить certificate pinning и TLS 1.3 для передачи.
4. Применить ProGuard/R8 на Android и code obfuscation на iOS.
5. Организовать remote wipe через MDM при утере устройства.

Что входит в работу

• Аудит регуляторных требований и согласование с заказчиком
• Проектирование архитектуры (FHIR-модель, схема доступа, audit log)
• Разработка мобильного приложения (iOS/Android/cross-platform)
• Реализация шифрования и безопасного хранения
• Интеграция с FHIR-сервером и внешними системами
• QA и penetration testing
• Документация и инструкции для пользователей
• Поддержка при релизе в App Store / Google Play

Какие сценарии тестировать отдельно?

Сценарии «врач потерял телефон»: данные пациентов на устройстве должны быть уничтожены через remote wipe (MDM) или недоступны без биометрии после N минут неактивности.

Сценарий «пациент умер»: что происходит с доступом доверенных лиц? Это не технический вопрос — это юридический, но от него зависит архитектура согласий.

Процесс

Полный MVP — 2–3 месяца. Приложение с полной FHIR-интеграцией, поддержкой врача и пациента, HIPAA-совместимым audit log — ближе к трём. Сроки и стоимость каждого проекта оцениваются индивидуально после анализа требований и выбранной юрисдикции. Закажите предварительную консультацию для оценки вашего проекта. Получите фиксированную смету на основе требований.

Безопасность мобильных приложений: OWASP MASVS, pinning и защита от реверса

Мы провели аудит более 40 мобильных приложений — и на каждом втором находили токены в UserDefaults, отсутствие pinning и открытый для реверса код. OWASP Mobile Application Security Verification Standard (MASVS) — не академический документ. Это чек-лист пентестера. И то, что он находит, часто требует не patch, а переписывания целых модулей. Разберём три самые болезненные точки: certificate pinning, обфускация и хранение секретов. И покажем, как их закрыть без даунтаймов на продакшне.

Почему certificate pinning ломает продакшн?

Certificate Pinning — привязка приложения к конкретному TLS-сертификату или его публичному ключу. Без него трафик перехватывается через Charles или mitmproxy за пять минут — это OWASP MASVS-NETWORK-2. Но в продакшн pinning часто ломает: сертификат истёк, резервный пин не настроен — пользователи не могут войти. Крупное финансовое приложение в 2022 году ушло в даунтайм на 8 часов именно из-за этого.

На iOS реализуется через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) с проверкой SecTrust. Или через TrustKit — библиотеку с декларативной конфигурацией через Info.plist. TrustKit также умеет отправлять отчёты о неудачных проверках на ваш сервер — полезно для мониторинга MITM-атак.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критическое правило: всегда два пина — основной и резервный. Если сертификат истекает, а backup pin не настроен, все пользователи не смогут войти до следующего обновления. Именно так ломаются production-сборки.

Ещё одна точка отказа: CDN и third-party SDK. Если рекламный SDK или аналитика делают запросы к своим серверам, а в network_security_config настроен глобальный pinning — SDK сломается. Конфигурация должна быть поддоменно-специфичной.

Как защитить данные в Keychain и Keystore?

MASVS-STORAGE-1 и STORAGE-2 — самые часто нарушаемые требования. Частая ошибка на iOS: токены авторизации хранятся в UserDefaults. Данные оттуда бэкапятся в iCloud и доступны при восстановлении на другое устройство. Токен на новом iPhone — это чужая авторизованная сессия. Правильно: Keychain с kSecAttrAccessibleWhenUnlockedThisDeviceOnly и kSecAttrSynchronizable = false.

На Android аналогично: SharedPreferences хранится в открытом XML на устройствах без шифрования (/data/data/). Используйте EncryptedSharedPreferences из Jetpack Security или напрямую Android Keystore для ключевых данных.
Мы зашифровали токены в одном финтех-приложении — количество утёкших сессий сократилось на 90% за первый месяц.

Обфускация и защита кода

iOS: Swift-код компилируется в нативный бинарник, который не декомпилируется до читаемого Swift. Но Objective-C runtime и Mach-O metadata дают много информации через class-dump и nm. Имена классов, методов, строки в бинарнике — всё видно. Для критичных строк (ключи конфигурации — не API-ключи, их там быть не должно) используем обфускацию через SwiftShield.

Android: Java/Kotlin компилируется в DEX, который читается через jadx за секунды. R8 (включён по умолчанию в release сборках) минифицирует и обфусцирует. Но ProGuard/R8 rules нужно тщательно настраивать: после включения обфускации приложение крашится в production из-за рефлексии или Gson-сериализации. Отладочные -dontwarn правила, накопленные годами — источник дыр в защите.

Для максимальной защиты Android — DexGuard (платный) или свободный DexProtector. Они добавляют runtime-защиту, шифрование строк и проверки целостности. Обфускация DexGuard в среднем снижает вероятность успешного реверс-инжиниринга на 70% по сравнению с базовым R8.

Обнаружение jailbreak и root

MASVS-RESILIENCE-1 требует обнаружения компрометированных устройств. Стандартные проверки: наличие /Applications/Cydia.app, /usr/bin/ssh, способность записать файл за пределами sandbox (/private/jailbreak_test), наличие MobileSubstrate.

Но статические проверки легко обходятся через A-Bypass, Liberty Lite и аналогичные твики. Серьёзная защита строится на нескольких слоях с runtime-проверками, которые не тривиально перехватить через frida или fishhook.

Готовые решения: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-уровня — Guardsquare AppSweep с интеграцией в CI и динамическим анализом.

Что входит в работу по безопасности мобильного приложения

Как мы реализуем защиту: кейс

Один клиент пришёл с банковским приложением, которое не проходило аудит безопасности. Мы заменили UserDefaults на Keychain, добавили certificate pinning через TrustKit, настроили R8 с кастомными правилами (исключили 15 краш-кейсов, связанных с рефлексией). Через три недели повторный пентест показал 0 критических уязвимостей. С момента внедрения — ни одного инцидента за два года.

Сроки и стоимость

• Security-аудит по OWASP MASVS уровня L1 — от 1 до 2 недель.
• Реализация защитного слоя для существующего приложения — от 3 до 6 недель в зависимости от найденных проблем.
• Полный цикл «аудит + внедрение + тест» — от 4 до 8 недель.

Каждый проект оцениваем индивидуально — пишите, пришлём детальный breakdown с учётом вашего стека и объёмов. Работаем под ключ: от анализа до деплоя в сторах.

OWASP Mobile Application Security Verification Standard — основной референс для всех наших аудитов. Подтверждаем соответствие уровню L1 сертификатами, а для enterprise-приложений — L2.

Оценим ваш проект за один рабочий день после получения APK/IPA. Свяжитесь — расскажем, какие дыры закроем в первую очередь.