Most practice administrators understand why a health information exchange matters: fewer duplicate labs, faster access to a patient’s history across care settings, better coordination when a patient shows up at an urgent care or specialist across town. Far fewer can explain how an electronic health record actually gets data into and out of a statewide network like the one Arizona built — historically known as The Network — and later folded into the successor regional HIE, Contexture. The mechanics matter because they determine what your EHR vendor needs to support, what an IT partner has to configure, and how long onboarding realistically takes. Below is what actually happens under the hood when an EHR connects to a health information exchange, in plain terms, with no vendor pitch attached.
Three Formats, One Goal: Moving the Same Clinical Record Three Ways
Interoperability standards exist because two EHR systems rarely store data the same way internally. A statewide HIE has to accept and translate clinical data regardless of which system sent it, and three approaches, developed over different eras, are still in active use side by side.
HL7 v2 is the oldest and still the most common transport for event-driven clinical messages — admission, discharge, and transfer (ADT) feeds, lab results, and order updates. It’s a rigid, pipe-delimited format, but it’s been the backbone of hospital-to-hospital data flow for decades, and most legacy EHR modules still speak it natively.
HL7 Clinical Document Architecture, most often used through its Consolidated CDA (C-CDA) profile, packages a patient’s clinical summary — problem list, medications, allergies, recent encounters — into a structured document, commonly called a Continuity of Care Document (CCD). This is the format that typically fires when a patient is referred or transitions between care settings, which is exactly the use case a statewide HIE was built to support.
FHIR (Fast Healthcare Interoperability Resources) is the newer, API-first standard. Instead of sending a whole document, FHIR exposes discrete, queryable resources — a single medication, a single lab result, a single allergy — over standard REST calls. That granularity is what lets a modern EHR or patient portal pull just the piece of data it needs at the point of care rather than parsing an entire document. Consistent use of coded terminology underneath all three formats — standards like SNOMED CT and LOINC — is what keeps a diagnosis or lab result meaningful once it crosses from one system’s vocabulary into another’s.
Direct Secure Messaging: The Simplest On-Ramp
Not every practice is ready to build a full HL7 or FHIR integration on day one, and a statewide HIE typically offers a lighter-weight path: Direct Secure Messaging (DSM). DSM works like encrypted email built specifically for healthcare — a provider sends a referral, a discharge summary, or a care transition note to another provider’s Direct address, and the message arrives encrypted and authenticated. DirectTrust is the accrediting body that certifies Direct Messaging services, which is why a vendor’s DSM offering being DirectTrust-accredited is a meaningful checkpoint rather than a marketing detail. For a small or mid-size Arizona practice, DSM is frequently the fastest way to start exchanging care-transition documents with hospitals and specialists on the network before investing in a deeper API integration.
FHIR Over Direct: Where the Two Approaches Converge
The two paths aren’t mutually exclusive. "FHIR over Direct" uses Direct Secure Messaging as the secure transport layer for FHIR-formatted payloads, which lets a practice get the structured, granular benefits of FHIR data without standing up a full real-time API connection right away. It’s a practical middle step that a lot of HIE onboarding plans lean on, particularly for practices whose EHR vendor has FHIR capability but hasn’t yet built out live API endpoints.
The Two Things That Actually Slow Practices Down
The standards themselves are well documented; what actually stalls a connection timeline is almost always one of two operational issues, not the technical protocol.
Identity matching. A statewide HIE has to be confident that "John A. Smith, DOB 3/14" in one practice’s EHR is the same person as "J. Smith" in a hospital’s system, without a shared universal patient identifier. Matching logic, and the data-quality discipline it demands from the sending EHR, is one of the harder unglamorous problems in any HIE integration.
Consent and governance. Data-sharing agreements, patient consent mechanisms, and role-based access controls all have to be configured correctly before a single record moves — and misconfiguring this step is what turns a technically complete integration into one that still can’t go live.
A Practical Checklist Before You Connect
Before a practice signs off on an HIE integration project, whether it’s being handled in-house or through an outside implementation partner, these are the questions worth having answered:
- Which formats does our EHR natively support — HL7 v2 feeds, C-CDA export, a live FHIR API, or only Direct Secure Messaging?
- Is our EHR vendor’s Direct Messaging service DirectTrust-accredited?
- Who owns identity-matching data quality on our end — are our patient demographics clean enough to match reliably?
- What consent and data-sharing agreements need to be signed before the connection goes live, and who at the practice is authorized to sign them?
- Is this a one-way feed (sending data out) or a two-way connection (also querying the network for outside records)?
- What’s the realistic testing and validation window before go-live — interoperability testing across use cases takes real time, not a single configuration change?
- Who handles ongoing monitoring once the connection is live, so a broken feed gets caught quickly rather than silently failing for weeks?
None of this requires a practice to become its own health-IT integration team. It does mean walking into a vendor conversation — whether that’s your EHR vendor, an HIE onboarding specialist, or a broader health-IT services partner — knowing which of these boxes are already checked and which ones aren’t. That’s the gap a neutral matching resource is built to close: connecting an Arizona practice to vendors who actually do this integration work, without a stake in which format, platform, or shortcut they push you toward.