FHIR IQ - The Semantic Intelligence Layer for Healthcare

🔄

FHIR Facade

Expose legacy systems through modern FHIR APIs without migrating underlying data

Medium Complexity

Common Use Cases:

•Legacy system modernization
•API standardization
•Gradual FHIR adoption

View Details →

🏛️

FHIR Clinical Data Repository (CDR)

Centralized storage of clinical data in native FHIR format for enterprise access

High Complexity

Common Use Cases:

•Enterprise data hub
•Single source of truth
•Multi-system integration

View Details →

📱

FHIR for Health Apps

Build patient-facing and provider applications using SMART on FHIR

Medium Complexity

Common Use Cases:

•Patient portals
•Clinical decision support
•Mobile health apps

View Details →

🔗

FHIR for Interoperability

Enable seamless data exchange between healthcare organizations

Medium Complexity

Common Use Cases:

•HIE connectivity
•Payer-provider exchange
•Care coordination

View Details →

🧠

FHIR Clinical Reasoning

Implement CDS Hooks, clinical pathways, and quality measure reporting

High Complexity

Common Use Cases:

•Quality measure reporting
•Clinical decision support
•Care pathways

View Details →

🔬

FHIR for Research

De-identify and aggregate clinical data for research and population health

High Complexity

Common Use Cases:

•Clinical research
•Population health
•Real-world evidence

View Details →

📊

FHIR Analytics Platform

Flatten and transform FHIR data for analytics, BI, and machine learning

High Complexity

Common Use Cases:

•Business intelligence
•Predictive analytics
•Reporting dashboards

View Details →

🌊

FHIR Data Lake

Store raw FHIR resources at scale for multi-purpose analytics and AI

High Complexity

Common Use Cases:

•Big data analytics
•ML training data
•Historical data retention

View Details →

Detailed Architecture Patterns

🔄

FHIR Facade Architecture

Modernize legacy systems with a FHIR API layer without data migration

Architecture Overview

A FHIR Facade acts as an API translation layer that exposes legacy data through modern FHIR endpoints. The underlying data remains in its original format (HL7 v2, proprietary databases, etc.) while the facade transforms requests and responses in real-time.

FHIR Facade Data Flow

Key Components

API Gateway:Handles authentication, rate limiting, and routing
Transformation Engine:Converts between FHIR and legacy formats bidirectionally
Caching Layer:Reduces load on legacy systems with intelligent caching
Validation Service:Ensures FHIR compliance and data quality

When to Use

✓ Best For:

• Legacy system modernization
• Gradual FHIR adoption
• Read-heavy use cases
• Regulatory compliance (TEFCA, etc.)

⚠ Consider Alternatives:

• High transaction volumes
• Complex write operations
• Real-time clinical workflows
• Analytics and reporting

Implementation Considerations

Performance: Add Redis/Memcached for caching transformed resources
Data Mapping: Document mapping rules between legacy and FHIR models
Error Handling: Gracefully handle legacy system unavailability
Versioning: Support multiple FHIR versions (R4, R5) if needed

Get Implementation Help →

🏛️

FHIR Clinical Data Repository (CDR)

Enterprise-grade storage with native FHIR data model

Architecture Overview

A FHIR CDR stores clinical data in native FHIR format, serving as the single source of truth for an organization. Unlike a facade, data is actually stored as FHIR resources, enabling rich querying, versioning, and compliance features.

FHIR Clinical Data Repository Architecture

Key Components

FHIR Server:HAPI FHIR, Microsoft FHIR Server, or Google Cloud Healthcare API
Storage Layer:PostgreSQL for structured data, MongoDB for document storage
Search Engine:Elasticsearch for complex FHIR search parameters
ETL Pipeline:Data ingestion from multiple source systems
Terminology Service:ValueSet expansion and code system management

Storage Strategies

Relational (PostgreSQL)

Best for structured queries, transactions, and SQL analytics

Document (MongoDB)

Best for flexible schemas, high write throughput, resource versioning

Hybrid Approach

Store in PostgreSQL, index in Elasticsearch for search

Implementation Considerations

Scalability: Plan for sharding/partitioning by patient, organization, or date
Versioning: Implement resource history and audit trail capabilities
Data Quality: Validate resources against profiles on ingestion
Performance: Index common search parameters (patient, date, code)
Backup & DR: Implement point-in-time recovery and geo-replication

Design Your CDR →

📱

FHIR for Health Applications

Build patient and provider apps with SMART on FHIR

Architecture Overview

SMART on FHIR enables healthcare applications to launch from within EHRs and securely access patient data. This architecture standardizes authentication, authorization, and data access patterns across the healthcare ecosystem.

SMART on FHIR Application Architecture

Key Components

SMART Launch:EHR launch, standalone launch, or backend services
Authorization Server:OAuth 2.0 / OpenID Connect for secure authentication
FHIR Client Library:fhir.js, HAPI FHIR Client, or language-specific SDKs
App Frontend:React, Vue, or Angular with SMART on FHIR JS library

App Types

Patient-Facing

• Patient portals
• Medication tracking
• Symptom checkers
• Appointment scheduling

Provider-Facing

• Clinical decision support
• Risk calculators
• Order entry
• Documentation aids

Backend Services

• Bulk data export
• Population health
• Analytics pipelines
• Quality reporting

Implementation Considerations

Scopes: Request minimal necessary scopes (patient/*.read vs user/*.write)
Security: Implement PKCE for public clients, validate tokens server-side
UX: Handle launch context, patient selection, and session management
Offline Access: Request refresh tokens for apps that need persistent access
Testing: Use SMART App Launcher and Inferno for certification testing

Build SMART Apps →

📊

FHIR Analytics Platform

Flatten and transform FHIR for BI, reporting, and ML

Architecture Overview

FHIR resources are hierarchical and nested, making them challenging for traditional analytics tools. An analytics platform flattens FHIR data into relational tables or data warehouse schemas optimized for querying and reporting.

FHIR Analytics Platform Architecture

Key Components

Bulk Data Export:FHIR $export operation for large-scale data extraction
Flattening Engine:FHIRPath, SQL views, or Apache Spark for transformation
Data Warehouse:Snowflake, BigQuery, Redshift, or Azure Synapse
BI Layer:Tableau, Power BI, Looker, or custom dashboards

Flattening Strategies

1. OMOP Common Data Model

Transform FHIR resources to OMOP tables for standardized analytics

Patient → person, Observation → measurement, Condition → condition_occurrence

2. Star Schema

Create fact and dimension tables for traditional BI tools

fact_observations (date_key, patient_key, code_key, value)
dim_patients, dim_codes, dim_date

3. Wide Tables

Denormalize into wide tables with one row per resource

patient_id, observation_code, observation_value, effective_date, ...

Implementation Code Example

-- Flatten Observation resources to SQL table CREATE TABLE observations_flat AS SELECT o.id, o.resource->>'subject' AS patient_id, o.resource->'code'->'coding'->0->>'code' AS code, o.resource->'code'->'coding'->0->>'display' AS code_display, o.resource->'valueQuantity'->>'value' AS value_numeric, o.resource->'valueQuantity'->>'unit' AS unit, o.resource->>'effectiveDateTime' AS effective_date FROM fhir_observation o; -- Index for performance CREATE INDEX idx_obs_patient ON observations_flat(patient_id); CREATE INDEX idx_obs_code ON observations_flat(code); CREATE INDEX idx_obs_date ON observations_flat(effective_date);

Implementation Considerations

Performance: Use incremental loads, not full refreshes
Data Quality: Handle missing values, invalid codes, null-flavored data
Versioning: Track resource versions and handle updates/deletes
Privacy: Apply de-identification, masking, and access controls
Terminology: Normalize codes (LOINC, SNOMED) for consistent analytics

Build Analytics Platform →

FHIR Design Patterns

Proven patterns for modeling clinical data in FHIR

Contained Resources

Embed referenced resources within a parent resource for atomic operations

Observation { contained: [Practitioner] performer: "#prac1" }

Bundles

Group multiple resources together for transactions or messaging

Bundle { type: "transaction" entry: [Patient, Obs, ...] }

Extensions

Add custom data elements not covered by base FHIR specification

Patient { extension: [{ url: "race" valueCoding: {...} }] }

Profiles

Constrain base resources for specific use cases and regions

US Core Patient: - Must have name - Must have identifier - Race/ethnicity required

Must Support

Mark elements that systems must handle if present in data

mustSupport: true // Server MUST store // Client MUST display // If present in data

Search Parameters

Define custom search criteria for resources beyond standard parameters

GET /Observation? code=8867-4 &date=gt2024-01-01 &_sort=-date

Learn FHIR Profiling & Design →

Data Platforms on FHIR

Build modern healthcare data platforms with FHIR as the foundation

Cloud-Native FHIR Platforms

Leverage managed FHIR services from major cloud providers for scalable, compliant data platforms

Azure Health Data Services

Managed FHIR server with DICOM, MedTech IoMT connector

Google Cloud Healthcare API

FHIR R4, HL7v2, DICOM stores with BigQuery integration

AWS HealthLake

FHIR data lake with ML-powered entity extraction

Key Capabilities

• Auto-scaling FHIR servers with SLA guarantees
• Built-in compliance (HIPAA, HITRUST, SOC 2)
• Native integration with analytics tools
• Managed backups and disaster recovery

Open Source FHIR Platforms

Deploy and customize open-source FHIR servers for full control and flexibility

HAPI FHIR

Java-based, most feature-complete, production-ready

Firely Server (Vonk)

.NET-based, high performance, commercial support available

IBM FHIR Server

Java, linear scalability, multi-tenancy support

Medplum

TypeScript, includes EHR features, developer-friendly

Key Capabilities

• Full customization and white-labeling
• Self-hosted or private cloud deployment
• Active community and ecosystem
• Plugin architectures for extensibility

Data Platform Architecture Layers

Ingestion

HL7v2, CDA, CSV, APIs

Storage

FHIR Server, Database

Processing

ETL, Validation, Enrichment

Access

APIs, Analytics, Apps

Related Resources

GUIDE

FHIR Reference Architectures

FHIR Facade

FHIR Clinical Data Repository (CDR)

FHIR for Health Apps

FHIR for Interoperability

FHIR Clinical Reasoning

FHIR for Research

FHIR Analytics Platform

FHIR Data Lake

Detailed Architecture Patterns

FHIR Facade Architecture

Architecture Overview

FHIR Facade Data Flow

Key Components

When to Use

Implementation Considerations

FHIR Clinical Data Repository (CDR)

Architecture Overview

FHIR Clinical Data Repository Architecture

Key Components

Storage Strategies

Implementation Considerations

FHIR for Health Applications

Architecture Overview

SMART on FHIR Application Architecture

Key Components

App Types

Implementation Considerations

FHIR Analytics Platform

Architecture Overview

FHIR Analytics Platform Architecture

Key Components

Flattening Strategies

Implementation Code Example

Implementation Considerations

FHIR Design Patterns

Contained Resources

Bundles

Extensions

Profiles

Must Support

Search Parameters

Data Platforms on FHIR

Cloud-Native FHIR Platforms

Key Capabilities

Open Source FHIR Platforms

Key Capabilities

Data Platform Architecture Layers

Need Help Choosing the Right Architecture?

Related Resources

FHIR Profiling Design

CQL Quality Measures

FHIR Mapping Wiki