EHR Integration, Step by Step: HL7, FHIR, and What to Actually Do

EHR integration is the process of connecting your application to an electronic health records system so that patient data flows securely between them. In 2026, that almost always means building against FHIR R4 APIs, signing Business Associate Agreements with every vendor that touches PHI, and navigating a hospital IT approval process that will take longer than the actual coding. Plan for 4 to 9 months minimum for a clean integration, and budget $60,000 to $200,000+ for your first Epic connection.

This is not a piece about why interoperability matters in the abstract. I’ve integrated with Epic, Oracle Health, and half a dozen smaller EHR systems across companies I’ve co-founded and advised as a fractional CTO. What follows is how it actually works.

What Is EHR Integration and Why Does It Matter Now?

An EHR integration creates a data channel between your software and a hospital or clinic’s records system. That channel can read patient demographics, clinical notes, lab results, medications, and appointments, or it can write back care plan updates and results. Without it, clinicians copy-paste data between screens, orders get missed, and your product sits outside the actual clinical workflow.

The regulatory environment has shifted dramatically in recent years. The ONC’s 21st Century Cures Act Final Rule mandates that certified EHR developers expose standardized FHIR R4 APIs and prohibits information blocking. ONC received 2,124 possible information blocking claims between April 2021 and May 2026, with provider enforcement via the OIG beginning July 31, 2024. The rules have teeth now.

For health plans and payers, the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) mandates four FHIR R4-based APIs (Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization) by January 2027.

The market has responded: 84% of hospitals had adopted certified FHIR-enabled API technology by 2024, and 70% of US hospitals had enabled patient access using FHIR-configured apps, up from 57% in 2021. If you are building any kind of health-tech product, FHIR R4 integration is no longer optional infrastructure.

HL7 v2 vs FHIR: What Is the Actual Difference?

This is the question I get most often from founders who are new to healthcare software. The short answer: HL7 v2 is the legacy message format that still runs most hospital back-office systems; FHIR (Fast Healthcare Interoperability Resources) is the modern REST-based standard that regulators now mandate.

Here is what I want to be honest about: 57% of digital health companies currently use both standards-based and proprietary APIs in production. HL7 v2 is not dead. Most hospitals still send ADT (admission, discharge, transfer) notifications over HL7 v2 MLLP pipes. If your use case involves real-time bed management or lab results streaming directly from instruments, you will likely need an HL7 v2 listener in addition to your FHIR client. I have never seen a production healthcare integration that was purely one or the other.

What Is SMART on FHIR?

SMART on FHIR is an authorization framework layered on top of FHIR. It uses OAuth 2.0 to allow your application to launch within an EHR’s clinical interface, request scoped access to specific resource types (for example, patient/Observation.read), and receive tokens that gate your API calls.

You need SMART on FHIR if any of the following apply:

• Your app launches inside Epic’s Hyperspace or Oracle Health’s PowerChart
• You want clinicians to authorize access with a single sign-on click, not a separate login
• You are building a patient-facing app that uses the EHR’s patient portal as an identity provider

If your integration is purely backend-to-backend (your server pulling data on a schedule), you typically use the Client Credentials flow instead, which does not involve SMART launch sequences.

Who Are the EHR Vendors You Actually Encounter?

Before you write a line of code, you need to know which EHR you are integrating with, because each has a distinct developer program, fee structure, and approval process.

Epic holds 42.3% of US acute care hospitals by count and 54.9% by bed count as of end-2024, while Oracle Health (formerly Cerner) holds 22.9% by hospital count. Together they cover roughly two-thirds of the acute care market. If you can only support two integrations in your first product cycle, start with Epic.

Notably, hospitals using Epic were significantly more likely to have FHIR-enabled app access (83%) compared to those using other EHR developers (56%), according to ONC data from 2024.

Epic Developer Program (Showroom): In 2024 Epic renamed App Orchard to Showroom. There are three tiers: Connection Hub ($500/year), Toolbox, and Workshop. Epic provides approximately 450 FHIR R4 API endpoints across 55 resource types, and its FHIR APIs process over 1 billion transactions monthly. You work in Epic’s sandbox environment (non-production MyChart or Hyperspace) before any production access.

Oracle Health Developer Portal: Oracle Health maintains its own developer sandbox and certification process. The approval timelines are generally comparable to Epic, though the documentation can be harder to navigate. Expect similar BAA requirements and per-site credentialing.

Other EHR systems (athenahealth, Modernizing Medicine, Meditech, Allscripts) have their own portals, all of which expose FHIR R4 under ONC certification requirements. The patterns are similar; the specifics differ.

Step-by-Step: How EHR Integration Actually Works

I am going to walk through this as a numbered process because the sequence matters. Skipping steps or parallelizing the wrong phases will cost you weeks.

Step 1: Define Your Data Contract Before Touching Any API

Identify exactly which FHIR resource types you need and what you will do with them. Common resource types: Patient, Encounter, Condition, Observation, MedicationRequest, DiagnosticReport, DocumentReference, Appointment. Map each resource type to a specific feature in your product. This data contract becomes the spec for your sandbox work and your Showroom submission.

Step 2: Apply for Sandbox Access (2 to 6 Weeks)

For Epic, submit an Access Application at open.epic.com. You will describe your use case, request specific API scopes, and agree to Epic’s terms of use. This is a real review, not an instant approval. For Oracle Health, apply through the Oracle Health Developer Portal. Either way, plan for a 2 to 6 week wait before you have a working sandbox environment.

Step 3: Build and Validate in the Sandbox (4 to 10 Weeks)

This is where your engineers write the actual integration code. A FHIR R4 client is a REST client with OAuth 2.0 or SMART token management and JSON deserialization into your data model. The work includes:

• OAuth 2.0 / SMART launch flow implementation
• Resource fetching, pagination (_count, Bundle.link traversal), and error handling
• Data mapping from FHIR resources to your application’s domain model
• Edge-case handling: missing fields, unsupported extensions, partial responses

One of the most common complaints I hear from engineering teams is that sandbox data is unrealistic. 41% of digital health companies cite lack of realistic clinical testing data as a substantial barrier to EHR API integration. Epic’s sandbox has synthetic patients, but the data sparsity does not always reflect what you see in production. Build your parser defensively.

Step 4: Complete HIPAA Compliance Before Production Access

You cannot get production access without a signed Business Associate Agreement in place with the EHR vendor and every middleware layer touching PHI. This is not optional or deferrable. OCR collected over $9.9 million in HIPAA settlements across 22 enforcement actions in 2024, with BAA deficiencies cited as a contributing factor in multiple cases.

The compliance checklist before production access:

• BAA with Epic or Oracle Health (they have standard forms)
• BAA with any cloud infrastructure provider handling PHI (AWS, GCP, Azure all have BAA programs)
• BAA with any integration middleware (Mirth Connect, Azure API for FHIR, etc.)
• Encryption in transit (TLS 1.2 minimum) and at rest
• Audit logging for all PHI access (who accessed what, when)
• Access controls: least-privilege for API credentials

A note on the proposed HIPAA Security Rule NPRM: it would make encryption mandatory rather than “addressable.” Treat encryption as mandatory regardless of whether the final rule has passed by the time you read this.

Step 5: App Orchard / Showroom Review (4 to 12 Weeks)

Before you can connect to a live hospital, Epic requires Showroom listing review. You submit documentation of your use case, security posture, and testing evidence. This review is done by Epic’s team and has no guaranteed turnaround SLA. Budget 4 to 12 weeks. Oracle Health has an equivalent certification step.

Step 6: Hospital IT Approval (4 to 16 Weeks, the Real Bottleneck)

This is the phase that surprises every first-time health-tech founder. Even after Showroom approval, each hospital’s IT and security team runs its own review. They will ask for your SOC 2 report (or equivalent), your BAA, your penetration test results, a data flow diagram, and sometimes a vendor questionnaire that runs to 200 items. The review committee may meet monthly. One hospital approval can add 4 to 16 weeks to your timeline, and you are doing this for every customer.

Build relationships with hospital IT governance teams early. If your first customer has a champion inside the institution, that person can move things faster than any technical optimization you make.

Step 7: User Acceptance Testing (2 to 6 Weeks)

With production credentials in hand, run UAT with the clinical staff who will actually use the integration. Data mapping bugs that were invisible in the sandbox become visible here. FHIR extensions that Epic uses for Epic-specific metadata (.meta.tag, custom extensions) often carry data you need but that is not in the base spec.

Step 8: Go-Live and Ongoing Maintenance (1 to 4 Weeks, then Forever)

Go-live is a cutover, not a finish line. Monitor your API error rates, token refresh failures, and data mapping exceptions. EHR vendors release API updates, and your FHIR client needs to track them. Budget 20 to 30% of your initial build cost annually for maintenance.

Realistic Cost and Timeline Ranges

Based on what I have seen across multiple integration projects and supported by published data from healthtech consultants:

First Epic integration cost: $60,000 to $200,000+ depending on complexity, team rates, and how many resource types you need. This includes engineering, compliance documentation, and vendor fees, but not ongoing maintenance.

Common Pitfalls I Have Seen Teams Hit

Treating compliance as a final gate. Teams that defer HIPAA BAA paperwork until after build completion routinely add two to three months to their timeline. Start compliance in parallel with sandbox development.

Underestimating data mapping complexity. FHIR resources are typed, but the content varies wildly between EHR systems. A Condition resource in Epic is populated differently from the same resource in Oracle Health. Write mapping tests against real de-identified data, not just synthetic records.

Missing the fee model. 47% of digital health companies cite high fees as a substantial barrier to EHR API integration. Middleware transaction costs at scale ($0.005 to $0.02 per call) compound rapidly. Model your API call volume before finalizing architecture choices.

One-integration-at-a-time thinking. If you need to support more than one hospital, invest in an abstraction layer early. A thin interface that normalizes FHIR responses across EHR vendors will save you from parallel codebases.

Ignoring interoperability reality. 69% of providers report significant interoperability issues between their EHR and other systems. Your integration will surface data quality issues that exist in the source EHR. Plan for missing, duplicated, or inconsistently formatted records.

Compliance Touchpoints: What Runs in Parallel

EHR integration involves three distinct compliance tracks that must run concurrently:

1. ONC FHIR certification compliance: Your EHR vendor is certified; your integration must use the certified APIs and not circumvent them. The information blocking provisions apply to developers, too.
2. HIPAA: BAAs with every vendor, encryption, audit logging, access controls, breach notification procedures. This is your compliance surface area, not the EHR vendor’s.
3. CMS API mandates (for payer-side integrations): If your product touches health plans, the CMS Interoperability Final Rule sets specific FHIR R4 API requirements with January 2027 deadlines for payers.

These are three separate checklists. I have seen teams conflate “we use FHIR” with “we are HIPAA compliant.” They are not the same thing. I always recommend engaging a healthcare compliance attorney before production launch, not after.

How EHR Integration Fits Your Healthcare Website and Product Strategy

If you are building in healthcare, your product’s public-facing digital presence needs to speak to the technical credibility you are building. I have written about this in the context of healthcare website design, specifically how trust signals, compliance transparency, and integration documentation visible to procurement teams accelerate sales cycles. A well-documented integration story on your website reduces the friction during hospital IT review, because your security posture is already visible.

The HIE market is estimated at $1.97 billion in 2024 and projected to reach $3.44 billion by 2029. Integration capability is increasingly a table-stakes requirement, not a differentiator. The differentiation is in how fast you can integrate, how reliably you maintain it, and how well you handle the edge cases that break competitors.

Frequently Asked Questions

What is EHR integration and how does it work?

EHR integration connects your application to an electronic health records system so that patient data such as demographics, clinical notes, lab results, and medications can flow securely between them. It works by calling the EHR vendor’s APIs (typically FHIR R4 REST endpoints in 2026) using OAuth 2.0 tokens, deserializing the returned JSON resources, and mapping them to your application’s data model. The process also requires signed HIPAA Business Associate Agreements and, for major EHR systems like Epic, completion of a vendor certification program before production access is granted.

What is the difference between HL7 v2 and FHIR?

HL7 v2 is a legacy message format that uses pipe-delimited text segments transmitted over MLLP connections. FHIR (Fast Healthcare Interoperability Resources) is a modern REST-based standard using typed JSON or XML resources over HTTPS. The ONC’s Cures Act Final Rule mandates FHIR R4 for certified EHR developers, making it the regulatory baseline for new integrations. That said, 57% of digital health companies still use both in production because HL7 v2 pipelines remain common for ADT feeds and lab results from older hospital systems.

How do you integrate with Epic’s FHIR API?

You start by applying for access at open.epic.com, wait 2 to 6 weeks for approval, build and test against Epic’s sandbox using their FHIR R4 endpoints, then submit for Showroom review (4 to 12 weeks). After Showroom approval, each hospital customer runs its own IT security review before granting production credentials. Epic provides roughly 450 FHIR R4 endpoints across 55 resource types. The Showroom Connection Hub tier costs $500 per year.

How long does EHR integration take?

A clean first integration typically takes 4 to 9 months end-to-end. Complex workflows with multiple resource types and bidirectional data flows can run 12 to 18 months. The biggest time sink is not the API coding: it is hospital IT approval (4 to 16 weeks per institution) and vendor certification review (4 to 12 weeks). These phases cannot be meaningfully parallelized.

How much does EHR integration cost?

A first Epic integration project typically runs $60,000 to $200,000+, covering engineering time, compliance documentation, and vendor fees. Transaction costs for middleware at scale add $0.005 to $0.02 per API call. Budget 20 to 30% of the initial build cost annually for ongoing maintenance as the EHR vendor evolves its APIs. The 47% of digital health companies that cite high fees as a barrier in published research are not wrong; this is expensive infrastructure.

What is SMART on FHIR and do I need it?

SMART on FHIR is an OAuth 2.0-based authorization framework that allows your app to launch inside an EHR’s clinical interface and receive scoped tokens for specific FHIR resource types. You need it if your app launches within Epic Hyperspace or Oracle Health PowerChart, or if you want clinicians to authorize access with a single click. If your integration is purely backend-to-backend (server pulling data on a schedule), you typically use Client Credentials flow instead and do not need SMART launch sequences.

What HIPAA compliance steps are required for EHR API integration?

At a minimum: sign a Business Associate Agreement with the EHR vendor and every infrastructure or middleware layer that touches PHI, enforce TLS encryption in transit and encryption at rest, implement audit logging for all PHI access, and apply least-privilege access controls to API credentials. OCR collected over $9.9 million in HIPAA settlements across 22 enforcement actions in 2024, with BAA deficiencies cited repeatedly. Start compliance in parallel with sandbox development, not after it. I also recommend engaging a healthcare compliance attorney before production launch.

Working With a Fractional CTO on Your EHR Integration

I have led EHR integrations from the first API application through production go-live at multiple healthcare startups. The pattern that works is parallel-tracking compliance and engineering from week one, building defensively against real-world data quality issues, and managing the hospital IT approval process as a relationship-building exercise, not a technical one.

At Sparkable, I work with healthcare founders as a fractional CTO, bringing a dedicated engineering team that has shipped FHIR integrations in production. You own all IP. Engagements start at $2,000 per month.

If you are about to start an EHR integration and want to pressure-test your approach before spending six months on it, book a free consultation. I will tell you honestly what the timeline looks like for your specific use case and where the likely bottlenecks are.

Disclaimer: This article is B2B technical guidance for software builders and healthcare founders, not medical advice to patients or legal advice to organizations. Regulatory requirements, fees, and timelines are based on publicly available sources and real-world experience as of 2026, but compliance specifics should be confirmed with qualified legal and clinical counsel for your specific situation.