-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigation | How to implement stays #11288
Comments
I would lean towards the second option. We use a similar pattern for remand supplemental claims, which will probably also be used for 930s. So if there's a "Stayed" action on an issue, we can generate the "Stayed Appeal" (which is linked to the original appeal) and move the issue to it. That is on the data side, and it's not hard to find them in the data. That said, our UI for navigating remand supplemental claims and connecting then to the original claim right now is non-existent, they're treated more like individual supplemental claims. I don't know if that poses any issues for the work suggested above, but I do think we eventually want to connect them in the UI too. These comments are mostly for AMA appeals, I would have to understand more before commenting on the VACOLS piece. To answer your question, I would think of "stayed" as a closed_status on the first request issue, and the new request issue being added as an open issue to a "stayed" appeal. It will already have gone through the other validations before being added to the first appeal, so I think we would consider it eligible on the stayed appeal and it would get added there automatically, so we could skip eligibility checks that we want to. |
I'm still learning about the task world, but if stayed appeals need a task anyway (does that affect how it gets assigned?), then we might be able to make this a staged approach with a combination of 1 and 2. |
Can you say more about how you might define a "Stayed appeal" and how it's different than just adding a stayed issue to a newly established appeal?
I agree, it likely will end up being a combo of 1 and 2. Depending on the LOE and time it takes to build each of these, we'd give a suggestion for whether we implement 1 before 2. It seems like 1 is lower effort, but I'd love your engineering thoughts on it. |
For your first question, the main difference is that a stayed appeal would be connected to the original appeal, where as a regular original appeal isn't connected to another appeal. For your second question, that's what I was thinking too. So early on they could process appeals that are all stayed, and then we could add the functionality to have partially stayed appeals. |
As of Friday, July 19, the Board has asked we go ahead with option 1 and provide an LOE for option 2. |
Team moved forward with Option 1, closing. |
Context
VA has issued a stay on blue water Navy Veterans. The Board would like our input in how we might easily implement stays.
There is no easy way to identify blue water Navy Veterans right now. That is, there is no single data point we can look to in any VA system. Attorneys would identify that the case needs a stay when they begin reviewing the file. So, these stayed cases would only be identified after distribution to a judge, and that judge assigns cases to attorneys.
The Board allows appeals that have only some stayed issues to proceed to decision - these are referred to as "partially stayed appeals". In a VACOLS world, they would (1) remove the stayed issue from the appeal and (2) create a new VACOLS record with it, so the other VACOLS record (without stayed issues) could proceed. We can consider this when thinking through Caseflow options.
For each option, let's think through feasibility and level of effort.
Do not allow partially stayed appeals
Option 1:
Stayed appeal
admin action/ColocatedTask
Description: We could add the task
Stayed appeal
to the list ofColocatedTasks
that attorneys can assign to VLJ Support Staff. #11278Pros:
Stayed appeal
task could be applied to both AMA and Legacy appeals, so it's a one stop shopCons:
Questions:
ColocatedTask
?Do allow partially stayed appeals
Option 2: Use VACOLS for legacy appeals as usual. Mimic VACOLS process by allowing users to establish new appeals with Stayed issues via Caseflow Intake, which allows the other appeal to continue as usual.
Description:
AMA appeals: When an attorney identifies only some out of all issues on an AMA appeal, they go to
Correct issues
and remove that stayed issue(s) from the appeal. Another appeal gets established through Caseflow intake with just the stayed issue(s). #11292Legacy appeals: When an attorney identifies only some out of all issues on a legacy appeal, report it to whoever they need to to remove the stayed issue from their appeal and create a new VACOLS record for it. Someone moves that appeal into a given location (perhaps the "Stayed" location) in VACOLS
Pros:
Stayed
closed_status
for request issues in the backend, we just haven't surfaced it to the frontend yet - by adding theStayed
option in the dropdown (alongsideRemove
andWithdraw
) on the Add/Remove issues and the Edit issues Caseflow Intake screenCons:
Note: this option could likely work in conjunction with option 1 in the long term
Questions:
Stayed
as a request issue description?Option 3: Do the development work to allow a 2nd decision on an appeal
Description:
Stayed
option in the dropdown (alongsideRemove
andWithdraw
) on the Add/Remove issues and the Edit issues Caseflow Intake screen)Pros:
Cons:
The text was updated successfully, but these errors were encountered: