Updated: Sep 21, 2018
by Chris Lanaman
St. Patrick’s Day parades, the NCAA tournament. It looks like there will be lots of mad marching today. Whether you’re wearing the green of Ireland or the red/blue/green/gold/purple of your favorite college basketball team, I want to focus today on a journey that, although complex, should be much more predictable: the route that data needs to travel through Millennium® from the moment of entry to execution.
Every application that makes up the Cerner system — FirstNet®, PowerChart®, etc. — has its own pathway to getting information and placing it in your database. Each application is comprised of many different functions, which cascade to complete each task. For example, when placing an order for an aspirin, the clinician’s final step of clicking the “sign” button starts several functions within Millennium. The system validates the patient, finds the code for aspirin, executes checks to see if the patient is allergic to the aspirin, validates that the person ordering the aspirin is authorized to order it, moves the tasks associated with administrating the aspirin, adds the order to the pick list for pharmacy or the Pyxis® system, drops a charge and, finally, updates the patient record in the database.
This process is repeated over and over for all of the different workflow processes that clinicians carry out. If your system is finely tuned, these steps happen in fractions of seconds. Unfortunately, there are many places where even the simplest action like ordering an aspirin can go wrong. The good news is that there are ways of checking those pathways to see where the bottlenecks are and then setting controls to prevent them from recurring.
One of the best ways to understand the bottlenecks in Millennium is to imagine the checkout line at the grocery store. If only one lane is open, shoppers might have to wait a long time to finish their purchase. However, if managers open another lane, they can process shoppers twice as fast. The same concept applies to Millennium. If the lines get long (queues fill up) where data is processing, you can increase the number of lanes (instances) that are processing your information. The result will be less waiting for clinicians.
With such a myriad of functions to complete in order to execute even the simplest of orders, it’s not surprising that the system slows down at times. What’s surprising is that some organizations equate slow with normal and do nothing to unclog the bottlenecks. It doesn’t have to be that way. Keeping your system tuned will help it deliver the performance clinicians expect.
Prognosis: You can learn how to identify which services are backing up and how to start more instances on the problem servers by reading our previous postings: “Triage 1: Diagnose System Slowdowns” and “From Triage to Treatment: Configure a Dedicated SSP.”