FHIR Interoperability: Modern RESTful Architecture
To definitively resolve the brittle limitations of HL7 v2, the HL7 organization developed the Fast Healthcare Interoperability Resources (FHIR) standard.
FHIR represents a total architectural paradigm shift, transitioning the industry away from rigid, event-driven, point-to-point messaging pipelines toward modern, web-centric, RESTful API principles.
Industry Adoption
FHIR has become the de facto standard for healthcare interoperability, mandated by regulations like the 21st Century Cures Act and supported by all major EHR vendors.
FHIR R4 Specification
Official HL7 FHIR Release 4 specification with resource definitions
View FHIR R4FHIR Resources: Core Data Models
At the core of FHIR architecture are Resources—highly standardized, discrete, and modular data models representing universal clinical concepts.
Common FHIR Resources
Common FHIR Resources and use cases
| Resource | Description | Use Case |
|---|---|---|
| Patient | Demographics and administrative data | Patient registration, identity management |
| Observation | Clinical measurements and results | Lab results, vital signs, clinical findings |
| Medication | Medication definitions and prescriptions | Medication lists, prescribing, dispensing |
| Practitioner | Healthcare provider information | Provider directories, care team management |
| Encounter | Patient-provider interactions | Visit tracking, care episodes |
| Condition | Diagnoses and health concerns | Problem lists, chronic disease management |
| AllergyIntolerance | Patient allergies and intolerances | Medication safety, clinical decision support |
Resource Characteristics
- Modular and composable
- Human-readable narratives
- Machine-processable data
- Extensible via profiles
- Versioned and tracked
FHIR Resource Catalog
Complete catalog of FHIR resources with definitions and examples
View Resource ListRESTful API Architecture
FHIR allows developers to query, manipulate, and extract highly granular data elements on demand using standard HTTP verbs.
HTTP Verbs
- GET: Retrieve resources
- POST: Create new resources
- PUT: Update/replace resources
- DELETE: Remove resources
- PATCH: Partial updates
Payload Formats
FHIR payloads are structured in universally parseable formats:
- JSON: Lightweight, web-friendly, most common
- XML: Structured, enterprise integration
- RDF: Semantic web applications
Stateless Architecture
FHIR supports stateless, HTTP-based queries, allowing applications to extract specific data points without relying on continuous, heavy TCP/IP message feeds.
Semantic Interoperability
FHIR enforces strict semantic interoperability by intrinsically binding data fields to established global clinical terminologies.
Terminology Bindings
- SNOMED CT: Clinical terminology (diagnoses, procedures)
- LOINC: Laboratory and clinical observations
- ICD-10: Disease classification and billing
- RxNorm: Medication nomenclature
- UCUM: Units of measure
USCDI
The United States Core Data for Interoperability (USCDI) defines standardized data elements that must be exchangeable via FHIR APIs for certified EHR systems.
FHIR Terminology Service
FHIR terminology service for code validation and expansion
View Terminology ServiceSNOMED CT International
SNOMED CT clinical terminology for standardized healthcare data
Explore SNOMED CTFHIR vs HL7 v2 Comparison
The following table compares FHIR with the legacy HL7 v2 standard.
FHIR vs HL7 v2: Architectural comparison
| Feature | HL7 v2 | FHIR |
|---|---|---|
| Architecture | Event-driven, point-to-point messaging | RESTful API, web-centric |
| Data Model | Segments with optional fields | Modular Resources |
| Transport | MLLP over TCP/IP | HTTP/HTTPS |
| Format | Pipe-delimited text | JSON or XML |
| Query Capability | Limited, message-based | Granular, on-demand queries |
| Security | Requires VPN/TLS tunneling | Native HTTPS, OAuth 2.0 |
FHIR Security Guidance
HL7 FHIR security implementation guidance and best practices
View Security GuideCDA to FHIR Transition
HL7 resources on transitioning from CDA documents to FHIR resources
Learn CDA MigrationFHIR Bridge Architecture
The FHIR Bridge pattern enables bidirectional transformation between legacy HL7 v2 systems and modern FHIR APIs.
HL7 v2 to FHIR transformation bridge
Loading diagram...
Bridge Pattern
Mirth Connect intercepts HL7 v2 messages, transforms segments to FHIR Resources (ADT→Patient/Encounter, ORU→Observation), and stores in a FHIR-native repository for modern API access.
AWS HealthLake: Cloud-Native FHIR Storage
AWS HealthLake is a HIPAA-eligible managed service that stores, transforms, and queries FHIR-formatted health data at scale.
Core Capabilities
AWS HealthLake features and benefits
| Feature | Description | Benefit |
|---|---|---|
| FHIR R4 Native Storage | Store health data in FHIR R4 format with automatic indexing | No schema design required, instant FHIR API access |
| NLP Clinical Entity Extraction | Automatically extract medications, conditions, procedures from unstructured text | Transform clinical notes into queryable structured data |
| Athena/QuickSight Analytics | Run SQL queries and build dashboards on FHIR data | Population health analytics without ETL pipelines |
| Cross-Account Data Sharing | Securely share FHIR stores across AWS accounts | Enable HIE partnerships and research collaborations |
NLP Clinical Entity Extraction
HealthLake automatically applies machine learning models to extract medical entities from unstructured clinical text, including medications, conditions, procedures, and anatomical references. This transforms free-text clinical notes into queryable, structured FHIR resources.
Analytics Integration
HealthLake integrates with Amazon Athena for SQL queries and QuickSight for dashboards, enabling population health analytics without building complex ETL pipelines.
AWS HealthLake Documentation
AWS managed service for storing, transforming, and querying FHIR data at scale with built-in analytics
View AWS HealthLake DocsHealthLake NLP Features
Extract medical entities from unstructured clinical text using AWS Comprehend Medical
Explore NLP FeaturesHealthLake Data Sharing
Export FHIR data from HealthLake for downstream sharing, analytics, and governed exchange
Learn HealthLake ExportHealthLake Integration Sequence
AWS HealthLake provides a complete FHIR data pipeline from ingestion through NLP extraction to analytics.
HealthLake FHIR ingestion and analytics sequence
Loading diagram...
This sequence demonstrates the complete analytics pipeline: FHIR data streams into HealthLake, NLP extracts medical entities from unstructured text, Athena enables SQL queries, and QuickSight visualizes population health insights.
FHIR Façade Pattern: Legacy Integration
The FHIR Façade pattern enables organizations to expose modern FHIR APIs without replacing legacy EMR systems.
Architecture Components
FHIR Façade architecture components
| Component | Role | Example |
|---|---|---|
| Legacy EMR/EHR | System of record (HL7 v2, proprietary DB) | Epic Chronicles, Cerner ODS |
| FHIR Façade Server | Intercepts HTTP requests, translates to legacy queries | Custom Node.js service, Mirth Connect |
| Integration Engine | HL7 v2 parsing and FHIR resource mapping | Mirth Connect channels, Apache Camel |
| API Gateway | Exposes FHIR endpoints with rate limiting and auth | AWS API Gateway, Kong, Apigee |
| Lambda Functions | On-demand transformation for complex mappings | AWS Lambda, Azure Functions |
Transformation Workflow
- External app sends FHIR GET /Patient/123 request
- API Gateway validates authentication and rate limits
- FHIR Façade intercepts and translates to legacy query
- Integration engine (Mirth Connect) transforms HL7 v2 → FHIR
- Lambda functions handle complex mapping logic
- FHIR JSON response returned to client
Read-Only vs Bi-Directional
FHIR Façade is optimal for read-only queries. Bi-directional workflows require careful synchronization to prevent data conflicts between legacy and FHIR layers.
AWS Clinical Systems Architecture
AWS architectural guidance for modernizing and exposing clinical systems safely
View AWS GuidanceMirth Connect FHIR
NextGen Connect (Mirth) interface engine for HL7 to FHIR transformations
Explore Mirth ConnectAWS API Gateway for Healthcare
Secure, scalable API Gateway for exposing FHIR endpoints with authentication
View API GatewaySMART on FHIR Integration
SMART on FHIR provides standardized authorization for third-party applications accessing FHIR APIs.
Integration Components
SMART on FHIR integration architecture
| Component | Purpose | Flow |
|---|---|---|
| OAuth 2.0 Authorization Server | Issues access tokens after user authentication | Authorization code grant with PKCE |
| OpenID Connect (OIDC) | Identity layer providing user authentication | ID Token contains user claims (name, role, organization) |
| FHIR Authorization Server | Validates scopes and issues JWT access tokens | Token endpoint accepts authorization code + PKCE verifier |
| EHR Launch Context | Provides patient, encounter, user context to app | Context passed via redirect parameters or FHIR API |
App Launch Flow
- App redirects to EHR authorization endpoint with client_id and scopes
- User authenticates with EHR identity provider
- User approves consent prompt for requested scopes
- EHR returns authorization code to app redirect_uri
- App exchanges code for JWT access token (with PKCE)
- App uses token to call FHIR API with Bearer authentication
EHR Launch vs Standalone
EHR Launch opens the app from within the EHR interface with existing user context. Standalone Launch is an independent app launch requiring separate authentication.
SMART on FHIR Specification
Official HL7 SMART on FHIR app launch and authorization specification
View SMART SpecFHIR Use Cases
FHIR enables a wide range of modern healthcare applications.
Primary Use Cases
- Mobile health applications
- Patient portals and personal health records
- Population health analytics platforms
- Remote IoMT (Internet of Medical Things) monitoring
- Clinical research data extraction
- Cross-organization data exchange
- Third-party application integration
Decoupling Benefit
The transition to FHIR effectively decouples clinical data from the underlying proprietary EHR database, enabling flexible, vendor-neutral integration.
Migration Standards Selection
The selection of a migration standard is dictated by specific architectural drivers.
Integration pattern to standard mapping
| Integration Pattern | Best-Suited Standard | Architectural Reasoning |
|---|---|---|
| Event-driven internal workflows | HL7 v2 | Lightweight, highly real-time, proven reliability for ADT/ORM/ORU |
| RESTful API-based apps & Mobile | FHIR | Built natively for HTTP, JSON, and modern API gateways |
| Complex Document exchange | CDA | Structured, highly compliant clinical narratives and discharge summaries |
| Data lake ingestion / Analytics | Hybrid (HL7 → FHIR) | FHIR offers cleaner, standardized resource models for big data analytics |
Coexistence Strategy
- HL7 v2 for real-time internal workflows (ADT, orders)
- FHIR for external APIs and mobile applications
- CDA for document-based exchange (discharge summaries)
- Hybrid patterns for analytics and data lakes
FHIR ImplementationGuide Resource
Directory of FHIR implementation guides for various use cases
View IGsSummary & Key Takeaways
FHIR represents the modern standard for healthcare interoperability, addressing HL7 v2 limitations with RESTful API architecture.
Core Concepts Recap
- FHIR: Fast Healthcare Interoperability Resources
- Resources: Modular data models (Patient, Observation, Medication)
- RESTful API: GET, POST, PUT, DELETE over HTTP
- Formats: JSON or XML payloads
- Terminologies: SNOMED CT, LOINC, ICD-10, RxNorm
- USCDI: Core data elements for interoperability
Architectural Benefits
- Decouples data from proprietary EHR databases
- Enables granular, on-demand queries
- Native web and mobile support
- Modern security (HTTPS, OAuth 2.0)
- Vendor-neutral interoperability
Next Steps
Proceed to SMART on FHIR Security to explore OAuth 2.0, OIDC, and PKCE authorization frameworks for FHIR APIs.
External References
For further reading on FHIR interoperability standards:
HL7 FHIR R4 Specification
Official HL7 FHIR Release 4 specification and resource definitions
View FHIR R4 Spec21st Century Cures Act
Federal interoperability mandates and information blocking regulations
Read Cures Act InfoAWS HealthLake FHIR
AWS managed service for storing, transforming, and querying FHIR data at scale with built-in analytics
View AWS HealthLake DocsKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.