Interpreter Dispatching

Business problem
Medical interpreter dispatching was handled separately for each of three hospital campuses. Centralizing the dispatching function would make it much more efficient, but was impossible without an automated tool that would provide an enterprise-wide view and allow dispatchers to quickly match interpreters with requests.

The environment
Across the enterprise, patients come from a wide variety of cultural backgrounds, and many need medical interpreters to ensure good quality care. With nearly three dozen languages spoken by patients, coordinating and dispatching interpreters to multiple hospitals and ambulatory clinics is a complicated task.

• Interpreting for the more common languages — Spanish, Portuguese, Haitian Creole, Vietnamese and a few more — are handled by staff interpreters.
• Less common languages are interpreted by contract interpreters via face to face, telephone, or video conferencing.
• Hospital interpreting requests generally cannot be scheduled in advance. When an interpreter is needed, hospital staff call the interpreter number and request an interpreter.
  • For the common languages, a staff interpreter is dispatched as soon as one is available.
  • For other languages, a contract interpreter is arranged, usually for a telephone session.
• Ambulatory clinics have a mix of scheduled and same-day appointments. Appointments scheduled in the Epic outpatient system are flagged when an interpreter is needed, and an automated feed pulls schedule data in near-real time.
  • Staff interpreters are based at some clinics for the more common languages.
  • Requests for other languages are handled by the central dispatchers.

Asynchronous communication
Much of the inefficiency of the old process was driven by the need for synchronous communication between dispatcher and interpreter:

• Interpreter called dispatcher to announce availability at start of shift, end of interpreting session, or end of break; and,
• Interpreter called dispatcher to obtain full details for each assignment.

The most efficient method of communication is via asynchronous communication such as e-mail or paging. Eliminating the need for dispatchers to speak with interpreters would make both groups of staff more efficient — especially the dispatchers.

Connecting with IVR
Interpreters no longer call a dispatcher to announce availability at start of shift, end of interpreting session, or end of break. Instead, they call a local extension which is answered by an IVR system. (Most IVR systems were much too expensive for this project, but we found a relatively inexpensive system from Plumvoice that met our needs.)

When an interpreter is available for assignment (beginning of shift, after a session is completed, or after a break), s/he calls the IVR number, inputs his/her ID number, and tells the system that s/he is available. This automatically updates the dispatching application database and the interpreter is either automatically assigned the next request or placed into the queue for the next assignment (see below).

Automated dispatching
The new dispatching process automates as much as possible. For the three most common languages at each hospital

• Spanish and Portuguese at all three hospitals,
• Haitian Creole at two hospitals, and
• Vietnamese at the third hospital,

interpreting requests are auto-assigned on a FIFO basis. The first request in the queue for one of these languages is automatically assigned to the first interpreter for that language to make him/herself available.

Interpreters are notified of all new assignments (not just the auto-assignments described above) via an automated message to their beeper through a secure paging system. When a request is assigned to an interpreter, the automated process sends a message (maximum 110-characters) with all relevant details about the appointment to the interpreter's pager. The message includes:

This streamlines the dispatching process by eliminating three steps in the process:

• the dispatcher manually paging the interpreter;
• the interpreter finding a phone and calling for details of the assignment; and,
• the dispatcher verbally giving details of the assignment to the interpreter.

Incoming requests
Interpreter requests are added to the queue in several ways:

• All current inpatients with a "medical care language" other than English (including unknown or null) are automatically added to the request queue at 5am daily.
• Any inpatient admission during the day with a medical care language other than English is automatically added to the request queue upon admission.
• In-hospital requests, and same-day clinic appointments for which there is no on-site staff interpreter available, are received via telephone and manually added to the queue by the dispatcher (see "Manual dispatching" below).
• Scheduled outpatient appointments for which an interpreter was requested from the Epic outpatient system.

Scheduled appointment list
All scheduled, outpatient appointments for which an interpreter was requested are automatically loaded into a separate list in the dispatching application from the Epic outpatient system (shown below). Dispatchers review these appointments in advance and assign them to interpreters as appropriate (it cannot be assumed that each appointment actually needs an interpreter).

[Click the partial image above to see a full size image]

Manual dispatching
Requests for less common languages (see above) are manually assigned by a dispatcher, using a new dispatching application. All interpreting requests for the day are shown in the dispatching screen (shown below).

• Unassigned requests are grouped by language and sorted by time.
• Language sections can be collapsed or expanded by clicking the language title.
• Unassigned/pending requests change background color as the appointment time approaches:
  • > 30 minutes in future = normal background color
  • 15-30 minutes in future = yellow background
  • < 15 minutes in future = red background
• Requests may be canceled at any time — before or after the request is assigned.

[Click the partial image above to see a full size image]

To add a new request, the dispatcher selects the "Add request" button in the toolbar at the top of the dispatching screen (see above) and the Dispatch window pops up (shown below).

• Depending on the site/language selected, the request may be auto-dispatched or the dispatcher may need to manually select an interpreter.
• If medical record number (MRN) is used to find a patient, a list of relevant account numbers is displayed so the details of the correct encounter can be selected.

Request confirmation
Scheduled, outpatient appointments with requests for less frequently-used languages are generally assigned in advance to part time/per diem interpreters, or to an agency. These requests must be accepted and confirmed by the interpreter before they can be considered dispatched.

Requests are given a "pending" status until the interpreter confirms that s/he will handle the assignment, at which time the status is changed to "confirmed." These requests are tracked with a Request Confirmation screen.

Interpreter status
The current status of all interpreters is shown in one list (shown below).

• Because most dispatched interpreting is for inpatients, interpreters are grouped by hospital, so it is easier for a dispatcher to see who may be available for a request at that hospital.
• When an interpreter for one of the major languages signs in via IVR and there is an auto-assign requests in the queue, the interpreter is automatically dispatched and their status is updated to "Assigned."
• In any other circumstance, when an interpreter signs in via IVR, their status is automatically updated to "Available."
• When an interpreter signs out via IVR, either for a break or at the end of their shift, their status is automatically updated to "Off."

[Click the partial image above to see a full size image]

Interpreter Profile
To ensure that a dispatcher can reach interpreters when needed, a profile is maintained for each interpreter. This profile displays all relevant information that might help a dispatcher select the correct interpreter and contact them quickly (shown below).

Documenting with IVR
For interpreters, the big impact of IVR is with documentation. Before IVR, an interpreter had to hunt for an available computer, log into the intranet, open the interpreter tracking application, and input the details of each interpreting session. This took a lot of time, especially finding an available computer.

With IVR, the process is much faster. The interpreter

• calls the IVR number,
• inputs their ID number,
• inputs the request number from their pager, and
• inputs the time arrived, started and ended for the session.

All other details about the session are already in the database, linked via the request number.

Outcomes

• Centralized dispatching allowed consolidation of dispatching staff and lower staff costs for the dispatching function.
• Centralized dispatching, together with other workflow changes, produced significant staff savings for the interpreter group.
• Documenting with the IVR was a major contributor to the interpreter staff savings.
• Automated dispatching, by thoroughly tracking all assignments, revealed that after-hours activity logging had been incomplete. With better data, the interpreter group can further refine staffing needs.
• It is expected that the new dispatching process will improve customer satisfaction with the interpreter function, as resources are better matched with demand.

Lessons learned

• Building an application to serve several groups of people with different opinions about how it should work can be challenging. We first tried to design a dispatching application two years earlier, and gave up when the group could not reach consensus. This time, under new management, the group reached consensus, then made some significant midcourse changes to the process, then reverted back to nearly the original design. This extended the development timeline.
• It is particularly challenging for people to design an application for a new workflow which they have never used. Centralized dispatching was dependent on the new application, so the dispatching staff had to design an application for a workflow they were only imagining. Under these circumstances, the design detour mentioned above was quite understandable.

Posted 25 August 2008