# Clinical data tier decision matrix (AWS healthcare 2026)

Use before standing up a clinical data plane. Score each row 0–2 per column; sum ≥ 6 on a row → that tier is primary.

| Scenario | HealthLake FHIR store | Custom Glue + S3 FHIR lake | On-prem interface engine only |
|----------|----------------------|----------------------------|-------------------------------|
| Multiple EHR/HL7v2 sources need FHIR R4 normalization | **2** — native FHIR R4, bulk import, CCDA agent (preview Mar 2026) | 1 — you own parsers | 0 — stays siloed |
| Need SMART on FHIR + OAuth for patient apps | **2** — SMART 2.0, ONC Inferno validated | 0 — build yourself | 1 — vendor-dependent |
| DICOM imaging at petabyte scale | 0 — use HealthImaging | 0 | 0 |
| CCDA clinical documents without in-house FHIR team | **2** — transformation agent preview | 1 | 1 |
| Single-source FHIR API already (one vendor) | 1 | 1 | **2** if latency SLA requires local |
| Research de-ID lake + Bedrock | 1 — export to S3 | **2** — Lake Formation + Glue | 0 |

## Opinionated default

**Buy HealthLake** when ≥2 distinct clinical sources must land in one FHIR R4 store. **Defer custom Glue FHIR** until you have a dedicated interoperability team and a written reason HealthLake export cannot satisfy analytics (e.g., air-gapped research partition).

## HealthImaging gate

Add **AWS HealthImaging** when radiology/cardiology PACS volume exceeds **~50 TB** or DICOMweb clients already exist. Regions (GA): us-east-1, us-west-2, ap-southeast-2, eu-west-1, eu-west-2 (London, Mar 2026).

## When NOT to use HealthLake

- Single specialty with one vendor-managed FHIR endpoint and no cross-source analytics
- Batch research only on de-identified CSV — S3 + Athena may suffice
- No BAA in place with AWS — stop; sign BAA before any PHI ingest