LastVet / Last 1 Enterprises LLC Prepared for: Melissa Bianchi (health-data practice lead) and team Date: 2026-07-23 (rev; initial 2026-07-21) Contact: Ryan Curry · privacy@last.vet
This packet collects counsel-ready architecture and compliance materials for the master HL engagement (tracked in Muster). Disclosed known issues are listed first, before review asks, using the same discipline as the unprompted VA data-persistence correction (June 2026).
Disclosed known issues (corrected in writing before counsel asks)¶
A veteran can revoke a provider's access to their record; revocation is enforced at the consent engine before PHI is served.
What was true
A veteran could hold two active consent grants to the same provider (Grant Access + ROI sign). Revoking one grant left the other active. Revoking the ROI grant did not stop mental_health or SUD access when a surviving full_record grant carried Part 2.
API fix (shipped 2026-07-21)
Migration 052_dual_grant_fix.sql: merge dual pairs + consent_grant_authorizations + merge audit. Engine: ROI attach (no second row), revoke-all per provider, partial revoke returns 409 with surviving grants unless confirmPartial. Prod merge: Sheba703 / Test Provider. Tests: tests/dual-grant-revocation.test.ts.
Client fix (shipped 2026-07-23)
TestFlight proof on prod API: Edit Access (scopeMode=replace, audit grant_amended via migrations 054–056), Revoke all (no 500), single-grant Revoke Access, pull-to-refresh cancellation fix. Minimum builds: iOS 21695a7, API 9282ab4.
409 survivor path
Hand-verified logic in client; not exercised on prod (Test Provider is single merged grant). Staging dual-grant seed available for counsel demo if needed. Primary veteran action is Revoke all.
HL ask
Confirm amendment vs. new-authorization language when ROI updates an existing grant; confirm "revoke all for provider" satisfies 42 CFR Part 2 revocation expectations for SUD scopes.
Pilot gate
~~Do not admit real veterans until TestFlight proof~~ Client proof complete. Real veteran pilot still blocked on issue #2 (Part 2 sheet artifact) and D10 counsel lock.
2. Part 2 dual consent paths — open; one path lacks signed artifact; both gate SUD today¶
Discovered
2026-07-21 (prod trace during dual-grant fix)
What we claim
SUD records require 42 CFR Part 2 consent before disclosure.
What is true
Two paths create active part2_consents rows: (a) ROI sign — signed 10-5345 PDF + Part 2 row in one transaction; (b) Grant Access — in-app Part 2 sheet → POST /me/consents/:grantId/part2 with no signed authorization artifact. Engine gates SUD on the part2_consents table for both.
Prod evidence
Sheba703 / Test Provider (sandbox): after merge, active Part 2 rows on the survivor grant have consented_at2026-07-21T17:37:34Z and 17:37:37Z (Grant Access sheet). Signed ROI completed 17:38:12Z. Merge kept pre-existing sheet rows; ROI-linked Part 2 did not replace them. Signed ROI PDF is on the survivor grant; Part 2 enforcement row is sheet-sourced.
HL ask (direct)
Does the in-app Part 2 consent sheet satisfy 42 CFR Part 2 written-consent requirements for SUD disclosure? If not, what specific elements or signed artifact are required before Grant Access may include SUD/full_record scopes?
Engineering tracker
Muster: Part 2 Grant Access signed-artifact fix (track after HL answer)
Pilot gate
Real veteran pilot blocked until HL answers and engineering unifies or documents the compliant path.
2026-07-23 (internal audit after AWS role split; found while tracing empty DD-214 vault on staging)
What we claimed
Batch 1 PHI tables (documents, health_record_items, provider_notes, self_reported_entries) are isolated by PostgreSQL RLS under lastvet_app.
What was true
On Railway, the Postgres superuser bypassed RLS even with FORCE ROW LEVEL SECURITY. After AWS migration, the API pool uses lastvet_app (NOBYPASSRLS). ~22 runtime call sites still queried those tables withoutapplyRequestDbContext, carrying the old assumption.
Failure mode
Fail-closed throughout: SELECT → empty/404; INSERT/UPDATE → RLS violation (500). No cross-veteran leak observed. Storage cap check was fail-open (SUM → 0). iOS (try? await api.getDocuments()) ?? [] masked list failures as an empty vault.
None required for disclosure; confirm our read that fail-closed RLS without context is acceptable interim defense while call sites are wired (vs. fail-open).
Pilot gate
Staging live verify must pass before DD-214 / coordination-note E2E is treated as green.
5. VA clinical data persistence — disclosed and corrected June 2026¶
Discovered
2026-06-15 (same-day self-correction after VA demo)
What was stated
VA clinical data is never stored on LastVet servers.
What is true
Veteran-directed encrypted snapshots persist in Postgres (health_record_items, veterans) after sync. VA OAuth tokens remain device-only.
Correction sent
Persistence matrix + architecture diagram to VA same day.