These are the main healthcare data integration approaches when connecting clinical and administrative systems:

1. Tinybird (for separating clinical analytics from operational systems)
2. Integration engines with HL7 v2/FHIR
3. FHIR-based interoperability platforms
4. Document exchange (IHE XDS.b, CDA)
5. Bulk data extraction for analytics
6. Real-time subscriptions and events

Healthcare data integration is uniquely difficult. You're not just moving data between systems—you're maintaining patient identity across organizations, preserving clinical context and meaning, managing consent and privacy, and ensuring regulatory compliance while integrating dozens of incompatible systems built over decades.

A typical hospital runs 50-200 different clinical and administrative applications. Electronic Health Records (EHR), Laboratory Information Systems (LIS), Radiology Information Systems (RIS), Picture Archiving and Communication Systems (PACS), pharmacy systems, billing systems, medical devices, patient portals, and more.

Each speaks a different language. Each stores data differently. Each has different identifiers for the same patient. And somehow, they all need to work together to deliver safe, effective care.

The standard approach? Build complex integration infrastructure with HL7 v2 message routing, FHIR transformation pipelines, identity resolution services, terminology servers, and custom mapping logic for every interface.

Six months and hundreds of engineering hours later, you have infrastructure that moves data between systems. You also have a fragile integration layer that breaks with every software upgrade, requires specialized expertise to maintain, and still can't answer simple analytical questions like "how many patients with diabetes had an A1C test in the last 90 days?"

The uncomfortable truth: most healthcare integration projects are solving two different problems at once—operational data exchange for clinical workflows, and analytical data integration for reporting, quality, and insights.

This article explores healthcare data integration strategies—when traditional approaches make sense, where they break down, and how separating clinical analytics from operational integration can deliver better results with less complexity.

1. Tinybird: When Your Healthcare Integration Is Really an Analytics Problem

Let's start with an uncomfortable question: are you building healthcare integration infrastructure because you need operational interoperability, or because you need real-time analytics?

Many healthcare organizations conflate these two fundamentally different requirements and end up with integration complexity that serves neither well.

The hidden analytics requirement

Here's the common pattern: Your hospital implements an EHR. Clinical workflows require some data sharing—labs to pharmacy, radiology orders to PACS, ADT notifications to billing.

Then someone asks for a quality metrics dashboard. Then population health reporting. Then operational analytics on bed utilization. Then real-time sepsis alerts based on vitals and lab results. Then predictive models for readmission risk.

Now your integration engine isn't just routing clinical messages—it's trying to power analytics workloads it was never designed to handle.

Performance suffers. Queries are slow. Reports are outdated. The integration team is underwater maintaining hundreds of custom transformations and mappings.

Someone suggests "we need better integration infrastructure" and you're looking at a year-long FHIR platform implementation.

The actual problem

The problem isn't your integration infrastructure. The problem is mixing operational interoperability with analytical data needs.

HL7 v2 message routing is optimized for event-driven clinical workflows—admissions, discharges, orders, results. It's not designed for analytical queries across patient populations.

FHIR APIs are optimized for transactional clinical data access—retrieving individual patient records, updating specific resources. They're not designed for aggregating millions of records with sub-second latency.

These systems serve critical operational purposes. Using them for analytics creates problems for both workloads.

How Tinybird solves healthcare analytics integration

Instead of forcing your integration infrastructure to serve analytics, Tinybird lets you separate analytical workloads while keeping operational systems doing what they do best.

You stream clinical streaming data changes from your EHR, lab system, and other sources into Tinybird using Change Data Capture or HL7/FHIR feeds. That data becomes immediately queryable for analytics while operational systems continue serving clinical workflows.

No complex FHIR transformation pipelines for analytics. Just streaming data into a columnar database optimized for analytical queries.

No slow batch ETL jobs. Tinybird enables real-time data processing — data is queryable in real-time as it arrives.

No custom API layers. Write SQL, get a production-ready API for dashboards, alerts, or predictive models.

One health system described their experience: "We were building a FHIR analytics platform on top of our already complex integration engine. We realized we just needed fast queries on clinical events. Tinybird solved that without touching our operational integration."

The architectural difference

Traditional approach: Build one integration infrastructure that handles both operational message routing AND analytical data warehousing, creating complexity and fragility in both.

Separation approach: Keep operational integration focused on clinical workflows. Use purpose-built analytics infrastructure for reporting, quality metrics, and operational intelligence.

The benefits are immediate:

Operational integration stays simple because it's not trying to serve analytical queries.

Analytics queries are fast because they run on infrastructure optimized for aggregations and joins over large datasets.

Both systems are more reliable because they're not competing for resources or creating conflicting requirements.

Faster time to value because you're not waiting for FHIR transformation pipelines or complex integration projects, while maintaining low latency in analytical queries.

When Tinybird Makes Sense for Healthcare Data Integration

Consider Tinybird for the analytics portion of healthcare integration when:

• You need real-time dashboards for quality metrics, operational intelligence, or population health
• Your existing integration infrastructure is buckling under analytical query load
• You want to build predictive models or alerts based on streaming clinical events
• Your "integration project" is really about enabling analytics and reporting
• You need sub-second query performance on clinical data without impacting operational systems

If you genuinely need operational clinical data exchange—routing lab results to the EHR, sending ADT notifications, coordinating care across providers—you need traditional healthcare integration. But you probably also need analytics, and those are different problems requiring different solutions.

2. The Healthcare Data Integration Challenge

Before diving into integration strategies, let's be honest about what makes healthcare integration uniquely difficult.

Patient identity: The foundation that's always broken

Patient matching errors and duplicate records remain a persistent problem in healthcare data integrity and exchange. Without reliable cross-referencing of patient identifiers across systems, every other integration effort builds on shaky ground.

Your lab system knows the patient as MRN 123456. Your radiology system has the same patient as MRN 654321 (different numbering scheme). Your billing system has them with a different name spelling and DOB entry error.

Now integrate those three systems and try to build an accurate longitudinal patient record. This is the identity problem that plagues healthcare integration, and it requires governance, not just technology.

Semantic interoperability: The illusion of standards

Having data in HL7 or FHIR format doesn't guarantee it means the same thing. Structural interoperability (messages parse correctly) is different from semantic interoperability (fields mean the same thing across systems).

Different lab systems use different codes for "hemoglobin A1C." Different EHRs store medication lists with different terminologies. Different imaging systems encode study metadata differently.

This requires controlled vocabularies—LOINC for lab results and clinical measurements, SNOMED CT for clinical concepts. But implementing terminology services and maintaining mappings adds significant complexity.

Regulatory and privacy complexity

Healthcare data integration operates under strict regulatory frameworks. HIPAA in the US defines standards for protecting patient health information. The European Health Data Space (EHDS) regulation, which entered into force on March 26, 2025, establishes requirements for health data exchange and secondary use across the EU.

These aren't just compliance checkboxes—they fundamentally affect architecture:

• Who can access what data under what circumstances
• How consent is captured and enforced
• What audit trails are required
• How data must be de-identified for research use
• What security controls are mandatory

Integration that doesn't account for these requirements from the beginning creates compliance nightmares later.

The technology landscape

Healthcare systems weren't designed for integration. They were built independently, often decades ago, using different technologies, data models, and assumptions.

Connecting them requires understanding multiple standards simultaneously:

HL7 v2 for event messaging (admissions, discharges, orders, results)—still the workhorse of clinical integration despite being decades old.

HL7 FHIR for modern REST-based APIs and granular resource access—increasingly mandated by regulation.

DICOM and DICOMweb for medical imaging and related workflows.

IHE profiles like XDS.b for document sharing and PIX/PDQ for patient identity resolution.

Each has different semantics, different tooling, and different operational requirements.

3. Integration Engines and HL7 v2: The Traditional Backbone

The most common healthcare integration pattern is still point-to-point HL7 v2 messaging through an integration engine.

How integration engines work

An integration engine sits between clinical systems, receiving messages, transforming them, and routing to destinations. Messages arrive in one HL7 v2 format, get transformed to match the receiving system's expectations, and are delivered.

This pattern handles the core operational workflows: ADT (admissions, discharges, transfers), lab orders and results, pharmacy orders, scheduling updates.

It's battle-tested technology that works for event-driven clinical workflows where systems need to know about state changes as they happen.

Where integration engines struggle

The problems emerge as integration grows:

Point-to-point complexity explodes. With N systems, you potentially need N² interfaces if everyone needs to talk to everyone. Integration engines help but don't eliminate this combinatorial growth.

HL7 v2 variance creates fragility. HL7 v2's flexibility means different implementations interpret messages differently. Each interface requires custom mapping logic that breaks when systems upgrade.

Analytics becomes an afterthought. Integration engines route messages well but don't make data easily queryable. Building analytics requires additional data warehouses infrastructure.

Observability is poor. When messages fail or data doesn't arrive, debugging requires deep expertise in message formats, transformation logic, and system-specific quirks.

One integration engineer described it: "We have 300 interfaces. Half our time is spent maintaining transformations that break whenever vendors update their systems."

When integration engines make sense

Use integration engines for:

• Operational clinical messaging between established systems
• Organizations with significant legacy system investments
• Event-driven workflows (ADT, orders, results) requiring low latency
• Teams with HL7 v2 expertise and integration specialists

Don't use them as your analytics infrastructure—they're message routers, not analytical databases.

4. FHIR-Based Healthcare Data Integration Platforms

HL7 FHIR represents the modern approach to healthcare interoperability—RESTful APIs, granular resources, and web-native integration.

What FHIR platforms provide

FHIR platforms expose clinical data through standardized REST APIs using resources like Patient, Observation, Medication, Condition. Applications can query data using familiar HTTP operations rather than parsing HL7 v2 messages.

SMART on FHIR adds OAuth 2.0-based authorization, enabling third-party apps to integrate securely with standardized scopes and launch contexts.

This enables ecosystem development—patient portals, mobile apps, decision support tools—all accessing data through consistent APIs.

The flexibility problem

FHIR's strength is also its challenge: massive flexibility.

Different FHIR implementations can represent the same clinical concept in incompatible ways. Without implementation guides, profiles, and value set bindings, interoperability is theoretical, not practical.

Mapping from existing systems to FHIR requires significant work. Your HL7 v2 lab results, CDA discharge summaries, and proprietary EHR data models don't automatically become clean FHIR resources.

Terminology mapping is essential but complex—translating local codes to standard terminologies, maintaining FHIR ValueSets and ConceptMaps, running terminology services to validate and expand codes.

One FHIR implementation lead explained: "We spent six months building FHIR APIs. We spent another year making them actually interoperable with profiles, terminology bindings, and proper validation."

When FHIR platforms make sense

Use FHIR-based integration for:

• Building patient-facing applications and third-party ecosystems
• Organizations modernizing integration infrastructure
• Regulatory compliance requiring FHIR support (increasingly common)
• Use cases needing granular data access rather than bulk exchange

Understand that FHIR is a framework requiring significant profiling and implementation work to deliver actual interoperability.

5. Document Exchange and Imaging Integration

Many healthcare integration workflows are fundamentally document-based—sharing clinical summaries, lab reports, imaging studies, and discharge documentation across organizations.

IHE XDS.b for document sharing

IHE XDS.b (Cross-Enterprise Document Sharing) defines how to share clinical documents between organizations using registries, repositories, and standardized metadata.

Documents (typically HL7 CDA clinical summaries) are published to repositories with metadata that enables discovery and retrieval. Organizations query registries to find relevant documents, then retrieve them from repositories.

This pattern works well for regional health information exchanges and longitudinal care coordination where organizations need to share comprehensive clinical summaries.

DICOM and DICOMweb for imaging

Medical imaging requires specialized integration. DICOM defines standards for producing, storing, transmitting, and displaying medical images, with complex workflows for studies, series, and instances.

DICOMweb brings web-native REST APIs to imaging access, making it easier to integrate imaging into modern applications without traditional DICOM networking protocols.

The document integration challenge

Document-based integration sounds simple but has operational complexity:

Metadata quality matters enormously. Without consistent patient identifiers, document types, and clinical context in metadata, discovering relevant documents becomes unreliable.

Documents are large (especially imaging studies), creating storage and network bandwidth challenges.

Documents are point-in-time snapshots, not queryable structured data. You can't easily answer "all diabetic patients who had an A1C test in the last year" from documents alone.

When document integration makes sense

Use document-based integration for:

• Cross-organizational clinical information exchange
• Longitudinal patient records combining data from multiple providers
• Imaging workflows requiring study retrieval and viewing
• Regulatory frameworks mandating document-based exchange

Recognize that documents complement but don't replace structured data integration for analytics.

6. Bulk Data Extraction for Healthcare Analytics

When the goal is analytics, research, or population health rather than operational workflows, transactional FHIR APIs are too slow and expensive.

FHIR Bulk Data Access

HL7 FHIR Bulk Data Access enables extracting large volumes of data from FHIR servers to authorized clients. Rather than making thousands of individual API calls, bulk export retrieves entire patient populations or groups.

This is designed for secondary use cases—extracting EHR data to research databases, data warehouses, or quality reporting systems.

SMART Backend Services provides OAuth 2.0-based authentication for bulk data access, ensuring requests are authorized and audited.

The operational reality

Bulk data export solves volume but creates new challenges:

Incremental updates aren't standardized. "What changed since last export?" isn't consistently solved across implementations. You often end up with full exports and complex change detection logic.

FHIR resources need flattening for analytical use. Nested FHIR structures don't map directly to relational or columnar schemas without transformation.

Export scheduling and orchestration becomes another system to manage—when to export, how to handle failures, how to maintain consistency.

One health analytics team described: "Bulk export gets data out of the EHR. We still needed an entire ETL pipeline, data lake, and analytics platform to make it useful."

When bulk data extraction makes sense

Use bulk data approaches for:

• Populating analytical databases or research repositories
• Quality reporting requiring population-level data
• Data warehouse loads where real-time isn't required
• Organizations with FHIR-enabled source systems

Understand it's the first step in an analytics pipeline, not a complete solution.

Real-Time Subscriptions for Event-Driven Healthcare Analytics

When analytics requires real-time responsiveness—clinical alerts, operational dashboards, predictive models—batch extraction isn't sufficient.

FHIR Subscriptions

FHIR Subscriptions enable servers to proactively notify clients when resources matching specific criteria are created or updated. The modern topic-based subscription approach standardizes common notification patterns.

This enables use cases like:

• Real-time sepsis alerts based on vital signs and lab results
• Operational dashboards showing current census and bed availability
• Predictive models updating as new clinical data arrives

The implementation challenge

Subscriptions solve notification but create operational complexity:

Not all FHIR servers support subscriptions reliably. Implementation maturity varies significantly.

Webhook endpoints must be lightweight or they become bottlenecks. You need message queues to decouple notification receipt from processing.

Filtering capabilities vary by implementation, affecting how precisely you can target relevant events.

This isn't true streaming infrastructure—it's notification mechanisms with server-dependent semantics and reliability.

One clinical informatics director explained: "We built subscriptions for alerts and realized we needed Kafka, message processing, state management, and monitoring on top. We basically built a streaming platform to use subscriptions effectively."

When subscriptions make sense

Use FHIR subscriptions for:

• Event-driven alerts and notifications requiring low latency
• Operational dashboards needing current state
• Systems already invested in FHIR infrastructure

Recognize they're notification mechanisms requiring additional streaming infrastructure for production-grade event processing.

In connected health and Internet of Things (IoT) environments, streaming data from medical devices and sensors can be integrated with FHIR Subscriptions to enable continuous patient monitoring, automated alerts, and predictive care models across distributed systems.

Decision Framework: Choosing Healthcare Data Integration Strategies

Separate operational from analytical integration

The most important decision: are you integrating for operational workflows or analytics?

For operational clinical data exchange (routing messages, coordinating care, sharing results), use traditional healthcare integration—engines for HL7 v2, FHIR platforms for modern APIs, document exchange for cross-organizational sharing.

For analytics, reporting, and operational intelligence, consider purpose-built analytics platforms like Tinybird that handle streaming data ingestion and sub-second query performance without burdening operational systems.

Match integration pattern to use case

Event-driven clinical workflows (ADT, orders, results) → Integration engines with HL7 v2

Modern app ecosystems (patient portals, third-party apps) → FHIR platforms with SMART on FHIR

Cross-organizational care coordination → Document exchange (IHE XDS.b, CDA)

Population health and quality reporting → Bulk data extraction

Real-time alerts and operational dashboards → Streaming analytics platforms (Tinybird) or subscriptions with supporting infrastructure

Assess your team's capabilities

Healthcare integration requires specialized expertise:

• HL7 v2 message parsing and transformation
• FHIR resource modeling and profiling
• Clinical terminology and semantic mapping
• Healthcare privacy and security requirements
• Distributed systems and streaming infrastructure (for analytics)

Managed platforms (whether integration engines or analytics platforms) reduce the expertise burden at the cost of less control.

Custom integration gives maximum flexibility but requires deep expertise and dedicated resources.

Calculate true total cost

Integration infrastructure costs include:

• Licensing fees for integration engines, FHIR platforms, or analytics platforms
• Engineering time for implementation, maintenance, and troubleshooting
• Infrastructure costs for servers, storage, and network bandwidth
• Compliance and security controls
• Opportunity cost of engineers on integration vs product features

A $500K/year platform subscription might be cheaper than three integration engineers at $200K each.

Frequently Asked Questions (FAQs)

What's the difference between HL7 v2 and FHIR?

HL7 v2 is a messaging standard for event-driven workflows, decades old but still dominant for operational integration. FHIR is a modern REST API standard designed for web-native integration and granular data access. Many organizations use both—v2 for established workflows, FHIR for new apps and APIs.

How do I solve patient identity across systems?

Master Patient Index (MPI) systems maintain cross-references between different patient identifiers. IHE PIX and PDQ profiles standardize patient identity cross-referencing and demographic queries. This is foundational work requiring governance, not just technology—data quality, duplicate management, and matching rules matter as much as the software.

What about HIPAA compliance in integration?

HIPAA requires protecting patient health information in transit and at rest, implementing access controls, maintaining audit logs, and having business associate agreements with vendors. Integration infrastructure must support encryption, authentication, authorization, and auditing—not bolt them on afterward. Design security in from the beginning.

Can I use healthcare data for analytics without PHI concerns?

De-identification following HIPAA Safe Harbor or Expert Determination methods can enable analytics on data that's no longer considered PHI. Pseudonymization under GDPR/EHDS reduces risk but data remains personal. Proper governance and risk assessment are essential—don't assume de-identification is simple or absolute.

What's the role of clinical terminologies like LOINC and SNOMED?

LOINC standardizes lab results and clinical observations so "hemoglobin A1C" means the same thing across systems. SNOMED CT standardizes clinical concepts. Without controlled vocabularies, semantic interoperability is impossible—systems can exchange data structurally but not understand what it means. Terminology mapping is essential integration work.

Should I build analytics on my FHIR platform?

FHIR APIs are designed for transactional access, not analytical queries. Running aggregations and joins over FHIR endpoints creates performance problems and overwhelms servers. Use bulk export or streaming to purpose-built analytics infrastructure (like Tinybird) instead of trying to make FHIR serve analytical workloads.

What's the minimum team size for healthcare integration?

Realistically, you need dedicated integration expertise—at least one experienced integration engineer for smaller organizations, growing to specialized teams (integration, terminology, identity, security) in larger health systems. Without that expertise, integration projects fail or create unmaintainable systems.

Healthcare data integration is uniquely complex because it combines technical challenges (incompatible systems, multiple standards) with semantic challenges (clinical meaning, terminology) and regulatory challenges (privacy, security, compliance).

The traditional approach—building monolithic integration infrastructure that handles both operational workflows and analytical queries—creates systems that serve neither well.

The better approach separates concerns: Keep operational integration focused on clinical workflows using appropriate standards (HL7 v2, FHIR, IHE). Use purpose-built analytics platforms like Tinybird for reporting, quality metrics, and operational intelligence.

This separation delivers better performance for both workloads, reduces complexity, and enables faster time to value for analytics without disrupting critical clinical operations.

For operational integration, choose patterns based on use case—integration engines for HL7 v2 messaging, FHIR platforms for modern APIs, document exchange for cross-organizational sharing.

For analytics, don't build on top of operational integration. Stream clinical data to analytics infrastructure optimized for sub-second queries over millions of records.

The right architecture isn't one integration platform for everything. It's the right tool for each job—operational integration for clinical workflows, analytics platforms for insights.

Choose accordingly.