When an Arizona practice talks about "connecting to the HIE," the conversation usually jumps straight to Direct Secure Messaging or query-based exchange. But underneath both of those workflows sits a less-discussed piece of infrastructure that determines whether a record-locator search actually finds the right patient: the Master Patient Index. Understanding what an MPI does — and what it does not do — is the difference between evaluating a health-IT vendor on marketing language versus evaluating it on the architecture that will actually move records correctly.
What a Master Patient Index Actually Does
A Master Patient Index is a database whose sole job is patient identity: it assigns each patient a unique identifier, commonly a medical record number or a universal patient identifier, and ties that identifier to the patient’s demographic data. When the same patient shows up in a hospital system, a lab system, and an independent clinic’s EHR under three slightly different name spellings or a typo’d date of birth, the MPI is the layer responsible for recognizing that these are the same person rather than three separate patients. An Enterprise Master Patient Index (EMPI) extends this same matching logic across multiple institutions rather than a single organization, which is the version relevant to any practice participating in a regional or statewide exchange network.
This sounds like a back-office detail, but it is the single point of failure that determines whether "record-locator" workflows are trustworthy. A record-locator search is only as good as the identity matching underneath it — a weak MPI produces duplicate patient records or, worse, silently merges two different patients into one.
How the MPI Powers Record-Locator Services
A Record Locator Service (RLS) is the component that answers a different question than the MPI. Where the MPI determines who the patient is, the RLS determines where that patient’s records physically reside across the participating organizations in a network. Working together, the two let a provider run a single query and pull back pointers to every location where a given patient has been seen — the hospital discharge, the specialist visit, the outside lab — instead of manually contacting each organization one at a time. This pairing is what turns "we are connected to an HIE" into an actual operational capability rather than a checkbox on a vendor sales sheet.
MPI vs. Query-Based Exchange vs. Direct Secure Messaging
These three terms get used almost interchangeably in vendor conversations, but they solve different problems and a practice evaluating options should know which one it is actually being sold.
| Mechanism | What it does | Relies on a centralized MPI? |
|---|---|---|
| Master Patient Index / EMPI | Establishes one trusted identity per patient across systems | Is the MPI itself |
| Record Locator Service | Finds where a matched patient’s records live across a network | Depends on the MPI for accurate matching |
| Query-based exchange | A provider actively searches and pulls available records on demand | Typically no — many query-based HIE networks use patient-matching algorithms and indexing rather than a single centralized MPI, and the clinical data itself is usually not stored on the network |
| Direct Secure Messaging | Sender-initiated, point-to-point encrypted delivery of a specific document (referral, discharge summary, transition of care) | No — it transmits a message to a known recipient rather than querying or matching identity across a network |
In practice, Direct Secure Messaging is the workflow most practices already have some familiarity with: it runs on the Direct Standard and the DirectTrust trust framework, and it behaves much like secure email addressed to a specific provider for a specific transition of care. Query-based exchange and record-locator services are the workflows a practice needs when it does not already know who has a patient’s prior records — the more demanding, and more valuable, interoperability capability.
The Standards Working Underneath All of This
None of this runs on a single company’s proprietary format. HL7 — through HL7v2, HL7v3, and increasingly FHIR — defines how the underlying data is structured and moved. Integrating the Healthcare Enterprise (IHE) publishes the integration profiles that make cross-vendor identity resolution possible in practice, including Patient Identifier Cross-referencing (PIX) and Patient Demographics Query (PDQ), the two profiles most directly responsible for letting one organization’s MPI talk to another’s. The Office of the National Coordinator for Health IT (ONC) sets the federal policy and certification expectations that push vendors toward these standards rather than closed alternatives, and AHIMA has historically published the data-quality models practices use to keep their own patient-matching accurate in the first place. A vendor that cannot explain which of these standards its identity-matching engine actually implements is a vendor asking a practice to take its interoperability claims on faith.
What This Means When Evaluating a Vendor
For an Arizona practice weighing HIE onboarding, EHR migration, or a broader health-IT stack, the practical takeaway is simple: "we support record-locator services" is not a complete answer. The follow-up questions are what separate a serious vendor from a marketing claim — does the platform maintain its own MPI or rely on a network partner’s, what patient-matching algorithm and match-rate does it report, and does it support PIX/PDQ or FHIR-based identity resolution rather than a proprietary lookup. Those are the specifics a neutral matching process should be surfacing before a practice signs a contract, not questions discovered after a duplicate-record incident.
None of this is legal or compliance advice — it is an operational map of how patient-record exchange actually works underneath the marketing terms, intended to help a practice ask sharper questions of the vendors it is considering. Getting the identity layer right is what makes every downstream record-locator or query-based workflow trustworthy in the first place.