EHR Software Integrations: A Guide to HL7, FHIR, and the Build-vs-Buy Decision

Core insight

Connecting your product to an EHR is one of the hardest, most expensive parts of building digital health software. Technically, there are three routes - integration middleware, direct vendor APIs, or a custom integration layer. Strategically, the question is who owns that work: a platform, a specialized partner, or your own internal team - and the right answer is tied to your company's stage. Middleware gets you to market fast but grows expensive and rigid at scale, which is when companies move integrations to a partner or in-house. Underneath it all sit FHIR R4, legacy HL7 v2, and an evolving regulatory landscape.

What EHR integration actually means

EHR integration is the work of connecting your product to an electronic health record system so the two can exchange clinical and administrative data. It can mean reading information out of the EHR, writing it back, or both. In practice, it is moving records such as patient demographics, encounters, orders, lab results, medications, allergies, and clinical notes between your application and platforms like Epic, Oracle Health (formerly Cerner), athenahealth, or MEDITECH.

Direction of data flow is one of the biggest drivers of complexity. A read-only integration pulls information into your product to give clinicians context - a patient's medical history, for example. A bidirectional integration also writes back into the EHR, so documentation generated by your application becomes part of the patient's official record. Write-back significantly increases engineering effort, expands the compliance scope, and typically requires more rigorous validation.

That distinction - read-only versus bidirectional, multiplied by how many systems you support - is one of the strongest drivers of cost and timeline.

Why it's still hard in 2026

There are many reasons why EHR integration is still one of the most time-consuming and expensive parts of building a digital health product.

Market fragmentation. Epic and Oracle Health dominate much of the U.S. acute care market, but they are not the only solutions available. Hundreds of systems serve ambulatory care, behavioral health, long-term care, and specialty practices, each exposing its own APIs, workflows, and quirks. Experience integrating with Epic transfers only partly to a platform like athenahealth or eClinicalWorks.

Uneven implementation of standards. FHIR has become the primary interoperability standard for modern U.S. healthcare APIs. In some cases, it's even required: for certified health IT and for payers (health insurers). Implementation still varies widely, though - across vendors, and even across different customer deployments of the same EHR. What is more, even if a system supports the data that's needed, it's possible that an organization running it doesn't have a licence to use it, or hasn't enabled it. "FHIR-compatible" rarely means plug-and-play, and a resource that supports write operations in one environment may be read-only or unavailable in another.

Patient matching. The United States still has no national patient identifier. Matching the right record to the right person across organizations is a serious technical problem, and getting it wrong carries clinical consequences.

Vendor onboarding and per-connection cost. Certification programs, licensing, customer onboarding, and site-specific activation mean every new EHR connection adds cost and administrative overhead. What feels manageable across the first two integrations becomes a real operational burden as your customer base grows.

Expanding security and compliance obligations. Every connection increases the PHI your product handles, and with it your HIPAA responsibilities, audit requirements, monitoring, and breach exposure. In this sense, integration is as much a security and compliance initiative as an engineering one.

None of this makes interoperability impossible, but it does explain why the approach that works well for an early-stage product tends to reach its limits as the business scales.

HL7 v2 vs FHIR: which standard does what

Most production integrations rely on two standards, and many real implementations use both at once.

HL7 v2

HL7 v2 remains widely deployed in hospitals, particularly in the U.S. It is an old messaging standard that has carried hospitals for more than three decades. It is mature and battle-tested, but implementations vary from one organization to the next, so parsing, mapping, and transformation account for much of the effort. When you connect to an established hospital interface, HL7 v2 routed through an interface engine is often the underlying technology.

Here is an example of what the standard looks like:

PID|1||MRN0012345^^^MERCY^MR||Johnson^Michael||05/14/1978|M

The fields are separated by a pipe (|) and nothing labels the data - you have to know that the patient's name sits in the fifth field of the PID segment (PID-5) and the date of birth in the seventh (PID-7). That's one of the reasons why parsing and mapping this data is so hard.

FHIR

FHIR is a modern standard from HL7 for exchanging health data, designed around the web technologies that power ordinary apps and websites. Its latest version, FHIR R4, has become the preferred choice for modern interoperability work. It is built around RESTful APIs, JSON, and standardized resources such as Patient, Observation, Encounter, and DocumentReference. It secures access with OAuth 2.0, usually through SMART on FHIR, the standard for app authorization. Every major vendor now exposes FHIR APIs (though coverage and implementation depth vary considerably), and current U.S. interoperability regulation increasingly centers on FHIR-based exchange. For most new integrations in 2026, FHIR R4 is the logical starting point for your interoperability strategy - the standard to reach for first where a source system exposes the capabilities you need, while expecting HL7 v2 wherever existing clinical workflows still depend on it.

Few teams choose one standard exclusively. A single product might retrieve demographics and scheduling through a FHIR API while receiving lab results as HL7 v2 ORU messages, because that is how the source system publishes them. FHIR is cleaner to build against; HL7 v2 still powers a large share of production hospital workflows. Plan for both. Add DICOM (the standard for medical images) if your product handles imaging. And in large, cross-organization setups, expect one more layer: IHE profiles - a set of rules for moving records between institutions. Most teams will not touch IHE profiles directly. But if the healthcare organizations using your product exchange documents across institutional boundaries, this layer will sit somewhere in the path.

Three technical paths to EHR integration

There are three primary approaches to connecting - the technical routes your product takes to reach the data - and each strikes a different balance between speed, flexibility, cost, and long-term ownership. (Who owns and maintains that work - whether you buy, partner, or build in-house - is the separate, strategic question we turn to right after.)

1. Integration middleware. Platforms such as Redox provide a unified API that abstracts away much of the complexity behind individual EHRs. You integrate once with the middleware provider, and they maintain the connections to each vendor. For an early-stage company, this is often the fastest way to support multiple systems while keeping the maintenance burden off your team. The trade-offs surface over time: recurring per-connection or usage-based fees, limited room for highly customized workflows, and an additional abstraction layer between your product and the underlying clinical systems.

One distinction is worth getting right, because it drives scoping and cost: "middleware" actually covers two different tools. An integration platform like Redox wires your product into many EHRs for ongoing, bidirectional workflows - orders out, results and notes back. But there are also network aggregators like Health Gorilla or Particle Health, that retrieves records from national networks such as Carequality and CommonWell, primarily in one direction, usually under a treatment purpose. They get lumped together, but one is a two-way workflow platform and the other a record-retrieval network - and confusing them when you scope a project is a common source of mismatched estimates.

2. Direct vendor APIs. Here you integrate through each vendor's own developer ecosystem - Epic's developer program (formerly App Orchard), Oracle Health's developer APIs. This gives you more control over implementation and a direct relationship with the platform, at the cost of a separate onboarding, technical requirements, certification path, and maintenance responsibility for every vendor you support. A vendor's program may expose FHIR APIs, proprietary APIs, or both, and the data available can differ by mechanism. Where the vendor supports SMART on FHIR, it is commonly used for secure authentication, authorization, and launch inside the clinician's workflow.

3. Custom integration layer. You build your own interoperability layer, internally or with a specialized integration partner. Depending on the environment, this combines FHIR R4, HL7 v2, and DICOM, often with an interface engine such as Mirth Connect or Rhapsody normalizing data across systems. It offers the most flexibility for complex workflows, custom business logic, and specialized clinical use cases, and it carries the most engineering ownership.

For the implementation-level mechanics - the specific API calls, authentication, data mapping, and error handling - see our article: How EHR Integration Works.

The technical differences are straightforward. The harder decision is which approach fits your current stage - and when it is time to move to the next one.

Build vs buy - matched to your company stage

One of the most common mistakes is treating your EHR integration strategy as a permanent build-versus-buy decision. It usually evolves: the approach that fits an early-stage startup can become inefficient as you add customers and integrations. And "build" does not necessarily mean hiring and managing an internal engineering team - you can own the architecture and integration layer while relying on a specialized partner to build and operate it.

Early product, first customers → middleware. When your priority is proving product-market fit and showing compatibility across several EHRs, middleware is often the right investment. A single integration can replace months of vendor-specific work and let your engineers focus on the product instead of interoperability infrastructure. Paying more for speed is a rational trade at this stage, because faster implementation can directly influence whether you win the next customer.

Scaling company, growing workflow complexity → custom integrations with a partner. -Middleware usually doesn't become obsolete, but rather becomes less economical and less flexible as volume grows. Two forces usually drive this transition. The first is cost: usage-based pricing that felt trivial with a handful of customers becomes a substantial line item as transaction volumes rise. The second is workflow complexity. As the software matures, customers ask for increasingly specialized behavior: custom write-back logic, vendor-specific workflows, proprietary data transformations, tighter latency requirements. Eventually your team spends more effort working around the middleware than benefiting from it. When the platform starts limiting what customers need instead of accelerating delivery, it has become the constraint. Building a custom layer with an experienced integration partner restores flexibility while sparing you the cost of standing up a full internal integration team too early.

Large-scale organization → in-house interoperability team. For organizations running many deep, bidirectional integrations across multiple systems, interoperability itself can become strategic intellectual property. At that point a dedicated internal team can make business sense. It is the highest fixed investment in engineering, security, and compliance, and it buys maximum control over architecture, data flows, and long-term product direction.

The transition rarely happens overnight. Three signals tend to appear together: middleware costs growing faster than the value they deliver, rising demand for workflows the current platform cannot support, and a strategic need to own more of the interoperability and compliance stack. When two or more show up at once, it is usually time to reassess.

Decision table: choosing the right approach

The 2026 regulatory landscape

Regulation increasingly defines the minimum capabilities a modern interoperability solution is expected to support. Implementation details keep evolving, but several frameworks shape most U.S. integration projects today.

21st Century Cures Act and information blocking. The Information Blocking Rule prohibits healthcare organizations, health IT developers, and health information networks from unreasonably interfering with the access, exchange, or use of EHI (electronic health information). For a software builder, the practical effect is that organizations should generally be able to access EHI through permitted mechanisms unless a defined exception applies. Guidance continues to be refined through ASTP/ONC rulemaking, so verify the current requirements when you scope a new project.

ASTP/ONC certification and USCDI. The Health IT Certification Program sets the baseline capabilities certified EHRs must support, anchored on the United States Core Data for Interoperability (USCDI). Under the HTI-1 Final Rule, USCDI v3 is the required version for certification as of January 1, 2026; USCDI v4 is published but voluntary for now. Expect the specifics to keep shifting - what holds is the direction: certified health IT relies on standardized, FHIR-based interoperability and a shared national data model.

CMS-0057-F: interoperability and prior authorization. For many organizations, this rule has the most immediate roadmap impact. It requires affected payers - Medicare Advantage organizations, Medicaid and CHIP managed care plans, state Medicaid fee-for-service programs, and Qualified Health Plan (QHP) issuers on the federally facilitated exchange - to modernize interoperability with FHIR R4 APIs and improve prior authorization. The rule rolls out in two phases that are easy to conflate. The operational requirements came first, effective January 1, 2026: decisions within 72 hours for urgent requests and 7 calendar days for standard ones, plus specific denial reasons. Those decision timeframes apply to most impacted payers but exclude QHP issuers on the exchange, who still owe denial reasons and public metrics reporting. The technical phase comes a year later: the four FHIR APIs - Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization - must generally be operational by January 1, 2027, with exact dates varying by payer type. If your product touches payer workflows or prior authorization, treat that 2027 date as an engineering milestone with regulatory teeth.

TEFCA. The Trusted Exchange Framework and Common Agreement establishes a nationwide framework for health information exchange through QHINs (Qualified Health Information Networks). Participation is still short of mandatory for most digital health vendors, yet it is becoming a more important piece of nationwide interoperability strategy. Recent rulemaking has also strengthened the link between TEFCA participation and information-blocking policy, which makes it strategically relevant for teams building long-term interoperability capabilities.

FHIR is the primary standard for modern interoperability work, prior authorization modernization sets concrete deadlines for affected payers, and certification requirements will keep changing. Ongoing regulatory awareness is non-negotiable.

Beyond the U.S.

FHIR R4, HL7 v2, and DICOM are international standards, so the way you actually build an integration looks much the same in Berlin or Warsaw as it does in Boston. What changes outside the U.S. is the regulatory environment and the mix of vendors you connect to.

In the EU, the closest counterpart to the U.S. interoperability push is the European Health Data Space (EHDS) - Regulation (EU) 2025/327. It entered into force in March 2025, with implementation phased between 2027 and 2035. The regulation establishes EU-wide interoperability requirements for electronic health records and complements GDPR for health data governance. Software that qualifies as a medical device is also subject to the EU Medical Device Regulation (MDR). Like the U.S., the overall direction is toward standardized, API-based exchange built on common interoperability specifications, with HL7 FHIR playing a central role.

The vendor landscape shifts as well. Alongside Epic and Oracle Health (formerly Cerner), which operate in parts of Europe, you'll encounter regional and national vendors such as Dedalus, CompuGroup Medical (CGM), InterSystems, and country-specific EHR platforms that dominate individual markets.

The decision framework in this guide travels with you - only the regulatory references and the local vendor mix change from market to market.

How to choose an integration partner

Once you move past basic middleware, the partner you pick largely determines whether interoperability becomes a strategic capability or a recurring operational drag. A strong partner shows more than general software experience.

Healthcare-specific delivery experience. A general engineering team and a team that knows healthcare are two different bets. Ask which platforms they have integrated with, whether the work was read-only or bidirectional, which FHIR resources and HL7 message types they have handled, and how they deal with customer-specific variation. Experience with the exact workflows you need matters more than a long technology list.

Security and compliance maturity. HIPAA is the baseline expectation, but you can also ask about mature security practices, documented processes, audit readiness, and experience in regulated environments. SOC 2 demonstrates organizational security maturity, and products operating as or alongside medical devices may call for additional quality frameworks such as ISO 13485.

Real interoperability experience. What matters is real, delivered work with the standards your project actually uses - ask a partner to walk you through where they have applied FHIR R4, HL7 v2, or DICOM in production. The strongest teams understand the messy realities behind the standards: inconsistent implementations, clinical workflow requirements, data normalization, patient identity.

A long-term operating model. The relationship matters most after go-live. Ask how they handle API changes, monitoring, production incidents, error resolution, and ongoing compliance. Healthcare integrations need operational ownership over years, not a clean hand-off at launch.

Existing ecosystem experience. Familiarity with Epic, Oracle Health, and athenahealth reduces friction, because a partner who already knows the common requirements and approval processes can move faster through them.

The most valuable partner is not always the one promising the fastest build. It is the one that combines healthcare interoperability expertise, security maturity, and a sustainable operating model. Here is what that kind of work looks like in practice.

Case study: Frontive - EHR integration for pre-operative patient self-service

Apzumi built Frontive, a HIPAA-compliant platform (web, iOS, Android) that lets surgical patients self-manage their pre- and post-operative journey - personalized reminders, dos and don'ts, onboarding surveys, and surgical history. On the clinical side, an administrative panel manages hospitals, protocols, and users.

The interoperability work centered on connecting the platform to the systems surgical offices already run on: Frontive exchanges data with the practice's EHR, an OTC medication database, and Nextech, ensuring instructions, patient records, and protocols stay in sync across the pre-op workflow rather than living in a separate silo. The result is less manual staff work and higher patient adherence to complex pre-surgical instructions.

How Apzumi approaches compliance

At Apzumi, compliance comes first. HIPAA is the baseline; we design healthcare software with security and quality requirements built into the architecture from the start. When a product needs medical-device-grade processes, we build to that bar - as we do for Calpro AS, whose Crohn's-monitoring platform we develop and maintain as a certified medical device (ISO 13485). Across integrations, that means standards like DICOM and direct EHR connectivity, handled by a team that treats PHI protection as a first design constraint.

Planning an EHR integration and weighing build versus buy? Talk to our team - we'll help you scope the right path for your product's stage.

FAQ

Middleware like Redox or a custom integration - which should I choose?

It maps to your stage and priorities. Middleware is often the best call when speed and broad EHR coverage matter most, since it supports many systems without building each connection yourself. A custom approach becomes more attractive when middleware costs climb, when customer workflows need capabilities the platform cannot support, or when interoperability becomes strategically important to the product.

Do I need my own team to integrate with an EHR?

For most growing healthcare products, no. A specialized partner gives you the right balance of technical control and operational flexibility without a full internal interoperability team. An internal team makes more sense when integration becomes a core competitive capability and you are running many complex, bidirectional connections.

What's the difference between EMR and EHR integration?

An EMR (electronic medical record) is usually the digital record system used within a single organization. An EHR (electronic health record) is built to support exchange across organizations. The terms are often used interchangeably in everyday conversation. In practice, most modern projects involve exchanging information across systems, which is why "EHR integration" is the more common industry term.

HL7 or FHIR - which one do I use?

In most modern products, both. FHIR R4 is the preferred starting point for new API work because it offers a more standardized REST and JSON approach. HL7 v2 remains deeply embedded in existing hospital workflows, especially for admissions, orders, and results. A typical application uses FHIR APIs for structured data while still receiving certain clinical feeds through HL7 v2.

Is HIPAA compliance enough?

HIPAA is the foundation, well short of a full security strategy. Healthcare buyers increasingly evaluate broader security maturity, including practices demonstrated through frameworks such as SOC 2. Products in regulated medical contexts may also require quality systems and standards such as ISO 13485. A strong partner treats compliance as an ongoing engineering discipline, not a final checklist.