Caseflow: Filter ineligible issues from Queue

[shanear]

In Intake, we save ineligible issues on appeals to keep a record of how often veterans request ineligible issues. However, these issues should not appear in the rest of queue. The should also not require decisions

[lowellrex]

In case I'm not able to get around to this today, I think we can add a field to the WorkQueue::AppealSerializer's issues property to check if the issue is eligible? and filter those that are not out on the frontend.

[amprokop]

@shanear @pkarman -

Was thinking about this a bit. Off the top of my head, at least a few downstream changes are necessary I believe due to this change.

• reporting on the number of issues on an appeal should probably filter out ineligible issues
• IDT API needs to change to not return these issues
• productivity reporting for attorneys needs to take this into account (this will be based on number of issues on an appeal going forward- likely that ineligible issues should not be counted)
• validation of decision issues and request issue mapping needs to exclude ineligible issues

Question for you both- did you consider saving ineligible issues into a separate table to avoid downstream gotchas across other parts of Caseflow? If not, would you be willing to consider that approach instead?

My guess is that we only really want to reference this information in pretty isolated Intake-related cases, and other folks/teams shouldn’t need to know about it at all, and isolating that information might prevent later bugs.

Curious about your thoughts. Thanks!

[lowellrex]

This case seems exemplary of the types of issues we run into not infrequently, where expectations about what data exists in a table is different from team to team, or where changes made to the extensively shared sections of the codebase impact one team in a way that is unexpected. I wonder if now is the right time to schedule a larger conversation about practices we can adopt to avoid these types of situations (Maybe maintain some documentation as the source of truth about how some shared tables should be used? Require a two day open comment period on any schema changes for shared tables?).

cc @mdbenjam

[mdbenjam]

👋

I think that probably makes sense. I think this is something that has hurt the Queue team in the past. I had a little bit of a hard time getting AMA cases into Queue since Intake and Queue were changing some of the models at the same time. Maybe this is a good opportunity for a good ole fashioned post-standup-discussion: https://github.com/department-of-veterans-affairs/caseflow/issues/7708

[pkarman]

@amprokop we didn't consider adding a separate table.

To your point, I didn't completely understand the cascading impact of storing eligible and ineligible request issues together. That's a breakdown in our process, I think.

Another way to solve this problem would be to add an eligible scope to the RequestIssue model and make it the default scope. So by default you'll only see eligible issues, but can explicitly ask for all of them. The advantage of that approach would be simplifying the data storage and actions on the model, esp for cases like #7301 .

[laurjpeterson]

@shanear - Would love to connect with you to clarify what should happen to ineligible issues after intake. I see your note that these issues should not show in queue. Is there any reason for BVA employees / attorneys to see these issues down the line?

I've reviewed these two tickets in appeals-design-research to try and get context:

• https://github.com/department-of-veterans-affairs/appeals-design-research/issues/915
• https://github.com/department-of-veterans-affairs/appeals-design-research/issues/1033

[mdbenjam]

@pkarman didn't know about default scope, that's a really cool thing.

[amprokop]

+1 on default scope, nice feature. Given that @laurjpeterson is going to dig into this more, I think it makes sense to circle back on what the product requirements are for Queue and then revisit this topic, if that's okay with y'all.

[laurjpeterson]

Connected with @shanear earlier today. I now understand that current state, Queue is showing ineligible issues by default in Case details, but not distinguishing ineligible from eligible. This means that attorneys and judges are prompted to add issue dispositions for them when they should not. Shane presumed that we'd want to hide them, though I think it could be useful for attorneys and other BVA employees to see these ineligible issues and the reason for their ineligibility. Most folks review the NOD so it could be useful for everything a Veteran lists to be viewable in Caseflow.

Suggested next steps:

1. @shanear - Can you provide some examples of what ineligible issues look like in Caseflow? What fields do we have (something like issue description and ineligibility reason perhaps), and what are some examples of ineligible issues that we already have in Caseflow?
2. @allyceh - Can you take a look through this issue and let me know if you have any thoughts on how we might display ineligible issues in the Issues section of Case details? (you probably need the data Shane will provide above to do so.) Perhaps you can ask a few attorneys about whether they'd find viewing ineligible issues useful in Caseflow when you test issue adding and removing with them this week.
3. @shanear - Is there a way to see which RAMP appeals have ineligible issues right now? Feel free to point me to the right fields in Looker and I can build a report. I see the risk of attorneys/judges accidentally deciding an ineligible issue and wanting to filter them out even in the time being, but if there are so few of them, we can likely wait for a quick design exploration.

[shanear]

1. There are a variety of reasons an issue can be ineligible (you can see those here: https://github.com/department-of-veterans-affairs/caseflow/blob/master/app/models/request_issue.rb#L12, also this list will be growing). We store the reason in the DB. What they look like is WIP (see https://github.com/department-of-veterans-affairs/caseflow/issues/7594#issuecomment-436452141 with the latest).

2. Yes. Though we've only had the ineligible functionality launched for a few days so there may not be any now. In looker just use the ineligible_reason on request_issues to make reports.

[laurjpeterson]

Cool - it looks like ineligible issues will look the same as others - the issue description sentence - but highlighted in a different color. I should have gotten that, whoops. So @allyceh - you can likely proceed with a design exploration!

[allyceh]

@laurjpeterson I had assumed we wanted to not display ineligible issues in Case Details since attorneys wouldn't be deciding on them. One of our error messages in the Intake flow addresses this situation like this (below):

I will ask a couple attorneys what they think of viewing ineligible issues, and we can go from there!

[laurjpeterson]

If the attorney wanted to Correct contested decisions and enters the Add/Remove issues flow, would they see that the ineligible issue was selected by intake, and prevent them from selecting it again? That might be all we need to ensure (and it might already be done).

[carolaponce]

Will continue this and post a new alert style by 11/13/18