Work and school have conspired to use up my time, so I’ve been blogging less often. But I wanted to make a point of blogging this week because I’ve reached an unofficial milestone.

Over the weekend I reached my unofficial 1000 hour mark as an ED Tech.

I say unofficially because I’m using a fairly conservative method of counting it and officially, I reached it close to two weeks ago. So why am I counting my number, that came later, rather than the earlier number? Because this one is more meaningful to me and gives me more of a margin for counting.

Officially, by the timeclock, I reached 1000 hours over two weeks ago. However, this time included by 24 hours of initial classroom orientation and the time to get my CPR recertified and some other training where I wasn’t even in the Emergency Department.

The other factor, was that officially, many of my shifts have been 8.5 hours, with .5 reserved for lunch. However, due to staffing shortages, often many of us techs will work through our meals (and swipe the timeclock for that, guaranteeing we get paid for that time). But it was simply easier for me to ignore those “worked through meals” and only count an 8 or 12 hour shift as 8 or 12 hours, not 8.5 or 12.5 hours.

So, I simply tracked time I was actually in the Emergency Department.

Now I’d like to say that when I hit my unofficial 1000 hour mark I was doing something exciting like working a trauma or even something routine like taking an EKG. However, the truth is, I was sitting at a desk going over some study materials. I was working what’s known as the “BB-Short Stay”. Generally when working here, there’s very little to do (I think I did 18 sets of vitals in 8 hours, and one bed change. But, that’s the nature of the job sometimes.) Fortunately, my next 4 hours of that shift was back in the main area of the Emergency Department and I was able to be more active.

That’s not to say I didn’t celebrate a bit:

Me celebrating 1000 hours with overpriced sushi

So, a final note, the reason for the 1000 hour celebration, is that a number of the schools I’m applying to require a minimum of 1000 “patient contact hours” (one only requires 500 hours and another 750 hours) and now I’ve met that! That’s why I don’t count the classroom orientation or the like because that’s technically didn’t involve any patient contact.

At this point, I can start applying, despite a few classes this semester pending final grades and for most schools, needing to take Microbiology, which I’m doing over the summer.

But this was the single biggest hurdle that I had the least control over. For classes, I could simply sign up. However for the patient contact hours, I had to first get a job, ideally in a place that gave me more contact than simply “taking a set of vitals now and then” and then gain enough hours. Officially my job is only 24 hours a week and I started in late October. Fortunately I’ve been able to pick up a lot of extra hours, hence hitting my 1000 hour mark in only 6 months. My hope of course is that my 1000+ hours of patient contact in an Emergency Department stands out compared to say someone who has only had 1000+ hours in say a medical office where they’re simply taking vitals.

So this bridge crossed!

Slowly but surely getting there.

Standard Disclaimer: nothing here represents any official policy or action of my employee Albany Medical Health Systems and I do not speak for them in any capacity or in any way.

The Value of DR Testing

Just a short blog post today since I’m actually in the middle of a call with a client as we test our failover scenario.

Right now I’m calling it a success even though the SQL Server hasn’t come up yet.

Why am I calling it a success? Because we learned that our current plan has a serious gaping hole concerning how the iSCSI drives failover. Yes, technically we failed to failover as quickly as we expected.

But, we’ve learned that before this system went into production. So that’s a success. This raises our confidence level for next time.

In all honesty, we often learn more from our failures from our successes. For example, before NASA would allow SpaceX to fly a crew on Crew Dragon, they required several abort tests, one of which involved launching a Falcon 9 and then in mid-flight firing the Crew Dragon abort engines. This resulted in the destruction of the Falcon 9 (which was expected) but proved the abort plans worked. Note however that for Orion on Artemis, NASA has decided such a test is not necessary. The decision making process behind this particular decision is worthy of a blog of its own.

In any case, with the current DR test, we expect to have things finally failed over in the next hour or two. Then we’ll update our playbook and have a lot more confidence.

Moral of your story: test your DR. Assume things will go wrong the first time because they will, but far better to have that before you go to production. This is not the first time I’ve had a failover not go as planned, but prior to production.