Showing posts with label troubleshooting. Show all posts
Showing posts with label troubleshooting. Show all posts

Monday, July 26, 2010

Ounces of Caution, Pounds of Cure

When my car needs repairs for problems I can't identify, the strategy of starting off with the cheapest interventions makes sense. Why spend the money on the most costly intervention and risk unnecessary expenditures?

This approach to solving problems makes good sense, until you start talking about the car being your own body. Case in point, if you have a problem with your brain or heart whose origin you can't identify, do you want the doctor to throw the take-2-aspirins-and-call-me-in-the-morning strategy at the problem or the ER-stat-to-make-sure-it's-not-a-stroke-or-heart-attack strategy?

With the car problem, the main consideration reduces to the issue of cost-benefit. If the cheapest solution works, great, you haven't emptied your bank account to tackle it and the benefit is that your car continues to function. If your car is the most precious possession you own you may not choose to take the chance that the simple and cheap solution could end up doing long-term damage because it didn't address the underlying issues.

That's the kind of consideration that comes into play when your car is actually you and the problem is an unusual headache or atypical chest pain. No one wants to take the chance that the simple solution could overlook a serious problem. At least that's how modern health care thinks about it. Or so it seems.

Last Wednesday, I was in the instructional technology lab talking to the padawans when I became conscious of a dull pressure on the left side of my breast bone a couple ribs down, right over my heart. "Hm. A pain in my chest. That's strange."

Mentally I compared it to pain I developed 20 years ago when I was a graduate student in medical art. At that time—for the period of several months—whenever I sat slouched and then straightened up, my chest would feel tight in that same place. (Ignore the issue of slouching. I still do it.) If I arched my back, I could get the nitrogen that accumulated to release with a knuckle-cracking pop. But this felt different. I left a voicemail message for my wife and mentioned it to a colleague and the boss in case it should change too rapidly for me to mention later.

Sitting at the reference desk for an hour the discomfort seemed to disappear, but when I started walking around it seemed to return. After another 2 hours I decided to call my wife again and have someone drive me to the hospital. My wife works in benefits administration and urged me to call our primary care provider whom she was certain would have a walk-in EKG machine. As luck would have it, that afternoon was when the office, a teaching clinic, was off for rounds. The answering service operator insisted I go to the hospital. Off I went with my colleague driving.

The emergency room admitted me as soon as I walked in at 3:21 p.m. and hooked me up for an EKG. That and a blood test for enzymes that get released when the heart tissue dies that causes the pain of a heart attack both came back negative. Still, as a precaution, the attending physician admitted me for observation.

The question is if a car is running well and has always been well maintained, is comprehensive service justified? If I am a healthy male with low cholesterol and no history of heart trouble, was this course necessary? When your heart is potentially at risk, no one would recommend taking a chance; so in I went. My wife arrived to settle me into my room and said goodnight so she could get the kids home from our friend's house.

On hindsight, here is the kicker. The attending physician stopped in before the end of the evening. Chest pain that originates from the heart does not change with movement. Mine did. Likewise it cannot be replicated by manual pressure. Mine could. She speculated that my pain was musculoskeletal in origin. I must have strained my chest muscles or breastbone; although I could identify no specific, originating event. She said a stress test the next morning would likely confirm her hunch.

The stress test comprises an MRI scan with thallium dye in your coronary arteries—the arteries surrounding and feeding the heart. It’s done in 2 stages, the first after getting your heart rate elevated using a treadmill, then the second 2 hours later after resting. I did great. No evidence of narrowing of arteries that could have caused chest pain. I even impressed the cardiologist who observed that my heart rate at the same point on the treadmill as other patients was lower than average. That sounds pretty fit for someone who doesn’t do much exercising. Of course, you have to put that into perspective: I’m more fit than the average person being tested in the emergency room. Go ahead, laugh.

When all was said and done and my wife had picked me up to drive me home, I had a prescription for extra-strength Motrin to ease the ache and a full coronary workup at emergency room prices.

My question again: Was all that entirely necessary? With a few minutes of pre-screening by phone, a physician could easily have gauged my symptoms for the likelihood of a heart attack. I had no sweating connected with the pain. There was some dizziness, but not concurrent with the pain (plus this had already been happening for 2 weeks and seemed likely to be latent vertigo from a cruise I’d just returned from). The pain changed based on activity. I could recreate it by pressing on the spot where the pain originated. All of this was determinable through dialogue. In fact, apart from the EKG, the enzymes tests, and the stress test, the attending physician and cardiologist both determined this by talking to me, as obviated by their combined skepticism that my pain was heart-related, and 2 nurses, 1 physician assistant (educated at Arcadia University!), and 2 resident physicians surely also determined this though none of them actually articulated so.

To the comment that EVERYONE offered—it’s better to be safe than sorry—I must reply: That’s what medicine is about—risk assessment. I am low risk for heart attack and the verbalization of my symptoms plainly suggested I was not having one. Considering my risk, I could have gone into the doctor’s office to get a walk-in EKG. Yes, I have a family history of heart trouble (my dad had quadruple bypass surgery—at 81 years-of-age, non-emergency—and both parents have high blood pressure), but that’s information that’s already in my medical history. It would have been a fraction of the emergency room cost to have a preventive stress test done as part of routine screening.

Wiser medical, insurance, economic, political professionals will comment about my observations from a more informed perspective, but this event gave me a noteworthy personal connection to the health care debate.

Friday, May 21, 2010

Teaching How to Troubleshoot


Spring semester is over. I've turned in the grades for the graduate technology course I teach to school library certification students. The padawans are starting up summer project work.

There's one project we do annually for the Physical Therapy department. The PT students take 9 medical conditions for which quality of life can be improved with strength-building exercises. Here are some of the topics: End-stage Renal Disease, Cancer-related Fatigue, Fibromyalgia, Childhood Obesity, Down Syndrome, Juvenile Rheumatoid Arthritis. The PT students present current research and exercise strategies to 2 audiences respectively, professional and consumer.

The basic strategy is to videotape the speakers presenting off of paper notes. With accompanying PowerPoint slide durations timed simultaneously, we can then synchronize the slides to the speakers. Videotaping the speakers away from the project slide presentation allows us to avoid lighting problems. We then composite the videos together with the slide shows. I manage the instructional technology padawans from videotaping through to the video creation in Flash format. We post the videos for Arcadia University-affiliated clinical instructors to learn from and recommend to patients. We replace them every year with new presentations created by the next year's student class.

We just finished videotaping the presentations for 2010. We'll create the final 18 presentations throughout the summer. Every year we improve on the videos with more streamlined procedures, better quality, faster throughput. And every year we have to troubleshoot the new procedures.

In 2008, we composited the final presentations using QuickTime Pro. A related problem is that we had to use the videos with the exact original videotaped dimensions. QT Pro isn't flexible enough to zoom in or otherwise alter the video's appearance. For instance, if we didn't zoom in enough on presenters of smaller stature, we ended up with videos of mostly background. Also, if the video file sizes got too big, e.g., much larger than 1 Gb (or some 20 minutes of presentation), QT Pro was unable to process a final video image. We had to turn large .avi files into more modest .dv files or even smaller .mov files to be able to accomplish the compositing.

In 2009, we began using Final Cut Pro. Because our processing skills were so elementary, we synthesized clunky techniques through sophisticated software. More specifically, we turned PowerPoint presentations with timed slides into video files to composite with the speaker videos. Whenever we found timing errors, we had to program in the new slide durations in PowerPoint, create new slide videos, then composite them together again with the speaker videos. I won't go into how drop-frame time coding (a default setting in FCP that we didn't even learn about for another year) made those slide videos unpredictable in length thus further complicating the composition process.

This year, we finished videotaping on Monday and Wednesday and already had trouble that we didn't have last year simply downloading the video files from the digital camera's memory cards. The file formats are .mod. Last year we learned how to convert them to .mov files that FCP could handle. This year 25% of the files could not download without error messages.

Guessing that those files were unlikely to have been corrupted over the 2 days it took to bring them from the video site to computer lab, I guessed that the operating system on our iMac simply couldn't manage those few files. I wondered if Windows XP could do any better on a pc. And indeed it could; we downloaded the 4 troublesome files to a pc, transferred them to the server, then transferred those files to the iMac. No problem. Best of all, the downloads that took multiple hours to the iMac (alright, no doubt there are other issues with our OS) became file transfers lasting 15 minutes total. (Fine, if we worked at it, we could probably fix all the issues with the iMac, but why? This system worked fine and didn't make the process that much more difficult.)

My issue over these 3 years has been that I've been the sole person able to identify the problems and conceive of solutions. Sure I manage the lab, but I am not a computer superhero. I'm a reference librarian who has learned technology from padawans who have graduated and moved on, by experimentation, by googling effectively for solutions, and by standing back and considering the bigger issues. I suspected this year that the iMac's OS couldn't handle some otherwise perfectly decent video files. I considered another OS, albeit on a different platform. And then I tried out a hunch that worked out.

If I had left the file downloading to the padawans, they would never have completed the task. They might even have attempted to re-videotape the speakers with no guarantees the resultant files would have downloaded any more successfully.

If I have no fantastic technology skills, I often wonder whence comes any problem-solving abilities I have. Maybe fantastic technology skills come less from mastery of the technology and more from the ability simply to stand back and think, to see the picture from a little bigger perspective.

I talked through my entire thought process with the 2 padawans to help them think more. The challenge is to help them learn how to problem solve, too. Just.

Saturday, April 18, 2009

Handling Bad Assignments from Professors

(Twitter is failing me because I get no input box in which to tweet.)

One of our librarians distributed a web article she came across recently about bad library assignments professors make their students do (Collier). The article is from a second-year librarian. She comments about the difficulty of imagining approaching a faculty member to discuss the assignment. "What moxie!" She says.

I'm now a fourth-year librarian and in many ways I've forgotten about the challenge of approaching faculty. I think this is mostly because (I believe) I've both cultivated a strong relationship with my faculty and learned how to be diplomatic with phrasing concerns. It helps that despite being a fourth-year librarian, I've been in the work world for 20 years and have an easily approachable personality (I've been told!).

Last year I noticed the pattern of students from the same course searching for specific articles on genetic modification every year. The big problem was that the obvious keywords of gene modification weren't yielding good results. Couple that with the problem of the article having to be less than 3 years old and no one being permitted to use an article that someone else found.

I nipped the problem in the bud by immediately getting on the phone and asking the instructor for an opportunity to do a 15-minute instruction. What worked is that I knew the instructor and knew I could approach the subject tactfully by offering to come into the class. But even if I hadn't known the instructor, I'd still have made the call. Just another opportunity to connect with someone!

As students we see professors as paragons of intellect and wisdom that we must uphold with high regard and can approach only with temerity and humility. They are people, too, with their own personalities, weaknesses, and insecurities! So much can be accomplished by approaching them with due respect, tact, and empathy, but with candor.

Not to say there aren't profs who are full of themselves. At least at Arcadia University, I don't see much of them. There will be situations in which problems are irresolvable. Nobody wins all the time.

Works Cited
Collier, Ellie. "Stepping on Toes: The Delicate Art of Talking to Faculty about Questionable Assignments." In the Library with the Lead Pipe. 18 March 2009. 17 April 2009 <http://inthelibrarywiththeleadpipe.org/2009/stepping-on-toes-the-delicate-art-of-talking-to-faculty-about-questionable-assignments/>.

Friday, April 17, 2009

Troubleshooting technology

At Arcadia University, reference librarians work with instructional technologists in a unit within the Library Department called Instructional Technology and Library Research Services. The details of why this is and why it's a good idea are for another post. The significance is that besides being the Sciences Librarian, I'm also the student supervisor for instructional technology.

With final presentations fast arriving (it's Week 13 of 14), we're actively managing poster printing. These posters are the big ones you see at professional meetings that students have prepared based on their research.

The lab where the padawans work (read padawan as student apprentices--only the Sith have apprentices) is in the library physically. The large format printer is in Information Technology in a neighboring building. This makes life interesting because we have to monitor the progress of printing remotely. Although you can see from the printer window if a print job has failed, you don't necessarily know exactly why. So far the only causes I've known of are empty ink cartridges or a spent paper roll. I haven't known of more causes because this year is the first that I've done this supervision and, thus, been involved with the printing process.

One phenomenon that I did notice as we monitored printing remotely is that there are other users printing other projects that aren't posters. You can see them interspersed with the presentation poster print jobs we send.

Here's the lesson. It is important to get to know the relevant processes before giving full control to a padawan--or anyone else for that matter. After all, knowledge is power.

I'm sitting next to the printer now because there are no padawans on duty. Normally I'd be in the library but the printer report indicated that there was a failure. I could have called an IT student apprentice (they must be Sith over in IT) to check on the printer status, but I figured I'd just look myself.

What I found was a lab full of design students. My poster print job was failing because the design students were trading out paper rolls from poster paper to drawing vellum. I watched a student change the paper back but still had the poster print job I was handling fail twice more. I looked at the printer and noticed it querying for the user to load the paper even though she already had and had then left for the day. I removed the poster paper and reloaded it. Then I realized that she had never changed the printer's paper setting. She had changed the paper to poster paper, but the setting was still for vellum.

If I had been sitting in the library, I would never have realized that the other print jobs I was seeing in the queue could be contributing to failed print jobs. So now I know of 3 possible reasons why a print job can fail that I can notify the padawans to be aware of.