Enterprise Web portals balance security and accessibility

Extending access to radiology images and reports has always been a challenge. When PACS was first introduced in the early 1990s, it required costly dedicated workstations for viewing images and reports. Even radiology information systems, in use since the '70s, required a "dumb" terminal or terminal emulation software on a PC to view reports. These limitations prevented most clinicians outside the radiology department from reaping the benefits of digital imaging and reporting.

When the Web became popularized in 1995, a few companies saw the future and introduced systems that could take DICOM images, convert them to the common JPEG format, and distribute them along with the report text (when available) via the Web. This provided a huge boost to referring clinician access. Now everyone in the hospital could see that CT scan within seconds of its completion without having to trudge to a PACS workstation in radiology.

By the end of the '90s, even the "big iron" PACS vendors realized that having a Web interface to PACS was quickly becoming a necessity. Some Web distribution companies continued to develop a symbiotic relationship with the bigger PACS vendors, providing Web access to the archive when the PACS vendor could not. Because their client applications were lighter and could be installed on regular PCs, many RIS vendors did not see as great a need to "Webify" their applications. To this day, most RIS user interfaces are not Web-based.

Despite these advances, access ended at the limits of the hospital network in most cases. If your office was on the hospital's network, then you could see images and reports; if not, then you could not. You could forget about access from home or a remote office or another hospital. Further, hospitals realized that their networks had to be protected from hackers and viruses. They set up firewalls between their networks and the public Internet that prevented all access from the outside world, legitimate or not.

TRADITIONAL VPNs

Of course, the problem of remote access was not unique to radiology or even healthcare, and virtual private networks were created to address this issue. In most cases, a firewall only allows users within the hospital to request information from or initiate communication with the outside world, but not vice versa. This setup is like a pay phone that you can use to call anywhere but does not allow incoming calls.

The VPN appliance called a concentrator is the device that mediates traffic initiated from the outside world toward the hospital. Like any good sentry, it first requires that the user be authenticated via any combination of password, electronic certificate, USB key, and SecurID card (a small handheld device that displays a number that changes every minute). Once authenticated, the outside user's computer becomes connected to the hospital's internal network through a secure encrypted tunneling protocol, usually IP Security Protocol (IPSec). Once you're in, you're in. Your home computer now functions as if it were within the walls of the hospital, with all the benefits and restrictions of that network.

While plenty of systems within a hospital contain information that might be useful to a physician at home or in a remote office, historically the radiology department has driven the desire for remote access. A physician who wanted to know the latest potassium level for a patient, for example, could just call the laboratory to find out. This solution did not work with radiologic images.

Dr. Eliot Siegel of the Baltimore VA Medical Center jokes about this PACS downtime scenario: When the referring clinician calls to ask what the liver lesion looks like, the radiologist replies, "Picture a sunny day, with the sun just over the horizon, and the birds swooping down from the heavens . . ."

You get the idea-there's no substitute for seeing the images yourself. Furthermore, the radiologist shortage, which is easing but still present, and the increasing availability of teleradiology services contribute to the need for remote access to meet growing demand for radiology services. Remote access also increases opportunities for radiologists to confer with one another about difficult cases.

VPNs are powerful all-purpose tools, but they come with a price in terms of implementation and support. For most end users in a hospital environment, they are too powerful. Partners HealthCare in Boston manages information technology for Massachusetts General Hospital, Brigham and Women's Hospital, and eight other healthcare facilities/systems. Partners needs several full-time equivalent employees to maintain the VPN hardware and software, validate applications functioning through it, and deal with the constant influx of new users throughout the year. Installing VPN client software is never easy. Conflicts with other applications, antivirus software, personal firewalls, and home routers are common.

Some brands of VPN clients can't even coexist with others on the same computer. Any attempt to install a second VPN client can prevent your computer from starting Windows at all. To put it simply, VPNs often don't play well with each other or with other software on your computer. A physician who works at more than one hospital and seeks remote access to both from the same home computer may be out of luck.

Most VPNs are configured to give the user access to everything on the network, including network printers that are nowhere near you, and servers to which you can only cause harm. Such unnecessary access is a security risk, especially should access to a VPN account fall into the wrong hands.

Some hospital systems, such as Partners, implemented VPNs anyway because it was the only way to provide the needed access securely. Some decided to deploy applications such as the PACS Web server on the Internet, relying upon the authentication and encryption of the application itself for security. Others saw this approach as too risky but just didn't have the resources to handle a VPN, and they decided that remote access would have to wait until something better came along. Now, finally, that day has arrived.

FROM COMMERCE TO MEDICINE

The Secure Sockets Layer protocol has been around for over 10 years. People around the world use SSL for secure communication over the Web for credit card purchases and bank transactions. Rather than giving you full access to the bank's internal network, it allows you to access only your own account, and that access terminates when you close your Web browser or the session times out. It makes you prove who you are with a password and encrypts the information passing back and forth between you and the bank, but it requires no special software installation. The necessary components are already there in the Web browser, and they work for every bank and every merchant without conflicts.

Theoretically, SSL technology can be applied to every information server in the hospital, including the PACS Web viewer, the RIS Web viewer, the voice recognition Web interface, the HIS Web interface, the laboratory Web interface, and so on. But this requires each of these individual applications to employ SSL, and each of these servers must be put on the Internet for access, where they will basically serve as fresh meat for hackers and viruses (Figure 1). Hospitals, and indeed most large facilities, minimize the number of points of physical entry and exit for visitors and employees for security reasons. Likewise, it is better to maintain one point on the network for remote access and then deploy all of those applications through that point. Such a solution, called an SSL VPN, has recently become available (Figure 2) (http:/www.net-security.org/article.php?id=595).

A hospital using an SSL VPN can get secure authenticated access with no special software to deploy. In effect, the hospital can create a secure Web portal, a single point of access on the Web to reach the protected internal resources of the hospital. What a user initially sees may look something like Figure 3. At the discretion of the hospital's IS department, the user provides a combination of password and any of the other authentication methods described above. This process should require a relatively high level of security-more complex passwords and perhaps one of the other methods-because it is the main barrier standing between unwanted visitors and your hospital's internal information sources.

The user is then presented with a list of available applications and other resources such as network drives. In order to access the PACS, for example, the user will still have to provide a password for that application, but the process will be no different from that of a user sitting at a computer in the hospital.

One advantage of this approach is that the user has access to only those applications that are part of that individual's profile, and these can be set on a per user or per group basis. In a typical traditional VPN environment, all access is permitted except that which is explicitly denied. In an SSL VPN environment, all access is denied except that which is explicitly permitted. Traditional VPNs provide access at the network level, whereas SSL VPNs provide access at the application level, where it is much easier to manage. Unlike traditional VPNs, which either grant or deny access and then ignore the ensuing activity over the connection, SSL VPNs actually mediate the entire session.

To the PACS application, for example, the SSL VPN is just another user on the system; the PACS is unaware that the SSL VPN is actually serving as a proxy for a remote user. Thus, the PACS application needs no special modification to support this type of access. More important, it allows the SSL VPN to actively monitor and record every detail of every transaction.

There are three A's of network security. The first two, authentication and authorization, were discussed above. The mediation process provides the third one: audit. If a security breach is suspected, the SSL VPN has an audit trail that can trace the suspicious activity to help identify its source.

SIMPLE CONNECTIONS

PACS, HIS, RIS, and electronic medical record user interfaces range in complexity from simple Web-based designs to heavy CD-based installations that can be hard to configure and have poor tolerance for the comparatively low bandwidth of the Internet. Those that are purely Web-based can be easily deployed via an SSL VPN with "zero footprint." That is, not only does the connection itself not require the installation and configuration of a VPN client from a CD, but there's not even the smallest bit of special code to download or a cookie to store on your hard drive.

In effect, doctors can use a computer with the tightest security settings, which will not allow them to make the slightest modification to the system, and still be able to use the SSL VPN. Many Windows-based applications can be deployed in much the same way via a presentation server on the hospital side and a Web browser plug-in on the user side. Citrix Metaframe is one popular example of this technology. As with all SSL connections, your session ends when you close the browser. If you close down your Web browser after checking your bank account and then try to go back in, you'll find you have to log in again because your first session has ended. This is also the case with simple SSL VPN connections.

MANAGED CONNECTIONS

For applications that do not have a Web-based user interface and need to communicate over non-Web protocols, such as some 3D rendering packages, surgical planning software, and streaming videoconferencing, there is an extension of the SSL VPN idea. SSL tunneling allows these bulkier applications to conduct their non-Web protocol communications through a small software-based session manager that is downloaded the first time the user accesses the hospital's system.

Download of this applet does require some level of user permissions on the remote computer, but it's a small price to pay for the access it provides. The session manager keeps you connected even after you close your Web browser until you log out or your session expires. (An icon typically resides in the system tray in the right end of the taskbar to indicate your connection status.) Moreover, it acts as an adjunct to, rather than a substitute for, your regular connection to the Internet. If you start an application that needs to connect to one of the hospital's internal resources-the PACS archive, for example-the session manager takes notice and handles the connection. But if you are simply trying to browse a public Web site, it ignores your request and allows your regular Internet connection to handle it.

This is fundamentally different from the way traditional VPNs operate. Almost every user of a traditional VPN has at one time tried to print to a local networked printer and failed, forgetting that a user connected to a remote location via VPN is no longer on the local network. With a traditional VPN you are either "there" (on the hospital's network) when connected, or "here" (on your local home or office network) when not connected, but never both at the same time. With managed SSL tunneling sessions, in effect you can be both there and here at the same time.

SSL tunneling ultimately encapsulates all network traffic, regardless of the original protocol, into a Web protocol. This adds to security because network administrators need to monitor only one protocol: the Web protocol that everyone uses for most everything else. This function is similar to the single point of entry, except in this case it's a single type of entry.

PUTTING IT INTO ACTION

Partners HealthCare began providing widespread VPN access in 1999, and it has dealt with the expansion of the system to include hundreds of users. This has been a huge support burden, and the group began test deployment of an SSL VPN last year. It has met with measured success thus far, and the plan is to gradually convert most VPN users to this service over the next few years. The zero

footprint model will be deployed as much as possible. For situations in which thick client access over non-Web protocols is necessary, the managed session approach will be used. Traditional IPSec VPN access will remain, but only when direct access to the network is absolutely necessary, as for vendors who need direct access to the machines they support.

Staten Island University Hospital in New York City is taking a similar approach. The hospital has an IPSec VPN, but it is used only by vendors and technical support personnel. SIUH has already tested and validated its SSL VPN solution with the Web interface of its PACS and new RIS, which is inherently Web-based.

For hospitals that have been holding back on remote access because traditional VPNs seemed too difficult to manage, now is a great time to jump in with SSL VPNs.

Acknowledgments

The authors wish to acknowledge Christopher Gervais, senior research analyst/technologist at Partners HealthCare, and Bill Rears, director of PC LAN services at Staten Island University Hospital, for their valuable input to this article.