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. Production activation will require executed participation agreements, production credentials, and completed launch checks — the production promotion process is being finalized with launch participants ahead of January 1.
Start in the sandbox — three steps
The steps below are the self-service path. Working with a Certified Network Partner instead? They run these same three steps on your behalf — your part is saying yes and granting access. Either way, what follows is identical: same bundle, same discovery document, same signed admission.
- Run one published bundle — the gateway image with its built-in, IG-loaded FHIR validator.
- Point it at the network — one machine-readable discovery document configures your gateway against the live endpoints and pinned versions. No kickoff call, no key-swapping emails.
- You’re testing. Sandbox admission is automated once credentials are issued — you prove possession of your own keys, and every lifecycle event is signed into the audit chain. Production participation requires executed agreements, organization-authorized production credentials, and completed capability and launch checks.
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.
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. Connect directly, or through a certified partner — same network, same rates. →
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 five 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
Five 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.
- Non-aggregation — no component persists a cross-organization record or a patient→organization index.
- Payload-blind routing — the Hub is constructed without a decryption key. It cannot read what it routes.
- 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.
- Tamper-evident audit — every leg lands in an append-only, hash-chained, externally anchored log. Metadata only, never content.
- 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 R4 + US Core 6.1.0 · Da Vinci CRD/DTR/PAS 2.0.1 · 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.
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.
Go to the developer portal →Questions: developers@smarthealthnetwork.org