Sandbox tenancy onboarding
Get sandbox access in five steps.
Register a sandbox tenancy. Receive a sandbox API key bound to your tenant. Build with substrate widgets, SDKs, and sample apps using synthetic data from the W6 toolkit. Audit chain emits substrate-event-records signed by the audit-signing-service Step 6 endpoint.
Sandbox tenancy registration
[MSE UX scope; pending CPL register-distinction-discipline review + GC sandbox terms-of-use legal framework + substrate-side wire-contract delivery] Register with your organization name + contact email. Substrate-side issues a sandbox API key bound to your tenant ID + sandbox-tier scope binding. Tenant-fence enforced at substrate-network layer; cross-tenant access architecturally blocked.
Sandbox tenancy is governed by the Smart Health Council under the Council certification framework. SHN PBC operates the sandbox infrastructure and issues sandbox API keys under sandbox CA service per Track B v0.1. Synthetic data only in sandbox; production deployment Q3 2026.
What you can do with sandbox access
- Embed Pattern (c) widgets — <smart-prior-auth> (UC22 Federated Prior Auth canonical lead use case) + <smart-patient-access> (§164.524 Federated Patient Access)
- Build with the TS SDK consuming substrate-types canonical via Pattern (b)
- Test against synthetic patient encounter data (W6 toolkit Stages 1-3 — FHIR R4 + X12 837P + NCPDP D.0 + AuditRecord/SubstrateEventRecord generators)
- Inspect substrate-event-records signed at audit-signing-service Step 6 endpoint
- Compose with Federated Prior Auth canonical pattern — substrate routes payload-blind; provider's data layer evaluates against Council-published Use Authority template