Tag Archives: gear

the man and the machine

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.

For many RTs, though, it’s a daily thing. I can think of two examples in particular, and they’re polar opposites: the spirometer, and the ventilator.

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 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 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.

Tagged , , , ,

equipment monkey

It’s all at once an amusement, a pain in the ass, and a blessed distraction to be one of the only direct-patient-care health professionals that keeps a toolbox in her office.

I feel a certain sense of pride and accomplishment when I’m walking down the hall past the ICU, packing a two pound crescent wrench, or a pair of pliers, or an assortment of screwdrivers and hex keys. I work in this normally sterile environment and here I am getting my hands dirty, hauling tanks, spinning nuts and bolts, tightening connections, taking apart malfunctioning equipment to fix it, replacing bulbs and batteries and sensors and analyzing cells. Some equipment is less dirty than others; tanks are by far the dirtiest job. Some equipment is bigger and heavier than others; the blood gas machine is by far the tiniest and most finicky.

On the other hand, being the only person in the building besides the biomed (and the one who keeps the more extensive hours) I end up being the one getting phone calls about “why is this leaking” or “this isn’t working and I need you to come take a look at it” for pretty much any piece of equipment I lay my hands on in my scope of practice. It becomes somewhat frustrating when I have people to deal with (people can’t lay broken on the counter for a month and then be fixed at my convenience) but at the same time I rely so much on the equipment in order to do my job that it becomes just part of the job to ensure that what I rely on is optimally tuned and ready to go.

At the same time, while it can be grating to get multiple phone calls to come fix a piece of equipment that can wait, it’s absolutely lovely during times of “office” drama to be able to disappear with my toolbox and let them all hash it out.

I think the tendency for us to be the fixers comes from several sources. There’s first, the fact that my entire job revolves around equipment. Oxygen equipment, pulse oximeters, the ventilator, suction equipment, intubation equipment, that damned blood gas analyzer, and on and on and on. Then there’s the fact that since so much of my job is equipment, a significant chunk of my training is troubleshooting equipment. When you’re keeping a patient alive with equipment, you’d better know how to troubleshoot when things start to go awry. (Significant in this training: “is it a problem with the equipment or a problem with the patient?”) Lastly, and this is just a loose theory, there seems to be this predilection towards mechanical inclination that’s common among RTs, and combined with all of the above, when there’s one of me and between two and twenty nurses watching me do my job, it becomes common knowledge among the healthcare team that I’m the one who just knows how to fix things. I imagine that’s how I get roped into performing a 3am-on-a-Saturday resuscitation on the printer, anyway.

With so much more equipment being software-controlled, there’s going to need to be an inclination towards computers moreso too, I think. Maybe not so much as the biomed needs, but it’s looking like it’s going to be more and more necessary to troubleshoot software problems as well as problems with the mechanics of it all.

All in all, though, I’m happy to be the one with the toolbox. And not only because when I’m resuscitating equipment, if my patient dies, with enough tools and time and parts and knowledge, I can pretty much always bring it back to life.

Tagged , , ,