CPOE and Building a Well-Indexed Order Set Catalog

Hi fellow Clinical Informaticists and other #HealthIT leaders,

Sorry, it's been a while since I've been able to blog much. Been very busy recently, engaging physicians, APRNs/PAs, residents, nurses, pharmacists, and other clinical leaders. Since I had a few free minutes this holiday season, I just wanted to take the time to offer some insights into the links between Computerized Provider Order Entry (CPOE) and order set design and strategy.

Developing a good order set strategy can sometimes take a while. Many organizations go through a gradual learning curve, which unfortunately, can sometimes take years. In general, some organizations will start their CPOE journey with a rudimentary strategy, often based only on the popular med-school mnemonic 'ADCVANDISMAL', that can sometimes leave providers unhappy with their early CPOE exposure. Some hints that an organization may be at the beginning of their order set design journey : 

1. The doctors are using 'ADCVANDISMAL' or pre-existing paper order sets as the only guidelines for building their new electronic order sets.
2. Order sets are quite long, sometimes several (2-3) pages.
3. Providers find themselves spending time searching through these long order sets, looking for the two or three orders they want to place at a particular moment, or using the same order set over-and-over for different clinical scenarios.
4. Providers might have somewhere between 2-4 order sets that they use for all of their ordering needs.
5. There is limited use of headers above sections of orders, to give providers guidance about when to check (or uncheck) an order.
6. There is limited use of pre-checked orders.
7. Providers might complain about 'long order sets', clunky order sets' or 'too many alerts'.
8. Order set names are non-standard format (e.g. one catalog has order sets named "Pneumonia Admission Order Set" and "Hospitalist General Admit order set" and "ED Pneumonia", all in the same catalog.)

Gradually, through trial-and-error, some organizations learn that good order set design takes real work and very detailed planning. So I'd like to offer you a way for you to develop what I call a "well-indexed order set catalog strategy", before you begin your CPOE journey. 

(Remember, providers will want a good experience when they start CPOE - Giving them bad order set design will color their first experiences with CPOE!)

Before we begin, let me warn you that there may be other strategies that may work better for your organization. The strategy described below may work, but it may not be ideal for your organization - especially if you already have a starkly different strategy, in which case there may be a serious learning curve for your providers. Read on, and judge for yourself - But always make sure you check with your local informatics professionals before designing an order set strategy for your organization.

ONE WAY TO DEVELOP YOUR NEW ORDER SET STRATEGY :
To develop a stronger order set strategy, it's helpful to start with a good working definition of the term "order set". Although published definitions can vary (see the ISMP Guidelines for Standard Order Sets), there is a simpler one I can offer up, that still works very well from a functional standpoint : 

"Order set (n.) - a collection of orders used to standardize and expedite the ordering process for a common clinical scenario."

Take a good look at the above definition. Does it work for you? Simple and effective, but before we move on, make sure it looks good for you.

If you think that's fairly reasonable, then let's build an index on this definition. If the concept of "order set" is linked, by this definition, to the concept of "common clinical scenario", then what exactly are common clinical scenarios? 

In addition to good listening, and displaying compassion and empathy, physicians/providers generally have two things they do to actively help patients - Either do a procedure, or write an order. Since we're talking about the orders that physicians/providers write, what are the common clinical scenarios that these orders are used for? The common ones seen in most organizations : 

1. Admitting a patient
2. Transferring a patient 
3. Discharging a patient
4. Working up a complaint or condition
5. Treating a diagnosis
6. Pre-operative or pre-procedure care
7. Post-procedure or post-operative care
8. Protocols - (Allowing registered nurses, pharmacists, or other licensed medical professionals to act on an order or orders on behalf of the ordering provider or attending physician)
9. Other (for those things not in 1-8 above)

So now take a look at the above 9 scenarios. Do they work for you? If they still seem reasonable, then you can then use them to build out your new order set index : 

1. ADMIT - To admit an adult patient to an inpatient level-of-care
2. TRANSFER - To transfer an adult patient to another inpatient level-of-care
3. DISCHARGE - To discharge an adult patient from an inpatient level-of-care to home
4. WORKUP - To work up a common chief complaint (e.g. SOB, abd pain, fever, etc)
5. TREATMENT - To treat a common diagnosis (often the top 50 DRGs)
6. PRE-OP - To treat a patient about to undergo a procedure
7. POST-OP - To treat an adult patient after a procedure
8. PROTOCOLS - To allow a registered nurse, pharmacist, or other licensed medical professional to start/modify/stop an order (or orders) on behalf of a Licensed Independent Practitioner (LIP), Physician Assistant (PA), or resident. (E.g. Med titration protocols, dietary interchange protocols, vent liberation protocols)
9. OTHER ('Convenience Panels') - For other common clinical scenarios not outlined in 1-8 above (e.g. Routine pain control, Anti-Emetics, Sleep Agents, Blood Transfusion, etc.)

You'll notice that for the above nine chapters, these all typically refer only to ADULT patients. Pediatric patients, generally, have different diseases, different complaints, different workups, and different drug dosages (usually with weight-based dosing) - So if you have both adult and pediatric patients, you could potentially have an index that looks like this :

A. ADULT LIBRARY

1. ADMISSION ORDER SETS
2. TRANSFER ORDER SETS
3. DISCHARGE ORDER SETS
4. WORKUP ORDER SETS
5. TREATMENT ORDER SETS
6. PRE-PROCEDURE ORDER SETS
7. POST-PROCEDURE ORDER SETS
8. PROTOCOLS
9. OTHER (CONVENIENCE PANELS) ORDER SETS

B. PEDIATRIC LIBRARY

1. ADMISSION ORDER SETS
2. TRANSFER ORDER SETS
3. DISCHARGE ORDER SETS
4. WORKUP ORDER SETS
5. TREATMENT ORDER SETS
6. PRE-PROCEDURE ORDER SETS
7. POST-PROCEDURE ORDER SETS
8. PROTOCOLS
9. OTHER (CONVENIENCE PANELS) ORDER SETS

Using this hierarchy, you can then start to build out the catalog - I'll use only the adult catalog as an example : 

A. ADULT LIBRARY

1. ADMISSION ORDER SETS

• ADMIT TO MED/SURG
• ADMIT TO TELEMETRY
• ADMIT TO ICU
• ADMIT TO LABOR AND DELIVERY
• ADMIT TO PSYCHIATRY
• ADMIT TO SURGICAL DAYCARE
• ADMIT TO MEDICAL DAYCARE 

2. TRANSFER ORDER SETS 

• TRANSFER TO MED/SURG
• TRANSFER TO TELEMETRY
• TRANSFER TO ICU
• TRANSFER TO LABOR AND DELIVERY
• TRANSFER TO PSYCHIATRY
• TRANSFER TO SURGICAL DAYCARE
• TRANSFER TO MEDICAL DAYCARE

3. DISCHARGE ORDER SETS

• DISCHARGE FROM MED/SURG
• DISCHARGE FROM TELEMETRY
• DISCHARGE FROM ICU
• DISCHARGE FROM LABOR AND DELIVERY
• DISCHARGE FROM PSYCHIATRY
• DISCHARGE FROM SURGICAL DAYCARE
• DISCHARGE FROM MEDICAL DAYCARE

4. WORKUP ORDER SETS (based on chief complaints)

• WORKUP - ABDOMINAL PAIN
• WORKUP - AMENHORRHEA
• WORKUP - BACK PAIN 
• WORKUP - CHEST PAIN
• WORKUP - CONFUSION
• WORKUP - COUGH
• WORKUP - FEVER
• WORKUP - GI BLEEDING
• WORKUP - HEADACHE
• WORKUP - SUSPECTED HYPERCOAGULABLE DISORDER
• ...
• WORKUP - OTHER 
• WORKUP - SHORTNESS OF BREATH 
• WORKUP - SWOLLEN EXTREMITY
• WORKUP - SYNCOPE 
• WORKUP - TICK BITE 
• WORKUP - VAGINAL BLEEDING

5. TREATMENT ORDER SETS (based on common diagnoses or DRG)

• TREATMENT - ACS - UNSTABLE ANGINA/NSTEMI
• TREATMENT - ACS - STEMI
• TREATMENT - AFIB WITH RVR
• TREATMENT - ANAPHYLAXIS
• TREATMENT - ASTHMA EXACERBATION
• TREATMENT - BACK PAIN 
• TREATMENT - CELLULITIS
• TREATMENT - CHF EXACERBATION
• TREATMENT - COPD EXACERBATION
• TREATMENT - FEVER
• TREATMENT - GI BLEEDING
• TREATMENT - HEADACHE
• ...
• TREATMENT - PNEUMONIA - HCAP
• TREATMENT - PNEUMONIA - ASPIRATION  
• TREATMENT - STROKE 
• TREATMENT - SWOLLEN EXTREMITY
• TREATMENT - SYNCOPE 
• TREATMENT - VAGINAL BLEEDING

6. PRE-OP AND PRE-PROCEDURE ORDER SETS (based on procedures)

• PREProcedure - CARDIOVERSION
• PREProcedure - CENTRAL LINE PLACEMENT
• PREProcedure - HEMODIALYSIS
• PREProcedure - INTUBATION
• PREProcedure - PARACENTESIS
• PREProcedure - THORACENTESIS
• PREop - APPENDECTOMY
• PREop - ARTHROPLASTY
• PREop - KYPHOPLASTY

7. POST-OP AND POST-PROCEDURE ORDER SETS (based on procedures)

• POSTProcedure - CARDIOVERSION
• POSTProcedure - CENTRAL LINE PLACEMENT
• POSTProcedure - HEMODIALYSIS
• POSTProcedure - INTUBATION
• POSTProcedure - PARACENTESIS
• POSTProcedure - THORACENTESIS
• POSTop - APPENDECTOMY
• POSTop - ARTHROPLASTY
• POSTop - KYPHOPLASTY

8. PROTOCOLS (allowing a registered nurse, pharmacist, or other licensed medical professional to START/MODIFY/STOP an order or orders on behalf of a Licensed Independent Practioner (LIP), Physician Assistant (PA), or resident.) 

• PROTOCOL - HEPARIN TITRATION PROTOCOL
• PROTOCOL - INSULIN TITRATION (DKA/HNK) PROTOCOL
• PROTOCOL - CARDIZEM TITRATION
• PROTOCOL - PROPOFOL TITRATION 
• PROTOCOL - ALCOHOL WITHDRAWAL
• PROTOCOL - MASSIVE TRANSFUSION PROTOCOL
• PROTOCOL - VENTILATOR LIBERATION

9. OTHER ('CONVENIENCE PANEL') ORDER SETS - For those common clinical scenarios not outlined in #1-8 above, also helpful for using as building blocks in other order sets (e.g. having a routine pain management panel in your admission order set)

• CONVENIENCE - Routine Pain Management
• CONVENIENCE - Routine Anti-Emetics
• CONVENIENCE - Routine Bowel Regimen
• CONVENIENCE - Routine Sleep Management
• CONVENIENCE - Routine Glycemic Control 
• CONVENIENCE - Routine VTE Prophylaxis 
• CONVENIENCE - Routine Blood Transfusion

Having this well-stratified an index will let you build small, short order sets, with only a few orders in each order set. The benefits of such a strategy :  

1. Shorter, faster order sets which can often be pre-clicked (in many scenarios, depending on your local policies), and pre-built with better decision support to better guide providers to better choices.
2. Fewer duplicate-order, duplicate-therapy, and drug-drug interaction alerts = Less alert fatigue.
3. Better ability to share order sets among specialties - Why should the workup for chest pain be different in the ED than on the floor? If one provider builds an order set, shouldn't everyone benefit? 
4. Faster build time and easier maintenance - Need to make sure all admissions to med/surg have a code status order? Only one order set needs fixing, not twenty.
5. Faster CPOE - Docs can breeze through an order set tailored to exactly the clinical scenario they are trying to address

And the disadvantages of this strategy? Your providers will use more order sets, and so having them go through the catalog to select their favorites and use them may take a few more clicks than if they just have 2-3 order sets that they use for everything. But you can always build synonyms that help speed up the alpha-search for these order sets, and I do believe that the many benefits outweigh this small disadvantage.

Of course, if this is a significant deviation from your current strategy, you will want to engage your local leadership to review this strategy, think about the cost of re-training your docs, and going forward with such a new strategy. And if you already have such a strategy - Congrats!

In closing - I hope this has been an interesting discussion on order set indexing, and how it impacts the naming convention, speed of ordering, ability to custom-design decision support, physician/provider experience with CPOE, and ultimately, the ability to continuously encourage physicians to deliver better, evidence-based, updated best practices. 

Thanks for taking the time to read this, and I hope everyone is looking forward to 2017 and what it will bring the #HealthIT and #Informatics communities!

This post is for discussion and educational purposes only - Always consult your local informatics professionals before deciding to adopt an order set strategy. Have any thoughts, comments or feedback? Or want to share your own order set indexing strategy? Feel free to leave them in the comments section below!

What exactly is "Alert Fatigue"?

Clinical Decision Support (CDS) - It's the mythical creature that every healthcare administrator and informaticist is hunting, to help reduce costs and improve care. Loosely, it can be broken into a few different areas :

1. Electronic decision support (e.g. CPOE Alerts to help prevent errors)
2. Order / order set design (e.g. to help prevent errors / guide docs to evidence-based care)
3. Workflow/documentation redesign (e.g. tools used to standardize high-risk decisions, e.g. procedure checklists)
4. Workflow/protocol design (e.g. tools used to automate high-risk procedures)

One of the hardest to tackle is #1 - CPOE Alerts. Are there too many, or too few? Everyone I know seems to be struggling with the same issue :

• Wanting to provide CPOE alerts to avoid errors, but
• Providing "too many alerts" could cause docs to ignore the "important alerts".

This phenomenon is loosely called alert fatigue, and has been fairly well-documented in literature as, paradoxically, a potential risk. 

When you hear Informatics professionals discuss alert fatigue, the challenging part is actually knowing when alert fatigue exists. Docs sometimes complain about it, but the response docs get to this is often skepticism - After all, how can an alert be bad? Maybe the doc just complains too much? And who is going to turn off the alert? Is it safe to turn off the alert? What if this opens up other problems? When is it too much? When is it too little?

So when you ask docs to define alert fatigue, they typically use general, loose definitions, like :

• "It's when the system gives me too much information and I miss the important stuff."
• "It's when the system tells me about the Tylenol interacting with Colace, but I miss out on the Coumadin/Bactrim interaction."
• "It's when I can't read all of the alerts."
• "It's when I just keep clicking 'Bypass' without actually reading the alert."
• "It's when I just keep clicking 'Acknowledge' without actually reading the alert."
• "It's when I click 'bypass' within 3 seconds, so I know I didn't read the alert."

And recently, when I asked some informatics colleagues for their definition of alert fatigue, I again got a myriad of responses, followed by the same sort of response Supreme Court Justice Potter Stewart gave in 1964, when defining "obscenity" in the Jacobellis v. Ohio case : "I know it when I see it."

Unfortunately, this doesn't help much for those of us who are really working to combat alert fatigue. 

The problem with all of these definitions is that they are fairly loose and subjective, and don't make a good litmus test to answer the question : Do you have alert fatigue?

So I'm going to use some reason and inference, to try to develop a better definition of alert fatigue that is quantifiable. (I used to be a mathematician/statistician, so please forgive the quasi-mathematical approach.)

Since it seems the "undesired scenario" nobody wants is made up of two steps :

• An EMR providing a confusing alert environment, and
• A doc displaying signs of poor response to that environment

So I'd like to submit two proofs, for two conditions which then go into a third proof. Here they are :

PROOF1 : "AlertOverload"

1. [AlertOverload] = [Bad] > [Good]

2. [AlertOverload] = [Noise] > [Signal] 

3. [AlertOverload] = [Low-value alerts] > [High-value alerts]

4. [AlertOverload] = [Low-risk alerts] > [High-risk alerts] 

5. [AlertOverload] = [# of low-risk alerts] > [# of high-risk alerts] 

6. [AlertOverload] = [Number of low-risk alerts in a time period] > [Number of high-risk alerts in a time period]

7. [AlertOverload] = When the number of low-risk alerts exceeds the number of high-risk alerts for a given physician in a given time period

PROOF2 : "AlertLoss"

1. [AlertLoss] = [Bad] > [Good]

2. [AlertLoss] = [BypassedAlert] > [AcknowledgedAlert] 

3. [AlertLoss] = [Number of bypassed alerts in a given time period] > [Number of acknowledged alerts in a given time period] 

4. [AlertLoss] = When the number of bypassed alerts exceeds the number of acknowledged alerts in a given time period

If one were to accept proof #1 and #2 as true, then I would propose this final proof/definition of AlertFatigue :

PROOF3 : "AlertFatigue"

1. [Bad] = [Bad] 

2. [AlertFatigue] = [Bad]

3. [AlertFatigue] = [AlertOverload] + [AlertLoss] 

4. [AlertFatigue] = Exists when a given physician experiences [AlertOverload] and displays [AlertLoss] in a given time period

So voila - My proposed definitions :

1. Alert Overload = When the number of low-risk alerts exceeds the number of high-risk alerts for a given physician in a given time period
2. Alert Loss = When the number of bypassed alerts exceeds the number of acknowledged alerts in a given time period
3. Alert Fatigue = "When a given physician experiences alert overload and displays evidence of alert loss in a given time period."

It's certainly not a universally-recognized definition, and I'm curious if other people are aware of any other professional, practical, policy-grade definitions that exist out there. Obviously, this definition now needs to be peer reviewed, tested, validated, and professionally accepted, so please don't use it in your own organization without consulting a legal professional, informatics professional, and your local regulatory agencies first.

Remember : As always, this discussion is for educational purposes only! Remember, your mileage may vary! Always enjoy thoughts, comments, and ideas!