Introduction
FAST SCRIPTS
Prescribing infrastructure you can read, run, and integrate before you talk to anyone. Full API access, open contracts, transparent state machines, and a complete local environment — with the certified network connection kept behind a deliberate, provider-neutral boundary.
FAST SCRIPTS accepts synthetic fixtures only. It cannot approve, sign, route, transmit, cancel, or renew a prescription. It has no pharmacy or prescription-network connection, does not support controlled substances, and makes no certification, compliance, licensure, clinical-safety, or production-readiness claim. Never place real patient data or production secrets in this system.
#What this is
Electronic prescribing is already the default in United States ambulatory care. The transport problem is solved. The developer layer is not: software teams that want native prescribing inside a product they control still meet a buying process built for 2009-era health IT — documentation after a sales call, sandbox access after signed terms, an iframe first, and customization later, if ever.
FAST SCRIPTS is being built as the layer that makes prescribing composable: prescribing workflows exposed as APIs, typed SDKs, local fixtures, webhooks, transparent state machines, and headless UI components. The reference point is what Stripe did for payments — full API, open documentation, a local sandbox, and your own interface — applied to prescribing.
The long-term goal is a production e-prescribing platform. The near-term goal, and everything running today, is to build the correct engine and developer surface first, under a hard synthetic-only boundary, so every control a live system needs exists and is tested before anyone claims live transmission.
#Start here
Quickstart
Run the complete stack locally in one command, then create a synthetic draft and open a review. →
Capability status
How to read every capability claim in this documentation — built, simulated, or gated. →
API reference
The four active HTTP operations, their contracts, headers, and idempotency semantics. →
Architecture
Modular monolith, enforced package boundaries, and the integrity spine underneath. →
#What runs today
One vertical slice, deliberately narrow and complete through every layer it touches:
- Create a draftA locally authenticated caller submits one supported synthetic draft with an idempotency key.
- Resolve and snapshotThe backend resolves tenant-bound context across the full authority graph and records exact medication, diagnosis, quantity-unit, and direction snapshots.
- Validate mechanicallyEight deterministic checks produce a version-bound result that always remains
clinicallyComplete=false. Blocking findings persist nothing. - Commit atomicallyOne transaction stores the aggregate, status history, evidence, outbox row, one-time grant verifier, and encrypted idempotent response — guarded by a commit-time re-lock.
- Exchange a one-time grantThe browser strips the secret-bearing URI fragment, exchanges it exactly once within five minutes, and receives a short-lived, device-bound review session.
- Read, and only readThe review surface renders the exact bound projection. No approve, sign, edit, or send control exists. The draft expires at 24 hours.
#Design principles
Fail closed, always
Unresolved authority is denied by default. A failed, unavailable, or skipped check is reported as exactly that — never converted into a passing result.
Evidence is transactional
Audit, validation, and lifecycle evidence commit in the same transaction as the mutation they describe. If evidence cannot commit, the mutation does not happen.
Simulation is never disguised
A prescription is never labeled sent, delivered, accepted, clinically approved, or legally signed when only a local simulation occurred.
Snapshots, not references
Clinically material values are copied into immutable snapshots at creation, so later catalog changes can never rewrite prescribing history.