Caseflow: IDT API epic

[amprokop]

This covers the IDT integration work for attorneys/judges and BVA dispatch to support RAMP.

Background

The Board built an Interactive Decision Template (IDT), which populates Veteran data from VACOLS, text from the CFR and other "snippets" of language for decisions from an Access Database into one of the various decision templates in MS Word. All attorneys and judges are now using the IDT for legacy appeals. BVA dispatch users will be integrating this into their workflow, too.

The Board would like to continue using the IDT for AMA appeals come February 2019, as well as for the RAMP appeals pilot in October 2018. Since Veteran and appeal data for AMA appeals will not be in VACOLS, Caseflow will need to surface Veteran and appeal data to the IDT.

By October 1st, we will have transitioned the attorney/judge IDT off of VACOLS entirely for both legacy and AMA appeals. For the BVA Dispatch IDT, by October 1st we will support AMA appeals but not legacy ones.

Requirements / Scope

Done

• Associate CSS ID with token
• Return VACOLS appeal list (by user and by file number) from /idt/api/v1/appeals
• Return more detailed info about VACOLS appeals from /idt/api/v1/appeals/:appeal_id
• Return user information from /idt/api/v1/user
• Return list of judges from /idt/api/v1/judges
• Add additional attributes to /idt/api/v1/appeals/:appeal_id

Ready for dev

• Return AMA appeals from /idt/api/v1/appeals
• Return AMA appeal details from /idt/api/v1/appeals/:appeal_id
• Ensure BVA Dispatch users can view their AMA appeals when making a call to /idt/api/v1/appeals
• Allow BVA Dispatch users to receive all claimant and POA addresses from BGS for AMA appeals
• Allow BVA Dispatch users to complete their tasks using the IDT API

Under investigation

For @amprokop to investigate

• Parse and return contesting claimant info and addresses from Power of Attorney wrapper
• Fix skipped IDT appeals controller test
• Figure out citation numbers for AMA appeals and return them to the API
• Determine what to do with the IDTDISPATCH table still in VACOLS - should we continue to use it for AMA?

[shanear]

Proposal: Build a Caseflow Decision Uploader in favor of an IDT Outcode API

Instead of having the appeal be outcoded when it's signed via the IDT, it should be outcoded when it's uploaded to VBMS. We can do this by building a simple Caseflow widget that dispatchers use to upload the document to VBMS and outcode the appeal at the same time. This would automatically link the VBMS document with the Caseflow appeal. Removing the need to search for the decision document from VBMS after the fact in the Dispatch job.

Why?

1) It would align incentives for BVA dispatch and processing decisions faster. Right now, BVA dispatch employees are measured on how many appeals are outcoded, not including uploading the Decision document to VBMS, even though it is a necessary step in having the decision processed, and can delay processing for weeks.

2) It would be similar, maybe less than the complexity of modifying current Dispatch processes to support AMA appeals:
- It would completely remove the need for the Dispatch job to try and match up decision documents. This job is both error prone, and has edge cases and error states that require the Dispatch UI to resolve (multiple decision documents).
- It completely removes the need for the Missing Decision Documents page in Caseflow. This is a win from both the engineering perspective (as most of the fields would have to be switched to come from either VACOLS or Caseflow), and the process perspective (we would no longer have to pester the BVA dispatch team to stay on top of the missing decisions page)
- Since in October, we aren't recording special issues and all dispatch EPs will be routed to AMO, we can automatically generate the dispatch EP in response to the decision being uploaded.

3) It would be closer to our desired end state. We want to get away from the IDT and have more stuff handled in Caseflow anyways, so this gets us closer to that state with little to no extra work.

[amprokop]

Super nice. Will think / talk this through with some folks tomorrow, @shanear. Thanks!

[amprokop]

@laurjpeterson, mind taking a look at Shane's proposal and offering thoughts?

[amprokop]

I remember there being some rules associated with decision uploads to VBMS — like for example, if it's after 3pm the document doesn't get uploaded until the next day? Is that right?

[laurjpeterson]

• I think Shane's proposal is something we have been thinking about for Caseflow long term - automatic upload to VBMS. I pictured it for after October, and maybe even when we had decision documents in s3, and did not think it was feasible for the October time frame. But after chatting with Shane and Sunil about this yesterday, it seems more feasible and intriguing.
• I like the idea of removing the need for Caseflow Dispatch jobs. Learning more about them yesterday, they seem even more complex than I had originally understood. Especially since RAMP appeals are compensation appeals only (lower probability of special issues), it seems less risky to change the process even now
• I don't think we'd have to prioritize fixing the Missing Decisions page for October because there are so few appeals and they will be highly visible. This could come after October. I might be taking on too much risk there, though.
• I think the rules are more associated with physical mail schedules - mail is picked up every day at 3:30pm. BVA decisions have to have the same decision date and mail date, but their upload to VBMS date can be later. @allyceh - can you confirm?

[amprokop]

One possible tweak to Shane's proposal — the IDT could upload the decision document through the Caseflow API, which would accept the document upload itself and upload to VBMS. This would probably be the lowest-effort option of all, with no frontend. @shanear @laurjpeterson @sunil-sadasivan @allyceh thoughts on this?

[allyceh]

Good stuff here!

@laurjpeterson @amprokop The date on the letter must match the day a letter is mailed. This date must also match the date it's uploaded to VBMS.

Mail is picked up daily at 3:30 pm. If it's after this time, Dispatchers can still prepare decision letters, but they must date the letter for the following day. They mail and upload the decision letter on the following day because VBMS does not offer date selection for the future; so, they must always upload to VBMS on the day the letter goes out.

If someone is working from home, the date they choose for the decision letter is the date they'll be in the office next. Example: If someone works from home every Monday and Tuesday, they would date their letters for Wednesday when they're back in the office. On Wednesday morning, they take an hour or so to print out several letters, stuff envelopes, and upload all of these to VBMS before they can start on any new cases. Kind of playing catch up.

[allyceh]

@amprokop I like your tweak because it reduces the burden on the Dispatcher. Before we go that route, I am wondering if we might need some sort of date selection for this or way to "back out" of an automatic outcode/upload? See below.

1. Most common use case: It's business as usual, and a Dispatcher prepares a decision letter that will be mailed today. It's outcoded and uploaded to VBMS automatically. Everything is golden.
2. Edge case: It's after 3:30 pm, so a Dispatcher dates a decision letter for the following day. The decision is automatically outcoded and uploaded to VBMS and it's routed to it's next destination. Therefore, the Dispatch tool will route the case to ARC prior to the letter actually going out in the mail. Q: @sunil-sadasivan @shanear are there any risks in doing this?
3. Edge case: Someone is working from home and dating their decision letters for the next day they are in the office. They get sick, and don't end up coming into the office for a few days. They must change the date on their decision letters when they get back in. Q: Similarly, is there a risk in having decisions outcoded + in VBMS when they'll actually be mailed a couple days later? Do Dispatchers need a way to "un-do" an outcode/upload? Or to select a date that it should be uploaded?

When we were accounting for automatic outcoding (but not automatically uploading to VBMS) earlier, I wasn't concerned about the decision getting to ARC before a letter was mailed because I knew that for decisions to get routed, the decision had to be both 1) outcoded, 2) uploaded to VBMS for the job to pick it up. And since decisions are mailed the same day they are uploaded to VBMS, we would not run into this issue.

Would love for you all to weigh in on this!

[shanear]

the IDT could upload the decision document through the Caseflow API, which would accept the document upload itself and upload to VBMS.

I pitched this when chatting with Sunil, but he seemed to think that it wasn't possible, but I'm all for it.

[sunil-sadasivan]

I pitched this when chatting with Sunil, but he seemed to think that it wasn't possible, but I'm all for it.

Wasn't sure of what was possible via word macros 🤷‍♀️. Changed my view on this after chatting with Alex and realized Paul (S) was already asking about that possibility.

[amprokop]

I’ll talk to Paul about this. Fallback is probably manual processing due to
the number of appeals, but Anya and I can see if we can get this done for
Oct

On Fri, Aug 31, 2018 at 13:57 Sunil Sadasivan [e-mail]
wrote:

I pitched this when chatting with Sunil, but he seemed to think that it
wasn't possible, but I'm all for it.

Wasn't sure of what was possible via word macros 🤷‍♀️. Changed my view
on this after chatting with Alex and realized Paul (S) was already asking
about that possibility.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/department-of-veterans-affairs/caseflow/issues/6358#issuecomment-417743716,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADm0y1Epwmy5f6_CUEdALjmeEd3sR4X1ks5uWXkGgaJpZM4VgrNO
.

[amprokop]

After thinking through @allyceh's edge cases, it seems to me that for now, the simplest way to allow the users to handle 2. and 3. would be to decouple the the Dispatch IDT from the outcoding & upload step to give them flexibility re: the upload date— so contrary to my previous suggestion, it'd probably be best to build an upload widget a la @shanear's suggestion rather than my proposal to bake that into the API. Thoughts on that?

[sunil-sadasivan]

@amprokop yeah I was thinking about that too. I think that makes the most sense, though in building a widget within Caseflow, we would then have to onboard the BVA staff who outcode on to the Caseflow UI since they wouldn't have access to Caseflow for the October pilots? Is that correct?

If there's a way around that (eg. can we onboard them on to Caseflow?) I think a widget within Caseflow would make sense esp as it may be setting up the pathway for what the long-term solution is.

[allyceh]

@sunil-sadasivan the BVA Staff who are our pilot users will have access to Caseflow! Specifically, the Case Details page to view veteran/appeal information. Unless we think there's a better place for the widget, we could put it on the Case Details page. It seems like we would need to ensure that only BVA Dispatchers can click and/or see this widget. We wouldn't want anyone accidentally uploading-- unless that wouldn't be possible, technically (i.e., there's a rule where a decision would need to be outcoded before the widget becomes active).

[amprokop]

Update: @sunil-sadasivan, @laurjpeterson, and i had a long discussion about this. We are considering setting a definite date to start dispatching of RAMP appeals, and considering proposing that it be November 1st. This would give us a bit more certainty and room to plan a solution.

[pkarman]

@laurjpeterson I think this Epic is complete?

[laurjpeterson]

Yep!