From a request for care to a clear next step.
Healthcare happens between organizations and over time. But most of our technology was built around what happens inside each institution — separate portals, point-to-point integrations, clearinghouses and trust arrangements negotiated relationship by relationship. We’ve digitized healthcare organizations without building the common infrastructure that lets them reliably work together.
Smart Health Network provides that infrastructure: a shared, governed network for trusted transactions and interactions across existing systems. This page explains the architecture first, then uses prior authorization to show it working.
A digital front door is only the first step.
APIs are digital front doors to services. Reaching one also requires an address, a connection and permission to enter. Common standards help systems exchange information, but organizations still need a dependable way to find one another, establish trusted access and complete the work.
SHN supplies that common framework. Its Gateway connects an organization’s systems to the network and applies the required checks. The standard path runs Application → Gateway → Hub → Gateway → Application: the Hub carries encrypted messages between Gateways without reading their contents or holding the keys to decrypt them. Existing standards and content — FHIR, X12, NCPDP, REST APIs, files, documents and human-readable messages — retain their native meaning and behavior. Formally supported alternatives are described in the technical documentation.
Join. Connect. Choose. Transact.
1. Join the network. Establish identity and standing under the common Network Rules — who is participating and who is accountable, including any appointed operators.
2. Connect once. Attach existing systems through qualified Gateway functionality: self-operated — your team runs it; embedded in a product — an EHR, clearinghouse or platform incorporates it; or operator-supplied — a qualified operator or SHN Managed Gateway runs it. Each institution keeps its own identity, authority and responsibilities, whoever operates the Gateway.
3. Choose your transactions. Select supported actions and counterparties, implement the applicable native bindings, complete qualification and activate the relevant roles and scope.
4. Transact. Send and receive requests, information and responses through existing applications, and follow delivery, acceptance, status and outcomes.
And the payoff: adding a second payer reuses the Gateway, network identity and trust evidence already established — only the new relationship’s scope is configured anew.
A prior authorization, across organizations
The provider sends the request. A supported workflow sends the request and the information required for that interaction.
The plan receives and responds. The request reaches the responsible plan service. The response can confirm receipt, ask for more information or communicate a decision.
The response reaches the people responsible for the next step. The connected workflow distinguishes what has happened from what still needs to happen.
Delivery is not completion. The network distinguishes three events: delivery — the request reached the receiving endpoint; acceptance of responsibility — the plan’s workflow takes the request up for processing; and the business outcome — the plan’s reported determination. A delivery receipt does not mean a request has been approved.
The person can be included. An authorized Member experience can make progress understandable across organizations, rather than leave the patient calling each one for an answer. Current availability is described on the patients page.
The health plan makes coverage decisions. Clinicians make care decisions. SHN provides the common infrastructure for the exchange.
One connection, more useful work.
Connections and trust arrangements can be reused across participating organizations and supported transactions. The next use may need configuration, permissions and testing, but it does not require rebuilding the entire foundation.
Adding a second payer shows what reuse means. The provider keeps its Gateway, network identity and common trust evidence. What is configured anew is the new relationship itself: the second payer’s qualified receiving capability and the activation of that counterparty’s scope. Adding a different transaction type reuses the same foundation while the new native behavior is implemented and qualified.
Keep your existing EHR, payer systems and vendors. Gateway functionality can be self-operated, embedded in a product, or operator-supplied — your operating choice does not purchase different network rights.
How information is protected
Clinical content is encrypted at the sending Gateway and decrypted only at the receiving one. The Hub processes the information needed to authorize, route and prove the exchange; network audit records are distinct from clinical content. Participants maintain their clinical records and authoritative workflow status. Security teams can review the actual architecture and documentation through the developer resources and the security-review process.
Included transactions. Optional services.
Designated Open Access transactions carry no SHN participation, network-access, transaction or required Gateway-software-license fee. Optional services are separate purchases and never a condition of included transactions. The full catalog, with scope and availability, is on Open Access.