Mobile App EHR Integration: FHIR, HL7 & Implementation Guide

EHR Integration Landscape

The 21st Century Cures Act requires EHR vendors to provide standardized APIs for data access, transforming how mobile apps connect to clinical systems.

For AI-powered healthcare applications, see our healthcare AI development services and AI EHR integration guide.

FHIR R4 for Mobile

FHIR (Fast Healthcare Interoperability Resources) uses RESTful API conventions that mobile developers already know:

Common FHIR Resources

FHIR API Patterns

• Read: GET /Patient/{id} — retrieve a single resource
• Search: GET /Observation?patient={id}&code=8867-4 — search with parameters
• Create: POST /Observation — create new resource
• Update: PUT /Patient/{id} — update existing resource
• Batch: POST / with Bundle — multiple operations in one request

FHIR responses are JSON (or XML), making them straightforward to parse in Swift, Kotlin, or JavaScript.

SMART on FHIR

SMART on FHIR is the standardized OAuth 2.0 authorization framework for healthcare apps. It defines how apps authenticate, what data they can access, and how tokens are managed.

Launch Types for Mobile Apps

• Standalone launch: App opens independently, user authenticates, selects patient. Most common for patient-facing and clinical workflow apps.
• EHR launch: App is launched from within the EHR (e.g., Epic's embedded browser). Receives launch context (current patient, encounter) via token.

Scopes

SMART scopes define what data the app can access:

• patient/Patient.read — read patient demographics
• patient/Observation.read — read observations (vitals, labs)
• patient/MedicationRequest.read — read medications
• launch/patient — receive patient context from EHR launch
• openid fhirUser — get user identity

Request only the minimum scopes needed — the HIPAA minimum necessary principle applies.

Vendor-Specific Integration

Epic Integration

• Registration: Register app on Epic App Orchard (now called Epic App Market). Requires organization verification.
• Sandbox testing: Use Epic's sandbox FHIR server with synthetic data. Free for development.
• Review process: 4-12 weeks. Epic reviews security, HIPAA compliance, and clinical safety.
• Production access: Each health system must individually approve your app. Epic central approval enables, but doesn't guarantee, access.

Oracle Health (Cerner) Integration

• Registration: Register on Cerner Code Console. More developer-friendly than Epic historically.
• Sandbox: Open sandbox with synthetic data, self-service provisioning.
• Review: 3-8 weeks. Security review and clinical safety assessment.
• Production: Each health system activates through their Cerner admin console.

Timeline Planning

Mobile Architecture for EHR Integration

  ┌──────────────────────────────────┐
  │          Mobile App              │
  │  ┌──────────┐  ┌─────────────┐  │
  │  │ Clinical  │  │ Local Cache │  │
  │  │ UI Views  │  │ (Encrypted) │  │
  │  └─────┬────┘  └──────┬──────┘  │
  │        │               │         │
  │  ┌─────▼───────────────▼──────┐  │
  │  │      FHIR Client Layer     │  │
  │  │  Resource Models │ Parser  │  │
  │  │  Auth Manager    │ Cache   │  │
  │  └──────────────┬─────────────┘  │
  └─────────────────┼────────────────┘
                    │ HTTPS + SMART Auth
  ┌─────────────────▼────────────────┐
  │        Your Backend (Optional)   │
  │  Token Proxy │ Aggregation       │
  │  AI Processing │ Audit Logs      │
  └─────────────────┬────────────────┘
                    │
  ┌─────────────────▼────────────────┐
  │        EHR FHIR Server           │
  │  Epic / Cerner / Meditech        │
  └──────────────────────────────────┘

Key Architectural Decisions

• Direct vs. proxy: Mobile app can call FHIR APIs directly (simpler) or through your backend proxy (more control, aggregation, AI processing).
• Local caching: Cache FHIR resources locally for performance. Encrypt all cached PHI. Implement cache invalidation based on resource version IDs.
• Offline access: For clinical apps used in low-connectivity areas, cache critical patient data locally with HIPAA-compliant encryption. See our offline-first guide.
• Error handling: EHR APIs can be slow (5-15 second response times) and have rate limits. Implement retry logic, timeout handling, and graceful degradation.

Data Models

FHIR Resource Mapping

Map FHIR resources to native app models. Key considerations:

• Coding systems: Medical data uses SNOMED CT, LOINC, ICD-10, RxNorm codes. Your app needs to display human-readable text while preserving coded values.
• Extensions: EHR vendors add custom FHIR extensions for vendor-specific data. Parse gracefully — don't fail on unknown extensions.
• Versions: Each FHIR resource has a version ID. Use for cache invalidation and optimistic concurrency on updates.
• References: FHIR resources reference each other (e.g., Observation references Patient). Implement lazy loading or batch retrieval for referenced resources.

Compliance Requirements

• HIPAA: All PHI must be encrypted at rest and in transit. Audit logging for all data access. Minimum necessary access. See our HIPAA mobile development guide.
• 21st Century Cures Act: Prohibits information blocking. Apps must allow patients to access their data. APIs must be standards-based (FHIR).
• ONC Health IT Certification: If your app needs certification, it must meet ONC criteria including FHIR US Core Profile compliance.
• State regulations: Some states have additional requirements (e.g., California CMIA, New York SHIELD Act).

For our production EHR integration work, see the AI EHR onboarding case study where we achieved 82% faster data processing.

Frequently Asked Questions