How to choose the right health data integration path for your product

Your product needs patient data it doesn't have. Maybe it's a new patient's history from the hospital they left, or the referral a partner organization just sent. The data exists, but it lives in dozens of systems you don't control.

Most product teams already know the right integration depends on the data they need. What's harder is telling which option fits which case. Health Information Exchanges, national networks, EHR integration engines, payer APIs and the platforms built on top of them pull different data, from different places, under different rules, and vendor pages rarely make those differences clear.

In this guide, we sort those options by the data access problem each one solves, which is how we make the call when we build healthcare products. Before comparing routes, it helps to understand why outside patient data is so hard to reach in the first place, because that difficulty is exactly what all these networks and platforms exist to absorb.

Why is it so hard to access external patient data?

Connecting to a health data network is rarely a pure engineering problem. Four things make it slow.

1. Agreements come first - Networks run on trust frameworks. Before you query anything, you sign participation agreements, prove you're eligible, and show you meet HIPAA and the network's own policies. Regional HIEs often require this one network at a time.
2. The protocols are old - Many networks were built more than a decade ago on document-based exchange standards. Implementing them from scratch takes specialized knowledge most product teams don't have.
3. Finding the right patient is a problem of its own - The US has no national patient identifier. Records are matched on name, date of birth, address and other demographics. A typo can hide a patient's history. A bad match can pull someone else's.
4. The data arrives messy - Records come from many hospitals and clinics, each with its own system. Expect duplicates, gaps and the same allergy listed five different ways.

This is why so many intermediaries exist. Each one absorbs part of this work so you don't have to, and each one makes different trade-offs about which part.

What are the main ways to access patient health data?

The most useful way to sort the options is by the source of the data. There are five main routes.

Health Information Exchange (HIE). This route finds a patient's history wherever they've been treated, through regional HIEs, national networks like CommonWell and Carequality, and Qualified Health Information Networks (QHINs) under TEFCA, the federal framework for nationwide exchange.

Platforms such as Metriport, Zus, Health Gorilla and Particle Health connect to these networks and deliver the data through a single integration. For example, a primary care startup that onboards patients from many health systems can query the networks when a patient books a first visit and have their medication list and past discharge summaries ready before the appointment.

What is the difference between an HIE and a QHIN?

Within this category, regional HIE versus QHIN is a real decision. A regional HIE can offer depth in one area and is sometimes required by local rules, such as California's Data Exchange Framework (DxF). A QHIN offers national reach through one connection point. Which fits depends on where your patients are.

If your customers already run on a commercial EHR, check what it does before you add a vendor. Most EHRs come with network access built in. Epic's Care Everywhere, for example, connects Epic customers to each other and, through Carequality and TEFCA, to organizations on other systems.

When the outside records only need to appear inside that EHR's own workflow, the existing connection may be enough. A standalone platform earns its place when your product needs to control how records are queried, stored and shown on its own screens.

• Provider EHR API - Redox and similar integration engines connect your product to the EHR of a specific provider organization you work with. This solves a different problem. You're not searching for a patient's history across the country. You're exchanging data with one customer's system, often in both directions, including writing results back into their EHR. For example, a remote monitoring company serving one hospital's cardiology department can pull its patient list from that hospital's EHR and write device readings back into the chart.
• Patient-authorized EHR access - The data still comes from providers' EHRs, but the patient authorizes access instead of a contract or a treatment relationship. Under the 21st Century Cures Act, certified EHRs offer patient-facing APIs, and services like Fasten, Flexpa and OneRecord let patients connect them to your app. Metriport also supports patient-initiated retrieval through TEFCA's Individual Access Services, with a hosted identity verification step. This works when you don't have a treatment relationship with the patient, as in many consumer apps. For example, a wellness app can let users connect their patient portal accounts through SMART on FHIR, and a clinic can accept a SMART Health Link at check-in instead of a paper intake form.
• Payer API - Flexpa and 1upHealth pull data from health plans through the Patient Access APIs required by CMS. This is the route for claims, coverage and financial details, with the patient's consent. Under CMS rules, plans must make a claim available through the API within one business day after it's processed, so claims data trails the visit by however long the claim takes to be submitted and adjudicated. For example, a medication adherence app can ask members to connect their health plan account and read pharmacy claims to see which prescriptions were actually filled.
• Records request - When a standardized summary isn't enough, or the provider isn't reachable through a network or an API, you can request the full medical record directly from the provider, including scanned and paper documents. Services like Predoc handle these requests, often through fax and phone workflows. On the payer side, Datavant, Reveleer and Moxe do the same for health plans. For example, a specialty clinic receiving a referral from a small practice that isn't on any network can request the full chart and receive it as faxed documents.

A sixth route, tokenization through companies like Datavant and HealthVerity, links de-identified datasets for research and analytics. It matters for data teams, but it sits outside most product workflows.

Which integration approach fits intake, referrals and care coordination?

The same product can need more than one route. What decides it is the job the data has to do. These are the use cases we see most often.

Pulling a new patient's history at intake - You want to know what happened before the patient reached you: diagnoses, medications, allergies, past encounters. HIEs are built for this, usually through a platform such as Metriport, Zus, Health Gorilla or Particle Health that queries several networks at once.

We built an open-source demo EHR of this flow. A provider connects the patient from the chart, the app matches them through Metriport's API and starts a network query, and the provider reviews what comes back before importing anything. Matching runs on first and last name, date of birth, gender and a US address together, so the quality of your intake data decides whether any records come back at all.

When it makes more sense for the patient to bring the data, SMART Health Links offer a lighter path. The patient shares records through a link or QR code at intake, and your product reads only what they chose to share. Coverage depends on what the patient can access, and nothing flows back to a network. Our Kill the Clipboard library implements the specification in TypeScript.

Mapping these answers for your own product?
See how we approach healthcare integrations and interoperability

Receiving and sending referrals - Referrals move between specific organizations, so the route depends on who's on the other side. If your partner runs an EHR you can integrate with, the provider's EHR API may fit. If referrals arrive through a network or a regional HIE, you connect there. Many organizations still send them by fax, so plan for that too. We cover the workflow side in more detail in our guide to building trackable referral workflows.

Enriching the chart over time - Some products need to stay current after the first load. Admission and discharge alerts are the clearest case. Many regional HIEs run encounter notification services that push ADT (admit, discharge, transfer) messages to the organizations that subscribe, and Zus combines ADT alerts from PointClickCare and Bamboo Health with its network data. A single query at intake won't catch any of this, so plan for event subscriptions or scheduled re-queries from the start.

Coordinating care across organizations - Care coordination programs often need to read data from many providers and share care plans back. This usually means an HIE connection plus clear rules about what you contribute in return.

Meeting regional requirements - In some states, regulations or contracts decide part of the answer for you. California's DxF is one example. If your customers operate under such rules, check them before you compare vendors.

How should you evaluate health data integration options?

Before comparing vendors, we answer six questions with the product team.

1. Where does the data you need come from? Providers across the country, one customer's EHR, health plans, or the patient.
2. Does the route cover your patients? Network coverage varies by region and provider type. Check it against where your patients actually receive care.
3. Who authorizes access? A treatment relationship, the patient's consent, or a contract with a provider organization.
4. What do you have to give back? Some routes are read-only. Others expect you to contribute data in return.
5. How much detail do you need? A standardized summary, structured clinical data, or the full chart.
6. How much time and complexity can you absorb before launch? Direct connections give control but take months. Platforms shorten the path and add a vendor dependency.

The table below shows how the main routes typically answer them:

What is the difference between Zus and Metriport?

Picking a route doesn't end the decision. Platforms in the same category can reach the same networks and still deliver different things.

Zus and Metriport are a good example. Both connect to CommonWell and Carequality. Zus combines that network data with pharmacy data from Surescripts and admission and discharge alerts from PointClickCare and Bamboo Health, then presents it as a curated patient profile.

Metriport takes a developer-first approach. It's an open-source API platform that is an implementer in Carequality and a member of CommonWell, and it reaches TEFCA through a QHIN. A single query searches those networks for a patient, with pharmacy and lab sources available alongside HIE data, and the records come back normalized as FHIR R4 resources your product can store directly. Because the code is open source, teams can self-host it and keep control over the integration layer. Metriport also offers an embeddable patient view, which our demo uses for its read-only review screen.

Neither is better in general. A care team that needs to know the moment a patient is admitted has reasons to look at Zus. A product team that wants to own its data pipeline and avoid lock-in has reasons to look at Metriport. The use case decides.

What does a health data network require your product to send back?

Network access comes with conditions, and they shape the architecture more than most vendor comparisons suggest.

Eligibility comes before any query - HIE networks are built for treatment. Metriport, for example, requires production requests to come from a covered entity with an NPI, for a treatment purpose. Patient-initiated retrieval runs through a separate individual access flow with identity verification. If your product does research or analytics, or can't name the treatment purpose behind a request, this route may be unavailable, and a payer API or patient-authorized EHR access may be the only options.

Responding and contributing are two different obligations - Responding means answering when another participant queries for a patient you hold records on. Networks generally expect this for treatment queries, so once your product stores clinical data, other organizations may come asking for it. Contributing means sharing records for the patients you query, and some platforms make it a condition of access. Metriport states that participation is bidirectional, with clinical documents sent back to the networks after encounters.

Either obligation turns your product into a source of data as well as a consumer of it. Your records need to map to what the network accepts, and someone has to keep that mapping current as your data model changes. In the pilot described below, sending records back through the network was its own piece of engineering, separate from querying. The details vary by network and platform, and public summaries don't always match the governing agreements, so read the terms of the one you sign with before planning the build.

The work that starts after the records arrive

Most comparisons end at the connection. The work that follows, deciding how outside records enter your product, is where teams tend to underestimate the effort. Our demo shows most of it in practice.

Records arrive asynchronously - A network query takes minutes to return, and in our demo the first read after a query is slow enough to fail before a retry succeeds. Your product needs a state for "queried, nothing yet", a retry, and a way to let the provider know when results land.

Providers review before anything enters the chart - Outside records appear in a read-only view first, so the care team sees what came back without changing the patient's record.

Import is selective - In our demo, providers pick items from four categories (problems, allergies, medications and immunizations), and only those are written to the chart. Importing everything a network returns fills the chart with duplicates and with history the care team never needed.

Repeated imports write nothing - Each import is a FHIR conditional create, so importing the same item twice changes nothing, and items already in the chart are marked.

Duplicates also come from different sources - The same medication can arrive from a network document, from the EHR and from the patient. Our demo blocks a second import of one item, but recognizing the same fact across sources takes matching rules and a decision about which source wins when they disagree. If the network says one thing and your care team entered another, someone has to define the source of truth.

Re-queries need an owner - A patient's history keeps changing after the first query, and our demo doesn't re-query a connected patient yet. Decide who triggers the next query, and when, before the first one runs.

Each of these steps has a cost. Review and selective import take provider time for every new patient, which we accept because every imported item becomes part of the record the care team acts on. Asynchronous arrival takes engineering time in states, retries and notifications that a synchronous call wouldn't need.

How do you avoid vendor lock-in with health data integrations?

Your first integration choice is rarely your last. Coverage gaps show up as you expand into new regions, and TEFCA keeps reshaping the national landscape while your product is in the market.

We isolate the integration layer from day one. The product talks to an internal interface, and the vendor sits behind it. Swapping vendors, or adding a second route for a different use case, then becomes a contained change instead of a rewrite.

Our demo shows both sides of this. The vendor's API key lives only in server-side functions the app calls, so the browser never talks to the vendor directly and the integration sits behind one boundary. Imported items are written as the product's own FHIR resources, so they stay in the chart if the vendor changes. The read-only review screen, on the other hand, embeds the vendor's own patient view, and that screen would have to be rebuilt after a switch. Deciding early which screens can depend on a vendor is part of keeping the exit open.

Open-source platforms add another layer of protection. If you can self-host the integration code, a change in vendor terms doesn't put your product at risk.

What we learned building these integrations

We recently built a care coordination platform for a nonprofit in California. The organization coordinates care using clinical data from external providers, under Medi-Cal programs that require bidirectional data sharing, closed-loop referrals and admission and discharge alerts.

We evaluated two routes. The first was a regional HIE. It covered one part of California well, but the organization served people beyond that region. The second was a national network connected through a QHIN, which offered broader reach through a single integration point. We built a working prototype on that route: authenticating against the network, retrieving FHIR resources, creating and updating patient records, and simulating inbound referrals.

Connecting to the network turned out to be the more predictable part of the work. Most of the effort went into deciding which external data to import and which source takes priority when network data conflicts with what staff entered in the platform. That's the reconciliation problem above, and it's a product decision as much as a technical one.

Networks aren't the whole picture, either. With Everself (formerly Bariendo), an obesity care platform we work with, much of the external data exchange happens with partner facilities, labs, and pharmacies that still rely on fax and phone. We built fax workflows that match inbound documents to the right patient and partner organization and route them to the responsible provider. Their move away from a previous EHR raised the same source-of-truth question, because the team had to decide which system owned each record during the transition.

Choosing your integration path

In most products we build, the answer ends up being a combination, such as an HIE connection for patient history plus fax workflows for the partners who aren't on one. Mapping that combination early is what keeps the integration and interoperability work predictable.

The expensive mistakes happen before any code is written: choosing a vendor before defining the use case, or discovering reciprocity and reconciliation requirements after the data model is set. We work through these decisions with product teams as part of our integration and interoperability work, from choosing the route to designing how outside records enter the chart.

Planning to bring external patient data into your product?
Talk to our team about healthcare integrations and interoperability