Deloitte Follow-Up — Cover Note¶
To: Mike, Anupam, and team
From: Ryan Curry, LastVet
Re: Data persistence during a typical session (Day −7 sync / Day 0 provider visit)
Attached materials¶
- VA_DATA_PERSISTENCE.pdf — full write-up with persistence matrix, session TTLs, and FAQ
- va-data-persistence.png — as-built architecture diagram
The direct answer to your question¶
When a provider views a veteran's VA record on Day 0, they see a consent-gated read of the veteran's last sync from LastVet's encrypted Postgres — not a live FHIR pull from VA Lighthouse.
| Step | What happens |
|---|---|
| Day −7 (veteran prepares) | Veteran signs in with VA on iOS → FHIR pull → local cache → POST /health-record/me/sync → Postgres |
| Day 0 (provider visit) | Provider logs in with their own LastVet credentials → consent check → Postgres read → JSON held in browser memory only |
VA OAuth tokens stay on the veteran's device (Keychain). They are never stored on LastVet servers. The provider portal does not persist PHI on disk (cache: no-store).
What this package intentionally does not cover¶
This follow-up focuses on data persistence and provider access path only. It does not include VA Lighthouse production access positioning, Part 2 deep-dive, or platform scope materials — those are in a separate VA reviewer package being finalized separately.
Questions¶
Happy to walk through any section on a call. privacy@last.vet
LastVet · June 2026