AWS Infrastructure for FHIR: Overview
AWS provides a comprehensive suite of services for building secure, scalable, and compliant FHIR architectures. From managed FHIR data stores to serverless compute and AI/ML capabilities, AWS enables healthcare organizations to innovate while maintaining regulatory compliance.
This module covers AWS HealthLake, serverless facade patterns for legacy integration, multi-tenant architecture strategies, and 40+ AWS services relevant to FHIR implementations.
AWS Healthcare Compliance
AWS supports Australian healthcare compliance requirements including IRAP PROTECTED assessment, data residency in Sydney/Melbourne regions, and integration with NASH PKI for secure B2B connections.
- AWS HealthLake: Managed FHIR R4 data store with NLP
- Serverless patterns: API Gateway + Lambda facades
- Multi-tenant strategies: Silo, Pool, and Hybrid models
- 40+ AWS services for complete FHIR architectures
- Terraform infrastructure as code examples
AWS Australia Regions
Data residency in ap-southeast-2 (Sydney) and ap-southeast-4 (Melbourne)
Region DetailsAWS HealthLake: Managed FHIR Data Store
AWS HealthLake is a HIPAA-eligible service specifically designed to store, transform, query, and analyze health data in FHIR R4 format. It eliminates the undifferentiated heavy lifting of managing FHIR infrastructure.
HealthLake Core Capabilities
- FHIR R4 native storage with automatic indexing
- Built-in FHIR search and query capabilities
- Amazon Comprehend Medical integration for NLP
- Health Lake Data Catalog for discovery
- Encryption at rest and in transit
- Audit logging via CloudTrail
- Cross-Region replication support
HealthLake Architecture
AWS HealthLake data flow
Loading diagram...
Creating a HealthLake Data Store
HealthLake Data Store Configuration
Structured JSON example rendered with depth controls for easier inspection.
Click on an annotation to highlight it in the JSON
Bulk Data Import
HealthLake supports bulk import of FHIR data from S3 using the CreateFHIRImportJob API:
HealthLake Bulk Import Job
Structured JSON example rendered with depth controls for easier inspection.
Click on an annotation to highlight it in the JSON
HealthLake Limitations
HealthLake is optimized for read-heavy workloads. Write operations have eventual consistency. For high-throughput transactional workloads, consider custom DynamoDB or Aurora implementations.
Comprehend Medical Integration
HealthLake automatically extracts medical entities from unstructured clinical text:
- Medications (name, dosage, frequency, route)
- Medical conditions and diagnoses
- Anatomical references
- Protected Health Information (PHI)
- ICD-10-CM and SNOMED CT mappings
Serverless FHIR Facade Pattern
A serverless FHIR facade pattern exposes FHIR REST APIs using API Gateway and Lambda while translating requests to legacy backend systems (HL7 v2 interfaces, proprietary databases, mainframes).
Facade Architecture Components
Serverless FHIR Facade Architecture
Loading diagram...
API Gateway Configuration
API Gateway provides the FHIR REST API front-end:
- REST API (not HTTP API) for advanced features
- Request validation against FHIR schemas
- Lambda authorizers for OAuth 2.0/OIDC
- Request/response transformation (VTL templates)
- Rate limiting and throttling
- API keys for B2B partners
- CloudWatch logging and X-Ray tracing
Lambda FHIR Handler
Lambda functions handle FHIR operations and translate to backend systems:
- FHIR resource validation (using FHIR validator libraries)
- Request routing based on resource type and operation
- Translation to HL7 v2 messages or SQL queries
- Response transformation back to FHIR JSON
- Caching layer integration (DynamoDB/ElastiCache)
- Error handling and FHIR OperationOutcome generation
Lambda Considerations
Lambda has a 15-minute timeout limit. For long-running FHIR operations (bulk export, complex searches), use async patterns with SQS and Step Functions.
Building a Serverless FHIR Interface on AWS
Exact AWS Architecture Blog reference for API Gateway and Lambda FHIR facade patterns.
Review the reference architectureFHIR Facade Architecture Pattern
Architecture reference for exposing legacy clinical systems through a FHIR translation facade.
Facade ArchitectureTerraform: API Gateway + Lambda
resource "aws_apigatewayv2_api" "fhir_api" {
name = "fhir-rest-api"
protocol_type = "HTTP"
cors_configuration {
allow_origins = ["https://smart-app.example.com"]
allow_methods = ["GET", "POST", "PUT", "DELETE", "PATCH"]
allow_headers = ["Authorization", "Content-Type", "Accept"]
max_age = 300
}
}
resource "aws_apigatewayv2_route" "patient_read" {
api_id = aws_apigatewayv2_api.fhir_api.id
route_key = "GET /Patient/{id}"
target = "integrations/${aws_apigatewayv2_integration.patient_read.id}"
}
resource "aws_apigatewayv2_integration" "patient_read" {
api_id = aws_apigatewayv2_api.fhir_api.id
integration_type = "AWS_PROXY"
integration_method = "POST"
integration_uri = aws_lambda_function.fhir_handler.invoke_arn
}
resource "aws_lambda_function" "fhir_handler" {
filename = "fhir-handler.zip"
function_name = "fhir-facade-handler"
role = aws_iam_role.lambda_exec.arn
handler = "index.handler"
runtime = "nodejs18.x"
timeout = 30
memory_size = 512
environment {
variables = {
FHIR_DATASTORE_ID = aws_healthlake_fhir_datastore.main.id
TENANT_TABLE = aws_dynamodb_table.tenants.name
}
}
tracing_config {
mode = "Active"
}
}Request Flow Example
FHIR Serverless Facade Request Flow
Loading diagram...
- Client sends GET /Patient/123 with OAuth token
- CloudFront validates WAF rules, terminates TLS
- API Gateway validates token via Cognito authorizer
- Lambda receives request, validates FHIR parameters
- Lambda checks DynamoDB cache for Patient/123
- Cache miss: Lambda queries legacy database via SQL
- Lambda transforms result to FHIR Patient resource
- Lambda caches result in DynamoDB
- API Gateway returns FHIR JSON to client
Multi-Tenant Architecture Strategies
Multi-tenant FHIR architectures enable serving multiple healthcare organizations from shared infrastructure while maintaining data isolation and compliance boundaries.
Tenant Isolation Models
Multi-tenant architecture comparison
| Model | Isolation | Cost | Complexity | Use Case |
|---|---|---|---|---|
| Silo (Dedicated) | Highest (physical separation) | Highest (dedicated resources) | Medium (orchestration per tenant) | Healthcare enterprises, strict compliance |
| Pool (Shared) | Medium (logical via tenant_id) | Lowest (shared resources) | Highest (tenant routing logic) | SaaS applications, cost-sensitive |
| Hybrid | Configurable per tenant | Medium (tiered approach) | Highest (mixed architecture) | Multi-tier SaaS, enterprise + SMB |
Silo Model (Dedicated)
Each tenant has dedicated infrastructure:
- Dedicated HealthLake data store per tenant
- Dedicated DynamoDB tables per tenant
- Dedicated Lambda functions (or provisioned concurrency)
- Separate Cognito user pools per tenant
- Tenant-specific KMS keys
Silo Model Benefits
Maximum isolation for compliance (IRAP PROTECTED), predictable performance per tenant, easier data residency management, simplified tenant offboarding.
Pool Model (Shared)
All tenants share infrastructure with logical isolation:
- Single HealthLake data store with tenant_id tagging
- Single DynamoDB table with tenant_id partition key
- Tenant routing in Lambda via JWT claims
- Shared Cognito user pool with groups
- Row-level security in Aurora PostgreSQL
Pool Model Considerations
Requires strict tenant isolation logic, careful IAM policies, tenant-aware query filtering, and comprehensive audit logging to prevent data leakage.
AWS SaaS Tenant Isolation Strategies
AWS guidance on choosing silo, pool, and bridge isolation models for multi-tenant platforms.
Tenant Isolation GuideHybrid Model
Combines silo and pool approaches based on tenant tier:
- Enterprise tenants: Dedicated infrastructure (silo)
- SMB tenants: Shared infrastructure (pool)
- Tiered pricing based on isolation level
- Migration path from pool to silo as tenants grow
Terraform: Multi-Tenant DynamoDB
resource "aws_dynamodb_table" "fhir_resources" {
name = "fhir-resources"
billing_mode = "PAY_PER_REQUEST"
hash_key = "pk"
range_key = "sk"
attribute {
name = "pk"
type = "S"
}
attribute {
name = "sk"
type = "S"
}
attribute {
name = "tenant_id"
type = "S"
}
attribute {
name = "resource_type"
type = "S"
}
attribute {
name = "resource_id"
type = "S"
}
global_secondary_index {
name = "TenantIndex"
hash_key = "tenant_id"
range_key = "sk"
projection_type = "ALL"
}
global_secondary_index {
name = "ResourceTypeIndex"
hash_key = "resource_type"
range_key = "resource_id"
projection_type = "ALL"
}
point_in_time_recovery {
enabled = true
}
server_side_encryption {
enabled = true
}
tags = {
Environment = "production"
MultiTenant = "pool"
}
}Tenant Context Propagation
Tenant context must flow through all layers:
- JWT token includes tenant_id claim
- API Gateway authorizer extracts tenant_id
- Lambda receives tenant_id in event context
- All database queries include tenant_id filter
- CloudWatch logs include tenant_id for audit
- X-Ray traces tagged with tenant_id
AWS Services for FHIR (40+ Services)
AWS provides 40+ services relevant to FHIR architectures, from core compute and storage to AI/ML, analytics, and compliance tools.
Core FHIR Services
Core FHIR infrastructure services
| Service | Purpose |
|---|---|
| AWS HealthLake | Managed FHIR R4 data store with NLP |
| Amazon API Gateway | FHIR REST API front-end |
| AWS Lambda | Serverless FHIR operations |
Data Storage Services
Data storage options
| Service | Purpose |
|---|---|
| Amazon DynamoDB | FHIR resource storage (low latency) |
| Amazon Aurora PostgreSQL | Complex FHIR search queries |
| Amazon S3 | Binary resources, exports, backups |
| Amazon ElastiCache | FHIR resource caching (Redis) |
Security & Identity Services
Security and identity services
| Service | Purpose |
|---|---|
| Amazon Cognito | OAuth 2.0/OIDC, SMART on FHIR |
| AWS IAM | Service-to-service authorization |
| AWS Secrets Manager | Credential rotation, NASH certs |
| AWS KMS | Encryption key management |
| AWS Certificate Manager | TLS/SSL certificates |
Networking Services
Networking and edge services
| Service | Purpose |
|---|---|
| Amazon CloudFront | Global CDN, DDoS protection |
| AWS WAF | Web application firewall |
| AWS Shield | DDoS mitigation |
| Amazon VPC | Network isolation |
| AWS PrivateLink | Private service connectivity |
Integration & Messaging
Integration and messaging services
| Service | Purpose |
|---|---|
| Amazon SQS | Async FHIR operations queue |
| Amazon SNS | FHIR event notifications |
| Amazon Kinesis | Real-time FHIR streaming |
| Amazon EventBridge | Event-driven FHIR workflows |
| AWS Step Functions | FHIR workflow orchestration |
Analytics & AI/ML
Analytics and machine learning services
| Service | Purpose |
|---|---|
| Amazon Comprehend Medical | Clinical NLP entity extraction |
| Amazon Athena | SQL queries on FHIR data lake |
| AWS Glue | ETL for FHIR data |
| Amazon QuickSight | Healthcare analytics dashboards |
| Amazon SageMaker | ML models on clinical data |
Service Selection Guide
Start with HealthLake for managed FHIR storage. Add API Gateway + Lambda for custom APIs. Use DynamoDB for caching. Integrate Comprehend Medical for NLP. Layer on analytics (Athena, QuickSight) as needed.
AWS Clinical Systems Solutions
Concrete AWS reference material for clinical-system architectures that combine HealthLake, integration, analytics, and security services.
Clinical SystemsSecurity & Identity Architecture
AWS provides comprehensive security services for FHIR architectures, from identity management to encryption and compliance monitoring.
Amazon Cognito for SMART on FHIR
Cognito provides OAuth 2.0/OIDC identity for SMART on FHIR applications:
- User pools for practitioner/patient identities
- OAuth 2.0 authorization code flow
- OIDC ID tokens with custom claims
- SMART scopes (fhir/user, fhir/patient, etc.)
- MFA support (SMS, TOTP)
- Identity providers (SAML, social)
Terraform: Cognito User Pool
resource "aws_cognito_user_pool" "smart_users" {
name = "smart-on-fhir-users"
password_policy {
minimum_length = 12
require_lowercase = true
require_numbers = true
require_symbols = true
require_uppercase = true
}
schema {
name = "email"
attribute_data_type = "String"
required = true
mutable = true
}
schema {
name = "practitioner_role"
attribute_data_type = "String"
required = false
mutable = true
}
mfa_configuration = "OPTIONAL"
software_token_mfa_configuration {
enabled = true
}
}
resource "aws_cognito_user_pool_client" "smart_app" {
name = "smart-fhir-app-client"
user_pool_id = aws_cognito_user_pool.smart_users.id
explicit_auth_flows = [
"ALLOW_ADMIN_USER_PASSWORD_AUTH",
"ALLOW_USER_PASSWORD_AUTH",
"ALLOW_REFRESH_TOKEN_AUTH"
]
allowed_oauth_flows = ["code", "implicit"]
allowed_oauth_scopes = ["openid", "profile", "email", "fhir/user"]
allowed_oauth_flows_user_pool_client = true
callback_urls = [
"https://smart-app.example.com/callback"
]
supported_identity_providers = ["COGNITO"]
access_token_validity = 1
id_token_validity = 1
refresh_token_validity = 30
}AWS Secrets Manager
Secrets Manager securely stores and rotates sensitive credentials:
- Database credentials (Aurora, RDS)
- API keys for external services
- NASH PKI certificates and private keys
- OAuth client secrets
- Automatic rotation (30/60/90 days)
- Integration with Lambda (no code changes)
Encryption Strategy
AWS encryption services
| Service | Use Case |
|---|---|
| AWS KMS | Encryption key management, envelope encryption |
| CloudHSM | FIPS 140-2 Level 3 HSM for NASH certs |
| Certificate Manager | TLS/SSL certificates for APIs |
| S3 Encryption | Binary resource encryption at rest |
| DynamoDB Encryption | Server-side encryption for resources |
Encryption Best Practices
Use KMS customer-managed keys (CMKs) for FHIR data. Enable key rotation. Use envelope encryption for large payloads. Log all key usage via CloudTrail.
AWS CloudHSM User Guide
CloudHSM guidance relevant to managing high-assurance private key material when designing NASH-related certificate custody patterns on AWS.
CloudHSM GuideMonitoring & Observability
Comprehensive monitoring and observability are critical for FHIR production environments, enabling rapid issue detection and compliance auditing.
Amazon CloudWatch
- Lambda invocation metrics (duration, errors, throttles)
- API Gateway metrics (latency, 4xx/5xx errors)
- DynamoDB metrics (read/write capacity, throttling)
- Custom metrics (FHIR operation latency)
- Alarms for threshold breaches
- Dashboards for operational visibility
AWS X-Ray
X-Ray provides distributed tracing for FHIR requests:
- End-to-end request tracing (CloudFront → API Gateway → Lambda → DB)
- Service map visualization
- Error and fault analysis
- Latency breakdown by service
- Annotation with tenant_id, resource_type, operation
AWS CloudTrail
CloudTrail provides API audit logging for compliance:
- All AWS API calls (who, what, when, where)
- S3 object-level logging for Binary resources
- KMS key usage tracking
- Integration with CloudWatch Logs
- Export to S3 for long-term retention
Compliance Logging
For IRAP PROTECTED compliance, enable CloudTrail across all regions, log to encrypted S3 bucket with MFA delete, retain logs for 7+ years.
Terraform IaC Examples
Infrastructure as Code (IaC) using Terraform enables version-controlled, repeatable FHIR infrastructure deployments. This section provides production-ready Terraform modules for core FHIR components.
HealthLake FHIR Data Store Module
Complete HealthLake data store with encryption, IAM identity provider, and compliance tagging:
resource "aws_healthlake_fhir_datastore" "main" {
datastore_name = "clinical-fhir-datastore"
datastore_type = "FHIR_R4"
preload_sample_data = false
encryption_configuration {
kms_encryption_context = {
purpose = "FHIR data encryption"
environment = "production"
}
kms_key_id = aws_kms_key.fhir_data.arn
}
identity_provider_configuration {
type = "AWS_IAM"
}
tags = {
Environment = "production"
Compliance = "IRAP-PROTECTED"
}
}
resource "aws_kms_key" "fhir_data" {
description = "KMS key for FHIR data encryption"
deletion_window_in_days = 30
enable_key_rotation = true
tags = {
Name = "fhir-data-key"
Environment = "production"
}
}API Gateway with Lambda Authorizer
FHIR REST API with OAuth 2.0 JWT authorizer and CORS configuration:
resource "aws_apigatewayv2_api" "fhir_api" {
name = "fhir-rest-api"
protocol_type = "HTTP"
cors_configuration {
allow_origins = ["https://smart-app.example.com"]
allow_methods = ["GET", "POST", "PUT", "DELETE", "PATCH"]
allow_headers = ["Authorization", "Content-Type", "Accept"]
max_age = 300
}
}
resource "aws_apigatewayv2_route" "patient_read" {
api_id = aws_apigatewayv2_api.fhir_api.id
route_key = "GET /Patient/{id}"
target = "integrations/${aws_apigatewayv2_integration.patient_read.id}"
}
resource "aws_apigatewayv2_integration" "patient_read" {
api_id = aws_apigatewayv2_api.fhir_api.id
integration_type = "AWS_PROXY"
integration_method = "POST"
integration_uri = aws_lambda_function.fhir_handler.invoke_arn
}
resource "aws_lambda_function" "fhir_handler" {
filename = "fhir-handler.zip"
function_name = "fhir-facade-handler"
role = aws_iam_role.lambda_exec.arn
handler = "index.handler"
runtime = "nodejs18.x"
timeout = 30
memory_size = 512
environment {
variables = {
FHIR_DATASTORE_ID = aws_healthlake_fhir_datastore.main.id
TENANT_TABLE = aws_dynamodb_table.tenants.name
}
}
tracing_config {
mode = "Active"
}
}DynamoDB for FHIR Resource Caching
Multi-tenant DynamoDB table with global secondary indexes for efficient FHIR resource queries:
resource "aws_dynamodb_table" "fhir_resources" {
name = "fhir-resources"
billing_mode = "PAY_PER_REQUEST"
hash_key = "pk"
range_key = "sk"
attribute {
name = "pk"
type = "S"
}
attribute {
name = "sk"
type = "S"
}
attribute {
name = "tenant_id"
type = "S"
}
attribute {
name = "resource_type"
type = "S"
}
attribute {
name = "resource_id"
type = "S"
}
global_secondary_index {
name = "TenantIndex"
hash_key = "tenant_id"
range_key = "sk"
projection_type = "ALL"
}
global_secondary_index {
name = "ResourceTypeIndex"
hash_key = "resource_type"
range_key = "resource_id"
projection_type = "ALL"
}
point_in_time_recovery {
enabled = true
}
server_side_encryption {
enabled = true
}
tags = {
Environment = "production"
MultiTenant = "pool"
}
}Cognito User Pool for SMART on FHIR
Cognito configuration with OAuth 2.0/OIDC, MFA, and SMART scopes:
resource "aws_cognito_user_pool" "smart_users" {
name = "smart-on-fhir-users"
password_policy {
minimum_length = 12
require_lowercase = true
require_numbers = true
require_symbols = true
require_uppercase = true
}
schema {
name = "email"
attribute_data_type = "String"
required = true
mutable = true
}
schema {
name = "practitioner_role"
attribute_data_type = "String"
required = false
mutable = true
}
mfa_configuration = "OPTIONAL"
software_token_mfa_configuration {
enabled = true
}
}
resource "aws_cognito_user_pool_client" "smart_app" {
name = "smart-fhir-app-client"
user_pool_id = aws_cognito_user_pool.smart_users.id
explicit_auth_flows = [
"ALLOW_ADMIN_USER_PASSWORD_AUTH",
"ALLOW_USER_PASSWORD_AUTH",
"ALLOW_REFRESH_TOKEN_AUTH"
]
allowed_oauth_flows = ["code", "implicit"]
allowed_oauth_scopes = ["openid", "profile", "email", "fhir/user"]
allowed_oauth_flows_user_pool_client = true
callback_urls = [
"https://smart-app.example.com/callback"
]
supported_identity_providers = ["COGNITO"]
access_token_validity = 1
id_token_validity = 1
refresh_token_validity = 30
}Complete FHIR Infrastructure Stack
Combine modules into a complete FHIR infrastructure stack:
# Main FHIR Infrastructure Module
module "fhir_platform" {
source = "./modules/fhir-platform"
environment = "production"
aws_region = "ap-southeast-2"
vpc_cidr = "10.0.0.0/16"
healthlake_config = {
data_store_name = "clinical-fhir-store"
fhir_version = "R4"
encryption_key = aws_kms_key.fhir_data.arn
}
dynamodb_config = {
table_name = "fhir-resources"
billing_mode = "PAY_PER_REQUEST"
point_in_time_recovery = true
}
cognito_config = {
user_pool_name = "smart-fhir-users"
access_token_validity = 1
refresh_token_validity = 30
}
tags = {
Project = "FHIR Platform"
Compliance = "IRAP-PROTECTED"
CostCenter = "healthcare-digital"
}
}Terraform State Management
Store Terraform state in S3 with DynamoDB locking for team collaboration. Enable versioning and encryption. Never commit state files to version control.
Best Practices
- Use modules for reusability across environments (dev, staging, prod)
- Implement remote state with S3 + DynamoDB locking
- Use workspaces for environment isolation
- Implement CI/CD pipeline with terraform plan/apply
- Tag all resources for cost allocation and compliance
- Use variables for environment-specific configuration
- Implement output values for cross-module references
Summary & Key Takeaways
AWS provides a comprehensive platform for building secure, scalable, and compliant FHIR architectures with managed services, serverless patterns, and multi-tenant strategies.
Core Concepts Recap
- AWS HealthLake: Managed FHIR R4 data store with NLP
- Serverless facade: API Gateway + Lambda for legacy integration
- Multi-tenant models: Silo, Pool, and Hybrid approaches
- 40+ AWS services for complete FHIR architectures
- Cognito for SMART on FHIR OAuth 2.0/OIDC
- Comprehensive monitoring with CloudWatch, X-Ray, CloudTrail
Architecture Decision Guide
When to use each AWS service
| Requirement | Recommended Service |
|---|---|
| Managed FHIR storage | AWS HealthLake |
| High-throughput transactions | DynamoDB + Lambda |
| Complex FHIR search | Aurora PostgreSQL |
| Legacy system integration | API Gateway + Lambda facade |
| OAuth 2.0/OIDC | Amazon Cognito |
| Clinical NLP | Comprehend Medical |
| Bulk analytics | Athena + S3 |
Next Steps
After understanding AWS infrastructure, explore security compliance (IRAP PROTECTED, ISM), B2B integration (NASH certificates, mTLS), and SMART on FHIR authorization patterns.
Amazon HealthLake SMART on FHIR
Specific AWS documentation for SMART on FHIR scopes, authorization flow, and supported security behavior in HealthLake.
SMART on FHIR DocsKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.