Build

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 Preview test environment (shn-preview.org) — 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.

  1. Register an API client — self-service, no kickoff call: POST pa-test.shn-preview.org/register or register in the developer portal.
  2. Discover authentication metadata — the published discovery document carries the token endpoint and pinned versions.
  3. Obtain a tokenprivate_key_jwt (recommended); access tokens are short-lived (five minutes) with the system/Davinci.write scope.
  4. Send CRD/DTR/PAS requests against the preview test routes — synthetic data only.
  5. Verify the expected results — the free CMS-0057 Readiness Check scores per-scenario pass/fail across the eight prior-authorization use cases.

The self-service cloud path is a preview-testing surface — right for validating request construction and routing; production integration runs through the gateway paths.

Environment: one test environment — Preview (shn-preview.org), production-grade but not production; synthetic data only; there is no separate UAT. Every route referenced above is a preview route.

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 use case and any optional service — and in states with funded onboarding, program funding covers the tasks and organizations named in the program; other vendor or operating costs may remain with the provider. Start with your existing Da Vinci implementation. The connection review identifies the operations, versions, authentication, payer and product routing and response path used in your test. Your systems remain in place; configuration, integration or workflow changes may still be needed. Connect directly, or through a qualified partner — same network, same conformance, same Open Access rights. → The Get Connected two-pager →

Everything is public

Source code, protocol documentation and preview instructions are public. Security reports — including the SOC 2 Type II report — and configuration-specific diligence materials are provided through the appropriate review process. To evaluate the software and protocol:

  • 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. The SDK targets synthetic-data testing; see the repository README’s not-for-production notice. 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

These are the current Preview release pins — 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. Designated Open Access use cases carry no SHN fee within their defined scope; optional services are separate purchases. New use cases are delivered through the published software and conformance process. Each release delivers its updates 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; supported use cases arrive through the same connection.

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 access

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 Preview 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