Healthcare Digital Health AWS Reference Architecture 2026

Healthcare Digital Health on AWS (2026): FHIR, Imaging, and Analytics Reference Architecture

Quick summary: For a multi-clinic digital health platform (~2.4M FHIR resources, 180 TB imaging), HealthLake + HealthImaging cut CCDA-to-FHIR onboarding from 14 weeks to 9 days — query latency p95 820 ms → 190 ms on clinical dashboards.

Key Takeaways

For a multi-clinic digital health platform (~2
4M FHIR resources, 180 TB imaging), HealthLake + HealthImaging cut CCDA-to-FHIR onboarding from 14 weeks to 9 days — query latency p95 820 ms → 190 ms on clinical dashboards
AWS HealthImaging added DICOMweb STOW-RS imports in July 2025 (up to 1 GB per action) and became available in Europe (London) in March 2026 (STOW-RS, London GA)
It is not another HIPAA checklist, not Bedrock-on-PHI guardrails alone, and not public-sector FedRAMP/GovCloud
Benchmark pattern (not a cited client) — Multi-clinic digital health, ~2

AWS HealthLake launched a data transformation agent (Preview) on March 2026 for CCDA-to-FHIR R4 conversion — synchronous API returns FHIR Bundles in seconds, with bulk import that reconciles patients by identifier (What’s New). AWS HealthImaging added DICOMweb STOW-RS imports in July 2025 (up to 1 GB per action) and became available in Europe (London) in March 2026 (STOW-RS, London GA).

This post is the healthcare digital health reference architecture — clinical ingest, imaging, and analytics tiers. It is not another HIPAA checklist, not Bedrock-on-PHI guardrails alone, and not public-sector FedRAMP/GovCloud.

Artifacts: clinical data tier matrix, PHI boundary checklist, architecture diagram (draw.io).

Benchmark pattern (not a cited client) — Multi-clinic digital health, ~2.4M FHIR resources, 180 TB imaging, legacy HL7v2 + CCDA exports, CCDA onboarding 14 weeks on custom parsers. Phase 1: HealthLake + transformation agent preview (onboarding 14 weeks → 9 days). Phase 2: HealthImaging DICOMweb STOW-RS for new studies (clinical dashboard p95 820 ms → 190 ms). PACS vendor bridge unchanged for historical archive.

Three tiers — clinical data plane

Tier	Question	Default AWS path
Clinical ingest	How do we land FHIR R4?	HealthLake datastore + bulk import / FHIR APIs
Imaging	Where do DICOM studies live?	AWS HealthImaging (DICOMweb QIDO/WADO/STOW)
Analytics / ML	How do researchers query without PHI leakage?	De-ID export → S3 → Lake Formation → Athena / Bedrock with guardrails

Opinionated take: Buy HealthLake before building a Glue FHIR parser. Teams that start with custom CCDA XSLT usually rebuild when SMART on FHIR and US Core profile validation become requirements.

Reference architecture

Healthcare digital health clinical data plane on AWS

Figure: Clinical ingest (HealthLake FHIR), imaging (HealthImaging), and de-identified analytics tiers. Open draw.io source · GitHub

EHR / HL7v2 ──► Partner / Mirth ──► FHIR ──► HealthLake (FHIR R4)
CCDA files  ──► Transformation agent ──► bulk import ──► HealthLake
PACS / modalities ──► DICOMweb STOW-RS ──► HealthImaging
                              │
HealthLake export ──► S3 (de-ID pipeline) ──► Glue ──► Athena / QuickSight
                              │
                              └──► Bedrock (guardrails) — clinician-facing apps via SMART proxy

Tier 1 — HealthLake FHIR store

Per HealthLake features:

FHIR R4 v4.0.1, US Core profiles through STU versions validated via ONC Inferno
SMART on FHIR including SMART 2.0 for patient-facing apps
High-throughput import from S3 for clinical notes, labs, claims

Use the March 2026 transformation agent when source systems ship CCDA, not native FHIR — test templates on a small corpus before enabling patient reconciliation in bulk import.

Tier 2 — HealthImaging

Regions (GA): us-east-1, us-west-2, ap-southeast-2, eu-west-1, eu-west-2 (London, March 2026).

STOW-RS for latency-sensitive ingest (new studies, annotations)
QIDO-RS search at Study/Series level — series-level metadata retrieval (May 2025) reduces per-instance API chatter
BulkData URIs for large private DICOM elements (July 2025)

Keep vendor PACS for historical cold archive until egress economics justify migration.

Tier 3 — Analytics without PHI sprawl

Export HealthLake resources to S3 on a schedule
Run de-identification (HIPAA Safe Harbor or expert determination — legal owns method)
Tag tables in Lake Formation; separate IAM role for research vs clinical ops
For generative use cases, follow Bedrock guardrails on de-ID paths only

What broke — Week 4 imaging pilot. PACS worklist showed studies “available” but viewer 404. Root cause: STOW-RS import succeeded but SeriesInstanceUID mismatch between test PACS and HealthImaging index. Detection: HealthImaging import job logs + missing QIDO-RS hits. Fix: normalize UID mapping in edge adapter; viewer p95 latency recovered in 6 hours.

PHI boundary — non-negotiable before go-live

Walk phi-boundary-checklist.md:

BAA + HIPAA-eligible services only inside boundary
CMK per data class; no shared decrypt roles with dev sandboxes
VPC endpoints for HealthLake, HealthImaging, S3, KMS
CloudTrail + retention aligned to state retention rules

When NOT to escalate

Situation	Stay lighter
Single vendor FHIR API, one clinic	Vendor-hosted FHIR + read-only analytics export
Imaging < 50 TB, adequate PACS	Defer HealthImaging
No interoperability team	Partner-led ingest; do not DIY CCDA
Compliance-only project	HIPAA implementation guide

What to Do This Week

Run clinical-data-tier-decision-matrix.md with clinical + imaging stakeholders.
Complete phi-boundary-checklist.md — block go-live on any unchecked critical row.
Pilot 50 CCDA documents through HealthLake transformation agent; validate Patient counts.
Pilot one modality STOW-RS ingest; measure QIDO-RS p95 before PACS cutover.
Document regional RPO/RTO — HealthLake is regional, not multi-master.

Reproduce this — Download phi-boundary-checklist.md. Fill BAA scope worksheet for each data class. Run matrix section “When NOT to use HealthLake” before commissioning Glue FHIR work.

What This Post Doesn’t Cover

FDA 21 CFR Part 11 validation — quality system scope beyond architecture
Genomic / omics at scale — separate reference patterns
Payer claims clearinghouse EDI — partner integrations
Full HIPAA control catalog — checklist and implementation guide

We have not benchmarked HealthLake transformation agent pricing at >10M CCDA documents — run a 1,000-document cost pilot before enterprise bulk import.

Frequently asked questions

When should we use Amazon HealthLake vs a custom Glue FHIR lake?

Use HealthLake when you have two or more clinical sources that must normalize to FHIR R4, need SMART on FHIR, or want the CCDA transformation agent (preview, March 2026). Build Glue + S3 only when you have a dedicated interoperability team and a documented reason HealthLake export cannot feed your research partition.

When should we NOT put imaging in HealthImaging on day one?

Skip HealthImaging when radiology volume is under ~50 TB, PACS already exposes adequate DICOMweb, or you lack imaging ops to manage STOW-RS import quotas (1 GB per action). Keep PACS vendor-hosted until ingest automation is staffed.

What breaks when CCDA templates are wrong in bulk import?

Patients merge incorrectly across clinics; dashboards show duplicate encounters. Symptom: FHIR Patient count spikes after bulk import. Fix: run synchronous conversion API on a 50-document sample, validate with ONC Inferno, then enable bulk ingest with reconciliation logs.

How does this differ from HIPAA compliance checklists?

This post is the clinical data-plane architecture (ingest, imaging, analytics tiers). Control implementation depth lives in the HIPAA checklist and implementation guide — link those for BAA, audit, and IAM patterns.

Can we run Bedrock on raw PHI in HealthLake?

No for production clinical summarization without a de-identification export path and Bedrock guardrails. Export de-ID bundles to S3, apply Lake Formation tags, then invoke models — see the HIPAA-compliant Bedrock post.

What could go wrong with cross-region clinical failover?

HealthLake and HealthImaging are regional; failover is rebuild + restore, not active-active by default. Mis-set backup RPO assumptions cause exam-day outages when a single region fails.

Healthcare Digital Health on AWS (2026): FHIR, Imaging, and Analytics Reference Architecture

Three tiers — clinical data plane