Attorney check out | Remand reasons

[lpciferri]

When an attorney is assigning a decision to a judge for review and one or more issues have the remand issue disposition, they want to mark the type of remand, so that the Board and VBA can have better data about why issues are being remanded back to the agency of original jurisdiction (AOJ).

Updated

Note we are changing the navigation of checkout flows and talking about design consistency tomorrow. Nav through the flow may change

• [x] When a user selects a remand reason as a disposition, they are taken to the Remand Reasons screen
• [x] Verify that the bread crumbs for this page are called Select Remand Reasons
• [x] The title of this page is called Select Remand Reasons
• [x] There is a horizontal line underneath the copy
• [x] The remand reasons behaves as an embedded page for single and multi issues (see mocks)
• [x] Each Issue on this page is labeled:
  • Issue 1 - for single issues
  • Issue 1 of x - for multi issues
• [x] There is a section called Issue with the following categories:
  • Program
  • Issue
  • Code
  • Certified date
• [x] Verify that the list of reasons appear
  • look at the mock for the reasons (not writing since we already have those)
• [x] Verify that there is a link at the bottom left called < Go back to [previous page title]
• [ ] Verify the following error states:
  • When a user does not select a remand reason we mirror a form error with the text below "Choose at least one"
  • When a user selects a remand reason but not a before or after cert designation that we render the error seen in the mock with the following copy: "Chose one"

Single Remand Reason

• [x] Verify that there is a button on the bottom right called "Continue" through the flow of Remand Reasons

Multi remand reasons

• [x] For pages with multiple remand reasons - show a button called "Next Issue"
• [x] This pattern continues until the last issue is shown, where the above button disappears and a continue shows at the bottom.

Select remand reasons page 1

Select remand reasons page 2

Next issue button disappears and the continue shows

Select remand reasons error

Select remands reasons error checkbox

Archive 2.zip

---

Acceptance Criteria

• [ ] Verify that if a user selects "Remand" as an issue disposition on the Select Remands Screen #4471, they are directed to the "Select Remands Screen"
• [ ] Verify that regardless of number of remand dispositions selected, one issue is shown
• [ ] Verify that each issue is separated by a title called Issue 1, Issue 2 etc.
• [ ] Verify that underneath the Issue title is the issue with the following structure:
  • Program
  • Issue
  • Code
  • Certification date
• [ ] Verify that there should be a a sub title caused Remand Reasons
• [ ] Verify that for each remand reason has the following sections as radio buttons in this order:
  • Medical Examinations and Opinions
    • Medical Opinions
    • Medical Examinations
  • Duty to assist
    • VA records
    • Private records
    • Service personnel records
    • Service treatment records
    • Other government records
    • Due process and duty to notify
      • Due process
      • Duty to notify
• [ ] Verify that one of the reasons are picked an indented check box appears with the following options
  • Before certification
  • After certification
• [ ] Verify that when a user clicks show more 2 more issues appear
• [ ] Verify that when the last remand disposition is displayed, the show more disappears

Mocks

Default screen

Context

• Relevant AMA statutory reporting requirements:
  • “The total number of remands to obtain advisory medical opinions under section 5109(d) of title 38, United States Code, as added by section 2(j).”
  • “The number of errors committed by the Secretary in carrying out the Secretary’s duty to assist under section 5103A of title 38, United States Code, that were identified by higher-level review and by the Board, disaggregated by type of error, such as errors relating to private records and inadequate examinations, and a comparison with errors committed by the Secretary in carrying out such duty with respect to appeals of decisions on legacy claims.”
• For AMA appeals, we need to add AOJ rating decision date instead of certification date
• For AMA appeals, we need to add. before or after AOJ rating decision date, instead of before or after certification date

Open questions

• These new options encompass some of the existing remand reasons in VACOLS. Do we need to crosswalk to existing remand reasons for legacy appeals?

[lpciferri]

@amprokop - confirmed the required remand reasons going forward with stakeholders. these remand reasons won't neatly map to existing VACOLS remand reasons because they are inclusive of some, or the higher category (e.g. due process as a selection itself did not previously exist). thoughts on the lack of an exact crosswalk to VACOLS here?

[Chingujo]

@laurjpeterson

Added details to AC to reflect the new changes - page layout. Final mocks uploaded

[Chingujo]

Laying the remand reasons to rest:

Context: This screen will change in a month and the rate of remand per appeal is rounded up to 2 with rare instances of three to four. The UX flow is that users will see one issue and a show more button that will expand two issues per copy link. The reason for this is as follows:

• Showing one issue makes the length of the screen more manageable
• Showing two more per issue allows us to capture the broad range of remands numbers with one click (2-3) vs. the three to four suggested.
• Although lazy load was suggested, on scrolls generate scroll fatigue are more prone to user error. Accidentally pressing a scroll wheel and, from my experience, can generate lag and visual blurs. Show more is more deliberate.
• Although new pages would prevent scroll fatigue, it will make breadcrumbs more difficult. We are really just replacing scroll fatigue with process fatigue.

[Chingujo]

Few quick things to preserve the decisions and records

• Checkboxes for list over radio buttons
• No limits to selections within groups as attorneys were allowed to check across groups. There is very little edge cases where more than 2 is selected.

[dannysellers]

What do we mean by the user being "directed" to the Select Remands screen? I'm hesitant to automatically redirect someone as soon as they change an option, and was tentatively using a link under the dropdown.

I'm not sure how to display the remand reason(s) after the user gets back to this screen.

Also, just to confirm: After a user sets an issue's disposition to "Remanded" and goes to the Select Remand Reasons screen, they'll only be choosing reasons for the issue they just marked as remanded, correct?

I'm unclear on what displaying multiple issues in this screen means—are the other issues displayed here from the set of issues the user marked as "remanded" in the previous screen? For example, if the user sets 3 issues to remanded and navigates to Select Remand Reasons for one issue, should we give them the ability to set remand reasons for the other two issues while on the same screen?

I was tentatively using /tasks/:appealId/dispositions/:issueId/remand for this page's URL, with the idea that it's a page to edit an individual issue (similar to /dispositions/:issueId/(add or edit)). If that's not the case, we can make it something like /tasks/:appealId/dispositions/remands (where /dispositions is the Select Dispositions page).

Also, where does an issue's certification date come from?

[Chingujo]

@laurjpeterson Chatted with @dannysellers over slack and think in person would be best tomorrow since there is a lot here. Let sync after stand up? Here are some answers to more of the quick ones:

What do we mean by the user being "directed" to the Select Remands screen? I'm hesitant to automatically redirect someone as soon as they change an option, and was tentatively using a link under the dropdown.

It would not automatically direct after the dropdown is selected. It would direct if a remand was selected as an option after the user clicks the finish dispositions button

Also, just to confirm: After a user sets an issue's disposition to "Remanded" and goes to the Select Remand Reasons screen, they'll only be choosing reasons for the issue they just marked as remanded, correct?

Yes =D

I'm not sure how to display the remand reason(s) after the user gets back to this screen.

The remand reasons don't have to display. If you mean the dispositions screen by when the user gets back to this screen. For example, if a user selected remand reasons and then clicks the browser back or bread crumb there would be no need to display anything additional on the disposition screen. Users would rarely return back unless they marked a remand as a mistake.

I'm unclear on what displaying multiple issues in this screen means—are the other issues displayed here from the set of issues the user marked as "remanded" in the previous screen? For example, if the user sets 3 issues to remanded and navigates to Select Remand Reasons for one issue, should we give them the ability to set remand reasons for the other two issues while on the same screen?

TLDR is yes. More context below and let's re-visit when we sync tomorrow. It was an issue of scroll length versus multiple pages. Since the average is 1.57, my preference is toward clarity of information i.e. a scroll versus show more.

I was tentatively using /tasks/:appealId/dispositions/:issueId/remand for this page's URL, with the idea that it's a page to edit an individual issue (similar to /dispositions/:issueId/(add or edit)). If that's not the case, we can make it something like /tasks/:appealId/dispositions/remands (where /dispositions is the Select Dispositions page).

Good question for tomorrow. It would be second under the current UX but would prefer remand reasons versus remands as the file path if possible.

Also, where does an issue's certification date come from?

Something Alex or Anya would know from the back end. A certification date is when the appeal was sent or "certified" to the BVA and is used to determine whether a remand occurred pre or after certification.

[dannysellers]

@laurjpeterson @Chingujo In this response from Jed about remand reasons, he mentions active vs. inactive reasons. Is that something that may change over time?

[Chingujo]

hahah reminds me of a certain checkbox @laurjpeterson as some of what we are displayed on this Remand Reasons excel spread sheet is in the inactive column.

LP can gut check me here.

Remand reasons is a fluid screen and we should expect these reasons to change over time. Not just in terms of active or inactive but what we actually display in the UI as well.

[lpciferri]

@Chingujo @dannysellers - in the past, yes, Jed was asked to edit remand reasons. however, i think that will be reduced in the future, under AMA.

1) these remand reasons have been captured for legacy appeals to help with training ROs, and we've learned this data is not widely used 2) many of these remand reasons are no longer applicable under AMA. we have an updated screen focusing specifically on AMA reporting requirements that we will introduce when we have deprecated DAS

[Chingujo]

@dannysellers

AC and mocks updated to reflect final remand reasons screen. Thanks for the patience

[dannysellers]

To designers: One technical issue I forgot about is #5092: Due to the way our footer (which contains Back and Next buttons) is constructed, it doesn't re-render as often as it should.

What that means for this ticket is that the Next/Continue button (below the app frame) is hidden when the user first visits the page, because there still are hidden remand reason blocks, and then doesn't appear once they've showed/gone through all the reason blocks, leaving the user with no way to proceed to the next page.

Unfortunately, until this issue is fixed, it means we can't really do anything to affect the usability of the Next button in the footer (like just disabling it instead of hiding it).

Two solutions come to mind, one of which is a bit messy. One option is to display two buttons, one to Show Next Issue, and the other to Continue. We can easily alter the behavior of the footer button (because that behavior is external to the rendering/re-rendering of the component itself), so we could always prevent the user from continuing until they've showed all possible issues. At that point, though, we might as well only display one button (within the footer). I think I proposed this earlier—to have only the one button (in the footer) display more issues before they're all displayed, and then once they're all displayed (and the user has selected ≥ 1 remand reason), use that button to proceed to the next page.

[amprokop]

Just for a visual aid (correct me if I'm wrong @dannysellers ), we're just asking to move the button in the first screenshot out of the white box and into the footer, like in the second screenshot.