You need to connect your product to a Health Information Exchange, and somewhere along the way someone quoted you a year. A year of legal review, a year of IHE conformance testing, a year of bilateral interfaces with one HIE after another. That number is real for the wrong approach - and almost always wrong for the right one. Connecting to an HIE in 2026 looks far more like onboarding to a single network than building dozens of point-to-point integrations.
This guide walks through what an HIE actually is, the two ways data moves through one, the connection mechanics under the hood, and the realistic path that turns a year-long project into a months-long one. The single biggest lever is choosing the right on-ramp.
What an HIE actually is
A Health Information Exchange is shared infrastructure that lets unaffiliated organizations move clinical data about the same patient. The clinic that referred your patient, the hospital that admitted them, and the lab that ran their panel all use different EHRs that were never built to talk to each other. The HIE sits between them as a trust framework and a set of technical services so a record created in one place can be found and read in another.
Two things make an HIE more than a file transfer. First is governance: a legal agreement that says who may query for what, under which permitted purposes, with what consent and audit requirements. Second is patient identity resolution - the ability to decide that the "Maria Garcia" in your system and the "Maria L. Garcia" in another are the same person. Both matter more than any single wire protocol, and we will come back to identity, because it is the part most teams underestimate.
The two interaction models: push and pull
Every HIE exchange falls into one of two models, and understanding the split clarifies almost everything else.
Directed (push) exchange
Push exchange sends a specific document to a specific, known recipient - the digital equivalent of a secure fax. The dominant standard here is Direct messaging: encrypted, S/MIME-secured email between Direct addresses, carrying a C-CDA document as an attachment. You use push for transitions of care, referrals, and discharge summaries, where you already know who needs the record. It is simple, asynchronous, and a good first milestone because you do not need to discover anything - you address the message and send it.
Query-based (pull) exchange
Pull exchange is where the real value of an HIE lives, and where the engineering is harder. Instead of knowing the recipient, you ask the network a question: who has records on this patient, and may I retrieve them? A pull transaction has two distinct phases. First, patient discovery - locating the patient across every connected organization. Then, document retrieval - pulling the matched records back. The national networks were built primarily around this query model, because it answers the question a clinician actually asks at the point of care: "what does anyone, anywhere, already know about the person in front of me?"
This push-versus-pull distinction maps directly onto the broader standards picture we cover in our guide to FHIR, HL7, and healthcare interoperability standards. An HIE is one of the places those standards stop being theory and start carrying live patient data.
The connection mechanics: IHE profiles and FHIR
Under the hood, HIE exchange runs on a small family of IHE profiles - and, increasingly, a FHIR-based alternative. You do not have to love SOAP to work with these, but you do have to recognize them.
Document sharing: XDS.b and XCA
XDS.b (Cross-Enterprise Document Sharing) is the foundational profile for sharing clinical documents within a single exchange community. It defines a registry that holds document metadata and a repository that holds the documents themselves, so a system can query for what exists and then retrieve it. When you need to reach across communities - one HIE asking another - that is XCA (Cross-Community Access). XCA is what makes nationwide query possible: it federates many XDS domains so a single query fans out to communities you never integrated with directly. Both use SOAP transport and ebRIM metadata, and both move C-CDA documents.
Patient identity: PIX, PDQ, and XCPD
Before you can retrieve a document, you have to agree on whose document it is. PIX (Patient Identifier Cross-Referencing) links the different identifiers the same patient carries across systems. PDQ (Patient Demographics Query) lets you look a patient up by demographics - name, date of birth, sex - and get back the identifiers a community uses. For cross-community work, XCPD (Cross-Community Patient Discovery) is the profile that locates a patient across every connected community before any document query runs. In a national query, XCPD comes first, then XCA. Get the identity step wrong and the retrieval step never matters.
The FHIR-based path
The newer access model replaces SOAP and ebRIM with FHIR REST and JSON. IHE's MHD (Mobile access to Health Documents) profile offers a RESTful interface to the same document-sharing infrastructure, PDQm is the FHIR version of demographics query, and TEFCA has defined a "Facilitated FHIR" path so participants can exchange FHIR resources over the national framework. If you are building a modern app, the FHIR path is the one you want - it speaks the same language as the rest of your stack. This is also why a FHIR facade is such a common pattern: it lets a clean FHIR API sit in front of older XDS or HL7v2 plumbing, so your application never touches the SOAP layer directly.
The national networks and how TEFCA reshapes them
Three names dominate any conversation about nationwide exchange:
- Carequality is a trust framework - a common set of legal and technical rules that lets connected networks query each other. It is implemented inside most major EHRs, which is why a clinician on one EHR can often pull records created on another.
- CommonWell Health Alliance is a network and a Carequality implementer; it provides record locator and query services to its members, and connects out to Carequality on their behalf.
- eHealth Exchange is one of the largest public-private exchange networks in the country, connecting a large share of U.S. hospitals along with state and regional HIEs and federal agencies.
What is reshaping all of this is TEFCA - the Trusted Exchange Framework and Common Agreement. Where Carequality and CommonWell grew up as voluntary frameworks, TEFCA establishes a single federal floor for nationwide exchange, governed under a common legal agreement. Networks that meet its bar become QHINs (Qualified Health Information Networks): the backbone that routes queries from one QHIN to another. As of 2026 the designated QHINs include eHealth Exchange, CommonWell, Epic Nexus, Health Gorilla, MedAllies, and KONZA, among others. QHINs must support both a query model and a message-delivery model, and the QHIN technical framework is built on the same IHE profiles - XCPD and XCA - with the Facilitated FHIR path layered in. The current framework and policy live with ONC.
The strategic point for your roadmap: TEFCA does not replace your need to connect; it standardizes what you connect to. We unpack the implications, timelines, and what it means for a build-versus-buy decision in our TEFCA guide for developers and CTOs and in the broader interoperability regulations action plan. If you want to know how this sits alongside the CMS and ONC rules driving adoption, our 2026 compliance overview ties the regulatory threads together.
Patient matching: the hard, underrated problem
Here is the part that quietly determines whether your HIE integration works: there is no national patient identifier in the United States. Every query depends on matching demographics - and demographics are messy. Names change, dates of birth get fat-fingered, addresses go stale, and the same person shows up as "Bob," "Robert," and "Rob" across three systems.
The component that absorbs this mess is the Master Patient Index (MPI), the authoritative identity layer that decides which records belong to the same human. When you connect to an HIE, your patient-discovery flow (PDQ or XCPD) is only as good as the demographics you send and the matching the network runs on the other side. Send sloppy data and you get two failure modes, both dangerous: a false negative, where you miss records that exist, and a false positive, where you pull in someone else's chart. The first is a care-quality risk; the second is a safety and privacy incident.
Teams that treat patient matching as an afterthought are the ones whose projects slip. The ones that ship on time invest early in clean demographic capture, a real MPI or EMPI strategy, and explicit handling of probable-but-not-certain matches. Identity resolution is not a checkbox at the end; it is the spine of the whole integration.
The realistic path: connect through a network, not bilaterally
Now to the year-versus-months question. The single decision that determines your timeline is how you connect.
The slow path is bilateral: stand up your own XDS infrastructure, negotiate and certify with each HIE individually, and build a new interface for every organization you want to reach. That is genuinely a year of work, and it never ends, because there is always one more endpoint. The fast path is to connect through a single on-ramp - a QHIN, a CommonWell or Carequality-connected vendor, or an HIE aggregation platform - that already holds the trust relationships and runs the IHE or FHIR plumbing on your behalf. One connection, thousands of organizations reachable, none of them integrated point-to-point.
A months-long path looks like this:
- Pick an on-ramp. Choose an intermediary whose network, permitted purposes, and access model (query, push, FHIR) match your use case. This is the highest-leverage decision in the project.
- Onboard and test. Exchange trust certificates, run in the sandbox, and pass conformance for the transactions you need - XCPD and XCA for query, or the FHIR endpoints for a modern build. This is structured work with a clear finish line, not open-ended R&D.
- Solve matching. Wire your demographics and MPI into the network's patient-discovery flow, and tune for false negatives and false positives before you trust the results clinically.
- Go live by use case. Launch one workflow - say, query at intake - prove it, then expand to push notifications, additional query types, or FHIR access. Sequencing by use case is what keeps the timeline honest.
What turns this into a year-long project is almost always a decision to build interfaces instead of buying an on-ramp, or to underestimate identity and discover the matching problem in production. Avoid those two traps and the rest is execution.
Where a healthcare-specialist partner helps
Healthcare is the only industry we work in, and HIE connectivity is the kind of integration where domain depth pays for itself. We are FHIR R4 native, we have built EHR integrations for 30+ healthtech startups, and we have shipped multi-EHR connectivity in production - for example, Yown Health across Epic, Cerner, Allscripts, and athenahealth. The same instincts that make a multi-EHR build work - treating identity, transport, and document semantics as one connected problem - are exactly what an HIE connection demands. If you want a connection plan scoped to a real timeline rather than a generic one, that is a conversation worth having before you write the first line of code.
Key takeaways
- An HIE moves data two ways: directed push (Direct messaging to a known recipient) and query-based pull (discover the patient, then retrieve records). The value is mostly in the pull.
- The mechanics run on IHE profiles - XDS.b and XCA for documents, PIX/PDQ/XCPD for identity - with a growing FHIR REST alternative (MHD, PDQm, Facilitated FHIR).
- Carequality, CommonWell, and eHealth Exchange already connect most of the country; TEFCA and QHINs are standardizing that exchange under one federal framework.
- Patient matching through your MPI is the underrated hard part - false negatives miss records, false positives pull the wrong chart.
- Connect through a single on-ramp (a QHIN or intermediary), not bilateral interfaces - that one choice is the difference between months and a year.
If your roadmap calls for HIE connectivity and you would rather not spend a year discovering the hard parts the slow way, map the network landscape first, then book a 15-minute call to pressure-test the connection plan against your use case.
