When it comes to ordering laboratory tests within our EHR and related applications, have we inadvertently made the provider’s job more difficult? If the system(s) were designed to operate based on our workflows, the answer might be no. However, there are variables that create trade offs in lab ordering system design and this is where we end up with divergent paths. Here, we discuss the impact of these variables on provider, patient, and our recommended path for lab ordering system setup across Ambulatory and Acute facility sites.
Variable 1: Proximity to Patient
If the system was not specifically designed to generate laboratory options based on the patient’s proximity to testing locations, the related challenge for the provider is a “memory tax” to recall the most convenient options for the patient. In turn, the patient is faced with a “decide now” moment in working with their provider. Similar to how pharmacies can allow someone choose a pharmacy to send the escrip, the ideal system design is to allow the provider and patient to choose a lab.
Variable 2: Multiple labs for one orderable test
Two different labs may have the same orderable test, but those two labs may report different parts/pieces/components for that orderable. This can be due to any number of reasons, like how the vendors create the instruments and what each instrument will report. It could be that one testing site is a reference lab and they change their orders and/or components as much as they change… well, you can choose the analogy here.
Variable 3: Outpatient lab ordering systems
So far, I have introduced the variables affecting the patient’s choice and impact of instrument and lab configurations. This is easier to handle when the Lab Information System is the hospital lab’s system and perhaps a direct lab interface to a reference lab. When a lab specimen arrives in the hospital lab, as it should, the lab gets to make the decision on where that specimen’s testing is performed.
Let’s throw in a third variable and for the sake of argument, name it Provider Outpatient Lab Ordering system (POLO). In our scenario, the POLO system has the capabilities to place lab orders and send them wherever services are provided, including the hospital, Reference Lab 1, Reference Lab 2, and so on. POLO is a great approach assuming it operates as its own entity that can send and receive orders and results without any impact on the hospital.
There is a system design opportunity and pitfall here. Imagine that the ordering system we named POLO appears to be a separate solution to the Providers, but under the hood, were directly tied to the hospital system’s lab application build. It is plausible to facilitate the outpatient orders by building a separate set of orderables and components. This would work well if all the under-the-hood-application-build pieces were invisible to the hospital lab. Well, we know by experience implementing lab ordering for health systems both small and large that they typically aren’t. Not only are these orders and components not invisible, it can be nearly impossible to make it invisible and the separate build items have the potential to end up on the lab’s hold queue order list, vastly complicating their already busy workload.
Think long term for lab ordering system design
Ultimately, there are two options for designing lab orders across outpatient and inpatient sites. The first, creating separate orders for each performing site. The second, keeping orders as one.
Our recommended practice is to utilize the same tests for orders that are essentially the same, and making them appear differently to the facility placing the order. This will likely require custom requisition (report) build, or a user to toggle the Ambulatory order to the correct testing site when the patient arrives and the testing lab site calls for the electronic order.
Why the recommended practice? If we choose the path of making separate orders for each performing site, we have now placed that burden we highlighted in the beginning squarely on the provider’s shoulders. With each new orderable, the provider may get two or more to remember. If the site has 400 orderable send-out tests, it equals 800 for the provider to remember. Again, that is if the patient makes the decision at the time of order of where they will go to have the testing done.
If we go with the keeping orders as one, we have solved for multiple orders for the same type of test, but we have created a burden for the lab system set up. This, in the long run, is the better of the two options because it builds the complexity into the system once and can be utilized long term. If executed properly, there would be a set of instructions to maintain and add components and profiles as time passes.
Priority in healthcare system setup should be given to empowering the delivery of care with the least disruption over time. The benefits to providers, patients, and the efficiency in ordering will almost always outweigh the cost, time and effort to deliver an optimal laboratory ordering system setup.
