How I Learned to Stop Worrying and Love Telecommuting

CareGroup CIO John Halamka takes an in-depth look at the policies and technologies necessary for supporting flexible work arrangements.

1 2 3 4 Page 2
Page 2 of 4

At the same time, security issues cannot be overstated, especially in healthcare. We do not want connected to our network a home computer running Windows 98 Second Edition that's infected with a keystroke logger. So we have to provide computers to remote workers. We decided to outfit them with thin client computing devices from HP, which provide a low-cost, self-contained computer without any moving parts—the hard drive has been replaced with Flash RAM. The devices, which cost about $300 apiece, do not allow users to do any configuration or install any software. They plug into a network just as a phone plugs into a wall. If a device fails, we issue another one. Our thin clients run only a Web browser and Citrix for applications such as Outlook and those few clinical systems that are not Web-based, such as our transplant system, cardiology systems and medical-record coding systems, so users can access all files and financial and clinical information via our intranet. At present we've deployed a dozen of these thin client devices, but we plan to deploy more in the future as we expand our flexible work arrangements.

To make sure that internal and external customers can easily get in touch with employees working from home, we worked with our telecom provider, Avaya, to forward calls from teleworkers' offices to their home phones.

Being a remote employee in 2008 requires full integration with the workflow of the company and access to all those applications and files that a person onsite would have.

One way to extend the office into a remote location is to extend the network. The use of secure socket layer (SSL) virtual private networks (VPNs), such as Juniper's SSLVPN, works extremely well and across platforms (Windows, Mac and Linux.) Our SSLVPN examines the remote computer, ensures the appropriate operating system patches and antivirus software are up to date, then enables the remote user to join our network via the public Internet. Our SSLVPN connects inside our firewall, but we have a secondary internal firewall in place so that SSLVPN traffic is further examined by our network intrusion detection and prevention systems before it gains access to our most secure resources.

Finally, remote collaborators need to be able to share files, no matter what the size. Juniper's SSLVPN enables corporate employees to access home and shared directories remotely. To support file sharing among collaborators in different companies, a secure file transfer appliance, such as that offered by Accellion, works very well. This appliance supports file transfers up to 2 gigabytes using Web technologies to place the file on a secure website and then e-mailing a user name and password to the collaborators who need to access it.

Remote desktop applications, such as the remote desktop functionality built into the Juniper SSLVPN, also enable remote users to access their office desktops and effectively use all the tools on their office computer from their home workstation.

In addition to these standard remote access methods, we may need new applications to support remote workflows. For example, our medical records coders need access to the paper medical record. Since shipping thousands of sheets of paper is a logistical nightmare and a security risk, we elected to digitize all our in-patient paper records and make them available securely via the Web. Specifically, we use EMC's Captiva software to scan each portion of the medical record, render it as a PDF, then upload it to a secure Web application for remote access.

In the next section, I discuss in detail specific communication, collaboration and presentation sharing tools that are both useful and necessary in supporting remote workers.


E-mail, ListServs and Instant Messaging

The most basic way to communicate remotely is via text sent among collaborators. There are many ways to do this synchronously and asynchronously.

For me, asynchronous text communication works best since I'm interacting with 40,000 Harvard and CareGroup customers 12 hours a day (CareGroup runs Beth Israel Deaconess Medical Center, and the Harvard Medical School teaches at Beth Israel). And since I find it challenging to speak in a meeting, listen attentively, keep my train of thought intact and text at the same time, e-mail is my preferred method of asynchronous communication. It has mature standards, cross-platform support and is interoperable across corporate networks, so there are few barriers to using it among collaborators. I live by BlackBerry, answering 700 e-mails a day using my 8320 over GSM/GPRS/EDGE and Wifi. I don't find the Treo, iPhone or any of the Windows mobile devices as efficient as the BlackBerry for high-volume e-mail management. (For a review of different Smartphones see, The Business-Savvy Smartphone Review.)

I use Entourage 2008 on OS X Leopard, and I am quite pleased with its functionality and stability. I use Outlook Web Access 2003 in Firefox, but am frustrated by its lack of a Gmail-like search feature. Finally, I have a Gmail account for family and personal correspondence, which works well with any browser on any operating system.

I also use listservs, both moderated and unmoderated, to send communication among large groups of collaborators. We've used listservs in IT for strategic planning, to discuss points that came up in in-person committee meetings, and to develop documentation as a group. Whenever I sign up for listservs, I always configure my account for "digest mode" so I get one e-mail per day summarizing all of the discussion threads. The chatter on listservs can be very annoying, so digest mode helps me manage the amount of e-mail I receive from the list.

As for synchronous messaging, many companies have developed an instant messaging (IM) culture for communications. Given its adoption by younger workers, IM is a major communication medium that modern CIOs cannot ignore. I certainly can't ignore it: My 14-year-old daughter and her friends use IM while reading, surfing the Web and talking on the phone.

When I started this pilot, I hadn't used IM much so I took a deep dive into the technology. I opened accounts with AOL Instant Messenger (AIM), GoogleTalk, MSN Messenger, Yahoo Messenger, Skype and even BlackBerry Messenger for real-time communication with my staff.

To me, effective chat needs to work across all platforms, so I tested all of these platforms with an Ubunu Linux laptop, a Macbook and a Dell OptiPlex 745 desktop running Windows XP. For Linux, I used the Pidgin open-source instant messaging application and the Skype client. For the Mac, I used iChat plus specific clients from MSN, Yahoo and Skype. For the Windows machine, I downloaded clients from AOL, MSN, Yahoo and Skype. For GoogleTalk, I used the Google Web client, which is part of Gmail, by using a Firefox browser on all three computers. I also tried, a web-based IM tool that works with all IM providers.

My first impression is that IM can be an effective communication tool for real-time, emergent situations, such as a server or application outage, for quick questions (when is the meeting?), and for brainstorming as a group. But my frustration with it is that I must use the same service as the person whom I want to message. Since my collaborators have accounts on different IM platforms, I must use all of them. Though some clients enable me to log in to multiple IM services simultaneously, I still need to create and remember the credentials for the accounts on all these services. There are emerging technologies such as OpenID that will simplify account management across IM providers in the future.

All of the IM services I tried support text. Some of these services support audio and video chat, but just about every audio/video experience I had was not cross-platform and did not work well on corporate networks, since many ports used by IM clients are blocked by firewalls and corporate intrusion prevention systems. Specifically, here's what I found:

  • AOL Instant Messaging (AIM). The Windows AIM client supports text, audio and video. Same with Mac iChat. Linux Pidgin supports text only. All use the proprietary OSCAR protocol. AIM audio worked fine between a Windows machine and my Mac. I could not get AIM video to work on my corporate networks. Why? Take a look at the instructions on AOL's website:
    If either you, or the person you want to Video IM with are behind a firewall and are having problems getting Video IM to operate, work with your Internet Service Provider, your company's system administrator or modify your firewall software yourself to open ports 1024 through 5000."

    It's highly unlikely that a corporate networking group is going to create a permissive firewall for ports 1024-5000 for AOL video support.

  • MSN. The Windows Messaging client supports text, audio and video. The Mac and Linux aMSN open-source applications support text and video. All use the proprietary MSNP protocol. I encountered the same problems with video on MSN as I did with AOL.
  • Google Talk. Google uses a hosted implementation of the industry standard Extensible Messaging and Presence Protocol (XMPP) and the extended Jingle protocol. It works with any standards-based chat client such as Trillian for Windows, iChat for Mac and Pidgin for Linux. It supports audio via a downloadable Google talk client for Windows and works with iChat for the Mac. No audio support is available for Linux.
  • Yahoo. The Windows Yahoo client supports text, audio and video. The Yahoo client for Macs supports text and video. Linux Pidgin only supports text. All use the proprietary Yahoo! Messenger Protocol. I found the same issues with video on Yahoo as I did with AOL and MSN.
  • Skype. The Windows and Mac Skype clients support text, audio and video. The Skype client for Linux only supports text and audio. All use the proprietary Skype protocol. Interestingly, video worked well, with no firewall issues between Windows and Mac Skype clients. Sound quality was irregular given the many uncontrollable quality of service issues on the Internet connection between my laptop, the Skype servers and my collaborators.

There are also several free, open-source IM clients available that support just about all IM providers:

  • Adium is an instant messaging application for Mac OS X, released under the GNU general public license, which makes it available to developers at no cost. With Adium, you can connect to any number of messaging accounts on any combination of supported messaging services and then chat using those services, which include AIM, MSN, Google Talk, Yahoo, Bonjour and MySpace IM.
  • Trillian Astra is the upcoming version of the Trillian instant messenger. It supports AIM, MSN, Google Talk, Yahoo, Bonjour and MySpace IM for Windows, Macs, and mobile platforms such as the iPhone.

Finally, there are Web-based services such as meebo, which do not require any software other than a Web-browser to connect to many IM service providers.

After trying all these services, my conclusion is that text works very well across all platforms as long as your collaborators are on the same IM service. If I have collaborators on Yahoo, MSN, AOL and Google, I need to establish accounts on every one of these services, install the clients for these services and check multiple different applications to determine if my collaborators are online. Audio is problematic across platforms and has very uneven quality. The poor sound quality is a function of many bandwidth bottlenecks from desktop to desktop via the Internet and the IM service provider. Even if video was available across platforms, it will still have the firewall issues I described above.

In sum, I recommend using e-mail and listservs for asynchronous communication and text-only IM for synchronous communication. If you need audio and/or video, stick with teleconferencing technologies, which I describe next.

Next: Audio and Video Teleconferencing

Technologies, cont.

Audio and Video Teleconferencing


Seven Quick Tips for Video Conferencing Beginners

Review: LifeSize, a Serious Enterprise Videoconferencing System

Viewsonic Monitor with Webcam: Not Ready for Its Close-Up

The Ferrari of Videoconferencing: TelePresence

Cisco TelePresence 3000: First Impressions

I'm a fan of audio teleconferencing. It works well, is low cost, and the technology is mature. I do not need an engineer to set up a teleconference, and I can use any mobile or landline phone I wish.

Using a local phone system to initiate a multiparty conversation works well for a small number of participants, generally about three. For a large group, numerous services are available such as Reservationless conferencing from Intercall or Ready Conference. "Free" conference calling (it's a toll call for participants) is available from and

Video conferencing is a bit more complicated. I evaluated the following technologies:

  • Windows: Polycom PVX software, using H323 and SIP teleconferencing protocols over IP.
  • Mac: Xmeeting, an open-source H323 and SIP teleconferencing tool, iChat via H264.
  • Ubuntu Linux
  • : Ekiga, an open-source H323 and SIP teleconferencing tool.

My first observation about video conferencing systems is that poor video can be tolerated, but audio must be nearly perfect for the technology to be useful. Polycom has figured that out and seems to preferentially use available bandwidth to ensure the quality of the audio.

1 2 3 4 Page 2
Page 2 of 4
7 secrets of successful remote IT teams