Skip to content
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

Closed
lpciferri opened this issue Jul 3, 2019 · 6 comments
Closed

Investigation | How to implement stays #11288

lpciferri opened this issue Jul 3, 2019 · 6 comments
Assignees
Labels
Priority: Low Reported issue, not a blocker. "Last in" priority for new work. Product: caseflow-intake Product: caseflow-queue Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Team: Echo 🐬 Team: Foxtrot 🦊 Type: Investigation

Comments

@lpciferri
Copy link

lpciferri commented Jul 3, 2019

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 of ColocatedTasks that attorneys can assign to VLJ Support Staff. #11278

Pros:

  • This Stayed appeal task could be applied to both AMA and Legacy appeals, so it's a one stop shop
  • This task will also make it easy for folks to find all appeals with a Stay, because they can just look for these tasks
  • Legacy appeals will be in the CASEFLOW VACOLS location and won't be able to be moved/touched by any staff

Cons:

  • If we went this route, I think we should suggest that the Board not allow partially stayed appeals just yet

Questions:

  • What's the LOE to add a new 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). #11292

Legacy 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:

  • This allows decisions to move forward
  • We already have a Stayed closed_status for request issues in the backend, we just haven't surfaced it to the frontend yet - by adding the Stayed option in the dropdown (alongside Remove and Withdraw) on the Add/Remove issues and the Edit issues Caseflow Intake screen

Cons:

  • It could be harder to connect the original appeal with the new appeal (with only stayed issues) because they'd be two different records
  • Probably harder to train?
  • Creates a second docket number (though it would have the same NOD receipt date)

Note: this option could likely work in conjunction with option 1 in the long term

Questions:

  • What's the LOE to allow users to select Stayed as a request issue description?
  • Can we confirm that we can remove and add these Stayed issues, given all the Caseflow Intake validations?

Option 3: Do the development work to allow a 2nd decision on an appeal

Description:

  • Allow users to mark request issues as Stayed
    • (by adding the Stayed option in the dropdown (alongside Remove and Withdraw) on the Add/Remove issues and the Edit issues Caseflow Intake screen)
  • Allow appeals to move forward - attorneys can add decision issues for non-stayed request issues, allow judges to check out decisions to BVA dispatch, allow BVA dispatch to outcode, create EPs, etc.
  • When the stay is lifted, allow attorneys and judges to make a second decision on the same appeal

Pros:

  • The issues stay connected to this same docket number
  • Easier to see the story of the appeal because all tasks are on the same record
  • Uses the pattern we'll have to use for Litigation Support - post-decisional motions - to add a second decision/decision document to an appeal

Cons:

  • The most complicated, and includes the most new engineering work
@leikkisa
Copy link
Contributor

leikkisa commented Jul 3, 2019

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.

@leikkisa
Copy link
Contributor

leikkisa commented Jul 3, 2019

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.

@lpciferri
Copy link
Author

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.

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'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.

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.

@leikkisa
Copy link
Contributor

leikkisa commented Jul 8, 2019

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.

@lpciferri
Copy link
Author

As of Friday, July 19, the Board has asked we go ahead with option 1 and provide an LOE for option 2.

@jimruggiero jimruggiero added Priority: Low Reported issue, not a blocker. "Last in" priority for new work. Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests labels Sep 3, 2019
@araposo-tistatech
Copy link

Team moved forward with Option 1, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Low Reported issue, not a blocker. "Last in" priority for new work. Product: caseflow-intake Product: caseflow-queue Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Team: Echo 🐬 Team: Foxtrot 🦊 Type: Investigation
Projects
None yet
Development

No branches or pull requests

5 participants