Keywords
Telephone - workflow - communication - organizational efficiency - VoIP
1. Background
Many researchers examine clinical workflows using one of two approaches [[1]]. One is direct visualization of clinical activities with human observers taking
notes as they watch clinicians go about their tasks [[2]–[9]]. The other is analysis of use patterns of pre-existing enterprise software such
as computerized physician order entry or nursing medication administration [[10]–[15]]. Both approaches have limitations. Manual observation is expensive, limiting data
collection to narrow pre-selected workflows. Analysis of a facility’s electronic medical
record environment necessarily reflects workflows from specific software and hardware
configurations rather than elective workflow choices made by clinicians.
Likewise, there are limited ways to identify clinical workflows at the scale of a
healthcare system with thousands of employees [[16]–[19]]. Answering the managerial question of how frontline nursing and patient care staff
spend their time is not easy [[20]–[25]]. This challenge becomes evident when hospitals embark on “Six Sigma” or “Lean”
re-engineering efforts and struggle to discover their current processes by asking
their employees to manually identify workflow inefficiencies [[26], [27]]. Instrumented workflow discovery tools such as RFID tagging and saccadic eye-movement
tracking have had limited success here [[28]–[30]].
2. Objectives
One promising workflow discovery assistance tool is computational analysis of electronic
log files recorded as a byproduct of using software for other tasks. Log files have
been used to analyze screen navigation, outlier events in laparoscopic surgery and
as targets for machine learning approaches to categorize clinical pathways [[12]–[14], [31]–[33]]. This paper focuses on the analysis of log files generated by making telephone
calls on a medical center’s communications server network.
Communication is intimately involved with clinical workflows [[34], [35]]. The adoption of “bring your own device” policies (allowing use of personal cell
phones and tablets) in many healthcare workplaces has increased awareness of communications
[[36]–[41]]. Identification of lapses in communication during “handoffs” has also generated
widespread interest [[42]–[49]]. Telephone calls are interesting to measure because they represent clinical tasks
in and of themselves and because these communications may serve as surrogate markers
for clinical activities which have no current electronic signature. Telephone calls
may also reflect rework when phone calls are placed to address failed processes. Of
note if there are frequent very short phone calls, the limited information transfers
within these short calls may allow identification of simple tasks which offer opportunities
for automation or process redesign, for example by replacing some calls with a workflow
engine or other communications technology [[50]–[52]].
The transition from public switched telephone circuits to voice over IP (VoIP) servers
which route internal enterprise calls over the enterprises’ IP (Internet protocol)
networks offers new ways to analyze clinical communications at an enterprise scale
[[53], [54]]. VoIP servers direct voice calls internal to the enterprise relying on the publicly-switched
telephone network only when calls leave enterprise sites. Multiple vendors offer enterprise
VoIP systems, often as part of a unified communications system [[55]]. While actual conversations are not routinely recorded for reasons of privacy and
storage costs, each call generates a call detail record (CDR) in a log file [[56], [57]].
This paper describes a framework for mapping telephone calls to clinical areas as
identified by cost-centers using CDR logs and then graphically displaying the high-volume
call patterns. The goal is to build a tool which can help clinical re-engineering
teams identify additional workflow inefficiencies beyond those recalled from memory
by showing the repetitive telephone calls clinicians use in their work. This software
can also be used for future work to measure the impact of resulting workflow redesigns.
3. Methods
3.1 Data Requirements
The two main types of data needed to perform IP telephony-based analysis of clinical
workflows are a set of call detail records (CDR) and information to map phone numbers
in those CDR’s to one or more identifiers of the specific clinical location or activity.
CDR log files are generated by the VoIP telephony or unified communications server.
Each record’s data fields include the phone numbers and IP addresses involved in the
calls, start and stop time stamps, call type classification such as a conference call
or a bridged call, and potential related information such as video conference data
[[56]].
Mapping phone numbers to the clinical environment requires local information. Directory
information should provide information allowing the phone numbers to be mapped to
clinical areas and tasks. The actual workflow analysis is performed on those phone
numbers which represent high call volume clinical areas with individual user data
computationally discarded. Phone numbers could, for example, represent nursing units,
labs, radiology, operating rooms or the emergency department. Enterprise phone numbers
may accumulate over the course of decades and hence span multiple technologies. Larger
institutions can reserve banks of phone numbers to map their phone to internal exchanges
allowing shorter numbers to be dialed (e.g. xxx-xx5–1234 is mapped to 5–1234). Additional
identification options to map clinical numbers include use of cost center codes and
use of Emergency Location Identification Number data which allows emergency responders
to pinpoint 911 over VoIP call locations within buildings. Lightweight Directory Access
Protocol (LDAP) files may help in providing site mapping of phone numbers.
3.2 Log file analysis
A convenience sample of one million consecutive call detail records from one academic
medical center’s Cisco Unified Communications Manager™ version 7.x instance was obtained
as a log file (424 KB in size) [[56], [57]]. The medical center’s information technology group, which administers enterprise
telephony, also provided a manually-maintained Excel™ spreadsheet mapping of phone
numbers which contained active numbers and a mapping to cost center codes. A separate
Excel™ spreadsheet crosswalk of cost center numbers (1004 in total) to the cost center
names was also provided. Use of pagers, personal cell phones and text messaging was
not measured. All data was transmitted and maintained using encrypted storage and
public key cryptography. The research protocol was reviewed by the Ohio State University
IRB who determined that the research did not involve human subjects and did not fall
under requirements for IRB review or exemption.
Software analyzing the call detail records and the telephone number mappings was programmed
using Perl version 5.16. [[58]] Modules to support in-memory debugging, persistence and calculations of memory
structure size were obtained from Perl’s CPAN.org (Data::Dumper, Storable and Devel::Size).
Perl hash functions were used to represent the major data structures as unique key:value
pairs. Programming was performed in Windows 7 and Centos Linux environments on a laptop
personal computer with an Intel Core i7 2.90 GHz CPU and 16 gigabytes of RAM.
Each phone call generated a 94 field comma separated value CDR. For workflow analysis,
each individual phone call’s data needed to be aggregated and indexed to the phone
number allowing collection of cumulative data about all calls between each realized
pair of internal phone numbers. These aggregated data structures also needed to support
the generation of a directed graph where phone numbers are nodes or vertices and phone
calls are arcs or edges.
To minimize memory use reading the log files, each CDR was read one at a time and
parsed into a hash structure temporarily holding the data fields. Selected fields
such as the number calling, the number called, and the duration of the call were then
saved into three core representations of the phone call traffic. These three hashes
had keys, respectively, of the number calling, the number called and a string combined
the number calling and the number called. These hashes stored the total duration of
calls, the number of successful and unsuccessful calls as defined by the metadata
definitions from the Cisco Unified Communications Manager technical manuals, information
about the calling device and, as described below, data about the clinical environment
[[56]]. The calling number hash also contained a nested hash with subkeys for each called
number and that subset’s call characteristics while correspondingly the called number
hash contained a nested hash with subkeys for each calling number. Having nested hashes
provides significant flexibility in structuring further analysis. Specifically having
symmetrically nested hash functions for both calling and called phone numbers allows
retracing all call patterns in either direction. The Perl language provides hashes
where each key has a unique value.
Functions to sort the calls by call counts were built to allow selection of high-volume
call patterns. Additional functions were built to capture aggregate statistics, time
stamps, and the volume of short duration phone calls. Major data structures were optimized
using Perl references which are pointers to locations in memory. Processing one million
calls with debugging code enabled required 6 minutes.
3.3 Building a graph representation
Intuitively, enterprise representations of phone traffic can be represented as network
graphs. With the growth of Facebook™ and LinkedIn™, social network analysis of graphical
data structures is increasing [[59]–[67]]. Network graphs can be transformed into matrices allowing for application of a
wide variety of computational descriptions of the information flows implicit in the
graph [[68]–[70]].
Graphs can be represented as matrices using an adjacency matrix. An adjacency matrix
representation of a graph of phone call patterns is a matrix A where calls from phone number i to phone number j can be summed as individual matrix element aij
. The nested hashes described above can be seen as sparse adjacency matrices where
only positive matrix elements are represented. Of note, since the direction of the
call, i.e. which number is calling and which number is called, is important in this
analysis, the graph representation of the data is directed. Correspondingly, the phone
call adjacency matrix is not symmetrical as it would be with an undirected graph.
In this visualization of the graph representations of the data, selected phone numbers
are represented as nodes while cumulative phone traffic in one direction is represented
as an arc (or arrow) pointing in one direction. For many pairs of phone numbers (nodes),
there were high volumes of phone calls in both directions so the graph representation
included arcs for both call directions. Building a unified graph representation consolidating
information from both the calling and called phone number data structures requires
making choices about how to combine each data structure’s call duration information.
3.4 Mapping clinical workflows
Mapping of enterprise phone numbers to clinical areas and by implication clinical
activities occurring in those areas depends on how an institution documents its organizational
structure. For this analysis phone numbers were identified by cost center. The cost
center mapping was programmed by cross-matching and merging a cost center file holding
the names and descriptions of clinical cost centers with an enterprise list of phone
numbers with their cost center identification into a hash where the phone numbers
served as keys. On reading each CDR, number lookup from this “phone directory” hash
was performed and the phone number’s cost center data incorporated into the calling,
called and call-pair number hashes.
Importantly, the granularity of the cost center data used allowed association of the
phone numbers with individual nursing units, operating room areas, and numerous other
specific departments and area of the medical center. To focus on clinical workflows,
only data from internal 5-digit extensions was carried forward eliminating outside
calls and internal server re-routed calls. Filtering and data cleansing of the historical
phone number assignment file were programmed using regular expressions.
3.5 Graphical display
For this academic medical center there were over 100,000 phone calls a day and approximately
30,000 unique phone numbers necessitating a strategy of examining only high volume
workflows. Gephi© was selected as the open-source visualization tool for the graph representation [[71]]. Traversing the hash structures described above, each phone number and its associated
clinical cost center was mapped into a node for Gephi while the call traffic between
the phone numbers and corresponding count data was mapped as a directed edge. Gephi
allows customizations to the display of nodes and edges to incorporate color mappings
and various weighting functions. Edge and node files written to Gephi were limited
to the 500 most frequent edges (sorted call pairs) for ease of visual inspection.
Filtering functions to select calls by cost center or call group were built.
Because the goal of this work was to display nodes that are meaningfully labeled and
edges which can be directly inspected, indirect graph analysis using tools such as
clustering, graph partitioning, community detection or spectral analysis was not performed.
4. Results
Summary statistics for all calls are listed in ►[Table 1]. Two findings are of note. First, the large volume of phone calls in this single
academic medical center and its affiliated clinics (with approximately 850 inpatient
beds at the time of this analysis) reflects a measurable labor investment in telephony.
Filtering results of the log file to select call traffic in the first 168 hours to
correspond to exactly one calendar week yielded 23,186 hours of call duration as measured
by server time for that week. Averaging over that week’s total of 912,386 calls yielded
an average call volume per day of 130,341 calls. Second, as noted in ►[Table 1], roughly half of the call pairs were short calls averaging 27 seconds length.
Table 1
Summary VoIP Call Statistics
|
Total VoIP calls
|
1,000,000
|
|
Successful calls[*]
|
898,316
|
|
Average duration of successful calls
|
101.54 seconds
|
|
Unique call pairs[**]
|
533,311
|
|
‘Short’ call pairs[**] with average call under 60 seconds
|
267,158
|
|
Average duration of ‘short’ call pairs
|
26.93 seconds
|
|
Total duration of call time for 1,000,000 calls
|
25,337 hours
|
|
Total duration of clock time to obtain the 1,000,000 calls
|
181 hours
|
|
Total call count in one week (7 calendar days, 168 consecutive hours)
|
912,386
|
|
Total duration of call time in one week (168 consecutive hours)
|
23,186 hours
|
* Successful calls are defined in CDR metadata as calls with duration over 1 second
** Call pair is a unique pair of number x calling number y
This framework capturing CDR data allows network displays aggregated by sets of cost
centers and numbers. ►[Figure 1] displays the overall high frequency call traffic for the top 500 call pairs. There
is one large internal node for voice mail as well as a number of other aggregations
most of which represent inpatient nursing units. ►[Figure 2] displays a drill-down into one representative inpatient nursing unit showing a high
volume of internal to the unit shared phones traffic between the unit clerks, nurses,
and patient care associates.
Fig. 1 Gephi© graphical network display of overall enterprise top 500 call pairs calls out of the
one million calls using the Fruchterman-Reingold force-directed layout algorithm.
The left column and margins of the Gephi screen show tools to select the layout algorithm
as well as to label the nodes (phone numbers) and edges (calls) with information such
as cost center name, call volume or duration. The large node in the right upper quadrant
represents voice mail and many of the smaller sub-networks correspond to large inpatient
nursing units. Here label display is turned off to show the overall structure of high-frequency
telephone traffic.
Fig. 2 Close-up of Gephi© screen capture of sorted high frequency calling patterns involving one representative
inpatient nursing unit cost center. Phone number nodes are labeled with their cost
center label and overall contribution to call volume while edges (calls between specific
phone numbers) are labeled with directional call counts. Other call detail record
data could be selected for display when writing the node and edge data files for import
into Gephi. This figure represents the type of display which would be generated and
shown to start manual discovery of clinical workflows in Lean or Six Sigma programs.
5. Discussion
5.1 Discussion
This paper describes design of a software stack to use internal VoIP telephone log
files to generate a graphical representation of enterprise medical center telephone
traffic labeled with clinical cost center information. The cost center label serves
as the proxy for who is making the call and the types of clinical activities which
may have been discussed during the telephone call. The actual topic of the conversation
is obviously not known since conversations were neither recorded nor analyzed.
The framework is designed to generate visual displays for exploratory data analysis
and to facilitate the manual recall of relevant common clinical workflows by medical
center staff engaged in workflow redesign. The author hypothesizes that graph display
can provide information not otherwise available to teams identifying clinical workflows
for redesign, for example as part of a “Six Sigma” or “Lean” process. While this framework
provides potentially new information to assist in analyzing clinical activities, the
mapping into actual clinical activities is entirely dependent on employee pattern
recognition and insight [[72]]. Given the re-engineering intent of the framework, only internal VoIP calls were
displayed graphically.
Summary statistics of the telephone traffic can help frame the clinical informatics
questions and opportunities. The amount of telephony work by employees is likely significantly
underestimated when measuring only the 23,186 hours of time per week spent on the
server. To the extent that that server time reflects an actual two-way conversation
rather than time spent on hold or in voice mail, employee call time totals should
be doubled. If one were to make the assumption that most time on the phone is spent
talking to another employee rather than leaving voicemail this data would suggest
up to approximately twice this time or ∼40,000 employee hours per week were spent
on the phone. However, the author was not able to parse time spent in actual conversation
from the log files. Importantly, we have no measures of additional time spent searching
for phone numbers or the time costs of related workflow interruptions for either party
over the average of the 130,341 calls per day [[48], [73]].
Short telephone calls (defined here as phone number pairs averaging calls under 60
seconds here 27 seconds on average) may represent a unique opportunity to redesign
workflows since the limited call span suggests that only one substantive fact is being
exchanged once one subtracts time required within the call for “overhead” such as
greetings, caller identification, and maybe patient identification. The author’s clinical
experience suggests many of these short calls are status requests or updates. The
class of short calls with limited data payloads may be particularly amenable to separate
automation or incorporation into EMR workflows.
The author and clinical colleagues are performing future research to use the framework
operationally. Early analysis of the data suggests many of the nursing unit calls
are related to patient requests for food or bathroom assistance when handled by patient
care associates and for pain relief and issues with intravenous lines when handled
by nurses. While this work looks at VoIP logs, EMR generated log files involving communication
or coordination tasks such as orders or nursing activities may also be represented
as hashed data structures and mapped into graphs. Other communication formats such
as RTLS (real time location services) and nurse call systems may be similarly mapped
into graphs.
5.2 Limitations
This is a single academic medical center study representing one VoIP server and telephone
network installation. This medical center provided mobile VoIP phones to many employees
so more data could be obtained from VoIP logs than in environments more reliant on
pagers or personal cell phones. Communications using pagers, email or cell phones
were not captured [[74]–[76]]. Building and analyzing the framework’s data structures requires correct interpretation
of the meaning of what is written out in each of the CDR data fields by the telecommunications
server [[56]]. Only one million sequential calls were analyzed. Analysis of larger call volumes
or analysis of call traffic by time of day may reveal different patterns of calling.
This project uses a pre-existing independent mapping of cost-center data to identify
clinical units at a high level of precision. Use of this approach at other institutions
would require some similar type of site-specific mapping of phone numbers to support
inference of clinical activities. Such mappings might be programmed using geo-spatial
localization data, LDAP files, other directories, mandated emergency call telephone
location files and or manual annotation as well as the cost-center information used
here. The granularity or number of clinical locations and implicitly potential clinical
activities can impact workflow insights.
The network graphs become too cluttered if low volume calls are represented. Significant
workflow insights may be lost when not examining this “long tail” of low volume information
[[77]].
6. Conclusions
Clinical institutions using VoIP communications can parse log files generated by internal
telephone calls to identify high-frequency telephone call patterns. Because the numerals
of the phone number alone do not typically carry information, this analysis requires
identification of a data source or process to allow electronical mapping of the telephone
number to a specific clinical area or activity within the enterprise. Assignment of
a phone number to a specific clinical area then facilitates manual inference about
common clinical activities occurring in that area and possible explanations for high
frequency telephone calls placed or received at that number.
By aggregating this individual call information into enterprise-wide data structures
indexed by calling number, called number and calling-called number pairs, cumulative
statistics can be generated. These hash-indexed data structures can also be used to
compute directed graphs where nodes or vertices represent phone numbers and edges
or arcs represent phone call traffic.
Analysis of one medical center’s VoIP log files suggests that medical care at large
clinical enterprises involves amounts of telephone time equivalent to hundreds of
FTE’s (full-time equivalent employees). A large subset of the phone calls were short,
averaging 27 seconds, with the intriguing possibility that these small and possibly
definable data payloads may be shifted from manual telephone calls to some form of
optimization or automation, for example, by providing new tools for status requests
and updates.
Graphical mapping of high-volume call patterns can offer insights into common clinical
activities which are labor-intensive, highly interruptive, and have limited or no
electronic signature in current clinical software. Visual analysis of telephone traffic
may serve as a starting point for “6 Sigma” and “Lean” re-engineering.
Clinical Relevance Statement
Clinical Relevance Statement
Healthcare system telephone calls represented a major time cost to one large academic
medical center with 130,341 phone calls per day. Clinical workflow re-engineering
targets for Lean and Six Sigma efforts are difficult to identify and providing a graphical
display of high-volume telephone traffic can serve as a visualization tool to assist
in workflow analysis. A large subset of calling number – called number phone call
pairs have an average duration of 27 seconds and the small data transfers implicit
in these short calls may serve as a separate automation or process redesign target.
Questions
1). Converting each entry in a telephone call log file into which of the following
data structures can best assist in cross-correlating information such as the calling
and called phone numbers?
-
an array
-
a hash
-
a union
-
a linked list
Answer: (B) a hash.
Indexing log file data is needed to allow cross-correlations and insights beyond summary
statistics. A hash is the data structure which performs key value pair indexing. The
individual entries are naturally already in an array as one reads the file but that
is not enough to build cross-correlations such as a graph network. Unions and linked
lists are basic data structures which were not needed for this analysis.
2). What type of adjunct data structure should be built or used to perform telephone
log file analysis?
-
a data dictionary
-
a time-stamping tool
-
a directory
-
a communications server
Answer: (C) a directory.
Phone numbers in the log file need to be mapped to some representation of the clinical
enterprise via a directory. In this paper the directory maps to cost centers rather
than individuals as with a classic “reverse” telephone directory where the phone number
is indexed to its human (or corporate) owner. It is important to understand the metadata
represented in a log file but this can be done without building a separate data dictionary.
The log files provide their own time stamps so a separate time-stamping tool is not
required though there will likely be code needed to analyze the temporal implications
of the data. A communications server overseeing the Voice over IP communications traffic
is what generates the log file and does not need to be built separately to do this
analysis.
