Skip to content

Onset Clinic × Fullscript — Partner Evaluation Brief

Integrator: Last 1 Enterprises LLC
Product: Onset Clinic Portal + Onset patient iOS app
Contact: Ryan Curry — ryan@theonset.app
Date: June 2026
Environment: Sandbox (us-snd) — staging demo below; production integration disabled pending partner review.

1. Integration scope (Phase 1 — protocols only)

Onset Clinic is a supplement protocol organizer for wellness practitioners. Fullscript is the dispensary and treatment-plan authoring system. Practitioners build plans in Fullscript; Onset pulls active treatment plans into a per-patient master protocol, merges any manual Onset-only supplements, and delivers the unified protocol to the patient’s Onset iOS app.

In scope

Capability Direction Notes
Practitioner OAuth Fullscript → Onset Per-practitioner connection; tokens encrypted at rest
Patient import / link Fullscript ↔ Onset Email match; explicit link rows
Pull active treatment plan Fullscript → Onset Product names via catalog variant lookup
Auto-sync on plan change Fullscript → Onset Webhooks + hourly Events API poll
Push patient identity Onset → Fullscript Create/link chart only (no plan push)
Open in Fullscript Onset → Fullscript Dynamic links; native Fullscript UI for catalog/plans
Protocol delivery to patient app Onset internal Configurable timing; separate from FS ordering

Explicitly out of scope (not requested for eval)

Excluded Reason
Fullscript Labs API Reduces compliance surface; labs are not part of this integration
Push protocol (Onset → Fullscript) Phase 2; deferred until variant-ID mapping is finalized
In-portal Fullscript Embed (iframe) Disabled by default; practitioners use Fullscript directly in a new tab
Fullscript ordering in Onset Patient supplement ordering remains in Fullscript; Onset stores a reference link only

OAuth scopes requested: catalog:read, clinic:read, clinic:write, patients:read, patients:write, patients:treatment_plan_history — no labs scopes.

2. Data flow (high level)

Practitioner
    │
    ├─► Fullscript (us-snd) — build/edit treatment plans, patient ordering
    │
    └─► Onset Clinic Portal
            │  OAuth connect (per practitioner)
            │  Pull latest active plan → master protocol (Supabase)
            │  Webhook / cron on plan.updated
            │
            └─► Onset patient iOS app
                    Connection code → claim assignment → supplement routine

Data stored in Onset (from Fullscript pull)

  • Treatment plan ID, sync timestamps, plan items (name, schedule, variant/product refs)
  • Fullscript patient ID link (scoped per practitioner)
  • Sync audit log (fullscript_sync_log)
  • Optional patient ordering URL (reference only; opens in Fullscript)

Data not pulled from Fullscript

  • Lab orders/results
  • Payment / checkout data
  • Full patient chart beyond what is needed for plan sync

Patient isolation: A plan is merged only when practitioner scope, link row, and verified email match align. Mismatches are rejected and logged.

3. Staging demo (sandbox E2E completed)

Item Value
Clinic portal (staging) https://clinic-theonset-app-staging-staging.up.railway.app
Fullscript sandbox https://us-snd.fullscript.io
Demo flow Connect Fullscript → import/link patient → pull plan → send to patient app
Verified Pull, auto-sync (webhook/cron), named supplements, delivery settings, patient isolation

Suggested demo path: Patients → Connect Fullscript → Fullscript roster → link patient → Pull latest protocol → Send to patient app (Apply immediately). Patient app connect via connection code (Onset Staging TestFlight) is in final QA.

Production: FULLSCRIPT_INTEGRATION_ENABLED=false and FULLSCRIPT_CUSTOMER_AVAILABLE=false on production until partner approval and compliance gates are confirmed.

4. Security & compliance posture (summary)

  • Wellness organizer framing — Onset organizes and displays supplement routines; it does not provide clinical decision support or lab interpretation.
  • SHIELD-style controls — patient consent for shared data, connection-code rate limits, provider access audit events, least-privilege APIs.
  • HIPAA crossover prevention — documented patient isolation invariant, link audit script, practitioner-scoped link rows.
  • Documented production gates (internal) — SOC 2 Type 2 + Sub-BAA with Fullscript + partner approval before production enablement.

We are not claiming HIPAA-covered-entity status for the clinic portal unless separately contracted with each clinic.

5. Questions for Fullscript partner review

  1. Partner / technical review — Can we schedule eval review against the staging demo above with protocol sync only (no labs, no embed, no push-protocol)?
  2. SOC 2 Type 2 + Sub-BAA — Are these required before sandbox/partner eval, or only before production OAuth and live practitioner rollout?
  3. Production credentials — Process and timeline for production OAuth app, webhook registration, and go-live checklist.
  4. Scope confirmation — Any objection to launching Phase 1 without Labs API, Embed UI, or bidirectional protocol push?

6. References

  • Internal integration doc: docs/FULLSCRIPT_INTEGRATION.md (repo: Last-1-Enterprises/clinic.theonset.app)
  • Fullscript API: treatment plans, dynamic links, webhooks (sandbox configured)

Production flags remain off until Fullscript confirms eval requirements and partner approval path.