The AWS health portfolio now has clear product boundaries
AWS healthcare architecture is easier to reason about once you stop treating AWS for Health as a marketing umbrella and start treating it as a portfolio. The real design question is which service owns which healthcare modality, API contract, and operating boundary.
As of March 10, 2026, AWS documents distinct service surfaces for clinical longitudinal data, medical imaging, point-of-care operations, and omics workflows. HealthLake owns the managed FHIR boundary, HealthImaging owns cloud-native DICOM workflows, Amazon Connect Health owns point-of-care agents and patient-operation flows, and HealthOmics owns bioinformatics execution plus availability-aware omics storage planning. AWS HealthScribe remains separately documented within Amazon Transcribe and still appears in healthcare application designs for conversation-to-note workflows.
Current AWS health service boundaries
Loading diagram...
Read service docs, not just portfolio summaries
High-level portfolio summaries shift frequently. The stable architectural facts live in the service docs, prescriptive guidance, and API references.
Modern healthcare data strategy example
AWS Prescriptive Guidance mapping HealthLake, HealthImaging, and HealthOmics to distinct healthcare data domains.
Review the multimodal strategyAmazon Connect Health point-of-care overview
Official user guide describing domains, subscriptions, templates, and vended artifacts for point-of-care agents.
Review point-of-care mechanicsAWS HealthScribe overview
Official HealthScribe documentation describing conversation transcription and clinical-note generation.
Read the HealthScribe guidePurpose-built does not mean standalone
A common mistake is to assume that one purpose-built service replaces the surrounding AWS platform. In reality, IAM still owns access control, KMS still owns key policy, EventBridge still carries operational signals, and analytics services still matter when data has to be consumed outside the transactional system.
How the main offerings differ
| Service | Primary domain | Native contract | Typical companion services |
|---|---|---|---|
| AWS HealthLake | Clinical longitudinal data | FHIR R4 APIs, import, export, NLP enrichment | IAM, KMS, Athena, S3, analytics and app layers |
| AWS HealthImaging | Medical imaging | DICOM ingest, image sets, DICOMweb-compatible retrieval | IAM, EventBridge, S3, viewers, edge gateways |
| AWS HealthOmics | Bioinformatics and omics analytics | Private workflows, sequence stores, and availability-aware planning for existing-customer variant and annotation stores | ECR, IAM, S3, research portals, orchestration |
| Amazon Connect Health / AWS HealthScribe | Patient operations and clinical documentation | Ambient notes, patient insights, coding, transcript and note JSON | EHR integration, KMS, app review UI, contact-center controls |
Purpose-built service inside a broader AWS platform
Loading diagram...
Modern healthcare data strategy example
AWS Prescriptive Guidance showing HealthLake, HealthImaging, and HealthOmics as separate domain data products.
Read the reference strategyInteroperability reference architecture
AWS Well-Architected healthcare guidance for standards-aware ingress and target architecture decisions.
Review the interoperability architectureChoose by operational ownership boundary, not by marketing category
If the dominant contract is FHIR, HealthLake is usually the candidate. If the system has to preserve DICOM hierarchy and image retrieval behavior, the candidate is HealthImaging. If the workload runs genomics pipelines and stores omics artifacts, HealthOmics is the better fit, but new programs should check the current availability status of each store type before assuming the full historical surface area. If the workflow is ambient documentation, patient insights, patient verification, or patient scheduling around a visit, Connect Health and HealthScribe belong in the design review.
- Ask which domain object is authoritative: FHIR resource, DICOM object, omics run, or conversational artifact.
- Ask whether the service is a system of record or only one stage in a broader workflow.
- Ask which standards and audit trails must survive the design unchanged.
- Ask what still has to be built around the service: identity, eventing, orchestration, review UI, or analytics.
Do not force multimodal health data into one service
AWS now documents multimodal health-data strategies explicitly. A patient record may reference imaging and omics data, but the operational stores and APIs still differ.
Amazon Connect Health point-of-care AI capabilities
Official point-of-care overview for Amazon Connect Health domains, subscriptions, agents, and vended artifacts.
Review point-of-care mechanicsHealthOmics variant and annotation store availability change
Official HealthOmics page documenting that variant and annotation stores are closed to new customers and describing migration options.
Review HealthOmics availabilityKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.