Do you ever get calls like this? “HELP! I can’t send images to PACS!” Or, “I can’t print films from the workstation!” Or, “I can’t save my patient exam to the server!” The device could be an endoscopy acquisition station or an EMG/EEG machine that is running in local mode because it cannot connect to the server. Maybe you have pulmonary function machines that should be saving studies on a network file share. Whatever the complaint may be, the underlying problem is the same: One networked device is unable to communicate with another networked device.

One answer for situations such as this is to turn the problem over to your IT department. The problem with that solution is that it may not be the most expedient way to help the customer, and it does not enhance your value as a biomed. It became clear to me early on that in a large institution with a sizeable and diverse IT department, transferring problems to IT was likely to mean this particular problem was not going to get resolved soon, and patient care would be affected negatively.

I started fielding these kinds of service calls about 15 years ago when my hospital acquired one of the very early computed radiography (CR) image readers. The reader would display digital images on remote workstations so the radiologists could interpret the exam quickly from CRTs instead of waiting for film to develop. Most of the communications between the reader and the workstations were over thick fiber optic cables. A short while later, the radiology department purchased a CR reader that communicated via Ethernet and used TCP/IP addressing protocol. That was when things got to be “fun.”

At that time, we had several workstations that were located on different floors and on different network subnets. The IT department was responsible for the network infrastructure such as switches, routers, and cabling. The radiology picture archiving and communication systems (PACS) was supported by a different group. I often received calls from radiology techs telling me they could not send images to another workstation where the images would be QCd before being routed to the PACS.

The support dividing line that worked best for our customers was that all imaging modalities and their associated analysis or QC workstations were supported by clinical engineering. Anything else, like PACS, was supported by another group. It was generally the responsibility of clinical engineering to determine where the fault lay. Collaboration with the appropriate support group was often necessary.

ADAPTING TO CHANGE

My Air Force training as a radar repair tech, my biomedical electronics degree, and my early years as a biomed repairing high-tech laboratory equipment did not prepare me for troubleshooting network communication failures. The answer for me was to learn as much as I could, as fast as I could, whenever the opportunity presented itself. I would work with the IT tech or the PACS tech assigned to look at the problem, and right from the first call we realized that we would need to work together to find the solution to the problem. I knew the components of the system and how they were supposed to work, while he/she knew the network protocols and infrastructure.

In addition, the IT or PACS tech had the tools to effectively troubleshoot the problem. Switches, routers, gateways, addresses? All I understood was that networks sounded like they were modeled after the US Postal Service. Houses had addresses and mail came from distribution centers, which kind of matched IP addressing and routers, but that is where the similarities seemed to end. The IT field is arguably more diverse and specialized than biomedical electronics, and I don’t believe that most biomeds would trade places with an IT specialist, as we generally like the hands-on aspect as well as the diversity of equipment that we work with. However, I do believe that most biomeds would benefit from a heavy dose of IT training. By that, I mean that we don’t need to become specialists in servers, routers, gateways, Windows OSs, or device security, but with some knowledge in all of these areas we become much more valuable. Customers would rather call a biomed to solve the problem because biomeds can gauge the urgency of the situation.

LEARNING A NEW WAY

In my experience, IT is not set up to respond the way that biomeds do; their response to a given problem is based on how many users are affected. Each group responds the way it does because that is what works for its customers. The level of response we apply, for either group, was established before the computerization and networking of medical equipment. Biomedical technicians are adaptable to changes in the way we operate and, therefore, are well able to bridge the gap between IT and medical equipment repair.

Medical devices are becoming more integrated, and users are asking for the ability to access electronic patient information from locations other than where the information is being created. Examples include x-ray systems getting worklists and then sending the images to either a PACS or a workstation for review and maybe a film printer.

Some facilities have a record keeping system in the operating rooms that record anesthesia data from all of the anesthesia machines, or patient monitors on multiple units that are connected to servers and connected to a master server that feeds patient data to an electronic medical record system. This communication most often means two or more devices will be connected by an Ethernet cable. Ethernet cable generally involves closets that house switches, routers, firewalls, servers, fiber optic cable, and converters. In addition to the device configuration issues of IP, Netmask, Gateway, and DNS addressing, there are domains, AE titles, host names, and possibly worklist functions and resource codes that can all get in the way of establishing the desired network traffic. A failure of any one of these components or a change to any of the configuration settings can cause communications to stop. Establishing communications between two devices or troubleshooting communication failures can be both time-consuming and frustrating for biomeds not generally trained in the IT world. However, your customers’ issues can frequently be resolved quickly if you have a general understanding of:

  • How the system is supposed to work;
  • What devices comprise the system;
  • What operating system is running on the problem device;
  • What tools are available to isolate the problem; and
  • How to check and view the device configuration.

Whether you are setting up a device for the first time or troubleshooting an established system, the investigative techniques are the same. The knowledge gained from checking any or all of the techniques listed below will enable you to either troubleshoot the problem yourself or communicate effectively with your IT staff so that they can resolve the issue.

Many of the networked devices use one of the Microsoft Windows operating systems. Of those, some may use a fully updated and patched version and others may use an embedded version of Windows that only resembles something like Win 95 – Win XP. These embedded operating systems may not support all the troubleshooting tools available in the full versions. Depending on the Windows version, you may be able to open a terminal session and use command tools such as ping, ipconfig, tracert, and netstat.

The ability to ping a device on the network is one of the most useful tools available, but at the same time you will find you cannot rely too heavily on the results of a ping test. The ping test is really just an “are you there?” question. Some devices won’t respond to a ping test due to the way they are configured or because the network interface card is not capable of responding. A positive ping test does not always tell you that the devices in question will talk to one another because other factors are involved. The vendor for the devices involved may be able to give you more information on this kind of test. Unix and Linux operating systems are also used, and each has its own set of tools for troubleshooting.

FIRST LOOK

In my experience, there are two main types of communications issues: No communication between two devices and intermittent communication. I have created a list of questions to ask when you suspect network problems after you have confirmed that all devices you are concerned with are turned on and appear to be functioning. It can be very helpful to know the physical location of every device, such as switches, firewalls, patch panels, and closets that are in the network path.

Below I have provided two different scenarios and a list of things to try. You will learn which ones work and in which order to try them from experience. Be careful of the assumptions you make when going through this troubleshooting process. When the results from one check do not seem to make sense, try something else that will confirm your previous results.

SYMPTOM: NO COMMUNICATION BETWEEN TWO DEVICES

  1. Check for communication to a third device. Can you ping or verify connectivity to anything else on your subnet from the device that appears to have the communication problem?
  2. Check for communication from a third device. Can you ping the problem device from a desktop PC, if possible, on that subnet? If not, can you then ping the problem device from anywhere?
  3. Can you ping the subnet gateway or the DNS servers from the problem device?
  4. Check the wall port for a link light with a network tool. You can make an inexpensive port checker with a D sub connector, a battery, and a transceiver.
  5. Try a different known good port wall connection on the same subnet.
  6. Can any other device communicate with the device you are trying to talk to?
  7. Have you checked/replaced the network cable to the wall? Are the connectors on either end of the cable damaged? Check inside the connector carefully; the contact wires can bend easily.
  8. Have you confirmed the network configuration for the host device?
  9. Are there any firewalls between the two devices? In large institutions we don’t always know what is out there. Find out who to call.
  10. Does either device have a host-based firewall? Is it configured to allow the traffic you want?
  11. Have you contacted the administrator for the device you are trying to communicate with to check for problems on that side?
  12. Did it ever work correctly? If so, did anything change?
  13. Has either device been moved recently? If so, trace the cabling to ensure that the connections are correct (cables plugged into the right ports).
  14. Does either device have multiple network interface cards (NIC)? Is the cable using the correct NIC?
  15. Know the limitations of your test equipment!

SYMPTOM: INTERMITTENT COMMUNICATION BETWEEN TWO DEVICES

  1. Have you checked/replaced the network cable to the wall port? Are the connectors damaged?
  2. Is there an IP or name conflict? Disconnect the network cable and go to another device and try to ping the first device. If it pings successfully, then some other device is using that IP.
  3. Can any other device communicate with the device you are trying to talk to without any problems?
  4. Have you tried a different NIC?
  5. Contact the network infrastructure support group for assistance. They will need to monitor the transmissions to look for any problems, such as too many collisions or a subnet that is too busy.
  6. Is it possible the device you are attempting to communicate with is busy with other devices, causing you to get preempted?
  7. Confirm that both devices as well as the network switches are configured for the same data transmission mode, half or full duplex or auto-negotiate, for example.
  8. Contact the vendor for assistance.

HOW TO GET THERE

Knowing how a device is configured for network communications and how to view that configuration is the first step toward understanding communication failures. I encourage you to work closely with your IT staff and use those collaborative opportunities to learn what and how they troubleshoot. The more knowledge you gain about network protocols, the more effective you will be in the troubleshooting process. Learning about the industry standard definitions for the layers in the protocol stack of the Open Standards Interconnection reference model and TCP/IP standards will also help. Training is available in community colleges, and there is a wealth of information in bookstores and on the Web. Learning the language used in the IT world is important to help you communicate effectively with your IT staff.

Do you have networking tips? Share them on the 24×7 blog.

Generally, the first call customers make when they have problems with patient care equipment is to the biomedical/clinical engineering department. Biomeds who know the IT side of medical equipment are in short supply but are proving to be great assets to clinical engineering departments. When biomeds have the ability to solve problems that have traditionally been turned over to IT they might notice a sense of relief from their IT staff when they find out they no longer need to respond to problems with patient care equipment! Any knowledge you can acquire regarding networking will help reduce your stress levels and enhance your career, as well as the reputation of your clinical engineering department.

Warren Heggen, CBET, AA, is the imaging supervisor of clinical engineering at the University of Washington Medical Center, Seattle. For more information, contact .