-
Notifications
You must be signed in to change notification settings - Fork 17
Processing decisions
There are a variety of actions that need to happen when a decision is made. Caseflow Intake is not just responsible for the creation of the initial data, but performs many cleanup tasks related to a decision review.
End products created by Caseflow are continuously polled for changes. When an EP becomes canceled, it indicates that Caseflow should automatically close the issues associated to that EP.
When an EP becomes cleared, it indicates that a decision has been made on the issues associated to that EP. Synchronizing the decisions made on a decision review EP is a complex operation managed by a job triggered by the clearing of the decision. Caseflow first finds the rating connected to the EP that was cleared. If it can't be found, the job will fail and retry again in hopes the rating will appear several hours later. Once the rating is found, Caseflow then requests the dispositions for each contention on the EP from VBMS.
Decision issues are created in the Caseflow DB for each request issue on the EP by combining data from the connected rating issue and the contention disposition. Each issue associated to the cleared EP should have a disposition recorded for it's VBMS contention. However, not each issue necessarily has a rating issue associated to it. These decision issues will be contestable in future decision reviews.
NOTE: Rating data for the decision made on a cleared EP appears to take at least 24 hours to begin returning from the BGS service. So it will take at least that long for the decision synchronization, and any follow up effects such as the automatic creation of supplemental claims take effect.
When a decision is made either in VBMS or Caseflow, if the dispositions of any issues are Duty to Assist errors (DTA errors), then Caseflow automatically generates the follow up supplemental claim that will be used to resolve these DTA errors. Once created, the supplemental claim will be processed in the same way as if it was created via an intake.
The Board only makes decisions, it does not actually execute them. So when a decision for an appeal is outcoded, the appropriate business line must be notified of any granted issues, so the business line can take the appropriate actions for that grant to take effect. This is called an effectuation. If the business line uses VBMS, the effectuation is managed via an EP, which is automatically generated by Caseflow. If the EP resulted in a rating change, the resulting rating issues are connected to back to the granted decision issues that prompted them. If the business line does not use VBMS, the effectuation is managed using a Caseflow task.
When the Board issues a grant related to the business line, the business line must be notified of this grant and make any changes for the decision to take effect. When those changes have been made, the business line can confirm that those changes have been made using Caseflow.
- Home
- Acronyms and Glossary
- Caseflow products
- Caseflow Intake
- Caseflow Queue
- 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
- 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
- Technical Talks