Secondary Condition Finder

A claim-preparation research aid for VA disability claims. It keeps secondary and presumptive service-connection research separate because they use different legal and evidentiary frameworks.

• Secondary (38 CFR § 3.310, M21-1 Spicer update May 2026): starts from established service-connected conditions and organizes diagnosed conditions that may warrant further research, along with authored pathways, evidence gaps, and source references. After the Spicer v. McDonough ruling, the M21-1 uses "but for" causation language and recognizes treatment-interference as a secondary aggravation pathway. Competent nexus evidence may be needed when the relationship requires medical expertise; the app does not create or replace a medical opinion.
• Presumptive (38 CFR §§ 3.307 and 3.309): compares authored qualifying service locations/date windows with the service history supplied in the workflow and lists presumptions that may apply. A presumption can remove the need to prove that qualifying service caused the recognized condition, but the app does not determine eligibility.

The current presumptive data covers the authored PACT Act burn-pit and Agent Orange categories described in docs/presumptive-track.md. Data-governance rules for condition IDs, schema strictness, and citation quality are in docs/data-governance-note.md.

This is not medical or legal advice. It does not diagnose conditions, determine eligibility, or estimate ratings. Every suggestion is a possibility to research with a qualified provider or an accredited representative.

Current status

Deployment

The application is deployed on Vercel. The canonical production URL is https://secondary-condition-finder.vercel.app.

Knowledge-base snapshot — generated, not documented

The knowledge base changes with every authoring commit, so this README does not hardcode snapshot counts (mappings, relationships, published/draft split, verified references). Each was a recurring source of documentation-only commits and merge conflicts. Generate the current numbers instead (the table below is generated from the snapshotGenerators metadata in package.json by npm run readme:snapshot — edit the metadata, not the table):

Snapshot metric	Generator
Catalog + mapping integrity, file/condition counts	npm run kb:validate
Citation verification state and the verification-debt ratchet	npm run citations:audit
Published/draft authoring coverage by wave and batch	npm run authoring:tracker
References below the provenance bar	npm run citations:weak
CRG relationship-graph structure (cycles, bidirectional pairs, redundancy)	npm run audit:crg
CRG transitive-redundancy triage register and posture tables	npm run crg:triage
Qualified-human citation-verification queue	npm run citations:queue

Browser-local evidence processing

Supported PDF, DOCX, and text files are read entirely in the browser tab — raw bytes and extracted text are never submitted to the application server.

• Step 6 groups excerpts under each authored claim pathway in a Pathway Evidence Mapping table (research cues only — no interpretation, no egress), alongside per-gap coverage chips and the evidence checklist.
• Step 4 offers two analysis depths — Standard (the default) and an opt-in Extended envelope for large local sets such as full C-files — with file, batch, page, character, and retention limits derived from one limits module and published verbatim on /privacy.
• Each document carries its own author credential (physician, psychologist, NP/PA, non-clinician, or unknown), so VA decision letters are not counted as clinician-authored medical opinions.
• The classifier understands clinical shorthand (dx, 2/2 = secondary to), normalizes hyphen/spelling variants, treats Diagnosis:/Assessment: sections as diagnosis context, and excludes regulatory boilerplate from nexus counts.
• Scanned or image-only PDFs are recognized with Local OCR that runs entirely in the tab against same-origin tesseract.js assets.
• Every boundary is enforced before or during extraction, including DOCX archive-expansion preflight bounds.

Guided VA.gov records walkthrough

Step 4 includes a guided VA.gov medical-records download walkthrough for veterans who want their complete VA health record. Downloading it is a multi-page journey — VA.gov signs you in through ID.me (email, password, and a multi-factor code), then the download tool asks for a date range, record type, and file type before producing the PDF.

• The walkthrough mirrors that flow as a 14-step checklist with deep links that open VA.gov in a new tab.
• It never collects, transmits, or stores VA.gov or ID.me credentials, MFA codes, or session data — sign-in happens entirely on VA.gov.
• Progress checkmarks live only in the current browser tab.
• It appears on the secondary workflow's document step and standalone at /get-records.

The screenshot is regenerable with node scripts/capture-va-gov-walkthrough-screens.mjs (starts a dev server and headless Chrome, seeds the browser-local workflow record in sessionStorage, and captures the card via the DevTools Protocol).

Step 5–6 research aids

Steps 5 and 6 surface research aids built from the same authored data:

以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗