Build once. Reach further.

Use a common connection to make your healthcare application useful across more organizations. Smart Health Network provides published interfaces, reference software and a shared testing environment, starting with prior authorization.

The goal is less time rebuilding connectivity and more time improving the work your users need to do.

Choose your first test

Use the cloud API sandbox to try supported requests and responses without running a local Gateway. Use the local reference software to explore the Gateway and your integration. Follow the current developer instructions for registration, credentials and supported versions.

Synthetic data only. Do not send real patient information or production credentials.

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; authorize a qualified operator — your HIE, your EHR vendor, a revenue-cycle firm, or a cloud environment — to deploy and run the gateway on your behalf; or implement the published protocol directly in your own stack. Same network identity, rules, and conformance model, whichever path you choose — commercial treatment depends on the applicable interaction, Utility, Capability, or service — 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 conformance, same Open Access rights. → 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 — in the current routing architecture, no routing 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. Patient visibility reads through — network-routed activity is surfaced to authorized patients from canonical sources, not assembled into a new central store.

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 release and standard pins live with the code: see the developer portal and release manifest.

Each governed interaction defines permitted actors, purpose, authority, FHIR/API profile, state transitions, service expectations, conformance requirements, and exception behavior. The wire protocol and conformance standard do not change based on commercial treatment. Some interactions are designated Open Access; Utilities and optional capabilities may carry separate economics. 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.

Start building on the shared path

Choose one synthetic workflow and use the published instructions to run it. Bring the result — and anything that did not work — to the testing team.

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