Skip to main content

AI & assistant-friendly summary

This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.

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 Facts

  • 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

Entity Definitions

Bedrock
Bedrock is an AWS service discussed in this article.
S3
S3 is an AWS service discussed in this article.
IAM
IAM is an AWS service discussed in this article.
VPC
VPC is an AWS service discussed in this article.
Glue
Glue is an AWS service discussed in this article.
Athena
Athena is an AWS service discussed in this article.
compliance
compliance is a cloud computing concept discussed in this article.
HIPAA
HIPAA is a cloud computing concept discussed in this article.

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

Cloud ArchitecturePalaniappan P4 min read

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
Healthcare Digital Health on AWS (2026): FHIR, Imaging, and Analytics Reference Architecture
Table of Contents

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.

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

TierQuestionDefault AWS path
Clinical ingestHow do we land FHIR R4?HealthLake datastore + bulk import / FHIR APIs
ImagingWhere do DICOM studies live?AWS HealthImaging (DICOMweb QIDO/WADO/STOW)
Analytics / MLHow 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:

  • 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 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

SituationStay lighter
Single vendor FHIR API, one clinicVendor-hosted FHIR + read-only analytics export
Imaging < 50 TB, adequate PACSDefer HealthImaging
No interoperability teamPartner-led ingest; do not DIY CCDA
Compliance-only projectHIPAA implementation guide

What to Do This Week

  1. Run clinical-data-tier-decision-matrix.md with clinical + imaging stakeholders.
  2. Complete 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. 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 catalogchecklist 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.

Related: Healthcare industry hub · Cloud compliance services · Data analytics · Bedrock services

PP
Palaniappan P

AWS Cloud Architect & AI Expert

AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.

AWS ArchitectureCloud MigrationGenAI on AWSCost OptimizationDevOps

Recommended Reading

Explore All Articles »