Learn about front-line clinical informatics, clinical workflow design, and EMR implementation with an experienced CMIO. Open discussion is encouraged, education is a priority. All opinions are strictly my own.

Tuesday, August 31, 2010

I've recently been paying a lot of attention to the cost of hidden and embedded protocols in healthcare. When physicians argue about the efficiency of EMRs, I think this is really what they're talking about.

Let me explain.

Know that tool we commonly use in healthcare, known as the "clinical protocol"? Common examples of this tool found in most hospitals include the "heparin protocol", the "insulin protocol", and the "STEMI protocol". You've probably heard of them.

So what exactly is a protocol?

A protocol is a set of well-defined care instructions and conditional statements which allow nurses, pharmacists, respiratory therapists, and other licensed medical professionals to initiate, modify, or discontinue an order, on behalf of the ordering physician, as instructed by the protocol. Any conditional statements (IF/THEN arguments) in a protocol should refer to a discrete, well-defined data element. Protocols are primarily activated/deactivated by a physician order, but may in rare instances be activated by a clinical policy in situations where regulatory laws permit (e.g. "pharmacy substitutions" are a common protocol/policy combination). Protocols are typically published through a printshop or an electronic site.

Where did that definition come from? CMS? Joint Commission? Neither. I actually penned it. It probably could use work, but it's a start, and since neither AMIA, HIMSS, Joint Commission, or CMS endorses a particular definition of this tool, I had to write it myself. (Feel free to use the definition for your own uses, and comments are definitely welcome!)

Protocols are generally loved by physicians - They generally allow other healthcare professionals to automate a process on behalf of the physician. The Heparin protocol allows nurses to titrate heparin on their own. Respiratory protocols generally allow a respiratory therapist to manage a vent automatically. And so on.

And here's the surprise : Protocols are sometimes found in many more places than just those sheets.

I think the easiest way to spot a protocol hiding somewhere else is the reference to a conditional statement - An IF/THEN - That allows someone to initiate, modify, or discontinue an order on behalf of the physician who ordered the protocol, as defined by the protocol.

So if you use the "IF/THEN" as your guide, try taking a look at your old paper order sets - you may be surprised when you start to notice a bunch of conditional statements (hidden protocols) in them, such as :

1. "Advance diet as tolerated"

2. "Out of bed as tolerated"

3. "These orders are only supposed to be active in the _______ department."

4. "Titrate sedation for comfort".

5. "Use this drug, unless patient is allergic, then use this other drug" (or some variation of that theme...)

From an engineering standpoint - Having all of these little pieces of embedded protocols hidden in your order sets makes it very difficult to convert a paper order set to the electronic form. Why?

Because computers are unforgiving.

Electronic Order sets generally go in one specific section of your EMR.

PaperOrder sets can have "IF/THEN" and other conditional statements in them.

Q : "So Dirk, what exactly is the cost issue then?"

Here's the challenge : In converting paper order sets to electronic order sets, often, depending on the design, you have to decide what to do with these hidden embedded protocols.

You basically have two choices :

Develop the protocol, but this often takes a significant amount of time and committee and policy work, OR....

You simply leave the protocol out of the new electronic order set.

What ends up happening, often? Order set designers are forced to simply leave out most of these conditional orders (embedded protocols) in the new electronic world.

As a result, this is why, often, the electronic order sets :

Don't LOOK like the paper order sets.

Don't FUNCTION like the paper order sets.

Q: "So Dirk, again, where's the cost issue?"

Well, here it is : If your electronic order sets have been stripped of all of the hidden, embedded protocols found in your paper order sets -

Then your physicians, on "going electronic", may notice many more phone calls from nurses looking to clarify orders that were previously initiated, modified, or discontinued by these embedded protocols.

And you may notice efficiency changes after you "go electronic".

Q : "Wow. And is there any way to help avoid this?"

It takes a lot of work, but fixing this "hidden protocol cost of EMR implementation" will depend on various factors :

How many "hidden protocols" you had in your paper order sets, to begin with. (They generally appear more often in specialties that are not in-house 24/7.)

How reliable your protocol framework is.

How efficient your committees are at examining protocols for safety and approving them.

Your informatics resources, to analyze the workflows, and re-engineering those protocols absolutely necessary for safe workflow to continue.

The cost of not fixing it? Your physicians may sense a significant slowdown after your EMR go-live.

This is where the lack of a Joint Commission-endorsed, or CMS-endorsed definition, causes a problem. By not having a standard definition for hospitals to work with, many protocols go hidden in policies and order sets. (When there isn't a good definition for a protocol, it's easy to engineer them into the wrong tools.)

Avoid the problem by :

Trying to avoid these hidden, embedded protocols in your paper order sets, as much as possible.

Having a robust informatics platformbefore your EMR and CPOE and documentation go-live dates, to help analyze the paper order sets and begin re-engineering those protocols that are absolutely essential for proper functioning of your hospital.

Making sure your committee structure can analyze these necessary protocols for safety, and approve them in a timely manner.

Thursday, August 26, 2010

Another change I've noticed in hospitals that "go electronic", especially private hospitals (those without residents), is that the training needs are often hard to meet. I've heard this from several other CMIOs that I speak with.

The training needs for a hospital with an EMR are challenging. Not only is there the initial training (that most software vendors supply at your go-live), there is the training for every new physician you hire, and then there are training needs every time you update your software. In hospitals which employ a best-of-breed approach, which often have many clinical systems, sometimes the training challenges can be daunting.

So it's important for every CMIO to keep tabs of the "minimum training requirement" - That is, what does it take to initiate a new physician to your electronic environment?

Often, especially in a best-of-breed setting, it also means tailoring the training to the specific needs of the physician's clinical specialty.

The challenge, however, is that this training is often no small task. It's not unusual for it to take 3-5 hours as you introduce a new physician to :

Your overall electronic landscape and their passwords / accounts

Your key workflows that they will be operating in. (The main workflows are important, because they help a new physician trouble-shoot when a portion of the delivery system gets delayed)

Your particular EMR, Order Sets, CPOE, and Electronic Documentation

Any ancillary systems you may use (e.g. Dictation, Radiology, Billing, etc.)

The difficulty often arises, then, when you have a moonlighter who doesn't prepare for this training time. I'm not sure how the big staffing companies handle this in their contracts, but it seems many companies provide coverage with little advanced notice.

But how will you handle a moonlighter who shows up on the day they are supposed to provide coverage? Or what if you only use the moonlighter "in emergencies"? Or what if the moonlighter only works in your organization once every 3-4 months?

I think, in general, that moonlighting companies will need to respond to the pressures of increased EMR adoption by either :

1. Budgeting and writing contracts that allow the moonlighter for the necessary training time.

2. Perhaps allowing hospitals some preference for moonlighters who have experience with "their EMR"?

Will doctors start adding their EMR experience to their CVs, as a hiring qualification?

The EMR shadow is cast well-beyond the boundaries of the hospital setting! :)

Wednesday, August 18, 2010

So as someone who thinks a lot about the informational flows behind a hospital's day-to-day operations, I read a lot about people who are having challenges with "EMR governance issues".

The governance issues you hear about are basically related to change management and implementation issues. After you have an EMR, your training needs expand dramatically. You may need to engineer your paperwork differently. You have workflow issues to contend with, and decision support issues to tackle.

And the committee structure you had before your EMR may not hold up under the new workload demands. Make too small a committee, and you may not get the right input. Make too large a committee, and you may never be able to make a decision.

If the committee charters aren't well-designed, some committees will be overburdened, while others are looking for work to do.

And if you don't have the support to implement your basic tools, then the "ejection fraction" of your committees will drop. (E.g. the committee will decide on a new policy, but if nobody knows about the new policy, then the committee can make lots of decisions that don't really get executed on the floor.)

In short - it helps if you lay out a strategy for how to deal with all of these issues.

So I created this simple little tool, to help a CMIO (or CMIO-like person) figure out how to help orchestrate the "overhaul" to meet your new needs. I affectionately call it, "The CMIO's Checklist". (See the spreadsheet above for an idea of how to build your own.)

With this tool, you first have to come up with a list of your common paperwork design challenges. As an example, most hospitals generally struggle with the timely design, testing, approval, publication, and implementation of the following :

Procedures - Tools which include the detailed steps on how to achieve an organizational standard or defined goal. Typically published attached to a policy statement or in a separate procedure manual.

Guidelines - Tools more flexible and negotiable than a policy that are used to outline desired actions and outcomes of therapy.

Clinical Protocols (ON/OFF) - Tools used to standardize and automate care for a common clinical scenario, containing those conditional (IF/THEN) statements that allow a nurse, pharmacist, or other licensed medical professional to start / modify / stop a patient care order on behalf of a physician. All conditional (IF/THEN) statements in a protocol should refer to a discrete, well-defined data element. Protocols are primarily activated/deactivated by a physician order, or in some scenarios by a clinical policy. Common examples include : Heparin Protocol, alcohol protocol, PPI substitution protocol, etc. Protocols are typically published through a printshop or an electronic site.

Order Sets - Tools which include a grouping of orders which can be started / modified / stopped by a physician, used to standardize and expedite the ordering process for a common clinical scenario. Typically categorized as either admission order sets, diagnosis order sets, or convenience order sets, and commonly published either through a printshop or an EMR.

Orders - Tools used to instruct a licensed person to deliver a defined type of care to a defined patient at a defined time in a defined manner for a defined duration. Medication orders, referring to the delivery of medications, are typically compiled in a medication formulary and are commonly published via printshop, electronic site, or EMR.

Clinical Documentation - Tools used to record and sometimes transmit information about a patient's history, activities, therapies, and responses in time, legally authenticated by a licensed medical professional. Commonly includes notes, checklists, forms, flowsheets, tables, fields, images, movies, and other media. Clinical documentation is typically published through a printshop or an EMR.

Templates - Tools that help expedite and standardize the creation of a document.

Staff Education Modules - Tools used to educate staff about a common clinical scenario, often including text, slides, videos, recordings, and other media. All staff education modules will include at least three competency questions. Typically published through a printshop or an electronic site.

Patient Education Modules - Tools used to educate patients about a common clinical condition or activity, often including text, slides, videos, recordings, and other media. Follow-up questionnaires are recommended. Typically published through a printshop or an electronic site.

Staff Schedules - A tool used to define which staff member(s) is/are responsible for a specific type of care at a defined date and time. Typically published through a printshop or an electronic site.

Then, going down the left-hand border of the CMIO checklist spreadsheet, are the following questions that everyone goes through when creating any tool:

Who codes this tool? (Who comes up with the coding scheme for this tool?)

What coding schema do you use? (E.g. a number like #2.12 or ABC-123?)

Who publishes this tool? How will your staff be able to find it to use it? In a common place?

Who tracks this tool? (What database tracks the tool, it's code, and its approval date?)

Who educates/implements this tool? (Who is responsible for spreading the word that a new tool has entered your clinical arena?)

Who monitors this tool? (Who looks at the tracking database and checks your quality data to look for problems with the tool or its design process?)

Building and completing a CMIO's checklist is a good way to :

Generally figure out where your informatics issues may arise, after you go-live with your EMR.

Generally figure out what committee(s) you will need to approve the maintenance of these tools, and how to build those committees.

Help your committee chairpeople to better define their charters.

Help your middle managers know who is responsible for each part of each tool, when they need to make changes to the clinical setting.

Help the people who design these tools understand the definitions, so that you don't have the "feature bleed" problem I've talked about in previous posts.

Help employees understand the role(s) they play in the overall functioning of your organization.

You will probably want to try completing one of these BEFORE you go-live with your EMR. If you don't, you may have to adjust your governance issues AFTER your go-live.

Remember - Every hospital will have slightly different definitions of these tools, and fill in different titles and committees into each of these boxes. Why? Because unfortunately, there are not universally standard policy-worthy definitions for each of these tools - CMS and Joint Commission curiously don't seem to endorse definitions - I'm not sure why. (What I've written above is just my own example - You may need to adjust the definitions to suit your needs.)

Monday, August 9, 2010

So today I spent a good part of the day with folks from a hospital preparing for their EMR go-live. I went over the role of the CMIO, how to get buy-in, how to develop an informatics platform, and other things that you need to do before you "go-live" with your EMR.
Remember, in the formula for EMR implementation :

The CAR = your EMR

The GAS = 1/2 clinical IT staff, 1/2 Informatics (IS) staff

So we talked about how to budget for your gas, and other issues in getting physician buy-in.
And then, the subject came up about "the order sets". Especially, all of the work that goes into "fixing" the old order sets.
So they reported to me that they were hoping to save some time by just abandoning their old paper order sets, and using some of the "generic electronic order sets" that come with their EMR.
And then I had to break the news to them : Even this won't save you time.

Q : Huh? Dirk, you have posted about how hard it is to fix the old paper order sets. So why can't you just use the order sets that came with your EMR, and tailor them to your needs?

Here's the reason.
Most of your paper order sets (the ones you made before your EMR go-live) actually have little snippets of protocol in them.

Remember, protocols are the "if/then" conditional statements that help automate some nursing process, generally, so your physicians don't get a phone call. (The most common example is the "Heparin protcol", or the "Insulin Protcol", which most people understand fairly well.)
But you probably have other pieces of protocol in your other order sets. Don't believe me? Look at your paper order sets and look for any text that says "If" or "Discontinue when" or "For use in the _____ only", which are all synonyms for "If _____ then ______" - Or, in other words, these are all hidden pieces of protocols.

So the problem you'll have, if you simply abandon your paper order sets and use whatever came with your EMR, is that suddenly all of those pieces of protocol (which are serving you every day) will disappear from clinical function.

And when those hidden, embedded pieces of protocol suddenly disappear from your clinical setting, your docs will suddenly start getting large numbers of phone calls from nurses to clarify these many clinical scenarios.

And this will lead to your CMIO dilemma : When you have your CPOE go-live, suddenly the docs will sense a "serious decrease in efficiency", and the obvious target of their anger will be your EMR. (This is a good way to lose physician buy-in.)

My advice : Repeat the mantra, "There is no such thing as a free lunch when it comes to order sets". Before you decide to adopt this strategy, take a look at your paper order sets. Highlight any pieces of embedded protocol you find (now that I taught you how to find them.) Realize that these protocols will disappear in the electronic world, unless you have the policy mechanism to re-create them as published protocols.

So if you go through all of your paper order sets, and find a lot of pieces of protocols, I wouldn't advise simply getting rid of your paper order sets - Your docs will suddenly feel a loss of productivity and efficiency when you "go CPOE".

I suppose, if you go through all of your paper order sets, you don't find any hidden pieces of protocols, then you may proceed with caution, but if your paper order sets are that well-designed, and your policy mechanism handled protocols well in the past, then these paper order sets won't be too hard to "make electronic" anyway.

(I have yet to meet anyone who has old paper order sets that are built to that level of engineering, but your story may be different.) :)My closing take-home points :