How it works

One hub. Sealed envelopes. The patient at the center.

Smart Health Network is a switchboard that can’t listen in. Every transaction moves in a sealed envelope — encrypted at the source, routed by a hub that cannot decrypt what’s inside and processes only the metadata required to authorize, route, and prove the exchange, opened only by the party it’s meant for. The real work happens at the edges, in a Smart Gateway each participant runs (or has run on its behalf); the hub in the middle only routes and proves delivery. Nothing is pooled into a central store, and the patient sits at the center — able to see network-routed requests, decisions, and access records under the network’s consent and privacy rules.

Why a shared hub matters

Healthcare doesn’t have a prior authorization problem. It has an administrative-network problem: every payer builds separately to every provider, and every provider separately to every payer. Smart Health Network changes the topology — one governed path for the administrative transactions that slow care down, without pooling records into a central database.

One connection, a growing catalog of transactions.

Most networks do one job. This one is built to carry them all. Everything the network does is a transaction type in one governed catalog — prior authorization first, because that’s where the pain and the federal deadline sit, with eligibility following as it is enabled; claims and remittance in April 2027, when the biggest savings begin; pharmacy prior authorization in July and quality and value-based reporting in October, on the published calendar. Each new release arrives on the connection you already have — each quarterly release is delivered through the network’s published software and conformance process; activating a transaction is a governed configuration and readiness decision made by the participant or its operator — never an automatic or silent update, and not a new bilateral integration project. Connect once, reach everyone, and the catalog comes to you.

The transaction catalog

Every capability on the network is a transaction type in one governed catalog — published, versioned, and arriving on a set calendar. Each new category lands on the same connection under the published utility-fee structure — no new bilateral integration and no separate capability fee.

Prior authorization is the first transaction, not the program. The same shared rails carry each release on the published calendar.

What the claims release means. Claims on the network is an additional, standards-based route for claims submission, claim status, attachments, and remittance — carried in the formats payers already run (X12 at the edges; the gateway handles translation). It does not require a payer to build new claims APIs, replace its claims engine, or abandon existing routes — payers may connect through their gateway or through the clearinghouse they already use. The network adds a route; it never removes one. The claims operating model — routes, partner roles, and activation sequence — is being finalized with launch participants ahead of the January 13 Claims & Remittance Connectathon.

State-option workflows can ride the same shared rails later: eligibility/redetermination support, program-integrity support, public-health reporting, Medicaid quality, and other state-specific lanes.

How markets launch: scheduled, not sold.

The network launches market by market. Each launch cohort has named participants and a defined minimum production scope, and additional participants activate continuously after launch. New transaction releases arrive on the target release calendar — subject to launch-participant readiness and governed release approval — each proven at a Connectathon roughly ninety days before it ships.

Built like modern infrastructure

The network is new construction — cloud-native, API-first, and built on open, published standards, including HL7 FHIR and the federal interoperability APIs — and built to interoperate with the X12 transactions the industry already runs at the edges. That is why a new mandate becomes a network release, not another bespoke compliance build.

It is also built to be trusted the way infrastructure must be. The industry has learned the risk of depending on rails embedded inside a single company’s proprietary systems. SHN is structurally different: participants connect through gateways they control, keep their own data and their own connections, and route on open standards with no proprietary lock-in — and the rules are set by neutral governance, not by a competitor. Privacy is architectural, not contractual: transactions move like registered mail, sealed at the sending gateway and opened only at the receiving one — the hub reads the envelope label, never the contents. The claim is not that infrastructure can never fail; it is that standards-based, participant-controlled connections make failure more recoverable and less captive than a proprietary hub inside one commercial actor.

Two ways to test, one hosting decision

The network is the constant. How you connect to it is your choice — and you can deepen it without starting over: the organization does not start its participation history over as the operating model evolves, and SHN’s published network utility rates do not change based on operating mode (independent implementation or operating services may have their own charges).

• Testing — the cloud sandbox (most teams start here) or the Local Test Kit on your laptop; synthetic data, before any commitment. For payers, testing starts even simpler: SHN connects to the standard APIs you’re already building.
• Hosting — a gateway you host at your own edge (your IT vendor or systems integrator running it is still you-hosting), or SHN hosts it as a managed service under your authority and the applicable key-custody controls. Partner-hosted arrangements may become available over time.

Qualified platform vendors — EHR, HIE, or RCM systems that want to integrate the network workflow natively — contact SHN.

The path from testing to production is deliberate: Test → Activate → Integrate → Expand → Sustain. Activation requires agreements and production credentials — issued through organizations that already know you, under network credentials governed by the independent Council; integration deepens on your timeline; later releases use the same network relationship and published upgrade process — without building a new bilateral connection to every counterparty each time.

Free where it’s a public good, paid where the savings are

Foundational capabilities — a patient’s access to their own information, eligibility, public-health reporting — are free at the network layer, for everyone. Prior authorization is free to use, funded by the network’s utility fees. Two published fees fund the network: a flat per-member participation fee for payers, and one provider utility fee on routed paid-claim volume. Patients never pay. Surplus is reinvested, not extracted. The rates are published. See pricing →

From sandbox to live

You start in a sandbox on synthetic data — the same Gateway, the same rules, no real patient information — and run the conformance checks until you’re ready. Connectathons (the first was July 13 in Delaware — 200+ participants; the national readiness Connectathon is October 14) are where you prove it against the live test network. When you’re conformant, the same setup can move toward production after executed agreements, production credentials, and completed launch checks — a promotion process being finalized with launch participants ahead of January 1. Going live is a deliberate step with its own agreement and credential — but there’s no rebuild between testing it and doing it.

What happened at the July 13 Delaware Connectathon →