EHR/EMR Integration: HL7 & FHIR Explained

TL;DR: EHR/EMR integration is how your healthtech app reads and writes clinical data in the systems hospitals and clinics already use. Modern integrations use HL7 FHIR (a REST/JSON API standard) for new work, while legacy HL7 v2 messaging is still everywhere and cannot be ignored. Budget for authentication, data mapping, and testing against real systems—that is where the time goes, not the code.

What is EHR/EMR integration and why is it hard?

Getting ehr emr integration right is the difference between a healthtech product clinicians actually adopt and one that dies in a pilot. An EHR (Electronic Health Record) or EMR (Electronic Medical Record) is the system of record for patient data—think Epic, Oracle Health (Cerner), MEDITECH in the US, or SystmOne and EMIS in the UK. Integration means your application can securely pull data from and push data to those systems: demographics, allergies, medications, lab results, appointments, and clinical notes.

It is hard for reasons that have little to do with writing code. Healthcare data is fragmented across hundreds of vendors, each with its own configuration, and the same field—a date of birth or a medication dose—can be represented differently in every deployment. Access is gated behind procurement and security review. And because you are handling Protected Health Information (PHI), every decision carries regulatory weight under HIPAA in the US, GDPR in Europe, and equivalent frameworks elsewhere. The standards below exist to tame that chaos.

What is HL7 and how does HL7 v2 work?

HL7 (Health Level Seven) is the standards organization behind most healthcare interoperability. Its oldest and still most widely deployed standard is HL7 v2, first released in the late 1980s. Despite its age, it powers a huge share of messaging between hospital systems worldwide—admissions, lab orders, and results flow over it constantly.

HL7 v2 is a pipe-delimited messaging format, not a modern API. Messages are triggered by events (a patient is admitted, a lab result is ready) and typically travel over a low-level protocol called MLLP. A fragment of an ADT (admit/discharge/transfer) message looks like this:

MSH|^~\&|SENDING_APP|HOSPITAL|RECEIVING_APP|CLINIC|20260712083000||ADT^A01|MSG00001|P|2.5
PID|1||100472^^^HOSP^MR||DOE^JANE^A||19850312|F

Each segment (MSH, PID) carries fields separated by pipes. It is compact and battle-tested, but cryptic, loosely enforced, and painful to debug—every site tweaks it slightly. There is also HL7 v3 and its document format CDA (Clinical Document Architecture), used for structured clinical documents, but v3 never achieved v2's adoption. For founders: if you integrate with established hospital systems, you will almost certainly meet HL7 v2, even in 2026.

What is FHIR and why is it the modern standard?

FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is HL7's modern standard and where all new integration work should start. It reframes healthcare data as resources—Patient, Observation, MedicationRequest, Encounter, Appointment—exposed over a normal RESTful API using JSON or XML. If your team knows how to consume a REST API, FHIR will feel familiar:

GET /Patient/100472
GET /Observation?patient=100472&category=laboratory

FHIR matters for two reasons. First, it is dramatically friendlier for developers than HL7 v2. Second, regulation is actively pushing the industry toward it. In the US, the 21st Century Cures Act and ONC rules require certified EHRs to expose a standardized FHIR API (based on the USCDI data set) and prohibit "information blocking." SMART on FHIR layers OAuth 2.0 and OpenID Connect on top so third-party apps can authenticate and launch inside the EHR with scoped, patient- or user-level permissions. In the UK, NHS interoperability standards likewise centre on FHIR (UK Core).

HL7 v2 vs FHIR: which should you use?

In practice this is rarely an either/or, since mature products often support both, but the framework is straightforward.

Dimension	HL7 v2	FHIR
Format	Pipe-delimited messages	JSON/XML resources over REST
Style	Event-driven messaging (push)	Request/response API + subscriptions
Developer experience	Steep, cryptic, site-specific	Familiar to any API developer
Best for	Legacy hospital feeds, real-time ADT/lab flows	New apps, patient-facing data, mobile
Regulatory momentum	Legacy, widely embedded	Mandated by US Cures Act, NHS, others
Maturity	Extremely mature, ubiquitous	Modern, evolving, strong tooling

A practical rule: build on FHIR first for anything patient-facing or greenfield, and add HL7 v2 support when a specific hospital feed requires it. Do not build a v2-only integration in 2026 unless a partner explicitly forces it—you would be starting on the standard the industry is migrating away from.

How do you actually connect to an EHR?

There are three broad routes; the right one depends on which systems you must reach, and how many.

1. Direct vendor APIs. Epic (via its App Orchard/Showroom and open FHIR endpoints), Oracle Health, and others publish FHIR APIs. This gives you the deepest access but means separate onboarding, credentials, and app registration per vendor—and often a review process before production access.
2. Integration/aggregator platforms. Services such as Redox, Health Gorilla, 1upHealth, or Particle Health provide one normalized API in front of many EHRs. You trade some per-integration control and a subscription cost for far faster coverage—often the pragmatic choice for a startup that needs to reach many provider systems quickly.
3. Interface engines. For classic HL7 v2 feeds, engines like Mirth Connect (open source), Rhapsody, or cloud offerings such as AWS HealthLake and Google Cloud Healthcare API route, transform, and translate messages—including v2-to-FHIR conversion.

Whichever route you choose, the same components recur: authentication (OAuth 2.0 / SMART on FHIR), data mapping between the EHR's model and yours, error handling and retries, an audit trail of every PHI access, and a sandbox for testing before you touch live data. If you are also designing the surfaces patients use, our guide to building a telemedicine app shows how these feeds connect to real workflows.

How much does EHR/EMR integration cost and how long does it take?

Costs vary enormously with scope, so treat these as 2026 industry estimates rather than quotes. The single biggest variable is how many distinct systems you must integrate—each direct EHR connection carries its own onboarding and testing overhead.

Approach	Typical effort	Estimated range (USD)
Single FHIR integration (one EHR, read-focused)	4-8 weeks	$15,000-$40,000
Aggregator platform integration (many EHRs, one API)	6-12 weeks build + subscription	$25,000-$70,000 + platform fees
Bidirectional read/write with HL7 v2 feeds	3-6 months	$60,000-$150,000+

The time rarely goes where founders expect. Writing the API client is quick; the schedule is dominated by vendor onboarding, mapping edge cases in real-world data, security review, and testing against sandboxes that never quite match production. This is why a QA-first discipline pays off in healthcare integration. CodeVix Labs builds and integrates healthtech products this way—treating the mapping and test layer, not the happy-path code, as the real deliverable. You can see the shape of that work on our portfolio, and get a scoped estimate via pricing or a short conversation.

What compliance and security rules apply to EHR integration?

Every EHR integration touches PHI, so compliance is not optional. In the US that means HIPAA—encryption in transit (TLS 1.2+) and at rest, least-privilege access, immutable audit logs, and signed Business Associate Agreements with every vendor in the data path, including your aggregator. In Europe and the UK, GDPR (and UK GDPR) govern lawful basis, data minimisation, and patient rights; the NHS adds its own Data Security and Protection Toolkit. Enterprise health buyers will also expect SOC 2. For the concrete controls, work through our HIPAA compliance checklist for software teams before connecting to a single live system.

Frequently asked questions

Is HL7 v2 still relevant, or can I just use FHIR?

HL7 v2 is still very much in use—it underpins a large share of real-time hospital messaging worldwide and will for years. Build new, patient-facing, and greenfield work on FHIR, but expect to support HL7 v2 whenever you integrate with established hospital feeds. Interface engines can translate v2 into FHIR to bridge the gap.

Do I need to integrate each EHR separately?

With direct vendor APIs, yes—each system has its own registration, credentials, and review. Aggregator platforms exist precisely to avoid this: they expose one normalized (usually FHIR) API across many EHRs. For a startup that needs broad coverage fast, an aggregator is often the pragmatic first move, with direct integrations added later where deeper access is needed.

What is SMART on FHIR?

SMART on FHIR is a set of open specifications that add OAuth 2.0 and OpenID Connect authentication on top of FHIR, plus a standard way for third-party apps to launch inside an EHR with scoped permissions. It is the mechanism that lets an external app securely request patient- or user-level access rather than holding raw credentials, and it is the expected pattern for certified EHR integrations in the US.

How do I test an EHR integration safely?

Never develop against live PHI. Major EHR vendors and aggregators provide sandboxes with synthetic patient data, and open tools like Synthea can generate realistic test records. Validate FHIR resources against the relevant profiles (USCDI in the US, UK Core in the UK), and treat data mapping and error handling as first-class test targets—that is where real-world integrations break.