Health information exchange with EHR systems in regional care networks

I didn’t set out to become obsessed with health information exchange. It happened gradually—starting with a small care-transition project that kept breaking at the seams. A patient discharged from the hospital would show up in the community clinic two days later with a different medication list, and my stomach would sink. Somewhere between our EHR and theirs, truth was getting lost. That’s when I started sketching how data should flow across a community: hospitals, clinics, home health, public health, and even payers pulling in claims context. It felt a bit like drawing a subway map for a city that never sleeps. I wanted to write down what finally made this puzzle “click” for me, without hype, and with practical steps I now use to bring EHR systems into a resilient regional exchange.

The moment it finally made sense

I’d been treating HIE like a big technical pipe. Then it clicked: regional exchange is a governance + workflow + standards problem that happens to rely on technology. The pipe matters, but not as much as what we send (content, codes), who we send it to (trust), and why (clinical use cases). Once I anchored on a few concrete use cases—ED notifications, closed-loop referrals, and post-discharge medication reconciliation—the architecture choices got much easier.

• Pick two to three high-value use cases to start (e.g., ADT alerts to PCPs, query-and-retrieve meds and problem lists before a visit). Tie each one to a measurable outcome like fewer duplicate tests or faster follow-up.
• Align on content you will trust across systems. Agree on a “starter pack” that converges on core elements (allergies, meds, problems, immunizations) and coded vocabularies (LOINC, SNOMED CT, RxNorm).
• Map your network’s trust routes. In some regions, a local HIE hub is the backbone; in others, inter-network frameworks and national networks carry most of the load. Understanding the options under TEFCA was a turning point for me.

How I visualize the regional data fabric

When I draw the regional map now, it has just five building blocks. I ask myself where each block lives, who maintains it, and how it’s governed. The fun (and challenge) is that you can assemble these blocks in different ways and still succeed.

• Identity and record location — An MPI (probabilistic or deterministic) and a record locator service (RLS) are table stakes. Even if you “outsource” this to a network connection, your local patient-matching hygiene is a make-or-break factor.
• Transport and trust — Think of secure pipes plus legal frameworks. Local HIE participation agreements, inter-network frameworks (e.g., query via a national network), or alignment under TEFCA (QHIN-to-QHIN exchange) are all valid paths.
• Content and format — In the U.S., the regulatory center of gravity points to FHIR APIs and a defined “floor” of data. The HL7 FHIR R4 specification is the workhorse for modern exchange.
• Use-case orchestration — Event-driven alerts (ADT), query-and-retrieve for care planning, closed-loop referral status, and data submission to public health. These are workflows, not just data calls.
• Stewardship and policy — Privacy rules, data-sharing agreements, and behavior expectations (what you must share, when you can say no). Understanding the contours of Information Blocking keeps projects on track.

Once those blocks are clear, the “which network” question becomes tactical. You can start with your EHR’s native connections, a state/regional HIE, or pursue TEFCA alignment via a QHIN—often it’s a blend. I’ve learned to think in layers rather than either–or.

A field guide to connecting an EHR into a community exchange

Here’s the stepwise checklist I keep close when I’m advising a small health system or a multi-clinic network. It’s opinionated but grounded in policy and real-world friction points.

• Start with outcomes — Write one sentence per use case: “We will reduce 14-day readmissions by sending ADT alerts to PCPs within 30 minutes.” Put a metric on a dashboard before any interface work begins.
• Inventory the data — Pull sample charts and map key fields to your target content. Even if you won’t cite it in a contract, align your “floor” to ONC’s minimum expectations under HTI-1 (think modern API support and transparency): skim the HTI-1 summary for what certified health IT must support.
• Choose your backbone — Local HIE feed, EHR vendor network, or TEFCA-enabled route. If multiple are available, pilot the fastest path for your first use case; then expand for redundancy.
• Decide on query behaviors — Who is allowed to query what and when? Pre-fetch before a scheduled visit? Retrieve on demand? Put it in your governance artefacts, not just a meeting note.
• Close the loop — Alerts and referrals are half-baked unless you show status back to the sender. Treat “acknowledged,” “scheduled,” and “completed” as first-class data elements.
• Test with living data — Run tabletop scenarios using actual (de-identified) encounter timelines. Verify that meds, allergies, problems, and immunizations reconcile cleanly. Measure duplicate orders before/after go-live.
• Set expectations on sharing — Share what you must, with exceptions that are respectful and lawful. A good starting orientation is ONC’s plain-language overview of Information Blocking to ensure clinical access isn’t hindered without a valid exception.

What the rules actually require without the legalese

I used to treat policy as a roadblock; now I see it as a guardrail. A few highlights I keep in my notes when executives ask “what’s the minimum we have to do?”

• EHR certification and transparency (HTI-1) — ONC’s HTI-1 final rule updates certification and introduces transparency around decision support algorithms and modern API behaviors. If your EHR is certified, there’s a baseline you can count on; skim ONC’s HTI-1 overview to understand what “certified” means for your project scope.
• Information Blocking — The policy is simple in spirit: don’t get in the way of appropriate access, exchange, or use of electronic health information unless an established exception applies. ONC’s resource center is the friendliest place to align leadership and legal counsel.
• Nationwide connectivity (TEFCA) — TEFCA establishes a common trust framework so networks can talk to networks. If your region has multiple overlapping networks, TEFCA participation (directly or via a QHIN) can reduce one-off connections; ONC’s TEFCA page is where I send folks for a big-picture read.
• Payer APIs and prior authorization (CMS-0057-F) — Your regional fabric now includes payers. CMS is phasing in API requirements (Patient Access, Provider Access, Payer-to-Payer, and Prior Auth status) that can complement clinical exchange. The current fact sheet for the CMS Interoperability and Prior Authorization Final Rule is the most up-to-date snapshot I keep handy.
• Technical lingua franca — For modern exchange, the practical default is HL7 FHIR R4 (with US Core profiles). Even when documents (C-CDA) are still in play, most expansion work I see uses FHIR APIs to stitch EHRs and services together.

A simple, repeatable framework I now use

When the project starts to sprawl, I fall back to this three-step framing to cut through the noise:

• Step 1 — Notice where the clinical friction lives: duplicated labs, missed follow-ups, delayed med histories. Make these the “jobs to be done.”
• Step 2 — Compare connection options: (a) your EHR’s vendor network, (b) state/regional HIE, (c) TEFCA-enabled routes. Consider latency (event vs query), coverage (who’s actually on it), and contractual lift (how long to sign and onboard).
• Step 3 — Confirm governance and guardrails: information blocking exceptions you might rely on, patient communications, and data segmentation for sensitive info. Keep a one-page “sharing guide” for clinicians and a public-facing FAQ.

For the playbook’s “policy” tiles, I link teams to three primary sources so we argue less and build more: ONC’s pages for HTI-1, Information Blocking, and TEFCA. For “tech,” my anchor is FHIR R4. For “payer data,” I keep the CMS 0057-F overview bookmarked.

Reality checks from the trenches

I used to think turning on an interface would magically feed clean data everywhere. Then I watched a clinic drown in duplicates because we hadn’t aligned reconciliation behavior. Here are the “micro-habits” I keep testing.

• Golden sources — We agreed which system “owns” specific elements at specific points in care (e.g., meds list is owned by the discharging hospital until the first post-discharge PCP visit, then the PCP EHR takes over).
• Conservative merging — We tuned the MPI thresholds and created a simple escalation lane for possible matches. False positives are worse than missing a match when medications are involved.
• Clinician-friendly views — We added “external data” tabs that show provenance: when/where the data came from, who contributed it, and a one-click way to accept or ignore. The user experience is part of data quality.
• Sandbox sprints — Before go-live, we ran two-week sprints in a test tenant with synthetic but messy data. We tried to break the workflows on purpose, then fixed the rough edges.
• Measure and publish — Every month we post three numbers: (i) % of encounters with pre-fetched external data, (ii) duplicate lab rate, (iii) 7-day post-discharge follow-up completion. If they’re not moving, we revisit the use cases.

What to double-check before you scale out

Some risks aren’t scary once they’re named. Here are the ones that tell me to slow down for a week, not a year.

• Sensitive data handling — Substance use disorder records and certain behavioral health details may have special protections and consent requirements in your state and under federal law. Your legal team should align exchange behaviors with policy; meanwhile, stay oriented to the sharing expectations under Information Blocking so you don’t over-restrict clinical access.
• Over-permissioned access — If everything is open to everyone, it’s a breach waiting to happen. Least privilege and audit trails are your friend. Make sure your FHIR endpoints are well-scoped and monitored (FHIR R4 security sections aren’t just for implementers).
• Unclear patient communication — Tell patients what you share, with whom, and why—in plain English. Publish your “data sharing at a glance” page and keep signage at registration simple and accurate.
• Data bloat — Pulling everything is a recipe for clinician fatigue. Curate the views and prioritize what drives decisions for your specific use cases.
• Contract gaps — Participation agreements, BAAs, and security addenda need to match the actual data flows. If you switch transport or expand to payer APIs (see CMS 0057-F), revisit the paperwork.

Putting it all together in a regional story

Here’s the composite scenario I keep returning to. A patient with heart failure is admitted to a regional hospital, discharged with medication changes, and followed by a community PCP and home health. Pre-visit, the clinic’s EHR pre-fetches meds and problems via a FHIR query from the network. When an ED visit happens at a neighboring health system, an ADT alert notifies the PCP. Home health documents vitals and symptoms, which the PCP queries through the network before adjusting diuretics. Meanwhile, payer APIs surface prior-authorization status for a new cardiac rehab referral. None of this is “future tech.” It lives in the intersection of TEFCA-enabled network trust, HTI-1-aligned capabilities in certified EHRs, payer API requirements rolling in under CMS 0057-F, and tried-and-true FHIR R4 plumbing.

What I’m keeping and what I’m letting go

I’m keeping a bias toward use cases with clear outcomes and a small, deliberate set of data elements that clinicians actually use. I’m keeping a deep respect for governance and transparency—it’s what lets us move fast without breaking trust. And I’m keeping a humble posture toward policy; it changes, but it’s increasingly designed to promote appropriate sharing.

I’m letting go of the idea that one network or one standard solves everything. I’m letting go of “toggle it on and hope for the best.” Instead, I’m embracing an iterative, measured approach that treats interoperability as a clinical program with technical support—not the other way around.

FAQ

1) Does my EHR have to use FHIR for HIE?
Answer: Practically speaking, yes for modern API-based exchange. The U.S. regulatory posture (via ONC) and most new payer-facing requirements expect modern API capabilities aligned to the FHIR R4 specification and US Core profiles, even though some document exchange still uses C-CDA.

2) Is TEFCA required for my region to share data?
Answer: No—local HIEs and vendor networks can work well. TEFCA provides a national trust framework that can reduce custom connections, especially when multiple networks overlap or you need broader reach.

3) How do Information Blocking rules affect clinicians?
Answer: They set expectations to not unreasonably interfere with appropriate access, exchange, or use of electronic health information. There are defined exceptions; ONC’s overview is a good primer to align policies and workflows.

4) Where do payer APIs fit into a regional exchange?
Answer: They don’t replace clinical HIE but complement it—think prior authorization status, claims/encounter context, and sharing relevant data with in-network providers. See CMS’s Interoperability and Prior Authorization Final Rule for current timelines and scope.

5) What’s the minimum data set we should align on?
Answer: For a starter pack: demographics, problems, meds, allergies, immunizations, and recent labs/imaging summaries—mapped to standard codes. Certification updates under HTI-1 push vendors toward more consistent API access and transparency, which helps.

Sources & References

• ONC — TEFCA
• ONC — HTI-1 Final Rule
• ONC — Information Blocking
• CMS — Interoperability & Prior Authorization Final Rule
• HL7 — FHIR R4 Specification

This blog is a personal journal and for general information only. It is not a substitute for professional medical advice, diagnosis, or treatment, and it does not create a doctor–patient relationship. Always seek the advice of a licensed clinician for questions about your health. If you may be experiencing an emergency, call your local emergency number immediately (e.g., 911 [US], 119).