Aaron Berdofe, MHI – Health Informatics

One of the qualifications of Meaningful Use is to use computerized physician order entry (CPOE) within your EMR  (Still resisting EHR! This is how I fight the man).  The dirty secret in the LSS world is that barely any of their customers actually use the ordering functionality to its full intent.  Some send orders to the Lab, but send paper orders for Ultrasounds, X-Rays, MRIs, etc.  Some send orders electronically and then also send a paper order as well.  A large number of sites are still trying to figure out how the thing works in the first place before they even attempt to use it.  Here’s the deal: The functionality is unnecessarily complicated and your service rep. probably knows only as much as you do about the topic.  You’ve probably asked LSS and MEDITECH the best way to set up ordering is.  I’m guessing the response was: “Well, there are a number of different options and since everyone is different, it’s really what works best for you.”

When it comes to ordering, you’re not unique or special.  You’re just like everyone else.  Actually, you’re just like everyone else in a lot of ways, but this post is on ordering.  Everyone is trying to accomplish the same job:

When a patient shows up for a test, we need to figure out what the patient is here for, why they are here for it and what account we are charging this to.

The job itself is pretty simple, but the way the system was designed actually makes it quite difficult. Previously, the patient would hand over a piece of paper with all the information on it.  Now, the information is supposed to be in the system…somewhere.  I’ll divide this into two parts first and as they are defined in the system:  Lab Orders and Imaging Orders.

A quick walkthrough of the flow of orders first.  Each AOM Procedure is mapped to an OE Procedure which is then mapped to either a Lab Test or a test in ITS (or RAD).  In order for an order to leave AOM and go to OE, it needs a priority, a service date, a performing location and any queries required in OE to be answered.  Visual below:

Lab Orders: These orders should always be sent to your hospital Lab location when being placed.  Regardless of if the patient stops in at a lab in the clinic (blood draw, urine, etc.) the processing of the order is being sent to the hospital in MEDITECH terms.  You can still print labels to the appropriate place in this set up within the LAB module dictionaries based on the test that is being ordered.  Printing labels automatically on the date of service is handy for all orders being performed the same day they are placed.  However, for future orders, it may become a minor pain as we shall see.  For future Lab orders, there is typically no scheduled date that the patient will come in on.  In AOM, the Service Date dictionary allows you to specify intended services dates for an order.  This assists on the clinic side by being able to set up Overdue Ambulatory Orders to appear on the users’ workloads if the patient never comes in during the intended timeframe.  However, what gets sent to OE/LAB is the date defined in the Service Date dictionary.  So if you define “Within 1 Week” as 7 days.   A service date of 7 days from today is applied to the order.  Therefore, in 7 days, that label is going to print in at the Lab whether the patient has shown up or not.  The system was designed for orders that are performed on specific dates…which rarely happens in the Lab world.  Labels printing when patients haven’t shown up yet will happen so far, so based on the frequency of that event in your lab you have to determine whether you want labels to print automatically or to have users force print the label when the patient shows up.

Now let’s consider accounts.  All same-day orders should be set up to create a REG CLI account.  These aren’t the issue.  Future orders should be held in AOM and set up to create a PRE CLI account.  By being held in AOM, the orders now get put on a queue in LAB called Pending AOM Orders.  There is a routine in LAB when the user brings up the requisition that prompts the user to add any of the outstanding AOM orders that the patient has to the account that they are working on.  No set up to get that routine, just hold the orders in AOM.  If multiple accounts were created (more on that in a bit) then using this routine by-passes some confusion.  So this accomplishes two of the three parts of the job needing to be done: What is the patient here for?  And What account are we putting this on?  The third part, Why are these tests being done? is still outstanding.

Multiple accounts:  When orders for the same day are placed from an encounter, a single hospital account is created. This is also true when orders for future dates (regardless if they are different) are placed.  They create a single hospital account.  If you mix and match, you could have one account created for same day orders and one created for future orders.  Problems arise, when additional orders need to be placed or orders need to be changed.  As long as the user goes back to that EAR Encounter and makes changes or adds new orders, then the existing accounts will be used.  However, if the Find Patient routine is used or the patient’s orders are accessed another way outside of that original encounter, a new account will be created (you will see this as an Order Generated Note if not ordered from an existing encounter).

I promise I’ll come back to finding out why the patient is needing the tests (aka the diagnosis).

Imaging Orders: These orders should be set to not be held in AOM and go straight on through.  Hold them in OE though.  Why? For the most part they are scheduled.  If the nurse typically schedules these for the patient, they can add in the service date before the patient leaves.  If the patient schedules them a service date that equates to a far off future date can be used so the order doesn’t drop into ITS (or RAD) before that patient remembers to schedule it.  The scheduling staff will take the account created by placing the order and modify as needed.  Then it won’t drop into ITS (or RAD) until the date of service.  Yes, if the appointment date is modified, that doesn’t flow back to AOM, but that’s a minor nuisance that you have to live with.  ITS and RAD don’t have a Pending AOM Orders routine like LAB so you have to use the routine that allows you to transfer orders to different accounts if there’s a mix-up situation for multiple orders.  LAB also has this routine, but the Pending AOM Orders should circumvent the need to use it.  The multiple orders considerations that I mentioned above for Lab orders, applies to Imaging orders as well.  So that also takes care of 2/3 of the job: they’ll know what the patient is there for when they show up and what account to put it on.

Quick note on setting up Pending Appointments through OE and SCH.  Don’t.  It’s superfluous and probably a waste of your time.

That leaves the question of Why is the patient getting this test done?  In the MEDITECH/LSS world, the diagnosis on the order doesn’t flow over to OE and thus, not to LAB or ITS/RAD.  The Visit Reason does for some unknown reason, but that important thing, the Dx does not.  Lots of people over the years have complained about this, but it still isn’t changed.  This is why most people trying to use this functionality still send over a paper order that has the Dx on it.  The only alternative to this is to either create a report that can be run on demand that shows this information or try and get a custom ($$$).

In summary, hold future Lab orders in AOM and let the Imaging orders go through.  The one thing that implementations forget to do that compounds this already difficult task is to walk through the entire order process and all scenarios with the people who are using SCH/ADM, LAB, OE and ITS(RAD). Sit down with everyone at the same time and talk about it.  Just remember, setting up this functionality really is that difficult.  And no matter what your specialist tells you, you’re not special.  You are just like everyone else.