--- title: Healthcare Digital Health on AWS (2026): FHIR, Imaging, and Analytics Reference Architecture description: 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. url: https://www.factualminds.com/blog/aws-healthcare-digital-health-reference-architecture-2026/ datePublished: 2026-07-06T00:00:00.000Z dateModified: 2026-07-06T00:00:00.000Z author: palaniappan-p category: Cloud Architecture tags: aws, healthcare, healthlake, healthimaging, fhir, hipaa, digital-health, architecture --- # Healthcare Digital Health on AWS (2026): FHIR, Imaging, and Analytics Reference Architecture > 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 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](https://aws.amazon.com/about-aws/whats-new/2026/03/aws-healthlake-data-transformation-agent/)). **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](https://aws.amazon.com/about-aws/whats-new/2025/07/aws-healthimaging-dicomweb-stow-rs-data-imports/), [London GA](https://aws.amazon.com/about-aws/whats-new/2026/03/aws-healthimaging-europe-london/)). This post is the **healthcare digital health reference architecture** — clinical ingest, imaging, and analytics tiers. It is **not** another [HIPAA checklist](/blog/hipaa-on-aws-complete-compliance-checklist/), **not** [Bedrock-on-PHI guardrails alone](/blog/hipaa-compliant-ai-aws-bedrock/), and **not** [public-sector FedRAMP/GovCloud](/blog/aws-public-sector-compliance-fedramp-govcloud-2026/). Artifacts: [clinical data tier matrix](https://www.factualminds.com/examples/architecture-blog-2026/healthcare-digital-health/clinical-data-tier-decision-matrix.md), [PHI boundary checklist](https://www.factualminds.com/examples/architecture-blog-2026/healthcare-digital-health/phi-boundary-checklist.md). > **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 ``` 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](https://aws.amazon.com/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 1. Export HealthLake resources to S3 on a schedule 2. Run de-identification (HIPAA Safe Harbor or expert determination — legal owns method) 3. Tag tables in **Lake Formation**; separate IAM role for research vs clinical ops 4. For generative use cases, follow [Bedrock guardrails](/blog/how-to-set-up-amazon-bedrock-guardrails-production/) 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](https://www.factualminds.com/examples/architecture-blog-2026/healthcare-digital-health/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](/blog/how-to-implement-hipaa-compliant-architecture-aws/) | ## What to Do This Week 1. Run [clinical-data-tier-decision-matrix.md](https://www.factualminds.com/examples/architecture-blog-2026/healthcare-digital-health/clinical-data-tier-decision-matrix.md) with clinical + imaging stakeholders. 2. Complete [phi-boundary-checklist.md](https://www.factualminds.com/examples/architecture-blog-2026/healthcare-digital-health/phi-boundary-checklist.md) — block go-live on any unchecked critical row. 3. Pilot **50 CCDA documents** through HealthLake transformation agent; validate Patient counts. 4. Pilot **one modality** STOW-RS ingest; measure QIDO-RS p95 before PACS cutover. 5. Document regional RPO/RTO — HealthLake is regional, not multi-master. > **Reproduce this** — Download [phi-boundary-checklist.md](https://www.factualminds.com/examples/architecture-blog-2026/healthcare-digital-health/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](/blog/hipaa-on-aws-complete-compliance-checklist/) and [implementation guide](/blog/how-to-implement-hipaa-compliant-architecture-aws/) We have not benchmarked **HealthLake transformation agent** pricing at **>10M** CCDA documents — run a 1,000-document cost pilot before enterprise bulk import. **Related:** [Healthcare industry hub](/industries/aws-healthcare/) · [Cloud compliance services](/services/cloud-compliance-services/) · [Data analytics](/services/aws-data-analytics/) · [Bedrock services](/services/aws-bedrock/) ## FAQ ### 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. --- *Source: https://www.factualminds.com/blog/aws-healthcare-digital-health-reference-architecture-2026/*