Barriers to Telemedicine Implementation
Usually it's not technology issues that undermine a project--it's
by Steven H. Stumpf, Rod R. Zalunardo and Robert J. Chen
April 2002 - Healthcare
Telemedicine has turned a
corner. The field experienced its first great surge in the 1990s with the
marriage of computers and telecommunications, but recently, applications
seem to have exploded regionally, nationally and globally. The number of
telemedicine project implementations in California has grown substantially
since 1998 as the state's private foundations and health organizations have
been increasingly willing to fund demonstrations and applications. For
example, the California Telehealth and Telemedicine Center alone has funded
more than 90 grants in the past four years. And the Kaiser Permanente system
has made a serious and continuing commitment (more than $1 billion) to
integrating telemedicine and telehealthcare--the largest U.S. healthcare
organization to do so.
"Bridging the digital divide" was originally the slogan for ensuring that
telemedicine crossed over from engineering and clinical laboratories to
community clinics. But the concept has expanded to include bringing up to
speed a provider community often perceived as reluctant to accommodate
telemedicine in routine practice.
Our group is a campus-based telemedicine systems deployment and
evaluation shop at the University of Southern California Keck School of
Medicine in Los Angeles and a grantee under the National Library of Medicine
Telemedicine Initiative. Our experience includes community clinics,
community health advocacy, funding organizations that support community
telemedicine projects and the implementation planning teams for such
projects. Since 1994, we have implemented six different telemedicine
projects at six distinct community sites. Our projects have included a four-way
international videoconference and transfer of images across an Internet
platform at many sites, including our own medical school.
Evaluation of telemedicine remains a fairly narrowly focused endeavor,
typically documenting satisfaction of providers and patients, frequency of
usage, and economic impact. However, a trend is emerging within reporting
that documents "everything else"--the nontechnology issues that are not so
easily quantified but present barriers to implementation.
Experience has taught us to expect a predictable set of barriers when
planning implementation of any telemedicine project, especially at community
sites. We have found that our experiences are not unusual--just undocumented--and
that the following axioms apply to all telemedicine project implementations:
For example, many telemedicine projects are implemented before a
feasibility study is conducted to anticipate and understand the barriers
likely to be encountered. The typical course of development in evaluating
telemedicine systems is considerably out of synch with how practice might
occur if barriers to implementation were better anticipated.
Typically, projects are implemented, then feasibility is considered,
policy is reviewed, and research is conducted. In contrast, the proper
sequence, which will become increasingly important as telemedicine
proliferates, is to begin with research, followed by feasibility studies and
implementation, with policy review occurring at the end of the path.
Solutions to technology problems for telemedicine and telehealthcare
projects are abundant and generic. Comparatively inexpensive, disposable
off-the-shelf applications can be integrated to meet most project needs.
Custom designed, proprietary and expensive solutions of the recent past are
practically obsolete. Engineers make careers of solving technology problems
routinely and quickly.
Solving the nontechnology problems facing telemedicine implementation
teams is more complex. The challenges are widely experienced as endless and
overwhelming. New systems implemented in old settings may require a
significant change in skills, the way business is conducted, and ordinary
routine, often generating resistance. The following are typical barriers,
accompanied by coping strategies that may tilt the odds in favor of
successful implementation, and some real-world vignettes.
Inadequate leadership: A project without a dedicated, local on-site
project coordinator will lack leadership. The project coordinator should be
a central resource with some understanding of all aspects of the project,
from technology to the needs of patients and healthcare workers, but should
not be the same person who called for the project. When the project
coordinator role is parsed among different staff--such as the business
manager, clinical coordinator, and consulting physician--the project will
struggle from the start.
Example 1. A local site did not hire a project coordinator
despite funds budgeted for the role. Project leadership defaulted in name to
the external evaluator, who held no influence within the medical group.
Responsibility for various tasks, from installation of on-site cable service
to coordination of patient flow, was divided among individuals. Although
they met monthly, none of them held management authority. The project
languished, falling eight months behind schedule.
Example 2. The project was presented to a core group of
community-based organization leaders who did not possess sophisticated
knowledge of telecommunications or telemedicine. Our technology assessment
called for significant equipment upgrades. The community organization
director authorized the installation of a DSL line and the purchase of
several new computers sufficient to manage the telemedicine system. A junior
manager was appointed to be our project contact but left abruptly without
notifying our technology team. The DSL line was installed in a different
building than originally identified. The community organization director,
upon learning of the mistake, questioned support for the installation and
the entire project.
Lack of physician buy-in: Local physician endorsement is an
absolute requirement of any healthcare project. A physician inside the local
group has to bring the project to the community and be a flag-bearer and
project advocate and champion. The physician champion lobbies the
stakeholders, sponsoring institution and other physicians. If a champion
cannot be identified or is insufficiently empowered to have an impact on
policy and procedures, the project will become orphaned, left to fend for
itself without sponsorship, and be at risk of cancellation.
Immediate and widespread implementation breakdown: Telemedicine
projects implemented prematurely and without a feasibility study can quickly
begin drifting in a sea of dashed expectations. Marketing promises for ease
of use and instant results often fail to deliver. Electronic medical records,
high-resolution digital images, faster bandwidth speeds, and processors that
easily and quickly handle multimedia programs create the perception that
telemedicine is a plug-and-play or point-and click-solution that can
overcome access to care barriers, especially within underserved communities.
Unfortunately, this is not the case.
Providers are hungry for simple solutions and implementation in community
sites, where the digital divide is often the widest. But startup must be
preceded by feasibility studies.
Example: A statewide project sought to install telemedicine
systems in mostly rural sites serving the most vulnerable populations. The
high-profile undertaking had support from a major foundation, a core of
external champions and a coordinating committee. The correct collaborative
partners were included and a set of initial implementation sites identified.
The system had been demonstrated as effective at a lower level of
technology, with certain limitations, under a well-documented feasibility
study by another group for a similar project. Differences for the proposed
project were judged to be minor and manageable. They included a different
version of supporting software, a different method of telemedicine delivery
(plain old telephone service vs. the Internet), and an expansion from one
site to ten. The new telemedicine equipment manufacturer also provided the
software, so that was assumed to be sufficient. And though clinical
coordination on a grander scale would be required, the project team believed
problems and solutions would be generalizable. Reality proved different.
Technology needs varied by site, with bandwidth an issue at some. The
email solution required an unanticipated modification in the new
manufacturer's software. Complications compounded quickly, with subsequent
loss of confidence on all fronts once it became clear that the vendor did
not have a true software engineer. Installations fell seven months behind
schedule, threatening the entire project. System feasibility became a
Unavailability of technical expertise or support: It is essential
to have an IT specialist on site to troubleshoot all the predictable
problems that arise with use of the equipment. In some cases, this person
will act as a local security officer.
In community sites especially, the level of technical knowledge among
staff varies greatly. The admonition "a little knowledge is a dangerous
thing" applies. Motivated staff often tamper with workstation settings,
disrupting access to applications. Others use computers for personal
interests, introducing viruses to the system or otherwise compromising the
project. Having someone on site who can quickly return workstations to
functional status is very beneficial.
Resistance to evaluation protocol: Evaluation is integral to all
project implementations. Funding sources are entitled to know project impact
and stakeholder value. However, evaluation experts often use familiar
methods perceived as burdensome to the end users--satisfaction surveys being
the most common, least informative and most intrusive. An evaluation
strategy that is likely to be viewed as helpful and embraced by users
gathers information that meets the needs of local interests, such as a
format assessing quality-of-care indicators.
Example: In the first site visit, the external evaluator
proposed that information be collected on patients not served by the new
telemedicine system, intended to demonstrate a need for continued funding
and subsequent expansion of the service. The local medical director did not
want to document failure to provide treatment or service, because that might
compromise the quality-of-care ranking, which would in turn potentially
threaten the medical group's services contracts. This basic conflict of
interests grew into a conflict of personalities, from which the project
Staff resistance to changing habits: The belief that one
implementation strategy will succeed across multiple sites can be fatal to a
project. Each site must be viewed as a unique system functioning according
to established patterns. Different clinical sites often exhibit similar
problems, but each responds differently and requires a separate approach.
The most common solution is individualized training that anticipates or
quickly responds to difficulties as they develop.
Example: An electronic patient record system implemented
across multiple sites ran afoul of staff members at one site who maintained
practices violating patient confidentiality that the system sought to
overcome. The evaluator cautiously wrote, "At best, the work discipline thus
entailed yields poor information security practices. At worst, staff
disregards or overrides the requirements for confidentiality and integrity
in their daily work. Achieving a thoughtful balance...requires training for
everyone (staff, patients and vendors) in sound security practices."
Some of the barriers we encountered were not as obvious and familiar as
those we've described. This shows that we have learned from our mistakes,
and systems integration and telemedicine implementations are becoming
smoother. Of course, our list of barriers is not exhaustive. Issues related
to streamlining data collection and adopting client-driven solutions that
get around our best-laid plans are central to managing change. But as we
encounter barriers to implementation--the old ones and new ones--we will
apply our model: Take small steps before big ones, and document mistakes to
devise better strategic solutions.
Steven H. Stumpf, Ed.D., is director of projects management; Rod R.
Zalunardo, Ed.D., is executive administrator; and Robert J. Chen, MHA, is
senior project manager; Advanced BioTelecommunications and BioInformatics
Center, University of Southern California Keck School of Medicine, Los