How busy are you?

How do you measure an EMS system?

Cardiac arrest survival rates?  Profit? Market share?


How can one system accurately compare themselves to another?

I was tasked earlier in the year with a seemingly simple question: “Are we busy? How busy?”


Um, yes and um, a lot?


Many systems use a measurement of Unit Hour Utilization (UHU), or a numerical value of how much time you spend doing EMS stuff.  This number can then be compared to others since it uses two basic measurements.  Those measurements are Hours Staffed and Time on Task.

Let’s say you’re on Medic 99 for 12 hours. 12 is your denominator, since you spent 12 hours on the rig.  Your time on task is defined slightly differently from place to place, but the standard definition is any time you spend responding to, at the scene of, transporting from or at hospital following a call for service.  This total becomes your numerator.  So let’s just say that on your 12 hour shift you ran 5 calls for a total time of 7.25 hours.  That means 7.25(time on task)/12(hours staffed) is a UHU of .60.  Quite busy indeed.

But I learned very quickly this is not a complete picture of the shift.

You see, you didn’t magically appear in service when you came on duty, you had to get the rig checked and fueled.  Then at the end of your shift you had to return to base and try to get the rig squared away for the next shift.

We refer to this time as the “Logistics Gap” or the amount of time we are paying you to do what should have been done already.  On average this can take 30 minutes at the start and end of a shift.  Now your 12 hour shift feels like an 11 hour shift.  That increases your UHU from 7.25 hours in a 12 hour shift to 7.25 hours in an 11 hour shift, or a .68.

That’s even busier.

But STILL not accurate.

What about all that post moving?

We spent months trying to get our servers to spit out CAD data that tracked post moving, but the language just didn’t understand what we were trying to do.  Adding up all the post moving time gives us an idea of how much time we are paying you to drive around instead of sitting still eating, going to the bathroom, studying, etc.


Applying that total, let’s say it’s a whole 60 minutes per shift, brings our UHU to 8.25 (7.25 time on task plus 1 hour post moving)/11 hours (12 hour shift – logistics gap) or .75.


From a .6 to a .75 is a HUGE difference!  If you are only tracking your UHU Actual, or the Time on Task/Hours paid, you are not getting an accurate picture of how busy your crews really are.


The best part of tracking these 3 values is that you can track them separately and add them up in a simple table.  Now when you introduce a new inventory tracking system that reduces restocking time, the impact can be measured and compared to previous days.  Or if a new software program at dispatch makes post moving less efficient, we can track it and break it down.


If your reports can be configured properly you can then measure each rig, each hour, each area of your district to see who is busy and how busy they are compared to others.


My agency is in the middle of gearing up for an expansion of market share and trying to figure out how busy we will be at different staffing levels is a breeze.  Just add a few rigs to the mix and rerun the math.

Yup, that’s what I do now.

So, how busy are we? That’s a secret. ;P

Agree? Disagree? Have something to add? Why not leave a comment or subscribe to the RSS feed to have future articles delivered to your feed reader?

14 thoughts on “How busy are you?”

    1., but there are multiple entries including advise for post, move up, dsback (replacing another unit) etc. Our servers have trouble counting one post status to another. We use Deccan for posting and are re-evaluating its rules to decrease posting move times to decrease UHU. What do you do up there LG?

  1. Increase your market share? As far as I knew, you are the sole provider of 911 EMS in the city of San Francisco. How do you get more market share than that?

    1. Arrangements like that in a major city with an IAFF-represented FD involved always amaze me. The union would never allow anything like that here.

  2. If only we could do that with fire companies, to include all the logistics gap. My company may do anywhere from 5-15 runs a day, but that does not account for continuing ed, fire training, maintenance of the building, report writing, equipment maintenance, and special ops equipment checks. I probably spend 3-4 hours a day on those tasks, yet our leadership never goes beyond “we did XXXXX runs last year” when they justify our manpower.

  3. Now that’s a happening idea. My service calculates our UHU as transports divided by staff hours. I’ve always thought that it should be time on task divided by staff hours.

    1. Transports divided by hours is commonly used to establish an anticipated return on billing. An average of say .12 transports per ambulance hour can be projected forward to establish an expected return. That ratio can then influence staffing.
      UHU refers to unit hours utilized. How your service defines “utilized” is important to consider.

  4. The problem here is using the wrong tool for the wrong job. UHU is not a measure of ‘busy-ness” – it is a measure of economic efficiency. Hence, transports per hour. Go back and read Jack Stout’s work from the late 1970s and early 1980s. Jack was an economist (PhD), hence his interest in production and efficiency. It’s transports/hour, by definition. It doesn’t work for busy-ness because a transport takes a different length of time in different places – some places 30 minutes, some places 3 hours.

    If you want to measure “busy-ness” you need to measure total busy time. That means accounting for all time not simply “available.” I was recently able to get, from a 20 year old CAD (thanks to the tech staff at Raleigh Wake ECC) every “status change” and its duration. This lets us capture everything from dispatch to call complete, and from “dispatch to cover” and all times away from home. Add a little for logistics time, and we have a reasonably accurate measure of how busy crews are.

    It is REALLY enlightening information.

    Any managers that use UHU as a surrogate for crew busy-ness need to take another look.

  5. Skip, thanks for the comment.

    That was my exact feeling when I was presented with the UHU calculations. It told me nothing I didn’t already know. The term UHU as traditionally applied is inaccurate in itself. That’s the main reason I have to call ours the EUHUP (Estimated unit hour utilization posting), but unit hours utilized applied to number of transports per hour is not a useful metric. It was before we had access to the CAD data to reliably track out of service times, but now we are learning how to gather that data.

    By reapplying it and actually looking at it as the hours utilized instead of transports per hour, we are now able to track all the different things we’re doing when not available for a call.

    It took a lot of tweaking, as it sounds like yours did, but the data is truly illuminating. What our service thought was a light work load looked only at transports (traditional UHU) and never took into account time spent responding to, assessing or documenting other dispositions. This was 20-35% of our day! That’s a huge gap.

    We in EMS seem to have only one agreed upon definition – Cardiac Arrest. I hope to attend more National gatherings of Quality Managers to better hone our use of all this data to explain to he budget maker why we need more people and more rigs since I can prove we physically can’t go to more calls.

    Thanks again for reading and commenting!

  6. While it’s common for most services to calculate based off UHU, I happen to agree with Tim. I’ve always thought that it should be time on task divided by staff hours as well, just my 2 cents.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>