Skip to content

Hearing Record and Transcribe (HRT)

minhazur9 edited this page Apr 26, 2024 · 3 revisions

Pexip

Pexip is our legacy means of hosting conferences for virtual hearings. Once a virtual hearing gets scheduled for Pexip, Caseflow will run the VirtualHearings::CreateConferenceJob to create a conference link for Pexip, there is a recurring job that gets ran to delete conferences not needed anymore called VirtualHearings::DeleteConferencesJob. These jobs will be leveraging the Management API from Pexip to use the endpoints for creation and deletion.

Method Endpoint Description
POST https://MANAGEMENT_HOST/api/admin/configuration/v1/conference/ Creating a conference
PATCH https://MANAGEMENT_HOST/api/admin/configuration/v1/conference/CONFERENCE_ID Editing a conference
DELETE https://MANAGEMENT_HOST/api/admin/configuration/v1/conference/CONFERENCE_ID Deleting a conference

After a hearing gets held a TranscriptionTask gets created for confirmation. The Transcription Team will pick this up and send a work package consisting of audio recordings to a transcriber who will manually type out the transcript. Once it gets completed, the Transcription Team will retrieve the finished transcript and start reviewing it for QA. If it passes then the TranscriptionTask can be marked completed, if not then it will be "on hold" until either the appellant opts for a new hearing or proceeds without a transcript.

Webex

Instant Connect

Also known as the ‘slim’ client, Instant Connect provides a way for guests to join meetings without needing an account or the Webex Meetings app that provides FedRAMP support. Instant Connect Docs

RTC

Also known as the 'thick' client, WebexRTC allows for an abundance of customization upon meeting creation. RTC Docs

Phase 1

Switch a User to Webex

As a Team Admin user navigate to the Team Management page and scroll to the Hearings Management Org Admin Page link. This user will be able to change how a current team member schedules a hearing using either Pexip or Webex through the selection of radio buttons that updates the user.meeting_type. A user is always a Pexip user until a different selection is made on this page.

Schedule Virtual Webex Meetings

Whether a hearing is a Pexip or Webex type is based on the meeting_type of the user that originally schedules the hearing. create_conference_job in virtual_hearings uses the conference_client to determine the correct service to build the virtual hearing link from.

Phase 2

Recordings API

GET A List of Recordings
GET Details for a Recording

Process Models

Every hour we run Hearings::FetchWebexRecordingsListJob to call on the Webex Recordings API to receive all the transcriptions that were generated within the hour before with the endpoint for getting all recordings. (Ex. At 10 am we query for transcriptions made from 8-9 am). Once this happens we run Hearings::FetchWebexRecordingsDetailsJob for each recording to get the information we need and the download links so we can begin downloading for VTT and MP3 formats, reupload them up to our S3 bucket before grabbing the AWS link to make them available for download from the frontend. At this point we are able to download a transcription file in VTT, MP3 and MP4 format.

Current query Config for fetching the Webex recordings list

def fetch_recordings_list
    from = CGI.escape(2.hours.ago.in_time_zone("America/New_York").beginning_of_hour.iso8601)
    to = CGI.escape(1.hour.ago.in_time_zone("America/New_York").beginning_of_hour.iso8601)
    max = 100
    query = { "from": from, "to": to, "max": max }

    WebexService.new(
      host: HOST,
      port: PORT,
      aud: ORGANIZATION,
      apikey: API_KEY,
      domain: DOMAIN,
      api_endpoint: ENDPOINT,
      query: query
    ).fetch_recordings_list
end

We are also able to get the transcription file in a more readable format like a regular document through our TranscriptionTransformer workflow to convert the original VTT into an RTF. In order to do this we utlize ruby gems called webvtt and rtf. webvtt is used for parsing a VTT and generating an object containing the metadata and content of the file which we need for smooth conversion. rtf is used to create and format an rtf file. Usually to generate an rtf file we would need to convert the file into a raw rtf string and input the information manually for things like borders, spacing, text, font, etc, and its a very slow process to format everything correctly. This gem streamlines the process and allows making edits programmatically, we will be sending the rtf to S3 as well.

The original VTT file

image

The RTF file after conversion

image

If an error occurs during conversion we will be using the csv gem to record the error and information about it to generate a csv file before uploading it to the S3 bucket.

The CSV error file will be formatted like this:

Length Appeal ID Date Judge Issues File Name
Duration of hearing ID of appeal Date of hearing Name of the judge Errors occurred during conversion Name of the file

Process Flow Chart

ASR-309 Phase 2 part 1 v 34 3rd revision A

ASR-309 Phase 2 part 2 v 34 2nd revison

Display of Transcription Files in Caseflow

Information regarding a Webex hearing's transcription_files is made available to Caseflow users on the Hearing Details page under the Transcription Details section. The Transcription Files table (TranscriptionFilesTable.jsx) includes columns:

  • Docket(s): transcription_file.docket_number
  • Uploaded: transcription_file.date_upload_aws
  • File Link: transcription_file.aws_link
  • Status: transcription_file.file_status

Previously, the Hearing Details page never rendered the Transcription Details section for legacy hearings. That being said, for a legacy Webex hearing, we now display the Transcription Details section – but the only subsection we would include is the newly created Transcription Files table. The Transcription Files table will never render for a Pexip hearing.

Screenshot 2024-04-24 at 8 25 49 AM

Multiple Dockets

The Transcription Files table "Docket(s)" column name suggests the potential for the table to represent transcription_files across multiple dockets. As of HRT Phase 3, this behavior has yet to be implemented. However, in TranscriptionFiles.jsx, we allow for the case where hearing.transcriptionFiles returns a nested object, which would have been sorted by transcription_file.docket_number on the backend. The table would then group associated rows in the table and style accordingly.

One-to-One Relationship Between Non-Virtual Hearings and Conference Links

The introduction of Webex as a conference provider brought to light a discrepancy between how Caseflow manages virtual and non-virtual conference links. Whereas we assign each virtual hearing its own unique conference link, in the case of a non-virtual hearing, the existing behavior was to associate a conference link with an entire hearing_day. One hearing_day may have multiple non-virtual hearings, each of which would share the same conference_link. What results is a one-to-many relationship between a conference_link and its hearings through a shared hearing_day association.

The one-to-many relationship mirrors the process by which a regional office may stop and start the same conference to host multiple non-virtual hearings over the course of one day. However, when it came to the newly integrated Webex hearings, both virtual and non-virtual, it became apparent that the one-to-many relationship fell short. In order to associate a hearing with its recording and transcription files, which we retrieve from the Webex API, it became necessary to include the hearing_id and hearing type (Hearing or LegacyHearing) in the subject of the Webex conference.

app/models/concerns/hearing_concern.rb

def subject_for_conference
  "#{docket_number}_#{id}_#{self.class}"
end

Unique hearing identifiers would not be available at the time of hearing_day creation, which is when Caseflow generates non-virtual Pexip conference links. As a result, we opted to enforce a one-to-one association between non-virtual Webex hearings and their conference links. In addition, although the process of Pexip link creation was left unchanged, adjustments were made to create the appearance of a one-to-one relationship regardless of conference provider – this in order to ensure a more uniform user experience.

  • Non-virtual Webex hearings retrieve their conference_link through HearingConcern#non_virtual_conference_link.

    app/models/concerns/hearing_concern.rb
    
    def non_virtual_conference_link
      ConferenceLink.find_by(hearing: self)
    end
    
    • The non-virtual Webex conference_link is then serialized as :non_virtual_conference_link on the hearing object in both the HearingSerializer and LegacyHearingSerializer.
  • Non-virtual Pexip hearings retrieve their conference_link through #daily_docket_conference_link on both the Hearing and LegacyHearing models.

    app/models/hearing.rb or app/models/legacy_hearing.rb
    
    def daily_docket_conference_link
      hearing_day.conference_link
    end
    
    • HearingDay#conference_link overrides the conference_link association and returns nil if scheduled_date_passed? or if the :pexip_conference_service feature toggle is disabled. Prior to HRT, an empty array was returned instead of nil.
    • The non-virtual Pexip conference_link is then serialized as :daily_docket_conference_link on the hearing object in both the HearingSerializer and LegacyHearingSerializer.
  • By serializing non-virtual conference links on the hearing object, the Hearing Details page is now able to display non-virtual conference links for both Webex and Pexip hearings. More information on hearing link location here.

  • HearingLinks.jsx is updated to conditionally render the conference link for a hearing based on its hearing type (virtual or non-virtual) and conference provider (Pexip or Webex).

    client/app/hearings/components/details/HearingLinks.jsx
    
    const getLinks = () => {
      if (scheduledForIsPast) {
        return null;
      } else if (isVirtual) {
        return virtualHearing;
      } else if (conferenceProvider === 'pexip') {
        return dailyDocketConferenceLink;
      } else if (conferenceProvider === 'webex') {
        return nonVirtualConferenceLink;
      }
    };
    

Hearing Link Location

Hearing Details

Prior to the implementation of HRT, the Hearing Links section of the Hearing Details page only displayed hearing links for virtual hearings. The newly enforced one-to-one relationship between a non-virtual hearing and its conference link enables the Hearing Details page to display hearing links across all hearing types, virtual and non-virtual.

The Hearing Links section displays three different links for each hearing:

  • Host Link: The link through which the VLJ joins the virtual or non-virtual hearing.
  • Co-Host Link: The link through which the hearing coordinator joins the virtual or non-virtual hearing. For Webex hearings, the co-host link is unique. For Pexip hearings, the co-host link and the host link are identical but displayed as separately to maintain consistency.
  • Guest Link: The link through which the appellant and/or their representative join the virtual hearing. For a non-virtual hearing at which the appellant would be physically present, the guest link may be used by the appellant's representative to join remotely.

Depending on the conference provider, Pexip or Webex, there are slight difference in how the links are displayed. For one, Pexip hearings require a pin.

Webex Hearing Links: Screenshot 2024-04-23 at 9 38 52 AM

Pexip Hearing Links: Screenshot 2024-04-23 at 9 39 05 AM

Daily Docket

Prior to HRT, Caseflow displayed the guest link for non-virtual hearings at the top of the Daily Docket page. After conference links for non-virtual hearings were moved to the Hearing Details page, the guest link section was removed from the Daily Docket – the intention being to reinforce consistent hearing link locations across all hearing types and conference providers. That being said, each hearing's row in the Daily Docket still contains a link through which the VLJ can connect to the conference.

Rollout Plan

Assignment of meeting type to a team member of the Hearings Management Organization group will be done at the discretion of an admin. Phase 1 and 2 are to be released together. An admin will ensure that the Webex feature toggle and Conference Selection feature toggle are enabled so that the selection of meeting type will be visible. Once every member has 'Webex' selected as their provider to schedule a hearing, the Pexip feature toggle and Conference Selection feature toggle can be disabled.

Clone this wiki locally