Treated Our Clients' Need for Remote Access Through
a Single Interface
by Kurt I. Munson and Michelle Frisque
We work at the Galter Health Sciences Library of
the Feinberg School of Medicine, Northwestern University,
located in downtown Chicago. The library serves the
medical school's faculty, staff, residents, students,
and alumni on campus and at six affiliated hospitals
throughout the metropolitan area, as well as affiliates
around the world and other users on the university's
Evanston, Ill., campus.
The Galter Library's vision is to be "anywhere the
user wants it to be." This means that access to the
library must extend beyond the building's walls through
its Web site, http://www.galter.northwestern.edu.
A resident on duty at a hospital cannot leave the building,
so at times she can't get to the physical library even
though she may be just across the street. Treating
patients requires information at the bedside, regardless
of the library's hours.
To aid our off-site patrons, we wanted to create
a system where a user logged in once and had access
to all of the library's electronic resources and online
services. Whether we wrote the code ourselves or used
commercially available products or open source software,
we were shooting for a single interface. We wanted
a system that not only authenticated users, but also
saved their personal information, allowed for customization,
and was easy for the user to update or change.
The system, known in-house as "online services," was
developed as different modules. In early 2000, members
of the information systems and the interlibrary loan
(ILL) departments, along with the head of user services,
started designing the user database and the ILL module.
Next, we added modules for desktop delivery, billing,
proxy server, and, finally, a customizable Web site.
These modules are explained in greater detail in the
We developed the user database first because it is
the system's backbone. The library staff determined
what user information we needed and created a table
in Microsoft Access to store it. Users input their
personal information through a Web-based form that
serves as the front end.
Authenticating and categorizing users presented a
number of challenges. First, we needed to identify
a data source that we could use for authentication.
Since the six hospitals are administratively separate
from the university, no single, all-inclusive data
source existed. Second, we needed a method of classifying
users' affiliations, since this determines which resources
and services they can access. Third, we wanted to keep
unaffiliated individuals from registering. Finally,
library staff wanted to automatically populate the
fields of our local records and minimize re-keying
Fortunately, the user tables of our integrated library
system, Endeavor's Voyager, proved to be excellent
medicine for our concerns. Since each patron receives
a unique bar code and a user category, we were able
to adapt these for authentication and classification.
Library staff can create user records on the fly in
Voyager, so we can easily add staff from the hospitals
along with others who do not have a university ID card.
For example, when a doctor registers, she enters
her last name and bar code into the preregistration
page on the library's Web site. A search is run against
the Voyager server. If her bar code is not found in
Voyager, a Web page would appear instructing her to
contact the library for assistance. If the doctor's
record is found, fields (including the registrant's
category) are copied to our local user database. So
when she registers, she can add additional personal
information, choose a specialty, set communication
preferences, enter a preferred e-mail address, and
set a password in the registration form. After clicking
the Register button, she instantly has access to all
of the library's resources and services. If she wants
to make changes in the future, she can update her information
simply by logging in and clicking on the "edit personal
Writing a Script
Early on, the library's information systems department
decided to use ColdFusion. We are running ColdFusion
MX on a Windows 2000 server. Currently the data is
stored in an Access database, but we are in the process
of migrating to an SQL server. The database houses
all of our user information, electronic resources,
user profiles, etc. We query the database using SQL
commands and display the information using the ColdFusion
Session variables are used to remember information
queried from the database that will be needed while
the user is logged into the system. If a user navigates
to a page that requires a login, the session variable
will redirect him to that page once he has signed on.
This facilitates a more seamless navigation from the
user's perspective. Session variables are also used
to time out people who forgot to log out. When patrons
log in, they have the option to save this personal
information so they do not have to type their username
and password every time they visit our Web site. The "save
We have also added a feature that allows users to easily
delete their cookies if they wish. We store users'
personal Ovid account information in our database if
they choose to have a personal account. This means
that logged-in users can access Ovid simply by clicking
on the Ovid link. Our system remembers their information
and automatically authenticates them into Ovid when
they start a session. This is one less password for
borrowers to remember.
Treating the ILL
We developed the interlibrary loan module first since
it was part of our plan to introduce paperless ILL.
This module consists of a form for users to submit
requests and a staff section for processing ILLs. Since
users frequently ask about the status of their ILL
requests, we designed the module to provide frequent
feedback. For example, when a student submits a request,
he will get a confirmation e-mail. A second e-mail
lets him know that the item has been received and is
available. The e-mails are tailored to the type of
item requested. E-mails for books differ from those
for journal articles. Users can check the status of
their requests at any time by logging in, clicking
the "check request status" button, and reviewing the
results. They can see when a request was submitted
to OCLC. (Users can click on the word "OCLC" to get
a description of that processing method.) We wanted
a process that was transparent to the user, yet informative.
We also wanted to avoid retyping data as much as
possible for both the staff and users. Saving login
information in the user table means that when someone
completes an ILL request, all she needs to do is enter
the citation information. This has proved very popular
with frequent ILL users, as has the "quick submit" function.
(This is where a borrower enters the PubMed ID number
from our primary database, MEDLINE, and all the fields
in the request form are populated automatically.)
We chose Prospero as the desktop delivery system
for ILL and implemented it in early 2001. In Prospero,
a user enters an e-mail address and a four-digit PIN
to retrieve ordered items. To avoid introducing additional
passwords or PINs, we wrote a script to strip the users'
e-mail addresses and online services passwords from
our user table and copy them into the Prospero user
file. Doing this allowed us to preserve our single
Making House Calls
One way we accomplished remote access was by making
sure our services are available through our Web site.
We also needed to make sure that our e-resources are
available from anywhere too. We did this by purchasing
and implementing EZproxy, a program that provides our
users with remote access to our Web-based licensed
databases. We configured EZproxy to use the authentication
process we currently had in place for all of our other
In addition to verifying login information, we have
created an application template that checks for the
user's IP address. If a borrower accesses our Web site
from an unrecognized IP address and the user type,
stored in the user table, is one of the types with
remote access privileges, we then create a proxy session.
If a user type is prohibited, the person will not be
able to access our resources. We export information
from the user table into EZproxy to make sure valid
users can have a single sign on for both services and
remote access. We also use information stored in our
electronic resources table to create the list of resources
we want to proxy. For the most part, this list requires
little human effort to function. We use a ColdFusion
script created locally to export the necessary information
and to format it according to the EZproxy specifications.
This script runs nightly as an automated task to ensure
that recently added resources will work in EZproxy.
Increasing the Dosage: The Health SmartLibrary
In 2003 we launched a new Web site called Health
SmartLibrary (HSL). This site incorporated all of the
existing services, as well as new tools for users to
customize and personalize their own online library.
To help users manage their information needs, we
created four tools:
- My E-Resources: a select list of e-journals,
e-books, databases, and
- My File Cabinet: a place to store
and organize favorite Web links
- Stay Current: a current journal literature
- Quick Search: a function that allows
the user to enter a search on the home page and
search a resource
When a user logs into HSL, My E-Resources, Stay Current,
and Quick Search are populated with preselected resources
derived from the specialty interest selected when he
first registered to use our Web site. Our librarians
created the profiles for each specialty by choosing
the best locally available electronic resources in
each discipline. Currently, we have more than 50 profiles
available for our users to choose from, and each specialty
profile contains six to 15 resources including databases,
journals, reference resources, and e-books. If a student
or resident does not like the resources associated
with his profile, he can easily customize each tool
and create his own personal profile.
HSL was built on the existing system. When users
register, we ask them to identify their respective
disciplines. The discipline determines an association
with a specialty profile. We continued to use ColdFusion
to do the majority of the work, but we also make the
rounds with other tools such as Perl, Cascading Style
HSL was made possible through information systems
02 from the National Library of Medicine. As part of this grant, we have created
a Web site to share the code and the database we used to create the HSL tools.
You can find it at http://www.hsl.northwestern.edu.
Maintaining the System
Now that we had a system in place, we needed to make
sure that only our valid users could access our resources.
(We work in an academic setting, after all.) Purging
users who are no longer affiliated with the university
is not as simple as we would like. We use Voyager to
populate the database, so it was only natural to use
Voyager to delete departing users. We use a script
with two facets. First, it checks Voyager for accounts
expired for more than 6 months and flags these accounts
in our local database for purging. We then check this
database for additional users who have not logged in
for more than 6 months and flag these records as well.
We send e-mails to the users marked for deletion, notifying
them that they will be purged in a month. The e-mail
tells them what to do if they feel that they have received
this message by mistake. Two weeks prior to the purge,
we rerun the script against those flagged users to
reassess their status. Users who still have not updated
their Voyager records or logged in will receive a final
e-mail warning them that they will be purged in 2 weeks.
When the time is up, we delete their record. We do
this every fall and spring.
Training and Assessment
Library staff at all of the service desks received
training on the different modules as each one was introduced.
The staff also tested the new modules prior to release.
Since the system was introduced more than 4 years
ago, it has become central to the provision of library
services. Management needed to ensure that the library
staff could use the system, explain it to users, and
troubleshoot their problems.1 So all new
staff members are trained on the system during orientation.
Two quizzes were developed and administered to ensure
that staff members could answer the most common types
of questions. New staff members completed the first
quiz as part of their 90-day evaluations, and current
staff completed the first quiz in a reference team
meeting. The second quiz is used after additional training
or as a refresher.
The system has become an increasingly important part
of our services. We conducted a number of studies to
determine if we were able to "keep it simple for the
users." Our assessments included usability tests, surveys,
focus groups, and a study of all system-related questions
asked at the reference desk in a year. We found that
27 percent of our reference questions involved the
system in some way. By analyzing the results of these
assessments, we were able to diagnose the most common
ailments, such as interruption of service on the publishers'
end, forgotten passwords, and confusing e-mail messages.
We have instituted changes to alleviate this suffering.
Surviving and Thriving
We have many enhancements we want to make to the
library's Web site. One request asked for further customization
of HSL: Users want to choose what to display and where.
They also want the ability to delete particular sections
from their personalized HSLs.
One thing we are working on is incorporating third-party
information into the HSL interface. We do this with
the "In the News" feature, which is created from an
RSS feed. We are experimenting with different RSS feeds
to see which one we like best. We are also working
with Doody Enterprises, Inc. to incorporate its book
reviews into our "Stay Current" section.
Keeping it simple for the users was key, as was setting
up a single login to everything. We developed a system
stitched together from homegrown code (ILL system),
commercial products (EZproxy), and open source software
(Prospero) that presents users with a single, uniform
interface. By making an interface easy for people to
use, we achieved our goalwe were able to dissolve
the blockages between services, resources, vendors,
and providers to create a remote service point that
is usable from everywhere the user needs it to be.
1. Munson, Kurt I. and Walton, Linda J. "Assessing
Reference Staff Competency in the Electronic Environment." Medical
Reference Services Quarterly, vol. 23, no. 2 (Summer
2004): pp. 3340.
I. Munson is the head of user services at the Galter
Health Sciences Library, Northwestern University in Chicago.
He holds an M.L.I.S. from the University of IllinoisUrbana-Champaign.
His e-mail address is kmunson@
northwestern.edu. Michelle Frisque is the head of information systems at the
Galter Health Sciences Library, Northwestern University in Chicago. She holds
an M.L.I.S. from the University of Pittsburgh. Her e-mail address is mfrisque@