Part I: Foundations & Landscape

The Digital Health Stack

Architectural layers of a modern health application
View as Markdown

Overview

A modern digital health application is built on multiple architectural layers. Understanding these layers — and the decisions required at each level — is essential for building scalable, secure, and compliant health products.

The Six Layers

1. Experience Layer

The interfaces through which users interact with your health product.

  • Patient-facing: Mobile apps, web portals, voice interfaces, wearable UIs
  • Clinician-facing: Dashboards, EHR-integrated views, clinical decision support interfaces
  • Admin-facing: Practice management, reporting, analytics dashboards

2. API & Integration Layer

The connectivity backbone that enables data exchange between components.

  • FHIR APIs: Standardized health data exchange (R4, US Core, EU formats)
  • REST/GraphQL APIs: Application-level service interfaces
  • WebSocket/Event Streams: Real-time data for monitoring and alerts
  • EHR Integrations: HL7 v2, FHIR, custom APIs for EMR connectivity

3. Application Services Layer

The core business logic and service orchestration.

  • User Management: Authentication, authorization, role management
  • Patient Management: Demographics, consent, care team assignment
  • Clinical Services: Data collection, assessment scoring, care plan management
  • Communication Services: Messaging, notifications, telehealth sessions
  • Analytics Services: Reporting, population health, predictive models

4. Data Layer

Storage, processing, and management of health data.

  • Clinical Data Store: Structured health data (observations, conditions, medications)
  • Document Store: Unstructured clinical notes, PDFs, imaging
  • Time-Series Store: Wearable data, continuous monitoring, vitals
  • Data Lake: Aggregated data for analytics and ML training
  • Data Warehouse: Reporting and business intelligence

5. Security & Compliance Layer

Cross-cutting controls that protect data and ensure regulatory compliance.

  • Identity & Access Management: SSO, MFA, RBAC, SCIM provisioning
  • Encryption: At rest (AES-256) and in transit (TLS 1.3)
  • Audit Logging: Immutable logs of all PHI access
  • Key Management: Automated key rotation, HSM integration
  • Consent Management: Patient consent tracking and enforcement

6. Infrastructure Layer

The foundation that everything runs on.

  • Cloud Provider: AWS, GCP, Azure (HIPAA-eligible configurations)
  • Container Orchestration: Kubernetes, ECS, Cloud Run
  • CI/CD Pipeline: Automated testing, security scanning, deployment
  • Monitoring & Observability: Logging, metrics, tracing, alerting
  • Disaster Recovery: Multi-region, backup, failover

Common Architecture Patterns

FHIR-Native Architecture

Health services expose FHIR APIs directly. The FHIR model becomes the canonical data model. Best for interoperability-first products

Microservices + Event-Driven

Loosely coupled services communicating via event streams. Ideal for complex health workflows and real-time monitoring

Offline-First Mobile

Critical for patients in low-connectivity environments. Local encrypted storage with background sync

EHR-Embedded

Runs as a SMART-on-FHIR app within existing EHR systems. Leverages health system infrastructure and clinician workflows

Key Architectural Decisions

Every health app faces these architectural questions:

DecisionOptionsTrade-offs
Data modelFHIR-native vs custom vs hybridFHIR maximizes interoperability but adds complexity
Cloud providerAWS, GCP, AzureEach has different HIPAA compliance programs and health-specific services
Auth providerAuth0, Cognito, Azure AD, customCustom gives more control but requires compliance certification
EHR integrationFHIR, HL7 v2, custom APIFHIR is modern but less adopted; HL7 v2 is widely deployed but rigid
AI/ML infrastructureCloud AI services, custom models, third-party APIsCompliance review required for any PHI-processing AI service