EHR Integration Guide: HL7, FHIR and SMART on FHIR Costs
EHR integration guide covering HL7, FHIR, SMART on FHIR, Epic and Cerner costs and how to choose the right approach.
Updated
8 min read
815 views
Key takeaways: EHR integration in 2026 5
Compare workflows, access dependencies and estimate inputs before choosing an exchange path.
- Different layers HL7 v2 carries message feeds, FHIR defines resource exchange and SMART adds launch and authorization conventions.
- Pick by use case Choose by the operations and workflow supported in the target environment; confirm access and mapping requirements.
- Separate cost inputs Estimate engineering, vendor dependencies and operating support separately. Confirm applicable fees for the selected APIs and customer.
- Schedule by readiness Confirm access, non-production tests and customer acceptance before committing to a timeline.
- Engine only if needed Assign routing, transformation, replay, reconciliation and monitoring responsibilities before choosing an engine or direct API components.
Scope an EHR connection by the clinical workflow, the resources and operations it needs, the customer environment and the access already available. This EHR integration guide explains where HL7 v2, FHIR and SMART on FHIR fit, then separates engineering work from vendor onboarding, licensing and operation. Use it to prepare a healthcare IT integration brief.
EHR integration scope: HL7 v2 carries message feeds, FHIR defines resources and exchange interfaces, and SMART App Launch adds authorization and launch conventions. They can be used together. A successful sandbox read does not establish production access, write permission or compatibility with every customer environment. Confirm those dependencies before estimating the build.
What EHR integration is and why it is the hard part
EHR integration is the work of connecting your software to an electronic health record system so it can exchange patient and clinical data: demographics, encounters, orders, results, medications and documents. The EHR is the system of record, so your product has to speak its language, pass its security model and reconcile its data without ever corrupting a patient record.
Estimate the connection from its resource mapping, identity rules, authorization and reconciliation work. Vendor onboarding and customer provisioning are separate dependencies. Record who supplies each before agreeing the scope of software integration services.
The standards you will meet: HL7, FHIR and SMART on FHIR
These specifications address different layers of exchange. A project can combine a message feed with FHIR resource access and a SMART launch rather than choose one for every workflow.
HL7 v2 - the legacy workhorse
HL7 v2 is the decades-old messaging standard still running most hospital data feeds. It moves ADT (admit, discharge, transfer), ORM (orders) and ORU (results) messages over an interface engine. It is everywhere, but it is pipe-delimited, loosely implemented and usually needs transformation logic for each site.
FHIR R4 - the modern REST API
FHIR defines structured resources and exchange patterns. For a FHIR R4 connection, inspect the target server's CapabilityStatement and its resource documentation. Support for a resource does not establish support for every interaction, profile or customer configuration. US Core and Bulk Data add separate requirements when they are part of the agreed scope.
SMART on FHIR - apps inside the EHR
SMART App Launch defines authorization and launch conventions around FHIR. The published SMART App Launch 2.2 guidance explains that granted scopes remain constrained by underlying permissions: a permitted search may omit results and an apparently permitted write may still be refused. Shared standards help reuse a design, but each target needs its own access, profile and workflow checks.
HL7 vs FHIR vs SMART on FHIR: which to use
The short rule: HL7 v2 for legacy message feeds, FHIR for modern API access and SMART on FHIR for apps that launch inside the EHR. The table compares them.
| Standard | Best for | Transport and auth | Build effort | Maintenance |
|---|---|---|---|---|
| HL7 v2 | Legacy message feeds (ADT, ORM, ORU) | Often MLLP; deployment security is separate | Depends on feeds and transforms | Maintain site-specific mappings |
| FHIR R4 | Modern API access to clinical data | REST; target authorization must be configured | Depends on resources and operations | Maintain profiles and API versions |
| SMART on FHIR | Apps that launch inside the EHR | OAuth 2.0 + OpenID Connect | Shared launch conventions with target-specific setup | Retest access and workflow in each environment |
How much EHR integration costs in 2026
Separate the engineering estimate from fees paid to the EHR vendor or customer environment. This guide does not establish a fixed 2026 market rate or a Pharos Production quote. The scope table identifies the inputs needed for a project estimate.
| Cost component | What to establish |
|---|---|
| Read-only connection | Resources, profiles, patient matching, completeness checks and the target environment |
| Write-back | Supported write operations, authorization, validation, correction workflow and clinical acceptance owner |
| HL7 feeds | Message types, site mappings, acknowledgements, replay and interface engine responsibilities |
| Vendor and environment fees | Confirm applicable licensing, provisioning and optional services directly with the vendor and customer |
| Operation | Monitoring, incident handling, version changes, reconciliation and support coverage |
Write-back adds decisions about validation, correction and responsibility for the destination record. A read-only workflow still needs identity and completeness tests. Compare the actual operations with your integration team, rather than estimate from the protocol name alone.
Ongoing cost: interfaces are not one-time
Budget for monitoring, failed messages or requests, reconciliation, support and API version changes. Set the operating estimate from the agreed interfaces, service coverage and customer responsibilities. A standards-based connection still requires maintenance and regression checks when a target changes.
How long EHR integration takes
Separate engineering milestones from access and customer implementation dependencies. Schedule commitments need a named owner and evidence for each gate below.
| Gate | Evidence required |
|---|---|
| Access | Registered application, customer environment and confirmed operations |
| Non-production test | Expected mappings, permission failures and incomplete-response handling |
| Customer acceptance | Agreed workflow, reconciliation results, correction process and release approval |
A sandbox demonstration completes only part of this sequence. Customer provisioning, workflow configuration and acceptance can remain open after the application code is ready.
How to integrate with Epic and Cerner specifically
Epic's developer guide describes a federated model in which customers control their connections. Developers can use self-service registration and testing; Showroom listing is optional after a customer go-live. Do not treat a listing or a universal paid certification as a prerequisite for every integration. For Oracle Health, consumer access and provider/system access have different onboarding paths. Its listed value-added developer services are optional and are not a universal API licensing tariff.
Vendor, environment and operation matrix
References checked on September 30, 2026. Use this matrix to request target-specific confirmation; it does not promise support for a particular resource or write operation.
| Target | Environment and operations | Access and fee dependency |
|---|---|---|
| Epic | Distinguish non-production testing from the named customer instance. Identify each required read, search or write operation. | Confirm client registration, distribution and customer implementation. Ask the customer and Epic which licensing terms apply to the selected APIs. |
| Oracle Health | Specify Millennium Platform or Soarian Clinicals and consumer, provider or system access. Check the documented resources and operations. | Follow the applicable registration path. Separate optional developer services from customer provisioning and any applicable contractual fees. |
| Each additional EHR | Record endpoint, version, profile, operation and launch context. Retest mappings and permissions. | Obtain that target's access requirements and fee confirmation. Approval for one vendor or customer does not transfer automatically. |
Do you still need an interface engine?
An interface engine such as Mirth Connect or Rhapsody routes, transforms and monitors HL7 v2 messages between systems. If your integration is HL7 v2 heavy, with many feeds and per-site quirks, an interface engine still earns its place. For a pure FHIR or SMART on FHIR integration you often do not need one, since the REST API and standard auth do that work. Many real deployments run a hybrid: an engine for legacy HL7 feeds and FHIR for everything new.
Security and compliance in EHR integration
Determine which data and parties fall within the applicable privacy obligations. The HHS scope guidance distinguishes covered entities and business associates; a BAA is not required merely because any party touches health data. For workflows subject to HIPAA, identify the required business associate relationships and agreements. Engineering controls include access checks, audit records and protected transport. Use the HIPAA software development cost guide for cost planning and involve cybersecurity for the agreed technical scope.
How to control EHR integration cost
- Choose the exchange path from the workflow. Reuse standards-based components where the target supports them, then test the site-specific mappings and permissions.
- Scope read versus write tightly. Include write-back only where the workflow needs it and the target supports the required operation.
- Inspect reusable connectors. Confirm their resource coverage, version, access conditions and correction behavior before relying on them.
- Budget maintenance from day one. Treat each interface as a yearly cost, not a one-time delivery.
- Start with one EHR. Prove the integration on a single platform, then expand using the same FHIR and SMART foundation built by a software development team with healthcare experience.
Synthetic acceptance example: block an unsafe delivery
Synthetic application check: this in-memory fixture tests a delivery gate with invented records. It does not connect to an EHR, implement SMART authorization or establish vendor certification or clinical safety. The version is ehr-application-acceptance-v1.
The agreed input permits a read for synthetic-patient-a and requires status and value. The gate checks the operation, patient identifier and required fields before making data ready for review.
| Test | Changed input | Expected and observed outcome |
|---|---|---|
| Approved read | Expected patient with both required fields | READY_FOR_REVIEW |
| Refused write | Write operation in a read-only scope | BLOCK_SCOPE |
| Wrong patient | Response identifies synthetic-patient-b | BLOCK_IDENTITY |
| Partial response | Required value field omitted | BLOCK_COMPLETENESS |
A blocked case stays out of delivery and goes to the application owner for investigation. The example uses application outcomes rather than vendor HTTP status codes. Project owners must define the real identity, completeness and clinical acceptance rules; passing these four checks does not establish production readiness.
Inspect the synthetic inputs and checked outputs as JSON. Before requesting an estimate, record the vendor, environment, resource operations, existing access and unresolved acceptance decisions.
How Pharos Production delivers EHR integration
Bring your vendor, environment, resource operations and existing access to a scoped discussion with our healthcare IT solutions and software integration teams. Agree the engineering deliverables, customer dependencies and acceptance responsibilities before committing to a budget or schedule.
Primary references checked September 30, 2026: Epic Developer Resources, Oracle Health API Access and Fees, HL7 FHIR R4 CapabilityStatement, SMART App Launch 2.2 and HHS covered entity/business associate guidance, linked in the relevant sections. Vendor conditions can change. The acceptance fixture is synthetic and is not evidence of a client implementation.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
How much does EHR integration cost?
Estimate the engineering work from the resources, operations, mappings and acceptance checks. Separately confirm vendor licensing, customer provisioning, optional developer services and operating support.
A sandbox read does not establish the cost of production access. This guide supplies estimate inputs rather than a fixed market tariff or project quote.
-
What is the difference between HL7 and FHIR?
HL7 v2 carries message feeds such as admissions, orders and results. FHIR defines structured resources and exchange patterns. A deployment can use both. Compare the actual feeds, transformations, resource operations and target support; the protocol name alone does not establish build or maintenance cost.
-
What is SMART on FHIR?
SMART App Launch defines authorization and launch conventions around FHIR. Granted scopes remain limited by the underlying permissions, so a response may be filtered or an operation refused. Reusable components still need access, resource and workflow tests in each customer environment.
-
How long does EHR integration take?
Schedule the build against confirmed access, a non-production test and customer acceptance. Registration, provisioning, mappings, write validation and correction responsibilities can remain unresolved after a sandbox demonstration.
Agree those gates and their owners before committing to a project timeline.
-
How do you integrate with Epic?
Register the required APIs and client record, test the workflow and arrange implementation in the target customer environment. Epic describes self-service development and customer-controlled connections.
Showroom listing is optional after a customer go-live; it does not substitute for the target access and operation checks.
-
Is FHIR replacing HL7?
FHIR and HL7 v2 serve different exchange needs and can coexist. Inspect the target resources, interactions and message feeds before selecting the approach. Support for a FHIR resource does not establish every operation, profile or customer configuration, and SMART adds launch and authorization conventions rather than replacing the message workflow.
-
Do you need an interface engine?
An interface engine can provide routing, transformation, acknowledgements, replay and monitoring for message workflows. A direct API connection still needs explicit decisions about transformation, retries, reconciliation and operations.
Choose an engine or application components from those responsibilities rather than assume that REST and authorization supply them all.
EHR integration glossary 5
- EHR (Electronic Health Record)
- The digital system that stores the medical history of a patient, used by hospitals and clinics.
- HL7
- A long-standing messaging standard for exchanging clinical and administrative healthcare data between systems.
- FHIR
- A modern HL7 standard that exchanges healthcare data over web APIs using discrete resources.
- SMART on FHIR
- A specification that lets third-party apps securely connect to EHR data using FHIR and OAuth 2.0.
- Interoperability
- The ability of systems to exchange data and use it in an agreed workflow, with compatible formats and meanings.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
