HL7 v2 architectures still start with transport and semantic cleanup
The AWS healthcare lens starts interoperability with a reality check: HL7 v2 often has decent structural consistency and weak semantic consistency. That means the architecture problem is not just moving bytes. It is securing the transport, parsing segment structure, and normalizing meaning before the downstream platform treats the data as authoritative.
AWS specifically calls out MLLP as a common transport that does not natively provide encryption. The lens recommends compensating with MLLP over TLS where possible, or with encrypted channels such as VPN or SFTP when direct TLS is not available.
Secure HL7 v2 ingress pattern
Loading diagram...
Interoperability reference architecture
Official AWS healthcare lens page covering HL7 v2, HL7 v3, and FHIR architecture patterns.
Read the interoperability architecturesHL7 v3 and XDS shift the boundary toward web services
The lens places HL7 v3, CCD, C-CDA, and XDS patterns into a web-service style integration boundary. AWS specifically mentions using Amazon API Gateway to support XDS transactions such as ITI-41, adding TLS with certificate-based authentication and resource policy controls to restrict who can reach the service.
How the lens separates the main interoperability styles
| Style | Primary concern | Common front door | Key control |
|---|---|---|---|
| HL7 v2 | Secure legacy transport plus semantic cleanup | VPN, SFTP, or MLLP over TLS into an integration layer | Encrypted channel and message mapping |
| HL7 v3 / CCD / C-CDA / XDS | Document and transaction exchange over web services | API endpoint supporting XDS transactions | TLS certificate auth and resource policy |
| FHIR | Standards-based API contract for apps and partners | Managed API endpoint with OAuth-style auth | Authentication, conformance checks, and transforms |
Web-service style interoperability boundary
Loading diagram...
API Gateway mutual TLS for REST APIs
Specific AWS documentation for mutual TLS on API Gateway, useful when interpreting the lens discussion of certificate-authenticated XDS style services.
Review mutual TLS on API GatewayAPI Gateway resource policies
Specific AWS documentation for restricting API Gateway access by source and policy, which the lens calls out for interoperability services.
Review resource policy controlsFHIR architectures make the API boundary explicit
The representative FHIR architecture in the AWS lens shows a clear integration boundary: an API front door in front of one or more systems of record, authentication with OAuth or Amazon Cognito, conformance checks for structural interoperability, transformation between standards and proprietary schemas, and optional persistence when the design needs it.
The same page also positions AWS HealthLake as a downstream fit when the program needs FHIR-native persistence, enrichment of unstructured data against clinical ontologies, or analytics and machine learning use cases around the normalized FHIR contract.
FHIR request through a governed integration boundary
Loading diagram...
HealthLake SMART discovery document
Specific HealthLake documentation for SMART discovery, relevant when a FHIR front door also has to advertise an app-launch and authorization contract.
Review SMART discoveryHealthLake token validation
Specific HealthLake documentation for SMART token validation behavior at the FHIR boundary.
Review token validationKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.