<%Response.charset="iso-8859-1"%>
Troubleshooting medical devices and systems is at the very core of what our jobs are in hospitals and field service. Most of us have developed a system over the course of our careers for troubleshooting that combines various techniques that we constantly need to upgrade. This becomes a problem during certification testing, because your troubleshooting method may be different from that of the person who wrote the question, which can alter sequences or even answers. Before we discuss troubleshooting, think about the following.
From day to day, the end user spends a lot more time with devices that are broken than we techs do. We can greatly reduce our repair time spent on broken devices if we understand what users are doing to the devices and what they expect from the devices. We have all spent hours on devices where our reports read, “Could not duplicate,” or “No problem found.” We mumble about brain-dead staff and send the unit back—only to get the device back with a “still broken” sign on it. We now have two problems: The device, and the user who now thinks we cannot fix the equipment, leaving everyone in a no-win situation.
The keys to troubleshooting are: 1) think simply; 2) look for the obvious; and 3) do not overcomplicate the problem. If you remember these three points, you should be able to answer most of the exam questions.
At some point in our careers we have all asked ourselves “what if,” followed quickly by “oops,” and then several words not allowed in this magazine. Hopefully, that scenario happens less and less as we become more experienced in this business. But we learned from those moments. If we do not learn from them, that is when we become dangerous and should consider politics as a career (they never seem to learn from their mistakes).
Over the years, many troubleshooting procedures have been taught, and all contain most of the steps that will be covered in this article.
Look!
Before you dive into fixing, look at the device/system and make sure that it is connected, not damaged, and properly applied/set up.
Reduce repair time spent on broken devices by understanding what users are doing to the devices and what they expect from the devices. |
Listen!
This is difficult for many people, but listen to the user describing what he or she perceives the problem to be. Also, listen to the device/system for sounds that should not be present but are, and sounds that should be present but are not.
Smell!
If you detect a burning smell, you know that the problem is heat-related. It could be a bad component, but more likely it is a dust buildup or a spill, and the problem is more likely in a high-voltage rather than a low-voltage area.
Power
Is the unit connected to the power source? Is that power source on? Is the fuse, breaker, pressure limit valve, or other limiting device defective? They all need to be checked.
Input
Is there an input coming to the device/component? Sometimes this can be difficult to determine because there may be multiple inputs and only one is missing. Check them all before moving on.
Output
Is there an output? Is the output correct? If there is a correct output, then there is no problem with the device/component. If there is an output but it is not correct, then it must be the processor (what the device does between the input and output). It could also be a problem with a missing input or a power supply, but you should have checked those before you reached this point.
Processor
If the output is not correct but the input is, the processor is probably the problem—unless there is a software problem, which can be difficult to find and correct.
Software
This is the black hole that covers everything that is not obvious, detectable, and correctable using our normal tools and skills. Many times we have to go to the vendors to get upgrades on the software, and there is a fee for that.
Network
This is the latest addition to the troubleshooting sequence, and a source of many problems. In recent articles we have seen that IT departments have changed IP addresses and forgotten to tell us, so devices fail to communicate. We have seen devices not being backed up because IP addresses were changed and the command never got to the device, or the network is running slow. As more devices are networked, we will have more problems to solve, which means that we will need to sharpen our skills in the networking areas.
I am sure you have additional steps that you use from time to time in troubleshooting, because not one method fits all events. But we know that, and adapt as we go. Over the years I have seen and heard of many techs who are great at hands-on troubleshooting but have difficulty with written questions. The key to doing well on a test is to read the question completely, look for the obvious, and think in simple terms. In some cases, the answer to the question is in the question, so look carefully. After you read the question, visualize the problem, because you probably have seen the device and problem in your work. Then look at the answers and select the correct response. Remember that trick questions and questions on obscure devices or systems are not part of the exam. The problems presented are common ones that you can handle. Remember: Think simply, look for the obvious, and do not overcomplicate the problem/question, and you will do fine.
David Harrington, PhD, is director of staff development and training at Technology in Medicine (TiM), Holliston, Mass, and is a member of 24×7‘s editorial advisory board. Contributing to this article is Trever Tiller, a BMET with TiM, Richmond, Va. For more information, contact .