Serverless API Platform for Healthcare Interoperability

All inbound API traffic enters through Amazon API Gateway configured as HTTP APIs (not REST APIs) for lower latency and cost. We defined separate API stages for ABDM gateway callbacks, hospital HIP integration endpoints, patient-facing HIU query APIs, and internal operational endpoints — each with its own throttling configuration, WAF association, and access log destination. Custom domain names are mapped per API type, with mutual TLS (mTLS) enabled on the ABDM gateway-facing endpoints to satisfy NHA's certificate pinning requirements.

Every API endpoint is protected by a Lambda custom authorizer (REQUEST-type, not TOKEN-type, to enable access to full request context). The authorizer validates inbound JWTs issued by the ABDM gateway using JWKS endpoint verification with key rotation support, verifies hospital-specific API keys against DynamoDB, enforces ABHA token signatures for patient-initiated requests, and returns a fine-grained IAM policy document scoping the downstream Lambda's execution context. Authorizer responses are cached for 300 seconds per unique token to avoid redundant validation overhead, with cache invalidation triggered on token revocation events via SQS.

Business logic is distributed across purpose-specific Lambda functions written in TypeScript (Node.js 20.x runtime). Key functions include: ConsentOrchestrator (handles the full consent lifecycle state machine), HealthRecordFetcher (initiates async record collection from registered HIPs), FHIRTransformer (runs HL7-to-FHIR transformation), ABDMGatewayAdapter (implements the NHA gateway protocol including push notifications to ABDM callback URLs), and AuditEmitter (writes structured audit events to CloudWatch Logs). Provisioned concurrency is configured on ConsentOrchestrator and ABDMGatewayAdapter — the two functions in the critical path for patient-facing workflows — targeting 20 pre-warmed instances each to eliminate cold start latency from consent grant and record request flows.

DynamoDB serves as the primary state store for consent artifacts, consent lifecycle events, hospital registration records, and ABHA linking tokens. Tables are encrypted at rest with AWS-managed KMS keys (SSE-KMS with aws:dynamodb service key), with DynamoDB Streams enabled on the ConsentTable to trigger downstream processing when consent state transitions occur. The data model uses a single-table design with entity-type prefixed partition keys (CONSENT#<consentId>, HOSPITAL#<hipId>, PATIENT#<abhaId>) and composite sort keys for efficient access patterns. Point-in-time recovery is enabled on all production tables with a 35-day retention window.

Assembled FHIR bundles are stored in a dedicated S3 bucket with server-side encryption using customer-managed KMS keys (SSE-KMS). Each health record object is keyed by a compound path that includes the consent artifact ID, the ABHA address hash, and a record timestamp — making access pattern auditing straightforward. Bucket policies enforce that objects are only accessible via the VPC endpoint (no public internet path exists to health record objects). S3 Object Lock is enabled in Governance mode with a 7-year retention policy for audit compliance. Pre-signed URLs with 15-minute expiry are generated for patient health record downloads, with URL generation events logged to CloudTrail.

We implemented an envelope encryption pattern for PHI. Each health record is encrypted with a unique data encryption key (DEK) generated per-record. The DEK is itself encrypted (wrapped) with a customer-managed KMS CMK. The encrypted DEK is stored alongside the record metadata in DynamoDB; the plaintext DEK exists only in Lambda function memory during record assembly and is never persisted. KMS CMKs are configured with key policies that restrict decrypt operations to specific Lambda execution roles and require multi-region replication for disaster recovery. Key usage is logged to CloudTrail with each decrypt event associated to a consent artifact ID.

Health record fetch is inherently asynchronous in the ABDM protocol: the HIU requests records, the HIP queues a fetch job, retrieves records from its HMIS, packages them as FHIR bundles, and delivers them via a callback URL — all without a synchronous HTTP connection held open. We modelled this with SQS FIFO queues per hospital (to maintain ordered processing within a consent context), Lambda triggers consuming from those queues with a batch size of 1 for isolation, a dead-letter queue capturing failed fetch attempts with a redrive policy after 3 retries, and a separate RecordDeliveryQueue for outbound FHIR bundle dispatch to HIU callback URLs. Message bodies are encrypted using SQS SSE with the same CMK hierarchy as the record store.

Every significant operation — consent state transition, health record access, FHIR transformation, ABHA ID verification, gateway authentication — emits a structured JSON audit event to a dedicated CloudWatch Log Group with a 2-year retention policy and log data protection enabled to mask PHI in log streams. CloudWatch Logs Insights queries are pre-built for common audit scenarios: 'all record accesses under a given consent ID', 'all consents granted for a specific ABHA address in a time window', 'failed authentication attempts per hospital in last 24 hours'. CloudWatch Alarms monitor error rates, DLQ depth, consent processing latency, and API Gateway 5xx rates, with PagerDuty integration via SNS for on-call alerting.