Research: new hearing type of virtual

[chandracarney]

Context

Engineering research needed for new hearing type of "virtual hearing." Hearing Coordinators need to be able to schedule a virtual hearing from the start of the scheduling process.

Hearing branch's end goals:

• Increase capacity to perform hearings with virtual hearing or Regional Office (no mixed dockets).
• The Intake form identifies whether the Veteran is willing to have a virtual hearing (the Board is responsible for requirements to update the form).

Interim solution required for the Board:

• Personnel at the Board will need to mark Veterans as eligible for virtual hearings after contacting Veterans.
• So that we are not immediately dependent on the form, the interim solution is that Hearing Coordinators (or Intake personnel) are able to mark a Veteran as eligible for virtual hearings.

Open questions to answer:

Hearing type:

• How does hearing type get edited?

Checkbox for interim solution:

• Would this be a flag on the Veteran or a flag on the particular case/appeal? (Might be at the appeal level because the intake form has to do with the appeal, not the Veteran.)
• Should this be a new task type "mark eligible for virtual hearings"?
• What options do we have?
• What additional information is needed from product, stakeholders, or other teams?
• Do we have any external dependencies?

[ferristseng]

Research Findings

Ensure HearingDay can accurately represent a virtual hearing

The current HearingDay model looks as follows:

HearingDay(
  id: integer,
  bva_poc: string,
  created_at: datetime,
  created_by_id: integer,
  deleted_at: datetime,
  judge_id: integer,
  lock: boolean,
  notes: text,
  regional_office: string,
  request_type: string,
  room: string,
  scheduled_for: date,
  updated_at: datetime,
  updated_by_id: integer
)

The only thing I can think of that should probably not apply to virtual hearings is the room field. There is some automated logic to find an available room in

caseflow/app/services/hearing_day_room_assignment.rb

Line 3 in 1d5bbcf

class HearingDayRoomAssignment

, which we will need to circumvent for virtual hearings. Outside of that, it doesn't look like room is used too much in a way that we'd need to change.

The other part of this would be figuring out if we need to add anything to HearingDay. As far as I can tell, we wouldn't since most of the info we need is tracked per-Hearing.

Compatibility with legacy hearings

The request type for a legacy hearing is stored directly on the hearing, instead of on the hearing day. This means that we could potentially have to introduce a new hearing type to VACOLS, which I'm not sure is possible since we won't be able to get a good sense if that would affect logic in VACOLS.

One possible way to work around this is by treating the HearingDay as the canonical source for scheduling data if the hearing is in Caseflow past a certain date (see #13273). If there's a HearingDay associated with a legacy hearing, we can have the request type on that day override whatever is in VACOLS.

Ensure conditional logic can handle "virtual" type

Probably one of the biggest parts to this would be ensuring that all of the conditional logic we have that depends on the hearing day request type would be able to handle a new virtual hearing type. There are a number of places where we assume central or virtual hearing types such as:

caseflow/app/models/hearing.rb

Lines 80 to 85 in 1d5bbcf

	def readable_location
	return "Washington, DC" if request_type == HearingDay::REQUEST_TYPES[:central]
	return "#{location.city}, #{location.state}" if location
	nil
	end

caseflow/app/controllers/hearings/hearing_day_controller.rb

Lines 181 to 182 in 3f18958

	def no_available_rooms
	key = (params[:request_type] == HearingDay::REQUEST_TYPES[:central]) ? "CO" : "VIDEO"

There shouldn't ever be a location for virtual hearings, but the function still handles all non-central hearings similarly. I think instead we should refactor all code that has conditional logic dependent on the request type to be explicit about how different hearing types are handled using a case/switch statement:

def readable_location
  case request_type
  when HearingDay::REQUEST_TYPES[:central]
    "Washington, DC"
  when HearingDay::REQUEST_TYPES[:video], HearingDay::REQUEST_TYPE[:travel]
    return "#{location.city}, #{location.state}" if location

    nil
  when HearingDay::REQUEST_TYPES[:virtual]
    nil
  else
    fail HearingRequestTypeInvalid, "invalid request type #{request_type}"
  end
end

I think all the relevant code should be adapted to fail fast if we aren't explicitly handling any cases to catch any bugs as quickly as possible.

Timezone for Virtual Dockets

Since virtual-dockets won't be associated with a physical location, we won't have a timezone available to us to display the hearings time in. We do have access to the veteran's address, so we could potentially make a rough estimate of the timezone based on zip code. It's also worth noting that the this problem already exists with video hearings, since we're using the location of the hearing as opposed to the veteran's address to figure out the timezone. There's a chance that the timezone might not be correct in that scenario, although we are expecting it not to be incredibly common.

See https://dsva.slack.com/archives/C3EAF3Q15/p1585770263131600

Which data to display on the Frontend?

Because virtual-only dockets won't have a location associated with them, we most likely will need to update our frontend to hide fields that reference a physical location.

Small things

• Add option for virtual request type to the dropdown on the HearingDayAddModal
• All of our request types are stored as a single character -- what should that character be? V, T, C are already taken.
• On the hearings schedule page we categorized video days with virtual hearings in a way that might be inconsistent
  • Days that show a type of Video, Virtual days are treated as Video days when filtering
  • A Video day with only Virtual hearing days is shown as Virtual
  • A virtual hearing day would presumably show Virtual as its type, but this would be different than a Video day with only virtual hearing days because it wouldn't have a room associated with it. Is this confusing to a HC?
  • Video, Virtual days should show up when filtering by Virtual days, where as they do not do that now.

[pshahVA]

@chandracarney, as we discussed earlier, would we like to investigate a veteran self selecting from their va.gov profile? I can create a ticket with the VA.gov team to look into this.

[ferristseng]

Going to close this, since the research is done, and tickets have been created!