Gear comes up so often as an RT that a day where I don’t do at least some troubleshooting is a boring day indeed. Where most of the other equipment other team members deal with are either ways of gathering patient data (lab analyzers, patient monitors) or ways of giving drugs to the patient (IV pumps), there are relatively few situations where the patient is directly interfacing with the machine in question. It is, after all, somewhat frowned upon for patients to adjust their monitor alarms or change their IV rate.
Spirometry is a difficult test to do sometimes, as it’s almost 100% effort dependent on the part of the patient. This is in contrast with blood analysis by the lab, where the major difficulty regarding the patient is whether or not you can get blood out of the person. (Sometimes it takes the lab tech who can get blood from a stone. Sometimes it takes four strong staff and five point restraints.) The most accurate results will only happen when a patient can understand my instructions, will cooperate and follow my directions, and when they try as hard as they possibly can.
They emphasize to us in school how important it is for us to coach the patient enthusiastically, since a major portion of getting the best effort out of someone is coaching them to try their hardest. It’s not uncommon for me to look at a patient’s results on the screen or watch a patient blow and go, “you can do better than that.”
Then there’s the interface itself: I’m trying to make a person do a very specific thing to a machine, and if I can’t make that person do what I need them to do, the test is nearly useless. This is a classic example of troubleshooting the patient. I made sure at the beginning of the testing day that my machine is working correctly, so unless something catastrophically fails, the problem is almost universally one with the patient. It’s my job to look at the output the machine displays, and try and explain to the patient I’m testing what I need them to do differently in order to get the output I want. This includes noticing things like air escaping the system at the mouthpiece (and therefore not being measured,) a lack of effort on the part of the patient (meaning the results appear as if the patient has terrible lung funtion to the untrained eye,) or some things the patient has no control over, like whether their dentures are loose, whether that stroke they had five years ago means they can’t make a mouth seal at the mouthpiece, whether they can’t understand what I’m saying but are smiling and nodding anyway, or whether they’re just not going to put the effort in and I’m wasting my time trying to teach a pig to sing.
I can’t stare only at the machine and ignore the patient: the forced exhalation maneuver can cause a transient decrease in blood pressure and a transient slowing of the heart rate, especially towards the end of exhalation, where the patient is forcing against airways that are empty of air and for the most part, closed. In this way it resembles a valsalva maneuver and I need to pay attention to my patient, because if they faint and fall off the chair and bounce their skull off the concrete floor, well, I have a bigger problem than poor test results. If I don’t notice that air is leaking out the side of the patient’s mouth, I’m gonna have a really hard time figuring out why I can’t get decent results. At the same time, I can’t only stare at the patient and ignore the machine. The whole trick to the success of the test is ensuring that the patient is interfacing properly with the machine. Ignoring the machine is to ignore half of the system.
The other major example I have, the ventilator, is somewhat the opposite sort of system. In this case, the patient is often, but not always, passive (rather than with the spirometer, where the machine is passive.) With the ventilator, I’m trying to make the machine do this very specific thing, and if I can’t get the machine to do what I need it to do, then I’ve got some serious problems. The confounding extra factor, for bonus fun, is that sometimes the patient isn’t passive. Sometimes, I’ve got this machine that’s supposed to be breathing for a patient that’s trying to breathe, and a major limitation to this is that they don’t share a brain (though they’re working on that.) Sometimes the patient’s trying to breathe and the machine is trying to breathe and they end up fighting each other, or what some people call “the patient fighting the ventilator.” The term we prefer to use is ‘patient-ventilator dyssynchrony’ or, more colloquially, “hypo-sedation-emia.”
In an ideal world, the patient would initiate a breath and the ventilator would detect this and deliver a breath in synchrony with the patient’s efforts. This is called ‘triggering’ the breath. Then, when the patient is done inhaling, the ventilator can also detect this and, depending on the mode of ventilation, can stop delivering the breath near the same time the patient stops inhaling. This is called ‘cycling’ the breath.
Being as, from a gas flow physics standpoint, the sensors that make these detections are a considerable distance from the patient, sometimes the ventilator isn’t able to detect what the patient wants the ventilator to do. Accordingly, the ventilator is more likely to have a harder time the sicker you are and the worse your lungs are. The ventilator is, after all, a machine, and one of the major downfalls of machines is they don’t think, they only do what we program them to do. Sometimes we can program them with complex algorithms designed to eliminate some of the thinking, but that does not obviate the need to think.
This is where I come in. I observe both the machine and the patient and try to tweak what variables I can tweak in order to get the machine and the patient to agree with each other. I try and see what the patient is trying to do and try and manipulate the variables I have to try and make the vent do what the patient is trying to get it to do. It’s a magical sort of alchemy, and sometimes I can’t make it work. Most of the time, though, I can manage to find the sweet spot between the totally passive patient who “rides” the ventilator and the dyspneic, agitated, desaturating, magical self-extubating patient.
The opposite is also true: sometimes the patient is so sick and so short of breath that they consume so much oxygen trying to breathe (and doing so only ineffectively) that they’re better off anaesthetized so I can take over and make the patient’s lungs do what I want them to do so they get some actual gas exchange going and they can get better.
The trend with new ventilator modes is to try and make it so the machine can adjust itself continually according to what the patient appears to ‘want’ according to a software algorithm. This seems like a good idea in theory, and it can work pretty good for some patients, but us RTs tend to hate these newfangled modes for one reason and one reason only: we can’t tweak them. “I can’t make the stupid thing do what I want it to do” is what we think, trying to find that sweet spot. I can see what the patient is trying to get the vent to do and the software algorithm can’t.
It’s alchemy, it’s guesswork, it’s “let’s try this and see how that works”, it’s tweaking and a process of elimination. Half the time the process is a series of judgement calls and failed experiments until something works.
I’m the respiratory therapist, and when I troubleshoot a system, it’s got both a machine and a person in it, and I have to troubleshoot them both at the same time. It leads to a unique set of skills and challenges, and I don’t even think these systems are unique to my profession. I think these systems are visible in many disciplines where people interact with machines. I think most of us are just not used to seeing the person as a part of the system.