The JavaScript Event loop for Emergency Physicians

If you’re a reader of my blog past or present you’ll know that I’ve long been interested in programming and am also an Emergency Medicine physician.  While studying javacript callback functions I was referred to this talk which explains them well, but it didn’t really “click” until I saw the visual “event loop” waiting for it’s opportunity to let the main stack know there were results to dealt with from prior callback functions.

What’s a callback function? This is one I’m still wrapping my head around, but it allows for a task to be worked on while the main program continues to function.  This way the main program is not held up waiting for results that may be dependent on some 3rd party, such as downloading a file or communicating with an API, or any other calculation or processing that needs to be done.

A callback function seemed confusing to me because I was trying to understand the literal terms of what was being “called back”.  While I’m still not certain I get that, let me explain it in terms of how the emergency room functions.  If you’ve ever been a patient in the ER or in a hospital and had a health care worker stop into your room to keep you updated on results or what exactly you’re waiting for, this should make a lot of sense to you.

And if you happen to also be an Emergency Physician or Practitioner managing complex care for many patients, you’ll also recognize YOUR role in the “event loop”.

The physician’s physical location is the main stack

In order to diagnose & treat a patient. The physician has a role in evaluating the patient’s primary complaint, including a history, a physical exam, objective testing data, and then a clinical summary of what it all means.

Some of this can only be done by the physician being present, in the room, talking with the patient and doing a hands on physical exam. The physican may be caring for many patients at once, but can only be in one place at a time. The physician’s physical location combined with what stage of evaluation they are in is kind of like the main call stack.

  • Pick up a New Chart
  • Read the chief complaint, note allergies, prior medical issues, and nursing notes that may be pertinent
  • Go to the patient room and talk with the patient, get further history
  • Perform a physical exam on the patient
  • Return to the desk or order entry area and order appropriate blood tests, x rays, other diagnostic tests, or place a phone call to a specialist.

All of these things ideally happen in an uninterrupted sequence. Bear with me here, interruptions are common, but the above set allows for full focus on ONE patient at a time and minimizes early errors in thinking, or forgetting something like an out of the ordinary lab test for your patient that seems appropriate (for example, a TSH is not a routine test, but in some cases it may be valuable to the ER physician).

So the call stack, the main flow of the ER, involves the physician reviewing charts, seeing patients and ordering tests. She does this twenty times a day, but must find time inbetween these “stacks” to review all that data she’s ordered.

Each test ordered is a callback function

When the physician or practitioner orders blood tests, several things happen automatically that creates a new work routine for one or more people. Stickers are printed for the blood tubes, a technician sees the order and grabs the supplies to draw the blood. The technician or nurse physically goes to the room to draw blood on the patient. Blood tubes are labeled and sent to the lab with care.

The lab receives them and begins processing them and eventually results are returned, either on a printer, via telephone or most often, in a computerized record system. The lab runs the blood tests on several different machines and they results come back at different times, to be reviewed by the nurse & physician when they are available to synthesize that information and make a decision on it.

Clearly if the physician had to wait for all of this to happen, or even part of it, before moving to the next patient, the flow of the ER would creep to a complete halt. Physicians would be limited to 1 to 3 patients per day rather than 2 to 3 per hour. Only because these ancillary tests are “callbacks” can the physician move on to the next patient in the queue to being their evaluation.

The event loop allows the physician to process the results
At some point the physician has a brief mental & physical break beteween seeing two patients, or between a phone call and the next patient and can turn to the computer to see what’s resulted on a waiting patient. This is analgous to the call stack (the physicians workload) finally being open again to pay attention to a new piece of information.

The results of the testing (the callbacks) are available to review

An experienced physician understands the flow of effort 7 energy between picking up a new chart (filling the call stack again) and reviewing prior results on older patients ( the call backs) This is the “event loop”. The event loop waits until the call stack is empty, until the main program flow has returned from other tasks, and can manage the results of functions, whether it is a set of calculations, a file, or information from a web site.

The event loop analogy applies to not only test results but any other type of interruption to the physicians call stack. Interruptions create a mistake prone environment, so it’s vital that both physician and other staff recognize the ideal moments in which to have new information processed.

Asynchronous Patient Flow

Only because of the asynchronous nature of the “Physician Stack”, “Callback Testing”, and “Event Loop Interruptions” can today’s healthcare environment support the massive volume of patients needing to be seen. We are always looking for ways to become more efficient while maintaining good patient care, satisfaction, reducing mistakes or injuries, and maintaining work satisfaction for all involved.

I would imagine in the same way during my exploration as a javascript full stack developer, I’ll continue to seek out ways to maintain efficiency, improve program flow and keep myself happy along the way while getting a good product for any client I work with.


Loupe: A visualization of the JS CallStack/Callback/Event Loop

Free Code Camp – A Full stack JavaScript development education platform

Converting a Javascript object to a readable JSON file

While working through the final challenges at FCC (Free Code Camp) I coded a live working Angular.js project alongside the hand-holding tutorials that are entirely done in side the browser.

The tutorials at CodeSchool are excellent as they prompt you step by step through what initially seem like very complex tasks.  As a I worked through the tutorial and watched the videos, I recreated the project (a fun little gemstore) on my own computer.

This was really important to me to convince myself that I understood the technology.

However in the final final step of the angular.js course, and thus the final challenge of Free Code Camp, they introduced a cool trick to import data from an external file in a format called JSON.  JSON is very similar in appearance to how a Javascript object appears…it’s human readable in the same way, however the syntax is slightly different.


It was going to be a daunting task to convert the entire object from Javascript to JSON just to get this last step working.  A little googling led me to two pieces of advice that solved my problem instantly.


First was this gem at Stackoverflow:

  1. Launch Firefox/Chrome/Safari
  2. Open Firebug/developer tools
  3. Copy/paste your code into the console.
  4. Then type console.log(JSON.stringify(object)) and voila!

So I tried it, and got back a minified version of the JSON object. This actually worked fine, but I couldn’t read it, so I used this nifty site to simply format it with line breaks and tabs:

Just click the icon of the little outline after pasting in the results from your console and presto…there is your JSON file.