Patient Sharing — LastVet Integration (v1)¶
This folder specifies how Onset shares a veteran's protocol and adherence data with LastVet so LastVet can surface it to the veteran's providers.
v1 scope (decided 2026-05-20)¶
- One direction: Onset pushes to LastVet. Onset exposes no inbound provider read API.
- One target: LastVet (
api.last.vet). No other aggregator in v1. - One audience: veterans who use both apps. Civilian sharing is tabled — civilian providers can sign up on
clinic.theonset.appif they want access. See ADR-002 for the rationale.
Architecture (confirmed 2026-06-18)¶
Onset → LastVet → provider grants — not direct Onset→provider for the aggregator channel.
| Layer | Role |
|---|---|
| Onset iOS | Patient-initiated OAuth to LastVet; pushes protocol/adherence snapshots via POST /me/sync |
| LastVet | Patient record hub; stores Onset payloads; runs VA verification |
| LastVet provider portal | NPI-verified providers; consent_grants govern what each provider can see |
| Onset Clinic | Separate channel (ADR-001): practitioner prescribing via clinic.theonset.app |
last1.id is the portable identity layer across LastVet, Onset, and other Last1 apps. The OIDC issuer is https://auth.last1.id (marketing site remains https://last1.id). Onset links Last1.id under Integrations → Last1.id before LastVet Connect so the shared identity can match the veteran record. Last1.id is not the v1 sync transport — data flows Onset → LastVet API directly.
Documents¶
Read in this order:
| Doc | What it covers |
|---|---|
ADR_001_CLINIC_VS_PROVIDER_BOUNDARY.md |
Hard separation between clinic prescribing (write) and patient sharing (outbound push). |
ADR_002_LASTVET_FIRST_INTEGRATION.md |
Why v1 is LastVet-only and civilians are tabled. |
LASTVET_IDENTITY_BRIDGE.md |
OAuth 2.0 + PKCE + OIDC spec. Veteran verification model. JWT claim shapes. Threat model. Read before either of the two below. |
ONSET_TO_LASTVET_SYNC_CONTRACT.md |
Wire-level data API contract: payloads, sync triggers, idempotency, error handling. |
LASTVET_API_CHANGES_REQUIRED.md |
Concrete changes needed in last.vet-api and last.vet-provider (migrations, routes, middleware). |
LASTVET_CONNECT_AND_REVOKE.md |
iOS UX, Onset data model, Keychain layout, and dual-direction revoke flows. |
PROVIDER_AUDIT_AND_PATIENT_ACCESS_HISTORY.md |
data_share_events table and patient-facing activity list. |
PROVIDER_LAST_VET_PILOT_ROLLOUT.md |
Phased implementation plan with exit criteria and KPIs. |
Three channels at a glance¶
| Channel | Direction | Status | Surface |
|---|---|---|---|
| Clinic prescribing | Practitioner → patient (write) | Existing | clinic.theonset.app → Onset iOS |
| LastVet sharing (veterans) | Onset → LastVet (push) | v1, this folder | Onset Settings → "Connected health records" |
| Civilian sharing | (tabled) | Workaround: provider signs up on clinic.theonset.app |
n/a in v1 |
Veteran verification — why there is no is_veteran flag in Onset¶
Self-attestation is not verification. Adding a "Are you a veteran?" question to onboarding would create a soft fiction that neither side could trust. LastVet runs the actual VA Lighthouse verification work and exposes its result through OIDC id_token claims after a successful OAuth dance.
Therefore: a successful OAuth into LastVet IS the verification. The "Connect to LastVet" card in Onset Settings is visible to all users; civilians who tap it can't get past LastVet's authorize screen. Onset stores the veteran identity claims it receives (verified, branch, rank) for display only — it does not derive or persist any separate veteran flag. Full reasoning in LASTVET_IDENTITY_BRIDGE.md.
What previously lived here, and why it's gone¶
An earlier draft proposed Onset would stand up a generic SMART-on-FHIR-style provider authorization server with per-scope grants and a provider data access contract. That described a system Onset doesn't need to build:
- LastVet already runs the provider portal, the consent grants, the NPI verification, the audit log, and the 42 CFR Part 2 redaction. We integrate with it; we don't duplicate it.
- For civilians, we don't yet have a single ask for it. When we do, snapshot-share is likely a better answer than running an OAuth server.
The deleted documents (PROVIDER_AUTH_SMART_FHIR.md, PROVIDER_DATA_ACCESS_CONTRACT.md) and the earlier versions of the rewritten ones live in git history under the commit prior to this rewrite.