Skip to content

LASTVET — PHASE 1 FOCUS + STRICT API ROADMAP

Created: June 30, 2026 Status: Supersedes the prior Layer 1 reframe. Disciplines it down to a single wedge and a gated roadmap. Scope: Phase 1 only. Revenue Layers 2–6 in the parallel-ecosystem strategy are unchanged and remain future, gated behind the milestones below.


THE DISCIPLINE (READ FIRST)

The risk is becoming the "everything" app: verification + records + benefits + housing + employment + insurance + pharmacy, all reachable, none deep. Optionality feels like progress and is actually the failure mode.

The rule that prevents it: the two APIs currently pending VA approval are the entire Phase 1 surface. Nothing ships in Phase 1 that isn't powered by one of them.

  • Patient Health API (FHIR) — the sovereign health record.
  • Veteran Service History & Eligibility API — verified veteran + service history + eligibility.

Every other VA API is parked and gated (see roadmap). We do not request a third API, add a second org type, or open a second domain until a specific proof milestone is met. Gates are earned, not scheduled.


THE PHASE 1 PRODUCT (ONE SENTENCE)

A verified, sovereign veteran health-and-service profile — owned by the veteran, verifiable by a trusted org, shareable with consent.

That is the whole product. If a feature needs an API we don't have, it is not Phase 1.


THE SINGLE WEDGE: MENTAL HEALTH CARE COORDINATION

The test every wedge must pass

Its full value must be deliverable by the two pending APIs alone, with zero new API dependency.

Why mental health passes and the others don't

Candidate Verdict
Mental health coordination PASS. Uses both APIs maximally: verified veteran (Service History & Eligibility) + complete record before the first session (FHIR). The VA's worst-shortage area. Straight line into Layer 2 (Care Network) and Layer 5 (mental-health CCN carve-out).
Benefits navigation FAIL. Killer feature (document submission) needs Benefits Intake API + VA accreditation. Doesn't use FHIR.
Housing / employment OFF-CORE. Verification helps, but neither touches the health record — the actual moat.

The cost of this choice (name it honestly)

42 CFR Part 2. Leading with mental health brings substance-use-record rules on stage in Phase 1. This is already in Hogan Lovells' scope and is unavoidable given the Layer 5 endgame — better confronted in a controlled ~200-veteran pilot than at scale.

What Phase 1 is deliberately NOT doing (and why that's the point)

  • No community-care routing (needs Community Care Eligibility API — parked).
  • No benefits submission (needs Benefits Intake API + accreditation — parked).
  • No housing or employment org network (second/third domain — parked).
  • No insurance, pharmacy, CCN, or data-revenue activity (Layers 3–6 — future).

Saying no to these now is the strategy, not a limitation of it.


PRODUCT BOUNDARY: THE COORDINATION NOTE (COORDINATION LAYER, NOT A BH EHR)

Naming: what was called "clinic notes" is renamed the Coordination Note. "Clinic notes" implies clinical documentation and invites the exact EHR-creep we are avoiding. The name states the boundary.

The trap: letting LastVet hold clinical documentation is how the app slowly becomes a second EHR the provider has to double-enter into — recreating the two-platform problem that kills provider adoption and quietly turning LastVet into the behavioral-health tool it is not meant to be.

What a Coordination Note IS: a veteran-owned, cross-provider summary written to be seen by the next provider and by the veteran.

What it is NOT: a billable progress note, treatment plan, or assessment. Those stay in the provider's EHR (SimplePractice, TheraNest, Valant, Epic, etc.). LastVet does not attempt to replace them.

How it is MADE (the anti-double-entry mechanism): wherever the provider runs on an API-enabled EHR, the Coordination Note is auto-derived from what the provider already documents — LastVet pulls the coordination-relevant, veteran-visible subset via the EHR's FHIR API. The provider writes once, in their own system; their only action in LastVet is authorizing what flows. Manual entry is the fallback, never the default. (This is why Phase-1 org targeting is interoperable-first — see Org Side.)

The test for whether a note belongs in LastVet: Is it written to be shared across providers and visible to the veteran, as coordination? → LastVet. Is it the clinician's internal documentation? → their EHR.

Why this boundary also serves the mission: Behavioral health is opaque to the veteran because the progress note is provider-owned and hidden. The Coordination Note is veteran-visible by design — which demystifies BH and puts the veteran at the center. The constraint that stops LastVet from becoming an EHR is the same one that delivers the veteran-centering value. Focus and mission are not in tension here; the boundary produces both.


VETERAN SIDE (UNCHANGED)

Acquisition stays health-and-records-led. Trust is the focus. No reward-baiting, no leading with the marketplace.

  • Lead with the sovereign health record. Highest-trust, highest-stakes capability; the Deloitte/VA story.
  • Honest pipeline. Tell veterans plainly what's coming and why: "Today, your record — owned by you. Next, it becomes the key that unlocks verified access to care and services on your terms." Trust invested, not extracted.
  • The Operating System (de-tokenized — no cash-out, no data dividend, no paid-to-be-treated; those fail the Bible test and touch Anti-Kickback / HIPAA sale-of-PHI):
  • Radio Check — recurring check-in; a reason to open the app between clinical events; surfaces "need support" signals.
  • Missions — guided multi-step journeys; each step is an action or referral that creates org-side value.
  • Status / Progress — profile completeness + verification; a fuller profile = a warmer, more qualified referral.

Engagement is non-monetary for the veteran. Money enters only on the org side.


ORG SIDE (PHASE 1): ONE ORG TYPE, ONE REGION

  • Org type: veteran-serving mental health orgs (group practices, veteran MH nonprofits, peer-support orgs, Vet Center–adjacent, university-affiliated programs). Not solo clinicians.
  • Region: San Diego. Dense veteran population, your backyard, convenable in person.
  • The sell (all deliverable by the two APIs): verified veterans + the complete record before first contact + veteran-episode care-outcome reporting (via RealOutcomes — see below). None of it depends on a veteran's clinical calendar.
  • Channel: veteransco.org convenes the local mental-health org cohort. The coalition is the supply-side acquisition engine — not veteran→provider referral, which is too slow and too veteran-gated.

Build the local org network dense before or alongside the first veteran cohort, so a veteran who surfaces a mental-health need has a real, responsive org on the other end. Density in one niche beats breadth with nothing behind it.

Targeting filter: interoperable-first is an integration signal, not an entry gate

Entry is open — the pricing gate handles small orgs. An org with fewer than ~10 veterans lands on Free regardless of its EHR; it still counts toward org density, and for Layer 1, org count (traction) is worth more than revenue. So interoperability does not decide who gets in; it decides where we spend integration effort. Two separate axes:

  • Acquisition priority (get them in — traction): driven mostly by warmth. A warm org is an early "yes" even at low volume. Free tier, minimal friction, counts toward density.
  • Integration priority (spend API effort — frictionless coordination): driven by veteran volume × reachability. Only orgs with enough volume to justify it get the aggregator-based, auto-derived Coordination Note. Everyone else runs referral-only or manual notes — the model degrades gracefully.

Do not build N direct EHR integrations. Reach the volume orgs through an aggregator — Health Gorilla (TEFCA QHIN), Redox, or AWS HealthLake — integrate once, reach many. Primary BH-EHR targets where volume justifies integration: Qualifacts (CareLogic/Credible), Valant, TherapyNotes, ICANotes, SimplePractice, Kipu, Netsmart, BestNotes — most expose FHIR/HL7 and already capture PHQ-9 / GAD-7 / C-SSRS natively.

Tailwind: US FHIR-API adoption is now the norm (84% of hospitals, up from 56% in 2022); TEFCA/CMS rules are mandating the rails LastVet needs. The coordination layer is being standardized into existence.

Measurement: RealOutcomes needs a Phase-1 care-outcomes mode

RealOutcomes as built evaluates nonprofit program impact for funders. The Gate-2 orgs are mostly for-profit BH providers who donate a capped number of sessions per veteran per year, then bill directly — they have no grant funder for the current tool to report to. Phase 1 therefore requires a change of unit: measure care outcomes at the veteran-episode level, provider-agnostic (works identically for for-profit and nonprofit). This is more aligned with LastVet's core — outcomes are provable precisely because LastVet sees across providers, which no single EHR can.

For the donated-then-billed model, this gives the for-profit org three things it actually wants, none requiring nonprofit status: (1) a way to track and prove its donated-care commitment; (2) outcome data on those sessions (for reputation, referral relationships, and value-based positioning); (3) transparent continuity when donated care runs out.

Mission tripwire: the transition-when-donated-care-ends must be built for the veteran — the veteran sees their remaining session balance and their real options. It is never a funnel that routes veterans into billing. Keep the veteran able to see the meter, and the feature stays honest.


THE STRICT ROADMAP (GATED, NOT SCHEDULED)

Each gate unlocks exactly one new thing. Numbers are illustrative — set the real thresholds, but do not move a gate to unlock more than one item.

Gate 0 — build now (no approval dependency). Two open-data APIs, each with a specific Phase-1 job — not generic "access": - Facilities → "find veteran mental-health care near you," including VA MH clinics and Vet Centers. Real routing value as-is. - Formsnot a form repository (a pile of PDFs veterans can't act on is dead weight). The Forms API only supplies the current valid form version; the actionability is LastVet's. Phase 1 uses exactly one form — the release-of-information / authorization-to-share (and its Part 2-compliant consent), the form the entire coordination layer runs on. LastVet pre-fills it from data already held, the veteran reviews and authorizes it in-app, and LastVet delivers it to the chosen provider. A form becomes the consent mechanism behind every referral. - Boundary: delivering a signed ROI to a provider is Phase-1 in-app sharing. Submitting forms to the VA needs Benefits Intake — parked. Do not conflate them.

Gate 1 — prove the veteran side. Unlocks nothing new; validates the record. Target: ~200 San Diego veterans with a synced sovereign FHIR record and a verified service/eligibility profile, actively using the OS.

Gate 2 — prove the loop. Unlocks the first expansion decision. Target: ~10 San Diego mental-health orgs in-network and ~50 consented veteran→org referrals that closed with a logged outcome. The loop is "closed" when four events are recorded — referral made → referral accepted → care delivered → outcome logged — plus one outcome signal (e.g. a PHQ-9/GAD-7 delta, which the target BH EHRs already capture). Do not build an analytics suite to pass Gate 2; measure the four events and one delta. → Only on passing Gate 2: request API #3 (Community Care Eligibility) to strengthen routing. Nothing else.

Gate 3 — prove revenue. Unlocks the second domain. Target: N paying orgs at the Org tier with retention proven over 2+ months. → Only on passing Gate 3: open domain #2 (housing or benefits) and request the API cluster that domain needs (e.g. Benefits Claims/Intake for benefits — with the accreditation question already answered by counsel).

No API request, no new org type, no new domain jumps a gate. That is the whole roadmap.


COMPLIANCE (PHASE 1 ONLY)

  • 42 CFR Part 2 — mental-health/substance-use record handling. In Hogan Lovells' scope; resolve before the pilot goes live.
  • Two-data-plane discipline — same as the Deloitte diagram: VA-sourced data flows through with consent; only veteran-directed copies and LastVet-native data persist. Verification must not become a new persistence liability.
  • No financial inducement — no paying veterans to share data or receive care. Verification and referral are sovereignty features, never paid actions.

WHAT'S PARKED (AND ITS GATE)

Capability API needed Gated behind Why parked
Community-care routing Community Care Eligibility Gate 2 Strengthens routing; not needed to prove the loop
Benefits status/submission Benefits Claims / Intake Gate 3 New domain; Intake also needs org accreditation
Housing hook Loan Guaranty Gate 3 Second/third domain
Appeals Appeals Status / Decision Reviews Post-Gate 3 Low-frequency, high-complexity
Layers 2–6 (care, insurance, pharmacy, CCN, data) Their own phase Entire future business; not Phase 1

NEXT ACTIONS (PHASE 1 ONLY)

  1. Lock the wedge: confirm mental health (or consciously choose the housing fallback, accepting it sidelines FHIR). — locked.
  2. Build Gate 0 now: Facilities routing + the pre-filled ROI/consent delivery flow (not a form repository).
  3. On approval of the two pending APIs, integrate them into the current build — verified profile + sovereign record — and nothing else.
  4. Build the interoperable-first target list: San Diego veteran-serving MH orgs on API-reachable EHRs (Qualifacts, Valant, TherapyNotes, SimplePractice, Kipu, etc.); plan to reach them via an aggregator (Health Gorilla / Redox), not one-off builds.
  5. Spec the Coordination Note as auto-derived from EHR data via API (provider writes once; manual entry is fallback only).
  6. Add a Phase-1 care-outcomes mode to RealOutcomes (veteran-episode, provider-agnostic) so it can measure for-profit orgs; build the donated-care meter as veteran-visible.
  7. Wire the Operating System (Radio Check, Missions, Status) as the veteran-side frequency engine, de-tokenized.
  8. Resolve 42 CFR Part 2 with Hogan Lovells before the pilot goes live.
  9. Set the real Gate 1–3 thresholds. Do not request API #3 until Gate 2 is passed.

Companion to the Bible, the Project Outline, and LASTVET_REVENUE_STRATEGY___THE_PARALLEL_ECOSYSTEM.md. Reviewed when Gate 2 is passed.