Skip to content

Engineering the Emergency Room, Part I.

20 April 2012

I will not be able to address the entire subject today. But I will discuss the nature of the system, and introduce some tools we use to try to address the issue. Fundamentally, asking why emergency department visits take so long is like asking why traffic is so bad, or why air travel is so annoying. Because it’s an extremely complicated system, and a lot of people with different needs, desires, and agendas are all trying to access it.

To back up a moment, it is probably useful to define the term “system”. The problem with that is that there’s no universal definition, and to some degree, like with the term “set”, there’s no truly satisfying definition that isn’t at least vaguely tautological. The most basic definition I use is this:

System (n): A collection of objects, and the relationships between those objects.

Simple, straightforward, and it gets the fundamental point across. Systems theory is the study of things, and how they interact with other things. Complex Systems is more satisfyingly defined, and fundamentally describes dynamic arrangements of large numbers of interdependent sub-systems, which exhibit global properties which may be non-obvious from the behavior of elements in the systems. Think about animals. If you study an ant, by itself, you’d have no way of predicting that when you put a few hundred thousand of them together in a forest, they’ll build an ant-hill. When studying a sardine in isolation, there is no particular reason to suspect that a school of them will make simultaneous direction changes in response to predatory threats. But it is often a very simple rule set (each fish tries to stay within two inches of its neighbor, each fish tries to move orthogonally to a threat) that cause such behavior.

And an emergency room is no different. It’s simply a large collection of objects (patients, rooms, physicians, nurses, lab samples, computers, etc.) and the relationships between those objects (treatment, consumption, creation, etc.). And the global behavior of the system is often difficult to observe. For anyone. Because when we go to the ER, we are elements in the system, but other elements are hidden from us. And in fact very few, if any, of the elements of the system can see how the whole system is behaving. This leads to specious generalizations, like assuming that because it is slow for me, it must be slow for everyone.

So, because it isn’t really possible to observe nice, fluid, sexy, obvious global behaviors, like a concerto of starlings wheeling in unison to avoid a peregrine falcon (Can you tell I watched LIFE recently?), we need to define what we mean by system performance. And this is where it gets complicated, both in general, for systems theory, and specifically, for the emergency room. Because the system doesn’t exist in isolation and it’s hard to know where the edges are. The ER interacts with the lab, and radiology, and the inpatient beds. Through ambulances, it interacts with other hospitals in the region.

Performance metrics most frequently defined as relevant in the ER are throughput metrics. Average time in system, from arrival to disposition (which may be admission, transfer, discharge, or death). This is often broken down into several sub-metrics, time from arrival to triage, from triage to first physician contact, from arrival to admission orders, from admission order to inpatient bed acquisition, etc.. And the other system most frequently identified as crucial to ER throughput is the inpatient wards (ICU, or specialty care such as cardiac telemetry).

Finally, it’s all very well and good to measure these things, but how do we determine exactly what contribution various factors have in influencing length of stay? There are statistical methods, of course, but they rely on mathematical assumptions that may not hold (even basic hypothesis testing often requires independent observations. But in the ER, it’s difficult to say that any two patients are independent events, because they compete for resources.). I’m not a statistician, and I know there are ways to account for differing factors. But even the best statistical methods can’t give us a dynamic image of how an ED behaves, and what happens when different random events cause system disturbances.

The tool I use to examine these systems is called discrete event simulation. It’s a computer simulation of the emergency department which captures the inputs (patient arrivals, staffing numbers, capacity) of the system, and implements the system flow (how physicians and other system resources treat and disposition patients) in a dynamic, graphical model. Discrete event simulation is an ideal tool for the study of these systems, because it allows us to take into account the many different processes that happen in an ER and examine them at both reductionistic and global scales. We define each process individually, according to simple rules (eg. physician sees patient for 5±2 min, and then a lab sample is created), and then let all of those processes interact together graphically, so that global behaviour may be visualized at a glance.

So how do we actually model a system? How do we turn a living, breathing ER into a model that we can then use to make conclusions about the provision of care? That’s up next, in part II.

7 Comments leave one →
  1. Harlow permalink
    20 April 2012 09:29

    Throughput is important but even more important is patient outcomes. Also, cost is not inconsequential.

    • 20 April 2012 09:32

      Of course, those things are critical. However, a lot of literature supports the hypothesis that patient outcomes are highly associated with length of stay. And it is rare to consider cost in the medical literature. Physicians don’t want to make critical care decisions based on cost.

  2. bronironi permalink
    20 April 2012 10:37

    This anthropologist is looking forward to part 2. I’m very curious to know how an engineer tries to model human behaviors.

  3. 24 April 2012 21:13

    Lots of factors to think about and lots of interactions.

Trackbacks

  1. Engineering the Emergency Room, Part II. « Infactorium
  2. Engineering the Emergency Room, Part III. « Infactorium
  3. Engineering the Emergency Room, Part IV « Infactorium

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s