Building Your Own Remote Access

Manufacturers enjoy the benefits of remote service access. It makes it easier to satisfy customers. Increasingly, on-site service organizations are supporting high-end modalities that were traditionally left to the manufacturer, such as CT, MRI, nuclear medicine and laboratory analyzers. While many provide quality, cost-effective service, they are working at a disadvantage. It’s time to level the playing field by bringing remote access on-site.

It is possible to construct a remote access system (RAS) that will attach to practically any device with network capabilities — we’ll look at one design in this article. The technical part isn’t extraordinarily difficult, the operational benefits of the technology are appealing, but the politics — well, we’ll talk about that.

Choose your weapon
A remote access system (RAS) can be built on Windows or Linux (a type of Unix). Linux is a good choice for several reasons: it is less expensive; there is an abundance of free, well-organized online technical support; and Linux can be networked to a medical device without changing any of the files on that device. Either operating system will work. Choose what best suits your need.

We selected an old ‘486DX66 computer as the hardware, along with a used 28.8 kbps modem and a used network card ($5 at a flea market.) The hard drive was upgraded and a CD-ROM drive installed. The total cost, including a copy of Red Hat’s Linux 5.1, was approximately $200.

Linux was installed and configured, setting up the network card, placing the modem in auto answer mode and activating system security features. What’s missing? The RAS software. There isn’t any! This is another benefit of Linux; everything you need is already built into the operating system.

Assembled and configured, the RAS can be accessed by a PC using Windows HyperTerminal. Error logs can be reviewed and basic Unix diagnostics run without difficulty. We tested it with home PCs, and for maximum flexibility, it could work with a notebook computer dialing through a cellular modem.

Start to finish, this project took roughly 30 hours. Any technician who enjoys a challenge and is willing to put in a little self-study should be more than able to complete it. It does help to know some Unix. Local community colleges typically offer “Intro to Unix” classes, and attending such a class is a good investment, especially if your medical equipment is also Unix-based.

Applying the tool
Many medical device manufacturers install remote diagnostics. However, customers are typically not authorized to use them without paying steep licensing fees. The diagnostics are usually protected by security measures making access impossible. So what good is an RAS if you can’t run remote diagnostics? Error logs, a valuable troubleshooting tool. In most cases, errors generated by the medical device are appended to open, non-proprietary text files. These files can be viewed, searched, and organized using basic Unix commands, such as cat, cp, and grep.

Do not underestimate the power these error logs give you. If the service history of a device is carefully documented (i.e. problem, resolution and associated error codes), the error logs can be compared to that history to help diagnose a problem.

Unix has a variety of handy non-proprietary utilities. “Ping” is used to test network connections, and “dv” lists hard drives and how full they are, just to name two.

Your home-brew remote access system will improve your efficiency and reduce equipment down time. If a specialized technician is maintaining a modality across an entire health system, remote access is almost a necessity. The RAS also has non-technical benefits. Clinical staff and administrators find the idea of remote access very reassuring, and that strengthens your case for keeping service on-site. It’s a great project to illustrate the ingenuity, technical skill and professionalism of your organization.

Political reality
Consider this fair warning, manufacturers do not approve of remote access for on-site service. Their aggressiveness on the subject will vary. Many are civil. Others are downright ruthless, almost Borg-like. Expect some resistance. From the manufacturer’s point of view, once a non-proprietary RAS has proven functional, a major service contract edge is lost. It is in the manufacturer’s interest to discredit your on-site RAS.

The time has come for more on-site service organizations to enjoy the benefits of remote access. What are you waiting for? Dust off that old ‘486 computer you rescued from the dumpster and put it to good use!

Kevin Carpenter is a CT/MR Specialist at the Thomas Jefferson Health System in Philadelphia. Additional technical information and project notes are available online at http://user.erols.com/xrayeng. The author also welcomes e-mail questions at xrayeng@erols.com. Readers may visit the author’s demo RAS by dialing 215-952-5196. Login: Biomed; password: 24x7mag.