Legal Changelog

Previous version: v1.2, effective August 7, 2026

Corrects our production-infrastructure disclosure. The prior version named a third-party public-cloud host as the production database. Production health records now run on dedicated, single-tenant infrastructure we control.

Read the full current terms of service

• MaterialData processor (Section 13.3)

  Section 13.3 no longer names Amazon Web Services (AWS) as the production database host. The prior version did, and that was accurate when published. Production health records now run on dedicated, single-tenant infrastructure that we control. Where a vendor processes health data on our behalf, that relationship is covered by a Business Associate Agreement. Cloudflare remains named for public-site hosting only and does not process health records. We are disclosing this rather than quietly updating it.

  A note on timing

  Our terms commit to 30 days notice before a material change takes effect. That commitment is about changes we are going to make. The infrastructure change described above already happened, so there was no way to give advance notice of it. We are disclosing it immediately rather than waiting, and we are labeling it material because it concerns who processes your data and where health records are held. Going forward, any material change we intend to make will be announced here, and by email, before it takes effect.

Previous version: v1.2, effective August 7, 2026

Corrects our production-infrastructure disclosure. The prior version named a third-party public-cloud host as the production database. Production health records now run on dedicated, single-tenant infrastructure we control. Also corrects the security disclosure so it does not overstate database access controls.

Read the full current privacy policy

• MaterialData processor / PHI location (Sections 5.1 and 5.2)

  Sections 5.1 and 5.2 no longer name Amazon Web Services (AWS) as the production database host under a Business Associate Agreement. The prior version did, and that was accurate when published. Production health records now run on dedicated, single-tenant infrastructure that we control. Where a vendor processes health data on our behalf, that relationship is covered by a Business Associate Agreement. Cloudflare remains named for public-site hosting only and does not process health records. We are disclosing this rather than quietly updating it.

  A note on timing

  Our policy commits to 30 days notice before a material change takes effect. That commitment is about changes we are going to make. The infrastructure change described above already happened, so there was no way to give advance notice of it. We are disclosing it immediately rather than waiting, and we are labeling it material because it concerns who processes your data and where health records are held. Going forward, any material change we intend to make will be announced here, and by email, before it takes effect.

• Correction / ClarificationSecurity disclosure (Section 7)

  Section 7 no longer claims that the application cannot bypass database access controls. Access is enforced through multiple layers, including database-level controls on sensitive record data. Those controls are real and in use. They are not claimed as complete for every class of stored data.

Previous version: v1.1, effective July 11, 2026

Clarifying, protection-neutral updates for VA production onboarding. Privacy Policy: explicit 30-day user-requested deletion timeline (100% of data incl. non-VA), explicit dormant-account deletion timeline, affirmative statement that we do not collect geolocation, financial, or contacts data. Terms of Service: matched deletion language, corrected CARIN/MyHealthApplication listing status to reflect activation upon VA production onboarding. No reduction of any user protection; notice provided under 30 days as these are non-substantial clarifications that do not reduce protections.

Read the full current terms of service

• Correction / ClarificationAccount deletion timeline (Section 3.3)

  Section 3.3 now states that when you delete your account, we permanently remove 100% of your associated personal data within 30 days, including VA-sourced copies, self-reported entries, uploaded documents, profile information, and other non-VA data you added to LastVet.

• Correction / ClarificationCARIN listing status (Section 13.1)

  Section 13.1 clarifies that our MyHealthApplication.com listing will be activated upon completion of VA Lighthouse production onboarding, and that our attestation letter is available upon request at [email protected] until then.

Previous version: v1.1, effective July 11, 2026

Clarifying, protection-neutral updates for VA production onboarding. Privacy Policy: explicit 30-day user-requested deletion timeline (100% of data incl. non-VA), explicit dormant-account deletion timeline, affirmative statement that we do not collect geolocation, financial, or contacts data, plus §3.6 clarification that VA Facilities lookup uses a fixed regional search center (San Diego), not device location, with no storage on LastVet servers. Terms of Service: matched deletion language, corrected CARIN/MyHealthApplication listing status to reflect activation upon VA production onboarding. No reduction of any user protection; notice provided under 30 days as these are non-substantial clarifications that do not reduce protections.

Read the full current privacy policy

• Correction / ClarificationUser-requested deletion timeline (Section 8)

  Section 8 now states that when you request account deletion, we permanently remove 100% of your associated personal data within 30 days, including VA-sourced copies, self-reported entries, uploaded documents, profile information, and other non-VA data you added to LastVet.

• Correction / ClarificationDormant account deletion timeline (Section 8.1)

  Section 8.1 now states explicitly that after 24 months of inactivity, a notification email, and a 60-day login window, we permanently delete your account and associated personal data within 30 days after that window closes.

• Correction / ClarificationData we do not collect (Section 3.6)

  New Section 3.6 states that LastVet does not collect geolocation data, financial account or payment card data, or contacts from your device address book.

• Correction / ClarificationVA Facilities query handling (Section 3.6)

  Section 3.6 now clarifies that finding nearby VA mental-health facilities queries the VA Facilities API using a fixed regional search center (currently San Diego), not the device location, and that LastVet does not store that search or any location on its servers.

Previous version: v1.0, effective April 3, 2026

Corrects our infrastructure processor disclosure after the AWS migration, clarifies Cloudflare's role on public sites only, and aligns provider-contributed language with coordination notes.

Read the full current terms of service

• MaterialData processor (Section 13.3)

  Section 13.3 updated to name AWS as our production database host under an executed BAA, and to clarify Cloudflare provides web hosting and CDN for public sites only and does not process health records. The prior version named different processors and was accurate when published.

  A note on timing

  Our terms commit to 30 days notice before a material change takes effect. That commitment is about changes we are going to make. The infrastructure migration described above already happened, so there was no way to give advance notice of it. We are disclosing it immediately rather than waiting, and we are labeling it material because it concerns who processes your data. Going forward, any material change we intend to make will be announced here, and by email, before it takes effect.

• Correction / ClarificationCoordination notes (Section 4.2)

  Section 4.2 changed "provider-contributed notes" / clinical notes language to coordination notes, and added that providers' clinical charting remains in their own EHR.

Previous version: v1.0, effective April 3, 2026

Corrects our infrastructure processor disclosure after the AWS migration, clarifies Cloudflare's role, aligns provider-contributed data language with coordination notes, and strengthens our security disclosure.

Read the full current privacy policy

• MaterialData processor (infrastructure migration)

  We migrated our production infrastructure from Railway to Amazon Web Services (AWS), under an executed Business Associate Agreement. Our previous policy named Railway as our hosting and database provider. That was accurate when published and became inaccurate when we migrated. AWS is now the processor. We are disclosing this rather than quietly updating it.

• MaterialVendor scope (Cloudflare)

  Clarified that Cloudflare provides web hosting and content delivery for our public websites only. Cloudflare does not process or access health records, and health data traffic does not pass through Cloudflare.

  A note on timing

  Our policy commits to 30 days notice before a material change takes effect. That commitment is about changes we are going to make. The infrastructure migration described above already happened, so there was no way to give advance notice of it. We are disclosing it immediately rather than waiting, and we are labeling it material because it concerns who processes your data. Going forward, any material change we intend to make will be announced here, and by email, before it takes effect.

• Correction / ClarificationProvider-contributed data terminology

  Changed "clinical notes" to "coordination notes" for provider-contributed data, to match how the platform actually works. A provider's clinical charting stays in their own EHR. LastVet does not hold it.

• Correction / ClarificationVA-sourced data list

  Removed clinical notes from the VA Lighthouse data list. LastVet pulls structured FHIR resources (conditions, medications, allergies, procedures, immunizations, and lab results). We do not currently pull VA progress or clinical note documents.

• StrengtheningSecurity disclosure

  Updated our security disclosure to reflect what is now in place: encryption at rest and in transit, and row-level security enforced at the database connection level, so the application itself cannot bypass the access controls protecting your record.