If you work in Clinical Informatics, you probably have a lot of experience with order sets.
Order sets offer great opportunity, and can really help streamline clinical processes and create predictable outcomes. Since they are a part of the medical record that every doctor uses (like Larry Weed, MD once said), they can help guide and teach. In my 13 years of designing them, I’ve seen remarkable standardization in processes, reduction in variation, and improved outcomes when they are designed well.
For those who design and build them, however, here are the five most common challenges:
- People without solid order set experience often don’t budget properly for them, either from a time or resources perspective. (They often take more work than most people would initially imagine.)
- Doing them well often requires a great deal of effort and coordination between multiple clinical stakeholders, including physicians, nurses, pharmacists, and often other ancillary services, operational leaders, finance, legal/compliance, etc.
- It’s not just the effort to create them — it’s also the effort to maintain
- People often disagree about the best way to create, review, test, approve, and publish them.
- Managing expectations can take time, especially when they’re being used to solve complex training/education or utilization problems.
There are actually best practices for developing them, but they’re often not well-understood. It takes time to build them in a collaborative manner, to help ensure the best outcomes: Order sets that physicians will actually use, predictably, to achieve predictable outcomes.
My CMIO colleague Paul Fu, MD from UCLA recently shared a tweet about an EMR order for ‘birthday cake,’ presumably from a pediatric hospital that had actually had built an order for pediatric patients who could tolerate a piece of birthday cake on their birthday.
While several Clinical Informatics friends chimed in to comment, I took the opportunity to create a tongue-in-cheek, general-purpose Ice Cream Order Set (found at the bottom of this page) that could actually be used for teaching and discussion purposes. This [DRAFT] order set example above basically lets you prepare ice cream for your TV binge-watching purposes. Remember, it’s not a real order set; it’s a decent teaching example to show just how complicated and workflow-dependent order set design can be.
You’ll notice that it’s a general-purpose ice-cream order set, addressing some common scenarios:
- It’s fairly flexible, allowing you to eat as little as a single scoop in a bowl or cup, or as much as multiple pints.
- It does a decent job addressing common allergies (lactose, peanut, dairy, etc.)
- It uses fairly standardized units of measurement, which are reasonable for most ice-cream consumption purposes.
- It lets you select a number of toppings, and even finishes with a cherry on top.
You’ll also notice that it has some limitations:
- It only offers three flavors: chocolate, strawberry, and vanilla. (Imagine trying to index an order set to offer more complex flavor combinations?)
- While it has decision-support built in to help guide an ordering provider to the right choices, it does require a doctor to order the ice cream differently, depending on the utensils and container (i.e., cup/bowl versus the ice-cream container).
- Some Clinical Informatics friends have suggested it should have alerts and hard-stops for people with certain food allergies (g. should you be able to order peanuts if you have a peanut allergy?)
Of course, it’s just ice-cream, but the order set is still fairly complex, and required the development of a new term (‘unique container’) to address the ordering workflow related to eating from bowls/cups versus the ice-cream container. Imagine creating order sets for complex or high-risk clinical workflows.
What would you do to make this order set easier or offer more flavors? Do you have any tips or feedback about order set development or maintenance?