When an Arizona practice sets out to connect with hospitals, labs, and specialists electronically, the first real decision isn't which vendor to sign with — it's which method of exchange the workflow actually calls for. "Direct Secure Messaging" and "query-based exchange" both move patient records between systems, but they solve different problems, use different standards, and fit different moments in care. Confusing the two is one of the most common reasons a practice ends up paying for connectivity it can't use, or missing the connectivity it actually needs.
This breakdown compares the two models on their technical mechanics, the standards behind them, and the specific scenarios where each earns its keep — so a practice evaluating vendors for query/retrieve, direct messaging, or record-locator workflows can ask sharper questions before signing anything.
Direct Secure Messaging: a "push" model built on a known recipient
Direct Secure Messaging (often just called "Direct") behaves like secure email between two known, trusted parties. A referring physician sends a discharge summary or continuity-of-care document to a Direct address — the healthcare equivalent of an email address — and it arrives encrypted, authenticated, and logged. The sender has to know exactly who they're sending to; there is no searching or discovery involved.
Under the hood, the Direct Project specification handles the transport: content is packaged and encrypted using S/MIME, sender and receiver identities are verified with X.509 digital certificates, and messages typically route over SMTP. The clinical content riding inside that secure envelope is usually structured as a Consolidated Clinical Document Architecture (C-CDA) document, an HL7 standard. IHE's Cross-Enterprise Document Media Interchange (XDM) profile governs how documents and their metadata get packaged for that transfer.
Because it's a push mechanism between known parties, Direct fits planned care coordination: referrals to a specialist, discharge summaries flowing back to a primary care physician, lab results going to an unaffiliated ordering provider, or routine transitions of care. If a practice already knows exactly who needs the document, Direct is usually the simpler, cheaper connection to stand up.
Query-based exchange: a "pull" model for the unplanned moment
Query-based exchange flips the model. Instead of sending a document to someone specific, a provider searches a health information exchange network for whatever records exist on a given patient, wherever they happen to live. It is the workflow behind the phrase "query/retrieve" and it is built for situations where the sender of the original record has no idea, in advance, who will eventually need it.
This is where the newer standards layer in. IHE's Cross-Enterprise Document Sharing (XDS) profiles are foundational for discovering and retrieving documents held by other organizations in a network. HL7's FHIR standard is increasingly the transport layer for the underlying API calls, and the HL7 FHIR Da Vinci Clinical Data Exchange (CDex) implementation guide specifically supports query-based, task-based, and document-based workflows — including exchange between providers and payers, which matters for the credentialing and billing side of practice operations as well as clinical care.
The clearest use case is unplanned care: an urgent care visit, an ED encounter, or a new patient who shows up without their records in hand. A query-based connection lets the treating provider pull a medication list, allergy history, or recent labs from wherever they were last recorded, without anyone having pre-arranged the hand-off. It also reduces duplicate testing — a provider who can see a lab result from three weeks ago doesn't need to re-order it.
The Record Locator Service: the piece that makes query-based exchange work
Query-based exchange only works if there's a way to know where a patient's records actually live across a network of otherwise-unconnected organizations. That's the job of a Record Locator Service (RLS). An RLS doesn't store clinical data itself — it maintains an index or directory of where records exist for a given patient, based on demographic matching, and returns pointers rather than content.
The practical benefit is real: without an RLS, a query has to rely on "geofencing" — guessing which nearby organizations might hold a record and querying each one individually, which is slow and misses anything outside the assumed radius. An RLS lets a single query search across an entire network in real time, which is exactly what an ED or urgent care visit needs when a patient is unresponsive or new to the area. It also means the network can operate without a national patient identifier or a centralized data repository — every organization keeps its own records, and the RLS just knows who has what.
Comparing the two models directly
| Factor | Direct Secure Messaging | Query-Based Exchange |
|---|---|---|
| Mechanism | Push — sender addresses a known recipient | Pull — requester searches a network for available records |
| Best fit | Planned transitions: referrals, discharge summaries, routine results | Unplanned care: ED visits, urgent care, new patients |
| Core standards | Direct Project transport, S/MIME, X.509, HL7 C-CDA, IHE XDM | IHE XDS, HL7 FHIR, Da Vinci CDex |
| Requires knowing the recipient in advance? | Yes | No |
| Needs a Record Locator Service? | No | Yes, for network-wide discovery |
| Typical onboarding complexity | Lower — one trusted connection at a time | Higher — requires network participation and matching setup |
What this means when choosing a vendor
Most practices don't need to pick one model exclusively — the two are complementary, and many EHR and HIE connections eventually support both. But when a practice is scoping a first connectivity project, or trying to figure out why an existing setup isn't doing what they expected, the distinction matters for setting the right expectations:
- If the goal is getting referral letters, discharge summaries, and specialist consult notes flowing reliably between known partners, that's a Direct Secure Messaging problem — look for a HISP (Health Information Service Provider) connection and confirm the vendor supports C-CDA document exchange.
- If the goal is being able to pull a patient's history from anywhere — particularly relevant for urgent care, walk-in, or specialty practices that see unfamiliar patients — that's a query-based exchange problem, and it means evaluating whether the vendor participates in a network with real Record Locator Service coverage, not just a regional data pool.
- Either way, ask what standards the connection actually implements. A vendor who can speak clearly about C-CDA versus FHIR, or XDM versus XDS, is a vendor who has actually built the plumbing rather than reselling a label.
Arizona's health-IT landscape has a long history of statewide exchange infrastructure, and the vocabulary above — Direct, query/retrieve, record locator — is the same vocabulary that infrastructure was built on. Understanding which problem each model solves is the fastest way for a practice to evaluate whether a proposed connection actually matches its workflow, rather than discovering the gap after go-live.