|
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:
Data
item |
Characters |
Cum |
Description |
label |
3
+ 1 = 4 |
4 |
INT
- page from interpreting |
cancel
/ confirm / stat |
4
+ 1 = 5 |
9 |
CAN
(for cancel), CONF (need confirmation) STAT (ignore any previous
call, not currently used) |
date
/ time |
12
+ 1 = 13 |
22 |
12/31
11:15A |
provider/caller |
20
+ 1 = 21 |
43 |
|
location |
20
+ 1 = 21 |
64 |
|
Room
No |
4
+ 1 = 5 |
69 |
|
language |
3
+ 1 = 4 |
73 |
first
3 chars |
Patient
Name |
20
+ 1 = 21 |
94 |
first
20 chars of "name,first" |
requestid |
14
= 14 |
108 |
|
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
|
|
|
|
|