A deliberately narrow data boundary

VAVC exists to move one fact — did the veteran attend — and the money that fact triggers. It is not a clinical system and does not need clinical data to work. This page states exactly what crosses the boundary, what never does, and how access is controlled. These are the platform's design commitments; specific contract, hosting, and authorization terms are settled with the contracting office.

What crosses the boundary

Veteran identifier (file number) and name
Facility identifier and clinic or service name
Appointment identifier and scheduled date and time
One non-clinical attendance flag: attended, no-show, or emergency walk-in
Time the attendance was recorded, the recording station, and the acting staff account
Computed travel amounts: round-trip miles, mileage rate, deductible, meals, lodging, tickets

What never does

Diagnoses, problem lists, or ICD/CPT codes
Clinical notes, results, imaging, or medications
Reason for visit or provider commentary
Full bank account numbers — only the last four digits are displayed for confirmation
Social Security numbers

Access and accountability controls

Role-scoped access

Every account holds an explicit role — front desk, Travel Pay, veteran, or administrator — stored separately from the user profile so it cannot be self-assigned. Access rules are enforced in the database on every read and write, not in the interface.

Front desk sees only its own facility

A clerk account can see and record attendance only for appointments at the facility assigned to that account. It cannot browse other facilities or other veterans.

Veterans get read-only access

A veteran sees their own attendance and claim history and nothing else. Corrections are made by the travel office by phone, so no one can alter the record that supports a payment.

Append-only audit log

Attendance events, claim status changes, rate changes, and subscriber-office changes are written to a log that records who acted, what changed, and when. Entries are added, never edited.

Signed inbound events

When a medical IT system reports attendance directly, the request is verified before it is accepted, validated against a published schema, and rejected if the payload does not match the event contract.

Least-privilege service access

Privileged operations run only in server-side code after the acting account's role is verified. Browser code never holds an administrative credential.

Program posture

Data ownership	The VA owns all attendance, claim, and audit data produced through the platform.
Exit path	Full export on request in an open format, plus the published event contract, so the feed can be re-pointed to another system without vendor cooperation.
Authorization review	Production use is expected to follow a security authorization (ATO) review and a privacy threshold analysis. The narrow data boundary described above is what keeps that review short.
Hosting	Available as a hosted service or deployed single-tenant inside a VA-controlled environment under the enterprise license.
Vulnerability reporting	Report a suspected vulnerability through the contact form and mark the interest as Other. Reports are acknowledged before any public disclosure.

How attendance is certified

A claim is supported by two independent marks: the staff account that recorded the check-in at the facility, and the veteran's own signed-in acknowledgement of that visit on their record. Both are timestamped and written to the audit log, so a payment is never traceable to a single unverified click. Emergency walk-ins follow the same path and are flagged as unscheduled.

Read the integration spec Ask a security question