Tips for Avoiding Some Common Order-Entry Problems
By Cathy Welsh, MS, RD
As a former
patient services manager turned clinical informatics analyst, I would like to
share some considerations when planning your diet database to help avoid some
common order-entry problems.
Should you have a few subcategories of orders?
flexibility, you should build in a few subcategories. The primary category of
your food service orders is meals. These are continuing orders. Diet orders
start when entered and do not end until discharge. Create another category for
specialty or one-time orders, such as “Birthday Cake” or “Test Tray.”
can determine access to enter, or even see, diet orders. You may decide that
diet technicians can enter specialty items, but not meals.
also are used to design reports. This reporting can take place in the medical
record itself, such as a special page or view, or in a printout. You might want
your diet census to print everything, but for a special view, such as a nursing
Kardex in the electronic medical record, you might want to only display meals.
2. How are
clinicians going to find your diets?
primary descriptions or synonyms. To ease order entry, make a synonym for each
diet order that begins with the term “Diet,” as in “Diet, Regular.” With one
word, the user can easily review your diet list for as many orders that fill
the order window. If you have more diets than that, that is another story!
does your diet order look like?
Consistency is the key. The basic style or format of each
diet order should have common features—a description, a start and stop time,
duration, special instructions, and comments. More new details mean more
formats. From a maintenance perspective, the fewer formats the better. How do
you decide what kind of field to use?
Pick list (codeset or drop-down fields): These lists
of values are used again and again. A good example is the values of calorie
levels in your diabetic diets, such as 1200, 1500, and 1800. Having a free-text
or even numeric field could lead to order entry errors and take more time, such
as a 1408-calorie diet. Make you pick lists short enough, so you can see them
Numeric fields: A good use is for sodium
restriction. Numeric fields can have decimal values, but for simplicity’s sake,
stick with integer (whole number) fields to avoid 2.75-milligram sodium diet
or “No” fields: Choose labels for Yes/No fields carefully. On calorie-restricted
diets, add a “Diet Snack Needed at Bedtime” order detail as a Yes/No field. If
the clinician selects “Yes,” then the order says that. If “No” is selected,
then the order details could say “No Diet Snack Needed at Bedtime” or nothing.
Free text: You want to
give the clinicians some flexibility, so the best approach is to keep it
standardized. Offer a “Special Instructions” field on each diet-order format. A
common free-text order field size is 255 characters. If more space than that is
needed, the clinician should just order a consult!
4. How can
you avoid having multiple active diet orders with clinician order entry?
sometimes is challenging. The question is, whose job is it to reconcile orders?
Use these tips to help minimize the situation.
Put the “duplicate checking” settings on your meal orders to
warn that the patient has a current active diet order, and present a window to
cancel. Or set meal orders to reject when duplicated. This way you are unable
to enter new diet orders until the other order is cancelled.
Combinations: Build all the standard combination
combinations into one order, such as Low Protein, Low Sodium, Low Potassium, and
Cancelling orders: Encourage staff to cancel
orders that no longer apply.
Durations: Encourage the setting of “durations”
on diet orders. For example you can build order sets for progressive diets,
where you have a regular diet ending at midnight and the NPO order beginning
just after midnight.
resuming a diet: Train staff to use an order action to “suspend”
a diet while the patient is away for a procedure and then to “resume” the diet
when the patient returns.