Caseflow: Allow certain users to manually distribute a case to a judge.

[pshahVA]

Background

There are special AOD cases, ie. Terminally Ill Veterans need to bypass the case distribution algorithm in Caseflow and need to be distributed to a judge directly.

Goals

Investigate a way of manually assigning a veteran to a judge. Possibly allowing a Veteran to be manually pulled out of line while being mindful of legal and and policy implications.

Idea

• Create organization where all cases that are ready for distribution live. could be called "Case Storage" even.
• Give only certain people access to that organization
• Allow manual distribution/assignment to judges from that link only
• Manual distribution includes:
  
  
  
  • user selects a case within the list and navigates to Case Details
  
  
  • DistributionTask shows in Currently Active Tasks component
  
  
  • user has the Action available in the dropdown to "send to judge"
  
  
  • user can select a judge from a list (like how we assign cases to attorneys today)
  
  
  • "send to judge" creates a JudgeAssignTask and assigns it to the correct judge
  
  

Steps that were taken manually by the engineering team for a one time fix:

# Let's take a look at the state of the appeal.
rails c> appeal = Appeal.find_by(uuid: "7fd1cf4b-fb83-40c7-9ce3-922312fc30f8")
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
# [[173228, nil, "RootTask", "on_hold"],
   [173229, 173228, "TrackVeteranTask", "in_progress"],
   [173230, 173228, "DistributionTask", "assigned"],
   [173232, 173231, "ScheduleHearingTask", "cancelled"],
   [173231, 173230, "HearingTask", "completed"],
   [213352, 173231, "EvidenceSubmissionWindowTask", "completed"]]
# Looks like the case is in the correct state (schedule hearing task cancelled because
# hearing was withdrawn, distribution task ready for distribution).

# Let's grab the judge we will assign this to.
rails c> judge = User.find_by(full_name: "XXXX, XXXXX")

# Let's assign the case to the judge.
rails c> judge_task = JudgeAssignTask.create!(appeal: appeal, parent: appeal.root_task, appeal_type: Appeal.name, assigned_at: Time.zone.now, assigned_to: judge, action: COPY::JUDGE_ASSIGN_TASK_LABEL)
rails c> appeal.tasks.where(type: DistributionTask.name).update(status: :completed)

# Let's confirm the appeal is in the correct state now:
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
# [[173228, nil, "RootTask", "on_hold"],
   [173229, 173228, "TrackVeteranTask", "in_progress"],
   [173230, 173228, "DistributionTask", "completed"],
   [173232, 173231, "ScheduleHearingTask", "cancelled"],
   [173231, 173230, "HearingTask", "completed"],
   [213352, 173231, "EvidenceSubmissionWindowTask", "completed"],
   [214702, 173228, "JudgeAssignTask", "assigned"]]
# Looks good. Ready for a decision!

Questions:

1. Who will be allowed to this?
2. Do we have to add any special checks and balances for this?

[nicholasholtz]

I would clarify that there is an open question here as to whether this should continue to be an engineering task, or whether the functionality should be built for a small group of users. I have no particular opinions there, other than the competing interests that (a) it might make people's lives easier in the long run if that functionality was in place, and (b) providing the functionality is essentially a workaround to the algorithm, and could be abused and thereby put the normal appeal distribution at risk.

[laurjpeterson]

Slack thread about this: https://dsva.slack.com/archives/C2ZAMLK88/p1558703774003200

[laurjpeterson]

Question about this - are DistributionTasks assigned to an organization? I wonder if we could just create a queue for whatever organization that is, add some "super users" to that organization, and allow them to assign tasks to judges from there.

@lowellrex or @monfresh might know the answer to this

[lowellrex]

are DistributionTasks assigned to an organization?

Yup! DistributionTasks are assigned to the mail team (I don't know why, but perhaps @amprokop recalls?).

I wonder if we could just create a queue for whatever organization that is, add some "super users" to that organization, and allow them to assign tasks to judges from there.

That approach makes sense to me!

[RachelSauter]

Question 1:

This is above my pay grade, but I can assist with making a recommendation to leadership if needed. In my opinion (not speaking for the Board) this is an important function and someone at the Board needs to be able to do this. But I agree that it would be dangerous to give a large group of people the ability to move cases around outside of the algorithm. I might put it with litigation and customer support since I think they would be fielding the requests to expedite a case. It’s likely that most of these are sitting with the hearing branch awaiting a hearing, but I’m not sure if the hearing branch should have the ability to move cases. Alternatively, we could take the superuser approach, but we would need to have some type of internal approval process (like a DVC needs to sign off before the case can be moved).

If for some reason a case was mistakenly moved from the AMA hearing docket to a judge, how would we “undo” that action? Would we be able to put the case back in line to be scheduled?

Question 2:

I'm going to provide a lot of information below for your records, but the bottom line is we need to draw a distinction between advancing a case in line on its current docket versus switching it to another docket, and whoever ultimately gets the ability to move AOD cases needs to understand this distinction. We have a lot of flexibility to move AOD cases ahead in line on their current docket, but the law gives the Board no flexibility to move a case from one docket to another - we have to adhere to specific rules to switch dockets.

Current Docket: Once an AOD motion is granted, we can move it to a judge immediately (unless there is something else that needs to happen, like the Veteran requested a hearing and has not withdrawn the request). 38 USC 7107(a)(2) provides the authority for AOD, and it includes serious illness, financial hardship, and “other sufficient cause,” so there is a lot of flexibility to grant an AOD motion. Once a case is AOD, we are not required to decide it in order, and can manually move that case to the front of the line for its docket.

For example, a Veteran on the AMA hearing docket falls into one of these special scenarios where the case must go to a judge immediately. If the Veteran says, "I withdraw my hearing request, because I want a judge to decide my case now" then we are allowed to move the case to a judge immediately, but the case remains on the hearing docket.

Docket Switch: In the example above, if the Veteran instead says, "I want to switch from the hearing docket to the direct docket, because I want a judge to decide my case now" then we cannot move the case, because there are specific rules that control the process of switching dockets. These are found in 38 CFR 20.202(c)(2) (available here: https://www.ecfr.gov/cgi-bin/text-idx?SID=d7fc2b0069243d8d7697cb90605c17ed&mc=true&node=se38.2.20_1202&rgn=div8) and 20.800(a)(2) (available here: https://www.ecfr.gov/cgi-bin/text-idx?SID=d7fc2b0069243d8d7697cb90605c17ed&mc=true&node=se38.2.20_1800&rgn=div8).

We can only move a case from one docket to another when all three of the following are met:

• The Veteran (or representative) submits a new VA Form 10182 indicating their new choice of review (direct, evidence, or hearing); and
• The request is made within one year from the date of the AOJ decision, or 60 days from the date of the first 10182, whichever is later; and
• The Veteran has not yet submitted evidence or hearing testimony.

If the Veteran doesn’t follow these rules, the Board is actually prohibited by law to move the case from the hearing docket to the evidence or direct docket, or from the evidence or direct docket to the hearing docket (technically, we are not prohibited from moving cases between the evidence and direct dockets, but that doesn’t mean we should). The Board is allowed under the law to deny a request to switch dockets, but as a policy matter, I think we should be very careful to respect Veteran choices even if we don’t agree with them.

[pshahVA]

Thanks @RachelSauter for the detailed response.
@laurjpeterson, I believe the next steps would be to determine if this is a backlog item or continue to do the manual backend fix (as @pshahVA suggested). Maybe add this to the list of things to be prioritized?

[laurjpeterson]

@pshahVA - yep, going to ask JW about it today.

[amprokop]

Yup! DistributionTasks are assigned to the mail team (I don't know why, but perhaps @amprokop recalls?).

My memory of this is — we assign these tasks to the Mail organization because, if a Mail task comes in, it can then be added as a subtask and block distribution.

@lowellrex does that make sense to you?

[lowellrex]

if a Mail task comes in, it can then be added as a subtask and block distribution.

Makes sense!

[lomky]

For the four cases today, all were in the same state. JudgeAssignTask assigned to a SSC. We cancelled that task and created a new JudgeAssignTask assigned to the VLJ requested. Steps:

```ruby

get the appeal

a = Appeal.find_by(uuid: "f6f26393-cb1e-4896-b015-6954e54664d5")

examine the tasks & pick out the JudgeAssignTask, confirm it is assigned to the SSC

pp a.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
jt = Task.find(TASK_ID)
User.find(USER_ID)

find the new judge, confirm its a unique match

user = User.find_by_sql("select * from users where lower(full_name) like '%NAME%'").first
User.find_by_sql("select * from users where lower(full_name) like '%NAME%'").count

To retain the history of the case, we will close the current SSC judge task, and make another for the requested judge

ActiveRecord::Base.multi_transaction do
new_jt = JudgeAssignTask.create!(appeal: a,
parent: a.root_task,
assigned_at: Time.zone.now,
assigned_to: user,
action: COPY::JUDGE_ASSIGN_TASK_LABEL)
jt.update!(status: Constants.TASK_STATUSES.cancelled)
end

review the SQL run

confirm Appeal & its assignment look good.

pp a.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
Task.find(NEWTASK).assigned_to

[pshahVA]

Can we combine this with #10551

[laurjpeterson]

@lomky or others. I'm assuming SSCs are judges in VACOLS - is that true?

If they are judges in VACOLS, i though they would already be able to reassign tasks from one judge to another, fixed with this ticket. https://github.com/department-of-veterans-affairs/caseflow/issues/7612. if they are, then we can train SSCs how to reassign JudgeAssignTasks from one judge to another.

@pshahVA - i think this is slightly different than #10551, and doesn't need to be blocked by #10551.

I saw @lowellrex post in slack yesterday so would like his feedback on this AC (also now listed above) and if it's enough to go on for the next eng step - to spec it out:

• Create organization where all cases that are ready for distribution live. could be called "Case Storage" even.
• Give only certain people access to that organization
• Allow manual distribution/assignment to judges from that link only
• Manual distribution includes:
  
  
  
  • user selects a case within the list and navigates to Case Details
  
  
  • DistributionTask shows in Currently Active Tasks component
  
  
  • user has the Action available in the dropdown to "send to judge"
  
  
  • user can select a judge from a list (like how we assign cases to attorneys today)
  
  
  • "send to judge" creates a JudgeAssignTask and assigns it to the correct judge
  
  

[nicholasholtz]

@laurjpeterson I believe part of the issue here is policy; while having SSCs as a judge would grant them this capability, there is apparently a Board policy that prevents SSCs from transferring these cases. Thus, they want these admins to have the ability. Essentially it would look exactly the same on the back end, but from their process point of view, it would be an admin doing it, and not a SSC.

[laurjpeterson]

Moving this to design in progress pipeline!

[pshahVA]

Closing this ticket as we are past the investigation stage, and it is being worked on.

11263 #11346