Smart Health Network

Smart Health Network

Utility infrastructure for federated health.

Mission-locked. Capture-resistant. Patient-fiduciary by architectural construction. Delaware Public Benefit Corporation. Federated query-to-data architecture. Substrate operates persistently.

Thesis

Smart Health Network is healthcare federated-data utility infrastructure — designed for persistence, utility-tier operational continuity, generation-long horizons.

Four commitments are load-bearing:

Mission-locked. Legal obligation runs to mission rather than shareholders. Delaware Public Benefit Corporation.

Capture-resistant. Four institutional bodies separated by structural design — operator, governance, patient-fiduciary, philanthropy — with non-aligned reasons-to-exist.

Patient-fiduciary by architectural construction. Substrate commitments to patients exist in the architecture itself, not in policy claims. They are non-modifiable at the architectural-commitment layer.

Patient at the architectural center. The substrate is organized around the patient logical record — the addressable virtual reference point that lives distributed across providers, payers, and other holders. Operations are evaluated against the patient logical record, not against any institution view of the patient. The patient is the architectural primary, not a downstream concern.

Substrate-grade infrastructure tier comparable: Stripe (payments infrastructure), Vercel (deployment infrastructure), Anthropic (AI infrastructure), DNS / certificate authorities.

Architecture

First-cohort demonstration opens at sandbox-grade with Synthetic Data discipline June 9, 2026. Production-grade tenancy with real PHI Q3 2026, contingent on per-participant Network Promoter Agreement, Form BAA, and Smart Health Council certification.

The Hub. The Hub is the substrate routing component. It routes operations between providers (who hold records), payers (who authorize operations against published criteria), and patients (the architectural primary). The Hub is payload-blind — it routes operations without reading the records. Records never leave their custodians.

Three-way routing pattern. Every federated operation routes through the Hub between three roles: a provider holding records, a payer evaluating against published authority criteria, and a patient whose logical record is the operation organizing reference. The patient sees what was asked, what was decided, what was disclosed — by architectural construction.

Per-operation authority binding. Every operation evaluated against per-operation authority — not blanket access, not standing privilege.

Identity architecture. Three layers with distinct scopes — substrate routing, identity resolution, patient-claimed identity. Composes with existing identity infrastructure such as commercial EHR patient portals, state HIE master patient indices, and sovereign jurisdiction identity systems. Does not aggregate.

Onboarding patterns. Five patterns at the utility infrastructure layer — EHR integration, health system, payer network, state network, AI agent federation. Sandbox-first; production by invitation.

Developer surfaces. Reference documentation at developers.smarthealthnetwork.org. Operational substrate surfaces at *.smarthealthhub.net subdomains.

Read technical architecture →

Use cases

Every federated use case operates through the same three-way routing pattern at the Hub — provider, payer, patient. The substrate routes; provider records stay in custody; payer evaluates against published criteria; patient sees the decision.

Five federated use cases architecturally supported at first-cohort scope. Federated prior authorization demonstrates end-to-end first; the remaining four federated use cases reach end-to-end at production-grade trajectory.

Federated prior authorization. Provider holds the clinical record; payer publishes prior-auth authority criteria; substrate routes the query to the provider; provider data layer evaluates clinical accuracy against criteria in place; patient sees what was asked and decided. CARIN Alliance + Da Vinci PAS composition.

Federated patient access. Patient requests records under §164.524 right-of-access; substrate routes the request to record-holders; records remain in custody; patient receives an aggregated view. CARIN Alliance + CMS Patient Access API composition.

Federated quality measurement. Payer (or measure-steward) publishes HEDIS measure criteria; substrate routes the measure query to provider data layers; measure evaluates in place; aggregated result returns. NCQA composition.

Federated public health reporting. Public health authority publishes §164.512(b) reporting criteria; substrate routes to provider data layers; reporting data returns under per-operation authority.

Federated eligibility verification. Provider asks; payer answers against eligibility criteria; substrate routes; patient sees what was asked. 270/271.

Governance

Four institutional bodies, structurally separated by design:

Smart Health Council — standards and certification. Governs network rules and conformance criteria. Ratifies architectural commitments. Promulgates the Patient Bill of Rights. Council is a Delaware purpose trust, structurally analogous to the Anthropic Long-Term Benefit Trust with healthcare-substrate-governance scope. smarthealthcouncil.org

Smart Health Network PBC — operates the substrate. Delaware Public Benefit Corporation; mission-locked at the corporate charter. Board fiduciary duty runs to the public benefit purpose, not exclusively to shareholders. Operates under Council rule-setting and standards-conformance certification; subject to Trust patient-fiduciary representation at the governance layer. Publishes a public benefit report at least biennially.

Smart Health Trust — patient-fiduciary representation at the governance layer. The Trust holds patient-fiduciary representation at governance scope because the patient is the architectural primary — patient interests are the substrate organizing reference, not a downstream concern. Advocates for patients, including against the operating company where operational interests diverge from patient interests. (In formation; Delaware purpose trust constitution forthcoming Q3–Q4 2026.) smarthealthtrust.org

Smart Health Foundation — forming 501(c)(3) public charity (Form 1023 filing forthcoming). Receives, redistributes, funds the precompetitive layer. smarthealthfoundation.org

These bodies operate at distinct scopes. Council governance is separate from PBC operation. Trust patient-fiduciary representation is separate from PBC operation. Foundation philanthropic capital is separate from PBC operation.

The substrate commitments to patients exist by architectural construction — they cannot be re-negotiated by any future operator decision, capital event, or political cycle.

Developers

Reference documentation and SDKs at developers.smarthealthnetwork.org.

  • Public ADR registry — architectural decision records
  • SDKs and integration guides
  • FHIR Accelerator IG composition documentation
  • Reference architecture for AI agent federation
  • Sandbox environment access

Operational substrate surfaces at *.smarthealthhub.net subdomains (sandbox, api, widgets, demo, match).