Build on the Smart Health Network.

One connection reaches every authorized participant — payers, providers, and the patients they serve. The network runs on the standards your systems already speak: HL7® FHIR® R4 with US Core and Da Vinci CRD/DTR/PAS for prior authorization today. X12 arrives at the network’s edges with the April claims release — carried in the formats payers already run, alongside the routes they already use. The work you’ve done for CMS-0057 is the work — the network adds reach, not rework.

Prior authorization isn’t the product. It’s the first transaction. The product is shared administrative rails.

Build the connection once for prior authorization; on the same network relationship — without rebuilding a bilateral connection to every counterparty — the same integration then carries claims, remittance, pharmacy prior authorization, and quality and value-based reporting on the published calendar, plus new governed categories as the catalog grows. Every release arrives through the published software and conformance process; activating it is your readiness decision, never a silent update.

Sandbox only. Use synthetic data only — the production promotion process is being finalized with launch participants ahead of January 1.

Start in the sandbox — pick your path

Four quickstarts, one network. Working with a Certified Network Partner instead? They run these same steps on your behalf — your part is saying yes and granting access. Either way, what follows is identical: same bundles, same discovery document, same signed admission.

What you’ll be able to run: realistic prior-authorization workflows against synthetic data — submit a request with documentation attached, route it to a payer, return a decision, and see the audit events structured for authorized patient visibility, end to end, through the shared hub.

See it work first

Local Test Kit. Built for on-your-laptop testing: the kit bundles an actual gateway, reference provider FHIR servers, and a UI that — with a free developer account — auto-registers a full provider gateway and synthetic EHR on the hub. You see real Da Vinci flows run through a real gateway talking to the real preview hub, with nothing to deploy or configure. It’s a reference implementation for testing — not the deployment path. Nothing touches your production systems.

Gateway Reference Implementation. The open-source gateway code, published for review and testing: run it locally against the sandbox, inspect exactly what a network edge does, and evaluate the integration surface your organization or partner would operate in production.

Create a free developer account → download the Local Test Kit

Keep your Da Vinci stack

If your systems already speak Da Vinci, the gateway meets them there.

Providers: point your existing CDS Hooks (CRD), DTR $questionnaire-package, and PAS $submit clients at the gateway’s native ingress — your workflow doesn’t change.

Payers: delegate the CRD, DTR, and PAS legs to your own Da Vinci endpoints over SMART Backend Services — your existing rules engine and adjudication stack stay the source of truth for decisions.

Three ways to integrate

Connect behind a gateway at your own edge; have a Certified Network Partner — your HIE, your EHR vendor, a revenue-cycle firm — deploy and operate the gateway on your behalf; or implement the published protocol directly in your own stack. Same contracts, same conformance gate, whichever path you choose — and in states with funded onboarding, the partner path costs a provider nothing. To the gateway, the direct-FHIR and EHR-native paths are indistinguishable — if it speaks Da Vinci, it routes; the only requirement is a Coverage.payor identifier the network’s resolvers can map. Most deployments require outbound connectivity only. Connect directly, or through a certified partner — same network, same rates. → The Get Connected two-pager →

Everything is public

Everything you need to evaluate the network is published — no NDA, no sales call:

• Technical architecture — how the network works, from the structural commitments to the wire contract. Read it on GitHub →
• Participant protocol and SDK — the published wire contract, a dependency-light client SDK, and a reference participant implementation, versioned under a documented stability commitment. GitHub →
• The gateway is open source — inspect the code that seals, validates, and routes, rather than trusting a black box. Reference connectors ship for FHIR R4 systems of record, plus a scaffold for non-FHIR backends (HL7v2, X12, SQL).

Guarantees you can test

Structural commitments, each enforced by what components can and cannot hold — and each asserted by live invariant tests: mutate one byte, one field, one sender, and the network refuses it.

1. Non-aggregation — no component persists a cross-organization record or a patient→organization index.
2. Payload-blind routing — the Hub is constructed without a decryption key. It cannot decrypt the clinical or administrative payload; it processes only the metadata required to authorize, route, and prove the exchange.
3. Per-operation authority — no standing access; every message leg carries a fresh, signed token bound to that exact exchange, down to a hash of the encrypted payload.
4. Tamper-evident audit — every leg lands in an append-only, hash-chained, externally anchored log. Metadata only, never content.
5. A patient surface that holds nothing — patients see what happened with their data through an account that reads through to canonical sources and stores none of it.

Pinned, versioned, stable

You always know exactly what you’re building against: FHIR core 4.0.1 (R4) + US Core 6.1.0 · Da Vinci CRD, DTR, and PAS 2.0.1 · Da Vinci PDex 2.1.0 · wire protocol v1.1.0 — advertised in the discovery document and pinned per release, with a documented stability commitment on the published artifacts.

Current releases: shn-gateway v0.30.0 · shn-sdk v0.32.0 · shn-kit v0.9.9 · Pins verified July 27, 2026.

New transaction releases are delivered to your gateway. Each quarterly release delivers its rails to your gateway; activating a transaction is a governed configuration and readiness decision made by your operator — never an automatic or silent update. Build once; the catalog comes to you.

Proven in the preview network

On the preview network today, two independent third-party Da Vinci reference implementations — an external provider and an external payer, each running its own systems and holding its own keys — complete a full prior authorization with each other, end to end. Same contracts you’d use; there is no separate demo path.

Request sandbox access

Create your account and get sandbox credentials in the developer portal — synthetic data, the free CMS-0057 Readiness Check, and synthetic prior-authorization endpoints.

Questions: developers@smarthealthnetwork.org