Jack
Stout
JEMS Magazine
May 1983
SYSTEM STATUS MANAGEMENT
The Strategy of Ambulance Placement
System status management refers to the formal or informal systems, protocols, and procedures which determine where the remaining ambulances will be when the next call comes in. Whether elaborate or simple, written or remembered, every system has such a plan—the question is, does it make sense and does it work?
Author Jack Stout is a regular contributor to JEMS
and will have a monthly column beginning in the June issue. He has long been
involved in designing and implementing
Some of the most earth-shaking concepts seem merely
interesting when they first emerge into view. Some go nearly unnoticed. The
force and impact of the idea may change our lives without
our ever knowing that it was that idea that did it.
The well-known Eisenberg studies certainly caught
our attention, but did you know that those studies are subtly but powerfully
impacting the very structure of the entire ambulance industry? Legally imposed
response time standards are no longer arbitrary or entirely subjective, and the
courts are upholding ordinances with stringent response time requirements
based, in part, upon the Eisenberg studies. The right of private ambulance companies, or public agencies for that matter, to deliver
life-threatening response times has been seriously weakened. The life
expectancies of low-performance ambulance organizations, and even entire
classes of ambulance systems, have been dramatically shortened by the new
knowledge. Almost unnoticed, the forces have been set in motion.
In the February 1983 issue of Medical Care, Dr. C.
Gene Cayten and others upped the ante even further
with the publication of a research project summary entitled, “Clinical Algorithms
for Prehospital Cardiac Care.” This well-written
article describing a truly fine piece of research is, perhaps with less fanfare
than the Eisenberg studies, another blockbuster. Whether an
As our infant industry matures, we are learning that
some ways are better than others, and that everything isn’t a matter of
opinion. Eisenberg showed us that, for certain patient conditions, both fast
BLS and slow ALS are deadly. Dr. Cayten and his
colleagues have now shown us that well-documented clinical
algorithms not only help paramedics retain their technical skills, but
actually can be traced with statistical significance to changes in patient
outcome.
Gradually, very gradually, we are learning what some
have suspected all along. We are learning that life-saving system performance
is hard to come by. Not even money can necessarily buy it. Smart people with
good intentions and expensive equipment are not enough. Our business is more
like pro-football, gorilla warfare, or (closer to home for this writer)—heavy
weather sailing—all depend upon first recognizing that a variety of events are
going to happen very quickly, your responses to those events must be perfectly
selected and executed, and that you can’t possibly predict what’s really going
to happen. Then with painstaking diligence, you try to predict everything that
could happen anyway, and you figure out what you would do if it did happen, and
you write it down and you think it through and prepare yourself and you
practice, practice, practice. When things do start happening, you hope most of
what you do goes according to plan, leaving you and your crew free to
concentrate your intelligence and creativity upon a limited and more manageable
set of unforeseen circumstances.
The concept common to all of these activities is the
goal of reducing, as much as possible, the need to invent protocols and
procedures on the spot. Think it through before it happens. Plan the response
while the pressure if off, while the advice of others is available, while
mistakes can be made and corrected in the hypothetical—not in a ditch under a
car in a foot of water covered with a shiny film of gasoline.
And practice. Cayten
noticed that the number of paramedics treating the patient influenced patient
outcome, and had to adjust the analysis to account for this and other
variables. But having lots of paramedics at the scene doesn’t automatically
help the patient. You can’t outnumber an attack of ventricular fibrillation.
Paramedics make a better team because they all know what’s going on, what’s
next, and how to help. But how many two-tiered systems have even written down,
much less practiced, team task descriptions and protocols so that BLS crews
know how to really join the team when assisting an ALS crew?
High Performance in Dispatch
The term “dispatcher” is used in the commercial
trucking industry, the taxicab industry, and defines the job of the 18-year-old
clerk who sends out the Xerox repairman, the plumber, or the exterminator crew.
And back when “as soon as we can, ma’am” was soon enough…the same era when “in
the best hands” and “all that could be done was done” was the measure of good
medical care….dispatchers dispatched ambulances, too.
But just as we are learning that highly ordered and
practiced action in the field makes for better management of patient care, we
are also beginning to learn that the management of an entire system can be
dramatically improved by similar refinements in the control center.
I remember a conversation I
once had with an experienced dispatcher in a large urban system. I was watching
the operation of the dispatch center late one night when I heard the dispatcher
say to a telephone caller, “what is your telephone number?” Later I asked that dispatcher if the caller
was phoning from the caller’s own home. The answer was, “no.” The dispatcher had asked, literally, for the
caller’s own phone number. What the dispatcher wanted to know was the callback
number. I suggested that if you want to know what number the caller is coming
from, then you should say the words, “what number are you calling from?” No
other words are as good.
There still exist throughout the country major
ambulance service systems, some even ALS, where the conversation between the
“dispatcher” and the caller is more like a chat than anything else. Each
dispatcher has his or her own approach to the conversation—a far cry from the
orderly and reliable telephone protocols (i.e. information gathering
algorithms) of Dr. Jeff Clawson’s Salt Lake City Fire Department operation (see
Dr. Clawson’s article, “Medical Priority Dispatch – It Works!” February 1983 jems).
Sloppy and extemporaneous telephone protocol makes
for misunderstanding, faulty information, and missing information; yet the
system’s entire initial response is based upon that information.
In some of our better managed EMS systems, medically
trained dispatchers employ clinically sound and thoroughly thought out
telephone protocols to gather information and to advise the caller with prearrival instructions, and in multi-tiered response
systems, these same protocols extend to guide the selection of ambulances and
first-responder units. All essential, but what about the management of the
system itself—the system whose configuration when the phone rings can often
make the critical difference? What about the management of system status?
“System status management refers to the formal or informal
systems, protocols, and procedures which determine where the remaining
ambulances will be when the next call comes in.” Whether formal or informal,
elaborate or simple, written or remembered, every system has a “system status
management plan.” The only question is, does your system status management plan
make sense and does it work?
EFFECTIVE UNIT
HOUR UTILIZATION
Think of it this way. Every ambulance system can
afford to place only a limited number of ambulances on the street. Because
ambulance demand patterns usually follow a weekly cycle, I like to think in
terms of “unit hours per week.” A “ unit hour” is
simply a fully equipped and manned ambulance on the street for one hour. A
dispatcher trying to match supply with demand must utilize the available “unit
hours” in the best way he or she can to squeeze the highest response time
performance possible out of the unit hours available.
At the most basic level, there are two extreme forms
of unit hour deployment. At one end of the extreme, the system could run the
average number of unit hours available per week all the time, i.e. the same
number of ambulances on the streets 24 hours a day, seven days a week. At the
other extreme, but not much more foolish, you could put all the unit hours on
the street at the same time for one hour, if you owned that many ambulances.
Since all of the calls don’t come in during one hour
a week, it would obviously be stupid to use up all of your precious unit hours
during one 60-minute period each week. But at the same time, demand for
ambulance service fluctuates wildly by time of day and day of week, so it
wouldn’t be much more intelligent to run the same number of units all the time.
Somewhere in between is a solution that makes sense. The Demand Analysis Report
for Kansas City (page 30, from the American Ambulance Abstract Service—AAAS)
illustrates the normal and unusual patterns of fluctuation, by time-of-day, and
day-of-week, for life-threatening emergency calls, non-life-threatening
emergency calls, and non-emergency calls for all the Thursdays for four months
ending December 1982 in Kansas City, Missouri. Look it over and think about how
you might spend unit hours on Thursdays in
Taking surplus unit hours off the street when they
aren’t needed, and adding these unit hours during times of overload or wild
fluctuation makes sense. But the question of where to put these ambulances
remains. If you assume that the geographic pattern of demand is fairly
constant, or completely random, chances are you will be wrong, and from some
patient’s perspective, dead wrong.
Every ambulance system has strategy for placing its
ambulances, ranging from the Pollyanna approach of giving every ambulance a
permanent “home base” and leaving it there except when dispatched, all the way
to automated deployment systems which utilize different deployment plans for
each hour of the day and each day of the week, complete with mini-deployment
plans within each hour depending upon the number of ambulances then left
available in the system.
Maps “A” and “B” show the location of all emergency
requests in the City of
If you see a “G” on the
maps, it means a life-threatening emergency where the system responded in eight
minutes or less. If you see a “B” (i.e. bad), it means a life-threatening
emergency with a response time over eight minutes. An “O” means a
non-life-threatening emergency with a response time under ten minutes. (Other
maps use different response time tolerances for different purposes.)
Notice that during Hour 10 on Thursdays,
activity concentrates heavily among the west end of
Now compare that with what goes on during Hour 11.
Not much happens on
Maps “A” and “B” show how different things look in
the same city, on the same day, just two hours apart. Now let’s look at the
same hour (i.e. Hour 11,
A more sophisticated system status plan is simply a
plan for dealing with different demand patterns by basing the around-the-clock
deployment of unit hours, and the geographic deployment of remaining units
available upon the historical, geographical and time-of-day fluctuations in
demand patterns. Of course, for some hours in some areas there almost is no
pattern to be found. The “O’s”, the “B’s,” “P’s” and “G’s” scatter all over
everywhere, and demand volumes hit everywhere except on the average. But this
is a type of pattern itself, the toughest of all to deal with, and so we are forced
to get out the checkbook, spread out our units, and when the last unit is all
we’ve got, park it near a freeway exchange where it can’t get to any location
very fast, but can cover the whole city with some reliability.
When I go through this
process, I get my latest AAAS Maps and Demand Analyses, along with several
other useful reports and sit down with the most experienced dispatchers and
street people I can find. I show them the maps and the demand analyses for one
hour of the day, one day of the week, and ask them the following question: “Knowing
the frequency and fluctuation of demand for this hour, and seeing the maps of
historical demand and response time performance, if you only had one ambulance
left in the system, where would you like it to be located?”
This, as it turns out, is an
amazing question. The “system status committee” may often argue and struggle
for some time to come up with an answer. They pick a spot and then someone
notices that, at that time of day, the ambulance would be upstream of the
hotspot, and in rush-hour traffic. Someone else notices that another location
would be downstream from traffic relative to a potential hotspot, but would
have a helluva time reaching the occasional call on
the other side of the city. But notice carefully: if it takes that much
analysis and discussion to make the decision when the pressure is off, when all
the data is available, and when the most experienced people in town are making
the decision, how on earth does anyone think a single dispatcher, under
pressure, with no time and limited information, and with six calls in progress
is going to do any better?
When we are done figuring
out where one ambulance should be, if it’s the only ambulance left and it’s
4:30 in the afternoon on a Friday, then I ask what should be done if you had
two ambulances left. Then three, then four, and so on.
Then we figure out, at each
level of remaining capability, which ambulance posts have the lowest priority,
and should therefore be used for dispatching non-emergency calls. This effort
helps to preserve the best possible remaining coverage while minimizing
post-to-post moves.
While we are at it, we recheck the demand
fluctuation for that hour, and ask ourselves what level of vehicle coverage is
so low that non-emergency dispatches should be suspended until another unit
comes back into service. Finally, we “make a wish” as to how many ambulances we
think would be necessary for safe and effective coverage during that hour of
the day, that day of the week—i.e. how many “unit hours” shall we “spend” on
this one of 168 hours of the week?
When this is done, we move on to the next hour, and
167 “plans” later, we have a pretty good idea of what the best and most
experienced dispatchers and street people in the system think should be done.
We find some hours where the volume of demand fluctuates so wildly, and where
the geographic distribution takes on no pattern at all, and during these hours
we know coverage will be expensive and difficult; we will have to make up for
the losses somewhere else.
But we also find other hours where demand volume is
highly predictable and where geographic patterning is relatively concentrated.
During these hours, coverage is easier to achieve and if the system is heavily
dependent upon fee-for-service revenues, the “profits” made during that hour
will help cover the “losses” incurred in other hours.
If the whole thing sounds
difficult, boring, frustrating, and sometimes seemingly not worth the effort,
you are beginning to understand. High performance is hard to come by unless money and
“unit hours” are no object, and even with a blank check on unit hours, real
high performance may still elude a system. In any case, when we are done with
the process, everything is written down and displayed in a flipchart or entered
into a small computer programmed (i.e. Micad or Minicad) as a system status management aid, and the result
is the beginning of a “system status plan.”
When complete, this plan serves dispatchers as a
sort of algorithm for on-line management of a system deployment, just like a
clinical algorithm guides a field paramedic. It minimizes seat-of-the-pants
redeployment, and benefits from the experience of many instead of a few.
Perhaps best of all, its effectiveness can be measured and evaluated, and the
plan continuously improved and fine-tuned. As long as every dispatcher does his
or her own thing, there is no “plan” to evaluate---only dispatchers.
EVERY SYSTEM
HAS A PLAN, HOWEVER SILLY IT MAY BE
Before we first began our work in Kansas City, the
plan then in use, though not exactly written down anywhere, went something like
this:
There will be 14 ambulances on the street, 24 hours
a day, 7 days a week, for a total of 2352 unit hours of coverage a week. Every
ambulance crew shall be on a 24/48 hour shift, and shall show up for work at a
permanently assigned ambulance post, and shall relieve the crew on duty either
on time or whenever that crew returns to its post. There shall be no rules
governing suspension of non-emergency transfer work or out-of-town dispatches.
If there are 13 calls in progress and only 1 ambulance left in the system, even
though the emergency load may be about to peak, it’s okay to send the last
ambulance out of town or to dispatch it to a non-emergency transfer call.
Furthermore, if the only ambulances left in the system are stationed at the
most remote and least active posts, while all the other ambulance crews in the
system are working their tails off, it won’t be necessary to relocate any of
the remaining ambulances, especially if it is late at night and the outlying
crews are asleep. Finally, whenever any ambulance completes a run, its crew
shall return to its permanently assigned post, regardless of whatever else may
be going on in the system at the same time. (If a dispatcher would like to
experiment from time-to-time by relocating ambulances during a shift, no rules
would prevent such experimentation, no polices would guide such
experimentation, and if the crews got mad because of the inconvenience, or if
the fuel bill were to rise noticeably, lord only knows what might happen.)
The multimillion dollar ambulance company that used
that plan is now out of business. But the “plan” is not all that uncommon. It
is easy to see why systems using system status plans like
Most systems use formal or informal plans that lie
somewhere in between the old
DEPLOYMENT
ISN’T EVERYTHING
Our first experience with really sophisticated
system status management was the result of being squeezed between a stringent
city-imposed response time requirement and a several hundred thousand dollar
increase in union wages. Revenues were fixed, costs were going up, and response
time performance had to be maintained. We had no choice except to squeeze more
performance out of fewer unit hours per week.
Our second experience with system status management
occurred when we were asked to help a system equalize an otherwise good
response time record throughout various neighborhoods of the city. An effective
and primarily black consumer group demanded an investigation of that system’s
response time performance in the poorer neighborhoods of the community. We were
initially called in to perform that investigation, and the data showed that
while the black community was receiving comparatively good response time
performance, it could be better. But surprisingly, there was a remote and
wealthy neighborhood experiencing chronic response time performance problems.
It seemed to us that response time performance could be better equalized
throughout all areas of the city using some of the deployment and management
techniques we had then recently developed elsewhere.
We went through the whole process with dispatchers
and field people just as discussed above, and after some reshuffling of crews,
posts, and shifts, a new system status plan was installed. The result was an
improvement in overall response time, and even greater improvement in equality
of performance throughout the city. (That system had focused its attention,
partly by the ordinance, upon average response time performance—a practice
which we now know results in more life-threatening response times for patients
at the dangerous end of the distribution curve, and also promotes geographic
inequality in response time performance.)
Everyone was generally pleased with the initial
results, and after a few months of operating with the new system, fine tuning
began. Using more AAAS maps and reports, we began to identify problem times of
day and neighborhoods which needed extra attention. We started by locating
areas and times of day where we apparently had surplus production capacity.
(AAAS “solution maps” highlight geographic areas and times/days where response
times are unusually fast and where the eight-minute maximum is virtually never
exceeded. The purpose is to locate surplus unit hours which can be reassigned
either geographically or by time of day to cover peaks and overload
conditions.)
As we proceeded with this fine-tuning process, we
ran into some really stubborn performance problems that didn’t seem to be
solved by any amount of ambulance coverage. Looking more closely at the records
of these specific runs, we began to learn that the problem wasn’t always a lack
of ambulances, or even a lack of nearby ambulances.
With the help of our little MICAD computer aid, we
were able to recreate a record of the status of the system at the time any
given call came in. that is, we can produce a report which tells us, for
example, that when the problem call came in at 12:35a.m., there were seven
ambulances in the system, one with mechanical problems, two on emergency calls,
one on a non-emergency, and the remaining three ambulances were available for
dispatch—one at Post 12, one at Post 13, and one en route from County Hospital
to Post 3. With that kind of information available to us, we could then take a
look at the dispatcher’s vehicle selection, the conformance of the system with
the original plan, and when we really were short of ambulances when the call
came in, we could begin to find out why
Sometimes the problem was simply a lack of
sufficient ambulances to achieve coverage, or the placement of remaining
ambulances in the wrong locations. But not always. We
began to identify a whole list of factors which impact response time
performance, some of which cost money to deal with, but most of which do not.
If money is no object and you have a response time
performance problem in some neighborhood or during some time of day/day of
week, you can simply buy another ambulance, hire another crew, and add another
“unit hour” at the right time and place. Sometimes that will solve your
problem, and sometimes it won’t.
Ambulance system response time performance is not
“good” or “bad,” in general. If you are having response time problems, they are
almost always occurring at some times of the day/day of the week but not at
others, and problems often repeat themselves in fairly predictable geographic
patterns. These patterns are obscured by the fact that where the response time
problem is occurring will change depending upon when it is happening. Since
only a handful of systems have a way of combining and displaying this
information for analysis, and since most systems rely heavily upon “averages,”
few of us have learned to see response time problems in a diagnostically useful
way.
If I have a response time problem, and have no
prospect of increasing system costs to solve that problem, then I must exhaust
every possibility for solving the problem before I resort to simply adding
equipment and crews, or even to going through the hassle of revising schedules
and shift assignments. I must first pinpoint the time and location of the problem,
and then proceed to diagnose the causes. Only then can I devise a solution. The
process I use relies extensively upon statistical information from the AAAS
reporting service, and I follow a step-by-step path that is too lengthy to be
detailed here. However, several of the most productive steps can be described
as follows:
1. Define
the problem specifically. I must know exactly when and where the response time
problem is occurring before I can begin to diagnose it. Is there a pattern?
2. Bonafide system overload? Was the dispatcher out of
ambulances when the call came in? Were the available ambulances too far away? If so, why? Where were all the other ambulances at the time, and what were they doing?
3. Plan
followed or violated? Did the problem occur because the system status plan is
faulty or because the plan wasn’t being followed?
4. Dispatcher error? Was the nearest
ambulance dispatched? Were the routing instructions accurate? Is the crew or
dispatcher unfamiliar with
that neighborhood? (One AAAS report analyzes response time
performance by dispatcher , by district or
neighborhood, to detect performance problems which may be the result of a given
dispatcher’s lack of familiarity with a specific neighborhood. For example,
white dispatchers may sometimes spend less time in black neighborhoods than in
other parts of the city, and therefore may be less familiar with primarily
black neighborhoods. If that is the problem, no amount of extra ambulances will
solve it.)
5. Are unit
hours being wasted? Are there plenty of ambulances on duty that hour, given the
number of calls received, but for some reason availability is lacking? Figure 1
shows a sample “Hospital Drop Time” report from the AAAS service designed
to detect hospitals whose method of receiving patients excessively delays
ambulance crews. As a result of this particular report, a “uniform hospital
drop policy” may be developed and adopted by all hospitals, reducing
unnecessary out-of-service time to the tune of thousands of dollars in lost
unit hours per year.
Figure 2 analyzes “Hospital
Drop Time” too, but this time by senior paramedic. There is no “right” time at
the scene, and there is no “right” hospital drop time either. Every call is
different. But when you are looking at 40 or 50 runs per medic, and one medic
averages twice as long at the hospital as everyone else in the company, its worth a conversation. Most medics in our systems are
used to these reports, and posting alone seems to do the trick. But believe me, the first time we ran these reports, the numbers were
all over the place.
If you think all hospitals are about the same in
hospital drop times, think again. In one city, we found a hospital that
averaged triple delays in drop times, no matter who the medics were. This added
up to over $150,000 per year in lost unit hours due to that hospital'’ methods
of accepting patients. Other reports detect bad habits which hurt system
performance. I call one such report the “paramedic honey locator” report, since
it can detect a paramedic who is normally fast in hospital turnaround time, but
who routinely takes longer at a particular hospital that is normally fast for
everyone else. I presume the presence of a “honey.”
6.
Equipment failure? Are we plagued by equipment failures? How long does it take
to get a unit back in service? How often does one ambulance assist another
because the former’s cardiac monitor won’t work,
etc.?
7. Demand
pattern change? Has the demand pattern begun to change for this location and
time of day/day of week? Was there a seasonal fluctuation that we can prepare
for? Was there a special event that we failed to account for?
8. Traffic
flow problem? Were we upstream when we should have been downstream?
9.
Out-of-chute time? One standard AAAS report routinely displays average times
from unit alert to en route status, organized by senior paramedic name and
number. For life-threatening calls, this time should be under 30 seconds on the
average, and never over one minute. Lost time leaving the chute can never be
made up, no matter what you do. In one case, we found what should have been
obvious to everyone—an ambulance post location where the crew quarters were on
the second floor and at the other end of the hall from where the ambulance was
parked. With brilliance, we moved the crew quarters and solved the problem.
Sometimes our work isn’t very sophisticated.
10.
Dangerous non-emergency cutoff level? Is
the problem repeatedly happening when several non-emergency transfer runs are
in progress? Could the problem be fixed by simply raising the non-emergency
cutoff point to a safer level?
11. Change
post locations? Could we solve the
problem simply by moving an existing ambulance from a less frequently utilized
post location into the problem area? This is the simplest move, since it
requires no reshuffling of shift schedules. However, care must be taken since
you may simply relocate the response time problem to the other side of town.
The AAAS “solution maps” help make this decision by
locating neighborhoods where problems rarely occur and where response times are
extra rapid. We will deliberately adjust the system to eliminate emergency
response times over eight minutes, even if doing so results in a slight
increase in either overall average response times or slightly decreased
coverage in an apparently overserved neighborhood.
When first starting out, the past plan of deployment
is normally so poorly documented, poorly conceived, poorly followed, or all three, that it makes no sense to use the past system as a
basis for refinement. Most of the time, you can do better by simply abandoning
the past structure in favor of an initial system status plan developed by your
most experienced dispatch and field personnel, utilizing the process discussed
earlier in this article, together with the essential displays of demand pattern
history.
Every time we have tossed out n old deployment plan
and replaced it with a new system status plan designed that way, the
improvement has been instantaneous and dramatic. Kansas City, for example, (a
100 percent paramedic system providing both emergency and non-emergency work),
has managed consistent improvements in response time performance, both citywide
and by the city’s mandated councilmatic districts,
while shrinking unit hour coverage from 2352 unit hours per week down to the
level currently reported at 1600 hours per week. For financial reasons, the
system had to drastically cut either unit hours or wages, due to a declining
city subsidy and a badly needed commercially financed $2-1/2 million total
equipment replacement. In that city, late runs cost the operator $10 per minute
in payment deductions, and chronic late runs would cost the entire contract.
Under such circumstances, performance is almost inevitable, or at least
mandatory. (Jay Finch, manager of Medevac’s
Implementation of the first sophisticated system
status plan (SSP) usually requires a major reshuffling of everything from
ambulance post locations to shift schedules, compensation plans, crew change
methods, inventory control, and just about everything else that is sacred in
any established ambulance service. It is traumatic.
Furthermore, during the earlier stages of the plan,
there will be quite a few seemingly unnecessary post-to-post vehicle movements,
mostly occurring in the middle of the night when a 24-hour crew is trying to
sleep. The tendency will be for dispatchers to delay a post-to-post move if
another crew is nearly ready to clear from a hospital; to the extent that the
delays are frequent, the SSP isn’t being tested at all. The result might be
that you finish a difficult two or three months of initial experience only to
find out that, whatever else you may have done, you have not actually
implemented the SSP, and you can’t be sure whether the problems you are still having are the result of the SSP, or
the result of not following the SSP. If
you don’t follow the SSP, you can’t fine tune it.
Fine tuning your system status plan is, I think,
fun. In the first round of planning, everything was based on the expert
judgment and prediction of the most experienced people available, with benefit
of detailed demand maps and demand analyses. The second time around,
adjustments to the plan can be based upon the initial plan’s actual results.
During fine tuning, you can shift some posts around,
shift some unit hours around, and take numerous steps to simultaneously reduce
unnecessary post-to-post movement while squeezing out any remaining performance
problems.
In most systems, you will need about three months of
data per fine tuning cycle, which means that you must stick with the current
plan as closely as possible. Of course, the initial plan should be watched very
closely during the first few weeks to detect any obvious glaring flaws which
may need midcourse correction. (In this case, it is good to “stay the course,”
but not at all costs. The important thing is that, if a mid-course change is
necessary, it should take the form of a change in the plan—not an authorized
departure from the plan. That way, subsequent data can be used to assess the effectiveness
of the revised plan—not the old plan that was abandoned.)
With enough time and experience, and enough
quarterly fine tuning efforts, the plan will begin to take on seasonal
variations, and will account for special events such as Fourth of July,
Christmas, New Year’s, and Rolling Stones concerts. After a year or so of
development and fine tuning, you will have squeezed, poked and prodded about
all of the performance you can get out of your system, at least in terms of
response time performance per unit hour. From then on, small semi-annual
adjustments should do the trick, and probably without fanfare or too much
gnashing of teeth.
The reality of instituting sophisticated system
status management is considerably harder than you might think. Dispatcher
duties and responsibilities are more than doubled. Dispatchers of moderate
ability will bite the dust. (The new job is so different that we hate to call
these people “dispatchers,” we prefer “system status managers.”) The dispatcher training program must
absolutely involve extensive off-line simulations. Our system status manager
certification test covers Salt Lake City-type telephone protocols, medical
vocabulary, and a compressed 200-run system simulation covering every
conceivable complication. Certification requires zero-defect performance.
We have had to completely overhaul labor contracts,
shift schedules, compensation programs, and bonus plans, and we adapted a shift
bid process from the way TWA bids flights for flight attendants.
We use eight-hour shifts, 10-hour shifts, 12-hour
shifts, 24/48, and hybrids. In one city there was nearly a strike due to the
loss of some 24/48 shifts, while in another labor got mad because some
eight-hour shifts were being lost to 24/48. In another case, crews had actually
purchased homes near their permanently assigned posts. We eliminated permanent
post assignments.
But the
ultimate purpose of sophisticated system status management is very simple; we
want our ambulance crews and equipment to be located where and when they are
needed as often as humanly possible. What’s the alternative? Being somewhere else.
FAILURE
GUARANTEED
If system status management is such hot stuff, where
has it been all this time? The uncomfortable but grownup answer is that
organizations learn to do what makes money or what it takes to survive. You can
count on one hand all the cities that fine their ambulance providers for poor
response time performance. Government operations almost never compete for
survival, and there’s always the average response time to hide behind.
System status management, done properly, takes a
whole lot of work, requires constant attention, may strain labor relations, and
is really easy to screw up. No wonder no one developed it until they had to.
There are probably hundreds of ways to prove that
system status management won’t work in any city. But there are four ways that
are guaranteed to fail:
1. Try
buying part of it. An organization will
make system status management work when its financial stability and very
existence depend upon it. Under any other conditions, system status management
is just too much trouble. If your city wants good system status management,
turn over your dispatching and field operations to a qualified operator, hold that
operator financially accountable for every late run, forget average response
times and focus upon maximums, and be ready to bury
the operator for chronic performance failure. Then forget about system status
management, and you will get it.
As I always say in pre-bid conferences when asked by
private ambulance operators how my client city wants dispatching done, no one
cares how many ambulances you put on the street, how you dispatch them, or what
you do with the money we pay you. When the phone rings, we want a qualified
paramedic talking to the caller, we want a full-blown paramedic ambulance on
the scene within eight minutes 90 percent of the time, we want superb equipment
and performance, and no one cares how you do it. If you can put a guru on a hill
who can get two ambulances to handle thirty thousand
calls a year, go to it. But screw up a little and it’s ten bucks a minute.
Screw up a lot, and you’re out of business.
2. Separate
dispatching from operations. The
absolute key to system status management is the operation of the dispatch
center and the quality of dispatch personnel. The company
that does the dispatching and the company that runs the ambulances have got to
be the same company, and it’s that company must be responsible for developing,
revising, and implementing the system status plan. It’s just too
complicated to work any other way. If you think it isn’t that complicated, then
you clearly don’t understand, and you will probably never know what went wrong.
3. Try it
with employees who care little about their patients and less about their
company. People get used to the old
ways. Low performance is less work than high performance. I know for a fact
there are ambulance personnel who have deliberately delayed an emergency
response for the sole purpose of “proving” that the new plan won’t work and
that more unit hours are needed. These people are, perhaps without realizing
it, dedicated to their own company’s failure. And they will jeopardize their
own patient to make a point.
These are the same people who, rather than helping
to work out the bugs, wag their fingers at dispatcher error, who make anonymous
calls to reporters in hopes of making their company and its effort to improve
performance look foolish, and who were recently caught driving 35 mph, red
lights and siren on an open road and light traffic, on the way to an emergency.
If you have such people in your company, you have a choice: get rid of them or
cater to them. So long as they are on your payroll, they have the power to prove
you wrong. I have seen them do it.
4. Try
computer simulation. I do not recommend
or support the use of computer simulation models to determine ambulance
coverage patterns and post locations. Such models rely too heavily upon
theoretical travel times to optimize distribution. Our experience has convinced
us that a committee of experienced dispatchers and street people can outperform
a computer simulation every time if they are provided with the demand pattern
statistics, demand maps, and other informational tools which, when combined
with human judgment and experience, take into consideration traffic flow
patterns, complex street names/numbering systems, familiarity with area, and a hundred other factors that
go far beyond the scope of practical computer simulation.
CONCLUSION
When thinking about system status management, keep
in mind that regardless of how you staff and deploy your ambulances, you are
using a system status plan. System status management isn’t “good” or “bad”---it
is inevitable. Your plan may be simple and stupid, complex and stupid, simple,
yet effective, or possibly even complex and even more effective.
There are many good reasons for sticking with a more
simplified approach to system status management. Only the best managed organizations
with the most dedicated personnel should even attempt to use the most complex
and sophisticated models. But almost every system can benefit from thinking
things through with the maps and the demand analyses and the other reports,
even if the result is an elegantly simple but more effective approach to
deployment.