Every statewide health information exchange (HIE) has to answer one deceptively simple question before a single record can flow between providers: does a patient’s data get shared by default, or only after they say yes? The answer — opt-in or opt-out — shapes everything downstream, from how much clinical data actually populates the exchange to how much administrative work lands on front-desk staff. For practices in Arizona, where the state’s health information exchange has operated on an opt-out foundation since its earliest years under Arizona Health-e Connection (AzHeC) and now continues under Health Current / Contexture, understanding that legacy is not academic. It directly affects how a new EHR integration, an HIE connection, or a patient intake workflow needs to be built.
The Two Consent Models, Explained
In an opt-in HIE, nothing is assumed. A patient’s clinical information is not shared through the exchange until that patient actively agrees, typically by signing a consent form during registration or at a kiosk. New York, Rhode Island, and California are commonly cited opt-in states, and some — like Rhode Island — even allow granular consent, where a patient can specify which categories of information may be shared.
In an opt-out HIE, the default is reversed: a patient’s records are included in the exchange automatically, and the patient must take an affirmative step — usually submitting a form — to be excluded. Arizona falls into this category, alongside states such as Colorado, Maryland, Connecticut, Alaska, Florida, and Oklahoma. Opting out generally limits what other providers can pull through the exchange; it does not usually stop a provider from submitting records to the HIE in the first place, and it typically does not override disclosures required for public health reporting or genuine emergencies.
Arizona’s Opt-Out Design — and Its Emergency Carve-Out
Arizona’s approach has a specific wrinkle worth understanding: when a patient withholds consent, the HIE does not allow access to their clinical information for routine treatment purposes — but an exception exists for emergency care providers. That distinction matters operationally. A specialist reviewing a referral cannot rely on the exchange for a record on a patient who opted out, but an emergency department treating that same patient after a car accident may still be able to reach critical information such as allergies or current medications. For practices building out interoperability workflows, that means "the patient opted out" is not a single flag to check once; it is a condition that behaves differently depending on care setting.
How Other States Compare
The national picture is a genuine patchwork, which is one reason multi-state health systems and EHR vendors treat consent configuration as a per-state build, not a universal toggle.
| Consent Model | Example States / Exchanges | Practical Effect |
|---|---|---|
| Opt-in | New York, Rhode Island, California | Lower data volume in the exchange; higher administrative lift to capture consent from every patient |
| Opt-out (with emergency access) | Arizona (Health Current / Contexture), Maryland (CRISP) | Broader baseline data availability; emergency providers retain access even for opted-out patients |
| Opt-out (no emergency override) | New Mexico (SYNCRONYS) | A full opt-out means no access at all, even in emergencies, though patients may opt back in anytime |
| Opt-out, standard form-based | Colorado, Connecticut, Nebraska, Florida, Oklahoma, North Carolina, Virginia | Consent assumed unless the patient files an opt-out request through the state exchange or health department |
What This Means for Practice Onboarding Workflows
The consent model a state has chosen is not just a compliance footnote — it drives concrete build decisions for any practice connecting its EHR to the exchange:
- Intake forms need a consent field that matches the state’s default, not a generic template. A practice importing a national EHR configuration built around an opt-in assumption will misrepresent Arizona’s opt-out default unless the intake workflow is corrected.
- Front-desk staff need a clear, short script for explaining opt-out rights. Because consent is assumed, patients often only learn about the exchange when someone explains it — and are more likely to trust the process when that explanation is proactive rather than buried in paperwork.
- Emergency-access logic has to be tested separately from routine-access logic. Since opted-out records can still surface for emergency providers in Arizona’s model, any interface engine or HIE connection needs its access rules validated for both scenarios, not just the default case.
- Opt-out status has to be re-confirmed periodically. Patients can typically change their election at any time, so a one-time capture at initial registration is not sufficient for a practice that wants its records accurately reflected in the exchange over years of care.
Where This Gets Complicated for Smaller Practices
Larger health systems generally have a compliance or health-IT team dedicated to configuring consent logic correctly. Smaller and mid-sized Arizona practices often do not — they are relying on whichever EHR vendor or HIE onboarding partner they hired to have gotten the state-specific detail right. That is exactly where a neutral, statewide-focused referral approach has value: rather than a practice discovering after go-live that its intake form assumes the wrong default, or that emergency-access rules were never tested, the right vendor match up front should already understand that Arizona’s exchange is opt-out with an emergency carve-out, and build accordingly.
The Bottom Line
Consent architecture is one of the least visible but most consequential design decisions behind any health information exchange. Arizona’s opt-out model, inherited from the state’s original health-e connection initiative and carried forward by its successor organization, means data flows more freely by default — but it also means practices carry a real obligation to inform patients, honor opt-out requests promptly, and build systems that handle the emergency exception correctly. Getting that right is less about legal risk in the abstract and more about whether the exchange actually delivers what it promises: the right information, available to the right provider, at the moment it is needed.