-
Notifications
You must be signed in to change notification settings - Fork 19
Why Caseflow Intake?
VACOLS is the system of record for the legacy appeals process. Architecturally, the VACOLS database exists on an island. It does not integrate to the VBA corporate database, and any data points shared between the two databases are synchronized manually, often incorrectly (see #2).
The parallel, issue-oriented nature of AMA decision reviews is far more complex than the serial legacy appeals process. There are also a number of complex metrics that are congressionally mandated to be reported on.
Any software tooling used to improve the processes of AMA or automate collection of many of these metrics is going to require a much more complex and integrated data model than VACOLS provides. Namely, one that can track individual issues as they are contested, decided, and potentially re-contested through different types of decision reviews.
The data structure for Caseflow Intake does just this. It distinguishes between issues as they are requested by the veteran (request issues), and issues as they are decided by attorneys or case workers (decision issues). It accounts for a myriad of different possibilities, such as when one decision satisfies many request issues, or vice versa, when one request issue is decided by many decision issues. It creates data that can trace a claim through its initial decision, through any requests to contest that decision or subsequent decisions, all the way to the final decision(s).
Structuring the data in this way helps present data to veterans online in the same way they already view decision reviews, as an extension to their original claim. This was not possible with VACOLS.
2. To use automation to prevent as many errors as possible, and ensure trustworthy data throughout the entire AMA process.
Uncaught errors can cause major issues with how veterans' appeals are processed. They can cause veterans to not be notified of mistakes made on their form for weeks, months or years. They can cause decision reviews to wait in the wrong queue unnecessarily, or worse, never be processed at all.
Additionally, when building early Caseflow features, it quickly became apparent that our options for improving the appeals workflow were extremely limited without trustworthy data. Improving the correctness of data will open up options for process improvements in the future that were previously unviable.
We found that the best place to catch errors was at the very beginning of the process, the point at which claims assistants intake veteran form data. We use canonical VBA corporate data when possible to ensure consistency of data between the AMA and the rest of the VBA processes. We also perform a number of other automated form specific validations during this process.
3. To provide a logic core to enable veterans to submit decision review requests online and receive real time feedback.
Decision review requests can be difficult for veterans to fill out, and it's easy to make mistakes. It can be especially frustrating to only be notified of those mistakes after an entire round trip of paper mail and manual processing.
An online form could provide digital assistance for veterans attempting to submit a decision review. For example, it could show all reviewable VA decisions, so veterans would simply select from a list, instead of having to write each disagreement down, which opens the door for misinterpretations. It could also immediately tell the veteran if the decision is ineligible for review in the selected lane, and why. Additionally, if the data appears to be incorrect, it could empower the veteran to notify the VA in a much more informed way, noting exactly how the VA's data differs from what they expected.
The current core of logic used to process intake of paper forms could be easily adapted into an API, used to power such an online form.
AMA decision reviews can be requested of almost every business line at the VA. Also, an appeal to the Board can contain issues contesting decisions from multiple different business lines. Coordinating the tasks and data of these issues that span different organizational boundaries of the VA can be challenging, and requires a central software system.
- Home
- Acronyms and Glossary
- Caseflow products
- Caseflow Intake
- Caseflow Queue
- Appeals Consumer
- Caseflow Reader
- Caseflow eFolder
- Caseflow Hearings
- Caseflow Certification
- Caseflow APIs
- Appeal Status API
- Caseflow Dispatch
-
CSUM Roles
- System Admin
- VHA Team Management
- Active Record Queries Resource
- External Integrations
- Caseflow Demo
- Caseflow ProdTest
- Background
- Stuck Jobs
- VA Notify
-
Caseflow-Team
- Tier 4
- Bat Team
- Technical Documentation
- Backend Code Patterns
- Backend Working Group
- FACOLS, VACOLS DB Schema
- Asyncable Models
- External Data: where and why
- Data Fetching Scripts
- Caseflow Data Model and Dictionary
- User Access Permissions
- Controller Schemas
- Constants
- Frontend Best Practices
- Accessibility
- How-To
- Debugging Tips
- Adding a Feature Flag with FeatureToggle
- Editing AMA issues
- Editing a decision review
- Fixing task trees
- Investigating and diagnosing issues
- Data and Metric Request Workflow
- Exporting and Importing Appeals
- Explain page for Appeals
- Record associations and Foreign Keys
- Upgrading Ruby
- Stuck Appeals
- Testing Action Mailer Messages Locally
- Re-running Seed Files
- Rake Generator for Legacy Appeals
- Manually running Scheduled Jobs
- System Admin UI
- Caseflow Makefile
- Upgrading Postgresql from v11.7 to v14.8 Locally
- VACOLS VM Trigger Fix M1
- Using SlackService to Send a Job Alert
- Technical Talks