Category Archives: Procedures

“The Water is Turned Off…”

Posted on by
3

“,,, so you won’t be able to flush or wash your hands until I turn it back on,” the nurse said. I understood why, but honestly, the sound of some rushing water might have helped with the task at hand: filling a specimen bottle with at least 40 ml of urine.

I had forgotten until a few minutes earlier when she had mentioned it, that a urinalysis was required as part of the intake process. I’m generally against drug tests for most jobs as I think they’re irrelevant and don’t necessarily have a bearing on the candidates ability to do the job. It’s part of the reason I actually ended up in consulting right out of college. The software company I could have basically walked into a job with had been acquired and now required drug testing. Now, I was not at the time taking drugs and have actually never taken illegal drugs, not even any form of cannabis when it’s been offered. So it was never a fear of being caught. It was simply a resistance to what I feel is an unwarranted invasion of privacy for a tasking involving sitting in front of a computer and creating code.

But this job is different. This job involves both being directly involved in the health care of others and it involves being exposed to drugs. I feel it’s a reasonable compromise. So there I was being handed a sealed specimen bottle standing in a bathroom. Outside all my items, phone, keys, pen, etc. were locked in a cabinet, I’m assuming to ensure I couldn’t sneak in any clean samples. She walked out and I gave deep thoughts of places like Niagara Falls. Fortunately it worked. Less than a minute later I was handing this woman I had met only 20 minutes earlier a warm specimen bottle full of my pee.

Protocols

She had with her a kit that included another container of sorts. She opened it and the specimen bottle. I started to leave the bathroom and she told me I had to stay “since I have an open specimen bottle”. I realized in this case, unlike the lack of running water to keep me from cheating, this was most likely to make sure there was a witness to prevent her from tampering with the sample.

Once it was transferred and sealed in the new container we left together and she started filling out some forms on the computer screen while we waited for the urine to travel up the test strips and react with the reagents. Think about how the Covid test trips we’re all familiar with work, a Control line and before that a Test line (the Control being after to of course ensure the sample has travelled past the test). This container had 3 strips built in so I asked about them. The 3rd one actually had 4 tests on it, but she said she ignored one. I asked why. It turns out it was for THC, since it was no longer banned in New York. So, I suppose I could take up pot if I wanted to. But I have no interest. I also had fortunately not eaten any poppy seed bagels recently!

After all the strips all reacted she moved it to the edge of the counter and rang a bell. She explained she needed a second witness to sign off on the sample. In this case I assume it was to ensure I wasn’t bribing her to pass my sample. Not 2 seconds later we both hear a rather loud, “GOT IT!” from down the hall and up walked another nurse. She saw our somewhat surprised faces and admitted, “I love doing that.” I joked in return that I had apparently passed my audio test (which strangely enough is about the only thing they didn’t test yesterday!)

The Rest of the Afternoon

I’m not ready to call that the highlight of the day, but it was just one part of that day’s intake process. I also managed to get a flu shot, the first step of 2 TB skin tests, scheduled for a Tdap vaccination (in addition to hopefully at the community college getting my Covid Bivalent booster this week), the second of the 2 TB skin tests, get fingerprinted, get entered into the HR system, fitted for an N95 mask, and start the paperwork on parking.

I had arrived around 1:00 PM (a bit early for my 1:15 scheduled appointment with the health center) and was done with all of the above by about 3:15 PM. Not too bad. There was some waiting, but overall a rather expedient process.

N95 Mask Fiitting

This was one thing I wasn’t familiar with before yesterday. I knew the general principal: make sure the mask is tight and the nose bridge is well-formed to your face. However the fitting process is actually a bit more complex. I did find out after arriving that if I had wanted to keep my beard, they have a a PAPR and I could have been fitted for that. But honestly, I figured it was time to get rid of the Covid Beard for a bit so had shaved the day before.

The actual fitting is interesting because the mask they give you is hooked up to a machine with two tubes, I’m presuming to measure air inflow and out. You put on the mask, fit it to your face and then, as the machine instructs do a series of exercises, including bending over for 30 seconds and breathing, loudly reading some text, turning your head side to side and then up and down. Apparently my initial attempts at fitting weren’t quite right so the fitter came around to my side of the bench and moved the masked down and adjusted the nose piece a bit. She explained after why. So now when I’m wearing an N95 mask, I’ll have to remember to place it a bit lower than I thought was proper. I was also instructed to refuse an assignment if the type of mask I was fitted with was not available. So for those who are geeky enough to care, my mask type is a 3M 8210 Reg – White. I even have a sticker to put on the back of my ID badge once I receive it.

Beardless Again

Next Steps

So, Wednesday I go back to have the TB test checked and then next Monday go back again for the TDap booster, another TB Test, and I think the first of two shots for my Hep B regiment and then back next Wednesday for the final TB check. Then on the 17th I start actual orientation at 8:00 AM. (due to orientation it looks like I will be missing an A&P lab and two A&P lectures unfortunately). Finally, I think my actual start date on the ED floor will be October 25th. I can’t wait!

Call 911, If You Can

Posted on by
Reply

Also known as “things have changed”

For one my of clients I monitor and maintain some of the jobs that run on their various servers. One of them had started to fail about two weeks ago. The goal of the job was basically to download a file from one server, transfer it to another and upload it.  Easy-peasy. However, sometimes the job fails because there’s no file to transfer (which really shouldn’t be a failure, but just a warning).  So, despite the fact that it had failed multiple days in a row, I hadn’t looked at it. And of course no one was complaining (though that’s not always a good reason to ignore a job failure!)

So yesterday I took a look and realized the error message was in fact incorrect. It wasn’t failing because of a lack of a new file, but because it could no longer log into the primary server. A quick test showed the password had been changed. This didn’t really surprise me as this client is going through and updating a number of accounts and passwords. This was simply obviously one and we had missed this one. (Yes, this is where better documentation would obviously be a good idea.  We’re working on that.)

So, I figured the fix would be easy, simply email the right person, get the new password and update the process.  I also was taking the time to update the script to that the password would be encrypted moving forward, right now it’s in plain text and to give the correct error in the event of login in failure.

Well, the person who should have the password wasn’t even aware of this process. As we exchanged emails, and the lead developer chimed in, the conclusion was that this process probably shouldn’t be using this account, and that perhaps even then, this process may no longer be necessary.

So, now my job is to track down the person who did or does rely on this process, find out if they still are and then finish updating the password.  Of course if they’re not, we’ll stop this process. In some ways that’s preferable since it’s one less place to worry about a password and one less place to maintain.

Now, the above details are somewhat specific to this particular job, but, I’m sure all of us have found a job running on a server someplace and wondered, “What is this doing?” Sometimes we find out it’s still important. Sometimes we discover that it’s no longer necessary. In a perfect world, our documentation would always be up to date and our procedures would be such that we immediately remove unnecessary jobs.

But the real world is far messier unfortunately.

(and since the full photo got cropped in the header, here it is again)

Call 911. If you can

Apparently not only can guest rooms can not be called from this phone

And as a reminder, if you enjoy my posts, please make sure to subscribe.

 

Failure is Required

Posted on by
Reply

Last week one of my readers, Derek Lyons correctly called me out on some details on my post about Lock outs. Derek and I go back a long ways with a mutual interest in the space program. His background is in nuclear submarines and some of the details of operations and procedures he’s shared with me over the years have been of interest.  The US nuclear submarine program is built around “procedures” and since the adoption of their SUBSAFE program, has only suffered one hull-loss and that was with the non-SUBSAFE-certified USS Scorpion.

The space program is also well known for its heavy reliance on procedures and attention to detail and safety. Out of the Apollo 13 incident, we have the famous quote, “Failure is not an option” attributed to Gene Kranz in the movie (but there’s no record of him saying it at the time.)

Anyway, his comments got me thinking about failures in general.

And I’d argue that with certain activities and at a certain level, this is true. When it comes to bringing a crew home from the Moon, or launching nuclear missiles, or performing critical surgeries, failure is not an option.

But sometimes, not only is it an option I’d say it’s almost a requirement. I was reminded of this at a small event I was asked to help be a panelist at last week.  It turned out there were 3 of us panelists and just 2 students from a local program to help folks learn to code: AlbanyCanCode. The concept of agile development was brought up and the fact that agile development basically relies on failing fast and early.  For software development, the concept of failing fast really only costs you time. And agile proponents will argue that in fact it saves you time and money since you find your failures much earlier meaning you spend less time going down the wrong path.

But I’m going to shift gears here to an area that’s even more near and dear to my heart: cave rescue.  At an overarching, one might say strategic level, failure is not an option. We teach in the NCRC that our goal is to get the patient(s) out in as good or better shape than we found them as quickly and safely as possible.  In other words, if we end up killing a patient, but get them out really quickly, that’s considered a failure; whereas if we take twice as long, but get them out alive, that’s considered a success.

But how do we do that?  Where does failure come into play?

One of the first lessons I was taught by one of my mentors was to avoid “the mother of all discussions.” This lesson hit home during an incident in my Level 1 training here in New York. We had a mock patient in a Sked. Up to this point it had been walking passage through a stream with about 1″ of water. But we had hit a choke point where the main part of the ceiling came down to about 12″ above the floor passage.  There was alternative route that would involve lifting the patient up several feet and then over some boulders and through some narrow and low (but not 12″ low passage) and then we’d be back to walking passage.  I and two others were near the head of the litter.  At this point we had placed the litter on the ground (out of the water).  We scouted ahead to see how far the low passage went and noticed it went about a body length.  A very short distance.

Meanwhile the rest of our party were back in the larger passage having the mother of all discussions. They were discussing whether we should could drag the litter along the floor, lift it up to go high, or perhaps even for this part, remove the patient from the litter and have them drag themselves a bit.  There may have been other ideas too.

My two partners and I looked at each other, looked at the low passage, looked at the patient, shrugged our shoulders and dragged the patient through the low passage to the other side.

About 10 seconds later someone from the group having the mother of all discussions exclaimed, “where’s the patient?”

“Over here, we got him through, now can we move on?”

They crawled through and we completed the exercise.

So, our decision was a success. But what if it had been a failure. What if we realized that the patient’s nose was really 13″ higher than the floor in the 12″ passage. Simple, we’d have pulled the patient back out. Then we could have shut down the mother of all discussions and said, “we have to go high, we know for a fact the low passage won’t work.”

Failure here WAS an option and by actually TRYING something, we were able to quickly succeed or fail and move on to the next option.

Now obviously one has to use judgement here. What if the water filled passage was 14″ deep. Then no, my partners and I certainly would NOT have tried to move the patient with just the three of us. But perhaps we might have convinced the group to try.

The point is, sometimes it can often be faster and easier to actually attempt a concept than it is to discuss it to death and consider every possibility.

Time and time again I’ve seen students in our classes fall into the mother of all discussions rather than actually attempt something. If they actually attempt something they can learn very quickly if it will work or not. If it works, great, the discussion can now end and they can move on to the next challenge. If it doesn’t work, great, they’ve narrowed down their options and can discuss more intelligently about the remaining options (and then perhaps quickly iterate through those too.)

So today’s take away, is don’t be afraid of failure. Embrace it. Enjoy it. Experience it. It will lead to learning.  Just make sure you understand the price of failure.  Failure may be an option and is sometimes mandatory, but in other cases, the old saw is true, failure is not an option, especially if failure means the loss of life.

 

Locked Out

Posted on by
3

As I’ve mentioned, not only am I fascinated by disasters and their root causes and how we react, I’m also fascinated by how we take steps to prevent them.  In my book IT Disaster Response: Lessons Learned in the Field I discuss the idea of blue-flagging on railroads.  The important concepts were two-fold: 1) a method of indicating that the train should not be moved and 2) controls on who could remove that indication.

During my recent power outage, I came across something similar.  It should be the featured image for this article.  It’s basically an orange flag locked to a utility pole.  Note the key word there, locked.

The photo doesn’t show the fact that this utility pole contained circuit breakers (I believe that’s the proper term in this context) for the overhead power lines. They had been tripped as a result of a tree further down the road taking out all three supply lines.

Close up of orange flag on utility pole, along with tag with lock-out information

Close-up with tag and flag.

So let’s analyze this a bit:

The orange flag itself was VERY visible. This ensures any other crews that might be in the area that there is something they need to notice.

There is a tag with detailed information. It’s hard to see in the above photo, but it includes who tagged it, the location, and date and some other information.

What’s not clear, is it’s padlocked to the pole.

Now, to be clear, this is NOT a physical lock-out like you see on some power panels (i.e. where the padlock physically prevents the circuit-breaker from being opened or closed).

In this case, a physical lock-out would most likely have to be placed 30′ in the air at the top of the pole where it wouldn’t be easily noticed.

But that said, this served its purpose. It alerted other crews to a danger in the area and presumably can only be removed by the person who put it there. And it contains information on that person so they can be reached if there are questions.

Since power was restored within 1 hour and I didn’t hear of any reports of line worker getting electrocuted, this appears to have worked.

Today’s take-away: when you have a change from the normal state of operation, what steps can you take to ensure that others don’t try to return items to a normal state of operations without confirming things first? By the way, for a good read-up on how bad things can go when intentions about a non-standard mode of operation don’t get properly communicated, I recommend reading up on the events leading up to the Chernobyl disaster.

Procedures are important. Deviating from them can have serious consequences. Do what you can to minimize the possibility of deviations.