Every health information exchange (HIE) runs on a promise that is easy to state and hard to deliver: a lab result, a prescription, or an admission notice generated in one system should show up, intact and on time, in another. Arizona has decades of history with that promise — the state built one of the country’s early statewide HIEs and ran the standards and e-prescribing initiatives that got local labs, pharmacies, and clinics connected in the first place. The work itself hasn’t gotten simpler since. Onboarding a single data feed still means navigating a specific stack of messaging standards, a testing cycle, and an administrative process that most small and mid-sized practices have never had a reason to learn until the moment they need to.
This is a walk-through of what that onboarding actually involves — the standards bodies and protocols in play, the steps a lab, pharmacy, or clinic goes through from first contact to go-live, and where the process typically bogs down.
Why “Connecting the Feed” Is Its Own Discipline
A health information exchange is not a single database that providers dump records into. It’s a routing and translation layer that has to accept data in whatever format a practice’s existing systems produce, normalize it, and make it available to every other authorized participant — hospitals, other clinics, payers, public health agencies. That normalization work is where most of the technical effort lives. A lab’s instrument output, a pharmacy’s dispensing system, and a clinic’s EHR were rarely built with each other in mind, so the interface between each of them and the exchange has to reconcile real differences in codes, formats, and transport methods before anything useful can flow.
The Standards That Actually Move the Data
A small number of protocols do almost all of the work:
- HL7 v2 remains the most common interoperability standard inside hospitals and clinics. It defines the message structures for the transactions that matter most to onboarding: ADT (admission, discharge, transfer), ORM (orders), and ORU (results). Most lab and clinic feeds into an HIE are HL7 v2 messages.
- LOINC (Logical Observation Identifiers Names and Codes) is the universal code set HIEs use to make lab results interpretable across systems. A lab whose instruments emit proprietary or local codes typically needs those mapped to LOINC before its results feed is usable by anyone downstream.
- FHIR (Fast Healthcare Interoperability Resources) is the newer, API-based standard gradually supplementing HL7 v2, offering a more modern integration path for systems built to support it.
- NCPDP SCRIPT is the standard specific to e-prescribing, and Surescripts is the network most e-prescribing traffic actually runs through — connecting a pharmacy or prescriber for electronic prescriptions means going through credential verification on that network, not just configuring software.
- Direct Secure Messaging provides an encrypted, email-like channel for point-to-point exchange between trusted participants, often used alongside the larger HIE connection rather than instead of it.
- TEFCA (the Trusted Exchange Framework and Common Agreement) and USCDI (United States Core Data for Interoperability) sit above the individual protocols, defining the national framework and the minimum data classes that exchanges are expected to make available to participants.
None of these are optional add-ons a practice can skip to save time. An interface that doesn’t map to the right code sets or use the right transaction types simply won’t be readable on the other end — the data arrives, but it doesn’t mean anything to the system receiving it.
The Path From First Contact to Go-Live
The onboarding sequence is fairly consistent across exchanges, even though the paperwork and timelines vary by state and by HIE:
- Intent and agreement. The practice signs a letter of intent and a participation agreement, and provides basic organizational details — practice name, locations, and NPI numbers for prescribers.
- Readiness assessment. The HIE and the practice’s technical contact (often the EHR vendor or an outside integration engineer) confirm what data will be exchanged — ADT, ORU, CCDA documents, e-prescribing — and whether the practice’s existing system can produce it in a compatible format.
- Interface build. The interface is configured to send and receive HL7 messages over a secure connection, with any non-standard codes mapped to standard terminologies like LOINC.
- Testing and validation. Sample data, including test patients, is sent through a test environment to confirm messages transmit correctly and display properly for other participants. Data quality checks catch formatting or mapping errors before anything goes live.
- Go-live and monitoring. Once testing passes, the feed moves to production, typically followed by an initial monitoring period to confirm the interface holds up under real transaction volume.
Where the Timeline Actually Goes
The honest answer is that onboarding rarely moves as fast as a practice expects going in. The technical integration and testing phases for a typical HL7 feed — covering ADT, vitals, labs, medications, and allergies — commonly require somewhere in the range of ten to twenty hours of dedicated interface-engineering work, on top of several hours of pre-work scoping. E-prescribing credentialing through a network like Surescripts adds its own timeline, often on the order of one to two weeks for identity and credential verification before a prescriber can transmit electronically. Layer administrative delays — consent-process setup, staff availability, agreement review — on top of the technical work, and the full process from first contact to a stable, monitored go-live can stretch to weeks or, for practices without dedicated IT staff, considerably longer.
Why a Neutral Point of Contact Matters
Most labs, pharmacies, and clinics don’t have an in-house interface engineer, and they shouldn’t need to build that expertise from scratch to get connected. The practical bottleneck usually isn’t the standards themselves — HL7, LOINC, and NCPDP SCRIPT are well documented — it’s finding a vendor who has actually done this integration work before and can scope it accurately instead of discovering the gaps mid-project. That is precisely the role a neutral, statewide health-IT convener is built to play: not performing the interface build itself, but matching a practice with a vetted integration partner suited to its EHR, its data volume, and its timeline, so the onboarding sequence above runs in weeks rather than months.
Connecting a lab, pharmacy, or clinic to a health information exchange is a solvable, well-understood technical process — but only when the practice starts with the right vendor relationship instead of learning the standards landscape under deadline pressure.