Most EHR integration projects end up as hybrids. You use HL7 v2 where the hospital already runs high-volume legacy interfaces, FHIR where modern API access fits the data and workflow, and vendor-specific APIs when the EHR vendor exposes a supported path that saves time or reduces maintenance risk. The teams that struggle are the ones who pick a standard in the abstract and then try to force every workflow through it. The teams that ship pick the right tool for each interface.
This guide covers what you are actually connecting, how the three main approaches differ, when each one fits, what drives cost and timelines, and where projects stall. It is written for CIOs, CTOs, product leaders, and founders who need to plan an EMR integration for a clinical product, analytics platform, telehealth tool, patient app, or internal hospital system.
What EHR integration actually has to connect
Before choosing a protocol, define the data objects and events your product needs. Most projects touch some combination of these:
- Demographics and patient identity. ADT feeds, MRN lookups, patient matching across systems.
- Appointments and scheduling. Slot availability, booking, check-in status, cancellations.
- Clinical notes and documents. Progress notes, discharge summaries, referral letters, scanned forms.
- Labs and observations. Lab orders, results, vitals, flowsheet data.
- Medications and allergies. Active medication lists, allergy alerts, prescription history.
- Orders and results. CPOE orders, radiology orders, pathology results.
- Billing and claims-adjacent data. Charge capture, procedure codes, insurance eligibility checks.
- Referrals and care plans. Referral routing, care plan documents, transition-of-care summaries.
- Device and remote-monitoring data. Wearable readings, RPM device feeds, patient-reported outcomes.
- Analytics and reporting feeds. Bulk data exports, population health extracts, quality measure data.
A working interface is not enough. Each of these integration points needs clear ownership, field-level data mapping, error handling, monitoring, consent and security controls, audit logging, and a production support model. If your plan does not account for those, you have a demo, not an integration. For a broader look at how these pieces fit into a full EHR build, see this guide on EHR software development.
HL7, FHIR, and vendor APIs: how the options differ
HL7 v2
HL7 v2 is a message-based standard that has been running in hospitals since the late 1980s. It uses pipe-delimited segments (ADT, ORM, ORU, SIU, MDM, and others) sent over TCP/IP connections, often through an interface engine like Mirth Connect, Rhapsody, or Cloverleaf. It is event-driven: a patient is admitted, a lab result is finalized, an order is placed, and a message fires.
HL7 v2 is not elegant. Message structures vary between vendors, between hospitals, and sometimes between departments in the same hospital. But it is deeply embedded in clinical infrastructure. If you need real-time ADT events, lab results, or order feeds from a hospital that has been running for 20 years, HL7 v2 is almost certainly what the interface engine already speaks.
FHIR
FHIR (Fast Healthcare Interoperability Resources) uses a resource-and-API model built on web standards: REST, JSON or XML, OAuth, HTTP. It combines ideas from HL7 v2, HL7 v3, and CDA and supports mobile apps, cloud communication, EHR-based data sharing, and large provider environments.
FHIR is a better fit for app-based access, patient-facing data, and modular clinical reads. SMART on FHIR adds app launch context and scoped authorization. The ONC Cures Act Final Rule requires certified EHR systems to support standardized APIs so patients can access structured health information through apps, which has pushed FHIR adoption forward.
But FHIR is not zero-mapping integration. Local agreements and adaptations are common. Resource coverage varies by vendor and version. Write-back support is limited in many implementations. And the CMS Patient Access API requirements make clear that large unstructured documents do not automatically become discrete FHIR resources; mapping and data quality still matter.
Vendor APIs
Epic, Cerner (now Oracle Health), athenahealth, Allscripts, and other EHR vendors each expose proprietary APIs, SDKs, app marketplaces, bulk export paths, and portal-level endpoints. These range from well-documented RESTful APIs with sandbox environments to legacy SOAP services with limited documentation.
Vendor APIs can offer capabilities that generic standards do not cover: scheduling workflows specific to that EHR, in-context app embedding, vendor-managed authentication, and pre-built data models that match the EHR's internal schema. The trade-off is lock-in. You build to one vendor's surface, you go through their certification and review process, and you accept their release cycle and deprecation timeline.
For a deeper comparison of standards and how they relate to broader interoperability in healthcare, that resource covers the protocol-level details.
A quick way to compare them:
- HL7 v2: event-driven messages over TCP/IP, usually managed through an interface engine. Best for ADT, labs, orders, results, and legacy feeds.
- FHIR: RESTful resources over HTTPS. Best for patient apps, clinician apps, modular clinical reads, and SMART on FHIR launch patterns.
- Vendor APIs: EHR-specific endpoints, SDKs, or marketplace paths. Best for single-EHR workflows and embedded apps when the vendor offers a supported route.
When each EHR integration approach fits
Choose HL7 v2 when you need stable event streams for ADT, lab results, orders, or radiology workflows. If the hospital already runs an interface engine and the data you need flows through existing message types, HL7 v2 is the path of least resistance. It is also the right choice when the receiving system expects traditional message-based feeds.
Choose FHIR for patient-facing apps, clinician-facing apps that need on-demand clinical reads, third-party app access under SMART on FHIR, consent-aware data exchange, or workflows where you need to query specific resources rather than subscribe to a firehose of events. FHIR also makes sense when regulatory requirements point you toward standardized API access.
Choose vendor APIs when a supported vendor route exists for your specific workflow, when your product lives inside one EHR ecosystem, or when vendor review and ongoing support are worth the constraint. App marketplace listing, embedded launch, and vendor-managed identity are real advantages if your product fits the model.
Use a hybrid when you are integrating across multiple sites, EHR vendors, or workflow types. A telehealth platform might use FHIR for patient-facing data access, HL7 v2 for real-time scheduling and results feeds from the hospital, and a vendor API for embedded launch inside the EHR. This is normal. Plan for it.
Cost and timeline drivers in EHR integration
There is no single price for EHR integration. Ranges depend on scope, vendor cooperation, and organizational readiness. Here is what shapes the numbers:
Simple read-only FHIR or API integration with a cooperative sandbox: Often a few weeks of development after access is approved. The approval itself can take longer than the build.
HL7 v2 feed through an existing interface engine: A few weeks to a few months, depending on the number of message types, field-level mapping complexity, testing rigor, and who owns the interface engine queue.
Multi-site integration with patient identity, bidirectional writes, consent, audit, failover, monitoring, and vendor review: Several months or longer. Projects that span multiple EHR vendors or require write-back to clinical workflows routinely take six months to a year when you include certification and go-live.
The factors that drive cost and timeline most:
- Vendor access and certification. Some vendors grant sandbox access in days. Others require partnership agreements, security reviews, and marketplace certification that take months.
- Data mapping and terminology. Translating between local code sets, SNOMED, LOINC, ICD-10, RxNorm, and your internal data model is where much of the real work lives.
- Number of interfaces. Each message type, resource, or endpoint is its own mapping, testing, and monitoring surface.
- Bidirectional writes. Reading data is simpler than writing it back. Write-back requires clinical validation, error handling for rejections, and often vendor-specific approval.
- Patient identity matching. Matching patients across systems without creating duplicates is a problem that scales with volume and complexity.
- Environment and test data quality. Sandbox data that does not resemble production data leads to surprises at go-live.
- Security review and BAA execution. PHI handling, encryption, access controls, and business associate agreements take time and legal review.
If you need help scoping an integration project or evaluating vendor options, IT consulting services focused on healthcare can compress the discovery phase.
Common pitfalls that delay EHR integration
Assuming FHIR means plug-and-play. FHIR is a standard, not a product. Two FHIR R4 implementations can expose different resources, support different search parameters, and handle extensions differently. You still need to test against each target system.
Skipping field-level mapping and terminology work. "We'll just pull the patient resource" ignores the reality that a medication list in one system uses NDC codes while another uses RxNorm, and a third stores free-text drug names.
Building before vendor API access is confirmed. Teams sometimes spend months building against public documentation only to discover that production access requires a partnership tier, a security review, or a marketplace listing they had not planned for.
Treating sandbox success as production readiness. Sandbox environments are clean. Production environments have malformed messages, missing fields, duplicate patients, downtime windows, and interface engine queues that back up on Monday mornings.
Ignoring patient matching and duplicates. Without a clear patient identity strategy, you will create duplicate records, merge errors, or data that lands on the wrong chart.
Weak exception handling and retries. Interfaces fail. Messages get rejected. APIs return 429s. If your integration does not handle retries, dead-letter queues, and alerting, you will lose data silently.
No monitoring or interface ownership. Someone needs to watch the interface after go-live. If nobody owns it, failures go unnoticed until a clinician reports missing data.
Putting integration logic in the application layer. Embedding HL7 parsing, FHIR calls, and data transformation directly in your app makes every change risky. A separate integration layer with its own versioning and observability is easier to maintain.
Vague BAAs and security responsibilities. If your BAA does not specify who is responsible for encryption at rest, access logging, breach notification, and data retention, you have a compliance gap.
Implementation roadmap
Phase 1: Define the workflow. Start with the clinical or operational workflow, not the standard. What does the user need to do? What data moves, when, and between which systems? Document the workflow before you pick a protocol.
Phase 2: Choose data objects and events. Map the workflow to specific data types: ADT events, lab results, medication lists, appointment slots. This determines which interfaces you need and which standards or APIs cover them.
Phase 3: Confirm vendor and interface engine access. Apply for sandbox credentials, confirm API availability, check interface engine capacity, and understand the vendor's certification or review process. Do this early because it is often the longest lead-time item.
Phase 4: Map data and terminology. Build field-level mapping documents. Identify code set translations. Flag fields that are optional in the standard but required in your workflow. This is where you find the gaps.
Phase 5: Design security, consent, audit, and PHI handling. Define authentication, authorization scopes, consent enforcement, audit log structure, encryption requirements, and data retention policies. Execute BAAs.
Phase 6: Build the integration layer. Implement with retries, queues, dead-letter handling, observability, and versioning. Keep integration logic separate from application logic. This makes production fixes safer when the EHR vendor changes an endpoint, field, or message variant.
Phase 7: Test with realistic scenarios. Use production-like data volumes, malformed messages, missing fields, duplicate patients, and downtime simulations. Test error paths as thoroughly as happy paths.
Phase 8: Pilot with one site or workflow. Go live with a single department, location, or workflow. Monitor closely. Collect feedback from clinical users.
Phase 9: Monitor and tune. Track message volumes, error rates, latency, and data quality metrics after launch. Adjust mapping, retry logic, and alerting thresholds based on real production behavior.
For teams building custom healthcare software that needs to connect with existing clinical systems, this phased approach reduces risk at each stage.
